LINUX.ORG.RU
ФорумTalks

[ диванный хайлоад ] Сравнение PostgreSQL и MongoDB


0

1

Сап, Лорчан.
В больном мозге родилась идея из серии «сравнить ежа и ужа». Что я хочу выяснить в ходе эксперимента:
- Cравнение скорости работы этих БД в режиме использования MongoDB как базы с фиксированной структурой данных, то бишь, повторяющим структуру таблиц в Postgres.
- Сравнение отказоусточивости (борьба с ломом в виде прибивания процесса БД на ноде, аки симуляция выпадения ноды).
- Общая скорость и надёжность синхронизации данных между нодами, выбор оптимальных режимов репликации, восстановление данных на ноде при выпадении при записи и всё такое.
Если это всё же имеет смысл, вторая часть вопроса: из железа имеются два ноута и два системника с весьма разношёрстными кишками и д-линковский свич 100 Мбит для их соединения. План таков: одна машина будет «сервером приложений», три остальных - нодами базы данных. Первая машина будет выполнять выборки, запись, замеры, остальные - просто будут «кластером» БД. Так вот, имеет ли смысл проводить эксперимент на таком железе, или лучше снять 4 виртуальных машины на каком-нибудь хостинге? Разумеется, с локальной сетью между машинами. В остальном, реквестирую соображения по методикам тестирования и общей вменяемости затеи.

P.S:
Запостил в толкс, потому что не вижу особо технических вопросов, если неправ - переместите в более подходящий раздел.

Сравнение СУБД разных парадигм это конечно бред, но глянуть результаты все равно было бы интересно.

Dobriy_i_Prostoy ()

идея попахивает бредом немного, но я сторонник мнения «больше тестов, хороших и разных». Так что - делай тесты, а там коммьюнити рассудит. На крайняк - даже если и получится говно - всегда можно запостить на фороникс ;-)

Pinkbyte ★★★★★ ()

заодно протестируй эти субд на разных дистрибутивах GNU Linux и на FreeBSD. и тоже на фороникс.

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

Это очевидно. Но для начала хочется послушать, может чего предложат более интересного.

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

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

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

PostgreSQL выйграет )

Пока для общей структуры БД будет хватать памяти.

Сравнение СУБД разных парадигм это конечно бред

Фигасе! Сравнение СУБД одинаковых парадигм не более чем проверка качества реализации СУБД, а в данном случае это сравнение парадигм.

ТС, проверь ещё сколько занимает разработка, т.е. в сколько строк кода и какой сложности укладываются типовые сложные запросы.

PS: Mongo зарулит по скорости.

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

ТС, проверь ещё сколько занимает разработка, т.е. в сколько строк кода и какой сложности укладываются типовые сложные запросы.

Но я же буду использовать ORM, так что кол-во кода должно не сильно отличаться.

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

конечно нет. Но в куче и так связей нет.

в куче where иногда делать очень сложно.

Зато можно в одной куче хранить сложные объекты.

Например вот у меня: [code=JavaScript]

{ «_id»: «productsPage», «_rev»: «12-c0aed325ce90ccc45503093b67c54e6a», «edit_template»: «chapters_edit.html», «childs»: [ [ «tablo», «productsPage:tablo» ], [ «clocks», «productsPage:clocks» ], [ «scan_101», «productsPage:scan_101» ], [ «switches», «productsPage:switches» ], [ «sunon», «productsPage:sunon» ] ], «name»: «products», «title»: «Продукты», «ctype»: «IBlog», «template»: «chapter_pages.html» }

[/code]

Для этого на Postgre одной таблицей не обойтись.

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

Но я же буду использовать ORM, так что кол-во кода должно не сильно отличаться.

Тоды ой. Но тогда какой это хайлоад?

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

Диванный, очевидно. В принципе, можно сделать два варианта: с ORM и с чистыми запросами.

2demmsnt:
Так не одна таблица предполагается. Пока думаю над вариантом избитого блогоподобного нечта: записи, камменты к ним, возможно, теги, дата и прочее. И выборка по всему этому. Сейчас думаю как генерить набор данных.

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

в качестве ORM хочу использовать MongoEngine и SQLAlchemy

А вот это определённо зря: так ты в значительной степени будешь тестировать ормы, а не субд.

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

ORM это инструмент, позволяющий удобно работать с БД, что уж тут поделать. Но повторюсь: думаю, можно сделать два цикла выборок: с ORM и без, на чистых запросах.

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

Так возьми ulogd она большая и привяжи айпишники к организациям. Типа организация A Имеет такие, а Б другие....

Но еще раз говорю - в Couch ты это оформишь соооооооооовсем по другому. И Couch хранит версии. Получается, что мы сравниваем бульдога с носорогом.

Коуч удобна для хранения таких развесистых документов с полями типа массивов и словарей. Почти идеальна для всяких Wiki или CMS.

А для 1 млн записей по трафику совсем не удобна

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

И еще про ОРМ. Я из БД (Couch) и так получаю Dict. Причем при моей организации это готовый объект, только методы добавь.

А вот с SQL пока соберем объект из 10 таблиц или пока разберем его в них.....

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

Я всякие говносайтики пишу. В Куче есть attacment это для меня решило вопрос. Правда с ними проблемы с русскими именами, но я нашел обход.

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

Аттач файла? Монго умеет GridFS с модулем для Nginx подгрузки файлов оттуда напрямую.

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

Почитай туториал, тебе надо где-то строчек 10 кода написать самому, остальное нагенерируется boss-компилятором.

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

Если бы у меня была практическая необходимость, я бы, безусловно, «асилил». Но для поиграться курить язык с нуля как-то не очень хочется. Не в этот раз.

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

Я даже знаю, какие будут результаты:

Постгрес с грохотом провалится в:
- Вопросах масштабирования. Слон немасштабируем (в современном смысле этого слова) даже если обвешать костылями.
- Скорость поиска данных по ключу.
- Ненужная мудотряска с ACL.

И постгрес выиграет в:
- простоте применения к аппликухам, сайтам типа ЛОРа и чуть выше.
- простоте писания, т.е. дешевизне разработки, ибо привычный SQL вместо какого-то непонятного js, mapreduce, etc.

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

Что-то мне всё меньше и меньше охота проводить сие мероприятие =)

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

Это лишь если ключ целочисленный и табличка небольшая. А провалится он по простой причине:

PRIMARY KEY в постгресе хранится как столбец + unique-индекс. Т.е. данные ячеек хранятся два раза. Сначала будет проход по индексу, а потом поиск по полученному из индекса оффсету к данным. Т.е. на большом объеме данных, когда индекс фрагментирован и не влезает в RAM, будет непредсказуемое количество перемещений головки диска.

Чего не будет в монго-дб из-за сортировки данных в хранилищах и некоторых других приемов KV-хранилищ.

shahid ★★★★★ ()

монго не умеет джоины в принципе, а постгрес не умеет мап-редьюс. Что ты сравнивать будешь? raw select запросы? Нет, такое исследование лишено смысла, увы.

JFreeM ★★★☆ ()

Сравнение грузовика и мотоцикла как раз в духе аватара ТС. Не нужно.

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