ElasticSearch
安装elasticsearch
单实例安装
wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-5.5.2.tar.gz
tar -vxf elasticsearch-5.5.2.tar.gz
cd elasticsearch-5.5.2
sh ./bin/elasticsearch 启动（java version 1.8以上才行）
访问127.0.0.1:9200 （查看是否启动成功）
分布式安装
mkdir es_slave
cp -r elasticsearch-5.5.2 ./es_slave/es_slave1
vim config/elasticsearch.yml
cluster.name: wali
node.name: slave1
network.host:127.0.0.1
http.port: 8200
discovery.zen.ping.unicast.hosts: ["127.0.0.1"]
./bin/elasticsearch -d(服务后台启动)API
restfull api
api基本格式：http://<ip>:<port>/<索引>/<类型>/<文档id>
常用http动词 GET/PUT/POST/DELETE
创建非结构化索引（header插件创建索引）
五个分片和 一个复制分片。
结构化索引
创建第二个索引people。
通过连接创建http:127.0.0.1:9200/people(创建一个people索引的PUT请求)
请求体 {
"settings": {
"number_of_shards": 3,//三个主分片（如图中粗方块0,1,2）
"number_of_replicas": 1//每个主分片有一个复制分片。（细方框）
},
"mappings": {
"man": { //索引下类型（_type）为man的格式映射
"properties":{
"name":{
"type": "text"
},
"country": {
"type": "keyword"
},
"age": {
"type": "integer"
}
}
},
"women":{}//索引下类型（_type）为women的格式映射
}
}
索引信息如下
elastic集群的结构图如下
集群
集群由节点（node）组成。
集群健康
在Elasticsearch集群中可以监控统计很多信息，但是只有一个是最重要的：集群健康(cluster health)。集群健康有三种状态：green、yellow或red。GET /_cluster/health
颜色 | 意义 |
| 所有主要分片和复制分片都可用 |
| 所有主要分片可用，但不是所有复制分片都可用 |
| 不是所有的主要分片都可用 |
集群的状态
集群A
({
"cluster_name": "elasticsearch",//分片名称
"status": "green", <1>//集群健康状态
"timed_out": false,//是否超时。
"number_of_nodes": 3,//节点数量
"number_of_data_nodes": 3,//有数据的节点数。
"active_primary_shards": 2,//主分片数
"active_shards": 6,//活动的分片数
"relocating_shards": 0,//迁移的分片数
"initializing_shards": 0,//初始化的分片数
"unassigned_shards": 3<2>//没有使用的分片数。})
节点
cluster.name去设置集群名称。它们协同工作，分享数据和负载。当加入新的节点或者删除一个节点时，集群就会感知到并平衡数据。集群中一个节点会被选举为主节点(master)
我们杀掉的节点是一个主节点。一个集群必须要有一个主节点才能使其功能正常，所以集群做的第一件事就是各节点选举了一个新的主节点：Node 2。主分片1和2在我们杀掉Node 1时已经丢失，我们的索引在丢失主分片时不能正常工作。如果此时我们检查集群健康，我们将看到状态red：不是所有主分片都可用！幸运的是丢失的两个主分片的完整拷贝存在于其他节点上，所以新主节点做的第一件事是把这些在Node 2和Node 3上的复制分片升级为主分片，这时集群健康回到yellow状态。这个提升是瞬间完成的，就好像按了一下开关。为什么集群健康状态是yellow而不是green？我们有三个主分片，但是我们指定了每个主分片对应两个复制分片，当前却只有一个复制分片被分配，这就是集群状态无法达到green的原因，不过不用太担心这个：当我们杀掉Node 2，我们的程序依然可以在没有丢失数据的情况下继续运行，因为Node 3还有每个分片的拷贝。 如果我们重启
Node 1 ，集群将能够重新分配丢失的复制分片，集群状况与上一节的 图5：增加number_of_replicas到2 类似。如果
Node 1 依旧有旧分片的拷贝，它将会尝试再利用它们，它只会从主分片上复制在故障期间有数据变更的那一部分。
分片
一个分片(shard)是一个最小级别“工作单元(worker unit)”,它只是保存了索引中所有数据的一部分。
分片是Elasticsearch在集群中分发数据的关键。把分片想象成数据的容器。文档存储在分片中，然后分片分配到你集群中的节点上。当你的集群扩容或缩小，Elasticsearch将会自动在你的节点间迁移分片，以使集群保持平衡。
默认情况下，一个索引被分配5个主分片，一个复制分片。
复制分片
复制分片只是主分片的一个副本，它可以防止硬件故障导致的数据丢失，同时可以提供读请求，比如搜索或者从别的shard取回文档。
当索引创建完成的时候，主分片的数量就固定了，但是复制分片的数量可以随时调整。
让我们在集群中唯一一个空节点上创建一个叫做blogs的索引。默认情况下，一个索引被分配5个主分片，但是为了演示的目的，我们只分配3个主分片和一个复制分片（每个主分片都有一个复制分片）：
PUT /blogs
{
"settings" : {
"number_of_shards" : 3,
"number_of_replicas" : 1
}
}数据
文档
文档(document)这个术语有着特殊含义。它特指最顶层结构或者根对象(root object)序列化成的JSON数据（以唯一ID标识并存储于Elasticsearch中）。
一个文档不只有数据。它还包含了元数据(metadata)——关于文档的信息。三个必须的元数据节点是：
节点说明_index文档存储的地方_type文档代表的对象的类_id文档的唯一标识
_index
索引(index)类似于关系型数据库里的“数据库”——它是我们存储和索引关联数据的地方。
提示：
事实上，我们的数据被存储和索引在分片(shards)中，索引只是一个把一个或多个分片分组在一起的逻辑空间。然而，这只是一些内部细节——我们的程序完全不用关心分片。对于我们的程序而言，文档存储在索引(index)中。剩下的细节由Elasticsearch关心既可。
_type
在Elasticsearch中，我们使用相同 类型(type) 的文档表示相同的“事物”，因为他们的数据结构也是相同的。
_id
id仅仅是一个字符串，它与_index和_type组合时，就可以在Elasticsearch中唯一标识一个文档。当创建一个文档，你可以自定义_id，也可以让Elasticsearch帮你自动生成。
