为什么区块链永远不会干掉数据库
区块链前线导读:现在有一种声音,说数据库不行了,要被区块链干掉了。真是这样的吗?诚然,数据库在IT界,确实是一个特别古老的研究领域,从最初的文件系统,到后来的ER实体关系模型。大数据实际就是数据库研究的一个分支。而区块链对于数据库的关系,就好比虚拟现实和电影的关系。虚拟现实并不会取代电影,数据库同样也如此。区块链和数据库并非你死我活的竞争关系,它们最终将会融合,就像电影的发展无法阻挡地向着虚拟现实技术发展一样。
区块链和数据库在数据处理和存储方式上有着根本的区别,这些区别意味着这两者在技术上是互补的关系,而非竞争对手。
区块链被大肆炒作,连卖菜的大妈也在谈论区块链、数字货币,在舆论场上,区块链占据了绝对性的主导地位,场面已经失控。尽管区块链是一项让数据生态系统更安全、更可信、更可验证的神奇技术,但它并不是什么万能药。在区块链的大肆炒作中,尤其有一个错误的观点,就是:区块链作为可验证的记录系统,因此,就可验证的记录系统而言,数据库已经被淘汰了!其实,这个观点完全是错误的。区块链和数据库是两种不同类型的记录系统,事实上,它们是互补的。
区块链的好处和挑战
市面上有许多不同的区块链技术和网络,它们都有一个共同的基本特征:“事务”记录都不存储在一个数据库中。相反,交易的共识是记录在生态系统中的整个参与者网络中。
区块链是一个不可变的分布式事务记录。它使用加密算法,以一种安全的方式在一组各方之间达成共识,从而使交易链中的各方对每一笔交易都有准确的记录。没有一个中央存储库是由单方保护的,否则,它可能会为了自己的利益而篡改数据库。区块链是值得信赖的,因为它的分布式模型、块是如何链接到链上的,以及它的一致性算法,使得改变它的成本之高,令人望而却步。
区块链的计算量很大。根据设计,用于产生共识的加密算法需要进行大量的工作。因此,人们在减少计算费用、相应的加密货币费用和电力费用上投入了大量的精力。一种称为“锚定”(anchoring)的方法,该方法减少了存储在链上的数据量。在链上,事务被分组、哈希并组织成带时间戳的区块,以便包含到区块链中。然后,在区块链上指示数据锚定位置的收据存储在数据库或其他持久存储中,使任何事务都可以验证。
这种方法的一个关键方面是,事务中涉及的数据并没有“存储”在锚中。锚只存储数据的加密哈希。锚定用于根据哈希验证原始数据,并确定何时将其提交到区块链,但不用于存储数据。这实际上就是一个记录系统,因为它记录了事务数据的哈希,其完整性任何人都可以随时进行验证。这就提供了一个独立的信任来源,同时还保持了机密数据的隐私,即使在公共区块链上也是如此。
区块链应用
区块链支持哪些应用?它们分为以下三类:
- 智能合约确保基于预先确定的规则进行资产的一致转移。
- 智能资产确保任何标记化资产的所有状态可在各方之间跟踪、验证和结算。
- 智能物联网确保设备生成的信号未被篡改,并反映所感知的真实值。
数据库应用
数据库与区块链的不同之处在于,数据库是明确地存储数据,而不仅仅是哈希。数据库支持两种工作负载:运行工作负载(operational workloads)和分析工作负载(analytical workloads)。
操作数据库,也称为联机事务处理(Online Transactional Processinig,OLTP),为某些应用提供了支持。例如,欺诈争议解决系统,该系统允许呼叫中心代理能够帮助客户在一秒或更短的时间内审查金融交易并就这些交易提出争议。要实现这一点,就需要特殊的数据结构和算法,才能够非常快速地同时处理许多用户的数据。
在线分析处理(Online Analytical Processing,OLAP)系统负责审查历史事务并从中获得见解或生成预测的机器学习模型。这些系统专门用于对数据进行排序和计算指标,例如求和、平均值。这需要高吞吐量才能做到。
现在出现了一种新型数据库,可以将OLTO、OLAP和机器学习集成到同一个平台上,称为在线预测处理(online predictive processing,OLPP)。(译注:Splice Machine就提供了一个OLPP平台)
例如,可以考虑以下三个用例:
- 客户服务呼叫中心:通过电话、网络或移动应用等渠道,呼叫中心代理在接到订单后几秒内就对客户的查询做出响应。
- 个性化:使用机器学习模型,可以预测客户即将采取何种行动。
- 预测维护:使用机器学习模型,预测现场设备何时可能出现停机故障。
以上谈到的这些用例,都需要一个数据库才能完成,而这些用例区块链根本无法做到。
最后的话
那些数据库被淘汰的言论实在太夸张了!区块链确实可能会彻底改变事务的完整性,但是数据库仍将继续支持关键任务应用,分析这些应用,并作为人工智能学习的核心。区块链和数据库双剑合璧,一起为许多垂直领域提供了强大的组合。
原文链接: Why Blockchain Will Never Kill the Database
感谢杜小芳对本文的策划和审校。