LINUX.ORG.RU

PostgreSQL обогнал MongoDB в NoSQL-тестах

 ,


2

6

Компания EnterpriseDB провела тестирование производительности средств для обработки неструктурированных данных в формате JSON в PostgreSQL 9.4-beta (в данном выпуске появился новый тип JSONB) и MongoDB 2.6. PostgreSQL оказался в разы быстрее MongoDB при выполнении выборки, загрузки и вставки сложных наборов данных в условиях работы с хранилищем, включающим 50 млн записей. Кроме того, для хранения такого объёма данных MongoDB потребовалось на 33% больше дискового пространства. Примечательно, что в тесте с хранилищем из 10 млн записей PostgreSQL и MongoDB показали примерно одинаковые результаты. Исходные тексты тестового набора опубликованы на GitHub.

совус

Deleted

Но он же не вебскейл.

x3al ★★★★★
()

Похвально, но нужно погонять кластер против кластера

vertexua ★★★★★
()

ахаха.

еще летом как-то ехал домой, слушал подкасты. в том числе и radio-t. как раз тот выпуск когда у них в гостях был чувак из pg. тогда его там культурно опустили. а на счет этого не очень поверили (говорили нужно проверять) через общий получившийся тон разговора. а тут вот оно как оказалось

ZuBB ★★★★★
()
Последнее исправление: ZuBB (всего исправлений: 2)

во первых странность, в тексте указана 2.6, в картинке 2.4. во вторых, в 2.8 наконец обещают локи на уровне документов, что вполне может изменить результаты до равных. ну и в третьих постгря не шардится автоматически :) хотя конечно, для большинства сайтиков оно и не нужно

wwwsevolod
()
Ответ на: комментарий от wwwsevolod

хотя конечно, для большинства сайтиков оно и не нужно

На большинстве сайтиков и 10млн записей никогда не наберется =)

Siado ★★★★★
()

«В соревнованиях непассажирского транспорта болид F1 обогнал подводную лодку». А если сравнить в задачах хранения данных по ключу Postrgres с Redis? Последний же тоже NoSQL.

...

Postrges научился хотя бы master-master репликации?

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

Сравнивать транзакционную РСУБД с k/v поделкой в памяти, которая пишет на диск не сразу? Нуну

А что редис научился хотя бы master-master?

disarmer ★★★
()
Ответ на: комментарий от KRoN73

Ты ничерта не в теме, ещё бы с memcached предложил сравнивать. Хранение данных в redis у него, лол.

master-master отсюда ещё дальше, это же территория вебскейла и шардинга.

x3al ★★★★★
()
Ответ на: комментарий от disarmer

которая пишет на диск не сразу

Боян.

Разбирался бы ты в монге, знал бы реальные проблемы. А этот боян - лакумусовая бумажка диванного аналитика

vertexua ★★★★★
()
Последнее исправление: vertexua (всего исправлений: 1)
Ответ на: комментарий от vertexua

Ну это наверняка не самая большая проблема nosql, но с точки зрения производительности большая фора

disarmer ★★★
()

Меня больше всего удивило:

для хранения такого объёма данных MongoDB потребовалось на 33% больше дискового пространства

У postgres оверхед начинается от 24 байт на строку, тогда какой же у монги?

disarmer ★★★
()
Ответ на: комментарий от disarmer

У монги обьекты динамические, потому их нужно втискивать в преаллоцированые куски диска. Когда обьект начинает не влезать, то кусок увеличивают, вроде в два раза и переписывают поверх. Они могли подобрать неудачный размер обьекта или неудачные способ записи. Если это так, то трагедия этого бенчмарка еще более глубокая, так как на реальном продашкне это бы людей волновало и они преаллоцировали более удачные размеры

vertexua ★★★★★
()
Ответ на: комментарий от vertexua

Каким образом ты собрался преаллоцировать более реальные размеры для данных неизвестного объема?

anonymous
()
Ответ на: комментарий от anonymous

Варианты

1) Исследовать данные

2) Теоретически их предсказать

3) Реструктурировать данные чтобы они были известного размера

4) Игнорировать, если для текущего проекта проблемы в производительности нет

vertexua ★★★★★
()
Ответ на: комментарий от disarmer

Сравнивать транзакционную РСУБД с k/v поделкой в памяти, которая пишет на диск не сразу? Нуну

А что, MongoDB стала, вдруг, транзакционной? :)

А что редис научился хотя бы master-master?

Вот и сравнение Postrges с Mongo из той же оперы :) Тёплое с мягким.

KRoN73 ★★★★★
()
Ответ на: комментарий от x3al

