Тест СУБД 2

Сравнительное тестирование быстродействия трех СУБД: MySQL, ZODB, MongoDB

Как и предполагалось (в первой статье) работа с BTree оказала существенное влияние на производительность ZODB. Собственно наблюдались все признаки использования индекса в RDBMS. Запись в базу несколько замедлилась, значительно возросла скорость чтения и, как ожидалось, прозрачностью модели данных пришлось пожертвовать (т.е. если не стремиться максимально ускорить работу, то некоторое подобие прозрачности достичь удалось бы, но это все же не то, что просто писать древовидный (сложный) объект в базу и иметь еще и быструю навигацию по нему, да еще и без загрузки всего дерева в ОЗУ :) ). На самом деле модель получилась вполне удобной - нечто среднее между реляционными таблицами и полностью объектной моделью (из первой части). Использование дискового пространства при этой модели значительно оптимизировалось - почти на порядок лучше чем в первой модели и по этому показателю (как и по скорости чтения данных) ZODB стала бесспорным лидером (впрочем в чтении базы до 1000000 записей очень близко идет MongoDB в начале показывая лучший результат). Расход ОЗУ у такой модели тоже значительно меньше чем у чисто объектной версии. Можно считать такое использование ZODB оптимальным (в первом приближении).

Как и ZODB MongoDB имеет встроенный механизм кэширования (причем очень агрессивный - файлы БД полностью маппируются в ОЗУ) - предполагалось, что это вероятная причина замеченной в первом тесте странной характеристики чтения. Однако дополнительные эксперименты выявили лишь незначительную зависимость производительности чтения от доступной СУБД ОЗУ (кроме того, идея нехватки ресурсов отпадает по причине плавной, без ступенек, кривой графика). Второе предположение не утешительное - как и в MySQL для MongoDB был использован неуникальный индекс и неэффективный алгоритм поиска по индексу дает такую характеристику (в отличие от MySQL). Были проведены дополнительные исследования в этом направлении, изменен алгоритм и индекс сделан уникальным, что привело к предполагаемому, небольшому, увеличению времени записи, но не дало никакого эффекта на чтении. Что позволяет предположить, что либо причина не в индексах, либо алгоритм работы индекса не эффективен в реализации этой СУБД. У MongoDB есть преимущество встроенного горизонтального масштабирования (sharding), однако использование BSON в качестве протокола запросов (формата данных) предполагает однопоточную обработку (аналогичная проблема есть у ZODB). Для разделения по ядрам можно использовать только sharding в пределах одной машины (примерно также проблема решена у ZODB - используется ZEO-сервер, а для обеспечения защиты от сбоев используется платный механизм Zope Replication Service, или открытый ZEOraid). У MongoDB есть ограниченные коллекции которые идеальны для задач логирования, и есть встроенная обработка геоданных (хранение x-y координат и поиск в границах фигур определенных координатами - ограниченный аналог PostGIS). В конечном итоге, попытки выяснить причину столь странного поведения графика последовательного чтения MongoDB, в рамках моего исследования, не увенчались успехом. Чтобы понять в чем дело нужно задавать вопросы разработчикам, или анализировать код драйвера и самой СУБД. Основные мои предположения - либо проблема в алгоритме индексов, либо в драйвере для Python (драйвер можно попытаться исключить реализовав алгоритм на Си, например - что тоже не входит сейчас в мои планы). Информации об этой СУБД не очень много и она очень противоречива (у некоторых эта база показывает очень быстрое чтение, у других запись, у третьих и то и другое, а есть отзывы, что это просто тормоз - думаю многое зависит от версии базы и от использованного драйвера). В процессе поиска ответов, проводились тесты MongoDB в условиях safe=True (ибо наблюдались серьезные потери данных при записи в тестах с составными индексами) - это дало ожидаемое падение производительности записи, примерно в полтора раза, но эта СУБД, бесспорно, осталась самой быстрой в тесте записи.

В общих чертах можно говорить о том, что MySQL - весьма неплохой выбор (средние результаты в обоих тестах, которые, кстати, можно заметно подтянуть в нужном направлении выполнением дополнительной оптимизации), если структура хранимых приложением данных достаточно однородна (как в рассмотренном примере). ZODB оказывается очень удобна для хранения разнородных объектов и предлагает очень быстрое чтение данных, при медленной записи. А MongoDB - напротив быструю запись при, возможно очень, медленном чтении (возможность хранения сложных объектов тоже есть, но она для Python несколько менее доступная, чем в ZODB, IMHO). График чтения MongoDB остановлен на отметке 1666665 записей т.к. он продолжает свой рост в дальнейшем и остальные два графика складываются в один при установленном масштабе рисунка. Итак - окончательные результаты (тестирование до 2М записей, на расширенном дисковом пространстве, и на 1Гб ОЗУ (хотя это увеличение практически не изменило результат), остальные условия - те же, что и в первой статье):

И дополнительные скрипты (остальные 4 взяты из первого теста):

ZODB BTree запись

ZODB BTree чтение

Связанные элементы: Тест СУБД