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

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

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

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

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

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

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

इसके बाद, निरंतरता के आवश्यक स्तर को सुनिश्चित करने के दो तरीके हैं। सामान्य नियम:
एनडब्ल्यू + एनआर > आरएफ

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

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

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

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

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

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

सीपीयू: Xeon E5-2680 v4 @ 2.40GHz 64 थ्रेड।
डिस्क: 12 टुकड़े SATA HDD
जावा संस्करण: 1.8.0_111

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

कैसेंड्रा.yml पैरामीटरसंख्या_टोकन: 256
संकेतित_हैंडऑफ़_सक्षम: सत्य
संकेत_हैंडऑफ़_थ्रोटल_इन_केबी: 1024
max_hints_delivery_threads: 2
संकेत_निर्देशिका: /डेटा10/कैसंड्रा/संकेत
संकेत_फ्लश_पीरियड_इन_एमएस: 10000
max_hints_file_size_in_mb: 128
बैचलॉग_रिप्ले_थ्रोटल_इन_केबी: 1024
प्रमाणक:AllowAllAuthenticator
प्राधिकारकर्ता:AllowAllAuthorizer
भूमिका_प्रबंधक: कैसेंड्राभूमिका प्रबंधक
Roles_validity_in_ms: 2000
अनुमतियाँ_वैधता_in_ms: 2000
क्रेडेंशियल्स_वैलिडिटी_इन_एमएस: 2000
विभाजनकर्ता: org.apache.cassandra.dht.Murmur3Partitioner
डेटा_फ़ाइल_निर्देशिकाएँ:
- /data1/cassandra/data # प्रत्येक dataN निर्देशिका एक अलग डिस्क है
- /डेटा2/कैसंड्रा/डेटा
- /डेटा3/कैसंड्रा/डेटा
- /डेटा4/कैसंड्रा/डेटा
- /डेटा5/कैसंड्रा/डेटा
- /डेटा6/कैसंड्रा/डेटा
- /डेटा7/कैसंड्रा/डेटा
- /डेटा8/कैसंड्रा/डेटा
कमिटलॉग_निर्देशिका: /डेटा9/कैसंड्रा/कमिटलॉग
सीडीसी_सक्षम: गलत
डिस्क_विफलता_नीति: रुकें
प्रतिबद्ध_विफलता_नीति: रुकें
तैयार_कथन_कैश_आकार_एमबी:
बचत_तैयार_कथन_कैश_आकार_एमबी:
key_cache_size_in_mb:
key_cache_save_period: 14400
row_cache_size_in_mb: 0
row_cache_save_period: 0
काउंटर_कैश_आकार_में_एमबी:
काउंटर_कैश_सेव_पीरियड: 7200
save_caches_directory: /data10/cassandra/saven_caches
कमिटलॉग_सिंक: आवधिक
कमिटलॉग_सिंक_पीरियड_इन_एमएस: 10000
कमिटलॉग_सेगमेंट_साइज_इन_एमबी: 32
बीज_प्रदाता:
- क्लास_नाम: org.apache.cassandra.locator.SimpleSeedProvider
पैरामीटर:
- बीज: "*,*"
concurrent_reads: 256 # प्रयास किया 64 - कोई अंतर नजर नहीं आया
concurrent_writes: 256 # प्रयास किया 64 - कोई अंतर नजर नहीं आया
concurrent_counter_writes: 256 # प्रयास किया 64 - कोई अंतर नजर नहीं आया
समवर्ती_भौतिक_दृश्य_लेखन: 32
memtable_heap_space_in_mb: 2048 # 16 जीबी का प्रयास किया - यह धीमा था
मेमटेबल_आवंटन_प्रकार: ढेर_बफ़र्स
सूचकांक_सारांश_क्षमता_in_mb:
Index_summary_resize_interval_in_मिनट: 60
ट्रिकल_fsync: गलत
ट्रिकल_fsync_interval_in_kb: 10240
स्टोरेज_पोर्ट: 7000
एसएसएल_स्टोरेज_पोर्ट: 7001
सुनो_पता: *
ब्रॉडकास्ट पता: *
प्रसारण_पते पर सुनें: सत्य
इंटरनोड_प्रमाणक: org.apache.cassandra.auth.AllowAllInternodeAuthenticator
प्रारंभ_नेटिव_परिवहन: सत्य
देशी_परिवहन_पोर्ट: 9042
प्रारंभ_आरपीसी: सत्य
आरपीसी_पता: *
आरपीसी_पोर्ट: 9160
rpc_keepalive: सत्य
rpc_server_type: सिंक
थ्रिफ्ट_फ़्रेम्ड_ट्रांसपोर्ट_साइज़_इन_एमबी: 15
वृद्धिशील_बैकअप: गलत
स्नैपशॉट_पहले_कॉम्पेक्शन: गलत
ऑटो_स्नैपशॉट: सत्य
column_index_size_in_kb: 64
column_index_cache_size_in_kb: 2
समवर्ती_कॉम्पैक्टर: 4
कॉम्पैक्शन_थ्रूपुट_एमबी_प्रति_सेकंड: 1600
sstable_preemptive_open_interval_in_mb: 50
read_request_timeout_in_ms: 100000
रेंज_रिक्वेस्ट_टाइमआउट_इन_एमएस: 200000
राइट_रिक्वेस्ट_टाइमआउट_इन_एमएस: 40000
काउंटर_राइट_रिक्वेस्ट_टाइमआउट_इन_एमएस: 100000
cas_contention_timeout_in_ms: 20000
ट्रंकेट_रिक्वेस्ट_टाइमआउट_इन_एमएस: 60000
request_timeout_in_ms: 200000
Slow_query_log_timeout_in_ms: 500
क्रॉस_नोड_टाइमआउट: गलत
एंडपॉइंट_स्निच: गॉसिपिंगप्रॉपर्टीफाइलस्निच
डायनामिक_स्निच_अपडेट_इंटरवल_इन_एमएस: 100
डायनामिक_स्निच_रीसेट_इंटरवल_इन_एमएस: 600000
डायनामिक_स्निच_बैडनेस_थ्रेसहोल्ड: 0.1
request_scheduler: org.apache.cassandra.scheduler.NoScheduler
सर्वर_एन्क्रिप्शन_विकल्प:
इंटरनोड_एन्क्रिप्शन: कोई नहीं
क्लाइंट_एन्क्रिप्शन_विकल्प:
सक्षम: गलत
इंटरनोड_संपीड़न: डीसी
इंटर_dc_tcp_nodelay: ग़लत
ट्रेसटाइप_क्वेरी_टीटीएल: 86400
ट्रेसटाइप_रिपेयर_टीटीएल: 604800
Enable_user_Defined_functions: गलत
Enable_scripted_user_Defined_functions: गलत
विंडोज़_टाइमर_इंटरवल: 1
पारदर्शी_डेटा_एन्क्रिप्शन_विकल्प:
सक्षम: गलत
टॉम्बस्टोन_वार्न_थ्रेसहोल्ड: 1000
टॉम्बस्टोन_विफलता_सीमा: 100000
बैच_आकार_चेतावनी_सीमा_में_केबी: 200
बैच_साइज_फेल_थ्रेसहोल्ड_इन_केबी: 250
अनलॉग्ड_बैच_क्रॉस_पार्टीशन_वार्न_थ्रेसहोल्ड: 10
संघनन_बड़ा_विभाजन_चेतावनी_सीमा_एमबी: 100
gc_warn_threshold_in_ms: 1000
बैक_प्रेशर_सक्षम: गलत
Enable_materialized_views: सत्य
Enable_sasi_indexes: सत्य

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

