此前某些软件的“弱点”
学习Elasticsearch集群原理之前，先了解它能解决什么问题、之前的某些软件为何不能解决这些问题。
Q1： 电商平台出售的商品，如笔记本，关于规格这一栏，不同型号，配置不同。用关系型数据库，无法把所有笔记本的配置信息都存入同一张表中。即，关系型数据库没法存非结构化的数据。
Q2： 可以用NoSQL存配置数据，也可以解决数据安全性（冗余备份），但，当数据暴增时，是否能快速的水平扩展？能否保证暴增查询时间的稳定。
Elasticsearch的优点
Elasticsearch是：
- 一个分布式的实时文档存储，每个字段 可以被索引与搜索
- 一个分布式实时分析搜索引擎
- 能胜任上百个服务节点的扩展，并支持 PB 级别的结构化或者非结构化数据
Elasticsearch 是面向文档的，意味着它存储整个对象或文档。Elasticsearch 不仅存储文档，而且索引每个文
档的内容，使之可以被检索。
ElasticSearch 的主旨是随时可用和按需扩容，扩容分为纵向扩容、水平扩容。
- 纵向扩容： 增加单服务器的CPU核数、内存大小，以及硬盘升级SSD。
- 横向扩容： 增加服务器个数，如，2台变4台，4台变8台。
ElasticSearch 真正的扩容能力是来自于横向扩容——为集群添加更多的节点，并且将负载压力和稳定性分散到这些节点中。
对于大多数的数据库而言，通常需要对应用程序进行非常大的改动，才能利用上横向扩容的新增资源。 与之相反的是，ElastiSearch天生就是分布式的 ，它知道如何通过管理多节点来提高扩容性和可用性。
Elasticesearch的相关述语
一个 Elasticsearch 集群可以包含多个索引 ，相应的每个索引可以包含多个类型 。 这些不同的类型存储着
多个文档 ，每个文档又有多个属性（类型） 。做个类比，如下图：
索引
存储数据到 Elasticsearch 的行为叫做索引 ，但在索引一个文档之前，需要确定将文档存储在哪里。
- 索引（名词）
索引实际上是指向一个或者多个物理分片的逻辑命名空间 。类似于关系型数据库中的一个数据库。 - 索引（动词）
索引一个文档 就是存储一个文档到一个 索引 （名词）中以便被检索和查询。类似于 SQL 语句中的 INSERT。
类型
多组非结构化数据的集合，即多个文档的集合。如，电商平台上所有笔记本：{配置数据、价格、款式型号等}是一个类型。某单位所有雇员：{名字、年龄、有哪些兴趣爱好、是否有人生格言且有是哪些}。
文档
一组非结构化数据的集合，如某种型号笔记本的端口有3种信息：{显示端口、音频端口、USB3.0}，另外一款笔记本的文档中的端口信息只有2种：{显示端口、音频端口}。这些文档数据以分片的形式存储在索引当中。
节点
一个运行中的 ElasticSearch 实例称为一个节点，而集群是由一个或者多个拥有相同 cluster.name 配置的节点组成， 它们共同承担数据和负载的压力。当有节点加入集群中或者从集群中移除节点时，集群将会重新平均分布所有的数据。
当一个节点被选举成为主节点时， 它将负责管理：集群范围内的所有变更，例如增加、删除索引，或者增加、删除节点等。而主节点并不需要涉及到文档级别的变更和搜索等操作，所以当集群只拥有一个主节点的情况下，即使流量的增加它也不会成为瓶颈。 当主节点宕机后，副节点中的其中一个会成为主节点。
作为用户，我们可以将请求发送到集群中的任何节点 ，包括主节点。 每个节点都知道任意文档所处的位置，并且能够将我们的请求转发到存储我们所需文档的节点。 无论我们将请求发送到哪个节点，它都能负责从各个包含我们所需文档的节点收集回数据，并将最终结果返回给客户端。
分片
一个分片是一个底层的工作单元，它仅保存了全部数据中的一部分。
ElasticSearch是利用分片将数据分发到集群内各处的。分片是数据的容器，文档保存在分片内，分片又被分配到集群内的各个节点里。 当你的集群规模扩大或者缩小时， ElasticSearch会自动的在各节点中迁移分片，使得数据仍然均匀分布在集群里。
一个分片可以是主分片或者副本分片。 索引内任意一个文档都归属于一个主分片，所以主分片的数目决定着索引能够保存的最大数据量。
一个副本分片只是一个主分片的拷贝。副本分片作为硬件故障时保护数据不丢失的冗余备份，并为搜索
和返回文档等读操作提供服务。
集群健康
集群健康在 status 字段中展示为 green 、 yellow 或者 red 。
curl -X GET "localhost:9200/_cluster/health?pretty"
{
"cluster_name": "elasticsearch",
"status": "green",
"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
}
- green: 所有的主分片和副本分片都正常运行。
- yellow: 所有的主分片都正常运行，但不是所有的副本分片都正常运行。
- red: 有主分片没能正常运行。
故障迁移
启动单节点，设置主分片为3，副本为1。此时的健康状态为yellow，即3个副分片没有被分配到其他节点。
[root@i-ancken27 config]# pwd
/elasticsearch/elasticsearch_node/config
[root@i-ancken27 config]# vim elasticsearch.yml
index.number_of_shards: 3
index.number_of_replicas: 1
{
"cluster_name": "elasticsearch",
"status": "yellow", # 集群 status 值为 yellow
"timed_out": false,
"number_of_nodes": 1,
"number_of_data_nodes": 1,
"active_primary_shards": 3,
"active_shards": 3,
"relocating_shards": 0,
"initializing_shards": 0,
"unassigned_shards": 3, # 没有被分配到任何节点的副本数。
"delayed_unassigned_shards": 0,
"number_of_pending_tasks": 0,
"number_of_in_flight_fetch": 0,
"task_max_waiting_in_queue_millis": 0,
"active_shards_percent_as_number": 50
}
当第二个节点加入到集群后，3个副本分片将会分配到这个节点上——每个主分片对应一个副本分片。 这意味着当集群内任何一个节点出现问题时，我们的数据都完好无损。P0-2是主分配，R0-2是备份分片。
当启动了第三个节点，我们的集群将会看起来如图，拥有三个节点的集群，ES为了分散负载而对分片进行重新分配所示。
应对故障
当主节点宕机后，slave-node2变成主节点，R0、R1复制到slave-node2上变成P0、P1；R2被复制到新的主节点，变成P2
简单的查询数据
- 搜索所有雇员：其中， megacorp是索引名称；employee是类型名称。
curl -X GET "localhost:9200/megacorp/employee/_search?pretty"
- 搜索姓氏为'Smith'的雇员：
curl -X GET "localhost:9200/megacorp/employee/_search?pretty" -H 'Content-Type: application/json' -d'
{
"query" : {
"match" : {
"last_name" : "Smith"
}
}
}
'
- 短语搜索
curl -X GET "localhost:9200/megacorp/employee/_search?pretty" -H 'Content-Type: application/json' -d'
{
"query" : {
"match" : {
"about" : "rock climbing"
}
}
}
'