ES架构及原理

本文转载自https://www.cnblogs.com/tgzhu/p/6098339.html
Elasticsearch 是一个兼有搜索引擎和NoSQL数据库功能的开源系统，基于Java/Lucene构建，能够用于全文搜索，结构化搜索以及近实时分析。能够说Lucene是当今最早进，最高效的全功能开源搜索引擎框架。 说明： Lucene：只是一个框架，要充分利用它的功能，须要使用JAVA，而且在程序中集成Lucene，学习成本高，Lucene确实很是复杂。 Elasticsearch 是 面向文档型数据库，这意味着它存储的是整个对象或者 文档，它不但会存储它们，还会为他们创建索引，这样你就能够搜索他们了

目录：

应用场景
solr VS ES
核心概念
ES模块结构
分片示例
应用场景

站内搜索：主要和 Solr 竞争，属于后起之秀
NoSQL json文档数据库：主要抢占 Mongo 的市场，它在读写性能上优于 Mongo ，同时也支持地理位置查询，还方便地理位置和文本混合查询，属于歪打正着 （对比测试参见：http://blog.quarkslab.com/mongodb-vs-elasticsearch-the-quest-of-the-holy-performances.html）
监控：统计以及日志类时间序的数据的存储和分析以及可视化，这方面是引领者
国外：Wikipedia使用 ES 提供全文搜索并高亮关键字、StackOverflow结合全文搜索与地理位置查询、Github使用Elasticsearch检索1300亿行的代码
国内：百度（在casio、云分析、网盟、预测、文库、直达号、钱包、风控等业务上都应用了ES，单集群天天导入30TB+数据，总共天天60TB+）、新浪 （见大数据架构--log），阿里巴巴、腾讯等公司均有对ES的使用
使用比较普遍的平台ELK(ElasticSearch, Logstash, Kibana)
solr VS ES

Solr是Apache Lucene项目的开源企业搜索平台。其主要功能包括全文检索、命中标示、分面搜索、动态聚类、数据库集成，以及富文本（如Word、PDF）的处理。
Solr是高度可扩展的，并提供了分布式搜索和索引复制。Solr是最流行的企业级搜索引擎，Solr4 还增长了NoSQL支持。
Solr是用Java编写、运行在Servlet容器（如 Apache Tomcat 或Jetty）的一个独立的全文搜索服务器。 Solr采用了 Lucene Java 搜索库为核心的全文索引和搜索，并具备相似REST的HTTP/XML和JSON的API。
Solr强大的外部配置功能使得无需进行Java编码，即可对 其进行调整以适应多种类型的应用程序。Solr有一个插件架构，以支持更多的高级定制
Elasticsearch 与 Solr 的比较总结
两者安装都很简单
Solr 利用 Zookeeper 进行分布式管理，而 Elasticsearch 自身带有分布式协调管理功能
Solr 支持更多格式的数据，而 Elasticsearch 仅支持json文件格式
Solr 官方提供的功能更多，而 Elasticsearch 自己更注重于核心功能，高级功能多有第三方插件提供
Solr 在传统的搜索应用中表现好于 Elasticsearch，但在处理实时搜索应用时效率明显低于 Elasticsearch
Solr 是传统搜索应用的有力解决方案，但 Elasticsearch 更适用于新兴的实时搜索应用
核心概念

集群（Cluster): 包含一个或多个具备相同 cluster.name 的节点.
集群内节点协同工做，共享数据，并共同分担工做负荷。
因为节点是从属集群的，集群会自我重组来均匀地分发数据.
cluster Name是很重要的，由于每一个节点只能是群集的一部分，当该节点被设置为相同的名称时，就会自动加入群集。
集群中经过选举产生一个mater节点，它将负责管理集群范畴的变动，例如建立或删除索引，添加节点到集群或从集群删除节点。master 节点无需参与文档层面的变动和搜索，这意味着仅有一个 master 节点并不会因流量增加而成为瓶颈。任意一个节点均可以成为 master 节点。咱们例举的集群只有一个节点，所以它会扮演 master 节点的角色。
做为用户，咱们能够访问包括 master 节点在内的集群中的任一节点。每一个节点都知道各个文档的位置，并可以将咱们的请求直接转发到拥有咱们想要的数据的节点。不管咱们访问的是哪一个节点，它都会控制从拥有数据的节点收集响应的过程，并返回给客户端最终的结果。这一切都是由 Elasticsearch 透明管理的
节点(node): 一个节点是一个逻辑上独立的服务，能够存储数据，并参与集群的索引和搜索功能, 一个节点也有惟一的名字，群集经过节点名称进行管理和通讯.
索引（Index)： 索引与关系型数据库实例(Database)至关。索引只是一个 逻辑命名空间，它指向一个或多个分片(shards)，内部用Apache Lucene实现索引中数据的读写
文档类型（Type）：至关于数据库中的table概念。每一个文档在ElasticSearch中都必须设定它的类型。文档类型使得同一个索引中在存储结构不一样文档时，只须要依据文档类型就能够找到对应的参数映射(Mapping)信息，方便文档的存取
文档（Document) ：至关于数据库中的row， 是能够被索引的基本单位。例如，你能够有一个的客户文档，有一个产品文档，还有一个订单的文档。文档是以JSON格式存储的。在一个索引中，您能够存储多个的文档。请注意，虽然在一个索引中有多分文档，但这些文档的结构是一致的，并在第一次存储的时候指定, 文档属于一种 类型(type)，各类各样的类型存在于一个 索引 中。你也能够经过类比传统的关系数据库获得一些大体的类似之处：
关系数据库 ⇒ 数据库 ⇒ 表 ⇒ 行 ⇒ 列(Columns)
Elasticsearch ⇒ 索引 ⇒ 类型 ⇒ 文档 ⇒ 字段(Fields)
模拟示意图如：

