രണ്ട് യാക്കോസുന യുദ്ധം, അല്ലെങ്കിൽ കസാന്ദ്ര vs HBase. Sberbank ടീം അനുഭവം

ഇതൊരു തമാശ പോലുമല്ല, ഈ പ്രത്യേക ചിത്രം ഈ ഡാറ്റാബേസുകളുടെ സത്തയെ ഏറ്റവും കൃത്യമായി പ്രതിഫലിപ്പിക്കുന്നതായി തോന്നുന്നു, അവസാനം എന്തുകൊണ്ടെന്ന് വ്യക്തമാകും:

DB-Engines റാങ്കിംഗ് അനുസരിച്ച്, ഏറ്റവും ജനപ്രിയമായ രണ്ട് NoSQL കോളം ഡാറ്റാബേസുകൾ കസാന്ദ്ര (ഇനിമുതൽ CS), HBase (HB) എന്നിവയാണ്.

വിധിയുടെ ഇഷ്ടപ്രകാരം, Sberbank-ലെ ഞങ്ങളുടെ ഡാറ്റ ലോഡിംഗ് മാനേജ്മെന്റ് ടീം ഇതിനകം തന്നെ ഉണ്ട് വളരെ മുമ്പ് കൂടാതെ HB-യുമായി അടുത്ത് പ്രവർത്തിക്കുന്നു. ഈ സമയത്ത്, ഞങ്ങൾ അതിന്റെ ശക്തിയും ബലഹീനതയും നന്നായി പഠിക്കുകയും അത് എങ്ങനെ പാചകം ചെയ്യാമെന്ന് പഠിക്കുകയും ചെയ്തു. എന്നിരുന്നാലും, സി‌എസിന്റെ രൂപത്തിലുള്ള ഒരു ബദലിന്റെ സാന്നിധ്യം എല്ലായ്പ്പോഴും സംശയങ്ങളാൽ സ്വയം പീഡിപ്പിക്കാൻ ഞങ്ങളെ നിർബന്ധിതരാക്കി: ഞങ്ങൾ ശരിയായ തിരഞ്ഞെടുപ്പ് നടത്തിയോ? മാത്രമല്ല, ഫലങ്ങൾ താരതമ്യങ്ങൾ, DataStax നിർവഹിച്ചത്, ഏതാണ്ട് തകർപ്പൻ സ്കോർ ഉപയോഗിച്ച് CS എളുപ്പത്തിൽ HB-യെ തോൽപ്പിക്കുമെന്ന് അവർ പറഞ്ഞു. മറുവശത്ത്, DataStax ഒരു താൽപ്പര്യമുള്ള കക്ഷിയാണ്, അതിനായി നിങ്ങൾ അവരുടെ വാക്ക് എടുക്കരുത്. ടെസ്റ്റിംഗ് അവസ്ഥകളെക്കുറിച്ചുള്ള ചെറിയ അളവിലുള്ള വിവരങ്ങളാലും ഞങ്ങൾ ആശയക്കുഴപ്പത്തിലായി, അതിനാൽ BigData 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 സമാനമായ തത്വത്തിൽ പ്രവർത്തിക്കുന്നു, അതായത്. അത്തരമൊരു താരതമ്യം കൂടുതൽ ന്യായമായിരിക്കും.

