2010-07-25 12 views
5

Ich versuche, ein Datenmodell zu entwerfen, die eine sehr große Menge an Daten aufnehmen können, haben jemand mit Erfahrung in großen Datenmengen über jedes Feedback zu diesem Thema, das heißt:Transaktionen über sehr sehr große Entitätsgruppe

// 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; 
} 

Basierend auf dem, was ich gelesen habe, ist die einzige Möglichkeit, transaktionale Integrität beim Einfügen eines Transaction und Aktualisieren balance erhalten, es zu einer Entitätsgruppe zu machen.

Allerdings würde es im Laufe der Zeit Millionen von Transaktionen für eine bestimmte TransactionAccount. Die Anzahl der Schreibvorgänge in dieser Entitätsgruppe wäre niedrig, aber die Lesevorgänge wären viel höher.

Ich weiß, es könnte möglicherweise sharded, aber das Lesen der balance ist eine sehr häufige Operation, und sharding es würde eine der häufigsten Operationen machen getBalance() die langsamste Operation.

+0

Es gibt eine [Follow-up-Frage] (http://stackoverflow.com/questions/3342603/how-do-you-propery-add-manipulate-thousands-of-children-in-entity-group) diskutieren [wie man verwaltet] (http://stackoverflow.com/questions/3342603/how-do-you-propery-add-manipulate-thousands-of-children-in-antitity-group) eine Entitätsgruppe mit Zehnen von Tausenden von Kinderobjekten. – Jacob

Antwort

3

Die Anordnung, die Sie beschreiben, sollte gut funktionieren. Wenn Ihre Entitätsgruppe übermäßig groß wird (wir sprechen Hunderte von Megabytes an Transaktionen, bevor dies zu einem Problem wird), könnten Sie eine Prozedur schreiben, um alte Transaktionen "aufzurollen": Ersetzen Sie einen Satz alter Transaktionsdatensätze transaktionsweise durch einen einzigen die Summe dieser Transaktionen, um die Invariante zu erhalten, dass der Saldo gleich der Summe aller Transaktionen ist. Wenn Sie noch einen Datensatz dieser alten, "zusammengerollten" Transaktionen speichern müssen, können Sie diese in einer separaten Entitätsgruppe kopieren, bevor Sie den Roll-up durchführen.

+1

Dies ist eine ausgezeichnete Idee, Sie könnten zum Beispiel eine "cron" Aufgabe haben, die nach Entitäten mit mehr als X Datensätzen sucht und dann einfach die ältesten X Transaktionen in eine andere Entitätsgruppe verschiebt. – corydoras

+0

Nur neugierig, wo bekommen Sie die Zahl "Hunderte von Megabyte" als Richtlinie? Wäre es nicht zu viel, ein "Transaction" -Objekt in den Speicher zu laden, das 100Mb Daten enthält? – corydoras

+1

Mit Hunderten von Megabyte, meine ich die Größe der Entity-Gruppe als Ganzes - das Konto und alle seine Transaktionen - nicht die Größe einer einzelnen Entität. Ich bekomme die Hunderten von Megabyte-Richtlinie aus meiner eigenen Erfahrung als Bigtable-Administrator. :) –

2

Sie haben richtig gelesen, dass Transaction und TransactionAccount in der gleichen Entitätsgruppe sein müssen, um die transaktionale Einfüge- und Aktualisierungsoperation auszuführen.

Der Grund für shard ist, Schreibkonflikte zu reduzieren, aber Sie sagen, dass dies eine niedrige Schreibeinheit sein wird, so dass hier kein Sharding benötigt wird.

Um die Größe Ihrer Entitätsgruppen gering zu halten, können Sie einen Archivierungsprozess einrichten. Wenn dies beispielsweise für ein Bankkonto gilt, können Sie bei der Erstellung der Monatsrechnung die Transaktionen dieses Monats archivieren.

+1

Dies ist in der Nähe, aber eine Monatsgrenze ist möglicherweise nicht der beste Weg, um es zu tun .. wie in Spitzenzeiten kann viel in einem Monat passieren. – corydoras