包含云原生数据库TDSQL-C的词条

本文目录：

• 1、gbase哪个证书要花钱
• 2、对话阿里云李飞飞：关于云原生数据库的五大预判
• 3、NewSQL分布式数据库发展策略讨论
• 4、TDSQL TCA 分布式实例特点初探分布表和SQL透传

gbase哪个证书要花钱

国产数据库浪潮之下，学习国产数据库的人越来越多，国产数据库认证的含金量也越来越高。获得国产数据库相关认证的小伙伴，在求职、晋升等方面都具有极大的优势。小编整理了国产数据库免费认证汇总，想要完善知识体系，系统学习并获得免费认证的朋友，看这一篇就够了！

目录

TiDB

认证介绍

学习方式

OceanBase

认证介绍

学习方式

GBase

认证介绍

学习方式

腾讯云

认证介绍

学习方式

国产数据库认证考试指南汇总

TiDB

TiDB是 PingCAP 公司自主设计、研发的开源分布式关系型数据库，目前PingCAP Education 共推出了 PCTA PCTP 两门在线认证考试，两门在线认证都可以免费获得。

认证介绍

PCTA （ PingCAP Certified TiDB Associate ）是 PingCAP 公司认证 TiDB 数据库专员的缩写。 PCTA 要求具备安装部署及日常运维分布式关系型数据库的能力。PCTA 需要学习并熟练掌握 TiDB 架构原理、安装部署、周边工具等基础知识。

PCTP （ PingCAP Certified TiDB Professional ）是 PingCAP 公司认证 TiDB 数据库专家的缩写 。PCTP 要求具备管理大型分布式关系型数据库集群的能力。 PCTP 需要学习并熟练掌握 TiDB 的深度原理及高级 Feature、性能调优、SQL 优化、故障排除和高可用架构等进阶内容。 要成为 PCTP 必须先获得 PCTA 认证。

PCTA考取后，才可以考 PCTP，PCTP难度大于 PCTA。顺利通过 PCTA / PCTP 认证考试，即可获得相应认证证书。

学习方式

直接在官网： 报名，课程进度达到一定值，即可报名考试。

1、PCTA 认证考试。 学习《301 TiDB 系统管理基础》课程，学习进度达到60%及以上即可报名考试。考试时长 60 分钟，共 60 道题（单选 30 道，多选 30 道，每题 1 分）满分 60 分， 36 分为及格 。认证证书（电子版）将于考试结束后 1 个工作日内发放，一经发放，长期有效。

最近报名时间： 2022-06-04 00:00至2022-06-20 00:00

最近考试时间： 2022-06-23 20:00至2022-06-23 21:05

2、PCTP 认证考试。 PCTP 认证考试为远程闭卷考试，学习《302 TiDB 高级系统管理》课程进度达到80%及以上即可报名参加考试，考试时长 90 分钟，共 70 道题（单选 35 道，多选 35 道，每题 1 分）满分 70 分， 42 分为及格 。 认证证书（电子版）将于考试结束后 2 个工作日内发放。证书一经发放，长期有效。六月PCTP考试已结束，大家可以在官网关注七月认证时间。官网报名费900元，可以通过以下两种方式获得免费考试兑换码：

1）4000 社区积分可兑换 1 个 PCTP 考试兑换码。

2）成为 TiDB 社区版主，版主任职满 6 个月，可获得 1 个 PCTP 认证考试兑换码。

OceanBase

OceanBase是由蚂蚁集团完全自主研发的企业级分布式关系数据库，目前推出了OBCA、OBCP 以及OBCE三种认证，其中OBCA（OceanBase 数据库认证专员）目前限时免费，可在官网： 报名。

认证介绍

OBCA 认证主要讲解 OceanBase 的发展历程、应用案例、产品架构、核心功能、部署安装等知识。帮助您理解多副本一致性协议、数据可靠及高可用、在线水平扩展、分布式事务等 OceanBase 的重要特性。OBCA 认证主要面向具备 IT 通用基础能力的学员，了解至少一门关系型数据库（MySQL 或者 Oracle），对分布式系统或分布式事务有基本了解，适合初级数据库管理员，初级应用开发人员，合作伙伴驻场服务人员等。

学习方式

在OceanBase官网平台注册登录，进行个人实名认证后，点击OBCA认证考试，即可免费报名。目前OBCA 认证培训有线上、线下两种方式参与，线上学习有六章视频课程。OBCA的考试题目一共50道题（从题库中随机抽取）。其中15道判断题（每题1分）、20道单选题目（每题2分）、15道多选题目（每题3分），总分为100分，通过分数为60分。

OBCA考试现阶段为每位考生提供3次免费考试机会，考生每天限考1次。考试通过以后，可以在OceanBase官网查询领取OBCA证书，证书终身有效。

GBase

GBase是南大通用数据技术有限公司推出的自主品牌的数据库产品，GBASE继续在今年暑假期间，举办“千人优学-GBase数据库大学生专场实训”培训，专为在校大学生量身定做、全程免费的GBase 8s GDCA认证培训。

认证介绍

面向对国产数据库感兴趣、有意愿未来从事数据库交付运维、售前支持的在校学生，通过课程，了解国产数据库，掌握GBase 8s原理及基本运维开发。考试通过者免费获得GBase管理工程师认证证书（电子）。

学习方式

