Ev ne henekek e jî, wusa dixuye ku ev wêneya taybetî herî rast cewhera van databasan nîşan dide, û di dawiyê de dê diyar bibe çima:
Li gorî DB-Engines Ranking, du databasên stûnên NoSQL yên herî populer Cassandra (li vir CS) û HBase (HB) ne.
Bi daxwaza çarenûsê, tîmê meya rêveberiya barkirina daneyê li Sberbank berê xwe daye û bi HB re ji nêz ve dixebite. Di vê demê de, me hêz û qelsiyên wê baş lêkolîn kir û fêrî çêkirina wê bû. Lêbelê, hebûna alternatîfek di forma CS-ê de her gav me neçar dikir ku em hinekî xwe bi gumanan biêşînin: ma me bijartina rast kir? Wekî din, encamên , ku ji hêla DataStax ve hatî çêkirin, wan got ku CS bi hêsanî HB-ê hema hema bi rêjeyek şikestî têk dibe. Ji hêla din ve, DataStax partiyek eleqedar e, û divê hûn gotina wan negirin. Di heman demê de em ji ber agahdariya piçûktir a di derbarê şert û mercên ceribandinê de jî tevlihev bûn, ji ber vê yekê me biryar da ku em bi xwe fêr bibin ka padîşahê BigData NoSql kî ye, û encamên ku hatine bidestxistin pir balkêş derketin.
Lêbelê, berî ku meriv li ser encamên ceribandinên ku hatine kirin biçin, pêdivî ye ku meriv aliyên girîng ên mîhengên jîngehê binav bike. Rastî ev e ku CS dikare di moda ku dihêle windabûna daneyê de were bikar anîn. Ewan. ev gava ku tenê serverek (girêk) ji daneyên mifteyek diyar berpirsiyar e, û heke ji ber hin sedeman ew têk neçe, wê hingê nirxa vê mifteyê winda dibe. Ji bo gelek karan ev ne krîtîk e, lê ji bo sektora bankingê ev îstîsna ye û ne qaîdeyek. Di doza me de, girîng e ku ji bo hilanîna pêbawer çend kopiyên daneyan hebin.
Ji ber vê yekê, tenê moda xebitandina CS-ê di moda dubarekirina sêalî de hate hesibandin, ango. Afirandina cîhê dozê bi pîvanên jêrîn pêk hat:
CREATE KEYSPACE ks WITH REPLICATION = {'class' : 'NetworkTopologyStrategy', 'datacenter1' : 3};
Dûv re, du rê hene ku ji bo pêbaweriya asta pêwîst a hevgirtinê bicîh bikin. Rêbaza giştî:
NW + NR > RF
Ev tê vê wateyê ku divê jimara piştrastkirina girêkan dema nivîsandinê (NW) plus hejmara pejirandinên ji girêkan dema xwendinê (NR) ji faktora dubarekirinê mezintir be. Di doza me de, RF = 3, ku tê vê wateyê ku vebijarkên jêrîn guncan in:
2 + 2 > 3
3 + 1 > 3
Ji ber ku ji me re girîng e ku em daneyan bi qasî ku pêkan pêbawer hilînin, pilana 3+1 hate hilbijartin. Wekî din, HB li ser prensîbek wekhev dixebite, ango. danberheveke wiha wê adiltir be.
Divê were zanîn ku DataStax di lêkolîna xwe de berevajî kir, wan hem ji bo CS û hem jî HB RF = 1 danîn (ji bo ya paşîn bi guheztina mîhengên HDFS). Ev aliyek bi rastî girîng e ji ber ku bandora li ser performansa CS di vê rewşê de pir mezin e. Mînakî, wêneya jêrîn zêdebûna dema ku ji bo barkirina daneyan li CS-ê hewce ye nîşan dide:
Li vir em jêrîn dibînin: mijarên pêşbazker çiqas daneyan binivîsin, ew qas dirêjtir dibe. Ev xwezayî ye, lê girîng e ku kêmbûna performansê ji bo RF=3 bi girîngî bilindtir e. Bi gotineke din, heke em 4 têlan di nav 5 tabloyan de binivîsin (bi tevahî 20), wê demê RF=3 bi qasî 2 caran winda dibe (150 çirke ji bo RF=3 beramberî 75 ji bo RF=1). Lê heke em bi barkirina daneyan di nav 8 tabloyên ku her yek ji wan 5 têlan hene (bi tevahî 40) barkirinê zêde bikin, wê demê windabûna RF=3 jixwe 2,7 qat e (375 çirk li hember 138).
Dibe ku ev hinekî jî sira ceribandina barkirinê ya serketî ya ku ji hêla DataStax ve ji bo CS-ê hatî çêkirin be, ji ber ku ji bo HB-ê li standa me guheztina faktora dubarekirinê ji 2 ber 3 ti bandorek nekiriye. Ewan. dîskên ji bo veavakirina me ne stûna HB ne. Lêbelê, li vir gelek xeletiyên din jî hene, ji ber ku divê were zanîn ku guhertoya me ya HB-ê piçekî hatî qewirandin û guheztin, hawîrdor bi tevahî cûda ne, hwd. Di heman demê de hêjayî gotinê ye ku dibe ku ez tenê nizanim meriv çawa CS-ê rast amade dikim û hin awayên bi bandortir hene ku meriv pê re bixebite, û ez hêvî dikim ku em ê di şîroveyan de fêr bibin. Lê pêşî tiştên pêşîn.
Hemî ceribandin li ser komek hardware ku ji 4 pêşkêşkeran pêk tê, ku her yek bi veavakirina jêrîn pêk tê, hatin kirin:
CPU: Xeon E5-2680 v4 @ 2.40GHz 64 têlan.
Dîskên: 12 perçe SATA HDD
guhertoya java: 1.8.0_111
Guhertoya CS: 3.11.5
Parametreyên cassandra.ymlhejmara_nîşan: 256
hinted_handoff_enabled: rast
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
rayedar: AllowAllAuthorizer
role_manager: CassandraRoleManager
roles_validity_in_ms: 2000
permissions_validity_in_ms: 2000
credentials_validity_in_ms: 2000
dabeşker: org.apache.cassandra.dht.Murmur3Partitioner
data_file_directories:
- /data1/cassandra/data # her pelrêçek dataN dîskek cihê ye
- /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: derewîn
disk_failure_policy: raweste
commit_failure_policy: raweste
amade_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: periyodîk
commitlog_sync_period_in_ms: 10000
commitlog_segment_size_in_mb: 32
seed_provider:
- class_name: org.apache.cassandra.locator.SimpleSeedProvider
Parameters
- tov: "*,*"
concurrent_reads: 256 # ceriband 64 - tu cûdahî nehat dîtin
concurrent_writes: 256 # ceriband 64 - tu cûdahî nehat dîtin
concurrent_counter_writes: 256 # ceriband 64 - tu cûdahî nehat dîtin
concurrent_materialized_view_writes: 32
memtable_heap_space_in_mb: 2048 # 16 GB ceriband - hêdîtir bû
memtable_allocation_type: heap_buffers
index_summary_kapacity_in_mb:
index_summary_resize_interval_in_minutes: 60
trickle_fsync: derewîn
trickle_fsync_interval_in_kb: 10240
depo_port: 7000
ssl_storage_port: 7001
listen_navnîşan: *
navnîşana_weşanê: *
listen_on_broadcast_address: rast
internode_authenticator: org.apache.cassandra.auth.AllowAllInternodeAuthenticator
start_native_transport: rast
xwecihî_transport_port: 9042
start_rpc: rast
rpc_address: *
rpc_port: 9160
rpc_keepalive: rast
rpc_server_type: hevdeng
thrift_framed_transport_size_in_mb: 15
incremental_backups: derewîn
snapshot_before_compaction: derewîn
auto_snapshot: rast
column_index_size_in_kb: 64
column_index_cache_size_in_kb: 2
hevdem_kompaktor: 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
daxwaz_timeout_in_ms: 200000
slow_query_log_timeout_in_ms: 500
cross_node_timeout: derewîn
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: tune
client_encryption_options:
enabled: derewîn
internode_compression: dc
inter_dc_tcp_nodelay: derewîn
tracetype_query_ttl: 86400
tracetype_repair_ttl: 604800
enable_user_defined_functions: derewîn
enable_scripted_user_defined_functions: derewîn
windows_timer_navber: 1
transparent_data_encryption_options:
enabled: derewîn
tombstone_warn_threshold: 1000
bergeha_şkestina_ gorê: 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: derewîn
enable_materialized_views: rast
enable_sasi_indexes: rast
Mîhengên GC:
### Mîhengên CMS-XX: + UseParNewGC
-XX: + UseConcMarkSweepGC
-XX:+CMSParallelRemark Enabled
-XX:Ratio Survivor=8
-XX:MaxTenuringThreshold=1
-XX:CMSInitiatingOccupancyFraction=75
-XX:+CMSInitiatingOccupancyOnly bikar bînin
-XX:CMSWaitDuration=10000
-XX:+CMSParallelInitialMarkEnabled
-XX: + CMSEdenChunksRecordHerdem
-XX:+CMSClassUnloadingEnabled
Bîra jvm.options 16Gb hate veqetandin (me 32 Gb jî ceriband, tu cûdahî nehat dîtin).
Tablo bi fermanê hatine çêkirin:
CREATE TABLE ks.t1 (id bigint PRIMARY KEY, title text) WITH compression = {'sstable_compression': 'LZ4Compressor', 'chunk_length_kb': 64};Guhertoya HB: 1.2.0-cdh5.14.2 (di sinifa org.apache.hadoop.hbase.regionserver.HRegion de me MetricsRegion dernexist ku diçû GC dema ku hejmara herêman li ser RegionServer ji 1000î zêdetir bû)
Parametreyên HBase-ne-defaultzookeeper.session.timeout: 120000
hbase.rpc.timeout: 2 deqîqe(s)
hbase.client.scanner.timeout.period: 2 deqîqe(s)
hbase.master.handler.count: 10
hbase.regionserver.lease.period, hbase.client.scanner.timeout.period: 2 deqîqe(s)
hbase.regionserver.handler.count: 160
hbase.regionserver.metahandler.count: 30
hbase.regionserver.logroll.period: 4 saet(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 roj
Snippet Veavakirina Pêşkeftî ya Karûbarê HBase (Valveya Ewlekariyê) ji bo 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
Vebijarkên Veavakirina Java ji bo HBase RegionServer:
-XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70 -XX:+CMSParallelRemarkEnabled -XX:ReservedCodeCacheSize=256m
hbase.snapshot.master.timeoutMillis: 2 deqîqe(s)
hbase.snapshot.region.timeout: 2 deqîqe(s)
hbase.snapshot.master.timeout.millis: 2 deqîqe(s)
HBase REST Server Max Log Mezinahî: 100 MiB
Pêşkêşkara HBase REST Piştgiriya Pelê Têketinê ya Zêde: 5
HBase Thrift Server Max Log Mezinahî: 100 MiB
Pêşkêşkara HBase Thrift Vegerandina Pelê Têketinê ya Zêde: 5
Mezinahiya Têketinê ya Master Max: 100 MiB
Piştgiriya Pelê Têketinê ya Mamoste: 5
Mezinahiya Têketinê ya HerêmServer Max: 100 MiB
Backupên Pelê Têketinê yên Herî Server: 5
HBase Active Master Detection Pace: 4 deqîqe(s)
dfs.client.hedged.read.threadpool.size: 40
dfs.client.hedged.read.threshold.millis: 10 millisecond(s)
hbase.rest.threads.min: 8
hbase.rest.threads.max: 150
Danasîna Pelê Pêvajoya Herî zêde: 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
Mijarên Veguhastina Herêmê: 6
Mezinahiya Heap Java ya Xerîdar li Bîtan: 1 GiB
HBase REST Pêşkêşkara Pêşkêşkara Pêşkêşkar: 3 GiB
HBase Thrift Server Standard Koma: 3 GiB
Mezinahiya Java Heap ya HBase Master bi Bîtan: 16 GiB
Mezinahiya Java Heap ya Servera Herêmê ya HBase li Bîtan: 32 GiB
+ZooKeeper
maxClientCnxns: 601
maxSessionTimeout: 120000
Çêkirina tabloyan:
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'}
Li vir xalek girîng heye - danasîna DataStax nabêje çend herêm ji bo afirandina tabloyên HB hatine bikar anîn, her çend ev ji bo cildên mezin krîtîk e. Ji ber vê yekê, ji bo ceribandinan, hêjmar = 64 hate hilbijartin, ku destûrê dide hilanîna heya 640 GB, ango. sifrê size navîn.
Di dema ceribandinê de, HBase 22 hezar tablo û 67 hezar herêm hebûn (ev ji bo guhertoya 1.2.0 kujer bûya heke ne ji bo patchê ku li jor hatî destnîşan kirin).
Niha ji bo kodê. Ji ber ku ne diyar bû ku kîjan mîhengan ji bo databasek taybetî bikêrtir in, ceribandin di navhevokên cihêreng de hatin kirin. Ewan. di hin ceribandinan de, 4 tablo bi hevdemî hatin barkirin (her 4 girêk ji bo girêdanê hatin bikar anîn). Di testên din de em bi 8 tabloyên cihêreng xebitîn. Di hin rewşan de, mezinahiya hevîrê 100 bû, di hinên din de 200 (parametreya hevîrê - li koda jêrîn binêre). Mezinahiya daneyê ji bo nirxê 10 byte an 100 bytes e (DataSize). Bi tevahî, her carê di her tabloyê de 5 mîlyon qeyd hatin nivîsandin û xwendin. Di heman demê de, li ser her tabloyê 5 mijar hatin nivîsandin/xwendin (hejmara mijarê - thNum), ku her yek ji wan bişkojkên xwe bi kar anî (hejmar = 1 mîlyon):
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);
}
}
Li gorî vê yekê, fonksiyonek wekhev ji bo HB hate peyda kirin:
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);
}
}
Ji ber ku di HB de pêdivî ye ku xerîdar bala xwe bide dabeşkirina yekgirtî ya daneyan, fonksiyona xwê ya sereke bi vî rengî xuya bû:
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);
}
Niha beşa herî balkêş - encam:
Di forma grafîkê de heman tişt:
Feydeya HB ew qas ecêb e ku guman heye ku di sazkirina CS-ê de celebek tengahiyê heye. Lêbelê, Googl û lêgerîna li parametreyên herî eşkere (wek concurrent_writes an memtable_heap_space_in_mb) tiştan lez nekir. Di heman demê de, têketin paqij in û li ser tiştek sond naxwin.
Daneyên li ser girêkan bi rengek wekhev hate belav kirin, statîstîkên hemî girêkan bi qasî hev bûn.
Ya ku statîstîkên tabloyê ji yek ji girêkan xuya dike ev eCihê key: ks
Hejmara Xwendin: 9383707
Derengiya xwendinê: 0.04287025042448576 ms
Hejmara binivîse: 15462012
Derengiya Nivîsandinê: 0.1350068438699957 ms
Germên li bendê: 0
Tablo: t1
Hejmara SSTable: 16
Cihê ku tê bikar anîn (zindî): 148.59 MiB
Cihê bikar anîn (bi tevahî): 148.59 MiB
Cihê ku ji hêla wêneyan ve hatî bikar anîn (bi tevahî): 0 byte
Bîra bêserûber hatî bikar anîn (bi tevahî): 5.17 MiB
Rêjeya Têkbirina SSTable: 0.5720989576459437
Hejmara dabeşan (texmîn): 3970323
Hejmara şaneyên Memtable: 0
Mezinahiya daneya Memtable: 0 bytes
Memtable off heap bîra tê bikaranîn: 0 bytes
Hejmara veguherîna Memtable: 5
Hejmara xwendina herêmî: 2346045
Derengiya xwendina herêmî: NaN ms
Hejmara nivîsandina herêmî: 3865503
Derengiya nivîsandina herêmî: NaN ms
Germên li bendê: 0
Ji sedî tamîrkirin: 0.0
Parzûna kulîlkê pozîtîfên derewîn: 25
Rêjeya derewîn Parzûna Bloom: 0.00000
Cihê parzûna kulîlkê hatî bikar anîn: 4.57 MiB
Parzûna Bloom ji bîranîna tîrêjê tê bikar anîn: 4.57 MiB
Kurteya îndeksê ya bîranîna kelûmê ya hatî bikar anîn: 590.02 KiB
Metadata berhevkirinê ya ji bîranîna giravê hatî bikar anîn: 19.45 KiB
Herî kêm bytên dabeşkirina berhevkirî: 36
Bîteyên herî zêde yên dabeşkirina berhevkirî: 42
Wateya beytên dabeşkirina berhevkirî: 42
Navincî hucreyên zindî yên her perçeyek (pênc hûrdemên paşîn): NaN
Her perçeyek herî zêde şaneyên zindî (pênc deqeyên dawî): 0
Kevirên goran ên navîn li ser perçeyê (pênc hûrdemên paşîn): NaN
Her perçeyê herî zêde kevirên gorê (pênc deqeyên dawî): 0
Mutasyonên daketî: 0 byte
Hewldanek ji bo kêmkirina mezinahiya komê (tewra şandina wê bi serê xwe) ti bandorek nekir, ew tenê xirabtir bû. Mimkun e ku bi rastî ev bi rastî performansa herî zêde ya ji bo CS-ê ye, ji ber ku encamên ku ji bo CS-ê hatine bidestxistin dişibihe yên ku ji bo DataStax-ê hatine wergirtin - bi sed hezaran operasyon di çirkeyê de. Wekî din, heke em li karanîna çavkaniyê binerin, em ê bibînin ku CS pirtir CPU û dîskan bikar tîne:
Hêjmar karanîna di dema meşandina hemî ceribandinên li pey hev ji bo her du databasan nîşan dide.
Di derbarê berjewendiya xwendina bihêz a HB de. Li vir hûn dikarin bibînin ku ji bo her du databasan, karanîna dîskê di dema xwendinê de pir kêm e (testên xwendinê ji bo her databasê beşa paşîn a çerxa ceribandinê ne, mînakî ji bo CS ev ji 15:20 heta 15:40 e). Di doza HB de, sedem zelal e - piraniya daneyan di bîranînê de, di memstore de, û hin jî di blokê de têne girtin. Di derbarê CS-ê de, ne pir zelal e ka ew çawa dixebite, lê vezîvirandina dîskê jî nayê xuyang kirin, lê di her rewşê de, hewl hat dayîn ku cache row_cache_size_in_mb = 2048 çalak bike û caching = {'keys': 'HEMÛ', 'rows_per_partition': ' 2000000'}, lê vê yekê ew hinekî xirabtir kir.
Her weha hêja ye ku carek din xalek girîng di derbarê hejmara herêmên li HB de were gotin. Di rewşa me de, nirx wekî 64 hate destnîşan kirin. Heke hûn wê kêm bikin û wê bikin wek mînak, 4, wê hingê dema xwendinê, lez 2 carî dadikeve. Sedem ev e ku memstore dê zûtir tije bibe û pel dê pir caran pirtir werin şuştin û dema xwendinê, pêdivî ye ku bêtir pel bêne pêvajo kirin, ku ev ji bo HB karekî pir tevlihev e. Di şert û mercên rastîn de, ev dikare bi fikirîna bi stratejiyek pêşbirkkirin û berhevkirinê were derman kirin; nemaze, em karûbarek xwe-nivîskî bikar tînin ku çopê berhev dike û HFiles bi domdarî di paşerojê de berhev dike. Pir mimkun e ku ji bo ceribandinên DataStax wan ji her tabloyê tenê 1 herêm veqetandine (ku ne rast e) û ev ê hinekî zelal bike ka çima HB di ceribandinên xwendina wan de ew qas kêm bû.
Encamên pêşîn ên jêrîn ji vê yekê têne derxistin. Bihesibînin ku di dema ceribandinê de xeletiyên mezin nehatine kirin, wê hingê Cassandra mîna kolosek bi lingên gil xuya dike. Bi rastî, dema ku ew li ser yek lingê hevseng dike, wekî di wêneya di destpêka gotarê de, ew encamên nisbeten baş nîşan dide, lê di şerek di bin heman şertan de ew bi tevahî winda dike. Di heman demê de, li ber çavan kêm karanîna CPU-ya li ser hardware me, em fêr bûn ku her mêvandar du HB RegionServer biçînin û bi vî rengî performansa ducar kirin. Ewan. Li ber çavan bikaranîna çavkaniyan, rewşa CS-ê hê xerabtir e.
Bê guman, ev ceribandin pir sentetîk in û hêjeya daneyên ku li vir hatine bikar anîn bi rêkûpêk hindik e. Mimkun e ku ger em veguheztin terabytes, rewş cûda bûya, lê dema ku ji bo HB em dikarin terabytes bar bikin, ji bo CS ev yek pirsgirêk derket. Ew bi gelemperî bi van cildan re jî OperationTimedOutException avêt, her çend pîvanên li benda bersivê berê çend caran li gorî yên xwerû zêde bûne.
Ez hêvî dikim ku bi hewildanên hevbeş em ê kêşeyên CS-yê bibînin û ger em karibin wê bilezînin, wê hingê di dawiya postê de ez ê bê guman agahdariya li ser encamên dawîn zêde bikim.
UPD: Bi saya şîretên hevalan, min karî leza xwendinê bikim. Bû:
159 ops (644 tablo, 4 stream, hev 5).
Lê zêde kir:
.withLoadBalancingPolicy(new TokenAwarePolicy(DCAwareRoundRobinPolicy.builder().build()))
Û min bi hejmara têlan lîst. Encam ev e:
4 tablo, 100 têl, kom = 1 (parçe bi perçe): 301 ops
4 tablo, 100 mijarên, kom = 10: 447 ops
4 tablo, 100 mijarên, kom = 100: 625 ops
Dûv re ez ê serişteyên din ên tunekirinê bicîh bikim, çerxek ceribandinek tevahî bimeşînim û encaman di dawiya postê de lê zêde bikim.
Source: www.habr.com