“简单事务操作”数据库（NO-SQL数据库）应用系统的可扩展性设计的十条原则...

原文：《Ten Rules for Scalable Performance in “Simple Operation” Datastores》By<wbr>Michael Stonebraker and Rick Cattell</wbr>

作者简介：（MIT教授，多家公司和项目的开创者）Michael Stonebraker (stonebraker@csail.mit.edu) is a professor of Electrical Engineering and Computer Science, MIT, consultant and founder, Zetics, Inc, consultant and founder, Goby, Inc., consultant and founder, VoltDB, Inc., and board member, Vertica Systems, Inc.<wbr><wbr></wbr></wbr>

（译者）归纳总结：by Xiangxu Meng（yumengkk@gmail.com）from UPCOM

一、简单操作数据库系统定义<wbr><wbr><wbr><wbr><wbr><wbr></wbr></wbr></wbr></wbr></wbr></wbr><wbr><br><wbr><wbr><wbr></wbr></wbr></wbr></wbr>在一个事务中只对一小部分对象进行读写操作的数据库应用：常见的应用场景为——在线事务处理（OLTP），社交网络（Social network）等；
二、DBMS沿革
<wbr><wbr><wbr><strong>1</strong></wbr></wbr></wbr>、1970年提出的关系数据库为主流：Oracle，DB2，MySQL，PostgreSQL等，他们具有如下特征：
<wbr><wbr><wbr><wbr><wbr><wbr><wbr></wbr></wbr></wbr></wbr></wbr></wbr></wbr>①磁盘存储；
<wbr><wbr><wbr><wbr><wbr><wbr><wbr></wbr></wbr></wbr></wbr></wbr></wbr></wbr>②以表的形式组织的行存储；
<wbr><wbr><wbr><wbr><wbr><wbr><wbr></wbr></wbr></wbr></wbr></wbr></wbr></wbr>③B树作为索引机制；
<wbr><wbr><wbr><wbr><wbr><wbr><wbr></wbr></wbr></wbr></wbr></wbr></wbr></wbr>④写前log机制以支持crash恢复；
<wbr><wbr><wbr><wbr><wbr><wbr><wbr></wbr></wbr></wbr></wbr></wbr></wbr></wbr>⑤SQL作为访问语言；
<wbr><wbr><wbr><wbr><wbr><wbr><wbr></wbr></wbr></wbr></wbr></wbr></wbr></wbr>⑥以行（row）为基础的优化器和执行器；
<wbr><wbr><wbr><wbr><wbr><wbr><wbr></wbr></wbr></wbr></wbr></wbr></wbr></wbr>综合如上特征，我们统称这些数据库为“通用目的事务行存储”（general-purpose traditional row stores (GPTRS)）数据库。主要服务于在线事务处理。
<wbr><wbr><strong>2</strong></wbr></wbr>、现在数据库的用途越来越广，出现了多种数据库和应用，如下表：
<wbr><wbr><wbr><wbr><wbr><wbr><a href="http://photo.blog.sina.com.cn/showpic.html#blogid=6fc2c2850100vhd5&amp;url=http://s1.sinaimg.cn/orignal/6fc2c285ga9df575f65a0" target="_blank" style="text-decoration:none; color:rgb(62,115,160)"></a></wbr></wbr></wbr></wbr></wbr></wbr>



