HBaseని ఉపయోగించే సిద్ధాంతం మరియు అభ్యాసం

శుభ మద్యాహ్నం నా పేరు డానిల్ లిపోవోయ్, స్బెర్టెక్‌లోని మా బృందం కార్యాచరణ డేటా కోసం HBaseని నిల్వగా ఉపయోగించడం ప్రారంభించింది. దానిని అధ్యయనం చేస్తున్నప్పుడు, నేను క్రమబద్ధీకరించాలని మరియు వివరించాలని కోరుకున్న అనుభవం పేరుకుపోయింది (ఇది చాలా మందికి ఉపయోగకరంగా ఉంటుందని మేము ఆశిస్తున్నాము). దిగువన ఉన్న అన్ని ప్రయోగాలు HBase సంస్కరణలు 1.2.0-cdh5.14.2 మరియు 2.0.0-cdh6.0.0-beta1తో నిర్వహించబడ్డాయి.

1. సాధారణ నిర్మాణం
2. HBASEకి డేటా వ్రాస్తోంది
3. HBASE నుండి డేటాను చదవడం
4. డేటా కాషింగ్
5. బ్యాచ్ డేటా ప్రాసెసింగ్ MultiGet/MultiPut
6. పట్టికలను ప్రాంతాలుగా విభజించే వ్యూహం (విభజన)
7. తప్పు సహనం, కాంపాక్టిఫికేషన్ మరియు డేటా ప్రాంతం
8. సెట్టింగ్‌లు మరియు పనితీరు
9. ఒత్తిడి పరీక్ష
10. కనుగొన్న

1. సాధారణ నిర్మాణం

బ్యాకప్ మాస్టర్ ZooKeeper నోడ్‌లో యాక్టివ్‌గా ఉన్న వ్యక్తి యొక్క హృదయ స్పందనను వింటాడు మరియు అదృశ్యమైతే, మాస్టర్ యొక్క విధులను తీసుకుంటాడు.

2. HBASEకి డేటాను వ్రాయండి

ముందుగా, సరళమైన సందర్భాన్ని చూద్దాం - పుట్(రౌకీ)ని ఉపయోగించి టేబుల్‌కి కీ-విలువ వస్తువును రాయడం. క్లయింట్ ముందుగా hbase:meta టేబుల్‌ని నిల్వ చేసే రూట్ రీజియన్ సర్వర్ (RRS) ఎక్కడ ఉందో కనుక్కోవాలి. అతను జూకీపర్ నుండి ఈ సమాచారాన్ని అందుకుంటాడు. ఆ తర్వాత అది RRSని యాక్సెస్ చేసి, hbase:meta టేబుల్‌ని చదువుతుంది, దాని నుండి ఆసక్తి పట్టికలో ఇచ్చిన రౌకీకి డేటాను నిల్వ చేయడానికి RegionServer (RS) బాధ్యత వహిస్తుంది అనే సమాచారాన్ని సంగ్రహిస్తుంది. భవిష్యత్ ఉపయోగం కోసం, క్లయింట్ ద్వారా మెటా టేబుల్ కాష్ చేయబడుతుంది మరియు అందువల్ల తదుపరి కాల్‌లు నేరుగా RSకి వేగంగా వెళ్తాయి.

తరువాత, RS, ఒక అభ్యర్థనను స్వీకరించిన తర్వాత, ముందుగా దానిని WriteAheadLog (WAL)కి వ్రాస్తుంది, ఇది క్రాష్ అయినప్పుడు రికవరీకి అవసరం. ఆపై డేటాను MemStoreలో సేవ్ చేస్తుంది. ఇది మెమరీలో బఫర్, ఇది ఇచ్చిన ప్రాంతం కోసం క్రమబద్ధీకరించబడిన కీల సమితిని కలిగి ఉంటుంది. ఒక పట్టికను ప్రాంతాలుగా (విభజనలు) విభజించవచ్చు, వీటిలో ప్రతి ఒక్కటి కీల యొక్క విరుద్ధమైన సెట్‌ను కలిగి ఉంటుంది. అధిక పనితీరును సాధించడానికి వివిధ సర్వర్‌లలో ప్రాంతాలను ఉంచడానికి ఇది మిమ్మల్ని అనుమతిస్తుంది. అయితే, ఈ ప్రకటన స్పష్టంగా ఉన్నప్పటికీ, ఇది అన్ని సందర్భాల్లో పని చేయదని మేము తరువాత చూస్తాము.

మెమ్‌స్టోర్‌లో ఎంట్రీని ఉంచిన తర్వాత, ఎంట్రీ విజయవంతంగా సేవ్ చేయబడిందని క్లయింట్‌కు ప్రతిస్పందన తిరిగి వస్తుంది. అయితే, వాస్తవానికి ఇది బఫర్‌లో మాత్రమే నిల్వ చేయబడుతుంది మరియు కొంత సమయం గడిచిన తర్వాత లేదా కొత్త డేటాతో నిండిన తర్వాత మాత్రమే డిస్క్‌కి వస్తుంది.

"తొలగించు" ఆపరేషన్ చేస్తున్నప్పుడు, డేటా భౌతికంగా తొలగించబడదు. అవి తొలగించబడినట్లుగా గుర్తించబడతాయి మరియు ప్రధాన కాంపాక్ట్ ఫంక్షన్‌ను పిలిచే సమయంలో విధ్వంసం సంభవిస్తుంది, ఇది పేరా 7లో మరింత వివరంగా వివరించబడింది.

HFile ఫార్మాట్‌లోని ఫైల్‌లు HDFSలో సేకరించబడతాయి మరియు ఎప్పటికప్పుడు మైనర్ కాంపాక్ట్ ప్రాసెస్ ప్రారంభించబడుతుంది, ఇది చిన్న ఫైల్‌లను ఏదైనా తొలగించకుండా పెద్ద వాటిలో విలీనం చేస్తుంది. కాలక్రమేణా, ఇది డేటాను చదివేటప్పుడు మాత్రమే కనిపించే సమస్యగా మారుతుంది (మేము దీనికి కొంచెం తర్వాత తిరిగి వస్తాము).

