正文
Dynamo 和 BigTable 都是为了解决各自业务场景所遇到的数据挑战而提出的，两者都有着丰富的设计思路和技术实现。这些设计和实现为后续的很多 NoSQL 产品所借鉴，并经常搭配使用，从而解决业务场景的各种挑战。例如 HBase 借鉴了 BigTable 的数据模型、Cassandra 借鉴了 BigTable 的数据模型和 Dynamo 的分布式设计。
主要的非关系模型有KV模型、宽表模型、文档模型、图模型、时序模型等：
-
KV模型：
主要特征是将每个数据值与唯一的键关联起来，
适用于OLTP场景，例如 Amazon's DynamoDB
-
宽表模型：主要特征在于动态列、多版本、TTL，其自动分裂的特性和基于lsm-tree的存储引擎提供了强大的水平伸缩性和写入吞吐量，特别适用于稀疏数据集的海量写入和查询场景。业界主流产品是 BigTable 和 HBase，HBase 是 BigTable 的开源实现
-
文档模型：主要特征在于提供了最接近于真实的业务对象模型的 JSON/BSON 存储格式，是一种对开发非常友好的存储模型。业界主流产品是 MongoDB，其与 Express、Angular、Node.js 等开源技术栈一起构成了 MEAN Stack
-
图模型：主要特征在于提供了点和边的存储语义，可以高效执行跨节点和边的网络查询，易于描述实体间的关系。业界主流产品是 Neo4J
-
时序模型：主要特征在于提供了时间序列数据的建模能力，将时序数据抽象为指标、标签、时间戳三个维度。业界主流产品是 InfluxDB、Prometheus、OpenTSDB 等，InfluxDB 与 Telegraf、Chronograf、Kapacitor 等组件一起组合为 TICK Stack
NoSQL 本质上舍弃了传统关系型数据库的一些功能，从而可以实现更加灵活的特性。这些丰富的灵活的特性简化了应用程序的数据操作，极大简化了业务逻辑。NoSQL 并不是某种特定的数据库产品，甚至没有一个明确的定义，而是一种区别于传统关系型数据库的数据模型和数据管理模式，社区赋予了其更包容和多样化的含义。借用《NoSQL Distilled》中总结的 NoSQL 的共同特征：
-
Not using the relational model
-
-
-
Built for the 21st century web estates
-
在以 Spanner、OceanBase 为代表的 NewSQL 出现后，关系型数据库也能提供非常好的水平扩展性，关系型数据库与 NoSQL 之间的水平扩展性差异大幅缩小。但灵活的数据模型依然是 NoSQL 的独特价值。
从应用程序视角，NoSQL 等同于 “Non Relational” 或者 “Non Transactional”，意味着灵活的数据模型和访问接口、可定义的放松的数据一致性，从而提供了关系型数据库以外的另一种选择。且其运行于分布式集群之上，天然具备极好的水平扩展性，能够更好的适用于大数据场景。数据库产品面向 OLTP 业务需要提供的特性可以总结为三类：ACID、水平扩展性、数据模型灵活性，NoSQL 和 关系型数据库各有擅长：
因此，关系型数据库与 NoSQL 具备非常好的特性互补，应用程序往往搭配使用并形成了标准的数据架构。关系型数据库提供 ACID 能力，保证数据持久性和数据完整性，用于 mission-critical 的关键业务场景。NoSQL 提供水平扩展性和灵活数据模型，用于创新场景和大数据场景。两者间的数据划分，可以由应用程序分别写入，也可以通过 event stream/change stream 的方式从关系型数据库流向 NoSQL。
-
更灵活的数据模型以提升研发效率：应用开发者的很大一部分精力在于将业务数据的内存结构映射为传统数据库的关系模型，而 NoSQL 提供了诸多可以直接表征业务数据的数据模型，极大简化了业务逻辑
-
更优的数据处理规模和性能以简化应用架构：随着业务的发展，应用程序需要处理更多的数据，需要更快的处理数据，从而让数据更有价值。在传统数据库上处理，会带来更多的应用开发成本和硬件成本，甚至很难搞定，而 NoSQL 被设计为在大规模集群上运行，从而可以很好的应对此类挑战
NoSQL 的数据范式
NoSQL 的兴起使得业务数据的建模能力得到了加强，使得业务数据不再被其存储形式束缚。NoSQL 与关系数据库一起构建了更立体的数据架构，使得现代应用解除了传统关系模型的局限性，更好的专注于业务逻辑。
关系型数据库对应用程序提供了非常关键的 ACID 能力，使得数据可以安全的完整的持久化，可以安全的并发访问。但关系型数据库并不能适用于所有的企业数据和场景，因此应用程序往往同时使用 NoSQL 应对不同的数据存储需求。两者共同构建了企业在线业务的数据架构 —— Polyglot Persistence，应用程序使用多种数据库产品处理不同类型数据，从而在面临具体数据时可以选择最合适的产品。Polyglot Persistence 非常适合于复杂应用，从而为各种业务数据选择最合适的数据模型。Polyglot Persistence 在提供便利性的同时也引入了架构复杂度，需要在收益和复杂度之间做好权衡。
以蚂蚁业务为例，不同类型的业务数据有着各自最合适的数据库产品。交易域业务的数据，模式基本固定，且数据一致性要求很高，非常适合由关系型数据库提供服务，我们会选择 OceanBase；客户域业务的数据，一般跟用户ID直接关联，且是一个典型的读多写少的场景，非常适合由 KV数据库提供服务，我们往往选择 TBase；风控域业务的数据，模式灵活、请求量大、且对数据实时性和查询性能要求很高，非常适合由宽表数据库提供服务，我们往往选择 HBase。
CQRS
Polyglot Persistence 是一种数据职责分离的范式，为不同的数据类型选择最合适的数据库产品。另一种数据职责分离的范式是 CQRS（Command Query Responsibility Segregation），将写入操作和读取操作分开。写入操作（Command）通过规范化的关系模型来提供，从而保证数据完整性和数据一致性。读取操作（Query）通过非规范化的数据模型来提供，从而可以获得灵活性和极致性能。两者之间的数据通过异步机制保持最终一致性，可以通过应用程序的异步消息，也可以通过数据库系统的 CDC（Change Data Capture）机制。
