oceanbase

[转帖]TPC-C解析系列04_TPC-C基准测试之数据库事务引擎的挑战

本小妞迷上赌 提交于 2019-12-01 21:33:16
TPC-C解析系列04_TPC-C基准测试之数据库事务引擎的挑战 http://www.itpub.net/2019/10/08/3331/ OceanBase这次TPC-C测试与榜单上Oracle和DB2等其他数据库在硬件使用上有非常大的不同,OceanBase的数据库服务器使用的是204+3台型号是ecs.i2.16xlarge阿里云ECS服务器,其中204台作为data node,还有3台作为root node,每位读者都可以在阿里云网站上轻松按需购买。如果读者翻看Oracle和DB2的TPC-C测试报告会发现,这些数据库都会使用专用的存储设备,例如前最高记录保持者Oracle在2010年的测试,使用了97台COMSTAR专用的存储设备,其中28台用来存储数据库的重做日志(Redo Log)。 硬件的差异给软件架构提出了完全不同的挑战,专用的存储设备其内部通过硬件冗余实现了设备自身的可靠保证,数据库软件在使用这样的存储设备时就天然的预设了数据不会丢失。但是,这种方式带来了成本的极大消耗,专用的存储设备的价格都是特别昂贵的。 OceanBase使用通用的ECS服务器提供数据库服务,并且只使用ECS机器自带的本地硬盘做数据存储,这是最通用的硬件条件。但是这种方式对软件架构提出了很大的挑战,因为单个ECS服务器的不如专用的存储设备可靠性高

[转帖]TPC-C解析系列05_TPC-C基准测试之存储优化

给你一囗甜甜゛ 提交于 2019-12-01 21:33:10
TPC-C解析系列05_TPC-C基准测试之存储优化 http://www.itpub.net/2019/10/08/3332/ 蚂蚁金服科技 2019-10-08 11:27:02 本文共3664个字,预计阅读需要10分钟。 TPC-C规范要求被测数据库的性能(tpmC)与数据量成正比。TPC-C的基本数据单元是仓库(warehouse),每个仓库的数据量通常在70MB左右(与具体实现有关)。TPC-C规定每个仓库所获得的tpmC上限是12.86(假设数据库响应时间为0)。假设某系统获得150万tpmC,大约对应12万个仓库,按照70MB/仓库计算,数据量约为8.4TB。某些厂商采用修改过的不符合审计要求的TPC-C测试,不限制单个warehouse的tpmC上限,测试几百到几千个warehouse全部装载到内存的性能,这是没有意义的,也不可能通过审计。在真实的TPC-C测试中,存储的消耗占了很大一部分。OceanBase作为第一款基于shared nothing架构登上TPC-C榜首的数据库,同时也作为第一款使用LSM Tree存储引擎架构登上TPC-C榜首的数据库,在存储架构上有如下关键点: 为了保证可靠性,OceanBase存储了两个数据副本和三个日志副本,而传统的集中式数据库测试TPC-C只存储一份数据; 由于OceanBase存储两个数据副本,再加上OceanBase

[转帖]TPC-C解析系列01_TPC-C benchmark测试介绍

ぃ、小莉子 提交于 2019-12-01 21:32:50
TPC-C解析系列01_TPC-C benchmark测试介绍 http://www.itpub.net/2019/10/08/3334/学习一下. 自从蚂蚁金服自研数据库OceanBase获得TPC-C测试第一名后,引起了行业内外大量关注,我们衷心的感谢大家对OceanBase的支持与厚爱,也虚心听取外界的意见和建议。为了让大家更好的了解测试的技术细节,我们特意邀请了OceanBase的核心研发人员对本次测试做专业的技术解读,本文为第一篇,后续文章也将于近日对外发布。 OceanBase于2010年立项,九年来,研发人员一步一个脚印,不断的对OceanBase做出改进以及增加新的功能。OceanBase也从服务于支付宝开始,逐渐对外开放,为广大的各行业客户提供服务。在这个过程中,我们希望外界对OceanBase的实力有更直观的了解,让客户对我们的产品更有信心,TPC-C测试为我们提供了一个绝佳的舞台。 通过本次测试,我们发现了OceanBase的一些不足之处,比如,之前的单机数据库只能通过增加CPU、内存等来提高处理能力,OceanBase通过分布式架构,可以让大量的普通硬件设备像一台电脑一样处理数据,想提高性能只需增加设备即可,但是,OceanBase在每台设备上的性能还有不少提升空间;另外,OceanBase支持的功能、易用性、数据库生态相比业界标杆还有一些差距。 接下来

[转帖]TPC-C解析系列03_TPC-C基准测试之SQL优化

霸气de小男生 提交于 2019-12-01 21:32:48
TPC-C解析系列03_TPC-C基准测试之SQL优化 http://www.itpub.net/2019/10/08/3330/ TPC-C是一个非常严苛的基准测试模型,考验的是一个完备的关系数据库系统全链路的能力。这也是为什么在TPC-C的榜单前列,出现的永远只是大家熟知的那几家在业界有着几十年积累、从关系数据库理论开始发展就差不多同步出现的数据库公司。接下来我们通过这篇文章为您分析在TPC-C测试中OceanBase数据库的SQL模块具体遇到了哪些挑战、做出了哪些优化。 背景 对TPC-C有所了解人都知道,TPC-C是一个典型的OLTP (On-Line Transaction Processing) 场景测试,考察的是数据库在高并发压力场景下的事务处理能力,最终的性能指标以tpmC(transaction per minute,也即每分钟系统处理TPC-C模型中的new order事务的数量)和平均到每tpmC的系统成本作为衡量标准。在OLTP场景中,每条请求的响应时间都是极短的。因此,各个数据库厂商在进行TPC-C测试时,都会尽一切可能将每一个操作时间压缩到最短,不夸张的说,在TPC-C的测试中,一些关键操作的优化往往需要细化到CPU指令级。 在进入我们的主题前,我们先来谈谈TPC-C中的事务模型,主要分为五种事务,订单创建、订单支付、订单查询、订单发货以及库存查询

