[Решено]Математическая обработка больших файлов со значениями. (Какое средство выбрать для данной задачи?)

[ffldove]

Некая программа на выходе дает несколько текстовых файлов и известной не стандартной структурой (таблицей но не совсем упорядоченной). Требуется математически (сложная математика включающая различные действия) обработать файлы (от одного до десяти одновременно), На выходе получается некая таблица результата анализа все N файлов. Проблема в том что файл может достигать размера нескольких гигабайт. Как лучше решить данную проблему? Вижу несколько вариантов:
1) Написать программу на компилируемом языке которая будет сама без посредников работать с файлами.
Плюсы:
- Нет дополнительных прослоек между ПО и файлами.
Минусы:
- Возникнут проблемы в быстродействие при работе с такими большими файлами.
2) Использовать СУБД для всех вычислений.
Плюсы:
- Не будет проблем с большими файлами.
Минусы:
- Проблемы решения сложных математических задач (видимо придется использовать дополнительно скриптовый язык для решения таковых).
- Придется перегонять файлы в базу.
3) Использовать СУБД только для хранения + программа для вычисления.
Плюсы:
- Не будет проблем с большими файлами.
- Нет проблем с математикой.
Минусы:
- Сложнее реализовать.
- Придется перегонять файлы в базу.

Придерживаюсь 3-его варианта. Что лучше выбрать, или можно еще куда то посмотреть?

[apprentice]

- Возникнут проблемы в быстродействие при работе с такими большими файлами.

Это вы с чего взяли?

Если писать на нормальном языке (С/С++) то это будет самый быстрый вариант, т.к. у вас будет полный контроль за всеми этапами работы. Все остальные варианты проиграют во много раз (возможно в десятки, сотни и даже тысячи раз по быстродействию)

Но естественно трудоемкость разработки системы будет выше чем в других вариантах.

[ffldove]

- Возникнут проблемы в быстродействие при работе с такими большими файлами.

Это вы с чего взяли?

Если писать на нормальном языке (С/С++) то это будет самый быстрый вариант, т.к. у вас будет полный контроль за всеми этапами работы. Все остальные варианты проиграют во много раз (возможно в десятки, сотни и даже тысячи раз по быстродействию)

Но естественно трудоемкость разработки системы будет выше чем в других вариантах.

Одновременно в одном вычисление может потребоваться до 10 значений из разных файлов по несколько Гб, следовательно придется очень грамотно все это организовывать в плане одновременной работы с файлами. А стоит ли это того? Будет ли большая разница против СУБД?

ПС
Какая разница в скорости будет к примеру при чтение из текстового файла N строки M столбца ( при этом учитывая не обычное форматирование текста, столбцы разделены абы как, чаще кучей пробелов) + преобразование строки к виду пригодному для математических вычислений, против вытаскивания N строки M столбца из СУБД?

[eddy]

По-моему, все-таки, быстрее получится сначала прогнать все таблицы и сделать своеобразный кэш-файл (пометить смещения для строк с определенным шагом, например, для каждой 200-й строки), а затем работать с файлами напрямую.
Если же вы будете использовать, к примеру, SQLite, вам сначала придется прочитать файлы строка за строкой, выделив нужную информацию, и поместить все их содержимое в БД. Этот вариант выгоднее лишь в случае, когда вам необходимо производить много вычислений с одними и теми же файлами.

[Crazy]

ПС
Какая разница в скорости будет к примеру при чтение из текстового файла N строки M столбца ( при этом учитывая не обычное форматирование текста, столбцы разделены абы как, чаще кучей пробелов) + преобразование строки к виду пригодному для математических вычислений, против вытаскивания N строки M столбца из СУБД?

Что бы что-то вытащить из СУБД, нужно что-то туда положить. Все равно придется парсить файлы, что бы загнать их в СУБД.

[ffldove]

eddy
Ах да вариант: Пропарсить изначально файл для более удобной затем с ним работы это тоже (можно сказать) 4-ый вариант.

