很好的问题，答案比人们期望的要细腻得多。您可以将索引用于几种不同的目的。

关系指标

最简单，最熟悉的布局将克隆您从关系数据库中获得的期望。您可以（非常粗略地）想到像数据库这样的索引。

• MySQL =>数据库=>表=>行/列
• ElasticSearch =>索引=>类型=>具有属性的文档

ElasticSearch集群可以包含多个Indices（数据库），而数据库又包含多个Types（表）。这些类型包含多个Documents（行），每个文档都有Properties（列）。

因此，在您的汽车制造方案中，您可能会有一个SubaruFactory索引。在此索引内，您有三种不同的类型：

• People
• Cars
• Spare_Parts

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

搜索和查询采用以下格式：http：// localhost：9200 / [index] / [type] /
[operation]

因此，要检索Subaru文档，我可以这样做：

  $ 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可以让我们为每个用户创建索引没有问题。