6850 читателей, 1280 постов
Администрация
Модераторы
Полезности для web-разработчиков.
Web-разработка whois
- индекс
- 184,85
MongoDB и MySQL в Ruby и PHP
Некоторое время назад довольно заинтересовался разработкой для MongoDB и провел некоторые бенчмарки в сравнении с MySQL.Изначально только в Ruby, но, когда результаты изумили (в худшую сторону), то и в PHP, для сравнения.
Может быть, это кому-то сэкономит некоторое время.
Исходные данные:
- Система:
$ uname -a
Linux pavlin.ik 2.6.31-gentoo-r4 #1 SMP Sun Nov 1 18:21:31 MSK 2009 i686 Intel® Core(TM)2 Duo CPU T5450 @ 1.66GHz GenuineIntel GNU/Linux - MongoDB v. 1.0.1
- Gems:
- gem mongo (0.16)
- gem mongo_ext (0.16)
- gem mysql (2.8.1)
- ruby 1.8.7 (2009-06-12 patchlevel 174) [i686-linux]
- ruby 1.9.1p243 (2009-07-16 revision 24175) [i686-linux]
- ruby-enterprise-1.8.7-2009.10
Собственно, результаты:
Вывод один: это не значит, что MongoDB хуже MySQL, это значит, что для нее ещё не написано нормального, быстрого драйвера для Ruby :)
P.S. будет круто, если кто-то проведет аналогичные тесты для Python.
P.P.S. пользуясь случаем, передаю привет TravisBickle ;)
комментарии (57)
Не могли бы вы добавить график mysql-php?
PHP, Ruby 1.8, Ruby 1.9, Ruby Enterprise.
MySQL и MongoDB для каждого.
mongodb использует mmap()
Да, это не БД. Это записная книжка с SQL-интерфейсом. Для серьезных проектов лучше использовать innodb.
И если на сервере не журналируемая ФС, то innodb на этом севере тоже не бд?
Во-первых, он пару раз просто упал во время тестов (в логах не было ничего, даже segmentation fault), а во вторых я заинтересован исключительно в Ruby, поэтому подожду, когда хотя-бы однопоточный уровень скорости записи будет соизмерим с PHP, на котором показано, что гипотетический драйвер MongoDB способен на большее.
В любом случае, продолжение следует.
Я полагаю, что мы обсуждаем web-разработку, а в этом случае делать выводы на основе этого теста некорректно. Единственное, что он объективно показывает, что взаимодействие MongoDB с Ruby более медленное, чем взаимодействие с PHP. А нужно сравнивать поведение MySQL и MongoDB. Я уверен в том, что результат в реальных многопоточных условиях может быть другим. И если MongoDB будет быстрее MySQL, то какая разница в том, что в PHP он работает быстрее.
Вы уж простите моё невежество, что я вам ссылками отвечаю.
(Моя лепта в построении семантического веб! :-)
Но ваши лучше тем что есть исходники :)
Если вам не безразличны бенчмарки среди движков PHP, вы можете проделать их сами.
Я специально оставил исходники в распоряжении читателя :-)
1. Зависимость времени вставки от количества вставок.
Зависимость линейная, как и предполагал shai_xylyd. Видно, что с MySQL у Ruby дела обстоят одинаково, независимо от версии, а вот с MongoDB у Ruby 1.8 самый низкий результат (максимальное время вставки). PHP, тем не менее, пока может дать фору Ruby в работе с базами (по крайней мере при последовательных вставках).
2. Сравнение времени вставки 100k записей в MySQL и в MongoDB
Ну тут, в принципе пояснять и нечего. Все и так понятно.
3. Отношение времени, затраченного на вставку в MySQL к времени, ушедшему на вставку в MongoDB.
Для Ruby все почти стабильно. А вот для PHP с ростом количества вставок это соотношение снижается. Может кто-нибудь объяснить почему?
Покажите db.collection().findone из монго, мне кажется там может быть проблема с типом.
> db.bmdb.findOne()
{"_id": ObjectId( «4af78bb8eb470d23710952bd»), «stub»: «i am empty init doc»}
Вот, например, первая:
> db.bmdb.find({«count»:1});
{"_id": ObjectId( «4af78c6aeb470d23710952bf»), «text»: «i am any text», «count»: 1, «coords»: {«x»: 100, «y»: 200, «z»: 1}}
во время тестов где бутылочное горлышко для mongo и mysql
но все же посмотреть успел
графики вставки не так интересны, как графики выборки (или лучше даже вместе)
можно написать вставку просто в текстовый файл — и будет заметно быстрее, но явно не есть преимуществом такого подхода
а еще третий график в коментах плохо соответствует первому… пхп и руби ведут себя линейно в первом графике, а отношение — не очень… странно :)
жду с нетерпением графика зависимости времени вставок и времени выборок от количества имеющихся в базе записей
от количества записей скорость не зависит — сложность операций O(1) в обоих случаях.
от роста количества записей растут индексы, вставка нового индекса — это обычно O(log n)
но если в многодб линейно, то что же с индексами?
По опыту — сначала у обоих всегда ложится винт если есть запись и сеть если нет, по расходу cpu mongo выигрывает. mysql пока лучше работает с сокетами и конкурентностью, но у них там планов на следующий год вагон.
Тестирование проводилось на одной машине?
Если так, то это фигня а не тест.
БД, неважно какая, поделила ресурсы с движком.
Руби, особенно 1.8 ест побольше чем тот же пых. Соответственно базе осталось меньше. Вот она и сливает. И дрова тут не особо причем.
Но вот в чем приколы (!):
1. MongoDB не дает ответа insert/update/delete, просто глотает. Чтобы узнать успешна ли операция надо в тот же коннект запульнуть специальный запрос и получить ответ.
2. На каждый коннект выделяется 1 тред, который по порядку выполняет операции приходящие в этот коннект. Поэтому, для нормального бенчмарка надо хотя сделать кол-во коннектов большим или равным 2*кол-во ядер.
3. В MongoDB операция insert это фактически thread-safe изменение позиции вставки (чтоб два конкурентных инсерта не перезаписали одну и ту же позицию в файле) и собственно mmap. Ну и конечно
задроченноезаоптимизированное обновление индекса. Это происходит ну очень быстро, нет смысла сравнивать с MySQL и прочими «сложными» базами данных. Упрётесь в сеть/в диск, никак не в CPU и не в архитектурные блокировки.In [7]: mydb.users.insert({ ...: 'username': 'test', ...: 'password': 'secret'}) Out[7]: ObjectId('4affa006c8021f0a53000001')Разумеется это можно отключить, что даст нехилую прибавку в скорости. 150 000 простых объектов вставляется за 45 секунд. С опцией manipulate=False — за 30.