登陆发布提交

PolarDB大更新-最新版本颁布 (polardb和mysql的区别)

文章编号：11061 更新时间：2024-03-16 分类：互联网资讯 阅读次数：次

资讯内容

架构简介

PolarDB-X驳回Shared-nothing与存储分别计算架构启动设计，系统由4个外围组件组成。

PolarDB大更新最新版本颁布pola
PolarDB-X架构图

开源地址：[]

版本说明

梳理下PolarDB-X开源头绪：

2022年9月份，PolarDB-X数据库高分经过散布式数据库金融规范验证，共启动了337个检测项的验证上班，触及：架构、运维、安保、容灾、性能等。经专家评审后，PolarDB-X判定合乎的检测项为323项，全体测试结果体现优秀。

2022年10月份，PolarDB-X正式颁布2.2.0版本，这是一个关键的里程碑版本，重点推出合乎散布式数据库金融规范下的，共包括八大外围个性，片面优化PolarDB-X散布式数据库在金融、通信、政务等行业的普适性。

01国产ARM适配

目前市场上关于国产主机的适配有比拟强的需求，经常出现的需求就是兼容CPUARM架构，除了数据库能反常运转在ARM架构上，还须要联合国产ARM架构优化数据库的性能。

参考文档：干流CPU性能摸底(Intel/AMD/鲲鹏/海光/飞扬)

PolarDB-XV2.2.0版本开局，同时颁布兼容X86/ARM架构的二进制版本，另外配套的数据库部署工具，也会允许ARM架构下的numa绑核才干，优化数据库的性能。

口头dockermainfestinspect(检查对应的二进制版本)

X86/ARM版本

为了更繁难的体验PolarDB-X的X86/ARM部署，经过阿里云提供ARM芯片架构的ECS主机，云起试验室体验地址：如何在ARM平台部署PolarDB-X

02全新读写分别架构

MySQL生态里读写分别是一种比拟经常出现的技术，除了用于处置写少读多场景的优化，也常罕用于OLTP/OLAP业务隔离的典型场景，比如思考在线数据库的稳固性，经过读写分别将一般复杂查问发送给MySQL的备库。

传统MySQL的读写分别：

传统读写分别

存在的疑问：

PolarDB-X的读写分别架构：

云原生HTAP~读写分别架构

强分歧读写分别

散布式数据库，自然具有多正本的才干，PolarDB-X驳回了Paxos少数派共识协定，借助于Paxos协定的日志流LogIndex(全局递增的惟一序列，记载Paxos日志下标)，PolarDB-X可以基于LogIndex成功多正本的全局分歧性读，到达读写分别的成果。

PolarDB-X在传统的MySQL读写分别架构基础上，引入了PaxosLearner节点作为只读RO节点(不介入Paxos三正本投票，仅异步复制数据，RO节点CPU跑满不会影响三正本少数派的写入)。在读写分别形式下，路由到只读RO节点的流量，PolarDB-X会优先失掉主库的LogIndex，确保RO正本的LogIndex超越该值，同时应用散布式事务MVCC的TSO期间戳版本，可以成功满足RC/RR隔离级别下的强分歧读写分别。

1、强分歧读写分别测试：模拟业务先写后读的场景，写出当初RW库、读出当初RO库

写后读距离（ms） 传统读写分别(弱分歧性) PolarDB-X读写分别(强分歧性)

图中数值示意主备节点的位点提前，数值越小示意提前越小，0示意无提前。

2、sysbench压测，验证强分歧读写分别形式下的性能裁减

CN节点规格：2*16C128G，DN节点规格：RW主实例2*4C32G、RO只读实例2*4C32G

sysbencholtp_read_only场景： 

sysbench--config-file='sysb.conf'--db-ps-mode='disable'--skip-trx='on'--mysql-ignore-errors='all'--tables='16'--table-size='10000000'--range-size=5--threads=512oltp_read_onlyrun
只读实例查问占比 主实例+一个只读实例(强分歧) 主实例+一个只读实例(弱分歧) 主实例+两个只读实例（强分歧） 主实例+两个只读实例（弱分歧）

