UDN-企业互联网技术人气社区

板块导航

浏览  : 1657
回复  : 0

[讨论交流] 对数据库的tradeoff分析

[复制链接]
哥屋恩的头像 楼主
发表于 2016-10-23 12:57:36 | 显示全部楼层 |阅读模式
  分布式数据库方面的技术栈要列是可以列很多,这些资料的学习属于领域专业性较强的事。由我来写一篇如题的文章文章实属不应该,原本需要研究人员来写更为合适,谁知我一直没看到,索性我来写一篇看上去没什么大毛病的文章来抛砖引玉。如果恰巧你有兴趣,那随我一起来思索分布式数据库的:tradeoff

  “哗众取宠”的分布式技术栈

  我粗略的读过 The Google File System 与 Bigtable: A Distributed Storage System for Structured Data ,这两篇算是分布式数据库的开端,论文里有谷歌项目应用的介绍,我不在这里详细的说,但我们在看待一个新东西时,最好结合着场景来看,因为这往往是tradeoff的根据。这两篇论文的融合如图所示:

d.png

  来自bigtable论文

  BigTable将物理化的一些文件都存储在了GFS。BigTable有两大核心:Master Server 和Tablet Server,后者现在被新起的 spanner 继续沿用。先看Master Server,其实它主要是用来做数据的存储以及分布式调度的, 而真正的读写操作则是由Tablet Server 来完成。Jeff dean 领导开发过一个项目 leveldb (代码量不大),与其相仿的角色其实是后者(穿插一句Spanner中用的是Colossus就是二代Google File System,但与leveldb关系不大,只是聊到存储引擎模块的东西了,拉一些相互可替代的东西出来延伸.)聊多几句leveldb,因为它使用了近来又再度热起的核心算法lsm-tree。facebook 在这方面也开了个分支叫rocksdb以及port到了mysql上叫myrocks。myrocks的推出在在insert上力压innodb,其实不乏有误导一些初学者之意。我简单的展开一下与传统的b-tree作对比,再聊引擎层面基本运作原理的共性。

  引用wiretiger提供的lsm-tree在读写方面的性能特点与b-tree的比较,可以参考下图:

