write down,forget

Diving Into ElasticSearch (5) 分布式架构

<Category: Diving Into ElasticSearch> 查看评论

今天介绍下ElasticSearch的分布式架构,如果你熟悉cassandra、hadoop、mongodb,你会发现ElasticSearch里面有很多他们的影子,没错,ElasticSearch吸收了目前主流的分布式系统的很多特性,下面简单介绍一把。

之前翻译过一篇[译]搜索引擎与时间机器,里面介绍了下作者在设计ElasticSearch的一些想法,现在看起来还是记忆犹新,因为他的这种思路实在是非常新颖,比如ES里面的将数据分为工作数据和持久化数据两种:

工作数据就是正常的提供查询和索引的数据,这部分数据假定是瞬时的,并且是不可靠的,随时可能丢失的数据,而持久化数据则是可靠的,一致的数据,工作数据可以都放在内存中,这样可以保证非常好的性能,而持久化数据则专心保证数据的一致性就ok了,我们自动的分布式系统有CAP原则,通过对数据分离方式,我们很好的解决了C和A的问题,你可能会问,你内存中的数据如果不对了怎么办?不就会影响数据的一致性吗?一方面数据可以从持久化数据进行加载,另外ES节点间的数据会定时刷新和同步,最终确保数据的一致,就算万一机器都歇了,没关系,从持久化目录里面重新加载数据即可。

单前面说的那个还不算什么,如果不能很好的解决动态扩容的问题,那就不算是ElasticSearch了,在ElasticSearch里面,索引目录有如下两个概念:shard(碎片)、replica(副本)

碎片(shard)的意思很好理解,db可以有sharding,索引也可以做嘛,单个索引目录太大,GB级别的索引文件,你再继续往里塞数据,文件合并,优化,有过这种经验的人应该会明白这种痛苦,怎么办?拆呗(china?拆那?),一般的做法是按数据拆,自己按租户,按时间拆等等,很是麻烦,并且拆完了之后的事情也不少,跨目录查询怎么办?更新怎么办?接口要怎么变?这些在ElasticSearch里面都帮你想到了,对你而言,全是透明的,你操作的就是一个索引,你在创建索引的时候,根据索引的规模指定碎片的大小,其他的你就不用管了,至于它里面怎么实现数据的平均分配,其实很简单,就用了一个取模的算法,随机分配到各个碎片中,至于一致性哈希之类的,目前来说完全没有必要。

碎片可以解决单个索引太大的问题,但是凡任何事有利必有弊,索引碎片在实现上其实就分成了很多个索引目录,索引目录越多,对建索引的速度会有提示,尤其是多线程环境,因为我们建索引的时候单个索引目录肯定加锁,一旦涉及锁,势必要减慢速度,不过我多几个目录,不就可以并发执行了吗?是的,ES就是这么做的,但是前面说了,有利就有弊,索引搞得到处都是,ES查询起来就很费劲了,一般情况下,我们在没有使用Routing的情况下(后面再介绍routing),ES会同时多个线程去读取各个碎片的索引数据,然后再合并查询结果,另外在ES的分布式环境下,碎片如果分布在多台服务器上就要加上网络的开销,势必会影响查询速度了,在海量数据的前提下,这些其实都还好,并且ES支持多种查询方式(reflink:search type):

Query And Fetch:

Query Then Fetch:

Dfs, Query And Fetch:

Dfs, Query Then Fetch:

Count:

Scan:

根据不同的查询需求,选择合适的查询类型,会收到意想不到的效果。

先整体看看单ES节点的模块结构吧:

 

再看看一次索引操作

再看看一次查询请求

本文来自: Diving Into ElasticSearch (5) 分布式架构


  1. 很喜欢用你写的程序在READER里读新浪微博的RSS,但是前几天您这边程序做了调整,导致标题行全是省略号,不是微博内容,造成了手机和电脑阅读的不方便,能不能改回以前的效果?谢谢~