做区块链架构工作这么些年, 我是一件非常确定的事情是: 去中心化是协议层的事情, 而工程这层就躲不开对中心化数据库的使用。以太坊全节点的底下挂着PostgreSQL, 公链浏览器那里全都是Golang加MySQL的架构。这不是说谁在设计的时候就错了, 而是量级到了那个程度, 就必须得这么干才行。
区块链需要中心化数据库吗
到底是不是需要呢, 答案就是确实需要的。因为存在于链上面的这些数据呀结构是这样的, 它们把哈希块给嵌套进了默克尔树里面去, 所以没法直接SQL查询。
如果你想要搞出业务报表来, 或者是打算做一下属于链下合规方面的审计工作, 还有通过去监听合约事件的方式来触发出后端业务逻辑这些环节的话, 在没有中心化数据库的情况下，所有这些操作都得裸露奔溃。
我曾经亲眼见过一个团队, 执意要对所谓的纯去中心化进行死磕, 进而把存储层面全部替换成了IPFS技术。这一操作带来的后果是严重的, 查询延迟数据直接从原来的20毫秒猛增到了3秒之多, 导致客户的投诉电话数量巨大, 直接就把客服部门的线路给堵爆了, 而运营人员每天都只能在群里大声呼喊以祈求帮助。
经过长达三个月的反复折腾与尝试, 他们最终只能选择妥协, 恢复性地重新加入了MySQL数据库组件。在将MySQL添加完毕之后的当晚, 整个系统的运行状况立刻就恢复了稳定状态。尽管在技术理念上存在不同的追求, 但是必须明确的是, 保证可用性才是不可逾越的底线要求。可用性才是底线。
区块链中心化数据库怎么选
在做选型的时候, 我最看重的点其实就是数据回灌能力这个东西。因为区块链接本身是那种只能追加的新数据的结构, 数据库必须跟着区块高度的变化去进行同步操作, 这还不算完, 还得费心去处理分叉之后的回滚问题。
在我的实际操作里, 我一般选择使用PostgreSQL来把链上事件的快照存进去, 同时搭配使用Redis来做节点的实时状态的缓存, 这样的话, 这两套系统就能各自干各自该干的活了。
另外一个容易被忽略的陷阱, 是数据库不要设计成单点故障的状态。当前的架构方案是采用主数据库配合两个位于不同可用区域的只读副本实例构成的模式。在主节点发生不可用异常的情况时系统会自动进行流量切换操作。
由于区块链技术本身的核心特性表现为分布式的网状结构, 如果在最底层的存储环节中设置了单点依赖, 那么上层所有的分布式优势都将失去意义并且前面的大量工作会付诸东流。
所谓去中心化更像是一种信念上的执着, 而采用中心化的数据库则是为了维持现实业务的生存根基。所以千万不要在抽象的理念方面耗费过多的精力去纠结争辩，更应当先把眼前的具体业务逻辑顺利地运转起来, 毕竟终端客户并不会在意你的底层架构中到底部署了多少个计算节点。
