Elasticstarch 相关
索引：
在Elasticsearch中存储数据的行为就叫做索引(indexing)，不过在索引之前，我们需要明确数据应该存储在哪里。
在Elasticsearch中，文档归属于一种类型(type),而这些类型存在于索引(index)中，我们可以画一些简单的对比图来类比传统关系型数据库：
Relational DB -> Databases -> Tables -> Rows -> Columns
Elasticsearch -> Indices -> Types -> Documents -> Fields
Elasticsearch集群可以包含多个索引(indices)（数据库），每一个索引可以包含多个类型(types)（表），每一个类型包含多个文档(documents)（行），然后每个文档包含多个字段(Fields)（列）。
-（1）关系型数据库中的数据库（DataBase），等价于ES中的索引（Index）
-（2）一个数据库下面有N张表（Table），等价于1个索引Index下面有N多类型（Type），
-（3）一个数据库表（Table）下的数据由多行（ROW）多列（column，属性）组成，等价于1个Type由多个文档（Document）和多Field组成。
-（4）在一个关系型数据库里面，schema定义了表、每个表的字段，还有表和字段之间的关系。 与之对应的，在ES中：Mapping定义索引下的Type的字段处理规则，即索引如何建立、索引类型、是否保存原始索引JSON文档、是否压缩原始JSON文档、是否需要分词处理、如何进行分词处理等。
-（5）在数据库中的增insert、删delete、改update、查search操作等价于ES中的增PUT/POST、删Delete、改_update、查GET.
「索引」含义的区分：
你可能已经注意到索引(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
