区块链所使用的算法以及数据库所采用的算法, 它们在解决核心问题方面的侧重点是完全不一样的, 前者主要是依靠共识机制, 来达到保证数据不被篡改的目标, 后者则是借助索引结构与事务机制, 以实现提升读写操作效率的目的, 只有弄清楚两者各自具备的能力边界, 在进行系统架构选型的时候, 才可以尽量地避免走弯路。
区块链和数据库算法有何不同
数据库算法的核心, 实际上是由像B加树或者LSM树这样类型的索引结构所构成的, 然后它们会配合着ACID事务来保证在单个节点内部的数据是一致的状况, 当你写入一条记录的时候, B加树会直接地告诉你这条记录最终会落在第几页和第几槽这个位置上的, 那么在查询操作走的是那种精确的字节定位方式的, 并且它的响应时间是在微秒级的。

区块链算法的逻辑完全是另外一种样子, 它没有中间那个充当裁判的中心节点在场, 而是凭借哈希链条连接数据, 再加上通过共识机制进行的投票环节, 使得每一位参与者都能依靠自己的算力去独立地对数据进行验证。
由于数据是按照区块形成的先后顺序不断被追加写入的, 因此系统中并不存在传统意义上那种能够快速检索的索引结构, 如果想要查找一条具体的历史交易记录, 那么参与者就只有两种选择, 要么是带着耐心从起点开始慢慢遍历整个链条, 要么是自己额外搭建并托管一个专门的索引服务来辅助查找。
区块链和数据库算法怎么选
只有那些需要多方之间相互不信任, 且要求数据绝对不会被篡改的场景, 比如说供应链的溯源工作, 再或者是跨机构的资金来源与结算处理, 这种情况才真正值得去使用区块链技术。
如果是说单个企业内部的这种数据管理方式, 那么采用关系型数据库再加上分库以及分表的相关策略, 在性能方面和成本方面所产生的差距能够达到两个数量级的程度。
很多团队经常会把去中心化这一概念当做是万能的解决办法, 不过在实际情况中, 共识算法的吞吐量是一个无法改变的硬性约束条件。
对于日活跃用户数量达到百万级别的订单系统而言, 运行在区块链之上的每秒交易处理量是完全无法承受巨大压力的, 因此, 踏踏实实地使用数据库算法来优化读取路径, 这绝对远比大量堆砌节点要来得更加实际一些。
在进行选型工作的时候, 并没有绝对的优胜和劣汰之分,其关键的着眼点在于信任模型。如果你觉得中心节点是值得信赖的, 那么就可以选择使用数据库;如果你对此并不信赖, 再转而考虑采用区块链技术, 这两者在实际上是完全能够做到混合部署的, 并且可以各自掌管属于自己那一层级的任务。
转载请注明出处:imtoken,如有疑问,请联系()。
本文地址:https://zmdyd.cn/imazbqb/10285.html
