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

DatabaseShardingArchitectureIndepthAnalysisGuide

时间:2023-03-21 17:54:33 科技观察

本文翻译自ApacheShardingSpherePMCPanJuan在StackOverflow上发表的技术文章《Howshardingadatabasecanmakeitfaster》。原文链接:https://stackoverflow.blog/2022/03/14/how-sharding-a-database-can-make-it-faster/数据分片往往是分布式数据库提升性能的众多首选方法之一,以及近年来的技术革新,逐渐使其成为最佳选择。数据库在今天受到很多关注,因为它们管理着公司最重要的数据资产。三十年前,数据主要存储在纸张、磁带或某种类型的磁盘上。当时,人均产生和消费的数据量很小,因此这些方法可以有效地支持数据的存储、管理和访问。然而,在“数据为王”的时代,情况就大不一样了。随着智能手机的出现和普及,人们的日常生活越来越离不开手机。手机应用程序消耗和产生的数据量在十五年前是不可想象的。海量数据意味着数据库集群需要处理巨大的流量。一些顶级网站和服务器每周都有数十亿的访问量,数据库集群承受着巨大的压力。我们如何处理到达数据库集群的巨大数据流量?答案可能是使用数据分片。也许您从未听说过数据分片,或者您选择忽略它作为应对当代挑战的过时解决方案。数据库分片架构可能不像其他解决方案那样华而不实或花里胡哨,但它绝对既有效又实用。最近,数据分片实现了不久前不可想象的重大技术创新(例如分布式SQL/DistSQL,这使得分片更易于实施和管理)。也许这就是为什么它在一些寻求实现数据可扩展性的区块链公司中越来越受欢迎的原因。数据库碎片化数据库已经存在了50多年,在那个时候您可能会认为数据库没有创新的空间。但事实上,数据库碎片化已经成为科技行业增长最快的垂直领域之一,因为现有数据基础设施的复杂性似乎只会变得更糟。许多现代应用程序都建立在多个通常具有特殊用途的数据库之上。单个应用程序可能包括用于存储和访问内容的关系数据库(例如PostgreSQL)、用于内容缓存的内存数据库(例如Redis)、自定义数据库(例如时间序列数据库)和数据仓库用于分析。现在,想象一下当一个企业有多个应用程序,或者不同的部门使用不同的应用程序,或者更糟的是,不同的供应商同时使用不同的数据库时会发生什么?如上所述,数据已经成为任何企业最重要的资产之一,而近期数据库技术的快速发展离不开人工智能、机器学习、区块链和云技术的快速发展。根据DB-Engines的统计,有超过350个数据库管理系统,还有更多的数据库系统甚至没有包含在列表中。根据卡内基梅隆大学设计和维护的“DatabaseofDatabases”网站,目前有792个值得关注和差异化的数据库管理系统。业界有如此多不同的数据库管理系统(简称DBMS),这也反映出企业在选择数据库管理系统时存在各种潜在需求。例如,银行或其他金融机构可能会选择SQLServer或PostgreSQL等关系型DBMS,以确保其结构化数据具有ACID(原子性、一致性、隔离性和持久性)事务特性。对于拥有大型在线多人游戏的企业或具有在线会话的Web应用业务,通常首选Redis等键值NoSQL数据库。进行社交媒体分析的企业通常选择图形数据库,而物联网(IoT)企业则选择时间序列数据库来支持其传感器或网络数据。如果您认为这些选项不错,那么随着未来几年更多解决方案投放市场,您会爱上它们的多样性。这些解决方案可能由创新型初创公司实施,而更多成熟的数据库供应商将继续发布新产品或增强现有解决方案。用不了多久,数据库市场的碎片化趋势会更加明显,而碎片化也带来了厂商技术的兼容、遗留系统的适应性、高昂的更换成本等重大挑战。为什么需要数据分片?受NoSQL和NewSQL概念日益流行的启发,越来越多的新数据库产品被推向市场,传统数据库难以处理海量数据和查询流量,但仅靠这些概念并不能真正解决数据增长问题。分片将数据拆分为单独的行和列,并将它们保存在单独的数据库服务器实例上以分散流量负载。每个小表称为分片。ApacheHBase或MongoDB等NoSQL产品具有分片功能,分片架构也内置于某些NewSQL系统中。让我们看一下特定类型的NewSQL架构,即与当今OLTP问题相关的分片架构。虽然许多解决方案可以最大限度地减少数据库负载,但数据分片解决方案提供以下好处:?跨多台机器的分布式数据存储?轻松平衡不同分片上的流量负载?显着提高查询性能?无需通过额外操作扩展数据库?有效地实现重用遗留数据库管理系统的升级和升级?使用代理支持多租户,允许多个数据库跨用户使用单个服务器或云计算资源。如何进行数据库分片接下来,我们将通过介绍数据分片的基本流程来展示如何实现DBMS的分片。此外,在介绍了配置和基本概念之后,还会更深入地解释一些亮点。创建分片的最佳技术之一是将数据拆分为多个小表,也称为分区。原表可以分为垂直分片或水平分片,即在一个单独的表中存储一个或多个列,或者在一个单独的表中存储一个或多个行。这些表可以标记为“VS1”用于垂直分片,“HS1”用于水平分片,其中数字代表第一个表或第一个模式,依此类推。这些数据子集组合起来形成表的原始模式。以下是与分片相关的两个关键概念:?分片键:指示行存储在哪个分片中的特定列值。?分片算法:一种将数据分布到一个或多个分片的算法。Step1:分析场景查询和数据分布,确定合适的shardingkey和shardingalgorithm要确定存储指定行的shard,需要对shardingkey应用sharding算法。不同的分片策略适用于不同的场景。常见的分片策略包括:MOD:Modulo的缩写,一种模数分片算法,用于将每第n行或第n列发送到特定分片。例如,MOD3算法会将第1、4和7行发送到第一个分片,将第2、5和8行发送到第二个分片,将第3、6和9行发送到第三个分片,依此类推。HASH:Hashmodulosharding算法,通过Hashsharding将数据均匀随机分布在各个shard之间。根据为该行的分片列值计算的一致散列,将每一行放置在一个分片中。RANGE:一种基于分片边界的范围分片算法,它将特定范围的行或列发送到每个分片。TAG:发送匹配特定值的所有行或列。例如,如果分片键是“ID”并且分片算法是“ID模2”(即拆分偶数行和奇数行),则行将按如下方式分布:分片键的适当算法和分片策略会极大的影响查询效率和以后的横向扩展。不正确或糟糕的分片算法总是会在不同的分片之间产生冗余数据进行计算,最终导致整体计算性能不佳。在决定如何对数据库进行分片时,需要考虑的重点是明确业务查询和数据分布的特点。虽然每个数据库都会有影响数据分片策略选择的个体因素,但我们可以通过提供一个场景案例来解释一个好的分片算法如何有效地实现数据分布。RANGE例如,在对包含时间戳日志详细信息的表进行分片时,建议使用以创建日期为分片键的RANGE分片算法,因为传统上人们倾向于只查询特定时间范围内的这些详细记录。然而,在使用date-time时,RANGE算法可能会带来另一个问题:由于历史记录的更新频率通常较低,而最近的记录更新和查询频繁,大多数查询会针对最新存储记录的分片,从而导致大多数查询相互竞争更新该数据的专有权。MODMOD分片算法可以有效避免上述激烈竞争。它按照shardingKeyMODshardsnumber来切分行,最新的行会被切分到不同的分片中,这样最新的query就可以发送到不同的分片中,避免最新行之间的竞争。当分片键是字符串值(并且可能对泄漏敏感)时,可以使用HASH算法创建一个值,MOD算法可以使用该值在分片之间分布数据。当TAG需要根据cell的值对数据进行分片时,推荐使用TAG分片算法。假设,为了遵守通用数据保护条例(GDPR),所有与欧盟相关的数据都需要存储在位于欧盟的服务器上。基于这个原因,我们如何操作基于分片的分布式数据库系统?假设数据库管理员(DatabseAdministrator,DBA)使用TAG分片算法,如果想知道有多少条记录受到影响,可以将带有国家/地区标签的数据行发送到位于特定国家/地区的指定分片,分片数据库系统可以通过简单地从与欧盟相关的分片返回COUNT(*)来回答这个查询来自一个碎片。没有一种放之四海而皆准的方法。要获得最佳的数据库性能,请花更多的时间对特定的业务场景进行深入分析。当然,基于分片的分布式数据库系统的开发者,为了实现用户快速上手,通常会选择满足大多数用户场景的通用策略。第2步:迁移现有数据如果您决定实施分片,则无需将所有原始数据迁移到分片集群。但这样做是有风险的,会面临以下问题:如何在分片的同时保证业务不间断运行如何在新分片集群中重放增量数据如何对比原数据库和新分片集群的数据找到最佳时间将流量切换到新的分片集群但是,如果你决定将历史数据迁移到分片,传统的方法是:1.首先,通过分片算法将历史数据划分到新的数据库分片集群中。建议使用自动数据迁移程序来运行所有需要的SQL查询。2、其次,运行平台或程序拉取并解析数据库日志,了解数据分片过程中发生了哪些变化,并将这些变化应用到新的分片集群(增量数据分片)中。3.第三,选择一种数据检查策略,将原数据库和新分片集群中的数据进行对比。这些数据检测策略非常灵活,可以选择高精度检测或快速检测,也可以选择折中的检测策略。是比较每个单元格,还是只检查总数,由您决定。为了达到最准确的数据检查策略,可以采用逐行比较,这也是最费力的检查方法。只比较原数据库和新集群的行值是最快的检查方式,但准确性大大降低。其他策略,例如CRC32,正在实现准确性和速度之间的平衡。第3步:将流量转移到新集群假设上述步骤已成功完成,下一步是将实时流量转移到新的分片集群。此操作适用于无法写入数据库集群的时间段,以便两个数据集保持一致并保留可选查询-此步骤是非高峰时段的常见选择。应抑制所有更新请求以保持分布式数据的一致性。但是,可以允许查询,因为查询不会导致分布式系统发生任何变化。过程很简单,但每个部分都很难处理。自动执行将最大限度地减少停机时间,但由于正在处理的数据的重要性,建议谨慎行事。不过,好消息是您不是第一个面临这些挑战的人。开源项目帮助我们站在巨人的肩膀上。整个分片过程是ApacheShardingSphere的主要特点之一(我也是该项目的贡献者之一)。它提供了各种分片策略、数据迁移、重新分片和管理现有分片等功能。它还提供了许多更高级的功能来帮助解决我们将在下一节中提到的问题。此外,作为额外的好处,ApacheShardingSphere拥有一个活跃的社区,这意味着您的大部分问题都已得到解答。什么是好的碎片?现在我们已经了解了分片工作流程以及在数据库上执行分片的必要步骤。但是一个好的碎片应该是什么样的呢?在不过多扩展边缘理论或背景和场景特定要求的情况下,良好的分片通常具有六个特征。如果负责运行操作的DBA(数据库管理员)发生变化,分片应该易于设置和理解。Sharding具有高可用性、弹性可扩展性、高分布式系统性能、可观察性和低迁移成本。这六个元素代表了一个理想的分片,但它也取决于您选择的分片客户端。使用分片和副本由于数据库场景的多样性,需求会随着应用的扩展而变化。因此,除了上述核心流程外,您还需要了解以下内容。提高数据库性能和可伸缩性的另一种方法是通过副本。副本创建独立的副本数据库节点,写入一个节点的数据被复制到另一个副本节点。通常,从事热情项目的专业人员和开发人员都努力最大限度地利用数据库以实现高可用性和高性能。然而,分片和副本的架构会使数据库管理和路由策略复杂化。假设每个分片都有副本节点,结果会如下图所示。如果一个主节点有多个副本,应用访问它们的情况就比较复杂。那么,分片和副本有何不同?上面说了sharding,就是把一个大表拆分成几个小表,创建很多分片;另一方面,副本将创建原始表的多个副本。每个副本将包含原始节点(主节点)的全部数据。分片可以帮助用户对存在于多台服务器上的数据进行负载均衡,以实现可扩展性;而副本将创建主数据库备份以提高系统可用性。这两种不同的架构给分布式系统带来了不同的优势。基于这个论点,一些用户希望同时拥有两者,因此拥有同时利用分片和副本的架构并不少见。如下图所示,用户可能希望将包含大量数据的数据库跨不同的服务器(如P1、P2、P3)进行分片。每个查询也会被分成不同的分片,以提高分布式数据库系统的TPS或QPS。但是,一旦其中一个分片崩溃并离线,可用性就会下降到2/3。不仅如此,召回离线副本非常耗时,而且代价高昂。为了增加这种分片系统的可用性,复制每个分片将是一种有效的方法,即复制到上述主节点P1、P2、P3。R1、R2、R3的存在可以很好的解释我上面提到的解决方案。当P1不可用时,其副本R1将成为主节点为业务服务。可以肯定的是,停机时间越短,您的业务和服务损失就越少。这个想法乍一看不错,但是这种分布式、分片的数据库系统的拓扑结构,使得应用访问变得非常复杂。假设每个主节点有两个副本,P1、P2、P3及其六个副本的网络会让开发人员感到困惑和负担。他们可能会问这样的问题:哪个主节点适合这个查询?如何访问他们的副本?如何在不同副本之间进行负载均衡?一旦主节点发生故障,谁负责重新路由此查询?在这个假设的场景中,开发人员负责编写代码以确保业务效率。这种架构确实有它的优势,但它的复杂性也意味着它难以利用和维护。如何向应用程序隐藏这种复杂性?通常,有两种客户端或访问模式可供用户选择,外加一种新的“额外”类型的客户端。用户可以通过专用的数据库连接驱动程序或通过连接应用程序以路由数据的代理应用程序来启动分片。Sidecar是可用的分片模式中一个相对较新的概念,它起源于服务网格。简单的说就是部署了某种服务的proxy实例,处理不同服务之间的通信,监控等。这种模式就像摩托车上的sidecar。这意味着边车附加到父应用程序,同时为该应用程序提供支持功能。如果我们使用专用的驱动程序或代理而不是使用sidecar,它将只是一个帮助用户管理数据库集群的单一数据库服务器。这样,应用程序就不会受到这些复杂访问拓扑的影响,也不必重构代码来适应新框架。总结与趋势Sharding是解决网络应用快速发展带来的新挑战的途径之一。其他解决方案包括DBaaS(或云上的数据库)、新的数据库架构或简单地增加用于存储的数据库数量的老式方法。兜兜转转,我希望这篇文章至少可以帮助您了解分片架构。如果您听说过分片但认为它已经过时,希望本文能改变您的想法。我其实不喜欢时尚这个词,因为它对我来说感觉转瞬即逝,因为今天流行的东西明天可能就过时了。虽然生活中很多事情都是如此,尤其是技术,但我更愿意根据具体场景下的实用性、效率和成本优势来判断一项技术。所有这一切都表明,虽然对新趋势持开放态度是件好事,但不要忘记,有时现有的和经过验证的技术可能是最好的解决方案。作者介绍潘娟,SphereEx联合创始人兼CTO,Apache成员,ApacheShardingSpherePMC,Apachebrpc(Incubating)&ApacheAGE(Incubating)导师,中国木兰开源社区导师。曾负责京东数科数据库智能平台的设计与开发,现专注于分布式数据库&中间件生态及开源领域。被评为《2020 中国开源先锋人物》,OSCAR巅峰开源人物。*参考文档[1]https://db.cs.cmu.edu/papers/2016/pavlo-newsql-sigmodrec2016.pdf[2]https://github.com/apache/shardingsphere[3]https://opensource.com/article/21/9/distsql