બે યાકોઝુનાનું યુદ્ધ, અથવા કેસાન્ડ્રા વિ HBase. Sberbank ટીમનો અનુભવ

આ એક મજાક પણ નથી, એવું લાગે છે કે આ ચોક્કસ ચિત્ર આ ડેટાબેસેસના સારને સૌથી સચોટ રીતે પ્રતિબિંબિત કરે છે, અને અંતે તે સ્પષ્ટ થશે કે શા માટે:

DB-Engines રેન્કિંગ અનુસાર, બે સૌથી વધુ લોકપ્રિય NoSQL કૉલમર ડેટાબેઝ છે કેસાન્ડ્રા (ત્યારબાદ CS) અને HBase (HB).

ભાગ્યની ઇચ્છાથી, Sberbank પર અમારી ડેટા લોડિંગ મેનેજમેન્ટ ટીમ પહેલેથી જ છે લાંબા સમય પહેલા અને HB સાથે નજીકથી કામ કરે છે. આ સમય દરમિયાન, અમે તેની શક્તિઓ અને નબળાઈઓનો સારી રીતે અભ્યાસ કર્યો અને તેને કેવી રીતે રાંધવું તે શીખ્યા. જો કે, CS ના રૂપમાં વિકલ્પની હાજરીએ અમને હંમેશા શંકાઓ સાથે થોડો ત્રાસ આપવા માટે દબાણ કર્યું: શું અમે યોગ્ય પસંદગી કરી? વધુમાં, પરિણામો તુલના, DataStax દ્વારા કરવામાં આવ્યું હતું, તેઓએ જણાવ્યું હતું કે CS લગભગ એક કારમી સ્કોર સાથે HBને સરળતાથી હરાવી દે છે. બીજી બાજુ, DataStax એક રસ ધરાવતો પક્ષ છે, અને તમારે તેના માટે તેમનો શબ્દ લેવો જોઈએ નહીં. અમે પરીક્ષણ શરતો વિશેની થોડી માત્રામાં માહિતીથી પણ મૂંઝવણમાં હતા, તેથી અમે બિગડેટા NoSql ના રાજા કોણ છે તે શોધવાનું નક્કી કર્યું, અને પ્રાપ્ત પરિણામો ખૂબ જ રસપ્રદ હોવાનું બહાર આવ્યું.

જો કે, પરીક્ષણોના પરિણામો તરફ આગળ વધતા પહેલા, પર્યાવરણની ગોઠવણીના નોંધપાત્ર પાસાઓનું વર્ણન કરવું જરૂરી છે. હકીકત એ છે કે CS નો ઉપયોગ એવા મોડમાં થઈ શકે છે જે ડેટાને નુકશાનની મંજૂરી આપે છે. તે. આ ત્યારે થાય છે જ્યારે કોઈ ચોક્કસ કીના ડેટા માટે માત્ર એક સર્વર (નોડ) જવાબદાર હોય છે, અને જો કોઈ કારણોસર તે નિષ્ફળ જાય છે, તો આ કીનું મૂલ્ય ખોવાઈ જશે. ઘણા કાર્યો માટે આ મહત્વપૂર્ણ નથી, પરંતુ બેંકિંગ ક્ષેત્ર માટે આ નિયમને બદલે અપવાદ છે. અમારા કિસ્સામાં, વિશ્વસનીય સ્ટોરેજ માટે ડેટાની ઘણી નકલો હોવી મહત્વપૂર્ણ છે.

તેથી, ટ્રિપલ રિપ્લિકેશન મોડમાં માત્ર CS ઓપરેટિંગ મોડને ધ્યાનમાં લેવામાં આવ્યું હતું, એટલે કે. કેસસ્પેસની રચના નીચેના પરિમાણો સાથે હાથ ધરવામાં આવી હતી:

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 સમાન સિદ્ધાંત પર કામ કરે છે, એટલે કે. આવી સરખામણી વધુ ન્યાયી હશે.

