精华内容
下载资源
问答
  • 全套自动计算主机资源tpmC工具,填入业务数据,自动计算tpmC,直接评估系统所需的主机资源
  • 如何对服务器性能计算的公式参考(TPMC_TPCC)...pdf如何对服务器性能计算的公式参考(TPMC_TPCC)...pdf
  • sysbench基准测试并数据统计--TPS、QPS、TPMC及响应时间,让你第一时间了解数据库的运行情况。
  • 根据用户的基本需求,计算出一个和我们X86服务器匹配的TPMC值,给渠道项目上一个修改和使用我司服务器的机会
  • TPC TPCC TPMC 计算机性能衡量指标

    分享一下我老师大神的人工智能教程!零基础,通俗易懂!http://blog.csdn.net/jiangjunshow

    也欢迎大家转载本篇文章。分享知识,造福人民,实现我们中华民族伟大复兴!

                   

    第一章 什么是TPCtpmC?

    1 TPC

    TPC(Transaction Processing Performance Council,事务处理性能委员会)是由数10家会员公司创建的非盈利组织,总部设在美国。该组织对全世界开放,但迄今为止,绝大多数会员都是美、日、西欧的大公司。TPC的成员主要是计算机软硬件厂家,而非计算机用户,它的功 能是制定商务应用基准程序(Benchmark)的标准规范、性能和价格度量,并管理测 试结果的发布。

    TPC的出版物是开放的,可以通过网络获取(http://www.tpc.org)TPC不给出基准程序的代码,而只给出基准程序的标准规范(Standard Specification)。任何厂家或其它测试者都可以根据规范,最优地构造出自己的系统(测试平台和测试程序)。为保证测试结果的客观性,被测试者(通常是厂家)必须提交给TPC一套完整的报告(Full Disclosure Report),包括被测系统的详细配置、分类价格和包含五年维护费用在内的总价 格。该报告必须由TPC授权的审核员核实(TPC本身并不做审计)。现在全球只有几个审核员,全部在美国。

    TPC已经推出了四套基准程序,被称为TPCATPCBTPCCTPCD。其中AB已经过时,不再使用了。TPCC是在线事务处理(OLTP)的基准程序,TPCD是决策支持(Decision Support) 的基准程序。TPC即将推TPCE,作为大型企业(Enterprise)信息服务的基准程序。

     

    2 tpmC

    tpmC值在国内外被广 泛用于衡量计算机系统的事务处理能力。但究竟什么是tpmC值呢?作者曾向一些 用户、推销人员乃至某些国外大公司的技术人员问过这个问题,但回答的精确度 与tpmC值的流行程度远非相称。tpmC这一度量也常被误写为TPMTPMC

    TPC-C模拟一个批发商的货物管理环境。该批发公司有N个仓库,每个仓库供应10个地区,其中每个地区为3000名顾客服务。在每个仓库中有10个终端,每一个终端用于一个地区。在运行时,10×N个终端操作员向公司的数据库发出5类请求。由于一个仓库中不可能存储公司所有的货物,有一些请求必须发往其它仓库,因此,数据库在逻辑上是 分布的。N是一个可变参数,测试者可以随意改变N,以获得最佳测试效果。

    TPC-C使用三种性能和价格度量,其中性能由TPC-C吞吐率衡量,单位是tpmCtpmtransactions per minute的简称;CTPC中的C基准程序。它的定义是每分钟内系统处理的新订单个数。要注意的是,在处理新订单的同时,系统还要按表1的要求处理其它4类事务 请求。从表1可以看出,新订单请求不可能超出全部事务请求的45%,因此,当一个 系统的性能为1000tpmC时,它每分钟实际处理的请求数是2000多个。价格是指系 统的总价格,单位是美元,而价格性能比则定义为总价格÷性能,单位是$/tpmC

    tpmC定义: TPC-C的吞吐量,按有效TPC-C配置期间每分钟处理的平均交易次数测量,至少要运行12分钟。

    (吞吐量测试结果以比特/秒或字节/秒表示。)

    第二章 TPCC

    1             基准测试

    TPCC值被广泛用于衡量C/S环境下,由服务器和客户端构筑的整体系统的性能,它由事物处理性能委员会(TPCTransaction Processing Corp)制定,TPC为非赢利性国际组织。

     

    TPCC值可以反映出系统的性能价格比。TPCC测试系统每分钟处理的任务数,单位为tpm,(transactions per minute)。系统的总体价格(单位为美元)除以TPCC,就可以衡量出系统的性价比,系统的性价比值越大,系统的性价比越好。

     

    需要注意的是,TPC-C值描述的是C/S整体系统的性能,它与系统的服务器和客户机的性能都有关系,也就是说,同样的服务器配置不同的客户端将会影响TPCC,任何厂商和测试者都可以根据TPC提供的测试规范构造出自己最优的系统,当然测试的结果要经过TPC审核。

     

     

     

     

    ---------------------------------------------------------------------------------------------------------------

    2             性能测试指标介绍

    TPC-C

    作为一家非盈利性机构,事务处理性能委员会(TPC)负责定义诸如TPC-CTPC-HTPC-W基准测试之类的事务处理与数据库性能基准测试,并依据这些基准测试项目发布客观性能数据。TPC基准测试采用极为严格的运行环境,并且必须在独立审计机构监督下进行。委员会成员包括大多数主要数据库产品厂商以及服务器硬件系统供应商。

     

    相关企业参与TPC基准测试以期在规定运行环境中获得客观性能验证,并通过应用测试过程中所使用的技术开发出更加强健且更具伸缩性的软件产品及硬件设备。

     

    TPC-C是一种旨在衡量联机事务处理(OLTP)系统性能与可伸缩性的行业标准基准测试项目。这种基准测试项目将对包括查询、更新及队列式小批量事务在内的广泛数据库功能进行测试。许多IT专业人员将TPC-C视为衡量“真实”OLTP系统性能的有效指示器。

     

    TPC-C基准测试针对一种模拟订单录入与销售环境测量每分钟商业事务(tpmC)吞吐量。特别值得一提的是,它将专门测量系统在同时执行其它四种事务类型(如支付、订单状态更新、交付及证券级变更)时每分钟所生成的新增订单事务数量。独立审计机构将负责对基准测试结果进行公证,同时,TPC将出据一份全面彻底的测试报告。这份测试报告可以从TPC Web站点(http://www.tpc.org)上获得。

    3 TPC-C规范概要

    TPC-C是专门针对联机交易处理系统(OLTP系统)的,一般情况下我们也把这类系统称为业务处理系统。

    TPC-C测试规范中模拟了一个比较复杂并具有代表意义的OLTP应用环境:假设有一个大型商品批发商,它拥有若干个分布在不同区域的商品库;每个仓库负责为10个销售点供货;每个销售点为3000个客户提供服务;每个客户平均一个订单有10项产品;所有订单中约1%的产品在其直接所属的仓库中没有存货,需要由其他区域的仓库来供货。

    该系统需要处理的交易为以下几种:

    New-Order:客户输入一笔新的订货交易;

    Payment:更新客户账户余额以反映其支付状况;

    Delivery:发货(模拟批处理交易);

    Order-Status:查询客户最近交易的状态;

    Stock-Level:查询仓库库存状况,以便能够及时补货。

    对于前四种类型的交易,要求响应时间在5秒以内;对于库存状况查询交易,要求响应时间在20秒以内。

    4评测指标

    TPC-C测试规范经过两年的研制,于19927月发布。几乎所有在OLTP市场提供软硬件平台的厂商都发布了相应的TPC-C测试结果,随着计算机技术的不断发展,这些测试结果也在不断刷新。

    TPC-C的测试结果主要有两个指标:

    ①流量指标(Throughput,简称tpmC)

    按照TPC的定义,流量指标描述了系统在执行PaymentOrder-statusDeliveryStock-Level这四种交易的同时,每分钟可以处理多少个New-Order交易。所有交易的响应时间必须满足TPC-C测试规范的要求。

    流量指标值越大越好!

    ②性价比(Price/Performance,简称Price/tpmC)

    即测试系统价格(指在美国的报价)与流量指标的比值。

    性价比越大越好!

    第三章TPCC)如何衡量计算机系统的性能和价格

    在系统选型时,我们一定不要忘记我们是为特定用户环境中的特定应用选择系统。切忌为了与国际接轨而盲目套用国际通用的东西。在性能评价领域,越是通用的度量常常越是不准确的。据我所知,美国的一些大用户从不相信任何国际通用的度量,而是花相当精力,比如预算的5%,使用自己的应用来测试系统,决定选型。在使用任何一种性能和价格度量时,一定要弄明白该度量的定义,以及它是在什么系统配置和运行环境下得到的,如何解释它的意义等。下面我们由好到差讨论三种方式。

    1在真实环境中运行 实际应用

    最理想的方式是搞一个试点,要求制造商或系统集成商配合将系统(含平台、软件和操作流程)在一个 实际用户点真正试运行一段时间。这样,用户不仅能看到实际性能,也能观察到系统是否稳定可靠、使用是否方便、服务是否周到、配置是否足够、全部价格是否合理。如果一个部门需要购买一批同类的系统,这种方式应列为首选,因为它不仅最精确、稳妥,也常常最有效率,用户还可先租一套系统作为试点。用这种方式得到的度量值常常具有很明确和实际的含义。

    2使用用户定义的基准程序

    如果由于某种原因第一种方式不可行,用户可以定义一组含有自己实际应用环境特征的应用基准程序。 我举两个例子:近年来,由于R/3软件是应用层软件,SAP公司的基准程序获得了越来越多国外企业的认可;中国税务总局最近也开发了自己的基准程序,以帮助税务系统进行计算机选型。这种方式在中国尤其重要,因为中国的信息系统有其特殊性。

    3使用通用基准程序

    如果第1种和第2种方式都不行,则使用如TPC-C之类的通用基准程序,这是不得已的一种近似方法。因 此,tpmC值只能用作参考。我们应当注意以下几点:

    ①实际应用是否与基准程序相符

    绝大多数基准程序都是在美国制订的,而中国的企事业单位与美国的运作方式常常不一样(恐怕也不应该或不可能一样)。在使用TPCC时,我们应该清楚地知道:我的应用是否符合批发商模式?事务请求是否与表1近似?对响应时间的要求是否满足表1?如果都不是,则tpmC值的参考价值就不太大了。

    TPC度量的解释

    TPC基准程序是用来测系统而不是测主机的,厂家肯定要充分优化他们的被测系统。此处的系统包括主机、外设(如硬盘或RAID)、主机端操作系统、数据库软件、客户端计算机及其 操作系统、数据库软件和网络连接等。在很多厂家的TPC测试系统中,主机的价格只是系统总价格的1/4或更小,而硬盘的价格有可能占到总价格的1/3以上,因为TPCC要求被测系统必须保存180天的事务记录。如果同样的主机被用到用户的环境中,厂家报的tpmC值就意义不大,因为用户的实际系统与厂家原来用于TPC测试的系统大不一样。当同样的主机用在不同的系统中时,tpmC值可能有相当大的变化,现在很多用户还没有意识到这一点。

    我举一个例子。假设用 户希望购买一批同类系统,每一系统至少需要1GB的内存和50GB的硬盘。厂家ABC 各报了三个价格相当的系统,tpmC值分别为300028002600。用户是否应该选厂家A的产品呢?答案是:不一定。厂家用于测试tpmC值的系统与实际提供给用户的系统配置大不一样。tpmC最低的厂家C提供给用户的系统反而有可能性能最好,不 论是以实际系统的tpmC值还是以用户的实际应用性能来衡量。

    TPC测试的成本

    TPCCTPCD都是很复杂的基准程序,做一个严格的测试是很消耗资源的,厂家当然不会说出他们花费了多少钱和时间。但据国外知情人士透露,一个厂家做第一个TPCC测试需 要几十万到上百万美元的资金和半年左右的时间投入。因此,很多TPC的度量值都 是估计的。由于计算机系统换代频繁,如果用户一定要用通过审核的度量值,就必 须多等待半年时间,因此而不能用最先进的系统。中国的厂家通过审核的时间则更长。

    综上所述,我们对中国 用户(尤其是大用户)在计算机系统的选型方面有如下建议:

    最好建立一个真实的试点,因为实际应用环境是检验计算机系统的最好标准。

    中国的行业应该建立符合自己实际应用的基准程序和测试标准。中国税务总局的做法值得提倡。国家有关部门应该建立独立的测试中心,制定跨行业、符合中国企事业运作模式的性能测试标准。

    国际通用的度量可以作为参考值,而不应作为必要条件。尤其是一定要弄清这些流行度量有什么含义,是在什么样的系统环境中测得的,以及基准程序是否符合企业真实的业务流程和运作模式。

    作为一家非盈利性机构,事务处理性能委员会(TPC)负责定义诸如TPC-CTPC-HTPC-W基准测试之类的事务处理与数据库性能基准测试,并依据这些基准测试项目发布客观性能数据。TPC基准测试采用极为严格的运行环境,并且必须在独立审计机构监督下进行。委员会成员包括大多数主要数据库产品厂商以及服务器硬件系统供应商。

    相关企业参与TPC基准测试以期在规定运行环境中获得客观性能验证,并通过应用测试过程中所使用的技术开发出更加强健且更具伸缩性的软件产品及硬件设备。

    TPC-C是一种旨在衡量联机事务处理(OLTP)系统性能与可伸缩性的行业标准基准测试项目。这种基准测试项目将对包括查询、更新及队列式小批量事务在内的广泛数据库功能进行测试。许多IT专业人员将TPC-C视为衡量真实”OLTP系统性能的有效指示器。

    TPC-C基准测试针对一种模拟订单录入与销售环境测量每分钟商业事务(tpmC)吞吐量。特别值得一提的是,它将专门测量系统在同时执行其它四种事务类型(如支付、订单状态更新、交付及证券级变更)时每分钟所生成的新增订单事务数量。独立审计机构将负责对基准测试结果进行公证,同时,TPC将出据一份全面彻底的测试报告。这份测试报告可以从TPC Web站点(http://www.tpc.org)上获得。

     

     

    第四章 TPCC计算原则

    1建议

    不管是TPC-C还是SPECjbb2000,计算结果都只能作为一个横向比较的参考。在实际应用中,决定系统性能的因素除了硬件、系统软件外,与应用软件的设计也是有很大关系的,此外,基于系统可扩展性的考虑,更多时候也倾向于一次性的采购。
    从长远考虑,以政府信息化主管部门的角度考虑,建立一套评估机制是非常有用的,这其中包括:
    1
    、 通过对各单位业务系统运行情况的调查,进行历史数据的收集分析,按分类建立基准指标库。收集的信息包括:服务器的配置、并发用户数(每天业务量)、CPU负荷等;
    2
    、 由厂商定期提供基准值,更新基准指标库;
    有了基准指标库的信息参照,不仅可以用于评估项目建设方案中服务器选型,也可以对各部门进行系统架构设计的优化提供指导。如以下是一些指导原则:
    1
    、 数据库服务器选型:采购两台相同配置的小型机,进行虚拟分区和并行处理,以提高系统资源的利用率;日后扩容时采取垂直扩展的方式进行升级;
    2
    、 应用服务器:采用负载均衡的方式提高并发处理能力,一般可配置2台以上,每台的硬件配置完全可以不同,应首先考虑使用旧的数据库服务器(利旧),如需采购新的服务器,应采用水平扩展的方式逐步升级;
    3
    WEB服务器,可以考虑采用刀片服务器,提高扩展性和可管理性。

    2参考:某项目计算实例

    参考1

    为了方便计算数据库服务器的造型,我们约定:
    "
    系统同时在线用户数为1500人(U1);
    "
    平均每个用户每分钟发出2次业务请求(N1);
    "
    系统发出的业务请求中,更新、查询、统计各占1/3
    "
    平均每次更新业务产生3个事务(T1);
    "
    平均每次查询业务产生8个事务(T2);
    "
    平均每次统计业务产生13个事务(T3);
    "
    一天内忙时的处理量为平均值的5倍;
    "
    经验系数为1.6(实际工程经验)
    "
    考虑服务器保留30%的冗余;
    服务器需要的处理能力为:
    TPC-C=U1*N1*
    T1+T2+T3/3*3*经验系数/冗余系数
    则应用服务器的处理性能估算为:
    TPC-C= 1500*2*
    3+8+13/3*5*1.6/0.7= 274,285 tpmC

    数据库服务器关系到整个系统的稳定运行,考虑到高可靠性和高可用性,并注重设备的可扩展性和性价比,系统将配置两台TPC-C值不小于28万的高性能数据库服务器。

    参考2

     

    以单台服务器性能进行计算,即确保单台服务器工作的时候可以满足系统正常运行的需要;

    假设每天有1万人次来窗口办理业务,每人次办理一项业务。即以每日1万笔前台交易为例进行综合系数的推导:

    1. 假设每月前台交易数(未来5年内的设计指标)为220,000 (有些业务在月初、月末的处理量比较高,按月统计可以平衡此项差异);
    2.
    每日前台交易数=220000/22=10,000 ,即每日 1万笔;
    3.
    忙时处理能力:每日交易的80%4个小时内完成,即10000*80%/4=2000(笔/小时)
    4.
    峰值处理能力:2000*2=4000(笔/小时),即峰值处理能力为每小时4000笔,或 67/分,假设业务人员同时在线为100人,即每人每分钟处理0.7笔)
    5.
    假设每笔交易对应数据库事务数=20,基准TPC指标值对应的比例=8cpu保留30%的处理能力冗余,计算值与公布值(最优值)的偏差经验值为4 (这几个参数估算的依据不足,更多的是经验值)

    tpmC值为:
    tpmC= 67*20*8*4/(1-30%)= 61257[
    颠峰处理能力时(笔/分)*每笔交易对应数据库事务数*基准TPC指标值对应的比例*计算值与公布值(最优值)的偏差经验值/1- cpu保留30%的处理能力冗余)
    倒算出 综合系数 = 61257/10000=6.1
    即数据库服务器tpmC= 每日前台交易数 * 6.1 (实际计算值应不高于该值)
    应用服务器的 tpmC = 数据库服务器 tpmC *50% (一般)
    应用服务器的 tpmC = 数据库服务器 tpmC *70% (涉及大量计算的,如社保、税务)

     

               

    给我老师的人工智能教程打call!http://blog.csdn.net/jiangjunshow

    这里写图片描述
    展开全文
  • 服务器TPMC值计算方法

    2009-08-14 15:03:42
    服务器TPMC,项目预算时经常使用的。服务器TPMC,项目预算时经常使用的。
  • 按照TPC-C的规定,每上升一定的tpmC,就要增加一些原始数据,比如说新的仓库、物品等,也就是说,6000tpmc时库中的原始数据可能只有几个GB, 6千万tpmc时,原始数据可能就有几十上百个T。这里列的数字肯定不准,但...

    ❀ 2019年的OceanBase用了更多硬件资源超越了2010年Oracle的记录,这个记录在多大程度上可比?意义大吗?

    ❀ 从纸面上来看,OceanBase较9年前的Oracle相比,使用了1.5倍的主频、近4倍的CPU和Core,为什么达到的tpmC只有2倍左右?

    ❀ 是不是真的如有些媒体所说,中国的通用数据库已经要超过Oracle了?

    作为前高性能计算行业从业者,笔者对于上几个问题也相当好奇。幸运的是,2019年10月9日在中国人民大学信息学院,OceanBase的负责人阳振坤博士做了一个专题讲座,充分解答了上面的几个问题,也让现场所有听众充分了解了OceanBase取得的成绩背后的意义以及鲜为人知的故事。

    想要回答三个问题,先得讲讲大背景。OceanBase启动的时期正是2010年,也是Oracle已经独统RDBMS江湖的时候。淘宝业已兴起,支付宝也跟着欣欣向荣。然而每三个月增长一倍的业务量一直是悬在阿里数据库系统头上的一把利剑。彼时的阿里业务系统若要就这业务增长无限扩容Oracle数据库,不管是在经济还是安全上都有巨大隐患。在此前提下,OceanBase(后称OB)项目上马了。其目标是取代Oracle数据库,并能支持淘宝和支付宝(后蚂蚁金服)的业务需求。

    与银行不同,互联网电商面对交易量和弹性都极大的业务特点,天然亲近可用低成本小型服务器横向拓展的分布式系统。OB团队因而早早也在往分布式数据库的方向上考虑。一般来讲,传统RDBMS遵循ACID模型,分布式数据库尤其是一般的NoSQL数据库遵循CAP模型,但是OB对标的是Oracle,其定位跟一般的NoSQL数据库是完全不一样的,它是真正的面向OLTP的事务型关系数据库。同时,OB团队又希望其能够继承分布式高可用的特点,于是阳博士最终提出A2CID模型,即Atomicity,Availability,Consistency,Isolation,Durability,这便是技术直男的既要又要还要都要。但Oracle的一家独大并非没有理由,OLTP难度和投入极大,属于慢工出细活。

    阳博士一开始并不懂数据库,但是非常看好这个方向。其领导一开始同意让他做两年,没想一做做了9年才算出了些成绩。在此也感叹技术领头人确实需要眼光和魄力,而一个追求技术卓越的企业,也需要有对一个基础产品持续9年投入和改进的包容心和战略定力。

    A2CID中可用性和一致性这对天然矛盾体到底如何解决?图灵奖获得者Leslie Lamport发明的Paxos消息一致性算法,不仅解决了私有区块链中的一致性问题,也解决了OB可用性和一致性共存的设计难题。Paxos算法是面向非拜占庭模型的分布式系统共识算法,对于分布式数据库或者私有区块链这种假设无攻击的环境具有良好的适用性。

    当然,我们都知道墨菲定律,3个节点的Paxos节点,挂一个没事,挂两个咋办?为了提高整个Paxos网络的可靠性,OB团队把每一个Paxos主网络中的逻辑节点设计成了由三到五台机器组成的Paxos子网络。一个Paxos子网络节点中的几个机器同时出问题的概率是极小的,而这种极端情况即使发生了也没关系,因为Paxos主网络中还有多数逻辑节点来保证一致性。这种类似于嵌套Paxos网络的设计,真正保证了OB同时达到了可用性和一致性,系统服务(几乎)永不中断的情况下,数据在集群中还能确保一致。

    至于Paxos网络中可能遇到的死锁问题,根据现场的一些信息,猜想可能是将网络中几个被选举出来的统一时间服务器所产生的统一时间戳作为接受同步的主要判定标准。

    下面先回答问题三:讲座伊始,阳博士就直言,OB是“部分取代”了Oracle数据库,在功能性、单机性能上离Oracle数据库还有很大距离,而在横向可拓展方面较只能用高成本共享存储机柜集群的Oracle具备较大优势。值得一提的是,贯穿整个讲座,阳博士至始至终展现出了技术人的谦逊和务实,让人印象深刻。

    接下来是问题二:这也是很多人的关注点。这次TPC-C记录中OB的纸面硬件效率不如Oracle,但这并不代表OB就是靠低效“堆硬件”获得的结果。我们看到的硬件资源比和tpmC性能比不一致,是如下三个因素综合产生的结果:

    首先,按照TPC-C的要求,在tpmC上升的时候,整个底库数据是增加的,而不是在同一个小数据上重复提交交易。这个意思是,测试数据本身不是一成不变的。按照TPC-C的规定,每上升一定的tpmC,就要增加一些原始数据,比如说新的仓库、物品等,也就是说,6000tpmc时库中的原始数据可能只有几个GB, 6千万tpmc时,原始数据可能就有几十上百个T。这里列的数字肯定不准,但原则是,TPC-C会通过这个方式增加tpmC上升的难度。例如,在10个仓库,100个商品上实现1000万tpmC,和10000个仓库,1000万商品上实现1000万tpmC的难度是完全不一样的,前者会容易很多,因为表索引小、存储区块短、因而join等操作也更快。数据库性能下降跟库的增长一定不是线性关系,这是其一

    其二就是基于Paxos的高可用一致性设计,产生了大量信息和计算存储资源冗余。这部分是用分布式实现高可用的OLTP付出的必要代价,无可避免。但当交易量进一步上升时,与Oracle扩容高成本共享存储机柜集群的思路相比,OB这部分的代价肯定是更小的。这也是OB在横向可扩展性上的优势来源。

    其三就是TPC-C的认证对于系统性能波动具有极其严格的要求。在整个8小时的测试过程中,tpmC波动不能超过2%。第一次挑战,为了追求稳过,OB团队配置环境时保留了较多富余的计算资源,比如很多节点的CPU可能占用率并不高。这个属于团队选择的问题,后期也可调。总体来讲,在OB团队未来的挑战(如果还有的话)中,随着对TPC-C流程的进一步熟悉,以及对OB稳定性的更多信心,OB的性能价格比是有望进一步上升的。

    最后是问题一:笔者认为OB在TPC-C榜的挑战成功是非常了不起的成绩,于行业于国家都意义重大。OB在分布式系统上实现了金融业务级的OLTP通用数据库,并且还保留了分布式系统独有的低成本横向可扩展性和高可用性,在可预见的未来,一定会有更多的银行抛弃昂贵的IBM大机+ORACLE数据库解决方案,转向以OB为代表的分布式数据库。

    现场中国数据库技术的开创级人物王珊教授也对OB团队的成就做出了毫无保留的赞美和祝福。阳博士也表示,会继续优化OB文件系统,并且让OB走上立足OLTP向OLAP延伸的道路。

    一览群智作为AI赋能先行者,在各个业务中长期使用关系数据库,也一直积极关注和推进国内基础技术的进步。OceanBase取得的成绩令人敬佩,再次恭喜阳博士和OceanBase团队!也祝OceanBase越做越好!

    640?wx_fmt=png

    展开全文
  • 谐波污染已经影响了电力电子技术的应用和发展,三相矩阵交交变频器(3-phasematrixACACconverter,TPMC)具有高功率因数抵谐波污染等优良特性,文中研究了电动机负载下矩阵变换器的线侧电流谐波特性。基于TPMC的基本调制...
  • 第一章 什么是TPC和tpmC? 1 TPC TPC(Transaction Processing Performance Council,事务处理性能委员会)是由数10家会员公司创建的非盈利组织,总部设在美国。该组织对全世界开放,但迄今为止,绝大多数会员都是...
    第一章 什么是TPC和tpmC?
    
    1 TPC

    TPC(Transaction Processing Performance Council,事务处理性能委员会)是由数10家会员公司创建的非盈利组织,总部设在美国。该组织对全世界开放,但迄今为止,绝大多数会员都是美、日、西欧的大公司。TPC的成员主要是计算机软硬件厂家,而非计算机用户,它的功 能是制定商务应用基准程序(Benchmark)的标准规范、性能和价格度量,并管理测 试结果的发布。

    TPC的出版物是开放的,可以通过网络获取(http://www.tpc.org)。TPC不给出基准程序的代码,而只给出基准程序的标准规范(Standard Specification)。任何厂家或其它测试者都可以根据规范,最优地构造出自己的系统(测试平台和测试程序)。为保证测试结果的客观性,被测试者(通常是厂家)必须提交给TPC一套完整的报告(Full Disclosure Report),包括被测系统的详细配置、分类价格和包含五年维护费用在内的总价 格。该报告必须由TPC授权的审核员核实(TPC本身并不做审计)。现在全球只有几个审核员,全部在美国。

    TPC已经推出了四套基准程序,被称为TPC-A、TPC-B、TPC-C和TPC-D。其中A和B已经过时,不再使用了。TPC-C是在线事务处理(OLTP)的基准程序,TPC-D是决策支持(Decision Support) 的基准程序。TPC即将推TPC-E,作为大型企业(Enterprise)信息服务的基准程序。

     
    2 tpmC

    tpmC值在国内外被广 泛用于衡量计算机系统的事务处理能力。但究竟什么是tpmC值呢?作者曾向一些 用户、推销人员乃至某些国外大公司的技术人员问过这个问题,但回答的精确度 与tpmC值的流行程度远非相称。tpmC这一度量也常被误写为TPM或TPMC。

    TPC-C模拟一个批发商的货物管理环境。该批发公司有N个仓库,每个仓库供应10个地区,其中每个地区为3000名顾客服务。在每个仓库中有10个终端,每一个终端用于一个地区。在运行时,10×N个终端操作员向公司的数据库发出5类请求。由于一个仓库中不可能存储公司所有的货物,有一些请求必须发往其它仓库,因此,数据库在逻辑上是 分布的。N是一个可变参数,测试者可以随意改变N,以获得最佳测试效果。

    TPC-C使用三种性能和价格度量,其中性能由TPC-C吞吐率衡量,单位是tpmC。tpm是transactions per minute的简称;C指TPC中的C基准程序。它的定义是每分钟内系统处理的新订单个数。要注意的是,在处理新订单的同时,系统还要按表1的要求处理其它4类事务 请求。从表1可以看出,新订单请求不可能超出全部事务请求的45%,因此,当一个 系统的性能为1000tpmC时,它每分钟实际处理的请求数是2000多个。价格是指系 统的总价格,单位是美元,而价格性能比则定义为总价格÷性能,单位是$/tpmC。

    tpmC定义: TPC-C的吞吐量,按有效TPC-C配置期间每分钟处理的平均交易次数测量,至少要运行12分钟。

    (吞吐量测试结果以比特/秒或字节/秒表示。)
    第二章 TPCC
    1             基准测试

    TPCC值被广泛用于衡量C/S环境下,由服务器和客户端构筑的整体系统的性能,它由事物处理性能委员会(TPC,Transaction Processing Corp)制定,TPC为非赢利性国际组织。

     

    TPCC值可以反映出系统的性能价格比。TPCC测试系统每分钟处理的任务数,单位为tpm,(transactions per minute)。系统的总体价格(单位为美元)除以TPCC值,就可以衡量出系统的性价比,系统的性价比值越大,系统的性价比越好。

     

    需要注意的是,TPC-C值描述的是C/S整体系统的性能,它与系统的服务器和客户机的性能都有关系,也就是说,同样的服务器配置不同的客户端将会影响TPCC值,任何厂商和测试者都可以根据TPC提供的测试规范构造出自己最优的系统,当然测试的结果要经过TPC审核。

     

     

     

     

    ---------------------------------------------------------------------------------------------------------------
    2             性能测试指标介绍

    TPC-C

    作为一家非盈利性机构,事务处理性能委员会(TPC)负责定义诸如TPC-C、TPC-H和TPC-W基准测试之类的事务处理与数据库性能基准测试,并依据这些基准测试项目发布客观性能数据。TPC基准测试采用极为严格的运行环境,并且必须在独立审计机构监督下进行。委员会成员包括大多数主要数据库产品厂商以及服务器硬件系统供应商。

     

    相关企业参与TPC基准测试以期在规定运行环境中获得客观性能验证,并通过应用测试过程中所使用的技术开发出更加强健且更具伸缩性的软件产品及硬件设备。

     

    TPC-C是一种旨在衡量联机事务处理(OLTP)系统性能与可伸缩性的行业标准基准测试项目。这种基准测试项目将对包括查询、更新及队列式小批量事务在内的广泛数据库功能进行测试。许多IT专业人员将TPC-C视为衡量“真实”OLTP系统性能的有效指示器。

     

    TPC-C基准测试针对一种模拟订单录入与销售环境测量每分钟商业事务(tpmC)吞吐量。特别值得一提的是,它将专门测量系统在同时执行其它四种事务类型(如支付、订单状态更新、交付及证券级变更)时每分钟所生成的新增订单事务数量。独立审计机构将负责对基准测试结果进行公证,同时,TPC将出据一份全面彻底的测试报告。这份测试报告可以从TPC Web站点(http://www.tpc.org)上获得。
    3 TPC-C规范概要

    TPC-C是专门针对联机交易处理系统(OLTP系统)的,一般情况下我们也把这类系统称为业务处理系统。

    TPC-C测试规范中模拟了一个比较复杂并具有代表意义的OLTP应用环境:假设有一个大型商品批发商,它拥有若干个分布在不同区域的商品库;每个仓库负责为10个销售点供货;每个销售点为3000个客户提供服务;每个客户平均一个订单有10项产品;所有订单中约1%的产品在其直接所属的仓库中没有存货,需要由其他区域的仓库来供货。

    该系统需要处理的交易为以下几种:

    New-Order:客户输入一笔新的订货交易;

    Payment:更新客户账户余额以反映其支付状况;

    Delivery:发货(模拟批处理交易);

    Order-Status:查询客户最近交易的状态;

    Stock-Level:查询仓库库存状况,以便能够及时补货。

    对于前四种类型的交易,要求响应时间在5秒以内;对于库存状况查询交易,要求响应时间在20秒以内。
    4评测指标

    TPC-C测试规范经过两年的研制,于1992年7月发布。几乎所有在OLTP市场提供软硬件平台的厂商都发布了相应的TPC-C测试结果,随着计算机技术的不断发展,这些测试结果也在不断刷新。

    TPC-C的测试结果主要有两个指标:
    ①流量指标(Throughput,简称tpmC)

    按照TPC的定义,流量指标描述了系统在执行Payment、Order-status、Delivery、Stock-Level这四种交易的同时,每分钟可以处理多少个New-Order交易。所有交易的响应时间必须满足TPC-C测试规范的要求。

    流量指标值越大越好!
    ②性价比(Price/Performance,简称Price/tpmC)

    即测试系统价格(指在美国的报价)与流量指标的比值。

    性价比越大越好!
    第三章(TPCC)如何衡量计算机系统的性能和价格

    在系统选型时,我们一定不要忘记我们是为特定用户环境中的特定应用选择系统。切忌为了“与国际接轨”而盲目套用“国际通用”的东西。在性能评价领域,越是通用的度量常常越是不准确的。据我所知,美国的一些大用户从不相信任何“国际通用”的度量,而是花相当精力,比如预算的5%,使用自己的应用来测试系统,决定选型。在使用任何一种性能和价格度量时,一定要弄明白该度量的定义,以及它是在什么系统配置和运行环境下得到的,如何解释它的意义等。下面我们由好到差讨论三种方式。
    1在真实环境中运行 实际应用

    最理想的方式是搞一个试点,要求制造商或系统集成商配合将系统(含平台、软件和操作流程)在一个 实际用户点真正试运行一段时间。这样,用户不仅能看到实际性能,也能观察到系统是否稳定可靠、使用是否方便、服务是否周到、配置是否足够、全部价格是否合理。如果一个部门需要购买一批同类的系统,这种方式应列为首选,因为它不仅最精确、稳妥,也常常最有效率,用户还可先租一套系统作为试点。用这种方式得到的度量值常常具有很明确和实际的含义。
    2使用用户定义的基准程序

    如果由于某种原因第一种方式不可行,用户可以定义一组含有自己实际应用环境特征的应用基准程序。 我举两个例子:近年来,由于R/3软件是应用层软件,SAP公司的基准程序获得了越来越多国外企业的认可;中国税务总局最近也开发了自己的基准程序,以帮助税务系统进行计算机选型。这种方式在中国尤其重要,因为中国的信息系统有其特殊性。
    3使用通用基准程序

    如果第1种和第2种方式都不行,则使用如TPC-C之类的通用基准程序,这是不得已的一种近似方法。因 此,tpmC值只能用作参考。我们应当注意以下几点:
    ①实际应用是否与基准程序相符

    绝大多数基准程序都是在美国制订的,而中国的企事业单位与美国的运作方式常常不一样(恐怕也不应该或不可能一样)。在使用TPC-C时,我们应该清楚地知道:我的应用是否符合批发商模式?事务请求是否与表1近似?对响应时间的要求是否满足表1?如果都不是,则tpmC值的参考价值就不太大了。
    ②TPC度量的解释

    TPC基准程序是用来测系统而不是测主机的,厂家肯定要充分优化他们的被测系统。此处的“系统”包括主机、外设(如硬盘或RAID)、主机端操作系统、数据库软件、客户端计算机及其 操作系统、数据库软件和网络连接等。在很多厂家的TPC测试系统中,主机的价格只是系统总价格的1/4或更小,而硬盘的价格有可能占到总价格的1/3以上,因为TPC-C要求被测系统必须保存180天的事务记录。如果同样的主机被用到用户的环境中,厂家报的tpmC值就意义不大,因为用户的实际系统与厂家原来用于TPC测试的系统大不一样。当同样的主机用在不同的系统中时,tpmC值可能有相当大的变化,现在很多用户还没有意识到这一点。

    我举一个例子。假设用 户希望购买一批同类系统,每一系统至少需要1GB的内存和50GB的硬盘。厂家A、B、C 各报了三个价格相当的系统,tpmC值分别为3000、2800、2600。用户是否应该选厂家A的产品呢?答案是:不一定。厂家用于测试tpmC值的系统与实际提供给用户的系统配置大不一样。tpmC最低的厂家C提供给用户的系统反而有可能性能最好,不 论是以实际系统的tpmC值还是以用户的实际应用性能来衡量。
    ③TPC测试的成本

    TPC-C和TPC-D都是很复杂的基准程序,做一个严格的测试是很消耗资源的,厂家当然不会说出他们花费了多少钱和时间。但据国外知情人士透露,一个厂家做第一个TPC-C测试需 要几十万到上百万美元的资金和半年左右的时间投入。因此,很多TPC的度量值都 是估计的。由于计算机系统换代频繁,如果用户一定要用通过审核的度量值,就必 须多等待半年时间,因此而不能用最先进的系统。中国的厂家通过审核的时间则更长。

    综上所述,我们对中国 用户(尤其是大用户)在计算机系统的选型方面有如下建议:

    最好建立一个真实的试点,因为实际应用环境是检验计算机系统的最好标准。

    中国的行业应该建立符合自己实际应用的基准程序和测试标准。中国税务总局的做法值得提倡。国家有关部门应该建立独立的测试中心,制定跨行业、符合中国企事业运作模式的性能测试标准。

    “国际通用”的度量可以作为参考值,而不应作为必要条件。尤其是一定要弄清这些流行度量有什么含义,是在什么样的系统环境中测得的,以及基准程序是否符合企业真实的业务流程和运作模式。

    作为一家非盈利性机构,事务处理性能委员会(TPC)负责定义诸如TPC-C、TPC-H和TPC-W基准测试之类的事务处理与数据库性能基准测试,并依据这些基准测试项目发布客观性能数据。TPC基准测试采用极为严格的运行环境,并且必须在独立审计机构监督下进行。委员会成员包括大多数主要数据库产品厂商以及服务器硬件系统供应商。

    相关企业参与TPC基准测试以期在规定运行环境中获得客观性能验证,并通过应用测试过程中所使用的技术开发出更加强健且更具伸缩性的软件产品及硬件设备。

    TPC-C是一种旨在衡量联机事务处理(OLTP)系统性能与可伸缩性的行业标准基准测试项目。这种基准测试项目将对包括查询、更新及队列式小批量事务在内的广泛数据库功能进行测试。许多IT专业人员将TPC-C视为衡量“真实”OLTP系统性能的有效指示器。

    TPC-C基准测试针对一种模拟订单录入与销售环境测量每分钟商业事务(tpmC)吞吐量。特别值得一提的是,它将专门测量系统在同时执行其它四种事务类型(如支付、订单状态更新、交付及证券级变更)时每分钟所生成的新增订单事务数量。独立审计机构将负责对基准测试结果进行公证,同时,TPC将出据一份全面彻底的测试报告。这份测试报告可以从TPC Web站点(http://www.tpc.org)上获得。

     

     
    第四章 TPCC计算原则
    1建议

    不管是TPC-C还是SPECjbb2000,计算结果都只能作为一个横向比较的参考。在实际应用中,决定系统性能的因素除了硬件、系统软件外,与应用软件的设计也是有很大关系的,此外,基于系统可扩展性的考虑,更多时候也倾向于一次性的采购。
    从长远考虑,以政府信息化主管部门的角度考虑,建立一套评估机制是非常有用的,这其中包括:
    1、 通过对各单位业务系统运行情况的调查,进行历史数据的收集分析,按分类建立基准指标库。收集的信息包括:服务器的配置、并发用户数(每天业务量)、CPU负荷等;
    2、 由厂商定期提供基准值,更新基准指标库;
    有了基准指标库的信息参照,不仅可以用于评估项目建设方案中服务器选型,也可以对各部门进行系统架构设计的优化提供指导。如以下是一些指导原则:
    1、 数据库服务器选型:采购两台相同配置的小型机,进行虚拟分区和并行处理,以提高系统资源的利用率;日后扩容时采取垂直扩展的方式进行升级;
    2、 应用服务器:采用负载均衡的方式提高并发处理能力,一般可配置2台以上,每台的硬件配置完全可以不同,应首先考虑使用旧的数据库服务器(利旧),如需采购新的服务器,应采用水平扩展的方式逐步升级;
    3、 WEB服务器,可以考虑采用刀片服务器,提高扩展性和可管理性。
    2参考:某项目计算实例
    参考1

    为了方便计算数据库服务器的造型,我们约定:
    " 系统同时在线用户数为1500人(U1);
    " 平均每个用户每分钟发出2次业务请求(N1);
    " 系统发出的业务请求中,更新、查询、统计各占1/3;
    " 平均每次更新业务产生3个事务(T1);
    " 平均每次查询业务产生8个事务(T2);
    " 平均每次统计业务产生13个事务(T3);
    " 一天内忙时的处理量为平均值的5倍;
    " 经验系数为1.6;(实际工程经验)
    " 考虑服务器保留30%的冗余;
    服务器需要的处理能力为:
    TPC-C=U1*N1*(T1+T2+T3)/3*3*经验系数/冗余系数
    则应用服务器的处理性能估算为:
    TPC-C= 1500*2*(3+8+13)/3*5*1.6/0.7= 274,285 tpmC

    数据库服务器关系到整个系统的稳定运行,考虑到高可靠性和高可用性,并注重设备的可扩展性和性价比,系统将配置两台TPC-C值不小于28万的高性能数据库服务器。
    参考2

     

    以单台服务器性能进行计算,即确保单台服务器工作的时候可以满足系统正常运行的需要;

    假设每天有1万人次来窗口办理业务,每人次办理一项业务。即以每日1万笔前台交易为例进行综合系数的推导:

    1. 假设每月前台交易数(未来5年内的设计指标)为220,000 (有些业务在月初、月末的处理量比较高,按月统计可以平衡此项差异);
    2. 每日前台交易数=220000/22=10,000 ,即每日 1万笔;
    3. 忙时处理能力:每日交易的80%在4个小时内完成,即10000*80%/4=2000(笔/小时)
    4. 峰值处理能力:2000*2=4000(笔/小时),即峰值处理能力为每小时4000笔,或 67笔/分,假设业务人员同时在线为100人,即每人每分钟处理0.7笔)
    5. 假设每笔交易对应数据库事务数=20,基准TPC指标值对应的比例=8,cpu保留30%的处理能力冗余,计算值与公布值(最优值)的偏差经验值为4 (这几个参数估算的依据不足,更多的是经验值)

    则 tpmC值为:
    tpmC= 67*20*8*4/(1-30%)= 61257[颠峰处理能力时(笔/分)*每笔交易对应数据库事务数*基准TPC指标值对应的比例*计算值与公布值(最优值)的偏差经验值/(1- cpu保留30%的处理能力冗余)
    倒算出 综合系数 = 61257/10000=6.1
    即数据库服务器tpmC= 每日前台交易数 * 6.1 (实际计算值应不高于该值)
    应用服务器的 tpmC = 数据库服务器 tpmC *50% (一般)

    应用服务器的 tpmC = 数据库服务器 tpmC *70% (涉及大量计算的,如社保、税务)




    自己个例



    展开全文
  • 文章目录1 华为云数据库服务全景图1.1 华为云数据库服务1.2 关系型数据库和非关系型数据库2 华为自研数据库关键技术2.1 GAUSSDB(for openGauss)企业级分布式数据库2.1.1 GAUSSDB(for openGauss)遇到的问题2.1.1.1 ...

    1 华为云数据库服务全景图

    1.1 华为云数据库服务

    华为云数据库服务分为自研数据库服务和云托管两个主要服务类型

    image-20210530161539027

    1.2 关系型数据库和非关系型数据库

    在关系型数据库中,我们有华为的自研数据库GaussDB,其目前可以支持多种不同的生态

    1. 支持mysql等主流数据库的接口和语法
    2. 支持数仓场景
    3. 支持TP和AP

    在非关系型数据库中,我们有两大平台,一个是华为的自研数据库GaussDB,针对当前的市场上主流应用场景(文档型,宽表型,缓存型,实质型)都可以支持,并且和主流数据库接口兼容。

    一个是MongoDB等数据库在云上也有托管,华为云提供了很多应用工具助力开发者

    1. 数据库迁移
    2. 数据迁移
    3. 数据库运维(面向不同人员)
    4. 数据中介服务

    2 华为自研数据库关键技术

    2.1 GAUSSDB(for openGauss)企业级分布式数据库

    定位为企业级分布式云数据库,架构上着重构筑传统数据库的企业级能力和互联网分布式数据库的高扩展和高可用能力

    image-20210530204443255

    GAUSSDB(for openGauss)架构图

    GAUSSDB(for openGauss)面向企业核心应用场景,对标一流数据库打造。

    2.1.1 GAUSSDB(for openGauss)遇到的问题

    2.1.1.1 内存访问不对称问题

    image-20210530204647728

    在传统的服务器结构中,我们有CPU,内存等,CPU的速度比内存快很多,需要北桥去对接CPU和内存,从而降低时延

    这种情况下,数据库无需关注硬件的连接。

    但是随着CPU的速度增加,内存越来越多,北桥的作用越来越小,逐渐被淘汰。

    当前当前主机不同的CPU通过高速总线连接在一起,CPU也可以直接连接内存。

    这时我们就需要数据库来考虑硬件架构。

    2.1.1.2 缓存一致性问题

    image-20210530204941290

    CPU和内存之间的速率不一样,为了解决速率问题,CPU有一级缓存,二级缓存,三级缓存等,但是当CPU数量过多时,如果数据库无法感知硬件架构,每个CPU都在同时访问

    缓存时,都在加载同一个变量,CPU还要保证读写一致性,就会产生问题,这个效率会产生量级的降低

    2.1.2 解决方法

    2.1.2.1 GAUSSDB(for openGauss)黑科技1:NUMA-Aware极致优化

    NUMA-Aware技术原理上感知CPU等硬件架构的不对称问题

    实现方法:

    1. 把存在数据库的数据进行分区处理,尽可能降低CPU之间的冲突问题,提高并行能力,并提供CPU的整体利用率
    2. 数据库中全局变量有具体单CPU负责处理读操作,其它CPU进行写操作,减少数据访问冲突

    2.1.2.2 GAUSSDB(for openGauss)黑科技2:GTM-Lite分布式拓展技术

    image-20210530205112859

    分布式强一致,分布式的GTM-Lite方案提供全局事务提交号管理,实现强一致性,且无中心节点性能瓶颈

    实现方法:

    • CSN时间戳和事务号TXID解耦;
    • GTM-Lite仅仅管理全局时间戳;
    • 本地时间戳和全局时间戳两维度管理;
    • 仅在事务提交时推进全局时间戳;
    • 仅在涉及跨Shard访问时才访问全局时间践,否则使用本地时间戳;
    • GTM-Lite异步同步,降低GTM-Lite访问时延;

    使用全局时间时,需要经过网络多跳,会增加时延。解决方法是协调结点进行同步

    2.1.2.3 GAUSSDB(for openGauss)黑科技3:分布式优化器提供极致的分布式扩展能力

    image-20210530174856904

    想要利用好系统的资源

    1. 提高并行执行能力

      充分利用当前多核特点,通过多线程并发执行,提高系统吞吐量

    2. 优化器生成运行规则,通过向量执行,提高执行效率

    3. 编译执行提高CPU指令的利用率

      从解释执行向编译执行转变,答复降低算子的指令数量,提高运算效率

    • AI加持驱动数据库自优化,自诊断

    image-20210530174951271

    结合深度强化学习与全局优化算法,针对不同类别的参数进行细粒度调优

    1. 调优时间:由天降至分钟级
    2. 索引推荐:基于用户的单条语句或批量负载,推荐最优索引

    image-20210530175119211

    持续采集数据库运行数据,基于时序预测和异常检测等算法实现智能监测

    1. 故障预警:预测资源、性能变化趋势,故障异常智能检测

    2.1.3 GAUSSDB(for openGauss)实现效果

    image-20210530175424633

    优化效果非常不错

    2.1.4 GAUSSDB(for openGauss)应用场景举例

    华为云GaussDB支撑工行核心业务系统国产化分布式改造

    image-20210530175651935

    2.2 面向互联网的云原生数据库架构解析

    2.2.1开源Mysql的挑战

    1. 主备切换RTO时间较长
    2. 重建实例耗时过长
    3. 备机只读数据新鲜度低
    4. 计算与存储不解耦,利用率低
    5. 网络资源利用率
    6. 备机数量有限(影响主机性能、组网复杂)

    image-20210530175802029

    2.2.2 解决方案

    2.2.2.1 黑科技1:LOG IS DATABASE,存算分离的云原生数据

    image-20210530180003189

    image-20210530180013606

    2.2.2.2黑科技2:Near Data Process+并行,提供极致性能

    image-20210530183018628

    NDP

    算子下推支持:投影,谓词,聚合算子,MVCC可见性判断。在存储节点对页面进行判断处理,极大精简返回页面大小,缩减网络IO。count(*)查询缩减IO吞吐达到40-80倍

    高度并行(三层并行)

    第一层:计算节点多worker并行查询
    第二层:由原有一个一个页面串行读,变成批量读多个页面,Page分布在不同slice上,多slice上并行读取
    第三层:单个存储节点上,多个NDP处理线程并行处理Page,运算下推算子逻辑。

    2.2.2.3黑科技3:极致备份恢复

    数据库专用分布式存储系统,极致的数据备份恢复性能

    image-20210530183325115

    整体故障恢复时间比较

    image-20210530183340683

    2.2.3GaussDB和开源数据库相比优势

    image-20210530183434085

    2.2.4应用举例

    永安保险成功从某主流商业数据库搬迁至GaussDB(for MySQL)

    image-20210530183515947

    image-20210530183549351

    2.3 华为云GaussDB(for Influx)亿级时间线技术解密

    2.3.1 时序数据模型及主要应用场景

    时序数据模型应用最多的两个领域是Iot和监控

    image-20210530201409425

    2.3.2 公有云SRE趋势

    2.3.2.1 公有云SRE趋势1:爆炸式增长的时序数据

    以CloudMonitorCenter为例,时序数据库支持了两种业务场景的监控原始数据采集与存储

    • 系统指标:主要监控CPu、Disk、网卡、负载、TCP、NTP、Ping等。
    • 自定义指标:包含容器监控指标、数据库指标、进程指标、中间件指标、日志指标、业务指标等,不同指标类型的指标名称、数据标签、数据类型各不相同.

    image-20210530201557690

    2.3.2.2 公有云SRE趋势2:时序数据的价值越来越高

    image-20210530201652039

    2.3.3云上运维监控系统面临的挑战

    2.3.3.1 架构现状

    image-20210530201806926

    2.3.3.2数据膨胀+业务复杂化+业务变化快

    华为云业务快速增长过程中的挑战:

    1. 业务类型多,变化快,分析诉求难于得到快速满足
    2. 数据规模大,增长速度快数据处理实效要求高
    3. 不同业务关联度高,故障根因分析困难

    image-20210530201955081

    2.3.3.3多模NoSQL服务GaussDB NoSQL

    GaussDB NoSQL是基于华为最新一代DFV计算存储分离架构打造的Active-Active全分布式架构多模NoSQL数据库服务,高度兼容MongoDB、Cassandra、Redis、InfluxDB四款主流NoSQL接口,支持跨3AZ高可用集群,相比社区版具有分钟级计算扩容、秒级存储扩容、数据强一致、超低时延、高速备份恢复的优势。适用于loT、气象、互联网、游戏等领域。

    image-20210530202254782

    GaussDB(for Influx) : 一站式时序数据存储、分析及洞察平台

    image-20210530202326844

    2.3.4 云原生时序数据库GaussDB(for Influx)架构

    分布式+存储计算分离+高可用

    image-20210530202547835

    2.3.5GaussDB(for Influx)亿级时间线技术解密

    时序数据90%的热点在近期数据,保障海量数据存储的同时提供极致性能

    image-20210530203228932

    两级分区策略

    • 时间分区:数据按时间段分区,分区时长可配置,可根据需求定义全内存、全热存储或者全冷存储数据库。
      时间线分区:根据shard key作Range/Hash分区。
    • 可根据需求在新的时间分区切换分区策略
      (hash/range)

    数据分级

    • 数据按照时间段分级·热数据在内存
    • 温数据在SSD·冷数据放HDD

    专用存储引擎

    image-20210530203435929

    写性能加速

    • 批流结合预聚合数据
    • 异步日志
    • 行列混合内存布同,减小数据转换开销

    时序文件布局

    • 面向时序数据专用布局
    • 列式存储,多级索引
    • 多版本平滑升级

    多级压缩算法

    • 时间相似性压缩算法
    • 时间差量压缩

    多模索引

    • 维度索引:倒排索引定位数据源
    • 时间线索引∶海量时间线kv索引

    查询加速

    • 增加立件级BRIN索引,减小聚合计算,加速Scan
    • 多级cache,加速聚合查询
    • 优化器代价评估,作大查询控制,选择二级索引or扫描

    自适应压缩算法

    根据Timestamp以及field data不同数据类型以及数据变化趋势,采用不同的数值变换算法,再根据变换后的数据分布设计自适应数值压缩算法,最后结合高性能的字典编码方法实现时序数据的高效自适应压缩。同时针对TSM文件内的时间羸进行相似性压缩,进一步降低时序数据存储成本。

    image-20210530203741946

    高性能多维聚合查

    大数据量聚合查询性能是开源的2~5倍;支持多维条件组合查询;
    技术方案

    • MPP架构,一条查询语句在多节点及多核并发执行;
    • 向量化查询引擎,每次迭代批量返回数据,大数据星下查询性能更好;
    • 增量聚合引擎基于滑动窗口的聚合查询,大部分从聚合结果缓存直接命中返回,仅而要聚合增量数据部分即可;
    • 支持多维倒排索引,支持多维条件组合查询,避免大量Scan数据;
    • 支持存储摘要索引,能够更快的过滤无关数据;

    image-20210530203814088

    存储分析告截

    image-20210530204051409

    展开全文
  • TPC,TPCC,TPMC(计算机性能衡量指标)

    万次阅读 2017-02-21 11:31:25
    第一章 什么是TPC和tpmC? 1 TPC TPC(Transaction Processing Performance Council,事务处理性能委员会)是由数10家会员公司创建的非盈利组织,总部设在美国。该组织对全世界开放,但迄今为止,绝大多数会员都...
  • 第一章 什么是TPC和tpmC?1 TPCTPC(Transaction Processing Performance Council,事务处理性能委员会)是由数10家会员公司创建的非盈利组织,总部设在美国。该组织对全世界开放,但迄今为止,绝大多数会员都是美、日...
  • 服务器TPMC值计算.doc

    2021-10-07 20:23:33
    服务器TPMC值计算.doc
  • 北京奥星贝斯科技有限公司 CTO 兼 OceanBase 数据库创始人阳振坤,在外滩大会上分享了《OceanBase 数据库七亿 tpmC 的关键技术》的主题演讲,以下为演讲实录: 联机事务处理(OLTP)系统 很多人都清楚事务的 ...
  • TPMC

    2013-03-29 17:20:12
    什么是TPC和tpmC? tpmC 衡量计算机系统的事务处理能力 TPC(TransactionProcessing PerformanceCouncil,事务处理性能委员会) http://www.tpc.org 是由数10家会员公司创建的非盈 利组织,总部设在美国。 ...
  • 服务器TPMC值计算[参照].pdf
  • tpmc

    万次阅读 2010-08-18 11:50:00
    用户在选用计算机系统硬件平台时总是希望有一种简单、高效的度量标准,能够量化计算机系统的性能,以此作为...  认识TPC-C和tpmC  tpmC值在国内外被广泛用于衡量计算机系统的事务处理能力。但究竟
  • 服务器TPMC值计算

    万次阅读 2013-03-15 10:38:11
    根据TPC-C的标准,tpmC值是根据标准模型中New-Order事务的处理数目来计算的,一个New-Order事务由平均4-5个SQL语句处理完成,整个测试的执行过程中,New-Order处理占45%。 估算条件: 运行商2003年将达到250万用户...
  • 标签 PostgreSQL , tpcc 背景 环境 阿里云虚拟机 [root@pg11-test ~]# lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CP...
  • TPC,TPCC,TPMC(数据库性能衡量指标)

    万次阅读 2013-11-12 09:58:52
    第一章 什么是TPC和tpmC? 1 TPC TPC(Transaction Processing Performance Council,事务处理性能委员会)是由数10家会员公司创建的非盈利组织,总部设在美国。该组织对全世界开放,但迄今为止,绝大多数会员都是...
  • 好奇怪为什么有大量的adt_lock,后来才发现自己莫名其妙的开启了行审计的功能。。。。。。
  • 测试环境:centos 6.6mysql数据库版本:5.6.23-72.1-log Percona Server阅读前 请确保了解基本的tpcc基准测试模型和概念:可参考:...
  • tpmC简单计算法

    千次阅读 2012-10-09 17:15:39
    应用服务器的 tpmC = 数据库服务器 tpmC *70% (涉及大量计算的,如社保、税务) 建议: 不管是TPC-C还是SPECjbb2000,计算结果都只能作为一个横向比较的参考。在实际应用中,决定系统性能的因素除了硬件、...
  • 标签 PostgreSQL , tpcc 背景 环境 阿里云虚拟机 [root@pg11-test ~]# lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CP...
  • TPMC

    千次阅读 2011-12-08 17:24:40
    TPMC值=峰值系数×并发用户数×交易数×60秒)/(响应时间×冗余系数×CPU利用率 1.5*130*15*60/1*0.5*0.9
  • 什么是tpmc

    千次阅读 2009-07-08 16:14:00
    tpmC值在国内外被广泛用于衡量计算机系统的事务处理能力。但究竟什么是tpmC值呢?作者曾向一些用户、推销人员乃至某些国外大公司的技术人员问过这个问题,但回答的精确度 与tpmC值的流行程度远非相称。tpmC这一度量也...
  • TPC,TPCC,TPMC

    2011-12-28 21:01:00
    第一章 什么是TPC和tpmC? 1 TPC TPC(TransactionProcessing Performance Council,事务处理性能委员会)是由数10家会员公司创建的非盈利组织,总部设在美国。该组织对全世界开放,但迄今为止,绝大多数会员都是美...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 1,113
精华内容 445
关键字:

tpmc