### सीएमएस सेटिंग्स-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
-XX:+CMSParallelRemarkEnabled
-XX:उत्तरजीवी अनुपात=8
-XX:मैक्सटेन्योरिंगथ्रेसहोल्ड=1
-XX:CMSInitiatingOccupancyFraction=75
-XX:+केवलCMSInitiatingOccupancy का उपयोग करें
-XX:CMSWaitDuration=10000
-XX:+CMSPallelInitialMarkEnabled
-XX:+CMSEdenChunksRecordAlways
-XX:+CMSClassUnloadingEnabled

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

तालिकाएँ कमांड के साथ बनाई गईं:

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

एचबी संस्करण: 1.2.0-सीडीएच5.14.2 (कक्षा org.apache.hadoop.hbase.regionserver.HRegion में हमने मेट्रिक्सरीजन को बाहर कर दिया जिसके कारण रीजनसर्वर पर क्षेत्रों की संख्या 1000 से अधिक होने पर जीसी हुआ)

गैर-डिफ़ॉल्ट HBase पैरामीटरZookeeper.session.timeout: 120000
hbase.rpc.timeout: 2 मिनट
hbase.client.scanner.timeout.period: 2 मिनट
hbase.master.handler.count: 10
hbase.regionserver.lease.period, hbase.client.scanner.timeout.period: 2 मिनट
hbase.regionserver.handler.count: 160
hbase.regionserver.metahandler.count: 30
hbase.regionserver.logroll.period: 4 घंटे
hbase.regionserver.maxlogs: 200
hbase.hregion.memstore.flush.size: 1 GiB
hbase.hregion.memstore.block.multiplier: 6
hbase.hstore.compactionThreshold: 5
hbase.hstore.blockingStoreFiles: 200
hbase.hregion.majarसंक्षरण: 1 दिन
hbase-site.xml के लिए HBase सेवा उन्नत कॉन्फ़िगरेशन स्निपेट (सुरक्षा वाल्व):
hbase.regionserver.wal.codecorg.apache.hadoop.hbase.regionserver.wal.IndexedWALEditCodec
hbase.master.namespace.init.timeout3600000
hbase.regionserver. optioncacheflushinterval18000000
hbase.regionserver.thread.compaction.large12
hbase.regionserver.wal.enablecompressiontrue
hbase.hstore.compaction.max.size1073741824
hbase.server.compactchecker.interval.multiplier200
HBase रीजनसर्वर के लिए जावा कॉन्फ़िगरेशन विकल्प:
-XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70 -XX:+CMSParallelRemarkEnabled -XX:ReservedCodeCacheSize=256m
hbase.snapshot.master.timeoutMillis: 2 मिनट
hbase.snapshot.region.timeout: 2 मिनट
hbase.snapshot.master.timeout.millis: 2 मिनट
HBase REST सर्वर अधिकतम लॉग आकार: 100 MiB
HBase REST सर्वर अधिकतम लॉग फ़ाइल बैकअप: 5
HBase थ्रिफ्ट सर्वर अधिकतम लॉग आकार: 100 MiB
HBase थ्रिफ्ट सर्वर अधिकतम लॉग फ़ाइल बैकअप: 5
मास्टर मैक्स लॉग आकार: 100 एमआईबी
मास्टर अधिकतम लॉग फ़ाइल बैकअप: 5
रीजनसर्वर अधिकतम लॉग आकार: 100 एमआईबी
रीजनसर्वर अधिकतम लॉग फ़ाइल बैकअप: 5
HBase सक्रिय मास्टर डिटेक्शन विंडो: 4 मिनट
dfs.client.hedged.read.threadpool.size: 40
dfs.client.hedged.read.threshold.millis: 10 मिलीसेकंड
hbase.rest.threads.min: 8
hbase.rest.threads.max: 150
अधिकतम प्रक्रिया फ़ाइल डिस्क्रिप्टर: 180000
hbase.thrift.minWorkerThreads: 200
hbase.master.executor.openregion.threads: 30
hbase.master.executor.closeregion.threads: 30
hbase.master.executor.serverops.threads: 60
hbase.regionserver.thread.compaction.small: 6
hbase.ipc.server.read.threadpool.size: 20
रीजन मूवर थ्रेड्स: 6
क्लाइंट जावा हीप आकार बाइट्स में: 1 GiB
HBase REST सर्वर डिफ़ॉल्ट समूह: 3 GiB
HBase थ्रिफ्ट सर्वर डिफ़ॉल्ट समूह: 3 GiB
बाइट्स में HBase मास्टर का जावा हीप आकार: 16 GiB
बाइट्स में HBase रीजनसर्वर का जावा हीप आकार: 32 GiB