એ નોંધવું જોઇએ કે ડેટાસ્ટેક્સે તેમના અભ્યાસમાં વિપરીત કર્યું, તેઓએ 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: સાચું
hinted_handoff_throttle_in_kb: 1024
મહત્તમ_સંકેતો_ડિલિવરી_થ્રેડ્સ: 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
પ્રમાણકર્તા: AllowAllAuthenticator
અધિકૃતકર્તા: AllowAllAuthorizer
રોલ_મેનેજર: CassandraRoleManager
ભૂમિકાઓ_માન્યતા_માં_એમએસ: 2000
permissions_validity_in_ms: 2000
credentials_validity_in_ms: 2000
પાર્ટીશનર: org.apache.cassandra.dht.Murmur3Partitioner
data_file_directories:
- /data1/cassandra/data # દરેક dataN ડિરેક્ટરી એક અલગ ડિસ્ક છે
- /ડેટા2/કેસાન્ડ્રા/ડેટા
- /ડેટા3/કેસાન્ડ્રા/ડેટા
- /ડેટા4/કેસાન્ડ્રા/ડેટા
- /ડેટા5/કેસાન્ડ્રા/ડેટા
- /ડેટા6/કેસાન્ડ્રા/ડેટા
- /ડેટા7/કેસાન્ડ્રા/ડેટા
- /ડેટા8/કેસાન્ડ્રા/ડેટા
commitlog_directory: /data9/cassandra/commitlog
cdc_enabled: false
disk_failure_policy: રોકો
પ્રતિબદ્ધ_નિષ્ફળતા_નીતિ: રોકો
તૈયાર_સ્ટેટમેન્ટ્સ_કેશ_સાઇઝ_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_period_in_ms: 10000
કમીટલોગ_સેગમેન્ટ_સાઇઝ_ઇન_એમબી: 32
બીજ પ્રદાતા:
- વર્ગ_નામ: org.apache.cassandra.locator.SimpleSeedProvider
પરિમાણો:
- બીજ: "*,*"
concurrent_reads: 256 # 64 પ્રયાસ કર્યો - કોઈ તફાવત જોવા મળ્યો નથી
સહવર્તી_લેખન: 256 # 64 પ્રયાસ કર્યો - કોઈ તફાવત જોવા મળ્યો નથી
concurrent_counter_writes: 256 # 64 પ્રયાસ કર્યો - કોઈ તફાવત જોવા મળ્યો નથી
સમવર્તી_મટીરીયલાઇઝ્ડ_વ્યુ_રાઇટ્સ: 32
memtable_heap_space_in_mb: 2048 # એ 16 GB નો પ્રયાસ કર્યો - તે ધીમું હતું
memtable_allocation_type: heap_buffers
index_summary_capacity_in_mb:
index_summary_resize_interval_in_minutes: 60
trickle_fsync: ખોટા
trickle_fsync_interval_in_kb: 10240
સ્ટોરેજ_પોર્ટ: 7000
ssl_storage_port: 7001
સાંભળો_સરનામું: *
બ્રોડકાસ્ટ_સરનામું: *
સાંભળો_પર_પ્રસારણ_સરનામું: સાચું
internode_authenticator: org.apache.cassandra.auth.AllowAllInternodeAuthenticator
શરૂઆત_મૂળ_પરિવહન: સાચું
મૂળ_ટ્રાન્સપોર્ટ_પોર્ટ: 9042
start_rpc: સાચું
rpc_સરનામું: *
rpc_port: 9160
rpc_keepalive: સાચું
rpc_server_type: સમન્વયન
thrift_framed_transport_size_in_mb: 15
incremental_backups: false
snapshot_before_compaction: false
auto_snapshot: true
column_index_size_in_kb: 64
column_index_cache_size_in_kb: 2
સમવર્તી_કોમ્પેક્ટર્સ: 4
કોમ્પેક્શન_થ્રુપુટ_mb_per_sec: 1600
sstable_preemptive_open_interval_in_mb: 50
રીડ_રિક્વેસ્ટ_ટાઇમઆઉટ_માં_એમએસ: 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
સ્લો_ક્વેરી_લોગ_ટાઇમઆઉટ_ઇન_એમએસ: 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
સર્વર_એન્ક્રિપ્શન_વિકલ્પો:
internode_encryption: કોઈ નહીં
ક્લાયંટ_એન્ક્રિપ્શન_વિકલ્પો:
સક્ષમ: ખોટું
ઇન્ટરનોડ_કોમ્પ્રેશન: ડીસી
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
પારદર્શક_ડેટા_એન્ક્રિપ્શન_વિકલ્પો:
સક્ષમ: ખોટું
ટોમ્બસ્ટોન_વોર્ન_થ્રેશોલ્ડ: 1000
ટોમ્બસ્ટોન_ફેલ્યોર_થ્રેશોલ્ડ: 100000
batch_size_warn_threshold_in_kb: 200
batch_size_fail_threshold_in_kb: 250
unlogged_batch_across_partitions_warn_threshold: 10
કોમ્પેક્શન_મોટા_પાર્ટીશન_ચેતવણી_થ્રેશોલ્ડ_એમબી: 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:+CMSparallelRemark સક્ષમ
-XX:સર્વાઈવર રેશિયો=8
-XX:MaxTenuringThreshold=1
-XX:CMSIinitiating OccupancyFraction=75
-XX:+UseCMSI માત્ર ઓક્યુપન્સી શરૂ કરો
-XX:CMSWaitDuration=10000
-XX:+CMSparallelInitialMarkEnabled
-XX:+CMSEdenChunksRecordAlways
-XX:+CMSCક્લાસ અનલોડિંગ સક્ષમ

