Как быстро является Беркли DB SQL по сравнению с SQLite?
Oracle недавно выпустила бэкенд DB Беркли к SQLite. У меня, оказывается, есть сотни мегабайтов базы данных SQLite, которая могла очень хорошо извлечь выгоду из "улучшенной производительности, параллелизма, масштабируемости и надежности", но сайт Oracle, кажется, испытывает недостаток в любых измерениях улучшений. Кто-либо здесь сделал некоторое сравнительное тестирование?
3 ответа
Я участвовал в бета-оценке кода BDB SQLite и одного из Я пытался разобраться с разницей в производительности. В этот момент, Я не могу опубликовать то, что нашел, пока у меня не появится хотя бы еще один человек оценить мой код, запустить тесты и подтвердить полученные числа (которые сделано).Однако я могу обобщить здесь и сказать, что есть случаи, когда BDB предлагает значительные улучшения производительности по сравнению с SQLite, особенно в область обработки тяжелых нагрузок, связанных с параллелизмом записи.
Как правило, есть два показателя «быстрого» правильного - (1) эффективность: как долго требуется, чтобы один процесс выполнял XYZ по сравнению с (2) параллелизмом: сколько раз многие процессы могут выполнять XYZ в единицу времени. Основная проблема, которую решает BDB: параллелизм - обработка крупномасштабных транзакций. Таким образом вы думаете о многих одновременные соединения, записывающие и / или изменяющие содержимое базы данных.
SQLite изначально использует блокировку на уровне базы данных, поэтому существует максимум один писатель, который может работать с базой данных одновременно. Таким образом, транзакция SQLite скорость остается более или менее постоянной с количеством одновременных подключений, поэтому его масштабируемость в приложениях с интенсивной записью действительно измеряется его эффективность (1).
BDB, с другой стороны, использует блокировку на уровне страницы, что позволяет нескольким авторам работать в базе данных в данный момент (при условии, что они работают над отдельные страницы). Таким образом, скорость BDB потенциально увеличивается с увеличением количества соединений, и поэтому его масштабируемость является как вопросом эффективности (1), так и параллелизм (2), который может складываться.
В основном это сводится к параллелизму (записи). BDB может выдавать больше TPS, чем SQLite для нескольких писателей. Под транзакцией я подразумеваю то, что изменяет база данных (как они могут реально помочь для операций только для чтения?).Тем не менее, для параллелизма чтения (приложения, которые в основном выполняют операции SELECT) SQLite вполне может пойти лицом к лицу с BDB, потому что блокировка больше не является критической проблемой.
Что касается размера набора данных, я не уверен. Я не заглядывал в что. В конечном итоге они оба используют B-деревья для хранения. Могут быть факторы в их соответствующие реализации, чтобы рассмотреть, но я не исследовал это. я знайте, что SQLite может корректно обрабатывать наборы данных размером в сотни МБ и двузначные ГБ (и, возможно, больше теперь, когда реализация карты грязных страниц был изменен).
Следовательно, если у вас есть приложение, в котором используется много соединений, которые изменяют для данной базы данных и страниц относительно низкая конкуренция, тогда BDB может предложить значительные улучшения производительности. Но разногласия по страницам имеют решающее значение. Переменная. В пределе, если у вас была база данных BDB, данные которой состояли из одна страница, то его производительность будет соответствовать производительности SQLite во всех случаях потому что блокировка на уровне страницы здесь эффективно вырождается в эквивалент блокировка уровня базы данных - все борются из-за одного. Однако, как количество страниц увеличивается в BDB (и уменьшается конкуренция за страницы), затем Максимальный TPS начнет расти с увеличением количества одновременных подключений. потом с этого момента следующим ограничивающим фактором становится память. Но это другое история.
Кстати, я сейчас пишу статью об использовании BDB для тех, кто собирается из SQLite.
Ссылки на статьи:
Oracle Berkeley DB SQL API vs. SQLite API - техническая оценка
Oracle Berkeley DB SQL API vs.SQLite API - интеграция, преимущества и различия
Это довольно сложный вопрос. Результаты будут сильно отличаться в зависимости от скорости доступа к диску, размера кеша в памяти, количества вставок и чтений, разделения страниц, параллелизма и т. Д. И т. Д.
В целом BerkeleyDB может быть чрезвычайно быстро - недавно я разработал платформу анализа данных для работодателя, которая была способна выполнять 40 тыс. вставок в секунду на 8-ядерной системе x86 (при этом выполняя тысячи операций чтения в секунду) с набором данных в диапазоне 30 ГБ . Это было с полной защитой транзакций.
Это был лучший случай - были случаи, когда количество вставок могло упасть до 2 КБ в секунду, в зависимости от входящих данных и того, что в данный момент хранилось в Беркли. Производительность значительно падает, если у вас медленный дисковый ввод-вывод и низкая скорость попадания в кеш или если вы постоянно расширяете БД, вызывая разбиение страниц. Существует также огромное количество настроек, которые вы можете сделать, чтобы повысить производительность для вашего конкретного набора данных.
В целом это отличная система, но документации и знаний довольно мало. Я рекомендую The BerkeleyDB Book как, вероятно, лучший справочник, доступный в настоящее время.
В дополнение к книге Berkeley DB, о которой упоминает Брайан, вы также можете найти полезными следующие ресурсы:
- Онлайн форумы Berkeley DB могут дать много предложений как от пользователей, так и от разработчиков продукта. См. Berkeley DB forum,
- Набор документации Berkeley DB, который можно найти здесь. В частности, в Справочном руководстве есть несколько разделов, посвященных настройке, производительности и пропускной способности.