数据库如何存储实时秒数据？

Question

所以我所说的实时秒数据是指股票市场，每一秒数据都被输入到特定股票项目的确切区域。

数据在数据库中的外观如何？ 它有每秒的时间戳吗？ 如果是这样，那不会导致数据库快速填满吗？ 是否有特定的数据库来管理这种类型的东西？

谢谢！

Answer 1

考虑到金融科技领域的巨额资金，如果交易平台甚至使用传统的 RDMBS 数据库来存储他们的交易数据，我会感到惊讶，但我离题了......

数据在数据库中的外观如何？

（再次，假设他们甚至首先使用基于关系的模型）然后在 SQL 中是这样的：

CREATE TABLE SymbolPrices (
    Symbol char(4)  NOT NULL, -- 4 bytes, or even 3 bytes given a symbol char only needs 32 bits-per-char.
    Utc    datetime NOT NULL, -- 8 byte timestamp (nanosececond precision)
    Price  int      NOT NULL  -- Assuming integer cents (not 4 digits), that's 4 bytes
)

...具有 16 字节的固定行长度。

它有每秒的时间戳吗？

它可以做到，但不是每秒- 你需要比这更大的粒度：如果他们使用至少100 纳秒的分辨率，我不会感到惊讶，这是计算机系统时钟“滴答”的常用单位（例如.NET 的DateTime.Ticks是一个 100 纳秒单位的 64 位整数值）。 Java和 JavaScript 都使用毫秒，尽管这个分辨率可能太粗略了。

如果您改为存储增量而不是绝对值，则更改数值的存储空间要求始终可以得到显着优化：我认为每条记录可以降低到 8 个字节：

• 我认为 3 个字节足以以~1.5ms 1.5 毫秒的分辨率存储交易时间戳增量，假设每只股票每天 100,000 笔交易：即 1670 万个值代表 7 小时（ 25,200s ）的交易窗口，

• 价格差异也可能减少到 2 字节值（ -$327.68到+$327.67 ）。

• 并假设符号永远不会超过 4 个大写拉丁字符（ AZ ），那么它可以用 3 个字节表示。

• 提供改进的 8 字节 ( 3 + 3 + 2 ) 的固定行长度。

  • 尽管您现在需要每隔几千行存储“关键帧”数据，以防止需要从一开始就重新播放每笔交易以获得当前价格。

• 如果数据是按符号物理分区的（即，为每个符号使用磁盘上的单独文件），那么您根本不需要在记录中包含符号，将行长度降低到仅5 bytes 。

如果是这样，那不会导致数据库快速填满吗？

不，不是真的（至少假设您使用的是自 2000 年代初期以来制造的 HDD）； 考虑到：

• 主要证券交易所确实没有那么多股票，例如纳斯达克只有几千只股票（显然是5,015 ）。

• 虽然备受瞩目的股票（APPL、AMD、MSFT 等）的 30 天销量通常在 20-1.3 亿量级，但这只是最受欢迎的约 50 只股票，大多数股票的 30 天销量远低于此。

  • 让我们假设所有 5,000 只股票的 30 天交易量均为 300 万。
  • 平均每只股票每天约 100,000 笔交易。
  • 这将需要每只股票每天100,000 * 16 bytes 。
    • 也就是说，每只股票每天1,600,000 bytes 。
    • 或每只股票每天1.5MiB 。
      • 每只股票每年556MiB 。
  • 对于整个交易所（5,000 只股票）来说，这是7.5GiB/day 。
    • 或2.7TB/year 。
  • 当使用增量而不是绝对值时，存储空间需求减半至每只股票~278MiB/year ，或整个交易所的1.39TB/year 。

• 在实践中，历史信息可能会被存档和压缩（可能使用列优先的方法使它们更易于使用通用压缩方案进行良好的压缩，如果数据按符号分组，则可以再减少 4 个字节）。

  • 即使没有压缩，按符号分区和使用增量意味着整个交换870GB/year 。
    • 这足够小，可以装入亚马逊 40 美元的 HDD 驱动器。

是否有特定的数据库来管理这种类型的东西？

毫无疑问，但我认为他们不需要专门针对存储空间进行优化——更有可能是写入性能和安全性。

Answer 2

他们使用不同的大数据架构，如Kappa 和 Lambda ，其中数据在近实时和批处理管道中进行处理，在这种情况下，实时第二数据“存储”在Apache Kafka等消息传递引擎中，然后被检索、处理和摄取到具有流处理引擎的数据库，例如Apache Spark Streaming

他们通常不使用 MySQL、SQL Server 等 RDMBS 数据库来存储数据，而是使用 NoSQL 数据存储或 Apache Avro 或 Apache Parquet 等格式存储在 AWS S3 或 Google Cloud Storage 等存储桶中，并正确分区以提高性能.

一个完整的例子可以在这里找到： 使用 Apache Spark 和 Kafka 的流式架构