DataStax അവരുടെ പഠനത്തിൽ വിപരീതമാണ് ചെയ്തത് എന്നത് ശ്രദ്ധിക്കേണ്ടതാണ്, അവർ CS, HB എന്നിവയ്‌ക്ക് RF = 1 സജ്ജമാക്കി (അവസാനത്തേതിന് HDFS ക്രമീകരണങ്ങൾ മാറ്റുന്നതിലൂടെ). ഇത് വളരെ പ്രധാനപ്പെട്ട ഒരു വശമാണ്, കാരണം ഈ കേസിൽ സിഎസ് പ്രകടനത്തെ ബാധിക്കുന്നത് വളരെ വലുതാണ്. ഉദാഹരണത്തിന്, ചുവടെയുള്ള ചിത്രം 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 തടസ്സമല്ല. എന്നിരുന്നാലും, ഇവിടെ മറ്റ് നിരവധി അപകടങ്ങളുണ്ട്, കാരണം ഞങ്ങളുടെ എച്ച്ബി പതിപ്പ് ചെറുതായി ഒത്തുകളി മാറ്റി, പരിതസ്ഥിതികൾ തികച്ചും വ്യത്യസ്തമാണ് എന്നത് ശ്രദ്ധിക്കേണ്ടതാണ്. സിഎസ് എങ്ങനെ ശരിയായി തയ്യാറാക്കണമെന്ന് എനിക്കറിയില്ല എന്നതും ശ്രദ്ധിക്കേണ്ടതാണ്, കൂടാതെ ഇത് ഉപയോഗിച്ച് പ്രവർത്തിക്കാൻ കൂടുതൽ ഫലപ്രദമായ മാർഗങ്ങളുണ്ട്, അഭിപ്രായങ്ങളിൽ ഞങ്ങൾ കണ്ടെത്തുമെന്ന് ഞാൻ പ്രതീക്ഷിക്കുന്നു. എന്നാൽ ആദ്യം കാര്യങ്ങൾ ആദ്യം.

എല്ലാ പരിശോധനകളും 4 സെർവറുകൾ അടങ്ങുന്ന ഒരു ഹാർഡ്‌വെയർ ക്ലസ്റ്ററിലാണ് നടത്തിയത്, ഓരോന്നിനും ഇനിപ്പറയുന്ന കോൺഫിഗറേഷൻ ഉണ്ട്:

