Ответ зависит от требований к данным и особенностей записи, многопользовательская или нет (транзакции на запись - сильно выставляет требования к ресурсам), есть ли модификация данных (очень важный момент роняющий производительность в зависимости, правда если данные фиксированного размера то возможно не сильно), виды запросов на поиск и аналитику, (кому то нужны поиск по значению, а кому то сравнения больше/меньше, поиск min/max и сортировки, кому то нужны группировки по значению в индексе и многое другое), наличие упорядоченных данных (когда данные записываются последовательно и в запросах часто фигурирует выгрузка данных на интервале).
Отличный пример - числовое ключевое поле с монотонным ростом без пропусков позволяет использовать самый простой индексный файл где значение ключевого поля это смещение слова (например 4 байта) в индексном файле, а эти слова - это смещение в файле данных (например номер кластера фс, данные выровнены по нему). Файл данных это тупая последовательность размер+данные без разделителя.
Достоинства - максимальная из возможных производительность (файл данных и индексный файл могут храниться без файловой системы прямо в блочных устройствах), буквально 2 запроса на запись/поиск (при использовании файловых систем операций будет в несколько раз больше), ни одна универсальная база данных не даст такой. Кода - строк 20-30 на любом языке программирования, красиво можно пользоваться memory mapped files (они дают самую быструю работу с файлами и удобную под задачу). Данные пишутся линейно на диск (оптимально для hdd, само собой если не одновременно с чтением), большинство файловых и операционных систем поддерживают sparce файлы (будут накладные расходы, но константа), это значит можно с некоторыми оговорками пользоваться большими пропусками в порядке индексов (дырка в файле вернет нули, на диске храниться не будет).
Недостатки/особенности - требуется некий роутер, для управления несколькими файлами, если размер данных может выходить за пределы имеющихся устройств (в реляционных базах данных для этого есть прозрачный механизм tablespace), но на практике красивых монотонных индексов не существует и приходится выкручиваться, например группировать данные
Пример - временной ряд, в секунду происходят тысячи событий, хранить группами по секунде, т.е. ключевое поле для индекса - это timestamp-стартовое время файла, при среднем размере информации о событии в 100байт и 4 тысячи событий в секунду, на 3терабайтовый диск hdd индексы будут порядка 30 мегабайт, что прекрасно влезает в оперативную память. У меня самый дешевый toshiba3тб выдавал 60 req/sec случайных запросов (как в синтетических бенчмарках), при этом запрашивать можно было сразу большими интервалами, что роняло скорость максимум в 2-3 раза, пока данные влезали на дорожку (в зависимости от расположения там по разному). Последовательное чтение данных само собой работало на максимуме скорости диска в 150-200мб/с.
p.s. от такой модели отказался за ненадобностью, данные хорошо упаковывались большими блоками (в 10 раз), храню теперь просто в архивах большими блоками по несколько часов, на время работы нужные данные переливаются во временные файлы.
Помню тут на хабре была статья где человек залил в mssql миллионы записей, и радовался секундам на запрос (правда там хеши но это не так важно, для них тоже есть решения)
