Elasticsearch 学习笔记

最新推荐文章于 2024-06-17 16:09:14 发布

sdulibh

最新推荐文章于 2024-06-17 16:09:14 发布

阅读量2k

点赞数

分类专栏：云计算文章标签：实时搜索

云计算专栏收录该内容

113 篇文章 13 订阅

订阅专栏

最近在参与一个基于Elasticsearch作为底层数据框架提供大数据量(亿级)的实时统计查询的方案设计工作，花了些时间学习Elasticsearch的基础理论知识，整理了一下，希望能对Elasticsearch感兴趣/想了解的同学有所帮助。同时也希望有发现内容不正确或者有疑问的地方，望指明，一起探讨，学习，进步。

介绍

Elasticsearch 是一个分布式可扩展的实时搜索和分析引擎.

Elasticsearch 是一个建立在全文搜索引擎 Apache Lucene(TM) 基础上的搜索引擎. 当然 Elasticsearch 并不仅仅是 Lucene 那么简单，它不仅包括了全文搜索功能，还可以进行以下工作:

分布式实时文件存储，并将每一个字段都编入索引，使其可以被搜索。
实时分析的分布式搜索引擎。
可以扩展到上百台服务器，处理PB级别的结构化或非结构化数据。

基本概念

先说Elasticsearch的文件存储，Elasticsearch是面向文档型数据库，一条数据在这里就是一个文档，用JSON作为文档序列化的格式，比如下面这条用户数据：

{
    "name" :     "John",
    "sex" :      "Male",
    "age" :      25,
    "birthDate": "1990/05/01",
    "about" :    "I love to go rock climbing",
    "interests": [ "sports", "music" ]
}

用Mysql这样的数据库存储就会容易想到建立一张User表，有balabala的字段等，在Elasticsearch里这就是一个文档，当然这个文档会属于一个User的类型，各种各样的类型存在于一个索引当中。这里有一份简易的将Elasticsearch和关系型数据术语对照表:

关系数据库 ⇒ 数据库 ⇒ 表 ⇒ 行 ⇒ 列(Columns)

Elasticsearch ⇒ 索引 ⇒ 类型 ⇒ 文档 ⇒ 字段(Fields)

一个 Elasticsearch 集群可以包含多个索引(数据库)，也就是说其中包含了很多类型(表)。这些类型中包含了很多的文档(行)，然后每个文档中又包含了很多的字段(列)。

Elasticsearch的交互，可以使用Java API，也可以直接使用HTTP的Restful API方式，比如我们打算插入一条记录，可以简单发送一个HTTP的请求：

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

更新，查询也是类似这样的操作，具体操作手册可以参见 Elasticsearch权威指南

索引

Elasticsearch最关键的就是提供强大的索引能力了，其实InfoQ的这篇时间序列数据库的秘密(2)——索引写的非常好，我这里也是围绕这篇结合自己的理解进一步梳理下，也希望可以帮助大家更好的理解这篇文章。

Elasticsearch索引的精髓：

一切设计都是为了提高搜索的性能

另一层意思：为了提高搜索的性能，难免会牺牲某些其他方面，比如插入/更新，否则其他数据库不用混了:)

前面看到往Elasticsearch里插入一条记录，其实就是直接PUT一个json的对象，这个对象有多个fields，比如上面例子中的 name, sex, age, about, interests ，那么在插入这些数据到Elasticsearch的同时，Elasticsearch还默默 1 的为这些字段建立索引–倒排索引，因为Elasticsearch最核心功能是搜索。

Elasticsearch是如何做到快速索引的

InfoQ那篇文章里说Elasticsearch使用的倒排索引比关系型数据库的B-Tree索引快，为什么呢？

什么是B-Tree索引?

上大学读书时老师教过我们，二叉树查找效率是logN，同时插入新的节点不必移动全部节点，所以用树型结构存储索引，能同时兼顾插入和查询的性能。

因此在这个基础上，再结合磁盘的读取特性(顺序读/随机读)，传统关系型数据库采用了B-Tree/B+Tree这样的数据结构：

为了提高查询的效率，减少磁盘寻道次数，将多个值作为一个数组通过连续区间存放，一次寻道读取多个数据，同时也降低树的高度。

什么是倒排索引?

继续上面的例子，假设有这么几条数据(为了简单，去掉about, interests这两个field):

