仅针对日终数据，将有数十亿行。存储所有数据的最佳方法是什么。 SQL Server 2008是否足够好，或者我应该关注NoSQL解决方案，例如MongoDB。有什么建议吗？
如果有一个具有读/写权限的主数据库以及一个或多个用于只读操作的复制，那将是很酷的。只有master数据库才能用于向存储中添加新价格。另外，为了优化读取访问权限，能够单独复制大多数流行证券的OHLC价格会很酷。
然后，这些数据将流式传输到客户机器上的交易平台。
答案 0 :(得分：4)
您应该考虑在一些知名证券交易所的基础设施中正在生产的Oracle Berkeley DB。 Berkeley DB允许您在主设备上记录信息作为简单的键/值对，在您的情况下，我想象一下键的时间戳和值的编码OHLC设置。 Berkeley DB支持单主多副本复制（高可用性称为“HA”），以支持您概述的内容 - 读取可伸缩性。如有必要，Berkeley DB HA将自动故障转移到新的主服务器。使用Berkeley DB的一些简单压缩和其他基本功能，您将能够满足您的可扩展性和数据量目标（数十亿行，每秒数万个事务 - 取决于您的硬件，操作系统和BDB配置 - 请参阅3n+1 benchmark with BDB寻求帮助）没有问题。
当您开始访问OHLC数据时，请考虑Berkeley DB对批量获取的支持，并确保使用B-Tree访问方法（因为您的数据具有顺序和位置将提供更快的访问）。还要考虑使用Berkeley DB分区API来分割数据（可能基于符号甚至基于时间）。最后，因为您将复制数据，所以只要您的复制确认策略需要法定数量的副本ACK写入，然后再将其考虑为持久性，您就可以放宽对DB_TXN_WRITE_NOSYNC的持久性约束。在这种情况下，您会发现快速网络胜过快速磁盘。此外，要从主服务器卸载某些工作，请启用对等日志副本分发。
但是，首先阅读replication manager getting started guide并查看代表引用示例 - 它已经实现了您正在尝试做的一些事情（方便，嗯？）。
仅仅是为了记录，我完全披露了我作为Oracle Berkeley DB产品的产品经理。我有九年了，所以我有点偏颇。我猜其他解决方案 - 基于SQL或不基于SQL - 最终可能会给你一个工作系统，但我相信Berkeley DB可以不费吹灰之力。
答案 1 :(得分：0)
如果你真的每天都在谈论数十亿的新行（联邦快递的数据仓库不是那么大），那么你需要一个可以跨多台计算机分区的SQL数据库，比如Oracle或IBM的DB2。
另一种替代方案是像IBM的DFSMS那样的重型系统管理存储。