基于我读过的内容，获取插入时事务完整性的唯一方法一个交易和更新余额就是让它成为一个实体组。
然而，随着时间的推移，对于特定的 TransactionAccount 将有数百万笔交易。写入这个实体组的次数会很少，但读取次数会更多。
我知道它可能会被分割，但是读取余额是一个非常频繁的操作，并且分解它会使得最常见的操作之一是最慢的操作 getBalance（）。 >
解决方案你所描述的安排应该可以正常工作。如果您的实体组增长过大（我们在讨论数百兆事务之前就成为问题），那么您可以编写一个过程来滚动旧的事务：事务性地用一个旧事务记录替换一组旧事务记录这些交易的总和，以保持余额等于所有交易总和的不变。如果您仍然需要存储这些旧的卷起交易记录，则可以在执行汇总之前将其复制到单独的实体组中。
I am trying to design a data model which can hold a very large amount of data, does anyone with experience in large volumes of data have any feedback on this, ie:
// example only, not meant to compile public class TransactionAccount { private long balance; private List<Transaction> transactions = new ArrayList<Transaction>(); .... public long getBalance() { return balance; } } private class Transaction { public Date date; public long amount; }Based on what I have read, the only way to get transactional integrity on inserting a Transaction and updating balance is to make it one entity group.
However over time there would be millions of transactions for a particular TransactionAccount. The number of writes to this entity group would be low, but the reads would be much higher.
I know it could possibly be sharded, however reading the balance is a very frequent operation, and sharding it would make one of the most common operations getBalance() the slowest operation.
解决方案The arrangement you describe should work fine. If your entity group grows excessively big (we're talking hundreds of megabytes of transactions before this becomes an issue), you could write a procedure to 'roll up' old transactions: transactionally replace a set of old transaction records with a single one for the sum of those transactions, in order to maintain the invariant that the balance is equal to the sum of all transactions. If you still need to store a record of these old, 'rolled up' transactions, you can make a copy of them in a separate entity group before you perform the roll-up.
更多推荐
事务处理非常非常大的实体组
发布评论