Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 60
Спасибо за информацию.
Не могли бы вы добавить график mysql-php?
Не могли бы вы добавить график mysql-php?
А чем рисовался график?
Ruby не знаю и могу ошибаться, но, вроде, тестировалась только запись в базу. Вы не погли бы протестировать также, но только на чтение?
Поддерживаю. На самом деле результаты на чтение даже более интересы, нежели insert.
Кому что. У меня была цель сначала протестировать именно insert и именно в реальных условиях (в противовес вставке нормализованных данных в реляционную БД) и только потом find.
Если ваше гипотетическое приложение будет использовать коллекцию в большей степени для записи, а не для чтения, то используйте Capped Collections в Mongo
Имхо, глупость с выключением. О том что данные в Монго надо будет чинить сказано в документации. Вам это критично? Тогда не используйте. Лично у меня на сервере есть ИБП, чего и всем рекомендую :)
mysql-myisam тоже не бд?
mongodb использует mmap()
mongodb использует mmap()
> mysql-myisam тоже не бд?
Да, это не БД. Это записная книжка с SQL-интерфейсом. Для серьезных проектов лучше использовать innodb.
Да, это не БД. Это записная книжка с SQL-интерфейсом. Для серьезных проектов лучше использовать innodb.
Я к тому, что это не неприятный сюрприз. А задокументированная особенность. Да, она не транзакционная. Да, использовать ее для важных данных не рекомендуют и сами разработчики. Но есть много приложений не столь критичных. Зато у Монго такиииие возможности шардинга, что уххх… И это только начало. Все зависит от того для чего использовать. И как сказал товарищ выше — там где MyISAM часто бывает удобней использовать Монго.
Максим, да, это было бы интересным, но, уже благодаря этому, первоначальному и примитивному исследованию я понял, что MongoDB рановато пока использовать и продолжать тестирование буду только тогда, когда он обновится.
Во-первых, он пару раз просто упал во время тестов (в логах не было ничего, даже segmentation fault), а во вторых я заинтересован исключительно в Ruby, поэтому подожду, когда хотя-бы однопоточный уровень скорости записи будет соизмерим с PHP, на котором показано, что гипотетический драйвер MongoDB способен на большее.
В любом случае, продолжение следует.
Во-первых, он пару раз просто упал во время тестов (в логах не было ничего, даже segmentation fault), а во вторых я заинтересован исключительно в Ruby, поэтому подожду, когда хотя-бы однопоточный уровень скорости записи будет соизмерим с PHP, на котором показано, что гипотетический драйвер MongoDB способен на большее.
В любом случае, продолжение следует.
хотя-бы однопоточный уровень скорости записи будет соизмерим с PHP
Я полагаю, что мы обсуждаем web-разработку, а в этом случае делать выводы на основе этого теста некорректно. Единственное, что он объективно показывает, что взаимодействие MongoDB с Ruby более медленное, чем взаимодействие с PHP. А нужно сравнивать поведение MySQL и MongoDB. Я уверен в том, что результат в реальных многопоточных условиях может быть другим. И если MongoDB будет быстрее MySQL, то какая разница в том, что в PHP он работает быстрее.
а напишите выводы по полученным результатам и графикам… как в лабораторной работе в институте, а то возникает ощущение незаконченности исследования
Тест очень синтетический — идет последовательная запись в базу. Это объясняет, почему графики так примитивно выглядят (если ось абсцисс будет в обычной шкале, то мы получим прямые с разным коэффициентом наклона). Если рассматривать MongoDB как замену (дополнение) MySQL в web разработке, то тестироваться должны параллельные запись/чтение.
Все зависит от задачи. Делать выводы по одному этому исследованию некорректно. Можно ведь и жигули с суперкаром тестировать на бездорожье и сделать вывод о том, что разницы в принципе нет.
habrahabr.ru/blogs/webdev/74683/#comment_2158467
Вы уж простите моё невежество, что я вам ссылками отвечаю.
(Моя лепта в построении семантического веб! :-)
Вы уж простите моё невежество, что я вам ссылками отвечаю.
(Моя лепта в построении семантического веб! :-)
Было бы гораздо нагляднее предствить график «Mongo vs MySQL» в виде столбчатой диаграммы. То, что увеличение количества операций увеличивает время выполнения и ежу понятно.
При таком количестве рядов диаграмма просто замусорится, если сделать столбчатую диаграмму. В принципе и так все видно, надо не просто смотреть на график вдоль оси абсцисс, а просто сравнивать значения графиков в одной и той же точке (т.е. смотреть на изменение величины вдоль оси ординат).
Ничего подобного. Данные можно сгруппировать по языкам/версиям. Для осознания результатов достаточно только, к примеру 100000, остальное — информационный хлам. Если уж так хочется его использовать, нужно как-то обработать результаты и нормировать их по количеству операций. Графики показывают только динамику процесса. К примеру на 10000 совершенно не понятно чего лучше, а чего хуже.
Вот есть еще тесты от самих разработчиков www.mongodb.org/display/DOCS/Performance+Testing.
Но ваши лучше тем что есть исходники :)
Но ваши лучше тем что есть исходники :)
Хм, а что если у меня скажем php 5.3 у которой уже типа свой драйвер под MySQL который с ним не плохо я вам скажу работает?
Вообще-то PHP тут притянут просто для сравнения, на его месте так же безопасно мог бы чувствовать себя, например, Python. В тестировании мне интересен исключительно Ruby.
Если вам не безразличны бенчмарки среди движков PHP, вы можете проделать их сами.
Я специально оставил исходники в распоряжении читателя :-)
Если вам не безразличны бенчмарки среди движков PHP, вы можете проделать их сами.
Я специально оставил исходники в распоряжении читателя :-)
Построил еще несколько графиков по приведенным данным. Извините, что картинки выводятся сразу, но они легковесные: по 8 Кб всего.
1. Зависимость времени вставки от количества вставок.
Зависимость линейная, как и предполагал shai_xylyd. Видно, что с MySQL у Ruby дела обстоят одинаково, независимо от версии, а вот с MongoDB у Ruby 1.8 самый низкий результат (максимальное время вставки). PHP, тем не менее, пока может дать фору Ruby в работе с базами (по крайней мере при последовательных вставках).
2. Сравнение времени вставки 100k записей в MySQL и в MongoDB
Ну тут, в принципе пояснять и нечего. Все и так понятно.
3. Отношение времени, затраченного на вставку в MySQL к времени, ушедшему на вставку в MongoDB.
Для Ruby все почти стабильно. А вот для PHP с ростом количества вставок это соотношение снижается. Может кто-нибудь объяснить почему?
1. Зависимость времени вставки от количества вставок.
Зависимость линейная, как и предполагал shai_xylyd. Видно, что с MySQL у Ruby дела обстоят одинаково, независимо от версии, а вот с MongoDB у Ruby 1.8 самый низкий результат (максимальное время вставки). PHP, тем не менее, пока может дать фору Ruby в работе с базами (по крайней мере при последовательных вставках).
2. Сравнение времени вставки 100k записей в MySQL и в MongoDB
Ну тут, в принципе пояснять и нечего. Все и так понятно.
3. Отношение времени, затраченного на вставку в MySQL к времени, ушедшему на вставку в MongoDB.
Для Ruby все почти стабильно. А вот для PHP с ростом количества вставок это соотношение снижается. Может кто-нибудь объяснить почему?
Да, кстати, если уж замерять php, то неплохо было бы замерить php 5.3, там все-таки mysqlnd и это совсем не одно и то же как в 5.2.х
вы ос и mysql оптимизировали?
Покажите db.collection().findone из монго, мне кажется там может быть проблема с типом.
Покажите db.collection().findone из монго, мне кажется там может быть проблема с типом.
Нет, всё из коробки. Правда для Gentoo понятие «из коробки» несколько растяжимое :)
> db.bmdb.findOne()
{"_id": ObjectId( «4af78bb8eb470d23710952bd»), «stub»: «i am empty init doc»}
Покажите db.collection().findone из монго, мне кажется там может быть проблема с типом.
> db.bmdb.findOne()
{"_id": ObjectId( «4af78bb8eb470d23710952bd»), «stub»: «i am empty init doc»}
куда-то пропали исходники… nginx выдал not found
но все же посмотреть успел
графики вставки не так интересны, как графики выборки (или лучше даже вместе)
можно написать вставку просто в текстовый файл — и будет заметно быстрее, но явно не есть преимуществом такого подхода
а еще третий график в коментах плохо соответствует первому… пхп и руби ведут себя линейно в первом графике, а отношение — не очень… странно :)
жду с нетерпением графика зависимости времени вставок и времени выборок от количества имеющихся в базе записей
но все же посмотреть успел
графики вставки не так интересны, как графики выборки (или лучше даже вместе)
можно написать вставку просто в текстовый файл — и будет заметно быстрее, но явно не есть преимуществом такого подхода
а еще третий график в коментах плохо соответствует первому… пхп и руби ведут себя линейно в первом графике, а отношение — не очень… странно :)
жду с нетерпением графика зависимости времени вставок и времени выборок от количества имеющихся в базе записей
это сам сервис github лагает.
от количества записей скорость не зависит — сложность операций O(1) в обоих случаях.
от количества записей скорость не зависит — сложность операций O(1) в обоих случаях.
я себе представлял такую ситуацию:
от роста количества записей растут индексы, вставка нового индекса — это обычно O(log n)
но если в многодб линейно, то что же с индексами?
от роста количества записей растут индексы, вставка нового индекса — это обычно O(log n)
но если в многодб линейно, то что же с индексами?
ну не совсем так, b-tree в чистом виде мало кто использует, используется «буфферизированные» вставки для обычных индексов, в этом примере вообще только unique индексы, т.е. это по идее вообще аналог key-value бд. Для выборки сложностью все таки будет одинаковая, для записи она будет немного падать, но на фоне работы с жестким диском выглядит как линейная.
По опыту — сначала у обоих всегда ложится винт если есть запись и сеть если нет, по расходу cpu mongo выигрывает. mysql пока лучше работает с сокетами и конкурентностью, но у них там планов на следующий год вагон.
По опыту — сначала у обоих всегда ложится винт если есть запись и сеть если нет, по расходу cpu mongo выигрывает. mysql пока лучше работает с сокетами и конкурентностью, но у них там планов на следующий год вагон.
У меня возникло подозрение, что Mongo — документоориентированная база данных, а значит Ваш тест не совсем корректен. Может быть cтоит тестировать при сохранении больших объектов?
Правильно ли я понял.
Тестирование проводилось на одной машине?
Если так, то это фигня а не тест.
БД, неважно какая, поделила ресурсы с движком.
Руби, особенно 1.8 ест побольше чем тот же пых. Соответственно базе осталось меньше. Вот она и сливает. И дрова тут не особо причем.
Тестирование проводилось на одной машине?
Если так, то это фигня а не тест.
БД, неважно какая, поделила ресурсы с движком.
Руби, особенно 1.8 ест побольше чем тот же пых. Соответственно базе осталось меньше. Вот она и сливает. И дрова тут не особо причем.
У MongoDB другой интерфйес же, больше пригодный для ORM, а для MySQL вам придется писать уродливую обертку, которая здорово подпортит производительность MySQL. То есть если вы планируете писать запросы рукми — MySQL конечно круче, а если юзаете ORM — то лучше бросайте это бесперспективное дело :)
Хороший топик, и некоторые комменты порадовали.
Но вот в чем приколы (!):
1. MongoDB не дает ответа insert/update/delete, просто глотает. Чтобы узнать успешна ли операция надо в тот же коннект запульнуть специальный запрос и получить ответ.
2. На каждый коннект выделяется 1 тред, который по порядку выполняет операции приходящие в этот коннект. Поэтому, для нормального бенчмарка надо хотя сделать кол-во коннектов большим или равным 2*кол-во ядер.
3. В MongoDB операция insert это фактически thread-safe изменение позиции вставки (чтоб два конкурентных инсерта не перезаписали одну и ту же позицию в файле) и собственно mmap. Ну и конечнозадроченное заоптимизированное обновление индекса. Это происходит ну очень быстро, нет смысла сравнивать с MySQL и прочими «сложными» базами данных. Упрётесь в сеть/в диск, никак не в CPU и не в архитектурные блокировки.
Но вот в чем приколы (!):
1. MongoDB не дает ответа insert/update/delete, просто глотает. Чтобы узнать успешна ли операция надо в тот же коннект запульнуть специальный запрос и получить ответ.
2. На каждый коннект выделяется 1 тред, который по порядку выполняет операции приходящие в этот коннект. Поэтому, для нормального бенчмарка надо хотя сделать кол-во коннектов большим или равным 2*кол-во ядер.
3. В MongoDB операция insert это фактически thread-safe изменение позиции вставки (чтоб два конкурентных инсерта не перезаписали одну и ту же позицию в файле) и собственно mmap. Ну и конечно
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.
Я вроде бы не дальтоник, но графика с цветом, заявленном в легенде для mysql-ruby-18, не вижу (темно-синий). Что-то перепуталось :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
MongoDB и MySQL в Ruby и PHP