दो याकोजुन की लड़ाई, या कैसंड्रा बनाम HBase। Sberbank टीम का अनुभव

यह मजाक भी नहीं है, ऐसा लगता है कि यह विशेष चित्र इन डेटाबेस के सार को सबसे सटीक रूप से दर्शाता है, और अंत में यह स्पष्ट होगा कि क्यों:



DB-Engines रैंकिंग के अनुसार, दो सबसे लोकप्रिय NoSQL स्तंभ आधार कैसेंड्रा (इसके बाद सीएस) और HBase (HB) हैं।



भाग्य की इच्छा से, Sberbank में हमारी डेटा लोडिंग प्रबंधन टीम लंबे समय से HB के साथ मिलकर काम कर रही है। इस समय के दौरान, हमने इसकी खूबियों और कमजोरियों का अच्छी तरह से अध्ययन किया और इसे पकाने का तरीका सीखा। हालांकि, सीएस के रूप में हर समय एक विकल्प की उपस्थिति ने मुझे खुद को संदेह के साथ पीड़ा दी: क्या हमने सही विकल्प बनाया? इसके अलावा, डेटास्टैक्स द्वारा किए गए तुलना के परिणामों ने कहा कि सीएस आसानी से लगभग एक पेराई स्कोर के साथ एचबी को हरा देता है। दूसरी ओर, DataStax एक इच्छुक व्यक्ति है, और आपको यहां एक शब्द भी नहीं लेना चाहिए। इसके अलावा, परीक्षण की स्थितियों के बारे में बहुत कम जानकारी शर्मनाक थी, इसलिए हमने स्वतंत्र रूप से यह पता लगाने का फैसला किया कि बिगडाटा नोस्कल का राजा कौन है, और परिणाम बहुत दिलचस्प थे।

हालांकि, प्रदर्शन किए गए परीक्षणों के परिणामों पर आगे बढ़ने से पहले, पर्यावरण कॉन्फ़िगरेशन के आवश्यक पहलुओं का वर्णन करना आवश्यक है। तथ्य यह है कि सीएस का उपयोग डेटा लॉस टॉलरेंस मोड में किया जा सकता है। यानी यह तब होता है जब एक निश्चित कुंजी के डेटा के लिए केवल एक सर्वर (नोड) जिम्मेदार होता है, और यदि यह किसी कारण से बंद हो जाता है, तो इस कुंजी का मूल्य खो जाएगा। कई कार्यों के लिए यह महत्वपूर्ण नहीं है, लेकिन बैंकिंग क्षेत्र के लिए यह नियम के बजाय अपवाद है। हमारे मामले में, विश्वसनीय भंडारण के लिए डेटा की कई प्रतियां होना महत्वपूर्ण है।

इसलिए, केवल ट्रिपल प्रतिकृति के सीएस मोड पर विचार किया गया था, अर्थात्। मामले का निर्माण निम्नलिखित मापदंडों के साथ किया गया था:

CREATE KEYSPACE ks WITH REPLICATION = {'class' : 'NetworkTopologyStrategy', 'datacenter1' : 3}; 

इसके अलावा, निरंतरता के आवश्यक स्तर को सुनिश्चित करने के दो तरीके हैं। सामान्य नियम:
NW + NR> RF

इसका मतलब यह है कि लिखते समय नोड्स से पुष्टिकरण की संख्या (NW) प्लस नोड्स से पुष्टिकरण की संख्या जब पढ़ना (एनआर) प्रतिकृति कारक से अधिक होना चाहिए। हमारे मामले में, RF = 3 और इसलिए निम्नलिखित विकल्प उपयुक्त हैं:
2 + 2> 3
3 + 1> 3

चूँकि डेटा को यथासंभव विश्वसनीय बनाए रखना हमारे लिए मूलभूत रूप से महत्वपूर्ण है, इसलिए 3 + 1 योजना को चुना गया। इसके अलावा, एचबी एक समान आधार पर काम करता है, अर्थात्। ऐसी तुलना अधिक ईमानदार होगी।

