ఇది జోక్ కూడా కాదు, ఈ నిర్దిష్ట చిత్రం ఈ డేటాబేస్‌ల సారాన్ని చాలా ఖచ్చితంగా ప్రతిబింబిస్తుందని అనిపిస్తుంది మరియు చివరికి ఎందుకు స్పష్టంగా తెలుస్తుంది:
DB-ఇంజిన్స్ ర్యాంకింగ్ ప్రకారం, రెండు అత్యంత ప్రజాదరణ పొందిన 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 ఇదే సూత్రంపై పనిచేస్తుంది, అనగా. అటువంటి పోలిక మరింత న్యాయంగా ఉంటుంది.
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
జావా వెర్షన్: 1.8.0_111
CS వెర్షన్: 3.11.5
cassandra.yml పారామితులుసంఖ్య_టోకెన్లు: 256
hinted_handoff_enabled: నిజం
hinted_handoff_throttle_in_kb: 1024
max_hints_delivery_threads: 2
సూచనలు_డైరెక్టరీ: /data10/cassandra/hints
hints_flush_period_in_ms: 10000
max_hints_file_size_in_mb: 128
batchlog_replay_throttle_in_kb: 1024
ప్రమాణీకరణదారు: AllowAllAuthenticator
ఆథరైజర్: AllowAllAuthorizer
రోల్_మేనేజర్: కాసాండ్రా రోల్ మేనేజర్
ms: 2000లో పాత్రలు_చెల్లుబాటు
ms: 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: తప్పు
disk_failure_policy: ఆపండి
కమిట్_ఫెయిల్యూర్_పాలసీ: ఆపండి
సిద్ధం_స్టేట్‌మెంట్స్_కాష్_సైజ్_mb:
thrift_prepared_statements_cache_size_mb:
key_cache_size_in_mb:
key_cache_save_period: 14400
mb 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
కమిట్లాగ్_సెగ్మెంట్_సైజ్_in_mb: 32
విత్తన_ప్రదాత:
- తరగతి_పేరు: 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
ఇండెక్స్_సమ్మరీ_కెపాసిటీ_in_mb:
ఇండెక్స్_సారాంశం_పరిమాణం_నిమిషాల్లో_విరామం: 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: సమకాలీకరణ
పొదుపు_ఫ్రేమ్డ్_ట్రాన్స్‌పోర్ట్_పరిమాణం_mb: 15
incremental_backups: తప్పు
స్నాప్‌షాట్_బిఫోర్_కంపాక్షన్: తప్పు
ఆటో_స్నాప్‌షాట్: నిజం
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
msg_in_request_timeout_truncate_request: 60000
రిక్వెస్ట్_టైమ్ అవుట్_ఇన్_మ్స్: 200000
slow_query_log_timeout_in_ms: 500
cross_node_timeout: తప్పు
endpoint_snitch: GossipingPropertyFileSnitch
dynamic_snitch_update_interval_in_ms: 100
dynamic_snitch_reset_interval_in_ms: 600000
డైనమిక్_స్నిచ్_బాడ్‌నెస్_థ్రెషోల్డ్: 0.1
అభ్యర్థన_షెడ్యూలర్: org.apache.cassandra.scheduler.NoScheduler
server_encryption_options:
ఇంటర్నోడ్_ఎన్‌క్రిప్షన్: ఏదీ లేదు
client_encryption_options:
ప్రారంభించబడింది: తప్పు
ఇంటర్నోడ్_కంప్రెషన్: డిసి
inter_dc_tcp_nodelay: తప్పు
tracetype_query_ttl: 86400
ట్రేస్టైప్_రిపేర్_ttl: 604800
enable_user_defined_functions: తప్పు
enable_scripted_user_defined_functions: తప్పు
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: తప్పు
enable_materialized_views: true
enable_sasi_indexes: నిజం
GC సెట్టింగ్‌లు:
### CMS సెట్టింగ్‌లు-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
-XX:+CMSParallelRemarkEnabled
-XX:సర్వైవర్ రేషియో=8
-XX:MaxTenuring థ్రెషోల్డ్=1
-XX:CMSఇనిషియేటింగ్ ఆక్యుపెన్సీ ఫ్రాక్షన్=75
-XX:+ఉపయోగించుCMSఆక్యుపెన్సీని ప్రారంభించడం మాత్రమే
-XX:CMSWaitDuration=10000
-XX:+CMSParallelInitialMarkEnabled
-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ని మినహాయించాము, ఇది రీజియన్‌సర్వర్‌లో ప్రాంతాల సంఖ్య 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 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 రీజియన్‌సర్వర్ యొక్క జావా హీప్ పరిమాణం: 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'}
ఇక్కడ ఒక ముఖ్యమైన అంశం ఉంది - డేటాస్టాక్స్ వివరణ 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 సెటప్‌లో ఒక రకమైన అడ్డంకి ఉందా అనే అనుమానం ఉంది. అయినప్పటికీ, గూగ్లింగ్ చేయడం మరియు అత్యంత స్పష్టమైన పారామితుల కోసం శోధించడం (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 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 మరియు సెట్ కాషింగ్ = {'కీలు': 'అన్ని', ఎనేబుల్ చేయడానికి ఒక ప్రయత్నం జరిగింది. 'rows_per_partition': ' 2000000'}, కానీ అది మరింత దిగజారింది.
HBలోని ప్రాంతాల సంఖ్య గురించిన ఒక ముఖ్యమైన విషయాన్ని మరోసారి ప్రస్తావించడం విలువ. మా విషయంలో, విలువ 64గా పేర్కొనబడింది. మీరు దానిని తగ్గించి, ఉదాహరణకు, 4కి సమానంగా చేస్తే, అప్పుడు చదివేటప్పుడు, వేగం 2 సార్లు పడిపోతుంది. కారణం ఏమిటంటే, మెమ్‌స్టోర్ వేగంగా నిండిపోతుంది మరియు ఫైల్‌లు తరచుగా ఫ్లష్ చేయబడతాయి మరియు చదివేటప్పుడు, మరిన్ని ఫైల్‌లను ప్రాసెస్ చేయాల్సి ఉంటుంది, ఇది HB కోసం చాలా క్లిష్టమైన ఆపరేషన్. వాస్తవ పరిస్థితులలో, ముందుగా విభజించడం మరియు కాంపాక్టిఫికేషన్ వ్యూహం ద్వారా ఆలోచించడం ద్వారా దీనిని పరిష్కరించవచ్చు; ప్రత్యేకించి, మేము స్వీయ-వ్రాతపూర్వక యుటిలిటీని ఉపయోగిస్తాము, అది చెత్తను సేకరించి, నేపథ్యంలో నిరంతరం HFilesని కుదించవచ్చు. DataStax పరీక్షల కోసం వారు ఒక్కో టేబుల్‌కి 1 ప్రాంతాన్ని మాత్రమే కేటాయించారు (ఇది సరైనది కాదు) మరియు ఇది వారి రీడింగ్ పరీక్షలలో HB ఎందుకు తక్కువ స్థాయిలో ఉందో కొంతవరకు స్పష్టం చేస్తుంది.
దీని నుండి క్రింది ప్రాథమిక ముగింపులు తీసుకోబడ్డాయి. పరీక్ష సమయంలో పెద్ద పొరపాట్లు జరగలేదని ఊహిస్తే, కాసాండ్రా మట్టితో పాదాలతో ఒక కోలోసస్ లాగా కనిపిస్తుంది. మరింత ఖచ్చితంగా, ఆమె ఒక కాలు మీద బ్యాలెన్స్ చేస్తున్నప్పుడు, వ్యాసం ప్రారంభంలో చిత్రంలో ఉన్నట్లుగా, ఆమె సాపేక్షంగా మంచి ఫలితాలను చూపుతుంది, కానీ అదే పరిస్థితుల్లో పోరాటంలో ఆమె పూర్తిగా ఓడిపోతుంది. అదే సమయంలో, మా హార్డ్‌వేర్‌లో తక్కువ CPU వినియోగాన్ని పరిగణనలోకి తీసుకుని, మేము ఒక్కో హోస్ట్‌కి రెండు రీజియన్‌సర్వర్ 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