走进Elasticsearch

 

摘   要：在当今互联网大数据时代，我们可以认为数据的就是第一生产和发展要素，数据的处理变得越来越重要。无论是企业还是高校，对数据最重要的处理操作那毫无疑问就是搜索。我们任何人都离不开数据，更离不开搜索，从数据中按要求获取到所需要的重要数据是一个格外重要的发展要求。虽然已经有非常的多的支持搜索功能的数据库，但是这些数据库都有一个致命的短板，那就是处理海量数据的低效性。那么ELasticSearch就是一款非常适合海量数据搜索的搜索引擎，并且是一个实时的分布式搜索分析引擎，基于Restful WebApi，使用Java语言开发的搜索引擎库类。主要功能有三点：全文搜索、结构化搜索、分析。同时，ELasticSearch结合其他三个开源产品Kibana、Logstash、Beats所构建的ELK平台被广泛的运用在大数据近实时分析领域，可以实现搜索海量数据结构化、非结构化数据等功能。本文主要论述ELasticsearch的底层原理。

 

关键词：分布式、大数据、搜索引擎

 

ElasticSearch主要是对数据进行搜索、分析和存储，其分布式搜索和分析引擎都是基于JSON，具有水平可扩展性、高可靠性和管理便捷性特点。

Elasticsearch是实时的分布式搜索分析引擎，内部使用Lucene 做索引与搜索。何谓实时？新增到 ES 中的数据在1秒后就可以被检索到，这种新增数据对搜索的可见性称为“准实时搜索”。分布式意味着可以动态调整集群规模，弹性扩容，而这一切操作起来都非常简便，用户甚至不必了解集群原理就可以实现。按官方的描述，集群规模支持“上百”个 节点，相比HDFS等上千台的集群，这个规模“小了点”。影响集群规模 上限的原因将在后续的章节中分析。因此，目前我们认为ES适合中等数据量的业务，不适合存储海量数据。

Lucene是Java语言编写的全文搜索框架，用于处理纯文本的数据，但它只是一个库，提供建立索引、执行搜索等接口，但不包含分布式服务，这些正是 ES 做的。什么是全文？对全部的文本内容进行分析，建立索引，使之可以被搜索，因此称为全文。

基于ES，你可以很容易地搭建自己的搜索引擎，用于分析日志，或者配合开源爬虫建立某个垂直领域的搜索引擎。ES 易用的产品设计使得它很容易上手。除了搜索，ES 还提供了大量的聚合功能，所以它不单单是一个搜索引擎，还可以进行数据分析、统计，生成指标数据。而这些功能都在快速迭代，目前每2周左右就会发布新版本。

1、索引结构

ES是面向文档的。各种文本内容以文档的形式存储到ES中，一般使用 JSON

作为文档的序列化格式，文档可以有很多字段，在创建索引的时候，我们需要描述文档中每个字段的数据类型，并且可能需要指定不同的分析器。

在存储结构上，由_index、_type和_id唯一标识一个文档。

_index指向一个或多个物理分片的逻辑命名空间，_type类型用于区分同一个集合中的不同细分，在不同的细分中，数据的整体模式是相同或相似的，不适合完全不同类型的数据。多个_type可以在相同的索引中存在，只要它们的字段不冲突即可。_id文档标记符由系统自动生成或使用者提供。

2、分片（shard）

在分布式系统中，单机无法存储规模巨大的数据，要依靠大规模集群处理和存储这些数据，一般通过增加机器数量来提高系统水平扩展能力。因此，需要将数据分成若干小块分配到各个机器上。然后通过某种路由策略找到某个数据块所在的位置。

除了将数据分片以提高水平扩展能力，分布式存储中还会把数据复制成多个副本，放置到不同的机器中，这样一来可以增加系统可用性，同时数据副本还可以使读操作并发执行，分担集群压力。但是多数据副本也带来了一致性的问题：部分副本写成功，部分副本写失败。

为了应对并发更新问题，ES将数据副本分为主从两部分，即主分 片（primary shard）和副分片（replica shard）。主数据作为权威数据，写过程中先写主分片，成功后再写副分片，恢复阶段以主分片为准。

