客户口碑｜亲邻科技 x TDSQL

“ 腾讯云数据库 TDSQL-C 只读分析引擎的能力远超我们预期。因为一次偶然的测试将之前 20分钟执行的 SQL加速到了秒级。这促使了我们后端平台的整体升级替换，效果非常好。未来我们也将计划将所有的数仓和 ETL 平台进行全面迁移，进一步降低数据湖仓系统的复杂度和成本。为亲邻科技智慧社区和社区营销两大核心平台的 Agentic AI提供数据专家服务。

好产品值得推荐。 ”

—— 亲邻科技 CTO苏煦烽

项目背景

亲邻科技是国内领先的社区智能化解决方案提供商，致力于通过大数据、AI与物联网技术提升社区运营效率与居民生活体验。

公司核心产品包括智慧社区管理平台、社区营销中台及AIoT智能终端，目前服务覆盖230+城市，已进驻6万+社区，服务了超过7000万家庭，已经与超过12000家物业进行合作。

近期其核心系统已完成向腾讯云TDSQL-C云原生数据库的只读分析引擎的架构升级，成功解决原有系统在复杂查询、跨系统集成及成本效率上的使用瓶颈，并为AI驱动的社区服务奠定了更强大的数据基础。

从“痛点”到“破局” ，随着业务规模扩大，亲邻科技核心营销系统面临着三大核心痛点。

一、性能问题

面向营销提供数据服务的基础数据较多，查询所使用的 SQL 较为复杂，当前使用的原数仓系统性能较差。广告投放选址的语句，经常需要耗时 2分钟以上。

二、数据同步问题

业务数据分散到不同的地域，之前采用的数仓系统需要自行编写数据同步逻辑。数据的快速增长和较多任务上线导致 ETL 任务处理时间波动较大，经常因为各种意外导致同步中断。

三、成本问题

由于数据库与数仓系统采用不同的技术栈，对人员的要求高。学习成本和运维成本都深深影响着整体项目的进度。

技术选型

经过测试，亲邻的技术团队从性能、成本、易用性三个维度对比了各类数据库方案，最终选定采用腾讯云 TDSQL-C 只读分析引擎作为业务的核心数据分析用的数据库。关键决策依据如下：

一、性能超出预期

核心多表关联查询响应时间从之前的 10 秒压缩至 3 秒内。80% 以上复杂查询实现亚秒级响应，系统 API 平均响应时间稳定在700-1000毫秒，整体性能与用户体验显著改善。

提升感受最深刻的就是 AIoT 平台的周运营情况的报表数据查询从之前 的 20分钟直接缩短到了 60s 内。

只读分析引擎之所以能够对业务的性能提升如此明显，主要的得益于"三个基础核心能力、两个高阶优化"，三个基础核心能力包括：

1、列式存储

TDSQL-C 只读分析引擎采用了类 LSMTree 的数据结构，将数据以列的形式存储到磁盘当中。

使用列式存储可以在数据扫描时可以快速跳过无关列数据（列裁剪能力）。另外按列存储可以进一步提高压缩效率，减少了从磁盘上需要扫描的数据。

特别是多表聚合连接，只部分列字段的大数据集查询场景下性能优异。

如下图所示，表的列较多的场景，可以仅仅扫描 c1 的数据通过过滤后将指定行的数据提取出来。如表的列较多时候，性能提升可达几十倍。

2、向量化执行

因为数据是根据列的形式将各行数据存储在一起，也可以认为这些数据是以数组或者向量的方式存储的。

基于这样的特征，当该列数据需要进行某一同样操作 (做到取多条数据同时计算)，可以使用 SIMD（Single Instruction Multiple Data） 进一步提升计算效率。

SIMD 指令在本质上非常类似一个向量处理器，可对控制器上的一组数据 (又称“数据向量”) 同时分别执行相同的操作从而实现空间上的并行。

