Сохраните ряд данных в файле или базе данных, если я хочу выполнять математические операции на уровне строки?

Question

Я разрабатываю приложение, которое обрабатывает наборы данных финансовой серии (входные данные как csv или открытый документ), один набор может быть указан в десятизначных числах от 1000 до двух чисел (упрощение, но это важно).

Я планирую делать операции над этими данными (например, сумма, разница, средние и т. Д.), А также генерировать, скажем, другой столбец на основе вычислений на входе. Это будет между столбцами (операции на уровне строк) на одном наборе, а также между столбцами для многих (потенциально всех) наборов на уровне строк. Я планирую написать его на Python, и в конечном итоге ему понадобится интерфейс, ориентированный на интрасеть, для отображения результатов/графиков и т. Д., Теперь будет достаточно выхода csv на основе некоторых входных параметров.

Каков наилучший способ хранения данных и их обработки? До сих пор я вижу, что мой выбор состоит в том, чтобы либо (1) писать csv-файлы на диск, либо тратить их на выполнение математики, либо (2) я мог бы поместить их в базу данных и полагаться на базу данных для обработки математики. Моей главной задачей является скорость/производительность, так как число наборов данных растет, так как будет выполняться математическая математика на уровне ряда данных.

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

-Edit- Подробнее: Ряды будут все читали все в порядке, но я, возможно, придется сделать некоторые передискретизации/интерполяции, чтобы соответствовать различным ввода длины, а также различной метки времени для каждой строки. Поскольку каждый набор данных всегда будет иметь разную длину, которая не является фиксированной, у меня будет некоторая таблица царапин/память где-нибудь, чтобы провести интерполированные/повторно сэмплированные версии. Я не уверен, имеет ли смысл пытаться сохранить это (и попытаться увеличить/объединить до общей более высокой длины) или просто восстановить его каждый раз, когда это необходимо.

Answer 1

«Я планирую делать операции над этими данными (например, сумма, разница, средние и т. Д.), А также генерировать, скажем, другой столбец на основе вычислений на входе».

Это стандартный вариант использования схемы звездной схемы хранилища данных. Купите набор инструментов для хранения данных Kimball. Прочитайте (и поймите) схему звезды, прежде чем делать что-либо еще.

«Каков наилучший способ хранения данных и их обработки? "

Звезда Schema.

Вы можете реализовать это в виде плоские файлы (CSV штрафа) или СУБД. Если вы используете плоские файлы, писать простую петлю, чтобы сделать математику. Если вы используете СУБД вам написать простой SQL и простые петли.

«Моя главная забота скорость/производительность, поскольку число наборов данных растет»

Ничто так быстро, как плоский файл. Период. RDBMS медленнее.

Предложение по РСУБД связано с тем, что SQL является относительно простым способом указать SELECT SUM(), COUNT() FROM fact JOIN dimension WHERE filter GROUP BY dimension attribute. Python не такой уж короткий, как SQL, но он такой же быстрый и гибкий. Python конкурирует с SQL.

«Ловушки/ошибки, о которых я должен знать?»

DB design. Если вы не получите звездную схему и как отделить факты от измерений, все подходы обречены. Когда вы отделяете факты от измерений, все подходы примерно равны.

«В чем причины, по которым нужно выбирать над другим?»

RDBMS медленный и гибкий. Плоские файлы быстро и (иногда) менее гибкие. Python выравнивает игровое поле.

«Есть ли какие-либо потенциальные проблемы с пропускной способностью/производительностью, которые мне нужно знать, прежде чем я начну, что может повлиять на дизайн?»

Звездная схема: центральная таблица фактов, окруженная таблицами размеров. Ничто не сравнится с ним.

«Есть ли какой-либо проект или каркас, чтобы помочь в решении такого рода задач?»

Не совсем.

Answer 2

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

Редактировать: Если код подходит в памяти, тогда простая CSV в порядке. Простые текстовые форматы данных всегда легче иметь дело с непрозрачными, если вы можете их использовать.

Answer 3

Главное, если все данные будут помещаться одновременно в память. Из того размера, который вы даете, кажется, что это легко сделать (в худшем случае - несколько мегабайт).

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

Answer 4

Для оптимизации скорости, я хотел бы предложить два других направления исследований за изменения вашего базового механизма хранения:

1) Используйте промежуточную структуру данных.

Если максимальная скорость важнее минимизации использования памяти, вы можете получить хорошие результаты из-за использования другой структуры данных в качестве основы ваших вычислений, а не сосредоточиться на базовом механизме хранения. Это стратегия, которая на практике сократила время выполнения в проектах, над которыми я работал, резко, независимо от того, хранятся ли данные в базе данных или в тексте (в моем случае XML).

Хотя суммам и средним значениям требуется время выполнения только O(n), более сложные вычисления могут легко подтолкнуть их к O (n^2) без применения этой стратегии. O (n^2) будет хитом производительности, который, скорее всего, будет иметь гораздо большее влияние на скорость, чем чтение из CSV или базы данных. В качестве примера можно привести, если ваши строки данных ссылаются на другие строки данных, и необходимо собрать данные на основе этих ссылок.

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

2) Pre-cache.

В зависимости от того, как данные должны использоваться, вы можете сохранить рассчитанные значения загодя. Как только данные будут созданы/загружены, выполните свои суммы, средние и т. Д. И сохраните эти скопления вместе с вашими исходными данными или удерживайте их в памяти до тех пор, пока ваша программа работает. Если эта стратегия применима к вашему проекту (т. Е. Если пользователи не приходят с непредвиденными запросами расчета «на лету»), чтение данных не должно быть чрезмерно длительным, независимо от того, поступают ли данные из текста или базы данных.