А если по делу написать? Сколько запросов вставки, сколько выборок, характерный объем вставки/выборки... Вы сначала указываете в требованиях "работа с большими объемами информации", и сразу же после называете как кандидат MemcacheDB - уж определитесь, большой объем данных у вас, или БД, помещающаяся в ОЗУ - или у вас на серверах терабайты ОЗУ? :-)

ICPWinnipuh

Потому как не реляциионные (key-value хранилища) в разы быстрее. Как минимум не нужно парсить SQL и т.д


MBG

MemcacheDB в качестве хранилища использует BerkeleyDB. MemcacheDB и Memcache - это совсем разные вещи.

Насколько я себе понимаю, данные целиком кэшируются в ОЗУ, а изменения синхронизируются на диск. Хотя, может быть, это настраивается, но виденные мною тесты относились как раз к такому сценарию.

ICPЗапросов около 50-70 в секунду. Из них большая часть на выборку, примерно около 35-50. Объем базы 38 ГБ. Все это на Mysql и уже очень туго работает.

Мне важно протянуть железо, как можно дольше. Поэтому решил отказаться от SQL и всего остального 'сахара'. Уже оптимизировал выборки, активно работаю с кешом, но это спасет не надолго. Тестил такое key-value хранилище, как Redis. Очень понравилось по скорости, но оно прожорливо на ОЗУ, потому как хранит базу там и периодично дампует ее на винт(((.

Нагрузка небольшая, с такой легко справятся PostgreSQL и SQLite. На первом у меня до пары сотен запросов в секунду отрабатывает, на втором - десятки тысяч запросов в секунду (разумеется, в основном селекты). При вашем количестве запросов на модификацию вообще нет никаких проблем - на диске 7200 rpm (120 оборотов в секунду) мы можем выполнить 60 полных синхронизаций записи, т.е. эскулайт на десктопном диске позволяет 60 пишуших транзакций в секунду без каких-либо ухищрений, а постгрес намного более, т.к. объединяет набор транзакций в одну операцию сброса буферов.

Вот некоторые тесты упомянутых СУБД:
Тестирование PostgreSQL 8.1 на больших таблицах
Тестирование SQLite 3.6.17-mobigroup.2 на больших таблицах
Тестирование PostgreSQL 8.1 на больших таблицах: денормализация

Вероятно, вам следует оптимизировать построение отчетов, например, так
Построение отчетов - Временные таблицы и виды

Возможно и еще ускорить сложные выборки, но это потребует более сложных техник, в частности,
Построение отчетов - Использование защищенного интерпретатора в pltcl
Логическая оптимизация - Массивы

Что же касается key->value СУБД, то применять их для ускорения выборок - нонсенс. Вот что касается скорости модификации, тут есть большие резоны. Но, если вы посчитаете, то размер БД за год при таких скоростях модификации должен , как минимум, составлять терабайты, иначе овчинка не стоит выделки.


Вы работаете с весьма прожорливой, "падучей" и кривой MySQL, но проблема-то вовсе не в реляционных СУБД как таковых, а в конкретной реализации выбранной вами. Если вы в этом сомневаетесь, попробуйте выполнить вышеназванные тесты на нескольких разных СУБД на своем железе, сами увидите.

P.S. C PostgreSQL нужно быть очень осторожным, когда размер _выборок_ превышает размер ОЗУ. Вы о размере выборок ничего не сказали, но упомянутое мною ограничение касается очень немногих проектов, так что у вас не слишком много шансов на него наткнуться...

MBG
Насколько я себе понимаю, данные целиком кэшируются в ОЗУ, а изменения синхронизируются на диск. Хотя, может быть, это настраивается, но виденные мною тесты относились как раз к такому сценарию.


Посмотрел, полное кэширование не является необходимым, можно настроить объем shared memory для berkeleydb, а полное кэширование это в Redis.

Выборки в SQL СУБД выполняются практически с той же скоростью. А вот при агрегации на уровне приложения вы можете существенно потерять в эффективности, т.к. придется много данных передавать из БД в приложение.

Для БД, увеличивающейся на 10 ГБ в год, характерна нагрузка порядка единиц запросов модификации в секунду. При том, что реляционные СУБД на современных десктопах выдерживают в сотни раз большие нагрузки. Потому нет никаких разумных причин отказываться от использования реляционных СУБД.

Для работы с деревом имеет смысл сделать единственным запросом такую выборку, по которой можно построить дерево на уровне приложения (если таблица небольшая, порядка тысяч записей, может даже оказаться оправданным прочитать ее целиком). Рекурсивный SQL выдержат только встраиваемые СУБД (SQLite, BerkeleyDB), в которых prepared запрос выполняется чрезвычайно быстро. При использовании хранимой функции можно в ней кэшировать запрос или некоторые часто используемые выборки, вариантов оптимизации много.

А вы попробуйте тесты для SQLite. 10 000 запросов в секунду это немного для встраиваемой реляционной СУБД.

Хранимые процедуры в PostgreSQL выполняют запросы медленнее, чем те же запросы исполняются в SQLite. Как минимум, потому, что первый - версионник, и имеет некоторый оверхед из-за необходимости анализировать версии записей. Далее, при агрегации на уровне СУБД нет необходимости хранить все данные в памяти - их можно агрегировать "на лету" (POstgreSQL, насколько мне известно, этого делать не умеет), а передавая их в приложение или хранимую процедуру, мы опять же выполняем лишние копирования данных, что требует выделения и очистки памяти и проч. действия. Встраиваемые СУБД хороши тем, что в них обычно обеспечена эффективная работа с данными на диске, в то время как клиент-серверные реализации запихивают все исходные данные в кэш, надеясь на то, что они еще понадобятся - при этом, если данные не помещаются в кэш или выборки оперируют разными данными, возникают большие проблемы.

SQLite и BerkeleyDB не имеют встроенной рекурсии. Но prepared запросы в них позволяют извлекать данные настолько быстро, что набор последовательных запросов, извлекающих одну строку, почти эквивалентен одному запросу, извлекающему набор строк.
Как пример, поиск направления для набранного номера в телефонном биллинге (SQLite):
СУБД SQLite закэширует SQL-запрос и каждый последующий вызов уже не парсит SQL код, выполняется только выборка согласно значениям параметров запроса. В постгресе эквивалентный код необходимо поместить в хранимую процедуру, которая при первом обращении подготовит prepared запрос и сохранит его в глобальной переменной, а возвращаемый результат представить в виде некоторой структуры данных - соответственно, больше работы на выполнение запроса, да еще нужно формировать данные в функции и потом их разбирать в приложении (функции, возвращающие набор строк, работают существенно медленнее, чем возвращающие единственное значение).