16Gb jvm.options મેમરી ફાળવવામાં આવી હતી (અમે 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 વર્ગમાં અમે મેટ્રિક્સ રિજનને બાકાત રાખ્યું હતું જે GC તરફ દોરી જાય છે જ્યારે RegionServer પર પ્રદેશોની સંખ્યા 1000 કરતાં વધુ હતી)

નોન-ડિફોલ્ટ HBase પરિમાણોzookeeper.session.timeout: 120000
hbase.rpc.ટાઇમઆઉટ: 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.compactionThreshold: 5
hbase.hstore.blockingStoreFiles: 200
hbase.hregion.majorcompaction: 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 માટે જાવા રૂપરેખાંકન વિકલ્પો:
-XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSIinitiatingOccupancyFraction=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 થ્રીફ્ટ સર્વર મહત્તમ લોગ ફાઇલ બેકઅપ્સ: 5
માસ્ટર મેક્સ લોગ સાઈઝ: 100 MiB
માસ્ટર મેક્સિમમ લોગ ફાઇલ બેકઅપ્સ: 5
પ્રદેશ સર્વર મહત્તમ લોગ કદ: 100 MiB
RegionServer મહત્તમ લોગ ફાઇલ બેકઅપ્સ: 5
HBase એક્ટિવ માસ્ટર ડિટેક્શન વિન્ડો: 4 મિનિટ
dfs.client.hedged.read.threadpool.size: 40
dfs.client.hedged.read.threshold.millis: 10 મિલિસેકન્ડ(ઓ)
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 સર્વર ડિફોલ્ટ જૂથ: 3 GiB
HBase થ્રીફ્ટ સર્વર ડિફોલ્ટ જૂથ: 3 GiB
બાઇટ્સમાં HBase માસ્ટરનું જાવા હીપનું કદ: 16 GiB
બાઈટમાં HBase RegionServerનું જાવા હીપનું કદ: 32 GiB

+ZooKeeper
maxClientCnxns: 601
maxSessionTimeout: 120000
કોષ્ટકો બનાવવી:
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'}

