Привет всем.
Решаю такую задачу- есть файл с бинарными данными регулярной повторяющейся структурой: Например, struct { int f1; float f2; int f3; }
Мне нужно обеспечить такие операции над этими данными:
- постраничная выборка подмножеств структур, отсортированных по некоторому полю, например f1 (аналог ORDER BY и LIMIT)
- поиск и сортировка.

Для этих целей у меня возникло два варианта решения:
1) написать Reader для структур и перегнать их в БД и затем использовать
этот вариант оказался очень медленным для очень больших файлов (1...5Гб). Пробовал на MySQL, Postgres.
Поэтому возникла мысль о втором варианте:
2) написать свой аналог специализированной БД, заточенной только под конкретные задачи. Тем более задачи подразумевают лишь чтение данных, а не их изменение.
Мне нужно прежде всего быстродействие, поэтому начав исследовать этот вариант, я подумал, что нужно проиндексировать все поля структуры, тоесть построить для каждого поля f(i) упорядоченный индекс. Таким образом можно решить задачу постраничной выборки с сортировкой.
Для построения индексов я выбрал алгоритм двухфазной сортировки слиянием. Что у меня получилось: первая фаза (когда строятся первые отсортированные списки (размером 16Кб) выполняется довольно быстро: 300 секунд на проце Core2Duo 2Gb оперативки. Пока вторую фазу (слияние подсписков) я еще реализую и там возникает множество сомнений. Но посему вопрос - в правильном ли я направлении двигаюсь? Может есть более эффективный алгоритм?
Что можно посоветовать в подобных случаях?

спасибо за внимание.

да, забыл уточнить, я пользуюсь алгоритмом сортировки двухфазным многокомпонентным слиянием для сверхбольших отношений, описанный в книге "Системы баз данных", Г.Гарсиа-Молина, Дж. Ульман и др.

Ennor TiegaelС MySQL, говорите, пробовали? И что же, (если я ничего не путаю) не помог? Прям вот в разы медленнее, чем у вашего алгоритма индексирования?
нет, так не пробовал. Действовал в лоб - парсил файл и загонял по кортежу.

Ennor Tiegael
За эту команду, кстати спасибо! Попробую поэкспериментировать.

Реалист
Может быть, что перед заливкой такого большего объема данных просто забыл отключить индексы.
Тогда ничего удивительного нет в наличии тормозов ;-)
Дело в том, что индексы полюбому потом всё равно будут нужны, так как эти данные будут потом активно анализироваться, сортироваться по разным полям, осуществляться поиск по любому из полей или объединяться с другими подобными данными. И как раз одно из требований - обеспечить максимальную производительность анализа.
Поэтому да, я индексирование не отключал при загрузке данных в БД.

Реалист
Лучше бы это время потратил на поиск узкого места и оптимизацию БД.

Для заливки данных я использую простую таблицу для каждого файла с индексацией всех полей. Таблицы не имеют внешних ключей и являются сами по себе. Как можно в данном случае оптимизировать процесс заливки большого количества данных? 5 Гигов - это всего лишь отдельно взятый файл, коих может быть несколько десятков.
Ждать, пока все эти данные перегонятся в БД только затем, чтобы потом их анализировать в режиме только для чтения - это занимает слишком много времени. Поэтому встал вопрос - написать простенький аналог СУБД для этой конкретной задачи. Тем более структура файлов тривиальная. Нужно лишь решить задачу индексации полей.

Что я сейчас начал делать:

1) пусть есть у нас большой файл с однородной повторяющейся структурой {f1, f2, f3,...,fn} .
2) решено расщепить этот файл на несколько файлов, соответственно каждый файл с именем f(i).dat будет содержать пару:
{f(i), position}
где f(i) - это поле из исходного файла, а position - указатель на структуру в исходном файле, содержащую это поле.
Соответственно в файле f(i).dat все поля f(i) отсортированы в возрастающем порядке.

Это позволит выполнять постраничные запросы с сортировкой по любому из полей (аналог LIMIT + ORDER BY)
Тоесть задача алгоритмически и концептуально уже решена. Остался вопрос с оптимизацией узкого места в этой задаче- сортировка файла f(i).dat

Реалист
Загрузка данных в БД и работа БД - разные задачи, которые можно разнести по времени.

К сожалению, разнести во времени это нельзя. Так как анализ данных необходимо вести оперативно, по мере поступления исходных файлов большого объема. Это одно из требований ТЗ.

Реалист,

ну лучше может не напишу конечно же. но попытаться стоит :)
а вот где узкое место в БД - так я уже сказал - это заливка данных. Ладно, попробую с отключенными индексами попробовать.

MasterZiv, спасибо, уже понял.

Senya_Lunicornmirage,

Возможно, Вам интересно будет почитать описание сортировки в реальных СУБД. Тынц .

Очень интересно, спасибо, уже читаю!
Несмотря на то, что всегда остается вариант использовать существующие СУБД, решено попробовать пойти по пути создания специализированной СУБД. (Время на это имеется, так что экономические факторы этого пути не рассматриваю :) )