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