यह ध्यान दिया जाना चाहिए कि डेटास्टैक्स ने अपने शोध में विपरीत किया, उन्होंने सीएस और एचबी (एचडीएफएस सेटिंग्स को बदलकर उत्तरार्द्ध के लिए) के लिए आरएफ = 1 सेट किया। यह वास्तव में महत्वपूर्ण पहलू है, क्योंकि इस मामले में सीएस के प्रदर्शन पर प्रभाव बहुत बड़ा है। उदाहरण के लिए, नीचे दी गई तस्वीर सीएस में डेटा लोड करने के लिए आवश्यक समय में वृद्धि दर्शाती है:



यहां हम निम्नलिखित देखते हैं, अधिक प्रतिस्पर्धी धागे डेटा लिखते हैं, जितना अधिक समय लगता है। यह स्वाभाविक है, लेकिन यह महत्वपूर्ण है कि RF = 3 के लिए प्रदर्शन में गिरावट काफी अधिक है। दूसरे शब्दों में, यदि हम प्रत्येक 5 धाराओं (कुल 20) में 4 तालिकाओं में लिखते हैं, तो RF = 3 लगभग 2 गुना (150 सेकंड RF = 3 बनाम 75 RF = 1 के लिए) खो देता है। लेकिन अगर हम 5 धाराओं (कुल 40) में से प्रत्येक में 8 तालिकाओं में डेटा लोड करके लोड बढ़ाते हैं, तो आरएफ = 3 खोना पहले से 2.7 गुना (13875 बनाम 375 सेकंड) है।

शायद आंशिक रूप से यह सीएस लोड परीक्षण के लिए सफल डेटास्टैक्स परीक्षण का रहस्य है, क्योंकि हमारे स्टैंड पर एचबी के लिए, प्रतिकृति कारक को 2 से 3 में बदलने का कोई प्रभाव नहीं था। यानी डिस्क हमारे विन्यास के लिए HB के लिए अड़चन नहीं हैं। हालांकि, कई अन्य नुकसान भी हैं, क्योंकि यह ध्यान दिया जाना चाहिए कि एचबी का हमारा संस्करण थोड़ा पैच और अस्पष्ट था, वातावरण पूरी तरह से अलग हैं, आदि। यह भी ध्यान देने योग्य है कि शायद मैं नहीं जानता कि सीएस को ठीक से कैसे तैयार किया जाए और इसके साथ काम करने के कुछ और प्रभावी तरीके हैं और मुझे उम्मीद है कि टिप्पणियों में हमें पता चलेगा। लेकिन पहले बातें पहले।

सभी परीक्षण एक लोहे के क्लस्टर पर किए गए थे, जिसमें 4 सर्वर थे, प्रत्येक एक विन्यास में:

CPU: Xeon E5-2680 v4 @ 2.40GHz 64 धागे।
डिस्क: SATA HDD के 12 टुकड़े
जावा संस्करण: 1.8.0_111


सीएस संस्करण: 3.11.5


जीसी सेटिंग्स:


मेमोरी jvm.options को 16Gb आवंटित किया गया था (फिर भी 32 जीबी की कोशिश की गई, कोई अंतर नहीं देखा गया)।

तालिका बनाना कमांड द्वारा किया गया था:

 CREATE TABLE ks.t1 (id bigint PRIMARY KEY, title text) WITH compression = {'sstable_compression': 'LZ4Compressor', 'chunk_length_kb': 64}; 

एचबी संस्करण: 1.2.0-cdh5.14.2 (वर्ग में org.apache.hadoop.hbase.regionserver.Hegion हमने MetricsRegion को बाहर कर दिया है, जिसके चलते जीसी के साथ रीजनर के 1000 से अधिक क्षेत्र हो गए)


तालिकाएँ बनाना:
hbase org.apache.hadoop.hbase.util.RegionSplitter ns: t1 यूनिफ़ॉर्मप्लेट -c 64 -f cf
परिवर्तन 'ns: t1', {NAME => 'cf', DATA_BLOCK_ENCODING => 'FAST_DIFF', COMPRESSION => 'GZ'}

एक महत्वपूर्ण बिंदु है - DataStax विवरण यह नहीं बताता है कि एचबी टेबल बनाने के लिए कितने क्षेत्रों का उपयोग किया गया था, हालांकि यह बड़े संस्करणों के लिए महत्वपूर्ण है। इसलिए, परीक्षणों के लिए, संख्या = 64 को चुना गया, जो 640 जीबी तक स्टोर करने की अनुमति देता है, अर्थात। मध्यम आकार की मेज।

