హైలోడ్++ మాస్కో 2018, కాంగ్రెస్ హాల్. నవంబర్ 9, 15:00
సారాంశాలు మరియు ప్రదర్శన:
యూరి నస్రెట్డినోవ్ (VKontakte): నివేదిక మా కంపెనీలో క్లిక్‌హౌస్‌ను అమలు చేసిన అనుభవం గురించి మాట్లాడుతుంది - మనకు ఇది ఎందుకు అవసరం, ఎంత డేటాను నిల్వ చేస్తాము, ఎలా వ్రాస్తాము మరియు మొదలైనవి.
అదనపు పదార్థాలు:
యూరి నస్రెట్డినోవ్: - అందరికి వందనాలు! నా పేరు యూరి నస్రెట్డినోవ్, నేను ఇప్పటికే పరిచయం చేసుకున్నాను. నేను VKontakteలో పని చేస్తున్నాను. నేను మా సర్వర్ ఫ్లీట్ (పదివేల) నుండి క్లిక్‌హౌస్‌లోకి డేటాను ఎలా చొప్పిస్తాము అనే దాని గురించి మాట్లాడతాను.
లాగ్‌లు అంటే ఏమిటి మరియు వాటిని ఎందుకు సేకరించాలి?
మేము మీకు ఏమి చెబుతాము: మేము ఏమి చేసాము, మనకు “క్లిక్‌హౌస్” ఎందుకు అవసరం, మేము దీన్ని ఎందుకు ఎంచుకున్నాము, ప్రత్యేకంగా ఏదైనా కాన్ఫిగర్ చేయకుండా మీరు ఏ విధమైన పనితీరును పొందవచ్చు. బఫర్ టేబుల్‌ల గురించి, వాటితో మాకు ఉన్న సమస్యల గురించి మరియు ఓపెన్ సోర్స్ నుండి మేము అభివృద్ధి చేసిన మా పరిష్కారాల గురించి నేను మీకు మరింత చెబుతాను - KittenHouse మరియు Lighthouse.
మనం ఏదైనా ఎందుకు చేయాల్సి వచ్చింది (VKontakteలో ప్రతిదీ ఎల్లప్పుడూ మంచిది, సరియైనదా?). మేము డీబగ్ లాగ్లను సేకరించాలనుకుంటున్నాము (మరియు అక్కడ వందల కొద్దీ టెరాబైట్ల డేటా ఉంది), బహుశా గణాంకాలను లెక్కించడం మరింత సౌకర్యవంతంగా ఉంటుంది; మరియు మన దగ్గర పదివేల సర్వర్‌ల సముదాయం ఉంది, వీటన్నింటికీ ఇది అవసరం.
మేము ఎందుకు నిర్ణయించుకున్నాము? లాగ్లను నిల్వ చేయడానికి మేము బహుశా పరిష్కారాలను కలిగి ఉన్నాము. ఇక్కడ - అటువంటి పబ్లిక్ "బ్యాకెండ్ VK" ఉంది. దానికి సబ్‌స్క్రయిబ్ చేయమని నేను బాగా సిఫార్సు చేస్తున్నాను.
లాగ్‌లు అంటే ఏమిటి? ఇది ఖాళీ శ్రేణులను తిరిగి ఇచ్చే ఇంజిన్. VKలోని ఇంజిన్లను ఇతరులు మైక్రోసర్వీస్ అని పిలుస్తారు. మరియు ఇక్కడ నవ్వుతున్న స్టిక్కర్ ఉంది (చాలా ఎక్కువ ఇష్టాలు). అది ఎలా? బాగా, ఇంకా వినండి!
లాగ్లను నిల్వ చేయడానికి ఏమి ఉపయోగించవచ్చు? హడప్ చెప్పకుండా ఉండలేం. అప్పుడు, ఉదాహరణకు, Rsyslog (ఈ లాగ్లను ఫైల్‌లలో నిల్వ చేయడం). LSD. LSD అంటే ఏమిటో ఎవరికి తెలుసు? లేదు, ఈ LSD కాదు. ఫైల్‌లను కూడా వరుసగా నిల్వ చేయండి. బాగా, క్లిక్‌హౌస్ ఒక వింత ఎంపిక.
క్లిక్‌హౌస్ మరియు పోటీదారులు: అవసరాలు మరియు అవకాశాలు
మనకేం కావాలి? మేము ఆపరేషన్ గురించి ఎక్కువగా ఆందోళన చెందాల్సిన అవసరం లేదని మేము నిర్ధారించుకోవాలనుకుంటున్నాము, తద్వారా ఇది తక్కువ కాన్ఫిగరేషన్‌తో పని చేస్తుంది. మేము చాలా వ్రాయాలనుకుంటున్నాము మరియు త్వరగా వ్రాయండి. మరియు మేము దానిని అన్ని రకాల నెలలు, సంవత్సరాలు, అంటే చాలా కాలం పాటు ఉంచాలనుకుంటున్నాము. వారు మా వద్దకు వచ్చి, "ఇక్కడ ఏదో పని చేయడం లేదు" అని చెప్పిన కొన్ని సమస్యను మనం అర్థం చేసుకోవాలనుకోవచ్చు మరియు అది 3 నెలల క్రితం జరిగింది), మరియు మేము 3 నెలల క్రితం ఏమి జరిగిందో చూడగలగాలి " డేటా కంప్రెషన్ - ఇది ఎందుకు ప్లస్ అవుతుందో స్పష్టంగా ఉంది - ఎందుకంటే ఇది ఆక్రమించే స్థలాన్ని తగ్గిస్తుంది.
మరియు మనకు అలాంటి ఆసక్తికరమైన అవసరం ఉంది: మేము కొన్నిసార్లు కొన్ని ఆదేశాల అవుట్‌పుట్‌ను వ్రాస్తాము (ఉదాహరణకు, లాగ్‌లు), ఇది చాలా సులభంగా 4 కిలోబైట్‌ల కంటే ఎక్కువగా ఉంటుంది. మరియు ఈ విషయం UDP కంటే పని చేస్తే, అది ఖర్చు చేయవలసిన అవసరం లేదు ... ఇది కనెక్షన్ కోసం "ఓవర్ హెడ్" కలిగి ఉండదు మరియు పెద్ద సంఖ్యలో సర్వర్లకు ఇది ప్లస్ అవుతుంది.
ఓపెన్ సోర్స్ మనకు ఏమి ఆఫర్ చేస్తుందో చూద్దాం. మొదట, మనకు లాగ్స్ ఇంజిన్ ఉంది - ఇది మా ఇంజిన్; సూత్రప్రాయంగా, అతను ప్రతిదీ చేయగలడు, అతను పొడవైన పంక్తులు కూడా వ్రాయగలడు. సరే, ఇది డేటాను పారదర్శకంగా కుదించదు - మనకు కావాలంటే మనమే పెద్ద నిలువు వరుసలను కుదించవచ్చు... వాస్తవానికి, మేము కోరుకోము (వీలైతే). ఒకే సమస్య ఏమిటంటే, అతను తన జ్ఞాపకశక్తికి సరిపోయే వాటిని మాత్రమే ఇవ్వగలడు; మిగిలిన వాటిని చదవడానికి, మీరు ఈ ఇంజిన్ యొక్క బిన్‌లాగ్‌ను పొందాలి మరియు తదనుగుణంగా, దీనికి చాలా సమయం పడుతుంది.
ఏ ఇతర ఎంపికలు ఉన్నాయి? ఉదాహరణకు, "హడప్". ఆపరేషన్ సౌలభ్యం... హడప్‌ను ఏర్పాటు చేయడం సులభం అని ఎవరు భావిస్తున్నారు? వాస్తవానికి, రికార్డింగ్‌లో ఎటువంటి సమస్యలు లేవు. చదివేటప్పుడు, కొన్నిసార్లు ప్రశ్నలు తలెత్తుతాయి. సూత్రప్రాయంగా, నేను బహుశా లాగ్‌ల కోసం కాదు అని చెబుతాను. దీర్ఘకాలిక నిల్వ - వాస్తవానికి, అవును, డేటా కంప్రెషన్ - అవును, పొడవైన స్ట్రింగ్‌లు - మీరు రికార్డ్ చేయగలరని స్పష్టంగా తెలుస్తుంది. కానీ పెద్ద సంఖ్యలో సర్వర్‌ల నుండి రికార్డింగ్... మీరు ఇంకా మీరే ఏదైనా చేయాలి!
Rsyslog. వాస్తవానికి, మేము దానిని బ్యాకప్ ఎంపికగా ఉపయోగించాము, తద్వారా మేము బిన్‌లాగ్‌ను డంప్ చేయకుండా చదవగలము, కానీ ఇది పొడవైన పంక్తులను వ్రాయదు; సూత్రప్రాయంగా, ఇది 4 కిలోబైట్‌ల కంటే ఎక్కువ వ్రాయదు. అదే విధంగా డేటా కంప్రెషన్‌ను మీరే చేయాలి. చదవడం ఫైల్‌ల నుండి వస్తుంది.
అప్పుడు LSD యొక్క "బాదుష్కా" అభివృద్ధి ఉంది. ముఖ్యంగా “Rsyslog” వలె ఉంటుంది: ఇది పొడవైన తీగలకు మద్దతు ఇస్తుంది, కానీ ఇది UDP ద్వారా పని చేయదు మరియు వాస్తవానికి, దీని కారణంగా, దురదృష్టవశాత్తు, చాలా విషయాలు అక్కడ తిరిగి వ్రాయవలసి ఉంటుంది. పదివేల సర్వర్‌ల నుండి రికార్డ్ చేయడానికి LSDని రీడిజైన్ చేయాలి.
మరియు ఇక్కడ! ఒక తమాషా ఎంపిక సాగే శోధన. ఎలా చెప్పాలి? అతను చదవడంలో బాగానే ఉన్నాడు, అంటే, అతను త్వరగా చదువుతాడు, కానీ రాయడంలో బాగా లేదు. ముందుగా, ఇది డేటాను కుదిస్తే, అది చాలా బలహీనంగా ఉంటుంది. చాలా మటుకు, పూర్తి శోధనకు అసలు వాల్యూమ్ కంటే పెద్ద డేటా నిర్మాణాలు అవసరం. ఆపరేట్ చేయడం కష్టం మరియు దానితో తరచుగా సమస్యలు తలెత్తుతాయి. మరియు, మళ్ళీ, ఎలాస్టిక్ లో రికార్డింగ్ - మేము ప్రతిదీ మనమే చేయాలి.
ఇక్కడ క్లిక్‌హౌస్ ఆదర్శవంతమైన ఎంపిక. పదుల సంఖ్యలో సర్వర్‌ల నుండి రికార్డ్ చేయడం సమస్య మాత్రమే. కానీ కనీసం ఒక సమస్య ఉంది, మేము దానిని ఎలాగైనా పరిష్కరించడానికి ప్రయత్నించవచ్చు. మరియు మిగిలిన నివేదిక ఈ సమస్య గురించి. క్లిక్‌హౌస్ నుండి మీరు ఎలాంటి పనితీరును ఆశించవచ్చు?
మేము దానిని ఎలా చొప్పించబోతున్నాం? మెర్జ్ ట్రీ
“క్లిక్‌హౌస్” గురించి మీలో ఎవరు వినలేదు లేదా తెలియదు? నేను మీకు చెప్పాలి, కాదా? చాలా త్వరగా. అక్కడ చొప్పించడం - సెకనుకు 1-2 గిగాబిట్‌లు, సెకనుకు 10 గిగాబిట్ల వరకు పేలుళ్లు వాస్తవానికి ఈ కాన్ఫిగరేషన్‌ను తట్టుకోగలవు - రెండు 6-కోర్ జియాన్‌లు (అంటే అత్యంత శక్తివంతమైనవి కూడా కాదు), 256 గిగాబైట్ల ర్యామ్, 20 టెరాబైట్‌లు ఉన్నాయి. RAIDలో (ఎవరూ కాన్ఫిగర్ చేయబడలేదు, డిఫాల్ట్ సెట్టింగ్‌లు). అలెక్సీ మిలోవిడోవ్, క్లిక్‌హౌస్ డెవలపర్, బహుశా మేము దేన్నీ కాన్ఫిగర్ చేయనందున ఏడుస్తూ కూర్చుంటాడు (ప్రతిదీ మనకు అలా పనిచేసింది). దీని ప్రకారం, డేటా బాగా కుదించబడితే సెకనుకు దాదాపు 6 బిలియన్ లైన్ల స్కానింగ్ వేగం పొందవచ్చు. మీరు టెక్స్ట్ స్ట్రింగ్‌లో % ఇష్టపడితే - సెకనుకు 100 మిలియన్ లైన్‌లు, అంటే, ఇది చాలా వేగంగా కనిపిస్తుంది.
మేము దానిని ఎలా చొప్పించబోతున్నాం? బాగా, VK PHPని ఉపయోగిస్తుందని మీకు తెలుసు. మేము ప్రతి PHP వర్కర్ నుండి HTTP ద్వారా "ClickHouse"లోకి, ప్రతి రికార్డ్ కోసం MergeTree పట్టికలోకి చొప్పిస్తాము. ఈ పథకంలో సమస్యను ఎవరు చూస్తారు? కొన్ని కారణాల వల్ల, అందరూ చేతులు ఎత్తలేదు. నన్ను చెప్పనివ్వండి.
మొదట, చాలా సర్వర్లు ఉన్నాయి - తదనుగుణంగా, చాలా కనెక్షన్లు (చెడు) ఉంటాయి. అప్పుడు సెకనుకు ఒకసారి కంటే ఎక్కువసార్లు మెర్జ్‌ట్రీలో డేటాను ఇన్సర్ట్ చేయడం మంచిది. మరి ఎందుకో ఎవరికి తెలుసు? సరే సరే. దీని గురించి కొంచెం ఎక్కువ చెబుతాను. మరో ఆసక్తికరమైన ప్రశ్న ఏమిటంటే, మేము విశ్లేషణలు చేయడం లేదు, మేము డేటాను మెరుగుపరచాల్సిన అవసరం లేదు, మాకు ఇంటర్మీడియట్ సర్వర్లు అవసరం లేదు, మేము నేరుగా “ClickHouse”లోకి చొప్పించాలనుకుంటున్నాము (ప్రాధాన్యంగా - మరింత నేరుగా, మంచిది).
దీని ప్రకారం, మెర్జ్‌ట్రీలో చొప్పించడం ఎలా జరుగుతుంది? సెకనుకు ఒకసారి లేదా తక్కువ తరచుగా దానిలోకి చొప్పించడం ఎందుకు మంచిది? వాస్తవం ఏమిటంటే “క్లిక్‌హౌస్” అనేది స్తంభాల డేటాబేస్ మరియు డేటాను ప్రాథమిక కీ యొక్క ఆరోహణ క్రమంలో క్రమబద్ధీకరిస్తుంది మరియు మీరు ఇన్సర్ట్ చేసినప్పుడు, డేటా క్రమబద్ధీకరించబడిన నిలువు వరుసల సంఖ్యకు సమానమైన అనేక ఫైల్‌లు సృష్టించబడతాయి. ప్రాథమిక కీ యొక్క ఆరోహణ క్రమంలో (ఒక ప్రత్యేక డైరెక్టరీ సృష్టించబడుతుంది, ప్రతి ఇన్సర్ట్ కోసం డిస్క్‌లోని ఫైల్‌ల సమితి). అప్పుడు తదుపరి చొప్పించడం వస్తుంది, మరియు నేపథ్యంలో అవి పెద్ద "విభజనలు" గా మిళితం చేయబడతాయి. డేటా క్రమబద్ధీకరించబడినందున, ఎక్కువ మెమరీని వినియోగించకుండా రెండు క్రమబద్ధీకరించబడిన ఫైల్‌లను "విలీనం" చేయడం సాధ్యపడుతుంది.
కానీ, మీరు ఊహించినట్లుగా, మీరు ప్రతి ఇన్సర్ట్ కోసం 10 ఫైల్‌లను వ్రాస్తే, క్లిక్‌హౌస్ (లేదా మీ సర్వర్) త్వరగా ముగుస్తుంది, కాబట్టి పెద్ద బ్యాచ్‌లలో చొప్పించమని సిఫార్సు చేయబడింది. దీని ప్రకారం, మేము ఉత్పత్తిలో మొదటి పథకాన్ని ప్రారంభించలేదు. మేము వెంటనే ఒకదాన్ని ప్రారంభించాము, ఇక్కడ నంబర్ 2 ఉంది:
ఇక్కడ మేము ప్రారంభించిన సుమారు వెయ్యి సర్వర్లు ఉన్నాయని ఊహించుకోండి, కేవలం PHP ఉంది. మరియు ప్రతి సర్వర్‌లో మా స్థానిక ఏజెంట్ ఉంది, దానిని మేము "కిట్టెన్‌హౌస్" అని పిలుస్తాము, ఇది "ClickHouse"తో ఒక కనెక్షన్‌ని నిర్వహిస్తుంది మరియు ప్రతి కొన్ని సెకన్లకు డేటాను ఇన్సర్ట్ చేస్తుంది. డేటాను MergeTreeలోకి కాకుండా బఫర్ పట్టికలోకి చొప్పిస్తుంది, ఇది వెంటనే MergeTreeలోకి నేరుగా ఇన్సర్ట్ చేయకుండా ఉండటానికి ఖచ్చితంగా ఉపయోగపడుతుంది.
బఫర్ పట్టికలతో పని చేస్తోంది
అదేంటి? బఫర్ టేబుల్స్ అనేది మెమొరీలో ఒక భాగం, అది ముక్కలుగా ఉంటుంది (అంటే, దానిని తరచుగా దానిలోకి చొప్పించవచ్చు). అవి అనేక ముక్కలను కలిగి ఉంటాయి మరియు ప్రతి ముక్కలు స్వతంత్ర బఫర్‌గా పనిచేస్తాయి మరియు అవి స్వతంత్రంగా ఫ్లష్ చేయబడతాయి (మీరు బఫర్‌లో చాలా ముక్కలు ఉంటే, సెకనుకు చాలా ఇన్సర్ట్‌లు ఉంటాయి). ఈ పట్టికల నుండి చదవడం సాధ్యమవుతుంది - అప్పుడు మీరు బఫర్ మరియు పేరెంట్ టేబుల్ యొక్క కంటెంట్‌ల యూనియన్‌ను చదివారు, కానీ ఈ సమయంలో వ్రాయడం బ్లాక్ చేయబడింది, కాబట్టి అక్కడ నుండి చదవకపోవడమే మంచిది. మరియు బఫర్ పట్టికలు చాలా మంచి QPSని చూపుతాయి, అంటే, 3 వేల QPS వరకు చొప్పించేటప్పుడు మీకు ఎటువంటి సమస్యలు ఉండవు. సర్వర్ శక్తిని కోల్పోతే, డేటాను కోల్పోవచ్చు, ఎందుకంటే ఇది మెమరీలో మాత్రమే నిల్వ చేయబడుతుంది.
అదే సమయంలో, బఫర్‌తో కూడిన పథకం ALTERని క్లిష్టతరం చేస్తుంది, ఎందుకంటే మీరు మొదట పాత స్కీమ్‌తో పాత బఫర్ పట్టికను వదలాలి (డేటా ఎక్కడైనా అదృశ్యం కాదు, ఎందుకంటే టేబుల్ తొలగించబడటానికి ముందు అది ఫ్లష్ చేయబడుతుంది). అప్పుడు మీరు మీకు అవసరమైన పట్టికను "మార్చండి" మరియు మళ్లీ బఫర్ పట్టికను సృష్టించండి. దీని ప్రకారం, బఫర్ పట్టిక లేనప్పుడు, మీ డేటా ఎక్కడికీ ప్రవహించదు, కానీ మీరు దానిని కనీసం స్థానికంగా డిస్క్‌లో కలిగి ఉండవచ్చు.
కిట్టెన్‌హౌస్ అంటే ఏమిటి మరియు అది ఎలా పని చేస్తుంది?
కిట్టెన్‌హౌస్ అంటే ఏమిటి? ఇది ప్రాక్సీ. ఏ భాషని ఊహించండి? నేను నా రిపోర్ట్‌లో చాలా హైప్ టాపిక్‌లను సేకరించాను - “క్లిక్‌హౌస్”, గో, బహుశా నేను ఇంకేదైనా గుర్తుంచుకుంటాను. అవును, ఇది గోలో వ్రాయబడింది, ఎందుకంటే నాకు సిలో ఎలా వ్రాయాలో నిజంగా తెలియదు, నేను కోరుకోవడం లేదు.
దీని ప్రకారం, ఇది ప్రతి సర్వర్‌తో కనెక్షన్‌ను నిర్వహిస్తుంది మరియు మెమరీకి వ్రాయగలదు. ఉదాహరణకు, మేము క్లిక్‌హౌస్‌కు ఎర్రర్ లాగ్లను వ్రాస్తే, క్లిక్‌హౌస్‌కు డేటాను ఇన్సర్ట్ చేయడానికి సమయం లేకపోతే (అన్నింటికంటే, చాలా ఎక్కువ వ్రాసినట్లయితే), అప్పుడు మేము మెమరీని పెంచుకోము - మేము మిగిలిన వాటిని విసిరివేస్తాము. ఎందుకంటే మనం సెకనుకు అనేక గిగాబిట్ల లోపాలను వ్రాస్తే, మనం బహుశా కొన్నింటిని విసిరివేయవచ్చు. కిట్టెన్‌హౌస్ దీన్ని చేయగలదు. అదనంగా, ఇది విశ్వసనీయమైన డెలివరీని చేయగలదు, అనగా స్థానిక మెషీన్‌లో డిస్క్‌కి వ్రాయడం మరియు ప్రతిసారీ (అక్కడ, ప్రతి రెండు సెకన్లకు ఒకసారి) ఈ ఫైల్ నుండి డేటాను బట్వాడా చేయడానికి ప్రయత్నిస్తుంది. మరియు మొదట మేము సాధారణ విలువల ఆకృతిని ఉపయోగించాము - కొన్ని బైనరీ ఫార్మాట్ కాదు, టెక్స్ట్ ఫార్మాట్ (సాధారణ SQL వలె).
కానీ అప్పుడు ఇది జరిగింది. మేము నమ్మదగిన డెలివరీని ఉపయోగించాము, లాగ్లను వ్రాసాము, ఆపై నిర్ణయించాము (ఇది షరతులతో కూడిన పరీక్ష క్లస్టర్)... ఇది చాలా గంటలు ఉంచబడింది మరియు తిరిగి తీసుకురాబడింది మరియు వెయ్యి సర్వర్‌ల నుండి చొప్పించడం ప్రారంభించబడింది - క్లిక్‌హౌస్‌లో ఇప్పటికీ ఒక “థ్రెడ్ ఆన్ కనెక్షన్” - తదనుగుణంగా, వెయ్యి కనెక్షన్‌లలో, క్రియాశీల చొప్పించడం సర్వర్‌లో సగటున ఒకటిన్నర వేల లోడ్‌కు దారితీస్తుంది. ఆశ్చర్యకరంగా, సర్వర్ అభ్యర్థనలను ఆమోదించింది, అయితే కొంత సమయం తర్వాత కూడా డేటా చొప్పించబడింది; కానీ సర్వర్‌కి సర్వ్ చేయడం చాలా కష్టంగా ఉంది...
nginxని జోడించండి
థ్రెడ్ పర్ కనెక్షన్ మోడల్ కోసం ఇటువంటి పరిష్కారం nginx. మేము క్లిక్‌హౌస్ ముందు nginxని ఇన్‌స్టాల్ చేసాము, అదే సమయంలో రెండు ప్రతిరూపాల కోసం బ్యాలెన్సింగ్‌ని సెటప్ చేసాము (మా ఇన్సర్ట్ వేగం 2 రెట్లు పెరిగింది, అయితే ఇది వాస్తవం కాదు) మరియు క్లిక్‌హౌస్‌కి కనెక్షన్‌ల సంఖ్యను పరిమితం చేసింది అప్‌స్ట్రీమ్ మరియు, తదనుగుణంగా, 50 కనెక్షన్‌లలో కంటే ఎక్కువ, ఇన్సర్ట్ చేయడంలో ఎటువంటి పాయింట్ లేదని తెలుస్తోంది.
ఈ స్కీమ్‌లో సాధారణంగా ప్రతికూలతలు ఉన్నాయని మేము గ్రహించాము, ఎందుకంటే ఇక్కడ మాకు ఒకే ఒక nginx ఉంది. దీని ప్రకారం, ఈ nginx క్రాష్ అయినట్లయితే, ప్రతిరూపాలు ఉన్నప్పటికీ, మేము డేటాను కోల్పోతాము లేదా కనీసం ఎక్కడైనా వ్రాయము. అందుకే సొంతంగా లోడ్ బ్యాలెన్సింగ్ చేసుకున్నాం. “క్లిక్‌హౌస్” ఇప్పటికీ లాగ్‌లకు అనుకూలంగా ఉందని మేము గ్రహించాము మరియు “దెయ్యం” కూడా తన లాగ్లను “క్లిక్‌హౌస్”లో రాయడం ప్రారంభించాడు - నిజాయితీగా ఉండటానికి. మేము ఇప్పటికీ ఇతర "దెయ్యాల" కోసం దీనిని ఉపయోగిస్తాము.
అప్పుడు మేము ఈ ఆసక్తికరమైన సమస్యను కనుగొన్నాము: మీరు SQL మోడ్‌లో చొప్పించే ప్రామాణికం కాని పద్ధతిని ఉపయోగిస్తే, అది పూర్తి స్థాయి AST-ఆధారిత SQL పార్సర్‌ని బలవంతం చేస్తుంది, ఇది చాలా నెమ్మదిగా ఉంటుంది. దీని ప్రకారం, ఇది ఎప్పటికీ జరగకుండా ఉండేలా మేము సెట్టింగ్‌లను జోడించాము. మేము లోడ్ బ్యాలెన్సింగ్, ఆరోగ్య తనిఖీలు చేసాము, తద్వారా ఒకరు చనిపోతే, మేము ఇప్పటికీ డేటాను వదిలివేస్తాము. మేము ఇప్పుడు విభిన్న క్లిక్‌హౌస్ క్లస్టర్‌లను కలిగి ఉండాల్సిన చాలా పట్టికలను కలిగి ఉన్నాము. మరియు మేము ఇతర ఉపయోగాల గురించి కూడా ఆలోచించడం ప్రారంభించాము - ఉదాహరణకు, మేము nginx మాడ్యూల్స్ నుండి లాగ్లను వ్రాయాలనుకుంటున్నాము, కానీ మా RPCని ఉపయోగించి ఎలా కమ్యూనికేట్ చేయాలో వారికి తెలియదు. సరే, నేను వారికి కనీసం ఎలాగైనా ఎలా పంపాలో నేర్పించాలనుకుంటున్నాను - ఉదాహరణకు, UDP ద్వారా లోకల్ హోస్ట్‌లో ఈవెంట్‌లను స్వీకరించి, ఆపై వాటిని క్లిక్‌హౌస్‌కి ఫార్వార్డ్ చేయడం.
పరిష్కారం నుండి ఒక అడుగు దూరంలో
చివరి పథకం ఇలా కనిపించడం ప్రారంభమైంది (ఈ పథకం యొక్క నాల్గవ వెర్షన్): క్లిక్‌హౌస్ ముందు ఉన్న ప్రతి సర్వర్‌లో nginx (అదే సర్వర్‌లో) ఉంది మరియు ఇది కేవలం 50 కనెక్షన్‌ల సంఖ్యపై పరిమితితో లోకల్ హోస్ట్‌కు అభ్యర్థనలను ప్రాక్సీ చేస్తుంది. ముక్కలు. మరియు ఈ పథకం ఇప్పటికే చాలా పని చేస్తోంది, దానితో ప్రతిదీ చాలా బాగుంది.
మేము సుమారు ఒక నెల పాటు ఇలా జీవించాము. అందరూ సంతోషించారు, వారు పట్టికలు జోడించారు, జోడించారు, జోడించారు... సాధారణంగా, మేము బఫర్ పట్టికలను జోడించిన విధానం చాలా సరైనది కాదని తేలింది (అది అలా ఉంచుదాం). మేము ప్రతి పట్టికలో 16 ముక్కలు చేసాము మరియు కొన్ని సెకన్ల ఫ్లాష్ విరామం; మాకు 20 పట్టికలు ఉన్నాయి మరియు ప్రతి టేబుల్ సెకనుకు 8 ఇన్సర్ట్‌లను పొందింది - మరియు ఈ సమయంలో “క్లిక్‌హౌస్” ప్రారంభమైంది... రికార్డులు మందగించడం ప్రారంభించాయి. వారు ఉత్తీర్ణత సాధించకపోవడమే కాదు... డిఫాల్ట్‌గా, అప్‌స్ట్రీమ్‌లో కనెక్షన్లు ముగిస్తే, అది అన్ని కొత్త అభ్యర్థనలకు “502”ని తిరిగి ఇచ్చేంత ఆసక్తికరమైన విషయం nginxకి ఉంది.
మరియు ఇక్కడ మేము కలిగి ఉన్నాము (నేను క్లిక్‌హౌస్‌లోని లాగ్లను చూసాను) దాదాపు సగం శాతం అభ్యర్థనలు విఫలమయ్యాయి. దీని ప్రకారం, డిస్క్ వినియోగం ఎక్కువగా ఉంది, చాలా విలీనాలు ఉన్నాయి. సరే, నేను ఏమి చేసాను? సహజంగానే, సరిగ్గా కనెక్షన్ మరియు అప్‌స్ట్రీమ్ ఎందుకు ముగిసిందో గుర్తించడానికి నేను బాధపడలేదు.
nginxని రివర్స్ ప్రాక్సీతో భర్తీ చేస్తోంది
దీన్ని మనమే నిర్వహించాలని నేను నిర్ణయించుకున్నాను, దానిని nginxకి వదిలివేయవలసిన అవసరం లేదు - nginxకి క్లిక్‌హౌస్‌లో ఏ పట్టికలు ఉన్నాయో తెలియదు మరియు నేను nginxని రివర్స్ ప్రాక్సీతో భర్తీ చేసాను, అది కూడా నేనే వ్రాసాను.
అతను ఏమి చేస్తున్నాడు? ఇది fasthttp లైబ్రరీ "goshnoy" ఆధారంగా పని చేస్తుంది, అంటే వేగంగా, దాదాపు nginx వలె వేగంగా ఉంటుంది. క్షమించండి, ఇగోర్, మీరు ఇక్కడ ఉన్నట్లయితే (గమనిక: ఇగోర్ సిసోవ్ nginx వెబ్ సర్వర్‌ని సృష్టించిన రష్యన్ ప్రోగ్రామర్). ఇది ఏ రకమైన ప్రశ్నలను అర్థం చేసుకోగలదు - ఇన్సర్ట్ లేదా సెలెక్ట్ చేయండి - తదనుగుణంగా, ఇది వివిధ రకాల ప్రశ్నల కోసం విభిన్న కనెక్షన్ పూల్‌లను కలిగి ఉంటుంది.
దీని ప్రకారం, చొప్పించే అభ్యర్థనలను పూర్తి చేయడానికి మాకు సమయం లేకపోయినా, "ఎంపికలు" పాస్ అవుతాయి మరియు వైస్ వెర్సా. మరియు ఇది డేటాను బఫర్ పట్టికలుగా సమూహపరుస్తుంది - ఒక చిన్న బఫర్‌తో: ఏవైనా లోపాలు, సింటాక్స్ లోపాలు మరియు మొదలైనవి ఉంటే - అవి మిగిలిన డేటాను పెద్దగా ప్రభావితం చేయవు, ఎందుకంటే మేము బఫర్ పట్టికలలోకి చొప్పించినప్పుడు, మేము చిన్న "బాచీ"ని కలిగి ఉంది మరియు అన్ని వాక్యనిర్మాణ దోషాలు ఈ చిన్న భాగాన్ని మాత్రమే ప్రభావితం చేశాయి; మరియు ఇక్కడ అవి ఇప్పటికే పెద్ద బఫర్‌ను ప్రభావితం చేస్తాయి. చిన్నది 1 మెగాబైట్, అంటే అంత చిన్నది కాదు.
సమకాలీకరణను చొప్పించడం మరియు తప్పనిసరిగా nginxని భర్తీ చేయడం, తప్పనిసరిగా nginx ఇంతకు ముందు చేసిన అదే పనిని చేస్తుంది - దీని కోసం మీరు స్థానిక “కిట్టెన్‌హౌస్”ని మార్చాల్సిన అవసరం లేదు. మరియు ఇది fasthttpని ఉపయోగిస్తుంది కాబట్టి, ఇది చాలా వేగంగా ఉంటుంది - మీరు రివర్స్ ప్రాక్సీ ద్వారా సింగిల్ ఇన్‌సర్ట్‌ల కోసం సెకనుకు 100 వేల కంటే ఎక్కువ అభ్యర్థనలను చేయవచ్చు. సిద్ధాంతపరంగా, మీరు కిట్టెన్‌హౌస్ రివర్స్ ప్రాక్సీలో ఒకేసారి ఒక పంక్తిని చొప్పించవచ్చు, అయితే మేము అలా చేయము.
పథకం ఇలా కనిపించడం ప్రారంభించింది: “కిట్టెన్‌హౌస్”, రివర్స్ ప్రాక్సీ అనేక అభ్యర్థనలను పట్టికలుగా సమూహపరుస్తుంది మరియు బఫర్ పట్టికలు వాటిని ప్రధాన వాటిలోకి చొప్పించాయి.
కిల్లర్ అనేది తాత్కాలిక పరిష్కారం, పిల్లి శాశ్వతమైనది
ఇదొక ఆసక్తికరమైన సమస్య... మీలో ఎవరైనా fasthttpని ఉపయోగించారా? POST అభ్యర్థనలతో ఫాస్ట్httpని ఎవరు ఉపయోగించారు? బహుశా, ఇది నిజంగా చేసి ఉండకూడదు, ఎందుకంటే ఇది డిఫాల్ట్‌గా అభ్యర్థన బాడీని బఫర్ చేస్తుంది మరియు మా బఫర్ పరిమాణం 16 మెగాబైట్‌లకు సెట్ చేయబడింది. చొప్పించడం ఏదో ఒక సమయంలో కొనసాగించడం ఆగిపోయింది మరియు అన్ని పదివేల సర్వర్‌ల నుండి 16-మెగాబైట్ భాగాలు రావడం ప్రారంభించాయి మరియు క్లిక్‌హౌస్‌కి పంపబడే ముందు అవన్నీ మెమరీలో బఫర్ చేయబడ్డాయి. దీని ప్రకారం, మెమరీ అయిపోయింది, అవుట్-ఆఫ్-మెమరీ కిల్లర్ వచ్చి రివర్స్ ప్రాక్సీని చంపాడు (లేదా "క్లిక్‌హౌస్", ఇది సిద్ధాంతపరంగా రివర్స్ ప్రాక్సీ కంటే ఎక్కువ "తినగలదు"). చక్రం పునరావృతమైంది. చాలా ఆహ్లాదకరమైన సమస్య కాదు. చాలా నెలల ఆపరేషన్ తర్వాత మాత్రమే మేము దీనిపై పొరపాట్లు చేసినప్పటికీ.
నేను ఏమి చేశాను? మళ్ళీ, సరిగ్గా ఏమి జరిగిందో అర్థం చేసుకోవడం నాకు నిజంగా ఇష్టం లేదు. మీరు మెమరీలోకి బఫర్ చేయకూడదని నేను చాలా స్పష్టంగా భావిస్తున్నాను. నేను ప్రయత్నించినప్పటికీ ఫాస్ట్httpని ప్యాచ్ చేయలేకపోయాను. కానీ నేను దానిని తయారు చేయడానికి ఒక మార్గాన్ని కనుగొన్నాను, తద్వారా దేనినీ ప్యాచ్ చేయవలసిన అవసరం లేదు మరియు నేను HTTPలో నా స్వంత పద్ధతిని కనుగొన్నాను - నేను దానిని KITTEN అని పిలిచాను. సరే, ఇది తార్కికం - “VK”, “కిట్టెన్”... ఇంకా ఏమిటి?..
కిట్టెన్ పద్ధతితో సర్వర్‌కు అభ్యర్థన వస్తే, అప్పుడు సర్వర్ “మియావ్” అని ప్రతిస్పందించాలి - తార్కికంగా. అతను దీనికి ప్రతిస్పందిస్తే, అతను ఈ ప్రోటోకాల్‌ను అర్థం చేసుకున్నట్లు పరిగణించబడుతుంది, ఆపై నేను కనెక్షన్‌ని అడ్డగిస్తాను (fasthttp అటువంటి పద్ధతిని కలిగి ఉంది), మరియు కనెక్షన్ “రా” మోడ్‌లోకి వెళుతుంది. నాకు అది ఎందుకు అవసరం? TCP కనెక్షన్‌ల నుండి రీడింగ్ ఎలా జరుగుతుందో నేను నియంత్రించాలనుకుంటున్నాను. TCP ఒక అద్భుతమైన ఆస్తిని కలిగి ఉంది: ఎవరూ ఇతర వైపు నుండి చదవకపోతే, అప్పుడు వ్రాయడం వేచి ఉండటం ప్రారంభమవుతుంది మరియు జ్ఞాపకశక్తి ప్రత్యేకంగా ఖర్చు చేయబడదు.
కాబట్టి నేను ఒకేసారి దాదాపు 50 మంది క్లయింట్ల నుండి చదివాను (యాభై నుండి ఎందుకంటే యాభై ఖచ్చితంగా సరిపోవాలి, రేటు మరొక DC నుండి వచ్చినప్పటికీ)... ఈ విధానంతో కనీసం 20 సార్లు వినియోగం తగ్గింది, కానీ నేను, నిజం చెప్పాలంటే , నేను సరిగ్గా ఏ సమయాన్ని కొలవలేకపోయాను, ఎందుకంటే ఇది ఇప్పటికే పనికిరానిది (ఇది ఇప్పటికే ఎర్రర్ స్థాయికి చేరుకుంది). ప్రోటోకాల్ బైనరీ, అంటే, ఇది టేబుల్ పేరు మరియు డేటాను కలిగి ఉంటుంది; http హెడర్‌లు లేవు, కాబట్టి నేను వెబ్ సాకెట్‌ని ఉపయోగించలేదు (నేను బ్రౌజర్‌లతో కమ్యూనికేట్ చేయాల్సిన అవసరం లేదు - నేను మా అవసరాలకు సరిపోయే ప్రోటోకాల్‌ను తయారు చేసాను). మరియు అతనితో ప్రతిదీ బాగానే ఉంది.
బఫర్ టేబుల్ విచారంగా ఉంది
ఇటీవల మేము బఫర్ పట్టికల యొక్క మరొక ఆసక్తికరమైన లక్షణాన్ని చూశాము. మరియు ఈ సమస్య ఇప్పటికే ఇతరులకన్నా చాలా బాధాకరమైనది. ఈ పరిస్థితిని ఊహించుకుందాం: మీరు ఇప్పటికే క్లిక్‌హౌస్‌ని చురుకుగా ఉపయోగిస్తున్నారు, మీకు డజన్ల కొద్దీ క్లిక్‌హౌస్ సర్వర్లు ఉన్నాయి మరియు మీరు చదవడానికి చాలా సమయం తీసుకునే కొన్ని అభ్యర్థనలు ఉన్నాయి (60 సెకన్ల కంటే ఎక్కువ అనుకుందాం); మరియు మీరు వచ్చి ఈ క్షణంలో Alter చేయండి... ఈలోగా, "Alter"కి ముందు ప్రారంభమైన "ఎంపికలు" ఈ పట్టికలో చేర్చబడవు, "Alter" ప్రారంభించబడదు - బహుశా "Clickhouse" ఎలా పని చేస్తుందో కొన్ని లక్షణాలు ఈ ప్రదేశం. బహుశా ఇది పరిష్కరించబడుతుందా? లేక సాధ్యం కాదా?
సాధారణంగా, వాస్తవానికి ఇది అంత పెద్ద సమస్య కాదని స్పష్టమవుతుంది, కానీ బఫర్ పట్టికలతో ఇది మరింత బాధాకరంగా మారుతుంది. ఎందుకంటే, మీ “ఆల్టర్” సమయం ముగిసిపోయిందని అనుకుందాం (మరియు అది మరొక హోస్ట్‌లో సమయం ముగియవచ్చు - మీది కాదు, ఉదాహరణకు ప్రతిరూపంలో), అప్పుడు... మీరు బఫర్ టేబుల్‌ని తొలగించారు, మీ “ఆల్టర్” ( లేదా మరేదైనా హోస్ట్) సమయం ముగిసింది. ఆపై “మార్పు” లోపం సంభవించింది) - మీరు ఇప్పటికీ డేటా రాయడం కొనసాగుతుందని నిర్ధారించుకోవాలి: మీరు బఫర్ పట్టికలను తిరిగి (పేరెంట్ టేబుల్ వలె అదే స్కీమ్ ప్రకారం) సృష్టించారు, ఆపై "Alter" ద్వారా వెళుతుంది, అన్ని తరువాత ముగుస్తుంది మరియు బఫర్ పట్టికలో పేరెంట్ నుండి స్కీమాలో తేడా ఉంటుంది. “ఆల్టర్” అనేదానిపై ఆధారపడి, ఇన్సర్ట్ ఇకపై ఈ బఫర్ టేబుల్‌కి వెళ్లకపోవచ్చు - ఇది చాలా విచారకరం.
అటువంటి సంకేతం కూడా ఉంది (బహుశా ఎవరైనా దీనిని గమనించి ఉండవచ్చు) - క్లిక్‌హౌస్ యొక్క కొత్త వెర్షన్‌లలో దీనిని query_thread_log అంటారు. డిఫాల్ట్‌గా, కొన్ని వెర్షన్‌లో ఒకటి ఉంది. ఇక్కడ మేము రెండు నెలల్లో (840 గిగాబైట్లు) 100 మిలియన్ల రికార్డులను సేకరించాము. “ఇన్సర్ట్‌లు” అక్కడ వ్రాయబడడమే దీనికి కారణం (బహుశా ఇప్పుడు, మార్గం ద్వారా, అవి వ్రాయబడలేదు). నేను మీకు చెప్పినట్లుగా, మా “ఇన్సర్ట్‌లు” చిన్నవి - బఫర్ పట్టికలలో మాకు చాలా “ఇన్సర్ట్‌లు” ఉన్నాయి. ఇది నిలిపివేయబడిందని స్పష్టంగా ఉంది - నేను మా సర్వర్‌లో చూసిన వాటిని మీకు చెబుతున్నాను. ఎందుకు? బఫర్ పట్టికలను ఉపయోగించకుండా ఇది మరొక వాదన! స్పాటీ చాలా విచారంగా ఉంది.
ఈ వ్యక్తి పేరు స్పాటీ అని ఎవరికి తెలుసు? వీకే ఉద్యోగులు చేతులు ఎత్తేశారు. అలాగే.
“కిట్టెన్‌హౌస్” ప్రణాళికల గురించి
ప్రణాళికలు సాధారణంగా భాగస్వామ్యం చేయబడవు, సరియైనదా? అకస్మాత్తుగా మీరు వాటిని నెరవేర్చలేరు మరియు ఇతరుల దృష్టిలో చాలా మంచిగా కనిపించరు. కానీ నేను రిస్క్ తీసుకుంటాను! మేము ఈ క్రింది వాటిని చేయాలనుకుంటున్నాము: బఫర్ పట్టికలు, ఇప్పటికీ ఒక ఊతకర్రగా ఉన్నట్లు నాకు అనిపిస్తోంది మరియు చొప్పించడాన్ని మనమే బఫర్ చేయాలి. కానీ మేము దానిని డిస్క్‌లో బఫర్ చేయకూడదనుకుంటున్నాము, కాబట్టి మేము మెమరీలో చొప్పించడం బఫర్ చేస్తాము.
దీని ప్రకారం, “ఇన్సర్ట్” చేసినప్పుడు, అది ఇకపై సమకాలీకరించబడదు - ఇది ఇప్పటికే బఫర్ టేబుల్‌గా పని చేస్తుంది, పేరెంట్ టేబుల్‌లోకి చొప్పించబడుతుంది (అలాగే, ఏదో ఒక రోజు తర్వాత) మరియు ఇన్సర్ట్‌లు గడిచిన ప్రత్యేక ఛానెల్ ద్వారా రిపోర్ట్ చేస్తుంది మరియు ఇది లేదు.
నేను సింక్రోనస్ ఇన్సర్ట్‌ను ఎందుకు వదిలివేయలేను? ఇది మరింత సౌకర్యవంతంగా ఉంటుంది. వాస్తవం ఏమిటంటే, మీరు 10 వేల హోస్ట్‌ల నుండి చొప్పించినట్లయితే, అప్పుడు ప్రతిదీ బాగానే ఉంటుంది - మీరు ప్రతి హోస్ట్ నుండి కొంచెం పొందుతారు, మీరు సెకనుకు ఒకసారి అక్కడ చొప్పించండి, అంతా బాగానే ఉంది. కానీ ఈ పథకం పని చేయాలని నేను కోరుకుంటున్నాను, ఉదాహరణకు, రెండు యంత్రాల నుండి, తద్వారా మీరు అధిక వేగంతో డౌన్‌లోడ్ చేసుకోవచ్చు - బహుశా క్లిక్‌హౌస్ నుండి గరిష్టంగా పొందలేకపోవచ్చు, కానీ రివర్స్ ప్రాక్సీ ద్వారా ఒక మెషీన్ నుండి సెకనుకు కనీసం 100 మెగాబైట్‌లను వ్రాయండి - ఈ పథకం తప్పనిసరిగా పెద్ద మరియు చిన్న పరిమాణాలకు స్కేల్ చేయాలి, కాబట్టి మేము ప్రతి చొప్పించడం కోసం ఒక సెకను వేచి ఉండలేము, కనుక ఇది అసమకాలికంగా ఉండాలి. మరియు అదే విధంగా, చొప్పించడం పూర్తయిన తర్వాత అసమకాలిక నిర్ధారణలు రావాలి. పాస్ అయ్యిందో లేదో తెలుస్తుంది.
అతి ముఖ్యమైన విషయం ఏమిటంటే, ఈ పథకంలో చొప్పించడం జరిగిందో లేదో మనకు ఖచ్చితంగా తెలుసు. ఈ పరిస్థితిని ఊహించండి: మీకు బఫర్ టేబుల్ ఉంది, మీరు దానిలో ఏదో వ్రాసారు, ఆపై, టేబుల్ చదవడానికి మాత్రమే మోడ్‌లోకి వెళ్లి బఫర్‌ను ఫ్లష్ చేయడానికి ప్రయత్నించిందని చెప్పండి. డేటా ఎక్కడికి వెళుతుంది? అవి బఫర్‌లోనే ఉంటాయి. కానీ మేము దీని గురించి ఖచ్చితంగా చెప్పలేము - ఏదైనా ఇతర లోపం ఉంటే, దాని కారణంగా డేటా బఫర్‌లో ఉండదు ... (అలెక్సీ మిలోవిడోవ్, యాండెక్స్, క్లిక్‌హౌస్ డెవలపర్ చిరునామాలు) లేదా అది అలాగే ఉంటుందా? ఎల్లప్పుడూ? అంతా బాగానే ఉంటుందని అలెక్సీ మమ్మల్ని ఒప్పించాడు. ఆయనను నమ్మకపోవడానికి మాకు ఎటువంటి కారణం లేదు. కానీ ఒకే: మేము బఫర్ పట్టికలను ఉపయోగించకపోతే, వాటితో ఎటువంటి సమస్యలు ఉండవు. రెండు రెట్లు ఎక్కువ పట్టికలను సృష్టించడం కూడా అసౌకర్యంగా ఉంటుంది, అయినప్పటికీ సూత్రప్రాయంగా పెద్ద సమస్యలు లేవు. ఇదీ పథకం.
చదువు గురించి మాట్లాడుకుందాం
ఇప్పుడు చదవడం గురించి మాట్లాడుకుందాం. మేము ఇక్కడ మా స్వంత సాధనాన్ని కూడా వ్రాసాము. మీ స్వంత పరికరాన్ని ఇక్కడ ఎందుకు వ్రాయాలి?.. మరియు టాబిక్స్‌ను ఎవరు ఉపయోగించారు? ఎలాగో కొందరే చేతులు ఎత్తేశారు... మరి టాబిక్స్ పనితీరుతో ఎవరు సంతృప్తి చెందారు? బాగా, మేము దానితో సంతోషంగా లేము మరియు డేటాను వీక్షించడానికి ఇది చాలా సౌకర్యవంతంగా లేదు. ఇది విశ్లేషణలకు బాగానే ఉంది, కానీ వీక్షించడానికి ఇది స్పష్టంగా ఆప్టిమైజ్ చేయబడలేదు. కాబట్టి నేను నా స్వంత, నా స్వంత ఇంటర్‌ఫేస్ రాశాను.
ఇది చాలా సులభం - ఇది డేటాను మాత్రమే చదవగలదు. గ్రాఫిక్స్ ఎలా చూపించాలో, ఏ పని చేయాలో అతనికి తెలియదు. కానీ ఇది మనకు అవసరమైన వాటిని చూపుతుంది: ఉదాహరణకు, పట్టికలో ఎన్ని అడ్డు వరుసలు ఉన్నాయి, అది ఎంత స్థలాన్ని తీసుకుంటుంది (దీనిని నిలువు వరుసలుగా విభజించకుండా), అంటే చాలా ప్రాథమిక ఇంటర్‌ఫేస్ మనకు అవసరం.
మరియు ఇది సీక్వెల్ ప్రోకి చాలా పోలి ఉంటుంది, కానీ Twitter యొక్క బూట్‌స్ట్రాప్ మరియు రెండవ వెర్షన్‌లో మాత్రమే తయారు చేయబడింది. మీరు అడగండి: "యూరి, రెండవ సంస్కరణలో ఎందుకు?" ఈ సంవత్సరం? 2018? సాధారణంగా, నేను దీన్ని చాలా కాలం క్రితం “కండరాల” (MySQL) కోసం చేసాను మరియు అక్కడ ఉన్న ప్రశ్నలలో కొన్ని పంక్తులను మార్చాను మరియు ఇది “క్లిక్‌హౌస్” కోసం పని చేయడం ప్రారంభించింది, దీనికి ప్రత్యేక ధన్యవాదాలు! ఎందుకంటే పార్సర్ “కండరాల”కు చాలా పోలి ఉంటుంది మరియు ప్రశ్నలు చాలా పోలి ఉంటాయి - చాలా సౌకర్యవంతంగా ఉంటాయి, ముఖ్యంగా మొదట.
బాగా, ఇది పట్టికలను ఫిల్టర్ చేయగలదు, టేబుల్ యొక్క నిర్మాణం మరియు కంటెంట్‌లను చూపగలదు, క్రమబద్ధీకరించడానికి, నిలువు వరుసల వారీగా ఫిల్టర్ చేయడానికి మిమ్మల్ని అనుమతిస్తుంది, ఫలితంగా వచ్చిన ప్రశ్నను చూపుతుంది, ప్రభావిత అడ్డు వరుసలు (ఫలితంగా ఎన్ని), అంటే, డేటాను వీక్షించడానికి ప్రాథమిక అంశాలు. ప్రెట్టీ ఫాస్ట్.
ఎడిటర్ కూడా ఉన్నాడు. నేను టాబిక్స్ నుండి మొత్తం ఎడిటర్‌ను దొంగిలించడానికి నిజాయితీగా ప్రయత్నించాను, కానీ నేను చేయలేకపోయాను. కానీ ఏదో ఒకవిధంగా ఇది పనిచేస్తుంది. సూత్రప్రాయంగా, అంతే.
"క్లిక్‌హౌస్" డెన్‌లకు అనుకూలంగా ఉంటుంది
క్లిక్‌హౌస్, వివరించిన అన్ని సమస్యలు ఉన్నప్పటికీ, లాగ్‌లకు బాగా సరిపోతుందని నేను మీకు చెప్పాలనుకుంటున్నాను. ముఖ్యంగా, ఇది మా సమస్యను పరిష్కరిస్తుంది - ఇది చాలా వేగంగా ఉంటుంది మరియు నిలువు వరుసల ద్వారా లాగ్లను ఫిల్టర్ చేయడానికి మిమ్మల్ని అనుమతిస్తుంది. సూత్రప్రాయంగా, బఫర్ పట్టికలు బాగా పని చేయలేదు, కానీ సాధారణంగా ఎందుకు ఎవరికీ తెలియదు... బహుశా ఇప్పుడు మీకు ఎక్కడ సమస్యలు ఉంటాయో మీకు బాగా తెలుసు.
TCP? సాధారణంగా, VK లో UDP ని ఉపయోగించడం ఆచారం. మరియు నేను TCP ఉపయోగించినప్పుడు ... వాస్తవానికి, ఎవరూ నాకు చెప్పలేదు: “యూరీ, మీరు దేని గురించి మాట్లాడుతున్నారు! మీరు చేయలేరు, మీకు UDP అవసరం." TCP అంత భయానకంగా లేదని తేలింది. ఒకే విషయం ఏమిటంటే, మీరు వ్రాసే పదివేల క్రియాశీల సమ్మేళనాలు ఉంటే, మీరు దానిని కొంచెం జాగ్రత్తగా సిద్ధం చేయాలి; కానీ అది సాధ్యమే, మరియు చాలా సులభం.
అందరూ మా పబ్లిక్ “VK బ్యాకెండ్”కి సబ్‌స్క్రయిబ్ చేస్తే హైలోడ్ సైబీరియాలో “కిట్టెన్‌హౌస్” మరియు “లైట్‌హౌస్” పోస్ట్ చేస్తానని వాగ్దానం చేసాను... మరియు మీకు తెలుసా, అందరూ సబ్‌స్క్రయిబ్ చేసుకోలేదు... అయితే, మీరు మా సబ్‌స్క్రయిబ్ చేయమని నేను డిమాండ్ చేయను ప్రజా. మీలో ఇంకా చాలా మంది ఉన్నారు, ఎవరైనా మనస్తాపం చెందవచ్చు, కానీ ఇప్పటికీ, దయచేసి సభ్యత్వాన్ని పొందండి (మరియు ఇక్కడ నేను పిల్లిలాగా కళ్ళు పెట్టుకోవాలి). అది . చాలా ధన్యవాదాలు! గితుబ్ మాది . క్లిక్‌హౌస్‌తో మీ జుట్టు మృదువుగా మరియు సిల్కీగా ఉంటుంది.
ప్రముఖ: - మిత్రులారా, ఇప్పుడు ప్రశ్నల కోసం. మేము ప్రశంసాపత్రం మరియు VHSపై మీ నివేదికను అందించిన వెంటనే.
యూరి నస్రెట్డినోవ్ (ఇకపై YNగా సూచిస్తారు): – VHSపై నా నివేదిక ఇప్పుడే ముగిసినట్లయితే మీరు ఎలా రికార్డ్ చేయగలిగారు?
ప్రముఖ: – “క్లిక్‌హౌస్” ఎలా పని చేస్తుందో లేదో కూడా మీరు పూర్తిగా గుర్తించలేరు! మిత్రులారా, ప్రశ్నల కోసం 5 నిమిషాలు!
మీ ప్రశ్నలు
ప్రేక్షకుల నుండి ప్రశ్న (ఇకపై Q గా సూచిస్తారు): - శుభ మద్యాహ్నం. నివేదిక అందించినందుకు చాలా ధన్యవాదాలు. నాకు రెండు ప్రశ్నలు ఉన్నాయి. నేను పనికిమాలిన వాటితో ప్రారంభిస్తాను: రేఖాచిత్రాలలో (3, 4, 7...) "కిట్టెన్‌హౌస్" పేరులోని t అక్షరాల సంఖ్య పిల్లుల సంతృప్తిని ప్రభావితం చేస్తుందా?
YN: - దేని పరిమాణం?
Z: – లేఖ టి. మూడు టిలు ఉన్నాయి, ఎక్కడో మూడు టిలు ఉన్నాయి.
YN: - నేను దాన్ని పరిష్కరించలేదా? బాగా, అది చేస్తుంది! ఇవి వేర్వేరు ఉత్పత్తులు - నేను ఈ సమయంలో మిమ్మల్ని మోసం చేస్తున్నాను. సరే, నేను తమాషా చేస్తున్నాను - పర్వాలేదు. ఆహ్, ఇక్కడే! లేదు, అదే పని, నేను అక్షర దోషం చేసాను.
Z: - ధన్యవాదాలు. రెండవ ప్రశ్న తీవ్రమైనది. నేను అర్థం చేసుకున్నంత వరకు, క్లిక్‌హౌస్‌లో, బఫర్ పట్టికలు ప్రత్యేకంగా మెమరీలో నివసిస్తాయి, డిస్క్‌కు బఫర్ చేయబడవు మరియు తదనుగుణంగా, నిరంతరంగా ఉండవు.
YN: - అవును.
Z: – మరియు అదే సమయంలో, మీ క్లయింట్ డిస్క్‌కి బఫర్ అవుతుంది, ఇది ఇదే లాగ్‌ల డెలివరీకి కొంత హామీని సూచిస్తుంది. కానీ ఇది క్లిక్‌హౌస్‌లో హామీ ఇవ్వబడదు. హామీ ఎలా అమలు చేయబడుతుందో వివరించండి, దేని కారణంగా?.. ఇక్కడ ఈ విధానం మరింత వివరంగా ఉంది
YN: – అవును, సిద్ధాంతపరంగా ఇక్కడ ఎటువంటి వైరుధ్యాలు లేవు, ఎందుకంటే క్లిక్‌హౌస్ పడిపోయినప్పుడు, మీరు దానిని మిలియన్ విభిన్న మార్గాల్లో గుర్తించవచ్చు. క్లిక్‌హౌస్ క్రాష్ అయినట్లయితే (అది తప్పుగా ముగిస్తే), మీరు స్థూలంగా చెప్పాలంటే, మీరు వ్రాసిన మీ లాగ్‌లో కొంచెం రివైండ్ చేయవచ్చు మరియు ప్రతిదీ సరిగ్గా ఉన్న క్షణం నుండి ప్రారంభించవచ్చు. మీరు ఒక నిమిషం రివైండ్ అని అనుకుందాం, అంటే, మీరు ఒక నిమిషంలో ప్రతిదీ ఫ్లష్ చేసినట్లు పరిగణించబడుతుంది.
Z: – అంటే, “కిట్టెన్‌హౌస్” కిటికీని ఎక్కువసేపు పట్టుకుని, పడిపోయినప్పుడు, దానిని గుర్తించి రివైండ్ చేయగలరా?
YN: - కానీ ఇది సిద్ధాంతంలో ఉంది. ఆచరణలో, మేము దీన్ని చేయము మరియు విశ్వసనీయ డెలివరీ సున్నా నుండి అనంతం వరకు ఉంటుంది. కానీ సగటున ఒకటి. కొన్ని కారణాల వల్ల క్లిక్‌హౌస్ క్రాష్ అయినట్లయితే లేదా సర్వర్లు “రీబూట్” అయితే, మేము కొంచెం నష్టపోతామని మేము సంతృప్తి చెందాము. అన్ని ఇతర సందర్భాల్లో, ఏమీ జరగదు.
Z: - హలో. నివేదిక ప్రారంభం నుండి మీరు నిజంగా UDPని ఉపయోగిస్తున్నారని నాకు మొదటి నుండి అనిపించింది. మీకు http ఉంది, అదంతా... మరియు మీరు వివరించిన చాలా సమస్యలు, నేను అర్థం చేసుకున్నట్లుగా, ఈ నిర్దిష్ట పరిష్కారం వల్ల సంభవించాయి...
YN: – మేము TCPని ఏమి ఉపయోగిస్తాము?
Z: - ముఖ్యంగా అవును.
YN: - లేదు.
Z: – fasthttpతో మీకు సమస్యలు ఉన్నాయి, కనెక్షన్‌తో మీకు సమస్యలు ఉన్నాయి. మీరు ఇప్పుడే UDPని ఉపయోగించినట్లయితే, మీరు కొంత సమయాన్ని ఆదా చేసి ఉండేవారు. సరే, సుదీర్ఘ సందేశాలు లేదా మరేదైనా సమస్యలు ఉండవచ్చు...
YN: - దేనితో?
Z: – దీర్ఘ సందేశాలతో, ఇది MTUకి సరిపోకపోవచ్చు కాబట్టి, మరేదైనా... సరే, వారి స్వంత సమస్యలు ఉండవచ్చు. ప్రశ్న: UDP ఎందుకు కాదు?
YN: – TCP/IPని అభివృద్ధి చేసిన రచయితలు నాకంటే చాలా తెలివైనవారని మరియు ప్యాకెట్‌లను ఎలా సీరియలైజ్ చేయాలో నాకంటే బాగా తెలుసని నేను నమ్ముతున్నాను (తద్వారా అవి వెళ్తాయి), అదే సమయంలో పంపే విండోను సర్దుబాటు చేయండి, నెట్‌వర్క్‌ను ఓవర్‌లోడ్ చేయకుండా, దేనిపై అభిప్రాయాన్ని తెలియజేయండి చదవలేదు, మరొక వైపు లెక్కించబడదు... ఈ సమస్యలన్నీ, నా అభిప్రాయం ప్రకారం, UDPలో ఉంటాయి, అదే విషయాన్ని స్వయంగా అమలు చేయడానికి మరియు చాలా మటుకు నేను ఇప్పటికే వ్రాసిన దానికంటే ఎక్కువ కోడ్ రాయవలసి ఉంటుంది. పేలవంగా. నాకు C లో రాయడం కూడా ఇష్టం లేదు, అక్కడ విడదీసి...
Z: - కేవలం అనుకూలమైనది! సరే పంపబడింది మరియు దేని కోసం వేచి ఉండకండి - ఇది పూర్తిగా అసమకాలికమైనది. అంతా బాగానే ఉందని నోటిఫికేషన్ తిరిగి వచ్చింది - అంటే అది వచ్చింది; అది రాకపోతే, అది చెడ్డదని అర్థం.
YN: – నాకు రెండూ కావాలి – నేను డెలివరీ హామీతో మరియు డెలివరీ హామీ లేకుండా రెండింటినీ పంపగలగాలి. ఇవి రెండు భిన్నమైన దృశ్యాలు. నేను కొన్ని లాగ్లను కోల్పోకూడదు లేదా కారణంతో వాటిని కోల్పోకూడదు.
Z: - నేను సమయాన్ని వృథా చేయను. దీనిపై మరింత చర్చ జరగాలి. ధన్యవాదాలు.
ప్రముఖ: – ఎవరికి ప్రశ్నలు ఉన్నాయి – ఆకాశానికి చేతులు!
Z: - హలో, నేను సాషా. నివేదిక మధ్యలో ఎక్కడో, TCPతో పాటు, రెడీమేడ్ సొల్యూషన్‌ను ఉపయోగించడం సాధ్యమవుతుందని ఒక భావన కనిపించింది - ఒకరకమైన కాఫ్కా.
YN: – సరే... నేను ఇంటర్మీడియట్ సర్వర్‌లను ఉపయోగించకూడదని మీకు చెప్పాను, ఎందుకంటే... కాఫ్కాలో, మనకు పది వేల హోస్ట్‌లు ఉన్నాయని తేలింది; నిజానికి, మాకు మరిన్ని ఉన్నాయి - పదివేల హోస్ట్‌లు. కాఫ్కాతో ఎలాంటి ప్రాక్సీలు లేకుండా చేయడం కూడా బాధాకరంగా ఉంటుంది. అదనంగా, ముఖ్యంగా, ఇది ఇప్పటికీ "జాప్యం" ఇస్తుంది, ఇది మీకు అవసరమైన అదనపు హోస్ట్‌లను ఇస్తుంది. కానీ నేను వాటిని కలిగి ఉండటం ఇష్టం లేదు - నాకు కావాలి ...
Z: "కానీ చివరికి అది ఏమైనప్పటికీ ఆ విధంగా మారింది."
YN: – లేదు, హోస్ట్‌లు లేరు! ఇవన్నీ Clickhouse హోస్ట్‌లలో పని చేస్తాయి.
Z: - బాగా, మరియు “కిట్టెన్‌హౌస్”, ఇది రివర్స్ - అతను ఎక్కడ నివసిస్తున్నాడు?
YN: – క్లిక్‌హౌస్ హోస్ట్‌లో, ఇది డిస్క్‌కు ఏమీ వ్రాయదు.
Z: - మనం అనుకుందాం.
ప్రముఖ: - మీరు సంతృప్తి చెందారా? మేము మీకు జీతం ఇవ్వగలమా?
Z: - మీరు చెయ్యవచ్చు అవును. నిజానికి, అదే విషయం పొందడానికి క్రచెస్ చాలా ఉన్నాయి, మరియు ఇప్పుడు - TCP అంశంపై మునుపటి సమాధానం విరుద్ధంగా ఉంది, నా అభిప్రాయం ప్రకారం, ఈ పరిస్థితి. ప్రతిదీ చాలా తక్కువ సమయంలో నా మోకాళ్లపై పూర్తి చేసినట్లు అనిపిస్తుంది.
YN: – మరియు నేను కాఫ్కాను ఎందుకు ఉపయోగించకూడదనుకున్నాను, ఎందుకంటే క్లిక్‌హౌస్ టెలిగ్రామ్ చాట్‌లో చాలా ఫిర్యాదులు ఉన్నాయి, ఉదాహరణకు, కాఫ్కా నుండి సందేశాలు పోయాయి. కాఫ్కా నుండే కాదు, కాఫ్కా మరియు క్లిక్‌హాస్‌ల ఏకీకరణలో; లేదా ఏదో అక్కడ కనెక్ట్ కాలేదు. స్థూలంగా చెప్పాలంటే, కాఫ్కా కోసం క్లయింట్‌ని వ్రాయడం అవసరం. సరళమైన లేదా మరింత నమ్మదగిన పరిష్కారం ఉంటుందని నేను అనుకోను.
Z: – నాకు చెప్పండి, మీరు క్యూలు లేదా కొన్ని రకాల సాధారణ బస్సులను ఎందుకు ప్రయత్నించలేదు? అసమకాలికతతో మీరు లాగ్లను క్యూ ద్వారా పంపవచ్చని మరియు క్యూ ద్వారా అసమకాలిక ప్రతిస్పందనను స్వీకరించవచ్చని మీరు చెప్పారు కాబట్టి?
YN: – దయచేసి ఏ క్యూలను ఉపయోగించవచ్చో సూచించండి?
Z: – ఏదైనా, అవి క్రమంలో ఉన్నాయని హామీ లేకుండా కూడా. కొన్ని రకాల Redis, RMQ...
YN: – క్లిక్‌హౌస్‌ని తీసివేసే ఒక హోస్ట్‌లో (అనేక సర్వర్‌ల కోణంలో) కూడా Redis అటువంటి చొప్పించే వాల్యూమ్‌ను లాగలేడనే భావన నాకు ఉంది. నేను దీన్ని ఎటువంటి ఆధారాలతో బ్యాకప్ చేయలేను (నేను దీన్ని బెంచ్‌మార్క్ చేయలేదు), కానీ ఇక్కడ రెడిస్ ఉత్తమ పరిష్కారం కాదని నాకు అనిపిస్తోంది. సూత్రప్రాయంగా, ఈ వ్యవస్థను మెరుగైన సందేశ క్యూగా పరిగణించవచ్చు, కానీ ఇది “క్లిక్‌హౌస్” కోసం మాత్రమే రూపొందించబడింది.
ప్రముఖ: - యూరి, చాలా ధన్యవాదాలు. ప్రశ్నలు మరియు సమాధానాలను ఇక్కడ ముగించి, ప్రశ్న అడిగిన వారిలో ఎవరికి పుస్తకాన్ని ఇస్తామో చెప్పాలని నేను ప్రతిపాదించాను.
YN: – ప్రశ్న అడిగిన మొదటి వ్యక్తికి నేను పుస్తకం ఇవ్వాలనుకుంటున్నాను.
ప్రముఖ: - అద్భుతం! గొప్ప! అద్భుతం! చాలా ధన్యవాదాలు!
కొన్ని ప్రకటనలు 🙂
మాతో ఉన్నందుకు ధన్యవాదాలు. మీరు మా కథనాలను ఇష్టపడుతున్నారా? మరింత ఆసక్తికరమైన కంటెంట్‌ని చూడాలనుకుంటున్నారా? ఆర్డర్ చేయడం ద్వారా లేదా స్నేహితులకు సిఫార్సు చేయడం ద్వారా మాకు మద్దతు ఇవ్వండి, , ఎంట్రీ-లెవల్ సర్వర్‌ల యొక్క ప్రత్యేకమైన అనలాగ్, ఇది మీ కోసం మా ద్వారా కనుగొనబడింది: (RAID1 మరియు RAID10తో అందుబాటులో ఉంది, గరిష్టంగా 24 కోర్లు మరియు 40GB DDR4 వరకు).
ఆమ్‌స్టర్‌డామ్‌లోని ఈక్వినిక్స్ టైర్ IV డేటా సెంటర్‌లో Dell R730xd 2x చౌకగా ఉందా? ఇక్కడ మాత్రమే నెదర్లాండ్స్‌లో! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 నుండి! గురించి చదవండి
మూలం: www.habr.com