CPU: Xeon E5-2680 v4 @ 2.40GHz 64 ത്രെഡുകൾ.
ഡിസ്കുകൾ: 12 കഷണങ്ങൾ SATA HDD
ജാവ പതിപ്പ്: 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_in_ms: 10000
max_hints_file_size_in_mb: 128
batchlog_replay_throttle_in_kb: 1024
ഓതന്റിക്കേറ്റർ: AllowAllAuthenticator
അധികാരി: AllowAllAuthorizer
റോൾ_മാനേജർ: CassandraRoleManager
റോളുകൾ_സാധുത_ഇൻ_എംഎസ്: 2000
അനുമതികൾ_സാധുത_ഇൻ_എംഎസ്: 2000
credentials_validity_in_ms: 2000
പാർട്ടീഷനർ: 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: false
disk_failure_policy: നിർത്തുക
കമ്മിറ്റ്_പരാജയ_നയം: നിർത്തുക
തയ്യാറായ_പ്രസ്താവനകൾ_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: ആനുകാലികം
Commitlog_sync_period_in_ms: 10000
Commitlog_segment_size_in_mb: 32
വിത്ത്_ദാതാവ്:
- class_name: org.apache.cassandra.locator.SimpleSeedProvider
പാരാമീറ്ററുകൾ:
— വിത്തുകൾ: "*,*"
concurrent_reads: 256 # 64 പരീക്ഷിച്ചു - വ്യത്യാസമൊന്നും ശ്രദ്ധയിൽപ്പെട്ടില്ല
concurrent_writes: 256 # ശ്രമിച്ചു 64 - വ്യത്യാസമൊന്നും ശ്രദ്ധയിൽപ്പെട്ടില്ല
concurrent_counter_writes: 256 # ശ്രമിച്ചു 64 - വ്യത്യാസമൊന്നും ശ്രദ്ധയിൽപ്പെട്ടില്ല
concurrent_materialized_view_writes: 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
start_native_transport: true
നേറ്റീവ്_ട്രാൻസ്പോർട്ട്_പോർട്ട്: 9042
start_rpc: true
rpc_വിലാസം: *
rpc_port: 9160
rpc_keepalive: true
rpc_server_type: സമന്വയം
thrift_framed_transport_size_in_mb: 15
incremental_backups: false
സ്നാപ്പ്ഷോട്ട്_ബിഫോർ_കോംപാക്ഷൻ: തെറ്റ്
auto_snapshot: true
column_index_size_in_kb: 64
column_index_cache_size_in_kb: 2
concurrent_compactors: 4
കോംപാക്ഷൻ_ത്രൂപുട്ട്_mb_per_sec: 1600
sstable_preemptive_open_interval_in_mb: 50
read_request_timeout_in_ms: 100000
റേഞ്ച്_ക്വസ്റ്റ്_ടൈംഔട്ട്_ഇൻ_എംഎസ്: 200000
റൈറ്റ്_ക്വസ്റ്റ്_ടൈംഔട്ട്_ഇൻ_എംഎസ്: 40000
counter_write_request_timeout_in_ms: 100000
cas_contention_timeout_in_ms: 20000
60000
റിക്വസ്റ്റ്_ടൈംഔട്ട്_ഇൻ_എംഎസ്: 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: ഒന്നുമില്ല
client_encryption_options:
പ്രവർത്തനക്ഷമമാക്കി: തെറ്റ്
ഇന്റർനോഡ്_കംപ്രഷൻ: ഡിസി
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
transparent_data_encryption_options:
പ്രവർത്തനക്ഷമമാക്കി: തെറ്റ്
ശവകുടീരം_മുന്നറിയിപ്പ്_പരിധി: 1000
ശവകുടീരം_പരാജയം_പരിധി: 100000
batch_size_warn_threshold_in_kb: 200
batch_size_fail_threshold_in_kb: 250
unlogged_batch_across_partitions_warn_threshold: 10
compact_large_partition_warning_threshold_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:+CMSSparallelRemark പ്രവർത്തനക്ഷമമാക്കി
-XX:സർവൈവർ റേഷ്യോ=8
-XX:MaxTenuring Threshold=1
-XX:CMSഇനിഷ്യേറ്റിംഗ് ഒക്യുപൻസി ഫ്രാക്ഷൻ=75
-XX:+ഉപയോഗിക്കുകCMSആരംഭിക്കുന്നത് ഒക്യുപൻസി മാത്രം
-XX:CMSWaitDuration=10000
-XX:+CMSSparallelInitialMarkEnabled
-XX:+CMSEdenChunksRecordAlways
-XX:+CMSClassUnloadingEnabled

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.compaction ത്രെഷോൾഡ്: 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:CMSഇനിഷ്യേറ്റിംഗ് ഒക്യുപൻസി ഫ്രാക്ഷൻ=70 -XX:+CMSസമാന്തരറിമാർക്ക് പ്രവർത്തനക്ഷമമാക്കി -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 എംഐബി
മാസ്റ്റർ പരമാവധി ലോഗ് ഫയൽ ബാക്കപ്പുകൾ: 5
RegionServer പരമാവധി ലോഗ് വലുപ്പം: 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 Master-ന്റെ Java Heap Size: 16 GiB
HBase RegionServer-ന്റെ Java Heap Size Size: 32 GiB

+ZooKeeper
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'}

ഇവിടെ ഒരു പ്രധാന കാര്യം ഉണ്ട് - എച്ച്ബി ടേബിളുകൾ സൃഷ്ടിക്കാൻ എത്ര പ്രദേശങ്ങൾ ഉപയോഗിച്ചുവെന്ന് ഡാറ്റാസ്റ്റാക്സ് വിവരണം പറയുന്നില്ല, എന്നിരുന്നാലും ഇത് വലിയ വോള്യങ്ങൾക്ക് നിർണായകമാണ്. അതിനാൽ, പരിശോധനകൾക്കായി, അളവ് = 64 തിരഞ്ഞെടുത്തു, ഇത് 640 GB വരെ സംഭരിക്കാൻ അനുവദിക്കുന്നു, അതായത്. ഇടത്തരം വലിപ്പമുള്ള പട്ടിക.