పైన వివరించిన లోడింగ్ ప్రక్రియతో పాటు, మరింత ప్రభావవంతమైన విధానం ఉంది, ఇది బహుశా ఈ డేటాబేస్ యొక్క బలమైన వైపు - బల్క్‌లోడ్. మేము స్వతంత్రంగా HFilesని ఏర్పరుస్తాము మరియు వాటిని డిస్క్‌లో ఉంచుతాము, ఇది ఖచ్చితంగా స్కేల్ చేయడానికి మరియు చాలా మంచి వేగాన్ని సాధించడానికి అనుమతిస్తుంది. నిజానికి, ఇక్కడ పరిమితి HBase కాదు, కానీ హార్డ్‌వేర్ సామర్థ్యాలు. 16 RegionServers మరియు 16 NodeManager YARN (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 థ్రెడ్‌లు), HBase వెర్షన్ 1.2.0-cdh5.14.2తో కూడిన క్లస్టర్‌పై బూట్ ఫలితాలు క్రింద ఉన్నాయి.

ఇక్కడ మీరు పట్టికలో విభజనల (ప్రాంతాలు) సంఖ్యను పెంచడం ద్వారా, అలాగే స్పార్క్ ఎగ్జిక్యూటర్లు, మేము డౌన్‌లోడ్ వేగంలో పెరుగుదలను పొందుతాము. అలాగే, వేగం రికార్డింగ్ వాల్యూమ్‌పై ఆధారపడి ఉంటుంది. పెద్ద బ్లాక్‌లు MB/సెకనులో పెరుగుదలను అందిస్తాయి, యూనిట్ సమయానికి చొప్పించిన రికార్డుల సంఖ్యలో చిన్న బ్లాక్‌లు, అన్ని ఇతర అంశాలు సమానంగా ఉంటాయి.

మీరు ఒకేసారి రెండు టేబుల్‌లలోకి లోడ్ చేయడం ప్రారంభించవచ్చు మరియు రెట్టింపు వేగం పొందవచ్చు. 10 KB బ్లాక్‌లను రెండు టేబుల్‌లకు ఒకేసారి వ్రాయడం ప్రతిదానిలో (మొత్తం 600 MB/సెకను) 1275 MB/సెకను వేగంతో జరుగుతుందని మీరు క్రింద చూడవచ్చు, ఇది ఒక టేబుల్ 623 MB/సెకనుకు వ్రాసే వేగంతో సమానంగా ఉంటుంది (చూడండి పైన నం. 11)

కానీ 50 KB రికార్డులతో రెండవ రన్ డౌన్‌లోడ్ వేగం కొద్దిగా పెరుగుతోందని చూపిస్తుంది, ఇది పరిమితి విలువలను చేరుకుంటుందని సూచిస్తుంది. అదే సమయంలో, HBASE లోనే ఆచరణాత్మకంగా ఎటువంటి లోడ్ సృష్టించబడలేదని మీరు గుర్తుంచుకోవాలి, దీనికి కావలసిందల్లా ముందుగా hbase:meta నుండి డేటాను అందించడం మరియు HFilesని లైనింగ్ చేసిన తర్వాత, BlockCache డేటాను రీసెట్ చేసి, సేవ్ చేయండి MemStore డిస్క్‌కి బఫర్, అది ఖాళీగా లేకుంటే.

3. HBASE నుండి డేటాను చదవడం

క్లయింట్ ఇప్పటికే hbase:meta (పాయింట్ 2 చూడండి) నుండి మొత్తం సమాచారాన్ని కలిగి ఉందని మేము ఊహిస్తే, అభ్యర్థన నేరుగా అవసరమైన కీ నిల్వ చేయబడిన RSకి వెళుతుంది. మొదట, శోధన MemCacheలో నిర్వహించబడుతుంది. అక్కడ డేటా ఉందా లేదా అనే దానితో సంబంధం లేకుండా, శోధన BlockCache బఫర్‌లో మరియు అవసరమైతే, HFilesలో కూడా నిర్వహించబడుతుంది. ఫైల్‌లో డేటా కనుగొనబడితే, అది BlockCacheలో ఉంచబడుతుంది మరియు తదుపరి అభ్యర్థనపై వేగంగా తిరిగి ఇవ్వబడుతుంది. బ్లూమ్ ఫిల్టర్‌ని ఉపయోగించడం వల్ల HFileలో శోధించడం చాలా వేగంగా జరుగుతుంది, అనగా. తక్కువ మొత్తంలో డేటాను చదివిన తర్వాత, ఈ ఫైల్‌లో అవసరమైన కీని కలిగి ఉందో లేదో వెంటనే నిర్ణయిస్తుంది మరియు లేకపోతే, తదుపరి దానికి వెళుతుంది.

ఈ మూడు మూలాధారాల నుండి డేటాను స్వీకరించిన తర్వాత, RS ప్రతిస్పందనను రూపొందిస్తుంది. ప్రత్యేకించి, క్లయింట్ సంస్కరణను అభ్యర్థించినట్లయితే, ఇది ఒక వస్తువు యొక్క అనేక కనుగొనబడిన సంస్కరణలను ఒకేసారి బదిలీ చేయగలదు.

4. డేటా కాషింగ్

MemStore మరియు BlockCache బఫర్‌లు కేటాయించబడిన ఆన్-హీప్ RS మెమరీలో 80% వరకు ఆక్రమించాయి (మిగతాది RS సర్వీస్ టాస్క్‌ల కోసం రిజర్వ్ చేయబడింది). సాధారణ వినియోగ మోడ్ అదే డేటాను వ్రాయడం మరియు వెంటనే చదవడం వంటిది అయితే, BlockCacheని తగ్గించడం మరియు MemStoreని పెంచడం అర్ధమే, ఎందుకంటే డేటాను వ్రాయడం చదవడానికి కాష్‌లోకి రానప్పుడు, BlockCache తక్కువ తరచుగా ఉపయోగించబడుతుంది. BlockCache బఫర్ రెండు భాగాలను కలిగి ఉంటుంది: LruBlockCache (ఎల్లప్పుడూ ఆన్-హీప్) మరియు BucketCache (సాధారణంగా ఆఫ్-హీప్ లేదా SSDలో). చాలా రీడింగ్ రిక్వెస్ట్‌లు ఉన్నప్పుడు మరియు అవి LruBlockCacheకి సరిపోనప్పుడు BucketCacheని ఉపయోగించాలి, ఇది చెత్త కలెక్టర్ యొక్క క్రియాశీల పనికి దారి తీస్తుంది. అదే సమయంలో, రీడ్ కాష్‌ని ఉపయోగించడం నుండి పనితీరులో సమూలమైన పెరుగుదలను మీరు ఆశించకూడదు, అయితే మేము దీనికి పేరా 8లో తిరిగి వస్తాము.