ID	Name	Age	Sex
1	Kate	24	Female
2	John	24	Male
3	Bill	29	Male

ID是Elasticsearch自建的文档id，那么Elasticsearch建立的索引如下:

Name:

Term	Posting List
Kate	1
John	2
Bill	3

Age:

Term	Posting List
24	[1,2]
29	3

Sex:

Term	Posting List
Female	1
Male	[2,3]

Posting List

Elasticsearch分别为每个field都建立了一个倒排索引，Kate, John, 24, Female这些叫term，而[1,2]就是 Posting List 。Posting list就是一个int的数组，存储了所有符合某个term的文档id。

看到这里，不要认为就结束了，精彩的部分才刚开始…

通过posting list这种索引方式似乎可以很快进行查找，比如要找age=24的同学，爱回答问题的小明马上就举手回答：我知道，id是1，2的同学。但是，如果这里有上千万的记录呢？如果是想通过name来查找呢？

Term Dictionary

Elasticsearch为了能快速找到某个term，将所有的term排个序，二分法查找term，logN的查找效率，就像通过字典查找一样，这就是 Term Dictionary 。现在再看起来，似乎和传统数据库通过B-Tree的方式类似啊，为什么说比B-Tree的查询快呢？

Term Index

B-Tree通过减少磁盘寻道次数来提高查询性能，Elasticsearch也是采用同样的思路，直接通过内存查找term，不读磁盘，但是如果term太多，term dictionary也会很大，放内存不现实，于是有了 Term Index ，就像字典里的索引页一样，A开头的有哪些term，分别在哪页，可以理解term index是一颗树：

这棵树不会包含所有的term，它包含的是term的一些前缀。通过term index可以快速地定位到term dictionary的某个offset，然后从这个位置再往后顺序查找。

所以term index不需要存下所有的term，而仅仅是他们的一些前缀与Term Dictionary的block之间的映射关系，再结合FST(Finite State Transducers)的压缩技术，可以使term index缓存到内存中。从term index查到对应的term dictionary的block位置之后，再去磁盘上找term，大大减少了磁盘随机读的次数。

这时候爱提问的小明又举手了:”那个FST是神马东东啊?”

一看就知道小明是一个上大学读书的时候跟我一样不认真听课的孩子，数据结构老师一定讲过什么是FST。但没办法，我也忘了，这里再补下课：

FSTs are finite-state machines that map a term (byte sequence) to an arbitrary output .

假设我们现在要将mop, moth, pop, star, stop and top(term index里的term前缀)映射到序号：0，1，2，3，4，5(term dictionary的block位置)。最简单的做法就是定义个Map<String, Integer>，大家找到自己的位置对应入座就好了，但从内存占用少的角度想想，有没有更优的办法呢？答案就是： FST ( 理论依据在此，但我相信99%的人不会认真看完的 )

:o:️表示一种状态

–>表示状态的变化过程，上面的字母/数字表示状态变化和权重

将单词分成单个字母通过:o:️和–>表示出来，0权重不显示。如果:o:️后面出现分支，就标记权重，最后整条路径上的权重加起来就是这个单词对应的序号。

FSTs are finite-state machines that map a term ( byte sequence ) to an arbitrary output.

FST以字节的方式存储所有的term，这种压缩方式可以有效的缩减存储空间，使得term index足以放进内存，但这种方式也会导致查找时需要更多的CPU资源。

后面的更精彩，看累了的同学可以喝杯咖啡……

压缩技巧

Elasticsearch里除了上面说到用FST压缩term index外，对posting list也有压缩技巧。小明喝完咖啡又举手了:”posting list不是已经只存储文档id了吗？还需要压缩？”

嗯，我们再看回最开始的例子，如果Elasticsearch需要对同学的性别进行索引(这时传统关系型数据库已经哭晕在厕所……)，会怎样？如果有上千万个同学，而世界上只有男/女这样两个性别，每个posting list都会有至少百万个文档id。 Elasticsearch是如何有效的对这些文档id压缩的呢？

Frame Of Reference

增量编码压缩，将大数变小数，按字节存储

首先，Elasticsearch要求posting list是有序的(为了提高搜索的性能，再任性的要求也得满足)，这样做的一个好处是方便压缩，看下面这个图例：

如果数学不是体育老师教的话，还是比较容易看出来这种压缩技巧的。

原理就是通过增量，将原来的大数变成小数仅存储增量值，再精打细算按bit排好队，最后通过字节存储，而不是大大咧咧的尽管是2也是用int(4个字节)来存储。

Roaring bitmaps

说到Roaring bitmaps，就必须先从bitmap说起。Bitmap是一种数据结构，假设有某个posting list：

[1,3,4,7,10]

对应的bitmap就是：

[1,0,1,1,0,0,1,0,0,1]

非常直观，用0/1表示某个值是否存在，比如10这个值就对应第10位，对应的bit值是1，这样用一个字节就可以代表8个文档id，旧版本(5.0之前)的Lucene就是用这样的方式来压缩的，但这样的压缩方式仍然不够高效，如果有1亿个文档，那么需要12.5MB的存储空间，这仅仅是对应一个索引字段(我们往往会有很多个索引字段)。于是有人想出了Roaring bitmaps这样更高效的数据结构。

Bitmap的缺点是存储空间随着文档个数线性增长，Roaring bitmaps需要打破这个魔咒就一定要用到某些指数特性：

将posting list按照65535为界限分块，比如第一块所包含的文档id范围在0~65535之间，第二块的id范围是65536~131071，以此类推。再用<商，余数>的组合表示每一组id，这样每组里的id范围都在0~65535内了，剩下的就好办了，既然每组id不会变得无限大，那么我们就可以通过最有效的方式对这里的id存储。

细心的小明这时候又举手了:”为什么是以65535为界限?”

程序员的世界里除了1024外，65535也是一个经典值，因为它=2^16-1，正好是用2个字节能表示的最大数，一个short的存储单位，注意到上图里的最后一行“If a block has more than 4096 values, encode as a bit set, and otherwise as a simple array using 2 bytes per value”，如果是大块，用节省点用bitset存，小块就豪爽点，2个字节我也不计较了，用一个short[]存着方便。

那为什么用4096来区分大块还是小块呢？

个人理解：都说程序员的世界是二进制的，4096*2bytes ＝ 8192bytes < 1KB, 磁盘一次寻道可以顺序把一个小块的内容都读出来，再大一位就超过1KB了，需要两次读。

联合索引

上面说了半天都是单field索引，如果多个field索引的联合查询，倒排索引如何满足快速查询的要求呢？

利用跳表(Skip list)的数据结构快速做“与”运算，或者
利用上面提到的bitset按位“与”

先看看跳表的数据结构：

将一个有序链表level0，挑出其中几个元素到level1及level2，每个level越往上，选出来的指针元素越少，查找时依次从高level往低查找，比如55，先找到level2的31，再找到level1的47，最后找到55，一共3次查找，查找效率和2叉树的效率相当，但也是用了一定的空间冗余来换取的。

假设有下面三个posting list需要联合索引：

如果使用跳表，对最短的posting list中的每个id，逐个在另外两个posting list中查找看是否存在，最后得到交集的结果。

如果使用bitset，就很直观了，直接按位与，得到的结果就是最后的交集。

总结和思考

Elasticsearch的索引思路:

将磁盘里的东西尽量搬进内存，减少磁盘随机读取次数(同时也利用磁盘顺序读特性)，结合各种奇技淫巧的压缩算法，用及其苛刻的态度使用内存。

所以，对于使用Elasticsearch进行索引时需要注意:

不需要索引的字段，一定要明确定义出来，因为默认是自动建索引的
同样的道理，对于String类型的字段，不需要analysis的也需要明确定义出来，因为默认也是会analysis的
选择有规律的ID很重要，随机性太大的ID(比如java的UUID)不利于查询

关于最后一点，个人认为有多个因素:

其中一个(也许不是最重要的)因素: 上面看到的压缩算法，都是对Posting list里的大量ID进行压缩的，那如果ID是顺序的，或者是有公共前缀等具有一定规律性的ID，压缩比会比较高；

另外一个因素: 可能是最影响查询性能的，应该是最后通过Posting list里的ID到磁盘中查找Document信息的那步，因为Elasticsearch是分Segment存储的，根据ID这个大范围的Term定位到Segment的效率直接影响了最后查询的性能，如果ID是有规律的，可以快速跳过不包含该ID的Segment，从而减少不必要的磁盘读次数，具体可以参考这篇如何选择一个高效的全局ID方案 (评论也很精彩)

后续再结合实际开发及调优工作分享更多内容，敬请期待！

Reference

Elasticsearch权威指南

