最新

我需要通过同一条115 kbaud的线路在只有8 kB闪存剩余的Cortex-M0+上传输两倍的遥测数据。<p>Micro-RLE是我能想到的最小的即插即用方案：264字节的Thumb代码，36字节的状态，不使用malloc，最坏情况下每字节14个周期，并且对每种8位模式都能无损压缩。<p>在常见的传感器数据流（ADC、IMU、GPS）中，它比原始输出小33%到70%，并且启动时间小于600微秒，因此你可以在PLL锁定之前从main()函数中直接调用。<p>代码库是一个单独的.c文件和一个包含3个函数的API——只需用你的UART / DMA / 环形缓冲区替换掉弱的emit()钩子，就完成了。<p>大小证明：arm-none-eabi-size micro_rle.o 文本 数据 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. 原生复制——通过 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)