Когда сохранять данные временных рядов

Question

Мы собираем рыночные данные о 30 000 финансовых инструментов. Мы хотим хранить исторические данные каждые 10 минут или около того. Все это сохраняется в таблице PostgreSQL. Я спорю между двумя подходами:

"Snapshot"

Храните цену всех символов каждые 10 минут, с хорошей круглой отметкой времени.

Преимущества:

• Упрощает выполнение запросов, поскольку временная метка известна a-priori , просто округляя до последнего кратного 10-минутного числа.

Недостатки:

• Большой набор данных
• Большие вставки влияют на производительность
• Не будет сообщать, как часто данные прибора меняются без сохранения дополнительной информации

"Rolling Updates"

Хранить каждый символ только при его обновлении, если время, прошедшее с момента последнего обновления, превышает 10 минут.

Преимущества:

• Меньше и меньше (дешевле) вставок
• Меньший набор данных
• Данные будут более точно отражать фактическую частоту изменений (для приборов, которые меняются менее одного раза в 10 минут)

Недостатки:

• Запросы будут более сложными / дорогостоящими, поскольку временная метка нужной строки неизвестна.

Вопросы

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

Я выполнял "Rolling Updates" и не вижу проблем с производительностью запросов. В таблице имеется только один многостолбцовый индекс, но вставки все же кажутся намного более дорогими, чем запросы, поэтому этот метод кажется более подходящим. Это разумный подход? Есть ли другие соображения, по которым я скучаю?

Answer 1

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

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

Третий подход, который объединяет их оба, работает лучше всего: вы сохраняете временную запись «непрерывного обновления» для всех инструментов в памяти в вашем анализаторе, и на 10-минутной отметке вы записываете последнее значение впостоянная таблица и перезагрузка временных записей.Этот подход также позволяет легко отслеживать значения Open, High, Low, Close и Volume.

Answer 2

Я заново внедряю наш канал и переключаюсь с непрерывных обновлений на снимки.Это было легче кодировать;Мне не нужно отслеживать, когда что хранить.Данные загружаются в тщательно проиндексированную таблицу PostgreSQL с использованием бинарного копирования, поэтому производительность вставки не является проблемой;мы наблюдаем скорость не менее нескольких тысяч записей в секунду, что достаточно.

Я не использую специально круглые метки времени, но это облегчит извлечение всегоснимок, если мы хотим сделать это.На данный момент мы извлекаем данные только по одному символу за раз в один момент времени.

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

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