时间序列数据库的秘密(2)——索引

Elasticsearch2.0搭建集群及配置

Elasticsearch2.0集群配置
1.环境说明：      三个节点：
          Windows上配置：一个主节点，一个从节点，设定不同的端口后，启动两个Elasticsearch进程
          Linux上配置  ：一个从节点，设置默认端口，启动一个Elasticsearch进程

              Windows:
                       192.168.1.120
                                     node1          --- 主节点
                                                :9200       节点间的通信端口(默认：9200)
                                                :9300       Http数据传输接口(默认：9300)
                                     node3          --- 从节点
                                                :9201
                                                :9301
               Linux：
                       192.168.1.246
                                     linux_node2    --- 从节点
                                                :9200
                                                :9300
2.Windows上node1的config/elasticsearch.yml配置        node1主节点：
                   #自定义创建集群配置信息
                   # elasticsearch-node1主节点的配置 192.168.1.120
                   network.host: 192.168.1.120
                   # 配置集群名称
                   cluster.name: mycluster
                   # 配置节点名称
                   node.name: "node1"
                   node.master: true
                   node.data: true
                   #设置传播发现选项
                   discovery.zen.ping.multicast.enabled: false
                   discovery.zen.ping.unicast.hosts: ["192.168.1.120:9300"]
                   # 为节点之间的通信设置一个自定义端口(默认为9300)
                   transport.tcp.port: 9300
                   # 设置监听HTTP传输的自定义端(默认为9200)
                   http.port: 9200
        node3从节点:
                   #自定义创建集群配置信息
                   # elasticsearch-node1主节点的配置 192.168.1.120
                   network.host: 192.168.1.120
                   # 配置集群名称
                   cluster.name: mycluster
                   # 配置节点名称
                   node.name: "node3"
                   node.master: false
                   node.data: true
                   discovery.zen.ping.multicast.enabled: false
                   discovery.zen.ping.unicast.hosts: ["192.168.1.120:9300"]
                   # 为节点之间的通信设置一个自定义端口(默认为9300)
                   transport.tcp.port: 9301
                   # 设置监听HTTP传输的自定义端(默认为9200)
                   http.port: 9201

3.Linux上linux_node2的config/elasticsearch.yml配置        linux_node2从节点:
                   # elasticsearch-node2配置  192.168.1.246
                   network.host: 192.168.1.246
                   # 配置集群名称
                   cluster.name: mycluster
                   # 配置节点名称
                   node.name: "linux_node2"
                   node.master: false
                   node.data: true
                   # 为节点之间的通信设置一个自定义端口(默认为9300)
                   transport.tcp.port: 9300
                   # 设置监听HTTP传输的自定义端(默认为9200)
                   http.port: 9200
                   #设置发现选项地址
                   discovery.zen.ping.multicast.enabled: false
                   discovery.zen.ping.unicast.hosts: ["192.168.1.120:9300"]

4.通过Elasticsearch-head插件访问        1.安装head插件
               Windows下安装：
                  elasticsearch-2.0.0\bin>plugin install mobz/elasticsearch-head

               Linux下安装head插件
                  elasticsearch/bin/./plugin install mobz/elasticsearch-head

               访问Elasticsearch：
                  http://IP:port/_plugin/head/

        2.通过head访问Elasticsearch
               http://192.168.1.120:9200/_plugin/head/
           特别注意：
               这里的IP:port要与elasticsearch.yml中配置的network.host和http.port一致，否则无法访问

