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

Question

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

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

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

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

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

Answer 1

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

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

«Как лучше всего хранить данные и манипулировать ими? »

Схема звезды.

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

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

Нет ничего быстрее, чем плоский файл. Период. СУРБД медленнее.

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

"подводные камни / ошибки, о которых я должен знать?"

БД дизайн. Если вы не получите схему «звезда» и то, как отделить факты от измерений, все подходы обречены. Как только вы отделяете факты от измерений, все подходы примерно равны.

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

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

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

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

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

Не совсем.

Answer 2

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

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

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

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

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

2) Предварительный кеш.

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

Answer 3

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

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

Answer 4

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

edit: если код помещается в память, то простой CSV подойдет. С форматами данных в виде простого текста всегда легче работать, чем с непрозрачными, если вы можете их использовать.