加载失败
这条 HN 讨论围绕一篇关于 Branimir Lambov（IBM 工程师）谈 Cassandra 的访谈展开。Cassandra（分布式 NoSQL 数据库）原本以高可用和横向扩展见长，但评论者把话题延伸到它是否该加入 ACID 事务，以及像 Accord（Cassandra 相关的事务协议/项目）这样的方向是否有必要。另一条主线是数据库选型：有人强调 Cassandra、ScyllaDB（一个兼容 Cassandra 的高性能分布式数据库）、FoundationDB（一个强调事务能力的分布式数据库）都只适合特定场景，滥用会像把 GraphQL（API 查询语言）硬塞进不合适的系统一样。评论后半段又转向 AI/LLMs（大语言模型）在访谈中的“时效性陷阱”，担心对快速变化技术的评价很快过期，也提到 NYC Systems（纽约系统工程社区）在安排演讲时如何避免让话题被 AI 完全带跑。
有人担心下一代工程师会把 Cassandra、ScyllaDB、FoundationDB 这类为特定场景设计的数据库用错，像“resume-driven mercenaries”那样追新工具而不是理解边界。另一种看法认为，这种问题并不只发生在 NoSQL；很多开发者连传统 SQL RDBMS 也不会正确建模，尤其在允许 JSON 字段、牺牲规范化后，性能和扩展性的取舍会立刻变化。还有人补充，硬件更便宜后，工具选型的边界被拉宽了，但专用数据库仍然有价值，前提是团队真的知道何时该用。
讨论的另一条线索是 Cassandra 加 ACID 事务是否有意义。有人说这件事“很有意思”，并指向一个名为 awesome-accord 的资源；但也有人直言 Cassandra 根本不需要 ACID，引用“ACID rarely”以及“像鱼需要自行车”之类的比喻，暗示强一致事务并非它的设计重点。也有人补充，Accord 的开发者不少在 Apple 工作，说明至少 Apple 这类大客户确实希望 Cassandra 获得事务能力。
评论者对这位 IBM 工程师本人的评价很高。有人直接称他是“engineer's engineer”，强调他属于真正懂底层系统的人，而不是只会讲概念的人。另一条回应则补充，他的回答非常周到、深思熟虑，给人的印象是对技术细节和系统权衡都很扎实。
还有一组评论在谈为什么现在问开发者 LLMs 和 vibing 会变得别扭。问题在于，如果受访者给出具体经验，结论很快就会过时；如果回答得太笼统，又像没真正接触过；而试图兼顾时效与深度，又容易被看成是在替 frontier orgs 做宣传。有人提到自己给 NYC Systems 找演讲嘉宾时，会避免让整场 talk 都围绕 AI，但仍保留这个问题，因为它能反映大型基础设施团队今天到底怎么用 AI。
Cassandra: 一个分布式 NoSQL 数据库，强调高可用和横向扩展，常用于大规模写入场景。
ACID: 数据库事务的四个特性：原子性、一致性、隔离性、持久性；常用来描述强事务保证。
RDBMS: 关系型数据库管理系统，典型代表是传统 SQL 数据库。
LLMs: Large Language Models，大语言模型；在评论里被当作快速变化、容易过时的讨论主题。