અહીં એક મહત્વનો મુદ્દો છે - ડેટાસ્ટેક્સ વર્ણન એ નથી કહેતું કે HB કોષ્ટકો બનાવવા માટે કેટલા પ્રદેશોનો ઉપયોગ કરવામાં આવ્યો હતો, જો કે આ મોટા વોલ્યુમો માટે મહત્વપૂર્ણ છે. તેથી, પરીક્ષણો માટે, જથ્થો = 64 પસંદ કરવામાં આવ્યો હતો, જે 640 GB સુધી સ્ટોર કરવાની મંજૂરી આપે છે, એટલે કે. મધ્યમ કદનું ટેબલ.

પરીક્ષણ સમયે, HBase પાસે 22 હજાર કોષ્ટકો અને 67 હજાર પ્રદેશો હતા (જો ઉપરોક્ત પેચ માટે નહીં તો આવૃત્તિ 1.2.0 માટે આ ઘાતક સાબિત થાત).

હવે કોડ માટે. ચોક્કસ ડેટાબેઝ માટે કઈ રૂપરેખાંકનો વધુ ફાયદાકારક છે તે સ્પષ્ટ ન હોવાથી, પરીક્ષણો વિવિધ સંયોજનોમાં હાથ ધરવામાં આવ્યા હતા. તે. કેટલાક પરીક્ષણોમાં, 4 કોષ્ટકો એકસાથે લોડ કરવામાં આવ્યા હતા (બધા 4 નોડ્સ કનેક્શન માટે ઉપયોગમાં લેવાયા હતા). અન્ય પરીક્ષણોમાં અમે 8 વિવિધ કોષ્ટકો સાથે કામ કર્યું. કેટલાક કિસ્સાઓમાં, બેચનું કદ 100 હતું, અન્યમાં 200 (બેચ પરિમાણ - નીચે કોડ જુઓ). મૂલ્ય માટે ડેટાનું કદ 10 બાઇટ્સ અથવા 100 બાઇટ્સ (ડેટાસાઇઝ) છે. કુલ મળીને, 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 સેટઅપમાં કોઈ પ્રકારની અડચણ છે. જો કે, ગૂગલિંગ અને સૌથી સ્પષ્ટ પરિમાણો (જેમ કે સહવર્તી_રાઇટ્સ અથવા મેમટેબલ_હીપ_સ્પેસ_ઇન_mb) શોધવાથી વસ્તુઓની ઝડપ વધી નથી. તે જ સમયે, લોગ સ્વચ્છ છે અને કંઈપણ પર શપથ લેતા નથી.

ડેટા સમગ્ર નોડ્સ પર સમાનરૂપે વિતરિત કરવામાં આવ્યો હતો, તમામ નોડ્સના આંકડા લગભગ સમાન હતા.

એક નોડમાંથી કોષ્ટકના આંકડા આના જેવા દેખાય છેકીસ્પેસ: ks
વાંચો સંખ્યા: 9383707
વિલંબ વાંચો: 0.04287025042448576 ms
કાઉન્ટ લખો: 15462012
લેટન્સી લખો: 0.1350068438699957 ms
બાકી ફ્લશ: 0
કોષ્ટક: t1
SSTેબલ સંખ્યા: 16
વપરાયેલ જગ્યા (લાઇવ): 148.59 MiB
વપરાયેલ જગ્યા (કુલ): 148.59 MiB
સ્નેપશોટ દ્વારા વપરાતી જગ્યા (કુલ): 0 બાઇટ્સ
વપરાયેલ ઓફ હીપ મેમરી (કુલ): 5.17 MiB
SSTable કમ્પ્રેશન રેશિયો: 0.5720989576459437
પાર્ટીશનોની સંખ્યા (અંદાજ): 3970323
સ્મરણીય કોષોની સંખ્યા: 0
મેટેબલ ડેટાનું કદ: 0 બાઇટ્સ
મેટેબલ ઓફ હીપ મેમરી વપરાય છે: 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 માટે મહત્તમ પ્રદર્શન છે, કારણ કે CS માટે મેળવેલા પરિણામો DataStax માટે મેળવેલા પરિણામો જેવા જ છે - સેકન્ડ દીઠ લગભગ હજારો ઓપરેશન્સ. વધુમાં, જો આપણે સંસાધનના ઉપયોગને જોઈએ, તો આપણે જોઈશું કે CS વધુ CPU અને ડિસ્કનો ઉપયોગ કરે છે:

આકૃતિ બંને ડેટાબેઝ માટે એક પંક્તિમાં તમામ પરીક્ષણોના રન દરમિયાન ઉપયોગ દર્શાવે છે.

HB ના શક્તિશાળી વાંચન લાભ વિશે. અહીં તમે જોઈ શકો છો કે બંને ડેટાબેઝ માટે, વાંચન દરમિયાન ડિસ્કનો ઉપયોગ અત્યંત ઓછો છે (રીડ ટેસ્ટ એ દરેક ડેટાબેઝ માટે પરીક્ષણ ચક્રનો અંતિમ ભાગ છે, ઉદાહરણ તરીકે CS માટે આ 15:20 થી 15:40 સુધી છે). HB ના કિસ્સામાં, કારણ સ્પષ્ટ છે - મોટાભાગનો ડેટા મેમરીમાં, મેમસ્ટોરમાં હેંગ થાય છે અને અમુક બ્લોકકેશમાં કેશ થાય છે. CS માટે, તે કેવી રીતે કાર્ય કરે છે તે ખૂબ સ્પષ્ટ નથી, પરંતુ ડિસ્ક રિસાયક્લિંગ પણ દૃશ્યમાન નથી, પરંતુ માત્ર કિસ્સામાં, કેશ row_cache_size_in_mb = 2048 ને સક્ષમ કરવાનો પ્રયાસ કરવામાં આવ્યો હતો અને કેશિંગ = {'keys': 'ALL', સેટ કરો. 'rows_per_partition': '2000000'}, પરંતુ તેનાથી તે થોડું ખરાબ થઈ ગયું.

એચબીમાં પ્રદેશોની સંખ્યા વિશે ફરી એકવાર એક મહત્વપૂર્ણ મુદ્દો ઉલ્લેખ કરવો પણ યોગ્ય છે. અમારા કિસ્સામાં, મૂલ્ય 64 તરીકે નિર્દિષ્ટ કરવામાં આવ્યું હતું. જો તમે તેને ઘટાડીને તેને સમાન બનાવો છો, ઉદાહરણ તરીકે, 4, તો વાંચતી વખતે, ઝડપ 2 ગણી ઘટી જાય છે. કારણ એ છે કે મેમસ્ટોર ઝડપથી ભરાશે અને ફાઇલો વધુ વખત ફ્લશ થશે અને વાંચતી વખતે, વધુ ફાઇલો પર પ્રક્રિયા કરવાની જરૂર પડશે, જે HB માટે એક જટિલ કામગીરી છે. વાસ્તવિક પરિસ્થિતિઓમાં, પ્રિસ્પ્લિટિંગ અને કોમ્પેક્ટિફિકેશન વ્યૂહરચના દ્વારા વિચારીને તેની સારવાર કરી શકાય છે; ખાસ કરીને, અમે સ્વ-લિખિત ઉપયોગિતાનો ઉપયોગ કરીએ છીએ જે કચરો એકઠો કરે છે અને પૃષ્ઠભૂમિમાં સતત HFilesને સંકુચિત કરે છે. તે તદ્દન શક્ય છે કે DataStax પરીક્ષણો માટે તેઓએ ટેબલ દીઠ માત્ર 1 પ્રદેશ ફાળવ્યો હતો (જે સાચો નથી) અને આ કંઈક અંશે સ્પષ્ટ કરશે કે શા માટે HB તેમના વાંચન પરીક્ષણોમાં આટલું ઉતરતું હતું.

આના પરથી નીચેના પ્રાથમિક તારણો કાઢવામાં આવ્યા છે. માની લઈએ કે પરીક્ષણ દરમિયાન કોઈ મોટી ભૂલો થઈ નથી, તો પછી કસાન્ડ્રા માટીના પગ સાથે કોલોસસ જેવો દેખાય છે. વધુ સ્પષ્ટ રીતે, જ્યારે તેણી એક પગ પર સંતુલન રાખે છે, જેમ કે લેખની શરૂઆતમાં ચિત્રમાં, તે પ્રમાણમાં સારા પરિણામો બતાવે છે, પરંતુ તે જ પરિસ્થિતિઓ હેઠળની લડાઈમાં તે સંપૂર્ણ રીતે હારી જાય છે. તે જ સમયે, અમારા હાર્ડવેર પર ઓછા CPU ઉપયોગને ધ્યાનમાં લેતા, અમે હોસ્ટ દીઠ બે RegionServer HB રોપવાનું શીખ્યા અને તેના કારણે કામગીરી બમણી થઈ. તે. સંસાધનોના ઉપયોગને ધ્યાનમાં લેતા, CS માટે સ્થિતિ વધુ ખેદજનક છે.

અલબત્ત, આ પરીક્ષણો તદ્દન કૃત્રિમ છે અને અહીં વપરાયેલ ડેટાનો જથ્થો પ્રમાણમાં સાધારણ છે. શક્ય છે કે જો આપણે ટેરાબાઇટ પર સ્વિચ કરીએ, તો પરિસ્થિતિ અલગ હશે, પરંતુ જ્યારે HB માટે અમે ટેરાબાઇટ લોડ કરી શકીએ છીએ, CS માટે આ સમસ્યારૂપ બન્યું. તે ઘણીવાર આ વોલ્યુમો સાથે પણ OperationTimedOutException ફેંકી દે છે, જો કે પ્રતિસાદની રાહ જોવા માટેના પરિમાણો પહેલાથી જ ડિફોલ્ટની તુલનામાં ઘણી વખત વધી ગયા હતા.

હું આશા રાખું છું કે સંયુક્ત પ્રયાસો દ્વારા અમે CS ની અડચણો શોધીશું અને જો આપણે તેને ઝડપી બનાવી શકીશું, તો પોસ્ટના અંતે હું ચોક્કસપણે અંતિમ પરિણામો વિશે માહિતી ઉમેરીશ.

યુપીડી: સાથીઓની સલાહ બદલ આભાર, હું વાંચનને ઝડપી બનાવવામાં સફળ રહ્યો. હતી:
159 ઑપ્સ (644 કોષ્ટકો, 4 સ્ટ્રીમ્સ, બેચ 5).
ઉમેરાયેલ:
.withLoadBalancingPolicy(નવી TokenAwarePolicy(DCAwareRoundRobinPolicy.builder().build()))
અને હું થ્રેડોની સંખ્યા સાથે આસપાસ રમ્યો. પરિણામ નીચે મુજબ છે:
4 કોષ્ટકો, 100 થ્રેડો, બેચ = 1 (ટુકડા દ્વારા): 301 ઓપ્સ
4 કોષ્ટકો, 100 થ્રેડો, બેચ = 10: 447 ઓપ્સ
4 કોષ્ટકો, 100 થ્રેડો, બેચ = 100: 625 ઓપ્સ

પછીથી હું અન્ય ટ્યુનિંગ ટીપ્સ લાગુ કરીશ, સંપૂર્ણ પરીક્ષણ ચક્ર ચલાવીશ અને પોસ્ટના અંતે પરિણામો ઉમેરીશ.

સોર્સ: www.habr.com