Det finns många saker att tänka på, men generellt sett skulle jag basera relationell kartläggning i ditt fall på Row Data Gateway mönster (RDG). Om du inte har för många olika objekttyper bör denna metod för arkitektur skalas tillräckligt bra. RDG bör underlätta din cache-implementering om du begränsar cachebokföring till Finder-klassen.
Om du har tid och vilja kan du kolla in Patterns of Enterprise Application Architecture från Martin Fowler . Det är en brunn med bra information.
Nu till detaljerna...
- identifiera data med någon sorts id
Vanligtvis skulle du använda någon automatiskt inkrementerad heltalskolumn i databasen för detta. Du kan använda unordered_map för att dra dessa objekt från cachen snabbt. Eftersom du har alla objekt i din cache, för optimeringens skull, kan du också implementera några av find* funktioner för att söka i cachen först. Du kan använda unordered_map/unordered_multimap för att "indexera" en del av data, om din söktid är mycket begränsad, eller bara hålla dig till den gamla goda kartan/multimapen. Men detta fördubblar arbetet, och du har det redan gratis i databasen av den här typen av frågor.
- redigera cachade data/objekt
Smutsiga data bör inte vara synliga för resten av systemet förrän du faktiskt skriver det till databasen. När du startar uppdateringen, och om allt går som det är tänkt, kan du antingen ersätta objektet i cachen med det du använde för uppdateringen, eller helt enkelt ta bort objektet i cachen och låta andra läsare plocka upp det från databasen (vilket kommer att resultera i vid cachelagring av objektet igen). Du kan implementera detta genom att klona det ursprungliga Gateway-objektet, men slutsatsen är att du bör ha en låsstrategi implementerad.
- ta bort gamla data/objekt och lägg till nya data/objekt
Här tar du helt enkelt bort objekt från cachen och försöker ta bort från databasen. Om raderingen misslyckas i databasen kommer andra läsare att cache den. Se bara till att ingen klient kan komma åt samma post medan du håller på att radera. När du lägger till nya poster instansierar du helt enkelt Gateway-objektet, skickar det till domännivåobjektet och när du är klar med ändringarna, anropar du infoga på Gateway-objektet. Du kan antingen lägga det nya Gateway-objektet i cachen eller helt enkelt låta den första läsaren lägga in det i cachen.
- ordna data efter någon sorts prioritet (senast använd)
- Vad skulle vara det bästa sättet att cachelagra data/objekt baserat på den tillhandahållna informationen OCH VARFÖR?
Detta handlar om att välja den bästa cachingalgoritmen. Det här är ingen lätt fråga att svara på, men LRU borde fungera bra. Utan faktiska mätvärden finns det inget rätt svar, men LRU är enkel att implementera och om den inte uppfyller dina krav, gör bara mätvärdena och bestäm dig för en ny algoritm. Se till att du kan göra det sömlöst genom att ha ett bra gränssnitt till cachen. En annan sak att tänka på är att dina domännivåobjekt aldrig bör bero på gränserna för din cache. Om du behöver 100 000 objekt, men du har bara 50 000 cache, har du fortfarande alla 100 000 objekt i minnet, men 50 000 av dem finns i cachen. Med andra ord, dina objekt bör inte bero på tillståndet i din cache, och bör inte heller bry sig om du har caching alls.
Därefter, om du fortfarande släpper med idén om RDG, cachelagrar du helt enkelt Gateway-objekt i din cache. Du kan behålla instanser av Gateway-objekten i din cache med hjälp av shared_ptr, men bör också överväga din låsstrategi (optimistisk kontra pessimistisk), om du vill undvika smutsiga skrivningar. Dessutom kan alla dina gateways (en för varje bord) ärva samma gränssnitt, så att du kan generalisera dina spara/laddningsstrategier, och du skulle också kunna använda en enda pool samtidigt som du håller saker enkelt. (Kolla in boost::pool. Kanske kan det hjälpa dig med cacheimplementeringen.)
En sista punkt:
Kakan är en lögn! :D Oavsett vad du bestämmer dig för att göra, se till att det är baserat på en anständig mängd prestationsmått. Om du förbättrar prestandan med 20%, och du tillbringade 2 månader på att göra det, kanske det är värt att tänka på att lägga några fler spelningar med RAM till din hårdvara. Gör några lätta verifierbara proof of concept, som ger dig tillräckligt med information om huruvida implementeringen av din cache lönar sig, och om inte, prova några av de testade och pålitliga lösningarna från hyllan (memcachade eller liknande, som @Layne redan har kommenterat).