山东有实力的网站开发多少钱,沈阳网站制作机构,最新电大网站开发维护,网站开发行业标准数据库是应用开发中非常重要的组成部分#xff0c;可以进行数据的存储和管理。随着企业业务向数字化、在线化和智能化的演进过程中#xff0c;面对指数级递增的海量存储需求和挑战以及业务带来的更多的热点事件、突发流量的挑战#xff0c;传统的数据库已经很难满足和响应快…数据库是应用开发中非常重要的组成部分可以进行数据的存储和管理。随着企业业务向数字化、在线化和智能化的演进过程中面对指数级递增的海量存储需求和挑战以及业务带来的更多的热点事件、突发流量的挑战传统的数据库已经很难满足和响应快速变化和持续增长所带来的业务诉求。伴随云原生理技术的不断普及在数据库这个维度上也带来了巨大的变化。那就是云原生数据库技术的出现和被普及。
云原生数据库是一种通过云平台进行构建、部署并交付给用户的云服务它专门为云环境设计的数据库它可以自动扩展和缩减资源提供高可用性和数据安全性同时支持多种数据模型和编程语言。相对于传统数据库它最大的不同就是以云原生的形式进行交付它具备传统数据库所不具备的直接访问性和运行时的可伸缩性属于 DBaaS 平台DataBase as a Service。
1、云原生关系型数据库
关系型数据库在当前软件研发领域一致都是最主流的数据库类型而云原生关系型数据库在其架构上有着非常大的优势具体体现在
资源池化、大容量、高性价比
传统关系型数据库需要自行适配硬件如果要扩展需要购买设备。而云原生数据库从一开始就充分享受了云平台的各种技术优势资源共享池化可以存储海量的数据同时提升了资源的利用率让小公司也可以享受到像 BAT 这些大公司才能使用的先进硬件及部署环境。所使用的资源可以按需付费只需要对使用的部分买单即可降低了成本。
提供极致弹性
云原生数据库可以实现计算和存储分离CPU、内存和存储这些都可以独立弹性支持独立扩展变配速度快可以满足不断变化的多种业务需求实现完全 Serverless 化。
强大的容灾能力和可靠性
云原生数据库充分利用强大的云基础设施提供跨节点容灾支持。
云原生数据库充分利用新技术新硬件比如利用 RDMARemote Direct Memory Access远程直接数据读取技术实现分布式共享存储通过数据的多副本技术提升容灾能力。
云原生数据库充分提升跨区域的复制能力提升高可用能力保证用户业务的可用性。
完全托管
云原生数据库完全托管给云平台用户无须负责硬件的购买和部署、软件错误的修复、实例参数的配置、监控的开发、数据的备份和管理等工作。
智能化和自动化的管控平台
云原生数据库将机器学习、人工智能技术与数据库内核相结合使得数据库更加智能化和自动化实现自感知、自决策、自恢复和自优化。
2、云原生数据库技术分析
云原生数据库一致持续进行着技术演进。在硬件资源方面CPU/内存/存储的独立资源化对资源间的互联提出了很高的要求各个节点之间包括存储节点、计算节点甚至内存池节点的互联都需要高性能 RDMA 网络甚至其他新总线的支持。在软件方面因为资源的池化并不能在操作系统层面实现完全透明数据库需要对功能模块进行拆分和重构以实现不同的组件通过高速网络在不同的物理机的互连和运行从而实现性能的最大化。
OLTP 数据库作为一个整体需要在资源分离的情况下对外保证 ACID原子性、一致性、隔离性和持久性和外部一致性因此需要高效的分布式缓存、分布式锁和分布式事务机制来保证读写的快速弹性和整体的高性能。另外在保证正确性的前提下需要减少节点之间数据日志的通信量。
基于阿里的 PolarDB 对云原生数据库的核心技术进行分析如下
计算存储分离技术
云原生时代要求数据库具备海量的计算能力和数据存储能力。在这样的场景下传统数据库的计算和存储耦合架构的缺点逐渐暴露
资源浪费计算能力、存储能力达到瓶颈虽然这两种情况往往不会同时发生但单纯增加机器必然导致资源浪费扩展麻烦在计算和存储耦合的模式下如果单纯增加设备总会或多或少衍生出数据迁移和系统重新配置的问题扩展能力弹性不足
计算和存储耦合架构在云原生时代暴露出了缺乏弹性的严重问题。而在云原生数据库中已经实现了存储资源的独立扩展。基于分布式存储的云原生数据库 PolarDB 就已经实现了存储资源的池化及独立扩展。
计算和存储分离架构为云原生数据库带来了计算和存储上的实时水平扩展能力实现了计算能力上的极致弹性。由于单个数据库实例的计算能力有限传统做法往往是通过搭建多个数据库副本分担压力从而提供数据库扩展能力。然而这种做法需要存储多份全量数据日志数据频繁同步造成了过高的网络开销成本。同时在传统数据库集群上增加副本需要同步所有增量数据这又带来了同步延迟上涨问题。所以PolarDB 采用了共享存储集群的数据架构实现多个计算节点可以挂载同一份存储。计算节点可以单独扩展支持一写多读集群的部署且提供读扩展能力支持在分钟级扩展到15个读节点。
PolarDB 的系统架构图如下 图片来自于网络
计算内存分离技术
计算和存储分离的云原生架构虽然实现了计算和存储资源的独立弹性但计算节点仍然包含 CPU 和内存无法实现这两者的秒级弹性扩容收缩。与此同时在很多业务场景下这两者的业务需求很不一样所以云原生数据库也在尝试计算和内存的分离技术。
具体实现的核心点一般包括
缓冲区通过单独进程进行管理允许页面缓存独立于数据库。在出现数据库故障时页面缓存将保留在内存中确保数据库重启时不用重新加载数据而是直接使用最新状态预热缓冲池保留数据库实例崩溃前的数据内存状态数据库崩溃重启时不必再执行“故障恢复”的过程即回放日志以保障数据的一致性
除了独立缓存技术PolarDB 在 CPU 和内存分离方面有一些它独特的创新技术
数据库实例的 CPU 和内存资源可以部署在不同的物理机上并通过 RDMA 高速互联。因此CPU 和内存资源占比不再固定而是可以根据业务负载动态变化。所有 CPU 和内存资源都可以在集群资源池的维度进行分配利用业务的错峰和水位有效提升资源的利用率降低整体成本引入了独立的分布式共享内存池。在此架构下同一个数据库实例的内存可以由位于不同内存节点上的多块内存组成。因此缓冲区的大小不再受物理机限制在 CPU 和内存分离后PolarDB 的计算进程不再包含大量内存而是只有少量高速缓存。这使得计算进程变成了无状态的节点从而实现了快速的跨物理机弹性
高可用及数据的一致性
高可用率和灾难恢复能力是数据库的重要考量因素。云原生数据库通过多副本技术确保数据的可靠性。
PolarDB 通过 PolarFS 分布式文件系统实现了数据多副本及一致性。PolarFS 是国内首款面向 DB 应用设计的、采用了全用户空间 I/O 栈的低延迟高性能分布式存储系统。PolarFS 对 Raft 协议进行了优化实现了 Parallel-Raft 算法大幅提高了数据同步保证一致性的能力以分布式集群的方式提供了优异的存储容量与存储性能的扩展能力。在一个主集群三个副本的基础上PolarDB 还包含了一个跨机房的备节点以提供多机房容灾能力。 图片来自于网络
PolarDB 在存储层PolarStore提供了三个副本的同时还通过自研的 x-Paxos 库提供了跨节点、跨机房的数据同步以此提供跨 AZ 级别的容灾、RPO0 的解决方案。这个方案利用 PolarDB 自主物理复制能力提供更可靠、更低延迟的复制。相比 RDS 和 MySQL 的逻辑日志复制PolarDB 在节点切换时受大事务、DDL 的影响更小且可以保证 RTO 小于一分钟。PolarDB 三个节点分别用于部署 Leader、Follower 和 Log 节点。其中Log 节点只记录日志不参与选主不存储数据部署成本相比现在的架构多了 Active Redo Log但成本增加很少。 图片来自于网络
数据及日志的复制技术
PolarDB 为代表的云原生数据是基于 MySQL 发展而来的MySQL 数据库多采用逻辑日志和并行回放技术以提升备节点的性能。然而逻辑日志只能在事务提交时产生备节点也只能在主节点完成提交后才能在本地状态机中回放出主节点的状态。一旦遇到较大的事务这种主备之间的延迟将会非常明显。另一方面虽然 MySQL 具备并行回放能力但由于回放的并行粒度较大因此常受限于实际的使用场景。如在单表更新频繁的场景中实际上备节点只能做到串行回放。同时采用共享存储架构虽然多个节点是读取同一份存储数据但各个计算节点的 in-memory 数据仍需要保持一致这个“物理”的数据一致性是逻辑复制无法做到的。所以要想从根本上解决该问题势必需要将逻辑日志复制演进为物理日志复制。物理日志即在数据库更新时产生的写前日志这种日志一般针对数据库页面修改而产生每个页面的修改对应于一条或者多条日志项。如果复制物理日志并在备节点上回放那么数据库就具备了复制内容少、备节点上可执行更细粒度的并行回放可以页面为粒度进行并行回放等优势。
PolarDB 从架构设计开始就纳入了物理复制的思路。在代码实现中PolarDB 在内核层面实现了大量优化从而可以更好地适配 PolarFS 和 PolarStore。比如在 Redo Log 中加入一些元数据以减少日志解析时的 CPU 开销。这个简单优化减少了 60% 的日志解析成本。另外PolarDB 也重用了一些数据结构以减少内存分配器的开销。 图片来自于网络
跨地域高可用技术
随着数字经济时代的到来越来越多的商业行为逐渐数字化这就对互联网基础设施提出了越来越高的要求。数据库作为最基础的服务设施需要达到数据零丢失、服务零间断等标准才能在最极端的环境下满足业务最苛刻的需求。为满足双零需求在设计上数据库架构多采用异地多活的部署模式将数据库系统跨越一定的物理距离部署在多个地域要求多个地域内的数据保持一致并在某个地域发生故障时可以切换到另外一个可用域且该切换要做到数据不丢失、应用无感知。同城三中心、跨城五副本等架构正逐渐成为业务标配。在这些需求下云数据库不但要做到地域内的多节点和多副本更要支持跨区域的多点复制、迁移和服务功能。
为了解决跨地域高可用的强需求全球跨地域部署的强一致高可用解决方案不断涌现。 PolarDB 推出了全球数据库PolarDB Global Database NetworkPolarDB-GDN解决方案目前已覆盖全球 10 余个地域。PolarDB-GDN 主要解决了跨地域的数据读写问题和高网络延迟下的数据同步问题。全球数据库内的主集群与只读集群间采用了高速并行物理复制的技术所有集群间的数据都保持同步且在全球范围内的延迟控制在2秒之内这大大降低了非中心区域应用访问的读取延迟。
Serverless 及多租户技术
云原生数据库的一个特点是能够提供按需分配的资源。随着资源的完全池化整个数据中心甚至多个数据中心相当于现在的一台物理机上面只有一个多租户的云原生数据库每个用户都可以不受限制地扩展其读写能力一个用户可以瞬间使用大量 CPU 或内存资源支撑起业务高峰。因为所有资源的完全池化CPU、内存、存储使用率均可达到较高水平所有资源都按量计费相同的服务器资源可以支撑更多的用户业务从而提升产品的竞争力。
HTAP
传统的企业数据库系统根据其主要功能和性能不同可分为 OLTPOnLine Transaction Processing联机事物处理系统和 OLAPOnLine Analytic Processing联机分析处理系统。在传统数据库架构中OLTP 数据库和 OLAP 数据库是完全分离的。随着新业务需求的不断衍生OLTP 数据库往往还需要具备执行一些分析类 SQL 查询的能力。对分析需求不高的业务企业可以节约极大的数据库成本。兼具 OLTP 和 OLAP 能力的 HTAPHybrid Transaction/Analytical Processing混合事务/分析处理系统已成为数据库发展的重要趋势。目前越来越多主流的 OLTP 数据库加强了其执行复杂 SQL 的能力。可以预见OLTP 数据库将持续在执行框架、数据格式、副本形态、软硬件设计等方面加强执行复杂分析 SQL 的能力成为兼具 OLTP 和 OLAP 能力的 HTAP 数据库。
3、云原生多模数据库
随着业务的不断多样化应用对于数据的多类型处理能力提出了新的要求而传统多套系统组合解决方案又具有架构复杂、维护成本高、起步门槛高等痛点使得企业对于数据库系统提供多模能力的诉求越发凸显。
为了适应不断演进的业务需求云原生 NoSQL 数据库必须具备多模的能力成为云原生多模数据库实现一种数据库服务多种数据模型的能力并内置数据模型的转化与统一的访问语言。
主流 NoSQL 多模数据库的实现方式通常是先将数据模型抽象为 KV 数据再由 KV 数据通过存储引擎存储于硬件介质之上。以 KV 数据抽象为基础实现多模能力工程复杂度低但对于时序或者图这类具备显著数据特征的数据模型来说却不能最大程度地发挥其能力优势。
4、数据库安全
数据安全是企业的生命线而数据库又是对最核心数据进行计算和存储的部分所以数据库在企业中通常处于最核心的位置。从机房、网络、服务器、数据交换设备、操作系统、应用程序到数据库自身数据库所处的环境异常复杂安全隐患非常多。在传统线下环境中要想完整建设如此多环节的安全体系从成本、可运维性、稳定性角度而言所面临的挑战非常大。同时安全能力的迭代和运营也需要持续进行稍有不慎就会导致数据泄露和数据破坏的问题发生。
随着云原生数据库的普及数据库安全机制云原生化的需求日益强烈。相比传统云下数据中心云原生安全体系具有开箱即用、可弹性伸缩、自动进化与修复的能力。从安全漏洞、数据破坏等角度出发云原生保护能力比传统线下基于边界的安全形态更有优势。云原生数据库在敏感数据加密能力上提供了全链路端到端的加密手段以针对服务面和控制面的内外部人员操作进行全面的访问授权、审计和监测对审计日志提供基于区块链技术的防篡改能力使云原生数据库更加安全与可信。
