Elasticsearch入门

Elasticsearch 是一个实时的分布式搜索和分析引擎。它可以帮助你用前所未有的速度去处理大规模数据。Lucene 都毫无疑问是当今最先进、性能最高和功能最全的搜索引擎框架。但是 Lucene 只是一个框架，要充分使用它的功能，你需要使用 JAVA 作为开发语言，并且在你的程序中集成 Lucene。更糟的是，你需要深入了解相关知识才能明白它是如何运行的，Lucene 确实非常复杂。
Elasticsearch 也是使用 Java 编写的，并且采用了 Lucene 来实现索引与搜索的功能。而且，在你使用它做全文搜索时，只需要使用简单流畅的 RESTful API 即可，并不需要了解 Lucene背后复杂的的运行原理。当然 Elasticsearch 还有很多地方超越了 Lucene，它不仅可以实现全文搜索功能，还可以完成以下工作:
分布式实时文档存储，并将每一个字段都编入索引，使其可以被搜索。
分布式实时分析与搜索引擎。
可以扩展到上百台服务器，处理PB级别的结构化或非结构化数据。
这么多的功能被集成到一台服务器上，你可以轻松地通过客户端或者任何你喜欢的程序语言
与 Elasticsearch 的 RESTful API 进行通信。它的数据存储如下图所示

在 Elasticsearch 中，文档属于一种 类型(type)，各种各样的类型存在于一个 索引 中。你也可
以通过类比传统的关系数据库得到一些大致的相似之处：

关系数据库 ⇒ 数据库 ⇒ 表 ⇒ 行 ⇒ 列(Columns)
Elasticsearch ⇒ 索引 ⇒ 类型 ⇒ 文档 ⇒ 字段(Fields)

一个 Elasticsearch 集群可以包含多个 索引（数据库），也就是说其中包含了很多 类型（表）。这些类型中包含了很多的 文档（行），然后每个文档中又包含了很多的 字段（列）。
当搭建完一个基本环境的时候可以通过API获取集群的状态。
10.39.0.45:9200/_cluster/health
{
“cluster_name”: “elasticsearch”,
“status”: “yellow”,
“timed_out”: false,
“number_of_nodes”: 1,
“number_of_data_nodes”: 1,
“active_primary_shards”: 5,
“active_shards”: 5,
“relocating_shards”: 0,
“initializing_shards”: 0,
“unassigned_shards”: 5,
“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
}
可以看到集群的状态有三种：
green 所有主分片和从分片都可用
yellow 所有主分片可用，但存在不可用的从分片
red 存在不可用的主要分片
那先解释一下分片，分片分为 主分片(primary shard) 以及 从分片(replica shard) 两种。在你的索引中，每一个文档都属于一个主分片，所以具体有多少主分片取决于你的索引能存储多少数据。从分片只是主分片的一个副本，它用于提供数据的冗余副本，在硬件故障时提供数据保护，同时服务于搜索和检索这种只读请求。
可以通过API去输入输出数据的，下面举几个例子

PUT /megacorp/employee/1
{
"first_name" : "John",
"last_name" : "Smith",
"age" : 25,
"about" : "I love to go rock climbing",
"interests": [ "sports", "music" ]
}

megacorp是索引、employee是文档，1是员工的ID。
当然可以通过GET获取

GET /megacorp/employee/1

还支持一些简单搜索

GET /megacorp/employee/_search?q=last_name:Smith

还有一些高级的搜索

GET /megacorp/employee/_search
{
    "query" : {
        "filtered" : {
            "filter" : {
                "range" : {
                    "age" : { "gt" : 30 } <1>
                    }
            },
            "query" : {
                "match" : {
                "last_name" : "Smith" <2>
                }
            }
        }
    }
}

1. 这一部分的语句是 range filter ，它可以查询所有超过30岁的数据 – gt 代表 greater than （大于）
2. 这一部分我们前一个操作的 match query 是一样的

