不可变数据库

我不知道区块链技术最终是否会蓬勃发展，最终是否会得到广泛应用，但可以肯定的是，这种颠覆性技术引入的许多创新都会留在这里。从新的共识算法的实施，到更好的分布式网络协议的工程，以及新的密码原语、区块链技术的设计和实现，给我们带来了许多进步，即使我们最终放弃了区块链技术的永恒承诺，这些进步也会占上风。

可能占优势的一个进步是不可变的数据库。自从2018年末亚马逊的量子分类数据库(Amazon QLDB)宣布以来，我一直在想，企业中是否有使用这类数据库的利基市场。本周，我看到一篇关于开源不可变数据库ImmuDB的文章，我决定更深入地研究一下这个问题。首先是亚马逊，现在是一个开源计划，这是值得探索的事情。

不可变数据库是集中式数据库系统，其中信息以其完整性可以被密码验证的方式存储。跟踪每个数据更改，并维护更改的完整历史记录，以便可以随着时间的推移验证“数据库的完整性”。这就是我们称它们为“不可变”的原因，因为在数据存储中执行的所有更改的历史记录都会得到维护，以便无论何时发生意外或恶意修改，都可以检测、报告，在许多情况下甚至可以恢复。我强烈推荐这组常见问题解答，以便快速了解不可变数据库可以做什么和不能做什么。

不可变数据库使用可验证的加密原语和数据结构来确保存储数据的完整性。让我们以ImmuDB为例(开放源码项目稍后将详细介绍)。ImmuDB使用Merkle树存储数据并保持其完整性。因此，当我们在t0中将关键字k0与值v0相加时，数据库的Merkle Tree的根具有值h0((k0，v0)的散列)。随着我们不断向数据库添加新信息，树不断增长，树的根也不断变化。当我们在t1中将k0的值更新为v1时，树将使用新的分支进行更新，并且其根将更改为h01。无论是由于密钥的更新，还是由于新密钥中的存储数据，数据库中的每次新写入都会重复此过程。

使用此数据结构，很容易验证存储在系统中的数据的完整性。假设我们想要验证客户端A、k0和k1存储的数据的完整性。为此，我们只需要生成一个证明来验证第一个Merkle根与在数据库中添加新数据后生成的第二个Merkle根是一致的。为了生成该证明，我们将只需要(I)从Merkle根的第一版本的分支中获取节点(当客户端A添加他的数据时)；(Ii)获取在客户端B与系统交互之后在树中生成的新分支中可能的更高节点；(Iii)并且重构Merkle树的根并且检查其值是否与数据库中的当前树的值相同。因此，我们将从第一棵树中提取H01和H2，从第二棵树中提取H3和H456，并将树向上重建到根。如果获得的根等于树的第二个版本的实际根，则意味着自客户端A添加其数据以来没有更改任何数据。相反，如果在客户端A添加数据后以任何方式修改了信息，则第一棵树的H01和H2将与第二棵树中的H01和H2不同，从而导致在重新创建树到根时出现不同的根。

在本例中，使用Merkle树来验证数据的完整性，但是可以设计出更复杂的不可变数据库系统，其中可以使用其他加密原语来确保防篡改，例如Zero Knowledge Products(尽管，老实说，我不知道在许多情况下它是否可以补偿开销)。

不可变的数据库由单个实体管理，在由不同实体拥有和管理的网络中的不同节点之间不存在数据分发或复制。所以别搞错了，不可变的数据库根本不会取代区块链网络，但它们非常适合具体的用例，如下所示：

-A公司的首席信息官表示：“我想建立我自己的基于区块链的系统，以可靠地跟踪我的股票的所有变化。”

-“听起来不错，老板先生。这些更新涉及哪些实体？谁需要在这个区块链上写东西，参与者之间的信任程度是什么？“咨询公司的哈德沃克先生问道。

-“啊，不，不！就我一个人。我希望我公司的不同部门像现在一样修改数据库中的数据，但我希望跟踪所有这些更改的历史记录，这样我们的系统中就不会出现不一致的情况。更重要的是，我希望你能确保这个区块链可以容纳我业务的高交易负荷。但在这个区块链中写作的唯一公司将是我们“，博斯先生说。

