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

Предположительно, в качестве ORM хочу использовать MongoEngine и SQLAlchemy.

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

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

также предлагаю тестировать с большим количеством баз (~3000)

Может и набор тестовых данных посоветуешь?

[ диванный хайлоад ] Сравнение Огурцов и Картошки

Fxd.

Сумничал, ня?

какой в єтом смьісл?

// я серьезно

PostgreSQL выйграет )

Ты еще запросы на них поделай и поймешь, что они разные.

Могу дать тебе базу ulogd

Я в курсе же. Потому и ORM.

Гугл сказал что это логгер который умеет логировать в базу. И как, большая? Сложные связи есть?

смысл в том, чтобы сравнить эффективность работы механизма кеширования.

скрипт напиши, который будет забивать таблицы рандомными данными.

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

А с одной базой но большим обьемом данньіх нельзя проверить то же самое?

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

PostgreSQL выйграет )

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

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

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

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

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

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

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

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

в куче 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 одной таблицей не обойтись.

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

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

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

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

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

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

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

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

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

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

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

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

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

Про коуч речи не идёт. Монго же возвращает объект курсора.

Лопни мои глаза! Извини, промазал....

Бывает. Кстати, мне лично, Коуч не понравился почему-то. Как-то субъективно Монго приятнее.

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

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

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

boss_db поддерживает и ужа, и ежа.

Проблема в том, что я не поддерживаю Erlang.

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

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

А в чем практическая необходимость сабжа? Просто если сходить с ума, то по-максимуму.

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

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

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

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

не провалится, по крайней мере в скорости поиска данных по ключу.

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

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

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

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

Окай.

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