从测试结果看：

1.在强分歧性读下，在OLTP读场景下流量从主实例切换到只读实例上吞吐的性能衰减20～30%，然而经过参与只读实例个数，性能可以做到必定的线性参与；

2.在弱分歧性读下，在TP读场景下流量从主实例切换到只读实例上吞吐的性能未衰减，且经过参与只读实例的个数，性能可以做到线性参与；

HTAP混合负载

HTAP架构的外围目的是协助用户降落老本：运维老本、经常使用老本。比如：传统的OLTP+ETL+OLAP的处置方案，最大的应战在于运维老本的复杂性和稳固性，HTAP数据库的一体化架构可以有效降落外置的运维老本。

目前，市面上的HTAP架构外形多种多样，总结一下外围技术三因素：

PolarDB-X在开源V2.2.0版本里，提供了如下才干：

HTAP架构即使存在资源隔离，但假设业务在经常使用中将数据剖析查问假设跑到了主库上，也会影响了在线业务的性能，因此关于业务恳求如何正确经常使用多正本也十分关键。

从易用性和稳固性的角度，PolarDB-X提供了基于优化器cost代价的PolarDB-X优化器会基于代价剖析出查问物理扫描行数、CPU、内存、IO、网络等内围资源消耗量，将恳求区分为TP与AP负载，假设在集群地址上开启了智能路由，会被动识别SQL的上班负载类型来做路由，比如将辨以为AP负载的流量路由给只读RO正本。可以经过explaincost指令检查SQL上班负载类型的识别状况。例如以下查问，该查问触及到物理扫描行数rowcount很小，计算资源（CPU&Memory）也消耗比拟少，所以这个查问被辨以为TP负载。

以TPCHQ13为例来展示下口头器在不同场景下的减速成果，为了繁难截图在Q13前面都加了limit

对应CN/DN节点规格：2*16C64G单机复线程下运转，耗时3min31s

经常使用ParallelQuery减速，既单机多线程口头，耗时23.3s

经常使用MPP减速，既同时应用两个CN节点的资源计算，耗时11.4s

03MySQL生态兼容性

MySQL数据库除了基本的SQLDML/DDL/DAL以外，还有许多初级个性，比如锁系统、binlog协定、主备replicatION、存储环节、触发器、外键、视图等。

传统的散布式两边件或散布式数据库，标榜的高度MySQL兼容性，更多是在SQL的性能语法上，比如DML/DDL/DAL，但在性能兼容、生态兼容上还是有蛮多的差同性，带来了经常使用上的复杂性。

举几个例子：

PolarDB-X在22年3月份开源的版本中，曾经很好的允许MySQL隔离级别、以及MySQLbinlog生态兼容的才干，本次V2.2.0的开源版本，重点增强了几项新的兼容才干：

存储环节

存储环节（StoredProcedure）是一组为了成功特定性能的SQL语句集，业务在成功某些需求时，须要编写一组复杂的SQL语句才干成功的时刻，很多资深数据库用户习气经常使用存储环节。

经常使用存储环节能带来如下好处：

当然存储环节也存在一些缺陷：

PolarDB-X基于GMS存储，片面兼容了MySQL存储环节语法，允许存储环节的创立、修正、删除等治理操作。同时引入了PLEngine引擎允许存储环节的运转、以及运转的内存治理，允许GB级别的小事务和2小时的长事务等。 