Mapping： 至关于数据库中的schema，用来约束字段的类型，不过 Elasticsearch 的 mapping 能够自动根据数据建立
分片(shard) ：是 工做单元(worker unit) 底层的一员，用来分配集群中的数据，它只负责保存索引中全部数据的一小片。
分片是一个独立的Lucene实例，而且它自身也是一个完整的搜索引擎。
文档存储而且被索引在分片中，可是咱们的程序并不会直接与它们通讯。取而代之，它们直接与索引进行通讯的
把分片想象成一个数据的容器。数据被存储在分片中，而后分片又被分配在集群的节点上。当你的集群扩展或者缩小时，elasticsearch 会自动的在节点之间迁移分配分片，以便集群保持均衡
分片分为 主分片(primary shard) 以及 从分片(replica shard) 两种。在你的索引中，每个文档都属于一个主分片
从分片只是主分片的一个副本，它用于提供数据的冗余副本，在硬件故障时提供数据保护，同时服务于搜索和检索这种只读请求
索引中的主分片的数量在索引建立后就固定下来了，可是从分片的数量能够随时改变。
一个索引默认设置了5个主分片，每一个主分片有一个从分片对应
ES模块结构

模块结构图以下

Gateway: 表明ES的持久化存储方式，包含索引信息，ClusterState(集群信息)，mapping，索引碎片信息，以及transaction log等
对于分布式集群来讲，当一个或多个节点down掉了，可以保证咱们的数据不能丢，最通用的解放方案就是对失败节点的数据进行复制，经过控制复制的份数能够保证集群有很高的可用性，复制这个方案的精髓主要是保证操做的时候没有单点，对一个节点的操做会同步到其余的复制节点上去。
ES一个索引会拆分红多个碎片，每一个碎片能够拥有一个或多个副本（建立索引的时候能够配置），这里有个例子，每一个索引分红3个碎片，每一个碎片有2个副本，以下：
$ curl -XPUT http://localhost:9200/twitter/ -d '
index :
number_of_shards : 3
number_of_replicas : 2
每一个操做会自动路由主碎片所在的节点，在上面执行操做，而且同步到其余复制节点，经过使用“non blocking IO”模式全部复制的操做都是并行执行的，也就是说若是你的节点的副本越多，你网络上的流量消耗也会越大。复制节点一样接受来自外面的读操做，意义就是你的复制节点越多，你的索引的可用性就越强，对搜索的可伸缩行就更好，可以承载更多的操做

第一次启动的时候，它会去持久化设备读取集群的状态信息（建立的索引，配置等）而后执行应用它们（建立索引，建立mapping映射等），每一次shard节点第一次实例化加入复制组，它都会从长持久化存储里面恢复它的状态信息
Lucence Directory: 是lucene的框架服务发现以及选主 ZenDiscovery: 用来实现节点自动发现，还有Master节点选取，假如Master出现故障，其它的这个节点会自动选举，产生一个新的Master
它是Lucene存储的一个抽象，由此派生了两个类：FSDirectory和RAMDirectory，用于控制索引文件的存储位置。使用FSDirectory类，就是存储到硬盘；使用RAMDirectory类，则是存储到内存

一个Directory对象是一份文件的清单。文件可能只在被建立的时候写一次。一旦文件被建立，它将只被读取或者删除。在读取的时候进行写入操做是容许的Discovery节点启动后先ping（这里的ping是 Elasticsearch 的一个RPC命令。若是 discovery.zen.ping.unicast.hosts 有设置，则ping设置中的host，不然尝试ping localhost 的几个端口， Elasticsearch 支持同一个主机启动多个节点）Ping的response会包含该节点的基本信息以及该节点认为的master节点选举开始，先从各节点认为的master中选，规则很简单，按照id的字典序排序，取第一个若是各节点都没有认为的master，则从全部节点中选择，规则同上。这里有个限制条件就是 discovery.zen.minimum_master_nodes，若是节点数达不到最小值的限制，则循环上述过程，直到节点数足够能够开始选举最后选举结果是确定能选举出一个master，若是只有一个local节点那就选出的是本身若是当前节点是master，则开始等待节点数达到 minimum_master_nodes，而后提供服务, 若是当前节点不是master，则尝试加入master.ES支持任意数目的集群（1-N）,因此不能像 Zookeeper/Etcd 那样限制节点必须是奇数，也就没法用投票的机制来选主，而是经过一个规则，只要全部的节点都遵循一样的规则，获得的信息都是对等的，选出来的主节点确定是一致的. 但分布式系统的问题就出在信息不对等的状况，这时候很容易出现脑裂（Split-Brain）的问题，大多数解决方案就是设置一个quorum值，要求可用节点必须大于quorum（通常是超过半数节点），才能对外提供服务。而 Elasticsearch 中，这个quorum的配置就是 discovery.zen.minimum_master_nodes 。memcached经过memecached协议来访问ES的接口,支持二进制和文本两种协议.经过一个名为transport-memcached插件提供Memcached命令会被映射到REST接口，而且会被一样的REST层处理，memcached命令列表包括：get/set/delete/quitRiver : 表明es的一个数据源，也是其它存储方式（如：数据库）同步数据到es的一个方法。它是以插件方式存在的一个es服务，经过读取river中的数据并把它索引到es中，官方的river有couchDB的，RabbitMQ的，Twitter的，Wikipedia的，river这个功能将会在后面的文件中重点说到