क्योटो कैबिनेट/बर्कले डीबी: हैश टेबल आकार सीमाएं

Question

मुझे अपने एसएसडी पर हैश सरणी के साथ 16/32 बाइट्स के लाखों कुंजी/मूल्य जोड़े संग्रहीत करने में कठिनाई हो रही है।

क्योटो कैबिनेट के साथ: जब यह ठीक काम करता है, तो यह 70000 रिकॉर्ड/एस पर सम्मिलित होता है। एक बार यह गिरने के बाद, यह 10-500 रिकॉर्ड/एस तक चला जाता है। डिफ़ॉल्ट सेटिंग्स के साथ, लगभग दस लाख रिकॉर्ड के बाद ड्रॉप होता है। प्रलेखन को देखते हुए, यह सरणी में बाल्टी की डिफ़ॉल्ट संख्या है, इसलिए यह समझ में आता है। मैंने इस संख्या को 25 लाख तक बढ़ा दिया और वास्तव में, यह लगभग 25 लाख रिकॉर्ड तक ठीक काम करता है। समस्या यह है कि जैसे ही मैं 30 लाख या उससे अधिक की बाल्टी की संख्या को धक्का देता हूं, शुरुआत से ही डालने की दर 10-500 रिकॉर्ड्स/एस तक कम हो जाती है। क्योटो कैबिनेट डेटाबेस के निर्माण के बाद बाल्टी की संख्या बढ़ाने के लिए डिज़ाइन नहीं किया गया है, इसलिए मैं 25 लाख से अधिक रिकॉर्ड नहीं डाल सकता।

1/बाल्टी संख्या 25 एम से अधिक होने के बाद केसी की डालने की दर बहुत कम क्यों होगी?

बर्कले DB साथ : सबसे अच्छा गति मुझे मिल गया केसी से कुछ कम, 50000 रिकॉर्ड/s करीब, लेकिन अभी भी ठीक है। डिफ़ॉल्ट सेटिंग्स के साथ, केसी की तरह, गति लगभग दस लाख रिकॉर्ड के बाद अचानक गिर जाती है। मुझे पता है कि बीडीबी धीरे-धीरे अपनी बाल्टी की संख्या बढ़ाने के लिए डिज़ाइन किया गया है। इसके बावजूद, उसने प्रारंभिक संख्या को बढ़ाने की कोशिश की, हैशन्यूमेंट्स और फिलफैक्टर के साथ खेलना, लेकिन इनमें से किसी भी प्रयास ने स्थिति को सबसे खराब बना दिया। तो मैं अभी भी डीबीडी के साथ 1-2 लाख से अधिक रिकॉर्ड सम्मिलित नहीं कर सकता। मैंने गैर सिंक्रनाइज़ लेनदेन को सक्रिय करने की कोशिश की, चेकपॉइंट्स की विभिन्न दरों, बढ़ी हुई कैशों की कोशिश की। ड्रॉप डाउन में कुछ भी सुधार नहीं करता है।

2/बीडीबी की डालने की दर 1-2 मिलियन आवेषण के बाद क्या हो सकती है?

नोट: मैं जावा के साथ काम कर रहा हूँ, और जब गति गिरती है, CPU उपयोग करते हुए 100% पर जब सही गति से काम कर रहा 0-30% तक कम करती है।
नोट: प्रक्रिया को रोकना और सम्मिलन को फिर से शुरू करना कुछ भी नहीं बदलता है। तो मुझे नहीं लगता कि यह स्मृति सीमा या कचरा संग्रह से संबंधित है।

Thx।

Answer 1

नीचे मैं केसी के साथ लिखित सीमाओं के बावजूद अरबों रिकॉर्ड स्टोर करने में कामयाब रहा।

अधिक प्रयास के साथ, मैंने अभी भी क्योटो कैबिनेट और न ही बर्कले डीबी के लिए समस्या का हल नहीं किया है। हालांकि मैं क्योटो कैबिनेट का उपयोग करके एक दिलचस्प कामकाज के साथ आया था।

मैंने देखा कि मैं एक केसी फ़ाइल पर 25 एम से अधिक रिकॉर्ड नहीं लिख सकता, लेकिन पढ़ने के लिए ऐसी कोई सीमा नहीं है- डेटाबेस के आकार के बावजूद यह हमेशा तेज है। मैंने पाया समाधान हर 25 एम नए रिकॉर्ड के लिए एक नई केसी फ़ाइल (एक नया डेटाबेस) बनाना है। इस तरह पढ़ने कई केसी फाइलों पर होता है और अभी भी तेज़ है, और लेखन केवल आखिरी बनाई गई फाइल पर होता है और साथ ही तेज़ भी होता है। केवल शेष समस्या पिछली फाइलों पर रिकॉर्ड्स को अद्यतन/हटाने की अनुमति थी। कि के लिए, मैं की नकल की SSTables दृष्टिकोण, जो है:

• सभी 0 एन -1 के लिए फ़ाइलों को केवल पढ़ने के लिए कर रहे हैं, फ़ाइल एन पढ़ा जाता है + लिखें।
• फ़ाइल एन में कोई भी सम्मिलन/अद्यतन/हटाना लिखा गया है।
• फ़ाइलों को एन से 0 में देखें, और पहले देखा/अंतिम लिखित सम्मिलन/अद्यतन/हटाना वापस करें।
• एक फ़ाइल को एक्सेस करने से बचने के लिए प्रत्येक फ़ाइल से एक ब्लूम फ़िल्टर संलग्न होता है जिसमें वांछित रिकॉर्ड नहीं होता है।
• जैसे ही फ़ाइल एन 25 एम रिकॉर्ड तक पहुंच जाती है, यह केवल पढ़ने-योग्य हो जाती है और फ़ाइल एन + 1 बनाई जाती है।

नोट्स:

बस SSTables साथ की तरह
• , बहुत-से अपडेट/विलोपन प्रदर्शन कर रहे हैं, तो हम संघनन प्रदर्शन करने के लिए चाहते हो सकता है। हालांकि एसएसटीबल्स के विपरीत, यहां कॉम्पैक्शन को फ़ाइल को फिर से लिखने की आवश्यकता नहीं है। पुराने रिकॉर्ड को केसी फाइलों से हटा दिया जाता है, और यदि कोई केसी फ़ाइल बहुत छोटी हो जाती है, तो इसे या तो हटाया जा सकता है- फाइल एन में रिकॉर्ड्स डालने या नए प्रविष्टियों के लिए फिर से खोलने के लिए- अगली फाइलें कॉम्पैक्ट हैं।
• एक विलोपन रिकॉर्ड को हटा नहीं देता है, लेकिन एक विशेष मान लिखता है जो रिकॉर्ड को हटाए जाने की पहचान करता है। Compaction के दौरान, हटाए गए रिकॉर्ड वास्तविक के लिए हटा दिए जाते हैं।
• जांचना कि रिकॉर्ड रिकॉर्ड होने पर आमतौर पर डेटाबेस को देखने की आवश्यकता होती है। ब्लूम फ़िल्टर के लिए धन्यवाद, अधिकांश नकारात्मक उत्तरों को बिना डिस्क एक्सेस के दिया जा सकता है।