我需要构建一个系统来存储和维护大量（20 [TB]）的时间序列数据（用于许多不同的仪器），以便它能够支持以下要求：
(1) fast appends of new data, as new data comes in
(2) fast retrievals of existing (already stored) data
有 10,000 种工具和 1000 个数据字段（每 1 分钟更新一次）需要保存。一旦数据写入磁盘，它就会保持不变（不存在并发写入/读取问题）。
由于根本不需要任何连接（典型查询是give me all instruments for field 'X' on interval 'Y'：），我倾向于使用平面二进制文件来存储数据，这些文件将像这样命名：fieldName.timeStamp.bin；这样，我将能够将所有数据存储在平面二进制文件中（不需要为大型服务器/商业数据库花费巨资），而且查询速度仍然很快。
由于数据量很大（大约 20[TB]），我认为我需要一些逻辑来将文件（fieldName.timeStamp.bin）分发到我的所有机器上。我的想法是：有一台中央机器，所有查询都发送到该机器。这台中央机器（基于请求的字段和时间戳）会将查询路由到感兴趣的机器，然后该机器将返回请求的数据。
我的问题是：
(1) is this design scalable as I think it is? any drawbacks?
(2) is there anything I am missing here that might hurt performance?
(3) is it really the best way to send all queries to a central machine, that would in turn route the query to the right machine? or would it be best to directly access the 正确的机器（假设我知道是哪一个）using NFS？
(4) is there a faster way than NFS to access the 正确的机器 to read data from it? are there other methods for sharing all the data that on the data machines with client machines?
我所有的机器都使用 Ubuntu Linux。可以理解的是，将有许多client机器访问各种数据data machines并从中读取（只读，不写）数据。我的目标是尽可能快地读取数据。
答案1
您可能还想看看OpenTSDB，一个基于 Hadoop 的系统，用于存储和检索大量时间序列数据。我从未使用过它，但它听起来很方便，至少接近你的目的。
答案2
Tahoe 最低权限文件系统可以自动解决许多这些问题，特别是如果你可以使用他们的工具来检索数据。至少，在制作自己的系统之前，我会先看看它。如果没有关于实际带宽和延迟要求的数据，我就不能说更多了。
答案3
几点说明：
1) 在这里使用集中式服务器似乎没有必要。为什么不对文件名进行哈希处理并使用简单排序来决定在哪个服务器上存储/获取文件？这样，您就不需要中央服务器来存储/写入文件。
2) 考虑到您谈论的系统的规模，我会考虑使用 Lustre 或 GLuster 来为您处理文件系统，而不是使用 NFS。让它们为您完成艰苦的工作。两者都用于比这大得多的系统，并且有着良好的记录。
3) 如果您决定自行设置，我建议您认真考虑使用 OpenSolaris / Nexenta w/ZFS。对于如此大的文件系统，ZFS 的一些优势非常有用：
a) ZFS 可进行智能 raid 重建。我可以在 30 小时内在 10x2tb raid 50 驱动器设置上重建 16tb 数据。这比使用硬件 raid 卡进行相同类型的重建要快得多。b) ZFS 不需要 fsck，即使使用 ext3/4，对如此大的分区进行 fsck 也会非常痛苦。c) ZFS 的写入 I/O 调度程序非常强大。您可以添加单个 SSD 来保存 ZIL 日志/LARC2 缓存，并通过硬盘的大量数据保留获得基于 SSD 的存储系统的大部分收益。d) ZFS 内置了非常强大的 NFSv4 服务器。共享易于配置。e) ZFS 内置了文件系统级重复数据删除功能，如果仪器读数经常返回相似的结果，这对您来说可能是一个巨大的好处。