CGLIB 动态代理

NoSQL 运动的新时代

现代软件系统在数据量和吞吐量要求等方面面临的挑战表明，关系数据存储经常成为瓶颈，从而对整体系统可扩展性施加限制。传统上，解决这个问题的方法只是购买一个更大的盒子（所谓的垂直可扩展性），但是在某些时候支付的价格变得非常非常高，使得整个系统非常昂贵且不切实际。

业界正在积极寻找一种更便宜的方法来构建复杂的分布式系统，而不是利用水平可扩展性。它还意味着提出关系数据存储的替代方案，它也可以水平扩展。那一刻，当 NoSQL 运动开始时。

4. 表格与文档与图表与键值

一个关系型数据模型代表的元组和关系上的所有数据（更好地称为表）。结构化数据非常适合这种模型，并且很长一段时间没有其他可行的替代方案。随着 NoSQL 运动，开发了许多替代数据模型，诞生了一大堆专业数据存储系统。

在 NoSQL 的解决方案，可以在几个不同的类别进行分类。

文档数据存储设计用于存储，查询和管理文档（半结构化数据）。此类别中更成熟的代表包括 CouchDB、Couchbase、MongoDB、OrientDB 和 HyperDex。

键值数据存储设计用于存储，查询和管理关联数组（也称为字典或散列）。此类别中使用最广泛的代表包括 DynamoDB、FoundationDB、HyperDex、MemcacheDB、Redis、Riak、Aerospike、OrientDB。

图形数据存储设计用于有效地存储和操作图形结构。这一类的知名代表包括 Neo4J、InfiniteGraph、GraphBase 和 OrientDB。

宽列数据存储采用混合方法（结合键值数据存储的一些特征）和传统的关系数据存储）。此类别中最先进的代表包括 Accumulo、Cassandra 和 HBase。

请注意，上面提供的不同 NoSQL 数据存储列表远未完成，它只包含最知名和最广泛使用的名称，但还有更多，这里就不一一列举了。

5. MySQL 和 MongoDB：有意识的决定

让我们继续更实际的事情。在本文的这一部分中，我们将使用 MySQL 和 MongoDB 来查看应用程序开发过程的所有方面，并花一些时间讨论部署和监视。目标是讨论每个数据存储所做出的权衡和设计决策，并分析它们如何改变我们开发应用程序的方式。此外，本文的另一个目的是帮助做出决定，当 MongoDB 可能是比 MySQL 更好的选择（反之亦然），同时考虑到应用程序架构，数据访问模式和存储要求。

就像我们现在一样，MongoDB 是一个文档数据存储。它存储分组到集合中的 JSON 样式文档。在 MongoDB 的顶部，数据模型层次结构是一个数据库（请参阅官方文档以获取全面的详细信息）。MongoDB 的当前生产就绪版本是 4.0。

从另一方面来说，MySQL 是关系数据存储。数据存储在包含列的表中。这些表被分组到数据库中。目前生产的 MySQL 版本是 8.0。

MySQL 支持多个存储引擎，每个引擎都有自己的用途，并且具有其他存储引擎所不具备的一些功能。在本文中，我们假设使用 InnoDB 存储引擎，因为它是默认的，而且是最常用的，除了专门的用例外，建议使用它。

5.1 强制架构与无架构

MySQL 作为关系数据存储需要对其数据模型采用严格的模式：所有表都应该使用定义的列创建。只有这样才能使用 SQL 语言存储和查询数据。这有点使开发和部署过程复杂化，因为每次需要修改数据模型时，应首先更改模式，然后迁移数据。