Хабрахабр / Комментарии к посту «MongoDB и MySQL в Ruby и PHP» в блоге «Веб-разработка»

10.04.2010 05:49:26 phpclub

phpclub — Sat, 10 Apr 2010 05:49:26 GMT

Про Mongo — будет на DEVCONF — фанаты Mongo — объединяйтесь…
devconf.ru/phpconf/offers/50

01.03.2010 19:38:55 latrommi

latrommi — Mon, 01 Mar 2010 19:38:55 GMT

Он овпадает с бордовым.
mysql-ruby-18 ~ mysql-ruby-ent

01.03.2010 11:29:44 justabaka

justabaka — Mon, 01 Mar 2010 11:29:44 GMT

Я вроде бы не дальтоник, но графика с цветом, заявленном в легенде для mysql-ruby-18, не вижу (темно-синий). Что-то перепуталось :)

15.11.2009 06:39:08 bergamot

bergamot — Sun, 15 Nov 2009 06:39:08 GMT

MongoDB не дает ответа insert/update/delete, просто глотает.

Если работать через драйвер Python — по умолчанию на insert даёт ответ.

In [7]: mydb.users.insert({
   ...:     'username': 'test',
   ...:     'password': 'secret'})
Out[7]: ObjectId('4affa006c8021f0a53000001')

Разумеется это можно отключить, что даст нехилую прибавку в скорости. 150 000 простых объектов вставляется за 45 секунд. С опцией manipulate=False — за 30.

12.11.2009 00:53:44 TravisBickle

TravisBickle — Thu, 12 Nov 2009 00:53:44 GMT

Хороший топик, и некоторые комменты порадовали.
Но вот в чем приколы (!):

1. MongoDB не дает ответа insert/update/delete, просто глотает. Чтобы узнать успешна ли операция надо в тот же коннект запульнуть специальный запрос и получить ответ.

2. На каждый коннект выделяется 1 тред, который по порядку выполняет операции приходящие в этот коннект. Поэтому, для нормального бенчмарка надо хотя сделать кол-во коннектов большим или равным 2*кол-во ядер.

3. В MongoDB операция insert это фактически thread-safe изменение позиции вставки (чтоб два конкурентных инсерта не перезаписали одну и ту же позицию в файле) и собственно mmap. Ну и конечно ~~задроченное~~ заоптимизированное обновление индекса. Это происходит ну очень быстро, нет смысла сравнивать с MySQL и прочими «сложными» базами данных. Упрётесь в сеть/в диск, никак не в CPU и не в архитектурные блокировки.

10.11.2009 05:19:03 rosko

rosko — Tue, 10 Nov 2009 05:19:03 GMT

Если ваше гипотетическое приложение будет использовать коллекцию в большей степени для записи, а не для чтения, то используйте Capped Collections в Mongo

09.11.2009 17:50:47 SeLarin

SeLarin — Mon, 09 Nov 2009 17:50:47 GMT

Ага. Я так и сделал. Посмотри ниже. ;)

09.11.2009 14:56:24 drone

drone — Mon, 09 Nov 2009 14:56:24 GMT

Ничего подобного. Данные можно сгруппировать по языкам/версиям. Для осознания результатов достаточно только, к примеру 100000, остальное — информационный хлам. Если уж так хочется его использовать, нужно как-то обработать результаты и нормировать их по количеству операций. Графики показывают только динамику процесса. К примеру на 10000 совершенно не понятно чего лучше, а чего хуже.

09.11.2009 12:30:07 egorinsk

egorinsk — Mon, 09 Nov 2009 12:30:07 GMT

У MongoDB другой интерфйес же, больше пригодный для ORM, а для MySQL вам придется писать уродливую обертку, которая здорово подпортит производительность MySQL. То есть если вы планируете писать запросы рукми — MySQL конечно круче, а если юзаете ORM — то лучше бросайте это бесперспективное дело :)

09.11.2009 11:58:36 pgrishin

pgrishin — Mon, 09 Nov 2009 11:58:36 GMT

Драйвер это понятие из архитектуры самой mongo. сама субд там оперирует бинарными объектами, а интерфес для работы с этими бинарными объектами осуществляется в драйвере, в случае php это модуль .so

09.11.2009 11:46:03 pgrishin

pgrishin — Mon, 09 Nov 2009 11:46:03 GMT

это все предрассудки :) myisam хорошо выполняет предназначенные для него задачи — например, это может быть хорошая ферма slave-ов для запросов с беков — лучше чем innodb.

09.11.2009 11:40:01 pgrishin

pgrishin — Mon, 09 Nov 2009 11:40:01 GMT