c.png

  来自wiretiger的wiki

  上图链接

  看完算法层面的针对读写上的tradeoff。我们回到开发者视角不难发现,整个框架的运作原理,与传统数据库的引擎实现近乎一致:

  step1: 将事务产生的日志信息写入日志

  step2: 将数据放入buffer中,等待批量写盘

  step3: 批量写入的索引组织方式不同,如果单纯说写入,就算法理论基础就可以决定lsm-tree 要优于b-tree,只要你细看lsm-tree的paper,里面对算法实现的解释非常详尽

  step4: 依照各自协议存储入文件系统(研究过mysql文件系统源码的同学不难发现,设计非常巧妙精良,同样推荐一个链接,里面的两份pdf可以帮助你了解mysql持久化层的文件结构)

  了解分布式数据库“开端”的结构体系的后,不难发现传统的数据库实现结构上并没有什么大毛病,没有什么新的概念在里面。但分布式数据库在扩展性方面确实得到了K-V结构上的不少好处。所以不同点在于:事务模型的不同,存储算法上的不同并非关键。

  事务模型

  先带着事务模式上的不同的想象。先看另外一个非常重要的点:面向性。bigtable paper中有一句话:

  These products use Bigtable for a variety of demanding workloads, which range from throughput-oriented batch-processing jobs to latency-sensitive serving of data to end users.

  Bigtable面向的是海量数据处理,说白了有点批处理的味道,专业点就叫olap。通过更详尽读论文会发现BigTable 解决的项目场景的业务复杂度实属有限,或者我们可以换个角度再看,比如:为何spanner+f1会出来?为何它还深度构建了关系模型呢?在应用中,谷歌用它替代的mysql sharding应用,而并没有去替换的BigTable 的场景下的业务又是为何?

  虽然数据量大是共性,但绝对不是给这两套体系划出临界线。恰恰称为“newsql” 的spanner + f1在旨在灵活性上,从理论上看,它还很可能一定程度的造成了在简单模型业务下吞吐量的一定程度下降(由于没有具体测过也找不到数据支持,请慎理解)。我将在下文中结合着paper提供的细节中,再与谷歌对f1的运用作具体分析。这套新模型tradeoff的点到底是不是就在灵活性上。

  灵活性

  在spanner论文中有阐述到一点:Bigtable被设计成缺失跨行事务的框架导致了用户频繁的抱怨。因此原本mysql的场景下的业务在遇到数据量增大时,由于缺乏跨行事务则很难直切换至Bigtable的框架。再而著名的Megastore在谷歌应用:Gmail, Picasa, Calendar, Android Market, AppEngine项目中应用良好。我猜因为mega恰如其分的规避了跨行事务上的缺陷,谷歌才认为有构建Spanner的会带来关系模型与高扩展性的可能性融合,进而形成的研发动力。谷歌根据这些经验决定引入跨行/跨表等特性,充分的以关系模型为契机建立新型的分布式数据库,号称newSql,同时通过f1的扩展,非常接近的支持SQL类型的过程式语言,同时减少了替换成本。注意谷歌的分布式事务实现应用了perlocator的接口,并在这篇论文中,谷歌还提供了truetime API这项黑科技给perlocator,相辅相成堪称完美,在perlocator中的oracle timestamp对全球性的事务保证以及性能都有待考究。

  那么我想当时,谷歌力推bigtable的主要动力应该就是random access的问题,毕竟存文件系统没什么用。有了Bigtable的强大的分布式能力的加入则可以解决大量web index的随机接入的问题。所以个人认为你不应被谷歌当初在 nosql方面的作为中,出现的新颖的Data Model,什么key-value/什么Column Families之类的所迷惑。这不是创新,不是进步,而是当你真正的想让它能正常的支持可随机接入时这些设计应该都是必然。而真正支撑这一切的都是业务场景上的倾向所需。

  至于谷歌最新呈现出的spanner,其实就是建立在有可能满足业务灵活性与可扩展的一次“可能性”的革新。谷歌一直带有全球化的野心,带有弥补跨行跨表场景的需求指向,带着对关系理论对业务使用上的肯定的动力,才有了spanner,所以在它其实解决的是原有mysql sharding场景下的痛点。这也意味着谷歌真正想竞争的领域是cap理论的尽可能实现,以及挑战了关系型数据库在扩展性上的缺陷。然而延迟与稳定性谷歌正在竭力去完善,但看起来依旧需要待考验。这就是业务灵活性取向 tradeoff

  或许不少人,因为在使用关系型时,遇到各种使用上的缺陷,曾怀疑过它的存在的价值,然而今天看来,谷歌却在做融合之事,略显荒谬。下面我不会给出任何结论,单纯的提我们应该思考的几个点的来看看关系模型与NoSQL的融合价值所在。

  关系型与NoSQL为何需要融合?

  既然如上section看到了关系型已再入,不妨重新审视关系模型,需要看的paper肯定是;E F codd。这篇文章在introduction里给了一句挺优雅的提醒了我们:

  the principal application of relations to data system has been to deductive question-answer in system.

  这句话的优雅之处在于数据库的本质其实就是一种简单应用与数据组织背后的问答关系。顺延着这个思路,我搜到了一篇文章:NoSQL Data Modeling Techniques,里面有两句综述同样耐人寻味的话:

  关系型的设计理念:“What answers do I have?”

  nosql的设计理念:“What questions do I have?”

  先不对这两句话做过多的解析,希望通过下面的文字能让你自然的想清楚这两句话的含义。

  很多人在使用关系模型的数据库时,受尽各种join/各种行列转换的苦,或许有人会认为这是关系模型的错,或是根本就忽略了关系模型概念直接归罪于sql或数据库本身。有种即便再优秀的优化器都难解你心中的忧伤的感觉。(这也为很多dba创造了工作的机会)

  事实上,很多人都以为在为数据库的使用买单,他们去研究优化器,去判断为何它失灵,这似乎与研究PL领域的编译器那样高能般的存在。想明这点或许你会察觉到其实这并非数据库的错,更与sql本身无关,sql这种面向过程式的表达已经非常简单优雅了,所以问题始终需要回归到关系模型身上。

  那么再考虑一下,是不是关系模型只有它这些看得见的问题,却没有其他实质上的意义呢?我搜遍了甲骨文的公开文档,没有在这方面做足够多的论述,索性扭头先看nosql的意义何在?它又遇到了什么问题?编程带来了前所未有的质变吗?

  normalization Vs. denormalization

  如果把关系模型的做法叫作normalization,那么nosql则叫作denormalization。这冲破规格化的行为可以算是nosql革命的口号!肯定有不少人认为nosql的使用让一些复杂的sql无需再忍受join的脑残,行列转换不再痛苦,column-base是王道。我不得不承认columne-base在一些场景下的好处,比如:一个事件的追踪,有时间序列性的需求。这样的好处也避免了让某个key值重复的出现的问题,hbase的玩家应该对此乐此不疲。nosql的分类其实远比我现在提到的多,根据目前存在的需求所向与延续拓展分了以下几类:

  key-value 如:memcache redis的一部分功能

  对value的要求高了又有bigtable类型的数据库(map嵌套)

  对map的使用了其他想法后,便有了document,如mongodb这类用schema来format value去规避map嵌套的改变和索引加入

  elasticsearch这种搜索型的nosql数据库也算个方向的发展了起来

  琳琅满目,他们实现本身又是互不替代的。这算是nosql数据这种反规格化的运动的成效吗?刚才第一个section已经论述了nosql的实现本身更多的面向性是海量数据的吞吐量问题。有很多人一见到海量数据就放大了对海量的理解,这些理解里甚至充斥着各种对事务到底一不一致性的跑题性乱入,然而nosql自身灵活性的问题确实在很多场景覆盖上愈演愈烈,遭用户牢骚。

  或许你曾经思考过查询不就是函数式语言里面的filter, map等操作。你认为像MapReduce这样的分布式计算解决了目前关系式在查询上的代数拙劣的表达。我在这再次希望你好正确的意识到关系理论下的灵活性,但不是让你摆出一副摒弃nosql的样子。

  结束:

  单机在今天可能已成为你们抨击的理由,RAC或许也因为共享存储的梗对它各种浅置。我认为这未必是一个好的技术人的态度。为何不以正确的姿态认知为何谷歌去融合关系型呢?BigTable不行了吗?MySQL就已经到头了吗?只有NewSQL才是未来吗?

原文作者:写程序的胖头鱼 来源:开发者头条

相关帖子

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关于我们
联系我们
  • 电话:010-86393388
  • 邮件:udn@yonyou.com
  • 地址:北京市海淀区北清路68号
移动客户端下载
关注我们
  • 微信公众号:yonyouudn
  • 扫描右侧二维码关注我们
  • 专注企业互联网的技术社区
版权所有:用友网络科技股份有限公司82041 京ICP备05007539号-11 京公网网备安1101080209224 Powered by Discuz!
快速回复 返回列表 返回顶部