మొత్తం RS కోసం ఒక BlockCache ఉంది మరియు ప్రతి టేబుల్‌కి ఒక MemStore ఉంది (ప్రతి కాలమ్ ఫ్యామిలీకి ఒకటి).

ఎలా వివరించబడింది సిద్ధాంతపరంగా, వ్రాసేటప్పుడు, డేటా కాష్‌లోకి వెళ్లదు మరియు నిజానికి, పట్టిక కోసం CACHE_DATA_ON_WRITE మరియు RS కోసం “కాష్ డేటా ఆన్ రైట్” వంటి పారామితులు తప్పుగా సెట్ చేయబడ్డాయి. అయితే, ఆచరణలో, మేము మెమ్‌స్టోర్‌కు డేటాను వ్రాసి, దానిని డిస్క్‌కి ఫ్లష్ చేస్తే (దీనిని క్లియర్ చేస్తుంది), ఆపై ఫలిత ఫైల్‌ను తొలగించండి, ఆపై గెట్ అభ్యర్థనను అమలు చేయడం ద్వారా మేము డేటాను విజయవంతంగా స్వీకరిస్తాము. అంతేకాకుండా, మీరు BlockCacheని పూర్తిగా నిలిపివేసి, కొత్త డేటాతో పట్టికను పూరించినప్పటికీ, MemStoreని డిస్క్‌కి రీసెట్ చేసి, వాటిని తొలగించి, మరొక సెషన్ నుండి అభ్యర్థించినప్పటికీ, అవి ఎక్కడి నుండైనా తిరిగి పొందబడతాయి. కాబట్టి HBase డేటాను మాత్రమే కాకుండా, రహస్యమైన రహస్యాలను కూడా నిల్వ చేస్తుంది.

