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