+चिड़ियाघरपालक
maxClientCnxns: 601
अधिकतम सत्र समय समाप्त: 120000
तालिकाएँ बनाना:
hbase org.apache.hadoop.hbase.util.RegionSplitter ns:t1 UniformSplit -c 64 -f cf
'ns:t1', {NAME => 'cf', DATA_BLOCK_ENCODING => 'FAST_DIFF', COMPRESSION => 'GZ'} बदलें

यहां एक महत्वपूर्ण बिंदु है - डेटास्टैक्स विवरण यह नहीं बताता है कि एचबी टेबल बनाने के लिए कितने क्षेत्रों का उपयोग किया गया था, हालांकि यह बड़ी मात्रा के लिए महत्वपूर्ण है। इसलिए, परीक्षणों के लिए, मात्रा = 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);
    }
}

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

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

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

ग्राफ़ रूप में वही चीज़:

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

डेटा को सभी नोड्स में समान रूप से वितरित किया गया था, सभी नोड्स के आँकड़े लगभग समान थे।

किसी एक नोड से तालिका आँकड़े इस तरह दिखते हैंमुख्यस्थान: के.एस
पढ़ें गिनती: 9383707
विलंबता पढ़ें: 0.04287025042448576 एमएस
लिखें गिनती: 15462012
लिखने की विलंबता: 0.1350068438699957 एमएस
लंबित फ्लश: 0
तालिका: t1
एसएसटेबल गिनती: 16
प्रयुक्त स्थान (लाइव): 148.59 MiB
प्रयुक्त स्थान (कुल): 148.59 MiB
स्नैपशॉट द्वारा उपयोग किया गया स्थान (कुल): 0 बाइट्स
उपयोग की गई ऑफ हीप मेमोरी (कुल): 5.17 MiB
एसएसटेबल संपीड़न अनुपात: 0.5720989576459437
विभाजनों की संख्या (अनुमान): 3970323
स्मरणीय सेल गिनती: 0
स्मरणीय डेटा का आकार: 0 बाइट्स
मेमटेबल ऑफ हीप मेमोरी का उपयोग किया गया: 0 बाइट्स
स्मरणीय स्विच गिनती: 5
स्थानीय पढ़ने की संख्या: 2346045
स्थानीय पढ़ने की विलंबता: NaN एमएस
स्थानीय लेखन संख्या: 3865503
स्थानीय लेखन विलंबता: NaN एमएस
लंबित फ्लश: 0
मरम्मत का प्रतिशत: 0.0
ब्लूम फ़िल्टर झूठी सकारात्मकता: 25
ब्लूम फ़िल्टर ग़लत अनुपात: 0.00000
प्रयुक्त ब्लूम फ़िल्टर स्थान: 4.57 MiB
उपयोग की गई हीप मेमोरी से ब्लूम फ़िल्टर: 4.57 MiB
प्रयुक्त हीप मेमोरी का सूचकांक सारांश: 590.02 KiB
हीप मेमोरी से संपीड़न मेटाडेटा का उपयोग किया गया: 19.45 KiB
संकुचित विभाजन न्यूनतम बाइट्स: 36
संकुचित विभाजन अधिकतम बाइट्स: 42
संकुचित विभाजन माध्य बाइट्स: 42
प्रति स्लाइस औसत जीवित कोशिकाएं (अंतिम पांच मिनट): NaN
प्रति स्लाइस अधिकतम जीवित कोशिकाएँ (अंतिम पाँच मिनट): 0
प्रति टुकड़ा औसत समाधि पत्थर (अंतिम पाँच मिनट): NaN
प्रति टुकड़ा अधिकतम समाधि पत्थर (अंतिम पाँच मिनट): 0
गिराए गए उत्परिवर्तन: 0 बाइट्स

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

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

