विचार करने के लिए कई चीजें हैं, लेकिन सामान्य तौर पर मैं आपके मामले में संबंधपरक मानचित्रण को पंक्ति डेटा गेटवे पर आधारित करूंगा। पैटर्न (आरडीजी)। यदि आपके पास बहुत से अलग-अलग ऑब्जेक्ट प्रकार नहीं हैं, तो आर्किटेक्चर के लिए यह दृष्टिकोण काफी अच्छा होना चाहिए। यदि आप कैश बुक-कीपिंग को फ़ाइंडर वर्ग तक सीमित रखते हैं, तो RDG को आपके कैशिंग कार्यान्वयन को सुविधाजनक बनाना चाहिए।
यदि आपके पास समय और इच्छा है, तो मार्टिन फाउलर से एंटरप्राइज़ एप्लिकेशन आर्किटेक्चर के पैटर्न देखें . यह बहुत अच्छी जानकारी है।
अब बारीकियों पर...
- किसी प्रकार की आईडी से डेटा की पहचान करें
आमतौर पर आप इसके लिए डेटाबेस में कुछ ऑटो-इन्क्रिमेंटेड इंटीजर कॉलम का उपयोग करेंगे। आप उन वस्तुओं को कैश से जल्दी से खींचने के लिए unordered_map का उपयोग कर सकते हैं। चूंकि आपके कैश में सभी ऑब्जेक्ट हैं, अनुकूलन के लिए, आप कुछ find* भी लागू कर सकते हैं पहले कैश को खोजने के लिए कार्य करता है। यदि आपका खोज समय अत्यधिक प्रतिबंधित है, तो आप कुछ डेटा को 'अनुक्रमित' करने के लिए unordered_map/unordered_multimap का उपयोग कर सकते हैं, या बस अच्छे पुराने मानचित्र/मल्टीमैप से चिपके रहें। हालांकि, यह काम को दोगुना कर रहा है, और आपके पास पहले से ही इस तरह के प्रश्नों के डेटाबेस में मुफ्त में है।
- संचित डेटा/वस्तुओं को संपादित करें
जब तक आप वास्तव में इसे डेटाबेस में नहीं लिखते हैं, तब तक गंदा डेटा शेष सिस्टम को दिखाई नहीं देना चाहिए। एक बार जब आप अपडेट को किक करते हैं, और यदि सब कुछ इरादा के अनुसार हो जाता है, तो आप या तो कैश में ऑब्जेक्ट को अपडेट के लिए उपयोग किए गए ऑब्जेक्ट से बदल सकते हैं, या केवल कैश में ऑब्जेक्ट को हटा सकते हैं और अन्य पाठकों को इसे डेटाबेस से लेने दे सकते हैं (जिसका परिणाम होगा वस्तु को फिर से कैशिंग में)। आप मूल गेटवे ऑब्जेक्ट को क्लोन करके इसे लागू कर सकते हैं, लेकिन लब्बोलुआब यह है कि आपके पास कुछ लॉकिंग रणनीति लागू होनी चाहिए।
- पुराना डेटा/ऑब्जेक्ट हटाएं और नया डेटा/ऑब्जेक्ट जोड़ें
यहां आप केवल कैश से ऑब्जेक्ट को हटाते हैं, और डेटाबेस से हटाने का प्रयास करते हैं। यदि डेटाबेस में विलोपन विफल हो जाता है, तो अन्य पाठक इसे कैश कर देंगे। बस यह सुनिश्चित करें कि जब आप हटाने की प्रक्रिया में हों तो कोई भी ग्राहक उसी रिकॉर्ड तक नहीं पहुंच सकता। नए रिकॉर्ड जोड़ते समय, आप बस गेटवे ऑब्जेक्ट को इंस्टेंट करते हैं, इसे डोमेन स्तर ऑब्जेक्ट में पास करते हैं, और जब आप परिवर्तन कर लेते हैं, तो गेटवे ऑब्जेक्ट पर कॉल इंसर्ट करें। आप या तो नए गेटवे ऑब्जेक्ट को कैश में डाल सकते हैं, या बस पहले पाठक को इसे कैश में डालने दें।
- डेटा को किसी प्रकार की प्राथमिकता के आधार पर क्रमित करें (अंतिम बार उपयोग किया गया)
- प्रदान की गई जानकारी के आधार पर डेटा/ऑब्जेक्ट्स को कैश करने का सबसे अच्छा तरीका क्या होगा और क्यों?
यह सबसे अच्छा कैशिंग एल्गोरिथम चुनने का मामला है। इसका उत्तर देना आसान प्रश्न नहीं है, लेकिन LRU को ठीक काम करना चाहिए। वास्तविक मेट्रिक्स के बिना, कोई सही उत्तर नहीं है, लेकिन एलआरयू लागू करना आसान है और यदि यह आपकी आवश्यकताओं के अनुरूप नहीं है, तो बस मेट्रिक्स करें और एक नया एल्गोरिदम तय करें। सुनिश्चित करें कि कैश के लिए एक अच्छा इंटरफ़ेस होने से आप इसे मूल रूप से कर सकते हैं। ध्यान रखने वाली एक और बात यह है कि आपके डोमेन स्तर की वस्तुएं कभी भी आपके कैश की सीमा पर निर्भर नहीं होनी चाहिए। यदि आपको 100k ऑब्जेक्ट की आवश्यकता है, लेकिन आपके पास केवल 50k कैश है, तो आपके पास अभी भी सभी 100k ऑब्जेक्ट मेमोरी में हैं, लेकिन उनमें से 50k कैश में हैं। दूसरे शब्दों में, आपकी वस्तुओं को आपके कैश की स्थिति पर निर्भर नहीं होना चाहिए, और यह भी परवाह नहीं करनी चाहिए कि आपके पास कैशिंग है या नहीं।
इसके बाद, यदि आप अभी भी आरडीजी के विचार से रोक रहे हैं, तो आप बस अपने कैश में गेटवे ऑब्जेक्ट को कैश कर रहे हैं। आप अपने कैश में गेटवे ऑब्जेक्ट्स के उदाहरणों को साझा_ptr के माध्यम से रख सकते हैं, लेकिन यदि आप गंदे लेखन से बचना चाहते हैं, तो आपको लॉकिंग रणनीति (आशावादी बनाम निराशावादी) पर भी विचार करना चाहिए। साथ ही, आपके सभी गेटवे (प्रत्येक तालिका के लिए एक), एक ही इंटरफ़ेस को इनहेरिट कर सकते हैं, ताकि आप अपनी बचत/लोड रणनीतियों को सामान्यीकृत कर सकें, और साथ ही, आप चीजों को सरल रखते हुए सिंगल पूल का उपयोग करने में सक्षम होंगे। (boost::pool देखें। हो सकता है कि यह कैश कार्यान्वयन में आपकी सहायता कर सके।)
एक अंतिम बिंदु:
यह एक झूठा वायदा है! :D कोई फर्क नहीं पड़ता कि आप क्या करने का निर्णय लेते हैं, सुनिश्चित करें कि यह प्रदर्शन मेट्रिक्स की एक अच्छी मात्रा पर आधारित है। यदि आप 20% तक प्रदर्शन में सुधार करते हैं, और आपने इसे करने में 2 महीने बिताए हैं, तो शायद आपके हार्डवेयर में कुछ और गीगा रैम लगाने के बारे में सोचना उचित है। अवधारणा का कुछ आसान सत्यापन योग्य प्रमाण बनाएं, जो आपको पर्याप्त जानकारी देगा कि क्या आपके कैश को लागू करने से भुगतान होता है, और यदि नहीं, तो शेल्फ से कुछ परीक्षण किए गए और विश्वसनीय समाधान आज़माएं (memcached या जैसे, जैसा कि @Layne ने पहले ही टिप्पणी की है)।
