我想构建一些东西来存储和提供时间序列数据，这些数据来自不同时间间隔的各种来源。这包括原始数据和计算数据。例如，假设我想记录每 30 秒的温度读数，以及每 5 分钟单独计算的温度预测。
我需要能够快速查询数据，并且我发现关系数据库一旦变得太大就无法正常工作。所以我正在考虑创建某种内存中的东西，但我确信它会在某个时候崩溃，所以我需要将数据保存到磁盘。所以我想知道，为什么不让整个事情都基于磁盘，对常用数据进行某种缓存呢？
但我对如何去做这件事有点不知所措。我正在想象数据源定期将更新数据集推送到服务器，使用某种字符串键/符号来识别数据是什么。服务器获取数据，然后呢？将其写入某种二进制文件？我可以每个符号写入一个文件吗？（假设超过 100k 个符号）
我认为我想要的是类似于 google 的 BigTable，但规模要小得多。基本上，一个分布式哈希表，将字符串键映射到相关数据的时间序列，具有非常快速的检索和按时间检索范围查询的能力。和多维数据的加分。
哦，这将（理想情况下）由 C#/windows 项目 - 它不需要那么高性能。
遗憾的是，NDA 协议禁止我告诉您如何执行此操作。我在创建一个非关系数据库的团队工作，该数据库完全符合您的要求。它被称为城堡。但是，我可以向您指出公开可用的链接，它应该会给您一些关于它是如何工作的想法。
http://zone.ni.com/devzone/cda/tut/p/id/6579
您可以直接购买该产品，但价格相当昂贵。
同样正如Karl指出的，这通常用于 SCADA 产品，如Wonderware、Lookout和LabVIEW DSC。
搜索SCADA 数据存储也会发现一些有趣的读物。
顺便说一句，如果数据量很小，关系数据库可以解决这个问题。随着时间的推移，往往会发生数据无限增长的情况，并且关系数据库的容量会超出其容量。一个好的 SCADA 数据存储系统可以轻松处理每秒轮询 50000 个点。尽管在某些时候，它们甚至开始变得太大而无法轻松处理。
我必须告诉你，没有任何“文件系统”方法（我知道）会比关系数据库更快。而且情况可能会更糟。
关系数据库的问题不在于它们本质上很慢，而是将数据放入其中可以非常容易地完成，而无需考虑数据的保存方式。一个好的索引，即使是数百万条记录，也应该产生亚秒级的结果。这更多的是设计问题而不是访问问题。如果你设计得好，访问就会到来。
编辑：另外，如果“关系数据库”是指 Microsoft Access，那么你是对的；记录很多，速度很慢。我不会走那条路。如果钱是问题，请查看 MySql，如果钱不是问题，请查看 Oracle/Sql Server。
“ RRDTool是开源行业标准、高性能数据记录和时间序列数据绘图系统。”
它分为两部分，第一部分用于记录、存储和检索时间序列数据，第二部分用于绘图。有很多使用它的例子。
即使你不使用它，它的设计也绝对是相关的。
我同意其他人的观点，即数据库将是您最好的选择。
如果您确实要生成如此大量的数据以至于会导致性能问题，您可能需要创建两个表 - 一个作为“实时”源，另一个作为“存档”。
您的系统会将新数据插入实时表中，并且批处理作业会定期将数据从那里移动到存档表中。当性能受到关注时，您将只查询较小的实时表。如果您确实需要查询所有数据，您将查询 UNION 实时表和存档表的视图。
听起来像是 SCADA（系统控制和数据采集）类型的应用程序，利用了系统的数据采集部分。您是否查看过现成的解决方案。Wonderware/IndustrialSQL 或其他竞争产品？
话虽如此，我现在的雇主（The MetService，新西兰）每 30 秒、1 分钟或 1 小时记录一次来自自动气象站（温度、降雨量、风等）的读数，并预测到 Oracle DB。最小索引；索引减慢了 4 个 DML 操作中的 3 个并加快了 Selects 当然，您需要 3 个操作快速，尤其是插入。快速 IO 系统。用于重做日志的非常快的 IO。我们正在转向分区表，以便删除速度更快并生成更少的重做（删除包括内容的表空间而不是发出删除）虽然给予轻量级快速插入的事务很严重。尽管对执行插入和网络的机器和数据库的性能很重视。
如果您使用数据库并取出索引和关系部分，您几乎可以得到您所描述的内容。但是，我不确定它会有多大用处。你能给我们一个更好的想法，为什么数据库不适合你吗？你试过什么没用？
我不确定你为什么要为此使用数据库。我已经对具有数千万行的表进行了实时统计。此外，您可以定期对读数进行批处理，以将数十万行转换为数百行编译数据——显然取决于您的需要。
至于内存持久性和键值对访问，您可能需要查看memcachedb。它基于 memcached 并提供出色的性能。
此外，在考虑更多之后，您可以轻松地将事物作为内存中的哈希表运行，然后定期将其序列化到文件系统以保持持久性。