మా వినియోగదారులు అలసట తెలియకుండా ఒకరికొకరు సందేశాలు రాసుకుంటారు.
అది చాలా ఎక్కువ. మీరు అన్ని వినియోగదారుల సందేశాలను చదవడానికి బయలుదేరినట్లయితే, దీనికి 150 వేల సంవత్సరాల కంటే ఎక్కువ సమయం పడుతుంది. మీరు చాలా అధునాతన రీడర్ అని మరియు ప్రతి సందేశానికి సెకను కంటే ఎక్కువ సమయం కేటాయించకూడదని అందించారు.
అటువంటి డేటా పరిమాణంతో, దానిని నిల్వ చేయడానికి మరియు యాక్సెస్ చేయడానికి తర్కం ఉత్తమంగా నిర్మించబడటం చాలా కీలకం. లేకపోతే, ఒక అద్భుతమైన క్షణంలో, ప్రతిదీ త్వరలో తప్పుగా మారుతుందని స్పష్టమవుతుంది.
మాకు, ఈ క్షణం ఒకటిన్నర సంవత్సరం క్రితం వచ్చింది. మేము దీనికి ఎలా వచ్చాము మరియు చివరికి ఏమి జరిగింది - మేము మీకు క్రమంలో చెబుతాము.
చరిత్ర
మొదటి అమలులో, VKontakte సందేశాలు PHP బ్యాకెండ్ మరియు MySQL కలయికపై పని చేశాయి. చిన్న విద్యార్థి వెబ్‌సైట్‌కి ఇది పూర్తిగా సాధారణ పరిష్కారం. అయినప్పటికీ, ఈ సైట్ అనియంత్రితంగా పెరిగింది మరియు దాని కోసం డేటా స్ట్రక్చర్‌ల ఆప్టిమైజేషన్‌ను డిమాండ్ చేయడం ప్రారంభించింది.
2009 చివరిలో, మొదటి టెక్స్ట్-ఇంజిన్ రిపోజిటరీ వ్రాయబడింది మరియు 2010లో దానికి సందేశాలు బదిలీ చేయబడ్డాయి.
టెక్స్ట్-ఇంజిన్‌లో, సందేశాలు జాబితాలలో నిల్వ చేయబడ్డాయి - ఒక రకమైన “మెయిల్‌బాక్స్‌లు”. అటువంటి ప్రతి జాబితా uid ద్వారా నిర్ణయించబడుతుంది - ఈ సందేశాలన్నింటినీ కలిగి ఉన్న వినియోగదారు. సందేశం లక్షణాల సమితిని కలిగి ఉంటుంది: ఇంటర్‌లోక్యుటర్ ఐడెంటిఫైయర్, టెక్స్ట్, జోడింపులు మరియు మొదలైనవి. “బాక్స్” లోపల ఉన్న సందేశ ఐడెంటిఫైయర్ local_id, ఇది ఎప్పటికీ మారదు మరియు కొత్త సందేశాల కోసం వరుసగా కేటాయించబడుతుంది. "బాక్సులు" స్వతంత్రంగా ఉంటాయి మరియు ఇంజిన్ లోపల ఒకదానితో ఒకటి సమకాలీకరించబడవు; వాటి మధ్య కమ్యూనికేషన్ PHP స్థాయిలో జరుగుతుంది. మీరు లోపల నుండి టెక్స్ట్-ఇంజిన్ యొక్క డేటా నిర్మాణం మరియు సామర్థ్యాలను చూడవచ్చు .
ఇద్దరు వినియోగదారుల మధ్య కరస్పాండెన్స్ కోసం ఇది చాలా సరిపోతుంది. తర్వాత ఏం జరిగిందో ఊహించండి?
మే 2011లో, VKontakte అనేక మంది పాల్గొనే వారితో సంభాషణలను పరిచయం చేసింది-మల్టీ-చాట్. వారితో పని చేయడానికి, మేము రెండు కొత్త క్లస్టర్‌లను పెంచాము - మెంబర్-చాట్‌లు మరియు చాట్-సభ్యులు. మొదటిది వినియోగదారుల ద్వారా చాట్‌ల గురించి డేటాను నిల్వ చేస్తుంది, రెండవది చాట్‌ల ద్వారా వినియోగదారుల గురించి డేటాను నిల్వ చేస్తుంది. జాబితాలతో పాటు, ఇందులో, ఉదాహరణకు, ఆహ్వానించే వినియోగదారు మరియు వారు చాట్‌కు జోడించబడిన సమయం ఉంటాయి.
"PHP, చాట్‌కి సందేశం పంపుదాం" అని వినియోగదారు చెప్పారు.
“రండి, {username},” అని PHP చెప్పింది.
ఈ పథకానికి ప్రతికూలతలు ఉన్నాయి. సమకాలీకరణ ఇప్పటికీ PHP యొక్క బాధ్యత. పెద్ద చాట్‌లు మరియు వినియోగదారులకు ఏకకాలంలో సందేశాలు పంపడం ప్రమాదకరమైన కథ. టెక్స్ట్-ఇంజిన్ ఉదాహరణ uidపై ఆధారపడి ఉంటుంది కాబట్టి, చాట్ పాల్గొనేవారు వేర్వేరు సమయాల్లో ఒకే సందేశాన్ని స్వీకరించగలరు. పురోగతి నిలిచి ఉంటే దీనితో జీవించవచ్చు. కానీ అలా జరగదు.
2015 చివరిలో, మేము కమ్యూనిటీ సందేశాలను ప్రారంభించాము మరియు 2016 ప్రారంభంలో, మేము వాటి కోసం APIని ప్రారంభించాము. కమ్యూనిటీలలో పెద్ద చాట్‌బాట్‌లు రావడంతో, లోడ్ పంపిణీని కూడా మర్చిపోవడం సాధ్యమైంది.
మంచి బోట్ రోజుకు అనేక మిలియన్ సందేశాలను ఉత్పత్తి చేస్తుంది - చాలా మాట్లాడే వినియోగదారులు కూడా దీని గురించి గొప్పగా చెప్పుకోలేరు. దీనర్థం, అటువంటి బాట్‌లు నివసించిన టెక్స్ట్-ఇంజిన్ యొక్క కొన్ని సందర్భాలు పూర్తిగా బాధపడటం ప్రారంభించాయి.
2016లో మెసేజ్ ఇంజన్‌లు 100 చాట్-మెంబర్‌లు మరియు మెంబర్-చాట్‌లు మరియు 8000 టెక్స్ట్-ఇంజిన్‌లు. అవి వెయ్యి సర్వర్‌లలో హోస్ట్ చేయబడ్డాయి, ఒక్కొక్కటి 64 GB మెమరీతో ఉంటాయి. మొదటి అత్యవసర చర్యగా, మేము మెమరీని మరో 32 GB పెంచాము. మేము అంచనాలను అంచనా వేసాము. తీవ్రమైన మార్పులు లేకుండా, ఇది మరో సంవత్సరానికి సరిపోతుంది. మీరు హార్డ్‌వేర్‌ను పట్టుకోవాలి లేదా డేటాబేస్‌లను ఆప్టిమైజ్ చేయాలి.
ఆర్కిటెక్చర్ యొక్క స్వభావం కారణంగా, హార్డ్‌వేర్‌ను మల్టిపుల్‌లలో పెంచడం మాత్రమే అర్ధమే. అంటే, కనీసం కార్ల సంఖ్యను రెట్టింపు చేయడం - స్పష్టంగా, ఇది చాలా ఖరీదైన మార్గం. మేము ఆప్టిమైజ్ చేస్తాము.
కొత్త కాన్సెప్ట్
కొత్త విధానం యొక్క ప్రధాన సారాంశం చాట్. ఒక చాట్ దానికి సంబంధించిన సందేశాల జాబితాను కలిగి ఉంటుంది. వినియోగదారు చాట్‌ల జాబితాను కలిగి ఉన్నారు.
అవసరమైన కనిష్టం రెండు కొత్త డేటాబేస్‌లు:
- చాట్-ఇంజిన్. ఇది చాట్ వెక్టర్స్ రిపోజిటరీ. ప్రతి చాట్‌లో దానికి సంబంధించిన మెసేజ్‌ల వెక్టర్ ఉంటుంది. ప్రతి సందేశం చాట్‌లో ఒక వచనం మరియు ప్రత్యేక సందేశ ఐడెంటిఫైయర్‌ని కలిగి ఉంటుంది - chat_local_id.
- వినియోగదారు ఇంజిన్. ఇది వినియోగదారుల వెక్టర్‌ల నిల్వ - వినియోగదారులకు లింక్‌లు. ప్రతి వినియోగదారుకు peer_id (ఇంటర్‌లోక్యూటర్‌లు - ఇతర వినియోగదారులు, బహుళ-చాట్ లేదా కమ్యూనిటీలు) యొక్క వెక్టర్ మరియు సందేశాల వెక్టర్ ఉంటుంది. ప్రతి peer_idకి సంబంధించిన సందేశాల వెక్టర్ ఉంటుంది. ప్రతి సందేశానికి chat_local_id మరియు ఆ వినియోగదారు కోసం ఒక ప్రత్యేక సందేశం ID ఉంటుంది - user_local_id.
కొత్త క్లస్టర్‌లు TCPని ఉపయోగించి ఒకదానితో ఒకటి సంభాషించుకుంటాయి - ఇది అభ్యర్థనల క్రమం మారదని నిర్ధారిస్తుంది. వాటి కోసం అభ్యర్థనలు మరియు నిర్ధారణలు హార్డ్ డ్రైవ్‌లో నమోదు చేయబడతాయి - కాబట్టి మేము ఇంజిన్ వైఫల్యం లేదా పునఃప్రారంభించిన తర్వాత ఎప్పుడైనా క్యూ యొక్క స్థితిని పునరుద్ధరించవచ్చు. వినియోగదారు-ఇంజిన్ మరియు చాట్-ఇంజిన్ ఒక్కొక్కటి 4 వేల ముక్కలు ఉన్నందున, క్లస్టర్‌ల మధ్య అభ్యర్థన క్యూ సమానంగా పంపిణీ చేయబడుతుంది (కానీ వాస్తవానికి ఏదీ లేదు - మరియు ఇది చాలా త్వరగా పని చేస్తుంది).
చాలా సందర్భాలలో మా డేటాబేస్‌లలో డిస్క్‌తో పని చేయడం అనేది మార్పుల బైనరీ లాగ్ (బిన్‌లాగ్), స్టాటిక్ స్నాప్‌షాట్‌లు మరియు మెమరీలో పాక్షిక చిత్రం కలయికపై ఆధారపడి ఉంటుంది. పగటిపూట మార్పులు బిన్‌లాగ్‌కు వ్రాయబడతాయి మరియు ప్రస్తుత స్థితి యొక్క స్నాప్‌షాట్ క్రమానుగతంగా సృష్టించబడుతుంది. స్నాప్‌షాట్ అనేది మా ప్రయోజనాల కోసం ఆప్టిమైజ్ చేయబడిన డేటా స్ట్రక్చర్‌ల సమాహారం. ఇది హెడర్ (చిత్రం యొక్క మెటైన్‌డెక్స్) మరియు మెటాఫైల్‌ల సమితిని కలిగి ఉంటుంది. హెడర్ శాశ్వతంగా RAMలో నిల్వ చేయబడుతుంది మరియు స్నాప్‌షాట్ నుండి డేటా కోసం ఎక్కడ వెతకాలో సూచిస్తుంది. ప్రతి మెటాఫైల్ సమయానికి దగ్గరగా ఉండే డేటాను కలిగి ఉంటుంది-ఉదాహరణకు, ఒకే వినియోగదారుకు సంబంధించినది. మీరు స్నాప్‌షాట్ హెడర్‌ని ఉపయోగించి డేటాబేస్‌ను ప్రశ్నించినప్పుడు, అవసరమైన మెటాఫైల్ చదవబడుతుంది, ఆపై స్నాప్‌షాట్ సృష్టించబడిన తర్వాత సంభవించిన బిన్‌లాగ్‌లో మార్పులు పరిగణనలోకి తీసుకోబడతాయి. మీరు ఈ విధానం యొక్క ప్రయోజనాల గురించి మరింత చదువుకోవచ్చు .
అదే సమయంలో, హార్డ్ డ్రైవ్‌లోని డేటా రోజుకు ఒకసారి మాత్రమే మారుతుంది - మాస్కోలో అర్థరాత్రి, లోడ్ తక్కువగా ఉన్నప్పుడు. దీనికి ధన్యవాదాలు (డిస్క్‌లోని నిర్మాణం రోజంతా స్థిరంగా ఉంటుందని తెలుసుకోవడం), మేము వెక్టర్‌లను స్థిర పరిమాణంలోని శ్రేణులతో భర్తీ చేయగలము - మరియు దీని కారణంగా, మెమరీని పొందడం.
కొత్త పథకంలో సందేశాన్ని పంపడం ఇలా కనిపిస్తుంది:
- PHP బ్యాకెండ్ సందేశాన్ని పంపడానికి అభ్యర్థనతో వినియోగదారు-ఇంజిన్‌ను సంప్రదిస్తుంది.
- user-engine కావలసిన చాట్-ఇంజిన్ ఉదాహరణకి అభ్యర్థనను ప్రాక్సీ చేస్తుంది, ఇది వినియోగదారు-ఇంజిన్ chat_local_idకి తిరిగి వస్తుంది - ఈ చాట్‌లోని కొత్త సందేశం యొక్క ప్రత్యేక ఐడెంటిఫైయర్. chat_engine ఆ తర్వాత చాట్‌లోని స్వీకర్తలందరికీ సందేశాన్ని ప్రసారం చేస్తుంది.
- యూజర్-ఇంజిన్ చాట్-ఇంజిన్ నుండి chat_local_idని అందుకుంటుంది మరియు user_local_idని PHPకి అందిస్తుంది - ఈ వినియోగదారు కోసం ఒక ప్రత్యేక సందేశ ఐడెంటిఫైయర్. ఈ ఐడెంటిఫైయర్ ఉపయోగించబడుతుంది, ఉదాహరణకు, API ద్వారా సందేశాలతో పని చేయడానికి.
కానీ వాస్తవానికి సందేశాలను పంపడంతో పాటు, మీరు మరికొన్ని ముఖ్యమైన విషయాలను అమలు చేయాలి:
- సబ్‌లిస్ట్‌లు, ఉదాహరణకు, సంభాషణ జాబితాను తెరిచేటప్పుడు మీరు చూసే ఇటీవలి సందేశాలు. చదవని సందేశాలు, ట్యాగ్‌లతో సందేశాలు ("ముఖ్యమైనది", "స్పామ్" మొదలైనవి).
- చాట్-ఇంజిన్‌లో సందేశాలను కుదించడం
- వినియోగదారు-ఇంజిన్‌లో సందేశాలను కాషింగ్ చేస్తోంది
- శోధించండి (అన్ని డైలాగ్‌ల ద్వారా మరియు నిర్దిష్ట దానిలో).
- నిజ-సమయ నవీకరణ (లాంగ్‌పోలింగ్).
- మొబైల్ క్లయింట్‌లలో కాషింగ్‌ని అమలు చేయడానికి చరిత్రను సేవ్ చేస్తోంది.
అన్ని సబ్‌లిస్ట్‌లు నిర్మాణాలను వేగంగా మారుస్తున్నాయి. వారితో పని చేయడానికి మేము ఉపయోగిస్తాము . చెట్టు పైభాగంలో మేము కొన్నిసార్లు స్నాప్‌షాట్ నుండి సందేశాల మొత్తం విభాగాన్ని నిల్వ చేస్తాము అనే వాస్తవం ద్వారా ఈ ఎంపిక వివరించబడింది - ఉదాహరణకు, రాత్రి రీఇండెక్సింగ్ తర్వాత, చెట్టు ఒక టాప్‌ను కలిగి ఉంటుంది, ఇందులో సబ్‌లిస్ట్ యొక్క అన్ని సందేశాలు ఉంటాయి. స్ప్లే ట్రీ బ్యాలెన్సింగ్ గురించి ఆలోచించకుండా అటువంటి శీర్షం మధ్యలోకి చొప్పించడాన్ని సులభతరం చేస్తుంది. అదనంగా, Splay అనవసరమైన డేటాను నిల్వ చేయదు, ఇది మనకు మెమరీని ఆదా చేస్తుంది.
సందేశాలు పెద్ద మొత్తంలో సమాచారాన్ని కలిగి ఉంటాయి, ఎక్కువగా టెక్స్ట్, ఇది కుదించడానికి ఉపయోగపడుతుంది. ఒక వ్యక్తి సందేశాన్ని కూడా మనం ఖచ్చితంగా అన్‌ఆర్కైవ్ చేయడం ముఖ్యం. సందేశాలను కుదించడానికి ఉపయోగిస్తారు మా స్వంత హ్యూరిస్టిక్స్‌తో - ఉదాహరణకు, సందేశాలలో పదాలు “పదాలు కానివి” - ఖాళీలు, విరామ చిహ్నాలు - ప్రత్యామ్నాయంగా ఉన్నాయని మాకు తెలుసు మరియు రష్యన్ భాష కోసం చిహ్నాలను ఉపయోగించడం యొక్క కొన్ని ప్రత్యేకతలను కూడా మేము గుర్తుంచుకుంటాము.
చాట్‌ల కంటే చాలా తక్కువ మంది వినియోగదారులు ఉన్నందున, రాండమ్-యాక్సెస్ డిస్క్ అభ్యర్థనలను చాట్-ఇంజిన్‌లో సేవ్ చేయడానికి, మేము యూజర్-ఇంజిన్‌లో సందేశాలను కాష్ చేస్తాము.
ఈ వినియోగదారు యొక్క చాట్‌లను కలిగి ఉన్న అన్ని చాట్-ఇంజిన్ సందర్భాలకు వినియోగదారు-ఇంజిన్ నుండి వికర్ణ ప్రశ్నగా సందేశ శోధన అమలు చేయబడుతుంది. ఫలితాలు వినియోగదారు-ఇంజిన్‌లోనే మిళితం చేయబడ్డాయి.
సరే, అన్ని వివరాలు పరిగణనలోకి తీసుకోబడ్డాయి, కొత్త స్కీమ్‌కు మారడం మాత్రమే మిగిలి ఉంది - మరియు వినియోగదారులు దానిని గమనించకుండా ఉండటం మంచిది.
డేటా మైగ్రేషన్
కాబట్టి, మేము వినియోగదారు ద్వారా సందేశాలను నిల్వ చేసే టెక్స్ట్-ఇంజిన్‌ను కలిగి ఉన్నాము మరియు బహుళ-చాట్ రూమ్‌లు మరియు వాటిలోని వినియోగదారుల గురించి డేటాను నిల్వ చేసే రెండు క్లస్టర్‌లు చాట్-సభ్యులు మరియు మెంబర్-చాట్‌లు ఉన్నాయి. దీని నుండి కొత్త యూజర్ ఇంజిన్ మరియు చాట్ ఇంజిన్‌కి ఎలా మారాలి?
పాత స్కీమ్‌లోని సభ్యుల-చాట్‌లు ప్రధానంగా ఆప్టిమైజేషన్ కోసం ఉపయోగించబడ్డాయి. మేము దాని నుండి అవసరమైన డేటాను చాట్-సభ్యులకు త్వరగా బదిలీ చేసాము, ఆపై అది ఇకపై మైగ్రేషన్ ప్రక్రియలో పాల్గొనలేదు.
చాట్-సభ్యుల కోసం క్యూ. ఇందులో 100 ఉదంతాలు ఉన్నాయి, అయితే చాట్-ఇంజిన్‌లో 4 వేలు ఉన్నాయి. డేటాను బదిలీ చేయడానికి, మీరు దానిని సమ్మతిలోకి తీసుకురావాలి - దీని కోసం, చాట్-సభ్యులు అదే 4 వేల కాపీలుగా విభజించబడ్డారు, ఆపై చాట్-సభ్యుల బిన్‌లాగ్ చదవడం చాట్-ఇంజిన్‌లో ప్రారంభించబడింది.
ఇప్పుడు చాట్-ఇంజిన్‌కు చాట్-సభ్యుల నుండి బహుళ-చాట్ గురించి తెలుసు, కానీ ఇద్దరు సంభాషణకర్తలతో డైలాగ్‌ల గురించి దీనికి ఇంకా ఏమీ తెలియదు. ఇటువంటి డైలాగ్‌లు వినియోగదారుల సూచనతో టెక్స్ట్-ఇంజిన్‌లో ఉంటాయి. ఇక్కడ మేము "హెడ్-ఆన్" డేటాను తీసుకున్నాము: ప్రతి చాట్-ఇంజిన్ ఉదంతాలు అన్ని టెక్స్ట్-ఇంజిన్ ఉదంతాలకు అవసరమైన డైలాగ్‌ని కలిగి ఉంటే వాటిని అడిగాము.
గ్రేట్ - చాట్-ఇంజిన్‌కు మల్టీ-చాట్ చాట్‌లు ఏమిటో తెలుసు మరియు ఏ డైలాగ్‌లు ఉన్నాయో తెలుసు.
మీరు బహుళ-చాట్ చాట్‌లలో సందేశాలను కలపాలి, తద్వారా మీరు ప్రతి చాట్‌లో సందేశాల జాబితాతో ముగుస్తుంది. ముందుగా, చాట్-ఇంజిన్ ఈ చాట్ నుండి అన్ని వినియోగదారు సందేశాలను టెక్స్ట్-ఇంజిన్ నుండి తిరిగి పొందుతుంది. కొన్ని సందర్భాల్లో వాటిలో చాలా ఉన్నాయి (వందల మిలియన్ల వరకు), కానీ చాలా అరుదైన మినహాయింపులతో చాట్ పూర్తిగా RAMకి సరిపోతుంది. మేము ఆర్డర్ చేయని సందేశాలను కలిగి ఉన్నాము, ప్రతి ఒక్కటి అనేక కాపీలలో ఉన్నాయి - అన్నింటికంటే, అవన్నీ వినియోగదారులకు సంబంధించిన విభిన్న టెక్స్ట్-ఇంజిన్ సందర్భాల నుండి తీసివేయబడతాయి. సందేశాలను క్రమబద్ధీకరించడం మరియు అనవసరమైన స్థలాన్ని ఆక్రమించే కాపీలను తొలగించడం లక్ష్యం.
ప్రతి సందేశానికి అది పంపబడిన సమయం మరియు వచనాన్ని కలిగి ఉన్న టైమ్‌స్టాంప్ ఉంటుంది. మేము క్రమబద్ధీకరించడానికి సమయాన్ని ఉపయోగిస్తాము - మేము మల్టీచాట్ పాల్గొనేవారి యొక్క పురాతన సందేశాలకు పాయింటర్‌లను ఉంచుతాము మరియు టైమ్‌స్టాంప్‌ను పెంచడానికి ఉద్దేశించిన కాపీల టెక్స్ట్ నుండి హ్యాష్‌లను సరిపోల్చాము. కాపీలు ఒకే హాష్ మరియు టైమ్‌స్టాంప్‌ను కలిగి ఉండటం తార్కికం, కానీ ఆచరణలో ఇది ఎల్లప్పుడూ అలా ఉండదు. మీకు గుర్తున్నట్లుగా, పాత స్కీమ్‌లో సమకాలీకరణ PHP ద్వారా నిర్వహించబడింది - మరియు అరుదైన సందర్భాల్లో, ఒకే సందేశాన్ని పంపే సమయం వేర్వేరు వినియోగదారులలో భిన్నంగా ఉంటుంది. ఈ సందర్భాలలో, మేము టైమ్‌స్టాంప్‌ని సవరించడానికి అనుమతించాము - సాధారణంగా ఒక సెకనులోపు. రెండవ సమస్య వివిధ గ్రహీతలకు సందేశాల యొక్క విభిన్న క్రమం. అటువంటి సందర్భాలలో, వేర్వేరు వినియోగదారుల కోసం వేర్వేరు ఆర్డర్ ఎంపికలతో అదనపు కాపీని సృష్టించడానికి మేము అనుమతించాము.
దీని తర్వాత, మల్టీచాట్‌లోని సందేశాల గురించిన డేటా వినియోగదారు ఇంజిన్‌కు పంపబడుతుంది. మరియు ఇక్కడ దిగుమతి చేసుకున్న సందేశాల యొక్క అసహ్యకరమైన లక్షణం వస్తుంది. సాధారణ ఆపరేషన్‌లో, ఇంజిన్‌కు వచ్చే సందేశాలు user_local_id ద్వారా ఖచ్చితంగా ఆరోహణ క్రమంలో ఆర్డర్ చేయబడతాయి. పాత ఇంజిన్ నుండి వినియోగదారు ఇంజిన్‌లోకి దిగుమతి చేయబడిన సందేశాలు ఈ ఉపయోగకరమైన లక్షణాన్ని కోల్పోయాయి. అదే సమయంలో, పరీక్ష సౌలభ్యం కోసం, మీరు వాటిని త్వరగా యాక్సెస్ చేయగలగాలి, వాటిలో ఏదైనా చూడండి మరియు కొత్త వాటిని జోడించాలి.
దిగుమతి చేసుకున్న సందేశాలను నిల్వ చేయడానికి మేము ప్రత్యేక డేటా నిర్మాణాన్ని ఉపయోగిస్తాము.
ఇది పరిమాణం యొక్క వెక్టర్‌ను సూచిస్తుంది అందరూ ఎక్కడ ఉన్నారు - మూలకాల యొక్క ప్రత్యేక క్రమంతో విభిన్నంగా మరియు అవరోహణ క్రమంలో క్రమబద్ధంగా ఉంటాయి. సూచికలతో ప్రతి విభాగంలో మూలకాలు క్రమబద్ధీకరించబడతాయి. అటువంటి నిర్మాణంలో మూలకం కోసం శోధించడానికి సమయం పడుతుంది ద్వారా బైనరీ శోధనలు. మూలకం యొక్క జోడింపు విమోచన చేయబడింది .
కాబట్టి, పాత ఇంజిన్ల నుండి కొత్త వాటికి డేటాను ఎలా బదిలీ చేయాలో మేము కనుగొన్నాము. కానీ ఈ ప్రక్రియ చాలా రోజులు పడుతుంది - మరియు ఈ రోజుల్లో మా వినియోగదారులు ఒకరికొకరు వ్రాసే అలవాటును వదులుకునే అవకాశం లేదు. ఈ సమయంలో సందేశాలను కోల్పోకుండా ఉండటానికి, మేము పాత మరియు కొత్త క్లస్టర్‌లను ఉపయోగించే వర్క్ స్కీమ్‌కి మారతాము.
డేటా చాట్-సభ్యులకు మరియు వినియోగదారు-ఇంజిన్‌కు వ్రాయబడుతుంది (మరియు పాత పథకం ప్రకారం సాధారణ ఆపరేషన్‌లో వలె టెక్స్ట్-ఇంజిన్‌కు కాదు). యూజర్-ఇంజిన్ చాట్-ఇంజిన్ అభ్యర్థనను ప్రాక్సీ చేస్తుంది - మరియు ఇక్కడ ప్రవర్తన ఈ చాట్ ఇప్పటికే విలీనం చేయబడిందా లేదా అనే దానిపై ఆధారపడి ఉంటుంది. చాట్ ఇంకా విలీనం కానట్లయితే, చాట్-ఇంజిన్ తనకు తానుగా సందేశాన్ని వ్రాయదు మరియు దాని ప్రాసెసింగ్ టెక్స్ట్-ఇంజిన్‌లో మాత్రమే జరుగుతుంది. చాట్ ఇప్పటికే చాట్-ఇంజిన్‌లో విలీనం చేయబడి ఉంటే, అది chat_local_idని వినియోగదారు-ఇంజిన్‌కి తిరిగి పంపుతుంది మరియు అందరు స్వీకర్తలకు సందేశాన్ని పంపుతుంది. యూజర్-ఇంజిన్ మొత్తం డేటాను టెక్స్ట్-ఇంజిన్‌కి ప్రాక్సీ చేస్తుంది - తద్వారా ఏదైనా జరిగితే, పాత ఇంజిన్‌లో ఉన్న ప్రస్తుత డేటా మొత్తాన్ని మనం ఎల్లప్పుడూ వెనక్కి తీసుకోవచ్చు. టెక్స్ట్-ఇంజిన్ user_local_idని అందిస్తుంది, ఇది వినియోగదారు-ఇంజిన్ నిల్వ చేసి బ్యాకెండ్‌కు తిరిగి వస్తుంది.
ఫలితంగా, పరివర్తన ప్రక్రియ ఇలా కనిపిస్తుంది: మేము ఖాళీ వినియోగదారు-ఇంజిన్ మరియు చాట్-ఇంజిన్ క్లస్టర్‌లను కనెక్ట్ చేస్తాము. chat-engine మొత్తం చాట్-సభ్యుల బిన్‌లాగ్‌ను చదువుతుంది, ఆపై పైన వివరించిన పథకం ప్రకారం ప్రాక్సీ చేయడం ప్రారంభమవుతుంది. మేము పాత డేటాను బదిలీ చేస్తాము మరియు రెండు సమకాలీకరించబడిన క్లస్టర్‌లను (పాత మరియు కొత్తవి) పొందుతాము. టెక్స్ట్-ఇంజిన్ నుండి వినియోగదారు-ఇంజిన్‌కు పఠనాన్ని మార్చడం మరియు ప్రాక్సీయింగ్‌ను నిలిపివేయడం మాత్రమే మిగిలి ఉంది.
Результаты
కొత్త విధానానికి ధన్యవాదాలు, ఇంజిన్ల యొక్క అన్ని పనితీరు కొలమానాలు మెరుగుపరచబడ్డాయి మరియు డేటా స్థిరత్వంతో సమస్యలు పరిష్కరించబడ్డాయి. ఇప్పుడు మేము మెసేజ్‌లలో కొత్త ఫీచర్‌లను త్వరగా అమలు చేయగలము (మరియు ఇప్పటికే దీన్ని చేయడం ప్రారంభించాము - మేము గరిష్టంగా చాట్ పాల్గొనేవారి సంఖ్యను పెంచాము, ఫార్వార్డ్ చేసిన సందేశాల కోసం శోధనను అమలు చేసాము, పిన్ చేసిన సందేశాలను ప్రారంభించాము మరియు ప్రతి వినియోగదారుకు మొత్తం సందేశాల సంఖ్యపై పరిమితిని పెంచాము) .
తర్కంలో మార్పులు నిజంగా అపారమైనవి. మరియు ఇది ఎల్లప్పుడూ భారీ బృందం మరియు అనేక కోడ్ లైన్ల ద్వారా పూర్తి సంవత్సరాల అభివృద్ధిని సూచించదని నేను గమనించాలనుకుంటున్నాను. చాట్-ఇంజిన్ మరియు యూజర్-ఇంజిన్‌తో పాటు మెసేజ్ కంప్రెషన్ కోసం హఫ్ఫ్మన్, స్ప్లే ట్రీస్ మరియు ఇంపోర్ట్ చేసిన మెసేజ్‌ల కోసం స్ట్రక్చర్ వంటి అన్ని అదనపు కథనాలతో పాటు 20 వేల లైన్ల కంటే తక్కువ కోడ్ ఉంటుంది. మరియు అవి కేవలం 3 నెలల్లో 10 డెవలపర్‌లచే వ్రాయబడ్డాయి (అయితే, దానిని గుర్తుంచుకోవడం విలువ - ప్రపంచ ఛాంపియన్లు ).
అంతేకాకుండా, సర్వర్‌ల సంఖ్యను రెట్టింపు చేయడానికి బదులుగా, మేము వాటి సంఖ్యను సగానికి తగ్గించాము - ఇప్పుడు వినియోగదారు-ఇంజిన్ మరియు చాట్-ఇంజిన్ 500 భౌతిక మెషీన్‌లలో ప్రత్యక్ష ప్రసారం చేస్తాయి, అయితే కొత్త పథకం లోడ్ కోసం పెద్ద హెడ్‌రూమ్‌ను కలిగి ఉంది. మేము పరికరాలపై చాలా డబ్బు ఆదా చేసాము - నిర్వహణ ఖర్చులలో సంవత్సరానికి $5 మిలియన్ + $750 వేలు.
మేము అత్యంత సంక్లిష్టమైన మరియు పెద్ద-స్థాయి సమస్యలకు ఉత్తమ పరిష్కారాలను కనుగొనడానికి ప్రయత్నిస్తాము. మా వద్ద అవి పుష్కలంగా ఉన్నాయి - అందుకే మేము డేటాబేస్ విభాగంలో ప్రతిభావంతులైన డెవలపర్‌ల కోసం చూస్తున్నాము. మీరు ఇష్టపడితే మరియు అటువంటి సమస్యలను ఎలా పరిష్కరించాలో తెలిస్తే, అల్గారిథమ్‌లు మరియు డేటా స్ట్రక్చర్‌ల గురించి అద్భుతమైన పరిజ్ఞానం ఉంటే, మేము మిమ్మల్ని బృందంలో చేరమని ఆహ్వానిస్తున్నాము. మా సంప్రదించండి వివరాల కోసం.
ఈ కథనం మీ గురించి కాకపోయినా, దయచేసి మేము సిఫార్సులకు విలువ ఇస్తున్నామని గుర్తుంచుకోండి. గురించి స్నేహితుడికి చెప్పండి , మరియు అతను ప్రొబేషనరీ వ్యవధిని విజయవంతంగా పూర్తి చేస్తే, మీరు 100 వేల రూబిళ్లు బోనస్ అందుకుంటారు.
మూలం: www.habr.com