技术背景
对于搜索类需求，传统方式是将数据放入数据库中，然后使用sql语句进行精准查询或模糊查询，但随着业务的发展，数据量逐渐庞大，传统的数据库的性能逐渐不能满足要求，于是很多公司开始对数据库进行读写分离和分库分表，对数据库进行横向和纵向的扩容，但是这种做法增加了数据运维成本，对于大数据量的检索依然很慢，于是就出现了第一款全文检索工具lucene，lucene的缺点是对外暴露的可用接口对于操作来说比较复杂，且效率不高；后来有一款工具基于lucene做了进一步的封装，叫做solr，它是一款高性能分布式检索服务框架，其缺点是在建立索引期间，solr的搜索能力极度下降，造成了不满足实时索引的场景。于是ElasticSearch应运而生，它也是基于lucene开发的，基于restful接口发布，操作便捷
设计目的
- 为了解决对海量数据进行近实时的处理
- 提供全文检索，结构化检索，数据分析等功能
- 实现分布式的搜索引擎和数据分析引擎
- 用于解决日志的存储、分析、监控的处理
设计思想
- 分布式
- 索引库
技术本质
基于内容分词构建索引的工具
核心特性
- java 源码： 社区活跃，使用人群多
- NRT近实时：高性能，每个字段都有索引
- 分布式：高可用，高扩展，高可靠
- restful风格：交互简单友好
集群角色
Master
- 概念：主节点
通过类似于zk集群的选举机制产生 - 功能：管理type类的操作，负责所有indices索引库的创建，修改，删除，shard分片的分配地址，维护并更新整个集群的状态
indices
- 概念：索引库
- 功能：集中保存索引的地方，一个索引就是一个拥有几份相似特征的Document集合
type
- 概念：类型
- 功能： 类型可以理解为索引的逻辑分类/分区，type是逻辑结构，不是物理结构，类似于Hbase的分区字段，查询时可以使用和显示，在6.x版本之前，一个索引库可以有多种类型，6.x版本之后，一个索引库只有一个类型，预计未来会取消
Slaver
- 概念：从节点
Data Node
- 概念：数据节点
- 功能：保存shard分片的数据，可以进行横向扩展
Coordinator Node
- 概念： 类似于impala-server，哪个data node 接收客户端的请求，哪个data node就会转换为coordinator node，并负责该请求的处理，
- 功能：接受并处理客户端请求，负责将请求路由到数据shard分片所在的节点上，判断是否需要修改索引库，若有对indices索引库的创建，修改，删除请求，先将请求转发给master
Field
- 概念：字段，类似于表中的列
- 解释：
Document
- 概念： 一个可被索引的基础信息单元，一条完整数据（rdbms中的行数据，hbase中的rowkey+data），
- 解释：document = documentId + data；其中data可理解为fileds， document在物理上是属于索引库，但是查询是需要指定index/type/documentid；因为type是逻辑存在， documentid类似于rowkey，创建索引库时已经存在，可以自定义，若不自定义，一般会分配20位长度的id，每一条document文档都是以json格式来表示的
Shard
- 概念：分布式实现的基础，将索引库划分为多个shards分布式存储，就是分区，分片
- 补充：每个索引库默认有5个shards，document按照分区规则写入对应的shards分片中；分片规则： documentid的hash值对shards个数取余，分片有主从关系，主分片负责对外提供读写，副本分片负责同步主分片的数据和提供轮询下的读请求，primary shard 主分区， replicas shard 副本分区
Replicas
- 概念: shards分片的备份，副本
- 解释：默认每个shard分片都会1个replicas副本，相同分片的副本不允许在同一台机器， 轮询策略下replicas分片也可以提供读请求，提高吞吐量
