实时数据引擎系列(五): 关于 SQL Server 与 SQL Server CDC

 

摘要：在企业客户里, SQL Server 在传统的制造业依然散发着持久的生命力，SQL Server 的 CDC 复杂度相比 Oracle 较低, 因此标准的官方派做法就是直接使用这个 CDC 接口进行同步，但江湖上也有通过裸解析 ldf 文件来直接读取数据库变更，本文将就这两大门派展开探讨。

 

前言

上次发的关于Oracle CDC 的文章反响不错, 而像这种类型的数据库还有好几个, 这里把三大闭源数据库先讲一遍: Oracle, SQL Server 和 DB2。

 

在企业客户里, SQL Server 的使用范围远远超过我之前的预期, 这个在互联网用户那边几乎见不到的数据库, 在传统的制造业, 企业客户里依然散发着持久的生命力, 在 DB Engine 的排名里, SQL Server 仅次于 Oracle 与 Mysql, 排在第三, 是TAPDATA 在客户场景落地的时候经常碰见的数据库之一。

 

两大门派

SQL Server 的 CDC 复杂度相比 Oracle 较低, 且官方从 08 版本就天然支持这个功能, 只是在 16 版本之前, 这个设置只有在企业版才有, 在 16 版本之后, 在社区版也可以开启功能, 因此标准的官方派做法就是直接使用这个 CDC 接口进行同步。

 

在开启 CDC 功能之后, SQL Server 会将变更的内容同步到一张表中, 有主键, 业务方通过轮询这张带主键的表拿到新的事务变更。

 

这是最好实现的方案之一, 问题有好几个:

1. 08 版本之前不支持。
2. 16 版本之前只支持企业版。
3. 依靠轮询, 实时性较差, 且 CDC 表本身也存在延迟, 正常情况下的延迟往往超过秒级。
4. 如果忘记从表中取走数据, 这张表会无限膨胀。
5. 被取走的数据会被清理, 无法回放日志。
6. 配置复杂, 需要考虑 ALWAYSON 的情况下, 可用节点切换的 CDC 作业恢复的触发等配置。

 

SQL Server 在进行事务操作时, 会将操作记录在以 ldf 结尾的文件中, 因此江湖中各路草莽瞄准了这一点, 也开发了属于自己的数据追踪套路。

 

有很多做操作审计, 或者数据同步的厂商开始尝试绕过 CDC, 通过裸解析 ldf 文件来直接读取数据库变更, 具有的优势是:

1. 负载与数据库分开, 性能可单独优化, 速度很快, 瓶颈在 IO 上。
2. 可屏蔽各种部署结构带来的差异, ldf 文件是永恒的。
3. 事件触发, 相比轮询 CDC 表, 消息延迟很低, 可以在几十毫秒内。

 

劣势是增加了部署复杂度, 需要在数据库机器上部署一个单独的 Agent 用来做日志的采集, 且需要自行考虑高可用切换时 Agent 传输日志的问题。

 

相比 Oracle 多样的版本, 和完全无法捉摸的二进制格式, SQL Server 的解析较为简单, 业界实现的各种商业产品也非常多, 不过目前没有看到在 Linux 下可用的版本, 也没有看到开源的实现出现。

 

TAPDATA 的解法

在默认情况下, TAPDATA 使用了轮询 CDC 增量表的方式进行数据获取, 这种方式对用户使用比较友好, 不需要额外部署服务, 同时, 支持 ALWAYSON 的自动切换, CDC 任务的自动恢复等高可用特性, 方便易上手。

 

在数据量非常大, CDC Table 性能不足, 或者客户对 CDC 延时有极高要求时, TAPDATA 可以通过 Agent 传输 + 裸日志文件解析的形式, 在获得数倍于传统方式性能的同时, 有效降低了延迟

 

一个小问题

Oracle 日志解析因为比较困难, 开源项目比较少, SQL Server 相对来说内容少很多, 而且 Google 一下有大量的商业软件在基于裸日志解析做一些审计, 观察, 同步的事情, 为什么依然看不到像样的开源项目呢?

 

进一步了解Tapdata 实时数据服务平台，更多技术文章可前往 Tapdata 技术博客。Tapdata 自研的异构数据库实时同步工具—— Tapdata Cloud ，现已免费开放给技术开发者使用，目前支持 Oracle、MySQL、PostgreSQL、SQL Server、MongoDB、Elasticsearch 、达梦、Kafka等主流库之间的数据迁移和同步，即将支持 DB2、Sybase ASE、Redis、GBase、GaussDB 等。

 

本文作者：Tapdata 技术合伙人肖贝贝，源文地址。