win7 iis配置网站 视频教程,泉州seo网站关键词优推广,龙岗英文网站建设,海口房产网OB君#xff1a;2020年9月25日#xff0c;OceanBase在外滩大会举办的“数据库#xff0c;新标杆#xff0c;新征途”分论坛正式落幕#xff0c;内容涵盖数据库的趋势探讨、分布式数据库的技术创新与行业应用#xff0c;及国内数据库的发展与生态。欢迎持续关注本系列内容…OB君2020年9月25日OceanBase在外滩大会举办的“数据库新标杆新征途”分论坛正式落幕内容涵盖数据库的趋势探讨、分布式数据库的技术创新与行业应用及国内数据库的发展与生态。欢迎持续关注本系列内容~
北京奥星贝斯科技有限公司 CTO 兼 OceanBase 数据库创始人阳振坤在外滩大会上分享了《OceanBase 数据库七亿 tpmC 的关键技术》的主题演讲以下为演讲实录 联机事务处理OLTP系统
很多人都清楚事务的 ACID 特性知道事务要满足原子性、一致性、隔离性和持久性这是从数据库本身的角度来看。但是如果站在业务的角度客户对数据库其实有更高的要求第一个要求是数据不能错交易数据是企业所有数据的基础是最核心的数据这是企业的命脉。 第二个要求是服务不能停比如最早期的支付宝在后半夜没有业务访问或者业务访问量很少如今支付宝24小时都有访问每日高峰的时候峰值甚至比早年的双11还高。所以服务是永远不能停的。
第三个要求是事务高并发处理能力因为很难预算出有多少用户在同时使用所以这就需要数据库有高度并发处理的能力。全世界有非常多的数据库厂商近年来也进入了国产数据库的繁荣时期但是翻过这座山真正能够把这套系统做到生产中使用的其实少之又少。 TPC-C 基准测试
TPC-C benchmark 诞生于上个世纪80年代ATM 自动提款机问世以后数据库厂商都希望推销自家的联机交易处理系统。各个数据库厂商在联机交易处理的 benchmark 上各自为政没有统一的规范各自的 benchmark 结果既缺乏足够的说服力用户也无法在各个系统之间进行参照和对比。
TPC 组织的创始人 Omri Serlin 说服了8家公司成立 TPC 组织共同制定数据库的系列 benchmark 测试标准并对测试过程和结果进行审计和认证。TPC-C 是其中的联机交易处理的测试标准也是国际上最重要最权威的测试标准。TPC-C 模型本身看起来似乎很简单也就是九张表、五种事务。但正是这个看似简单的模型却很好了抽象了直到今天的各个行业业务系统包括电子商务、银行、商场、交通、通信、政府、企业等等。
TPC-C 的测试和审计是一个特别严格的过程。TPC-C 审计要求首先做功能的验证也就是数据库事务的 ACID功能验证通过了才能跑性能。跑性能则有两个要求第一要求8小时稳定运行没有任何人工干预第二性能测试至少进行2小时且期间的性能波动不超过2%。这一定程度上证明了系统的稳定和可靠性。
过去从来没有分布式数据库做过 TPC-C 测试。鉴于 OceanBase 存储架构的特殊性OceanBase 的性能测试是8小时而不是通常的2小时因此整个8小时中性能波动不能超过2%。 可能有人会说我可以用很少的数据也能跑出很高的性能这个数据可以在 CPU 的缓存里但这是 TPC-C 所不允许的因为 TPC-C 测试对应的是实际业务场景。在实际业务中用户数越多性能越高数据量也越大。所以TPC-C 要求性能与数据量成正比。这里我们需要提到 TPC-C 的一个基本概念——仓库每个仓库最高只允许12.86个tpmC大致换算一下相当于一个 tpmC 对应5.44MB的数据。
另外有一个看起来很宽松的要求不限制测试的软件和硬件的版本和型号也不限制软件硬件的数量和规格但配置和价格必须是公开的且在市场上可购买的。那么有人会问是否只要堆越多的机器就能达到越高的性能呢对于交易处理系统其实并没有这么简单。 为什么没有分布式 OLTP 数据库产品
很多人大学里学过分布式事务有人说两阶段提交如果2台机器能够做3台、4台、5台机器也能做那么用100台、1000台机器是否就能跑出更高的性能
可能很多人没有仔细去想这件事分布式事务两阶段提交其实是理论上的结果而且这基于很强的假设——假设硬件不出故障尤其存储不出故障。
那我们看看下面这个模型假设 A 给 B 转 100 元钱原来 A 有 900 元B 有 500 元转账后应该 A 有 800 元、B 有 600 元这是很简单的一个流程第一阶段做准备工作检查一下 A 账户是否正常同时检查 B 帐户是否正常任何一个不满足转账条件转账交易就要被取消如果两个账户都正常那就通知 A 扣 100 元通知 B 加 100元。 这个过程看起来一切都很正常但是如果其中有一个结点比如 A 这个结点坏了这怎么办B 这个结点的 100 元加还是不加仔细分析加也不对不加也不对。假如 A 彻底坏掉了就没有人知道它曾经做过这笔交易如果 B 加了这 100 元A 这里没减这个帐就不平了。那反过来如果 A 这个节点过一会儿又正常了B 这个节点不加这 100 元也不对因为 A 的 100元减掉了B 的100元没有加。那么看起来很简单的一件事其实做起来就变得很困难。所以事务处理不是简简单单靠堆机器就可以堆出来的。
那么又有人会问如果给这两个结点各建一个备库出了问题用备库来顶上行不行答案也是否定的。因为主备镜像无法做到主库与备库完全一致你要想做到完全一致意味着每一笔事务都需要从主库同步到备库这时候整个系统的可用性的链路变长了。对于银行和企业来说这是一个生死两难的问题要保证同步就面临着业务不可用的风险。所以主备一致性与服务可用性两者不可兼得。 OceanBase 的诞生契机
我们前面讲了交易型数据库很难做而且做了市场上很可能没有用户敢用何况它的各方面投入也会很大。而 OceanBase 的诞生和发展得益于有了千载难逢的天时地利与人和的机遇。 “天时”是互联网的爆发式增长对数据库的高并发、大数据量提出了很高的需求而传统关系数据库难以满足这个需求“地利”是阿里巴巴内部从淘宝到支付宝拥有大量使用数据库的场景OceanBase 可以从不是特别关键的应用场景开始尝试一步步地将数据库做到关键系统“人和”是当时单机数据库已经走到了尽头下一步一定是走向分布式而当时团队成员恰好具备分布式技术背景。这几个条件一起促成了 OceanBase 的诞生。 OceanBase 的技术架构
多数派(Paxos)协议
分布式数据库一定会面临分布式事务面临两阶段提交普通两阶段提交解决不了这个问题也分析过之所以出问题是因为对节点的可靠性做了假设。可以回想一下如果刚才两阶段提交中结点都不出问题那么两阶段提交是可以工作的。 OceanBase 是怎么解决这个问题的呢OceanBase 的做法是在原有的基础上增加一个备库主库同步事务到两个备库只要一个备库收到加上主库自己至少两个库收到这样如果两个备库相当于三个结点三个副本如果四个备库相当于五个结点五个副本。你坏一个甚至两个结点数据还在整个系统可以正常完成两阶段的提交工作。
OceanBase 分布式事务实现
我们以三个结点三个副本为例哪怕坏了一个结点剩下两个结点每一笔事务至少在其中一个结点上存在那么可以利用这一点把刚才没有进行完的事务或者进行中的事务恢复出来只要恢复出来事情就可以做下去两阶段的提交就可以正常结束。 三代 TPC-C 排行榜榜首
去年 OceanBase 第一次 TPC-C 测试之后有一些的噪音大家说你跟九年前的结果比算不了什么其实是这些人并不了解 OceanBase 登顶背后的真正意义。 OceanBase 的 TPC-C 测试的立项是2018年8月16日立项前讨论这个事情的时候大家有一定的担心因为从人力物力各方面来看都是比较大的投入。讨论之后定了两步走的策略第一步做小一点的规模目的是把这条路先走通因为当时全世界还没有厂商用分布式数据做过 TPC-C 测试。后来用了200多台的数据库服务器经过半年多的时间最终通过了这个测试。TPC-C 委员会的人对于传统的集中式数据库很熟悉但分布式事务处理数据库他们也没有接触过。
第一次 TPC-C 测试通过之后第二次测试的准备就开始了。因为有了第一次测试的经验第二次的测试结果是在意料之中的。或许有人会问集中式数据库是否还能跑出更高的性能众所周知数据库的性能受制于两个瓶颈一个是 CPU另一个是 IO。三代 TPC-C 榜首中第一和第二代的榜首是传统数据库的代表。第三代榜首是 OceanBase达到了7亿多 tpmC比二代高了一个数量级。在分布式环境下OceanBase 的存储是本地盘这个 IO 能力比共享存储的万兆网卡要更强最关键是没有数量上的限制无论是 CPU 还是硬盘数量。 新一代 HTAP 原生分布式关系数据库
讲到这里可能会有人说分库分表也可以解决你说到的类似问题。是的确实会解决一些问题但有些是很难解决的比如分库分表后是多个数据库这多个数据库要保持 ACID 就非常困难。如果原来的数据库是单一数据库就需要重新设计和规划整个系统。有人混淆分布式数据库的概念把分库分表也叫分布式但其实它不是分布式数据库因为它是多个数据库而不是一个数据库也不满足 ACID 。 分库分表方案缺乏全局索引和唯一ID因为它不再是单个数据库。还要对业务做拆分有个拆分维度比如买家维度那么业务上需要对卖家的维度进行处理怎么办因为卖家的信息会遍布所有分库如果做简单的统计还可以进行但如果涉及事务的处理是没有办法进行的。分库分表方案虽然可以解决一些问题但也带来更多的挑战更大的复杂性和更高的成本。
作为一款原生分布式关系数据库OceanBase 本身可以做到水平扩展不需要重新拆分业务我们可以在主库做交易处理在备库做数据分析处理。甚至在未来可以在主库上同时完成交易和分析的处理。这一技术上的革新很好地克服了分库分表方案的弊端。 原生分布式是数据库的未来
如今的海量数据处理系统不论是大数据系统还是数据仓库它们都是分布式——原生分布式。但是我们再看关系数据库尤其是 OLTP 数据库目前它仍然是单机/集中式的。不是 OLTP 数据库不需要分布式而是分布式的 OLTP 数据库的研制非常困难。
有很多客户说分布式是很好但是今天分布式的生态不够成熟不如集中式数据库的生态。回想起150年前汽车刚刚被发明马车还是最主流的交通工具当时在马路上优先通行的是马车汽车也没有生态。而到了2020年的今天作为主流交通工具的马车已经成为远古的过去汽车早就成为了不可逆转的主流。 原文链接 本文为阿里云原创内容未经允许不得转载。
