Hacker News 中文摘要

RSS订阅

Kafka很快——我会用Postgres -- Kafka is Fast – I'll use Postgres

原文链接 | HN讨论 | 2025-10-30 00:03:50

文章摘要

文章批评了技术界盲目追逐流行词和过度设计的现象，指出一些人为了简历好看而采用不必要的新技术，而另一类人则更务实，基于实际需求选择简单可靠的方案，如用PostgreSQL替代Kafka。

文章总结

技术世界的两极分化：从盲目追新到回归理性

两种技术阵营的对立

技术领域存在两种截然不同的阵营： 1. 追新阵营：盲目追逐流行词汇，未经深思熟虑就采用新技术，容易被"实时"、"无限扩展"、"云原生"等营销话术吸引。这种现象被称为"简历驱动设计"（resume-driven design），现代职场文化无形中助长了这种风气。 2. 务实阵营：坚持常识，注重简化复杂性，避免过度设计。他们从第一性原理出发做技术选型，对厂商宣传保持警惕。

趋势的转变

近年来，务实阵营开始获得更多支持，主要得益于两大趋势： 1. 小数据运动：人们意识到大多数场景的数据量并不大，而现代硬件性能已足够强大（如AWS提供128核、4TB内存实例）。 2. Postgres复兴：PostgreSQL因其多功能性重新受到青睐，能够替代许多专用系统： - 替代Elasticsearch（通过tsvector/tsquery） - 替代MongoDB（通过jsonb） - 替代Redis（通过无日志表） - 替代专用向量数据库（通过pgvector） - 甚至替代Kafka（本文重点）

Postgres的实用哲学

Postgres的核心优势在于：用20%的开发成本解决80%的问题（帕累托原则）。结合现代硬件，Postgres这种久经考验的系统往往比复杂的分布式系统更合适。

基准测试：Postgres作为消息系统的表现

发布/订阅模式测试

作者设计了Kafka风格的工作流： - 写入：批量插入消息并原子更新偏移量 - 读取：消费者组按分区顺序消费 - 保证：至少一次/最多一次处理，严格有序

测试结果亮点： 1. 4核单节点： - 写入：5036条/秒（4.8MB/s） - 读取：25183条/秒（24.6MB/s） - 端到端延迟：60ms(p99) - CPU利用率：60%

  1. 4核三节点（跨AZ复制）：

    • 性能几乎未下降
    • 年成本仅$11,514，远低于Kafka供应商方案

  2. 96核单节点：

    • 写入：243,000条/秒（238MB/s）
    • 读取：1,200,000条/秒（1.16GB/s）
    • CPU利用率仅10%

队列模式测试

使用SELECT FOR UPDATE SKIP LOCKED实现队列： - 4核单节点：2885条/秒（2.81MB/s） - 96核单节点：20,144条/秒（19.67MB/s）

何时该用Postgres？

作者提出最小可行基础设施（MVI）原则： 1. 选择团队熟悉且"足够好"的技术 2. 用最小功能集解决问题 3. 优先考虑广泛采用的技术（如Postgres）

反驳"扩展性焦虑"： 1. OpenAI案例：800万用户仍使用非分片Postgres架构 2. 增长计算：即使年增长200%，也有2年时间迁移 3. 过度设计就像新手乐队为Coldplay暖场而购买顶级音响

结论

在绝大多数场景下，Postgres都是明智的默认选择，直到真正遇到瓶颈再考虑专用系统。技术选型应注重实际需求而非理论最优，避免过早优化带来的复杂性。

（全文通过详实的基准测试和案例分析，有力论证了Postgres作为通用数据平台的可行性，对当前技术选型的浮躁风气提出了中肯批评。）

评论总结

以下是评论内容的总结，平衡呈现不同观点并保留关键引用：

支持PostgreSQL的观点

  1. PostgreSQL足够应对大多数场景

    • 评论1："Postgres is good enough for OpenAI, chances are it's good enough for you."
    • 评论3："Postgres really is a startup's best friend... the resources out there for something like PG are near endless."

  2. 避免过度复杂的技术选型

    • 评论2："You should always default to Postgres until the constraints prove you wrong."
    • 评论11："people often just don't understand their tools and are too quick to throw the baby out with the bath water."

对PostgreSQL的质疑

  1. 性能与适用性限制

    • 评论5："The way it locks tables and rows... can become a serious bottle-neck for performance-sensitive workloads."
    • 评论16："Their results with PG are absurdly slow... don't pretend you're on to something with your custom 5k msg/s PG setup."

  2. 功能缺失与实现复杂度

    • 评论10："Does Postgres support this functionality for their queues?"（指Kafka的offset特性）
    • 评论14："How do you implement 'unique monotonically-increasing offset number'?"（事务顺序问题）

中间立场与技术选型讨论

  1. 工具应根据需求选择

    • 评论24："Use the tool which is appropriate for the job... tools built for a purpose will always be more performant."
    • 评论25："we should try to use the right tool for the job... thinking about the development team's strengths and weaknesses."

  2. 反对极端化分类

    • 评论15："There's poles... the closer you are to either, the less pragmatic you are likely to be."
    • 评论23："People constantly trying to shoehorn their favourite technology into everything."

其他替代方案提及

  • 评论7推荐MongoDB的测试便利性："mongomock is SO VALUABLE... mongodb's 25 billion dollar valuation is partially based on this."
  • 评论20建议NATS Jetstream："If you don't need all the bells and whistles of Kafka, NATS Jetstream is usually the way to go."

关键争议点集中在PostgreSQL的通用性优势与专用工具（如Kafka）的功能完备性之间的权衡，以及技术选型中"过度简化"与"过度复杂化"的两种极端倾向。