ProHoster > Blogs > Administrācija > Divu jakozunu cīņa jeb Kasandra vs HBase. Sberbank komandas pieredze

Divu jakozunu cīņa jeb Kasandra vs HBase. Sberbank komandas pieredze

Tas pat nav joks, Ŕķiet, ka tieÅ”i Ŕī bilde visprecÄ«zāk atspoguļo Å”o datu bāzu bÅ«tÄ«bu, un beigās bÅ«s skaidrs, kāpēc:

Divu jakozunu cīņa jeb Kasandra vs HBase. Sberbank komandas pieredze

Saskaņā ar DB-Engines Ranking, divas populārākās NoSQL kolonnu datu bāzes ir Cassandra (turpmāk CS) un HBase (HB).

Divu jakozunu cīņa jeb Kasandra vs HBase. Sberbank komandas pieredze

Pēc likteņa gribas mÅ«su datu ielādes vadÄ«bas komanda Sberbank to jau ir izdarÄ«jusi sen un cieÅ”i sadarbojas ar HB. Å ajā laikā mēs diezgan labi izpētÄ«jām tās stiprās un vājās puses un iemācÄ«jāmies to pagatavot. Tomēr alternatÄ«vas klātbÅ«tne CS formā vienmēr lika mums sevi nedaudz mocÄ«t ar Å”aubām: vai mēs izdarÄ«jām pareizo izvēli? Turklāt rezultāti salÄ«dzinājumi, ko veica DataStax, viņi teica, ka CS viegli pārspēj HB ar gandrÄ«z satriecoÅ”u rezultātu. No otras puses, DataStax ir ieinteresēta puse, un jums nevajadzētu pieņemt viņu vārdu. MÅ«s mulsināja arÄ« diezgan mazais informācijas apjoms par testÄ“Å”anas apstākļiem, tāpēc nolēmām paÅ”i noskaidrot, kurÅ” ir BigData NoSql karalis, un iegÅ«tie rezultāti izrādÄ«jās ļoti interesanti.

Tomēr, pirms pāriet pie veikto testu rezultātiem, ir jāapraksta vides konfigurāciju bÅ«tiskie aspekti. Fakts ir tāds, ka CS var izmantot režīmā, kas ļauj zaudēt datus. Tie. tas ir tad, kad par noteiktas atslēgas datiem atbild tikai viens serveris (mezgls), un ja kāda iemesla dēļ tas neizdodas, tad Ŕīs atslēgas vērtÄ«ba tiks zaudēta. Daudziem uzdevumiem tas nav bÅ«tiski, bet banku sektoram tas ir drÄ«zāk izņēmums, nevis likums. MÅ«su gadÄ«jumā ir svarÄ«gi, lai bÅ«tu vairākas datu kopijas droÅ”ai uzglabāŔanai.

Tāpēc tika ņemts vērā tikai CS darbÄ«bas režīms trÄ«skārŔā replikācijas režīmā, t.i. Lietu telpas izveide tika veikta ar Ŕādiem parametriem:

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

Tālāk ir divi veidi, kā nodroÅ”ināt nepiecieÅ”amo konsekvences lÄ«meni. Vispārējs noteikums:
ZR + NR > RF

Tas nozÄ«mē, ka apstiprinājumu skaitam no mezgliem rakstÄ«Å”anas laikā (NW) plus apstiprinājumu skaitam no mezgliem lasÄ«Å”anas laikā (NR) ir jābÅ«t lielākam par replikācijas koeficientu. MÅ«su gadÄ«jumā RF = 3, kas nozÄ«mē, ka ir piemērotas Ŕādas iespējas:
2 + 2 > 3
3 + 1 > 3

Tā kā mums ir bÅ«tiski svarÄ«gi datus glabāt pēc iespējas uzticamāk, tika izvēlēta shēma 3+1. Turklāt HB darbojas pēc lÄ«dzÄ«ga principa, t.i. Ŕāds salÄ«dzinājums bÅ«s godÄ«gāks.