它的节点发现的功能还是挺好的，
Zen 发现机制是ElasticSearch中默认的用来发现新节点的功能模块，而且集群启动后默认生效。Zen发现机制默认配置是用多播来寻找其它的节点。对于用户而言，这是一极其省事的解决方案：只需启动新的ElasticSearch节点即可，如果各个模块工作正常，该节点就会自动添加到与节点中集群名字(cluster.name)一样的集群，同时其它的节点都能感知到新节点的加入。如果节点添加不进去，你就应该检查节点的publish_host属性或者host属性的设置，来确保ElasticSearch在监听合适的网络端口。

有时由于某些原因，多播无法使用或者由于前面提到的一些原因，你不想使用它。在比较大的集群中，多播发现机制可能会产生太多不必要的流量开销，这是不使用多播的一个充分理由。在这种情况下，Zen发现机制引入了第二种发现节点的方法：单播模式。
多播

前面已经提到，这是默认的网络传输模式。当节点并非集群的一部分时(比如节点只是刚刚启动或者重启 )，它会发送一个多播的ping请求到网段中，该请求只是用来通知所有能连接到节点和集群它已经准备好加入到集群中。关于多播发送，Zen发现模块暴露出如下的设置项：

discovery.zen.ping.multicast.address(默认是所有的网络接口):属性值是接口的地址或者名称。
discovery.zen.ping.multicast.port(默认是54328):端口用于网络通信。
discovery.zen.ping.multicast.group(默认是:224.2.2.4):代表多播通信的消息接收地。
discovery.zen.ping.multicast.buffer_size(默认是:2048byte):
discovery.zen.ping.multicast.ttl(默认是3):它代表多播信息的生存时间。只要数据包通过的路由，TTL值就废弃了。通过该参数可以限制信息接收的区域。注意路由器可以指定一个类似于TTL值的阈值来确保TTL值并非唯一可以限制数据包可以跳过路由器的因素。
discovery.zen.ping.multicast.enabled(默认值为true):设置该属性值的值为false就关闭了多播传输。如果计划使用单播传输，就应该关闭多播传输。
单播

当像前面描述的那样关闭多播，就可以安全地使用单播。当节点不是集群的一部分时(比如节点重启，启动或者由于某些错误从集群中断开)，节点会发送一个ping请求到事先设置好的地址中，来通知集群它已经准备好加入到集群中了。相关的配置项很简单，如下：

discovery.zen.ping.unicats.hosts:该配置项代表集群中初始结点的主机列表。每个主机由名字(或者IP地址)加端口或者端口范围组成。比如，该属性值可以是如下的写法：[“master1”,”master2:8181”, “master3[80000-81000]”] ，因此用于单播节点发现的主机列表基本上不必是集群中的所有节点，因为一个节点一旦连接到集群中的一个节点，这个连接信息就会发送集群中其它所有的节点。
discovery.zen.ping.unicats.concurrent_connects(默认值: 10):该属性指定节点发现模块能够开启的单播最大并发连接数

Zen发现机制的故障检测

ElasticSearch运行时会启动两个探测进程。一个进程用于从主节点向集群中其它节点发送ping请求来检测节点是否正常可用。另一个进程的工作反过来了，其它的节点向主节点发送ping请求来验证主节点是否正常且忠于职守。但是，如果我们的网络很慢或者节点分布在不同的主机，默认的配置可能显得力不从心。因此，ElasticSearch的节点发现模块开放出了如下的属性：

discovery.zen.fd.ping_interval:该属性的默认值是1s,指定了本节点隔多久向目标结点发送一次ping请求。
discovery.zen.fd.ping_timeout:该属性的默认值是30s,指定了节点等待ping请求的回复时间。如果节点百分百可用或者网络比较慢，可能就需要增加该属性值。
discovery.zen.fd.ping_retries:该属性值默认为3，指定了在目标节点被认定不可用之前ping请求重试的次数。用户可以在网络丢包比较严重的网络状况下增加该属性值(或者修复网络状况)。