从需求出发来看关系模型与非关系模型–时代的变革1

上次咱们谈到，由于互联网应用的实际需求与传统数据库之间出现了不匹配的状况。

因而，破坏与重构就成为了新时代的主音。

对互联网应用而言，最急需的需求，就是处理大量用户输入的海量数据，进行一些逻辑处理后再将结果返回给用户。所以，对于在线数据处理来讲，可水平扩展的容量指标，可无限增加的写入tps和读取qps，是互联网企业的最大，最急需的需求。

相比较而言，为了追求性能和容量的尽量最大化，其余的指标则被迫的推到了后面。这也很是容易理解，性能不够，容量不够，直接面临的是不能提供服务，做为互联网应用，若是不能为用户带来服务，其核心价值就受到了最大的挑战。所以，互联网应用的关键需求就是，高可用，高可扩展，高性能，其余则是额外的追求。所以，综合来看，互联网在线处理的需求排序列表基本上能够认为是：数据的扩展性>请求的响应时间尽量短>down机时间尽量短>成本尽量低>可自动快速恢复>数据的读取一致性>程序开发者的方便与快速响应需求。

但历史的演进也是渐进式的发展的，必须考虑到前人们的经验。由于关系模型的流行，关系数据库也天然而然的是当时人们可以找到的最安全合理的扩展目标，也正由于如此，传统数据库的水平切分，是第一个尝试解决这个问题的方案。

在这类方案中，用户通常会被要求使用某一个简单的切分条件将数据均匀的分散到几台甚至几百台数据库中，从而能够作到不管多少数据，均可以经过水平加机器的方式来作到能力的提高，从而使用数据库就能够知足“数据的扩展性”，“请求的响应时间”，“down机时间短”，这几个指标了，但，有好就有坏，使用这种切分的方案后，原来能够运行的SQL或事务却不得不作出必要的限制了，虽然不爽，但与开发成本相比，知足核心需求是第一位的，因此，这个方案是基本符合要求的。

从上世纪80年代到本世纪，大部分应用使用水平切分的方式知足了业务的实际须要。天然而然的，人们开始要求更多，但愿可以更简单的解决问题。天然的，会有人提出来：关系数据库咱们用着很好，关系模型表达也很是清楚和明确，你们都熟悉，大家为何不作个中间层，从而实现对上层彻底透明，而且与关系数据库彻底兼容的数据访问层出来呢？这样咱们就能够既不用修改咱们的业务逻辑，又能够享受到近乎无限的水平扩展能力了不是么？

想法很好，因而就有很是多的人开始往这个方向努力，他们在开始设计之初拿到的需求列表里也是这么写的：能够实现对应用彻底透明的数据库访问，用户不须要关心下层是什么数据，只须要按照关系模型写业务逻辑，其余东西都应该可以自动作好。

然而开始着手去知足这个需求的时候，就发现了几个必需要解决的问题。
1.多机事务怎么作？2.多机join怎么作才能很是高效？3.分布式索引怎么作？

嗯，其实这些问题一直困扰人们到如今都没有获得解决，为何呢？由于硬件碰到了天花板。

下面咱们来作个简单分析：
计算机是个分型的系统，从cpu设计开始，直到分布式存储，全部的操做处理其实都在作相似的事情。在cpu架构设计里面，最核心的问题就是，一个数据要被多个处理器访问，究竟是共享这个数据呢呢？仍是每次访问都复制一份呢？
也所以才会有CPU的三种标准处理方式，A方案：全局共享（smp）。B方案：全局不共享。以及C方案：部分共享部分不共享（numa）的折中方案。
在分布式存储领域也是同样的，想要水平的扩展，势必须要尽量的减小竞争的数据。而若是碰到全部机器都须要读写的数据时，只有共享才能作到最好的性能。数据库sharding明显的属于mpp架构，所以碰到须要多机器都须要读写的数据时，只能依靠机器与机器之间的通讯来完成数据读写的协调性工做。

这种协调，在单机的时候会使用cpu之间的消息队列，或者数据总线。而在分布式领域，协调就必须依托网络来进行了。而网络就是个硬件天花板。

既然要谈到天花板，咱们就须要对网络来进行一个简要的分析，这样才能更容易的理解这天花板在哪里：做为一种通讯的媒介，咱们把它抽象为如下几个关键的指标：延迟，吞吐量，安全性。
为了比较方便，咱们以cpu到内存的数据传输通道做为对比：
延迟网络：30ms内存：21ns
吞吐量网络：100mb/s内存：800ms/s
安全性网络：有不可达问题内存：无不可达问题

明显可以看到，延迟增长很是多，吞吐量则有明显的下降。又由于网络不够安全，因此须要更屡次的网络交互才能作到更高的安全性。在这几个属性的中，最麻烦的是延迟，由于延迟与距离相关，当距离变远的时候，延迟就会没法控制。咱们在后面还会更深刻的来讨论网络在分布式领域中形成的影响。