Jāpiebilst, ka DataStax savā pētÄ«jumā rÄ«kojās pretēji, viņi uzstādÄ«ja RF = 1 gan CS, gan HB (pēdējam mainot HDFS iestatÄ«jumus). Tas ir patieŔām svarÄ«gs aspekts, jo ietekme uz CS veiktspēju Å”ajā gadÄ«jumā ir milzÄ«ga. Piemēram, zemāk esoÅ”ajā attēlā ir redzams laika pieaugums, kas nepiecieÅ”ams datu ielādei CS:

Divu jakozunu cīņa jeb Kasandra vs HBase. Sberbank komandas pieredze

Å eit mēs redzam sekojoÅ”o: jo vairāk konkurējoÅ”u pavedienu ieraksta datus, jo ilgāks laiks ir nepiecieÅ”ams. Tas ir dabiski, taču ir svarÄ«gi, lai RF=3 veiktspējas pasliktināŔanās bÅ«tu ievērojami lielāka. Citiem vārdiem sakot, ja mēs ierakstām 4 pavedienus 5 tabulās katrā (kopā 20), tad RF=3 zaudē apmēram 2 reizes (150 sekundes RF=3 pret 75 RF=1). Bet ja palielina slodzi, ielādējot datus 8 tabulās ar 5 pavedieniem katrā (kopā 40), tad RF=3 zudums jau ir 2,7 reizes (375 sekundes pret 138).

VarbÅ«t tas daļēji ir DataStax for CS veiksmÄ«gās slodzes pārbaudes noslēpums, jo HB mÅ«su stendā replikācijas koeficienta maiņa no 2 uz 3 nedeva nekādu efektu. Tie. diski nav HB saÅ”aurinājums mÅ«su konfigurācijai. Tomēr Å”eit ir daudz citu slazdu, jo jāņem vērā, ka mÅ«su HB versija tika nedaudz lāpÄ«ta un pielabota, vides ir pilnÄ«gi atŔķirÄ«gas utt. Ir arÄ« vērts atzÄ«mēt, ka, iespējams, es vienkārÅ”i nezinu, kā pareizi sagatavot CS, un ir daži efektÄ«vāki veidi, kā ar to strādāt, un es ceru, ka mēs to uzzināsim komentāros. Bet vispirms vispirms.

Visi testi tika veikti aparatūras klasterī, kas sastāv no 4 serveriem, katrs ar Ŕādu konfigurāciju:

CPU: Xeon E5-2680 v4 @ 2.40 GHz 64 pavedieni.
Diski: 12 gab SATA HDD
java versija: 1.8.0_111

CS versija: 3.11.5

cassandra.yml parametritokenu skaits: 256
hinted_handoff_enabled: patiess
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
autentifikators: AllowAllAuthenticator
autorizētājs: AllowAllAuthorizer
role_manager: CassandraRoleManager
roles_validity_in_ms: 2000
permissions_validity_in_ms: 2000
credentials_validity_in_ms: 2000
sadalītājs: org.apache.cassandra.dht.Murmur3Partitioner
data_file_directories:
- /data1/cassandra/data # katrs datuN direktorijs ir atseviŔķs disks
- /data2/cassandra/data
- /data3/cassandra/data
- /data4/cassandra/data
- /data5/cassandra/data
- /data6/cassandra/data
- /data7/cassandra/data
- /data8/cassandra/data
commitlog_direktorijs: /data9/cassandra/commitlog
cdc_enabled: false
disk_failure_policy: stop
commit_failure_policy: stop
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: periodisks
commitlog_sync_period_in_ms: 10000
commitlog_segment_size_in_mb: 32
seed_provider:
- klases_nosaukums: org.apache.cassandra.locator.SimpleSeedProvider
parametri:
ā€” sēklas: "*,*"
concurrent_reads: 256 # mēģinājuÅ”i 64 ā€” atŔķirÄ«ba nav pamanÄ«ta
concurrent_writes: 256 # izmēģināts 64 - atŔķirÄ«ba nav pamanÄ«ta
concurrent_counter_writes: 256 # izmēģināts 64 - atŔķirÄ«ba nav manÄ«ta
concurrent_materialized_view_writes: 32
memtable_heap_space_in_mb: 2048 # izmēģināju 16 GB ā€” tas bija lēnāks
memtable_allocation_type: kaudzes_buferi
index_summary_capacity_in_mb:
index_summary_resize_interval_in_minutes: 60
trickle_fsync: nepatiess
trickle_fsync_interval_in_kb: 10240
Storage_port: 7000
ssl_storage_port: 7001
klausīŔanās_adrese: *
apraides_adrese: *
listen_on_broadcast_address: true
internode_authenticator: org.apache.cassandra.auth.AllowAllInternodeAuthenticator
start_native_transport: taisnība
native_transport_port: 9042
start_rpc: taisnība
rpc_address: *
rpc_port: 9160
rpc_keepalive: taisnība
rpc_server_type: sinhronizācija
thrift_framed_transport_size_in_mb: 15
incremental_backups: false
snapshot_before_compaction: false
auto_snapshot: taisnība
column_index_size_in_kb: 64
column_index_cache_size_in_kb: 2
concurrent_compactors: 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: false
endpoint_snitch: GossipingPropertyFileSnitch
dynamic_snitch_update_interval_in_ms: 100
dynamic_snitch_reset_interval_in_ms: 600000
dynamic_snitch_badness_threshold: 0.1
request_scheduler: org.apache.cassandra.scheduler.NoScheduler
server_encryption_options:
internode_encryption: nav
client_encryption_options:
iespējots: false
internode_compression: dc
inter_dc_tcp_nodelay: false
tracetype_query_ttl: 86400
tracetype_repair_ttl: 604800
enable_user_defined_functions: false
enable_scripted_user_defined_functions: false
windows_timer_interval: 1
transparent_data_encryption_options:
iespējots: false
kapa piemineklis_brīdinājuma slieksnis: 1000
kapakmens_neveiksmes_slieksnis: 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: false
enable_materialized_views: patiess
enable_sasi_indexes: true

