什么是弹性搜索中的索引

好问题，答案比人们想象的要微妙得多。可以将索引用于多种不同目的。

关系索引

最简单、最熟悉的布局克隆了您对关系数据库的期望。你可以（非常粗略地）把索引想象成一个数据库。

• MySQL =>数据库 =>表 =>行/列
• ElasticSearch => Indices => Types =>具有属性的文档

一个 ElasticSearch 集群可以包含多个（数据库），而数据库又包含多个（表）。这些类型包含多个（行），每个文档包含（列）。IndicesTypesDocumentsProperties

因此，在您的汽车制造场景中，您可能有一个指数。在此索引中，您有三种不同的类型：SubaruFactory

• People
• Cars
• Spare_Parts

然后，每种类型都包含与该类型对应的文档（例如，斯巴鲁Imprezza文档位于该类型内部。此文档包含有关该特定汽车的所有详细信息）。Cars

搜索和查询采用以下格式：http://localhost:9200/[索引]/[类型]/[操作]

因此，要检索斯巴鲁文档，我可能会这样做：

  $ curl -XGET localhost:9200/SubaruFactory/Cars/SubaruImprezza

.

日志记录索引

现在，现实情况是，索引/类型比我们在 RDBM 中习惯的数据库/表抽象要灵活得多。它们可以被视为方便的数据组织机制，根据您设置数据的方式，具有额外的性能优势。

为了演示一种完全不同的方法，很多人使用 ElasticSearch 进行日志记录。标准格式是每天分配一个新索引。您的索引列表可能如下所示：

• 日志-2013-02-22
• 日志-2013-02-21
• 日志-2013-02-20

ElasticSearch允许您同时查询多个索引，因此这样做不是问题：

  $ curl -XGET localhost:9200/logs-2013-02-22,logs-2013-02-21/Errors/_search=q:"Error Message"

它同时搜索过去两天的日志。由于日志的性质，这种格式具有优势 - 大多数日志从不被查看，并且它们以线性时间流的形式组织。为每个日志创建索引更具逻辑性，并提供更好的搜索性能。

.

用户索引

另一种完全不同的方法是为每个用户创建一个索引。想象一下，你有一些社交网站，每个用户都有大量的随机数据。您可以为每个用户创建一个索引。您的结构可能如下所示：

• 扎克指数
  • 爱好类型
  • 好友类型
  • 图片类型
• 弗雷德指数
  • 爱好类型
  • 好友类型
  • 图片类型

请注意，此设置如何以传统的RDBM方式轻松完成（例如，“用户”索引，以爱好/朋友/图片为类型）。然后，所有用户将被扔进一个单一的巨型索引中。

相反，出于数据组织和性能原因，有时将数据分开是有意义的。在此方案中，我们假设每个用户都有大量的数据，并且我们希望它们分开。ElasticSearch可以让我们为每个用户创建一个索引。

@Zach的答案适用于 elasticsearch 5.X 及更低版本。由于 elasticsearch 6.X 已被弃用，并将在 7.X 中完全删除。引用 elasticsearch 文档：Type

最初，我们谈到“索引”类似于SQL数据库中的“数据库”，而“类型”等同于“表”。这是一个不好的类比，导致了不正确的假设。

进一步解释，在SQL中，来自两个不同表的具有相同名称的两列可以彼此独立。但是在弹性搜索索引中，这是不可能的，因为它们由相同的Lucene字段支持。因此，elasticsearch中的“索引”与SQL中的“数据库”并不完全相同。如果索引中有任何相同的字段，它们最终将具有字段类型的冲突。为避免这种情况，elasticsearch 文档建议按文档类型存储索引。

参考：删除映射类型