整个课程分为学习和考试2个阶段，14天学习（内含1次模拟考试），2次认证考试机会，整个课程以在线学习平台组织培训考试，通过群内专业老师答疑，2次直播说明答疑，通过科学合理的安排，循序渐进、轻松掌握国产数据库基础知识。认证考试成绩60分（含）以上课程及格，可获得实训学分；80分（含）以上获得GBase 8s GDCA认证证书（电子版）；低于60分的同学可申请1次补考。

学习日期：6月20-7月3日 每天解锁一节课

考试日期：7月7日 19:00-21:00 （答题时长60分钟）

补考日期：7月9日 19:00-21:00 （答题时长60分钟）

具体报名方式：

腾讯云

腾讯云推出的“云梯计划”，为学生开发者及高校提供全面的腾讯云学习、实战资源，助力未来开发者登上筑梦云梯。学生群体完成学生认证后，可以免费上认证课程、免费获得动手实验课程，最后能获得8折优惠券报名认证考试，认证证书两年内有效。具体四项认证如下图所示：

认证介绍

腾讯云从业者认证是云计算行业从业者的初级技能认证，通过该认证可有效验证是否具备掌握云计算基础知识以及理解腾讯云基础产品的功能和使用场景的能力。适用于初入云计算行业，计划从事售前工作，或逐步向运维、架构等角色提升的人员。

腾讯云开发工程师认证是针对云上业务应用开发工程师的技能认证。通过该认证，可有效验证是否具备将传统应用重构并迁移上云的能力，以及基于腾讯云进行云原生应用和分布式微服务的设计和开发能力。适用于腾讯云开发工程师，负责云应用程序开发的人员。

腾讯云运维工程师认证是针对腾讯云产品运维人员的技能认证，通过该认证，可有效验证是否具备腾讯云基础产品的部署、监控、运维能力。适用于从事运维腾讯云产品和服务的人员，负责在云上部署业务的技术人员，保障云上业务正常稳定运行的维护人员。

腾讯云架构工程师认证是针对云解决方案架构师的技能认证，通过该认证，可有效验证是否具备设计中小型云架构的能力，根据业务规划高可用、高安全、成本优化的云架构方案。适用于腾讯云架构设计师，负责分析业务特性，并进行云上业务架构设计的技术人员。

学习方式

您想获得相关认证，需要按照下列步骤操作：

1、在官网认证页面： 完成学生认证。

2、领取相关课程以及实验资源，并学习。

3、获得8折优惠券，报名参与认证考试。

考试时间 90分钟

考试总分 100分

考试题型 60单选 + 20多选 + 不计分测试

通过条件 70分及以上

国产数据库认证考试指南汇总

目前国产数据库绝大多数都是付费认证培训，也有一部分免费认证是限时的，大家可以多多关注国产数据库各官网动态。国产数据库认证考试可参考下方表格：

厂商  等级认证名称培训认证费用

达梦入门DAE认证——达梦助理工程师

达梦初级DM8-DCA认证——达梦认证管理员4800元

达梦中级DM8-DCP认证——达梦认证专家7800元

达梦高级DCM认证——达梦认证大师

PingCAP初级PCTA认证——TiDB认证数据库专员限时免费

PingCAP中级PCTP认证——TiDB认证数据库专家1200元

华为初级HCIA-GaussDB 认证——华为认证GaussDB数据库工程师200USD

华为初级OGCA认证——openGauss初级管理员认证2100元（限时优惠）

华为中级OGCP认证——openGauss中级管理员认证待上线

华为高级OGCE认证——openGauss高级管理员认证待上线

华为中级HCIP-GaussDB-OLAP 认证——华为认证GaussDB OLAP数据库高级工程师300USD

华为中级HCIP-GaussDB-OLTP 认证——华为认证GaussDB OLTP数据库高级工程师300USD

蚂蚁金服初级OBCA 认证——OceanBase 数据库认证专员限时免费

蚂蚁金服中级OBCP 认证——OceanBase 数据库认证专家6000元

阿里云初级ACA认证——阿里云云原生数据库PolarDB助理工程师600元

阿里云中级ACP认证——阿里云云原生数据库PolarDB工程师1200元

阿里云高级ACE认证

腾讯云初级TCA认证—— 腾讯云TBase数据库交付运维初级工程师1200元

腾讯云初级TCA认证—— 腾讯云TDSQL数据库交付运维初级工程师1200元

腾讯云中级TCP认证——腾讯云TBase数据库交付运维工程师1800元

腾讯云中级TCP认证——腾讯云TDSQL数据库交付运维工程师（MySQL/PostgreSQL）1800元

腾讯云高级TCE认证——数据库交付运维级工程师-腾讯云TDSQL（MySQL/PostgreSQL）2400元

人大金仓初级KCA认证200元

人大金仓中级KCA认证200元

人大金仓高级KCM认证待添加

巨杉初级SCDA认证——巨杉数据库助理工程师599元

巨杉中级SCDP认证——巨杉数据库中级工程师1599元

巨杉中级SCDD认证——巨杉数据库开发工程师1599元

云和恩墨初级MGCA1800元

云和恩墨中级MGCP1800元

云和恩墨高级MGCE1800元

 

?点击： 查看国产数据库认证考试指南汇总。??欢迎各位墨友在评论区补充其他国产数据库免费/付费认证，让我们一起学习，一起成长！

 

更多阅读：

《国产数据库认证考试指南汇总》：

《国产数据库考试资料汇总》：

