Redpanda Connect 实战Microsoft SQL Server CDC 组件吞吐基准测试完全指南【免费下载链接】connectFancy stream processing made operationally mundane项目地址: https://gitcode.com/GitHub_Trending/con/connect导读本文聚焦 Redpanda Connect本项目内部实现位于internal/impl/mssqlserver/中microsoft_sql_server_cdc输入组件的端到端吞吐量基准测试方法。你将学会如何在本机用 Docker 拉起 Azure SQL Edge、用 SQL 脚本构造接近生产的数据集含 1000 万行大表、用内置benchmark处理器以msg/sec与MB/sec两个维度观测 CDC 读取吞吐并通过 checkpoint 缓存清理实现多轮可复现的对比实验。文章同时结合仓库中的基准测试套件源码与已记录的历史结果解释瓶颈在 SQL Server 单连接读取而非 Connect 本身这一核心结论的来龙去脉。1. 基准测试背景测什么、为什么测Redpanda Connect 的 SQL Server CDC 输入组件通过轮询 SQL Server 的 change tables变更表消费 Change Data Capture 事件可选的stream_snapshot模式还会把表中的存量数据一并流式读出。基准测试benchmark要回答的问题非常具体这个组件在真实数据集下能达到多少 msg/sec 和 MB/sec瓶颈在组件自身还是上游数据库因此每个需要基准测试的组件都会在实现包内拥有一个自包含的bench/目录完全遵循 docs/benchmarking.md 中定义的统一规范internal/impl/component/bench/ ├── README.md # 运行方法、前置条件、预期输出 ├── Taskfile.yaml # 基于 Task 的任务编排 ├── benchmark_config.yaml # Redpanda Connect 管道配置 ├── create.sql # 建库/建表/开启 CDC 脚本 ├── users.sql # 数据生成脚本 ├── products.sql └── cart.sqlSQL Server CDC 基准套件的完整文件即位于 internal/impl/mssqlserver/bench/ 目录后续所有命令均以该目录为执行上下文。前置说明microsoft_sql_server_cdc是 Redpanda 企业版Enterprise功能输入组件在 input_mssqlserver_cdc.go 中注册受 internal/license 的许可机制管控运行基准前请确认环境具备相应许可证。2. 前置条件与测试环境搭建2.1 安装 sqlcmd本地需要sqlcmd命令行工具来执行 SQL 脚本。macOS 上使用 Homebrew 安装brew install sqlcmdLinux 用户可从微软官方渠道安装mssql-tools含 sqlcmd本文档仓库内基准套件的 Taskfile 默认按sqlcmd已在 PATH 中设计。2.2 启动 SQL Server 容器Taskfile.yaml 提供了容器生命周期管理的全部任务。启动容器task sqlserver:up该任务对应的实际命令为docker run -d \ --name sqlserver \ -e ACCEPT_EULAY \ -e MSSQL_SA_PASSWORDYourStrong!Passw0rd \ -e MSSQL_AGENT_ENABLEDtrue \ -p 1433:1433 \ mcr.microsoft.com/azure-sql-edge参数说明ACCEPT_EULAY接受微软最终用户许可协议必须显式设置MSSQL_SA_PASSWORDsa 账号密码仓库脚本统一使用YourStrong!Passw0rd与 benchmark_config.yaml 中的连接串保持一致MSSQL_AGENT_ENABLEDtrue必须开启。SQL Server 的 CDC capture job捕获作业依赖 SQL Agent 异步扫描事务日志并把变更写入 change tables禁用 Agent 将导致组件无数据可读mcr.microsoft.com/azure-sql-edgeAzure SQL Edge 镜像与生产环境使用同一类型镜像符合 docs/benchmarking.md 中避免 lite/local 变体的原则。辅助任务task sqlserver:down # 删除并强制清理容器: docker rm -fv sqlserver task sqlserver:logs # 跟随容器日志: docker logs -f sqlserver2.3 架构一致性提醒在 Apple SiliconARM机器上务必确认镜像架构与宿主机一致。若以 x86 镜像在 Rosetta/QEMU 模拟层下运行吞吐数字会被严重拉低并产生误导性结论详见 docs/benchmarking.md 第 3 节。历史结果见第 7 节显示同一数据集下Docker 模拟层跑出 ~130-139 MB/sec而 ARM 原生运行可达到 ~140-154 MB/sec。3. 分步运行基准测试3.1 创建底层测试表task sqlcmd:create该任务实际执行sqlcmd -S localhost -U sa -P YourStrong!Passw0rd -i create.sql核心逻辑在 create.sql 中分三个阶段STAGE 1 — 创建数据库创建testdb并设置ALLOW_SNAPSHOT_ISOLATION ONCDC 读取需要快照隔离支持IF NOT EXISTS (SELECT name FROM sys.databases WHERE name Ntestdb) BEGIN CREATE DATABASE testdb; ALTER DATABASE testdb SET ALLOW_SNAPSHOT_ISOLATION ON; ENDSTAGE 2 — 启用数据库级 CDCUSE testdb; EXEC sys.sp_cdc_enable_db;STAGE 3 — 建表并逐表启用 CDC创建rpcnschema 及dbo.users、dbo.products、dbo.cart外加一张dbo.cart2四张表每张表创建后立即执行EXEC sys.sp_cdc_enable_table source_schema dbo, source_name users, role_name NULL;role_name NULL表示不创建捕获实例专用的访问角色限制。表结构刻意设计了差异化的列类型组合NVARCHAR(MAX)大文本、DECIMAL(10,2)金额、BIT布尔、DATETIME2时间戳等保证变更事件负载接近真实业务行。3.2 生成测试数据三种数据集脚本可单独或全部执行task sqlcmd:data:users task sqlcmd:data:products task sqlcmd:data:cart各脚本的数据规模与负载特征如下脚本行数负载特征对应文件users150,000about字段约 500 KBREPLICATE(..., 25000)模拟大文本行users.sqlproducts150,000description字段约 500 KB含价格/库存列products.sqlcart10,000,000行较小约 40 次重复的 info 文本单表千万行规模cart.sql三个脚本采用同一套批量插入模式外层WHILE循环按10,000行一批推进内层用WITH Numbers AS (SELECT TOP ... ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) ... FROM sys.all_objects a CROSS JOIN sys.all_objects b)生成无游标的集合式序号配合INSERT ... WITH (TABLOCK)批量写入。以 users 为例DECLARE users_total INT 150000; DECLARE users_batch_size INT 10000; DECLARE users_current INT 0; WHILE users_current users_total BEGIN DECLARE users_batch_end INT users_current users_batch_size; IF users_batch_end users_total SET users_batch_end users_total; WITH Numbers AS ( SELECT TOP (users_batch_end - users_current) ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) users_current AS n FROM sys.all_objects a CROSS JOIN sys.all_objects b ) INSERT INTO dbo.users WITH (TABLOCK) (name, surname, about, email, date_of_birth, join_date, created_at, is_active, login_count, balance) SELECT CONCAT(user-, n), CONCAT(surname-, n), REPLICATE(CONCAT(This is about user , n, . ), 25000), -- about ~500 KB CONCAT(user, n, example.com), DATEADD(DAY, -n % 10000, GETDATE()), SYSUTCDATETIME(), SYSUTCDATETIME(), CASE WHEN n % 2 0 THEN 1 ELSE 0 END, n % 100, CAST((n % 1000) (n % 100) / 100.0 AS DECIMAL(10,2)) FROM Numbers; SET users_current users_batch_end; PRINT CONCAT(Progress: , users_current, /, users_total, rows inserted into dbo.users); END值得注意的实现细节分批边界处理IF users_batch_end users_total SET users_batch_end users_total保证最后一笔不满批也能完整收尾幂等进度输出每批结束打印Progress: n/total便于在大数据集下确认脚本仍在推进cart.sql 的事务策略千万行插入包在显式BEGIN TRANSACTION ... COMMIT的事务块中逐批提交避免单事务过大users/products 则未显式开启事务直接依赖隐式提交脚本末尾自校验三个脚本都在结尾执行SELECT COUNT(*)并打印验证行数防止静默丢数据。数据插入后SQL Server 的 CDC capture job 会异步把这些变更写入 change tables——这正是组件轮询的数据来源。因此测试数据的写入完成与变更可用之间存在由捕获作业节奏决定的延迟属正常现象。3.3 运行 Connect 管道使用仓库根目录的 Connect 入口启动并加载基准配置go run ../../../../cmd/redpanda-connect/main.go run ./benchmark_config.yaml../../../../cmd/redpanda-connect/main.go即 cmd/redpanda-connect/main.go从 bench 目录出发的相对路径。3.4 每轮运行后清理 checkpoint 缓存task sqlcmd:drop-cache该任务执行sqlcmd -S localhost -U sa -P YourStrong!Passw0rd -Q USE testdb; DROP TABLE rpcn.CdcCheckpointCache;关于这一步为何必须执行见第 5 节。3.5 整体流程一览仓库 README 将上述动作归纳为完整的生命周期启动 Microsoft SQL Server 容器与 Redpanda Connect创建数据库并生成测试数据展示吞吐量滚动日志清空 checkpoint 缓存以便下一轮从头测量。4. 基准配置深度解析benchmark_config.yaml 是整条基准管道的核心逐段拆解如下http: debug_endpoints: true input: microsoft_sql_server_cdc: connection_string: sqlserver://sa:YourStrong!Passw0rdlocalhost:1433?databasetestdbencryptdisable stream_snapshot: false include: - dbo.users - dbo.products - dbo.cart batching: count: 1000 output: processors: - benchmark: interval: 1s count_bytes: true drop: {} logger: level: DEBUG metrics: prometheus: add_process_metrics: true add_go_metrics: true4.1 关键参数与实现依据http.debug_endpoints: true— 暴露localhost:4195上的 pprof 端点CPU/内存/阻塞剖析。当吞吐不达预期时这是定位 Connect 侧热点的基础设施。input.microsoft_sql_server_cdc— 组件在 input_mssqlserver_cdc.go 中以service.MustRegisterBatchInput(microsoft_sql_server_cdc, ...)注册。其配置字段在源码中定义如下节选自该文件第 32-48 行的常量声明const ( fieldConnectionString connection_string fieldStreamSnapshot stream_snapshot fieldMaxParallelSnapshotTables max_parallel_snapshot_tables fieldSnapshotMaxBatchSize snapshot_max_batch_size fieldStreamBackoffInterval stream_backoff_interval fieldTablesExclude exclude fieldTablesInclude include fieldCheckpointLimit checkpoint_limit fieldCheckpointCache checkpoint_cache fieldCheckpointCacheKey checkpoint_cache_key fieldCheckpointCacheTableName checkpoint_cache_table_name fieldCheckpointCacheConnectionString checkpoint_cache_connection_string fieldBatching batching )基准配置用到的字段含义connection_string标准sqlserver://URLencryptdisable用于本地容器场景跳过 TLSstream_snapshot: false关闭存量快照读取。组件描述源码第 59-60 行明确Streams changes from a Microsoft SQL Server database for Change Data Capture (CDC). Additionally, if stream_snapshot is set to true, then the existing data in the database is also streamed too.。本基准默认测的是纯增量流式模式——即生产环境真正会承受的负载形态include显式列出要消费的表。这里只纳入dbo.users/dbo.products/dbo.cart有意把 create.sql 中额外创建的dbo.cart2排除在外保证被观测的数据流完全可控batching.count: 1000输入侧批量大小。该值对吞吐影响显著且随组件差异很大docs/benchmarking.md 记录其他组件的取值从 1,000 到 140,000 不等需要实测调优——过小导致每批固定开销占比高过大会带来内存压力与延迟尖峰。output.processors[0].benchmark— 内置benchmark处理器以interval: 1s为周期打印滚动吞吐统计count_bytes: true让日志同时包含msg/sec与bytes/sec两个维度。output.drop: {}— 丢弃输出。基准只关心从数据库读出来的速度drop消除了下游写出开销让benchmark处理器测得的数值等价于输入吞吐上限。metrics.prometheus— 开启进程级与 Go 运行时指标add_process_metrics/add_go_metrics可对接 Prometheus/Grafana 做长时间观测项目 profiling 栈见 docs/benchmarking.md 的 Profiling 章节。4.2 组件读取模型性能语义源码的 Performance 段落input_mssqlserver_cdc.go 第 75-77 行附近对吞吐特征做了权威解释这是解读基准数字的前提该输入并不直接读事务日志SQL Server 的 CDC capture job 异步扫描日志并把行发布到每表独立的 change tables输入组件只是轮询这些表。捕获作业是所有 CDC 消费者的共同上游吞吐上限交付天然呈突发性——重写负载下短暂空闲后紧跟大批量是正常现象。这意味着基准测到的天花板主要由 SQL Server 侧决定而非 Connect 的 CPU。历史实测也印证了这一点见第 7 节。5. Checkpoint 缓存机制与多轮复现microsoft_sql_server_cdc是带状态的输入它会记录消费进度以 SQL Server 的 LSNLog Sequence Number 为游标保证重启后从断点续传。进度存放在 SQL Server 内的 checkpoint 缓存表中。实现位于 checkpoint_cache.go关键常量第 25-35 行const ( // cache updates a single row so we use a fixed key defaultCacheKey max_lsn // defaultCheckpointCache can be configured by the user defaultCheckpointCache rpcn.CdcCheckpointCache // the stored procedure name cannot be configured by the user defaultStoredProcName CdcCheckpointCacheUpdate // 4 bytes VLF sequence number 4 bytes log block offset 2 bytes slot number lsnByteLength 10 )要点默认缓存表为rpcn.CdcCheckpointCache内部通过存储过程CdcCheckpointCacheUpdate单行 upsertmax_lsn由于 SQL Server 不支持在cache_sql组件配置中表达 upsert组件自研了这个专用缓存源码注释明确说明这一动机使用默认缓存时Connect 用户需要创建表和存储过程的权限且rpcnschema 必须预先存在组件描述中 Permissions 段落的说明。为什么每轮必须清缓存因为 CDC 游标持久化在数据库中——如果不清除第二轮运行会从上一轮末尾的 LSN 继续change tables 中已消费的存量变更不会再被读出导致测得的吞吐虚低甚至为 0。task sqlcmd:drop-cache直接DROP TABLE rpcn.CdcCheckpointCache让组件下一轮从零开始全量消费保证多轮对比的公平性。同理docs/benchmarking.md 提醒SQL Server 的清理作业cleanup job可能定期清空 change tables长时间挂机的测试可能因变更数据被回收而出现 0 msg/sec——基准期间建议关闭或延长变更数据的保留窗口。6. 预期输出与结果解读正常运行时每秒打印一行滚动统计形如INFO rolling stats: 91733 msg/sec, 123 MB/sec serviceredpanda-connect bytes/sec1.22793538e08 label msg/sec91733 pathroot.output.processors.0 INFO rolling stats: 101267 msg/sec, 136 MB/sec serviceredpanda-connect bytes/sec1.35555936e08 label msg/sec101267 pathroot.output.processors.0 INFO rolling stats: 102000 msg/sec, 136 MB/sec serviceredpanda-connect bytes/sec1.36537118e08 label msg/sec102000 pathroot.output.processors.0 INFO rolling stats: 104000 msg/sec, 139 MB/sec serviceredpanda-connect bytes/sec1.39214558e08 label msg/sec104000 pathroot.output.processors.0 INFO rolling stats: 102000 msg/sec, 136 MB/sec serviceredpanda-connect bytes/sec1.36537106e08 label msg/sec102000 pathroot.output.processors.0解读要点pathroot.output.processors.0表明统计来自输出侧的benchmark处理器即从输入读入并完整走完管道的净吞吐msg/sec与MB/sec应同时关注本数据集单行约 1.4 KB500 KB 大文本字段的 users/products 拉高了均值因此 10 万 msg/sec 对应 130 MB/sec吞吐会在捕获作业批量投递的节奏下波动突发性交付看稳态区间而非单点峰值。若数值显著低于预期docs/benchmarking.md 给出的排查路径包括绕过组件验证上游用sql_raw输入直接读同一批数据若吞吐相当则瓶颈不在 Connect 而在 SQL Server 读取路径检查连接利用率打印sql.DBStats观察OpenConnections/InUse。历史基准正是在这里发现 100 个配置连接中实际只用了 1 个锁定单连接读取为瓶颈多表并行对单连接受限的场景用多张表多连接测试吞吐是否随连接数线性扩展变更环境在本地 Docker、原生安装、云端实例如 Azure SQL Premium间对比隔离容器化开销的影响。7. 结果记录与历史数据复盘基准的产物不止于终端日志。README 明确要求运行后把结果按日期追加到 docs/benchmark-results/mssqlserver-cdc.md完整规范见 docs/benchmarking.md。新增记录需包含日期与 PR 链接、环境细节硬件、Docker 配置、资源限制、数据集描述行数、行大小、总量、配置要点批量大小、并行度、吞吐表格与原始日志、观察与瓶颈分析。仓库已沉淀了两组可复现的历史结果是理解该组件性能边界的最佳参考7.1 2025-10-17 — 原生 ARM 环境环境Azure SQL Edge 原生运行于 ARM非 x86 模拟、Colima VM 4 vCPU / 12GB RAM、SQL Server 免费版限 4 核、单表 CDC 流式数据集1.4 KB × 21,198,489 行 ≈ 24.1 GB结果指标数值吞吐~140-154 MB/sec消息速率~105,000-119,000 msg/sec峰值154 MB/sec119K msg/sec原始日志节选INFO rolling stats: 116000 msg/sec, 150 MB/sec INFO rolling stats: 119000 msg/sec, 154 MB/sec INFO rolling stats: 113000 msg/sec, 146 MB/sec观察结论SQL Server 单核被打满106% CPU100 个配置连接中仅 1 个在用sql.DBStats{OpenConnections:1, InUse:1}——瓶颈是单连接 CDC 读取而非 Connect。理论上用多表并行流式可获得约 4 倍提升2 表实测约 2 倍CPU 136%。7.2 2025-10-15 — Docker 模拟层环境环境macOS 笔记本、SQL Server 跑在 DockerAzure SQL Edgex86 模拟层、单表 CDC 快照数据集同上24.1 GB结果~130-139 MB/sec、~65,000-105,000 msg/sec、总耗时约 4 分 30 秒。观察结论无论增加 Connect 可用核数、直连 Linux VM 上的 SQL Server、还是换用多种 Azure SQL 规格含 Premium P1125 DTUs都无法突破 ~139 MB/sec用sql_raw输入绕开 CDC 组件后依旧——瓶颈确凿地落在 SQL Server 单连接读取吞吐上。两组数据合起来传达的信息很清晰Connect 的 SQL Server CDC 输入在架构上留足了余量压测重点是数据库侧的单连接读取能力多表并行是纵向扩展该链路的正路。8. 基准测试方法论要点回顾结合 docs/benchmarking.md 的全局规范SQL Server CDC 基准还体现了三条通用原则快照与流式分开测stream_snapshot的快照模式本质是批量SELECT吞吐通常更高流式模式受上游变更捕获机制约束。报告两者才能既给出上限、又给出生产实际体验值批量大小要调参batching.count是吞吐敏感参数应在报告中注明本次使用的取值与尝试过的其他取值数字可追踪性能路径的任何改动批处理、缓冲、连接处理、序列化后都应重跑基准并追加新日期的记录段便于跨版本追踪性能演变。至此你已具备从零搭建、运行、解读到沉淀 SQL Server CDC 基准结果的完整能力——下一轮压测的滚动统计日志就是你评估组件与数据库协同性能的起点。【免费下载链接】connectFancy stream processing made operationally mundane项目地址: https://gitcode.com/GitHub_Trending/con/connect创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考