广州技术聚会第一期感想之KEY-VALUE的缺陷
赖神跟tim yang 组织了广州技术聚会,这里主要谈谈对 tim yang的”分布式 Key Value Store 漫谈“的感想小记.
其实早说要写了..一来很忙,二来很懒(寒).于是拖到了现在.
tim yang的总体内容还是非常不错,但是有几点小毛病,需要说说.
其一,诉说关系数据库已过时,这点完全出错.这篇文章详细的解说了关系数据库与K-V DB的对比,其实连这篇文章的论点,我也不太赞同,稍后评价.
1.关系型数据库本质上跟 K-V DB是一个体系的产物,其实都是关系型数据库理论下的产物..只是一个带SQL,一个不带SQL(用的是KEY-VALUE),后者早有了,伯克利DB早有了N年了..当然了,因为SQL以及其正统的实体-关系模型,对于某些应用来说,的确不能适应一些实际的业务逻辑的需求..所以国际上有NO-SQL这种聚会..总的感觉有点矫枉过正.
2.tim老大试图以因为要代替关系型数据库作为前提,来讲解k-v store的分布式策略如何避免关系型数据库来讲述,到了后来也有点走样..不过分布式的技术点介绍的蛮好的..其实tim老大若立论于分布式算法这个演讲就完美了.跟赖神讨论了一番,他说,他就当分布式算法来听的,这也是他关心的..这点收获蛮足.
3.K-V DB无法代替关系型数据库,上面提到的文章其实已经讲到了,其根本原因是,K-V DB无法对复杂的业务逻辑做很好的描述.就如现有的关系型数据库无法很好的对树型结构作很好的描述一样(取而代之的是关系型数据库的一个分支,对象型数据库).实体-关系这种描述能力是很强的,作为通用型数据库,还是以关系型数据库为主.
自关系型数据库诞生以来,就有不少人提出过要推翻,最终还是不了了之,其背后其实有深层原因,实体-关系对于描述而言其实跟函数很像,就函数而论,爱因斯坦曾赞叹道:”这个世界的最不可理解之处就这于它是可以理解的”,他也给出一个解释,通过函数,我们可理解这个世界.这是很有道理的,例如汽车跟全球暖化,若通过函数,让他们拥有了关系.他的相对论就让时间与空间产生了关系,对于以前的人们是无法想象了,两者之间竟然存在关联.
实际的例子是,谁用K-V DB快速的开发信息系统,那可得崩溃了不可..描述能力是一个很实用的指标,不同的语言的特点其本质区别就是描述能力的不同,编译器的原理本身是差不多的,为何有这么多计算机语言,主要还是其描述能力的差别.
其二,概念有点混淆,经过跟星星大神的讨论之后,我们严格区分出K-V DB,K-V cache,K-V store是三者完全不同的东西.
1.K-V DB上面已经讲解过了
2.K-V cache本质上来讲是缓存,而不在于其存储方式是否k-v,之所以K-V流行,其原因还是因为hash table速度非常快速,而众所周知的是,memcached正好用了这一数据结构,其实何种缓存结构,视情况而定,我所知道的一些大型互联网公司开发自己的cache的时候,不一定用k-v(因为有了memcached了),而是视业务逻辑而定,去开发链表,队列等cache小软件.
3.K-V store,跟星星沟通之后,认为这是分布式领域的研究领域,确实有人专门当做课题来做研究的,当属这个体系的严格来说,以google的big table和amazon的dynamo为典型.
若了解过一点google一篇论文的”数据中心即是一台电脑”的话,应该知道google站的高度,他们认为一整个分布式系统即可当一台电脑来看待,若以这个观点,big table应该是”这台电脑”的文件系统,这是从架构的出发,提出的新观念..
实际应用而言,k-v store应视为网络文件系统看待,就web而言,对于大量的图片,视频文件的处理,是一件麻烦事.有高可用,数据的一致性等问题存在,所以偶以前一直寻找一个较好的解决方案.google的方案对我们这种庶民来讲,显然过于的贵族化,tim老大的介绍的dynamo显然更好,更庶民一些,也能较好的解决这个问题,当然还有其他的网络文件系统,但有master的限制(基本跟mysql的主从是差不多的,这对分布式系统来说,大打折扣),跟dynamo比,这些软件在分布式算法上不足
其三,K-V结构的软件性能特别好?若让mysql用上新式的分布式缓存(外挂memcached),我看也差不多.剥离MYSQL一些功能,剩下最核心的数据结构,mysql本身的性能也差不多,drizzle正好在做这件事,也在对mysql进行改造.当然,不同的作者对软件的优化不一,肯定存在差异.MYSQL为什么需要memcached缓存作为补充,其原因是MYSQL是一个通用型系统,而memcached是专用型的.即是说,专用型只针对特定问题进行优化,从架构来讲,memcached并不能解决架构的问题,只是延缓架构的问题.再说用memcached的hash table跟mysql普遍用的B-TREE来对比,本身就不公平,谁都知道这个时间复杂度差距有多大.
即是说,应以通用型DB,如MYSQL,辅之以memcached或TT作为补充..TT在这里显然是一个多数据结构的专用型可解决一些特定业务需求.例如若web的流量非常大,某文章列表的标题可存放在TT的双向链表类型的结构中,还可以进行分页的计算,迅速的定位分页.这个需求用K-V的hash table显然不大适合了,用MYSQL的LIMIT和order by不堪重负了(双向链表则连order by都不用做了,这就是专用系统的优势)
感想即这么多,有任何批评指教,欢迎留言.
xiaoxiaolu辛苦了，我也喜欢看不同意见的文章，这里我简单补充下我的观点。
1. “实际的例子是,谁用K-V DB快速的开发信息系统,那可得崩溃了不可”, 不过我的slide中的前几页场景是数据库切分困惑，就是数据规模达到百万之后如何应对。你提到的“信息系统”大多是百万级别以下，他们的需求实际上用10年前的技术都可以满足。
2. 大部分使用了切分数据库的技术后，虽然还是用的MySQL, 但是已经没有join, 没有多表查询，主要sql也是针对uid主键操作，表面上看是用mysql, 骨子里实际已经是k/v设计模式了。
3. 当业务数据更大规模之后，无法避免要面临一个问题，数据存储的趋势，它是需要一个软件还是服务，如果用数据库软件解决，它没帮我们考虑数据扩展的问题，所以我们自始至终都要去做着切分的重复劳动。那如果数据存储服务是一种趋势，key/value比SQL有不可逾越的优势。
Reply
小路 reply on 九月 17th, 2009:
tim老大客气了.你说的这点的确是漏谈了,对于你的说的意思,我还是有不同意见.
第一,K-V结构的确能较好的解决扩展性的问题,但带来的描述的能力降低,其实也在增加开发的复杂度,并且把原来架构师的任务分摊到普通开发者身上,这对开发团队的影响也不小窥,团队培养的成本大幅度提高.
第二,你说的sharding的问题,虽然不断有架构调整与维护的问题,但是sharding只需要简单封装一层,便可以做的对开发者透明,因为人员素质问题,除了极少的公司适用于你说的方案之外(新浪,网易等),其他皆不适合.
这不得不说是一个矛盾,虽然让扩展性的重负解脱了,却让架构师和开发者的职责混淆在一起了,我始终认为架构的改进,是逐步与迭代改进的,一步到位会带来不少的麻烦,迭代改进是我坚信的最重要的开发原则.
dynamo等分布式系统似乎是”大公司的专用系统”,广而推广,有现实的难度.
Reply
小路 reply on 九月 17th, 2009:
另外,对于没有join的使用,主要是性能问题.原因是mysql的join的算法是性能最差的nested loop,简单来说,就是多重循环,这种join的算法当然慢,不过google已帮忙做了改进..发布在mysql 5.4上(google的mysql补丁集成版)
辅之以mysql的Partition,可以降低sharding的使用.良好的架构设计(低耦合),可自然的划分数据库,进一步降低sharding的使用.
依赖uid并不是以KEY-VALUE为设计视角,一切拥有用户的系统,都需要依赖uid..
找更强大的数据库才是正道,比如刘老师推崇的pgsql
Reply
在对关系型数据库不断的进行性能优化之后，可以看到它逐步向k/v转化，使用的关系特性越来越少。
Reply
小路 reply on 九月 17th, 2009:
欢迎老兄的到来.对于老兄说的,也视情况而言,有一些时候,并不一定需要K-V,合理的架构设计就能解决问题
Reply