国产数据库

免费

tidb

oceanbase

gbase

最后修改时间：2022-06-16 16:19:17

「喜欢文章，快来给作者赞赏墨值吧」

赞赏

【版权声明】本文为墨天轮用户原创内容，转载时必须标注文章的来源（墨天轮），文章链接，文章作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

评论

惭愧小七

软考（计算机技术与软件专业技术资格（水平）考试），国家级的考试，不存在包过、题库这种情况，很值得考的;

2022-11-26

点赞

回复

严少安

PCTA认证 — 10月起收费

OBCP — 下周开始升级为V3，考试内容和形式都有所变化

2022-07-11

1

2

墨天轮福利君 : 感谢补充！

严少安 : @墨天轮福利君 GBase 还有 GBase 8a 认证

相关阅读

墨天轮2022年度数据库获奖名单

2022年中国数据库排行榜年终盘点

2023年1月中国数据库排行榜：OceanBase 持续两月登顶，前四甲青云直上开新局

2022年墨天轮数据库大调查中奖名单火热出炉！

收官！OceanBase x 墨天轮第五届技术征文大赛获奖名单公布！

PingCAP 合作伙伴学习加速营第四期开始招募啦！

TiDB 荣获日本“你未来想用的数据库”第一名

OceanBase 社区版 4.0 离线方式升级bp1至bp2 指南（含避坑总结）

【DBA100人】白鳝：一直往上走，从程序员到数据库专家

方案精讲丨TiDB 多业务融合方案（上）

对话阿里云李飞飞：关于云原生数据库的五大预判

作者：王慧贤

数据存储、数据分析、数据安全……如今，围绕“数据”的话题越来越多，离人们的生活也越来越近。

从陌生到熟悉，数据不仅“出圈”，甚至已然站在了C位。去年，中央发布的《关于构建更加完善的要素市场化配置体制机制的意见》中明确表示，继土地、劳动力、资本、技术后，数据成为第五大生产要素。

步入信息化时代后，数据库、操作系统与中间件作为计算机最基础的三大软件，支撑着企业的正常运行。

当数据成为生产要素后，必然会迎来爆发式增长，企业的数据存储和处理需求将进一步释放。更重要的是，疫情加快了数字化转型的脚步，更加速了企业的上云速度。

从信息化到数字化，时代的变革，总会带来商业世界的变化。如何在云原生架构下使用数据库，成为企业的痛点和云厂商的机会，亚马逊AWS的CTO Werner Vogels曾多次强调：“数据库是云计算的终极之战。”

在数智化时代，云原生到底意味着什么？云原生数据库和传统数据库相比，核心优势是什么？是否把数据库搬上云就是云原生？基于这些问题，雷锋网与阿里巴巴集团副总裁、阿里云数据库产品事业部负责人李飞飞展开一场对话。

国产云原生数据库，摆脱「切肤之痛」

如今，数据库的商业世界，因为云的出现与发展，分成了两大派系。

一派是以Oracle为代表的传统商用数据库，一派是以国外AWS、国内阿里云为代表的云原生数据库，去“IOE革命”下的产物。

其实，早期较为火热的数据库种类有三种，层次式数据库、网络式数据库和关系型数据库。

在《浪潮之巅》一书中，作者吴军写下了这样的观点：“Oracle 的兴起很大程度上靠的是它最早看到关系型数据库的市场前景，并且在商业模式上优于 IBM。”

因此，在云原生数据库“入世”之前，数据库的天下一直是Oracle的，国内大部分互联网公司都不得不采用Oracle+IBM小型机+EMC的模式来维持正常运营。

高昂的费用，使得对于数据库需求较大的互联网巨头“忍无可忍”。

2009年，阿里巴巴的Oracle RAC 集群节点数达到了创记录的20个。可由于Oracle并没有弹性扩展的功能，只能按照峰值流量购买小型机和数据库，导致阿里将业务上涨带来的大部分利润，都支付给了Oracle。

第二年，阿里便开始走上了去“IOE”之路，根据开源MySQL搭建了AliSQL，并顺利经过了淘宝双11的考验，国产云原生数据库算是正式摆脱了“切肤之痛”，逐渐受到市场的真正认可。

另一边，国外的AWS在2015年公布了基于云计算的自研数据库Amazon Aurora。Aurora是一个关系型数据库，可以跨3个可用区域复制6份数据，其最大的特性就是高性能和高可用性。

云计算巨头的入局，让云原生数据库在国内外一步步成为主流。据Gartner预测，到了2021年，云数据库在整个数据库市场中的占比将首次达到50%，到2023年，75%的数据库都要跑在云平台之上。

关于云原生数据库，随着逐步的出圈，也让人们关心的焦点从“是啥？”转变为“还能解决哪些问题？”

但云原生数据库存在着数据孤岛的问题，无法打通多个数据系统的情况下，企业在数据加工和数据管理上就会“压力较大”，甚至在数据安全方面还存在隐患。

传统数据仓库一般基于T+1数据集成构建离线数仓，以支撑企业各项分析与服务。传统方案不但会影响线上业务稳定性，且难以支持企业的实时需求。

因此，在李飞飞看来，云原生数据库已经走到2.0阶段。这个阶段要解决的问题，就是上述存在的痛点。

9月26日，在阿里云数据库创新上云峰会上，阿里云发布了首个一站式敏捷数据仓库解决方案。该方案结合一站式数据管理平台DMS及云原生数据仓库AnalyticDB（简称：ADB），实现了库仓一体的技术架构，提供在线数据实时入仓、T+1周期性快照、按需建仓等能力，数据延时低至秒级，持续赋能业务在线化，使企业的在线数据可以释放出更大的价值。

相较于传统方案，阿里云一站式敏捷数据仓库解决方案有4大核心优势：

1、对业务侧影响小，不会因为数据汇聚集中和实时加工影响业务侧正常运行，CPU、内存占用低于5%；

2、事务顺序和数据准确性有保障，且处理链路短，支持在线数据实时处理落仓，效率更高。数据传输效率100m/s，数据延时在10秒内；

3、支持复杂实时数据加工、计算逻辑；

4、低代码操作，能够大大降低实时数仓的构建难度，提升构建效率的同时，支撑企业数字化转型过程中的各类实时场景。

除了实时统计分析场景外，企业为满足周期性数据分析需求，需建设周期性全量快照。

传统数仓的周期性全量集成方案会对生产业务造成稳定性影响、全量集成时效性差、且无法满足客户针对任意时间点进行数据回溯的业务诉求。

针对T+1周期性集成场景，一站式敏捷数据仓库解决方案支持基于拉链表的T+1全量数据快照，用户通过简单几个步骤，即可按需生成各种周期的全量或增量快照。

此外，业务还可按需进行任意时间点的数据回溯，以快速解决数据异常问题。

谈起未来数据库的发展趋势，李飞飞提到以下五点：

1、云原生+分布式一定是数据库的标配，分布式已经是必选项。分布式数据库由多个相互连接的数据库组合而成，面向用户则是以单个数据库的形态出现。云原生分布式数据库具备易用性、高扩展性、快速迭代、节约成本等特征，从资源池化到弹性扩展，再到智能运维，再到离在线一体化，解决企业用户的核心诉求。

2、AI for DB（database，指数据库）和 DB for AI 将是主流趋势。用AI将数据库运维管控智能化，尤其在云原生+分布式这个前提下更重要，因为数据库不仅是内核的能力弹性高可用、可拓展性，更重要的是部署后应用和运维的复杂度要大大降低。在数据库里，面对越来越多非结构化的数据，分析能力十分重要。

3、数据的安全可信，在今天这个大环境下变得愈发重要，如何确保整个数据库系统，在处理数据全链路过程中提供加密能力、多方安全计算能力、隐私保护的能力，也是很重要的趋势。

4、多模数据处理能力将越来越重要。比如，新型数据库多模态的处理能力，在新能源 汽车 企业打标签、智能电池化预测等应用场景中，将发挥越来越重要的作用。

5、一份数据，多个数据处理引擎：实现仓库一体、仓库联动、仓库打通，数据之间无缝流转。

以上判断，也从侧面反映出阿里云数据库的走向，这点毋庸置疑。但除此之外，业界最关心的，还有开源。

近半年，国内很多厂商相继提出开源战略，背后缘由显而易见，为了打造生态。就在今年的阿里云峰会上，阿里云智能总裁、达摩院院长张建锋（花名行癫）将2021年阿里云的发展关键词归纳为：做好服务、做深基础、做厚中台、做强生态。

做好服务与生态，成为如今厂商们不约而同的目标，而开源，就是最好的选择。

当雷锋网问到：“未来，阿里云数据库会不会把所有能力都开源？”这一问题时，李飞飞给到的回答是：“不会。”

之所以有这样的回答，是因为对于开源，他有着一些判断和看法。

李飞飞表示，这些部分，本就是阿里云数据库的商业化版本。

事实上，业界大多数的数据库厂商都不会针对自身的核心能力开源，如TiDB的核心管控组件、TiFlash。

与像MongoDB,、Cassandra、CouchDB这些以开源起家的数据库厂商不同，开源只是阿里云数据库的战略，不是阿里云数据库的命脉。

前几年，有业内人士表示，在面向开源时，国产数据库首先需要解决信任以及开源知识产权等问题。“开源会让厂商更加认真思考版权还有专利的问题，事实上，选择开源后，对于数据库厂商提出了更高的要求。”

李飞飞认为，开源只是一种选择，数据库开源成功并不代表着商业化就能够成功，不开源也不能代表厂商不先进。

更准确的说，开源只是一种有效手段。

最终，阿里云数据库希望客户能够通过开源版本把阿里云数据库产品技术快速用起来，并能够参与到技术产品的迭代过程中，在一些高阶能力上，借鉴团队专业能力和阿里云的服务能力，成为良好的商业合作伙伴，这是李飞飞以及阿里云数据库对于开源的一些基本思考。雷锋网雷锋网雷锋网

NewSQL分布式数据库发展策略讨论

作者 石默研

本文对新一代NewSQL分布式数据库发展策略中的普遍困扰进行讨论，包括云原生（Cloud Native）与本地部署(On Premise)、HTAP进展方向、分布式与单机需求等分布式数据库商业与技术发展中难以决策的问题。

1. 困扰

分布式NewSQL数据库近年来蓬勃兴起，其原因显而易见：切中了业务与数据量不断增长的用户对关系型数据库RDBMS需求，这在传统RDBMS到大数据的发展阶段中，有相当一段时间是空白。同时，随着互联网技术的不断发展与普及，用云计算模式满足IT需求似乎已经成为未来 社会 产业互联网发展的明确趋势，也就是说，有一种共识：不久的将来，绝大多数产业的IT服务是从公共的、行业的或者私有的、混合的云计算中心提供的。这一共识又带来了云原生（Cloud Native）概念与技术的兴起，而分布式NewSQL数据库自然也应该是云原生的，这决定了其相当多的产品设计决策应以符合这一趋势为原则。然而，在当今的现实中，满足业务与数据量不断增长的RDBMS需求的用户，与云原生的用户，除了互联网企业外，大多数情况下，并不重合，需要On-Premise部署的用户仍然占有很大比重，这就带来了第一个困扰：云原生（Cloud Native）与本地部署(On Premise)对产品发展要求的矛盾。

另一个困扰，是关于HTAP，即交易与分析混合负载。HTAP是当今非常火的一个概念与技术，在交易库上直接进行分析，而不再是将“数据从交易库搬下来，挪到另一个数据库中去”这样的繁琐过程。可以毫不夸张的说： 历史 上规模性企业IT复杂度的相当一部分，都来自于“搬数据”，这导致了数据采集、实时采集、全增量合并、数据传输、数据加载、数据建模、数据质量、数据标准、企业级元数据管理等繁杂多样的技术环节的产生，导致了企业数据分布、数据流向、数据模型、主数据、基础数据平台、ODS/数据仓库/数据集市、数据治理等复杂的数据架构设计优化领域，导致了由于多系统大规模数据搬迁而带来的如数据交换平台之类的复杂调度工程……。咋眼一看，感觉该企业的数据技术好厉害，相关各领域的技术产品好丰富，技术人员的相关技能也好受欢迎。但如果在交易库就能直接满足分析需求而不影响生产效能的话，这些复杂高级的技术环节不都成了“自己给自己造了一座山，还说自己爬的好辛苦”？然而，现实却是，问题并不这么简单，除了在交易库中进行分析会影响业务效能外，还有很多原因导致这一现象产生：交易库并不需要存储那么长的 历史 数据，而分析往往是需要建立在大量 历史 数据之上的；交易库的模型往往并不适合分析需求，多数情况下需要重要建模，如非常流行且价值不菲的各行业数仓主题模型；用于交易的OLTP数据库与用于分析的OLAP数据库，其技术体系完全不同；以及大型企业已固化的内部业务结构并没有留给交易/分析整合可实施的可行空间……等等。由于， 历史 积累的企业级数据体系相当复杂，HTAP的发明者迄今为止都没有系统表达完全替代数据分析需求、自顶而下重构企业数据体系的架构级策略，而是将产品重点定位在技术优化层面：在交易库上直接完成实时统计分析，满足高并发需求且不影响业务效能；或者是为实时分析统计/查询而建设的数据服务中间平台。然而，即使是暂时没有这种策略性的意向，在面向AP的产品具体研发中，又会发现明确的界限确实不好把握，随着一个个具体功能的不断完善，似乎假以时日，技术上也不是没有完全替代纯OLAP平台的可能性。那么，HTAP究竟如何定位呢？

再者就是规模化的分布式需求，与小规模的单机数据库需求（这里指逻辑上的单机）之间的矛盾：分布式数据库，自然而然是要应对规模化的数据管理需求的，长尾的小规模需求当然不应在产品设计考虑之列，同时，大炮轰苍蝇经常还打不好；然而，分布式NewSQL数据库又应该是云原生的，如果把云原生的业务含义理解为“全自助”，它应该以支持什么样的需求为主呢？现实看来，小规模长尾业务对云原生数据库的需求最起码应该是占据相当大的比重的。显而易见，如果是大规模的数据管理需求，即使是部署在云上，DBPaaS的“全自助”是其核心需求吗？这种规模化的业务，如果是云上的On-Premise又需要做出哪些方面的改变？从互联网与云计算发展的 历史 来看，“云自助”，其最核心的商业动机当然包括给用户侧的运维带来了方便，但更重要的可能是给云服务运营商应对海量长尾客户的安装与运维带来了极大的成本优势。这正如银行的小微及个人消费贷款都要走互联网线上模式，而重客、大客甚至中小企业信贷仍然是以线下为主的策略一样，本质是成本问题，而不是客户方便性问题。于是，矛盾显而易见：分布式是面向规模客户的，起码是中、大型客户，而云原生却有可能、最起码相当一段时间内是要以长尾客户为主要服务对象的。

以上困扰实质上，都涉及到了NewSQL分布式数据库的产品发展策略问题。

2. 讨论

问题是客观而又普遍的，但分析与应对策略往往包含主观因素：人们的一个决定与决策，很多情况下并不由严格推理而来，而是心中已经有一个答案，再来找理由支持它。这里的讨论或许也并不能例外。

首先，来看看Cloud Native与On Premise。云原生本应是数据库即服务，然而目前真正有规模化数据增长需求的NewSQL应用相当多的情况下却是付费On Premise与免费On Premise区别，很多互联网企业的应用也可能只是部署在云基础设施上而已，真正的云原生更多是一些实验性、尝试性的需求。但云原生数据库在公有云、行业云以及大型私有云上已经逐渐在形成一种意识上的共识，其商业前景不可限量。也就是说，未来的数字化转型进程中，产业互联网的数据库部署，会逐渐向云基础设施迁移，长在云上。它可能是公有云，也可能是行业云，也可能是私有云，它们都是被定义为云原生NewSQL数据库的市场范围。当然，肯定还会有相当一部分数据库长在云下，这也不用纠结，将其排除在云原生市场战略目标之外即可，就是说，不需要考虑这部分客户需求对产品规划的影响，因为前一部分的份额已经足够大了。这样看来，以云原生为目标进行产品规划的逻辑没有问题，不过，还是要明确一点：长在云上的数据库是不是一定符合我们对“云原生”的既有理解？这里认为，即使未来，在云上形成了产业互联网数据库市场的主体，需要“全自助”的数据库即服务可能也是以面向长尾客户最为迫切、必不可少并且是核心本质，而对中大型以上的需求，“全自助”的意义相对有限，同时比较而言商业模式的转变或者更关键些。那么，如果是以“长在云上”为市场目标，似乎可以将其定义为“广义的云原生”，同时，只要是“长在云上”，那么“云原生”概念中高弹性、高可用、低成本、快速迭代、存算分离等技术优势也都能方便获得。而对“云原生”策略中“云原生”一词的理解不同，对产品规划决策的影响也应该有所不同：一是目前被认为是On Premise的客户需求，或许也就是未来“云原生”主体市场的需求；二是NewSQL数据库关于云原生服务的产品策划，对用户侧“自助”水平的决策或许可以更灵活实用。高水平自助确实可以减轻客户对IT的依赖程度，但这里认为，云原生与用户自行在云上购买资源进行On-Premise部署相比，最关键的价值在于商业模式的改变，能自助多少，不一定是最重要的，因为成为云服务商后，运营运维的工作只会更多，责任可能会更大，甚至有时连IaaS的运维也需要PaaS服务商兜底。但从一个个客户的本地服务，变成集中化云服务，就已经是本质性的模式转变了。总之，需要就事论事，回到原点，仔细分析后决策，而不是用概念教条的判断，因为概念本身的定义并不见得准确对应实际的业务需求。

再来看看HTAP，对这个问题，正如在其它文章中表达过的一样，本文的观点较为明确。一是随着计算能力与架构的升级，从技术上讲，AP与TP的界限会越来越模糊；另外特别是在云原生的新世界里，数据库的这一特性又犹为重要，因为云原生的重要作用之一就是要让客户尽量摆脱对IT运维的依赖，将越来越多的精力集中到自己的业务发展上来；同时端到端的能力提升对云原生商业模式的贯彻也至关重要（需要仔细分析下目前DBPaaS的技术要求是否完全符合这一原点的、本质性的动力），过去与纯OLAP数据库的优势比较纠结在这里也可以得到正面支持；再者，既然架构上已经走向了AP，就很难做到在产品规划上时刻厘清纯AP与混合负载的需求后，再将前者排除在外。于是，以“混合负载满足部分AP需求”应该是由于投入与阶段性市场策略导致的阶段性产品规划，而长远来讲，以一套技术架构满足大多数需求，应该是云原生NewSQL数据库的追求。

接下来，就是关于规模化分布式与小规模单机需求的矛盾了。现在看来，经过上面的讨论，这一点已经不是什么问题了：因为“长在云上”、从分散服务向集中服务的商业模式转变就是指广义的云原生，而不一定要以小微的、迫切需要全自助的长尾为主流，那么，云原生NewSQL数据库仍然应以规模化分布式为其主体的需求方向，而小规模单机则暂时可以不做为重点来考虑。

最后指出一点，希望也能引发进一步的思考：我们所批判的主机，也声称自己是分布式架构，暂且不论其是否客观，但在现实中主机需要被替代的核心问题并不是有没有分布式，而是：一、扩展不灵活带来成本问题：“我只需要扩展一个节点，你却让我再买一台主机”；二、不自主可控；三、往往是软硬件结合的设计策略，包括内存、网络、存储与IO上的软硬融合设计，而这一点，是否需要云原生数据库从广义的定义出发进行学习参考，也是需要进一步讨论的。

TDSQL TCA 分布式实例特点初探分布表和SQL透传

TDSQL分布式实例通过Proxy接口提供和mysql兼容的连接方式，用户通过IP地址、端口号以及用户名、密码进行连接：

（注意：公有云TDSQL需要在实例页面申请公网连接地址）

连接示例：mysql -h172.21.32.13 （proxy地址） -P3306（proxy端口） -utest （数据库账号） -p

与普通的mysql连接方法一致，分布式实例兼容mysql的协议和语法，支持SSL加密等功能。当然，您也可以使用navicat、 jdbc、 odbc、 php、 Python等来连接分布式TDSQL实例。

1、TDSQL分布式实例支持表的类型介绍

a、分布式表： 即水平拆分表，也成为“分表”，该表从业务视角是一张完整的逻辑表，但后端根据分表键（shardkey）的HASH值将数据分布到不同的物理节点组（SET）中。

b、普通表： 又名Noshard表，即无需拆分的表，和传统集中式数据库中的表一致，且没有做任何特殊处理的表，目前分布式实例将该表默认存放在第一个物理节点组（set）中。

c、广播表： 又名小表广播技术，即设置为广播表后，该表的所有操作都将广播到所有物理节点组（set）中，每个set都有该表的全量数据，常用于业务系统关联查询较多，修改较少的小表或配置表等。

表类型选用注意事项：

在分布式实例中，如果两张表分表键相等，这意味着两张表**相同的分表键对应的行**，存储在相同的物理节点组中。这种场景通常被称为组拆分（groupshard）,会极大的提升业务联合查询等语句的处理效率。由于单表默认放置在第一个set上，如果在分布式实例中建立大的单表，则会导致第一个set的负载太大。除非特别需要，在分布式实例中尽量使用分布式表，这也是分布式实例的特点之一。

2、TDSQL分布式实例表的创建

接下来我们来看下分布式数据库TDSQL所支持的三种类型表的使用方法和注意事项。

a、分布式表的使用

简述：普通的分表创建时必须在最后面**指定分表键（shardkey）的值，该值为表中的一个字段名字，会用于后续sql的路由选择。连接到TDSQL分布式实例后，我们创建一个本次操作使用的数据库名为：testdb

mysql create database testdb;

mysqluse testdb;

接下来我们创建分布式表，命名以分布式拼音首字母命名

**建表语句1：**

MySQL testdb create table fbs ( a int, b int, c char(20),primary key (a),unique key u_1(a,c) ) shardkey=a;

Query OK, 0 rows affected (0.07 sec)

**建表语句2：**

MySQL testdb create table fbs2 ( a int, b int, c char(20), primary key (a,b) ) shardkey=a;

Query OK, 0 rows affected (0.09 sec)

b、广播表的创建

简述：支持建小表（广播表），此时该表在所有set中都是全部数据，这个主要方用于跨set的join操作，同时通过分布式事务保证修改操作的原子性，使得所有set的数据是完全一致的 。

**语句：**

MySQL testdb create table gbb(a int,b int key) **shardkey=noshardkey_allset;**

Query OK, 0 rows affected (0.03 sec)

c、传统普通表

简述：支持建立普通的表，语法和传统mysql完全一样，此时该表的数据全量存在第一个set节点中，所有该类型的表都放在第一个set中。

MySQL testdb create table ptb(a int ,b varchar(10));

Query OK, 0 rows affected (0.03 sec)

注意事项：

1、在分布式实例中，分布式表shardkey对应后端数据库的分区字段，因此必须是主键以及所有唯一索引的一部分， 否则可能无法完成建表操作。

2、分布式表shardkey字段的值不包含中文, 否则proxy会转换字符集可能会出错。另外SQL语法上如：shardkey=a 一般放在SQL语句最后来写。

3、TDSQL分布式实例表的数据操作

为了更好的发挥分布式架构的优势，在进行SQL操作时和传统数据库还是有部分差异。接下来我们从数据库的插入，更新，删除方面分别来看有哪些注意事项。

======INSERT插入操作=======

**插入语句1：**

MySQL testdb insert into fbs(a,b) values(10,1000);

Query OK, 1 row affected (0.00 sec)

**插入语句2：**

MySQL testdb insert into fbs values(1,10,1000);

或

MySQL testdb insert into test1 (b,c) values(100,”record3″);

ERROR 810 (HY000): Proxy ERROR:sql is too complex,need to send to only noshard table.Shard table insert must has field spec

注意：语句2报错的原因insert时字段需要包含shardkey，否则会拒绝执行该sql，因为Proxy不知道该sql发往哪个后端分片节点。

=====UPDATE、DELETE更新、删除操作=====

更新语句1：

MySQL testdb update fbs set b=2000 where a=10;

Query OK, 1 row affected (0.00 sec)

更新语句2：

MySQL testdb update fbs set b=2000 ;

ERROR 658 (HY000): Proxy ERROR: Join internal error: update query has no where clause

删除操作：

MySQL testdb delete from fbs;

ERROR 913 (HY000): Proxy ERROR:Join internal error: delete query has no where clause

注意事项：

1、出于数据操作安全上和减少人为误操作导致数据丢失情况的出现，TDSQL禁止update 无 where 条件的更新动作。

2、同样的delete操作无where条件也会被禁止执行，如果确认要删除表数据或表，建议备份后用truncate或drop方式操作。

3、同样的update操作时尽量避免更新shardkey字段，因为影响Proxy中的路由更新，会导致错误。

1、TDSQL透传功能介绍

对于分布式实例，会对SQL进行语法解析，有一定的限制，如果用户想在某个set中获取单个节点数据，或在指定节点执行SQL，可以使用TDSQL的透传SQL的功能。

使用透传功能，我们需要重新连接登录TDSQL分布式实例时指定 **- c选项**。普通登录方式，不支持指定节点执行SQL的透传功能。

登录如下：

mysql -h172.21.32.13 （proxy地址） -utest -P3306 -p -c(透传必须指定-c)

2、TDSQL透传操作演示

首先我们重新登陆TDSQL分布式实例： mysql -h172.21.32.13 -utest -P3306 -p -c

仍旧切换使用testdb数据库。

a、查看分布式实例set节点

使用/*proxy*/show status 查看当前的TDSQL分布式实例的节点信息，共有两个set ，分别为set_1605181898_1、set_1605181972_3

MySQL testdb /*proxy*/show status ;

+—————————–+——————————————————————-+

| status_name | value |

+—————————–+——————————————————————-+

| cluster | group_1605181791_302290 |

| **set_1605181898_1:ip | 10.53.179.14:4322;s1@10.53.178.227:4322@1@IDC_GZ_YDSS0301_79263@0 |

| set_1605181898_1:hash_range | 0—31 |

