Недавно выпущенный Oracle a Berkeley DB back-end to SQLite. У меня, похоже, есть база данных SQLite сотнями мегабайт, которая может очень хорошо выиграть от «улучшенной производительности, параллелизма, масштабируемости и надежности», но на сайте Oracle отсутствуют какие-либо из измерений. Кто-нибудь здесь сделал какой-то бенчмаркинг?Насколько быстро Berkeley DB SQL по сравнению с SQLite?
Я принимал участие в бета-оценке кода SQLite BDB, а один из вещей, которые я пытался получить, это разница в производительности. На данный момент, Я не могу опубликовать точно, что я нашел, пока у меня не будет хотя бы еще один человек оценить мой код, запустить тесты и подтвердить числа, которые я получил (это сделано). Тем не менее, я могу обобщить здесь и сказать, что бывают случаи, когда BDB предлагает значительные улучшения производительности по сравнению с SQLite, особенно в области , обрабатывающей большие нагрузки, которые связаны с параллелизмом записи.
Там, вообще, две мер «быстрого» право - (1) Эффективность: как долго занимает для одного процесса, чтобы сделать XYZ против (2) параллелизм: сколько раз может много процессов делать XYZ в единицу времени. Основной проблемой BDB-адресов является параллелизм - обработка крупномасштабных транзакций. Таким образом, вы думаете обо многих одновременных подключениях к записи и/или изменении содержимого базы данных.
SQLite по дизайну использует блокировку на уровне базы данных, поэтому существует максимум один писатель , который может работать в базе данных одновременно. Таким образом, транзакция SQLite остается более или менее постоянной с количеством одновременных подключений, поэтому ее масштабируемость в приложениях с интенсивной записью действительно измеряется ее эффективностью (1).
BDB, с другой стороны, использует блокировку уровня страницы, которая позволяет нескольким авторам работать в базе данных в заданное время (при условии, что они работают на отдельных страницах). Таким образом, ставка BDB потенциально увеличивается с количеством подключений , и поэтому его масштабируемость является одновременно вопросом эффективности (1) и параллелизма (2), который может складываться.
Главным образом то, что сводится к параллелизму (написанию). BDB может нажимать больше TPS, чем SQLite для нескольких авторов. По транзакции я имею в виду что-то, что изменяет базу данных (как они относятся к любой реальной помощи для операций только для чтения?). При этом для параллелизма чтения (приложения, которые в основном выполняют SELECT), SQLite вполне может пойти в голову с BDB, поскольку блокировка больше не является критичной проблемой.
Что касается размера набора данных, я не уверен. Я не смотрел на . В конечном счете, они используют B-деревья для хранения. В могут быть рассмотрены их соответствующие реализации, но я не исследовал это. I знают, что SQLite может изящно обрабатывать наборы данных в сотни мегабайт и двузначных ГБ (и, возможно, больше теперь, когда была реализована реализация карты грязной страницы ).
Таким образом, если у вас есть приложение, которое использует множество соединений, которые изменяют , данная база данных и конкуренция страниц относительно невелики, тогда BDB может предложить значительные улучшения в производительности. Но соперничество страниц является критической переменной . В пределе, если у вас есть база данных BDB, данные которой состоят из одной страницы , то ее производительность будет соответствовать производительности SQLite во всех случаях , поскольку блокировка уровня страницы здесь эффективно дегенерирует в эквивалент блокировки уровня базы данных - все борется за одну вещь. Однако по мере увеличения числа страниц в BDB (и сокращение страниц уменьшается), максимальный TPS начнет расти с количеством одновременных подключений. Затем с этой точки памяти становится следующим ограничивающим фактором. Но это еще один рассказ .
BTW, я нахожусь в процессе написания статьи об использовании BDB для тех, кто приходит из SQLite.
Статья Ссылки:
Oracle Berkeley DB SQL API vs. SQLite API – A Technical Evaluation
Oracle Berkeley DB SQL API vs. SQLite API – Integration, Benefits and Differences
Это своего рода загруженный вопрос. Результаты будут значительно варьироваться в зависимости от скорости доступа к дискам, размер кэш-памяти, количество вставок против читает, разбиений страниц, параллелизм и т.д., и т.д., и т.д.
В целом, BerkeleyDB может быть очень быстро - Недавно я разработал встроенную платформу для анализа данных для работодателя, которая способна выполнять 40 тыс. Вставок в секунду на 8-ядерную систему x86 (и одновременно делать тысячи считываний в секунду) с набором данных в диапазоне 30G. Это было с полной защитой транзакций.
Это было в лучшем случае, однако - бывали случаи, когда вставки могут падать до 2k в секунду, в зависимости от входящих данных и того, что в настоящее время хранилось в Беркли. Производительность значительно падает, если у вас медленный дисковый ввод-вывод и низкий коэффициент попадания в кеш или постоянно расширяется БД, приводящая к разрыву страниц. Существует также огромное количество настроек, которые вы можете сделать для повышения производительности вашего конкретного набора данных.
В целом это отличная система, но документация и знания довольно тонкие. Я рекомендую The BerkeleyDB Book, вероятно, лучшую ссылку, доступную в настоящее время.
В дополнение к Berkeley DB книги, что Брайан упоминает, вы также можете найти следующие ресурсы полезны:
Как проходит эта статья? –
Повернулось некоторое время назад. Теперь это из моих рук. Не уверен, когда, где он будет опубликован. Может услышать что-то на следующей неделе. –
Вот две белые статьи из статьи: http://www.oracle.com/technetwork/database/berkeleydb/learnmore/bdbvssqlite-wp-186779.pdf http://www.oracle.com/technetwork/database/berkeleydb /learnmore/bdbvssqlite-wp-186779.pdf –