GC iestatījumi:

### SPS iestatījumi-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
-XX:+CMSParallelRemarkEnabled
-XX:SurvivorRatio=8
-XX:MaxTenuringThreshold=1
-XX:CMSInitiatingOccupancyFraction=75
-XX:+Izmantojiet CMSIinitiatingOccupancyOnly
-XX:CMSWaitDuration=10000
-XX:+CMSParallelInitialMarkEnabled
-XX:+CMSEdenChunksRecordAlways
-XX:+CMSClassUnloadingEnabled

jvm.options atmiņai tika atvēlēti 16Gb (mēs pamēģinājām arÄ« 32Gb, atŔķirÄ«ba netika manÄ«ta).

Tabulas tika izveidotas ar komandu:

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

HB versija: 1.2.0-cdh5.14.2 (klasē org.apache.hadoop.hbase.regionserver.HRegion mēs izslēdzām MetricsRegion, kas noveda pie GC, kad RegionServer reģionu skaits pārsniedza 1000)

HBase parametri, kas nav noklusējuma iestatījumizookeeper.session.timeout: 120000
hbase.rpc.timeout: 2 minÅ«te(s)
hbase.client.scanner.timeout.period: 2 minÅ«te(s)
hbase.master.handler.count: 10
hbase.regionserver.lease.period, hbase.client.scanner.timeout.period: 2 minÅ«te(s)
hbase.regionserver.handler.count: 160
hbase.regionserver.metahandler.count: 30
hbase.regionserver.logroll.period: 4 stunda(s)
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 diena(s)
HBase pakalpojuma papildu konfigurācijas fragments (droŔības vārsts) vietnei 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 konfigurācijas opcijas HBase RegionServer:
-XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70 -XX:+CMSParallelRemarkEnabled -XX:ReservedCodeCacheSize=256m
hbase.snapshot.master.timeoutMillis: 2 minÅ«te(s)
hbase.snapshot.region.timeout: 2 minÅ«te(s)
hbase.snapshot.master.timeout.millis: 2 minÅ«te(s)
HBase REST servera maksimālais žurnāla izmērs: 100 MiB
HBase REST servera maksimālais žurnālfaila dublējumkopijas: 5
HBase Thrift servera maksimālais žurnāla izmērs: 100 MiB
HBase Thrift servera maksimālais žurnālfaila dublējumkopijas: 5
Master Max žurnāla izmērs: 100 MiB
Galvenās maksimālās žurnālfaila dublējumkopijas: 5
RegionServer Max žurnāla izmērs: 100 MiB
RegionServer maksimālie žurnālfailu dublējumkopijas: 5
HBase aktÄ«vā galvenā noteikÅ”anas logs: 4 minÅ«te(s)
dfs.client.hedged.read.threadpool.size: 40
dfs.client.hedged.read.threshold.millis: 10 milisekundes(s)
hbase.rest.threads.min: 8
hbase.rest.threads.max: 150
Maksimālie procesa failu deskriptori: 180000 XNUMX
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
Region Mover pavedieni: 6
Klienta Java kaudzes lielums baitos: 1 GiB
HBase REST servera noklusējuma grupa: 3 GiB
HBase Thrift servera noklusējuma grupa: 3 GiB
Java kaudzes HBase Master lielums baitos: 16 GiB
Java kaudzes HBase RegionServer lielums baitos: 32 GiB

