如何在 Corda 中处理较大的 Vault 大小？

Question

我们保管库中的数据是可以管理的。最终，我们会积累很大的数量。不可能为日常交易保留如此大的数据。我们希望定期归档或存储数据，以便维持查询性能。

我想知道您是否考虑过处理大规模数据集以及您的建议是什么。

Answer 1

从corda-dev邮件列表中：

\n\n

\n

是的，我们应该围绕这个做一些设计工作。正如您所注意到的，\xe2\x80\x99 现在不是一个紧迫的问题，但将来可能会成为一个紧迫的问题。

\n\n

我们当前的实现实际上是为了保留数据，即使它不再\xe2\x80\x98current\xe2\x80\x99在账本上。ORM 映射的保管库表更喜欢将行标记为过时，而不是实际从基础数据库中删除数据。此外，事务存储没有垃圾收集或修剪的概念，因此它也不会删除数据。从理解账本的历史及其如何进入当前状态的角度来看，这有明显的好处，但它也带来了操作问题。

\n\n

我认为人们根据自己的资源和管辖范围会有不同的偏好。让\xe2\x80\x99s 分别处理两个数据存储：

\n\n

使关系映射表删除数据很容易，\xe2\x80\x99 只是一个策略更改。我们实际上发出 SQL DELETE 调用，而不是将行标记为已消失。\n 事务存储更加棘手。Corda 受益于其无块设计；理论上我们可以对旧交易进行垃圾收集。然而，问题在于细节，因为对于使用 SGX 的节点，交易存储将被加密。因此，我们不仅需要为 tx 图开发并行 GC，而且还需要完全在 enclave 内运行它。一个有趣的系统工程问题。

\n\n

如果关心的只是查询性能，一个明显的举措是将 tx 存储转移到可扩展的 K/V 存储，如 Cassandra、托管 BigTable 等。\xe2\x80\x99s 没有深层原因 tx 存储必须位于同一个 RDBMS 中与其余数据一样，备份单个数据库很方便。随着数据集的增长，可扩展的 K/V 存储确实不会损失查询性能，因此，这也是一个不错的解决方案。

\n\n

WRT 像 GDPR 这样的事情，能够删除数据可能会有所帮助，也可能无关紧要。与 GDPR 相关的所有事情一样，没有人知道，因为欧盟没有\xe2\x80\x99 费心去定义任何答案 - 审计分布式账本可能会被视为 \xe2\x80\x9 数据的合理需求\xe2\x80\x9d，或者它可能不会，这取决于案件当天的法官是谁。

\n\n

无论如何，当个人数据存储在分类账上时，这只是一个问题，而这并不是当今的大多数用例。

\n

\n