இது ஒரு நகைச்சுவை கூட அல்ல, இந்த குறிப்பிட்ட படம் இந்த தரவுத்தளங்களின் சாரத்தை மிகவும் துல்லியமாக பிரதிபலிக்கிறது என்று தோன்றுகிறது, இறுதியில் அது ஏன் தெளிவாக இருக்கும்:
DB-Engines தரவரிசையின் படி, இரண்டு மிகவும் பிரபலமான NoSQL நிரல் தரவுத்தளங்கள் கசாண்ட்ரா (இனி CS) மற்றும் HBase (HB) ஆகும்.
விதியின் விருப்பப்படி, Sberbank இல் உள்ள எங்கள் தரவு ஏற்றுதல் மேலாண்மை குழு ஏற்கனவே உள்ளது மற்றும் HB உடன் நெருக்கமாக வேலை செய்கிறது. இந்த நேரத்தில், நாங்கள் அதன் பலம் மற்றும் பலவீனங்களை நன்கு ஆய்வு செய்து அதை எப்படி சமைக்க வேண்டும் என்று கற்றுக்கொண்டோம். எவ்வாறாயினும், சிஎஸ் வடிவத்தில் ஒரு மாற்றீட்டின் இருப்பு எப்போதும் சந்தேகங்களுடன் நம்மைத் துன்புறுத்தும்படி கட்டாயப்படுத்தியது: நாங்கள் சரியான தேர்வு செய்தோமா? மேலும், முடிவுகள் , DataStax ஆல் நிகழ்த்தப்பட்டது, CS எளிதாக HB ஐ கிட்டத்தட்ட நொறுக்கும் மதிப்பெண்ணுடன் தோற்கடிக்கிறது என்று கூறினார்கள். மறுபுறம், DataStax ஒரு ஆர்வமுள்ள தரப்பினர், அதற்காக அவர்களின் வார்த்தையை நீங்கள் எடுத்துக்கொள்ளக்கூடாது. சோதனை நிலைமைகள் குறித்த சிறிய அளவிலான தகவல்களால் நாங்கள் குழப்பமடைந்தோம், எனவே BigData NoSql இன் ராஜா யார் என்பதை நாங்கள் சொந்தமாக கண்டுபிடிக்க முடிவு செய்தோம், மேலும் பெறப்பட்ட முடிவுகள் மிகவும் சுவாரஸ்யமாக மாறியது.
இருப்பினும், நிகழ்த்தப்பட்ட சோதனைகளின் முடிவுகளுக்குச் செல்வதற்கு முன், சுற்றுச்சூழல் கட்டமைப்புகளின் குறிப்பிடத்தக்க அம்சங்களை விவரிக்க வேண்டியது அவசியம். உண்மை என்னவென்றால், தரவு இழப்பை அனுமதிக்கும் பயன்முறையில் சிஎஸ் பயன்படுத்தப்படலாம். அந்த. ஒரு குறிப்பிட்ட விசையின் தரவுக்கு ஒரே ஒரு சேவையகம் (முனை) மட்டுமே பொறுப்பாகும் போது, சில காரணங்களால் அது தோல்வியுற்றால், இந்த விசையின் மதிப்பு இழக்கப்படும். பல பணிகளுக்கு இது முக்கியமானதல்ல, ஆனால் வங்கித் துறைக்கு இது விதியை விட விதிவிலக்காகும். எங்கள் விஷயத்தில், நம்பகமான சேமிப்பகத்திற்கான தரவின் பல நகல்களை வைத்திருப்பது முக்கியம்.
எனவே, டிரிபிள் ரெப்ளிகேஷன் முறையில் சிஎஸ் இயக்க முறை மட்டுமே கருதப்பட்டது, அதாவது. கேஸ்பேஸ் உருவாக்கம் பின்வரும் அளவுருக்கள் மூலம் மேற்கொள்ளப்பட்டது:
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 இடையூறு அல்ல. இருப்பினும், இங்கே வேறு பல ஆபத்துகள் உள்ளன, ஏனென்றால் HB இன் எங்கள் பதிப்பு சற்று இணைக்கப்பட்டு மாற்றப்பட்டது என்பதை கவனத்தில் கொள்ள வேண்டும், சூழல்கள் முற்றிலும் வேறுபட்டவை போன்றவை. CS ஐ எவ்வாறு சரியாக தயாரிப்பது என்று எனக்குத் தெரியவில்லை என்பதும் குறிப்பிடத்தக்கது, மேலும் அதனுடன் வேலை செய்ய இன்னும் சில பயனுள்ள வழிகள் உள்ளன, மேலும் கருத்துகளில் கண்டுபிடிப்போம் என்று நம்புகிறேன். ஆனால் முதல் விஷயங்கள் முதலில்.
அனைத்து சோதனைகளும் 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
authorizer: AllowAllAuthorizer
ரோல்_மேனேஜர்: கசாண்ட்ரா ரோல்மேனேஜர்
பாத்திரங்கள்_செல்லுபடி_இன்_எம்எஸ்: 2000
permissions_validity_in_ms: 2000
நற்சான்றிதழ்கள்_செல்லுபடியாகும்_இன்_எம்எஸ்: 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
கமிட்லாக்_டைரக்டரி: /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
உறுதிப்_பிரிவு_அளவு_mb: 32
விதை_வழங்குபவர்:
- வகுப்பு_பெயர்: org.apache.cassandra.locator.SimpleSeedProvider
அளவுருக்கள்:
- விதைகள்: "*,*"
concurrent_reads: 256 # முயற்சி 64 - எந்த வித்தியாசமும் கவனிக்கப்படவில்லை
ஒரே நேரத்தில்_எழுதுகிறது: 256 # முயற்சி 64 - எந்த வித்தியாசமும் கவனிக்கப்படவில்லை
concurrent_counter_writes: 256 # முயற்சி 64 - எந்த வித்தியாசமும் கவனிக்கப்படவில்லை
concurrent_materialized_view_writes: 32
memtable_heap_space_in_mb: 2048 # 16 ஜிபி முயற்சி - அது மெதுவாக இருந்தது
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_address: *
rpc_port: 9160
rpc_keepalive: உண்மை
rpc_server_type: ஒத்திசைவு
thrift_framed_transport_size_in_mb: 15
incremental_backups: false
snapshot_before_companction: false
auto_snapshot: உண்மை
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
படிக்க_கோரிக்கை_நேரம்_இன்_எம்எஸ்: 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
குறுக்கு_முனை_நேரம்: தவறு
endpoint_snitch: GossipingPropertyFileSnitch
dynamic_snitch_update_interval_in_ms: 100
dynamic_snitch_reset_interval_in_ms: 600000
dynamic_snitch_badness_threshold: 0.1
கோரிக்கை_திட்டமிடல்: org.apache.cassandra.scheduler.NoScheduler
server_encryption_options:
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
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
சுருக்க_பெரிய_பகிர்வு_எச்சரிக்கை_வாசல்_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:SurvivorRatio=8
-XX:MaxTenuringThreshold=1
-XX:சிஎம்எஸ்இனிஷியேட்டிங் ஆக்கிரமிப்பு பின்னம்=75
-XX:+பயன்படுத்தவும்CMSஆக்கிரமிப்பு மட்டுமே
-XX:CMSWaitDuration=10000
-XX:+CMSSparallelInitialMarkEnabled
-XX:+CMSEdenChunksRecordAlways
-XX:+CMSClassUnloadingEnabled
16Gb jvm.options நினைவகம் ஒதுக்கப்பட்டது (நாங்களும் 32 ஜிபி முயற்சித்தோம், எந்த வித்தியாசமும் இல்லை).
அட்டவணைகள் கட்டளையுடன் உருவாக்கப்பட்டன:
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 வகுப்பில், RegionServer இல் பிராந்தியங்களின் எண்ணிக்கை 1000க்கும் அதிகமாக இருந்தபோது GC க்கு வழிவகுத்த MetricsRegion ஐ நாங்கள் விலக்கினோம்)
இயல்புநிலை அல்லாத 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. எண்ணிக்கை: 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.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:+CMSSparallelRemarkEnabled -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
RegionServer அதிகபட்ச பதிவு அளவு: 100 MiB
RegionServer அதிகபட்ச பதிவு கோப்பு காப்புப்பிரதிகள்: 5
HBase ஆக்டிவ் மாஸ்டர் கண்டறிதல் சாளரம்: 4 நிமிடம்(கள்)
dfs.client.hedged.read.threadpool. அளவு: 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. அளவு: 20
பகுதி நகர்த்தும் நூல்கள்: 6
பைட்டுகளில் கிளையண்ட் ஜாவா ஹீப் அளவு: 1 ஜிபி
HBase REST சேவையக இயல்புநிலை குழு: 3 GiB
HBase Thrift Server இயல்புநிலை குழு: 3 GiB
பைட்டுகளில் HBase Master இன் Java Heap Size: 16 GiB
பைட்டுகளில் உள்ள HBase RegionServer இன் Java Heap Size: 32 GiB
+ மிருகக்காட்சிசாலை காப்பாளர்
maxClientCnxns: 601
அதிகபட்ச அமர்வு நேரம்: 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 ஜிபி வரை சேமிக்க அனுமதிக்கிறது, அதாவது. நடுத்தர அளவு அட்டவணை.
சோதனையின் போது, 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 memory பயன்படுத்தப்பட்டது: 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 அதிக CPU மற்றும் வட்டுகளைப் பயன்படுத்துவதைக் காண்போம்:
இரண்டு தரவுத்தளங்களுக்கும் ஒரு வரிசையில் அனைத்து சோதனைகளின் போது பயன்படுத்தப்படும் பயன்பாட்டை படம் காட்டுகிறது.
HB இன் சக்திவாய்ந்த வாசிப்பு நன்மை குறித்து. இரண்டு தரவுத்தளங்களுக்கும், வாசிப்பின் போது வட்டு உபயோகம் மிகக் குறைவாக இருப்பதை இங்கே காணலாம் (ஒவ்வொரு தரவுத்தளத்திற்கும் சோதனைச் சுழற்சியின் இறுதிப் பகுதி வாசிப்புச் சோதனைகள், உதாரணமாக CS க்கு இது 15:20 முதல் 15:40 வரை). HB ஐப் பொறுத்தவரை, காரணம் தெளிவாக உள்ளது - பெரும்பாலான தரவு நினைவகத்தில், மெம்ஸ்டோரில் தொங்குகிறது, மேலும் சில பிளாக்கேச்சில் தற்காலிகமாக சேமிக்கப்படும். CS ஐப் பொறுத்தவரை, இது எவ்வாறு இயங்குகிறது என்பது தெளிவாகத் தெரியவில்லை, ஆனால் வட்டு மறுசுழற்சியும் தெரியவில்லை, ஆனால் ஒரு வேளை, கேச் row_cache_size_in_mb = 2048 மற்றும் கேச்சிங் = {'விசைகள்': 'அனைத்து' என அமைக்க முயற்சி செய்யப்பட்டது. 'row_per_partition': ' 2000000'}, ஆனால் அது இன்னும் கொஞ்சம் மோசமாகிவிட்டது.
HB இல் உள்ள பகுதிகளின் எண்ணிக்கையைப் பற்றிய ஒரு முக்கியமான விஷயத்தை மீண்டும் குறிப்பிடுவது மதிப்பு. எங்கள் விஷயத்தில், மதிப்பு 64 என குறிப்பிடப்பட்டுள்ளது. நீங்கள் அதைக் குறைத்து, எடுத்துக்காட்டாக, 4 க்கு சமமாகச் செய்தால், படிக்கும் போது, வேகம் 2 மடங்கு குறைகிறது. காரணம், மெம்ஸ்டோர் வேகமாக நிரம்பும் மற்றும் கோப்புகள் அடிக்கடி சுத்தப்படுத்தப்படும் மற்றும் படிக்கும் போது, அதிகமான கோப்புகள் செயலாக்கப்பட வேண்டும், இது HB க்கு மிகவும் சிக்கலான செயல்பாடாகும். உண்மையான நிலைமைகளில், முன்பொருத்துதல் மற்றும் சுருக்குதல் மூலோபாயம் மூலம் சிந்திப்பதன் மூலம் இதைக் கையாளலாம்; குறிப்பாக, குப்பைகளைச் சேகரித்து, பின்னணியில் தொடர்ந்து HFiles ஐ அழுத்தும் சுயமாக எழுதப்பட்ட பயன்பாட்டைப் பயன்படுத்துகிறோம். DataStax சோதனைகளுக்கு அவர்கள் ஒரு அட்டவணைக்கு 1 பகுதியை மட்டுமே ஒதுக்கியிருக்கலாம் (இது சரியல்ல) மேலும் இது அவர்களின் வாசிப்பு சோதனைகளில் HB ஏன் மிகவும் தாழ்வாக இருந்தது என்பதை ஓரளவு தெளிவுபடுத்தும்.
இதிலிருந்து பின்வரும் ஆரம்ப முடிவுகள் எடுக்கப்படுகின்றன. சோதனையின் போது பெரிய தவறுகள் எதுவும் செய்யப்படவில்லை என்று கருதினால், கசாண்ட்ரா களிமண்ணுடன் ஒரு கோலோசஸ் போல் தெரிகிறது. இன்னும் துல்லியமாக, கட்டுரையின் தொடக்கத்தில் உள்ள படத்தில் உள்ளதைப் போல அவள் ஒரு காலில் சமநிலையில் இருக்கும்போது, அவள் ஒப்பீட்டளவில் நல்ல முடிவுகளைக் காட்டுகிறாள், ஆனால் அதே நிலைமைகளின் கீழ் ஒரு சண்டையில் அவள் முற்றிலும் இழக்கிறாள். அதே நேரத்தில், எங்கள் வன்பொருளில் குறைந்த CPU பயன்பாட்டைக் கணக்கில் எடுத்துக்கொண்டு, ஒரு ஹோஸ்டுக்கு இரண்டு RegionServer HBகளை நிறுவ கற்றுக்கொண்டோம், அதன் மூலம் செயல்திறனை இரட்டிப்பாக்கினோம். அந்த. வளங்களின் பயன்பாட்டை கணக்கில் எடுத்துக்கொண்டால், CS இன் நிலைமை இன்னும் மோசமானது.
நிச்சயமாக, இந்த சோதனைகள் மிகவும் செயற்கையானவை மற்றும் இங்கு பயன்படுத்தப்பட்ட தரவுகளின் அளவு ஒப்பீட்டளவில் மிதமானது. நாம் டெராபைட்டுகளுக்கு மாறினால், நிலைமை வித்தியாசமாக இருக்கும், ஆனால் HB க்கு நாம் டெராபைட்களை ஏற்றலாம், CS க்கு இது சிக்கலாக மாறியது. இந்த தொகுதிகளுடன் கூட இது பெரும்பாலும் OperationTimedOutException ஐ வீசியது, இருப்பினும் பதிலுக்காக காத்திருக்கும் அளவுருக்கள் இயல்புநிலையுடன் ஒப்பிடும்போது ஏற்கனவே பல மடங்கு அதிகரிக்கப்பட்டுள்ளன.
கூட்டு முயற்சிகளின் மூலம் CS இன் இடையூறுகளை நாம் கண்டறிந்து அதை விரைவுபடுத்த முடிந்தால், இடுகையின் முடிவில் இறுதி முடிவுகளைப் பற்றிய தகவலை நிச்சயமாகச் சேர்ப்பேன் என்று நம்புகிறேன்.
UPD: தோழர்களின் ஆலோசனைக்கு நன்றி, நான் வாசிப்பை விரைவுபடுத்த முடிந்தது. இருந்தது:
159 ஆப்ஸ் (644 அட்டவணைகள், 4 ஸ்ட்ரீம்கள், தொகுதி 5).
சேர்த்தவர்:
.withLoadBalancingPolicy(புதிய TokenAwarePolicy(DCAwareRoundRobinPolicy.builder().build()))
நான் நூல்களின் எண்ணிக்கையுடன் விளையாடினேன். இதன் விளைவு பின்வருமாறு:
4 அட்டவணைகள், 100 நூல்கள், தொகுதி = 1 (துண்டாக துண்டு): 301 ஆப்ஸ்
4 அட்டவணைகள், 100 நூல்கள், தொகுதி = 10: 447 ஆப்ஸ்
4 அட்டவணைகள், 100 நூல்கள், தொகுதி = 100: 625 ஆப்ஸ்
பின்னர் நான் மற்ற டியூனிங் உதவிக்குறிப்புகளைப் பயன்படுத்துவேன், முழு சோதனைச் சுழற்சியை இயக்கி, இடுகையின் முடிவில் முடிவுகளைச் சேர்ப்பேன்.
ஆதாரம்: www.habr.com