关系数据库使用的演变

NoSQL Prequel - 关系数据库使用的演变发布在 NoSQL Prequel 1.1 上。 什么是NoSQL 在云计算时代，谈到大数据量的处理需求就必须谈到NoSQL。 以HBase、Cassandra为代表的NoSQL产品，可扩展性和高可用性受到业界推崇，广泛应用于数据存储和分析领域

NoSQL 前传 - 关系数据库使用的演变 发表于

NoSQL 前传 1.1。 什么是NoSQL

云计算时代，说到大数据的处理需求，就必须说到NoSQL。 以HBase、Cassandra、MongoDB为代表的NoSQL产品以其高扩展性和高可用性受到业界的高度评价，在数据存储和分析领域得到了认可。 广泛使用。

那么什么是NoSQL？ 对于这个问题有多种定义。 很多人认为它是“Not Only SQL”的缩写。 在这种情况下，它的含义是：在关系型数据库（DBMS）适合的场景使用关系型数据库，在关系型数据库中使用关系型数据库。 在不适用的场景下使用其他数据存储方案，这就是NoSQL。 文献[1]中对NoSQL的定义如下：下一代非关系型、分布式、开源、可水平扩展的数据库解决方案，其主要特点是：无模式、易于复制、API简单、最终一致性（根据）。

上面的官方定义有点拗口，我们会在第三阶段尝试给出自己的定义。 现在随着其技术的发展，NoSQL正在慢慢地加入关系型数据库的一些特性，而关系型数据库也在不断地融合NoSQL的最佳实践，或许两者最终会融合。

1.2. 关系数据库的演进过程

这里我们不会谈论DBMS相关的技术，比如事务和关系模型，而是重点讨论DBMS在互联网上的使用。 在互联网的早期，用户和内容都相对较小。 这时候，使用数据库就可以解决所有问题。

随着业务的发展，香港服务器和数据库读取逐渐成为瓶颈。 为了解决读问题，使用副本节点（Slave）来分担读请求。 Master节点负责写操作，并将数据异步复制到Slave节点、虚拟主机上，这样非实时的读操作请求就可以发送到Slave节点来完成。

当用户数量逐渐增多时，此时写操作就成为数据库的瓶颈。 此时需要多个Master来承担写操作。 其实这也是数据库中常见的数据库和表操作，不同的数据库表放在不同的节点上。 。

通过分库分表在一定程度上解决了海量数据的存储和管理问题。 但是当某个表的数据量特别大时，就需要将一张表分布到多个节点上。 这时候就需要对表进行水平分区，当然分区的方式有很多种。 我们首先想到的就是添加索引服务器。 应用程序写入数据时，需要将索引（数据条目与数据库节点的对应关系）写入索引服务器。 需要保证索引服务器和数据服务器之间的数据一致性。 同时读取数据时，首先需要去索引服务器获取对应的数据库节点信息。 一般来说云服务器演进，索引数据较小，可以放在内存中以加快访问速度，但索引服务器存在单点故障的问题。 另外，不同方式对数据的访问，例如范围查询、列值查询等，都很难通过索引服务器来完成。 一般是通过对所有节点进行全方位扫描来完成的。

1.3. NoSQL 简介

从上一节我们可以看到，关系型数据库虽然做了很多改进和努力，但仍然存在很多问题：比如海量数据的写入处理（可扩展性问题）、灵活的表结构（Schema）变更、海量数据的快速写入等。查询处理性能等，处理不好或者解决方案成本高。

为了解决关系数据库的缺点，NoSQL出现了慈云数据自营海外云服务器,高稳定高性价比,支持弹性配置，针对不同的业务需求进行定制化处理，满足功能和性能需求。 比如在一些互联网应用中，对数据一致性的要求可以降低，但要求高可用性。 所以在某种程度上，我给NoSQL的定义是：企业根据自身需求提供的定制化的低成本分布式存储系统。

根据存储模型分类，NoSQL大致可分为[1]：

l Key-Value存储：以DynamoDB、Redis等为代表。

l Column-Family列存储云服务器演进，也称列簇存储，以HBase、Cassandra为代表

l Document Store文档存储，以MongoDB和CouchDB为代表

l Graph Database 图数据库，以Neo4J为代表，该类型本书不涉及

参考文献[2]展示了一张有趣的NoSQL家族的演化图，我们可以看到这样的演化趋势：Key-Value时代、BigTable（Column-Family）时代、Document时代、图数据库时代，最后是关系数据时代的演化：

1.4. 参考

[1]

[2]