关于高效ElasticSearch文档设计的建议

时间:2018-10-19 04:23:45

标签: elasticsearch

我正在研究一个处理列表的项目(例如:Craiglist,Ebay,Trulia等)。

信息的基本单位是“列表”,如下所示:

{
   "id": 1,
   "title": "Awesome apartment!",
   "price": 1000000,
   // other stuff
}
可以搜索

一些字段(例如价格,位置等),其他字段仅用于在应用程序上显示(例如标题,包含大量HTML的描述等)。

我的问题是:我应该将所有数据存储在一个文档中,还是将其拆分为两个文档(一个用于搜索,例如“ ListingSearchIndex”,一个用于显示,例如“ ListingIndex”)。

我还必须对文档进行一些相当大的汇总。

我想的问题是,在较小的文档中进行搜索,然后再执行另一个调用以通过id提取结果比在整个文档中进行搜索会更快吗?

主要因素显然是速度,但是如果我分割文档,那么维护也将是一个因素。

对最佳做法有何建议?

谢谢:)

3 个答案:

答案 0 :(得分:0)

根据我在Elasticsearch方面的经验,在查询,聚合等时,分片配置在集群性能/速度方面非常重要。由于,每个分片本身都会消耗集群资源(内存/ cpu),并且会增加集群开销,因此非常适合正确获取分片计数,以使群集不会过载。我们的集群分片过多,影响了加载搜索结果,可视化效果,繁重的聚合等。一旦修复了分片计数,它就可以正常工作!

https://www.elastic.co/blog/how-many-shards-should-i-have-in-my-elasticsearch-cluster

旨在将平均分片大小保持在几GB到几十GB之间。对于具有基于时间的数据的用例,通常会看到碎片大小在20GB到40GB之间。

您可以在节点上保留的分片数量与您可用的堆数量成正比,但是Elasticsearch并没有规定固定的限制。一个好的经验法则是确保将每个节点的分片数量保持在配置的每GB堆20到25个以下。因此,具有30GB堆的节点最多应具有600-750个分片,但是越低于此限制,您可以使其越好。通常,这将有助于群集保持良好的健康状态。

答案 1 :(得分:0)

除了性能,我认为这里还有其他方面需要考虑。

与其他数据库相比,ElasticSearch在准确性和健壮性方面的保证较弱(有关此主题,请参见其博客文章ElasticSearch as a NoSQL database)。它的重点是搜索和搜索性能。

由于这些原因,正如他们在以上博客文章中提到的那样:

  

除了其他数据库外,Elasticsearch也经常使用

遵循该模式的一种方法:

  • 将数据存储在主数据库(例如关系数据库)中
  • 仅对搜索和聚合所需的内容编制索引,并将搜索结果链接回主数据库中的项目
  • 在显示之前从主数据库获取所需的内容-即,用于显示的数据主要应来自主数据库。

此方法的要旨是不要将ElasticSearch视为事实的来源;而是有了另一个事实来源,您可以从中索引数据。

这样做的另一个好处是,当您为新的搜索用例更改索引映射时(或在更改诸如分析器等的索引时间处理时),可以轻松地从主数据库重新索引。

答案 2 :(得分:0)

我认为您必须事先知道所有查询才能回答这个问题。例如,假设您拆分为文档,然后又决定需要基于存储在一个索引中的字段进行过滤,然后按存储在另一个索引中的字段进行排序。这将是一个大问题!

因此,我对您的建议是,如果不确定前进方向,只需将所有内容放在一个索引中即可。您以后可以重新索引和重新构建。