Question

我们的系统需要处理来自数千个客户的数十亿个查询，以获取数百万资源。有些资源的查询频率会高于其他资源。每个客户端一次可以提交数百到数百万个查询。因为每个资源每分钟只能支持数千个查询，所以查询将被排队，并且它们的结果将异步确定。

现在，这就是问题：每个客户的查询需要在每个资源方面获得相同的优先级。也就是说，如果一个客户端为特定资源提交了一百万个查询，然后另一个客户端立即提交了十几个查询，则第二个客户端不应该等待第一个客户端的查询在他们之前处理。相反，首先应该处理一个客户端的第一个查询，然后是另一个第一个查询，然后是第一个查询，依此类推，来回。（以及两个以上客户端和多个资源的类似想法;同样，只要保留这个基本思想，它就可以稍微细化一点。）

如果这个小到可以在内存中，我们只需要一个从资源到地图的映射，从帐户到查询队列，并循环迭代帐户，每个资源;但事实并非如此，因此我们需要基于磁盘的解决方案。我们还需要它是健壮的，高可用性的，事务性的等。。我有什么选择？我正在使用Java SE。

提前致谢！

Answer 1

提前，我知道HBase比Cassandra好多了。我的回复的某些方面是HBase特定的，我会将它们标记为这样。

假设您提供了足够的硬件，那么像Cassandra或HBase这样的BigTable实现会为您提供以下内容：

以极高的费率存储和检索查询的功能
以极高的速率吸收删除的能力（尽管使用HBase和Cassandra，刷新写入磁盘会导致定期延迟）

通常情况下，我可以看到一个架构，你使用了resource-id作为行键和account-id以及时间戳作为列键的组合，但是（特别是在HBase中）这可能导致托管某些流行的服务器中的热点资源（在HBase和Cassandra中，单个服务器负责一次托管任何给定行的主副本）。在Cassandra中，您可以通过使用异步写入（仅写入一个或两个节点，并允许八卦复制它们）来减少更新的开销，但这可能会导致旧记录在网络流量大小的情况下显着延长。高。在HBase中，写入始终是一致的，并始终写入托管该行的RegionServer，因此热点肯定是一个潜在的问题。

您可以通过将行键设置为资源ID和帐户ID的组合来减少热点的影响，但是您需要扫描所有行键以确定对资源有未完成查询的帐户列表。

您可能没有考虑的另一个潜在优势是直接从HBase或Cassandra数据节点运行查询的潜在能力，从而使您无需再次通过网络将查询发送到执行程序进程以实际运行该查询查询。您可能需要查看HBase Coprocessors或Cassandra Plugins来执行此类操作。具体来说，我正在谈论改变这个工作流程：

                                 /-> Query -> Executor -> Resource -> Results -> \
Client -> Query -> Query Storage --> Query -> Executor -> Resource -> Results -> --> Client
                                 \-> Query -> Executor -> Resource -> Results -> /

成像：

                                 /-> Query -> Resource -> Results -> \
Client -> Query -> Query Storage --> Query -> Resource -> Results -> --> Client
                                 \-> Query -> Resource -> Results -> /

但是在你的用例中这可能没有意义。

Answer 2

我可以就Cassandra给你一些答案。

Cassandra内部只编写新的数据文件，只是顺序执行，从不覆盖或修改现有文件，并且只有附加的预写日志，如事务性关系数据库。 Cassandra内部认为删除与其他任何写操作基本相同。

Cassandra可以在许多节点上进行线性扩展，并且没有单点故障。它对读取和写入都是线性可伸缩的。也就是说，只要您向群集添加足够的节点并为群集提供时间来重新平衡新节点上的数据，单个群集就可以支持您希望向其投入的任意数量的并发读取和写入。 Netflix最近load-tested Cassandra on EC2发现了线性可扩展性，他们在288个节点上测试的最大集群支持1,000,000次写入/秒持续一小时。

Cassandra支持many consistency levels。从Cassandra执行每次读取或写入时，您可以指定要执行的读取或写入的一致性级别。这使您可以确定，每次读取和每次写入，读取或写入是否必须快速，或者必须在托管该行的所有节点上一致地完成。

Cassandra不支持多操作交易。

如果Cassandra数据模型在您的情况下运行良好，Cassandra可能是最简单的解决方案，至少在操作级别。每个节点配置完全相同。没有主人，也没有奴隶，只有平等的同伴。没有必要设置单独的负载平衡，故障转移，心跳，日志传送，复制等。

但唯一可以确定的方法是测试它。

持久映射到队列以进行公平调度？

2 个答案: