Append Only база данных?

а после удаления старых записей место не освобождают

да, но при этом они начинают писать в это место. По крайней мере мускул и innodb. На счёт постгреса не помню.

Файлик сформировался - построили для него b-tree индекс в отдельном файле - транзакции и блокировки ненужны.

создать по таблице на день? Потом drop table/whatever.

А права раздать вьюхами/триггерами.

Ну и может table partitioning как-то в этом поможет...

да, но при этом они начинают писать в это место. По крайней мере мускул и innodb. На счёт постгреса не помню.

В теории, на практике, при регулярно вставке что-то ему мешает.

создать по таблице на день? Потом drop table/whatever.

ага, и рисовать въюху которая будет имитировать таблицу для анализа, только зачем?

А права раздать вьюхами/триггерами.

права там ненужны

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

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

Разве всякие редисы для этого плохо подходят?

Разве всякие редисы для этого плохо подходят?

redis отлично подходит, осталось только найти тачку с 500гиг оперативы...

там придется после удаления таблицы переписывать триггер партицирования

я думаю это можно автоматизировать триггерами.

можно попробовать nilfs с периодическим форматированием разделов со старыми данными

Занятная вещь, только индексы придется ручками рисовать - а это тоже велосипед что и на файлах

mongodb тут больше подхоит, во всяком случае не хранит все в памяти, но вот вопрос каково оно на таких задачах

Cassandra?

mongodb

да слишком мощно, мне нужен тупой журнал с индексами

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

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

logrotate + grep

Да я просто упустил что Редис ориентирован на память.

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

низкоуровневость тут не важна, как в прочем и отказоустойчивость особая.

mongodb тут больше подхоит, во всяком случае не хранит все в памяти, но вот вопрос каково оно на таких задачах

Человеку на индексы места жалко, а у mongo они намного больше занимают, чем у mysql.

«БД форума с тремя целочисленными индексами заняла [на mongodb] 10,4Гбайт против 4,9Гбайт на MyISAM и против 8,8Гбайт на InnoDB» // Вышел CouchDB 1.0 (комментарий)

Если тупо писать без транзакций и хитрых выборок, то мало что есть быстрее и компактнее, чем MyISAM.

мало что есть быстрее и компактнее, чем MyISAM

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

berkleydb не?

Что скажут кто сталкивался с сим?

Basho, которые делают бд riak, сталкивались. По этой ссылке можно почитать про дизайн ихней key-value базы данных bitcask: http://downloads.basho.com/papers/bitcask-intro.pdf

Сам не пользовался но почитать было интересно.

leveldb смотрел? Еще есть така штука как libeblob (от автора elliptics-а)

sqlite? по базе в день. Дешево и сердито. Индексы есть... view и crott-database есть, значит редкие навороченные выборки можно делать...

http://docs.mongodb.org/manual/tutorial/expire-data/

- сделать некую выборку (READ)

что за выборка?

выборка махровая, зачастую даже простым sql не описывается, причем сейчас мне известно только три вида выброк, а затем их кол-во будет расти.

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

- добавить записи в конец около 5млн в день (APPEND)
- сделать некую выборку (READ)
- снести все что старше полугода

Делали что-то подобное в mysql (myisam). Записи добавлялись обычными insert-ами, а сами таблицы ротейтились скриптом, который по крону делал:

CREATE TABLE mytable_new LIKE mytable;
RENAME TABLE mytable TO mytable_2012_11_01, mytable_new TO mytable;

Есть мысль хранить все в файликах, допустим файлик на день. Файлик сформировался - построили для него b-tree индекс в отдельном файле - транзакции и блокировки ненужны. Прошел год снесли кучку файлов и место вновь свободно.

Вообще-то вариант с myisam+rename так и делает (каждая таблица — отдельный файл). Заодно и индексы построятся.

Но если хранить надо долго, а искать редко, то можно сделать вообще без БД, просто писать напрямую в файлик. К тому же, если файлики текстовые, можно их паковать gz/xz, заодно и место экономить раз в 5-10.