Вопрос дизайна базы данных

Question

Я накопил довольно много данных в необработанном виде (csv и двоичный) - 4 ГБ в день в течение нескольких месяцев, если быть точным.

Я решил присоединиться к цивилизованному миру и использовать базу данных для доступа к данным, и я подумал, что будет правильным макетом; формат довольно прост: несколько строк для каждого тика (bid, ask, timestamp и т. д.) x до 0,5 млн. в день x сотни финансовых инструментов x месяцы данных.

Существует сервер MySQL с MYISAM (который, как я понял, будет правильным механизмом для этого типа использования), работающий на обычном аппаратном обеспечении (2 x 1 ГБ RAID 0 SATA, ядро ​​2 @ 2,7 ГГц)

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

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

SELECT (ask + bid) / 2
  WHERE instrument='GOOG'
  AND date = '01-06-2008'
  ORDER BY timeStamp;

Редактировать: Я пытался собрать все свои данные в одну таблицу, проиндексированную timeStamp, но это было слишком медленно - поэтому я рассчитывал, что потребуется более сложная схема.

Answer 1

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

• Финансовый инструмент; и
• Quote.

Итак, вам нужно определить атрибуты.

Финансовый инструмент:

• Защитный код;
• Market;
• и т.д.

Цитата:

• Отметка;
• Финансовый инструмент;
• Цена предложения; и
• Спросите цену.

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

Концептуально довольно просто.

CREATE TABLE instrument (
  id BIGINT NOT NULL AUTO_INCREMENT,
  code CHAR(4),
  company_name VARCHAR(100),
  PRIMARY KEY (id)
);

CREATE TABLE quote (
  id BIGINT NOT NULL AUTO_INCREMENT,
  intrument_id BIGINT NOT NULL,
  dt DATETIME NOT NULL,
  bid NUMERIC(8,3),
  ask NUMERIC(8,3),
  PRIMARY KEY (id)
)

CREATE INDEX instrument_idx1 ON instrument (code);

CREATE INDEX quote_idx1 ON quote (instrument_id, dt);

SELECT (bid + ask) / 2
FROM instrument i
JOIN quote q ON i.id = q.instrument_id
WHERE i.code = 'GOOG'
AND q.dt >= '01-06-2008' AND q.dt < '02-06-2008'

Если ваш набор данных достаточно большой, вы можете включить (bid + ask) / 2 в таблицу, чтобы вам не приходилось рассчитывать на лету.

Хорошо, это нормализованный вид. После этого вам может потребоваться начать оптимизацию производительности. Рассмотрим вопрос о хранении миллиардов строк в MySQL . Разбиение - это особенность MySQL 5.1+ (довольно новая).

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

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

Answer 2

При хранении данных на уровне тиков многие финансовые базы данных разбивают данные по крайней мере по инструментам, поскольку редко требуется выполнить запрос по инструментам. Таким образом, таблица на инструмент нормальная. Некоторые идут дальше и разбивают также по дате, давая таблицу по комбинации инструмента / даты. Это может усложнить запрос, если запросы по датам являются нормой.

Итак, два варианта:

1. Тиковая таблица для каждого инструмента с кластеризованным индексом на временной метке
2. Таблица тиков для каждого инструмента / даты, с кластеризованным индексом на отметке времени

Это базовый компромисс между скоростью доступа и простотой запросов.

Answer 3

Что вам нужно сделать, это прочитать нормализация базы данных . Если вы находите эту статью слишком много, вам просто нужно просмотреть учебник 3-я обычная форма .

Answer 4

Dani, Я работал с Tick by Tick data в течение многих лет и был бы рад сотрудничать в этом. Напишите мне IanTebbutt в Hotmail. (Кстати, я проверил, и в StackOverflow нет возможности сделать личную электронную почту, и Джефф, похоже, не согласен отклонено, .)

Вкратце я обнаружил, что разбиение по датам и инструментам работает довольно хорошо. Вы можете поместить месячные данные для инструмента X в набор таблиц, используя такой шаблон, как InstrumentX_YYDD. Затем при доступе к данным вам нужен, по крайней мере, генератор имен таблиц, но, скорее всего, генератор SQL, который может решить, какую таблицу использовать, или использовать Union для просмотра нескольких таблиц.

Как бы вы ни смотрели на эти объемы данных, с ними нелегко иметь дело. Это граничит с территорией DataWarehouse, и существует огромное количество способов снятия шкур с этой кошки. Как я уже сказал, рад сотрудничеству - у меня, вероятно, уже исправлена ​​половина ваших проблем.

Answer 5

Или, возможно, рассмотрим звездную схему, размеры и факты. У Ральфа Кимбалла есть несколько хороших вещей , чтобы рассказать вам, как это сделать.

Answer 6

Просто некоторые общие замечания:

• Не используйте столбец TIMESTAMP, так как он автоматически устанавливается на основе времени INSERT. Поскольку вы импортируете данные, это не то, что вам нужно.
• Если вы используете тип столбца MySQL DATETIME, вы можете использовать для него функции MySQL Дата и время .
• MyISAM не поддерживает ограничения FOREIGN KEY и молча игнорирует их.
• Указатели, указатели, указатели. Убедитесь, что они есть в столбцах, которые вы будете использовать для поиска. Однако, если у вас есть столбцы с большим количеством текста, вы можете вместо этого использовать FULLTEXT поиск .
• Если вы планируете превратить это в действующую базу данных с INSERT с, а также SELECT запросами, учитывая использование InnoDB с транзакциями и блокировкой на уровне строк (SELECT ... FOR UPDATE)