索引：

在Elasticsearch中存储数据的行为就叫做索引(indexing)，不过在索引之前，我们需要明确数据应该存储在哪里。

在Elasticsearch中，文档归属于一种类型(type),而这些类型存在于索引(index)中，我们可以画一些简单的对比图来类比传统关系型数据库：

Relational DB -> Databases -> Tables -> Rows -> Columns

Elasticsearch -> Indices   -> Types  -> Documents -> Fields

Elasticsearch集群可以包含多个索引(indices)（数据库），每一个索引可以包含多个类型(types)（表），每一个类型包含多个文档(documents)（行），然后每个文档包含多个字段(Fields)（列）。

「索引」含义的区分：

你可能已经注意到索引(index)这个词在Elasticsearch中有着不同的含义，所以有必要在此做一下区分:

● 索引（名词） 如上文所述，一个索引(index)就像是传统关系数据库中的数据库，它是相关文档存储的地方，index的复数是indices 或indexes。

● 索引（动词） 「索引一个文档」表示把一个文档存储到索引（名词）里，以便它可以被检索或者查询。这很像SQL中的INSERT关键字，差别是，如果文档已经存在，新的文档将覆盖旧的文档。

● 倒排索引 传统数据库为特定列增加一个索引，例如B-Tree索引来加速检索。Elasticsearch和Lucene使用一种叫做倒排索引(inverted index)的数据结构来达到相同目的。

默认情况下，文档中的所有字段都会被索引（拥有一个倒排索引），只有这样他们才是可被搜索的。

---

分片：

为了将数据添加到Elasticsearch，我们需要索引(index)——一个存储关联数据的地方。实际上，索引只是一个用来指向一个或多个分片(shards)的“逻辑命名空间(logical namespace)”.

一个分片(shard)是一个最小级别“工作单元(worker unit)”,它只是保存了索引中所有数据的一部分。在接下来的《深入分片》一章，我们将详细说明分片的工作原理，但是现在我们只要知道分片就是一个Lucene实例，并且它本身就是一个完整的搜索引擎。我们的文档存储在分片中，并且在分片中被索引，但是我们的应用程序不会直接与它们通信，取而代之的是，直接与索引通信。

分片是Elasticsearch在集群中分发数据的关键。把分片想象成数据的容器。文档存储在分片中，然后分片分配到你集群中的节点上。当你的集群扩容或缩小，Elasticsearch将会自动在你的节点间迁移分片，以使集群保持平衡。

分片可以是主分片(primary shard)或者是复制分片(replica shard)。你索引中的每个文档属于一个单独的主分片，所以主分片的数量决定了索引最多能存储多少数据。

理论上主分片能存储的数据大小是没有限制的，限制取决于你实际的使用情况。分片的最大容量完全取决于你的使用状况：硬件存储的大小、文档的大小和复杂度、如何索引和查询你的文档，以及你期望的响应时间。

复制分片只是主分片的一个副本，它可以防止硬件故障导致的数据丢失，同时可以提供读请求，比如搜索或者从别的shard取回文档。

当索引创建完成的时候，主分片的数量就固定了，但是复制分片的数量可以随时调整。

---

集群健康：

在Elasticsearch集群中可以监控统计很多信息，但是只有一个是最重要的：集群健康(cluster health)。集群健康有三种状态：green、yellow或red。

GET /_cluster/health

在一个没有索引的空集群中运行如上查询，将返回这些信息：

{

    "cluster_name":          "elasticsearch",

    "status":                "green", <1>

    "timed_out":             false,

    "number_of_nodes":       1,

    "number_of_data_nodes":  1,

    "active_primary_shards": 0,

    "active_shards":         0,

    "relocating_shards":     0,

    "initializing_shards":   0,

    "unassigned_shards":     0

}

status 是我们最感兴趣的字段

status字段提供一个综合的指标来表示集群的的服务状况。三种颜色各自的含义：

green所有主要分片和复制分片都可用

yellow所有主要分片可用，但不是所有复制分片都可用

red不是所有的主要分片都可用

所有索引：

GET /_cat/indices?v

curl http://192.168.31.140:9200/_cat/indices?v

health status index                           uuid                   pri rep docs.count docs.deleted store.size pri.store.size

green  open   webserver-access-log-2017.11.01 KXbLvV2iT7a7SDTzwmuMpw   5   1      62469            0     89.1mb         44.5mb

green  open   nginx-access-log-2017.10.31     y0RpxeGVQZ2tRpl1hfDFRw   5   1      12619            0     19.5mb          9.7mb

green  open   .monitoring-data-2              htaFQHKtRNaJOpGXxIEs3Q   1   1          3            0     14.3kb          7.1kb

green  open   .monitoring-kibana-2-2017.11.01 lK8587HOS7apx1fsKG8Uow   1   1        654            0    387.6kb        193.8kb

green  open   nginx-access-log-2017.11.02     JEAqXh9bTiGDjOczhVPhOA   5   1      18863            0     28.6mb         14.3mb

green  open   .monitoring-es-2-2017.10.31     5oE3xVVPTTKYaflBnNLyUg   1   1        423           78    762.7kb        381.3kb

green  open   .security                       nu8qiah9S0aw6QR4VXoRcA   1   1          2            0       11kb          5.5kb

green  open   nginx-access-log-2017.11.01     b8lzWMKWQOuvGAhZOe-Tqw   5   1      62582            0     88.5mb         44.2mb

green  open   .monitoring-es-2-2017.11.01     cZnvACgzSeicB-s_LCsGaQ   1   1       8768           51        8mb            4mb

green  open   .kibana                         LRc0dr8MRN6jLhciJDaG2w   1   1          3            0     44.6kb         22.3kb

green  open   webserver-access-log-2017.11.02 3EkGPnCGTmqegXehcqYYdA   5   1      18863            0     28.4mb         14.2mb

green  open   webserver-access-log-2017.10.31 kh3cDN3QQCOVz8WrvO6lsQ   5   1      12657            0       20mb           10mb