Elasticsearch简介
Relational DB -> Databases -> Tables -> Rows -> Columns
Elasticsearch -> Indices -> Types -> Documents -> Fields
Elasticsearch集群可以包含多个索引(indices)（数据库），每一个索引可以包含多个类型(types)（表），每一个类型包含多个文档(documents)（行），然后每个文档包含多个字段(Fields)（列）。
「索引」含义的区分
索引（名词） 如上文所述，一个索引(index)就像是传统关系数据库中的数据库，它是相关文档存储的地方。
索引（动词）「索引一个文档」表示把一个文档存储到索引（名词）里，以便它可以被检索或者查询。这很像SQL中的 INSERT 关键字，差别是，如果文档已经存在，新的文档将覆盖旧的文档。
倒排索引 传统数据库为特定列增加一个索引，例如B-Tree索引来加速检索。Elasticsearch和Lucene使用一种叫做倒排索引(inverted index)的数据结构来达到相同目的。
分布式的特性
Elasticsearch致力于隐藏分布式系统的复杂性。以下这些操作都是在底层自动完成的：
将你的文档分区到不同的容器或者分片(shards)中，它们可以存在于一个或多个节点中。
将分片均匀的分配到各个节点，对索引和搜索做负载均衡。
冗余每一个分片，防止硬件故障造成的数据丢失。
将集群中任意一个节点上的请求路由到相应数据所在的节点。
无论是增加节点，还是移除节点，分片都可以做到无缝的扩展和迁移。
集群内部工作方式
一个节点(node)就是一个Elasticsearch实例，而一个集群(cluster)由一个或多个节点组成，它们具有相同的 cluster.name ，它们协同工作，分享数据和负载。当加入新的节点或者删除一个节点时，集群就会感知到并平衡数据。
集群中一个节点会被选举为主节点(master),它将临时管理集群级别的一些变更，例如新建或删除索引、增加或移除节点等。主节点不参与文档级别的变更或搜索，这意味着在流量增长的时候，该主节点不会成为集群的瓶颈。任何节点都可以成为主节点。我们例子中的集群只有一个节点，所以它会充当主节点的角色。
做为用户，我们能够与集群中的任何节点通信，包括主节点。每一个节点都知道文档存在于哪个节点上，它们可以转发请求到相应的节点上。我们访问的节点负责收集各节点返回的数据，最后一起返回给客户端。这一切都由Elasticsearch处理。
集群健康
在Elasticsearch集群中可以监控统计很多信息，但是只有一个是最重要的：集群健康(cluster health)。集群健康有三种状态： green 、 yellow 或 red 。
查看健康状态指令：GET /_cluster/health
在一个没有索引的空集群中运行如上查询，将回这些信息：
分片(primary shard)和复制分片(replica shard)
为了将数据添加到Elasticsearch，我们需要索引(index)——一个存储关联数据的地方。实际上，索引只是一个用来指向一个或多个分片(shards)的“逻辑命名空间(logical namespace)”.分片是Elasticsearch在集群中分发数据的关键。把分片想象成数据的容器。文档存储在分片中，然后分片分配到你集群中的节点上。当你的集群扩容或缩小，Elasticsearch将会自动在你的节点间迁移分片，以使集群保持平衡。
分片可以是主分片(primary shard)或者是复制分片(replica shard)。你索引中的每个文档属于一个单独的主分片，复制分片只是主分片的一个副本，它可以防止硬件故障导致的数据丢失，同时可以提供读请求。当索引创建完成的时候，主分片的数量就固定了，但是复制分片的数量可以随时调整。
在单一节点上运行意味着有单点故障的风险——没有数据备份。幸运的是，要防止单点故障，我们唯一需要做的就是启动另一个节点。
如果我们启动第三个节点，我们的集群会自我感知，这时便成为了三节点集群
文档元数据
索引文档
检索文档
格式：get /index/type/id?pretty //pretty会美化json输出
检索文档一部分
格式：get /index/type/id?_source=field1,field2...
只得到_source字段
格式：get /index/type/id?_source
更新文档
格式：put /index/type/id{ field1:value1,field2:value2 }
更新成功后，version字段+1，create字段为false。在内部，Elasticsearch已经标记旧文档为删除并添加了一个完整的新文档。在有更新冲突的情况下，可以通过 retry_on_conflict 参数设置重试次数
创建文档
格式：post /index/type/{ field1:value1,field2:value2 } //post方法保证文档是新加入的
如果想使用自定义的 _id ，我们必须告诉Elasticsearch应该在 _index 、 _type 、 _id 三者都不同时才接受请求。
删除文档
格式：delete /index/type/id
如果文档被找到，Elasticsearch将返回 200 OK 状态码和以下响应体。如果文档未找到，我们将得到一个 404 Not Found 状态码。尽管文档不存在—— "found" 的值是 false —— _version 依旧增加了。这是内部记录的一部分，它确保在多节点间不同操作可以有正确的顺序。
乐观并发控制
格式：PUT /index/type/id?version=1
所有更新和删除文档的请求都接受 version 参数，它可以允许在你的代码中增加乐观锁控制。
