最新

嗨，HN， 在过去的几个月里，我一直在构建 UnisonDB——一个以日志为基础的数据库，其中的写前日志（WAL）不仅仅是一个恢复机制，而是数据库的核心。 我之所以开始这个项目，是因为每当我需要数据流动——从核心到边缘，或在数据中心之间——我总是不得不将一个 KV 数据库、变更数据捕获（CDC）和 Kafka 拼凑在一起。 虽然这样做有效，但总感觉有些过于复杂：即使是小型工作负载也有太多的组件，且缺乏确定性。 它是什么？ UnisonDB 将存储和流处理统一为一个基于日志的核心。 每次写入都是： • 持久的（附加到 WAL 中）， • 有序的（为安全性进行全局排序）， • 可流式传输的（实时提供给任何跟随者）。 它结合了 B+树存储（可预测的读取，没有 LSM 压缩风暴）和基于 WAL 的复制（在不到一秒内扩展到 100 多个节点）。 关键理念： 1. 存储 + 流处理 = 一个系统——没有 CDC，没有 Kafka，没有侧车管道 2. 基于 B+树——可预测的读取，零压缩开销 3. 多模型——在一个原子事务中支持 KV、宽列和大对象（LOB） 4. 原生复制——通过 gRPC 进行 WAL 流；跟随者实时跟进 5. 设计上是反应式的——每次写入都会发出 ZeroMQ 通知 6. 边缘友好——副本可以离线并即时重新同步 性能与权衡： 1. 写入吞吐量低于纯 LSM 存储（例如 BadgerDB）——因为写入是为了复制安全而进行全局排序。 这是一个故意的权衡：一致性 > 原始写入速度。 2. 启用复制时仍然比 BoltDB 快约 2 倍。 技术细节： 使用 Go 编写 使用 FlatBuffers 进行零拷贝序列化 使用 gRPC 进行流式复制 GitHub: [https://github.com/ankur-anand/unisondb](https://github.com/ankur-anand/unisondb)