Jest wiele rzeczy do rozważenia, ale generalnie mapowanie relacyjne w twoim przypadku opierałbym na Row Data Gateway wzór (RDG). Jeśli nie masz zbyt wielu różnych typów obiektów, to podejście do architektury powinno być wystarczająco skalowalne. RDG powinno ułatwić implementację pamięci podręcznej, jeśli ograniczysz księgowanie pamięci podręcznej do klasy Finder.
Jeśli masz czas i wolę, zapoznaj się z Wzorami architektury aplikacji korporacyjnych autorstwa Martina Fowlera . To źródło dobrych informacji.
Teraz do konkretów...
- zidentyfikuj dane za pomocą jakiegoś identyfikatora
Zazwyczaj używa się do tego w bazie danych kolumny z automatycznie zwiększanymi liczbami całkowitymi. Możesz użyć unordered_map, aby szybko wyciągnąć te obiekty z pamięci podręcznej. Ponieważ masz wszystkie obiekty w pamięci podręcznej, ze względu na optymalizację możesz również zaimplementować niektóre z funkcji find* funkcje, aby najpierw przeszukać pamięć podręczną. Możesz użyć unordered_map/unordered_multimap do "indeksowania" niektórych danych, jeśli Twój czas wyszukiwania jest bardzo ograniczony, lub po prostu trzymaj się starej dobrej mapy/multimap. Jest to jednak podwojenie pracy i masz już za darmo w bazie danych tego rodzaju zapytania.
- edytuj dane/obiekty w pamięci podręcznej
Brudne dane nie powinny być widoczne dla reszty systemu, dopóki nie zapiszesz ich w bazie danych. Po wykopaniu aktualizacji i jeśli wszystko pójdzie zgodnie z planem, możesz albo zastąpić obiekt w pamięci podręcznej tym, którego użyłeś do aktualizacji, albo po prostu usunąć obiekt z pamięci podręcznej i pozwolić innym czytelnikom pobrać go z bazy danych (co spowoduje w buforowaniu obiektu ponownie). Możesz to zaimplementować, klonując oryginalny obiekt Gateway, ale najważniejsze jest to, że powinieneś mieć zaimplementowaną jakąś strategię blokowania.
- usuń stare dane/obiekty i dodaj nowe dane/obiekty
Tutaj po prostu usuwasz obiekt z pamięci podręcznej i próbujesz usunąć z bazy danych. Jeśli usunięcie w bazie danych nie powiedzie się, inne czytniki będą ją buforować. Tylko upewnij się, że żaden klient nie ma dostępu do tego samego rekordu, gdy jesteś w trakcie usuwania. Podczas dodawania nowych rekordów po prostu tworzysz wystąpienie obiektu Gateway, przekazujesz go do obiektu na poziomie domeny, a kiedy skończysz ze zmianami, wywołujesz insert w obiekcie Gateway. Możesz umieścić nowy obiekt bramy w pamięci podręcznej lub po prostu pozwolić pierwszemu czytelnikowi umieścić go w pamięci podręcznej.
- uporządkuj dane według pewnego rodzaju priorytetu (ostatnio używane)
- Jaki byłby najlepszy sposób na buforowanie danych/obiektów na podstawie dostarczonych informacji I DLACZEGO?
To kwestia wyboru najlepszego algorytmu buforowania. Nie jest to łatwe pytanie, ale LRU powinno działać dobrze. Bez rzeczywistych metryk nie ma właściwej odpowiedzi, ale LRU jest proste do wdrożenia i jeśli nie spełnia Twoich wymagań, po prostu wykonaj metryki i zdecyduj się na nowy algorytm. Upewnij się, że możesz to zrobić bezproblemowo, mając dobry interfejs do pamięci podręcznej. Jeszcze jedną rzeczą, o której należy pamiętać, jest to, że obiekty na poziomie domeny nigdy nie powinny zależeć od ograniczeń pamięci podręcznej. Jeśli potrzebujesz 100k obiektów, ale masz tylko 50k pamięci podręcznej , nadal masz wszystkie 100k obiektów w pamięci, ale 50k z nich jest w pamięci podręcznej. Innymi słowy, twoje obiekty nie powinny zależeć od stanu twojej pamięci podręcznej, a także nie powinno obchodzić cię, czy w ogóle masz pamięć podręczną.
Następnie, jeśli nadal obnażasz ideę RDG, po prostu buforujesz obiekt Gateway w swojej pamięci podręcznej. Możesz przechowywać instancje obiektów Gateway w swojej pamięci podręcznej za pomocą shared_ptr, ale powinieneś również rozważyć strategię blokowania (optymistyczną vs pesymistyczną), jeśli chcesz uniknąć brudnych zapisów. Ponadto wszystkie Twoje bramy (po jednej dla każdej tabeli) mogą dziedziczyć ten sam interfejs, dzięki czemu możesz uogólnić strategie zapisywania/ładowania, a także możesz korzystać z jednej puli, zachowując przy tym prostotę. (Sprawdź boost::pool. Może to pomoże ci w implementacji pamięci podręcznej.)
Ostatni punkt:
Ciasto jest kłamstwem! :D Bez względu na to, co zdecydujesz się zrobić, upewnij się, że opiera się to na przyzwoitej ilości wskaźników wydajności. Jeśli poprawisz wydajność o 20%, a poświęciłeś na to 2 miesiące, może warto pomyśleć o dodaniu kilku gigabajtów pamięci RAM do swojego sprzętu. Zrób łatwy weryfikowalny dowód koncepcji, który da ci wystarczającą ilość informacji, czy wdrożenie pamięci podręcznej się opłaca, a jeśli nie, wypróbuj niektóre z przetestowanych i niezawodnych rozwiązań z półki (memcached lub takie, jak już skomentował @Layne).
