Задача такая. Надо сделать ньюсфид для проекта, в с ежедневной посещаемостью в несколько миллионов юзеров.
То есть для каждого пользователя логируются события, которые происходят с ним либо с его друзьями при взаимодействии с различными сущностями проекта, внешними приложениями итд. Примерно то же, что сделано vkontakte.ru, если посмотреть "новости друзей".

Сейчас реализация такая. Все события для каждого id хранятся в памяти, группировка и фильтарция делается вручную при отдаче (все это на С++). Вся база дампится на диск при выключении демона, загружается при старте.
Проблема в том, что сейчас в день набегает несколько Гб данных, и хранить дальше все в памяти уже невозможно. Можно сделать шардинг на несколько серверов, но это сопряжено с проблемами ("новости друзей"). Хочеться попробовать выжать еще из одного сервера.

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

Начал писать собственный движок, но все время гложет мысль, не изобретаю ли я велосипед:) Что думаете начет libmysqld или sqlite ? Опыта работы ни с тем, ни с другим у меня нет.

Насколько хорошо работают эти штуки на объемах в пару сотен гигов при простых insert и select по числовому id? Что еще посоветуете? В первую очередь интересует мнение уважаемого MGB:)

Структура данных у нас простая - грубо говоря, одно событие - это
struct event {
int user_id;
int delete_id; /*уникальный id, назначемый клиентом и используемый им для удаления*/
std::string attachment; /*строка произвольной длины, содержащая доп.инфу про событие.*/
/*... набор id для фильтрации и группировки*/
};

Надо выбирать по большому набору id (все друзья юзера). Еще события нужно уметь удалять уникальному id(например, юзер добавил фотку, потом удалил). События происходят в произвольном порядке, соответственно база как я понимаю будет не только большая, но и очень фрагментированая.

MBGимхо в описанной задаче стоит обращаться к БД напрямую на чтение (распараллеливая операции чтения на множество потоков выполнения), а запись выполнять из одного потока пакетно, например, раз в 5 секунд. В памяти можно вообще ничего не хранить, кроме не сброшенных на диск данных

Я так понимаю что SQLite полностью лочит базу при вставке, соответственно все читающие треды в этот момент будут ждать, и сервер будет лагать с какой-то периодичностью. Для этого собственно я и собирался использовать свой кеш, чтоб большинство чтений происходило прямо из него, а с базой работал отдельный тред или группа тредов(один на запись и несколько на чтение). По крайней мере кеш ОС(FreeBSD 7.3) в таком случае нас не выручал, и когда начинал сбрасываться буфер на диск, чтение начинало жутко тормозить(на SATA винтах).

Про zlib-сжатие хорошая идея, я тоже думал его использовать:)

Звучит очень убедительно, уже почти начал делать на SQLite, как вы сказали:)
Еще одно небольшое сомнение - сейчас появляются системы, использующие для хранения данных просто кучу маленьких файлов(например, фейсбуковская cassandra). Мнение у людей такое:

'Если вы используете доп. прослойку для работы с данными, то у вас просто плохая файловая система (Ганс Райзер)'

Может, действительно поставить линукс с той же ReiserFS и обойтись вообще без БД? Типа, БД это пережиток времени, когда файловые системы были еще плохими типа виндовых нынешних:) По идее, ReiserFS - тоже использует B+ дерево для индексов, компрессию поддерживает..А сложные запросы и прочие фичи БД мне и не нужны, сам сделаю если надо, нам не сложные отчеты делать, а просто хренову тучу однотипных выборок/вставок.

Что скажете?