परीक्षण के समय, HBase में 22 हजार टेबल और 67 हजार क्षेत्र थे (यह संस्करण 1.2.0 के लिए घातक होगा, यदि ऊपर वर्णित पैच के लिए नहीं है)।

अब कोड के लिए। चूंकि यह स्पष्ट नहीं था कि किसी विशेष डेटाबेस के लिए कौन से कॉन्फ़िगरेशन अधिक फायदेमंद हैं, परीक्षण विभिन्न संयोजनों में किए गए थे। यानी कुछ परीक्षणों में, लोड एक साथ 4 टेबल पर चला गया (सभी 4 नोड्स कनेक्शन के लिए उपयोग किए गए थे)। अन्य परीक्षणों में, उन्होंने 8 अलग-अलग तालिकाओं के साथ काम किया। कुछ मामलों में, बैच का आकार 100 था, दूसरों में 200 (बैच पैरामीटर - नीचे कोड देखें)। मान के लिए डेटा का आकार 10 बाइट्स या 100 बाइट्स (डेटासाइज़) है। कुल मिलाकर, प्रत्येक तालिका में हर बार 5 मिलियन रिकॉर्ड लिखे और घटाए गए। उसी समय, प्रत्येक तालिका में 5 धाराएँ लिखी गईं / पढ़ी गईं (स्ट्रीम नंबर thNum है), जिनमें से प्रत्येक ने अपनी स्वयं की कुंजी सीमा (गणना = 1 मिलियन) का उपयोग किया:

 if (opType.equals("insert")) { for (Long key = count * thNum; key < count * (thNum + 1); key += 0) { StringBuilder sb = new StringBuilder("BEGIN BATCH "); for (int i = 0; i < batch; i++) { String value = RandomStringUtils.random(dataSize, true, true); sb.append("INSERT INTO ") .append(tableName) .append("(id, title) ") .append("VALUES (") .append(key) .append(", '") .append(value) .append("');"); key++; } sb.append("APPLY BATCH;"); final String query = sb.toString(); session.execute(query); } } else { for (Long key = count * thNum; key < count * (thNum + 1); key += 0) { StringBuilder sb = new StringBuilder("SELECT * FROM ").append(tableName).append(" WHERE id IN ("); for (int i = 0; i < batch; i++) { sb = sb.append(key); if (i+1 < batch) sb.append(","); key++; } sb = sb.append(");"); final String query = sb.toString(); ResultSet rs = session.execute(query); } } 

तदनुसार, एचबी के लिए एक समान कार्यक्षमता प्रदान की गई थी:

 Configuration conf = getConf(); HTable table = new HTable(conf, keyspace + ":" + tableName); table.setAutoFlush(false, false); List<Get> lGet = new ArrayList<>(); List<Put> lPut = new ArrayList<>(); byte[] cf = Bytes.toBytes("cf"); byte[] qf = Bytes.toBytes("value"); if (opType.equals("insert")) { for (Long key = count * thNum; key < count * (thNum + 1); key += 0) { lPut.clear(); for (int i = 0; i < batch; i++) { Put p = new Put(makeHbaseRowKey(key)); String value = RandomStringUtils.random(dataSize, true, true); p.addColumn(cf, qf, value.getBytes()); lPut.add(p); key++; } table.put(lPut); table.flushCommits(); } } else { for (Long key = count * thNum; key < count * (thNum + 1); key += 0) { lGet.clear(); for (int i = 0; i < batch; i++) { Get g = new Get(makeHbaseRowKey(key)); lGet.add(g); key++; } Result[] rs = table.get(lGet); } } 

चूँकि क्लाइंट को HB में डेटा के समान वितरण का ध्यान रखना चाहिए, इस प्रकार की सलामी फ़ंक्शन को देखा गया:

 public static byte[] makeHbaseRowKey(long key) { byte[] nonSaltedRowKey = Bytes.toBytes(key); CRC32 crc32 = new CRC32(); crc32.update(nonSaltedRowKey); long crc32Value = crc32.getValue(); byte[] salt = Arrays.copyOfRange(Bytes.toBytes(crc32Value), 5, 7); return ArrayUtils.addAll(salt, nonSaltedRowKey); } 

