Персональные инструменты
Вы здесь: Главная / Статьи / Тест СУБД

Тест СУБД

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

Целью этого исследования была сравнительная характеристика быстродействия трех систем управления базами данных (СУБД), реализующих принципиально разный подход к процессам записи, хранения и доступа к данным (по сути это сравнение технологий, а не конкретных СУБД). Итак в сравнении участвовали СУБД: MySQL (RDBMS, или реляционная БД), ZODB (объектноориентированная БД) и MongoDB (документоориентированная БД). В качестве платформы использовалась виртуальная машина с 4-я ядрами (2,66ГГц) с весьма ограниченным дисковым пространством (порядка 3Гб под базу, для дополнительного теста MongoDB в систему было добавлено 25Гб пространства) и 768Мб ОЗУ (в тестах на чтение ZODB использовалось 2048Мб ОЗУ, из-за невозможности чтения тестовых баз на штатном объеме ОЗУ). Для тестирования был реализован (в виде Python-скриптов) простой и универсальный алгоритм моделирующий работу с многоуровневым форумом (блогом). Идея заключается в том чтобы сравнить базы (без специального тюнинга самих СУБД и без глубокй подстройки алгоритма задачи под конкретную СУБД) в реальных условиях среднего (дешевого) интернет-хостинга на реальной задаче (вэб-программировани). Специальной подстройки не проводилось еще и по той причине, что точные (тем более пиковые) значения производительности не требовались, хотелось получить сравнительные характеристики технологий хранения реализованных в исследуемых СУБД. Т.е. определиться с выбором именно технологии для вполне конкретной задачи во вполне конкретных условиях (ограниченных ресурсов) при объемах данных (до 1111110 записей в базе) с одной стороны дающих уже нагрузку на СУБД, с другой - доступных практически любой современной СУБД (и не требующих специальной подстройки, даже если она возможна для конкретной СУБД). Т.е. СУБД работали настроенными "из коробки" условиях достаточных для такой работы, кроме того именно такой (универсальный) режим и был интересен для исследования. Кроме указанного профиля тестирования интересно было посмотреть удобство (прозрачность использования) СУБД из системы программирования на языке Python. По методике - запись (дозапись) в базы производилась порциями по 111110 записей и, соответственно, после каждой порции читалась вся база, таких итераций делалось 10 (конечный объем баз 1111110 записей).

Теперь об особенностях протестированных СУБД. О ZODB я слышал как о надежной и наиболее удобной в использовании из Python (ее главное достоинство) - реализующей прозрачное хранение объектов языка. Кроме того она "из коробки" оптимизирована на чтение (т.е. реализует довольно медленную запись данных и очень быстрое чтение). Эта СУБД единственная в обзоре система транзакций которой "из коробки" поддерживает версии хранимых объектов. У этой базы есть еще один плюс (для исследуемых условий использования) - она работает без предустановленного системного сервиса (демона) - запускаясь прямо из скрипта (в условиях стандартного хостинга можно рассчитывать только на MySQL в качестве бэкенда, а для MongoDB придется брать виртуальный сервер). В целом можно сразу сказать, что эта СУБД проиграла в производительности обоим конкурентам. В плане использования из Python она, конечно, наиболее прозрачна (можно без особых усилий хранить например многоуровневый список и другие сложные объекты), но полной прозрачности все же нет. Чтобы Python увидел изменение хранимого объекта нужно реализовать его в виде совместимого с ZODB класса (взять готовый тип из пакета ZODB, или написать самому с учетом определенных требований). Но основным неудобством (для меня) в этой СУБД стала ее потребность в ресурсах. При записи в базу сложных объектов тестировать чтение стало возможным только при наличии в системе 2048Мб ОЗУ. А при попытке писать в базу простые объекты (аналогично другим СУБД из теста) размер базы вырос во много раз и разместить ее в тестовой системе стало невозможно (поэтому этот вариант теста не проводился). Кроме этого тест на запись перегружал дисковую подсистему (высокие требования к производительности дисковой подсистемы). Поскольку система тестировалась на запись на 768М и 2048М ОЗУ, то появилась возможность сделать дополнительный вывод - на платформе с большим ОЗУ ZODB показала примерно (в некоторых случаях) 15% роста производительности в тесте на запись, однако, такой рост в пределах погрешности даваемой виртуальной платформой.

MySQL показала вполне ожидаемый (средний, но хороший средний) результат. Изначально мое представление об этой СУБД было как об одной из самых быстрых среди SQL реляционных баз, однако теряющей свои преимущества при большой нагрузке, из-за невозможности настроить (как, например, PostgreSQL) поведение системы под увеличенную нагрузку (как по частоте запросов в базу, так и по объему хранимых данных). Однако, условия теста вполне вписываются в "коробочные" требования этой системы (как и других участников теста, да и большинства СУБД вообще). В плане надежности работы эта база (как и ZODB) реализует полную модель ACID (т.е. все требования к транзакциям для обеспечения целостности данных). По итогам теста MySQL была довольно медлительна при записи (и весьма требовательна к производительности дисковой подсистемы). Чтение никаких особых требований не предъявляет, но можно сказать, что читает эта СУБД относительно медленно (чтение примерно вдвое быстрее ZODB и примерно вдвое медленнее MongoDB, впрочем запись примерно в полтора раза быстрее ZODB и во много раз медленнее MongoDB). Однако потребление ресурсов можно считать минимальным (при записи и вычислительная мощность и потребление ОЗУ минимальны, только диск нагружен, но объем базы на диске в итоге минимален, при чтении вычислительная нагрузка вырастает, хотя и остается минимальной среди протестированных систем, ОЗУ - минимально, диск не нагружен).