支付类系统数据处理和数据中台的数据处理方式有什么不同?

无人久伴 提交于 2019-12-01 08:37:33
数据备份之后实时性如何保证 在建立数据中台的时候,数据还是来源于各个异构的业务应用系统,实现了数据的统一,但是数据实际上是多存了一份,数据存在冗余,同时数据实时性如何来保证了?针对每个业务系统都开发数据提取接口? 数据备份的通用处理方式 能用数据层的binlog方式就用,要不就业务层拉数据,不过如果可以的话,都可以针对各个数据存储开发类似binlog的东西。 其实,这个是三个问题。 第一,数据平台类似于数仓,一般就是基于binlog去同步的,异构数据库可以了解下阿里云的dts,支持多个数据库的解析。 第二,数据同步肯定存在时延,跨数据中心的同步正常情况下在几十毫秒左右,那么对于一些资金类的就要注意了,有些业务需要对数据强一致有要求,就只能读主库。 第三,数据提取接口不现实,比如rpc超时,消息消费失败都是需要考虑的,所以最后还是做到业务无侵入性。 数据强一致场景怎么搞 阿里在处理强一致场景下也是按照读写主库的方式处理的吗?这样的话数据库资源需要能承载所有的请求流量? 看场景,不考虑微服务之间的强一致性的前提下。我们就探讨时延导致的主从一致性。 比如,异地多活,整个链路调用都是单元化,那么就不会有问题,因为整个流量都在一个机房读写。如果上游单元化,下游没有单元化,这种情况,就需要所有流量走中心机房,所有读强制走主库。如果不考虑异地多活,只有一个机房,按照读写主库的方式处理。

蚂蚁金服隗华:十五年时间见证分布式数据库的崛起

社会主义新天地 提交于 2019-11-29 06:01:14
北大计算所启蒙 “做中国人自己的技术” 如果用一句话来评价读书时的隗华(花名:风羿),那一定是“德智体美劳全面发展的好学生”。本科在北航读的计算机专业,硕士则就读于北大的计算机研究所。 北大,中国高等学府的殿堂,所有学子的终极梦想,也是隗华从小到大追寻的梦。谈起考研的过程,一向一帆风顺的他在考研的时候吃了不少苦。北大研究生的考试并非全国统考,这就意味着非北大系的其他院校的学生之前很多知识体系都需要更新或者重建。 所以从大三开始,隗华就牟着一股劲,花了很大功夫吃透北大的教材,无数个日子都是在北大的考研班里度过的。 努力就会有希望。隗华最终考上了北大的计算机研究所。 当时的北大计算机系分为三块,分别由三位院士带领。第一部分是计算机系,由杨芙清院士带领;第二部分是计算机研究所,由王选院士带领;第三部分是微电子,由王阳元院士带领。硕士期间,隗华就读的正是王选院士带领的计算机研究所。 这里,诞生了汉字激光照排技术,同时也孵化出了方正集团这样的中国知名科技企业。 事实上,OceanBase的创始人阳振坤也是师从王选院士。 而阳老师正是隗华在研究生期间密码学课程的老师。 用隗华的话说,“在北大计算所除了学习知识和对技术的应用实践之外,更多的是一种文化的熏陶—— 做中国人自己的技术。 ”十年后,新生儿OceanBase数据库也正是在这样的文化传承下诞生。 初入数据库行业

在「不可靠」硬件上,分布式数据库如何保证数据可靠性和服务可用性?

不想你离开。 提交于 2019-11-27 03:14:37
“数据不能丢,服务不能停”,可以说这句话道出了用户对数据库的核心能力的要求。然而,传统的商业数据库必须依赖高可靠的硬件才能实现数据可靠性和服务可用性。OceanBase作为一款成熟的企业级分布式数据库,基于普通PC服务器,就能够做到传统高端硬件环境下的数据可靠性和服务可用性,而且还能做得更好!跟我们一起看看OceanBase的技术秘诀吧! Part1 前言 说到数据可靠性和服务可用性,在数据库领域真是老生常谈的话题,可以说从数据库诞生之日起就如影随形。如果要用一句话来概括数据库对数据可靠性和服务可用性的要求,可以借用OceanBase数据库创始人阳振坤老师的一句话:“数据不能丢,服务不能停”。可以说,这句话也道出了用户对数据库的一个核心能力要求:除了功能完善、使用方便之外,还要绝对安全、足够健壮。可以说,为了满足这两个看似简单的要求,在数据库领域诞生了大量的技术和论文,也让无数人绞尽了脑汁。 在传统的商业数据库产品(如Oracle、DB2)中,虽然也有一些行之有效的软件技术(如Redo Log、主从热备技术等)用来提高数据可靠性和服务可用性,但整体来说对硬件的稳定性有很强的依赖。而传统的企业级服务器(如IBM 的Mainframe、AS400、Power等)和EMC、IBM等厂商的高端存储产品,能够很好的保证硬件的稳定性,因此也就成为了Oracle为代表的传统数据库产品的理想平台