Gleasy的分布式实时索引平台CloudIndex

声明
本文为Gleasy原创文章,转载请指明引自Gleasy团队博客

一。CloudIndex是什么
是一个独立运行的平台级后端系统,不会直接对用户提供服务,通过API方式对应用服务器提供服务。API全部采用HTTP接口。

二。它能干什么
CloudIndex,分布式实时索引平台。作为数据库的有效补充,它替代了关系数据库的复杂检索功能,完全替代了like语句,还提供基于分词的检索能力。除此之外,它使用分布式技术来解决数据库所短缺的海量存储问题,单点故障问题,写单点问题。Gleasy但凡涉及检索的功能,或多或少都要与之打交道,它是名副其实的核心系统。

三。技术特性
支持海量存储和检索;
准实时索引(索引延时在200MS以内);
多写多读,无单点故障,不存在写单点问题;
横向和纵向动态负载均衡(数据分片 请求负载);
性能优秀,写TPS>10000,读TPS介于2000-5000之间(i5,16G内存)

四。产生背景
条件检索在系统规模不大的时候,使用数据库的like基本上也够用。不过随着数据量的暴增,一个like语句可能会造成CPU 100%,更不用提大规模海量并发了。由于索引平台是核心系统,在选取何种技术来实现这个问题是我们十分谨慎。最初考虑Lucene,但完全自主研发,似乎工作量太大;后面有考虑ElasticSearch,从介绍上看还是极为强大的,甚至也涵盖了分布式的大部分特性,不过缺点是社区太冷清,文档和插件稀少,且也未见成熟;然后又对比了solr和solrCloud,solr4涵盖了solr cloud的特性,并且有效弥补了Lucene的工作量大的缺点,加上社区内容丰富文档齐全,最终还是考虑基于solr来实现,至于是否使用solr cloud,我们谨慎地反复实验solr cloud的特性,包括分布式,Shard,Replica等,最终还是放充使用,一个关键的原因不太认可solr cloud的Leader-replica机制,所有写操作都必须提交到leader,然后由leader分发,效率太低;另外就是它的维护复杂度太高,通常越是功能强大的系统维护成本就越高,solr cloud也是如此,由此带来的风险是当问题出现或者需求不被满足的时候,我们不得不从代码入手进行二次改造。综合考虑以上因素,最终我们选择solr4但放弃使用它的solr cloud功能,仅保留它的实时检索能力,相当于我们使用的是单机模式的纯solor。我们在它基础上做上层包装,所有分布式的特征全由自己来实现。

五。设计思路
沿袭solr cloud的概念,CloudIndex在物理架构上和solr cloud没有本质区别,最大的区别在于实现方法不同。
CloudIndex没有Leader和Replica的概念,写入索引时,将索引更新内容写入MQ,所有结果按顺序消费对应的MQ来写入数据,并数据保证一致性。
CloudIndex使用人工shard进行数据划分,最大程序保证分片的合理性。

1. Collection(完整索引示间图)
casino online alt=”Collection” src=”http://rdc.gleasy.com/wp-content/uploads/2014/01/Collection.png” width=”683″ height=”400″ />

2.Solr与索引对应关系图

3.建索引示意图

4.分布式查询示意图

六。其它
CloudIndex已经线上平稳运行2年,实时支撑起Gleasy全部项目的检索工作。无论在性能及功能,可维护性方面都经受住了检验。还是一句老话,没有最好,只有最合适。

此条目发表在 Java技术, 分布式技术, 数据库技术, 运维 分类目录。将固定链接加入收藏夹。

Gleasy的分布式实时索引平台CloudIndex》有 2 条评论

  1. Pingback 引用通告: Gleasy分布式架构体系介绍 | Gleasy团队博客

  2. Pingback 引用通告: 高性能大型WEB应用技巧总结 | Gleasy团队博客

发表评论