ടെസ്റ്റ് സമയത്ത്, 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);
    }
}

അതനുസരിച്ച്, എച്ച്ബിക്ക് സമാനമായ പ്രവർത്തനം നൽകി:

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);
    }
}

എച്ച്ബിയിൽ ക്ലയന്റ് ഡാറ്റയുടെ ഏകീകൃത വിതരണം ശ്രദ്ധിക്കേണ്ടതിനാൽ, പ്രധാന ഉപ്പിടൽ പ്രവർത്തനം ഇതുപോലെയാണ്:

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 ബൈറ്റുകൾ
മെംറ്റബിൾ ഓഫ് ഹീപ്പ് മെമ്മറി ഉപയോഗിച്ചു: 0 ബൈറ്റുകൾ
മെംടേബിൾ സ്വിച്ച് എണ്ണം: 5
പ്രാദേശിക വായനയുടെ എണ്ണം: 2346045
പ്രാദേശിക വായന ലേറ്റൻസി: NaN ms
പ്രാദേശിക എഴുത്ത് എണ്ണം: 3865503
പ്രാദേശിക എഴുത്ത് ലേറ്റൻസി: NaN ms
ശേഷിക്കുന്ന ഫ്ലഷുകൾ: 0
നന്നാക്കിയ ശതമാനം: 0.0
ബ്ലൂം ഫിൽട്ടർ തെറ്റായ പോസിറ്റീവ്: 25
ബ്ലൂം ഫിൽട്ടർ തെറ്റായ അനുപാതം: 0.00000
ഉപയോഗിച്ച ബ്ലൂം ഫിൽട്ടർ സ്പേസ്: 4.57 MiB
ബ്ലൂം ഫിൽട്ടർ ഓഫ് ഹീപ്പ് മെമ്മറി ഉപയോഗിച്ചു: 4.57 MiB
ഉപയോഗിച്ച ഹീപ്പ് മെമ്മറിയുടെ സൂചിക സംഗ്രഹം: 590.02 കിബി
കംപ്രഷൻ മെറ്റാഡാറ്റ ഓഫ് ഹീപ്പ് മെമ്മറി ഉപയോഗിച്ചു: 19.45 കിബി
ചുരുക്കിയ പാർട്ടീഷൻ ഏറ്റവും കുറഞ്ഞ ബൈറ്റുകൾ: 36
ഒതുക്കിയ പാർട്ടീഷൻ പരമാവധി ബൈറ്റുകൾ: 42
കോംപാക്റ്റ് ചെയ്ത പാർട്ടീഷൻ ശരാശരി ബൈറ്റുകൾ: 42
ഓരോ സ്ലൈസിലും ശരാശരി ലൈവ് സെല്ലുകൾ (അവസാന അഞ്ച് മിനിറ്റ്): NaN
ഒരു സ്ലൈസിന് പരമാവധി ലൈവ് സെല്ലുകൾ (അവസാന അഞ്ച് മിനിറ്റ്): 0
ഓരോ സ്ലൈസിലും ശരാശരി ശവകുടീരങ്ങൾ (അവസാന അഞ്ച് മിനിറ്റ്): NaN
ഒരു സ്ലൈസിന് പരമാവധി ശവകുടീരങ്ങൾ (അവസാന അഞ്ച് മിനിറ്റ്): 0
ഉപേക്ഷിച്ച മ്യൂട്ടേഷനുകൾ: 0 ബൈറ്റുകൾ

ബാച്ചിന്റെ വലുപ്പം കുറയ്ക്കാനുള്ള ശ്രമം (അത് വ്യക്തിഗതമായി അയച്ചാലും) ഫലമുണ്ടായില്ല, അത് കൂടുതൽ വഷളായി. വാസ്തവത്തിൽ ഇത് CS-ന്റെ പരമാവധി പ്രകടനമാണ്, കാരണം CS-ന് ലഭിച്ച ഫലങ്ങൾ DataStax-ന് ലഭിച്ചതിന് സമാനമാണ് - സെക്കൻഡിൽ ലക്ഷക്കണക്കിന് പ്രവർത്തനങ്ങൾ. കൂടാതെ, ഞങ്ങൾ റിസോഴ്സ് വിനിയോഗം നോക്കുകയാണെങ്കിൽ, സിഎസ് കൂടുതൽ സിപിയുവും ഡിസ്കുകളും ഉപയോഗിക്കുന്നതായി കാണാം:

