NetCDF?

Сейчас гляну. А BerklyDB?

Для скорости еще лучше, наверное. Плюсы NetCDF - это скорее переносимость, самоописательность и matlab.

не слушай его

Только xml+xquery.

SQLite?

Возникло ощущение что Беркли DB переодически затыкается на некоторое время. Это не подходит. Еще раз, фишка в том,чо данных много. Несколько терабайт запросто может быть. И их нужно писать с нормальной скоростью. Реал-тайм в общем. И читать тоже. Данные последовательно расположены. Достаточно функций put next и get next. Теги, и связанные с ними бинарные деревья итд, не нужны.

Его даже из Amarok выкинули, хотя казалось бы, чему там тормозить?

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

Вообще, описанная задача весьма нетривиальна. Может быть попробовать для этого приспособить рсубд? тот же грамотно настроенный mysql запросто может жонглировать терабайтными базами и не захлебываться от большого потока insert'ов, к тому же позволяя делать вкусняшки типа контроля за целостностью, откаты, блокировки и т.п.

>>SQLite?

Где в посте требуется реляционность, чудень?

непонятны требования, добавление есть, а про выборку ничего не сказано. и что значит «становиться посредине и несколько минут парсить базу, а потом продолжить писать, нельзя»??

Выборка тоже последовательная. Добавление, только в конец. Удаления нет. Что такое реляционность, не знаю.

Контроль за целостностью, хотелось бы, откаты, блокировки итд, не нужны. Похоже база данных тут не нужна.

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

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

и хранить саму базу не одним файлом а бить каждые N записей. так надежней.

Хочется какого-то единого стандарта. Чтобы можно было сторонним софтом, побить на куски итд.

>Скорость записей будет порядка 10 мегабайт в секунду.

Только xml

facepalm.svgz [25 Mb]

ну раз хочется единого, юзай что нить SQL-подобное, самое простое SQLite, только это будет много лишнего функционала

Допустим, что средний размер 15килобайт. Тогда в секунду будет порядка 700 записей. Т.е 1-2 милисекунда на запись. А с учитывая размер записей и что надо писать на диск, ты не добьешься такой производительности. Интереса ради можешь посмотреть тесты redis, но он инмемори дает чтото типа такого.

Поэтому сразу смотри на базы с шардированием. Например. Mongodb шардированный.

//ar

тогда зачем тебе база? просто последовательно пиши в один большой файл и всё

root, hdf или просто в файлы.

тогда зачем тебе база? просто последовательно пиши в один большой файл и всё

В два, индекс лучше в общую кашу не ложить.

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

буфферизация решает

mongoDB, возможно, подойдёт.

так судя по всему ему индекс и не нужен

>NetCDF?

тогда и HDF до кучи.

так судя по всему ему индекс и не нужен

с функциями поиска, позиционирования по номеру записи итд?

grammanazi? ORLY?! «не ложить» - смертью караемое отклонение от линии партии

мля. в рекапче слово на идише... ппц... http://img714.imageshack.us/img714/3968/ffuuuv.png

ORLY?! «не ложить» - смертью караемое отклонение от линии партии

Ну и расскажи, как ты будешь искать пакет номер один миллион сто тыщ два, если индекс размазан по файлу с данными?

HDF5