हायबरनेटमध्ये डेटा कॅशिंग

तुमचे कॅशिंग सोल्यूशन कधीही लिहू नका

डेटाबेससह कामाचा वेग वाढवण्याचा आणखी एक मार्ग म्हणजे आम्ही आधीच विनंती केलेल्या वस्तू कॅशे करणे.

महत्वाचे! तुमचे स्वतःचे कॅशिंग सोल्यूशन कधीही लिहू नका. या कार्यात इतके तोटे आहेत की आपण स्वप्नातही विचार केला नसेल.

समस्या 1 - कॅशे फ्लश . कधीकधी घटना घडतात जेव्हा एखादी वस्तू कॅशेमधून काढून टाकण्याची किंवा कॅशेमध्ये अपडेट करण्याची आवश्यकता असते. हे सक्षमपणे करण्याचा एकमेव मार्ग म्हणजे कॅशे इंजिनद्वारे डेटाबेसमध्ये सर्व विनंत्या पास करणे. अन्यथा, प्रत्येक वेळी तुम्हाला कॅशेमध्ये कोणते ऑब्जेक्ट हटवायचे किंवा अपडेट करायचे हे स्पष्टपणे सांगावे लागेल.

समस्या 2 - स्मरणशक्तीचा अभाव . मेमरीमधील ऑब्जेक्ट्स खूप जागा घेतात असे तुम्हाला दिसत नाही तोपर्यंत कॅशिंग ही एक चांगली कल्पना दिसते. सर्व्हर ऍप्लिकेशन कॅशे प्रभावीपणे कार्य करण्यासाठी तुम्हाला अतिरिक्त दहा गीगाबाइट मेमरी आवश्यक आहे.

आणि नेहमी मेमरीची कमतरता असल्याने, कॅशेमधून ऑब्जेक्ट्स हटवण्यासाठी एक प्रभावी धोरण आवश्यक आहे. हे काहीसे जावामधील कचरा वेचणाऱ्यासारखेच आहे. आणि जसे तुम्हाला आठवते, अनेक दशकांपासून सर्वोत्तम मने पिढ्यानपिढ्या वस्तू चिन्हांकित करण्याचे विविध मार्ग शोधत आहेत.

समस्या 3 - भिन्न धोरणे . सराव दर्शविल्याप्रमाणे, कॅशेमध्ये संचयित आणि अद्यतनित करण्याच्या विविध धोरणे भिन्न वस्तूंसाठी प्रभावी आहेत. कार्यक्षम कॅशिंग सिस्टम सर्व ऑब्जेक्ट्ससाठी फक्त एक धोरण करू शकत नाही.

समस्या 4 - चे कार्यक्षम संचयन . तुम्ही फक्त वस्तू कॅशेमध्ये ठेवू शकत नाही. ऑब्जेक्ट्समध्ये अनेकदा इतर वस्तूंचे संदर्भ असतात, आणि असेच. या दराने, आपल्याला कचरा गोळा करणार्‍याची आवश्यकता नाही: त्यात काढण्यासाठी काहीही नाही.

म्हणून, वस्तू स्वतः संग्रहित करण्याऐवजी, त्यांच्या आदिम फील्डची मूल्ये संग्रहित करणे कधीकधी अधिक कार्यक्षम असते. आणि त्यावर आधारित वस्तू त्वरीत तयार करण्यासाठी सिस्टम.

परिणामी, तुम्हाला मेमरीमध्ये संपूर्ण व्हर्च्युअल DBMS मिळेल, जे त्वरीत कार्य करेल आणि कमी मेमरी वापरेल.

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

Java प्रोग्राममध्ये थेट कॅश करण्याव्यतिरिक्त, कॅशिंग अनेकदा डेटाबेसमध्ये थेट आयोजित केले जाते.

चार मोठ्या पद्धती आहेत:

डेटाबेस डिनॉर्मलाइझ करणे हा पहिला दृष्टिकोन आहे . SQL सर्व्हर मेमरीमध्ये डेटा कसा संग्रहित केला जातो त्यापेक्षा वेगळ्या पद्धतीने संग्रहित करतो.

जेव्हा डेटा टेबलमध्ये डिस्कवर संग्रहित केला जातो, तेव्हा बहुतेक वेळा विकसक डेटा डुप्लिकेशन शक्य तितक्या टाळण्याचा प्रयत्न करतात - या प्रक्रियेला डेटाबेस सामान्यीकरण म्हणतात. म्हणून, मेमरीमधील डेटासह कार्य गतिमान करण्यासाठी, उलट प्रक्रिया केली जाते - डेटाबेस डिनोर्मलायझेशन. संबंधित सारण्यांचा एक समूह आधीच एकत्रित स्वरूपात संग्रहित केला जाऊ शकतो - प्रचंड सारण्यांच्या स्वरूपात इ.

