Как быстро Беркли DB SQL по сравнению с SQLite?

Я участвовал в бета-оценке кода BDB SQLite и одного из то, что я пытался понять, было разницей в производительности. В этот момент, Я не могу опубликовать то, что я нашел, пока у меня нет хотя бы одного человека оцените мой код, запустите тесты и подтвердите номера, которые я получил (которые сделанный.) Однако, я могу обобщить и сказать, что есть случаи, когда БДБ предлагает значительные улучшения производительности по сравнению с SQLite, в частности зона обработки тяжелые нагрузки, связанные с параллелизмом записи.

есть, как правило, две меры" быстрого " права -- (1) эффективность: как долго требуется ли для одного процесса делать XYZ против (2) параллелизма: сколько раз может ли много процессов делать XYZ за единицу времени. Основная проблема BDB адреса параллелизм - крупномасштабная обработка транзакций. Таким образом, вы думаете о многих одновременные подключения запись и / или изменение содержимого базы данных.

SQLite по дизайну использует блокировка на уровне базы данных, чтобы было не более одного писатель, который может одновременно работать в базе данных. Таким образом, транзакция SQLite скорость остается более или менее постоянной с количеством одновременных подключений, поэтому масштабируемость в приложениях с интенсивной записью действительно измеряется его эффективность (1).

BDB с другой стороны использует блокировку уровня страницы, что позволяет нескольким авторам работать в базе данных в данный момент времени (при условии, что они работают отдельная страница.) Таким образом Скорость BDB потенциально увеличивается с числом соединения и поэтому его масштабируемость - это вопрос эффективности (1) и параллелизм (2), который может складываться.

в основном это сводится к (записи) параллелизма. BDB может нажать больше TPS чем SQLite для нескольких авторов. Под транзакцией я подразумеваю то, что изменяет база данных (как они могут реально помочь для операций только для чтения?). Это сказало, для параллелизма чтения (приложения, которые в основном делают выбор), SQLite может очень хорошо идти голова к голове с BDB, потому что блокировка больше не является критической проблемой.

Что касается размера набора данных, я не уверен. Я не изучал что. В конечном счете, они оба используют B-деревья для хранения. Могут быть факторы в их соответствующие реализации следует рассмотреть, но я не исследовал это. Я знайте, что SQLite может изящно обрабатывать наборы данных в сотни MBs и двузначный GBs (и, возможно, больше теперь, когда реализация карты грязных страниц был измененный.)

поэтому, если у вас есть приложение, которое использует много соединений, которые изменяют данный конфликт базы данных и страницы относительно низок, тогда BDB может предложить значительное улучшение производительности. Но page contention является критическим переменная. В пределе, если у вас есть база данных BDB, данные которой состоят из одна страница, тогда ее производительность будет соответствовать производительности SQLite во всех случаях поскольку блокировка на уровне страницы здесь фактически вырождается в эквивалент уровень базы данных блокировка-все борются за одну вещь. Однако, как количество страниц увеличивается в BDB (и конкуренция страниц уменьшается), затем максимальный TPS начнет расти с количеством одновременных соединений. Затем с этого момента, память становится следующим ограничивающим фактором. Но это другое. история.

кстати, я нахожусь в процессе написания статьи об использовании BDB для тех, кто приходит из SQLite.

статья ссылка:

Oracle Berkeley DB SQL API и на SQLite API-интерфейс – технической экспертизы

Oracle Berkeley DB SQL API против SQLite API-интеграция, преимущества и различия