+ZooKeeper
maxClientCnxns: 601
maxSessionTimeout: 120000
Tabulu izveide:
hbase org.apache.hadoop.hbase.util.RegionSplitter ns:t1 UniformSplit -c 64 -f cf
mainīt 'ns:t1', {NAME => 'cf', DATA_BLOCK_ENCODING => 'FAST_DIFF', COMPRESSION => 'GZ'}

Å eit ir viens svarÄ«gs punkts - DataStax aprakstā nav norādÄ«ts, cik reÄ£ionu tika izmantoti HB tabulu izveidoÅ”anai, lai gan tas ir ļoti svarÄ«gi lieliem apjomiem. Tāpēc testiem tika izvēlēts daudzums = 64, kas ļauj uzglabāt lÄ«dz 640 GB, t.i. vidēja izmēra galds.

Testa laikā HBase bija 22 tÅ«kstoÅ”i tabulu un 67 tÅ«kstoÅ”i reÄ£ionu (tas bÅ«tu bijis letāls versijai 1.2.0, ja ne iepriekÅ” minētais ielāps).

Tagad par kodu. Tā kā nebija skaidrs, kuras konfigurācijas konkrētai datubāzei bija izdevÄ«gākas, tika veikti testi dažādās kombinācijās. Tie. dažos testos vienlaikus tika ielādētas 4 tabulas (savienojumam tika izmantoti visi 4 mezgli). Citos testos strādājām ar 8 dažādām tabulām. Dažos gadÄ«jumos partijas lielums bija 100, citos 200 (partijas parametrs - skatÄ«t kodu zemāk). VērtÄ«bas datu lielums ir 10 baiti vai 100 baiti (dataSize). Kopumā katrā tabulā tika ierakstÄ«ti un nolasÄ«ti 5 miljoni ierakstu katru reizi. Tajā paŔā laikā katrā tabulā tika ierakstÄ«ti/nolasÄ«ti 5 pavedieni (pavediena numurs - thNum), no kuriem katrs izmantoja savu atslēgu diapazonu (skaits = 1 miljons):

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

Attiecīgi HB tika nodroŔināta līdzīga funkcionalitāte:

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

Tā kā HB klientam ir jārÅ«pējas par vienmērÄ«gu datu sadalÄ«jumu, galvenā sālÄ«Å”anas funkcija izskatÄ«jās Ŕādi:

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

Tagad interesantākā daļa - rezultāti:

Divu jakozunu cīņa jeb Kasandra vs HBase. Sberbank komandas pieredze

Tas pats diagrammas formā:

Divu jakozunu cīņa jeb Kasandra vs HBase. Sberbank komandas pieredze

HB priekÅ”rocÄ«ba ir tik pārsteidzoÅ”a, ka rodas aizdomas, ka CS iestatÄ«jumos ir kāds vājÅ” kakls. Tomēr googlÄ“Å”ana un acÄ«mredzamāko parametru (piemēram, concurrent_writes vai memtable_heap_space_in_mb) meklÄ“Å”ana nepaātrina darbÄ«bu. Tajā paŔā laikā baļķi ir tÄ«ri un ne par ko nezvēr.

Dati tika sadalīti vienmērīgi pa mezgliem, statistika no visiem mezgliem bija aptuveni vienāda.

