分布式搜索引擎es原理

分布式架构原理
es中存储数据的基本单位是索引
index：mysql里的一张表 ，一个index里可以有多个type
每个type有一个mapping，mapping就是这个type的表结构
接着你搞一个索引，这个索引可以拆分成多个shard，每个shard存储部分数据。
这个shard的数据实际是有多个备份，每个shard都有一个primary shard，负责写入数据
但是还有几个replica shard。primary shard写入数据之后，会将数据同步到其他几个replica shard上去。（高可用）

怎么写入？

首先呢写入一条数据，挑选一个机器，就叫协调节点，协调节点经过hash讲数据路由到对应的primary shard 上，primary shard 将数据同步到replica上去，完成以后，协调节点会返回成功响应给客户端
primary shard会把数据写在内存buffer里，同时写在translog日志文件里
如果Buffer快满了，就会将buffer数据先进os cache缓存一下 然后refresh到一个新的segment file(磁盘文件中)
只要buffer中的数据被refresh操作，刷入os cache中，就代表这个数据就可以被搜索到了

flush=commit全操作
当translog达到一定长度的时候，就会触发commit操作
commit操作：
1、写commit point；
2、将os cache数据fsync强刷到磁盘上去；
3、清空translog日志文件（自动每隔30分种清空，满了清空，手动清空）
es第一是准实时的，数据写入1秒后可以搜索到；可能会丢失数据的，你的数据有5秒的数据，停留在buffer、translog os cache、segment file os cache中，有5秒的数据不在磁盘上，此时如果宕机，会导致5秒的数据丢失。
es读数据过程
1）客户端发送请求到任意一个node，成为coordinate node（协调节点）
2）coordinate node对document进行路由，将请求转发到对应的node，此时会使用round-robin随机轮询算法，在primary shard以及其所有replica中随机选择一个，让读请求负载均衡
3）接收请求的node返回document给coordinate node
4）coordinate node返回document给客户端
es搜索数据过程
1）客户端发送请求到一个coordinate node
2）协调节点将搜索请求转发到所有的shard对应的primary shard或replica shard也可以
3）query phase：每个shard将自己的搜索结果（其实就是一些doc id），返回给协调节点，由协调节点进行数据的合并、排序、分页等操作，产出最终结果
4）fetch phase：接着由协调节点，根据doc id去各个节点上拉取实际的document数据，最终返回给客户端
在数据量很大的情况下（亿级别）如何提高查询效率啊？

性能优化的杀手锏——filesystem cache
仅仅只是写入es中要用来检索的少数几个字段就可以了，比如说，就写入es id name age三个字段就可以了，然后你可以把其他的字段数据存在mysql里面，一般是建议用es + hbase的这么一个架构。
hbase的特点是适用于海量数据的在线存储，就是对hbase可以写入海量数据，不要做复杂的搜索，就是做很简单的一些根据id或者范围进行查询的这么一个操作就可以了