#存储环节demoCREATEPROCEDUREpro_test()BEGINDECLAREaCHAR(16);DECLAREb,cint;DECLAREcur1CURSORFORSELECT>详细概略可以参见：
AutoIncrement自增解放
散布式数据库提供全局惟一数字序列的关键目的是为了生成全局惟一和有序递增的数字序列，罕用于主键列、惟一索引列等列值的生成。
相比于目前绝大局部的NewSQL仅提供了全局惟一但不延续的自增ID，PolarDB-Xv2.2提供了全局惟一、延续、干燥递增的AutoIncrement兼容才干，简称：NewSequence，发生的值是自动从1开局的自然数序列。在AUTO形式库中建表时，指定AUTO_INCREMENT自增列，将自动智能为该表创立并关联一个NewSequence对象，用于在INSERT时智能填充自增列的值。
#兼容MySQL的建表createtabletest(idbigintnotnullAUTO_INCREMENT,numberINTNOTNULL,primarykey(id))#兼容MySQL的SQL操作INSERTINTOtest(number)VALUES(1);INSERTINTOtest(number)VALUES(null,2);INSERTINTOtest(number)VALUES(0,3);INSERTINTOtest(number)VALUES(null,4),(null,5)…;SELECTLAST_INSERT_ID();#兼容OracleSequence语法CREATENEWSEQUENCEnewseqSTARTWITH1000;SELECTSEQ.NEXTVAL;SELECTSEQ.CURRVAL;SELECTSEQ.NEXTVALFROMDUALWHERECOUNT=100;ALTERTABLEtest_pxcAUTO_INCREMENT=200;
Demo视频：
详细概略可以参见：PolarDB-X与MySQLAUTO_INCREMENT齐全兼容
04数据库安保
在IT圈内，删库跑路曾经成为程序员经常提及的一句玩笑话。只管是玩笑话，却反映了数据库对企业的关键性，在优化数据库安保性上，除了做好网络隔离、权限治理外，还须要再全链路中做好审计，确保有查比有果。同时在面向数据失落的状况下，做好应急复原的才干。
全量SQL审计
传统的数据库审计，普通驳回网络旁路的形式，经过外置组件集中搜集一切网络流量，从中采集到对应的SQL审计，另外提供一个审计查问的入口启动极速检索。
PolarDB-XV2.2.0版本，经过数据库内置的SQL审计才干，可以极速且完整的记载一切SQL日志，PolarDB-X经过Logstash组件作为日志的解析和上报组件，自动准实时采集全量SQL的文本，经过logstash的投递组件的裁减，比如可以对接ElasticSearch组件或许自定义裁减组件，成功SQL审计耐久化存储和白屏化SQL审计查问。
详细概略可参见：
SQL日志格局：
SQL审计(ES截图)
FlashbackQuery
删库跑路事情不常有，但因大意造成的误删数据却不足为奇，比如手误口头了一个失误的DML，造成数据被误删。首先，咱们以一个实践误删数据的意外收场。
咱们来梳理下意外的期间线：
围绕这一次性的数据误删意外，看看是PolarDB-X是如何挽救大意的小明的？
PolarDB-X在新版本提供FlashbackQuery性能，针对行级误删场景，提供短期间内误操作的极速回退才干。
经过FlashbackQuery的ASOFTIMESTAMP'xx'可以极速查问数据误删前的数据版本记载
#SQL例子selecttitlefromemployeewhereidin(2,3)ASOFTIMESTAMP'2022-11-1100:00:00'
原了解读：失误SQL出现时，变卦都会记载在版本为Vn+1的undolog中；T2时，发现了误改疑问并确定误操作期间和影响的数据范畴；经过FlashbackQuery才干间接查到了被影响的两行记载在T1时辰正确的值；依据FlashbackQuery前往的正确值对数据启动了勘误。
05散布式数据治理
散布式数据库中，数据须要依照必定的战略散布到多个节点中，对数据的可治理性是数据库的一个关键才干维度，在保证数据库线性水平裁减下，基于数据治理来到达业务的诉求。
数据治理的典型业务场景：
    PolarDB-X在V2.2.0版本中，进一步增强了分区表的治理才干以及基于Locality的调度。
    分区表治理
    传统的数据分区战略，普通仅在数据表第一次性创立时定义了散布规定，预先的分区新增、修正、删除普通不允许数据搬迁。PolarDB-X在分区表的变卦才干上，在满足散布式数据不平衡性上做了更多灵敏的变卦治理。
    1.hash/key分区决裂
    比如一张表orders
    CREATETABLEorders(aint)PARTITIONBYkey(a)partitions3;
    自动的这三个分区的名字依次是p1，p2，p3，可以经过以下语法，将p1决裂成两个分区，这两个新分区是在原p1的hash空间范畴内将其按hash空间范畴一分为二：
    ALTERTABLEtb1SPLITPARTITIONp1;//p2/p3的数据分区不须要移动
    2.hash/key分区的热点提取
    在orders表的基础上，做一个变卦：
    ALTERTABLEorders(aint,bint)PARTITIONBYkey(a,b)PARTITIONSBY3;
    口头以下SQL，将拆分键值为(a=88,b=10)的数据，提取到一个独自的新分区：
    ALTERTABLEtb1EXTRACTTOPARTITIONp_hot88BYHOTVALUE(88,10);
    3.分区迁徙
    继续沿用orders表，拆分键值为(a=88,b=10)的数据分区，独自迁徙到一个独立的DN节点上，对应的DN名字为DN_VIP88。
    ALTERTABLEordersMOVEPARTITIONSp_hot88to'DN_VIP88';
    除了例子中的hash分区外，range/list等分区均允许相似的决裂、兼并、迁徙、重命名等治理。
    更多内容可以参考文档：
      Locality调度
      PolarDB-X在V2.2.0版本中，提供一种更灵敏的Locality定义才干，可以针对数据库的不同对象启动定义，从而去成功数据存储的有效治理。
        CREATE>2.table对象，指定loality可以将不同的单表散布到不同的DN节点中
        #0号DNCREATETABLEtableA(aint)singlelocality='dn=polardbx-dn-0000';#1号DNCREATETABLEtableB(aint)singlelocality='dn=polardbx-dn-0001';
        3.partition对象，可以在分区级别启动精细化分区治理，成功细粒度的治理。
        比如针对一张表，北京数据可以散布在3个DN节点、上海散布在2个DN节点，新疆和西藏共用一个DN节点
        CREATETABLEorders_region(order_idintAUTO_INCREMENTprimarykey,cityvarchar(64))PARTITIONBYLIST(city)(PARTITIONp1VALUESIN('北京')LOCALITY='dn=polardbx-dn-beijin01,polardbx-dn-beijin02,polardbx-dn-beijin03',PARTITIONp2VALUESIN('上海')LOCALITY='dn=polardbx-dn-shanghai01,polardbx-dn-shanghai02',PARTITIONp3VALUESIN('新疆'、'西藏')LOCALITY='dn=polardbx-dn-west',);
        冷热数据分别
        降本增效目前是数据库的一个关键技术方向，联合PolarDB-XV2.1.1提供的OSS提供冷热数据分别存储，以及分区和Locality调度，可以有如下的构想空间：
          更多内容可以参考文档：
            06开源相关配套工具
            数据库的生态树立，除了MySQL内核和协定的兼容性外，最关键的就是配套的生态工具，比如经常出现的就是面向数据库的导入导收工具。
            PolarDB-X在V2.2.0版本中，开源了在散布式数据库金融规范中所经常使用的几款生态工具，协助大家更好的经常使用PolarDB-X。
            polardbx-backup
            PolarDB-XOperator中提供了强分歧的备份复原，外部最关键的就是backup工具。咱们选用基于PeconaXtraBackup源码基础上，裁减了散布式数据库的局部个性：
              更多概略，可以参考开源代码：
              benchmark-boot
              PolarDB-X提供了一款白屏化的数据库压测工具，融合了经常出现的sysbench、TPC-C、TPC-H的压测脚本，可以协助大家极速成功数据库的性能测试。
              工具个性：
                更多概略，可以参考文档：经常使用BenchmarkBoot启动压测
                batch-tool
                BatchTool工具是专为PolarDB-X数据库提供数据导入导出服务的工具。其联合散布式数据库特点成功一站式且高效地从文件导入、导出到文件以及跨库的离线数据迁徙(MySQL/PolarDB-X)等性能，在此基础上，还允许基于文本文件批量更新、删除等性能(试验个性)。
                导出方法对比
                测试方法以PolarDB-X导出1000w行数据为例，数据量大略2GB左右。
                形式数据格局文件大小耗时性能（行/每秒）性能（MB/S）
                mysql-e命令导出原始数据原始数据格局
                mysql-e命令导出csv格局csv格局
                mysqldump工具（net-buffer-length=10KB）sql语句格局
                mysqldump工具（net-buffer-length=200KB）sql语句格局
                batchtool工具文件数=32（分片数）csv格局
                batchtool工具文件数=1csv格局
                导入方法对比
                测试方法以PolarDB-X导入1000w行数据为例，源数据是上一个测试中导出的数据，数据量大略2GB左右。
                形式数据格局耗时性能（行/每秒）性能（MB/S）
                source语句（net-buffer-length=10KB）sql语句格局
                source语句（net-buffer-length=200KB）sql语句格局
                mysql命令导入（net-buffer-length=10KB）sql语句格局
                mysql命令导入（net-buffer-length=200KB）sql语句格局
                load>数据导入导收工具小结：
                  更多概略，可以参考文档：
                    07轻量化部署和运维
                    PolarDB-XOperator是一个基于Kubernetes的PolarDB-X集群管控系统，宿愿能在原生Kubernetes上提供完整的生命周期治理才干，满足用户的轻量化部署。
                    在PolarDB-XV2.2.0版本，咱们进一步完善了泛滥面向消费运维的企业级性能。
                    强分歧备份复原
                    数据库经过备份复原来保证数据安保，用户在运维误操作、或删库跑路等严重缺点的状况下，可以驳回备份集复原的形式来极速复原业务数据，缩小业务损失。
                    散布式数据库在面向备份复原场景中，有几方面的应战：
                      PolarDB-XV2.2.0中驳回了散布式多机+物理备份的形式，提供了强分歧备份复原的才干。PolarDB-X是基于MySQL的原生散布式数据库，底下数据存储格局和MySQL凑近，因此咱们选用基于PeconaXtraBackup定制成功PolarDB-X的物理备份，多个DN节点并前启生物理备份复原，联合备份分歧性算法处置散布式事务在物理备份环节中的差异数据。
                      概略可以参考文档：
                        参数模板
                        PolarDB-X参考私有云数据库的最佳通常，提供了参数模板的治理才干，包括参数模板的创立、变卦、批量运行等，可以有效协助大家更好的治理在线数据库。
                        经常出现的参数模板，普通分为高安保形式和高性能形式，可以繁难大家在数据库POC和消费参数之间做好差异化治理。
                        创立参数模版(kubectlapply-f{参数模板文件称号}.yaml)
                        ##参数模板示例apiVersion:polardbx.aliyun.com/v1kind:PolarDBXParameterTemplatemetadata:name:parameterTemplatespec:nodeType:cn:#参数列表paramList:-name:CONN_POOL_BLOCK_TIMEOUTdefaultValue:"5000"mode:read-writerestart:falseunit:INTdivisibilityFactor:1optional:"[1000-60000]"-...dn:name:dnTemplateparamList:-name:innodb_use_native_aiodefaultValue:"OFF"mode:readonlyrestart:falseunit:STRINGdivisibilityFactor:0optional:"[ON|OFF]"-...gms:...
                        经常使用参数模板(PolarDBXCluster的yaml文件)
                        #经常使用参数模板apiVersion:polardbx.aliyun.com/v1kind:PolarDBXClustermetadata:name:pxcspec:......#须要性能的参数模板parameterTemplate:name:parameterTemplate
                        概略可以参考文档：
                          容灾部署
                          PolarDB-XOperator联合K8SPOD的调度才干，推出基于k8sselectors的集群部署规定。
                          首先，定义机房selector
                          selectors:-name:zone-anodeSelector:nodeSelectorTerms:-matchExpressions:-key:topology.kubernetes.io/zoneoperator:Invalues:-cn-hangzhou-a-name:zone-bnodeSelector:nodeSelectorTerms:-matchExpressions:-key:topology.kubernetes.io/zoneoperator:Invalues:-cn-hangzhou-b-name:zone-cnodeSelector:nodeSelectorTerms:-matchExpressions:-key:topology.kubernetes.io/zoneoperator:Invalues:-cn-hangzhou-c
                          最后，定义集群部署规定(每个机房平均部署)
                          //计算节点在A/B/C机房内平均散布cn:-name:zone-areplicas:1/3selector:reference:zone-a-name:zone-breplicas:1/3selector:reference:zone-b-name:zone-creplicas:1/3selector:reference:zone-c//存储节点的三正本区分部署在A/B/C机房dn:nodeSets:-name:cand-zone-arole:Candidatereplicas:1selector:reference:zone-a-name:cand-zone-brole:Candidatereplicas:1selector:reference:zone-b-name:log-zone-crole:Voterreplicas:1selector:reference:zone-c
                          基于k8s灵敏的yaml性能，大家可以施展下构想空间：
                            概略可以参考文档：
                              更多更详细的文档，可以参考：PolarDB-XOperator运维指南
                              08片面的性能优化和优化
                              PolarDB-X作为一款散布式数据库，除了企业级个性外，数据库的全体性能也不时是关键的演进方向，惯例的benchmark场景优化，比如：RPC协定优化、散布式事务1PC优化等。
                              更小的起步规格
                              散布式数据库由于天生散布式多组件，造成起步的规格性能要求比拟高，业务在开展初期并不须要16core64GB以上的大规格，更多还是在私有云干流的2core/4core/8core规格，在降本增效的大环境下，散布式数据库也须要贴合业务诉求，允许可小可大，成功更极致的线性裁减性。
                              目前PolarDB-X的最小起步规格状况：
                                全方位的性能优化
                                散布式相关型数据库中，经常出现的benchmark关键是sysbench和TPC-C，用来评估OLTP场景的基天性力，这类benchmark的典型特色是偏TP类的小查问为主，重点关注吞吐量，外围的优化思绪是从代码简化、网络传输、以及事务优化等方向。
                                PolarDB-XV2.2.0版本，在OLTP场景有3个外围优化：
                                  初步测试的高并发状况：3*16C64G(CN)、3*16c128g(DN)
                                  场景800并发2000并发
                                  point_select
                                  read_write
                                  除此之外，也在面向业务场景上做了更多才干上的优化，比如：冷数据归档的数据剖析、以及数据跑批的并行DML、小事务优化等，由于篇幅的相关不再详述，欢迎大家交换。
                                  更实时的CDC才干
                                  PolarDB-XCDC组件，关键提供全局binlog的相关才干，基于CDC可以成功PolarDB-X与MySQL之间构建MySQlreplication复制协定，同时兼容市面高端行的binlog解析工具，比如canal/flinkcdc/maxwell等。
                                  CDC的增量日志，比拟关键的目的就是增量提前(数据写入数据库到下游拿到该记载的变卦，对应的期间差称之增量提前)，散布式数据库下须要思考高并发下的增量提前数据。
                                  PolarDB-XV2.2.0中，在CDC同步性能成功翻倍，最大EPS才干从100w/s优化至200w/s，最大写入吞吐才干从250M/s优化至500M/s，外围性能目的如下（参考：PolarDB-X全局Binlog解读之性能篇）：
                                  测试场景参考目的增量提前(DelayTime)EPS(每秒binlogevent数)BPS(每秒binlog字节数)
                                  TPCC数据导入8000仓/1200并发450M/s-500M/s
                                  Sysbench数据导入48Tables/48并发
                                  TPCC买卖测试
                                  TPCC买卖测试
                                  Sysbencholtp_write_only
                                  小事务
                                  小事务
                                  小事务
                                  小事务
                                  小事务
                                  总结，CDC在16核的规格下，可以允许100万tpmC、sysbencholtp_write_only场景qps30万，满足增量提前<1秒，同时对小事务也做了磁盘swap的兼容处置，可以允许20GB的小事务机制，满足绝大局部的业务诉求。未来，PolarDB-X也会允许binlog多流，成功更大千万级别规模的线性裁减。
                                  开头
                                  PolarDB-X是由阿里自主研发的原生MySQL散布式数据库，坚持以全内核开源的形式，坚持开源的继续迭代。本次重磅颁布V2.2.0版本，是一个关键的里程碑，重点推出合乎散布式数据库金融规范下的企业级和国产化适配的产品才干，希冀PolarDB-X未来能作为国际原生MySQL散布式数据库的开源指导者，继续做好开源！

                                  国内做分布式数据库开发的现状如何？

                                  应该说，现在是国产分布式数据库发展的利好时期。在讨论发展前景前，首先要先看看分布式数据库的发展方向。

                                  大家把传统关系型数据库称作oldSQL，给人感觉要被淘汰似的。但其实数据量不是很大或者事务处理的场景夏，关系型数据库的还是占优的。

                                  关系型数据库的主要问题在于：

                                  性能瓶颈，

                                  单一模型（关系模型），只适合OLTP

                                  应对业务的灵活性不够，

                                  弹性扩充能力不够，

                                  两地三中心和双活等问题上不足。

                                  随着互联网和手机的飞速发展，无论从用户规模、使用频率、还是场景多样性都使得这些问题浮出水面。其实Oracle在92年就开始尝试转向分布式，还当时引起了业界的巨大争论，最后失败。更何况过去CPU、内存、存储、带宽的高成本导致分布式数据库的性价比并不高，只能停留在学术阶段，限制了分布式的发展。

                                  新分布式数据库首先是要避免和传统关系型数据库的竞争，这是明智的选择，能够轻装上阵。因此从几个方面入手，应对海量数据处理、分析、缓存、流式处理、开发模式等等。相对应列式，KV，Document等多种存储数据结构。

                                  所有这些都被称为NoSQL数据库，放弃ACID和事务能力还换取性能。然而，NoSQL又收到了大量的批评反对意见，主要是说把数据库应该处理的问题交还给了开发是种发展的倒退。这些问题包括，索引、版本、SQL支持、事务支持等等。市场上超过90%的开发员都需要SQL，而且SQL也是非常有效和成熟。于是大家无论底层是什么存储结构又开始支持SQL，形成了NewSQL。

                                  这里插一句题外话，在硅谷已经不再用SQL、NoSQL、NewSQL来划分数据库了。理由很简单，SQL是一种语言，从来没有SQL数据库的说法，自然也不应该有NoSQL数据库的说法。NewSQL数据库就更不合理，用的SQL并非什么“New“的新东西。所以专业上用关系型和非关系型数据库来划分，分布式数据库主要都是非关系型数据库。

                                  回过头来看国内分布式数据库市场需求，中小企业不满足Mysql的性能，分库分表又很难搞，也不彻底；大型企业被Oracle等垄断支付高额成本，而且又不解决实际碰到的瓶颈问题。因此，用户都在寻找新的解决方案。小型用户、云计算的用户、大型企业都需要对应的分布式数据库产品。

                                  再加上国产自主和去IOE浪潮，更加推动了国产分布式数据库的发展利好。值得注意的是，数据库研发是个严肃的事情，没法短平快。

                                  标签： 国产化、 PolarDB、 散布式数据库、

                                  本文地址： https://yihaiquanyi.com/article/2824bc9e8b018b9366d9.html

                                  上一篇：外交部驻港公署谴责欧洲议会通过涉港决议...
                                  下一篇：应并尽并优先拨补贴三部委六大政策力挺户用...

                                  发表评论

                                  热门文章

                                  站点推荐