Комментарии 71
В том топике просто такая картинка красивая в начале, вот никто и не заподозрил ошибки :)
Да, за мою графику можете стрелять сразу ) Виновен, не дизайнер.
Да, и спасибо за разбор полетов. А то я сам очень удивился таким результатам.
Хм, странно всё таки в тестах, которые я видел раньше монго был быстрее (но не в 10 раз конечно)…
Я опять же говорю — проверяйте, я мог тоже ошибится в чем-то — на то и исходник.
Ну тесты то сферические. Я видел как результаты где Монго выигрывает, так и где они с мускулем идут на равных.
Да, я тоже погуглил — у кого-то выигрывает, у кого-то проигрывает. Да и во всех базах есть нюансы (multi_insert, INSERT DELAYED, begin-commit и т.п.)
Добавили бы ещё XtraDB иль хотяб INNODB plugin
Ну а больше всего хочется увидеть XtraDB с патчами, не внесёнными в основу :)
Ну а больше всего хочется увидеть XtraDB с патчами, не внесёнными в основу :)
А оно есть для Win32? Если есть — добавить в тест не проблема.
Винда мля))))
Угу. Ща ради интереса запущу виртуализированную Fedora сравним заодно с виндой :)
(разумеется сравним — не поменяется ли расположение сил, а не сравним цифры)
10000 items
MyISAM INSERTs 27.0K per sec
INNODB INSERTs 28.6K per sec
Mongo INSERTs 62.5K per sec
MyISAM SELECTs 20.8K per sec
InnoDB SELECTs 20.8K per sec
Mongo SELECTs 12.0K per sec
Mongo cursor(WRONG!) SELECTs 166.7K per sec
100000 items
MyISAM INSERTs 27.9K per sec
INNODB INSERTs 28.4K per sec
Mongo INSERTs 73.0K per sec
MyISAM SELECTs 21.4K per sec
InnoDB SELECTs 21.1K per sec
Mongo SELECTs 14.8K per sec
Mongo cursor(WRONG!) SELECTs 169.5K per sec
100000 items
MyISAM INSERTs 27.9K per sec
INNODB INSERTs 27.9K per sec
Mongo INSERTs 78.7K per sec
MyISAM SELECTs 21.4K per sec
InnoDB SELECTs 21.1K per sec
Mongo SELECTs 14.4K per sec
Mongo cursor(WRONG!) SELECTs 169.5K per sec
Core i7 Fedora 12, ноликов пришлось добавить, при меньшем кол-ве выполняется за 0 секунд и вылезает деление на 0
НЕ скрываю, разочарован Innodb plugin ом :(
MyISAM INSERTs 27.0K per sec
INNODB INSERTs 28.6K per sec
Mongo INSERTs 62.5K per sec
MyISAM SELECTs 20.8K per sec
InnoDB SELECTs 20.8K per sec
Mongo SELECTs 12.0K per sec
Mongo cursor(WRONG!) SELECTs 166.7K per sec
100000 items
MyISAM INSERTs 27.9K per sec
INNODB INSERTs 28.4K per sec
Mongo INSERTs 73.0K per sec
MyISAM SELECTs 21.4K per sec
InnoDB SELECTs 21.1K per sec
Mongo SELECTs 14.8K per sec
Mongo cursor(WRONG!) SELECTs 169.5K per sec
100000 items
MyISAM INSERTs 27.9K per sec
INNODB INSERTs 27.9K per sec
Mongo INSERTs 78.7K per sec
MyISAM SELECTs 21.4K per sec
InnoDB SELECTs 21.1K per sec
Mongo SELECTs 14.4K per sec
Mongo cursor(WRONG!) SELECTs 169.5K per sec
Core i7 Fedora 12, ноликов пришлось добавить, при меньшем кол-ве выполняется за 0 секунд и вылезает деление на 0
НЕ скрываю, разочарован Innodb plugin ом :(
Насчет деления на ноль — это баг Питона.
Там на Linux надо time.clock() было надо поменять на time.time().
У Винды time.clock() — это точные (неокругленные) данные, а у Linux — time.time() — точный.
Парадокс, но факт :)
Спасибо, кстати за результаты. Радует, что отношения примерно те же вышли.
Там на Linux надо time.clock() было надо поменять на time.time().
У Винды time.clock() — это точные (неокругленные) данные, а у Linux — time.time() — точный.
Парадокс, но факт :)
Спасибо, кстати за результаты. Радует, что отношения примерно те же вышли.
Хотя вообще-то странно: InnoDB нос к носу с MyISAM — уверены что таблица создалась с типом InnoDB_Plugin? Обычно такая ровность — это повод подумать что что-то не так.
Вы чертовски правы, у меня дефолт — иннодб
на сколько мне известно, дефолт innodb должен читать медленней чем дефолт myisam
Не, там про другое — там первая таблица создается с дефолтом, а вторая — иннодб. Получилось что обе создались как иннодб.
тогда почему такая разница очевидная в тестах?:)
Где? Речь про это:
habrahabr.ru/blogs/mysql/87620/#comment_2625002
10000 items
MyISAM INSERTs 27.0K per sec
INNODB INSERTs 28.6K per sec
100000 items
MyISAM INSERTs 27.9K per sec
INNODB INSERTs 27.9K per sec
на самом деле тут где написано «myisam» был тоже «innodb» (по умолчанию созданный так)…
habrahabr.ru/blogs/mysql/87620/#comment_2625002
10000 items
MyISAM INSERTs 27.0K per sec
INNODB INSERTs 28.6K per sec
100000 items
MyISAM INSERTs 27.9K per sec
INNODB INSERTs 27.9K per sec
на самом деле тут где написано «myisam» был тоже «innodb» (по умолчанию созданный так)…
я про изначальные числа из топика
млин… я не знаю как подробнее объяснить уже.
fallen тестировал на линухе с innodb_plugin (отдельно от топика! в этой ветке!), у него получились результаты с ошибкой (обе таблицы innodb, про которое он и сказал, что одна таблица создалась по дефолту (Как иннодб), а вторая с четким указанием, (тоже иннодб!)), ошибку он исправил. у него настройки по умолчанию (дефолту) создавать innodb, у меня по дефолту — myisam…
при чем здесь изначальные числа из топика?
fallen тестировал на линухе с innodb_plugin (отдельно от топика! в этой ветке!), у него получились результаты с ошибкой (обе таблицы innodb, про которое он и сказал, что одна таблица создалась по дефолту (Как иннодб), а вторая с четким указанием, (тоже иннодб!)), ошибку он исправил. у него настройки по умолчанию (дефолту) создавать innodb, у меня по дефолту — myisam…
при чем здесь изначальные числа из топика?
:) и почему в подобных тестах не указывают настройки БД? у mysql они более чем скромные по умолчанию :)
Всегда с удивлением читаю тесты производительности на неизвестных конфигурациях, на неизвестных версиях субд… Замеры производительности вообще довольно обширная и сложная тема, вплоть до копирования раздела диска где БД лежит, чтобы при последующем ПОВТОРНОМ проведении теста результаты были на тех же условиях. Довольно не плохо об этом еще написано в «High performance Mysql». А так… Это все рокет сайнс…
НЛО прилетело и опубликовало эту надпись здесь
У меня подозрение, что это вторая попытка за день сравнить хрен с пальцем.
Чтобы серьезно сравнивать производительность баз данных, нужно заниматься этим лет тридцать, и то останутся вопросы
— какой режим БД (универсальный, быстрая запись (OLTP), быстрые запросы (Warehousing))
— какая файловая система (или вообще row partition)
— какое железо (диск — процессоры — память хотя бы)
— сколько параллельных запросов работало
— писались ли логи UNDO и REDO в каждом случае.
Для школьников исследования, подобные вашим, еще адекватны, а для более старших товарищей — уже не очень.
— какой режим БД (универсальный, быстрая запись (OLTP), быстрые запросы (Warehousing))
— какая файловая система (или вообще row partition)
— какое железо (диск — процессоры — память хотя бы)
— сколько параллельных запросов работало
— писались ли логи UNDO и REDO в каждом случае.
Для школьников исследования, подобные вашим, еще адекватны, а для более старших товарищей — уже не очень.
Зря вы на человека наезжаете, он сделал разбор статьи с тестом. Да может у него для майскуля не оптимальные настройки, но если их изменить, то это лишь подчеркнет картину, что тот тест был необъективен.
Мне это все вообще напоминает какую-то игру. А давайте посмотрим, сколько записей и чтений наша СУБД сделает в один поток за секунду? Давайте! Отчего б не посмотреть. Ооо. А ваша-то в 3 раза медленнее, что ж вы так.
Это как сравнивать автомобили по их количеству оборотов двигателя в минуту на нейтралке. Ничего не скажет, как быстро, а главное как хорошо поедет та или иная машина.
Это как сравнивать автомобили по их количеству оборотов двигателя в минуту на нейтралке. Ничего не скажет, как быстро, а главное как хорошо поедет та или иная машина.
Не нравится — не читайте.
Сделайте сами профессиональный обзор с перечислением всех настроек и всего оборудования и показывайте.
«тысячи каментов по всей сети, и что мы видим – кругом говно, говно, говно» © mr. Freeman
Сделайте сами профессиональный обзор с перечислением всех настроек и всего оборудования и показывайте.
«тысячи каментов по всей сети, и что мы видим – кругом говно, говно, говно» © mr. Freeman
> Не нравится — не читайте.
Это неправильно. Я ЧИТАЮ. Я ДУМАЮ, что сравнивать базы данных на основании ограниченного количества запросов — методически неверно. Я ПИШУ об этом.
А то так начнут писать что дважды два пять — и что, тоже не читать?
Большинство "преступлений" совершается под молчание равнодушных.
Это неправильно. Я ЧИТАЮ. Я ДУМАЮ, что сравнивать базы данных на основании ограниченного количества запросов — методически неверно. Я ПИШУ об этом.
А то так начнут писать что дважды два пять — и что, тоже не читать?
Большинство "преступлений" совершается под молчание равнодушных.
Вот я, к примеру, не знал что такое mongodb. Хотел попробовать в одном проекте, но теперь вижу, что ценность оного для меня никакая, так как там упор на чтение.
Вы — герой. Вам не всё равно. Раз такой умный — тусите с каспаровым, ему тоже не всё равно. И не лезьте в садик к школоте, как вы выразились!
Вы — герой. Вам не всё равно. Раз такой умный — тусите с каспаровым, ему тоже не всё равно. И не лезьте в садик к школоте, как вы выразились!
Да, соглашаюсь, но Вы же не можете утверждать, что тест НЕ верный? Он просто не отвечает Вашим требованиям об опубликованной информации. Но если бы я все это описал — от этого мускуль бы не стал в три раза быстрее?
Опять же — мне лично (как автору этого топика) важно например было узнать, что в среднем монго опережает mysql на запись и значительно. Разница в 10-40% на чтение — для меня не играет роли и не для кого особо не должна (в таких тестах), потому что такие выигрыши можно как раз делать разным использованием технологий (bulk insert, begin-commit, multi_get, отложенные ключи и т.п.).
Просто для чего такой тест может быть полезен — так это, например, увидели бы мы что мускуль проигрывает на таких задачах в 10 раз… то можно было бы сделать вывод, что мускуль — пережиток прошлого. Такого вывода сделать нельзя, можно только, что системы примерно равны по производительности и дальнейшее выжимание мощности из них зависит от самого программера.
Сколько ни тужься программеру — но Python не обгонит C — мы это знаем благодаря таким же «сферическим» тестам и можем делать разумный выбор.
Опять же — мне лично (как автору этого топика) важно например было узнать, что в среднем монго опережает mysql на запись и значительно. Разница в 10-40% на чтение — для меня не играет роли и не для кого особо не должна (в таких тестах), потому что такие выигрыши можно как раз делать разным использованием технологий (bulk insert, begin-commit, multi_get, отложенные ключи и т.п.).
Просто для чего такой тест может быть полезен — так это, например, увидели бы мы что мускуль проигрывает на таких задачах в 10 раз… то можно было бы сделать вывод, что мускуль — пережиток прошлого. Такого вывода сделать нельзя, можно только, что системы примерно равны по производительности и дальнейшее выжимание мощности из них зависит от самого программера.
Сколько ни тужься программеру — но Python не обгонит C — мы это знаем благодаря таким же «сферическим» тестам и можем делать разумный выбор.
Что означают результаты проведенного вами теста? Как можно их интерпретировать?
Допустим, вы делаете вывод «Монго выигрывает для приложений, у которых узкое место — запись, а не чтение». При этом надо понимать, что вы имеете ввиду узкую нишу приложений, которые делают миллион мелких запросов в один поток на машине с медленным винтом, один за другим.
Помимо операций чтения/записи есть издержки на работу ЦП. Они несущественны на машинах с медленными винтами, но для серверов с RAID-массивами могут быть более ощутимы. Есть также очень сильные издержки на конкуренцию (concurrency), то есть одновременный доступ к объектам БД множества пользователей, когда часть пытаются писать, а остальные — читать. Согласитесь, распространенная ситуация.
«Сколько ни тужься программеру — но Python не обгонит C — мы это знаем благодаря таким же «сферическим» тестам и можем делать разумный выбор.»
Предположим, у нас есть 1) приложение, которое большую часть времени проводит в ожидании сети, диска или команды пользователя; 2) программа, которая ищет первые 100 тысяч простых чисел. Во втором случае питону действительно не догнать си. В первом — спорный вопрос, издержки ЯП скорее всего будут меньше погрешности для издержек на ожидание пользователя.
Допустим, вы делаете вывод «Монго выигрывает для приложений, у которых узкое место — запись, а не чтение». При этом надо понимать, что вы имеете ввиду узкую нишу приложений, которые делают миллион мелких запросов в один поток на машине с медленным винтом, один за другим.
Помимо операций чтения/записи есть издержки на работу ЦП. Они несущественны на машинах с медленными винтами, но для серверов с RAID-массивами могут быть более ощутимы. Есть также очень сильные издержки на конкуренцию (concurrency), то есть одновременный доступ к объектам БД множества пользователей, когда часть пытаются писать, а остальные — читать. Согласитесь, распространенная ситуация.
«Сколько ни тужься программеру — но Python не обгонит C — мы это знаем благодаря таким же «сферическим» тестам и можем делать разумный выбор.»
Предположим, у нас есть 1) приложение, которое большую часть времени проводит в ожидании сети, диска или команды пользователя; 2) программа, которая ищет первые 100 тысяч простых чисел. Во втором случае питону действительно не догнать си. В первом — спорный вопрос, издержки ЯП скорее всего будут меньше погрешности для издержек на ожидание пользователя.
Каждый интерпретирует, как захочет. Это информация к размышлению, а не исчерпывающий анализ. Информация для «ПОДУМАТЬ».
Вообще логично предположить, что если продукт называют СУБД, и он уже некоторое время присутствует на рынке, то он должен по крайней мере неплохо справляться с самыми базовыми операциями, которые от него требуются.
В таком случае это тестирование демонстрирует, что ДА, действительно, разработчики обеих СУБД не облажались.
Но мы же не сравниваем операционные системы по скорости, с которой они могут забить оперативку машины процессами Hello World.exe (.app/etc)?
В таком случае это тестирование демонстрирует, что ДА, действительно, разработчики обеих СУБД не облажались.
Но мы же не сравниваем операционные системы по скорости, с которой они могут забить оперативку машины процессами Hello World.exe (.app/etc)?
Дело в том, что если у вас упор при линейной записи в любой БД получается не в жестком диске, вы явно где-то неправы. А он должен быть одинаков для любых БД (т.к. ограничении в блочном устройстве). Кроме того, по умолчанию принцип sync-а для mysql mysam, innodb и mongodb разный, надо все это приводить к одному знаменателю, как только вы это сделаете производительность в несколько раз на запись упадет для обоих тестов.
В многочисленных вставках ограничения возникают как правило не в скорости записи на диск, а в расчете индексов (b-tree как правило. Кстати у каждого своя реализация, вот ее интересно было бы сравнить). Тут тоже про это ничего не сказано.
Кроме того, у вас скорость чтения практически равняется скорости записи. Я себе такой представить могу только если вы совсем не используете память (и память БД, и память кеша ФС ОС). Как такое может быть я себе даже не представляю.
Вот пример интересного сравнения
www.mysqlperformanceblog.com/2009/10/15/mysql-memcached-or-nosql-tokyo-tyrant-part-1/
В многочисленных вставках ограничения возникают как правило не в скорости записи на диск, а в расчете индексов (b-tree как правило. Кстати у каждого своя реализация, вот ее интересно было бы сравнить). Тут тоже про это ничего не сказано.
Кроме того, у вас скорость чтения практически равняется скорости записи. Я себе такой представить могу только если вы совсем не используете память (и память БД, и память кеша ФС ОС). Как такое может быть я себе даже не представляю.
Вот пример интересного сравнения
www.mysqlperformanceblog.com/2009/10/15/mysql-memcached-or-nosql-tokyo-tyrant-part-1/
т.е. я поддерживаю — тест не адекватен.
Поддерживаю — тестируйте сами и пишите полный всесторонний обзор.
У меня слишком частные задачи для такого общего обзора :)
Вы не обижайтесь, я просто советую на что обратить внимание. Вас же должно было насторожить что SELECT-ы медленнее INSERT-ов. Я вообще такого не видел.
Думаю у вас сильную погрешность ввело еще то, что клиент (питон-скрипт) и сервер-ы работали на одном железе — т.е. делили ресурсы, а это тоже должно «зашумлять» объективность результата.
Вы не обижайтесь, я просто советую на что обратить внимание. Вас же должно было насторожить что SELECT-ы медленнее INSERT-ов. Я вообще такого не видел.
Думаю у вас сильную погрешность ввело еще то, что клиент (питон-скрипт) и сервер-ы работали на одном железе — т.е. делили ресурсы, а это тоже должно «зашумлять» объективность результата.
Мало смысла на самом деле гонять всё это дело на своих локальных ноутбуках. Надо, кстати, учесть, что и скорости дисков, как бы, тоже решают в данном вопросе, а не только CPU и оперативка, особенно, с учётом любви MongoDB к преаллокации.
Хотите реальности — поднимаем на реальных серверах в конкретных системах, с конкретными конфигурациями и даём реальные стресс-тесты. И тогда получаем сколь-нибудь реальные результаты. А так — это воздух.
Хотите реальности — поднимаем на реальных серверах в конкретных системах, с конкретными конфигурациями и даём реальные стресс-тесты. И тогда получаем сколь-нибудь реальные результаты. А так — это воздух.
Хм, действительно, видимо вы правы. Чтение данных в моём случае не происходило, признаю свою ошибку.
Спасибо за критику)
Спасибо за критику)
а вот я вчера тестировал stas-agarkov.livejournal.com/17659.html
немного не понял про скорость селектов. у меня хоть 140 тыщ выборка, хоть 30. время одинаковое практически.
я делал count, то есть не просто получал курсор. а потом я еще и сумму считал. вторая сумма меньше времени считалась, потому что там цикл по 30 тысячам, а первый раз — по 140 тысячам.
можете прояснить?
немного не понял про скорость селектов. у меня хоть 140 тыщ выборка, хоть 30. время одинаковое практически.
я делал count, то есть не просто получал курсор. а потом я еще и сумму считал. вторая сумма меньше времени считалась, потому что там цикл по 30 тысячам, а первый раз — по 140 тысячам.
можете прояснить?
А может быть Mongo медленный из-за того, что например его библиотека-клиент медленно десериализует данные, или еще что-то там, а майскульная — на Си и работает быстро?
Интересно бы еще многопоточно погонять это дело…
монго занимает все ядра…
этот же тест, без изменений вообще:
MyISAM INSERTs 2.9K per sec
INNODB INSERTs 3.5K per sec
Mongo INSERTs 17.6K per sec
MyISAM SELECTs 2.6K per sec
InnoDB SELECTs 2.8K per sec
Mongo SELECTs 3.3K per sec
В общем, вывод один — этот тест бесполезен
MyISAM INSERTs 2.9K per sec
INNODB INSERTs 3.5K per sec
Mongo INSERTs 17.6K per sec
MyISAM SELECTs 2.6K per sec
InnoDB SELECTs 2.8K per sec
Mongo SELECTs 3.3K per sec
В общем, вывод один — этот тест бесполезен
ну а теперь попробуем сделать репликацию/sharding и поднять количество коннектов к базе для чистоты эксперимента
НЛО прилетело и опубликовало эту надпись здесь
Все, кто предлагает расширить тест, уточнить его и т.п. — мне это не интересно, я узнал что хотел — что все примерно одинаковые — никто никого не убил, никто не тупит. А дальше — все исходники у вас есть — дерзайте.
PyMongo установлен с C-расширением?
api.mongodb.org/python/1.5%2B/installation.html#installing-without-the-c-extension
api.mongodb.org/python/1.5%2B/installation.html#installing-without-the-c-extension
Тест не такой уж и воздух. Он показал, что 99% тех, кто будет ставить одну из баз, получат одинаковую производительность — так как подавляющее большинство настройки не меняет. А оставшийся один процент уже будет думать более продвинуто — и другие базы посмотрит типа postgres, и режимы записи проверит, и разбросает индексы и таблицы по разным дискам. Но зависеть это будет уже от имеющихся ресурсов в каждом конкретном случае.
Давно такой интересной и полезной статьи не было, спасибо!
Поддерживаю предыдущий коммент, жалко, что нету PostgreSQL. Вот это было бы весьма и весьма кстати. Ещё не указано, как был настроен кэш в MySQL, это тоже очень важный момент.
А в целом ещё раз — спасибо.
Поддерживаю предыдущий коммент, жалко, что нету PostgreSQL. Вот это было бы весьма и весьма кстати. Ещё не указано, как был настроен кэш в MySQL, это тоже очень важный момент.
А в целом ещё раз — спасибо.
Потестировал у себя Mongo SELECTы и заметил следующее:
из питона получаю 6.6K per sec
на аналогичной key-value базе из джавы в один поток получаю 18K per sec
из джавы в 10 потоков получаю 30K per sec
дальнейшее увеличение кол-ва потоков у меня уже выигрыша не дает
При этом для MySQL и питон и джава выдают практически одинаковый результат: ~9K per sec
Получается, что драйвер Mongo под питон тормозит и что, в любом случае, лучше тестировать базы в несколько потоков, т.к. это ближе к реальной жизни.
из питона получаю 6.6K per sec
на аналогичной key-value базе из джавы в один поток получаю 18K per sec
из джавы в 10 потоков получаю 30K per sec
дальнейшее увеличение кол-ва потоков у меня уже выигрыша не дает
При этом для MySQL и питон и джава выдают практически одинаковый результат: ~9K per sec
Получается, что драйвер Mongo под питон тормозит и что, в любом случае, лучше тестировать базы в несколько потоков, т.к. это ближе к реальной жизни.
Давайте сделаем тесты и обсудим на DEVCONF.ru
тема MongoDb — весьма актуальна…
devconf.ru/phpconf/offers/26
тема MongoDb — весьма актуальна…
devconf.ru/phpconf/offers/26
Такая ситуация интересная произошла, намедни наткнулся на статью, прочитал с удовольствием, улыбнулся, подумал про себя: «ведь сейчас везде есть MySQL, не проще ли раздобыть хостинг с мускулом, либо установить его на сервере». По прошествию нескольких дней меня попросили написать 1 штуку, нужно использовать БД, а мускула нет на сервере и установить — гемор очень большой (не будем вдаваться в подробности). Бегом полетел искать эту статью, на этот раз добавил в favorites :)). Автору большое спасибо!!!
Тестировал аналогичные продукты на linux debian.
Получилось, что cassandra очень сильно отстает от остальных по всем операциям.
Слышал, что cassandra хорошо себя показывает только на очень мощных серверах.
Получилось, что cassandra очень сильно отстает от остальных по всем операциям.
Слышал, что cassandra хорошо себя показывает только на очень мощных серверах.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
MongoDB vs MySQL (vs Cassandra): А теперь чуть более правильный ответ