രണ്ട് ഡാറ്റാബേസുകൾക്കുമായി ഒരു നിരയിലുള്ള എല്ലാ ടെസ്റ്റുകളുടെയും റൺ സമയത്ത് ഉപയോഗത്തെ ചിത്രം കാണിക്കുന്നു.

എച്ച്ബിയുടെ ശക്തമായ വായനാ നേട്ടത്തെക്കുറിച്ച്. രണ്ട് ഡാറ്റാബേസുകളിലും, റീഡിംഗ് സമയത്ത് ഡിസ്ക് ഉപയോഗം വളരെ കുറവാണെന്ന് ഇവിടെ നിങ്ങൾക്ക് കാണാൻ കഴിയും (ഓരോ ഡാറ്റാബേസിനും ടെസ്റ്റിംഗ് സൈക്കിളിന്റെ അവസാന ഭാഗമാണ് റീഡ് ടെസ്റ്റുകൾ, ഉദാഹരണത്തിന് CS-ന് ഇത് 15:20 മുതൽ 15:40 വരെയാണ്). എച്ച്ബിയുടെ കാര്യത്തിൽ, കാരണം വ്യക്തമാണ് - മിക്ക ഡാറ്റയും മെമ്മറിയിലും മെംസ്റ്റോറിലും തൂങ്ങിക്കിടക്കുന്നു, ചിലത് ബ്ലോക്ക് കാഷെയിൽ കാഷെ ചെയ്യുന്നു. CS-നെ സംബന്ധിച്ചിടത്തോളം, ഇത് എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്നത് വളരെ വ്യക്തമല്ല, പക്ഷേ ഡിസ്ക് റീസൈക്ലിംഗും ദൃശ്യമല്ല, പക്ഷേ, കാഷെ row_cache_size_in_mb = 2048 പ്രവർത്തനക്ഷമമാക്കാനും കാഷിംഗ് = {'കീകൾ' സജ്ജമാക്കാനും: 'എല്ലാം', 'rows_per_partition': ' 2000000'}, പക്ഷേ അത് കുറച്ചുകൂടി മോശമാക്കി.

എച്ച്ബിയിലെ പ്രദേശങ്ങളുടെ എണ്ണത്തെക്കുറിച്ചുള്ള ഒരു പ്രധാന കാര്യം ഒരിക്കൽ കൂടി പരാമർശിക്കേണ്ടതാണ്. ഞങ്ങളുടെ കാര്യത്തിൽ, മൂല്യം 64 ആയി സൂചിപ്പിച്ചിരിക്കുന്നു. നിങ്ങൾ അത് കുറയ്ക്കുകയും തുല്യമാക്കുകയും ചെയ്താൽ, ഉദാഹരണത്തിന്, 4, തുടർന്ന് വായിക്കുമ്പോൾ, വേഗത 2 മടങ്ങ് കുറയുന്നു. കാരണം, മെംസ്റ്റോർ വേഗത്തിൽ നിറയുകയും ഫയലുകൾ കൂടുതൽ തവണ ഫ്ലഷ് ചെയ്യുകയും ചെയ്യും, വായിക്കുമ്പോൾ, കൂടുതൽ ഫയലുകൾ പ്രോസസ്സ് ചെയ്യേണ്ടതുണ്ട്, ഇത് എച്ച്ബിക്ക് വളരെ സങ്കീർണ്ണമായ പ്രവർത്തനമാണ്. യഥാർത്ഥ അവസ്ഥയിൽ, മുൻകൂർ വിഭജനവും കോംപാക്റ്റിഫിക്കേഷൻ തന്ത്രവും ഉപയോഗിച്ച് ഇത് കൈകാര്യം ചെയ്യാൻ കഴിയും; പ്രത്യേകിച്ചും, മാലിന്യങ്ങൾ ശേഖരിക്കുകയും പശ്ചാത്തലത്തിൽ നിരന്തരം HFiles കംപ്രസ് ചെയ്യുകയും ചെയ്യുന്ന ഒരു സ്വയം-എഴുതപ്പെട്ട യൂട്ടിലിറ്റി ഞങ്ങൾ ഉപയോഗിക്കുന്നു. DataStax ടെസ്റ്റുകൾക്കായി അവർ ഒരു ടേബിളിന് 1 പ്രദേശം മാത്രമേ അനുവദിച്ചിട്ടുള്ളൂ (അത് ശരിയല്ല) അവരുടെ വായനാ പരിശോധനകളിൽ എച്ച്ബി വളരെ താഴ്ന്നത് എന്തുകൊണ്ടാണെന്ന് ഇത് ഒരു പരിധിവരെ വ്യക്തമാക്കും.

