🥇दुई याकोजुनाको युद्ध, वा क्यासान्ड्रा बनाम एचबेस। Sberbank टोलीको अनुभव

यो मजाक पनि होइन, यस्तो देखिन्छ कि यो विशेष तस्वीरले यी डाटाबेसहरूको सारलाई सही रूपमा प्रतिबिम्बित गर्दछ, र अन्तमा यो स्पष्ट हुनेछ किन:

DB-Engines Ranking अनुसार, दुई सबैभन्दा लोकप्रिय NoSQL स्तम्भ डेटाबेसहरू क्यासान्ड्रा (यसपछि CS) र HBase (HB) हुन्।

भाग्यको इच्छा अनुसार, Sberbank मा हाम्रो डाटा लोडिङ व्यवस्थापन टोली पहिले नै छ давно र HB सँग नजिकबाट काम गर्दछ। यस समयमा, हामीले यसको बल र कमजोरीहरू राम्ररी अध्ययन गर्यौं र यसलाई कसरी पकाउने भनेर सिक्यौं। जे होस्, CS को रूपमा एक विकल्पको उपस्थितिले हामीलाई सधैं शंकाको साथ आफूलाई सताउन बाध्य बनायो: के हामीले सही छनौट गर्यौं? यसबाहेक, परिणामहरू तुलना, DataStax द्वारा प्रदर्शन, तिनीहरूले भने कि CS ले लगभग एक क्रशिंग स्कोर संग सजिलै HB लाई हराउँछ। अर्कोतर्फ, DataStax एक इच्छुक पार्टी हो, र तपाईंले यसको लागि उनीहरूको शब्द लिनु हुँदैन। हामी परीक्षण सर्तहरूको बारेमा थोरै मात्रामा जानकारीले पनि अलमलमा थियौं, त्यसैले हामीले BigData NoSql को राजा को हो भनेर आफैले पत्ता लगाउने निर्णय गर्‍यौं, र प्राप्त परिणामहरू धेरै रोचक हुन पुगे।

यद्यपि, परीक्षणको नतिजामा जानु अघि, वातावरण कन्फिगरेसनका महत्त्वपूर्ण पक्षहरू वर्णन गर्न आवश्यक छ। तथ्य यो हो कि CS लाई डेटा हराउन अनुमति दिने मोडमा प्रयोग गर्न सकिन्छ। ती। यो तब हुन्छ जब केवल एक सर्भर (नोड) निश्चित कुञ्जीको डाटाको लागि जिम्मेवार हुन्छ, र यदि कुनै कारणले यो असफल भयो भने, यो कुञ्जीको मान हराउनेछ। धेरै कार्यहरूको लागि यो महत्त्वपूर्ण छैन, तर बैंकिङ क्षेत्रको लागि यो नियम भन्दा अपवाद हो। हाम्रो अवस्थामा, भरपर्दो भण्डारणको लागि डाटाको धेरै प्रतिलिपिहरू हुनु महत्त्वपूर्ण छ।

त्यसकारण, ट्रिपल प्रतिकृति मोडमा मात्र CS अपरेटिङ मोडलाई विचार गरियो, अर्थात्। केसस्पेसको सिर्जना निम्न प्यारामिटरहरूसँग गरिएको थियो:

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

अर्को, स्थिरताको आवश्यक स्तर सुनिश्चित गर्न दुई तरिकाहरू छन्। सामान्य नियम:
NW + NR > RF

जसको मतलब यो हो कि (NW) लेख्दा नोडहरूबाट पुष्टिकरणहरूको संख्या र पढ्दा (NR) नोडहरूबाट पुष्टिकरणहरूको संख्या प्रतिकृति कारक भन्दा बढी हुनुपर्छ। हाम्रो अवस्थामा, RF = 3, जसको मतलब निम्न विकल्पहरू उपयुक्त छन्:
२ + २ > ३
२ + २ > ३

हाम्रो लागि डाटालाई सकेसम्म भरपर्दो रूपमा भण्डारण गर्नु मौलिक रूपमा महत्त्वपूर्ण भएकोले, ३+१ योजना छनोट गरिएको थियो। थप रूपमा, HB समान सिद्धान्तमा काम गर्दछ, अर्थात्। यस्तो तुलना अधिक निष्पक्ष हुनेछ।

