当前位置: 首页 > 科技观察

如何为您的微服务选择混合和多模型数据库-_0

时间:2023-03-14 23:20:50 科技观察

如何为您的微服务选择混合和多模型数据库?首开先河,掀起数据库行业的创意旋风。市场上也涌现出一大批具有竞争力的数据库平台。在本文中,我们将探讨如何为您的应用程序选择正确的数据库模型(是的,您可以选择多个!)。我们还将讨论这些数据模型选择将如何帮助您确定数据级别的各种技术。1.云架构、NoSQL和微服务当软件开发人员开始创建基于Web的应用程序时,那些在历史上主导我们多年的关系型数据库架构开始显现出“巨大的压力”。尤其是当我们开发频繁使用的社交应用,以及越来越多的设备连接到物联网(IOT)时,客户端读写大量的数据,这就导致了数据层的扩展需求。同时,为了满足这些高可扩展性需求,新的数据库类型应运而生。在许多情况下,这些新数据库是“非结构化查询语言(NoSQL)”或“非关系”数据模型解决方案。它们不是明确的关系模型,如文档、键值、面向列甚至图形数据库。通常,这些数据库会牺牲一些我们在传统关系型数据库中熟悉的特性,例如:强一致性、ACID事务和各种连接(join)。同时,SOA(Service-OrientedArchitecture)作为一种革命性的数据库技术,一直在朝着微服务架构的风格发展。许多组织已经开始放弃企业服务总线(EnterpriseServiceBus,ESB)等重量级的SOA架构,转而采用更加分散的实现方式。微服务架构的吸引力在于它能够独立开发、管理和扩展各种服务。这使我们在考虑数据库模式实现等方面的技术方面具有很大的实现选择灵活性。例如,假设我们正在开发一个基于大规模可扩展性需求的重要微服务架构。所以,无论项目是一个新的应用还是对现有应用的重构,我们都有机会选择一个新的数据库。1.Polyglot持久化微服务模型的一个优势是封装的持久化。我们可以根据各个服务的需要,自由选择不同的持久化技术。MartinFowler等人提出的术语混合持久化,特指根据不同数据类型选择数据存储的方法。可以说,混合持久化天生就适合微服务。下面的示例图展示了一组微服务,我们如何为每个服务选择使用不同的数据模型?在这里,我不会列举每种数据库类型的适当用例,而只会强调这些数据库类型和混合方法的优点。将混合持久性应用于微服务。开发服务A的团队可能会选择使用表格数据库,例如ApacheCassandra,因为它可以大规模管理核心应用程序数据。例如,零售应用程序的库存类数据可能非常适合Cassandra的表格形式。Cassandra提供了一套协调机制的工具集,包括批量调整一致性的能力,以及作为完整ACID事务替代的轻量级事务。服务B可能只需要支持通过众所周知的键查询参考值,这样简单的语义,比如产品目录的描述性数据。这是键值存储的一个很好的例子,我们可以通过产品ID的众所周知的键值来查找BLOB(二进制对象文件容器)类型的数据。然后会使用大量的内存空间来缓存key-value类型的数据,从而支持大规模超高速读访问。服务C主要考虑的是提供半结构化的内容,如:网站页面或表格、文档存储等。这些类型的数据非常适合。文档的存储具有“很多key-value类型相似,只有某个key不同”的数据结构。例如,只要对一些特殊的属性项进行索引,就可以加速各种搜索能力。服务D涉及导航各种数据之间的复杂关系,例如客户数据和组织内不同部门的客户联系人之间的历史数据。这可能涉及各种服务持有的数据类型之间的各种关系。例如,在这种情况下,你可以选择让你的服务为各种底层表创建一个只读的视图,然后调用其他“拥有”自己数据类型的“前门”服务API,进行过滤来实现任何所需的转换。最后,我们可能还有一些使用关系技术的遗留系统和服务,或者我们可能有一个数据服务来管理少量不经常更改的数据。那么关系数据库非常适合此类用例。2、个别服务需要混用吗?还有一种可能:我们设计一个服务放在多个数据库之上。例如,我们可以创建一个酒店服务,它使用映射名称和ID之间关系的键值存储索引。它还使用Cassandra的表格样式来存储有关酒店的描述性数据。混合服务?注意:使用非规范化的设计方法,也可以在Cassandra中实现名字和ID的映射。当然,你需要使用一个单独的表来维护名字和ID的映射关系。虽然这会使用更多的存储空间,但它简化了管理单个键值存储操作的复杂性。所以我的建议是:只要有可能,将给定的微服务连接到单个数据模型(和数据库)就完全没问题。如果您遇到需要将单个服务放置在两个不同数据库之上的情况,请确定该服务的范围是否太大。如果它太大,您可能需要考虑将其分解为多个较小的服务。3、混合持久化的局限性和优缺点混合持久化的主要缺点是:在初期开发和运营方面,需要支持多种技术的成本。开发成本主要来自对每个新的数据库技术培训个人开发人员的成本。如果您的开发团队高度机动,这个缺点会更加明显。另一个缺点是支持多个数据库的运营成本。如果数据库的管理是集中的并且整个团队必须跨多种技术保持高水平的维护,这可能会出现问题。但是当开发团队只支持他们为生产环境选择的数据库时,这个问题就会得到适当的缓解,从而形成真正的Devops运行模型。4.多模型数据库数据库提供商已经开始构建和改进一些多模型数据库作为混合持久化方法的替代或补充。术语“模型”是指由数据存储提供的抽象模型,例如表格(关??系和非关系)、列存储、键值、文档或图形。我们可以理解为多模型应用使用不止一种类型的数据存储,而多模型数据库可以支持多种抽象。DataStaxEnterprise(DSE)是多模型数据库的一个示例,其核心使用构建在图(DSE图)之上的抽象来支持Cassandra分区行存储(表)模型。在此核心模型之上创建您自己的键值和各种文档类型的抽象非常简单,如下图所示。通过这种方式,我们可以修改上述混合方法,为我们的所有服务利用一个单一的底层数据库引擎。同时,我们也可以使用单独的Cassandrakey-value空间来保持不同服务拥有的数据之间的清晰界限。作为多模型数据库与DataStaxEnterprise交互。让我们看看它是如何工作的:表单:像服务A这样的主要应用程序服务可以使用Cassandra的查询语言(CQL)直接与DSE数据库交互。键值:虽然Apache和DataStax的Cassandra版本都没有提供显式键值API,但可以设计服务B等服务,以将表交互限制在Cassandra中以进行键值存储。例如:CREATETABLEhotel.hotels(keyuuidPRIMARYKEY,valuetext);//orifyouprefer,"blob"文件:Cassandra通过各种JSON文件,可以支持文档类型交互,可以用于服务C等服务。注:因为Cassandra确实需要表模式,您不能随意插入任意JSON来定义新列,这通常需要与文档数据库相关的功能。Graph:对于像ServiceD这样高度支持数据互联的服务,DSEGraph是直接构建在DSE数据库之上的高度可扩展的图数据库。DSE图通过ApacheTinkerPop项目支持强大且富有表现力的GremlinAPI。5.多模型数据库的优点和局限性在考虑是否使用多模型数据库时(或者在使用现有数据库的多模型功能时),您需要考虑我们讨论的混合持久化方法的含义多于。开发和运营成本。使用多模型数据库简化操作。无论是不同的开发团队使用不同的API,还是不同的后端数据库平台交互模式,我们都受益于只需管理一个平台。选择多模型数据库时要考虑的一个方面是如何支持各种模型。一种常用的方法是:一个单一的基于本地的底层模型和其他层叠在它之上的模型共同构成一个数据库引擎。分层数据模型用于公开其底层主模型的各种特征。例如,在ThoughtWorks的技术雷达卷。16(https://assets.thoughtworks.com/assets/technology-radar-vol-16-en.pdf),讨论表明在CassandraFeaturesofthetoplayeredDSEgraphmodelandthetrade-offsinvolved:Neo4j,ourlong-timefavoriteanduseNotlocaltables.)逐渐暴露出大数据集类型的局限性,构建在Cassandra之上的DSE图表应运而生。当然,这种模式也有其自身的取舍,例如:你将失去ACID事务和Neo4j的运行时无模式特性;但DSE对底层Cassandra各种表的访问、Spark对负载分析的集成,以及强大的TinkerPop/Gremlin查询语言,还是值得考虑和选择的。如果你考虑在你的web架构应用中使用不同的数据类型,你可能会发现不同的数据类型有不同的一致性要求,但是真正需要即时一致性的数据类型并不多。另一个重要的考虑:多模型空间的问题,即不同数据库模型和诱导的集成和交互,以及访问数据的各种操作和分析用例。DSE支持通过Spark(DSEAnalysis)访问图数据以进行分析,而DSESearch提供了为存储在DSE数据库中的数据创建各种搜索索引的能力。2.微服务数据模型的四步曲既然我们已经了解了混合和多模型方法的各种优点,那么我们应该如何选择大规模微服务应用程序的数据模型呢?请参考以下步骤:1.识别应用中的主要数据类型,一个一个创建服务,控制每个服务的持久化。如果可能,将多模型数据库应用于所有服务,使服务能够根据它们选择与之交互的数据更改模式。2、根据你的网页的扩展性和易用性,key-value分层和文档的语义,根据需要使用表格形式(如DSE数据库)作为你的主要模型。请务必考虑使您的数据可用于各种操作和分析用例的方法。这使您可以提前计划如何使用查找索引等功能并将其复制到分析数据中心。3、使用高度相关的数据图形式(如DSE图),尤其是当实体之间的关系比实体本身具有更多的属性时,或者需要获取同一实体之间的多种关系时。4.当您不需要更改时,请保留传统的关系/SQL技术架构。例如,当您的用例不需要大规模、低延迟和高可用性时。我希望以上内容为您提供了一个有用的框架,用于思考如何为您的应用程序提供多模型支持,以及何时何地使用多模型数据库。原标题:如何为你的微服务选择数据库,作者:JeffCarpenter