【问题标题】:What is the best way to structure a database for a stock exchange?为证券交易所构建数据库的最佳方法是什么?
【发布时间】:2019-06-16 22:25:57
【问题描述】:

我正在尝试制作一个股市模拟器,我希望尽可能真实。

我的问题是:纳斯达克有 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.

还是根据做市商提供的可交易股票和买卖需求计算?例如:

我已经尝试过第一个示例,因为它在我的数据库中占用了很多空间,我担心所有这些交易的带宽,尤其是当每分钟都发出数百万个请求(交易)时。

我已经尝试过第一个示例,因为它在我的数据库中占用了很多空间,我担心所有这些交易的带宽,尤其是当每分钟都发出数百万个请求(交易)时。

什么是最好的解决方案?数据库还是数学?

提前致谢。

【问题讨论】:

  • 上面的结构在我看来还不错。我认为纳斯达克会有一些相当强大的服务器......
  • 纳斯达克每天而不是每分钟有数百万笔交易。股票市场关注的是交易,而不是单个股票。所有尝试的交易都被存储和匹配。你的问题太笼统了。
  • 这不是一个真正的编程问题,这是一个合法的问题。如果需要证券交易所来跟踪每只股票,那么您必须创建这样的表。否则,你不会。

标签: mysql sql stock


【解决方案1】:

您可能还想在 Google 上搜索多对多关系。

这样想。一个人可能拥有许多股票。一只股票可能被很多人持有。这是一个多对多关系,通常使用物理数据库中的三个表进行建模。这通常写为 M:M

此外,人们可能会多次购买或出售一家公司,这可能会使用另一张表进行建模。从人的角度来看,会有很多交易,所以我们有一种新型的关系,单(人)对多(交易)。这通常写成 1:M 关系。

至于存储什么,作为一般规则,最好存储原子数据。例如对于一笔交易,至少存储我要的客户、交易日期/时间、购买或出售的数量以及价格。

您可能还想阅读有关规范化的信息。通常第 3 范式是一个很好的努力水平,但很多都是“这取决于你的情况和你需要做什么”。人们通常会以牺牲更多存储空间和可能更复杂的更新为代价来提高访问速度……

您还提到了业绩,通常是纳斯达克等大公司。如果是 IT 基础设施,将使用多层。每一层将具有不同的作用,因此具有不同的功能特征和性能特征。通常它们是在一个集群中一起运行的多台服务器。例如,他们可能使用 NoSQL 系统来管理大量交易。从那里可能会出于其他目的(例如防止欺诈、分析、报告等)向其他系统提供信息(例如 kafka)。

您还提到了数据量。我不知道您在谈论多少数据,但在我工作过的一位金融客户那里,为了他们的分析平台,在 300 多台服务器上运行了几个 peta 字节的存储空间(1 peta 字节 = 1000 TB)。就金融机构而言,它们可能是大中型。

我希望这有助于为您指明正确的方向。

【讨论】:

  • LOL 感谢@Shadow 的编辑。有时自动更正是非常 - 我敢说 - “士气低落”!!! :-)
  • 它确实对我们所有人都有好处:)
猜你喜欢
  • 1970-01-01
  • 2012-03-04
  • 1970-01-01
  • 1970-01-01
  • 2018-05-22
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多