SenseiDB架构设计分析
1. Sensei介绍
- 全文检索
- 实时更新
- faceted search
- key-value查询
- 在高并发更新与查询性能高
- 支持与Hadoop集成
- 支持BQL语法
- 集群维护简单
- 支持实时索引
2. 整体架构
- Sensei Node
- Zoie System
- Data Provider
- Broker
- ZooKeeper
- Data Gateway
- jms
- 文件
- jdbc
- kafka
3. 均衡策略
4. 索引过程
- Data gateway获取到新索引数据
- 每个Sensei Node都从Data gateway获取到所有新索引数据,并各自过滤出自己负责的数据进行处理,其他的直接丢弃,这样做可以让Data gateway不用关注分区的策略,在加节点的时候比较简单
- 在处理索引数据的时候,Sensei Node为每个分区启动一个Zoie System,也就是说每个Sensei Node中对应每个分区有一个独立的索引
- 不同的Sensei Node负责的分区可以有相互重叠的部分,以此当做镜像服务器,镜像服务器也可以提供检索服务器以此提高负载能力
5. 检索过程
- 用户检索请求可以发送到任意一个broker,每个broker都是等价的,可以提供相同的检索服务
- broker根据用户查询的均衡字段,按照负载均衡策略分发到不同的Sensei Node进行检索
- 在分发检索请求到Sensei Node的时候,由于每个Sensei Node负责多个分区的数据,所以还需要在请求中指定需要检索的分区
- 对于全局搜索的情况broker会把多个sensei node的结果进行合并
6. 错误恢复
- 如果是Data gateway挂了,整个系统会停止新的索引,但是检索不受影响,只要Data gateway重启之后,各个Sensei Node就会继续获取新数据
- 如果是Sensei Node错误,对于可以持久化的数据源,如文件、http、数据库等,Sensei Node重启之后,就会从后处理的数据版本开始重新拉取数据建索引,自动完成恢复。但对于jms的非持久化的数据源,好像索引会丢失
7. 在线扩容
- Sensei提供的均衡策略是一级映射的关系,所以其扩容只能限制在一个服务器中本负责的多个分区拆分成多个服务器的情况,对于一个服务器只有一个分区的情况,只能够建立镜像服务器降低系统负载
- 由 于Sensei建索引是由Sensei Node主动向数据源拉取数据的,所以只要配置好新Sensei Node的分区信息,直接启动,新节点便自动从数据源抓取建索引的请求重建索引并加入集群,但是看代码分析,如果以jmq作为数据源,好像没法实现在线的 扩容,只能先停止往jmq发建索引请求(停止建索引),然后从把现有分区索引文件拷贝到新的节点,启动新服务器后再继续往jmq发建索引请求。
- 值得注意的一点是,在一开始划分分区的时候,如果划分的分区太多,会导致索引在物理上分成多块,对于个人搜索效率会比较高,但是会影响全局搜索的性能;如果划分的分区太少,则扩容受限
8. 参考资料
- 官方主页:www.senseidb.com
- shadowhunter的博客: http://johnnychenjun.blog.163.com/blog/#m=0&t=3&c=sensei
相关文章