hbase(main):001:0> create 'ns:magic', 'cf'
Created table ns:magic
Took 1.1533 seconds
hbase(main):002:0> put 'ns:magic', 'key1', 'cf:c', 'try_to_delete_me'
Took 0.2610 seconds
hbase(main):003:0> flush 'ns:magic'
Took 0.6161 seconds
hdfs dfs -mv /data/hbase/data/ns/magic/* /tmp/trash
hbase(main):002:0> get 'ns:magic', 'key1'
 cf:c      timestamp=1534440690218, value=try_to_delete_me

"రీడ్‌లో కాష్ డేటా" పరామితి తప్పుకు సెట్ చేయబడింది. మీకు ఏవైనా ఆలోచనలు ఉంటే, వ్యాఖ్యలలో చర్చించడానికి స్వాగతం.

5. బ్యాచ్ డేటా ప్రాసెసింగ్ MultiGet/MultiPut

సింగిల్ రిక్వెస్ట్‌లను ప్రాసెస్ చేయడం (గెట్/పుట్/డిలీట్) అనేది చాలా ఖరీదైన ఆపరేషన్, కాబట్టి వీలైతే, మీరు వాటిని లిస్ట్ లేదా లిస్ట్‌గా మిళితం చేయాలి, ఇది గణనీయమైన పనితీరును పెంచడానికి మిమ్మల్ని అనుమతిస్తుంది. వ్రాత ఆపరేషన్ కోసం ఇది ప్రత్యేకంగా వర్తిస్తుంది, కానీ చదివేటప్పుడు క్రింది ఆపద ఉంది. దిగువ గ్రాఫ్ MemStore నుండి 50 రికార్డ్‌లను చదవడానికి సమయాన్ని చూపుతుంది. పఠనం ఒక థ్రెడ్‌లో నిర్వహించబడింది మరియు క్షితిజ సమాంతర అక్షం అభ్యర్థనలోని కీల సంఖ్యను చూపుతుంది. ఇక్కడ మీరు ఒక అభ్యర్థనలో వెయ్యి కీలను పెంచుతున్నప్పుడు, అమలు సమయం పడిపోతుందని చూడవచ్చు, అనగా. వేగం పెరుగుతుంది. అయినప్పటికీ, MSLAB మోడ్ డిఫాల్ట్‌గా ప్రారంభించబడితే, ఈ థ్రెషోల్డ్ తర్వాత పనితీరులో సమూలంగా తగ్గుదల ప్రారంభమవుతుంది మరియు రికార్డ్‌లోని డేటా పెద్ద మొత్తంలో, ఆపరేటింగ్ సమయం ఎక్కువ.

వర్చువల్ మెషీన్, 8 కోర్లు, వెర్షన్ HBase 2.0.0-cdh6.0.0-beta1పై పరీక్షలు జరిగాయి.

MSLAB మోడ్ హీప్ ఫ్రాగ్మెంటేషన్‌ను తగ్గించడానికి రూపొందించబడింది, ఇది కొత్త మరియు పాత తరం డేటాను కలపడం వల్ల సంభవిస్తుంది. ప్రత్యామ్నాయంగా, MSLAB ప్రారంభించబడినప్పుడు, డేటా సాపేక్షంగా చిన్న సెల్‌లలో (భాగాలు) ఉంచబడుతుంది మరియు భాగాలుగా ప్రాసెస్ చేయబడుతుంది. ఫలితంగా, అభ్యర్థించిన డేటా ప్యాకెట్‌లోని వాల్యూమ్ కేటాయించిన పరిమాణాన్ని మించిపోయినప్పుడు, పనితీరు బాగా పడిపోతుంది. మరోవైపు, ఈ మోడ్‌ని ఆఫ్ చేయడం కూడా మంచిది కాదు, ఎందుకంటే ఇంటెన్సివ్ డేటా ప్రాసెసింగ్ సమయంలో ఇది GC కారణంగా ఆగిపోతుంది. చదివేటప్పుడు అదే సమయంలో పుట్ ద్వారా యాక్టివ్ రైటింగ్ విషయంలో సెల్ వాల్యూమ్‌ను పెంచడం మంచి పరిష్కారం. రికార్డింగ్ తర్వాత, మీరు MemStoreని డిస్క్‌కి రీసెట్ చేసే ఫ్లష్ కమాండ్‌ను అమలు చేస్తే లేదా మీరు బల్క్‌లోడ్ ఉపయోగించి లోడ్ చేస్తే సమస్య జరగదని గమనించాలి. పెద్ద (మరియు అదే మొత్తం) డేటా కోసం MemStore నుండి ప్రశ్నలు మందగింపులకు దారితీస్తాయని దిగువ పట్టిక చూపిస్తుంది. అయినప్పటికీ, పరిమాణాన్ని పెంచడం ద్వారా మేము ప్రాసెసింగ్ సమయాన్ని సాధారణ స్థితికి తీసుకువస్తాము.

పరిమాణాన్ని పెంచడంతో పాటు, ప్రాంతాల వారీగా డేటాను విభజించడం సహాయపడుతుంది, అనగా. పట్టిక విభజన. దీని ఫలితంగా ప్రతి ప్రాంతానికి తక్కువ అభ్యర్థనలు వస్తాయి మరియు అవి సెల్‌కి సరిపోతుంటే, ప్రతిస్పందన బాగానే ఉంటుంది.

6. పట్టికలను ప్రాంతాలుగా విభజించే వ్యూహం (విభజన)

HBase కీ-విలువ నిల్వ మరియు విభజన కీ ద్వారా నిర్వహించబడుతుంది కాబట్టి, డేటాను అన్ని ప్రాంతాలలో సమానంగా విభజించడం చాలా ముఖ్యం. ఉదాహరణకు, అటువంటి పట్టికను మూడు భాగాలుగా విభజించడం వలన డేటా మూడు ప్రాంతాలుగా విభజించబడుతుంది:

తర్వాత లోడ్ చేయబడిన డేటా లాంగ్ వాల్యూస్ లాగా కనిపిస్తే, ఇది చాలా మందగమనానికి దారి తీస్తుంది, ఉదాహరణకు, చాలా వరకు ఒకే అంకెతో మొదలవుతుంది, ఉదాహరణకు:

1000001
1000002
...
1100003

కీలు బైట్ శ్రేణి వలె నిల్వ చేయబడినందున, అవన్నీ ఒకేలా ప్రారంభమవుతాయి మరియు ఈ శ్రేణి కీలను నిల్వ చేసే ఒకే ప్రాంతం #1కి చెందినవి. అనేక విభజన వ్యూహాలు ఉన్నాయి:

HexStringSplit – కీని "00000000" => "FFFFFFFF" పరిధిలో హెక్సాడెసిమల్ ఎన్‌కోడ్ చేసిన స్ట్రింగ్‌గా మారుస్తుంది మరియు ఎడమవైపు సున్నాలతో ప్యాడింగ్ చేస్తుంది.

UniformSplit – "00" => "FF" పరిధిలో హెక్సాడెసిమల్ ఎన్‌కోడింగ్‌తో కీని బైట్ శ్రేణిగా మారుస్తుంది మరియు కుడివైపు సున్నాలతో ప్యాడింగ్ చేస్తుంది.

అదనంగా, మీరు విభజన కోసం ఏదైనా పరిధిని లేదా కీల సమితిని పేర్కొనవచ్చు మరియు స్వీయ-విభజనను కాన్ఫిగర్ చేయవచ్చు. అయితే, సరళమైన మరియు అత్యంత ప్రభావవంతమైన విధానాలలో ఒకటి యూనిఫార్మ్‌స్ప్లిట్ మరియు హాష్ సంయోగాన్ని ఉపయోగించడం, ఉదాహరణకు CRC32(రౌకీ) ఫంక్షన్ మరియు రౌకీ ద్వారా కీని అమలు చేయడం ద్వారా అత్యంత ముఖ్యమైన జత బైట్‌లు:

హాష్ + రౌకీ

అప్పుడు మొత్తం డేటా ప్రాంతాలకు సమానంగా పంపిణీ చేయబడుతుంది. చదివేటప్పుడు, మొదటి రెండు బైట్‌లు విస్మరించబడతాయి మరియు అసలు కీ మిగిలి ఉంటుంది. RS ప్రాంతంలోని డేటా మరియు కీల పరిమాణాన్ని కూడా నియంత్రిస్తుంది మరియు పరిమితులు దాటితే, స్వయంచాలకంగా దానిని భాగాలుగా విభజిస్తుంది.

7. తప్పు సహనం మరియు డేటా ప్రాంతం

ప్రతి సెట్ కీలకు ఒక ప్రాంతం మాత్రమే బాధ్యత వహిస్తుంది కాబట్టి, RS క్రాష్‌లు లేదా డీకమిషన్‌తో సంబంధం ఉన్న సమస్యలకు పరిష్కారం HDFSలో అవసరమైన మొత్తం డేటాను నిల్వ చేయడం. RS పడిపోయినప్పుడు, జూకీపర్ నోడ్‌లో హృదయ స్పందన లేకపోవడం ద్వారా మాస్టర్ దీనిని గుర్తిస్తుంది. ఆపై అది అందించబడిన ప్రాంతాన్ని మరొక RSకి కేటాయిస్తుంది మరియు HFiles పంపిణీ చేయబడిన ఫైల్ సిస్టమ్‌లో నిల్వ చేయబడినందున, కొత్త యజమాని వాటిని చదివి డేటాను అందించడం కొనసాగిస్తుంది. అయినప్పటికీ, కొన్ని డేటా MemStoreలో ఉండవచ్చు మరియు HFilesలోకి ప్రవేశించడానికి సమయం లేనందున, HDFSలో కూడా నిల్వ చేయబడిన WAL, కార్యకలాపాల చరిత్రను పునరుద్ధరించడానికి ఉపయోగించబడుతుంది. మార్పులు వర్తింపజేసిన తర్వాత, RS అభ్యర్థనలకు ప్రతిస్పందించగలదు, అయితే ఈ చర్య కొన్ని డేటా మరియు వాటికి సేవలందించే ప్రక్రియలు వేర్వేరు నోడ్‌లలో ముగుస్తుంది, అనగా. స్థానికత తగ్గుతోంది.

సమస్యకు పరిష్కారం ప్రధాన సంపీడనం - ఈ విధానం ఫైళ్లను వాటికి బాధ్యత వహించే నోడ్‌లకు (వాటి ప్రాంతాలు ఉన్న చోట) తరలిస్తుంది, దీని ఫలితంగా ఈ ప్రక్రియలో నెట్‌వర్క్ మరియు డిస్క్‌లపై లోడ్ బాగా పెరుగుతుంది. అయితే, భవిష్యత్తులో, డేటాకు ప్రాప్యత గమనించదగ్గ విధంగా వేగవంతం చేయబడింది. అదనంగా, major_compaction అనేది ఒక ప్రాంతంలోని ఒక ఫైల్‌గా అన్ని HFilesను విలీనం చేస్తుంది మరియు పట్టిక సెట్టింగ్‌లను బట్టి డేటాను కూడా శుభ్రపరుస్తుంది. ఉదాహరణకు, మీరు ఉంచవలసిన వస్తువు యొక్క సంస్కరణల సంఖ్యను లేదా ఆ వస్తువు భౌతికంగా తొలగించబడిన జీవితకాలాన్ని పేర్కొనవచ్చు.

ఈ విధానం HBase యొక్క ఆపరేషన్‌పై చాలా సానుకూల ప్రభావాన్ని చూపుతుంది. సక్రియ డేటా రికార్డింగ్ ఫలితంగా పనితీరు ఎలా క్షీణించిందో దిగువ చిత్రం చూపుతుంది. ఒక టేబుల్‌కి 40 థ్రెడ్‌లు ఎలా రాశాయో మరియు 40 థ్రెడ్‌లు ఏకకాలంలో డేటాను ఎలా రీడ్ చేశాయో ఇక్కడ మీరు చూడవచ్చు. రైటింగ్ థ్రెడ్‌లు మరిన్ని ఎక్కువ హెచ్‌ఫైల్‌లను ఉత్పత్తి చేస్తాయి, వీటిని ఇతర థ్రెడ్‌లు చదవబడతాయి. ఫలితంగా, మెమరీ నుండి మరింత ఎక్కువ డేటా తీసివేయవలసి ఉంటుంది మరియు చివరికి GC పని చేయడం ప్రారంభిస్తుంది, ఇది ఆచరణాత్మకంగా అన్ని పనిని స్తంభింపజేస్తుంది. మేజర్ కాంపాక్షన్ ప్రారంభించడం వల్ల ఏర్పడిన చెత్తను తొలగించడం మరియు ఉత్పాదకతను పునరుద్ధరించడం జరిగింది.

పరీక్ష 3 డేటానోడ్‌లు మరియు 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 థ్రెడ్‌లు)పై నిర్వహించబడింది. HBase వెర్షన్ 1.2.0-cdh5.14.2

"లైవ్" పట్టికలో ప్రధాన సంపీడనం ప్రారంభించబడిందని గమనించాలి, దీనిలో డేటా చురుకుగా వ్రాయబడింది మరియు చదవబడుతుంది. డేటాను చదివేటప్పుడు ఇది తప్పు ప్రతిస్పందనకు దారితీస్తుందని ఆన్‌లైన్‌లో ఒక ప్రకటన ఉంది. తనిఖీ చేయడానికి, కొత్త డేటాను రూపొందించి టేబుల్‌కి వ్రాసే ప్రక్రియ ప్రారంభించబడింది. దాని తర్వాత నేను వెంటనే చదివి, ఫలిత విలువ వ్రాసిన దానితో సమానంగా ఉందో లేదో తనిఖీ చేసాను. ఈ ప్రక్రియ నడుస్తున్నప్పుడు, మేజర్ కాంపాక్షన్ సుమారు 200 సార్లు అమలు చేయబడింది మరియు ఒక్క వైఫల్యం కూడా నమోదు కాలేదు. బహుశా సమస్య చాలా అరుదుగా కనిపిస్తుంది మరియు అధిక లోడ్ సమయంలో మాత్రమే కనిపిస్తుంది, కాబట్టి ప్రణాళిక ప్రకారం వ్రాయడం మరియు చదవడం ప్రక్రియలను నిలిపివేయడం మరియు అటువంటి GC డ్రాడౌన్‌లను నివారించడానికి శుభ్రపరచడం సురక్షితం.

అలాగే, మేజర్ కాంపాక్షన్ MemStore స్థితిని ప్రభావితం చేయదు; దానిని డిస్క్‌కి ఫ్లష్ చేయడానికి మరియు కుదించడానికి, మీరు ఫ్లష్ (connection.getAdmin().flush(TableName.valueOf(tblName)))ని ఉపయోగించాలి.

8. సెట్టింగ్‌లు మరియు పనితీరు

ఇప్పటికే చెప్పినట్లుగా, బల్క్‌లోడ్‌ని అమలు చేస్తున్నప్పుడు ఏమీ చేయనవసరం లేని చోట HBase దాని గొప్ప విజయాన్ని చూపుతుంది. అయితే, ఇది చాలా వ్యవస్థలు మరియు వ్యక్తులకు వర్తిస్తుంది. అయితే, ఈ సాధనం పెద్ద బ్లాక్‌లలో డేటాను పెద్దమొత్తంలో నిల్వ చేయడానికి మరింత అనుకూలంగా ఉంటుంది, అయితే ప్రక్రియకు బహుళ పోటీ రీడ్ అండ్ రైట్ అభ్యర్థనలు అవసరమైతే, పైన వివరించిన గెట్ అండ్ పుట్ కమాండ్‌లు ఉపయోగించబడతాయి. సరైన పారామితులను నిర్ణయించడానికి, పట్టిక పారామితులు మరియు సెట్టింగుల యొక్క వివిధ కలయికలతో లాంచ్‌లు నిర్వహించబడ్డాయి:

• 10 థ్రెడ్‌లు వరుసగా 3 సార్లు ఏకకాలంలో ప్రారంభించబడ్డాయి (దీనిని థ్రెడ్‌ల బ్లాక్ అని పిలుద్దాం).
• బ్లాక్‌లోని అన్ని థ్రెడ్‌ల ఆపరేటింగ్ సమయం సగటున నిర్ణయించబడింది మరియు బ్లాక్ యొక్క ఆపరేషన్ యొక్క తుది ఫలితం.
• అన్ని థ్రెడ్‌లు ఒకే టేబుల్‌తో పనిచేశాయి.
• థ్రెడ్ బ్లాక్ యొక్క ప్రతి ప్రారంభానికి ముందు, ఒక ప్రధాన సంపీడనం ప్రదర్శించబడింది.
• ప్రతి బ్లాక్ కింది కార్యకలాపాలలో ఒకదాన్ని మాత్రమే నిర్వహిస్తుంది:

- పెట్టు
- పొందండి
—గెట్+పుట్

• ప్రతి బ్లాక్ దాని ఆపరేషన్ యొక్క 50 పునరావృత్తులు చేసింది.
• రికార్డ్ యొక్క బ్లాక్ పరిమాణం 100 బైట్లు, 1000 బైట్లు లేదా 10000 బైట్లు (యాదృచ్ఛికం).
• బ్లాక్‌లు వేర్వేరు సంఖ్యలో అభ్యర్థించిన కీలతో ప్రారంభించబడ్డాయి (ఒక కీ లేదా 10).
• బ్లాక్‌లు వేర్వేరు టేబుల్ సెట్టింగ్‌ల క్రింద అమలు చేయబడ్డాయి. పారామితులు మార్చబడ్డాయి:

— BlockCache = ఆన్ లేదా ఆఫ్ చేయబడింది
— బ్లాక్‌సైజ్ = 65 KB లేదా 16 KB
- విభజనలు = 1, 5 లేదా 30
— MSLAB = ప్రారంభించబడింది లేదా నిలిపివేయబడింది

కాబట్టి బ్లాక్ ఇలా కనిపిస్తుంది:

a. MSLAB మోడ్ ఆన్/ఆఫ్ చేయబడింది.
బి. కింది పారామితులు సెట్ చేయబడిన పట్టిక సృష్టించబడింది: BlockCache = true/none, BlockSize = 65/16 Kb, విభజన = 1/5/30.
సి. కుదింపు GZకి సెట్ చేయబడింది.
డి. 10/1/10 బైట్‌ల రికార్డులతో ఈ పట్టికలో 100/1000 పుట్/గెట్/గెట్+పుట్ ఆపరేషన్‌లను చేస్తూ ఏకకాలంలో 10000 థ్రెడ్‌లు ప్రారంభించబడ్డాయి, వరుసగా 50 ప్రశ్నలను (రాండమ్ కీలు) ప్రదర్శిస్తాయి.
ఇ. పాయింట్ d మూడుసార్లు పునరావృతమైంది.
f. అన్ని థ్రెడ్‌ల ఆపరేటింగ్ సమయం సగటున ఉంది.

సాధ్యమయ్యే అన్ని కలయికలు పరీక్షించబడ్డాయి. రికార్డ్ పరిమాణం పెరిగేకొద్దీ వేగం తగ్గుతుందని లేదా కాషింగ్‌ని నిలిపివేయడం వల్ల మందగమనం జరుగుతుందని ఊహించవచ్చు. ఏదేమైనా, ప్రతి పరామితి యొక్క ప్రభావం యొక్క డిగ్రీ మరియు ప్రాముఖ్యతను అర్థం చేసుకోవడం లక్ష్యం, కాబట్టి సేకరించిన డేటా లీనియర్ రిగ్రెషన్ ఫంక్షన్ యొక్క ఇన్‌పుట్‌లోకి అందించబడింది, ఇది t-గణాంకాలను ఉపయోగించి ప్రాముఖ్యతను అంచనా వేయడం సాధ్యం చేస్తుంది. పుట్ కార్యకలాపాలను నిర్వహిస్తున్న బ్లాక్‌ల ఫలితాలు క్రింద ఉన్నాయి. కలయికల పూర్తి సెట్ 2*2*3*2*3 = 144 ఎంపికలు + 72 tk. కొన్ని రెండుసార్లు జరిగాయి. కాబట్టి, మొత్తం 216 పరుగులు ఉన్నాయి:

3 డేటానోడ్‌లు మరియు 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 థ్రెడ్‌లు) కలిగిన మినీ-క్లస్టర్‌పై పరీక్ష నిర్వహించబడింది. HBase వెర్షన్ 1.2.0-cdh5.14.2.

3.7 సెకన్ల అత్యధిక చొప్పింపు వేగం MSLAB మోడ్ ఆఫ్ చేయబడి, ఒక విభజనతో టేబుల్‌పై, BlockCache ప్రారంభించబడి, BlockSize = 16, 100 బైట్‌ల రికార్డులు, ఒక్కో ప్యాక్‌కు 10 ముక్కలు.
82.8 సెకనుల అత్యల్ప చొప్పింపు వేగం MSLAB మోడ్ ప్రారంభించబడి, ఒక విభజనతో ఒక టేబుల్‌పై, BlockCache ప్రారంభించబడి, BlockSize = 16, 10000 బైట్ల రికార్డులు, ఒక్కొక్కటి 1 పొందింది.

ఇప్పుడు మోడల్ చూద్దాం. మేము R2 ఆధారంగా మోడల్ యొక్క మంచి నాణ్యతను చూస్తాము, అయితే ఎక్స్‌ట్రాపోలేషన్ ఇక్కడ విరుద్ధంగా ఉందని ఖచ్చితంగా తెలుస్తుంది. పారామితులు మారినప్పుడు సిస్టమ్ యొక్క వాస్తవ ప్రవర్తన సరళంగా ఉండదు; ఈ మోడల్ అంచనాల కోసం కాదు, ఇచ్చిన పారామితులలో ఏమి జరిగిందో అర్థం చేసుకోవడానికి అవసరం. ఉదాహరణకు, పుట్ ఆపరేషన్‌కు బ్లాక్‌సైజ్ మరియు బ్లాక్‌కాష్ పారామితులు పట్టింపు లేదని విద్యార్థి యొక్క ప్రమాణం నుండి ఇక్కడ మనం చూస్తాము (ఇది సాధారణంగా ఊహించదగినది):

కానీ విభజనల సంఖ్యను పెంచడం వల్ల పనితీరు తగ్గుతుందనే వాస్తవం కొంతవరకు ఊహించనిది (బల్క్‌లోడ్‌తో విభజనల సంఖ్యను పెంచడం యొక్క సానుకూల ప్రభావాన్ని మేము ఇప్పటికే చూశాము), అయినప్పటికీ అర్థం చేసుకోవచ్చు. ముందుగా, ప్రాసెసింగ్ కోసం, మీరు ఒకదానికి బదులుగా 30 ప్రాంతాలకు అభ్యర్థనలను రూపొందించాలి మరియు డేటా పరిమాణం లాభాన్ని పొందేలా లేదు. రెండవది, మొత్తం ఆపరేటింగ్ సమయం నెమ్మదిగా ఉన్న RS ద్వారా నిర్ణయించబడుతుంది మరియు డేటానోడ్‌ల సంఖ్య RSల సంఖ్య కంటే తక్కువగా ఉన్నందున, కొన్ని ప్రాంతాలు సున్నా ప్రాంతాన్ని కలిగి ఉంటాయి. సరే, మొదటి ఐదు వాటిని చూద్దాం:

ఇప్పుడు గెట్ బ్లాక్‌లను ఎగ్జిక్యూట్ చేసే ఫలితాలను మూల్యాంకనం చేద్దాం:

విభజనల సంఖ్య ప్రాముఖ్యతను కోల్పోయింది, ఇది బహుశా డేటా బాగా కాష్ చేయబడిందని మరియు రీడ్ కాష్ అత్యంత ముఖ్యమైన (గణాంకంగా) పరామితి అని వివరించబడింది. సహజంగానే, అభ్యర్థనలో సందేశాల సంఖ్యను పెంచడం కూడా పనితీరుకు చాలా ఉపయోగకరంగా ఉంటుంది. టాప్ స్కోర్లు:

బాగా, చివరగా, మొదట ప్రదర్శించిన బ్లాక్ మోడల్‌ను చూద్దాం మరియు ఆపై ఉంచండి:

అన్ని పారామితులు ఇక్కడ ముఖ్యమైనవి. మరియు నాయకుల ఫలితాలు:

9. లోడ్ పరీక్ష

సరే, చివరకు మేము ఎక్కువ లేదా తక్కువ మంచి లోడ్‌ను ప్రారంభిస్తాము, కానీ మీరు పోల్చడానికి ఏదైనా కలిగి ఉన్నప్పుడు ఇది ఎల్లప్పుడూ మరింత ఆసక్తికరంగా ఉంటుంది. Cassandra యొక్క కీలక డెవలపర్ అయిన DataStax వెబ్‌సైట్‌లో ఉంది ఫలితాలు HBase వెర్షన్ 0.98.6-1తో సహా అనేక NoSQL నిల్వల NT. 40 థ్రెడ్‌లు, డేటా పరిమాణం 100 బైట్లు, SSD డిస్క్‌ల ద్వారా లోడ్ చేయబడింది. రీడ్-మాడిఫై-రైట్ ఆపరేషన్‌లను పరీక్షించిన ఫలితం క్రింది ఫలితాలను చూపింది.

నేను అర్థం చేసుకున్నంతవరకు, పఠనం 100 రికార్డ్‌ల బ్లాక్‌లలో నిర్వహించబడింది మరియు 16 HBase నోడ్‌ల కోసం, DataStax పరీక్ష సెకనుకు 10 వేల ఆపరేషన్‌ల పనితీరును చూపించింది.

మా క్లస్టర్‌లో 16 నోడ్‌లు కూడా ఉండటం అదృష్టమే, అయితే ప్రతి ఒక్కటి 64 కోర్లను (థ్రెడ్‌లు) కలిగి ఉండటం "అదృష్టం" కాదు, డేటాస్టాక్స్ పరీక్షలో కేవలం 4 మాత్రమే ఉన్నాయి. మరోవైపు, వాటికి SSD డ్రైవ్‌లు ఉన్నాయి, అయితే మనకు HDDలు ఉన్నాయి. లేదా మరిన్ని కొత్త వెర్షన్ HBase మరియు CPU వినియోగం లోడ్ సమయంలో ఆచరణాత్మకంగా గణనీయంగా పెరగలేదు (దృశ్యపరంగా 5-10 శాతం). అయితే, ఈ కాన్ఫిగరేషన్‌ని ఉపయోగించడం ప్రారంభించడానికి ప్రయత్నిద్దాం. డిఫాల్ట్ టేబుల్ సెట్టింగ్‌లు, రీడింగ్ కీ పరిధిలో 0 నుండి 50 మిలియన్ వరకు యాదృచ్ఛికంగా నిర్వహించబడుతుంది (అంటే, ప్రతిసారీ తప్పనిసరిగా కొత్తది). పట్టిక 50 మిలియన్ రికార్డులను కలిగి ఉంది, 64 విభజనలుగా విభజించబడింది. కీలు crc32 ఉపయోగించి హ్యాష్ చేయబడ్డాయి. టేబుల్ సెట్టింగ్‌లు డిఫాల్ట్‌గా ఉన్నాయి, MSLAB ప్రారంభించబడింది. 40 థ్రెడ్‌లను ప్రారంభించడం ద్వారా, ప్రతి థ్రెడ్ 100 యాదృచ్ఛిక కీల సమితిని రీడ్ చేస్తుంది మరియు వెంటనే ఈ కీలకు తిరిగి 100 బైట్‌లను వ్రాస్తుంది.

స్టాండ్: 16 డేటానోడ్ మరియు 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 థ్రెడ్‌లు). HBase వెర్షన్ 1.2.0-cdh5.14.2.

సగటు ఫలితం సెకనుకు 40 వేల కార్యకలాపాలకు దగ్గరగా ఉంది, ఇది డేటాస్టాక్స్ పరీక్ష కంటే మెరుగ్గా ఉంది. అయితే, ప్రయోగాత్మక ప్రయోజనాల కోసం, మీరు పరిస్థితులను కొద్దిగా మార్చవచ్చు. అన్ని పనులు ప్రత్యేకంగా ఒక టేబుల్‌పై మరియు ప్రత్యేకమైన కీలపై మాత్రమే నిర్వహించబడటం చాలా అసంభవం. ప్రధాన లోడ్‌ను ఉత్పత్తి చేసే నిర్దిష్ట "హాట్" సెట్ కీలు ఉన్నాయని అనుకుందాం. కాబట్టి, పెద్ద రికార్డులతో (10 KB), 100 బ్యాచ్‌లలో, 4 వేర్వేరు పట్టికలలో మరియు అభ్యర్థించిన కీల పరిధిని 50 వేలకు పరిమితం చేయడానికి ప్రయత్నిద్దాం. దిగువన ఉన్న గ్రాఫ్ 40 థ్రెడ్‌ల ప్రారంభాన్ని చూపుతుంది, ప్రతి థ్రెడ్ చదవబడుతుంది 100 కీల సమితి మరియు వెంటనే ఈ కీలపై యాదృచ్ఛికంగా 10 KBని వ్రాస్తుంది.

స్టాండ్: 16 డేటానోడ్ మరియు 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 థ్రెడ్‌లు). HBase వెర్షన్ 1.2.0-cdh5.14.2.

లోడ్ సమయంలో, ప్రధాన సంపీడనం చాలాసార్లు ప్రారంభించబడింది, పైన చూపిన విధంగా, ఈ విధానం లేకుండా, పనితీరు క్రమంగా క్షీణిస్తుంది, అయినప్పటికీ, అమలు సమయంలో అదనపు లోడ్ కూడా పుడుతుంది. డ్రాడౌన్లు వివిధ కారణాల వల్ల సంభవిస్తాయి. కొన్నిసార్లు థ్రెడ్‌లు పని చేయడం పూర్తయింది మరియు అవి పునఃప్రారంభించబడినప్పుడు విరామం ఏర్పడింది, కొన్నిసార్లు మూడవ పక్షం అప్లికేషన్‌లు క్లస్టర్‌పై లోడ్‌ను సృష్టించాయి.

చదవడం మరియు వెంటనే రాయడం అనేది HBase కోసం అత్యంత కష్టమైన పని దృశ్యాలలో ఒకటి. మీరు చిన్న పుట్ అభ్యర్థనలను మాత్రమే చేస్తే, ఉదాహరణకు 100 బైట్లు, వాటిని 10-50 వేల ముక్కల ప్యాక్‌లుగా కలపడం, మీరు సెకనుకు వందల వేల కార్యకలాపాలను పొందవచ్చు మరియు చదవడానికి మాత్రమే అభ్యర్థనలతో పరిస్థితి సమానంగా ఉంటుంది. డేటాస్టాక్స్ ద్వారా పొందిన వాటి కంటే ఫలితాలు సమూలంగా మెరుగ్గా ఉన్నాయని గమనించాలి, అన్నింటికంటే 50 వేల బ్లాక్‌లలోని అభ్యర్థనల కారణంగా.

స్టాండ్: 16 డేటానోడ్ మరియు 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 థ్రెడ్‌లు). HBase వెర్షన్ 1.2.0-cdh5.14.2.

10. ముగింపులు

ఈ వ్యవస్థ చాలా సరళంగా కాన్ఫిగర్ చేయబడింది, అయితే పెద్ద సంఖ్యలో పారామితుల ప్రభావం ఇప్పటికీ తెలియదు. వాటిలో కొన్ని పరీక్షించబడ్డాయి, కానీ ఫలిత పరీక్ష సెట్‌లో చేర్చబడలేదు. ఉదాహరణకు, ప్రాథమిక ప్రయోగాలు DATA_BLOCK_ENCODING వంటి పరామితి యొక్క ముఖ్యమైన ప్రాముఖ్యతను చూపించాయి, ఇది పొరుగు కణాల నుండి విలువలను ఉపయోగించి సమాచారాన్ని ఎన్కోడ్ చేస్తుంది, ఇది యాదృచ్ఛికంగా రూపొందించబడిన డేటాకు అర్థం అవుతుంది. మీరు పెద్ద సంఖ్యలో నకిలీ వస్తువులను ఉపయోగిస్తే, లాభం గణనీయంగా ఉంటుంది. సాధారణంగా, HBase చాలా గంభీరమైన మరియు బాగా ఆలోచించదగిన డేటాబేస్ యొక్క ముద్రను ఇస్తుందని మేము చెప్పగలం, ఇది పెద్ద డేటా బ్లాక్‌లతో కార్యకలాపాలను నిర్వహించేటప్పుడు చాలా ఉత్పాదకతను కలిగి ఉంటుంది. ముఖ్యంగా చదవడం మరియు వ్రాయడం ప్రక్రియలను సకాలంలో వేరు చేయడం సాధ్యమైతే.

మీ అభిప్రాయంలో తగినంతగా వెల్లడించనిది ఏదైనా ఉంటే, నేను మీకు మరింత వివరంగా చెప్పడానికి సిద్ధంగా ఉన్నాను. మీ అనుభవాన్ని పంచుకోవడానికి లేదా మీరు దేనితో ఏకీభవించనట్లయితే చర్చించడానికి మేము మిమ్మల్ని ఆహ్వానిస్తున్నాము.

మూలం: www.habr.com