nuke4303, тут узкий момент есть, в смысле что использовать базу это больше нагрузить систему, с файлами будет шустрее(это личное ИМХО). я бы все же просто дополнял блоки до максимального размера и писал их в бинарный файл, читать файл можно асинхронно, в отдельном потоке, зарание читая очередной блок информации и ставя его в очередь на обработку, а с другой стороны сохранять данные когда они достигнут какой нить критической массы(пару сотен метров, к примеру). в итоге получим что и память не будет забиваться полностью и в производительности не сильно потеряешь(это конечно с учетом что в системе не одно ядро). работа с базой будет проходить по такому же принципу, но база тяжелее файла(у нее должен работать свой сервер, запросы обрабатывать и пр....). если делать базу то проще писать, если делать с файлами то скорее всего будет шустрее работать(с учетом твоей личной грамотности как разработчика, конечно)

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

т.е. сначала размер блока, потом(вместо []) сам блок данных, потом следующая пара. минус всего этого это сложность реализации.

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

а по поводу хранения информации о блоке?

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

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

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