Սա նույնիսկ կատակ չէ, թվում է, թե կոնկրետ այս նկարը առավել ճշգրիտ արտացոլում է այս տվյալների բազաների էությունը, և վերջում պարզ կլինի, թե ինչու.
Ըստ DB-Engines Ranking-ի, NoSQL սյունակային տվյալների երկու ամենատարածվածներն են Cassandra-ն (այսուհետ՝ CS) և HBase-ը (HB):
Ճակատագրի կամքով, Սբերբանկի տվյալների բեռնման կառավարման մեր թիմն արդեն արել է և սերտորեն համագործակցում է HB-ի հետ: Այս ընթացքում բավականին լավ ուսումնասիրեցինք նրա ուժեղ և թույլ կողմերը և սովորեցինք պատրաստել այն։ Սակայն ՔՀ-ի տեսքով այլընտրանքի առկայությունը միշտ ստիպում էր մեզ մի փոքր տանջել կասկածներով՝ ճի՞շտ ընտրություն կատարեցինք։ Ընդ որում, արդյունքները DataStax-ի կատարմամբ, նրանք ասացին, որ CS-ը հեշտությամբ հաղթում է HB-ին գրեթե ջախջախիչ հաշվով։ Մյուս կողմից, DataStax-ը շահագրգիռ կողմ է, և դուք չպետք է ընդունեք նրանց խոսքը: Մեզ շփոթեցրեց նաև թեստավորման պայմանների մասին բավականին փոքր ինֆորմացիան, ուստի որոշեցինք ինքնուրույն պարզել, թե ով է BigData NoSql-ի արքան, և ստացված արդյունքները շատ հետաքրքիր ստացվեցին։
Այնուամենայնիվ, նախքան կատարված թեստերի արդյունքներին անցնելը, անհրաժեշտ է նկարագրել շրջակա միջավայրի կոնֆիգուրացիաների էական կողմերը: Փաստն այն է, որ CS-ը կարող է օգտագործվել այնպիսի ռեժիմով, որը թույլ է տալիս տվյալների կորուստը: Նրանք. սա այն դեպքում, երբ միայն մեկ սերվեր (հանգույց) է պատասխանատու որոշակի բանալու տվյալների համար, և եթե ինչ-ինչ պատճառներով այն ձախողվի, ապա այս բանալի արժեքը կկորչի: Շատ առաջադրանքների համար դա կարևոր չէ, բայց բանկային հատվածի համար սա բացառություն է, քան կանոն: Մեր դեպքում կարևոր է ունենալ տվյալների մի քանի օրինակ՝ հուսալի պահպանման համար:
Հետևաբար, դիտարկվել է միայն CS-ի գործառնական ռեժիմը եռակի կրկնօրինակման ռեժիմում, այսինքն. Գործերի տարածության ստեղծումն իրականացվել է հետևյալ պարամետրերով.
CREATE KEYSPACE ks WITH REPLICATION = {'class' : 'NetworkTopologyStrategy', 'datacenter1' : 3};
Հաջորդը, հետևողականության պահանջվող մակարդակն ապահովելու երկու եղանակ կա. Ընդհանուր կանոն.
NW + NR > ՌԴ
Ինչը նշանակում է, որ հանգույցներից հաստատումների թիվը գրելիս (NW) գումարած հանգույցներից հաստատումների թիվը կարդալիս (NR) պետք է լինի ավելի մեծ, քան կրկնօրինակման գործակիցը: Մեր դեպքում RF = 3, ինչը նշանակում է, որ հետևյալ տարբերակները հարմար են.
2 + 2 > 3
3 + 1 > 3
Քանի որ մեզ համար սկզբունքորեն կարևոր է հնարավորինս հուսալիորեն պահել տվյալները, ընտրվել է 3+1 սխեման: Բացի այդ, HB-ն աշխատում է նմանատիպ սկզբունքով, այսինքն. նման համեմատությունն ավելի արդարացի կլինի։
Հարկ է նշել, որ DataStax-ն իրենց ուսումնասիրության մեջ հակառակն է արել, նրանք սահմանել են RF = 1 և՛ CS-ի, և՛ HB-ի համար (վերջինիս համար՝ փոխելով HDFS կարգավորումները)։ Սա իսկապես կարևոր ասպեկտ է, քանի որ ազդեցությունը CS-ի կատարման վրա այս դեպքում հսկայական է: Օրինակ, ստորև նկարը ցույց է տալիս տվյալների CS-ում բեռնելու համար պահանջվող ժամանակի աճը.
Այստեղ մենք տեսնում ենք հետևյալը. որքան շատ մրցակցող թելեր գրեն տվյալներ, այնքան ավելի երկար է տևում: Սա բնական է, բայց կարևոր է, որ RF=3-ի համար կատարողականի դեգրադացիան զգալիորեն ավելի բարձր է: Այսինքն, եթե յուրաքանչյուրը 4 աղյուսակի մեջ գրենք 5 թեմա (ընդհանուր 20), ապա RF=3 կորցնում է մոտ 2 անգամ (150 վայրկյան RF=3-ի դիմաց 75-ի համար RF=1): Բայց եթե բեռնվածությունը մեծացնենք՝ տվյալները բեռնելով 8 աղյուսակների մեջ՝ յուրաքանչյուրը 5 թելերով (ընդհանուր 40), ապա RF=3-ի կորուստն արդեն 2,7 անգամ է (375 վայրկյան՝ 138-ի դիմաց):
Թերևս սա մասամբ է CS-ի համար DataStax-ի կողմից իրականացված հաջող բեռնվածության փորձարկման գաղտնիքը, քանի որ HB-ի համար մեր ստենդում կրկնօրինակման գործակիցը 2-ից 3 փոխելը որևէ ազդեցություն չի ունեցել: Նրանք. Սկավառակները մեր կազմաձևման համար HB-ի խոչընդոտ չեն: Այնուամենայնիվ, այստեղ կան բազմաթիվ այլ թակարդներ, քանի որ պետք է նշել, որ HB-ի մեր տարբերակը մի փոքր կարկատվել և շտկվել է, միջավայրերը բոլորովին այլ են և այլն: Հարկ է նաև նշել, որ գուցե ես պարզապես չգիտեմ, թե ինչպես ճիշտ պատրաստել CS, և կան դրա հետ աշխատելու մի քանի ավելի արդյունավետ եղանակներ, և հուսով եմ, որ մենք կիմանանք մեկնաբանություններում: Բայց առաջին հերթին առաջինը:
Բոլոր թեստերն իրականացվել են ապարատային կլաստերի վրա, որը բաղկացած է 4 սերվերից, որոնցից յուրաքանչյուրը ունի հետևյալ կոնֆիգուրացիան.
Պրոցեսոր՝ Xeon E5-2680 v4 @ 2.40 ԳՀց 64 թելեր:
Սկավառակներ՝ 12 հատ SATA HDD
java տարբերակ՝ 1.8.0_111
CS տարբերակ՝ 3.11.5
cassandra.yml պարամետրերթվային նշանները՝ 256
hinted_handoff_enabled՝ ճշմարիտ
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
authenticator: 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՝ կանգառ
commit_failure_policy. կանգառ
ready_statements_cache_size_mb:
thrift_prepared_statements_cache_size_mb:
key_cache_size_in_mb:
key_cache_save_period՝ 14400
row_cache_size_in_mb: 0
row_cache_save_period՝ 0
counter_cache_size_in_mb:
counter_cache_save_period՝ 7200
saved_caches_directory՝ /data10/cassandra/saved_caches
commitlog_sync՝ պարբերական
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 - տարբերություն չի նկատվել
միաժամանակյա_գրում է՝ 256 # փորձված 64 - տարբերություն չի նկատվում
concurrent_counter_writes: 256 # փորձել 64 - տարբերություն չի նկատվել
concurrent_materialized_view_գրում է՝ 32
memtable_heap_space_in_mb: 2048 # փորձված 16 ԳԲ - ավելի դանդաղ էր
memtable_allocation_type՝ heap_buffers
index_summary_capacity_in_mb:
index_summary_resize_interval_min_րոպեներում՝ 60
trickle_fsync: կեղծ
trickle_fsync_interval_in_kb՝ 10240
պահեստավորման_պորտ՝ 7000
ssl_storage_port՝ 7001
listen_հասցե՝ *
հեռարձակման_հասցե՝ *
listen_on_broadcast_address՝ ճիշտ է
internode_authenticator՝ org.apache.cassandra.auth.AllowAllInternodeAuthenticator
start_native_transport՝ ճիշտ է
հայրենի_տրանսպորտային_պորտ՝ 9042
start_rpc: ճիշտ է
rpc_հասցե՝ *
rpc_port՝ 9160
rpc_keepalive: ճշմարիտ
rpc_server_type՝ համաժամեցում
thrift_framed_transport_size_in_mb: 15
incremental_backups՝ կեղծ
snapshot_before_compaction՝ կեղծ
auto_snapshot՝ ճշմարիտ
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: 50
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՝ կեղծ
endpoint_snitch՝ GossipingPropertyFileSnitch
dynamic_snitch_update_interval_in_ms՝ 100
dynamic_snitch_reset_interval_in_ms՝ 600000
dynamic_snitch_badness_sheshold՝ 0.1
request_scheduler՝ org.apache.cassandra.scheduler.NoScheduler
server_encryption_options:
internode_encryption. ոչ մեկը
client_encryption_options:
միացված է՝ կեղծ
internode_compression՝ dc
inter_dc_tcp_nodelay՝ կեղծ
tracetype_query_ttl՝ 86400
tracetype_repair_ttl՝ 604800
enable_user_defined_functions՝ կեղծ
enable_scripted_user_defined_functions՝ կեղծ
windows_timer_interval՝ 1
transparent_data_encryption_options:
միացված է՝ կեղծ
տապանաքար_զգուշացման_շեմ՝ 1000
տապանաքար_տապալման_շեմ՝ 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՝ ճշմարիտ
enable_sasi_indexes՝ ճշմարիտ
GC կարգավորումներ.
### CMS-ի կարգավորումներ-XX:+UseParNewGC
-XX: + ՕգտագործեքConcMarkSweepGC
-XX:+CMSParallelRemark Միացված է
-XX:SurvivorRatio=8
-XX:MaxTenuringThreshold=1
-XX:CMSInitiatingOccupancyFraction=75
-XX:+UseCMSInitiatingOccupancyOnly
-XX:CMSWaitDuration=10000
-XX:+CMSParallelInitialMarkEnabled
-XX:+CMSEdenChunksRecordՄիշտ
-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};HB տարբերակ՝ 1.2.0-cdh5.14.2 (org.apache.hadoop.hbase.regionserver.HRegion դասում մենք բացառեցինք MetricsRegion-ը, որը հանգեցրեց GC-ին, երբ տարածաշրջանների թիվը 1000-ից ավելի էր RegionServer-ում)
Ոչ լռելյայն HBase պարամետրերzookeeper.session.timeout՝ 120000
hbase.rpc.timeout՝ 2 րոպե
hbase.client.scanner.timeout.ժամկետը՝ 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.majorcompaction՝ 1 օր(ներ)
HBase Service Advanced Configuration Snippet (Safety Valve) hbase-site.xml-ի համար.
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
Java-ի կազմաձևման ընտրանքներ HBase RegionServer-ի համար.
-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 Server Max Log չափը՝ 100 ՄԲ
HBase REST սերվերի մատյան ֆայլի առավելագույն կրկնօրինակումներ՝ 5
HBase Thrift Server Max Log չափը՝ 100 ՄԲ
HBase Thrift Server Մատյանների ֆայլերի առավելագույն կրկնօրինակումներ՝ 5
Master Max Log չափը՝ 100 ՄԲ
Հիմնական առավելագույն մատյան ֆայլի կրկնօրինակումներ՝ 5
RegionServer Max Log չափը՝ 100 ՄԲ
Տարածաշրջանի սերվերի մատյան ֆայլի առավելագույն կրկնօրինակում. 5
HBase Active Master Detection Window՝ 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
Հաճախորդի Java կույտի չափը բայթերով՝ 1 ԳԲ
HBase REST սերվերի լռելյայն խումբ՝ 3 ԳԲ
HBase Thrift սերվերի լռելյայն խումբ՝ 3 ԳԲ
Java Heap HBase Master-ի չափը բայթերով՝ 16 ԳԲ
Java Heap HBase RegionServer-ի չափը բայթերով՝ 32 ԳԲ
+Կենդանաբանական այգու պահապան
maxClientCnxns՝ 601
maxSessionTimeout՝ 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'}
Այստեղ կա մեկ կարևոր կետ. DataStax նկարագրությունը չի ասում, թե քանի շրջան է օգտագործվել HB աղյուսակների ստեղծման համար, թեև դա կարևոր է մեծ ծավալների համար: Հետևաբար, թեստերի համար ընտրվել է քանակ = 64, որը թույլ է տալիս պահել մինչև 640 ԳԲ, այսինքն. միջին չափի սեղան.
Փորձարկման պահին HBase-ն ուներ 22 հազար աղյուսակ և 67 հազար շրջան (սա մահացու կլիներ 1.2.0 տարբերակի համար, եթե չլիներ վերը նշված կարկատելը):
Հիմա կոդը: Քանի որ պարզ չէր, թե կոնկրետ տվյալների բազայի համար որ կոնֆիգուրացիաներն էին ավելի ձեռնտու, փորձարկումներն իրականացվեցին տարբեր համակցություններով: Նրանք. Որոշ թեստերում միաժամանակ բեռնվել են 4 աղյուսակներ (միացման համար օգտագործվել են բոլոր 4 հանգույցները): Մյուս թեստերում մենք աշխատել ենք 8 տարբեր աղյուսակների հետ: Որոշ դեպքերում խմբաքանակի չափը եղել է 100, մյուսներում՝ 200 (խմբաքանակի պարամետր - տե՛ս ստորև նշված կոդը): Արժեքի համար տվյալների չափը 10 բայթ է կամ 100 բայթ (dataSize): Ընդհանուր առմամբ, յուրաքանչյուր աղյուսակում յուրաքանչյուր անգամ գրվել և կարդացվել է 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-ի տեղադրման մեջ ինչ-որ խցան կա: Այնուամենայնիվ, Google-ը և առավել ակնհայտ պարամետրերի որոնումը (օրինակ՝ concurrent_writes կամ memtable_heap_space_in_mb) չեն արագացրել ամեն ինչ: Միևնույն ժամանակ, գերանները մաքուր են և ոչինչ չեն հայհոյում:
Տվյալները հավասարապես բաշխվեցին հանգույցների վրա, բոլոր հանգույցների վիճակագրությունը մոտավորապես նույնն էր:
Ահա թե ինչ տեսք ունի աղյուսակի վիճակագրությունը հանգույցներից մեկիցKeyspace: ks
Կարդացված քանակ՝ 9383707
Կարդալ ուշացում՝ 0.04287025042448576 ms
Գրելու համար՝ 15462012
Գրելու ուշացում՝ 0.1350068438699957 ms
Սպասվող ողողումներ՝ 0
Աղյուսակ՝ t1
SST-ների քանակը՝ 16
Օգտագործված տարածք (ուղիղ)՝ 148.59 ՄԲ
Օգտագործված տարածք (ընդհանուր)՝ 148.59 ՄԲ
Պատկերների օգտագործած տարածքը (ընդհանուր)՝ 0 բայթ
Օգտագործված անջատված կույտային հիշողություն (ընդհանուր)՝ 5.17 ՄԲ
SSTable սեղմման հարաբերակցություն՝ 0.5720989576459437
Միջնորմների քանակը (հաշվարկային)՝ 3970323
Memtable բջիջների քանակը՝ 0
Memtable տվյալների չափը՝ 0 բայթ
Memtable անջատված կույտային հիշողություն՝ 0 բայթ
Memtable անջատիչների քանակը՝ 5
Տեղական ընթերցումների քանակը՝ 2346045
Տեղական ընթերցման ուշացում՝ NaN ms
Տեղական գրությունների քանակը՝ 3865503
Տեղական գրելու ուշացում՝ NaN ms
Սպասվող լվացումներ՝ 0
Վերանորոգման տոկոս՝ 0.0
Bloom ֆիլտրի կեղծ պոզիտիվներ՝ 25
Ծաղկման ֆիլտրի կեղծ հարաբերակցությունը` 0.00000
Bloom ֆիլտրի տարածություն՝ 4.57 ՄԲ
Օգտագործված «Bloom filter off» կուտակային հիշողությունը՝ 4.57 ՄԲ
Օգտագործված կույտային հիշողություն ինդեքսի ամփոփագիր՝ 590.02 ԿԲ
Օգտագործված կույտային հիշողության սեղմման մետատվյալներ՝ 19.45 ԿԲ
Կոմպակտ բաժանման նվազագույն բայթ՝ 36
Կոմպակտ բաժանման առավելագույն բայթ՝ 42
Կոմպակտ բաժանման միջին բայթ՝ 42
Միջին կենդանի բջիջները մեկ կտորի համար (վերջին հինգ րոպեները)՝ NaN
Առավելագույն կենդանի բջիջները մեկ կտորի համար (վերջին հինգ րոպեն)՝ 0
Միջին տապանաքարերը մեկ կտորի համար (վերջին հինգ րոպեն)՝ NaN
Շիրմաքարերի առավելագույն քանակը մեկ կտորի համար (վերջին հինգ րոպեն)՝ 0
Անցած մուտացիաներ՝ 0 բայթ
Խմբաքանակի չափը փոքրացնելու փորձը (նույնիսկ առանձին ուղարկելը) ոչ մի արդյունք չտվեց, այն միայն վատացավ։ Հնարավոր է, որ իրականում սա իսկապես առավելագույն կատարումն է CS-ի համար, քանի որ CS-ի համար ստացված արդյունքները նման են DataStax-ի համար ստացվածներին՝ մոտ հարյուր հազարավոր գործողություններ վայրկյանում: Բացի այդ, եթե նայենք ռեսուրսների օգտագործմանը, կտեսնենք, որ CS-ն ավելի շատ պրոցեսոր և սկավառակներ է օգտագործում.
Նկարը ցույց է տալիս անընդմեջ բոլոր թեստերի օգտագործումը երկու տվյալների բազաների համար:
Ինչ վերաբերում է HB-ի հզոր ընթերցանության առավելությունին. Այստեղ դուք կարող եք տեսնել, որ երկու տվյալների բազաների համար էլ ընթերցման ընթացքում սկավառակի օգտագործումը չափազանց ցածր է (ընթերցման թեստերը յուրաքանչյուր տվյալների բազայի համար թեստավորման ցիկլի վերջին մասն են, օրինակ՝ CS-ի համար սա 15:20-ից 15:40-ն է): HB-ի դեպքում պատճառը պարզ է՝ տվյալների մեծ մասը կախված է հիշողության մեջ՝ memstore-ում, իսկ մի մասը պահվում է բլոկքեշում։ Ինչ վերաբերում է CS-ին, այնքան էլ պարզ չէ, թե ինչպես է այն աշխատում, բայց սկավառակի վերամշակումը նույնպես տեսանելի չէ, բայց ամեն դեպքում փորձ է արվել միացնել քեշը row_cache_size_in_mb = 2048 և սահմանել caching = {'keys': 'ALL', 'rows_per_partition': '2000000'}, բայց դա նույնիսկ մի փոքր ավելի վատացրեց:
Հարկ է ևս մեկ անգամ նշել մի կարևոր կետ ՀԲ-ում մարզերի թվի վերաբերյալ. Մեր դեպքում արժեքը նշվել է որպես 64, եթե այն փոքրացնում ես և հավասարեցնում, օրինակ, 4-ի, ապա կարդալիս արագությունը նվազում է 2 անգամ։ Պատճառն այն է, որ memstore-ն ավելի արագ կլցվի, և ֆայլերը ավելի հաճախ կփչանան, իսկ կարդալիս ավելի շատ ֆայլեր պետք է մշակվեն, ինչը բավականին բարդ գործողություն է HB-ի համար։ Իրական պայմաններում դա կարելի է վերաբերվել՝ մտածելով նախնական բաժանման և կոմպակտացման ռազմավարության միջոցով, մասնավորապես, մենք օգտագործում ենք ինքնուրույն գրավոր ծրագիր, որը հավաքում է աղբը և սեղմում HFiles-ը անընդհատ ֆոնին: Միանգամայն հնարավոր է, որ DataStax թեստերի համար նրանք հատկացրել են ընդամենը 1 շրջան յուրաքանչյուր աղյուսակի համար (ինչը ճիշտ չէ), և դա որոշակիորեն կպարզաբանի, թե ինչու է HB-ն այդքան զիջում իրենց ընթերցանության թեստերում:
Դրանից բխում են հետևյալ նախնական եզրակացությունները. Ենթադրելով, որ փորձարկման ընթացքում որևէ լուրջ սխալ չի արվել, ապա Կասանդրան կարծես կավե ոտքերով վիթխարի է: Ավելի ճիշտ, երբ նա հավասարակշռում է մեկ ոտքի վրա, ինչպես հոդվածի սկզբի նկարում, համեմատաբար լավ արդյունքներ է ցույց տալիս, բայց նույն պայմաններում մենամարտում նա պարտվում է բացարձակապես։ Միևնույն ժամանակ, հաշվի առնելով մեր սարքաշարի վրա պրոցեսորի ցածր օգտագործումը, մենք սովորեցինք տեղադրել երկու RegionServer HB յուրաքանչյուր հոսթին և այդպիսով կրկնապատկել կատարողականը: Նրանք. Հաշվի առնելով ռեսուրսների օգտագործումը, ԿՀ-ի վիճակն էլ ավելի անմխիթար է։
Իհարկե, այս թեստերը բավականին սինթետիկ են, և այստեղ օգտագործված տվյալների քանակը համեմատաբար համեստ է: Հնարավոր է, որ եթե անցնեինք տերաբայթի, իրավիճակն այլ լիներ, բայց եթե HB-ի համար մենք կարող ենք բեռնել տերաբայթեր, ապա CS-ի համար սա խնդրահարույց ստացվեց։ Այն հաճախ գցում էր OperationTimedOutException նույնիսկ այս ծավալների դեպքում, չնայած պատասխանին սպասելու պարամետրերն արդեն մի քանի անգամ ավելացել էին լռելյայնի համեմատ:
Հուսով եմ, որ համատեղ ջանքերով մենք կգտնենք CS-ի խցանումները, և եթե կարողանանք արագացնել այն, ապա գրառման վերջում ես անպայման կավելացնեմ տեղեկատվություն վերջնական արդյունքների մասին։
UPD- Ընկերների խորհուրդների շնորհիվ ես կարողացա արագացնել ընթերցանությունը: էր.
159 օպերացիա (644 սեղան, 4 հոսք, խմբաքանակ 5):
Ավելացրել է ՝
.withLoadBalancingPolicy(new TokenAwarePolicy(DCAwareRoundRobinPolicy.builder().build()))
Եվ ես խաղում էի թելերի քանակով։ Արդյունքը հետևյալն է.
4 սեղան, 100 թել, խմբաքանակ = 1 (հատ առ կտոր)՝ 301 օպ.
4 աղյուսակ, 100 թել, խմբաքանակ = 10: 447 օպս
4 աղյուսակ, 100 թել, խմբաքանակ = 100: 625 օպս
Հետագայում ես կկիրառեմ թյունինգի այլ խորհուրդներ, կանցկացնեմ ամբողջական թեստային ցիկլ և կավելացնեմ արդյունքները գրառման վերջում:
Source: www.habr.com