LSM-Tree的Compaction为何让数据库工程师又爱又恨：从写放大到读放大的三十年权衡
2018年，某互联网公司的一条生产事故报告引发了广泛关注：他们的RocksDB实例在写入量激增时突然"卡死"，应用层请求超时雪崩。排查日志后发现，罪魁祸首是Write Stall——RocksDB的内部保护机制在L0层文件过多时主动暂停写入。这不是孤例。在LSM-Tree架构的数据库中，Compaction（合并压缩）机制既是性能的守护者，也可能成为故障的导火索。 ...
数据库
分页设计的三十年陷阱：从OFFSET的性能灾难到Cursor的工程突围
一位开发者在生产环境遇到了一个奇怪的问题：分页查询在前100页运行良好，但当用户翻到第500页时，原本2秒的查询变成了2分钟。数据库CPU飙升，整个系统响应变慢。罪魁祸首？那个看起来人畜无害的 LIMIT 10000, 20。 ...
列式存储如何让数据分析提速百倍：从存储布局到向量化执行的技术真相
一个真实的数据对比揭示了令人震惊的性能差距：同样的1000万行数据，运行相同的分析查询，PostgreSQL需要12.2秒，而ClickHouse只需要453毫秒——27倍的差距。这不是硬件差异，不是索引设计，而是两种存储范式在数据仓库场景下的必然结果。 ...
分片键选错的代价有多大：从Foursquare宕机到美团实践的技术复盘
2010年10月，位置社交应用Foursquare经历了一场持续17小时的宕机。当时这家创业公司拥有300万用户、2亿次签到、每天新增1.8万用户，业务正处于快速增长期。导致宕机的直接原因并不复杂：分片数据分布不均，一个分片的数据量达到67GB，超过了节点66GB的内存容量，系统开始疯狂地将内存页面换入换出，整个数据库被拖慢到磁盘速度。 ...
SQLite为何能征服世界：从三位开发者的固执到一万亿数据库实例的技术传奇
2000年5月29日，D. Richard Hipp开始编写一个嵌入式数据库引擎。他的动机很务实：作为通用动力公司的承包商，他正在为美国海军的奥斯卡·奥斯汀号驱逐舰开发软件。军舰上的程序需要一个本地数据库，但传统的客户端-服务器数据库在这个场景下有一个致命缺陷——如果数据库服务器进程崩溃，整个应用程序就会瘫痪。 ...
数据库已提交的事务为何会丢失？从fsync到异步提交的持久性权衡
数据库教科书告诉开发者一个简单的承诺：事务一旦提交，数据就是持久的。ACID中的"D"代表Durability——持久性。但生产环境中的实际情况远比教科书复杂：同样配置了主从复制、同样使用了SSD存储、同样收到了COMMIT成功的返回码，断电重启后，有些数据确实完好无损，有些却凭空消失了。 ...
B+树索引的页分裂：从顺序插入的优雅到随机写入的代价
一个简单的测试揭示了令人困惑的现象：同样的硬件、同样的表结构、同样的索引设计，使用UUID作为主键的表插入速度只有自增主键的十分之一。更奇怪的是，存储空间的占用竟然相差接近一倍。 ...