दुसरी पद्धत क्वेरी कॅशिंग आहे . आणि क्वेरी परिणाम.

DBMS पाहते की बर्‍याचदा समान किंवा समान विनंत्या येतात. मग ते या विनंत्या आणि त्यांचे प्रतिसाद कॅश करणे सुरू करते. परंतु त्याच वेळी, आपल्याला खात्री करणे आवश्यक आहे की डेटाबेसमध्ये बदललेल्या पंक्ती वेळेवर कॅशेमधून काढल्या गेल्या आहेत.

प्रश्नांचे विश्लेषण करू शकणार्‍या माणसासाठी हा दृष्टीकोन खूप प्रभावी ठरू शकतो आणि डीबीएमएसला ते कसे सर्वोत्तम करावे हे शोधण्यात मदत करू शकतो.

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

आणखी एक सामान्यपणे वापरला जाणारा दृष्टीकोन. दुसरा डेटाबेस सर्व्हर आणि डीबीएमएस दरम्यान ठेवला आहे, जो त्याचा सर्व डेटा केवळ मेमरीमध्ये संग्रहित करतो. त्याला इन-मेमरी-डीबी असेही म्हणतात. तुमच्याकडे एकाच डेटाबेसमध्ये प्रवेश करणारे अनेक भिन्न सर्व्हर असल्यास, इन-मेमरी-डीबी वापरून तुम्ही विशिष्ट सर्व्हरच्या प्रकारावर आधारित कॅशिंग व्यवस्थापित करू शकता.

उदाहरण:

अॅप्रोच 4 - डेटाबेस क्लस्टर . अनेक फक्त-वाचनीय तळ.

क्लस्टर वापरणे हा दुसरा उपाय आहे: एकाच प्रकारच्या अनेक DBMS मध्ये समान डेटा असतो. त्याच वेळी, आपण सर्व डेटाबेसमधील डेटा वाचू शकता आणि फक्त एकावर लिहू शकता. जे नंतर उर्वरित डेटाबेससह समक्रमित केले जाते.

हे एक अतिशय चांगले उपाय आहे कारण ते कॉन्फिगर करणे सोपे आहे आणि सराव मध्ये कार्य करते. सहसा, डेटाबेसला डेटा बदलण्याच्या एका विनंतीसाठी, डेटा वाचण्यासाठी 10-100 विनंत्या येतात.

हायबरनेटमध्ये कॅशिंगचे प्रकार

हायबरनेट कॅशिंगच्या तीन स्तरांना समर्थन देते:

• सत्र स्तरावर कॅशिंग (सत्र)
• सेशनफॅक्टरी स्तरावर कॅशिंग
• कॅशिंग विनंत्या (आणि त्यांचे परिणाम)

आपण अशा आकृतीच्या स्वरूपात या प्रणालीचे प्रतिनिधित्व करण्याचा प्रयत्न करू शकता:

कॅशिंगचा सर्वात सोपा प्रकार (याला प्रथम स्तर कॅशे देखील म्हणतात ) हायबरनेट सत्र स्तरावर लागू केला जातो. हायबरनेट नेहमी डीफॉल्टनुसार ही कॅशे वापरते आणि अक्षम केली जाऊ शकत नाही .

चला ताबडतोब खालील उदाहरणाचा विचार करूया:

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

assertTrue(director1 == director2);

असे दिसते की डेटाबेससाठी दोन क्वेरी येथे कार्यान्वित केल्या जातील, परंतु तसे नाही. डेटाबेसला प्रथम विनंती केल्यानंतर, कर्मचारी ऑब्जेक्ट कॅश केला जाईल. आणि त्याच सत्रात तुम्ही ऑब्जेक्टची पुन्हा चौकशी केल्यास, हायबरनेट समान Java ऑब्जेक्ट परत करेल.

समान ऑब्जेक्ट म्हणजे ऑब्जेक्ट संदर्भ देखील एकसारखे असतील. तो खरोखर समान ऑब्जेक्ट आहे.

save() , update() , saveOrUpdate() , load() , get() , list() , iterate() , आणि scroll() पद्धती नेहमी प्रथम स्तर कॅशे वापरतील. खरं तर, जोडण्यासाठी आणखी काही नाही.

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

जर प्रथम स्तर कॅशे सत्र ऑब्जेक्टशी बांधील असेल, तर द्वितीय स्तर कॅशे सत्र ऑब्जेक्टशी बांधील असेल.सेशनफॅक्टरी. याचा अर्थ असा की या कॅशेमधील वस्तूंची दृश्यमानता पहिल्या स्तरावरील कॅशेपेक्षा खूपच विस्तृत आहे.

उदाहरण:

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);

या सर्व हाताळणीनंतरच द्वितीय-स्तरीय कॅशे सक्षम केली जाईल आणि वरील उदाहरणामध्ये, डेटाबेससाठी फक्त एक क्वेरी कार्यान्वित केली जाईल.