प्रोजेक्ट वोल्डेमॉर्ट में नुकसान

हमारे प्रोजेक्ट में से एक में इस्तेमाल किया जाता है जैसे कि प्रोजेक्ट वोल्डेमॉर्ट ।
संक्षेप में, यह की-वैल्यू स्टोरेज उर्फ ​​NoSQL डेटाबेस का एक बहुत ही दिलचस्प कार्यान्वयन है, जो लिंक्डिन के आंतों में लागू किया गया है। यही है, आप इसे एक कुंजी और एक मूल्य देते हैं, और यह जल्दी से मेमोरी में स्टोर / देता है और इसे डिस्क पर भी सहेजता है। यह दिलचस्प है, सिद्धांत रूप में, इसके द्वारा नहीं, बल्कि इसके क्लस्टरिंग के कार्यान्वयन से, एक अच्छी गति, अच्छी तरह से, क्योंकि यह अक्सर जावा में परियोजनाओं में उपयोग किया जाता है। सिद्धांत रूप में, हैबर पर इस डेटाबेस की कोई विस्तृत समीक्षा नहीं की गई थी, और कुछ किया जा सकता है। लेकिन अभी के लिए मैं आपको कुछ रेक के बारे में बताना चाहता हूं जिसका मुझे सामना करना था।
और हमें ऑपरेशन के दौरान एक समस्या का सामना करना पड़ा, अर्थात्, वोल्डेमॉर्ट के लिए बहुत सारे ट्रैफ़िक के साथ, इसका आधार भयानक बल के साथ प्रफुल्लित होने लगा - सचमुच प्रति घंटे दस गीगाबाइट्स - हालांकि डेवलपर्स ने आश्वासन दिया कि वहां इतना डेटा नहीं होना चाहिए। मुझे खोदना पड़ा।
"खुदाई" के परिणामस्वरूप, निम्नलिखित खुलासा किया गया था - वोल्डेमॉर्ट डिफ़ॉल्ट रूप से तथाकथित बीडीबी जेई - बर्कले डीबी जावा संस्करण का उपयोग करता है, और यह पता चला कि यह जेई सामान्य बर्कले डीबी से पूरी तरह से अलग है। यह पता चला कि यह केवल लिखा गया है - अर्थात, किसी भी ऑपरेशन के लिए एक ही सिद्धांत पर आधारित है - किसी भी ऑपरेशन के लिए - रिकॉर्डिंग, अपडेट करना, डिलीट करना - डेटा डिस्क पर फ़ाइलों के लिए लिखा जाता है और अपने आप से वे DELETED नहीं होते हैं। एक विशेष क्लीनर प्रक्रिया तब चारों ओर घूमती है और पुराने डेटा को साफ करती है - यह डेटाबेस में फ़ाइलों के सामान्य उपयोग की जांच करती है, और अगर यह bdb.cleaner.min से कम है , तो उपयोग प्रतिशत (डिफ़ॉल्ट रूप से - 50%) प्रत्येक फ़ाइल की जांच करना शुरू कर देता है, और अगर यह bdb.cleaner.min से कम है । file.utification प्रतिशत (डिफ़ॉल्ट रूप से 5%) फ़ाइल हटा दी जाती है, और इससे प्राप्त डेटा को एक नई फ़ाइल में स्थानांतरित कर दिया जाता है।
सब ठीक है। ऐसा लगता है कि आपको इन मापदंडों के साथ खेलने की आवश्यकता है, लेकिन ऐसा नहीं लगता है कि हमारे पास 50% रीसाइक्लिंग है - डिस्क पर बहुत अधिक डेटा संग्रहीत है।
जाँच करना - # java -jar /usr/local/voldemort/lib/je-4.0.92.jar DbSpace -h /usr/local/voldemort/data/bdb -u

File Size (KB) % Used
-------- --------- ------
00000000 61439 78
00000001 61439 75
00000002 61439 73
00000003 61439 74
...
000013f6 61415 1
000013fd 61392 2
000013fe 61411 3
00001400 61432 2
00001401 61439 1
...
0000186e 61413 100
0000186f 61376 100
00001870 16875 95
TOTALS 112583251 7 # java -jar /usr/local/voldemort/lib/je-4.0.92.jar DbSpace -h /usr/local/voldemort/data/bdb -u

File Size (KB) % Used
-------- --------- ------
00000000 61439 78
00000001 61439 75
00000002 61439 73
00000003 61439 74
...
000013f6 61415 1
000013fd 61392 2
000013fe 61411 3
00001400 61432 2
00001401 61439 1
...
0000186e 61413 100
0000186f 61376 100
00001870 16875 95
TOTALS 112583251 7

ओपा-पा। काम नहीं करता है, इसका मतलब सफाई है। सफाई के लिए थ्रेड्स की संख्या बढ़ाने की कोशिश - bdb.cleaner.threads (डिफ़ॉल्ट 1) के साथ खेल - कोई फायदा नहीं हुआ। Google के परिणामस्वरूप, हम BDB JE को समर्पित फ़ोरम में एक थ्रेड पर ठोकर खाते हैं (जैसा कि यह निकला, एक बहुत ही उपयोगी फ़ोरम, यदि आप किसी भी तरह से BDB JE का उपयोग कर रहे हैं - तो अवश्य पढ़ें)।
धागा (दुर्भाग्य से, मैं इसे अभी नहीं पा सकता) स्पष्ट रूप से इंगित करता है कि BDB कैश का आकार सफाई को बहुत प्रभावित कर सकता है। यही है, अगर कैश छोटा है - सफाई भी शुरू नहीं हो सकती है, क्योंकि बड़ी संख्या में चाबियों के साथ यह वांछनीय है कि वे सभी कैश में फिट होते हैं, अन्यथा सफाई प्रदर्शन में काफी गिरावट आएगी। निम्नलिखित आदेश का उपयोग करके वांछित कैश आकार का अनुमान लगाया जा सकता है -

# java -jar /usr/local/voldemort/lib/je-4.0.92.jar DbCacheSize -records 1000000 -key 100 -data 300

Inputs: records=1000000 keySize=100 dataSize=300 nodeMax=128 density=80% overhead=10%
Cache Size Btree Size Description
-------------- -------------- -----------
177,752,177 159,976,960 Minimum, internal nodes only
208,665,600 187,799,040 Maximum, internal nodes only
586,641,066 527,976,960 Minimum, internal nodes and leaf nodes
617,554,488 555,799,040 Maximum, internal nodes and leaf nodes
Btree levels: 3

(जहां कुंजी और डेटा कुंजी और डेटा का औसत आकार है, बाइट्स में, रिकॉर्ड रिकॉर्ड की संख्या है)।
अर्थात्, हमारे डेटा के लिए, प्रत्येक मिलियन रिकॉर्ड के लिए हमें लगभग 200 एमबी कैश की आवश्यकता होती है - और हमारे पास एक मिलियन से अधिक रिकॉर्ड थे। :(
कुल - पर्याप्त कैश ( bdb.cache.size ) सेट करने के बाद, डेटाबेस का उपयोग क्रमशः 7% से वांछित 50% तक बढ़ गया, क्रमशः, डेटाबेस का आकार लगभग गिर गया।
नैतिकता - उपयोग की गई तकनीक का अध्ययन करें, भले ही इसका उपयोग प्रत्यक्ष रूप से न किया जाए, लेकिन परोक्ष रूप से।