开头还是介绍一下群,如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, Oceanbase, Sql Server等有问题,有需求都可以加群群内有各大数据库行业大咖,CTO,可以解决你的问题。加群请联系 liuaustin3 ,(共2150人左右 1 + 2 + 3 + 4 +5) 新人直接分配到5群,另欢迎 OpenGauss 的技术人员加入。
这是一个关于世界级别的数据库信息的翻译性的系列,相关信息来自于世界级的IT 或 数据库信息类网站。相关文章来自于世界级的world IT info 网站
——————————————————————————————
在过去的工作环境中,数据库的工作相对简单:如帮助企业进行月度结算、生成一些报告,或者回答一些临时查询。数据库很重要,但在企业中还不至于称为一个时时刻刻续要关心的部分。
如今情况有所不同。数据库经常被用于支持业务运营和超大规模在线服务。交易的数据是不间断的,业务是需要连续性的,而且响应时间需要几乎是瞬间的相应的。在这个新的范式中,企业不仅仅通过他们的数据库获得信息——他们基本上是建立在数据库之上的。决策是基于海量数据的实时流,策略是实时制定的,服务是根据实时的数据流个性化的。
关系型数据库处于企业数据处理的中心。它们的角色不仅限于存储,还涉及处理复杂的交易、执行业务逻辑和提供实时的分析洞见。关系型数据库的结构化特性,以及保证事务的原子性、一致性、隔离性和持久性(ACID)的内在能力,使它们在数据成为业务策略核心的当今世界中无法替代。
为了满足现代应用程序的需求,关系型数据库需要一种彻底新的架构。它们必须从头开始设计,以处理大量数据和交易负载,抵御各种类型的故障,并在高需求时期无需人工干预或补丁式扩展策略的情况下无缝运行。
数据库架构必须具备内在的可扩展性和可靠性。这是一个现代it项目中需要首要考虑的,它们必须成为架构的基础。可伸缩性使数据库能够有效地适应波动的工作负载。可靠性确保持续性能,防止数据丢失或停机,这可能严重影响业务运营或决策。
TiDB 是这种新数据库架构的一个典型例子。它是一个为最苛刻的应用程序设计的开源分布式 SQL 数据库,可以扩展来处理高达一百万亿字节(petabyte)大小的数据量。在本文中,我们将探讨赋予 TiDB 可伸缩性和可靠性的架构特性。
TiDB 设计基本原则如下:
TiDB 架构的一个基石是将存储和计算解耦。这两个组件可以独立扩展,确保即使数据需求发生变化,也能实现资源的最佳分配和性能。这使得组织能够最有效地利用他们的硬件,提高成本效益和运营效率。
另一个关键设计元素是 TiDB 支持本地水平扩展,也就是横向扩展。传统的事务性数据库在处理日益增长的数据量和查询负载时遇到困难。最简单的解决方案是纵向扩展,基本上是切换到更强大的硬件。但是,单台机器的硬件存在限制。TiDB 会自动横向扩展以适应交易和数据量的增长。通过向系统添加新节点,TiDB 保持性能和可用性的一致性,即使数据和用户需求增加。
本地水平扩展的另一个好处是它消除了复杂、破坏性的分片操作的需求。分片的概念是通过将数据库分割为更小、更易管理的块,存储在独立的数据库实例和物理媒体上,以加快交易速度并提高可靠性。在实践中,维护一个分片系统需要大量手动工作来保持每个分片处于最佳状态。本地水平扩展消除了这个负担。数据库会根据需求扩展,使其能够处理突发的需求激增,比如黑色星期五的电子商务流量激增。
TiKV 是 TiDB 的分布式、事务性、键-值存储引擎。TiKV 以键-值格式存储数据。它可以自动将数据分割成小块,并根据工作负载、可用磁盘空间和其他因素在节点之间分布这些块。TiDB 在其复制模型中利用 Raft 共识算法,以确保数据块的强一致性和高可用性。
Raft 算法和 TiDB 中的复制机制
Raft 共识算法是 TiDB 架构中的另一个重要组成部分。TiDB 使用 Raft 算法来管理数据的复制和一致性,确保数据的行为就像它存储在单台机器上一样,即使数据分布在多个节点上。
工作原理如下。TiDB 将数据分解为称为 region 的小块。每个 region 充当一个 Raft 组,随着数据量和工作负载的变化,可以将一个 region 分裂成多个 region。当数据写入 TiDB 集群时,会被写入到该 region 的 leader 节点。Raft 协议通过日志复制来确保数据被复制到 follower 节点,保持多个副本之间的数据一致性。
最初,当 TiDB 集群规模较小时,数据包含在一个单一的 region 中。然而,随着添加更多数据,TiDB 会自动将 region 分割成多个 region,使得集群可以水平扩展。这个过程被称为自动分片,对于确保 TiDB 能够高效处理大量数据至关重要。
如果 leader 失效,Raft 保证会选举其中一个 follower 作为新的 leader,确保高可用性。Raft 还提供强一致性,确保每个副本在任何时刻都持有相同的数据。这使得 TiDB 能够在所有节点之间保持数据一致性复制,使其能够对节点故障和网络分区具有鲁棒性。
TiDB的自动分裂和合并机制的一个关键优势是,对于使用数据库的应用程序来说,这种机制是完全透明的。数据库会自动对数据进行重新切分,并在整个集群中重新分配,从而消除了手动分片方案的需求。这既降低了复杂性,减少了人为错误的可能性,同时也节省了宝贵的开发人员时间。
通过实现Raft共识算法和数据块自动分裂,TiDB确保了强大的数据一致性和高可用性,同时提供可扩展性。这种无缝的结合使企业能够专注于从数据中获取可操作的见解,而不必担心分布式环境中数据管理的底层复杂性。
TiDB的分布式架构的另一个关键组成部分是分布式事务,它保持了关系数据库基本的ACID(原子性、一致性、隔离性和持久性)属性。这种能力确保了数据操作会被可靠地处理,并且数据的完整性会在集群中的多个节点之间得到维护。
TiDB对分布式事务的原生支持对应用程序是透明的。当应用程序执行事务时,TiDB会自动处理将事务分布到涉及的节点之间。开发人员无需在应用程序层编写复杂、容易出错的分布式事务控制逻辑。此外,TiDB采用强一致性,意味着数据库确保每次读取都会获得最新的写入,或在存在冲突事务时会报错。
由于分布式事务在 TiKV 存储引擎中得到原生支持,SQL 层中的每个节点都可以同时充当读取者和写入者。这种设计消除了为写入指定主节点的需求,从而增强了数据库的水平扩展性,并消除了潜在的瓶颈或单点故障。与利用独立节点扩展读取能力,但仍使用单个节点进行写入的系统相比,这是一个显着优势。通过消除单写入问题,TiDB 实现了数量级更高的 TPS。
在讨论可扩展性时,必须超越数据量和每秒查询数(QPS)。处理不可预测的工作负载和实施智能调度的能力也同样重要。TiDB 的设计旨在预测并适应不同类型的工作负载和突然需求激增。其调度算法动态分配资源,优化任务管理,并防止性能瓶颈,确保一致高效的运行。
TiDB 在处理大规模数据库操作方面的可扩展能力也表现明显。TiDB 的架构简化了数据库定义语言(DDL)任务,这些任务通常是大型复杂系统中的瓶颈。这确保了即使 TiDB 数据库增长,诸如模式更改之类的操作也能高效执行。
下面我将为您介绍两个 TiDB 可扩展性的实际案例。第一个案例展示了一个单一 TiDB 集群管理了规模达 500TB 的数据,包含了 1.3 万亿条记录。下面的图表是 TiDB 集群监控仪表盘的屏幕截图。
第二个例子来自印度最大的电子商务公司 Flipkart,展示了一个 TiDB 集群扩展到了每秒 100 万次查询(QPS)。与 Flipkart 之前的解决方案相比,TiDB 实现了更好的性能,并将存储空间减少了 82%
TiDB的可靠性 应用程序和服务依赖于持续运行和稳健的数据保护。如果没有这些,用户会很快失去对数据库系统及其产出的信任。
TiDB提供了对高可用性的原生支持,以最大程度减少关键应用程序和服务的停机时间。它还提供了在发生重大故障时快速恢复数据的功能和工具。
复制和副本放置 我们已经讨论了TiDB如何使用Raft算法实现强大且一致的复制。副本的位置可以根据网络拓扑和用户想要防范的故障类型以不同方式进行定义。
TiDB支持的典型场景包括:
在单个机架内运行不同的服务器,以减轻服务器故障 在数据中心内的不同机架上运行不同的服务器,以减轻机架电源和网络故障 在不同可用区(AZ)内运行不同的服务器,以减轻区域故障 通过数据放置调度框架,TiDB可以支持不同数据策略的需求。
自动修复 对于短期故障,例如服务器重新启动,只要大多数副本仍然可用,TiDB就会使用Raft继续无缝运行。Raft确保如果原领导者失败,每组副本都会选出一个新的“领导者”,以便事务可以继续。受影响的副本一旦重新上线,就可以重新加入它们的组。
对于长期故障(默认超时时间为30分钟),例如区域故障或服务器长时间宕机,TiDB会自动从丢失节点中重新平衡副本,利用未受影响的副本作为源。通过使用存储节点的容量信息,TiDB确定群集中的新位置,并以分布方式重新复制丢失的副本,利用所有可用节点以及群集的聚合磁盘和网络带宽。
灾难恢复 除了Raft之外,TiDB还提供了一系列用于灾难恢复的工具和功能,包括数据镜像,快速错误纠正,持续数据备份和全面恢复。
TiCDC(变更数据捕获):TiCDC实时镜像主数据库的更改到一个下游,实现了主从复制设置。在主服务器发生故障时,TiCDC确保数据丢失最小,因为事务持续复制。这个系统不仅有助于灾难恢复,还有助于负载平衡和读操作卸载。数据更改的实时镜像对于需要高可用性的应用程序尤为重要,因为它确保辅助设置可以迅速接管而几乎没有停机时间。
Flashback:TiDB的Flashback功能提供了对灾难中最不可预测的原因之一——人为错误的保护。Flashback允许数据库在垃圾收集(GC)生命周期内恢复到特定时点,因此可以迅速纠正诸如意外数据删除或错误更新等错误,而无需大量停机时间,保持运营连续性和用户信任。
PiTR(按时间点恢复):PiTR持续备份数据更改,使得可以将群集恢复到特定时间点。这不仅对灾难恢复至关重要,还对业务审计至关重要,提供了审查历史数据状态的能力。PiTR提供了额外的数据安全层,保持业务连续性,并协助符合监管合规性。
完整备份和恢复:除了上述针对特定用例的工具外,TiDB配备了全面的完整备份和恢复功能,可在必要时重建整个群集。在灾难性故障场景中,数据结构被破坏或数据的大部分被损坏时,全面备份是不可或缺的。它确保服务可以在最短时间内恢复到正常状态,为最坏情况提供了强大的安全保障网。
设计用于变化的数据库 商业世界围绕着数据展开。由“按实际使用付费”等商业模式推动的全球在线交易激增,为高性能需求增添了前所未有的压力,同时也需要确保性能在需要时可靠提供。
当你围绕着变化这一理念重新设计关系数据库时,你会获得一个分布式SQL数据库。作为业务应用程序的基础,数据库必须能够适应意想不到的变化,无论是意想不到的增长、意想不到的流量,还是意想不到的灾难。
最终,一切都归结于规模和可靠性,即执行能力和对性能的信任。规模赋予用户创造前所未见事物的能力。可靠性使他们相信他们所建立的东西将继续运作。这就是把原型变成盈利业务的关键。在业务的核心,在熟悉的SQL接口后面,是一个为数据至关重要的世界设计的新架构。
完.