【问题标题】:Druid: how it uses cache and OS page cache?Druid:它如何使用缓存和 OS 页面缓存?
【发布时间】:2018-12-10 13:02:46
【问题描述】:

我观察到 Druid 查询性能可以从之前的查询中受益。因此,我试图了解原因。 我知道德鲁伊使用缓存(我在代理中使用缓存),但是这个缓存只存储每个段的查询结果(对吗?)。但是,我注意到如果后续查询使用相同的段,则性能会提高。

例子:

  1. 从表 x 中选择 sum(metric), dimteste2, dimteste3 where dimteste='x' group by dimteste2, dimteste3 -> 2 秒
  2. 从表 x 中选择 sum(metric), dimteste2, dimteste3 where dimteste3='y' group by dimteste2, dimteste3 -> 0.5 秒

我搜索了一下,发现这个行为可以通过OS页面缓存来实现。根据我的研究,我认为 Druid 在第一次查询数据源期间会将必要的段加载到内存(操作系统页面缓存)。并且在接下来的查询中可以更快地读取这些段。

我说的对吗? 我查看了 Druid 文档,但找不到任何有用的信息。

您能帮我解释一下这种令人敬畏的行为吗?

最好的问候,

何塞·科雷亚

【问题讨论】:

    标签: bigdata druid


    【解决方案1】:

    Druid 确实使用缓存来提高各个级别的性能。在历史数据的细分级别和经纪人的德鲁伊查询级别。你给它的内存越多,它的工作速度就越快。

    以下是关于缓存的文档 -

    查询缓存

    Druid 通过 LRU 缓存支持查询结果缓存。结果与给定查询的参数一起存储在每个段的基础上。这允许 Druid 部分基于缓存中的段结果和部分基于扫描历史/实时段的段结果返回最终结果。

    分段结果可以存储在本地堆缓存或外部分布式键/值存储中。段查询缓存可以在历史和代理级别启用(不建议同时启用缓存)。

    代理上的查询缓存

    在代理上启用缓存可以比在历史数据上为小型集群启用查询缓存产生更快的结果。这是较小的生产集群(

    历史数据上的查询缓存

    较大的生产集群应仅在历史数据上启用缓存,以避免必须使用代理来合并所有查询结果。在 Historicals 而不是 Brokers 上启用缓存可以让 Historicals 进行自己的本地结果合并,并减轻 Brokers 的压力。

    Druid 代理不会直接在操作系统页面缓存中执行任何操作,如果 操作系统有可用的虚拟内存,而不是基于内存 要求分配堆。

    【讨论】:

    • 感谢您的回复 mdeora。我看过文档,但我仍然不完全理解。我如何解释更复杂的查询,在对同一数据源执行更简单的查询之后执行返回结果所需的时间大大减少?我禁用了德鲁伊缓存,行为是一样的。因此,这是由于操作系统页面缓存,对吧?
    • @JoséCorreia 查询结果与查询参数一起存储在段级别的 LRU 缓存中,因此如果您再次使用与假设相同的结果进行查询,则不会进行任何查找,只有单个键值查找在段级别完成。
    • 我说的是类似的查询,但结果不同。我使用两个类似的查询对此进行了测试,但第二个使用具有更大基数的属性。从理论上讲,第二个查询应该比查询 1 花费更多的时间。重要说明:我禁用了 Druid 缓存来测试它。因此,没有 LRU 缓存。我将“useCache”和“populateCache”设置为 false (druid.io/docs/latest/querying/query-context.html)。
    • 就缓存而言 - 它纯粹基于 druid 可用于将段数据放入 druid 的内存堆。另请注意,还有许多其他因素会影响查询时间,例如。使用的段数、查询类型(topn、select、group by 等)。在这种情况下,我想不出操作系统页面缓存的任何具体作用。
    • 请在此链接中查看 rohit kochar 的回答:stackoverflow.com/questions/41415296/… 并让我知道您的意见。
    猜你喜欢
    • 2021-09-30
    • 1970-01-01
    • 2015-01-21
    • 2015-07-21
    • 2015-08-05
    • 2017-02-13
    • 1970-01-01
    • 1970-01-01
    • 2011-07-02
    相关资源
    最近更新 更多