ПС
Какая разница в скорости будет к примеру при чтение из текстового файла N строки M столбца ( при этом учитывая не обычное форматирование текста, столбцы разделены абы как, чаще кучей пробелов) + преобразование строки к виду пригодному для математических вычислений, против вытаскивания N строки M столбца из СУБД?

Что бы что-то вытащить из СУБД, нужно что-то туда положить. Все равно придется парсить файлы, что бы загнать их в СУБД.

Это понятно, но боюсь результат затрат на вытаскивания значения каждый раз все равно превзойдут однократные затраты на парсинг, плюс потом будет удобнее работать.
Во общем парсить думаю буду все равно, осталось решить парсить и в БД или парсить и работать напрямую.

[apprentice]

Одновременно в одном вычисление может потребоваться до 10 значений из разных файлов по несколько Гб,

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


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

[watashiwa_daredeska]

Какая разница в скорости будет к примеру при чтение из текстового файла N строки M столбца ( при этом учитывая не обычное форматирование текста, столбцы разделены абы как, чаще кучей пробелов) + преобразование строки к виду пригодному для математических вычислений, против вытаскивания N строки M столбца из СУБД?

А почему бы перед обработкой не распарсить эти файлы и не перегнать их в бинарные, хорошо пригодные для random search? СУБД -- дополнительные накладные расходы. А если можно писать 64-bit only, то вообще прекрасно -- бинарные файлы можно за-mmap'ить (несколько ГБ легко влезут в адресное пространство 64-bit). Система возьмет на себя кэширование, что тоже неплохо, а т.к. бинарные файлы могут быть меньше текстовых за счет отсутствия излишней разметки, то это ещё лучше -- в кэш влезет больше.

А ещё я бы рекомендовал покрепче подумать над алгоритмами, чтобы сделать расчеты более приближенными к поточным. Или "почти поточным" -- учесть наличие кэша ограниченного объема (т.е. в большинстве случаев обращаться к данным в current_point-C1..current_point+C2, где C1, C2 -- константы (чем они меньше, тем лучше -- меньше требуется кэша). Это сократит число обращений к диску и повысит скорость на порядки. Пусть лучше будет последовательность поточных алгоритмов с не очень хорошей расчетной скоростью, чем алгоритм, который рандомно дергает диск.

[Crazy]

А почему бы перед обработкой не распарсить эти файлы и не перегнать их в бинарные, хорошо пригодные для random search?

Всякие B/R-деревья?

[watashiwa_daredeska]

Всякие B/R-деревья.

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

[Portnov]

Сильно зависит от задачи. Если вычисления относительно несложные, но требуют данных сразу из многих файлов, и основная проблема не в вычислениях, а в работе с большим количеством данных, то загнать всё в PostgreSQL и вычисления писать на PL/Python или другом встроенном в постгрес языке. Если вычисления более сложные, и каждая итерация требует только небольшого количества данных, то писать на любимом компилируемом языке, только сделать чтение данных ленивым: не загружать сразу все файлы в память, а только необходимое в данный момент, уже обработанные данные из памяти убирать.

[ffldove]

Буду пробовать 2 варианта, с начало СУБД + вероятно Python, затем если что то не устроит на компилируемом языке + парсинг всех файлов в бинарный файл.
Первый вариант все таки выглядит предпочтительнее тем что есть возможность быстро сменить математическую формулу и прочее в алгоритме + реализация проще.

ПС
Видимо от варианта СУБД + компилируемая программа особого удобства и быстродействия не будет (по сравнению с вариантом СУБД + скрипт).

[watashiwa_daredeska]

Видимо от варианта СУБД + компилируемая программа особого удобства и быстродействия не будет (по сравнению с вариантом СУБД + скрипт).

Естественно. Весь CPU сожрёт парсинг SQL и припрыжки с индексами и прочей требухой, которая тут, в общем-то, не нужна.