区块链技术bdb就是做一件事儿, 它把嵌入式BDB存储引擎挂到链上节点里面去, 这个做法专门治疗一个老毛病, 这个老毛病就是出现高频写入的时候, 共识层和存储层会互相卡死, 我们干了八年这个事儿, 见过了太多团队在这个地方翻车, 今天打算把踩过的所有坑都摊开来跟大家说。
区块链bdb是什么
简单来说, 因为大多数的公链节点的底层都在运行sqlite或者rocksdb, 所以写入放大的问题显得特别严重, 当小事务一旦变多的时候, 系统就变得特别卡顿。
bdb换进去之后, 由于它采用的B+树结构以及日志管理的方式变得更加紧凑了, 因此单节点的写入TPS能够提高到原来的两到三倍的水平, 不过这个做法带来的代价是牺牲了跨平台可移植性, 从而导致部署和维护的门槛就不得不直接提升上去。
我这里负责的供应链溯源项目, 每天的新增交易记录数据量,已经达到了两千多万条之多。在更换为bdb这个系统之后, 所有节点进行同步所需的时间长度, 从原来的四个小时, 压缩到了四十分钟多一点的程度。运维方面的成本降低幅度, 确实是可以用肉眼清晰观察到的。
区块链bdb怎么用
在做选型工作的时候, 不要一股脑儿地就把所有的东西全部给替换掉。最好还是先挑一个稍微边缘一点的节点拿来验证一下, 让它跑上两周的时间比较合适。在这个过程里面, 你要把重点放在盯GC停顿时间还有日志文件的大小的这两个方面上面。
按照我平常的经验来说, 我是会让我的团队们把WAL这一类的日志单独给它挂在SSD这块盘上的, 因为那种传统的机械盘, 它是根本就拿不住那种超高的IOPS强度的。
还有一个比较麻烦的问题, bdb的线程模型跟Go里面的goscheduler存在冲突点, 在高并发的使用场合下, 如果goroutine的数量变得非常多, 那么就很容易出现内存溢出的错误, 所以我们需要手动地去限制一下并发处理的数量, 另外的一点是, 在bdb进行大版本的升级操作期间, 它的ABI是不兼容的, 所谓的即时热更新这个功能基本上没有办法实现, 面对这种情况我们只能选择停止服务或者是同时运行两个版本, 我在日常工作中通常会给出一个建议说法, 就是在双系统并行运行的一段时间内, 先让所有的读取流量全部都流向到新的实例上面去, 然后保持这种状态观察个一星期的时间之后再进行最终的切换工作。
并不存在所谓的万能解决方案, 具体到底适不适合你的业务场景, 需要通过完成性能测试以后, 依靠实际呈现出来的数据来进行说明。
