Apache Geode：在查询

Question

当order by子句作为查询的一部分提供时，我们目前面临性能问题。

当前规格： 我们正在运行两个容量为20Gb（最大堆大小）的geode服务器。 Geode拥有约310万条记录，该表有148万条记录。

查询：

  

query --query =“SELECT DISTINCT cashFlowId，upstreamSystem，upstreamSystemTxnDate，valueDate，amount，status FROM WHERE AND account IN SET（'XYZ'，'ABC'）AND valueDate＆gt; = TO_DATE（'20180320'，'yyyyMMdd '）AND status ='预订'AND isActive = true AND category ='Actual'ORDER BY金额DESC LIMIT 100“

上述查询在2-3次后13-15秒内检索输出。

  

实际结果集：666553

     

表中记录数：1.49百万

到目前为止，我们尝试/观察了什么？

1. 我们发现正确选择了索引（类型：范围）。
2. 即使为JVM分配更多内存后也没有任何改进。
3. 已验证IN运算符对查询性能没有影响。我们使用OR运算符
尝试了相同的操作
4. 在删除Order by子句后，查询将在2秒内完成。我们认为排序大部分时间都在进食。

您能否指导或提供一些有关改善查询效果的信息？

服务器指标：

Category  |        Metric         | Value
--------- | --------------------- | ------------
cluster   | totalHeapSize         | 47135
cache     | totalRegionEntryCount | 3100429

Answer 1

像Urizen所说，检查GC的数量，但还有更多。这是代码，它看起来相当紧凑：Geode Order By Comparator。还有另一个与分布式排序顺序相关的因素与Geode作为产品几乎没有关系。每个节点都按顺序排序，但是当从每个节点返回结果时，这些结果需要与其他节点的结果合并。换句话说，给定一组{2,4,3,1,6,5}，节点1可以排序{2,5,6}，节点2排序{1,3,4}，但控制节点需要为你做一个合并{1,2,3,4,5,6}。我怀疑其中有一些也在继续。这与Geode本身无关，而只是按照分布顺序排列。在数据库性能优化理论中，数据库是执行订单的最差位置。

我想知道这里更好的方法是返回2个答案集：1）你想要但未分类的答案集，以及2）K是金额的小KV集合，V是键。然后在客户端上，你会做一些小KV集合并迭代KV集合，按顺序读取你的大答案集。

如果您不想编写一个函数来执行此操作，您可以预先执行一个额外的查询来选择金额，键FROM ...，将其包装在已排序的集合中，然后执行完整的未排序查询。这应该非常快，因为在如此大的答案集上，网络会部分消耗2秒钟。

Jason可能有一些技术见解，但如果你有像你这样的大答案集，那么从服务器上卸下负载可能就是答案。