原文：《Ten Rules for Scalable Performance in “Simple Operation” Datastores 》By Michael Stonebraker and Rick Cattell
作者简介：（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.
（译者）归纳总结：by Xiangxu Meng（yumengkk@gmail.com）from UPCOM
一、简单操作数据库系统定义
在一个事务中只对一小部分对象进行读写操作的数据库应用：常见的应用场景为——在线事务处理（OLTP），社交网络（Social network）等；
二、DBMS沿革
1、1970年提出的关系数据库为主流：Oracle，DB2，MySQL，PostgreSQL等，他们具有如下特征：
①磁盘存储；
②以表的形式组织的行存储；
③B树作为索引机制；
④写前log机制以支持crash恢复；
⑤SQL作为访问语言；
⑥以行（row）为基础的优化器和执行器；
综合如上特征，我们统称这些数据库为“通用目的事务行存储”（general-purpose traditional row stores (GPTRS)）数据库。主要服务于在线事务处理。
2、现在数据库的用途越来越广，出现了多种数据库和应用，如下表：
图一：DBMS发展图——垂直轴代表操作复杂度，水平轴代表读写特性
在新的应用中，比如OLAP倾向于基于列的存储和优化；而图表的下部的一些应用具有NO-GPTRS（No-SQL数据库为主）特性，归纳如下：
① key-value存储，如Dynamo，Scalaris等，只提供简单的key和一系列payload的存储，不支持将payload解析为多个对象的功能，不能对非主要属性进行检索；
② 文档存储，如CouchDB，mongoDB，simpleDB等，支持包括多个属性的对象存储，并且提供NO-SQL语言或者例程支持，方便对数据的查询；
③ 可扩展的记录存储，如Hbase，BigTable，Cassandra等，支持不规则宽度记录的存储，支持表的任意垂直和水平分割，一般采取NO-SQL语言查询；
④ 关注与简单操作的DBMS系统，比如MySQL cluster，VoltDB等，这些系统保留了SQL和ACID，但是实现方式同GPTRS有所不同。
更加详细的分类讨论，可参见【1】。
3、NO-SQL数据库的繁荣
No-SQL的动机：如上的几类新的数据应用模式，重新限定了ACID（atomic，consistant，Isolate，Durable），包括放松了一些限制（比如将持久行，放松为“最终持久化”或者多副本共存）和仅仅支持单记录操作。
这几类应用的特性，可以总结为web应用特性：web应用在开始阶段用户较少，系统负载较轻，但是往往经历爆炸性的增长。这个问题通常的解决方案为：开始阶段只借助一个开源DBMS（如MySql数据库），而后建立多个数据库节点，进行分布式存储。在分布式存储方式下，一个表分开存储（比如一个几亿条的用户名存储，往往需要按照字母划分存在多个服务器的数据库上），数据的操作需要应用程序逻辑进行实现，该方案有如下缺点：
A、数据碎片交叉过滤和合并必须在应用程序中实现；
B、当一个事务中设计到多个节点上数据的操作时，应用程序必须保证数据的一致性操作；
C、规模较大时，节点失效的检测、恢复都很困难；
D、当系统在线时，数据模式的更改很难实现；
E、 节点的添加、重配置都变的非常困难和琐碎。
所以，这种web应用的开发者常常极其痛苦，因为他们必须在应用程序中处理这些复杂的任务。所以大多数No-SQL方案就是瞄准解决该问题，但是由于新的方案和解决方式越来越多，造成开发者很难选择使用那些方案。
因此，本文为那些需要开发简单操作客户端系统而传统GPTRS数据库不再适用时，选择合适NO-SQL方案的十个原则。这十个原则，主要针对那些客户端在自己的环境运行的场景，当然，大多数原则也适用于SaaS环境以及“云环境”。
三、十条原则
① 选用“shared-nothing”体系架构
如facebook的Web应用需要几百上千的数据处理器，如何将这些数据分布存储和处理？我们可以分别考量如下三种结构可用：
多处理器共享主存架构（shared-memory multiprocessing ，SMP)受到存储带宽的限制，很难扩展到几亿条数据的处理和存储；
磁盘集群（disk clusters）体系架构需要处理，数据在磁盘上同步的问题，但前很少有扩展到几十台主机的场景；
只用每个处理器具有自己的存储和计算能力的“无需共享”（shared-nothing）架构才可以支持上千台机器并行：不需要处理复杂的数据同步问题，也没有存储带宽瓶颈问题。
该种结构的限制是：数据良好的划分，网络带宽充足。
综上，选择网络连接的无共享集群结构是最合适的。
② 使用高级语言（并不会带来性能下降）
SQL的开销主要由如下五部分组成：
A、 优化器选择和执行路径规划带来的开销；
B、 同DBMS通信带来的开销；
C、 编码的训练带来的开销；
D、并发控制，灾难恢复，数据完整性处理带来的开销；
E、 为了保证本质工作执行而需要的各种保障机制带来的开销。
（该规则处理前三个问题，后两个问题由第三个规则处理）
高级语言带来的好处：
A、 容易编码；
B、 不需要了解数据如何存储和组织；
C、 数据模式的修改不会导致代码的大量修改；
高级别语言避免了SQL的解释开销；DBMS的通信开销减少（No-SQL数据库机制提供常用的索引、查询例程，可供高级语言直接调用）；降低了编码难度。
③ 谨慎的使用主存数据库
主存数据库很容易提供TB级别的数据处理，因此，从原理上而言，可以上千倍的提高系统查询速度（主存访问比磁盘访问至少快上几百倍）。
但是主存数据库并没有有效的降低，锁机制，多现成，缓存机制，并发机制带来的开销。只是降低了数据在磁盘和处理器间的开销。因此，选择主存数据库时要谨慎，选择对各种保障措施的开销规避比较好的系统。
④ SO数据系统具有高可用性、自修复能力
在硬件越来越便宜的趋势下，系统要做好冗余机制，避免发生故障时，长时间系统不可用问题。因此，简单操作系统通常都具有自修复能力（故障节点自检测、数据重划分等机制）。同时，还要考虑到做好灾难恢复系统以应对地震、海啸等灾害。
⑤ 持续在线
对于用户而言系统必须持续在线，对于模式变更、索引变化、重配置、软件升级等操作，必须保证服务持续在线。
⑥ 避免多节点操作
对于SO的可扩展行而言，两个条件必须满足：
A、 数据和应用负载在多个服务器间彻底分割（读操作可以采取复制机制，而写操作却需要依据主键保持一致）；
B、 数据操作不要跨越多个节点（多节点操作必定带来额外开销）。
⑦ 不要试图自己建立ACID一致性
在NO-SQL数据库中保持ACID是一件困难的事情，因此尽量避免自己实现SO系统的ACID一致性。如果确实有需求，则寻求具有该特性的DBMS。
⑧ 尽量简化管理
好的DBA调试后的数据库性能可以比差的DBA调试的好几倍。所以，考量使用什么系统时，一定要考量该系统的易学性，监控工具等因素。
⑨ 关注节点性能
对于线性扩展系统而言，单个节点性能依旧非常重要。因为节点越多，则需要更多的冷却资源、故障几率等。不要认为先行扩展就意味着多个差节点可以等同与少的好节点。
⑩ 开源可以让你对将来有更好的把握
从facebook等公司的经验可知，开源工具照样可以支持高性能的商务应用，我们希望更多的公司使用开源产品，因为我们可以根据需求进行优化。
四、小节
当选择SO系统方案时，有多种选择。面对选择的迷茫，可以从这十条原则入手。好运！
【1】Cattell, R., “High Performance Scalable Data Stores,” http://cattell.net/datastores/.
