在“国产数据库硬核技术沙龙 -TDSQL- A 技术揭秘”系列分享中，5 位腾讯云技术大咖别离从整体技术架构、列式存储及相干执行优化、集群数据交互总线、分布式执行框架以及向量化执行引擎等多方面对 TDSQL- A 进行了深刻解读。
在本系列分享的最初一期，咱们整顿了对于 TDSQL- A 大家最关怀的十个问题，腾讯云技术大咖们将对这些问题一一解答。
TDSQL- A 是腾讯首款分布式剖析型数据库引擎，采纳全并行无共享架构，具备自研列式存储引擎，反对行列混合存储，适应于海量 OLAP 关联剖析查问场景。它可能反对 2000 台物理服务器以上的集群规模，存储容量能达到单数据库实例百 P 级。
Q1: TDSQL- A 目前有哪些用户在应用？
TDSQL- A 是随同腾讯本身业务倒退过程中衍生进去的产品，在腾讯外部有十分宽泛的利用，像腾讯广告、QQ 音乐外围业务都在应用 TDSQL-A。
Q2: TDSQL- A 的次要劣势是什么？
TDSQL- A 的次要劣势在于，它是一个分布式的超大规模数据仓库集群，其利用场景次要面向超大规模数据汇合的高速计算，在达到数千台服务器单个数据库集群超大规模的同时，还能做到高效的查问的执行。
Q3: TDSQL- A 在反对国产化硬件和操作系统方面做了哪些工作？
近年来，随着国家芯创事业的推动，以及自主研发的硬件和软件的大规模利用，TDSQL- A 也始终在做相干的适配工作。在国产化硬件方面，像鲲鹏、海光等支流国产化芯片，咱们都做了很好的反对。在国产操作系统方面，咱们也通过了一系列支流厂家的认证。
Q4: TDSQL- A 是否反对强同步复制？
在 PostgreSQL 流程中，事务在提交前会记录 WAL 日志。对于行存表和列存表，咱们都有对应的 WAL 日志去反对主备间的流式复制，用户还能够抉择具体的复制级别或者是复制的同步配置。用户能够依据不同场景去抉择是否须要高级别或者偏低级别的主备同步级别。另外，TDSQL- A 也反对 Hot Standby，即备立体可读。这些都能够通过 TDSQL- A 的管控平台来进行便捷的配置。
Q5: TDSQL- A 如何进行高效的分布式 Join？
这次要波及到优化器、执行器、向量化等多个方面。咱们以优化器为例。如果是带有 CTE 或者子查问比拟多的简单查问，TDSQL- A 优化器会首先进行查问重写 (rewrite)，把 CTE 进行 inline 操作，随后尽量把子查问晋升成 Join 来进行优化。这样做能够升高查问的执行复杂度，如果是特定查问甚至可能达到成千盈百倍的晋升。
Rewrite 之后，优化器还会主动对 Join 的程序进行调整，相当于进行一个全面的遍历，而后去抉择一个最优执行代价的打算。在分布式场景下，咱们做了很多优化。比方 Join 关联的列是否是数据分布列，是否须要进行重散布，是否增加提早物化算子，TDSQL- A 会智能地依据 cost 来进行调整。
另外，在物理算子抉择时，依据不同的场景、选择率、代价评估，TDSQL- A 会抉择不同的关联算法，比方 Nestloop join、HashJoin、MergeJoin。同时 TDSQL- A 还反对全流程的并行执行和向量化执行，以此来保障整体的高效的分布式 Join 计算能力。
Q6: TDSQL- A 目前反对哪些算子？其算子级别的并行能力又在哪些方面失去加强？
咱们基于 PG 10 对 TDSQL- A 做了很多自研和性能加强。因为 PG 10 自身在并行能力上存在欠缺，比方像 Hash Join 反对表面的并行，但像 Build Hash Table 就不反对并行。为了补救欠缺，咱们基于 PG 10 开发了实现的 Hash Join 的并行来同时反对 Inner/Outer Plan 的并行。
另外就是聚合算子。因为很多分布式场景须要进行两阶段的聚合计算。这种两阶段聚合可能会在两头进行数据重散布，对于这种状况咱们也须要反对残缺的并行能力。TDSQL- A 会依据聚合的列去做一个 hash 的计算, 来抉择在哪个 work 上计算，同时在不同的执行分片之间进行绑定，保障不同的分片执行时，它的不同并行过程之间能够收到正确的数据而后做并行计算。TDSQL- A 还反对一些其它的算子，前面咱们会一直去更新。
Q7: TDSQL- A 是否能够间接拜访包含 Oracle 在内的内部数据源？
Oracle 以及 Hive/Spark 等大数据我的项目对接是比拟宽泛的利用场景。针对 Oracle 兼容和国产数据库替换，咱们做了很多兼容性能力加强方面的工作。另外用户能够间接在 TDSQL- A 中用 dblink 来间接拜访 Oracle 内部数据源，去做数据变更或者做查问。像 Hive 或者其余的第三方数据源，PG 有 Foreign Data Wrapper 这样的接口。用户能够应用咱们反对的插件或者适配丰盛的第三方插件来拜访异构内部数据源。
如果须要把数据拉到 TDSQL- A 来，咱们能够用 TDSQL- A 配套的数据导入工具 TDX 去进行数据导入。实际上咱们会有比拟丰盛的协定，能够通过不同的内部数据源，把数据流导到 TDX 下面。数据库会并行地从 TDX 往 DN 节点进行数据抽取，这样能够拜访内部数据源，也能够享受数据加载的便捷服务。
Q8: TDSQL- A 是否疾速把数据导入到数据库系统里？是否能与其余零碎进行数据交互？
TDSQL- A 反对在 PG 数据源上进行 copy，能够将数据 copy in、copy from，同时还反对表面定义，咱们能够去创立内部表，间接把内部的数据文件在数据库里进行定义，从而进行一些操作。同时，咱们还反对 DB bridge——云上的数据同步工具，它能够实时同步其余零碎的数据进来，而后再通过 Kafka 同步进来。此外，咱们还开发了一个专门的数据导入导出工具 TDX，它能够借助多 DN 并行高效地进行数据导入导出。
Q9: TDSQL- A 目前最多能反对多少个节点的部署？
在 TDSQL- A 中，部署节点数量是一个配置参数，在一开始初装时就能够进行配置，默认值为 2048，具体能够依据用户须要进行调整。
Q10: 大规模部署时，FN 如何保障通信更高效？
咱们先来假如在没有 FN 的状况下，因为零碎集群规模比拟大，集群内又在不停地创立连贯，这样就会导致整个零碎网络的 socket 数量成为瓶颈。这也是咱们引入 FN 数据交互总线的初衷，用来无效缩小连贯数量。通过 FN 节点，具体计算过程不须要间接进行全链接，而是通过 FN 节点进行数据路由，极大的缩小了 socket 连接数。
FN 如何保障高效性，这个问题能够从两方面来答复。一方面，在同一个服务器外部，FN 通过共享内存间接获取数据，实际上省了网络这一层，因而它的通信是比拟高效的。另一方面，在不同服务器之间，FN 次要负责数据的发送，其外部是一个多线程的模型，能够存在很多个发送线程。FN 外部还有一个 Merge 线程，它的作用是在一个数据发送之前，会查看哪个发送线程的队列比拟闲暇，而后把这个数据调度到这个闲暇的发送线程中，从而达到简单均能的成果。