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

Question

我们的保险库中的数据是可以管理的。最终，我们会积累大量数据。不可能为每天的交易保留这么多数据。我们希望定期归档或存储数据，以确保查询性能得到维护。

请问您是否考虑过处理大规模数据集，并有什么建议？

- Raj

Answer 1

来自corda-dev邮件列表：

是的，我们应该围绕此进行一些设计工作。正如您所指出的，现在并不是紧迫问题，但未来可能会成为一个问题。

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

我认为人们的偏好会因其资源和司法管辖区而异。让我们分别处理两个数据存储：

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

如果关注的只是查询性能，则其中一个明显的方法是将tx存储转移到可扩展的K / V存储中，例如Cassandra，托管的BigTable等。 tx存储不必与其他数据相同的RDBMS中，这只是备份单个数据库的方便之处。随着数据集的增长，可扩展的K / V存储不会真正失去查询性能，因此这也是一个不错的解决方案。

关于GDPR之类的事情，能够删除数据可能有所帮助，也可能无关紧要。与所有与GDPR相关的事物一样，没有人知道，因为欧盟没有费心定义任何答案-审计分布式分类帐可能会被视为对数据的“合法需求”，也可能不会，取决于当天案件的法官是谁。

总之，只有在将个人数据存储在分类帐上时才会成为问题，而这在今天并不是大多数用例。

- Joel