Возникла необходимость работать с файлами больших размеров (~20Gb)

Файл представляет собой таблицу небольших записей, каждая новая запись должна быть внесена в строго определенное место. Проблема в том, что записи поступают в таком порядке, что их размещение в файле очень близко к равмномерному распределению. NTFS в такой ситуации работает дико неэффективно - 5000 записей пишутся от 6 до 14 секунд.

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

Наиболее эффективное решение проблемы - изменить саму архитектуру.
1) Зачем вам писать записи в определенное место - может быть лучше снабдить их номерами.
Боюсь поиск будет неэффективен уже при 2 миллиардах записей. К тому же это дополнительный расход дискового пространства - последнего катастрофически нехватает :(

Отсюда сразу следует, что применять надо базу данных, так как там все ваши проблемы решили за вас, причем гарантированно лучше, чем вы когда-нибудь напишете
Пробовал MSSQL Express. Пишет действительно довольно быстро (bulk insert). Поиск тоже работал довольно шустро (Хотя не факт, что это сохранится на больших объемах данных). Однако, на 5 млн записей база разрослась до 250 метров, при максимально допустимом для них объёме в 100 мегабайт.
Так что задачу там конечно решили хорошо, но в данном случае качество неприемлемо.

Ну если религиозные соображения не позволяют использовать БД, то делаем буффер, сливаем в него новые записи просто по порядку - а фоновый процесс будет их распихивать в большом файле
Примерно такой была самая ранняя реализация. Это, к сожалению, ни коим образом не решает упомянутую проблему.
Религиозные соображения - цель оправдывает средства :)

mayton
всё верно. Не знаю Oracle Berkeley, но справится ли он там, где не хватило MSSQL Express?

Это очень странное заявление. Насколько я знаю, Express ограничен по вычислительной мощности в 1 камень и еще есть какие-то квоты на размер дата-файлов. Пусть спецы меня поправят если ошибся. Но в целом-то СУБД очень хорошая. Есть и partitions. Вы говорите что "не хватило". Не хватило на чём? На inserts? Или на выборках? Что тормозило? В любом случае, я-бы сначала выжал все возможности по перформансу из СУБД а потом уже доделывал велосипед.
Уж Standard Edition то под это могут купить. См выше - проблема не в перформансе, а в эффективности использования дискового простанства. Если использовать MS только для индекса, велосипеды остаются на месте. Если использовать его для всех данных, увеличение в 2.5 раза скушает на диске лишние ~6Тб.

Дело в том, что в моей системе кит другой - индексирование идет так, что требуемый объем уменьшается

Lelikk
Сейчас как раз прорабатываю второй вариант. Здесь дело идет на террабайты, а они, увы, дороже.

miksoft
Всё верно, это и понималось под "процессом" в первом посте. Пока наиболее адекватное предложение, которое я услышал - сортировать блоки входных данные по их разположению и отправлять на запись по порядку (в идеале - блоками соседних записей)

Потери данных недопустимы, что ж касается скорости/объйма - это направления, чем быстрее/компактнее - тем лучше