Der er mange ting at overveje, men generelt vil jeg basere relationel kortlægning i dit tilfælde på Row Data Gateway mønster (RDG). Hvis du ikke har for mange forskellige objekttyper, bør denne tilgang til arkitektur skalere godt nok. RDG bør lette din cache-implementering, hvis du begrænser cache-bogføring til Finder-klassen.
Hvis du har tid og vilje, så tjek Patterns of Enterprise Application Architecture fra Martin Fowler . Det er en brønd med god information.
Nu til detaljerne...
- identificer dataene ved en slags id
Typisk vil du bruge en auto-inkrementeret heltalskolonne i databasen til dette. Du kan bruge unordered_map til at trække disse objekter fra cachen hurtigt. Da du har alle objekterne i din cache, kan du af hensyn til optimeringen også implementere nogle af find* funktioner til at søge i cachen først. Du kan bruge unordered_map/unordered_multimap til at 'indeksere' nogle af dataene, hvis din søgetid er meget begrænset, eller bare holde dig til det gode gamle kort/multimap. Dette er dog en fordobling af arbejdet, og du har det allerede gratis i databasen af den slags forespørgsler.
- rediger de cachelagrede data/objekter
Beskidte data bør ikke være synlige for resten af systemet, før du rent faktisk skriver det til databasen. Når du først sparker opdateringen, og hvis alt går efter hensigten, kan du enten erstatte objektet i cachen med det, du brugte til opdateringen, eller blot slette objektet i cachen og lade andre læsere hente det fra databasen (hvilket vil resultere i ved at cache objektet igen). Du kan implementere dette ved at klone det originale Gateway-objekt, men bundlinjen er, at du bør have implementeret en låsestrategi.
- slet gamle data/objekter og tilføj nye data/objekter
Her sletter du blot objekt fra cache, og forsøger at slette fra databasen. Hvis sletningen mislykkes i databasen, vil andre læsere cache den. Bare sørg for, at ingen klient kan få adgang til den samme post, mens du er i gang med at slette. Når du tilføjer nye poster, instansierer du blot Gateway-objektet, sender det til domæneniveauobjektet, og når du er færdig med ændringerne, kalder du indsæt på Gateway-objektet. Du kan enten lægge det nye Gateway-objekt i cachen eller blot lade den første læser lægge det ind i cachen.
- ordner dataene efter en eller anden form for prioritet (sidst brugt)
- Hvad ville være den bedste måde at cache dataene/objekterne på baseret på de angivne oplysninger, OG HVORFOR?
Dette er et spørgsmål om at vælge den bedste cachingalgoritme. Dette er ikke et let spørgsmål at besvare, men LRU burde fungere fint. Uden egentlige målinger er der ikke noget rigtigt svar, men LRU er enkel at implementere, og hvis den ikke opfylder dine krav, skal du bare lave metrik og beslutte dig for en ny algoritme. Sørg for, at du kan gøre det problemfrit ved at have en god grænseflade til cachen. En anden ting at huske på er, at dine domæneniveauobjekter aldrig bør afhænge af grænserne for din cache. Hvis du har brug for 100k objekter, men du kun har 50k cache, har du stadig alle 100k objekter i hukommelsen, men 50k af dem er i cachen. Med andre ord bør dine objekter ikke afhænge af tilstanden af din cache, og de bør heller ikke være ligeglade med, om du overhovedet har caching.
Dernæst, hvis du stadig blotter med ideen om RDG, cacher du simpelthen Gateway-objektet i din cache. Du kan beholde forekomster af Gateway-objekterne i din cache ved hjælp af shared_ptr, men bør også overveje din låsestrategi (optimistisk vs pessimistisk), hvis du vil undgå beskidte skrivninger. Alle dine Gateways (en for hvert bord) kan også arve den samme grænseflade, så du kan generalisere dine gemme/indlæse strategier, og du ville også være i stand til at bruge en enkelt pool, mens du holder tingene enkle. (Tjek boost::pool. Måske kan det hjælpe dig med cache-implementeringen.)
Et sidste punkt:
Kagen er en løgn! :D Uanset hvad du beslutter dig for at gøre, så sørg for, at det er baseret på en anstændig mængde præstationsmålinger. Hvis du forbedrer ydeevnen med 20%, og du brugte 2 måneder på at gøre det, er det måske en god idé at tænke på at lægge et par ekstra koncerter RAM til din hardware. Lav nogle nemme verificerbare proof of concept, som vil give dig nok information, om implementering af din cache betaler sig, og hvis ikke, prøv nogle af de testede og pålidelige løsninger fra hylden (memcached eller sådan, som @Layne allerede har kommenteret).