最新

我需要在 Cortex-M0+ 上通过同一条 115 kbaud 的线路传输两倍的遥测数据，而这颗芯片只剩下 8 kB 的闪存空间。<p>Micro-RLE 是我能想到的最小的即插即用方案：264 B 的 Thumb 代码，36 B 的状态，没有 malloc，最坏情况下每字节 14 个周期，并且对每个 8 位模式都无损压缩。<p>在常用的传感器数据流（ADC、IMU、GPS）上，它比原始输出小 33-70%，并且在 &lt; 600 µs 内启动，因此你可以在 PLL 锁相环还没锁定时，从 main() 函数中直接调用并执行。<p>代码库是一个单独的 .c 文件和 3 个函数的 API——用你的 UART / DMA / 环形缓冲区替换弱化的 emit() 钩子函数，就完成了。<p>大小证明：arm-none-eabi-size micro_rle.o text data bss 264 0 36<p>MIT 许可，在代码库中链接。很高兴听到它还能应用在哪些地方！

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