如下图所示，在传统的执行方案下，一次只能对两个数执行一次加法操作。但是 SIMD执行的模式下，一次可以对两列中的多个值进行计算。

由此可见，通过向量化执行的能力，一次性可以处理一批数据，显著提高查询的执行效率。

3、并行计算

只读分析引擎采用多线程执行的系统架构去加速 SQL的执行效率。

如下图所示，当 SQL执行时会生成多个worker线程。如在执行TableScan算子时，可以根据数据的分区情况，使用多个worker线程去并行读取每一个分区的数据。

这样在遇到大批量数据扫描时就可以极大的提升数据扫描效率，提升 SQL执行速度。

同时传统的优化器只能生成串行的执行计划，为了实现并行读取数据，同时并行处理数据，我们还针对只读分析引擎的优化器进行了深度改造，让优化器可以生成最优的并行计划。

比如选择哪个表或哪些表可以并行读取或者哪些操作可以并行执行，通过并行执行可以带来足够的收益。

除了上面介绍的基础核心能力外，TDSQL-C 只读分析引擎提供的两个高阶优化能力：零拷贝、自适应的 Runtime Filter 让亲邻的 SQL 性能能够进一步提升 150% 以上。

1、零拷贝

需要提前说明的是零拷贝指的是存储引擎 Buffer Pool 和执行引擎之前的零拷贝，Buffer Pool 和执行引擎的数据存储格式都是列存存储。

但是由于服务目的的不同，两者数据的表示方式不是完全一致的: 存储引擎 BufferPool 为了更好的管理 IO 单元和索引，每个列的数据块按照固定大小存储，比如 256KB，每个数据块都存储在一段连续的内存中。

执行引擎为了保证数据的完整性，批量处理数据的时候，都会拿固定行数的数据块，每个数据块中的列也分布在连续的内存中。

这里就会出现一个问题，当存储的数据块向执行层转移的时候，固定行数的数据可就不一定在连续的内存中了。

以上图中拿 3 行数据的场景为例，C1 列的 3 行数据都在一个存储数据块中，所以可以直接引用这段内存进行计算，但是 C2 列的三行数据出现了跨数据块的情况，所以内存是不连续的，必须通过拷贝的来获得连续的数据。

因为分析查询中处理的数据量非常大，这部分内存拷贝完全不能忽视，查询经常会 Bound 内存带宽上，成为主要瓶颈。

为了规避掉这一部分的开销，又不影响各个模块的独立功能，我们在数据块的存储中引入向量化常数 K。这个向量常数 K 是啥意思呢？

拿存储来说，每个数据块的行数仍然可以不对齐，但是行数一定是向量化常数 K 的倍数，拿图中的例子来说：

C1 列的数据块是 3K 行， C2 是 2K 行。SQL 在执行的时候，动态的按照向量化常数 K 的倍数行数进行读取。

在上面的例子中，第一次取数据块的时候读取 2K 行，第二次读取数据块的时候读取 K 行，就能保证读每次读取的时候每个列的数据都落在一段连续内存中，可以直接进行内存引用，避免数据拷贝。

2、Adapive Runtime Filter

在亲邻的业务中 「多表关联查询」是最常见的复杂 SQL。而多表关联的 SQL中带有较多的过滤条件。

如果不能提前的处理这些数据过滤的话，就会导致每一次表的 Join 会对全表数据进行。

所以在只读分析引擎中，利用上了 Runtime Filter 的能力将数据提前过滤掉那些不会命中Join Key的输入数据。大幅减少Join中的数据传输和计算，从而减少整体的执行时间。

如下所示（非客户实际 SQL，为类似SQL示例）：

Select * from t1 join t2 on t1.item_num = t2.item_num where t2.date_time > date '2023-02-01';

可以从上图看到Runtime Filter 优化生效的流程：

1）根据查询的 Join条件，生成一条动态过滤条件传递规则。