अब सबसे दिलचस्प परिणाम हैं:



ग्राफ़ के समान:



एचबी का लाभ इतना अद्भुत है कि सीएस सेटिंग्स में कुछ प्रकार की अड़चन का संदेह है। हालांकि, सबसे स्पष्ट मापदंडों (जैसे समवर्ती_लेखों या memtable_heap_space_in_mb) के googling और मरोड़ ने त्वरण नहीं दिया। उसी समय, लॉग साफ होते हैं, किसी भी चीज़ की कसम नहीं खाते हैं।

डेटा नोड्स में समान रूप से लेटा होता है, सभी नोड्स के आंकड़े लगभग समान होते हैं।


बैच के आकार को कम करने का प्रयास (एक-एक करके भेजने के लिए) का प्रभाव नहीं था, यह केवल खराब हो गया। यह संभव है कि वास्तव में यह सीएस के लिए वास्तव में अधिकतम प्रदर्शन है, क्योंकि सीएस पर प्राप्त परिणाम डेटाटेक्स के लिए प्राप्त किए गए समान हैं - प्रति सेकंड सैकड़ों हजारों ऑपरेशन। इसके अतिरिक्त, यदि आप संसाधनों के उपयोग को देखते हैं, तो आप देखेंगे कि CS अधिक CPU और डिस्क का उपयोग करता है:


आंकड़ा दोनों डेटाबेस के लिए एक पंक्ति में सभी परीक्षणों के चलाने के दौरान उपयोग को दर्शाता है।

एचबी के शक्तिशाली पढ़ने के लाभों के बारे में। यह देखा जा सकता है कि दोनों डेटाबेसों के लिए, पढ़ने के दौरान डिस्क का उपयोग बेहद कम है (प्रत्येक डेटाबेस के लिए परीक्षण चक्र परीक्षण चक्र का अंतिम भाग है, उदाहरण के लिए, सीएस के लिए 15:20 से 15:40 तक)। एचबी के मामले में, कारण स्पष्ट है - अधिकांश डेटा मेमोरी में, मेमस्टोर में, और कुछ ब्लॉकचैच में कैश्ड थे। CS के लिए, यह बहुत स्पष्ट नहीं है कि यह कैसे काम करता है, हालांकि, डिस्क उपयोग भी दिखाई नहीं देता है, लेकिन सिर्फ मामले में, पंक्ति_cache_size_in_mb = 2048 कैश चालू करने और कैशिंग सेट करने का प्रयास किया गया = 'कुंजियाँ': 'ALL', 'row_per_partition': '' 2,000,000 '}, लेकिन इसने इसे और भी बदतर बना दिया।

एचबी में क्षेत्रों की संख्या के बारे में एक महत्वपूर्ण बिंदु कहने के लिए भी एक बार फिर से लायक है। हमारे मामले में, मूल्य 64 को संकेत दिया गया था। यदि आप इसे कम करते हैं और इसे उदाहरण 4 के बराबर बनाते हैं, तो जब गति 2 बार पढ़ती है। इसका कारण यह है कि मेमस्टोर तेजी से बंद हो जाएगा और फाइलें अधिक बार फ्लश होंगी और इसे पढ़ते समय अधिक फाइलों को प्रोसेस करने की आवश्यकता होगी, जो एचबी के लिए एक जटिल ऑपरेशन है। वास्तविक परिस्थितियों में, यह प्रीप्लेटिंग और कॉम्पैक्टिफ़िकेशन की रणनीति पर विचार करके इलाज किया जा सकता है, विशेष रूप से, हम एक स्व-निर्मित उपयोगिता का उपयोग करते हैं जो कचरे को इकट्ठा करता है और पृष्ठभूमि में लगातार HFiles को संकुचित करता है। यह संभव है कि डेटास्टैक्स परीक्षणों के लिए, आम तौर पर 1 क्षेत्र प्रति तालिका (जो सही नहीं है) आवंटित किया गया था और यह कुछ हद तक स्पष्ट करेगा कि एचबी अपने रीड टेस्ट में इतना क्यों खो गया।

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

