把区块链的 bcdb 这种东西讲明白, 就是简单地把数据库迁移到链上去,用来解决链外数据验证以及跨机构共享这些长期以来一直让人头疼的大问题。
我曾经带领我的团队去落地实施了三个关于链上数据层的项目, 在这个过程中踩过的坑非常多, 多到足以写出三本专门讲述如何避免陷入陷阱的手册, 因此我今天要把其中最核心的关键点一次性全部都讲清楚。
区块链bcdb是什么
它不是一种叫做上链存证的简单做法, 而是把整个数据库的读取和写入的基本逻辑, 都运行在分布式的那些节点上面, 依靠一种叫做共识的机制来保证多个副本的数据是一致的。
你可以试着想象一下如果用的是传统的 MySQL 这种单点架构的东西, 一旦那个点出现了故障, 系统就全都没法用了, 但是区块链bcdb天然多节点冗余, 想要把数据写进去的话, 必须得得到多数节点的确认之后, 这个写入操作才算真正生效。
我的第一个项目就在这件事情上栽了跟头。起初为了图省事, 把全量业务数据全部上链进行存储, 结果Gas费的开销直接把预算打穿, 导致团队差点就直接叫停了项目的推进。后来团队改为采用链下存储原文、而链上只存哈希摘要的混合架构进行处理, 这样一来读操作的延迟才被成功压低至人们可以接受的范围之中。
区块链bcdb怎么落地
在选择方案的时候, 千万不要只是去翻那些白皮书。我曾经见过这样的情况, 就是有一个团队他们选择了一个在当前市场上比较热门的那条公共区块链的数据库解决方案, 然后等到真正上线使用之后才发现这个性能的吞吐量它实际是跑不到50的, 结果导致了当日常活跃用户数达到两万人的时候系统就会直接卡住不动。
在实际落地执行的过程当中需要紧紧盯着以下这三件事情: 首先是节点延迟情况如何, 其次是要看数据分片的策略是不是合理, 最后还要看跟你们现有系统当中的应用程序接口的兼容程度, 只要其中有一件事情没做好就足够让项目组非常头疼麻烦了。
此外, 还埋着一个容易被忽视的巨大隐患, 那就是权限管理这个问题。
因为一旦链上的数据被写入系统之中, 那就基本上再也无法进行修改或者删除了, 所以关键是谁有能力去执行写入操作谁又只能进行读取这种权利到底由谁来掌控这些非常核心的环节, 就必须在整个架构搭建的最初期阶段确定下来并且固定住, 千万不要等到整个项目已经正式发布上线之后才想到要去补齐这些缺失, 那时候如果再去修改其中一个地址的相关配置, 就等同于要把全部的数据进行一遍搬迁迁移, 由此产生的额外成本绝对要高出原来的十倍以上。
区块链BCDB并不是那一把能打开所有门的万能钥匙, 可是如果把应用场景给用对了的话, 数据方面的可信程度以及不同机构协作时候的效率确实是那些传统的数据库根本都给不了的, 所以咱们建议先挑一个小模块去做一个叫POC的东西, 等到把这个延迟和成本给跑通了之后再去大面积地铺开, 千万别在一开始的时候就急着把所有东西都一次性迁移过来。