О MongoDB я слышал, как об очень быстрой СУБД, однако уступающей в надежности (целостности данных) традиционным реляционным SQL СУБД - в этой системе реализована не полная модель ACID. Технология представляет из себя некую смесь реляционной СУБД с быстрыми базами типа ключ-значение. Более подробное знакомство с документацией несколько рассеяло мои сомнения в надежности этой системы (благодаря особенностям технологии полная модель ACID не требуется, просто эта технология не предполагает наличие связанных коллекций-таблиц данных, а атомарность записи в одну коллекцию поддерживается - часть логики работы с базой придется вынести в приложение). Определенным минусом MongoDB можно считать некоторую ограниченность функционала (например невозможность join в запросе) по сравнению с SQL СУБД (в ZODB также есть проблема выборки по отдельным полям объекта - как и в MongoDB здесь хранимые объекты создаются на уровне проектирования и при необходимости выборки части хранимого объекта, в изменившихся условиях эксплуатации, приходится выбирать объект целиком, или перестраивать объектную модель приложения и конвертировать под нее саму базу) - это как-раз особенности технологии хранения. Использованию этой системы с Python показалось мне вполне удобным (с существенной оговоркой - при не очень большом объеме базы - до 1500000 записей). Очень высокая скорость записи данных (уверенное опережение обоих конкурентов), однако весьма странное поведение графика чтения заставило меня сделать несколько дополнительных замеров - они показали, что на отметке в 1333332 записи MongoDB проигрывает MySQL и продолжается дальнейший кубический? рост графика. В плане использования ресурсов - ОЗУ требуется лишь чуть больше чем MySQL, нагрузка на диск минимальна, требование к объему самые высокие (учитывая ZODB в режиме сложных объектов), но вполне приемлемые для условий тестовой системы (под хранение выделяются файлы начиная с 64М, каждый следующий файл вдвое больше - поэтому дисковое пространство выделяется ступенчато и с удвоением), потребление вычислительной мощности при чтении среднее (среди конкурентов), при записи - высокое. В плане особенностей пользования из Python эта система была пожалуй самой приятной (в ней можно хранить сложные объекты, хотя это и не столь удобно и изящно как в ZODB - в MongoDB потребуется привязка (возможно с преобразованием) к вложенного составного поля объекта к сущности базы, в ZODB нужна привязка всего объекта т.е. использование объекта питона в адаптированном к базе виде, хотя это практически не накладывает ограничений - к хранению можно адаптировать любой встроенный тип и, при желании, пользовательский). Условностей в хранимых типах пожалуй не больше чем у ZODB (с одной стороны объекты не всех типов просто хранить, но с другой стороны не требуется метить измененные объекты, поэтому можно легко пользоваться базовыми типами, все это благодаря прозрачному механизму транзакций которого нет у конкурентов). Существенным ограничением этой системы является недоступность ее на стандартном вэб-хостинге. После просмотра полученных графиков я сделал несколько дополнительных измерений - они показали дальнейший кубический? рост графика чтения (лавинное падение производительности), на отметке 1333332 записей MongoDB уже сильно проигрывала MySQL и приближалась к ZODB а на 1555554 - проиграла и ZODB. Поскольку операции чтения в вэб используются значительно чаще можно рекомендовать эту СУБД для небольших баз, или же для применений требующих преимущественно записи данных.

Итак, результаты получились весьма неоднозначные. Кроме того, мой подход к ZODB был пожалуй неоправданно прямолинейным (для хранения в этой СУБД принято использовать структуру BTree - думаю ее можно сравнить с индексом у конкурентов) - поэтому эта СУБД была поставлена в невыгодные условия (хотя использование BTree и наложит дополнительные условия на хранимые объекты и выиграв в скорости эта СУБД может сравняться в удобстве-прозрачности использования). В тесте не проверялась надежность систем хранения. Думаю, у каждой есть свои подводные камни, но в целом все они обеспечат целостность и сохранность данных примерно на одном уровне (с оговоркой, что для MongoDB в приложении будет реализована, при необходимости, дополнительная логика). Весьма интересный график чтения MongoDB побуждает меня выяснить причину такого поведения и провести дополнительные тесты (также несколько изменив скрипт для ZODB).

Теперь результаты (графически):

И скрипты:

ZODB запись

ZODB чтение

MySQL запись

MySQL чтение

MongoDB запись

MongoDB чтение

©(10.01.2013)CIV.Che

Продолжение теста...

Связанные элементы
Тест СУБД 2
Добавить комментарий

You can add a comment by filling out the form below. Plain text formatting. Comments are moderated.