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

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了关系型数据库的性能扩展思路及NoSQL产品的选取标准，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含4846字，纯文字阅读大概需要7分钟。

内容图文

一、关系型数据库面对数据访问的压力，通常采取的解决方案步骤（以MySQL为例）1、主从复制，实现读写分离或分布读；2、读请求比较多，可添加缓存服务器，如Memca

一、关系型数据库面对数据访问的压力，通常采取的解决方案步骤（以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)三种属性中的两种。

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

内容总结

以上是互联网集市为您收集整理的关系型数据库的性能扩展思路及NoSQL产品的选取标准全部内容，希望文章能够帮你解决关系型数据库的性能扩展思路及NoSQL产品的选取标准所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端

---