<wbr><wbr><wbr><wbr><wbr><wbr><wbr><wbr><wbr><wbr><wbr><wbr><wbr><wbr><wbr><wbr><wbr><wbr></wbr></wbr></wbr></wbr></wbr></wbr></wbr></wbr></wbr></wbr></wbr></wbr></wbr></wbr></wbr></wbr></wbr></wbr>图一：DBMS发展图——垂直轴代表操作复杂度，水平轴代表读写特性
<wbr><wbr><wbr><wbr><wbr></wbr></wbr></wbr></wbr></wbr>在新的应用中，比如OLAP倾向于基于列的存储和优化；而图表的下部的一些应用具有NO-GPTRS（No-SQL数据库为主）特性，归纳如下：
<wbr><wbr><wbr><wbr></wbr></wbr></wbr></wbr>①key-value存储，如Dynamo，Scalaris等，只提供简单的key和一系列payload的存储，不支持将payload解析为多个对象的功能，不能对非主要属性进行检索；
<wbr><wbr><wbr><wbr></wbr></wbr></wbr></wbr>②文档存储，如CouchDB，mongoDB，simpleDB等，支持包括多个属性的对象存储，并且提供NO-SQL语言或者例程支持，方便对数据的查询；
<wbr><wbr><wbr><wbr></wbr></wbr></wbr></wbr>③可扩展的记录存储，如Hbase，BigTable，Cassandra等，支持不规则宽度记录的存储，支持表的任意垂直和水平分割，一般采取NO-SQL语言查询；
<wbr><wbr><wbr><wbr></wbr></wbr></wbr></wbr>④关注与简单操作的DBMS系统，比如MySQL cluster，VoltDB等，这些系统保留了SQL和ACID，但是实现方式同GPTRS有所不同。
<wbr><wbr><wbr><wbr></wbr></wbr></wbr></wbr>更加详细的分类讨论，可参见【1】。
<wbr>3</wbr>、NO-SQL数据库的繁荣
<wbr><wbr><wbr><span style="word-wrap:normal; word-break:normal; line-height:21px"><wbr></wbr></span>No-SQL</wbr></wbr></wbr>的动机：如上的几类新的数据应用模式，重新限定了ACID（atomic，consistant，Isolate，Durable），包括放松了一些限制（比如将持久行，放松为“最终持久化”或者多副本共存）和仅仅支持单记录操作。

<wbr><wbr></wbr></wbr>这几类应用的特性，可以总结为web应用特性：web应用在开始阶段用户较少，系统负载较轻，但是往往经历爆炸性的增长。这个问题通常的解决方案为：开始阶段只借助一个开源DBMS（如MySql数据库），而后建立多个数据库节点，进行分布式存储。在分布式存储方式下，一个表分开存储（比如一个几亿条的用户名存储，往往需要按照字母划分存在多个服务器的数据库上），数据的操作需要应用程序逻辑进行实现，该方案有如下缺点：

A、数据碎片交叉过滤和合并必须在应用程序中实现；

B、当一个事务中设计到多个节点上数据的操作时，应用程序必须保证数据的一致性操作；

C、规模较大时，节点失效的检测、恢复都很困难；

D、当系统在线时，数据模式的更改很难实现；

E、<wbr></wbr>节点的添加、重配置都变的非常困难和琐碎。

所以，这种web应用的开发者常常极其痛苦，因为他们必须在应用程序中处理这些复杂的任务。所以大多数No-SQL方案就是瞄准解决该问题，但是由于新的方案和解决方式越来越多，造成开发者很难选择使用那些方案。

因此，本文为那些需要开发简单操作客户端系统而传统GPTRS数据库不再适用时，选择合适NO-SQL方案的十个原则。这十个原则，主要针对那些客户端在自己的环境运行的场景，当然，大多数原则也适用于SaaS环境以及“云环境”。

<wbr></wbr>

三、十条原则

<wbr><wbr></wbr></wbr>①选用“shared-nothing”体系架构

<wbr><wbr><wbr><wbr></wbr></wbr></wbr></wbr>如facebook的Web应用需要几百上千的数据处理器，如何将这些数据分布存储和处理？我们可以分别考量如下三种结构可用：

多处理器共享主存架构（shared-memory multiprocessing，SMP)受到存储带宽的限制，很难扩展到几亿条数据的处理和存储；

磁盘集群（disk clusters）体系架构需要处理，数据在磁盘上同步的问题，但前很少有扩展到几十台主机的场景；

只用每个处理器具有自己的存储和计算能力的“无需共享”（shared-nothing）架构才可以支持上千台机器并行：不需要处理复杂的数据同步问题，也没有存储带宽瓶颈问题。

