ES主要IW问题
这里我们汇总ES 的主要问题
IW
-
为什么要用Elasticsearch?
因为在我们商城中的数据多, 模糊查询, 模糊查询前置配置, 会放弃索引, 导致商品查询是全表扫面。 百万级数据库中, 效率非常低下。而使用ES做全文索引, 我们将经常查询的商品的某些字段, 比如说商品名 放入索引库, 可以提高查询速度。 -
ES 如何Master 选举?
ES 选主ZenDiscovery 模块, 主要包括Ping 和 Unicast 两部分。
对所有master 节点根据nodeId 字典排序, 每次选举每个节点都把总集所知道节点排序, 然后选出第一个节点, 暂认为是master 节点。
如果对某个节点的投票达到一定(n/2 +1 ) 并且该节点总集也选取自己, 那这个节点就是master。 -
ES 节点选举master 脑裂?
集群master 候选数量不小于3时, 可设置最小投票通过数量 (discovery.zen.minmum_master_nodes) 超过所有节点一半以上来解决脑裂问题; 当候选数量为两个时, 只能修改为唯一的一个master 候选, 其他作为data 节点,避免脑裂。 -
ES 索引文档的过程
协调节点默认使用文档ID 参与计算(routing), 以便为路由提供合适的分片
shard = hash(document_id) % (num_of_primary_shards)
当分片所在的节点接收到来自协调节点的请求后, 会将请求写入到Mem buffer, 然后定时写入FileSystem Cache, 这个从Memery Buffer 到Filesystem cache 的过程就叫做refresh。
ES 是通过translog 的机制来保证数据的可靠性的。 其实现机制是接收到请求后, 同时也会写入到translog 中, 当FileSystem cache 中的数据写入到磁盘, 才会清除掉, 这个过程叫做flush;
在flush 过程中, 内存中的缓存会被清除, 内容被写入一个新段, 段的fsync 将创建一个新的提交点, 并将内容刷新到磁盘, 旧的translog 将被删除并将开始一个新的translog。
flush 触发机制是定时触发(30min) 或者translog 变得太大(默认512M) -
ES 更新和删除文档的过程
删除和更新也都是写操作, 但是Elasticsearch 中的文档是不可变的, 因此不能被删除或者改动以展示其变更;
磁盘上的每个段都有一个相应的.del文件。 当删除请求发送后, 文档并没有真的被删除, 而是在.del文件中被标记为删除。 -
ES 搜索的过程
搜索被执行成一个两阶段过程, 我们称之为 Query Then Fetch;
查询会广播到索引中每一个分片拷贝(主分片或者副本分片)。 每个分片在本地执行搜索并构建一个匹配文档的大小为 from + size 的优先队列。 PS: 在搜索的时候是会查询Filesystem Cache 的, 但有部分数据还在Memory Buffer, 所以搜索是近实时的。
每个分片返回各自优先队列中 所有文档的ID 和排序值给协调节点, 它合并这些值到自己的优先队列中来产生一个全局排序后的结果列表。
接下来就是取回阶段, 协调节点辨别出哪些文档需要被取回并向相关的分片提交了多个GET 请求。 每个分片加载并丰富文档, 如果有需要, 接着返回文档给协调节点。 一旦所有文档都取回, 协调节点返回结果给客户端。
Query Then Fetch 的搜索类型在文档相关性打分的时候参考的是本分片的数据。 -
ES 对于大数据量(上亿量级) 的聚合如何实现?
ES 提供的首个近似聚合是cardinality 度量。 基于HIL 算法。 HIL 会先对输入作hash 运算。
特点: 可配置的精度, 用来控制内存的使用; 小的数据集精度非常高; 配置次数、设置去重的固定内存使用量。 -
在并发情况下, Elasticsearch 如何保证读写一致?
设置 replication 为sync (默认), 这使得操作在主分篇和副本分片都完成后才会返回; 如果设置replication 为 async 时,确保文档是最新版本。 -
ES 中的集群、节点、索引、文档、类型是什么?
-
ES 中的分片是什么?
在大多数环境中, 每个节点都在单独的盒子或虚拟机上运行
索引 - 在ES 中, 索引是文档的集合
分片 - 因为ES 是一个分布式搜索引擎, 所以索引通常被分割成分布在多个节点上的被称为分片的元素。
ES 是一个基于Lucene 的搜索引擎。
居中并且带尺寸的图片: