【51CTO.com快译】近十年来，大规模分布式系统得到了爆炸式增长，已经产生了一股可以说是对整个软件业开先河式的，数据库界的创意旋风。市场上也涌现了大量的颇具竞争力的数据库平台。
在本文中，我们将探讨如何为您的应用去选择合适的数据库模型（是的，完全可以选择不止一个！）。我们也会讨论到这些数据模型的选择将如何帮助您去确定数据层面的各种技术。
一、云架构，NoSQL和微服务
在软件开发人员开始创建Web架构的应用时，那些在历史上一直主导着我们多年的关系型数据库架构，已经开始表现出“压力山大”了。特别是在我们开发那些被频繁使用的社交应用，和将越来越多的设备连接到物联网（IOT）的时候，客户端大量地读取和写入数据导致了数据层面的扩展需求。而与此同时，为了满足这些高扩展性的需求，新的数据库类型随之出现。
在许多情况下，这些新的数据库是“非结构化查询语言（NoSQL）”或“非关系型”的数据模型解决方案。它们并非显性的关系模型，如文档、键-值、面向整列的、甚至是图表数据库。通常，这些数据库牺牲了一些在传统关系型数据库上为我们所熟悉的特性，如：强一致性、ACID事务和各种连接（joins）。
同时，作为革命性的数据库技术，SOA（面向服务的架构）已经日趋向微服务架构的风格进行发展，许多组织开始摒弃诸如企业服务总线（ESB）的重量级SOA架构，而改用更为分散的实现方法。微服务架构的吸引力在于其独立的开发、管理和扩展各种服务的能力。这使得我们在考虑数据库架构实现等方面的技术上，具有大量的实施选择灵活性。
举例而言，假设我们根据一项大规模可扩展性的需求，正在从事一个重要的微服务架构的开发。那么，无论该项目是一项新的应用，还是对现有应用的重构，我们都有机会来选择新的数据库。
1.混合持久化（Polyglot persistence）
微服务模式的一项优势是封装的持久性，我们可以自由地根据每个服务的需求来选择不同的持久化技术。Martin Fowler等人提出的混合持久化这一术语，特指根据不同的数据类型来选择数据存储的方法，可以说混合持久化天生就十分契合微服务。
下面的例图显示了一组微服务，我们该如何为每一项服务来选择使用不同的数据模型呢？在此，我不一一列举每种数据库类型的适当用例，只会突出这些数据库类型和混合方法的优势所在。
将混合持久化应用到微服务上。
开发服务A的小组可能会选择使用表格型数据库（tabular database），如Apache Cassandra，因为它能大规模地管理核心应用的数据。例如，零售应用的库存类数据可能就非常适合于Cassandra的表格形式。Cassandra提供了一套协调机制的工具集，包括能够批量调整一致性，和作为全面ACID事务替代品的轻量级事务等。
服务B可能只需要支持通过well-known键来查询参考值，这样简单的语义，比如说一个产品编录的描述性数据。这是一个很好的键-值（key-value）存储的案例，我们可以通过产品ID的well-known键-值来查找一个BLOB（二进制对象文件的容器）类型的数据。那么大量的内存空间会被用来缓存键-值类型的数据，从而支持大规模、且超快速地读取访问。
服务C主要考虑的是提供半结构化的内容，例如：网站的网页或表格，以及文档存储，这些类型的数据都是非常适合的。文档的存储有“许多键-值类型相似，仅有某个键不同”的数据结构，例如只要索引某些特殊属性项，便可加快各种搜索的能力。
服务D则涉及到导航各种数据间的复杂关系，例如：客户数据与组织内不同部门的客户联系人之间的历史数据。这可能潜在地涉及到：各种不同服务所拥有的数据类型之间的各种关系。比如说在这种情况下，您可以选择让您的服务创建一个对于各种底层表格都是只读的视图，然后通过调用其他“拥有着”自身数据类型的服务API这样的“front door”，来过滤实现任何预期的转换。
***，我们还可能会有一些使用着关系型技术的传统系统与服务，或者我们有一个管理着少量且不经常更改的数据服务。那么关系型数据库对于此类用例就是再好不过的了。
2.单独的服务需要混合吗？
也有一种可能：我们设计出一个放置在多数据库之上的服务。例如说，我们可以创建一个使用的键-值存储索引的酒店服务，它映射名称和ID之间的关系。同时它用Cassandra的表格样式来存储关于酒店的描述性数据。
一个混合服务？
注意：使用非规范化的设计方法，同样可以在Cassandra中实现名称与ID的映射，当然您需要用一张单独的表格来维持名称与ID的映射。这样虽然会用到更多的存储空间，但是简化了我们在管理一个单独的键-值存储操作上的复杂性。
所以我的建议是：只要可行，完全可以把一个给定的微服务与一个单一的数据模型（和数据库）相连接。如果您碰到需要将单一的服务放置在两个不同的数据库之上的情况，请判断该服务的范围是否过大。如果太大，您可能就需要考虑将其拆分成多个更小的服务了。
3.混合持久化的限制与利弊
混合持久化的主要劣势是：在最初化开发和运营方面，需要支持多种技术的成本。
开发的成本主要来自于培训各个开发人员熟悉每种新的数据库技术的成本。如果您的开发团队流动性较大的话，这种劣势会更加明显。
而另一个弊端是支持多个数据库的运营成本。如果数据库的管理是集中化的，并且整体团队必须对多种技术保持较高的维护水平时，这就可能会出现问题。但是当开发团队仅支持他们已选定的生产环境所用到的数据库，从而形成了真正的Devops运作模式时，该问题会得到适当的缓解。
4.多模型数据库
数据库提供商已经开始着手打造与提升一些多模型的数据库，作为混合持久化方法的一种替代或补充了。术语“模型”是指由诸如表格（包括关系和非关系型）、列存储、键-值、文档或图表之类的数据存储所提供的抽象模型。我们可以理解为：多模型应用使用的是一种类型以上的数据存储，而多模型数据库则能够支持多种抽象。
DataStax Enterprise（DSE）是一个多模型数据库的例子，其核心使用一种建立在顶端图表的抽象（DSE图表），来支持Cassandra分区的行存储（表格）模式。如下图所示，在此核心模型上创建您自己的键-值和各种文档类型的抽象是非常简单的。通过这种方式，我们可以修改上述的混合方法，利用单一的底层数据库引擎来提供我们的所有服务。与此同时，我们还可以使用单独的Cassandra键值空间，来维持那些由不同服务所拥有的数据之间的清晰界限。
与DataStax Enterprise交互，作为一个多模型的数据库。
我们下面来看看它是如何工作的：
表格：服务A之类的主要应用服务可以使用Cassandra的查询语言（CQL），来与DSE数据库直接进行交互。
键-值：虽然Apache和DataStax的Cassandra版本都无法提供一个明确的键-值API，但是像服务B之类的服务却能够通过设计来限制表格只与Cassandra互动实现键-值的存储。例如：
- CREATE TABLE hotel.hotels (
- key uuid PRIMARY KEY,
- value text); // or if you prefer, “blob”
文件：通过各种JSON文件，Cassandra能够支持文档类型的交互，这可以被用于服务C之类的服务。注意：因为Cassandra的确需要有表的schema模式，因此您不能插入任意的JSON来随便定义新的列，也就是说通常需要具有与文档数据库相关联的特性。
图表：对于像服务D之类高度支持数据互连的服务来说，DSE图表是一个高度可扩展的图表数据库，它直接建立在DSE数据库之上。DSE图表通过Apache TinkerPop 项目来支持强大的、且易于表现的Gremlin API。
5.多模型数据库的优势和局限性
在考虑是否要使用多模型数据库的时候（或使用你已有数据库的多模型功能时），你需要兼顾考虑我们上述所讨论的有关混合持久化方法所带来的开发和运营成本。
使用多模型数据库可以简化运营。无论是不同的开发团队使用不同的API，还是不同的后端数据库平台交互模式，我们都会从只需要管理单一的平台来受益。
在选择多模型数据库时，需要考虑的一个方面就是：各种模型如何能够被支持。一种常用的处理方式是：一个基于单一本地的底层模型与其上面分层的其他模型共同组成一个数据库引擎。分层的数据模型用于展示其底层主模型的各种特征。
例如，在ThoughtWorks的技术雷达第16卷（Technology Radar Vol. 16）（https://assets.thoughtworks.com/assets/technology-radar-vol-16-en.pdf）中，就讨论展示了在Cassandra顶端分层的DSE图表模型的特性和所涉及的取舍：
我们所长期钟爱和使用的Neo4j（译者注：Neo4j是一种高性能的NOSQL类型图表数据库，它将结构化数据存储在网络中而不是本地表里。）已经在大型的数据集类型中逐渐显露出了局限性，而建立在Cassandra顶端的DSE图表则应运而生。
当然，这种模式也有其自己的取舍，例如：您会失去ACID事务和Neo4j的独立于架构运行（run-time schema-free）特性；但是DSE通过访问底层的Cassandra各种表格，Spark对分析负载的集成，以及强大的TinkerPop/Gremlin查询语言，都使得它还是很值得考虑和选择的。
如果您在自己的Web架构应用中考虑使用不同的数据类型，那么您可能就会发现到：不同的数据类型有着不同的一致性需求，而实际需要立即进行一致化的数据类型并不多。
另一个需要重点考虑的是：多模型的空间问题，即不同数据库模型和引发的集成与交互，以及访问数据的各种操作和分析用例。DSE支持通过Spark（DSE分析）来访问图表数据以实现其分析的目的，而DSE搜索则提供了用于创建那些存储在DSE数据库中数据的各种搜索索引的能力。
二、微服务数据模型的四步骤
既然我们已经了解了混合与多模型方法的各类优点，那么我们应该如何为大规模的微服务应用来选定数据模型呢？请参考下列的步骤：
1. 识别应用程序中的主要数据类型，逐个创建服务，并控制每个服务的持久性。如果可能的话，将多模型的数据库运用到所有服务上，使服务能根据它们所选择交互的数据来改变模式。
2. 根据您网页级的延展性和可用性，键-值的分层和文档的语义，按需使用一种表格的形式（如DSE数据库）来作为您的主要模型。请务必考虑到各种方式，来保证您的数据能够被各种操作和分析用例所访问到。这样您就可以提前规划好那些如何使用查找索引，以及向分析数据中心进行复制等方面的功能。
3. 使用高度相关的数据图表形式（如DSE图表），特别是在各个实体之间的关系有着比其实体本身更多属性的时候，或是您需要在同一个实体间获取多重关系的时候。
4. 当您没有必要改变的时候，请保留传统的关系型/SQL技术的架构。例如，当您的用例并不需要大规模、低延迟和高可用性的时候。
我希望上述内容能够为您在思考如何为自己的应用程序提供多模型支持，以及何时、何处用到多模型数据库的时候提供一个实用的框架。
原文标题：How to choose a database for your microservices，作者: Jeff Carpenter
【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】