5.特别说明：        #设置发现选项地址
        hosts的地址：最好是主节点的  ["network.host:http:port:]

6.Java连接Elasticsearch集群

[java] view plain copy

package com.jay.elasticsearch.demo2;
import org.elasticsearch.client.transport.TransportClient;
//import org.elasticsearch.common.settings.ImmutableSettings;
import org.elasticsearch.common.settings.Settings;
import org.elasticsearch.common.transport.InetSocketTransportAddress;
import java.lang.reflect.Constructor;
import java.net.InetAddress;
import java.net.UnknownHostException;
/**
* 通过反射机制和单例模式，初始化更加高效的Client
* 对ES2.0有效
* Created by Jay He on 2015/11/9.
*/
public class MoreEffectiveClientTest {
// private static final String CLUSTER_NAME = "cluster_name";
public static final String CLUSTER_NAME = "elasticsearch";
// private static final String IP = "127.0.0.1";
private static final String IP = "192.168.1.120";
private static final int PORT = 9300;
//1.设置集群名称：默认是elasticsearch，并设置client.transport.sniff为true，使客户端嗅探整个集群状态，把集群中的其他机器IP加入到客户端中
/*
//对ES1.6有效
private static Settings settings = ImmutableSettings
.settingsBuilder()
.put("cluster.name",CLUSTER_NAME)
.put("client.transport.sniff", true)
.build();
*/
//对ES2.0有效
private static Settings settings = Settings
.settingsBuilder()
.put("cluster.name",CLUSTER_NAME)
.put("client.transport.sniff", true)
.build();
//创建私有对象
private static TransportClient client;
//反射机制创建单例的TransportClient对象 ES1.6版本
// static {
// try {
// Class<?> clazz = Class.forName(TransportClient.class.getName());
// Constructor<?> constructor = clazz.getDeclaredConstructor(Settings.class);
// constructor.setAccessible(true);
// client = (TransportClient) constructor.newInstance(settings);
// client.addTransportAddress(new InetSocketTransportAddress(InetAddress.getByName(IP), PORT));
// } catch (Exception e) {
// e.printStackTrace();
// }
// }
//ES2.0版本
static {
try {
client = TransportClient.builder().settings(settings).build()
.addTransportAddress(new InetSocketTransportAddress(InetAddress.getByName(IP), PORT));
} catch (UnknownHostException e) {
e.printStackTrace();
}
}
//取得实例
public static synchronized TransportClient getTransportClient(){
return client;
}
//为集群添加新的节点
public static synchronized void addNode(String name){
try {
client.addTransportAddress(new InetSocketTransportAddress(InetAddress.getByName(name),9300));
} catch (UnknownHostException e) {
e.printStackTrace();
}
}
//删除集群中的某个节点
public static synchronized void removeNode(String name){
try {
client.removeTransportAddress(new InetSocketTransportAddress(InetAddress.getByName(name),9300));
} catch (UnknownHostException e) {
e.printStackTrace();
}
}
public static void main(String args[]){
getTransportClient();
}
}

附：一个ES配置文件参考与参数详解

[java] view plain copy

cluster.name: data-cluster
node.name: "data-es-05"
#node.data: false
# Indexing & Cache config
index.number_of_shards: 5
index.number_of_replicas: 1
index.cache.field.type: soft
index.cache.field.expire: 10m
index.cache.query.enable: true
indices.cache.query.size: 2%
indices.fielddata.cache.size: 35%
indices.fielddata.cache.expire: 10m
index.search.slowlog.level: INFO
#indices.recovery.max_size_per_sec: 1gb
index.merge.scheduler.max_thread_count: 2 # Only for spinning media.
# Refresh config
index.refresh_interval: 300s
# Translog config
index.translog.flush_threshold_ops: 100000
# Paths config
path.data: /data/esData
path.plugins: /usr/share/elasticsearch/plugins
# Network And HTTP
network.bind_host: 10.0.126.203
network.publish_host: 10.0.126.203
transport.tcp.port: 9300
transport.tcp.compress: true
http.port: 9200
# Discovery
discovery.zen.minimum_master_nodes: 1
discovery.zen.ping.timeout: 10s
discovery.zen.ping.multicast.enabled: false
discovery.zen.ping.unicast.hosts: ["10.0.32.3:9300", "10.0.4.37:9300", "10.0.40.159:9300", "10.0.107.116:9300" , "10.0.126.203:9300"]

配置文件位于%ES_HOME%/config/elasticsearch.yml文件中，用Editplus打开它，你便可以进行配置。
        所有的配置都可以使用环境变量，例如：
node.rack: ${RACK_ENV_VAR}
        表示环境变量中有一个RACK_ENV_VAR变量。
        下面列举一下elasticsearch的可配置项：
         1. 集群名称，默认为elasticsearch：
cluster.name: elasticsearch
         2. 节点名称，es启动时会自动创建节点名称，但你也可进行配置：
node.name: "Franz Kafka"
         3. 是否作为主节点，每个节点都可以被配置成为主节点，默认值为true：
node.master: true
         4. 是否存储数据，即存储索引片段，默认值为true：
node.data: true
         master和data同时配置会产生一些奇异的效果：
         1) 当master为false，而data为true时，会对该节点产生严重负荷；
         2) 当master为true，而data为false时，该节点作为一个协调者；
         3) 当master为false，data也为false时，该节点就变成了一个负载均衡器。
         你可以通过连接http://localhost:9200/_cluster/health或者http://localhost:9200/_cluster/nodes，或者使用插件http://github.com/lukas-vlcek/bigdesk或http://mobz.github.com/elasticsearch-head来查看集群状态。
         5. 每个节点都可以定义一些与之关联的通用属性，用于后期集群进行碎片分配时的过滤：