master-master отсюда ещё дальше, это же территория вебскейла и шардинга.

Очень удивишься, но это первая область применения MongoDB.

KRoN73 ★★★★★
()
Ответ на: комментарий от disarmer

У postgres оверхед начинается от 24 байт на строку, тогда какой же у монги?

MySQL база на 5Гб в MyISAM при конвертации в InnoDB превращается в 9Гб, а при конвертации в Mongo превращается в 12Гб :) Цифры по памяти, до десятых долей на скажу, но целые где-то такие.

KRoN73 ★★★★★
()

Фишка монги в шардинге. Плюс rich-set операций для работы с документами, которых нет в постгре. Короче столбы с коровами сравнивают.

dizza ★★★★★
()

Зачем нужен постгрес?

anonymous
()

Зарализьте PG 9.4 сначала, умники, а потом пишите «разгромные» статьи.

Монга — вещь в себе. Её нужно конкретно уметь готовить. Иначе, возможны различные сюрпризы: от разбухания хранилища до неприличных размеров, до просто банального ступора базы. Кроме того, в монгу встроена «макака хаоса» которая её регулярно роняет, а без repair монга не встаёт, да.

Но есть одна особенность, которая с лихвой перекрывает все недостатки: простота. Во всем. Начиная от протокола, заканчивая моделью данных. Например, программа на C, без особых накладных расходов может спокойно работать с Монгой на wire-level где-нибудь в совершенно эмбеддед-среде. А с Постгре?

И да, забивать гвозди в крышку гроба Монги и говорить прощальные речи будете, когда запилите аналог Aggregation framework.

Macil ★★★★★
()
Ответ на: комментарий от disarmer

У postgres оверхед начинается от 24 байт на строку, тогда какой же у монги?

Бесконечный. Монга не удаляет стертые записи. Любой неаккуратный апдейт хранилища с дефолтными настройками, в т.ч. и *неявный*, способен резко увеличить размер хранилища, из-за чего Монга, скорее всего встанет колом, аллоцируя новый блок размером 2 гига. Гы-гы-гы.

Macil ★★★★★
()
Ответ на: комментарий от Macil

А с Постгре?

А что ей помешает?

когда запилите аналог Aggregation framework.

Какой-то свой особенный язык запросов против стандартизированного SQL? Чем он лучше, кроме нечитаемости?

disarmer ★★★
()

На опеннете написано, что и на 10 млн строк разница была аналогичной.

r_a_vic
()
Ответ на: комментарий от ZuBB

Так это же умпутун, у него всегда так оно когда ломает ему шаблон.

bhfq ★★★★★
()
Ответ на: комментарий от disarmer

Чем он лучше, кроме нечитаемости?

На SQL такая штука делается через CTE, а это мягко говоря, неудобно.

SQL? Стандартизованный? Гы-гы-гы-гы-гы-гы!

Macil ★★★★★
()
Ответ на: комментарий от KRoN73

Ты так говоришь, как будто редис научился.

anonymous
()

Продолжается победоносное сравнение вебскейла со скоростью выборок и транзакциями. Бедняжки, как им пукан-то рвет от монги.

Vit ★★★★★
()
Ответ на: комментарий от Vit

Продолжается победоносное сравнение вебскейла со скоростью выборок и транзакциями.

А вполне себе норм сравнение. Наглядная иллюстрация того, что если не собираешься выделять под монгу приличных размеров кластер, то лучше сто раз подумать, прежде чем с ней вообще связываться.

Manhunt ★★★★★
()

Что еще за webscale? Вот это - http://www.mongodb-is-web-scale.com/ ? Первая ссылка в гугле. Жизус

Голоса роботов, фак-перефак, чикен щит. Очень вдохновляет. Щитаю, постгре-комьюнити должны немедленно снять что-то такое же монументальное

anonymous
()
Ответ на: комментарий от disarmer

А, все, понял. Оно типа умеет, но нужны костыли для переключения в случае вылета одного из.

leg0las ★★★★★
()
Ответ на: комментарий от Manhunt

Ну лично я никогда не проповедовал втыкание монги везде где можно. Просто очень доставляют эти победные тесты, при отсутствии фич за которые монгу любят. В радио-т вообще адский отжиг был - чел обсирал монгу, умудряясь не врубаться в примеры под вебскейл, и приводя аргументы эпохи 2.2 версии. Ну если детство не отыграло - спросили бы для разгромной статьи у знающих людей про косяки монги, они ж все известны.

Я ни в коем случае не против посгреса. Очень годная база.

Vit ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.