原文标题：《CKB Style 的区块链乐高：Godwoken 上的 Polyjuice》
撰文：Xuejie Xiao

在研究 Godwoken、Polyjuice 或其他与区块链相关的东西之前，让我们首先从过去数据库领域的故事开始说起。

几十年前，人们由于需要更好的工具来组织数据，所以 SQL 数据库 应运而生。ACID 属性 的设计是为了让数据可以在原始创建数年后，依然可以安全地写入和读取。在那个时代，一个数据库只服务于有限数量的人，一台机器（大型机，或后期强大的微型计算机）就足以支撑一个数据库。

渐渐地，电脑开始普及，互联网的爆炸式发展更是加快了这一进程。很快，单台机器已经无法为数据库提供应有的支持，于是分布式数据库开始出现。然而，CAP 定理的发现（从一致性、可用性、分区容错性这三个特性中最多只能选择两个）给软件工程师带来了巨大的挑战。最终，他们被迫在 CP 和 AP 数据库之间做出选择。为了方便参考，我们用一个简单的（虽然是单方面的）方法来区分 CP 数据库和 AP 数据库：

• CP 数据库保证了整个分布式系统的全局一致性视图；

• AP 数据库可能为不同的逻辑部分或分区提供不同的视图。

AP 数据库，来源：https://kgrvamsi.wordpress.com/2013/05/28/riak-in-depth/

从亚马逊的 DynamoDB，再到 MongoDB 的蓬勃发展，其中有一段时间 AP 数据库受到了广泛的关注。到处都有人在呼喊： 「NoSQL 才是未来！SQL 就是一个过时的东西。」当时确实有很多人都选择了 NoSQL 解决方案来构建自己的应用程序。在当时看来，数据库的未来解决方案似乎确实就是分区的。

但故事并没有结束。几年后，AP 数据库的缺陷开始浮出水面：当人们在设计系统架构时，来自不同分区的不同视图确实会影响人们的决策。

举个例子，假设你是一个基于传统 SQL 数据库构建的开发人员，你只需要关心逻辑表和它们之间的连接即可。偶尔可能会需要更多的性能查询，但你的数据始终是保持有序的。然而在 AP 数据库中，你只配备了键值（KV）存储或文档存储。我们必须首先设计模式，但在此之上，你必须处理数据库不同分区发生的不一致写入。这大大增加了应用开发者的工作量，在很多情况下，这也会导致混乱的数据存储。

即使从 CP 数据库解决方案 DynamoDB 上线并使用至今的 AWS 来看，传统的 SQL 数据库仍然在被人们广泛使用。只有在特殊情况下，比如购物车逻辑中存在特殊的合并功能，DynamoDB 才会得到大量采用。对于日常开发者正在构建的绝大部分应用来说，AP 数据库很难作为一个很好的选择。 (责任编辑：admin)