एचबी के शक्तिशाली पठन लाभ के संबंध में। यहां आप देख सकते हैं कि दोनों डेटाबेस के लिए, रीडिंग के दौरान डिस्क का उपयोग बेहद कम है (रीड टेस्ट प्रत्येक डेटाबेस के लिए परीक्षण चक्र का अंतिम भाग है, उदाहरण के लिए सीएस के लिए यह 15:20 से 15:40 तक है)। एचबी के मामले में, कारण स्पष्ट है - अधिकांश डेटा मेमोरी में, मेमस्टोर में लटका रहता है, और कुछ ब्लॉक कैश में कैश किया जाता है। सीएस के लिए, यह बहुत स्पष्ट नहीं है कि यह कैसे काम करता है, लेकिन डिस्क रीसाइक्लिंग भी दिखाई नहीं देती है, लेकिन बस मामले में, कैश row_cache_size_in_mb = 2048 को सक्षम करने और कैशिंग सेट करने का प्रयास किया गया था = {'keys': 'ALL', 'rows_per_partition': '2000000'}, लेकिन इससे यह और भी खराब हो गया।

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

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

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

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

यूपीडी: साथियों की सलाह के लिए धन्यवाद, मैं पढ़ने की गति बढ़ाने में कामयाब रहा। था:
159 ऑप्स (644 टेबल, 4 स्ट्रीम, बैच 5)।
द्वारा जोड़ा गया:
.विदलोडबैलेंसिंगपॉलिसी(नया टोकनएवेयरपॉलिसी(डीसीएवेयरराउंडरॉबिनपॉलिसी.बिल्डर().बिल्ड()))
और मैंने धागों की संख्या के साथ खिलवाड़ किया। परिणाम निम्नलिखित है:
4 टेबल, 100 धागे, बैच = 1 (टुकड़ा दर टुकड़ा): 301 ऑप्स
4 टेबल, 100 धागे, बैच = 10: 447 ऑप्स
4 टेबल, 100 धागे, बैच = 100: 625 ऑप्स

बाद में मैं अन्य ट्यूनिंग युक्तियाँ लागू करूंगा, एक पूर्ण परीक्षण चक्र चलाऊंगा और पोस्ट के अंत में परिणाम जोड़ूंगा।

स्रोत: www.habr.com