北京
一个物联网数据管道让我彻底理解了存储引擎。每秒5万条传感器数据涌入PostgreSQL 15集群，配置不算差：NVMe固态盘、32核CPU、128GB内存。但写到4万条/秒时，写入延迟从2ms飙升到400ms再下不来。pg_stat_bgwriter显示检查点压力爆表，iostat里磁盘利用率死死钉在100%。
问题出在B树索引的随机写。每条插入都要原地更新索引页，高并发下随机I/O直接把磁盘吃光。
切到Cassandra后，写入问题瞬间消失。5万条/秒变成"四舍五入的误差"——提交日志和内存表的设计让写入变成顺序追加，磁盘不再是瓶颈。我得意了一周，直到同事问：为什么SELECT * FROM events WHERE device_id = 'abc' AND ts = 1704067200在只存了10分钟数据的表里要跑80毫秒？
我含糊其辞说了"压缩"两个字。两人其实都不懂。
这个落差——写入飞快、读取却需要解释——逼我去读原始论文。不是博客，是2006年的Bigtable论文和O'Neil 1996年的LSM树论文。我之前以为"Cassandra快因为分布式"，这个认知 embarrassingly 残缺。写入性能来自磁盘数据组织的特定结构决策，而同一个决策正是读取更贵、有时会拿到陈旧数据的根源。这三件事绑在一起，懂一个必须懂另外两个。
大多数开发者没建立这个心智模型，是因为抽象层在失效前都够用。ORM帮你插行，生活美好。但写密集型负载——物联网采集、事件溯源、时序数据、审计日志——很快撞上天花板，届时你只能调试症状，而非根因。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
