1.es的分布式架构原理能说一下么(es是如何实现分布式的啊)?
存储数据的基本单位是索引,比如你现在在es中存一些订单数据,你就应该在es中创建一个索引,order_idx,一个索引差不多就是相当于mysql中的一张表。index -> type -> mapping -> document -> field。
index:mysql里面一张表
type:详单于订单分类。例如一个是实物商品订单type,一个是虚拟商品订单type;很多情况下,一个index里可能就一个type,但是确实如果说是一个index里有多个type的情况,你可以认为index是一个类别的表,具体的每个type代表了具体的一个mysql中的表
mapping就是这个type的表结构定义,往index的mapping里面写一条数据就叫做document。每个document有多个field,每个field就代码这个document的一个字段的值。
【具体存储方式】shard上存储。每个shard会做备份。primary shared做写入数据,会将数据同步到其他replica shard上去。
【集群】多个节点会选举出一个master节点。这个节点是负责管理工作。维护索引元数据,切换primary shard和replica shard身份。master宕机了,会重新选举出一个master。如果非master节点宕机了,转移primary shard的身份到其他的机器上的。恢复了之后会把空缺的replica shard分配过去,同步后续修改的数据。
2.es写入数据的工作原理是什么啊?es查询数据的工作原理是什么啊?
a)写的过程
1)客户端选择一个node发送请求过去,这个node就是coordinating node(协调节点)
2)coordinating node,对document进行路由,将请求转发给对应的node(有primary shard)
3)实际的node上的primary shard处理请求,然后将数据同步到replica node
4)coordinating node,如果发现primary node和所有replica node都搞定之后,就返回响应结果给客户端
b)读数据
写入了一条document,这个document会自动分配一个全局的唯一的id,可以通过docid进行hash路由到对应的primary shared上面去。也可以指定doc id,比如用户订单id,用户id
1)客户端发送请求到任意一个node,成为coordinate node
2)coordinate node对document进行路由,将请求转发到对应的node,此时会使用round-robin随机轮询算法,在primary shard以及其所有replica中随机选择一个,让读请求负载均衡
3)接收请求的node返回document给coordinate node
c) es搜索数据过程
1)客户端发送请求到一个coordinate node
2)协调节点将搜索请求转发到所有的shard对应的primary shard或replica shard也可以
3)query phase:每个shard将自己的搜索结果(其实就是一些doc id),返回给协调节点,由协调节点进行数据的合并、排序、分页等操作,产出最终结果
4)fetch phase:接着由协调节点,根据doc id去各个节点上拉取实际的document数据,最终返回给客户端
写数据库原理:
写入buffer以及translog日志。写数据的时候先写到os cache中,每隔一秒钟写入一个新的segmentfile,这时候就可以进行查询了。这个也可以手动调用es的restfulapi活着java api,手动执行refresh。当写入不断增加的话,translog文件会越来越大,达到一定程度会执行commit操作。1.写commit point 2.将os cathe数据fsync强刷到磁盘中去。3.清空translog日志
注意:1.translog日志也是写在osche中,默认5秒钟刷到一次到磁盘中。如果宕机会丢失数据,可以设置每次写操作都会异步到磁盘中,但是性能会差很多。如果需要数据一定不丢失,可以写入buffer的时候,同时写入磁盘上的translog。2.segment文件多了会进行merge操作。
四个核心:refresh、flush、translog、merge
3.es在数据量很大的情况下(数十亿级别)如何提高查询效率啊?
(1)性能优化的杀手锏——filesystem cache
a).让写入es的数据小于等于,或者是略微大于es的filesystem cache的内存容量
b).搜索几个关键字。如id,name,查出来的数据去hbase中获取。
(2)数据预热
对于那些你觉得比较热的,经常会有人访问的数据,最好做一个专门的缓存预热子系统,就是对热数据,每隔一段时间,你就提前访问一下,让数据进入filesystem cache里面去。这样期待下次别人访问的时候,一定性能会好一些。
(3)冷热分离
将经常用的数据放到一个索引中。确保热数据在预热之后,保留在filesystem os cache。
(4)document模型设计
在放到es中就进行了联合查询,查询出来的结果在程序中执行。
(5)分页性能优化
1)不允许深度分页/默认深度分页性能很惨
2)类似于app里的推荐商品不断下拉出来一页一页的(scroll api)
4.es生产集群的部署架构是什么?每个索引的数据量大概有多少?每个索引大概有多少个分片?
(1)es生产集群我们部署了5台机器,每台机器是6核64G的,集群总内存是320G
(2)我们es集群的日增量数据大概是2000万条,每天日增量数据大概是500MB,每月增量数据大概是6亿,15G。目前系统已经运行了几个月,现在es集群里数据总量大概是100G左右。
(3)目前线上有5个索引(这个结合你们自己业务来,看看自己有哪些数据可以放es的),每个索引的数据量大概是20G,所以这个数据量之内,我们每个索引分配的是8个shard,比默认的5个shard多了3个shard。