ഇതിൽ നിന്നാണ് താഴെ പറയുന്ന പ്രാഥമിക നിഗമനങ്ങൾ. പരിശോധനയ്ക്കിടെ വലിയ പിഴവുകളൊന്നും സംഭവിച്ചിട്ടില്ലെന്ന് കരുതിയാൽ, കസാന്ദ്രയ്ക്ക് കാലുകൾ കളിമണ്ണുള്ള ഒരു ഭീമാകാരമായ പോലെ തോന്നുന്നു. കൂടുതൽ കൃത്യമായി പറഞ്ഞാൽ, ലേഖനത്തിന്റെ തുടക്കത്തിലെ ചിത്രത്തിലെന്നപോലെ അവൾ ഒരു കാലിൽ സന്തുലിതമാക്കുമ്പോൾ, അവൾ താരതമ്യേന നല്ല ഫലങ്ങൾ കാണിക്കുന്നു, എന്നാൽ അതേ സാഹചര്യങ്ങളിൽ ഒരു പോരാട്ടത്തിൽ അവൾ പൂർണ്ണമായും പരാജയപ്പെടുന്നു. അതേ സമയം, ഞങ്ങളുടെ ഹാർഡ്‌വെയറിലെ കുറഞ്ഞ സിപിയു ഉപയോഗം കണക്കിലെടുത്ത്, ഒരു ഹോസ്റ്റിന് രണ്ട് റീജിയൺസെർവർ എച്ച്ബികൾ നട്ടുപിടിപ്പിക്കാൻ ഞങ്ങൾ പഠിച്ചു, അതുവഴി പ്രകടനം ഇരട്ടിയാക്കി. ആ. വിഭവങ്ങളുടെ വിനിയോഗം കണക്കിലെടുക്കുമ്പോൾ, സിഎസിന്റെ സ്ഥിതി കൂടുതൽ പരിതാപകരമാണ്.

തീർച്ചയായും, ഈ പരിശോധനകൾ തികച്ചും സിന്തറ്റിക് ആണ്, ഇവിടെ ഉപയോഗിച്ച ഡാറ്റയുടെ അളവ് താരതമ്യേന മിതമാണ്. ഞങ്ങൾ ടെറാബൈറ്റിലേക്ക് മാറിയാൽ, സാഹചര്യം വ്യത്യസ്തമാകാൻ സാധ്യതയുണ്ട്, പക്ഷേ എച്ച്ബിക്ക് നമുക്ക് ടെറാബൈറ്റുകൾ ലോഡ് ചെയ്യാൻ കഴിയും, സിഎസിന് ഇത് പ്രശ്നമായി മാറി. ഈ വോള്യങ്ങളിൽ പോലും ഇത് പലപ്പോഴും ഒരു 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