बेशक, ये परीक्षण काफी सिंथेटिक हैं और यहां उपयोग किए जाने वाले डेटा की मात्रा अपेक्षाकृत मामूली है। यह संभव है कि जब टेराबाइट्स पर स्विच किया जाता है, तो स्थिति अलग होगी, लेकिन अगर एचबी के लिए हम टेराबाइट्स लोड कर सकते हैं, तो सीएस के लिए यह समस्याग्रस्त हो गया। यह अक्सर इन संस्करणों के साथ भी एक ऑपरेशनटिमेडऑटएक्स अपवाद को फेंक देता है, हालांकि डिफ़ॉल्ट लोगों की तुलना में प्रतिक्रिया की उम्मीद के मापदंडों को पहले ही कई गुना बढ़ा दिया गया था।

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

UPD: CS सेटअप पर निम्नलिखित दिशानिर्देश लागू किए गए थे:

disk_optimization_strategy: कताई
MAX_HEAP_SIZE = "32G"
HEAP_NEWSIZE = "3200M"
-Xms32G
-Xmx32G
-XX: + UseG1GC
-XX: G1RSetUpdatingPauseTimePercent = 5
-एक्सएक्स: मैक्सगैसकॉम्पिलिस = 500
-एक्सएक्स: इनिशियेटिंग हाइपऑक्यूपेंसीपेरेंट = 70
-XX: समानांतर GCThreads = 32
-एक्सएक्सएक्स: कॉनसीक्शट्स = 8

ओएस सेटिंग्स के लिए, यह एक लंबी और जटिल प्रक्रिया है (रूट प्राप्त करना, सर्वर रिबूट करना, आदि), इसलिए इन सिफारिशों को लागू नहीं किया गया था। दूसरी ओर, दोनों डेटाबेस समान स्थिति में हैं, इसलिए सब कुछ उचित है।

कोड भाग में, टेबल पर लिखने वाले सभी थ्रेड्स के लिए एक कनेक्टर बनाया गया है:

 connector = new CassandraConnector(); connector.connect(node, null, CL); session = connector.getSession(); session.getCluster().getConfiguration().getSocketOptions().setConnectTimeoutMillis(120000); KeyspaceRepository sr = new KeyspaceRepository(session); sr.useKeyspace(keyspace); prepared = session.prepare("insert into " + tableName + " (id, title) values (?, ?)"); 

डेटा बाइंडिंग के माध्यम से भेजा गया था:

 for (Long key = count * thNum; key < count * (thNum + 1); key++) { String value = RandomStringUtils.random(dataSize, true, true); session.execute(prepared.bind(key, value)); } 

इससे रिकॉर्डिंग प्रदर्शन पर महत्वपूर्ण प्रभाव नहीं पड़ा। विश्वसनीयता के लिए, मैंने YCSB टूल के साथ लोड लॉन्च किया, बिल्कुल उसी परिणाम के रूप में। नीचे एक धागे के लिए आँकड़े (4 में से):

2020-01-18 14: 41: 53: 180 315 सेकंड: 10,000,000 संचालन; 21589.1 वर्तमान ऑप्स / सेक; ] औसत = 2582.71, 90 = 3491, 99 = 16767, 99.9 = 99711, 99.99 = 171263]
[ओवरले], रनटाइम (एमएस), 315539
[OVERALL], थ्रूपुट (ops / sec), 31691.803548848162
[TOTAL_GCS_PS_Scavenge], गिनती, 161
[TOTAL_GC_TIME_PS_Scavenge], समय (ms), 2433
[TOTAL_GC_TIME _% _ PS_Scavenge], समय (%), 0.7710615803434757
[TOTAL_GCS_PS_MarkSweep], गणना, 0
[TOTAL_GC_TIME_PS_MarkSweep], समय (ms), 0
[TOTAL_GC_TIME _% _ PS_MarkSweep], समय (%), 0.0
[TOTAL_GCs], गिनती, 161
[TOTAL_GC_TIME], समय (एमएस), 2433
[TOTAL_GC_TIME_%], समय (%), 0.7710615803434757
[INSERT], संचालन, 10,000,000
[INSERT], औसतता (हमें), ३१4२.२४२ .०१
[INSERT], मिनलिटी (हमें), २६ ९
[INSERT], मैक्सलेटेंसी (हमें), ६० ९ २। ९
[आईएनएसईआरटी], ९ ५ वेंचरेंटलीलिटी (हमें), ५००,
[INSERT], ९९ वेंपार्सेंटलीलाटिटी (हमें), ३३४३ ९
[INSERT], रिटर्न = ओके, १०००००००