2）在 t2 表现执行过滤操作，通过实时的结果集生成一个 Runtime filter Object。

3）将这个 RuntimeFilter Object 传递给 T1表

4）T1表根据此object 进行过滤，减少了参与 Join 的数据。

而在实际业务场景中，不同的Join 条件表现出不同的选择率。

在选择率低的场景中适用Runtime Filter能取得比较好的性能价值，并且选择合适的类型(Bloom/Range/In filter)可以让性能收益最大化。

但是，在 Join 条件高选择率的场景下无法有效过滤数据，构建和使用Runtime Filter涉及计算和内存开销，在过滤无效情况下将带来性能减益；因此，分析引擎实现了执行器的 Adaptive Runtime Filter。

自适应的部分主要包含两个方面：

1）自适应选择何种类型的 Runtime Filter：根据具体的查询条件和数据分布情况，动态选择最适合的 Runtime Filter 类型，以达到最佳的过滤效果。

例如，在 Join Key NDV比较小的场景中选择In Filter快速精准过滤数据并有效利用索引能力;在识别连续数值类型场景选择Range Filter;在更通用的场景选择Bloom Filter并自适应决策Bloom Filter大小以提升过滤准确性。

2）自适应启用/禁用 Runtime Filter：在过滤效果不佳的场景下，执行引擎可以自适应地启用或禁用 Runtime Filter，这就要求执行引擎对当前过滤效果有动态反馈，根据过滤效果实时调整禁用和重新启用，最小化性能减益。

通过自适应Runtime Filter能力，使得只读分析引擎可以在Join Key选择率优势场景性能收益最大化，劣势场景性能减益最小化，这就更通用的让业务的多样化Join场景性能得到了极大提升。

二、更加简单易用

深度兼容 MySQL，仅需将分析引擎作为高性能MySQL只读实例使用。

通过TDSQL-C代理服务或编程框架轻松实现读写分离，业务对接数据库的开发成本降低70%。程序员仅需掌握MySQL与了解一点点分析引擎的特性，无需额外学习复杂技术栈。

1、无缝集成

TDSQL-C 只读分析引擎通过主从同步的原理，将数据实时加载为列式存储。无需 ETL工具，实时性与 MySQL从库相当。

2、MySQL生态兼容

整合 OLTP 与 OLAP能力，可以在一个MySQL兼容的数据库产品中完成业务中混合负载场景，又能够解决在数据库+数仓的数据分析处理场景。

三、更低使用成本

在当前业务中仅仅使用16核64G 单节点实例的情况下，就已经超越了之前数倍资源都无法获得的性能体验。并且通过数据压缩，存储成本直降60%。

1、数据压缩

TDSQL-C 只读分析引擎默认采用了 LZ4的数据压缩算法。根据我们实际观察，在某些数据相似度较高的表，数据压缩比可达到 10:1，甚至更高。

2、指定对象加载

对于一个在线业务而言，并非是 100%的数据对象都需要进行数据分析或者涉及有复杂查询。所以在只读分析引擎中可以通过控制台轻松点击，过滤掉无需使用的表，进一步节省磁盘空间。

未来展望

目前“只读分析引擎”也不仅限于支持云原生TDSQL-C MySQL。在云数据库 MySQL中也可以开启“只读分析引擎”。

业务可以通过“只读分析引擎”的无缝集成，快速实时的行列数据转换能力解决“实时分析”、“低延迟查询”的需求，提升系统运行速度。

未来，只读分析引擎将继续扩展更多的数据渠道；加强SQL执行性能；提升并发场景下的执行能力。

腾讯云数据库也将通过产品能力提升，携手每一位客户进一步挖掘在线数据的潜在价值，为业务创新提供更强有力的支持。

本文参与 腾讯云自媒体同步曝光计划，分享自微信公众号。原始发表：2025-04-02，如有侵权请联系 cloudcommunity@tencent 删除存储科技内存数据性能