SOLOTZG

数据库执行引擎的内存管理，真正难点不在于统计单条 SQL 用了多少内存，而在于当多个 SQL、后台任务和运行时系统共同竞争实例内存时，如何在 OOM 之前做出可解释的全局决策。传统“先分配、后统计、超限再杀 SQL”的方式处理得太晚，难以表达业务优先级，也无法覆盖逻辑内存与真实进程内存之间的偏差。本文围绕 TiDB 执行引擎的全局内存仲裁机制，讨论稳定性、利用率、公平性和优先级保护之间的设计取舍。

记录一次纯黑盒的 fd 泄漏问题排查过程。该问题发生在云上 GCP 环境，无法在本地或可控测试环境稳定复现，只能通过系统观测、tcpdump、对照实验等方式逐步收敛问题范围，最终定位到高置信触发链路并通过参数绕过止血。

What good can using exceptions do for me? The basic answer is: Using exceptions for error handling makes your code simpler, cleaner, and less likely to miss errors. But what’s wrong with “good old errno and if-statements”? The basic answer is: Using those, your error handling and your normal code are closely intertwined. That way, your code gets messy and it becomes hard to ensure that you have dealt with all errors.

—— Standard C++ Exception FAQ

由于 C++ 异常机制复杂的特性，编写异常安全的代码不是件轻松的事情。异常增强了语言的表达能力，但也带来了不可避免的开销。本文简单分析了 C++ 异常机制的实现原理，并总结相关注意事项。

本文主要讨论 Linux/ELF、System V AMD64 ABI、Itanium C++ ABI 下的实现，实验环境为 Clang 15。编译器、标准库、C++ ABI 运行时和 unwind 库是相互独立的组件；复现实验时还需要确认发行版、链接器及各运行库的具体实现和版本。其他平台和编译器的实现可能不同。

Ref What is a materialized view?: A materialized view is a pre-computed data set derived from a query specification (the SELECT in the view definition) and stored for later use. Because the data is pre-computed, querying a materialized view is faster than executing a query against the base table of the view. This performance difference can be significant when a query is run frequently or is sufficiently complex. As a result, materialized views can speed up expensive aggregation, projection, and selection operations, especially those that run frequently and that run on large data sets.

本文记录一项基于 Flink / Hudi / Kafka / TiCDC 以及 TiDB 构建 Materialized View（物化视图，aka MV）的简易 demo。

In database systems, Collation specifies how data is sorted and compared in a database. Collation provides the sorting rules, case, and accent sensitivity properties for the data in the database.

在数据库系统中，CHARACTER SET(aka 字符集) 为一组字符和编码的集合，COLLATION 则表示字符排序|比较规则、大小写敏感等属性。参考 Character Sets and Collations in MySQL，MySQL 支持多种字符集，每种字符集包含多种 collation（默认使用一种）。TiDB 体系中默认采用字符集 utf8mb4，collation utf8mb4_bin。对于 TiFlash 这样的 OLAP 引擎而言，字符集相关规则引入的额外抽象必然会对性能产生较大影响，本文主要阐述优化 collation 的过程并在 Benchmark TPCH 和 ClickBench 上验证效果。

C++ 提供了很大的工程自由度；如果缺少明确的依赖边界和持续度量，模板、头文件与编译单元的成本很容易随项目规模一起放大。

随着工程规模增大，TiFlash 项目也逐渐开始暴露出这类问题：

• 头文件凌乱
• 模板滥用
• 编译缓慢
• 工程质量愈发难以控制

本文旨在提供量化指标和参考方法用以优化 C++ 工程项目的编译流程。希望动员社区的力量，一起来优化 TiFlash 的工程质量。

全文包含两条主线：

• 构建效率：time trace、模板实例化、头文件依赖、编译单元、PCH、PImpl 和 ccache。
• 产物运行性能：LTO、PGO、BOLT 和代码大页。这些技术通常会增加构建成本，目标不是缩短日常编译时间。

TiFlash 于 2022-04-01 GMT+8 10:35 愚人节 正式官宣开源。

这是加入 PingCAP（aka 贵司）后首次尝试从提出规划到推进落地项目开源，算是值得纪念的事件 Celebrate open-source (#4551)，在此存档相关历程。

PingCAP（aka 贵司）自研了套部署工具 TiUP 来取代早前使用的重型部署工具 Ansible。然而实际使用时，TiFlash 节点在打 patch 过程中出现过不符合预期的报错。后来发现，TiUP 打 patch 的操作并没有停进程，而是直接 tar 命令解压覆盖部署目录，原子性保障也是无从谈起。v6.0 版本前 TiFlash 部分模块包含动态加载 共享库（aka 动态库）的行为，这类行为会被搜索路径下的库文件影响。如果存在某个时刻引入的模块相互不兼容，则直接影响程序的行为。

因为当时使用的 tar 实现会先移除旧目录项再创建新文件，已经映射旧 Inode 的进程没有遇到 cp 原地截断共享库常见的 Segmentation fault 问题。但这并不意味着整个 patch 过程具备原子性：更新期间启动的新进程或再次执行 dlopen() 的线程，仍可能看到缺失、未写完或彼此不兼容的一组文件。

正好借此整理下相关的几个问题：

• cp / tar 命令是如何工作的？
• cp 覆盖正在被使用的动态库为何会引发异常？
• 使用动态库要避开哪些坑？
• 动态库有哪些额外的开销？

结论先行：

• 不要用 cp 原地覆盖正在被映射的共享库。
• 单文件更新应在同一目录写完临时文件，再通过 rename() 原子替换目标；如需保证掉电后的持久性，还要同步文件和目录元数据。
• 多个共享库必须作为整体保持兼容时，应发布到新的版本目录，完成校验后再原子切换入口软链接，而不是逐个覆盖。
• 动态加载不等于符号隔离；稳定的 C ABI、最小导出符号集和明确的版本策略仍然是基础。
  Read more »

本文原链接 The architecture of TiFlash’s distributed storage engine and transaction layer 主要站在开发者的视角阐释 TiFlash 分布式存储 & 事务体系的基本架构和设计思想。

这套体系最初是 2018 年底本人加入 PingCAP 后开始从 0 到 1 设计构建的，于 2020-04-16 随 TiDB v3.1.0 版本正式 GA。

Release Notes 作为开源软件工程实践的重要一环，会很大程度上影响用户体验和交付流程。此篇文档是本人在历次发版任务中总结出来的模板规范，用以帮助产研提升 Release Notes 质量。该规范已由组内推广至 PingCAP 全公司。