हाइबरनेट में डेटा कैशिंग

अपना कैशिंग समाधान कभी न लिखें

डेटाबेस के साथ काम को गति देने का दूसरा तरीका उन वस्तुओं को कैश करना है जिन्हें हमने पहले ही अनुरोध किया है।

महत्वपूर्ण! अपना स्वयं का कैशिंग समाधान कभी न लिखें। इस कार्य में इतने नुकसान हैं कि आपने कभी सपने में भी नहीं सोचा होगा।

अंक 1 - कैश फ्लश । कभी-कभी घटनाएँ तब होती हैं जब किसी वस्तु को कैश से निकालने या कैश में अपडेट करने की आवश्यकता होती है। ऐसा करने का एकमात्र तरीका कैश इंजन के माध्यम से डेटाबेस के सभी अनुरोधों को पास करना है। अन्यथा, हर बार आपको कैश को स्पष्ट रूप से बताना होगा कि इसमें कौन से ऑब्जेक्ट हटाए या अपडेट किए जाने चाहिए।

समस्या 2 - स्मृति की कमी . कैशिंग तब तक एक अच्छा विचार प्रतीत होता है जब तक आप पाते हैं कि स्मृति में ऑब्जेक्ट्स बहुत अधिक जगह लेते हैं। सर्वर एप्लिकेशन कैश के प्रभावी ढंग से काम करने के लिए आपको अतिरिक्त दस गीगाबाइट मेमोरी की आवश्यकता है।

और चूंकि हमेशा स्मृति की कमी होती है, कैश से वस्तुओं को हटाने के लिए प्रभावी रणनीति की आवश्यकता होती है। यह कुछ हद तक जावा में कचरा संग्राहक के समान है। और जैसा कि आपको याद है, दशकों से, सबसे अच्छे दिमाग पीढ़ियों से वस्तुओं को चिह्नित करने के विभिन्न तरीकों का आविष्कार कर रहे हैं, आदि।

समस्या 3 - विभिन्न रणनीतियाँ । जैसा कि अभ्यास से पता चलता है, अलग-अलग वस्तुओं के लिए कैश में स्टोर करने और अपडेट करने की अलग-अलग रणनीतियाँ प्रभावी होती हैं। एक कुशल कैशिंग प्रणाली सभी वस्तुओं के लिए केवल एक रणनीति नहीं कर सकती है।

समस्या 4 - का कुशल भंडारण । आप केवल वस्तुओं को कैश में स्टोर नहीं कर सकते। वस्तुओं में अक्सर अन्य वस्तुओं के संदर्भ होते हैं, और इसी तरह। इस दर पर, आपको कचरा संग्राहक की आवश्यकता नहीं होगी: इसमें हटाने के लिए कुछ भी नहीं होगा।

इसलिए, वस्तुओं को स्वयं संग्रहीत करने के बजाय, कभी-कभी उनके आदिम क्षेत्रों के मूल्यों को संग्रहीत करना अधिक कुशल होता है। और उनके आधार पर वस्तुओं के त्वरित निर्माण के लिए सिस्टम।

नतीजतन, आपको मेमोरी में एक संपूर्ण वर्चुअल DBMS मिलेगा, जो जल्दी से काम करेगा और कम मेमोरी का उपभोग करेगा।

डेटाबेस कैशिंग

सीधे जावा प्रोग्राम में कैशिंग के अलावा, कैशिंग को अक्सर सीधे डेटाबेस में व्यवस्थित किया जाता है।

चार बड़े दृष्टिकोण हैं:

पहला तरीका डेटाबेस को असामान्य बनाना है । SQL सर्वर मेमोरी में डेटा को टेबल में स्टोर करने के तरीके से अलग तरीके से स्टोर करता है।

जब डेटा को टेबल में डिस्क पर संग्रहीत किया जाता है, तो अक्सर डेवलपर्स जितना संभव हो सके डेटा दोहराव से बचने की कोशिश करते हैं - इस प्रक्रिया को डेटाबेस सामान्यीकरण कहा जाता है। इसलिए, मेमोरी में डेटा के साथ काम को गति देने के लिए, रिवर्स प्रोसेस किया जाता है - डेटाबेस डीनॉर्मलाइज़ेशन। संबंधित तालिकाओं का एक गुच्छा पहले से ही एक संयुक्त रूप में संग्रहीत किया जा सकता है - विशाल तालिकाओं आदि के रूप में।

दूसरा तरीका क्वेरी कैशिंग है । और क्वेरी परिणाम।

DBMS देखता है कि बहुत बार समान या समान अनुरोध उसके पास आते हैं। फिर यह इन अनुरोधों और उनकी प्रतिक्रियाओं को कैश करना शुरू कर देता है। लेकिन साथ ही, आपको यह सुनिश्चित करने की ज़रूरत है कि डेटाबेस में बदली गई पंक्तियों को समय-समय पर कैश से हटा दिया जाए।

यह दृष्टिकोण एक इंसान के साथ बहुत प्रभावी हो सकता है जो प्रश्नों का विश्लेषण कर सकता है और DBMS को यह पता लगाने में मदद करता है कि उन्हें कैसे कैश करना है।

तीसरा दृष्टिकोण एक इन-मेमोरी डेटाबेस है ।