-“那么，让我向您介绍不可变的数据库，您问题的解决方案”，辛勤工作人员先生胜利地结束了讲话。他的销售差一点就成交了。

我想这个玩具例子说明了我的观点。不可变数据库是我们希望从防篡改存储系统中获益而不需要区块链系统的复杂性和潜在管理费用的使用案例的理想选择，因为数据库将只由单个实体(或少数受信任的实体)写入。

实际上，我希望很快就能看到不可变的数据库应用于其中的一些用例：

不变地存储对现有应用程序数据库的敏感数据库字段(信用卡或银行帐户数据)的每次更新。

当然，我永远不会使用不可变的数据库来存储大型数据。如果我们需要为大数据提供防篡改，我们可以遵循区块链的方式：对大文件进行散列，并使用不可变的数据库跟踪该散列的变化。

实际上，我想引用Amazon QLDB文档中的一句话来结束这一节，它完美地说明了在哪里使用不可变数据库：

Amazon QLDB不是区块链或分布式分类账技术。区块链和分布式分类账技术专注于解决涉及多方的分散应用问题，在这种情况下，不可能有单个实体拥有应用，并且各方不一定完全信任对方。另一方面，QLDB是专门为需要在其拥有的应用程序中维护完整且可验证的数据更改历史的客户而构建的分类帐数据库。Amazon QLDB提供历史、不可变性和可验证性，并结合了完全托管的AWS数据库的熟悉性、可扩展性和易用性。如果您的应用程序需要去中心化，并且涉及多个不可信方，区块链解决方案可能是合适的。如果您的应用程序需要所有应用程序数据更改的完整且可验证的历史记录，但不涉及多个不可信方，Amazon QLDB是非常合适的选择。

理论说得够多了。让我们来看看一个不可变的数据库的运行情况。我将重点介绍ImmuDB，这是我在发布之初提到的开放源码项目。我们将从一段视频开始(上班前总是很放松)。

imudb是在localhost上侦听端口3322并提供GRPC接口的服务器二进制文件。

immugw是连接到imudb并为应用程序提供REST风格接口的智能REST代理。建议在不同的机器上运行imudb和immugw以增强安全性。

immuadmin是imudb和immugw的管理员CLI。您可以安装和管理这两个组件的服务安装，并获取统计信息和运行时信息。

运行ImmuDB并开始使用它的最简单方法是克隆repo，构建所有二进制文件，然后启动数据库和网关，如下所示：

您还可以使用docker运行ImmuDB。在我的情况下，我无法将网关与数据库连接起来，这就是我选择本地部署的原因。但我觉得值得一提的是。

$docker run-it-d--name imudb-p 3322：3322-p 9497：9497 codenotary/immub：Latest$docker run-it-d-p 3323：3323--name immugw--env IMMUGW_IMMUDB-address=imudb codenotary/immugw：Latest

在数据库运行的情况下，我想尝试使用SDK将ImmuDB与一个简单的应用程序集成，但显然目前只有REST API和GRPC接口可用于与系统交互。根据他们的文档，很快就会有适用于Java、.NET、Golang、Python和Node.js的驱动程序，但目前我们只能满足于使用不方便的客户端。

我们可以看到，该命令的结果是将密钥添加到数据库、数据的散列，以及是否验证了添加。如果我们不在数据库中伪造数据，我们每次添加新数据时都会得到这个。

如果您想要“恶意”修改信息，您可以转到./db(默认情况下)，然后摆弄这些文件。如果您急于查看当您尝试添加新数据而数据库已“损坏”时会发生什么情况，我邀请您这样做；)。

最后，从ImmuDB的GitHub repo中提取一些关于性能的注释(如果您想知道可以应用此技术的加载场景的话)：

各位，今天就到这里吧！我很想知道您对不可变数据库有什么看法，以及它们可能具有的潜在用途。如果我之前没有你的消息，下周见！