Компания EnterpriseDB провела (http://blogs.enterprisedb.com/2014/09/24/postgres-outperform.../) тестирование производительности средств для обработки неструктурированных данных в формате JSON в PostgreSQL 9.4-beta (в данном выпуске появился новый тип JSONB (http://www.craigkerstiens.com/2014/03/24/Postgres-9.4-Lookin.../)) и MongoDB 2.6. PostgreSQL оказался в разы быстрее MongoDB при выполнении выборки, загрузки и вставки сложных наборов данных в условиях работы с хранилищем, включающим 50 млн записей. Кроме того, для хранения такого объёма данных MongoDB потребовалось на 33% больше дискового пространства. Примечательно, что в тесте с хранилищем из 10 млн записей PostgreSQL и MongoDB показали примерно одинаковые результаты. Исходные тексты тестового набора опубликованы (https://github.com/EnterpriseDB/pg_nosql_benchmark) на GitHub.
<center><a href="http://www.enterprisedb.com/sites/default/files/50Mil-chart.... src="http://www.opennet.me/opennews/pics_base/0_1411797306.png" style="border-style: solid; border-color: #606060; border-width: 15x;max-width:100%;" title="" border=0></a></center>URL: http://blogs.enterprisedb.com/2014/09/24/postgres-outperform.../
Новость: http://www.opennet.me/opennews/art.shtml?num=40690
> Компания EnterpriseDB провелаСам себя не похвалишь - никто не похвалит :)
>Сам себя не похвалишь - никто не похвалит :)Не этот случай. Почитай ка что такое EnterpriseDB
> Не этот случай.Все маркетологи так говорят.
И что?
Старый друг быстрее новых двух.
С couchdb тоже нужно сравнить было.
> С couchdb тоже нужно сравнить было.Стяни тесты с гитхаба и сравни!
На картинке вижу, что MongoDB быстрее. Кто-то врёт или я чего-то не понимаю?
>я чего-то не понимаю?Да. Чтение по ссылке разрешит Ваши сомнения, по сеянные неудачным оформлением текста новости здесь.
Меньшее время выполнения лучше, не?
ну тут оси не проименованы, сверху заголовок производительность, значит столбцы обосзначают производительность (в хз каких единицах), так что у господина выше не зря сомнения возникли
Присоединяюсь. Подписывать оси учат в школе, но всем "ынтырпрайзным" графикам почему-то их недостает.
не только подписывать оси, но и считать ОДЗ. Инфа 146%!
https://github.com/EnterpriseDB/pg_nosql_benchmark/issues/5
Хотел бы я посмотреть на человека, который будет выбирать между монгой и постгрей по критерию "быстрее-медленнее". Обычно критерий такой: что важнее - репликасет с автовыбором мастера или поддержка ACID-транзакций.
Например, если уже есть постгри, зачем создавать дополнительную точку отказа?
Затем, что по сравнению с постгрей монга - вообще не точка отказа.
И правда: если уже есть карьерный самосвал - зачем нам легковушки? :)
Ну на, смотри. Твой обычный критерий ваще не к месту.
Чего-то я не понял, в новости говорится: "Примечательно, что в тесте с хранилищем из 10 млн записей PostgreSQL и MongoDB показали примерно одинаковые результаты."
А в оригинальной статье:
"The data(результаты тестирования то есть) is almost identical to the results found in testing with 10 million records. However, it’s important to note a Correction to earlier versions. PostgreSQL community member Alvaro Tortosa found that the MongoDB console does not allow for INSERT of documents > 4K. This led to truncation of the MongoDB size by approx. 25% of all records in the benchmark."И вот выдержка из предыдущего тестирования (с 10 млн. записей):
"In testing, EDB has found that Postgres outperforms MongoDB in selecting, loading and inserting complex document data in key workloads:
- Ingestion of high volumes of data was 2.2 times faster with Postgres
- MongoDB consumed 35% more disk space
- Data inserts took three times longer with MongoDB than Postgres
- Data selection took almost three times as long with MongoDB than Postgres
"
>при выполнении выборки, загрузки и вставки сложных наборов данных в условиях работы с хранилищем, включающим 50 млн записей.Спасибо за эту чудесную новость. За тесты баз данных написанных на bash, особое спасибо, и за вот этот чудный набор "сложных запросов", на которых всё и мерилось:
F_MONGOSELECT1="db.${F_COLLECTION}.find({ brand: 'ACME'})"
F_MONGOSELECT2="db.${F_COLLECTION}.find({ name: 'Phone Service Basic Plan'})"
F_MONGOSELECT3="db.${F_COLLECTION}.find({ name: 'AC3 Case Red'})"
F_MONGOSELECT4="db.${F_COLLECTION}.find({ type: 'service'})"
Какие-то у вас глупые претензии. На самом деле же проблема этого теста в другом, mongo предназначена для шардинга и тестировать её с одним экземпляром - не честно.
>Какие-то у вас глупые претензии.Эм... серьезно? Запускать клиента из шелла на каждый запрос, вместо постоянного соединения — вот это по настоящему глупо, а еще глупо при этом мерять производительность, в этих тестах мерятся что угодно, только не производительность.
>На самом деле же проблема этого теста в другом, mongo предназначена для шардинга и тестировать её с одним экземпляром - не честно
Да тут весь тест это одна большая проблема.
> Эм... серьезно? Запускать клиента из шелла на каждый запрос, вместо постоянного
> соединения — вот это по настоящему глупо,Если хочется попиарить свой Энтерпрайз - сами понимаете...
> Запускать клиента из шелла на каждый запрос, вместо постоянного соединениясуровые реалити сегодняшнего дня - учитывать время соединения.
не удивительно
На тему JSONB и производительности неплохо рассказывали давеча на PostgreSQL Meetup (https://tech.yandex.ru/events/yagosti/24-sep-2014/). Думаю, скоро должны записи выложить, кому интересно - рекомендую посмотреть.
> На тему JSONB и производительности неплохо рассказывали давеча на PostgreSQL Meetup (https://tech.yandex.ru/events/yagosti/24-sep-2014/).
> Думаю, скоро должны записи выложить, кому интересно - рекомендую посмотреть.jsonb - заманчиво
jsonp, jsonrpc - еще есть такие игрушки
Ещё одно доказательство, что NoSQL - просто запоздалый базворд "ниочём".
Сетевые и иерархические базы уже делались аж в 70-ых. На сегодня они чуть менее, чем не нужны. Реляционные (даже при всех их недостатках) более-менее хорошо справляются со всеми задачами современности. Вопрос: кому и почему не сидится и не юзается реляционки? "абы как, лишь бы не так"? Так это к доктору надо, а не в ИТ!
как это ни странно, но смысл применения "отсутствия схемы" - именно в отсутствии схемы. :)
>Ещё одно доказательство, что NoSQL - просто запоздалый базворд "ниочём".Правда? То есть все NoSQL кэши к БД вроде memcached можно сразу выкинуть и производительность от этого не упадет?
> На сегодня они чуть менее, чем не нужны.
На сегодняшний день NoSQL это единственное решение позволяющее без гемороя хранить данные с горизонтальной масштабируемостью производительности.
>Реляционные (даже при всех их недостатках) более-менее хорошо справляются со всеми задачами современности.
Например, с беременностью среди малолетних.
>Вопрос: кому и почему не сидится и не юзается реляционки?
Ну к примеру нужна вам экспертная система, с 10 миллионной вариативностью, мой выбор под неё иерархическая/графовая база данных, скажем Neo4J, ну а ваш, по всей вероятности: 10 млн строк кода с if/else.
Или, к примеру, нужна вам сверхбыстрая база хранящая все значения в оперативной памяти и позволяющая выступать в роли брокера сообщений — мой выбор Redis, что вы выбирете из не NoSQL я даже не представляю.> "абы как, лишь бы не так"? Так это к доктору надо, а не в ИТ!
Чёж вы по форумам шляетесь, когда вам к доктору нужно.
Я и не сомневался. Парни из постгреса, в отличие от парней из монгодб, умеют писать нормальные субд.
Одно кольцо, чтобы рулить всеми... тьфу, я не то хотел сказать - в общем, круто, что posgresql можно крутить и для схемной, и для бессхемной базы на высокой скорости.
Вторая часть марлезонского балета - http://obartunov.livejournal.com/179512.html
NoSQL тупиковый путь, что и требовалось доказать.
>NoSQL тупиковый путь, что и требовалось доказать.Интересно как такой вывод делается из статьи о сравнение двух nosql движков?
Очень просто. Постгре содержит NoSql в себе, поэтому не требуется никаких дополнительных хреновин, которые используют только из-за моды и уменьшения в мире количества грамотных разработчиков.
NoSQL нормальный путь, проблема в монге и ее подходе. Она еще и память безконтрольно жрет!
Мне кажется или mongoDB 2.4 давно не последняя стабильная версия? Надо сравнивать с актуальной версией, mongoDB тоже на месте не стоит
мне одному кажется что там в некоторых тестах на каждый запрос запускают бинарник монго/постгрес клиента?
согласен. они идиоты