Šādi izskatās tabulas statistika no viena no mezgliemTaustiņu atstarpe: ks
Lasījumu skaits: 9383707
LasīŔanas latentums: 0.04287025042448576 ms
Rakstu skaits: 15462012
RakstīŔanas latentums: 0.1350068438699957 ms
Gaidāmie skalojumi: 0
Tabula: t1
SST tabulu skaits: 16
Izmantotā vieta (tieÅ”raidē): 148.59 MiB
Izmantotā vieta (kopā): 148.59 MiB
Momentuzņēmumu izmantotā vieta (kopā): 0 baiti
Izmantotā kaudzītes atmiņa (kopā): 5.17 MiB
SSTable kompresijas pakāpe: 0.5720989576459437
Starpsienu skaits (aptuvenais): 3970323
Iegaumējamo Ŕūnu skaits: 0
Iegaumējamo datu lielums: 0 baiti
Izmantotā iegaumējamā kaudzes atmiņa: 0 baitu
Iegaumējamo slēdžu skaits: 5
Vietējais lasīto skaits: 2346045
Vietējais lasÄ«Å”anas latentums: NaN ms
Vietējais rakstÄ«Å”anas skaits: 3865503
Vietējais rakstÄ«Å”anas latentums: NaN ms
Gaidāmie skalojumi: 0
Remonta procents: 0.0
Bloom filtra kļūdaini pozitīvi rezultāti: 25
Bloom filtra viltus koeficients: 0.00000
Izmantotā Bloom filtra vieta: 4.57 MiB
Izmantotā Bloom filtra kaudzes atmiņa: 4.57 MiB
Izmantotās kaudzes atmiņas rādītāja kopsavilkums: 590.02 KiB
Izmantotā kaudzes atmiņas saspieÅ”anas metadati: 19.45 KiB
Sablīvēta nodalījuma minimālie baiti: 36
Sablīvēta nodalījuma maksimālais baiti: 42
Sablīvēta nodalījuma vidējie baiti: 42
Vidējais dzÄ«vo Ŕūnu skaits Ŕķēlē (pēdējās piecas minÅ«tes): NaN
Maksimālais dzÄ«vu Ŕūnu skaits Ŕķēlē (pēdējās piecas minÅ«tes): 0
Vidējais kapu pieminekļu skaits vienā Ŕķēlē (pēdējās piecās minÅ«tēs): NaN
Maksimālais kapu pieminekļu skaits Ŕķēlē (pēdējās piecās minÅ«tēs): 0
Nomestās mutācijas: 0 baiti

Mēģinājums samazināt partijas lielumu (pat nosÅ«tot to atseviŔķi) nedeva nekādu efektu, tas tikai pasliktinājās. Iespējams, ka patiesÄ«bā Ŕī patieŔām ir maksimālā CS veiktspēja, jo CS iegÅ«tie rezultāti ir lÄ«dzÄ«gi DataStax iegÅ«tajiem - aptuveni simtiem tÅ«kstoÅ”u operāciju sekundē. Turklāt, ja mēs skatāmies uz resursu izmantoÅ”anu, mēs redzēsim, ka CS izmanto daudz vairāk CPU un disku:

Divu jakozunu cīņa jeb Kasandra vs HBase. Sberbank komandas pieredze
Attēlā parādÄ«ta izmantoÅ”ana visu testu izpildes laikā pēc kārtas abām datu bāzēm.

AttiecÄ«bā uz HB jaudÄ«go lasÄ«Å”anas priekÅ”rocÄ«bu. Å eit var redzēt, ka abām datu bāzēm diska izmantoÅ”ana lasÄ«Å”anas laikā ir ārkārtÄ«gi zema (lasÄ«Å”anas testi ir katras datu bāzes testÄ“Å”anas cikla beigu daļa, piemēram, CS tas ir no 15:20 lÄ«dz 15:40). HB gadÄ«jumā iemesls ir skaidrs - lielākā daļa datu karājas atmiņā, memstore, un daži tiek saglabāti blokkeÅ”atmiņā. Kas attiecas uz CS, tad nav Ä«sti skaidrs, kā tas darbojas, bet diska pārstrāde arÄ« nav redzama, taču katram gadÄ«jumam tika mēģināts iespējot cache row_cache_size_in_mb = 2048 un iestatÄ«t caching = {'keys': 'ALL', 'rows_per_partition': ' 2000000'}, taču tas padarÄ«ja to vēl nedaudz sliktāku.

