您的微服务架构需要多个数据模型。您应该选择混合持久性还是多模型数据库？在过去十年中，大规模分布式系统呈爆炸式增长。这种趋势激发了数据库领域的创造力激增，这在软件行业的历史上肯定是前所未有的。结果是一个健康且竞争激烈的数据库市场，我们可以从大量平台中进行选择。但是我们应该如何选择呢？在本文中，我们将讨论如何根据应用程序选择用于验证的数据库模式。（是的，可以有不止一种选择！），我们还将研究数据模式的选择如何帮助确定将在数据层中选择哪些技术。云架构、NoSQL和微服务架构随着开发人员开始创建可扩展的Web应用程序，历史上主导数据架构的关系数据库开始显示出很大的压力。我们开发了非常流行的社交应用程序，并开始将越来越多的设备连接到物联网(IoT)。用户读取和写入的大量数据需要扩展数据层，并且出现了新型数据库来满足这些高可扩展性要求。在许多情况下，这些新的数据库“NoSQL”或“非关系”解决方案基于不同于传统关系数据库模型的数据模型。NoSQL数据库包括文档、键值、列式甚至图形数据库。一般来说，这些数据库牺牲了关系型数据库的一些共同特性，如强一致性、ACID事务特性和join连接等。同时，和数据库技术的转型一样，本世纪初的SOA（Service-OrientedArchitecture）正在逐步向微服务架构架构演进，很多企业也逐渐放弃企业服务总线（ESB）等重量级的SOA架构)，并倾向于使用“去中心化”的架构方法。微服务架构的魅力在于其开发、管理、扩展服务相对独立。这给了我们很大的实施灵活性，包括数据库等基础设施技术。例如，假设我们正在进行微服务架构的开发工作，并期望有大量的可扩展性需求。无论项目是一个新的应用还是对现有应用的重构，我们都有机会对数据库做出新的选择。Polyglot持久性微服务架构风格的一个关键优势是持久性的封装。我们可以根据各个服务的需要，选择不同的持久化技术。根据每种数据类型的特点来选择数据存储的方法称为混合持久化。该术语最初由MartinFowler等人推广。混合持久性和微服务架构是天作之合。下图展示了一系列微服务以及我们如何为每个服务选择不同的数据模式。我不想在本文中为每种类型的数据库选择正确的用例。我的目的是强调各种类型数据库的优点，以及为什么混合持久化方法值得称道。其中，开发服务A的团队，由于该服务是基于大规模数据管理的核心应用，可能会使用诸如ApacheCassandra这样的表格模型数据库。例如，零售应用程序的库存应用程序可能非常适合ApacheCassandra。Cassandra提供了一系列协调机制工具，如可调一致性、批处理和轻量级事务机制，可以作为完整的ACID事务机制的替代品。服务B支持使用众所周知的键查找值的方式，例如产品目录的描述性数据。这是键值存储模型的一个很好的例子，我们通过众所周知的键值（例如产品ID）查找一系列数据。许多内存缓存使用键值对数据模型来支持大规模快速读取。服务C可能主要关注半结构化内容，例如网站的表单或页面，文档存储可能非常适合这种类型的数据。文档存储与键值存储有很多相似之处，但一个关键的区别是文档类型的数据支持为数据添加结构，例如索引特定属性以支持快速检索。服务D可能涉及导航数据之间的复杂关系，例如客户数据和客户与组织中各个部门的联系历史数据。这可能涉及其他服务拥有的数据类型之间的关系。这是一个有趣的案例，因为它开始与前面提到的服务具有自己的数据类型的约束相矛盾。在这种情况下，您可以选择为您的服务创建一个具有对底层表的只读访问权限的图，然后通过这个“前门”处理所有更改——也就是说，通过这个“前门”来调用那些“拥有”用于这些数据类型的其他服务的API。最后，我们可能还有一个使用关系数据库技术的遗留系统或服务，或者我们可能有一个管理数据量小或不经常更改的服务。关系数据库可能非常适合这些场景。单个服务应该使用混合持久化吗？也有可能我们可以设计一个需要多数据库支持的服务。例如，我们可以创建一个酒店服务，它使用键值存储模式作为索引，实现酒店名称和ID之间的映射，并在Cassandra中存储关于酒店的描述性数据。请注意，可以使用规范设计方法在Cassandra中实现名称到ID的映射，其中单独的表维护名称到ID的映射。这会使用更多的存储空间，但会降低管理单独的键值存储的操作复杂性。这是我推荐的做法——对于微服务，只要可行，就应该坚持单一数据模型（数据库）。如果您发现单个服务需要由两个不同的数据库支持的情况，请考虑该服务的粒度是否可能变得太大。您可能需要考虑将此服务拆分为更小的服务。混合持久性限制的权衡混合持久性的主要缺点是支持多种技术的成本，无论是在初始开发阶段还是在未来的操作中。主要的开发成本是需要培训每个开发人员掌握每一种新的数据库技术。这非常重要，尤其是在开发人员流动频繁的团队中。另一个成本是支持多个数据库的运营成本。这可能会成为一个问题，尤其是当数据库集中管理并且团队必须保持对多种技术的高度掌握时，但在DevOps环境中，这个问题并不那么突出，因为开发团队需要支持他们在生产环境选择的数据库。多模型数据库（MultiModelDatabases）作为混合持久化模式的另一种选择或补充，数据库厂商开始建立和推广多模型数据库。术语“模型”是指数据存储提供的核心抽象，例如表（关系和非关系）、列存储、键值、文档或图形。我们可以将多模型应用程序视为使用多种数据存储类型的应用程序，而多模型数据库是支持多种抽象模型的数据库。DataStaxEnterpriseEdition(DSE)是多模型数据库的典型示例。它以其核心支持Cassandra的分区行存储（表）模型，也支持在其之上的基于图的抽象层（DSE图）。DSE在核心模型之上构建相应的key-value和document模型也非常简单，如下图所示。通过这种方式，我们可以修改上面的混合持久化方法，为我们的所有服务利用一个单一的底层数据库引擎，同时使用单独的Cassandra键空间来维护不同服务拥有的数据之间的清晰界限。下面是它可以实现的功能：[list]表：我们主要的应用服务A可以通过Cassandra的查询语言（CQL）直接与DSE数据库打交道。键值对：虽然Apache和Cassandra的分布式版本DataStax都没有提供明确的键值对API，但是服务B可以通过表的设计来支持单键值和列的方式访问Cassandra，例如：代码CREATETABLEhotel。hotels(keyuuidPRIMARYKEY,valuetext);//或者选择blob类型的文档类型：Cassandra支持使用JSON文件的文档式数据，可以在服务C中使用。注意因为Cassandra需要为表定义schema，所以是无法插入任意JSON列，这是通常与文档数据库相关联的功能。Graph：对于像服务D这样高度相关的数据，DSE的Graph是一个构建在DSE数据库之上的高度可扩展的图形数据库。DSE图形支持来自Apachetinkerpop项目中强大且富有表现力的GremlinAPI。[/list]多模型数据库的优势和局限在考虑是否投资多模型数据库（或您已经在使用的数据库的多模型特性）时，您应该考虑我们之前讨论的混合持久化。开发和运营成本的问题。使用多模型数据库可以使操作变得容易。即使不同的开发团队使用不同的API、不同的交互方式来处理后端数据库平台，我们也只需要管理一个平台，提高了效率。选择多模型数据库时要考虑的一个问题是如何支持各种模型。一种常见的方法是将数据库引擎建立在一个本地基础模型的基础上，其他模型都建立在该模型的基础上。分层数据模型可以更好地揭示底层基本模型的特征。比如第16期ThoughtWorks技术雷达，讨论了基于Cassandra构建的DSE图数据库的特点，也提到了需要权衡的内容：引用基于Cassandra构建的DSE图数据库是一个大规模数据集，与Next相比，我们长期以来最喜欢的Neo4j开始显示出一些局限性。有取舍；例如，您失去了ACID的事务特性和Neo4j运行时的模式自由，但获得了对Cassandra底层表的访问权限，以及用于分析工作负载的Spark集成，以及强大的TinkerPop/Gremlin查询语言可用和确实是一个值得考虑的选择。如果你考虑web应用中的各种数据类型，你可能会发现不同的数据类型对一致性的要求是不同的，而真正需要立即一致性的数据类型是比较少的。在上面引用的ThoughtWorks观点中，还提到了考虑多模型数据库的另一个重要因素——不同模型和数据引擎之间的集成和交互，以及访问数据的各种操作和分析的用例。DSE支持通过Spark（DSE分析）访问图数据进行数据分析，DSE搜索引擎提供了为DSE数据库中的数据创建各种查询索引的能力。微服务数据模型运行的四个步骤既然我们已经讨论了混合持久化和多模型方法的优缺点，那么我们应该如何决定哪些数据模型适合大规模可扩展的微服务应用程序呢？按照以下步骤进行：确定应用程序中的主要数据类型，为每种类型创建一个服务，并让每个服务处理相应的持久层。在可能的情况下，为所有服务使用多模型数据库，允许服务在与数据交互的模型中有所不同。使用Tabular（如DSE数据库）作为网络层面可扩展性和可用性的主要模型，然后根据需要在其之上构建分层的键值对和文档数据模型。请务必考虑在操作和分析用例中访问数据的各种方法，以提前计划如何在DataAnalyticsHub中使用搜索索引和复制等功能。使用图的方法来表示（即DSE图）高度相关的数据，特别是当实体之间的关系具有多个或多个属性，并且数量超过实体本身的属性时，或者当同一实体需要捕获一个时多对多的关系。无需更改即可保留对关系数据库技术的遗留投资。例如，当您的案例需要大规模、低延迟和高可用性时，请使用传统的关系数据库。我希望本文能为读者提供一个有用的框架，让他们思考如何以及何时在您的应用程序中支持多个数据模型，以及何时考虑使用多模型数据库。
