#databases

DuckDB 2.0.0 LTS（代号“Cinnamon Teal”）已发布。发布信息称，该版本带来多核性能提升、客户端-服务器使用方式和触发器能力。社区用户 RobinL 报告，在 EC2 高核心数实例上，2.0 不仅从 S3 读取更快，计算也更快；CPU 利用率可接近 100%，直到约 128–192 vCPU，而此前扩展性大约在 64 vCPU 见顶。这些是用户实测经验，不是官方基准；另有用户指出，可通过 Postgres 线协议或 Arrow Flight 接入现有工具，但 DuckDB 自有的 Quack 协议客户端支持仍然有限。

Jepsen 发布对 ParticleDB 1.1.4 的审计，结论是该版本存在严重的正确性与持久性故障，建议用户停止继续部署并尽快迁移到其他数据库。报告称，这个自称 PostgreSQL 兼容的数据库在几乎各项测量中都出现事务异常，包括已提交写入丢失、内部一致性违例、G1a（Aborted Read）、G1b（Intermediate Read）和 P4（Lost Update）；在追加负载中，成功追加的值会从后续读取中消失。报告共列出 96 个问题，涵盖崩溃、死锁、数据丢失、无法删除的半可见行、WHERE 4 = 5、被删除的表以扭曲形式重新出现、列混淆以及字符串变成整数等。ParticleDB 官网曾宣称通过 TLA+ 形式化证明，但 Jepsen 表示合作期间没有可用的 TLA+ 规范，因此无法确认究竟证明了什么属性，也无法确认这些属性是否针对实际构建出的 ParticleDB。

rqlite 作者 Philip O&\x27;Toole 发表《Twelve years of distributed SQLite》，以个人经验复盘十二年来在分布式 SQLite 方向的工作。文章引发 Hacker News 对同类引擎的详细比较，讨论集中在事务支持、可靠性和外部依赖等选型因素上。现有材料没有给出新版本、性能数字或正式基准，读者应把它当作实践回顾而非产品发布。

rss · Sean Goedecke · 11月6日 00:00 「背景」 作者把数据库中的行或记录重新定义为“全局变量”：程序任何部分都能读写它们，因此也会带来隐式传数和跨模块耦合这两类全局变量的典型问题。然而，工程界一边告诫避免全局变量，一边又让许多优雅系统依赖数据库，这种表面矛盾正是文章要解释的。 「方案」 作者逐一检验了五种解释。第一，数据库应用也许本来就比较混乱；他认为这有一定道理，但不足以解释全部现象，因为数据库应用仍会刻意避免普通全局变量。第二，ACID 事务能缓解问题；他不接受，因为全局变量的根本问题在于其存在本身，而不是能否同步，否则加一把互斥锁就该让全局变量变得可接受。第三，数据库操作更显式，查询需要连接对象和函数调用，扫描代码时更容易定位，这确实减轻了隐式耦合。第四，数据库只能存数据、灵活性更低；他认为这只在弱类型语言中较有说服力，无法解释类型化语言里的情况。第五，开发者熟悉数据库的使用规范，比如读取时检查列类型，也不会拿它做循环计数器之类的琐事。作者最终认为第三和第五条最有说服力：数据库更好，部分是因为使用方式更显式、用途更受限，而这些原因是偶然形成的，并非数据库固有；若给全局变量建立类似约定，理论上也可能达到相近效果。 「启示」 作者并不建议改用全局变量，而是指出“避免全局变量”和“用数据库保存状态”这两条常见教条并不完全一致。他的更大结论是：软件设计知识仍多是一堆松散的经验法则，因此对那些只诉诸“最佳实践”、讲不出具体理由的工程师，应保持怀疑。 标签: databases, global variables, software design, coupling, engineering heuristics