【问题标题】:Elasticsearch - implications of splitting documents into separate indexesElasticsearch - 将文档拆分为单独索引的含义
【发布时间】:2015-04-07 19:00:37
【问题描述】:

假设我有 100,000 个来自不同客户组的文档,它们的格式相同,信息类型相同。

来自各个客户组的文档会在一天中的不同时间刷新。有人建议我为每个客户组提供自己的索引,这样当我的个人客户索引在本地刷新时,我可以为该客户创建一个新索引并删除该客户的旧索引。

将数据拆分为多个索引并使用别名进行查询的含义是什么?具体来说:

  • 它会增加我的服务器硬盘需求吗?
  • 它会增加我的服务器 RAM 需求吗?
  • 通过查询别名查询所有索引,elasticsearch 会不会比较慢?

感谢您的任何帮助或建议。

【问题讨论】:

  • 到底有多少个索引?
  • @AndreiStefan 感谢您的评论。很难说。开始时大约 10 个,但未来可能会显着增加。
  • 这个想法是每个节点可以持有一定数量的分片。并且根据您使用这些索引的方式(索引/搜索频率、频率),节点可以容纳的最大分片数会有所不同。发挥作用的还有每个索引配置有多少个分片以及多少个副本。这将是我最初提出问题的原因。如果“刷新”是指更改该索引的所有文档,那么我认为构建新索引确实会更有效。但请记住分片的数量。
  • 集群有多少个节点?文档数量增加和客户数量的预测是什么?
  • 如果客户数量会显着增加,而您又没有增加节点的计划,那么坚持只使用一个索引。

标签: elasticsearch elasticsearch-mapping elasticsearch-model


【解决方案1】:

每个索引在所有级别都有一些开销,但通常很小。对于 100,000 个文档,我会质疑拆分的必要性,除非这些文档非常大。一般来说,每个添加的索引都会:

  1. 插入缓冲区和其他与每个索引相关的任务需要一定数量的 RAM

  2. 相对于更大的单个索引,在磁盘上有自己的合并开销

  3. 如果查询跨越多个索引,则会由于结果合并而在查询时提供一些延迟增加

很多因素决定了其中任何一个是否重要。如果您有大量 RAM 和多个 CPU 和 SSD,那么您可能会没事。

我建议您构建一个使用尽可能少的分片的解决方案。这可能意味着一个(或至少只有几个)索引。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2020-04-30
    • 2021-10-03
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2018-06-24
    • 2020-01-12
    相关资源
    最近更新 更多