මෙය විහිළුවක්වත් නොවේ, මෙම විශේෂිත පින්තූරය මෙම දත්ත සමුදායේ සාරය වඩාත් නිවැරදිව පිළිබිඹු කරන බව පෙනේ, අවසානයේ එය පැහැදිලි වනු ඇත:
DB-Engines ශ්‍රේණිගත කිරීම අනුව, වඩාත් ජනප්‍රිය NoSQL තීරු දත්ත සමුදායන් දෙක වන්නේ Cassandra (මින් ඉදිරියට CS) සහ HBase (HB) වේ.
දෛවයේ කැමැත්ත අනුව, Sberbank හි අපගේ දත්ත පැටවීමේ කළමනාකරණ කණ්ඩායම දැනටමත් ඇත සහ HB සමඟ සමීපව කටයුතු කරයි. මෙම කාලය තුළ අපි එහි ශක්තීන් සහ දුර්වලතා හොඳින් අධ්‍යයනය කර එය උයන්නේ කෙසේදැයි ඉගෙන ගත්තෙමු. කෙසේ වෙතත්, CS ස්වරූපයෙන් විකල්පයක් තිබීම සැමවිටම අපට සැකයෙන් මඳක් වධ හිංසා කිරීමට බල කළේය: අපි නිවැරදි තේරීමක් කළාද? එපමණක් නොව, ප්රතිඵල , DataStax විසින් සිදු කරන ලද අතර, ඔවුන් පැවසුවේ CS ඉතා පහසුවෙන් HB පරාජය කරන බවයි. අනෙක් අතට, DataStax උනන්දුවක් දක්වන පාර්ශ්වයක් වන අතර, ඔබ ඒ සඳහා ඔවුන්ගේ වචනය නොගත යුතුය. පරීක්ෂණ කොන්දේසි පිළිබඳ තරමක් කුඩා තොරතුරු වලින් අපි ව්‍යාකූලත්වයට පත් වූ අතර, එබැවින් BigData NoSql හි රජු කවුදැයි අපි තනිවම සොයා ගැනීමට තීරණය කළ අතර ලබාගත් ප්‍රති results ල ඉතා සිත්ගන්නා සුළු විය.
කෙසේ වෙතත්, සිදු කරන ලද පරීක්ෂණවල ප්රතිඵල වෙත යාමට පෙර, පාරිසරික වින්යාසයන්හි සැලකිය යුතු අංගයන් විස්තර කිරීම අවශ්ය වේ. කාරණය වන්නේ දත්ත නැතිවීමට ඉඩ සලසන මාදිලියක CS භාවිතා කළ හැකි බවයි. එම. මෙය යම් යතුරක දත්ත සඳහා එක් සේවාදායකයක් (නෝඩයක්) පමණක් වගකිව යුතු අතර, කිසියම් හේතුවක් නිසා එය අසමත් වුවහොත්, මෙම යතුරේ වටිනාකම නැති වී යයි. බොහෝ කාර්යයන් සඳහා මෙය තීරණාත්මක නොවේ, නමුත් බැංකු අංශය සඳහා මෙය නීතියට වඩා ව්යතිරේකයකි. අපගේ නඩුවේදී, විශ්වසනීය ගබඩා කිරීම සඳහා දත්ත පිටපත් කිහිපයක් තිබීම වැදගත්ය.
එබැවින්, ත්රිත්ව අනුකරණ මාදිලියේ CS මෙහෙයුම් ආකාරය පමණක් සලකා බලන ලදී, i.e. කේස් අවකාශය නිර්මාණය කිරීම පහත පරාමිතීන් සමඟ සිදු කරන ලදී:
CREATE KEYSPACE ks WITH REPLICATION = {'class' : 'NetworkTopologyStrategy', 'datacenter1' : 3};
ඊළඟට, අවශ්ය මට්ටමේ අනුකූලතාව සහතික කිරීමට ක්රම දෙකක් තිබේ. සාමාන්ය රීතිය:
NW + NR > RF
එයින් අදහස් වන්නේ ලිවීමේදී නෝඩ් වලින් තහවුරු කිරීම් ගණන (NW) සහ කියවන විට නෝඩ් වලින් ලැබෙන තහවුරු කිරීම් ගණන (NR) අනුකරණ සාධකයට වඩා වැඩි විය යුතු බවයි. අපගේ නඩුවේදී, RF = 3, එනම් පහත විකල්ප සුදුසු ය:
2 + 2 > 3
3 + 1 > 3
දත්ත හැකිතාක් විශ්වාසදායක ලෙස ගබඩා කිරීම අපට මූලික වශයෙන් වැදගත් වන බැවින්, 3+1 යෝජනා ක්‍රමය තෝරා ගන්නා ලදී. මීට අමතරව, HB සමාන මූලධර්මයක් මත ක්රියා කරයි, i.e. එවැනි සංසන්දනයක් වඩාත් සාධාරණ වනු ඇත.
DataStax ඔවුන්ගේ අධ්‍යයනයේ දී ප්‍රතිවිරුද්ධ දෙය කළ බව සටහන් කළ යුතුය, ඔවුන් CS සහ HB යන දෙකටම RF = 1 සකසා ඇත (දෙවැන්න සඳහා HDFS සැකසුම් වෙනස් කිරීමෙන්). මෙම නඩුවේ CS කාර්ය සාධනය කෙරෙහි ඇති බලපෑම විශාල බැවින් මෙය සැබවින්ම වැදගත් අංගයකි. උදාහරණයක් ලෙස, පහත පින්තූරයේ දැක්වෙන්නේ CS වෙත දත්ත පූරණය කිරීමට ගතවන කාලය වැඩිවීමයි:
මෙන්න අපි පහත දේ දකිමු: තරඟකාරී නූල් දත්ත ලියන තරමට, එය වැඩි කාලයක් ගතවේ. මෙය ස්වාභාවිකය, නමුත් RF=3 සඳහා කාර්ය සාධනය පිරිහීම සැලකිය යුතු ලෙස වැඩි වීම වැදගත් වේ. වෙනත් වචන වලින් කිවහොත්, අපි වගු 4 බැගින් (සම්පූර්ණයෙන් 5) නූල් 20ක් ලිව්වොත්, RF=3 2 ගුණයකින් පමණ අහිමි වේ (RF=150 සඳහා තත්පර 3 සහ RF=75 සඳහා 1). නමුත් අපි නූල් 8 බැගින් (සම්පූර්ණයෙන් 5) වගු 40කට දත්ත පැටවීමෙන් බර වැඩි කළහොත් RF=3 හි අලාභය දැනටමත් 2,7 ගුණයක් වේ (තත්පර 375 සහ 138).
සමහර විට CS සඳහා DataStax විසින් සිදු කරන ලද සාර්ථක පැටවීමේ පරීක්ෂණයේ රහස මෙය විය හැකිය, මන්ද අපගේ ස්ථාවරයේ HB සඳහා 2 සිට 3 දක්වා අනුවර්තන සාධකය වෙනස් කිරීම කිසිදු බලපෑමක් ඇති නොකළ බැවිනි. එම. තැටි අපගේ වින්‍යාසය සඳහා HB බාධාව නොවේ. කෙසේ වෙතත්, මෙහි තවත් බොහෝ අන්තරායන් ඇත, මන්ද අපගේ HB අනුවාදය තරමක් පැච් කර වෙනස් කර ඇති බව සැලකිල්ලට ගත යුතුය, පරිසරය සම්පූර්ණයෙන්ම වෙනස් ය. සමහර විට මම CS නිවැරදිව සකස් කරන්නේ කෙසේදැයි නොදන්නා බවත් එය සමඟ වැඩ කිරීමට තවත් ඵලදායී ක්රම කිහිපයක් ඇති බවත් සඳහන් කිරීම වටී, අපි අදහස් දැක්වීමේදී සොයාගනු ඇතැයි මම බලාපොරොත්තු වෙමි. නමුත් පළමු දේ පළමුව.
සියලුම පරීක්ෂණ සිදු කරන ලද්දේ සේවාදායකයන් 4 කින් සමන්විත දෘඪාංග පොකුරක් මත වන අතර, ඒ සෑම එකක්ම පහත වින්‍යාසය ඇත:
CPU: Xeon E5-2680 v4 @ 2.40GHz නූල් 64.
තැටි: 12 කෑලි SATA HDD
java අනුවාදය: 1.8.0_111
CS අනුවාදය: 3.11.5
cassandra.yml පරාමිතීන්ටෝකන_සංඛ්‍යාව: 256
hinted_handoff_enabled: true
hinted_handoff_throttle_in_kb: 1024
max_hints_delivery_threads: 2
hints_directory: /data10/cassandra/hints
hints_flush_period_ms: 10000
max_hints_file_size_in_mb: 128
batchlog_replay_throttle_in_kb: 1024
authenticator: AllowAllAuthenticator
authorizer: AllowAllAuthorizer
භූමිකාව_කළමනාකරු: CassandraRoleManager
ms: 2000 හි භූමිකාවන්_වලංගු භාවය
අවසරයන්_වලංගු_අවස්ථාව: 2000
අක්තපත්‍ර_වලංගු_මිතු_තුළ: 2000
partitioner: 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: බොරු
disk_failure_policy: නවත්වන්න
කැපවීම_අසාර්ථක_ප්‍රතිපත්තිය: නවත්වන්න
සූදානම්_ප්‍රකාශයන්_cache_size_mb:
සකසුරුවම්_සකසන_ප්‍රකාශයන්_හැඹිලි_ප්රමාණය_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_cache_directory: /data10/cassandra/saved_cache
කැපවීම_සමමුහුර්ත: ආවර්තිතා
කැපවීම්_සමමුහුර්ත_කාලපරිච්ඡේදය: 10000
කැපවීම්_කොටස_ප්රමාණය_mb: 32
බීජ_ සපයන්නා:
- class_name: org.apache.cassandra.locator.SimpleSeedProvider
පරාමිතීන්:
- බීජ: "*,*"
සමගාමී_කියවීම: 256 # උත්සාහ 64 - වෙනසක් නොපෙනුණි
සමගාමී_ලියන්නේ: 256 # උත්සාහ 64 - වෙනසක් දක්නට නොලැබුණි
සමගාමී_ප්‍රති_ලිවීම: 256 # උත්සාහ 64 - වෙනසක් නොපෙනුණි
concurrent_materialized_view_writes: 32
memtable_heap_space_mb: 2048 # 16 GB උත්සාහ කළා - එය මන්දගාමී විය
memtable_alocation_type: heap_buffers
index_summary_capacity_in_mb:
දර්ශක_සාරාංශ_ප්රමාණය_විනාඩි_තුළ_පරිමාණ: 60
trickle_fsync: අසත්‍ය
trickle_fsync_interval_in_kb: 10240
ගබඩා_වරාය: 7000
ssl_storage_port: 7001
සවන් දෙන්න_ලිපිනය: *
විකාශන_ලිපිනය: *
සවන් දෙන්න_විකාශනය_ලිපිනය: ඇත්ත
internode_authenticator: org.apache.cassandra.auth.AllowAllInternodeAuthenticator
start_native_transport: true
දේශීය_ප්‍රවාහන_වරාය: 9042
start_rpc: ඇත්ත
rpc_address: *
rpc_port: 9160
rpc_keepalive: ඇත්ත
rpc_server_type: සමමුහුර්ත කරන්න
සකසුරුවම්_රාමු_ප්‍රවාහන_ප්රමාණය_mb: 15
incremental_backups: false
snapshot_before_compction: false
auto_snapshot: ඇත්ත
column_index_size_in_kb: 64
column_index_cache_size_in_kb: 2
සමගාමී_සංයුක්ත: 4
සංයුක්ත_throughput_mb_per_sec: 1600
sstable_preemptive_open_interval_in_mb: 50
කියවීම_ඉල්ලීම_කාලය_ඉක්මවීම_මි.: 100000
පරාසය_ඉල්ලීම_කාලය_ඉක්මවීම_මි.: 200000
ms_in_request_timeout_in: 40000
counter_write_request_timeout_in_ms: 100000
cas_contention_timeout_ins_ms: 20000
msg_in_request_timeout_com: 60000
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
ගතික_snitch_badness_threshold: 0.1
request_scheduler: org.apache.cassandra.scheduler.NoScheduler
server_encryption_options:
internode_encryption: කිසිවක් නැත
client_encryption_options:
enabled: false
internode_compression: dc
inter_dc_tcp_nodelay: අසත්‍ය
tracetype_query_ttl: 86400
tracetype_repair_ttl: 604800
enable_user_defined_functions: false
enable_scripted_user_defined_functions: false
windows_timer_interval: 1
විනිවිද පෙනෙන_දත්ත_ගුප්තකේතන_විකල්ප:
enabled: false
සොහොන් ගල_අවවාද_ඉන්පසුව: 1000
සොහොන් ගල_අසාර්ථක_එළිමහන: 100000
batch_size_warn_threshold_in_kb: 200
batch_size_fail_threshold_in_kb: 250
unlogged_batch_cross_partitions_warn_threshold: 10
සංයුක්ත_විශාල_කොටස_අවවාද_ඉලක්කම්_mb: 100
gc_warn_threshold_in_ms: 1000
back_pressure_enabled: false
enable_materialized_views: true
enable_sasi_indexes: true
GC සැකසුම්:
### CMS සැකසුම්-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
-XX:+CMSParallelRemarkEnabled
-XX:SurvivorRatio=8
-XX:MaxTenuringThreshold=1
-XX:CMSInitiatingOccupancyFraction=75
-XX:+CMSආරම්භක පදිංචිය පමණක් භාවිතා කරන්න
-XX:CMSWaitDuration=10000
-XX:+CMSParallelInitialMarkEnabled
-XX:+CMSEdenChunksRecordAlways
-XX:+CMSclassUnloading Enabled
jvm.options මතකය 16Gb වෙන් කර ඇත (අපි 32 Gb ද උත්සාහ කළෙමු, වෙනසක් දක්නට නොලැබුණි).
වගු නිර්මාණය කර ඇත්තේ විධානය සමඟිනි:
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 බැහැර කළෙමු, එය RegionServer හි කලාප ගණන 1000ට වඩා වැඩි වූ විට GC වෙත යොමු විය)
පෙරනිමි නොවන HBase පරාමිතීන්zookeeper.session.timeout: 120000
hbase.rpc.timeout: මිනිත්තු 2(ය)
hbase.client.scanner.timeout.period: මිනිත්තු 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.compactionTreshold: 5
hbase.hstore.blockingStoreFiles: 200
hbase.hregion.majorcompction: 1 දින(ය)
hbase-site.xml සඳහා HBase සේවා උසස් වින්‍යාස ස්නිපට් (ආරක්ෂිත කපාටය):
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
HBase RegionServer සඳහා Java Configuration විකල්ප:
-XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSආරම්භක වාඩිලාගැනීමේ භාගය=70 -XX:+CMSParallelRemarkEnabled -XX:ReservedCodeCacheSize=256m
hbase.snapshot.master.timeoutMillis: මිනිත්තු 2(ය)
hbase.snapshot.region.timeout: මිනිත්තු 2(ය)
hbase.snapshot.master.timeout.millis: මිනිත්තු 2(ය)
HBase REST සේවාදායකය උපරිම ලොග් ප්රමාණය: 100 MiB
HBase REST සේවාදායකය උපරිම ලොග් ගොනු උපස්ථ: 5
HBase සකසුරුවම් සේවාදායකය උපරිම ලොග් ප්රමාණය: 100 MiB
HBase Thrift Server උපරිම ලොග් ගොනු උපස්ථ: 5
Master Max ලොග් ප්රමාණය: 100 MiB
ප්‍රධාන උපරිම ලොග් ගොනු උපස්ථ: 5
RegionServer උපරිම ලොග් ප්රමාණය: 100 MiB
RegionServer උපරිම ලොග් ගොනු උපස්ථ: 5
HBase Active Master Detection Window: විනාඩි 4(ය)
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
උපරිම ක්‍රියාවලි ගොනු විස්තර: 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
සේවාලාභී ජාවා ගොඩ ප්රමාණය බයිට් වලින්: 1 GiB
HBase REST Server Default Group: 3 GiB
HBase Thrift Server Default Group: 3 GiB
බයිට් වලින් HBase Master හි Java Heap ප්රමාණය: 16 GiB
බයිට් වලින් HBase RegionServer හි Java Heap ප්රමාණය: 32 GiB
+සත්වෝද්‍යාන පාලකයා
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 GB දක්වා ගබඩා කිරීමට ඉඩ සලසයි, i.e. මධ්යම ප්රමාණයේ වගුව.
පරීක්ෂණය සිදු කරන විට, 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 සැකසුම තුළ යම් ආකාරයක අවහිරතාවයක් ඇති බවට සැකයක් ඇත. කෙසේ වෙතත්, ගූගල් කිරීම සහ වඩාත් පැහැදිලි පරාමිති සෙවීම (concurrent_writes හෝ memtable_heap_space_in_mb වැනි) දේවල් වේගවත් කළේ නැත. ඒ අතරම, ලොග් පිරිසිදු වන අතර කිසිවක් දිවුරන්නේ නැත.
දත්ත නෝඩ් හරහා ඒකාකාරව බෙදා හැර ඇත, සියලුම නෝඩ් වල සංඛ්‍යාලේඛන දළ වශයෙන් සමාන විය.
එක් නෝඩ් එකකින් වගු සංඛ්‍යාලේඛන පෙනෙන්නේ මෙයයියතුරු අවකාශය: ks
කියවීම් ගණන: 9383707
ප්‍රමාදය කියවන්න: 0.04287025042448576 ms
ලියන්න ගණන: 15462012
ප්‍රමාදය ලියන්න: 0.1350068438699957 ms
පොරොත්තු ෆ්ලෂ්ස්: 0
වගුව: t1
SSTable ගණන: 16
භාවිතා කළ අවකාශය (සජීවී): 148.59 MiB
භාවිතා කළ ඉඩ (මුළු): 148.59 MiB
ස්නැප්ෂොට් මගින් භාවිතා කරන ඉඩ (මුළු): බයිට් 0
ඕෆ් හීප් මතකය භාවිතා කර ඇත (මුළු): 5.17 MiB
SSTable සම්පීඩන අනුපාතය: 0.5720989576459437
කොටස් ගණන (ඇස්තමේන්තුව): 3970323
මතක සෛල ගණන: 0
මතක තබා ගත හැකි දත්ත ප්රමාණය: බයිට් 0
භාවිතා කළ Memtable off heap මතකය: 0 බයිට්
මතක ස්විච ගණන: 5
දේශීය කියවීම් ගණන: 2346045
දේශීය කියවීමේ ප්‍රමාදය: NaN ms
දේශීය ලිවීම් ගණන: 3865503
දේශීය ලිවීමේ ප්‍රමාදය: NaN ms
පොරොත්තු ෆ්ලෂ්: 0
අලුත්වැඩියා කළ ප්‍රතිශතය: 0.0
බ්ලූම් ෆිල්ටර් ව්‍යාජ ධනාත්මක: 25
බ්ලූම් ෆිල්ටර් ව්‍යාජ අනුපාතය: 0.00000
භාවිතා කරන ලද බ්ලූම් ෆිල්ටර් ඉඩ: 4.57 MiB
බ්ලූම් ෆිල්ටර් ඔෆ් හීප් මතකය භාවිතා කර ඇත: 4.57 MiB
දර්ශක සාරාංශය ඕෆ් හීප් මතකය භාවිතා කර ඇත: 590.02 KiB
සම්පීඩන පාරදත්ත භාවිතා කළ ගොඩ මතකය: 19.45 KiB
සංයුක්ත කොටස් අවම බයිට්: 36
සංයුක්ත කොටස් උපරිම බයිට්: 42
සංයුක්ත කොටසේ මධ්‍යන්‍ය බයිට්: 42
පෙත්තකට සාමාන්ය සජීවී සෛල (අවසන් මිනිත්තු පහ): NaN
පෙත්තකට උපරිම සජීවී සෛල (අවසන් මිනිත්තු පහ): 0
පෙත්තකට සාමාන්ය සොහොන් ගල් (අවසන් මිනිත්තු පහ): NaN
පෙත්තකට උපරිම සොහොන් ගල් (අවසන් මිනිත්තු පහ): 0
අතහැර දැමූ විකෘති: 0 බයිට්
කණ්ඩායමේ ප්රමාණය අඩු කිරීමට උත්සාහ කිරීම (එය තනි තනිව යැවීම පවා) කිසිදු බලපෑමක් ඇති කළේ නැත, එය නරක අතට හැරුණි. CS සඳහා ලබා ගන්නා ප්රතිඵල DataStax සඳහා ලබා ගත් ප්‍රතිඵලවලට සමාන වන බැවින් - තත්පරයකට මෙහෙයුම් සිය දහස් ගණනක් පමණ වන බැවින් ඇත්ත වශයෙන්ම මෙය CS සඳහා උපරිම කාර්ය සාධනය විය හැකිය. ඊට අමතරව, අපි සම්පත් භාවිතය දෙස බැලුවහොත්, CS වැඩිපුර CPU සහ තැටි භාවිතා කරන බව අපට පෙනෙනු ඇත:
දත්ත සමුදායන් දෙකම සඳහා පේළියේ ඇති සියලුම පරීක්ෂණ ධාවනයේදී භාවිතා කරන ආකාරය රූපයේ දැක්වේ.
HB හි බලවත් කියවීමේ වාසිය සම්බන්ධයෙන්. දත්ත සමුදායන් දෙක සඳහාම, කියවීමේදී තැටි භාවිතය අතිශයින් අඩු බව මෙහිදී ඔබට දැක ගත හැක (කියවීම පරීක්ෂණ යනු එක් එක් දත්ත සමුදාය සඳහා වන පරීක්ෂණ චක්‍රයේ අවසාන කොටසයි, උදාහරණයක් ලෙස CS සඳහා මෙය 15:20 සිට 15:40 දක්වා වේ). HB සම්බන්ධයෙන්, හේතුව පැහැදිලිය - බොහෝ දත්ත මතකයේ, memstore හි එල්ලී ඇති අතර, සමහරක් blockcache තුළ හැඹිලිගත වේ. CS සම්බන්ධයෙන් ගත් කල, එය ක්රියා කරන ආකාරය ඉතා පැහැදිලි නැත, නමුත් තැටි ප්‍රතිචක්‍රීකරණය ද දෘශ්‍යමාන නොවේ, නමුත් යම් අවස්ථාවක දී, හැඹිලිය සක්‍රිය කිරීමට උත්සාහයක් ගන්නා ලදී row_cache_size_in_mb = 2048 සහ හැඹිලි = {'keys': 'සියල්ල', 'row_per_partition': ' 2000000'}, නමුත් එය තව ටිකක් නරක අතට හැරුණි.
HB හි කලාප ගණන පිළිබඳ වැදගත් කරුණක් නැවත වරක් සඳහන් කිරීම වටී. අපගේ නඩුවේදී, අගය 64 ලෙස සඳහන් කර ඇත. ඔබ එය අඩු කර එය සමාන කරන්නේ නම්, උදාහරණයක් ලෙස, 4, පසුව කියවීමේදී වේගය 2 ගුණයකින් පහත වැටේ. හේතුව, memstore වේගයෙන් පිරෙන අතර ලිපිගොනු නිතර නිතර සේදීම සහ කියවීමේදී තවත් ගොනු සැකසීමට අවශ්ය වනු ඇත, එය HB සඳහා තරමක් සංකීර්ණ මෙහෙයුමකි. සැබෑ තත්ත්‍වයේ දී, මෙය පූර්ව බෙදීමේ සහ සංයුක්ත කිරීමේ උපාය මාර්ගයක් හරහා සිතීමෙන් ප්‍රතිකාර කළ හැක; විශේෂයෙන්ම, අපි කුණු එකතු කරන ස්වයං-ලිඛිත උපයෝගිතාවක් භාවිතා කරන අතර පසුබිමේ නිරන්තරයෙන් HFiles සම්පීඩනය කරන්නෙමු. DataStax පරීක්ෂණ සඳහා ඔවුන් වගුවකට කලාපය 1ක් පමණක් වෙන් කර තිබීම බොහෝ දුරට ඉඩ ඇත (එය නිවැරදි නොවේ) සහ මෙය ඔවුන්ගේ කියවීමේ පරීක්ෂණවලදී HB මෙතරම් පහත් වූයේ මන්දැයි තරමක් පැහැදිලි කරයි.
මෙයින් පහත මූලික නිගමන උකහා ගනු ලැබේ. පරීක්ෂා කිරීමේදී විශාල අත්වැරදීම් සිදු නොවූ බව උපකල්පනය කළහොත්, කැසැන්ඩ්රා මැටි පාද සහිත කොලොසස් මෙන් පෙනේ. වඩාත් නිවැරදිව, ලිපියේ ආරම්භයේ පින්තූරයේ මෙන් ඇය එක් කකුලක් මත සමතුලිත වන අතර, ඇය සාපේක්ෂව හොඳ ප්රතිඵල පෙන්නුම් කරයි, නමුත් එම කොන්දේසි යටතේ සටනකදී ඇය සම්පූර්ණයෙන්ම අහිමි වේ. ඒ අතරම, අපගේ දෘඪාංගවල අඩු CPU භාවිතය සැලකිල්ලට ගනිමින්, අපි එක් සත්කාරකයකට RegionServer HB දෙකක් සිටුවීමට ඉගෙන ගත් අතර එමඟින් කාර්ය සාධනය දෙගුණ කළෙමු. එම. සම්පත් භාවිතය සැලකිල්ලට ගනිමින්, CS සඳහා තත්වය වඩාත් කණගාටුදායක ය.
ඇත්ත වශයෙන්ම, මෙම පරීක්ෂණ තරමක් කෘතිම වන අතර මෙහි භාවිතා කරන ලද දත්ත ප්රමාණය සාපේක්ෂව මධ්‍යස්ථ වේ. අපි ටෙරාබයිට් වෙත මාරු වුවහොත් තත්වය වෙනස් විය හැකිය, නමුත් HB සඳහා අපට ටෙරාබයිට් පැටවිය හැකිය, CS සඳහා මෙය ගැටළු සහගත විය. එය බොහෝ විට මෙම වෙළුම් සමඟ පවා OperationTimedOutException එකක් විසි කරයි, නමුත් ප්‍රතිචාරයක් සඳහා රැඳී සිටීමේ පරාමිතීන් පෙරනිමි ඒවාට සාපේක්ෂව කිහිප වතාවක් වැඩි කර ඇත.
සාමූහික ප්‍රයත්නයන් තුලින් අපි CS හි ඇති බාධක සොයා ගනු ඇතැයි මම බලාපොරොත්තු වන අතර අපට එය වේගවත් කළ හැකි නම්, පෝස්ට් අවසානයේ අවසාන ප්‍රති result ලය පිළිබඳ තොරතුරු අනිවාර්යයෙන්ම එක් කරමි.
UPD: සහෝදරවරුන්ගේ උපදෙස් වලට ස්තූතියි, මම කියවීම වේගවත් කිරීමට සමත් විය. විය:
මෙහෙයුම් 159 (මේස 644, ප්‍රවාහ 4, කණ්ඩායම 5).
එකතු කරන ලදි:
.withLoadBalancingPolicy(new TokenAwarePolicy(DCAwareRoundRobinPolicy.builder().build()))
ඒ වගේම මම ත්‍රෙඩ් ගණනින් සෙල්ලම් කළා. ප්රතිඵලය පහත දැක්වේ:
වගු 4 ක්, නූල් 100 ක්, කණ්ඩායම = 1 (කෑල්ලෙන් කෑල්ල): 301 ops
වගු 4 ක්, නූල් 100 ක්, කණ්ඩායම = 10: 447 ops
වගු 4 ක්, නූල් 100 ක්, කණ්ඩායම = 100: 625 ops
පසුව මම වෙනත් සුසර කිරීමේ ඉඟි යොදන්නෙමි, සම්පූර්ණ පරීක්ෂණ චක්‍රයක් ක්‍රියාත්මක කර ප්රතිඵල පෝස්ටුව අවසානයේ එක් කරන්නෙමි.
මූලාශ්රය: www.habr.com