针对大量数据的数据库设计

Question

我想存储 1000 个交易品种的股票交易数据。数据实际上是从文本文件转换而来的，因此不需要插入和更新;只需要只读访问权限。

数据基本上是这样分组的：每个交易品种都有许多记录：{timestamp, price, quantity}，每条记录代表一笔交易。

一个交易品种的数据近似上限为 5 条记录/秒，每个工作日 8 小时，即每天 5x60x60x8 = 144K。 即 1K 符号每天将生成 144M 条记录。

对数据的大多数操作如下所示：

• 给我一个交易品种的所有记录，周期日期 D1、时间 T1 到日期 D2、时间 T2
• 查找期间 [D1， T1...D2， T2]

现在的问题是：在这种情况下，数据库的最佳设计是什么？

• 我可以将交易品种的所有交易存储在一个表格中吗？不过，在这种情况下，表会很快变得太大。
• 我应该每天/每周/每月创建一个单独的表吗？ 即 2013-10-25_ABC （ABC - 交易品种名称）。在这种情况下，我们每天/每周/每月可能会获得 1K 个新表。
• 或者，在这种情况下，纯文本文件可能就足够了？ 例如，将所有符号数据作为 2013-10-15 文件夹下的文件，导致每个文件夹中有 1K 个文件

数据库可以是MS SQL或MySQL。总时间段 - 长达 5 年。谢谢！

Answer 1

这是一大堆数据。请看NoSQl。

使用 SQL，以下是一些基本思想：

将所有价格数据放在一个表中，使用尽可能小的数据类型。使用 SymbolId （int） 引用符号、所需的最小日期时间类型、所需的最小货币类型。

做非规范化。使用每天的最小/最大/平均值和 SymbolId 创建第二个表。

研究水平分区和使用索引。

Answer 2

第三个选项是最好的 1。您需要高读取性能，写入几乎可以忽略不计。

您的要求最适合 NoSql 数据库。没有关系的单个表;MySQL是矫枉过正的。 更多信息 --> NoSql 数据库

Answer 3

由于您将从一个日期时间运行查询到另一个日期时间，因此我根本不会拆分表。相反，请详细了解分片。以下是我将使用的架构：

symbols
    id          varchar(6) // MSFT, GOOG, etc.
    name        varchar(50) // Microsoft, Google, etc.
    ...
trades
    id              unsigned bigint(P)
    symbol_id       varchar(6)(F symbols.id)
    qwhen           datetime
    price           double
    quantity        double
    ...