Question

我正在研究一个处理列表的项目（例如：Craiglist，Ebay，Trulia等）。

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

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

可以搜索

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

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

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

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

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

对最佳做法有何建议？

谢谢：）

Answer 1

根据我在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个分片，但是越低于此限制，您可以使其越好。通常，这将有助于群集保持良好的健康状态。

Answer 2

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

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

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

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

遵循该模式的一种方法：

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

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

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

Answer 3

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

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

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

3 个答案: