本文目录：
- 1、“去IOE”7年 银行IT架构国产化还需多久？
- 2、NewSQL分布式数据库发展策略讨论
- 3、腾讯云安全运营中心2.0对云服务器能带来什么
- 4、对话阿里云李飞飞：关于云原生数据库的五大预判
- 5、TDSQL TCA 分布式实例特点初探分布表和SQL透传
“去IOE”7年 银行IT架构国产化还需多久？
7月底，农行（601288.SH）宣告成立金融 科技 子公司农银金融 科技 有限责任公司，注册资本6亿。目前已有11家银行成立金融 科技 子公司，包括五家国有大行、五家股份行和一家城商行。新一家金融 科技 子公司的成立振奋市场，而国内银行金融 科技 是否能够与国际抗衡，是否能完成“进口替代”的话题再次浮出水面。
长久以来，IOE技术架构是银行业的标准配置和唯一选择，而在2013年之后，由于金融系统IT架构定价权和 游戏 规则控制在海外厂商手中，并且随着移动互联网的普及，高频交易让传统系统不堪重负，银行业也开始艰难谋求去IOE。
时隔7年，在金融 科技 助推下，银行们通过自我研发去IOE仍在进行中，也有银行依靠互联网等外部力量以求快速实现IT架构国产化。
银行业去IOE始于2013年左右。图 站酷海洛
IOE，分别指IBM（国际商用机器公司）、Oracle（甲骨文）和EMC（易安信），三者分别是小型机、数据库和高端存储的领导厂商，一定程度上主导了企业的IT架构。它们组成的系统一度被视为大型金融企业后台的“黄金架构”。
中国银行业自上世纪90年代开始逐步实现电子化，陆续采用数据、操作、应用大集中的管理模式，即数据中心大集中时代，以革除各家分支行各自为政的弊病，实现网点和业务的数据集中。而IBM以其强大的数据处理能力，装机量在国内一枝独秀。
当时，各类银行争相引进海外业务系统产品，实现流程改造和管理方式改革。
银行业去IOE始于2013年左右。
一直以来，由于银行业采用IOE为代表的IT基础体系，使得如此重要的金融机构IT整体都处于海外厂商的控制之中。可想而知，如若存在技术漏洞，或被主动植入漏洞，或者是国与国之间产生矛盾，供应商被要求停止技术服务，则金融业暴露在安全风险之中。
因此，国家层面基于金融与信息安全的导向推动提出了去IOE的想法，2012年6月国务院发布《关于大力推进信息化发展和切实保障信息安全若干意见》（国发〔2012〕23号），金融监管部门也期望银行逐年减轻对IOE的依赖程度。
尽管去IOE化在2014年、2015年就成为了金融 科技 领域的热门话题，但是它的进展速度显然没有它的热度上得快。
广发证券研报显示，去IOE在开始几年在传统银行间开展得并不顺利。
主要原因包括：第一，大型银行当前集中处理的业务模式对于服务器的稳定性要求极高。而IBM大型机/小型机的稳定性无人能及。其次，中小银行采用开放式平台架构，可以不用IBM服务器。但国产设备的性能、安全性、稳定性一直难以被信任。此外，服务器、存储、操作系统、数据库等基础设施层次相互依赖，难以单一替换。因此，过去5-10年，难以真正意义上撼动海外厂商在国内银行业的地位。
金融壹账通总经理助理、Gamma平台CEO区海鹰在接受媒体采访时对21世纪经济报道记者表示，去IOE仍是银行业头疼的问题。“因为金融是国家与 社会 最重要的一个稳定因素，银行业内部使用的技术中IOE占比非常高，如何去IOE对于银行业来说是一个非常大的挑战。”
区海鹰表示，去IOE只能“小步慢走”式迁移，而且这个工作量非常大。应用层、硬件层迁移已经非常耗费精力，而底层的改变要用到全部国产的服务器、网络，难度可想而知，“估计这个改造本身就是5-10年的工作”。
2019年10月，中国互联网金融协会发布的《中国商业银行数字化转型调查研究报告》显示，参与调研的75%的银行已经或正在启动数字化转型。这其中，不少银行通过自行研发实现了国产化架构支撑关键业务。
据微众银行年报披露，截至2018年底，微众银行已建成229个关键系统，1202个子系统。依靠分布式架构及开源技术的深度应用，行内系统成功支持了年内亿级客户量、亿级日交易量，达到国有大型银行同等规模。与此同时，行内账户运维成本持续下降45%。
今年5月，陆金所也宣布去“O”已经完成95%，预计到今年中实现开源数据库的完全替代。陆金所选择了MySQL的开放式架构作为Oracle核心数据库的替代方案。经测算，完全“去O”之后，系统软硬件成本将节约近90%。
如果说，微众银行等互联网银行实现去IOE更为轻车熟路，那么更多的银行通过外部合作，来降低对海外厂商的依赖，近年来尤其实现提速。
2019年5月，华为正式面向全球推出了GaussDB数据库，其GaussDB OLTP数据库已在招商银行综合支付交易系统成功上线投产，也已在工商银行内上线投产。同月，达梦发布DM8.0，10月23日，该新核心系统所引入的达梦数据库正式通过湖北银行项目方的验收。
去年10月，蚂蚁金服OceanBase登顶TPC-C，这是国产数据库首破OLTP的benchmark世界纪录。OceanBase落地西安银行，西安银行完成实施互联网金融业务平台MySQL数据库、互联网交易资金存管平台Oracle数据库向OceanBase分布式数据库的完整迁移。同月，中兴GoldenDB成功帮助中信银行替换DB2，换“心”后的中信银行信用卡核心交易系统对外投产，这是全国性股份制商业银行的首例。11月，腾讯宣布开源TBase数据库，TDSQL数据库落地张家港农商银行新一代核心业务系统。
对于互联网金融公司和银行的 科技 子公司在去IOE领域的竞争，一位金融 科技 业内人士认为，互联网 科技 公司的 科技 创新能力确实非常强，而且也有很大的服务C端用户的规模。银行业尤其是大行金融 科技 子公司从纯技术的角度与互联网公司旗鼓相当，但是互联网公司本身自带流量，具有很大的优势。
但上述人士坦言，数据库市场被国外厂商垄断，自研企业实力与Oracle仍有一定差距。智研咨询发布的《2020-2026年中国数据库市场深度分析及未来发展前景预测报告》显示：2018年我国数据库软件市场规模为139.25亿元，其中，关系型数据库规模约118.36，占比约85%。Oracle数据库关系型数据库市场份额超过46%，占数据库市场约39.1%。
国产数据库方面，既有传统大学成立的数据库企业，包括人大金仓、武汉达梦、神舟通用、南大通用、山东瀚高等，也有近几年主要以阿里、腾讯、华为为代表的企业研发也加快了追赶脚步。
从国产数据库的技术来源看，国产关系型数据库多源自或者借鉴开源MySQL、PostgreSQL等数据库及其变种，或收购商业源码（例如Informix）+自研的方式，大数据平台多源自或直接整合开源大数据生态组件，纯自研的国产数据库较少，数据库种类不够丰富，核心竞争力亟待突破。
更多内容请下载21 财经 APP
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上的软硬融合设计，而这一点，是否需要云原生数据库从广义的定义出发进行学习参考，也是需要进一步讨论的。
腾讯云安全运营中心2.0对云服务器能带来什么
随着产业互联网时代各行业数字化转型的逐步深入，用户有越来越多的业务依托公有云承载。公有云为用户构建数字化业务带来了极大便利和效率提升，但同时也对用户安全体系的建设带来了新的挑战。根据咨询机构的调查显示，公有云上安全事件发生的原因主要有用户不当的云配置以及云上的不当操作行为和越权操作。用户在公有云上除了需要应对外部威胁外，也需要做好自身的安全配置及云上操作的管理，防患于未然。
基于用户面临的云上安全挑战，腾讯安全即将发布腾讯云安全运营中心2.0，在原有安全运营中心的安全事件管理、泄漏监测及安全大屏等功能基础上新增资产安全中心、安全配置管理、云上用户行为智能分析、合规管理及安全评分等功能，帮助用户实现更全面的安全风险监测和一站式的自动化安全运营，提升用户在公有云上的整体安全水平。
安全评分
安全运营中心全新发布安全评分功能。基于安全运营中心的云上安全数据湖，从安全事件、漏洞及云安全配置风险等维度对云上安全情况进行整体评分，帮助云上用户直观了解自身腾讯云上业务的整体安全态势。
统一云上资产安全中心
资产安全运营是安全运营的基础。安全运营中心全新发布资产安全中心，实现12类云上资产的统一安全管理，涉及云服务器CVM、负载均衡LB、MySQL数据库、TDSQL数据库、Redis数据库、对象存储COS、云硬盘CBS及SSL证书等。资产安全中心可基于安全运营视角，从配置风险、漏洞及安全事件等角度对资产安全风险进行定位和管理，实现面向云资产的安全运营管理。针对云服务器，资产安全中心提供统一的漏洞运营平台，结合腾讯安全云鼎实验室提供的关键漏洞预警能力，帮助用户提升漏洞应对能力。
自动化云安全配置检查
针对云上各类型资产的配置风险，安全运营中心基于腾讯自身安全实践，为用户提供云原生的资产配置风险检查功能。从基础安全防护、身份认证与权限、网络访问控制、数据安全、日志审计及监控告警等维度，对云上12类资产进行自动化的配置风险检查；针对发现的风险问题提供相应的处置建议和快速修复方式，从源头提升云上风险应对水平。
云上用户行为智能分析（预览）
除了外部攻击及自身配置风险外，公有云业务面临的另一大安全风险来自于云上业务运营中的异常行为与风险操作。安全运营中心的Cloud UBA功能模块通过可视化、统计分析和异常检测等方式可对用户在公有云上的操作行为进行智能分析，识别安全风险。一方面，通过对操作路径、操作的云资源、操作行为、以及用户登录趋势等的统计与可视化呈现，帮助安全管理人员高效、直观地掌握云资源操作情况；另一方面，通过对云上的操作行为进行异常检测与动态风险评估，实现云上操作行为的风险智能化识别。
持续自动化的合规评估（预览）
合规是用户上云的基本安全要求。安全运营中心可为云上用户提供云原生的安全合规评估功能。针对用户公有云上的安全措施及安全体系建设情况，结合安全合规要求，安全运营中心通过自动化地、持续性地监测、评估来帮助用户实现云上业务的安全合规。目前已经覆盖了等级保护2.0标准中的部分安全通用要求及云计算安全扩展要求，并提供相应的解决方案建议，后续腾讯云将逐步提高对各类合规标准的覆盖。
对话阿里云李飞飞：关于云原生数据库的五大预判
作者：王慧贤
数据存储、数据分析、数据安全......如今，围绕“数据”的话题越来越多，离人们的生活也越来越近。
从陌生到熟悉，数据不仅“出圈”，甚至已然站在了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这些以开源起家的数据库厂商不同，开源只是阿里云数据库的战略，不是阿里云数据库的命脉。
前几年，有业内人士表示，在面向开源时，国产数据库首先需要解决信任以及开源知识产权等问题。“开源会让厂商更加认真思考版权还有专利的问题，事实上，选择开源后，对于数据库厂商提出了更高的要求。”
李飞飞认为，开源只是一种选择，数据库开源成功并不代表着商业化就能够成功，不开源也不能代表厂商不先进。
更准确的说，开源只是一种有效手段。
最终，阿里云数据库希望客户能够通过开源版本把阿里云数据库产品技术快速用起来，并能够参与到技术产品的迭代过程中，在一些高阶能力上，借鉴团队专业能力和阿里云的服务能力，成为良好的商业合作伙伴，这是李飞飞以及阿里云数据库对于开源的一些基本思考。雷锋网雷锋网雷锋网
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企业级分布式关系数据库
【云原生数据库TDSQL-C】的内容来源于互联网，如引用不当，请联系我们修改。
网友留言：