यो ध्यान दिनुपर्छ कि DataStax ले तिनीहरूको अध्ययनमा उल्टो गर्यो, तिनीहरूले CS र HB दुवैको लागि RF = 1 सेट गरे (पछिल्लोका लागि HDFS सेटिङहरू परिवर्तन गरेर)। यो एक साँच्चै महत्त्वपूर्ण पक्ष हो किनभने यस मामला मा CS प्रदर्शन मा प्रभाव ठूलो छ। उदाहरणका लागि, तलको चित्रले CS मा डाटा लोड गर्न आवश्यक समयको वृद्धि देखाउँछ:

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

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

सबै परीक्षणहरू 4 सर्भरहरू समावेश भएको हार्डवेयर क्लस्टरमा गरिएको थियो, प्रत्येक निम्न कन्फिगरेसनको साथ:

CPU: Xeon E5-2680 v4 @ 2.40GHz 64 थ्रेडहरू।
डिस्क: 12 टुक्रा SATA HDD
java संस्करण: 1.8.0_111

CS संस्करण: 3.11.5

cassandra.yml प्यारामिटरहरूnum_tokens: 256
hinted_handoff_enabled: true
hinted_handoff_throttle_in_kb: 1024
max_hints_delivery_threads: 2
hints_directory: /data10/cassandra/hints
hints_flush_period_in_ms: 10000
max_hints_file_size_in_mb: 128
batchlog_replay_throttle_in_kb: 1024
प्रमाणक: AllowAllAuthenticator
प्राधिकरण: AllowAllAuthorizer
role_manager: CassandraRoleManager
roles_validity_in_ms: 2000
permissions_validity_in_ms: 2000
credentials_validity_in_ms: 2000
विभाजनकर्ता: org.apache.cassandra.dht.Murmur3Partitioner
data_file_directories:
- /data1/cassandra/data # प्रत्येक dataN डाइरेक्टरी एक अलग डिस्क हो
- /data2/cassandra/data
- /data3/cassandra/data
- /data4/cassandra/data
- /data5/cassandra/data
- /data6/cassandra/data
- /data7/cassandra/data
- /data8/cassandra/data
commitlog_directory: /data9/cassandra/commitlog
cdc_enabled: false
disk_failure_policy: रोक्नुहोस्
कमिट_फेल्योर_नीति: रोक्नुहोस्
तयार_बयानहरू_cache_size_mb:
thrift_prepared_statements_cache_size_mb:
key_cache_size_in_mb:
key_cache_save_period: 14400
row_cache_size_in_mb: ०
row_cache_save_period: 0
counter_cache_size_in_mb:
counter_cache_save_period: 7200
saved_caches_directory: /data10/cassandra/saved_caches
कमिटलॉग_सिंक: आवधिक
commitlog_sync_period_in_ms: 10000
commitlog_segment_size_in_mb: 32
seed_provider:
- class_name: org.apache.cassandra.locator.SimpleSeedProvider
प्यारामिटरहरू:
- बीज: "*, *"
concurrent_reads: 256 # प्रयास 64 - कुनै फरक देखिएन
concurrent_writes: 256 # प्रयास 64 - कुनै फरक देखिएन
concurrent_counter_writes: 256 # प्रयास 64 - कुनै फरक देखिएन
concurrent_materialized_view_writes: 32
memtable_heap_space_in_mb: 2048 # 16 GB प्रयास गरियो - यो ढिलो थियो
memtable_allocation_type: heap_buffers
index_summary_capacity_in_mb:
index_summary_resize_interval_in_minutes: 60
trickle_fsync: गलत
trickle_fsync_interval_in_kb: 10240
भण्डारण_पोर्ट: 7000
ssl_storage_port: 7001
सुन्ने_ठेगाना:*
प्रसारण_ठेगाना: *
listen_on_broadcast_address: true
internode_authenticator: org.apache.cassandra.auth.AllowAllInternodeAuthenticator
start_native_transport: सत्य
नेटिभ_ट्रान्सपोर्ट_पोर्ट: ९०४२
start_rpc: सत्य
rpc_address: *
rpc_port: 9160
rpc_keepalive: सत्य
rpc_server_type: सिंक
thrift_framed_transport_size_in_mb: 15
incremental_backups: false
snapshot_before_compaction: false
auto_snapshot: true
column_index_size_in_kb: 64
column_index_cache_size_in_kb: 2
समवर्ती_कम्प्याक्टरहरू: 4
compaction_throughput_mb_per_sec: 1600
sstable_preemptive_open_interval_in_mb: ५०
read_request_timeout_in_ms: 100000
range_request_timeout_in_ms: 200000
write_request_timeout_in_ms: 40000
counter_write_request_timeout_in_ms: 100000
cas_contention_timeout_in_ms: 20000
truncate_request_timeout_in_ms: 60000
request_timeout_in_ms: 200000
slow_query_log_timeout_in_ms: 500
cross_node_timeout: false
endpoint_snitch: GossipingPropertyFileSnitch
dynamic_snitch_update_interval_in_ms: 100
dynamic_snitch_reset_interval_in_ms: 600000
dynamic_snitch_badness_threshold: ०.१
request_scheduler: org.apache.cassandra.scheduler.NoScheduler
सर्भर_इन्क्रिप्शन_विकल्पहरू:
internode_encryption: कुनै पनि छैन
client_encryption_options:
सक्षम: गलत
internode_compression: dc
inter_dc_tcp_nodelay: false
tracetype_query_ttl: 86400
tracetype_repair_ttl: ६०४८००
enable_user_defined_functions: false
enable_scripted_user_defined_functions: false
windows_timer_interval: 1
पारदर्शी_डेटा_इन्क्रिप्शन_विकल्पहरू:
सक्षम: गलत
tombstone_warn_threshold: 1000
tombstone_failure_threshold: 100000
batch_size_warn_threshold_in_kb: 200
batch_size_fail_threshold_in_kb: 250
unlogged_batch_across_partitions_warn_threshold: 10
compaction_large_partition_warning_threshold_mb: 100
gc_warn_threshold_in_ms: 1000
back_pressure_enabled: गलत
enable_materialized_views: true
enable_sasi_indexes: true

