2010-07-25 9 views
5

próbuję zaprojektować model danych, który może pomieścić bardzo dużą ilość danych, czy ktoś z doświadczeniem w dużych ilości danych mają jakieś opinie na ten temat, a mianowicie:Transakcje powyżej bardzo dużej grupy podmiotów

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

Na podstawie tego, co przeczytałem, jedynym sposobem uzyskania integralności transakcyjnej przy wstawianiu Transaction i aktualizowaniu balance jest utworzenie jednej grupy encji.

Jednak z biegiem czasu będą miliony transakcji dla określonego TransactionAccount. Liczba zapisów do tej grupy encji byłaby niska, ale odczyty byłyby znacznie wyższe.

Wiem, że można go było zignorować, jednak odczytanie balance jest bardzo częstą operacją, a odłamanie go spowodowałoby jedną z najczęstszych operacji.

+0

Istnieje [pytanie uzupełniające] (http://stackoverflow.com/questions/3342603/how-do-you-propery-add-manipulate-thousands-of-children-in-an-entity-group) dyskusja [jak zarządzać] (http://stackoverflow.com/questions/3342603/how-do-you-propery-add-manipulate-thousands-cho-children-in-an-entity-group) grupa encji z dziesiątkami tysięcy obiektów dzieci. – Jacob

Odpowiedz

3

Opisany układ powinien działać poprawnie. Jeśli twoja grupa podmiotów rośnie nadmiernie (mówimy o setkach megabajtów transakcji, zanim stanie się to problemem), możesz napisać procedurę "zwijania" starych transakcji: transakcyjnie zastąpić zestaw starych rekordów transakcji pojedynczym dla suma tych transakcji, aby utrzymać niezmienność, że saldo jest równe sumie wszystkich transakcji. Jeśli nadal chcesz przechowywać zapis tych starych, "zwiniętych" transakcji, możesz zrobić ich kopię w oddzielnej grupie jednostek, zanim dokonasz zrolowania.

+1

To jest doskonały pomysł, możesz na przykład mieć zadanie "cron", które sprawdza podmioty z więcej niż X rekordami, a następnie po prostu przenosi najstarsze X transakcji do innej grupy encji. – corydoras

+0

Po prostu ciekawa, skąd bierzesz "setki megabajtów" jako wytyczną? Czy nie byłoby zbyt wielkim zajęciem obiektu "Transakcja" do pamięci zawierającej 100 Mb danych? – corydoras

+1

Przez setki megabajtów mam na myśli wielkość grupy encji jako całości - konta i wszystkich transakcji - a nie wielkości pojedynczego podmiotu. Dostaję setki megabajtów z moich własnych doświadczeń jako administratora BigTable. :) –

2

Masz rację, że Transaction i TransactionAccount muszą należeć do tej samej grupy encji, aby można było przeprowadzić transakcję wstawiania i aktualizacji.

Powodem przeniesienia jest zmniejszenie liczby sporów dotyczących zapisu, ale mówisz, że będzie to obiekt o niskim współczynniku zapisu, więc nie ma potrzeby stosowania odłamków.

Aby zmniejszyć rozmiar grup encji, można przeprowadzić pewien proces archiwizacji. Na przykład, jeśli jest to konto bankowe, to podczas generowania wyciągu miesięcznego można zarchiwizować transakcje z tego miesiąca.

+1

To jest blisko, jednak granica miesiąca może nie być najlepszym sposobem na zrobienie tego .. jak w szczytowych okresach wiele może się wydarzyć w ciągu miesiąca. – corydoras

Powiązane problemy