Има много неща за обмисляне, но като цяло бих базирал релационното картографиране във вашия случай на шлюза за данни на редове модел (RDG). Ако нямате твърде много различни типове обекти, този подход към архитектурата трябва да се мащабира достатъчно добре. RDG трябва да улесни реализацията ви на кеширане, ако ограничите воденето на кеша до класа Finder.
Ако имате време и желание, разгледайте Модели на архитектурата на корпоративни приложения от Мартин Фаулър . Това е кладенец с добра информация.
Сега към подробностите...
- идентифицирайте данните по някакъв идентификатор
Обикновено бихте използвали някаква автоматично увеличена целочислена колона в базата данни за това. Можете да използвате unordered_map за бързо изтегляне на тези обекти от кеша. Тъй като имате всички обекти в кеша си, в името на оптимизацията можете също да внедрите някои от find* функции за търсене първо в кеша. Можете да използвате unordered_map/unordered_multimap, за да „индексирате“ някои от данните, ако времето ви за търсене е силно ограничено, или просто да се придържате към добрата стара карта/мултикарта. Това обаче удвоява работата и вече я имате безплатно в базата данни от тези видове заявки.
- редактирайте кешираните данни/обекти
Мръсните данни не трябва да се виждат за останалата част от системата, докато не ги запишете в базата данни. След като пуснете актуализацията и ако всичко върви по предназначение, можете или да замените обекта в кеша с този, който сте използвали за актуализация, или просто да изтриете обекта в кеша и да оставите други читатели да го вземат от базата данни (което ще доведе до при повторно кеширане на обекта). Можете да приложите това, като клонирате оригиналния обект на Gateway, но в крайна сметка трябва да приложите някаква стратегия за заключване.
- изтрийте стари данни/обекти и добавете нови данни/обекти
Тук просто изтривате обект от кеша и се опитвате да изтриете от базата данни. Ако изтриването не успее в базата данни, други четци ще я кешират. Просто се уверете, че никой клиент няма достъп до същия запис, докато сте в процес на изтриване. Когато добавяте нови записи, вие просто създавате инстанция на обекта Gateway, предавате го на обекта на ниво домейн и когато сте готови с промените, извиквате insert на обекта Gateway. Можете или да поставите новия обект Gateway в кеша, или просто да оставите първия четец да го постави в кеша.
- подредете данните по някакъв вид приоритет (последно използван)
- Какъв би бил най-добрият начин за кеширане на данните/обектите въз основа на предоставената информация И ЗАЩО?
Това е въпрос на избор на най-добрия алгоритъм за кеширане. Отговорът на този въпрос не е лесен, но LRU трябва да работи добре. Без действителни показатели няма правилен отговор, но LRU е лесен за прилагане и ако не отговаря на вашите изисквания, просто направете метриките и вземете нов алгоритъм. Уверете се, че можете да направите това безпроблемно, като имате добър интерфейс към кеша. Друго нещо, което трябва да имате предвид, е, че вашите обекти на ниво домейн никога не трябва да зависят от ограниченията на вашия кеш. Ако имате нужда от 100k обекта, но имате само 50k кеш, все още имате всички 100k обекта в паметта, но 50k от тях са в кеша. С други думи, вашите обекти не трябва да зависят от състоянието на кеша ви и също така не трябва да се интересуват дали изобщо имате кеширане.
След това, ако все още не сте с идеята за RDG, вие просто кеширате Gateway обект във вашия кеш. Можете да съхранявате екземпляри на обектите на Gateway във вашия кеш с помощта на shared_ptr, но също така трябва да вземете предвид стратегията си за заключване (оптимистично срещу песимистично), ако искате да избегнете мръсни записи. Освен това всичките ви шлюзове (по един за всяка таблица) могат да наследят един и същ интерфейс, така че можете да обобщите вашите стратегии за запис/зареждане, а също така ще можете да използвате един пул, като същевременно поддържате нещата прости. (Вижте boost::pool. Може би може да ви помогне с внедряването на кеша.)
Една последна точка:
Тортата е лъжа! :D Независимо какво решите да направите, уверете се, че се основава на прилично количество показатели за ефективност. Ако подобрите производителността с 20% и сте прекарали 2 месеца в това, може би си струва да помислите за поставянето на още няколко гига RAM към вашия хардуер. Направете някакво лесно проверимо доказателство на концепцията, което ще ви даде достатъчно информация дали внедряването на вашия кеш се изплаща, а ако не, опитайте някои от изпитаните и надеждни решения на пазара (memcached или нещо подобно, както вече коментира @Layne).
