Nid yw hyn hyd yn oed yn jôc, mae'n ymddangos bod y darlun penodol hwn yn adlewyrchu'n fwyaf cywir hanfod y cronfeydd data hyn, ac yn y diwedd bydd yn glir pam:
Yn ôl DB-Engines Ranking, y ddwy gronfa ddata golofnog NoSQL fwyaf poblogaidd yw Cassandra (CS o hyn ymlaen) a HBase (HB).
Yn ôl ewyllys tynged, mae ein tîm rheoli llwytho data yn Sberbank eisoes wedi gwneud hynny ac yn gweithio'n agos gyda BI. Yn ystod y cyfnod hwn, fe wnaethon ni astudio ei gryfderau a'i wendidau yn eithaf da a dysgu sut i'w goginio. Fodd bynnag, roedd presenoldeb dewis arall ar ffurf CS bob amser yn ein gorfodi i boenydio ein hunain ychydig gydag amheuon: a wnaethom ni'r dewis cywir? Ar ben hynny, mae'r canlyniadau , a berfformiwyd gan DataStax, dywedasant fod CS yn curo HB yn hawdd gyda sgôr malu bron. Ar y llaw arall, mae DataStax yn barti â diddordeb, ac ni ddylech gymryd eu gair amdano. Cawsom ein drysu hefyd gan y swm eithaf bach o wybodaeth am yr amodau profi, felly fe benderfynon ni ddarganfod ar ein pennau ein hunain pwy yw brenin BigData NoSql, a daeth y canlyniadau a gafwyd yn ddiddorol iawn.
Fodd bynnag, cyn symud ymlaen at ganlyniadau'r profion a berfformiwyd, mae angen disgrifio agweddau arwyddocaol ar ffurfweddiadau'r amgylchedd. Y ffaith yw y gellir defnyddio CS mewn modd sy'n caniatáu colli data. Y rhai. dyma pan mai dim ond un gweinydd (nod) sy'n gyfrifol am ddata allwedd benodol, ac os bydd yn methu am ryw reswm, yna bydd gwerth yr allwedd hon yn cael ei golli. Ar gyfer llawer o dasgau nid yw hyn yn hollbwysig, ond ar gyfer y sector bancio dyma'r eithriad yn hytrach na'r rheol. Yn ein hachos ni, mae'n bwysig cael sawl copi o ddata ar gyfer storio dibynadwy.
Felly, dim ond y modd gweithredu CS yn y modd atgynhyrchu triphlyg a ystyriwyd, h.y. Cyflawnwyd creu'r gofod achos gyda'r paramedrau canlynol:
CREATE KEYSPACE ks WITH REPLICATION = {'class' : 'NetworkTopologyStrategy', 'datacenter1' : 3};
Nesaf, mae dwy ffordd i sicrhau'r lefel ofynnol o gysondeb. Rheol gyffredinol:
NW + NR > RF
Sy'n golygu bod yn rhaid i nifer y cadarnhad o nodau wrth ysgrifennu (NW) ynghyd â nifer y cadarnhad o nodau wrth ddarllen (NR) fod yn fwy na'r ffactor atgynhyrchu. Yn ein hachos ni, RF = 3, sy'n golygu bod yr opsiynau canlynol yn addas:
2+2 >3
3+1 >3
Gan ei bod yn sylfaenol bwysig i ni storio'r data mor ddibynadwy â phosibl, dewiswyd y cynllun 3+1. Yn ogystal, mae HB yn gweithio ar egwyddor debyg, h.y. bydd cymhariaeth o'r fath yn decach.
Dylid nodi bod DataStax wedi gwneud y gwrthwyneb yn eu hastudiaeth, maent yn gosod RF = 1 ar gyfer CS a HB (ar gyfer yr olaf trwy newid y gosodiadau HDFS). Mae hon yn agwedd bwysig iawn oherwydd mae'r effaith ar berfformiad CS yn yr achos hwn yn enfawr. Er enghraifft, mae'r llun isod yn dangos y cynnydd yn yr amser sydd ei angen i lwytho data i mewn i CS:
Yma gwelwn y canlynol: po fwyaf o edafedd cystadleuol sy'n ysgrifennu data, yr hiraf y mae'n ei gymryd. Mae hyn yn naturiol, ond mae'n bwysig bod y diraddio perfformiad ar gyfer RF=3 yn sylweddol uwch. Mewn geiriau eraill, os ydym yn ysgrifennu 4 edafedd i 5 tabl yr un (20 i gyd), yna mae RF = 3 yn colli tua 2 waith (150 eiliad ar gyfer RF = 3 yn erbyn 75 ar gyfer RF = 1). Ond os ydym yn cynyddu'r llwyth trwy lwytho data i 8 tabl gyda 5 edafedd yr un (40 i gyd), yna mae colli RF = 3 eisoes 2,7 gwaith (375 eiliad yn erbyn 138).
Efallai mai dyma'n rhannol gyfrinach y profion llwyth llwyddiannus a gynhaliwyd gan DataStax ar gyfer CS, oherwydd ar gyfer HB ar ein stondin ni chafodd newid y ffactor atgynhyrchu o 2 i 3 unrhyw effaith. Y rhai. nid disgiau yw'r dagfa HB ar gyfer ein cyfluniad. Fodd bynnag, mae yna lawer o beryglon eraill yma, oherwydd dylid nodi bod ein fersiwn ni o HB wedi'i glytio a'i addasu ychydig, mae'r amgylcheddau'n hollol wahanol, ac ati. Mae'n werth nodi hefyd efallai nad wyf yn gwybod sut i baratoi CS yn gywir ac mae yna rai ffyrdd mwy effeithiol o weithio gydag ef, a gobeithio y cawn wybod yn y sylwadau. Ond pethau cyntaf yn gyntaf.
Perfformiwyd yr holl brofion ar glwstwr caledwedd yn cynnwys 4 gweinydd, pob un â'r ffurfweddiad canlynol:
CPU: Xeon E5-2680 v4 @ 2.40GHz 64 edafedd.
Disgiau: 12 darn SATA HDD
fersiwn java: 1.8.0_111
Fersiwn CS: 3.11.5
paramedrau cassandra.ymlrhif_tocyn: 256
hinted_handoff_enabled : wir
awgrym_handoff_throttle_in_kb: 1024
max_hints_delivery_threads:2
awgrymiadau_cyfeiriadur: /data10/cassandra/hints
awgrymiadau_flush_period_in_ms: 10000
max_hints_file_size_in_mb: 128
batchlog_replay_throttle_in_kb: 1024
dilysydd: AllowAllAuthenticator
awdur: AllowAllAuthorizer
role_manager: CassandraRoleManager
rolau_dilysrwydd_mewn_ms: 2000
caniatadau_dilysrwydd_yn_ms: 2000
credentials_validity_in_ms: 2000
rhannwr: org.apache.cassandra.dht.Murmur3Partitioner
data_ffeil_cyfeiriaduron:
- /data1/cassandra/data # mae pob cyfeiriadur dataN yn ddisg ar wahân
- /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: ffug
disk_failure_policy : stopio
commit_failure_policy : stopio
datganiadau_parod_cache_maint_mb:
clustog Fair_prepared_statements_cache_size_mb:
allwedd_cache_size_in_mb:
allwedd_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
save_caches_directory: /data10/cassandra/saved_caches
commitlog_sync: cyfnodol
commitlog_sync_period_in_ms: 10000
commitlog_segment_size_in_mb:32
darparwr_ hadau:
- class_name: org.apache.cassandra.locator.SimpleSeedProvider
paramedrau:
- hadau: "*,*"
concurrent_reads: 256 # ceisio 64 - dim gwahaniaeth wedi sylwi
concurrent_writes: 256 # ceisio 64 - dim gwahaniaeth wedi sylwi
concurrent_counter_writes: 256 # ceisio 64 - dim gwahaniaeth wedi sylwi
concurrent_materialized_view_writes: 32
memtable_heap_space_in_mb: 2048 # wedi ceisio 16 GB - roedd yn arafach
memtable_allocation_type: heap_buffers
mynegai_crynodeb_capasiti_mewn_mb:
index_summary_resize_interval_in_minutes: 60
trickle_fsync: ffug
trickle_fsync_interval_in_kb: 10240
porth_storio: 7000
ssl_storage_port: 7001
gwrandewch_cyfeiriad: *
cyfeiriad_darllediad: *
listen_on_broadcast_address: wir
internode_authenticator: org.apache.cassandra.auth.AllowAllInternodeAuthenticator
start_native_transport : wir
porth_trafnidiaeth_frodorol: 9042
start_rpc: gwir
rpc_cyfeiriad: *
rpc_porth: 9160
rpc_keepalive: wir
rpc_server_type: cysoni
clustog Fair_framed_transport_size_in_mb:15
incremental_backups: ffug
snapshot_before_compaction: ffug
auto_snapshot: wir
colofn_index_size_in_kb:64
colofn_index_cache_size_in_kb:2
cywasgwyr_cydredol: 4
cywasgu_trwyput_mb_per_sec: 1600
sstable_preemptive_open_interval_in_mb: 50
darllen_request_timeout_in_ms: 100000
range_request_timeout_in_ms: 200000
ysgrifennu_request_timeout_in_ms: 40000
counter_write_request_timeout_in_ms: 100000
cas_contention_timeout_in_ms: 20000
cwtogi_request_timeout_in_ms: 60000
cais_amser terfyn_mewn_ms: 200000
slow_query_log_timeout_in_ms: 500
cross_node_timeout : ffug
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
dewisiadau_amgryptio_weinydd:
internode_encryption: dim
dewisiadau_amgryptio_cliant:
galluog: ffug
internode_compression: dc
inter_dc_tcp_nodelay : ffug
tracetype_query_ttl: 86400
tracetype_repair_ttl: 604800
enable_user_defined_functions: ffug
enable_scripted_user_defined_functions: ffug
ffenestri_timer_cyfwng: 1
tryloyw_data_amgryptio_opsiynau:
galluog: ffug
tombstone_warn_threshold: 1000
tombstone_failure_threshold: 100000
swp_size_warn_threshold_in_kb: 200
swp_size_fail_threshold_in_kb: 250
unlogged_batch_across_partitions_warn_threshold: 10
cywasgu_large_partition_warning_threshold_mb:100
gc_warn_threshold_in_ms: 1000
back_pressure_enabled: ffug
galluogi_materialized_views : gwir
enable_sasi_indexes : gwir
Gosodiadau GC:
### Gosodiadau CMS-XX:+DefnyddioParNewGC
-XX:+UseConcMarkSweepGC
-XX:+CMSparallelRemarkEnable
-XX: Cymhareb Goroesi=8
-XX:MaxTenuringThreshold=1
-XX:CMSInitiatingOccupancyFraction=75
-XX:+DefnyddioCMSICychwyn Meddiannaeth yn Unig
-XX: CMSWaitHuration=10000
-XX:+Marc Cychwynnol CMSparallel Wedi'i alluogi
-XX:+CMSEdenChunksRecord Bob amser
-XX:+ClassDadlwythoGalluogi
Dyrannwyd 16Gb i'r cof jvm.options (fe wnaethom hefyd roi cynnig ar 32 Gb, ni sylwyd ar unrhyw wahaniaeth).
Crëwyd y tablau gyda'r gorchymyn:
CREATE TABLE ks.t1 (id bigint PRIMARY KEY, title text) WITH compression = {'sstable_compression': 'LZ4Compressor', 'chunk_length_kb': 64};Fersiwn HB: 1.2.0-cdh5.14.2 (yn y dosbarth org.apache.hadoop.hbase.regionserver.HRegion fe wnaethom eithrio MetricsRegion a arweiniodd at CG pan oedd nifer y rhanbarthau yn fwy na 1000 ar RegionServer)
Paramedrau HBase nad ydynt yn ddiofynzookeeper.session.timeout: 120000
hbase.rpc.timeout: 2 funud(s)
hbase.client.scanner.timeout.period: 2 funud(s)
hbase.master.handler.cyfrif:10
cyfnod.prydles.hbase.region, hbase.client.scanner.timeout.cyfnod: 2 funud(s)
hbase.regionserver.handler.cyfrif:160
hbase.regionserver.metahandler.cyfrif:30
hbase.regionserver.logroll.period: 4 awr(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 diwrnod(au)
Tamaid Ffurfweddu Uwch Gwasanaeth HBase (Falf Diogelwch) ar gyfer hbase-site.xml:
hbase.regionserver.wal.codecorg.apache.hadoop.hbase.regionserver.wal.IndexedWALEditCodec
hbase.master.namespace.init.timeout3600000
hbase.regionserver.optionalcacheflushinterval18000000
hbase.regionserver.thread.compacion.mawr12
hbase.regionserver.wal.galluogicywasgugwir
hbase.hstore.compaction.max.size1073741824
hbase.server.compactchecker.interval.multiplier200
Opsiynau Ffurfweddu Java ar gyfer Gweinydd Rhanbarth HBase:
-XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70 -XX:+CMSParallelRemarkEnabled -XX:ReservedCodeCacheSize=256m
hbase.snapshot.master.timeoutMillis: 2 funud(s)
hbase.snapshot.region.timeout: 2 funud(s)
hbase.snapshot.master.timeout.millis: 2 funud(s)
HBase REST Server Max Log Maint: 100 MiB
HBase REST Server Uchafswm copïau wrth gefn o Ffeil Log: 5
Maint y Log Gweinydd Clustog HBase: 100 MiB
HBase Server Thrift Uchafswm copïau wrth gefn o Ffeiliau Log: 5
Maint Log Meistr Max: 100 MiB
Meistr Uchafswm y copïau wrth gefn o ffeiliau log: 5
RegionServer Max Log Maint: 100 MiB
RegionServer Uchafswm copïau wrth gefn o'r Ffeil Log: 5
Ffenestr Canfod Meistr Actif HBase: 4 munud(s)
dfs.client.hedged.read.threadpool.maint: 40
dfs.client.hedged.read.threshold.millis: 10 milieiliad(au)
hbase.rest.threads.min:8
hbase.rest.threads.max: 150
Disgrifyddion Ffeil Proses Uchaf: 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.maint: 20
Trywyddau Symudwr Rhanbarth: 6
Maint Tomen Java Cleient mewn Beitiau: 1 GiB
Grŵp Diofyn Gweinyddwr HBase REST: 3 GiB
Grŵp Rhagosodedig Gweinydd Clustog Fair: 3 GiB
Java Heap Maint Meistr HBase mewn Beit: 16 GiB
Java Heap Maint Gweinydd Rhanbarth HBase mewn Bytes: 32 GiB
+Ceidwad Sw
maxClientCnxns: 601
Uchafswm Amser Sesiwn: 120000
Creu tablau:
hbase org.apache.hadoop.hbase.util.RegionSplitter ns:t1 UniformSplit -c 64 -f cf
newid 'ns:t1', {NAME => 'cf', DATA_BLOCK_ENCODING => 'FAST_DIFF', COMPRESSION => 'GZ'}
Mae un pwynt pwysig yma - nid yw disgrifiad DataStax yn dweud faint o ranbarthau a ddefnyddiwyd i greu'r tablau BT, er bod hyn yn hanfodol ar gyfer niferoedd mawr. Felly, ar gyfer y profion, dewiswyd maint = 64, sy'n caniatáu storio hyd at 640 GB, h.y. bwrdd maint canolig.
Ar adeg y prawf, roedd gan HBase 22 mil o fyrddau a 67 mil o ranbarthau (byddai hyn wedi bod yn angheuol ar gyfer fersiwn 1.2.0 os nad ar gyfer y darn a grybwyllir uchod).
Nawr am y cod. Gan nad oedd yn glir pa ffurfweddiadau oedd yn fwy manteisiol ar gyfer cronfa ddata benodol, cynhaliwyd profion mewn gwahanol gyfuniadau. Y rhai. mewn rhai profion, llwythwyd 4 bwrdd ar yr un pryd (defnyddiwyd pob un o'r 4 nod ar gyfer cysylltu). Mewn profion eraill buom yn gweithio gydag 8 bwrdd gwahanol. Mewn rhai achosion, maint y swp oedd 100, mewn eraill 200 (paramedr swp - gweler y cod isod). Maint y data ar gyfer gwerth yw 10 bytes neu 100 beit (dataSize). Cafodd cyfanswm o 5 miliwn o gofnodion eu hysgrifennu a'u darllen i bob tabl bob tro. Ar yr un pryd, ysgrifennwyd/darllenwyd 5 edefyn i bob tabl (rhif edau - thNum), gyda phob un ohonynt yn defnyddio ei ystod ei hun o allweddi (cyfrif = 1 miliwn):
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);
}
}
Yn unol â hynny, darparwyd swyddogaethau tebyg ar gyfer Bwrdd Iechyd:
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);
}
}
Gan fod yn rhaid i'r cleient ofalu am ddosbarthiad data unffurf yn Budd-dal Tai, roedd y swyddogaeth halltu allweddol yn edrych fel hyn:
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);
}
Nawr y rhan fwyaf diddorol - y canlyniadau:
Yr un peth ar ffurf graff:
Mae mantais Budd-dal Tai mor syndod fel bod yna amheuaeth bod yna ryw fath o dagfa yn y gosodiad CS. Fodd bynnag, ni wnaeth Googling a chwilio am y paramedrau mwyaf amlwg (fel concurrent_writes neu memtable_heap_space_in_mb) gyflymu pethau. Ar yr un pryd, mae'r boncyffion yn lân ac nid ydynt yn rhegi ar unrhyw beth.
Dosbarthwyd y data yn gyfartal ar draws y nodau, roedd yr ystadegau o bob nod tua'r un peth.
Dyma sut olwg sydd ar ystadegau tabl o un o'r nodauGofod allweddol: ks
Darllen Cyfrif: 9383707
Darllen Cywirdeb: 0.04287025042448576 ms
Ysgrifennwch Cyfrif: 15462012
Ysgrifennu Cywirdeb: 0.1350068438699957 ms
Fflyciadau ar y gweill: 0
Tabl: t1
Cyfrif SSTable: 16
Gofod a ddefnyddir (yn fyw): 148.59 MiB
Gofod a ddefnyddiwyd (cyfanswm): 148.59 MiB
Gofod a ddefnyddir gan gipluniau (cyfanswm): 0 beit
Cof oddi ar y domen a ddefnyddir (cyfanswm): 5.17 MiB
Cymhareb Cywasgu SSTable: 0.5720989576459437
Nifer y rhaniadau (amcangyfrif): 3970323
Cyfrif celloedd megable: 0
Maint data memtable: 0 beit
Cof pentwr medradwy a ddefnyddir: 0 beit
Cyfrif switsh memtable: 5
Cyfrif darllen lleol: 2346045
Cudd darllen lleol: NaN ms
Cyfrif ysgrifennu lleol: 3865503
Cudd ysgrifennu lleol: NaN ms
Gwlychiadau ar y gweill: 0
Canran wedi'u hatgyweirio: 0.0
Hidlydd Bloom positifau ffug: 25
Cymhareb hidlydd Bloom ffug: 0.00000
Gofod hidlo Bloom a ddefnyddir: 4.57 MiB
Hidlydd Bloom oddi ar y cof pentwr a ddefnyddiwyd: 4.57 MiB
Crynodeb mynegai oddi ar y cof pentwr a ddefnyddiwyd: 590.02 KiB
Metadata cywasgu oddi ar y cof pentwr a ddefnyddiwyd: 19.45 KiB
Isafswm beit rhaniad cywasgedig: 36
Beit mwyaf rhaniad cywasgedig: 42
Beit cymedrig rhaniad cywasgedig: 42
Celloedd byw cyfartalog fesul tafell (pum munud olaf): NaN
Uchafswm celloedd byw fesul tafell (pum munud olaf): 0
Cerrig beddau cyfartalog fesul tafell (pum munud olaf): NaN
Uchafswm cerrig beddau fesul tafell (pum munud olaf): 0
Treigladau wedi'u Gollwng: 0 beit
Ni chafodd ymgais i leihau maint y swp (hyd yn oed ei anfon yn unigol) unrhyw effaith, dim ond gwaethygu a wnaeth. Mae'n bosibl mewn gwirionedd mai dyma'r perfformiad uchaf ar gyfer CS mewn gwirionedd, gan fod y canlyniadau a gafwyd ar gyfer CS yn debyg i'r rhai a gafwyd ar gyfer DataStax - tua channoedd o filoedd o lawdriniaethau yr eiliad. Yn ogystal, os edrychwn ar ddefnyddio adnoddau, fe welwn fod CS yn defnyddio llawer mwy o CPU a disgiau:
Mae'r ffigur yn dangos y defnydd a wnaed yn ystod rhediad yr holl brofion yn olynol ar gyfer y ddwy gronfa ddata.
Ynglŷn â mantais darllen pwerus HB. Yma gallwch weld, ar gyfer y ddwy gronfa ddata, bod y defnydd o ddisgiau wrth ddarllen yn hynod o isel (profion darllen yw rhan olaf y cylch profi ar gyfer pob cronfa ddata, er enghraifft ar gyfer CS mae hyn rhwng 15:20 a 15:40). Yn achos HB, mae'r rheswm yn glir - mae'r rhan fwyaf o'r data yn hongian yn y cof, yn y memstore, ac mae rhai wedi'u storio mewn blockcache. O ran CS, nid yw'n glir iawn sut mae'n gweithio, ond nid yw ailgylchu disg hefyd yn weladwy, ond rhag ofn, gwnaethpwyd ymgais i alluogi'r storfa row_cache_size_in_mb = 2048 a gosod caching = { 'allweddi': 'ALL', ' rows_per_partition ' : ' 2000000 '}, ond gwnaeth hynny hyd yn oed ychydig yn waeth.
Mae hefyd yn werth sôn unwaith eto am bwynt pwysig ynglŷn â nifer y rhanbarthau mewn BI. Yn ein hachos ni, pennwyd y gwerth fel 64. Os ydych chi'n ei leihau a'i wneud yn hafal i, er enghraifft, 4, yna wrth ddarllen, mae'r cyflymder yn gostwng 2 waith. Y rheswm yw y bydd memstore yn llenwi'n gyflymach a bydd ffeiliau'n cael eu fflysio'n amlach ac wrth ddarllen, bydd angen prosesu mwy o ffeiliau, sy'n weithrediad eithaf cymhleth i HB. Mewn amodau go iawn, gellir trin hyn trwy feddwl trwy strategaeth ragnodi a chywasgu; yn benodol, rydym yn defnyddio cyfleustodau hunan-ysgrifenedig sy'n casglu sbwriel ac yn cywasgu HFiles yn gyson yn y cefndir. Mae'n ddigon posibl mai dim ond 1 rhanbarth y tabl a ddyrannwyd ar gyfer profion DataStax (nad yw'n gywir) a byddai hyn yn egluro rhywfaint pam roedd HB mor israddol yn eu profion darllen.
Tynnir y casgliadau rhagarweiniol canlynol o hyn. Gan dybio na wnaed unrhyw gamgymeriadau mawr yn ystod y profion, yna mae Cassandra yn edrych fel colossus gyda thraed o glai. Yn fwy manwl gywir, er ei bod yn cydbwyso ar un goes, fel yn y llun ar ddechrau'r erthygl, mae'n dangos canlyniadau cymharol dda, ond mewn ymladd o dan yr un amodau mae'n colli'n llwyr. Ar yr un pryd, gan gymryd i ystyriaeth y defnydd isel o CPU ar ein caledwedd, fe wnaethom ddysgu plannu dau HB RegionServer fesul gwesteiwr a thrwy hynny ddyblu'r perfformiad. Y rhai. Gan gymryd i ystyriaeth y defnydd o adnoddau, mae'r sefyllfa ar gyfer CS hyd yn oed yn fwy gresynus.
Wrth gwrs, mae'r profion hyn yn eithaf synthetig ac mae swm y data a ddefnyddiwyd yma yn gymharol fach. Mae'n bosibl pe baem yn newid i terabytes, y byddai'r sefyllfa'n wahanol, ond er y gallwn lwytho terabytes ar gyfer HB, ar gyfer CS daeth hyn yn broblematig. Roedd yn aml yn taflu OperationTimedOutException hyd yn oed gyda'r cyfrolau hyn, er bod y paramedrau ar gyfer aros am ymateb eisoes wedi cynyddu sawl gwaith o'i gymharu â'r rhai rhagosodedig.
Rwy'n gobeithio, trwy ymdrechion ar y cyd, y byddwn yn dod o hyd i dagfeydd CS ac os gallwn ei gyflymu, yna ar ddiwedd y post byddaf yn bendant yn ychwanegu gwybodaeth am y canlyniadau terfynol.
UPD: Diolch i gyngor cymrodyr, llwyddais i gyflymu'r darlleniad. Oedd:
159 o ops (644 bwrdd, 4 ffrwd, swp 5).
Ychwanegwyd gan:
.withLoadBalancingPolicy(Policy TokenAware newydd(DCAwareRoundRobinPolicy.builder().build()))
Ac yr wyf yn chwarae o gwmpas gyda'r nifer o edafedd. Mae'r canlyniad fel a ganlyn:
4 bwrdd, 100 edafedd, swp = 1 (darn wrth ddarn): 301 ops
4 bwrdd, 100 edafedd, swp = 10: 447 ops
4 bwrdd, 100 edafedd, swp = 100: 625 ops
Yn ddiweddarach byddaf yn defnyddio awgrymiadau tiwnio eraill, yn rhedeg cylch prawf llawn ac yn ychwanegu'r canlyniadau ar ddiwedd y post.
Ffynhonnell: hab.com