ну не совсем так, b-tree в чистом виде мало кто использует, используется «буфферизированные» вставки для обычных индексов, в этом примере вообще только unique индексы, т.е. это по идее вообще аналог key-value бд. Для выборки сложностью все таки будет одинаковая, для записи она будет немного падать, но на фоне работы с жестким диском выглядит как линейная.

По опыту — сначала у обоих всегда ложится винт если есть запись и сеть если нет, по расходу cpu mongo выигрывает. mysql пока лучше работает с сокетами и конкурентностью, но у них там планов на следующий год вагон.

09.11.2009 11:31:07 el777

el777 — Mon, 09 Nov 2009 11:31:07 GMT

Да все что угодно, хоть постгрес, только не маисам :)

09.11.2009 11:18:38 eugyn

eugyn — Mon, 09 Nov 2009 11:18:38 GMT

Правильно ли я понял.
Тестирование проводилось на одной машине?

Если так, то это фигня а не тест.

БД, неважно какая, поделила ресурсы с движком.
Руби, особенно 1.8 ест побольше чем тот же пых. Соответственно базе осталось меньше. Вот она и сливает. И дрова тут не особо причем.

09.11.2009 11:10:31 LupineDreamer

LupineDreamer — Mon, 09 Nov 2009 11:10:31 GMT

я себе представлял такую ситуацию:
от роста количества записей растут индексы, вставка нового индекса — это обычно O(log n)
но если в многодб линейно, то что же с индексами?

09.11.2009 11:03:34 pgrishin

pgrishin — Mon, 09 Nov 2009 11:03:34 GMT

это сам сервис github лагает.
от количества записей скорость не зависит — сложность операций O(1) в обоих случаях.

09.11.2009 11:01:07 pgrishin

pgrishin — Mon, 09 Nov 2009 11:01:07 GMT

почему не bdb xtradb или NitroEDB или BrightHouse? :)
И если на сервере не журналируемая ФС, то innodb на этом севере тоже не бд?

09.11.2009 10:52:09 Pilat

Pilat — Mon, 09 Nov 2009 10:52:09 GMT

У меня возникло подозрение, что Mongo — документоориентированная база данных, а значит Ваш тест не совсем корректен. Может быть cтоит тестировать при сохранении больших объектов?

09.11.2009 10:46:06 LupineDreamer

LupineDreamer — Mon, 09 Nov 2009 10:46:06 GMT

куда-то пропали исходники… nginx выдал not found
но все же посмотреть успел

графики вставки не так интересны, как графики выборки (или лучше даже вместе)
можно написать вставку просто в текстовый файл — и будет заметно быстрее, но явно не есть преимуществом такого подхода

а еще третий график в коментах плохо соответствует первому… пхп и руби ведут себя линейно в первом графике, а отношение — не очень… странно :)

жду с нетерпением графика зависимости времени вставок и времени выборок от количества имеющихся в базе записей

09.11.2009 10:40:57 el777

el777 — Mon, 09 Nov 2009 10:40:57 GMT

> mysql-myisam тоже не бд?
Да, это не БД. Это записная книжка с SQL-интерфейсом. Для серьезных проектов лучше использовать innodb.

09.11.2009 10:14:05 pgrishin

pgrishin — Mon, 09 Nov 2009 10:14:05 GMT

еще я смотрю в монго не safe insert используется, т.е. прием команды не ждет результат вставки.
во время тестов где бутылочное горлышко для mongo и mysql

09.11.2009 09:52:54 latrommi

latrommi — Mon, 09 Nov 2009 09:52:54 GMT

Сорри, не глядя скопипастил инитовую запись.
Вот, например, первая:

> db.bmdb.find({«count»:1});
{"_id": ObjectId( «4af78c6aeb470d23710952bf»), «text»: «i am any text», «count»: 1, «coords»: {«x»: 100, «y»: 200, «z»: 1}}

09.11.2009 09:48:04 pgrishin

pgrishin — Mon, 09 Nov 2009 09:48:04 GMT

а count где?

09.11.2009 09:46:15 latrommi

latrommi — Mon, 09 Nov 2009 09:46:15 GMT

habrahabr.ru/blogs/webdev/74683/#comment_2158467

Вы уж простите моё невежество, что я вам ссылками отвечаю.
(Моя лепта в построении семантического веб! :-)

09.11.2009 09:40:39 Shark

Shark — Mon, 09 Nov 2009 09:40:39 GMT

Может потому, что при вставке многих обьектов возрастает и количество ключей их свойств? Оно ведь тоже растет. Рекомендуется использовать очень короткие ключи вроде «datePublished» → «dP».

09.11.2009 09:40:25 latrommi

latrommi — Mon, 09 Nov 2009 09:40:25 GMT