Ir arÄ« vērts vēlreiz pieminēt svarÄ«gu punktu par reÄ£ionu skaitu HB. MÅ«su gadÄ«jumā vērtÄ«ba tika norādÄ«ta kā 64. Ja to samazina un padara to vienādu ar, piemēram, 4, tad lasot ātrums samazinās 2 reizes. Iemesls ir tāds, ka memstore piepildÄ«sies ātrāk un faili tiks izskaloti biežāk un lasot bÅ«s jāapstrādā vairāk failu, kas HB ir diezgan sarežģīta darbÄ«ba. Reālos apstākļos to var novērst, izmantojot iepriekŔējas sadalÄ«Å”anas un blÄ«vÄ“Å”anas stratēģiju; jo Ä«paÅ”i mēs izmantojam paÅ”rakstÄ«tu utilÄ«tu, kas savāc atkritumus un fonā pastāvÄ«gi saspiež HFiles. PilnÄ«gi iespējams, ka DataStax testiem viņi katrai tabulai pieŔķīra tikai 1 reÄ£ionu (kas nav pareizi), un tas zināmā mērā izskaidro, kāpēc HB bija tik sliktāks viņu lasÄ«Å”anas testos.

No tā tiek izdarÄ«ti Ŕādi sākotnējie secinājumi. Pieņemot, ka testÄ“Å”anas laikā netika pieļautas lielas kļūdas, tad Kasandra izskatās pēc kolosa ar māla pēdām. PrecÄ«zāk, kamēr viņa balansē uz vienas kājas, kā bildē raksta sākumā, uzrāda salÄ«dzinoÅ”i labus rezultātus, taču cīņā pie tādiem paÅ”iem nosacÄ«jumiem zaudē tieÅ”i. Tajā paŔā laikā, ņemot vērā mÅ«su aparatÅ«ras zemo CPU noslodzi, mēs iemācÄ«jāmies uzstādÄ«t divus RegionServer HB uz vienu saimniekdatoru un tādējādi dubultojām veiktspēju. Tie. Ņemot vērā resursu izlietojumu, CS situācija ir vēl bēdÄ«gāka.

Protams, Å”ie testi ir diezgan sintētiski, un Å”eit izmantoto datu apjoms ir salÄ«dzinoÅ”i neliels. Iespējams, ja mēs pārietu uz terabaitiem, situācija bÅ«tu citāda, bet, kamēr HB varam ielādēt terabaitus, CS tas izrādÄ«jās problemātiski. Tas bieži iemeta OperationTimedOutException pat ar Å”iem apjomiem, lai gan atbildes gaidÄ«Å”anas parametri jau tika palielināti vairākas reizes, salÄ«dzinot ar noklusējuma parametriem.

Ceru, ka kopÄ«giem spēkiem mēs atradÄ«sim CS vājās vietas un, ja izdosies to paātrināt, tad ieraksta beigās noteikti pievienoÅ”u informāciju par gala rezultātiem.

UPD: Pateicoties biedru padomiem, man izdevās paātrināt lasīŔanu. Bija:
159 644 operācijas (4 galdi, 5 straumes, 100. partija).
Pievienots:
.withLoadBalancingPolicy(new TokenAwarePolicy(DCAwareRoundRobinPolicy.builder().build()))
Un es spēlējos ar pavedienu skaitu. Rezultāts ir Ŕāds:
4 galdi, 100 pavedieni, partija = 1 (gabals pa gabalam): 301 969 operācijas
4 tabulas, 100 pavedieni, partija = 10: 447 608 operācijas
4 tabulas, 100 pavedieni, partija = 100: 625 655 operācijas

Vēlāk es izmantoÅ”u citus regulÄ“Å”anas padomus, izpildÄ«Å”u pilnu testa ciklu un pievienoÅ”u rezultātus ieraksta beigās.

Avots: www.habr.com

Pievieno komentāru