node.rack: rack314
         6. 默认情况下，多个节点可以在同一个安装路径启动，如果你想让你的es只启动一个节点，可以进行如下设置：
node.max_local_storage_nodes: 1
         7. 设置一个索引的碎片数量，默认值为5：
index.number_of_shards: 5
         8. 设置一个索引可被复制的数量，默认值为1：
index.number_of_replicas: 1
         当你想要禁用公布式时，你可以进行如下设置：
index.number_of_shards: 1
index.number_of_replicas: 0
         这两个属性的设置直接影响集群中索引和搜索操作的执行。假设你有足够的机器来持有碎片和复制品，那么可以按如下规则设置这两个值：
         1) 拥有更多的碎片可以提升索引执行能力，并允许通过机器分发一个大型的索引；
         2) 拥有更多的复制器能够提升搜索执行能力以及集群能力。
         对于一个索引来说，number_of_shards只能设置一次，而number_of_replicas可以使用索引更新设置API在任何时候被增加或者减少。
         ElasticSearch关注加载均衡、迁移、从节点聚集结果等等。可以尝试多种设计来完成这些功能。
         可以连接http://localhost:9200/A/_status来检测索引的状态。
         9. 配置文件所在的位置，即elasticsearch.yml和logging.yml所在的位置：
path.conf: /path/to/conf
         10. 分配给当前节点的索引数据所在的位置：
path.data: /path/to/data
         可以可选择的包含一个以上的位置，使得数据在文件级别跨越位置，这样在创建时就有更多的自由路径，如：
path.data: /path/to/data1,/path/to/data2
         11. 临时文件位置：
path.work: /path/to/work
         12. 日志文件所在位置：
path.logs: /path/to/logs
         13. 插件安装位置：
path.plugins: /path/to/plugins
         14. 插件托管位置，若列表中的某一个插件未安装，则节点无法启动：
plugin.mandatory: mapper-attachments,lang-groovy
         15. JVM开始交换时，ElasticSearch表现并不好：你需要保障JVM不进行交换，可以将bootstrap.mlockall设置为true禁止交换：
bootstrap.mlockall: true
         请确保ES_MIN_MEM和ES_MAX_MEM的值是一样的，并且能够为ElasticSearch分配足够的内在，并为系统操作保留足够的内存。
         16. 默认情况下，ElasticSearch使用0.0.0.0地址，并为http传输开启9200-9300端口，为节点到节点的通信开启9300-9400端口，也可以自行设置IP地址：
network.bind_host: 192.168.0.1
         17. publish_host设置其他节点连接此节点的地址，如果不设置的话，则自动获取，publish_host的地址必须为真实地址：
network.publish_host: 192.168.0.1
         18. bind_host和publish_host可以一起设置：
network.host: 192.168.0.1
         19. 可以定制该节点与其他节点交互的端口：
transport.tcp.port: 9300
         20. 节点间交互时，可以设置是否压缩，转为为不压缩：
transport.tcp.compress: true
         21. 可以为Http传输监听定制端口：
http.port: 9200
         22. 设置内容的最大长度：
http.max_content_length: 100mb
         2 3 . 禁止HTTP
http.enabled: false
         2 4 . 网关允许在所有集群重启后持有集群状态，集群状态的变更都会被保存下来，当第一次启用集群时，可以从网关中读取到状态，默认网关类型（也是推荐的）是local：
gateway.type: local
         2 5 . 允许在N个节点启动后恢复过程：
gateway.recover_after_nodes: 1
         2 6 . 设置初始化恢复过程的超时时间：
gateway.recover_after_time: 5m
         2 7 . 设置该集群中可存在的节点上限：
gateway.expected_nodes: 2
         2 8 . 设置一个节点的并发数量，有两种情况，一种是在初始复苏过程中：
cluster.routing.allocation.node_initial_primaries_recoveries: 4
         另一种是在添加、删除节点及调整时：
