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

Question

我们的vault中的数据是可管理的。最终，我们会积累一个很大的体积。不可能为每天的事务保留如此大的数据。我们希望定期对数据进行归档或入库，以便保持查询性能。

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

Answer 1

在corda-dev邮件列表中：

是的，我们应该围绕这个问题做一些设计工作。正如你所指出的，这现在不是一个紧迫的问题，但将来可能会成为一个。

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

我认为人们在这里会有不同的偏好，这取决于他们的资源和司法管辖权。让我们分别处理这两个数据存储：

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

如果只关心查询性能，一个明显的举措是将tx存储转换为可扩展的K/V存储，如Cassandra、hosted BigTable等。tx存储必须与其余数据位于相同的关系型数据库中没有深层次的原因，只需有一个数据库来备份即可。可伸缩的K/V存储并不会随着数据集的增长而真正降低查询性能，因此，这也是一个很好的解决方案。

像GDPR这样的W.R.T.功能，能够删除数据可能会有所帮助，也可能无关紧要。至于所有与GDPR相关的事情，没有人知道，因为欧盟没有费心定义任何答案-审计分布式账本可能算作对数据的“合法需求”，也可能不算作，这取决于案件当天的法官是谁。

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