| **set_1605181972_3:ip | 10.53.179.14:4323;s1@10.53.178.227:4323@1@IDC_GZ_YDSS0301_79263@0 |

| set_1605181972_3:hash_range | 32—63 |

| set | set_1605181898_1,set_1605181972_3 |

+—————————–+——————————————————————-+

6 rows in set (0.00 sec)

b、演示数据插入

我们针对之前创建的fbs分布式表进行数据的插入

MySQL testdb insert into fbs(a,b,c) values(10,1,’AAA’),(20,2,’bbb’),(30,3,’ccc’),(40,4,’dddd’),(50,5,’eee’),(60,6,’fff’),(70,7,’ggg’),(80,8,’hhhh’);

MySQL testdb select * from fbs order by 1;

+—-+——+——+

| a | b | c |

+—-+——+——+

| 10 | 1 | AAA |

| 20 | 2 | bbb |

| 30 | 3 | ccc |

| 40 | 4 | dddd |

| 50 | 5 | eee |

| 60 | 6 | fff |

| 70 | 7 | ggg |

| 80 | 8 | hhhh |

+—-+——+——+

8 rows in set (0.00 sec)

c、透传查看数据在各个节点的分布情况

MySQL testdb /*proxy*/show status;

+—————————–+——————————————————————-+

| status_name | value |

+—————————–+——————————————————————-+

| cluster | group_1605181791_302290 |

| **set_1605181898_1:ip | 10.53.179.14:4322;s1@10.53.178.227:4322@1@IDC_GZ_YDSS0301_79263@0 |

| set_1605181898_1:hash_range | 0—31 |

| set_1605181972_3:ip | 10.53.179.14:4323;s1@10.53.178.227:4323@1@IDC_GZ_YDSS0301_79263@0 |

| set_1605181972_3:hash_range | 32—63 |

| set | set_1605181898_1,set_1605181972_3 |

+—————————–+——————————————————————-+

6 rows in set (0.00 sec)

查看数据在set_1605181898_1 节点上的分布

MySQL testdb /*sets:set_1605181898_1*/select * from fbs order by 1;

+—-+——+——+——————+

| a | b | c | info |

+—-+——+——+——————+

| 10 | 1 | AAA | set_1605181898_1 |

| 30 | 3 | ccc | set_1605181898_1 |

| 40 | 4 | dddd | set_1605181898_1 |

| 50 | 5 | eee | set_1605181898_1 |

| 80 | 8 | hhhh | set_1605181898_1 |

+—-+——+——+——————+

5 rows in set (0.00 sec)

查看数据在set_1605181972_3节点上的分布

MySQL testdb /*sets:set_1605181972_3*/select * from fbs order by 1;

+—-+——+——+——————+

| a | b | c | info |

+—-+——+——+——————+

| 20 | 2 | bbb | set_1605181972_3 |

| 60 | 6 | fff | set_1605181972_3 |

| 70 | 7 | ggg | set_1605181972_3 |

+—-+——+——+——————+

3 rows in set (0.00 sec)

d、通过shardkey分片号查看数据

MySQL testdb /*shardkey:2*/select * from fbs order by 1;

+—-+——+——+

| a | b | c |

+—-+——+——+

| 20 | 2 | bbb |

| 60 | 6 | fff |

| 70 | 7 | ggg |

+—-+——+——+

3 rows in set (0.00 sec)

支持透传种类和格式：

1、set名字可以通过/*proxy*/show status查询

2、/*sets:set_1名称*/ 透传指定节点

3、/*sets:allsets*/ 透传所有节点

4、/*shardkey:10*/ 透传到shardkey分片对应的set

5、支持透传sql到对应的一个或者多个set

分布式表的DDL部分的语句限制：

暂不支持CREATE TABLE … LIKE

暂不支持CREATE TABLE … SELECT

暂不支持CREATE TEMPORARY TABLE

暂不支持CREATE/DROP/ALTER SERVER/LOGFILE GROUP/

暂不支持ALTER对分表键(shardkey)进行重命名，不过可以修改类型

分布式表的DML部分的语句限制：

暂不支持SELECT INTO OUTFILE/INTO DUMPFILE/INTO LOAD DATA导出

暂不支持INSERT … SELECT

暂不支持UPDATE 分布式shardkey列的值

本操作主要是面向传统数据库的开发者或者DBA用户，让大家能够初步入手了解分布式数据库的特点。另外分布式数据库在架构上提供了灵活的读写分离模式，在SQL上支持全局的order by， group by， limit操作，支持聚合函数，跨set节点的join、子查询、支持分布式事务，传统数据库所支持的大部分操作在分布式数据库中得到继承。分布式数据库是在传统数据库的基础之上发展起来的，对传统集中式的数据库有较好的兼容性，对SQL语句语法的使用上兼容大部分SQL1999,SQL2003标准，且对SQL的ACID特性都予以支持。分布式数据库在逻辑上是一个独立完整的数据库，但在架构上和物理上采用 多节点分片方式，经过内部算法将数据打散分布来到不同节点存储数据，对前端业务屏蔽后端的复杂架构，并且自身具备数据的最终一致性访问，可用性和分区容灾等特性的数据库。希望本次操作能给大家带来一些对分布式数据库TDSQL的一些认识和收获。

*禁止转载，可转发（转发文章请注明出处）

TDPub企业级分布式关系数据库

本文来源：https://www.yuntue.com/post/104707.html | 云服务器网，转载请注明出处！