所以，就算是算法十分完善，咱们也没法下降在分布式领域内针对同一个数据的延迟。而这直接致使原来可能可以进行的关系代数或事务过程，延迟直接变大一百倍。以致于业务没法接受！
关系代数模型也有相似的问题，由于查询共享的数据须要与多台机器交互，延迟比使用内存增长不少，所以延迟也被迫的增长了不少。

因而，咱们就悲剧的发现，想作到与单机数据库同样的事务或一致性体验，在分布式存储领域则再也不可以体验的到了。

由于这件事没办法获得很好的解决，因此这里的解决方案就发生了分化：

咱们在这里不会去评价一种思路的好坏，不过一切思路和想法的最终判断标准是他可以解决多少实际的问题。

一部分人从本身的实际场景出发，发现本身在一部分场景中(好比存储业务日志)只是在使用简单的接口，而基于分布式环境实现关系代数模型的难度又是这么的使人沮丧。那么，天然而然的会产生一种推论，抛弃关系代数模型不就行了？！
因而一个概念产生了：nosql。不要sql，扩展的广一点就是不要关系代数模型和一致性模型。这一派的核心思路比较激进：既然关系代数模型性能那么低，干脆丢弃它而选择更简单的层次模型不就解决问题了？由于实现一个层次模型的keyval数据库实现相对的容易，因而根据nosql这一理念，在很短期内就出现了一大批nosql的产品。这类产品的基本特征就是，只实现了简单的keyvalue接口，主要关注于数据的自动运维，以及利用新的存储引擎实现来达到写的优化，从而可以下降成本。比较有特点的nosql系统是cassandra，hbase，mongodb等。
我自己以为这个想法挺不错的，惋惜有一批nosql的开发者为了本身的利益，把nosql宣传成了无所不能的开发神器，彻底无视其致使的开发成本上升的负面做用，这就比较无语了。大部分状况下，开发效率比自动的数据运维重要的多，在这种状况下盲目的使用原始的层次模型接口来完成功能，可能会极大的下降生产效率，还望各位读者当心。

另外的一些人认为关系代数模型与扩展性无关，但愿可以用新的方式来支持分布式关系代数模型，这种尝试目前有个统一的称呼：newsql。他们的主要思路就是只作适当的权衡，并努力将关系代数模型在分布式环境下进行重构。

在这个领域内的一些比较有特点的想法是基于内存的数据库实现，他们假定将来的数据库应主要依托更大的内存和网络来进行构建，这样，数据库就成功的规避了慢速磁盘设备对系统形成的影响，让延迟降低到能够接受的程度。比较具备表明性的是voltdb，mysqlcluster等

在另外的一些尝试中，人们假定事务冲突的几率很小，而事务的数量则很大，依托这个假定，人们使用传统意义上的读写锁来实现数据的读写一致性，从而可以支持数据库的查询。这类实现中最出名的就是google的megastore和spanner

而传统的数据库阵营也在逐渐的被互联网的需求所引导，逐渐的将本身历史的包袱逐渐丢下，以更轻盈的体态来面对互联网应用的需求了。

而针对不一样读取场景进行优化的实现就更如皓月繁星那样多了。。

在咱们快速的浏览了这么多针对如今问题的尝试思路以后，让咱们针对目前的人们针对在线海量数据库的需求作一个简单的总结吧：

从目前来看，原教旨的nosql运动已经遇到了瓶颈，虽然在实际的应用场景中，人们能够在开始将本身的用户模型使用通过精心设计的keyval引擎进行实现。不过随着新业务需求被不断的提出，用户会逐渐的发现本身的大部分的开发内容是：将原有的数据，按照另一个key进行组织，而后提供给用户进行查询。这个过程则正是关系数据库主要可以解决的问题。

在知足了基本需求之后，用户对于方便性的需求会逐渐的变为矛盾的主要方面，所以，借鉴传统的关系数据库的优秀经验，结合互联网应用的实际需求进行适当的改进和裁剪，是目前全部存储领域从业人员共同努力的方向。

但在当前，由于用户的主要需求没能获得所有的知足，针对不一样的用户场景，产生了不一样的选择，因而在目前来看，一种存储模式解决全部问题的时代已通过去了，在存储领域进入了战国时代。

面对这么多的存储产品，一个问题天然而然的就产生了：面对这么多不一样的数据库产品，个人场景适合什么样的存储呢？在后续的文章中，我也将尝试从关系数据库出发，结合分布式场景中的实际需求，给你们阐述在分布式存储领域中面临的新挑战和应对这些新挑战的新的尝试。以期让你们可以快速的掌握分布式存储的核心脉络，作到知其然而知其因此然，从而可以快速的选择或实现适合本身的分布式存储产品。