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.

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

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艹（aka C++ or CPP）的开发规范一直都比较松散，各个组织包括个体总能在不轻易间把项目堆成 xxxx xxxxxxxx。

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

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

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

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 命令解压覆盖，反而没有出现老生常谈的 cp 覆盖动态库引起 Segmentation fault 的问题。

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

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

本文原链接 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 全公司。