यहां आप देख सकते हैं कि एक स्ट्रीम की गति लगभग 32 हजार रिकॉर्ड प्रति सेकंड है, 4 धाराओं ने काम किया है, यह 128 हजार निकला है। ऐसा लगता है कि डिस्क सबसिस्टम की वर्तमान सेटिंग्स पर निचोड़ने के लिए और कुछ नहीं है।

अधिक रोचक पढ़ने के बारे में। कामरेड की सलाह की बदौलत वह मौलिक रूप से तेजी लाने में सक्षम था। पठन 5 धाराओं में नहीं, बल्कि 100 में किया गया था। 200 की वृद्धि ने प्रभाव नहीं डाला। बिल्डर को भी जोड़ा:
.withLoadBalancingPolicy (नया TokenAwarePolicy (DCAwareRoundRobinPolicy.builder) (। build। ())।

नतीजतन, यदि पहले परीक्षण में 159 644 ऑप्स (5 स्ट्रीम, 4 टेबल, 100 बैच) दिखाए गए थे, तो अब:
100 धागे, 4 टेबल, बैच = 1 (व्यक्तिगत): 301 969 ऑप्स
100 धागे, 4 टेबल, बैच = 10: 447 608 ऑप्स
100 धागे, 4 टेबल, बैच = 100: 625 655 ऑप्स

चूंकि परिणाम बैचों के साथ बेहतर हैं, इसलिए मैंने एचबी के साथ इसी तरह के परीक्षण किए:

* जब से 400 थ्रेड्स में काम कर रहे हैं, रैंडमस्ट्रिंग यूटिल्स फ़ंक्शन, जो पहले इस्तेमाल किया गया था, ने सीपीयू को 100% तक लोड किया था, इसे एक तेज जनरेटर द्वारा बदल दिया गया था।

इस प्रकार, डेटा लोड करते समय थ्रेड्स की संख्या में वृद्धि एचबी प्रदर्शन में थोड़ी वृद्धि देती है।

पढ़ने के लिए, यहां कई विकल्पों के परिणाम दिए गए हैं। 0x62ash के अनुरोध पर, फ्लश कमांड को पढ़ने से पहले निष्पादित किया गया था, और तुलना के लिए कई अन्य विकल्प भी दिए गए हैं:
मेमॉस्टोर - मेमोरी से पढ़ना, अर्थात्। डिस्क में फ्लश करने से पहले।
HFile + ज़िप - GZ एल्गोरिथ्म द्वारा संकुचित फ़ाइलों से पढ़ना।
HFile + upzip - संपीड़न के बिना फ़ाइलों से पढ़ा जाता है।

एक दिलचस्प विशेषता उल्लेखनीय है - छोटी फाइलें ("डेटा" फ़ील्ड, जहां 10 बाइट्स लिखे गए हैं) को अधिक धीरे-धीरे संसाधित किया जाता है, खासकर अगर वे संकुचित होते हैं। जाहिर है, यह केवल एक निश्चित आकार तक ही संभव है, जाहिर है कि 5 जीबी की फाइल को 10 एमबी से अधिक तेजी से संसाधित नहीं किया जाएगा, लेकिन यह स्पष्ट रूप से इंगित करता है कि इन सभी परीक्षणों में अभी भी विभिन्न कॉन्फ़िगरेशनों के शोध के लिए कोई हल नहीं है।

रुचि के लिए, मैंने विलंबता और अधिक को मापने के लिए 100 टुकड़ों के एचबी बैचों के साथ काम करने के लिए वाईसीएसबी कोड को सही किया। नीचे 4 प्रतियों के काम का नतीजा है जो उनकी तालिकाओं को लिखा गया है, प्रत्येक में 100 धागे हैं। यह निम्नलिखित निकला:


, CS AverageLatency(us) 3114, HB AverageLatency(us) = 1162 (, 1 = 100 ).

— HBase. , SSD . , , , 4 , 400 , . : — . . ScyllaDB , …