GC सेटिङहरू:

### CMS सेटिङहरू-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
-XX:+CMSParallelRemark सक्षम गरियो
-XX: सर्वाइभर अनुपात = 8
-XX: MaxTenuringThreshold=1
-XX:CMSIinitiatingOccupancyFraction=75
-XX:+CMSIप्रारम्भिक पेशा मात्र प्रयोग गर्नुहोस्
-XX: CMSWaitDuration=10000
-XX:+CMSParallelInitialMark सक्षम गरियो
-XX:+CMSEdenChunksRecordAlways
-XX:+CMSCclassUnloading सक्षम गरियो

jvm.options मेमोरी 16Gb आवंटित गरिएको थियो (हामीले 32 Gb को प्रयास पनि गर्यौं, कुनै फरक देखिएन)।

तालिकाहरू आदेशको साथ सिर्जना गरिएको थियो:

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

HB संस्करण: 1.2.0-cdh5.14.2 (वर्ग org.apache.hadoop.hbase.regionserver.HRegion मा हामीले MetricsRegion लाई बहिष्कार गर्यौं जसले GC को नेतृत्व गर्‍यो जब क्षेत्रहरूको संख्या RegionServer मा 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: २ मिनेट(हरू)
hbase.regionserver.handler.count: 160
hbase.regionserver.metahandler.count: ३०
hbase.regionserver.logroll.period: ४ घण्टा(हरू)
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.majorcompaction: 1 दिन(हरू)
hbase-site.xml को लागि HBase सेवा उन्नत कन्फिगरेसन स्निपेट (सेफ्टी भल्भ):
hbase.regionserver.wal.codecorg.apache.hadoop.hbase.regionserver.wal.IndexedWALEditCodec
hbase.master.namespace.init.timeout3600000
hbase.regionserver.optionalcacheflushinterval18000000
hbase.regionserver.thread.compaction.large12
hbase.regionserver.wal.enablecompressiontrue
hbase.hstore.compaction.max.size1073741824
hbase.server.compactchecker.interval.multiplier200
HBase RegionServer का लागि जाभा कन्फिगरेसन विकल्पहरू:
-XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSIinitiatingOccupancyFraction=70 -XX:+CMSParallelRemarkEnabled -XX:ReservedCodeCacheSize=256m
hbase.snapshot.master.timeoutMillis: 2 मिनेट(हरू)
hbase.snapshot.region.timeout: २ मिनेट(हरू)
hbase.snapshot.master.timeout.millis: 2 मिनेट(हरू)
HBase REST सर्भर अधिकतम लग साइज: 100 MiB
HBase REST सर्भर अधिकतम लग फाइल ब्याकअपहरू: 5
HBase Thrift Server अधिकतम लग साइज: 100 MiB
HBase Thrift Server अधिकतम लग फाइल ब्याकअपहरू: 5
मास्टर अधिकतम लग साइज: 100 MiB
मास्टर अधिकतम लग फाइल ब्याकअप: 5
RegionServer अधिकतम लग साइज: 100 MiB
RegionServer अधिकतम लग फाइल ब्याकअप: 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: ३०
hbase.master.executor.closeregion.threads: ३०
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 Thrift Server पूर्वनिर्धारित समूह: 3 GiB
बाइटहरूमा HBase मास्टरको Java हीप साइज: 16 GiB
बाइटमा HBase RegionServer को Java हिप साइज: 32 GiB

+ ZooKeeper
maxClientCnxns: 601
maxSessionTimeout: 120000
तालिकाहरू सिर्जना गर्दै:
hbase org.apache.hadoop.hbase.util.RegionSplitter ns:t1 UniformSplit -c 64 -f cf
alter 'ns:t1', {NAME => 'cf', DATA_BLOCK_ENCODING => 'FAST_DIFF', COMPRESSION => 'GZ'}

यहाँ एउटा महत्त्वपूर्ण बिन्दु छ - डाटास्ट्याक्स विवरणले HB तालिकाहरू सिर्जना गर्न कति क्षेत्रहरू प्रयोग गरिएको थियो भनेर बताउँदैन, यद्यपि यो ठूलो मात्राको लागि महत्त्वपूर्ण छ। त्यसकारण, परीक्षणहरूको लागि, मात्रा = 64 छनोट गरिएको थियो, जसले 640 GB सम्म भण्डारण गर्न अनुमति दिन्छ, अर्थात्। मध्यम आकारको तालिका।

परीक्षणको समयमा, 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);
    }
}

