Kjo nuk është as shaka, duket se kjo fotografi e veçantë pasqyron më saktë thelbin e këtyre bazave të të dhënave, dhe në fund do të jetë e qartë pse:
Sipas DB-Engines Ranking, dy bazat e të dhënave kolonore më të njohura NoSQL janë Cassandra (në tekstin e mëtejmë CS) dhe HBase (HB).
Me vullnetin e fatit, ekipi ynë i menaxhimit të ngarkimit të të dhënave në Sberbank tashmë ka dhe punon ngushtë me HB. Gjatë kësaj kohe, ne studiuam mjaft mirë pikat e forta dhe të dobëta të tij dhe mësuam si ta gatuajmë. Sidoqoftë, prania e një alternative në formën e CS gjithmonë na detyronte të mundohemi pak me dyshime: a bëmë zgjedhjen e duhur? Për më tepër, rezultatet , kryer nga DataStax, ata thanë se CS mposht lehtësisht HB me pothuajse një rezultat dërrmues. Nga ana tjetër, DataStax është një palë e interesuar dhe ju nuk duhet ta pranoni fjalën e tyre për të. Ne u hutuam gjithashtu nga sasia mjaft e vogël e informacionit në lidhje me kushtet e testimit, kështu që vendosëm të zbulonim vetë se kush është mbreti i BigData NoSql, dhe rezultatet e marra dolën shumë interesante.
Megjithatë, përpara se të kalojmë te rezultatet e testeve të kryera, është e nevojshme të përshkruhen aspektet domethënëse të konfigurimeve të mjedisit. Fakti është se CS mund të përdoret në një mënyrë që lejon humbjen e të dhënave. ato. kjo është kur vetëm një server (nyje) është përgjegjës për të dhënat e një çelësi të caktuar, dhe nëse për ndonjë arsye ai dështon, atëherë vlera e këtij çelësi do të humbasë. Për shumë detyra kjo nuk është kritike, por për sektorin bankar ky është më shumë përjashtim sesa rregull. Në rastin tonë, është e rëndësishme të kemi disa kopje të të dhënave për ruajtje të besueshme.
Prandaj, është marrë parasysh vetëm mënyra e funksionimit CS në modalitetin e riprodhimit të trefishtë, d.m.th. Krijimi i hapësirës së rasteve u krye me parametrat e mëposhtëm:
CREATE KEYSPACE ks WITH REPLICATION = {'class' : 'NetworkTopologyStrategy', 'datacenter1' : 3};
Më tej, ekzistojnë dy mënyra për të siguruar nivelin e kërkuar të konsistencës. Rregulli i përgjithshëm:
VP + NR > RF
Që do të thotë se numri i konfirmimeve nga nyjet gjatë shkrimit (NW) plus numri i konfirmimeve nga nyjet gjatë leximit (NR) duhet të jetë më i madh se faktori i replikimit. Në rastin tonë, RF = 3, që do të thotë se opsionet e mëposhtme janë të përshtatshme:
2 + 2 > 3
3 + 1 > 3
Meqenëse është thelbësisht e rëndësishme për ne që të ruajmë të dhënat sa më të besueshme të jetë e mundur, u zgjodh skema 3+1. Përveç kësaj, HB punon në një parim të ngjashëm, d.m.th. një krahasim i tillë do të jetë më i drejtë.
Duhet të theksohet se DataStax bëri të kundërtën në studimin e tyre, ata vendosën RF = 1 si për CS ashtu edhe për HB (për këtë të fundit duke ndryshuar cilësimet e HDFS). Ky është një aspekt vërtet i rëndësishëm sepse ndikimi në performancën e CS në këtë rast është i madh. Për shembull, fotografia më poshtë tregon rritjen e kohës së nevojshme për ngarkimin e të dhënave në CS:
Këtu shohim sa vijon: sa më shumë threads konkurrues të shkruajnë të dhëna, aq më shumë zgjat. Kjo është e natyrshme, por është e rëndësishme që degradimi i performancës për RF=3 të jetë dukshëm më i lartë. Me fjalë të tjera, nëse shkruajmë 4 threads në 5 tabela secila (20 gjithsej), atëherë RF=3 humbet me rreth 2 herë (150 sekonda për RF=3 kundrejt 75 për RF=1). Por nëse rrisim ngarkesën duke ngarkuar të dhëna në 8 tabela me 5 thread secila (40 në total), atëherë humbja e RF=3 është tashmë 2,7 herë (375 sekonda kundrejt 138).
Ndoshta ky është pjesërisht sekreti i testimit të suksesshëm të ngarkesës të kryer nga DataStax për CS, sepse për HB në stendën tonë ndryshimi i faktorit të replikimit nga 2 në 3 nuk pati asnjë efekt. ato. disqet nuk janë pengesa HB për konfigurimin tonë. Sidoqoftë, këtu ka shumë gracka të tjera, sepse duhet theksuar se versioni ynë i HB ishte pak i rregulluar dhe i modifikuar, mjediset janë krejtësisht të ndryshme, etj. Vlen gjithashtu të përmendet se ndoshta thjesht nuk di të përgatis saktë CS dhe ka disa mënyra më efektive për të punuar me të, dhe shpresoj se do ta zbulojmë në komente. Por gjërat e para së pari.
Të gjitha testet u kryen në një grup harduerësh të përbërë nga 4 serverë, secili me konfigurimin e mëposhtëm:
CPU: Xeon E5-2680 v4 @ 2.40 GHz 64 fije.
Disqe: 12 copë SATA HDD
versioni java: 1.8.0_111
Versioni CS: 3.11.5
parametrat cassandra.ymlnumri_shenjave: 256
hinted_handoff_enabled: e vërtetë
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
vërtetuesi: AllowAllAuthenticator
autorizuesi: AllowAllAuthorizer
role_manager: CassandraRoleManager
roles_validity_in_ms: 2000
lejet_vlefshmëria_në_ms: 2000
kredencialet_vlefshmëria_në_ms: 2000
ndarës: org.apache.cassandra.dht.Murmur3Ndarës
drejtoritë_file_të dhënave:
- /data1/cassandra/data # çdo direktori dataN është një disk i veçantë
- /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: ndalo
commit_failure_policy: ndalo
përgatitur_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: periodike
commitlog_sync_period_in_ms: 10000
commitlog_segment_size_in_mb: 32
seed_provider:
- class_name: org.apache.cassandra.locator.SimpleSeedProvider
Parametrat:
- fara: "*,*"
concurrent_reads: 256 # u përpoq 64 - nuk u vu re asnjë ndryshim
concurrent_write: 256 # provuar 64 - nuk u vu re dallim
concurrent_counter_writes: 256 # provuar 64 - nuk vërehet dallim
concurrent_materialized_view_shkruan: 32
memtable_heap_space_in_mb: 2048 # u përpoq 16 GB - ishte më i ngadalshëm
memtable_allocation_type: heap_buffers
index_summary_kapacity_in_mb:
index_summary_resize_interval_në_minuta: 60
trickle_fsync: false
trickle_fsync_interval_in_kb: 10240
porta e magazinimit: 7000
ssl_storage_port: 7001
listen_adresa: *
adresa_transmetimi: *
listen_on_broadcast_address: e vërtetë
internode_authenticator: org.apache.cassandra.auth.AllowAllInternodeAuthenticator
start_native_transport: e vërtetë
vendlindja_transporti_port: 9042
start_rpc: e vërtetë
rpc_adresa: *
rpc_port: 9160
rpc_keepalive: e vërtetë
rpc_server_type: sinkronizoj
thrift_framed_transport_size_in_mb: 15
incremental_backups: false
snapshot_para_compaction: false
auto_snapshot: e vërtetë
kolona_indeksi_madhësia_në_kb: 64
column_index_cache_size_in_kb: 2
kompaktorët_bashkëkohor: 4
compaction_throughput_mb_per_sek: 1600
sstable_preemptive_open_interval_in_mb: 50
read_request_timeout_in_ms: 100000
range_request_timeout_in_ms: 200000
shkrim_kërkese_timeout_in_ms: 40000
counter_write_request_timeout_in_ms: 100000
cas_contention_timeout_in_ms: 20000
shkurtoj_kërkesën_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: asnjë
klienti_enkriptimi_opcionet:
aktivizuar: 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:
aktivizuar: false
pragu_varre_paralajmërimi: 1000
pragu i_dështimit të gurit të varrit: 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: e vërtetë
enable_sasi_indexes: e vërtetë
Cilësimet e GC:
### Cilësimet e CMS-XX:+PërdorParNewGC
-XX:+PërdorConcMarkSweepGC
-XX:+CMSParallelRemark Enabled
-XX:Raporti i mbijetuar=8
-XX:MaxTenuringThreshold=1
-XX:CMSInitiatingOccupancyFraction=75
-XX:+UseCMSInitiating OccupancyOnly
-XX:CMSWaitDuration=10000
-XX:+CMSParallelInitialMarkEnabled
-XX:+CMSEdenChunksRecordGjithmonë
-XX:+CMSClassUnloadingEnabled
Kujtesës jvm.options iu nda 16 Gb (ne provuam gjithashtu 32 Gb, nuk u vu re asnjë ndryshim).
Tabelat u krijuan me komandën:
CREATE TABLE ks.t1 (id bigint PRIMARY KEY, title text) WITH compression = {'sstable_compression': 'LZ4Compressor', 'chunk_length_kb': 64};Versioni HB: 1.2.0-cdh5.14.2 (në klasën org.apache.hadoop.hbase.regionserver.HRegion ne përjashtuam MetricsRegion që çoi në GC kur numri i rajoneve ishte më shumë se 1000 në RegionServer)
Parametrat jo të parazgjedhur të HBasekujdestar i kopshtit zoologjik.sesioni.përfundimi: 120000
hbase.rpc.timeout: 2 minuta
hbase.client.scanner.timeout.periudha: 2 minuta
hbase.master.handler.count: 10
hbase.regionserver.lease.period, hbase.client.scanner.timeout.periudha: 2 minuta
hbase.regionserver.handler.count: 160
hbase.regionserver.metahandler.count: 30
hbase.regionserver.logroll.periudha: 4 orë
hbase.regionserver.maxlogs: 200
hbase.hregion.memstore.flush.madhësia: 1 GiB
hbase.hregion.memstore.block.multiplier: 6
hbase.hstore.compactionThreshold: 5
hbase.hstore.blockingStoreFiles: 200
hbase.hregion.majorcompaction: 1 ditë
Pjesë e konfigurimit të avancuar të shërbimit HBase (valvula e sigurisë) për 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
Opsionet e konfigurimit të Java për serverin e rajonit HBase:
-XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70 -XX:+CMSParallelRemarkEnabled -XX:ReservedCodeCacheSize=256m
hbase.snapshot.master.timeoutMillis: 2 minuta
hbase.snapshot.region.timeout: 2 minuta
hbase.snapshot.master.timeout.millis: 2 minuta
Madhësia maksimale e regjistrit të serverit HBase REST: 100 MiB
Rezervimet maksimale të skedarëve të regjistrit të serverit HBase REST: 5
Madhësia maksimale e regjistrit të serverit HBase Thrift: 100 MiB
Rezervimet maksimale të skedarëve të regjistrit të serverit HBase Thrift: 5
Madhësia e regjistrit Master Max: 100 MiB
Rezervimet maksimale kryesore të skedarit të regjistrit: 5
Madhësia maksimale e regjistrit të serverit të rajonit: 100 MiB
Rezervimet maksimale të skedarit të regjistrit të RegionServer: 5
Dritarja e Zbulimit Master aktiv HBase: 4 minuta
dfs.client.hedged.read.threadpool.madhësia: 40
dfs.client.hedged.read.threshold.millis: 10 milisekonda(s)
hbase.rest.threads.min: 8
hbase.rest.threads.max: 150
Përshkruesit maksimal të skedarëve të procesit: 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
Temat lëvizëse të rajonit: 6
Klienti Java Heap Madhësia në Bajt: 1 GiB
Grupi i parazgjedhur i serverit HBase REST: 3 GiB
Grupi i parazgjedhur i serverit HBase Thrift: 3 GiB
Java Heap Madhësia e HBase Master në Bajt: 16 GiB
Java Heap Madhësia e Serverit të Rajonit HBase në Bajt: 32 GiB
+Keeper Zoo
maxClientCnxns: 601
maxSessionTimeout: 120000
Krijimi i tabelave:
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'}
Këtu ka një pikë të rëndësishme - përshkrimi i DataStax nuk thotë se sa rajone janë përdorur për të krijuar tabelat HB, megjithëse kjo është kritike për vëllime të mëdha. Prandaj, për testet u zgjodh sasia = 64, e cila lejon ruajtjen deri në 640 GB, d.m.th. tavolinë me madhësi të mesme.
Në kohën e testimit, HBase kishte 22 mijë tabela dhe 67 mijë rajone (kjo do të ishte vdekjeprurëse për versionin 1.2.0 nëse jo për patchin e përmendur më sipër).
Tani për kodin. Meqenëse nuk ishte e qartë se cilat konfigurime ishin më të favorshme për një bazë të dhënash të veçantë, testet u kryen në kombinime të ndryshme. ato. në disa teste, 4 tabela u ngarkuan njëkohësisht (të 4 nyjet u përdorën për lidhje). Në testet e tjera kemi punuar me 8 tabela të ndryshme. Në disa raste, madhësia e grupit ishte 100, në të tjerat 200 (parametri i grupit - shih kodin më poshtë). Madhësia e të dhënave për vlerën është 10 byte ose 100 bytes (dataSize). Në total, 5 milionë regjistrime u shkruan dhe u lexuan në secilën tabelë çdo herë. Në të njëjtën kohë, 5 fije u shkruan/lexuan në secilën tabelë (numri i fillit - thNum), secila prej të cilave përdori gamën e vet të çelësave (numërimi = 1 milion):
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);
}
}
Prandaj, funksione të ngjashme u siguruan për 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);
}
}
Meqenëse në HB klienti duhet të kujdeset për shpërndarjen uniforme të të dhënave, funksioni kryesor i kriposjes dukej kështu:
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);
}
Tani pjesa më interesante - rezultatet:
E njëjta gjë në formën e grafikut:
Avantazhi i HB është aq befasues sa ekziston dyshimi se ka një lloj pengese në konfigurimin e CS. Megjithatë, kërkimi në google dhe kërkimi i parametrave më të dukshëm (si concurrent_writes ose memtable_heap_space_in_mb) nuk i përshpejtoi gjërat. Në të njëjtën kohë, shkrimet janë të pastra dhe nuk shajnë për asgjë.
Të dhënat u shpërndanë në mënyrë të barabartë nëpër nyje, statistikat nga të gjitha nyjet ishin afërsisht të njëjta.
Kështu duken statistikat e tabelës nga një prej nyjeveHapësira kryesore: ks
Numri i leximeve: 9383707
Vonesa e leximit: 0.04287025042448576 ms
Numri i Shkrimeve: 15462012
Vonesa e shkrimit: 0.1350068438699957 ms
Flushimet në pritje: 0
Tabela: t1
Numri i SSTableve: 16
Hapësira e përdorur (live): 148.59 MiB
Hapësira e përdorur (gjithsej): 148.59 MiB
Hapësira e përdorur nga fotografitë e çastit (gjithsej): 0 bajt
Memorie jashtë grumbullit të përdorur (gjithsej): 5.17 MiB
Raporti i kompresimit SSTable: 0.5720989576459437
Numri i ndarjeve (vlerësimi): 3970323
Numri i qelizave Memtable: 0
Madhësia e të dhënave të Memtable: 0 bajt
Memtable off heap memorie e përdorur: 0 bajt
Numri i ndërprerësve të Memtable: 5
Numri i leximeve lokale: 2346045
Vonesa lokale e leximit: NaN ms
Numri lokal i shkrimeve: 3865503
Vonesa lokale e shkrimit: NaN ms
Shpëlarjet në pritje: 0
Përqindja e riparuar: 0.0
Pozitive false të filtrit të lulëzimit: 25
Raporti fals i filtrit të lulëzimit: 0.00000
Hapësira e filtrit të lulëzimit të përdorur: 4.57 MiB
Memoria e përdorur e filtrit të lulëzimit jashtë grumbullit: 4.57 MiB
Përmbledhja e indeksit të memorjes së grumbullit të përdorur: 590.02 KiB
Meta të dhënat e kompresimit nga memoria e grumbullit të përdorur: 19.45 KiB
Bajtet minimale të ndarjes së ngjeshur: 36
Bajtet maksimale të ndarjes së ngjeshur: 42
Bajtet mesatare të ndarjes së ngjeshur: 42
Mesatarja e qelizave të gjalla për fetë (pesë minutat e fundit): NaN
Maksimumi i qelizave të gjalla për fetë (pesë minutat e fundit): 0
Mesatarja e gurëve të varreve për fetë (pesë minutat e fundit): NaN
Maksimumi i gurëve të varrit për fetë (pesë minutat e fundit): 0
Mutacionet e rënë: 0 bajt
Një përpjekje për të zvogëluar madhësinë e grupit (madje edhe dërgimi i saj individualisht) nuk pati efekt, por vetëm u përkeqësua. Është e mundur që në fakt kjo është me të vërtetë performanca maksimale për CS, pasi rezultatet e marra për CS janë të ngjashme me ato të marra për DataStax - rreth qindra mijëra operacione në sekondë. Përveç kësaj, nëse shikojmë përdorimin e burimeve, do të shohim se CS përdor shumë më tepër CPU dhe disqe:
Figura tregon përdorimin gjatë ekzekutimit të të gjitha testeve me radhë për të dy bazat e të dhënave.
Lidhur me avantazhin e fuqishëm të leximit të HB. Këtu mund të shihni se për të dy bazat e të dhënave, përdorimi i diskut gjatë leximit është jashtëzakonisht i ulët (testet e leximit janë pjesa përfundimtare e ciklit të testimit për secilën bazë të dhënash, për shembull për CS kjo është nga ora 15:20 deri në 15:40). Në rastin e HB, arsyeja është e qartë - shumica e të dhënave varen në memorie, në memstore, dhe disa janë të ruajtura në cache në bllok. Sa i përket CS, nuk është shumë e qartë se si funksionon, por riciklimi i diskut nuk është gjithashtu i dukshëm, por për çdo rast, u bë një përpjekje për të aktivizuar cache row_cache_size_in_mb = 2048 dhe për të vendosur caching = {'keys': 'ALL', 'rows_per_partition': '2000000'}, por kjo e bëri atë edhe pak më keq.
Vlen të përmendet edhe një herë një pikë e rëndësishme për numrin e rajoneve në HB. Në rastin tonë, vlera u specifikua si 64. Nëse e zvogëloni dhe e bëni të barabartë, për shembull, me 4, atëherë kur lexoni, shpejtësia bie 2 herë. Arsyeja është se memstore do të mbushet më shpejt dhe skedarët do të pastrohen më shpesh dhe gjatë leximit do të duhet të përpunohen më shumë skedarë, gjë që është një operacion mjaft i ndërlikuar për HB. Në kushte reale, kjo mund të trajtohet duke menduar përmes një strategjie të ndarjes dhe kompaktifikimit; në veçanti, ne përdorim një mjet të vetë-shkruar që mbledh mbeturina dhe ngjesh skedarët HF vazhdimisht në sfond. Është shumë e mundur që për testet e DataStax ata kanë ndarë vetëm 1 rajon për tabelë (që nuk është e saktë) dhe kjo do të sqaronte disi pse HB ishte kaq inferior në testet e tyre të leximit.
Nga kjo nxirren përfundimet paraprake të mëposhtme. Duke supozuar se nuk janë bërë gabime të mëdha gjatë testimit, atëherë Cassandra duket si një kolos me këmbë prej balte. Më saktësisht, teksa ekuilibron në njërën këmbë, si në foton në fillim të shkrimit, tregon rezultate relativisht të mira, por në një luftë në të njëjtat kushte humbet plotësisht. Në të njëjtën kohë, duke marrë parasysh përdorimin e ulët të CPU-së në harduerin tonë, mësuam të vendosim dy RegionServer HB për host dhe në këtë mënyrë dyfishuam performancën. ato. Duke marrë parasysh shfrytëzimin e burimeve, situata për SHK është edhe më e mjerueshme.
Sigurisht, këto teste janë mjaft sintetike dhe sasia e të dhënave që është përdorur këtu është relativisht modeste. Është e mundur që nëse do të kalonim në terabajt, situata do të ishte ndryshe, por ndërsa për HB mund të ngarkojmë terabajt, për CS kjo doli të ishte problematike. Shpesh hidhte një OperationTimedOutException edhe me këto vëllime, megjithëse parametrat për pritjen e një përgjigjeje tashmë ishin rritur disa herë në krahasim me ato të paracaktuara.
Shpresoj që përmes përpjekjeve të përbashkëta të gjejmë pengesat e CS dhe nëse mund ta përshpejtojmë atë, atëherë në fund të postimit do të shtoj patjetër informacion për rezultatet përfundimtare.
UPD: Falë këshillave të shokëve arrita ta përshpejtoj leximin. ishte:
159 operacione (644 tavolina, 4 prurje, grup 5).
Shtuar:
.withLoadBalancingPolicy(new TokenAwarePolicy(DCAwareRoundRobinPolicy.builder().build()))
Dhe luaja me numrin e fijeve. Rezultati është si më poshtë:
4 tavolina, 100 fije, grumbull = 1 (pjesë-pjesë): 301 ops
4 tabela, 100 fije, grup = 10: 447 ops
4 tabela, 100 fije, grup = 100: 625 ops
Më vonë do të aplikoj këshilla të tjera akordimi, do të ekzekutoj një cikël të plotë testimi dhe do t'i shtoj rezultatet në fund të postimit.
Burimi: www.habr.com