我正在研究一个处理列表的项目(例如:Craiglist,Ebay,Trulia等)。
信息的基本单位是“列表”,如下所示:
{
"id": 1,
"title": "Awesome apartment!",
"price": 1000000,
// other stuff
}
可以搜索一些字段(例如价格,位置等),其他字段仅用于在应用程序上显示(例如标题,包含大量HTML的描述等)。
我的问题是:我应该将所有数据存储在一个文档中,还是将其拆分为两个文档(一个用于搜索,例如“ ListingSearchIndex”,一个用于显示,例如“ ListingIndex”)。
我还必须对文档进行一些相当大的汇总。
我想的问题是,在较小的文档中进行搜索,然后再执行另一个调用以通过id提取结果比在整个文档中进行搜索会更快吗?
主要因素显然是速度,但是如果我分割文档,那么维护也将是一个因素。
对最佳做法有何建议?
谢谢:)
答案 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)
我认为您必须事先知道所有查询才能回答这个问题。例如,假设您拆分为文档,然后又决定需要基于存储在一个索引中的字段进行过滤,然后按存储在另一个索引中的字段进行排序。这将是一个大问题!
因此,我对您的建议是,如果不确定前进方向,只需将所有内容放在一个索引中即可。您以后可以重新索引和重新构建。