问如何处理海量数据查询，并将时间控制在1秒以内？

EN

1. 分区。你能做的最快的I/O是你不需要做的I/O。
2. 索引。在适当的情况下，不是针对每一列。您不能让每个查询都以内存速度运行，所以您必须挑挑拣拣。
3. 现实主义。您不会在一秒钟内通过关系引擎处理十亿次I/O。

当然要分散开。

你可以使用像Hive ( http://wiki.apache.org/hadoop/Hive )这样的东西来进行SQL查询。

无论您有10万行还是1000亿行，每次查询都需要几分钟时间。您将在许多不同的计算机上存储数据，通过hadoop的魔力，您的查询将转到数据所在的位置，执行该部分的查询，然后返回结果。

或者，对于具有更多限制的更快的查询，请查看Hbase ( http://hbase.apache.org/#Overview )。它也位于hadoop之上，并且在较少的SQL like的权衡下速度更快。

我认为你应该社区维基，因为没有一个正确的答案(或者你在你的问题中得到了更多具体的答案)。

首先，扩展Tim的索引。Btree索引就像一个倒置的金字塔。你的Root/'level 0‘块可能指向100个'level 1’块。它们分别指向100个“2级”块和100个“3级”块。这是一百万个“3级”块，可以指向一亿个数据行。要访问数据集中任何行，需要进行五次读取(除了最后两行之外，其他所有行可能都缓存在内存中)。再多一级，你的数据集就会提升两个数量级。索引的伸缩性非常好，所以如果您的应用程序用例在一个非常大的数据集中处理小数据量，您就没问题了。

分区可以被视为索引的另一种形式，在这种情况下，您希望快速排除工作的重要部分。

当您希望在更大的数据集中处理大型数据集时，数据仓库设备是第二种解决方案。通常，解决方案是在出现问题时抛出磁盘，无论有没有专用于这些磁盘的CPU/内存，都可以解决问题。

分布式数据库主要解决的是一种不同形式的可扩展性，即大量并发用户。CPU可以寻址的内存是有限的，因此CPU可以处理的用户数量也是有限的，而不会出现内存争夺战。复制在一定程度上起到了作用，尤其是对于老式的读取繁重的应用程序。较新的NoSQL数据库要解决的问题是做到这一点并获得一致的结果，包括管理备份和恢复以恢复一致性。他们通常通过追求“最终一致性”来做到这一点，接受短暂的不一致作为可伸缩性的权衡。

我敢说，很少有NoSQL数据库的数据量排除了关系型数据库解决方案。相反，推动分布式数据库的是用户/事务/写入卷。

固态存储也将发挥作用。最近，棕色旋转磁盘的问题与旋转时的容量关系较小。它们不能足够快地访问您可以存储在它们上的所有数据。从根本上说，闪存驱动器/卡/内存/缓存占用了阻碍一切的“寻道”时间。