关系型数据库的性能扩展思路及NoSQL产品的选取标准

一、关系型数据库面对数据访问的压力，通常采取的解决方案步骤（以MySQL为例）

1、主从复制，实现读写分离或分布读；
2、读请求比较多，可添加缓存服务器，如Memcached，以提升读性能；但此时得手动维护数据的一致性；
3、写请求较多的场景，可简单进行向上扩展，使用性能更强的服务器以应付更多的写请求；同时，为了保证从服务器跟得上主服务器的更新速度，可能需要从服务器使用与主服务器相同的配置；此法性价比不高；
4、数据访问压力进一步增大时，联结查询性能会急剧下降；此时就得进行“反模式”化设计，将表根据业务需求进行合并，以增大数据冗余来换取系统性能；
5、停用存储过程、存储函数或触发器等代码，将对应的功能在应用程序中完成；
6、删除表的各辅助索引，改写查询使其仅使用主键索引；
7、数据库切分(sharding)；此法复杂度较大，维护成本较高；且数据规模再次提升时重新切分的成本高昂，二次扩展能力受限；

二、RDBMS与NoSQL

实际使用中，只要架构得当，关系型数据库完全能够服务于各种级别的数据存储应用，比如Facebook和Google各自有着运转良好的MySQL服务器集群服务于不同层次不同领域的数据存储场景。但此等规模的应用需要强大的技术实力突破各式各样的应用限制，这也会带来居高不下的维护成本，而且关系型数据库某些内生性的限制依然会成为应用中的梦魇。于是，近几年来，一些被归类为NoSQL的新项目或框架在多个组织或企业中雨后春笋般涌现。这些新项目或框架很少提供类似SQL语言一样的查询语言，而是提供了一种简化的、类API的数据访问接口。但RDBMS与NoSQL真正的不同之处在于低层，即存储级别，因为NoSQL通常不支持事务或辅助索引的功能等。

另一方面，NoSQL的著名项目中彼此间有许多功能是重叠的，甚至有不少特性与传统的关系型数据库的功能也存在相同之处，因此NoSQL算不上革命性的技术，尽管从工程师的眼下其绝对是革命性的。于是，现实中，memcached也被划归了NoSQL阵营，似乎不属于RDBMS的存储管理类程序都自然而然的属于NoSQL，NoSQL也因而成为了非RDBMS系统的“海纳百川”之地。然而，“有容乃大”就难免“鱼龙混杂”，为了便于理解，这里从多个维度来对NoSQL的主流技术进行简单的归类，以便对此能有个概括性的认识，并能够在实际应用场景中有个可以参照的选择标准。

1、数据模型
数据模型指数据的存储方式，其有好几个流派，如关系、键值、列式、文档及图像等。在它们的各自实现中，关系型数据库有MySQL、PostgreSQL、Oracle等，键值数据库有memcached、membase、Riak、Redis等，列式数据库有HBase、Cassandra、Hypertable等，文档数据库有MongoDB、CouchDB等，图像数据库有Neo4J等。在选用某特定的NoSQL产品时，应该事先评估应用程序是如何访问数据的，以及数据的schema是否经常演进等。

2、存储模型
指数据存储是基于内存存储还是持久存储。

3、一致性模型
存储系统在何种级别实现数据一致性，严格一致性还是结果一致性？一致性的等级可能会对数据访问延迟带来巨大影响。

4、物理模型
在物理模型上可归类分布式存储及单机存储。对分布式存储而言，其扩展能力及易扩展性如何也是一个重要的衡量指标。

5、读/写性能
对于工作在不同应用场景中的应用程序而言，其读/写需求有着显著不同。而不同的NoSQL产品也有着不同的适用性。

6、辅助索引
辅助索引有助于实现在非主键字段上完成排序、查询操作等；有的NoSQL产品不提供此类功能。

7、故障处理
不同的应用场景其故障恢复的时间容忍度不同，而不同的NoSQL产品也故障恢复能力方面也有着不同的表现。

8、数据压缩
当存储TB级别的数据时，尤其是存储文本数据时，数据压缩可以大量节约存储空间。

9、负载均衡
分布式存储将用户的读/写请求分布于多个节点同时进行能够极大提升系统性能。

10、锁、等待和死锁
RDBMS的事务处理过程分为两个阶段，多用户并发访问的场景中，这将显著增加用户在访问资源时的等待时间，甚至会导致死锁。

三、数据一致性模型

概括来讲，数据一致性是指在应用程序访问时，数据的有效性(validity)、可用性(usability)、精确性(accuracy)及完整性(integrity)方面的表现，其用于保证在用户自身事务或其他用户的事务执行过程中，每个用户看到的数据是一致的。在各种场景中都有可能产生数据一致性问题，但提到的较多的通常有应用程序一致性、事务一致性和时间点一致性等。

在数据库上，每个操作都可能促使数据库从一种状态转换为另一种状态，但这种转换的实现方式或过程是非特定的，因此其有着多种不同的模型。不过，无论是基于哪种实现，其最终结果要么是转换为的状态，要么恢复回原有的状态以保证数据的一致性。根据数据库在保证数据一致性实现的严格程度来分，大致有如下几类：

严格一致性(strict)
数据的改变是原子性的并且会立即生效；这是最高级别的一致性实现；
顺序一致性(Sequential)
每个客户端以他们提交应用的次序看到数据的改变；
因果一致性(Causal)
因果关联的所有的改变，在所有的客户端以同样的次序获取；
结果一致性(Eventual)
当一段时间内没有更新发生时，所有更新会通过系统进行传播，最终所有的副本都是一致的；也即当事务完成时，必须使所有数据都具有一致的状态；
弱一致性(Weak)
不保证所有的更新都能通告给所有客户端，也不保证所有客户端都能以同样的次序获取数据更新；

其中，结果一致性还可以进一步细分为多种不同的子类别，而且有些子类还可以共存，亚马逊公司的现任CTO Werner Vogels在“Eventually Consistent一文中对此有详细阐述。在文中，他还提出了CAP定理，并借此指出，一个分布式系统仅能同时实现一致性、可用性和分区容错错(partition tolerance)三种属性中的两种。

本文出自 “马哥Linux培训” 博客，转载请与作者联系！