Схема базы данных для организации исторических данных о запасах - PullRequest
Новая
       14

Схема базы данных для организации исторических данных о запасах

30 голосов
/ 06 октября 2009

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

Мои требования - хранить «данные бара» (дата, открытие, максимум, минимум, объем закрытия) для нескольких биржевых символов. Каждый символ может также иметь несколько таймфреймов (например, бары Google Weekly и бары Google Daily).

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

CREATE TABLE Exchange (exchange TEXT UNIQUE NOT NULL);

CREATE TABLE Symbol (symbol TEXT UNIQUE NOT NULL, exchangeID INTEGER NOT NULL);

CREATE TABLE Timeframe (timeframe TEXT NOT NULL, symbolID INTEGER NOT NULL);

CREATE TABLE OHLCV (date TEXT NOT NULL CHECK (date LIKE '____-__-__ __:__:__'),
    open REAL NOT NULL,
    high REAL NOT NULL,
    low REAL NOT NULL,
    close REAL NOT NULL,
    volume INTEGER NOT NULL,
    timeframeID INTEGER NOT NULL);

Это означает, что мои запросы в настоящее время идут примерно так: найдите timeframeID для данного символа / таймфрейма, затем сделайте выборку в таблице OHLCV, где timeframeID совпадает.

Ответы [ 3 ]

33 голосов
/ 14 января 2010

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

Мы смогли хранить сотни гигабайт внутридневных и ежедневных данных, используя эту схему в SQL Server: 

 Symbol -  char 6
 Date -  date
 Time -  time
 Open -  decimal 18, 4
 High -  decimal 18, 4
 Low -  decimal 18, 4
 Close -  decimal 18, 4
 Volume -  int

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

Для ежедневных данных у нас есть отдельная таблица, и мы не используем столбец Time. Тип данных тома также bigint вместо int.

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

Мы приобрели все наши исторические рыночные данные с веб-сайта Kibot: http://www.kibot.com/

26 голосов
/ 06 октября 2009

Что ж, с положительной стороны, у вас есть здравый смысл сначала спросить о вводе. Это позволяет вам опережать 90% людей, незнакомых с дизайном баз данных.

  • Нет четких взаимосвязей внешних ключей. Я так понимаю timeframeID относится к symbolID?
  • Неясно, как вы сможете найти что-нибудь таким образом. Чтение вышеупомянутых внешних ключей должно значительно улучшить ваше понимание без особых усилий.
  • Вы храните данные таймфрейма как TEXT. С точки зрения производительности, а также с точки зрения удобства использования, это нет-нет.
  • Ваша текущая схема не может приспособиться к разделению акций, что в конечном итоге произойдет. Лучше добавить еще один слой косвенности между таблицей данных о ценах и символом
  • open, high, low, close цены лучше хранить в виде десятичного числа или типа валюты или, предпочтительно, в виде поля INTEGER с отдельным полем INTEGER, в котором хранится делитель, как наименьшая допустимая доля цены (центы, восемь долларов и т. д.) варьируется в зависимости от обмена
  • Поскольку вы поддерживаете несколько бирж, вы должны поддерживать несколько валют.

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

4 голосов
/ 06 октября 2009

Я не уверен, какое значение добавляет Timeframe - это кажется ненужным осложнением, но это может быть то, чего я не понимаю ;-) Может ли таймфрейм иметь более одного OHLCV? Если нет, то я бы предложил объединить их.

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

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

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

...