弹性搜索，多个索引与不同数据集的一个索引和类型？答案

【问题标题】：Elastic search, multiple indexes vs one index and types for different data sets?弹性搜索，多个索引与不同数据集的一个索引和类型？
【发布时间】：2013-01-06 02:28:35
【问题描述】：

我有一个使用 MVC 模式开发的应用程序，现在我想索引它的多个模型，这意味着每个模型都有不同的数据结构。

最好使用多个索引，每个模型一个索引，还是每个模型在同一索引中都有一个类型？我认为这两种方式都需要不同的搜索查询。我刚开始做这个。
如果数据集很小或很大，这两个概念在性能方面是否存在差异？

如果有人可以为此目的推荐一些好的样本数据，我会自己测试第二个问题。

【问题讨论】：

标签： database search elasticsearch

【解决方案1】：

这两种方法都有不同的含义。

假设您使用 Elasticsearch 的默认设置，每个模型有 1 个索引将显着增加您的分片数量，因为 1 个索引将使用 5 个分片，5 个数据模型将使用 25 个分片；虽然 1 个索引中有 5 个对象类型，但仍将使用 5 个分片。

将每个数据模型作为索引的含义：

高效快速地在索引中搜索，因为每个分片中的数据量应该更小，因为它分布到不同的索引。
从 2 个或更多索引中搜索数据模型的组合会产生开销，因为查询必须跨索引发送到更多分片、编译并发送回用户。
如果您的数据集很小，则不建议这样做，因为创建每个额外的分片都会产生更多的存储空间，并且性能提升是微不足道的。
如果您的数据集很大并且您的查询需要很长时间来处理，建议使用，因为专用分片存储您的特定数据，并且 Elasticsearch 更容易处理。

将每个数据模型作为索引中的对象类型的含义：

更多数据将存储在索引的 5 个分片中，这意味着当您跨不同数据模型进行查询时开销问题较少，但您的分片大小会大得多。
由于要过滤的文档更多，因此 Elasticsearch 需要更长的时间来搜索分片中的更多数据。
如果您知道自己正在处理 1 TB 的数据，并且没有将数据分布在 Elasticsearch 映射中的不同索引或多个分片中，则不建议这样做。
推荐用于小型数据集，因为每个分片都会占用硬件空间，因此不会浪费存储空间来获得边际性能提升。

如果您要问什么是过多数据与小数据？通常，它取决于处理器速度和硬件的 RAM、您在 Elasticsearch 映射中每个变量中存储的数据量以及您的查询要求；在您的查询中使用许多方面会显着减慢您的响应时间。对此没有直接的答案，您必须根据自己的需要进行基准测试。

【讨论】：

如果没有来自elasticsearch.org/guide/en/elasticsearch/guide/current/…的信息，这个答案是不完整的
为了补充出色的答案，我引用 ES 5.2 doc 来解释为什么不建议维护大量分片：“By default elasticsearch rejects search requests that would query more than 1000 shards. The reason is that such large numbers of shards make the job of the coordinating node very CPU and memory intensive. It is usually a better idea to organize data in such a way that there are fewer larger shards. In case you would like to bypass this limit, which is discouraged, you can update the action.search.shard_count.limit cluster setting to a greater value.”

【解决方案2】：

虽然 Jonathan 的回答在当时是正确的，但世界已经在发展，现在看来 ElasticSearch 背后的人有一个长期计划放弃对多种类型的支持：

Where we want to get to: We want to remove the concept of types from Elasticsearch, while still supporting parent/child.

因此，对于新项目，每个索引仅使用一种类型将使最终升级到 ElasticSearch 6.x 更加容易。

【讨论】：

【解决方案3】：

乔纳森的回答很棒。我只想补充几点需要考虑：

可以根据您选择的解决方案自定义分片数量。您可能有一个包含 15 个主分片的索引，或者将其拆分为 5 个分片的 3 个索引 - 性能观点不会改变（假设数据平均分布）
考虑数据使用情况。 IE。如果您使用 kibana 进行可视化，则更容易包含/排除特定索引，但必须在仪表板中过滤类型
数据保留：对于应用程序日志/指标数据，如果您需要不同的保留期限，请使用不同的索引

【讨论】：

保留期是什么意思？你指的是时间活场吗？这是基于每个文档设置的。
不，这里的保留期是指文档/索引保留 - 存储这些数据的时间。基于数据质量、大小、重要性——我用来指定不同的保留策略。有些数据/索引在 7 天后被删除，有些在 6w 后被删除，有些在 10 年后被删除......

【解决方案4】：

以上两个答案都很棒！

我在索引中添加了几种类型的示例。假设您正在开发一个应用程序来搜索图书馆中的书籍。有几个问题要问图书馆所有者，

问题：

您打算存储多少本书？
你打算在图书馆里存放什么样的书？
你打算如何搜索书籍？

答案：

我计划存储 5 万到 7 万本书（大约）
我将拥有 15 k -20 k 技术相关书籍（计算机科学、机械工程、化学工程等），15 k 历史书籍，10 k 医学书籍。 10k 种语言相关书籍（英语、西班牙语等）
按作者名字、作者姓氏、出版年份、出版商名称搜索。（这让您了解应该在索引中存储哪些信息）

根据以上答案，我们可以说索引中的架构应该看起来像这样。

//这不是确切的映射，只是为了示例

            "yearOfPublish":{
                "type": "integer"
            },
            "author":{
                "type": "object",
                "properties": {
                    "firstName":{
                        "type": "string"
                    },
                    "lastName":{
                        "type": "string"
                    }
                }
            },
            "publisherName":{
                "type": "string"
            }
        }

为了实现上述目的，我们可以创建一个名为 Books 的索引，并且可以有多种类型。

索引：书籍

类型：科学、艺术

（或者，如果您有更多书籍，您可以创建多种类型，例如技术、医学、历史、语言）

这里要注意的重要一点是架构相似，但数据不相同。另一个重要的事情是您存储的总数据。

希望以上内容有助于何时在索引中使用不同类型，如果您有不同的架构，您应该考虑不同的索引。少数据的小索引。大数据的大索引:-)

【讨论】：