关于数据库以及为何它们如今的复杂性已不再必要

原文 ↗ Hacker News 讨论 ↗

一篇主张传统关系数据库过于复杂且从根本上存在缺陷的博文引发了讨论，焦点在于这些约束何时反而成了优势。评论者将适合大多数初创公司和业务系统的“一个大型 SQL 数据库”的简单性，与 PB 级、事件驱动架构的需求进行对比；在后者中，日志加物化视图以及 Rama、Kafka 或 Datomic 之类的工具可能更能发挥作用。许多人仍然对 Rama 声称可以取代数据库持怀疑态度——理由包括运维复杂性、JVM 绑定，以及从事件溯源中获得的经验教训——但也承认，针对模式演进、索引和大规模数据处理的更好工具仍然是一个尚未解决的问题。

单一数据库 vs. 多个数据库

  • 强烈支持“一个大数据库”作为一种超能力：语义更简单、没有分布式事务、更容易调试，而且对大多数公司来说通常已经足够扩展。
  • 反方观点：
    • 基础设施层面不可避免地至少还会有一个其他数据存储（例如 etcd/ZooKeeper/K8s 元数据）。
    • 在更大规模或更严格的隔离需求下，按服务、租户或工作负载拆分数据，可以降低故障爆炸半径并支持独立演进。
    • 对许多初创公司来说，单个纵向扩展的 RDBMS + 少量副本就足够了；水平分片通常为时过早。

关系模型、模式与复杂性

  • 有人认为，任何领域都可以用元组和关系清晰建模；真正的限制是性能，而不是表达能力。
  • 也有人强调，受限的模式和规范化是一种特性：它们迫使你认真思考、保护数据质量，并支持强大的查询能力。
  • 批评更多集中在模式演进、迁移风险以及 ORM 泄漏上，而不是关系模型本身。

事件溯源 + 物化视图

  • 许多人指出，最严肃的数据库本来就已经是“日志上的物化视图”（WAL/binlog）。
  • 在高规模、数据工程密集的环境中，事件溯源受到赞赏，但：
    • 许多人反馈它会增加样板代码、认知负担、版本管理难题、GDPR/匿名化问题，以及令人痛苦的调试成本。
    • 有几位表示，除非是在狭窄且有充分理由的场景下，否则他们后悔采用了它。
  • 也有人报告称，只在选择性场景中使用时效果不错，通常会结合 Kafka/CDC/outbox 模式，并以传统 RDBMS 作为权威存储。

Rama：架构与反应

  • Rama 被描述为：追加式“depots”（事件日志）+ 分布式数据流，构建任意“PStates”（物化索引）+ 查询拓扑。
  • 它运行在 JVM 上，提供 Java 和 Clojure API，旨在替代常见的“Postgres + 队列 + 搜索 + ETL”技术栈，并声称具备强一致性、类 ACID 语义和高可扩展性。
  • 热情评论：喜欢它一致的模型、内置遥测，以及摄取、处理和查询之间的紧密集成。
  • 怀疑意见：
    • 强营销（“数据库已无必要”、“用少 100 倍代码实现 Twitter 规模”）感觉言过其实；演示是合成的，不是真实的生产迁移。
    • API 看起来像嵌入在 Java 中的 DSL；仅限 JVM 是一道门槛；学习曲线和心智模型都不清晰。
    • 怀疑它能否比一个好的 RDBMS 更好地简化典型业务应用（例如购物车、会计）。

全局可变状态、事务与演进

  • 大家认同，全局可变状态本质上不可避免；随着新事件到来，事件日志本身也在不断变化。
  • 对于类似资金的工作负载，RDBMS 事务和约束仍然极具价值；有人认为 Rama 的模型只是把复杂性重新安置，而不是消除它。
  • 无论使用数据库还是事件日志，很多人都希望有更好的工具来支持模式演进、蓝绿迁移，以及“schema as code”。