Нет, всё из коробки. Правда для Gentoo понятие «из коробки» несколько растяжимое :)

Покажите db.collection().findone из монго, мне кажется там может быть проблема с типом.

> db.bmdb.findOne()
{"_id": ObjectId( «4af78bb8eb470d23710952bd»), «stub»: «i am empty init doc»}

09.11.2009 09:37:44 shai_xylyd

shai_xylyd — Mon, 09 Nov 2009 09:37:44 GMT

Все зависит от задачи. Делать выводы по одному этому исследованию некорректно. Можно ведь и жигули с суперкаром тестировать на бездорожье и сделать вывод о том, что разницы в принципе нет.

09.11.2009 09:34:33 latrommi

latrommi — Mon, 09 Nov 2009 09:34:33 GMT

Круто! Особенно последний график интересен.

09.11.2009 09:33:14 latrommi

latrommi — Mon, 09 Nov 2009 09:33:14 GMT

Вообще-то PHP тут притянут просто для сравнения, на его месте так же безопасно мог бы чувствовать себя, например, Python. В тестировании мне интересен исключительно Ruby.

Если вам не безразличны бенчмарки среди движков PHP, вы можете проделать их сами.
Я специально оставил исходники в распоряжении читателя :-)

09.11.2009 09:29:23 maxlapshin

maxlapshin — Mon, 09 Nov 2009 09:29:23 GMT

Если есть желание, советую замерять сколько времени суммарно требуется на сериализацию данных у PHP и у руби. Если время одинаковое, то надо думать дальше.

09.11.2009 09:28:58 shai_xylyd

shai_xylyd — Mon, 09 Nov 2009 09:28:58 GMT

хотя-бы однопоточный уровень скорости записи будет соизмерим с PHP

Я полагаю, что мы обсуждаем web-разработку, а в этом случае делать выводы на основе этого теста некорректно. Единственное, что он объективно показывает, что взаимодействие MongoDB с Ruby более медленное, чем взаимодействие с PHP. А нужно сравнивать поведение MySQL и MongoDB. Я уверен в том, что результат в реальных многопоточных условиях может быть другим. И если MongoDB будет быстрее MySQL, то какая разница в том, что в PHP он работает быстрее.

09.11.2009 09:25:36 Shark

Shark — Mon, 09 Nov 2009 09:25:36 GMT

Я к тому, что это не неприятный сюрприз. А задокументированная особенность. Да, она не транзакционная. Да, использовать ее для важных данных не рекомендуют и сами разработчики. Но есть много приложений не столь критичных. Зато у Монго такиииие возможности шардинга, что уххх… И это только начало. Все зависит от того для чего использовать. И как сказал товарищ выше — там где MyISAM часто бывает удобней использовать Монго.

09.11.2009 09:24:03 latrommi

latrommi — Mon, 09 Nov 2009 09:24:03 GMT

Всё по TCP. Над причиной еще предстоит подумать :-)

09.11.2009 09:20:28 latrommi

latrommi — Mon, 09 Nov 2009 09:20:28 GMT

Кому что. У меня была цель сначала протестировать именно insert и именно в реальных условиях (в противовес вставке нормализованных данных в реляционную БД) и только потом find.

09.11.2009 09:20:23 maxlapshin

maxlapshin — Mon, 09 Nov 2009 09:20:23 GMT

myisam — это для тех, кому надо быстро много, но не очень надо надежно вставлять.
Доверять ему важные данные без нужды не стоит.

09.11.2009 09:15:32 pgrishin

pgrishin — Mon, 09 Nov 2009 09:15:32 GMT

вы ос и mysql оптимизировали?

Покажите db.collection().findone из монго, мне кажется там может быть проблема с типом.

09.11.2009 09:14:29 BSDaemon

BSDaemon — Mon, 09 Nov 2009 09:14:29 GMT

Да, кстати, если уж замерять php, то неплохо было бы замерить php 5.3, там все-таки mysqlnd и это совсем не одно и то же как в 5.2.х

09.11.2009 09:12:05 maxlapshin

maxlapshin — Mon, 09 Nov 2009 09:12:05 GMT

Очень жаль. Я думал о его использовании в одном из проектов (по крайней мере попробовать), но пока отложу.

Что касается драйвера, то установили ли вы причину такого провала? Не по http ли общаются с базой?

09.11.2009 09:10:14 pgrishin

pgrishin — Mon, 09 Nov 2009 09:10:14 GMT

mysql-myisam тоже не бд?
mongodb использует mmap()

09.11.2009 09:09:39 latrommi

latrommi — Mon, 09 Nov 2009 09:09:39 GMT

habrahabr.ru/blogs/webdev/74683/#comment_2158418