Что такое хороший дизайн реляционной базы данных для данных фондового рынка?

Question

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

if (QUOTE) {
...
}
if (TRADE) {
...
}

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

Answer 1

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

С одной стороны, вы можете просто отвечать на кавычки клиентов, которые вы извлекаете из API, и в основном реализовывать кеш. В этом случае две таблицы в порядке.

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

Answer 2

Kdb + / q

Очень хороший вариант для данных тиков.Используется крупными банками.

здесь - информация об этом.

Вы можете установить версию трейла и поиграть с ней.

Answer 3

Короткий ответ: «Не совсем». Для фондового рынка и других данных временных рядов хранилище ключевых значений, таких как Berkley DB или Mongo, довольно хорошо.Кроме того, формат данных, такой как NetCDF (http://en.wikipedia.org/wiki/NetCDF), скорее всего, в долгосрочной перспективе будет вам полезнее. Это также зависит от того, какой тип доступа вы хотите и сколько времени вы хотите сохранить.

Вы этого не сделалиукажите, что вы делали с данными, что должно больше всего отражать ваш выбор хранилища. Например, приложение для высокоскоростной торговли будет иметь компромисс между хранилищами, отличным от исторической системы пакетной обработки (где Hadoop + NetCDF был бы хорош).YMMV