एक और आमतौर पर इस्तेमाल किया जाने वाला तरीका। सर्वर और DBMS के बीच एक और डेटाबेस रखा जाता है, जो अपने सभी डेटा को केवल मेमोरी में स्टोर करता है। इसे इन-मेमोरी-डीबी भी कहा जाता है। यदि आपके पास एक ही डेटाबेस तक पहुँचने वाले कई अलग-अलग सर्वर हैं, तो इन-मेमोरी-डीबी का उपयोग करके आप किसी विशेष सर्वर के प्रकार के आधार पर कैशिंग को व्यवस्थित कर सकते हैं।

उदाहरण:

दृष्टिकोण 4 - डेटाबेस क्लस्टर । कई रीड-ओनली बेस।

एक अन्य समाधान एक क्लस्टर का उपयोग करना है: एक ही प्रकार के कई DBMS में समान डेटा होता है। उसी समय, आप सभी डेटाबेस से डेटा पढ़ सकते हैं और केवल एक को लिख सकते हैं। जिसे बाद में बाकी डेटाबेस के साथ सिंक्रोनाइज़ किया जाता है।

यह एक बहुत अच्छा समाधान है क्योंकि इसे कॉन्फ़िगर करना आसान है और अभ्यास में काम करता है। आमतौर पर, डेटाबेस को डेटा बदलने के लिए एक अनुरोध के लिए, डेटा पढ़ने के लिए 10-100 अनुरोध आते हैं।

हाइबरनेट में कैशिंग के प्रकार

हाइबरनेट कैशिंग के तीन स्तरों का समर्थन करता है:

• सत्र स्तर पर कैशिंग (सत्र)
• सत्र कारखाना स्तर पर कैशिंग
• कैशिंग अनुरोध (और उनके परिणाम)

आप इस प्रणाली को इस तरह के चित्र के रूप में प्रस्तुत करने का प्रयास कर सकते हैं:

कैशिंग का सबसे सरल प्रकार (जिसे प्रथम स्तर का कैश भी कहा जाता है ) को हाइबरनेट सत्र स्तर पर लागू किया जाता है। हाइबरनेट हमेशा डिफ़ॉल्ट रूप से इस कैश का उपयोग करता है और इसे अक्षम नहीं किया जा सकता है ।

आइए तुरंत निम्नलिखित उदाहरण पर विचार करें:

Employee director1 = session.get(Employee.class, 4);
Employee director2 = session.get(Employee.class, 4);

assertTrue(director1 == director2);

ऐसा लग सकता है कि डेटाबेस से दो प्रश्न यहां निष्पादित किए जाएंगे, लेकिन ऐसा नहीं है। डेटाबेस के पहले अनुरोध के बाद, कर्मचारी वस्तु को कैश किया जाएगा। और यदि आप उसी सत्र में ऑब्जेक्ट को दोबारा पूछते हैं, तो हाइबरनेट उसी जावा ऑब्जेक्ट को वापस कर देगा।

समान वस्तु का अर्थ है कि वस्तु संदर्भ भी समान होंगे। यह वास्तव में वही वस्तु है।

सेव () , अपडेट () , सेवऑरअपडेट () , लोड () , गेट () , लिस्ट () , इटरेट (), और स्क्रॉल () विधियाँ हमेशा पहले स्तर के कैश का उपयोग करती हैं। दरअसल, जोड़ने के लिए और कुछ नहीं है।

द्वितीय स्तर कैशिंग

यदि प्रथम स्तर कैश सत्र ऑब्जेक्ट से जुड़ा हुआ है, तो दूसरा स्तर कैश सत्र ऑब्जेक्ट से जुड़ा हुआ है।सत्र कारखाना. जिसका अर्थ है कि इस कैश में वस्तुओं की दृश्यता प्रथम स्तर के कैश की तुलना में बहुत व्यापक है।

उदाहरण:

Session session = factory.openSession();
Employee director1 = session.get(Employee.class, 4);
session.close();

Session session = factory.openSession();
Employee director2 = session.get(Employee.class, 4);
session.close();

assertTrue(director1 != director2);
assertTrue(director1.equals(director2));

इस उदाहरण में, डेटाबेस से दो प्रश्न पूछे जाएंगे। हाइबरनेट समान वस्तुओं को लौटाएगा, लेकिन यह एक ही वस्तु नहीं होगी - उनके अलग-अलग संदर्भ होंगे।

दूसरे स्तर की कैशिंग डिफ़ॉल्ट रूप से अक्षम है । इसलिए, हमारे पास एक के बजाय डेटाबेस में दो प्रश्न हैं।

इसे सक्षम करने के लिए, आपको निम्नलिखित पंक्तियों को hibernate.cfg.xml फ़ाइल में लिखना होगा:

<property name="hibernate.cache.provider_class" value="net.sf.ehcache.hibernate.SingletEhCacheProvider"/>
<property name="hibernate.cache.use_second_level_cache" value="true"/>

द्वितीय-स्तरीय कैशिंग सक्षम करने के बाद, हाइबरनेट व्यवहार थोड़ा बदल जाएगा:

Session session = factory.openSession();
Employee director1 = session.get(Employee.class, 4);
session.close();

Session session = factory.openSession();
Employee director2 = session.get(Employee.class, 4);
session.close();

assertTrue(director1 == director2);

इन सभी जोड़तोड़ के बाद ही दूसरे स्तर के कैश को सक्षम किया जाएगा, और ऊपर के उदाहरण में, डेटाबेस के लिए केवल एक क्वेरी निष्पादित की जाएगी।