所以Apache查询太慢了

Question

目前，我正在使用，该仓库存储近3亿行，大小为44 of。我们正在开发一个使用Gunicorn和芹菜在Druid中开发SQL查询的Flask。它存在一个React，它生成对Flask的多个请求，然后在一个适当的SQL查询中向Druid生成API请求数据。我们的问题是德鲁伊的反应持续了很多时间。也就是说，当我们向德鲁伊发送接近50的请求时，可能需要近1.3分钟才能返回最后的答复。我们在前端和API优化方面做了大量工作，但我们怀疑问题存在于Druid数据源中。

我们的Druid Datasource有以下功能：

1. 总数据大小44.01 GB
2. 段大小(行)最小: 1，平均:0.151 M，最大值:0.637M
3. 分段粒度:日
4. 行数共计: 295.465.723
5. 平均行号: 148
6. 复制大小: 44.01 GB
7. 压缩:不启用。

然后，我们对数据源运行一个查询，发现行数最多的段有636688行，字节大小为80859007。

我认为我们需要在数据源中进行压缩操作，目的是根据Druid文档中关于段的引用来增加每个段的行数。在再次摄入我们的数据源之前，我想知道段的压缩是否会提高查询性能？或者我们需要在这个问题上采取另一种方法。

非常感谢

Answer 1

平均而言，这些是非常小的片段。读取每个段有一定的开销，因此它可能有助于进行一些压缩，并尝试实现段~500万行。历史中的每个线程一次只读取一个段，如果每个片段都包含大量的数据(~500-700 MB)，则效率要高得多。

本节的文档讨论了分段尺寸优化的重要性。

还有一些关于查询和并发优化的其他想法：

• 查询是否指定时间间隔筛选器？
• 这些查询试图做些什么？
• 是否启用了汇总？queryGranularity是什么？
• 最终用户需要什么时间的粒度？
• 你们有多少部历史剧？这将影响查询执行的并行性。
• 历史配置怎么样？我特别好奇的是：

a.druid.processing.numThreads

b.druid.server.http.numThreads

默认情况下，根据可用的CPU设置它们，从而确定每个历史记录的执行的并行性以及用于处理通信请求的线程的可用性。

一旦我们更多地了解了用例和集群过程可用的资源，我们就可以更好地帮助您优化工作负载。

Answer 2

尝试通过API查询数据源，以检查单个查询返回的速度。

curl -X POST 'http://your-druid-server:8082/druid/v2/?pretty' -H 'Content-Type:application/json' -H 'Accept:application/json' -d @/home/your-directory/your_query.json

您可以首先考虑优化慢速查询，比如使用相关的时间间隔或其他调整。如果它仍然慢(查询的分钟)，您可能可以尝试压缩，但它不能保证改善您的查询。