Каков наилучший способ структурировать базу данных для фондовой биржи? - PullRequest
Новая
       9

Каков наилучший способ структурировать базу данных для фондовой биржи?

0 голосов
/ 17 июня 2019

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

Мой вопрос таков: у Nasdaq более 3000 компаний и в их базе данных акций, верно ?!но является ли это одной строкой ввода для каждой акции каждого символа в sql db, как в следующем примере? 

Company Microsoft = MSFT

db `companies_shares`

    ID symbol price owner_id* company_id last_trade_datetime
    1  msft   58.99 54334     101        2019-06-15 13:09:32
    2  msft   58.99 54334     101        2019-06-15 13:09:32
    3  msft   58.91 2231      101        2019-06-15 13:32:32
    4  msft   58.91 544       101        2019-06-15 13:32:32

*owner_id = user id of the person that last bought the share.

маркет-мейкер?например:

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

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

Какое лучшее решение?База данных или математика?

Заранее спасибо.

1 Ответ

0 голосов
/ 17 июня 2019

Вы также можете хотеть Google много-много отношений.

Подумайте об этом так.Один человек может иметь много акций.Одна акция может быть проведена многими людьми.Это отношение многие ко многим и обычно моделируется с использованием трех таблиц в физической базе данных.Это часто пишется как M: M

Кроме того, люди могут покупать или продавать одну компанию несколько раз, что, вероятно, будет смоделировано с использованием другой таблицы.С точки зрения человека будет много транзакций, поэтому мы имеем новый тип отношений один (человек) ко многим (транзакции).Это часто записывается как отношение 1: М.

Что касается того, что хранить, как правило, лучше всего хранить атомарные фрагменты данных.Например, для транзакции сохраните информацию о клиенте, дату / время транзакции, купленное или проданное количество и минимальную цену.

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

Вы также упоминали о производительности чаще, чем не крупные компании, такие как NASDAQ.будет использовать несколько уровней, если ИТ-инфраструктура.Каждый слой будет играть разную роль и, следовательно, разные функциональные характеристики и рабочие характеристикиЧасто это будут несколько серверов, работающих вместе в кластере.Например, они могут использовать систему NoSQL для управления большим объемом торговли.Оттуда может быть канал (например, kafka) в другие системы для других целей (например, предотвращение мошенничества, аналитика, отчетность и т. Д.).

Вы также упоминаете объемы данных.Я не знаю, сколько данных вы говорите, но у одного финансового клиента, с которым я работал, было несколько петабайт хранилища (1 петбайт = 1000 ТБ), работающих на более чем 300 серверах только для их аналитической платформы.Вероятно, они были среднего и крупного размера в том, что касается финансовых учреждений.

Надеюсь, это поможет вам в правильном направлении.

...