该种结构的限制是：数据良好的划分，网络带宽充足。

综上，选择网络连接的无共享集群结构是最合适的。

②使用高级语言（并不会带来性能下降）

<wbr></wbr>SQL的开销主要由如下五部分组成：

A、优化器选择和执行路径规划带来的开销；

B、<wbr><wbr></wbr></wbr>同DBMS通信带来的开销；

C、<wbr><wbr></wbr></wbr>编码的训练带来的开销；

D、并发控制，灾难恢复，数据完整性处理带来的开销；

E、<wbr></wbr>为了保证本质工作执行而需要的各种保障机制带来的开销。

（该规则处理前三个问题，后两个问题由第三个规则处理）

高级语言带来的好处：

A、<wbr><wbr><wbr></wbr></wbr></wbr>容易编码；

B、<wbr><wbr><wbr><wbr></wbr></wbr></wbr></wbr>不需要了解数据如何存储和组织；

C、<wbr><wbr><wbr></wbr></wbr></wbr>数据模式的修改不会导致代码的大量修改；

高级别语言避免了SQL的解释开销；DBMS的通信开销减少（No-SQL数据库机制提供常用的索引、查询例程，可供高级语言直接调用）；降低了编码难度。

③谨慎的使用主存数据库

<wbr><wbr></wbr></wbr>主存数据库很容易提供TB级别的数据处理，因此，从原理上而言，可以上千倍的提高系统查询速度（主存访问比磁盘访问至少快上几百倍）。

<wbr><wbr></wbr></wbr>但是主存数据库并没有有效的降低，锁机制，多现成，缓存机制，并发机制带来的开销。只是降低了数据在磁盘和处理器间的开销。因此，选择主存数据库时要谨慎，选择对各种保障措施的开销规避比较好的系统。

④SO数据系统具有高可用性、自修复能力

<wbr><wbr></wbr></wbr>在硬件越来越便宜的趋势下，系统要做好冗余机制，避免发生故障时，长时间系统不可用问题。因此，简单操作系统通常都具有自修复能力（故障节点自检测、数据重划分等机制）。同时，还要考虑到做好灾难恢复系统以应对地震、海啸等灾害。

⑤持续在线

<wbr></wbr>对于用户而言系统必须持续在线，对于模式变更、索引变化、重配置、软件升级等操作，必须保证服务持续在线。

⑥避免多节点操作

<wbr></wbr>对于SO的可扩展行而言，两个条件必须满足：

A、数据和应用负载在多个服务器间彻底分割（读操作可以采取复制机制，而写操作却需要依据主键保持一致）；

B、数据操作不要跨越多个节点（多节点操作必定带来额外开销）。

⑦不要试图自己建立ACID一致性

<wbr><wbr></wbr></wbr>在NO-SQL数据库中保持ACID是一件困难的事情，因此尽量避免自己实现SO系统的ACID一致性。如果确实有需求，则寻求具有该特性的DBMS。

⑧尽量简化管理

<wbr></wbr>好的DBA调试后的数据库性能可以比差的DBA调试的好几倍。所以，考量使用什么系统时，一定要考量该系统的易学性，监控工具等因素。

⑨关注节点性能

<wbr></wbr>对于线性扩展系统而言，单个节点性能依旧非常重要。因为节点越多，则需要更多的冷却资源、故障几率等。不要认为先行扩展就意味着多个差节点可以等同与少的好节点。

⑩开源可以让你对将来有更好的把握

<wbr><wbr></wbr></wbr>从facebook等公司的经验可知，开源工具照样可以支持高性能的商务应用，我们希望更多的公司使用开源产品，因为我们可以根据需求进行优化。

四、小节

<wbr><wbr></wbr></wbr>当选择SO系统方案时，有多种选择。面对选择的迷茫，可以从这十条原则入手。好运！

【1】Cattell, R., “High Performance Scalable Data Stores,” http://cattell.net/datastores/.

<wbr><wbr></wbr></wbr>