cluster.routing.allocation.node_concurrent_recoveries: 2
         2 9 . 设置复苏时的吞吐量，默认情况下是无限的：
indices.recovery.max_size_per_sec: 0
        30 . 设置从对等节点恢复片段时打开的流的数量上限：
indices.recovery.concurrent_streams: 5
         3 1 . 设置一个集群中主节点的数量，当多于三个节点时，该值可在2-4之间：
discovery.zen.minimum_master_nodes: 1
         3 2 . 设置ping其他节点时的超时时间，网络比较慢时可将该值设大：
discovery.zen.ping.timeout: 3s
http://elasticsearch.org/guide/reference/modules/discovery/zen.html上有更多关于discovery的设置。
         3 3 . 禁止当前节点发现多个集群节点，默认值为true：
discovery.zen.ping.multicast.enabled: false
         3 4 . 设置新节点被启动时能够发现的主节点列表（主要用于不同网段机器连接）：

discovery.zen.ping.unicast.hosts: ["host1", "host2:port", "host3[portX-portY]"]

35.设置是否可以通过正则或者_all删除或者关闭索引

action.destructive_requires_name 默认false 允许可设置true不允许

Elasticsearch集群中处理大型日志流的几个常用概念

之前对于CDN的日志处理模型是从
logstash agent==>>Redis==>>logstash index==>>elasticsearch==>>kibana3，对于elasticsearch集群搭建，可以把索引进行分片存储，一个索引可以分成若干个片，分别存储到集群里面，而对于集群里面的负载均衡，副本分配，索引动态均衡（根据节点的增加或者减少）都是elasticsearch自己内部完成的，一有情况就会重新进行分配。
下面先是介绍几个关于elasticsearch的几个名词

cluster
代表一个集群，集群中有多个节点，其中有一个为主节点，这个主节点是可以通过选举产生的，主从节点是对于集群内部来说的。es的一个概念就是去中心化，字面上理解就是无中心节点，这是对于集群外部来说的，因为从外部来看es集群，在逻辑上是个整体，你与任何一个节点的通信和与整个es集群通信是等价的。

shards
代表索引分片，es可以把一个完整的索引分成多个分片，这样的好处是可以把一个大的索引拆分成多个，分布到不同的节点上。构成分布式搜索。分片的数量只能在索引创建前指定，并且索引创建后不能更改。

replicas
代表索引副本，es可以设置多个索引的副本，副本的作用一是提高系统的容错性，当个某个节点某个分片损坏或丢失时可以从副本中恢复。二是提高es的查询效率，es会自动对搜索请求进行负载均衡。

recovery
代表数据恢复或叫数据重新分布，es在有节点加入或退出时会根据机器的负载对索引分片进行重新分配，挂掉的节点重新启动时也会进行数据恢复。

river
代表es的一个数据源，也是其它存储方式（如：数据库）同步数据到es的一个方法。它是以插件方式存在的一个es服务，通过读取river中的数据并把它索引到es中，官方的river有couchDB的，RabbitMQ的，Twitter的，Wikipedia的，river这个功能将会在后面的文件中重点说到。

gateway
代表es索引的持久化存储方式，es默认是先把索引存放到内存中，当内存满了时再持久化到硬盘。当这个es集群关闭再重新启动时就会从gateway中读取索引数据。es支持多种类型的gateway，有本地文件系统（默认），分布式文件系统，Hadoop的HDFS和amazon的s3云存储服务。

discovery.zen
代表es的自动发现节点机制，es是一个基于p2p的系统，它先通过广播寻找存在的节点，再通过多播协议来进行节点之间的通信，同时也支持点对点的交互。

Transport
代表es内部节点或集群与客户端的交互方式，默认内部是使用tcp协议进行交互，同时它支持http协议（json格式）、thrift、servlet、memcached、zeroMQ等的传输协议（通过插件方式集成）。

sdulibh

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
Elasticsearch 学习笔记

最近在参与一个基于Elasticsearch作为底层数据框架提供大数据量(亿级)的实时统计查询的方案设计工作，花了些时间学习Elasticsearch的基础理论知识，整理了一下，希望能对Elasticsearch感兴趣/想了解的同学有所帮助。同时也希望有发现内容不正确或者有疑问的地方，望指明，一起探讨，学习，进步。介绍Elasticsearch 是一个分布式可扩展的实时搜索和
复制链接

扫一扫