分片（shard）是底层的基本读写单元，分片的目的是分割巨大索 引，让读写可以并行操作，由多台机器共同完成。读写请求最终落到某个分片上，分片可以独立执行读写工作。ES利用分片将数据分发到集群内各处。分片是数据的容器，文档保存在分片内，不会跨分片存储。分片又被分配到集群内的各个节点里。当集群规模扩大或缩小时，ES 会自动在各节点中迁移分片，使数据仍然均匀分布在集群里。

3、动态更新索引

为文档建立索引，使其每个字段都可以被搜索，通过关键词检索文档内容，会使用倒排索引的数据结构。倒排索引一旦被写入文件后就具有不变性，不变性具有许多好处：对文件的访问不需要加锁，读取索引时可以被文件系统缓存等。 那么索引如何更新，让新添加的文档可以被搜索到？答案是使用更多的索引，新增内容并写到一个新的倒排索引中，查询时，每个倒排索引都被轮流查询，查询完再对结果进行合并。

 每次内存缓冲的数据被写入文件时，会产生一个新的Lucene段， 每个段都是一个倒排索引。在一个记录元信息的文件中描述了当前Lucene索引都含有哪些分段。

由于分段的不变性，更新、删除等操作实际上是将数据标记为删除，记录到单独的位置，这种方式称为标记删除。因此删除部分数据不会释放磁盘空间。 

4、近实时搜索

在写操作中，一般会先在内存中缓冲一段数据，再将这些数据写 入硬盘，每次写入硬盘的这批数据称为一个分段，如同任何写操作一 样。一般情况下（direct方式除外），通过操作系统write接口写到磁 盘的数据先到达系统缓存（内存）,write函数返回成功时，数据未必被 刷到磁盘。通过手工调用flush，或者操作系统通过一定策略将系统缓存刷到磁盘。这种策略大幅提升了写入效率。从write函数返回成功开始，无论数据有没有被刷到磁盘，该数据已经对读取可见。

ES正是利用这种特性实现了近实时搜索。每秒产生一个新分段， 新段先写入文件系统缓存，但稍后再执行flush刷盘操作，写操作很快会执行完，一旦写成功，就可以像其他文件一样被打开和读取了。

由于系统先缓冲一段数据才写，且新段不会立即刷入磁盘，这两 个过程中如果出现某些意外情况（如主机断电），则会存在丢失数据 的风险。通用的做法是记录事务日志，每次对ES进行操作时均记录事 务日志，当ES启动的时候，重放translog中所有在最后一次提交后发生的变更操作。比如HBase等都有自己的事务日志。

5、段合并

在ES中，每秒清空一次写缓冲，将这些数据写入文件，这个过程 称为refresh，每次refresh会创建一个新的Lucene 段。但是分段数 量太多会带来较大的麻烦，每个段都会消耗文件句柄、内存。每个搜 索请求都需要轮流检查每个段，查询完再对结果进行合并；所以段越 多，搜索也就越慢。因此需要通过一定的策略将这些较小的段合并为 大的段，常用的方案是选择大小相似的分段进行合并。在合并过程 中，标记为删除的数据不会写入新分段，当合并过程结束，旧的分段数据被删除，标记删除的数据才从磁盘删除。

HBase、Cassandra等系统都有类似的分段机制，写过程中先在 内存缓冲一批数据，不时地将这些数据写入文件作为一个分段，分段 具有不变性，再通过一些策略合并分段。分段合并过程中，新段的产 生需要一定的磁盘空间，我们要保证系统有足够的剩余可用空间。

Cassandra系统在段合并过程中的一个问题就是，当持续地向一个表 中写入数据，如果段文件大小没有上限，当巨大的段达到磁盘空间的一半时，剩余空间不足以进行新的段合并过程。如果段文件设置一定 上限不再合并，则对表中部分数据无法实现真正的物理删除。ES存在同样的问题。

标签：分段,走进,索引,搜索,分片,Elasticsearch,数据,ES
来源： https://www.cnblogs.com/yuyapeng/p/16388222.html