我们的保险库中的数据是可管理的。最终，我们会累积大量的音量。不可能为每天的交易保留如此大的数据。我们希望定期存档或存储数据，以便维护查询性能。
我是否知道您是否考虑过处理大型数据集以及您的建议。
答案 0 :(得分：0)
来自corda-dev邮件列表：
是的，我们应该围绕这个做一些设计工作。正如你所指出的那样，它现在不是一个紧迫的问题，但可能在将来成为一个问题。
我们当前的实施实际上是为了保持数据，即使它在分类帐上不再是“当前”。 ORM映射的保险库表更喜欢将行标记为过时而不是实际从基础数据库中删除数据。此外，事务存储没有垃圾收集或修剪的概念，因此它也不会删除数据。从了解分类账的历史以及它如何进入当前状态的角度来看，这有明显的好处，但它也带来了运营问题。
我认为人们在这里会有不同的偏好，具体取决于他们的资源和管辖范围。让我们分别处理这两个数据存储：
使关系映射表删除数据很容易，这只是一个策略更改。我们实际上发出了一个SQL DELETE调用，而不是将行标记为已删除。 交易商店比较棘手。 Corda受益于其无块设计;理论上我们可以垃圾收集旧的交易。然而，恶魔在细节中，因为对于使用SGX的节点，tx存储将被加密。因此，我们不仅需要为tx图开发并行GC，而且还要在飞地内部完全运行它。一个有趣的系统工程问题。
如果关注的只是查询性能，一个明显的举措是将tx存储转移到可扩展的K / V存储，如Cassandra，托管BigTable等。没有深层原因tx存储必须与其他存储在同一个RDBMS中对于数据，只需要一个数据库进行备份。随着数据集的增长，可扩展的K / V存储不会真正失去查询性能，因此，这也是一个很好的解决方案。
W.R.T。像GDPR这样的东西，能够删除数据可能有所帮助，也可能无关紧要。与GDPR相关的所有事情都没有人知道，因为欧盟并不愿意定义任何答案 - 审计分布式分类账可能被视为数据的“合法需求”，或者可能不是，这取决于法官在当天的身份。案件。
当个人数据存储在分类帐上时，无论如何这只是一个问题，而今天的大多数用例都不是。