तदनुसार, समान प्रकार्यता HB को लागि प्रदान गरिएको थियो:

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

अब सबैभन्दा रोचक भाग - परिणाम:

ग्राफ फारममा एउटै कुरा:

HB को फाइदा यति अचम्मको छ कि त्यहाँ CS सेटअपमा केहि प्रकारको बाधा छ भन्ने शंका छ। यद्यपि, गुगलिङ र सबैभन्दा स्पष्ट प्यारामिटरहरू (जस्तै समवर्ती_राइट्स वा मेमटेबल_हेप_स्पेस_इन_एमबी) को खोजीले चीजहरूलाई गति दिँदैन। एकै समयमा, लगहरू सफा छन् र कुनै कुरामा कसम खाँदैनन्।

डाटा नोडहरूमा समान रूपमा वितरित गरिएको थियो, सबै नोडहरूबाट तथ्याङ्कहरू लगभग समान थिए।

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

ब्याचको आकार घटाउने प्रयास (यसलाई व्यक्तिगत रूपमा पठाउन पनि) को कुनै प्रभाव थिएन, यो केवल खराब भयो। यो सम्भव छ कि वास्तवमा यो CS को लागि अधिकतम कार्यसम्पादन हो, किनकि CS का लागि प्राप्त नतिजाहरू DataStax को लागि प्राप्त गरिएका परिणामहरूसँग मिल्दोजुल्दो छन् - प्रति सेकेन्डको लगभग सयौं हजार कार्यहरू। थप रूपमा, यदि हामीले संसाधन उपयोगलाई हेर्छौं भने, हामी देख्नेछौं कि CS ले धेरै CPU र डिस्कहरू प्रयोग गर्दछ:

आंकडाले दुबै डाटाबेसका लागि पङ्क्तिमा सबै परीक्षणहरूको रनको समयमा उपयोग देखाउँदछ।

HB को शक्तिशाली पढ्ने फाइदाको बारेमा। यहाँ तपाईले देख्न सक्नुहुन्छ कि दुबै डाटाबेसका लागि, पढ्ने क्रममा डिस्कको उपयोग अत्यन्त कम छ (पढ्ने परीक्षणहरू प्रत्येक डाटाबेसको लागि परीक्षण चक्रको अन्तिम भाग हो, उदाहरणका लागि CS को लागि यो 15:20 देखि 15:40 सम्म हो)। HB को मामला मा, कारण स्पष्ट छ - धेरै जसो डाटा मेमोरीमा ह्याङ्ग हुन्छ, मेमस्टोरमा, र केहि ब्लकक्यासमा क्यास हुन्छ। CS को लागि, यो कसरी काम गर्छ भन्ने धेरै स्पष्ट छैन, तर डिस्क रिसाइक्लिंग पनि देखिँदैन, तर केवल केसमा, क्यास सक्षम गर्ने प्रयास गरियो row_cache_size_in_mb = 2048 र सेट क्यासिंग = {'keys': 'ALL', 'rows_per_partition': '2000000'}, तर यसले यसलाई अझ खराब बनायो।

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

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

निस्सन्देह, यी परीक्षणहरू एकदम सिंथेटिक छन् र यहाँ प्रयोग गरिएको डाटाको मात्रा अपेक्षाकृत मामूली छ। यो सम्भव छ कि यदि हामीले टेराबाइटमा स्विच गर्यौं भने, स्थिति फरक हुनेछ, तर HB को लागी हामी टेराबाइट लोड गर्न सक्छौं, CS को लागी यो समस्याग्रस्त भयो। यसले प्रायः यी भोल्युमहरूको साथमा पनि OperationTimedOutException फ्याँक्यो, यद्यपि प्रतिक्रियाको लागि पर्खने मापदण्डहरू पूर्वनिर्धारित व्यक्तिहरूको तुलनामा धेरै पटक बढाइएको थियो।

मलाई आशा छ कि संयुक्त प्रयास मार्फत हामीले CS को बाधाहरू फेला पार्न सक्छौं र यदि हामीले यसलाई गति दिन सक्छौं भने, पोस्टको अन्त्यमा म निश्चित रूपमा अन्तिम परिणामहरूको बारेमा जानकारी थप्नेछु।

UPD: कमरेडहरूको सल्लाहको लागि धन्यवाद, मैले पढ्ने गति बढाउन सफल भए। थियो:
159 अप्स (644 टेबल, 4 स्ट्रिम, ब्याच 5)।
द्वारा थपिएको:
.withLoadBalancingPolicy(नयाँ TokenAwarePolicy(DCAwareRoundRobinPolicy.builder().build()))
र म थ्रेडहरूको संख्या संग वरिपरि खेल्थे। नतिजा निम्न छ:
4 टेबल, 100 थ्रेड, ब्याच = 1 (टुक्रा टुक्रा): 301 ops
4 टेबल, 100 थ्रेड, ब्याच = 10: 447 ops
4 टेबल, 100 थ्रेड, ब्याच = 100: 625 ops

पछि म अन्य ट्युनिङ सुझावहरू लागू गर्नेछु, पूर्ण परीक्षण चक्र चलाउनेछु र पोस्टको अन्त्यमा परिणामहरू थप्नेछु।

स्रोत: www.habr.com

दुई याकोजुनाको युद्ध, वा क्यासान्ड्रा बनाम एचबेस। Sberbank टोलीको अनुभव

एक टिप्पणी थप्न Отменить ответ