ClickHouse ఒక ప్రత్యేక వ్యవస్థ కాబట్టి, దానిని ఉపయోగిస్తున్నప్పుడు దాని నిర్మాణం యొక్క లక్షణాలను పరిగణనలోకి తీసుకోవడం చాలా ముఖ్యం. ఈ నివేదికలో, అలెక్సీ క్లిక్‌హౌస్‌ను ఉపయోగిస్తున్నప్పుడు సాధారణ తప్పుల ఉదాహరణల గురించి మాట్లాడతారు, ఇది పనికిరాని పనికి దారితీస్తుంది. ప్రాక్టికల్ ఉదాహరణలు ఎలా ఒకటి లేదా మరొక డేటా ప్రాసెసింగ్ స్కీమ్‌ను ఎంచుకోవడం ద్వారా పనితీరును మాగ్నిట్యూడ్ ఆర్డర్‌ల ద్వారా మార్చగలదో చూపుతుంది.
అందరికి వందనాలు! నా పేరు అలెక్సీ, నేను క్లిక్‌హౌస్ తయారు చేస్తున్నాను.
మొదట, నేను వెంటనే మిమ్మల్ని సంతోషపెట్టడానికి తొందరపడ్డాను, ఈ రోజు క్లిక్‌హౌస్ అంటే ఏమిటో నేను మీకు చెప్పను. నిజం చెప్పాలంటే, నేను దానితో విసిగిపోయాను. ప్రతిసారీ అది ఏమిటో నేను మీకు చెప్తాను. మరియు బహుశా ప్రతి ఒక్కరూ ఇప్పటికే తెలుసు.
బదులుగా, సాధ్యమయ్యే తప్పులు ఏమిటో నేను మీకు చెప్తాను, అంటే, మీరు ClickHouseని తప్పుగా ఎలా ఉపయోగించవచ్చో. వాస్తవానికి, భయపడాల్సిన అవసరం లేదు, ఎందుకంటే మేము క్లిక్‌హౌస్‌ను సరళమైన, అనుకూలమైన మరియు బాక్స్ వెలుపల పని చేసే సిస్టమ్‌గా అభివృద్ధి చేస్తున్నాము. నేను దీన్ని ఇన్‌స్టాల్ చేసాను, సమస్యలు లేవు.
కానీ మీరు ఇప్పటికీ ఈ సిస్టమ్ ప్రత్యేకమైనదని పరిగణనలోకి తీసుకోవాలి మరియు మీరు ఈ సిస్టమ్‌ను దాని కంఫర్ట్ జోన్ నుండి బయటకు తీసే అసాధారణ వినియోగ కేసును సులభంగా చూడవచ్చు.
కాబట్టి, ఏ రకమైన రేక్ ఉంది? ఎక్కువగా నేను స్పష్టమైన విషయాల గురించి మాట్లాడతాను. ప్రతి ఒక్కరికీ ప్రతిదీ స్పష్టంగా ఉంటుంది, ప్రతి ఒక్కరూ ప్రతిదీ అర్థం చేసుకుంటారు మరియు వారు చాలా తెలివైనవారని సంతోషించవచ్చు మరియు అర్థం చేసుకోని వారు కొత్తదాన్ని నేర్చుకుంటారు.
మొదటి మరియు సరళమైన ఉదాహరణ, దురదృష్టవశాత్తు, తరచుగా సంభవిస్తుంది, చిన్న బ్యాచ్‌లతో పెద్ద సంఖ్యలో ఇన్సర్ట్లు, అనగా పెద్ద సంఖ్యలో చిన్న ఇన్సర్ట్లు.
క్లిక్‌హౌస్ ఇన్సర్ట్‌ను ఎలా నిర్వహిస్తుందో మేము పరిశీలిస్తే, మీరు ఒక అభ్యర్థనలో కనీసం టెరాబైట్ డేటాను పంపవచ్చు. అది ఒక సమస్య కాదు.
మరి విలక్షణ ప్రదర్శన ఎలా ఉంటుందో చూడాలి. ఉదాహరణకు, మేము Yandex.Metrica డేటా నుండి పట్టికను కలిగి ఉన్నాము. హిట్స్. 105 కొన్ని నిలువు వరుసలు. 700 బైట్లు కుదించబడలేదు. మరియు మేము ఒక మిలియన్ వరుసల బ్యాచ్‌లలో మంచి మార్గంలో ఇన్సర్ట్ చేస్తాము.
మేము మెర్జ్‌ట్రీని టేబుల్‌లోకి చొప్పించాము, ఇది సెకనుకు అర మిలియన్ వరుసలను మారుస్తుంది. గొప్ప. ప్రతిరూప పట్టికలో ఇది కొంచెం చిన్నదిగా ఉంటుంది, సెకనుకు దాదాపు 400 వరుసలు.
మరియు మీరు కోరం చొప్పించడాన్ని ప్రారంభించినట్లయితే, మీరు కొంచెం తక్కువ, కానీ ఇప్పటికీ మంచి పనితీరు, సెకనుకు 250 నిబంధనలు పొందుతారు. క్లిక్‌హౌస్*లో కోరమ్ చొప్పించడం అనేది నమోదు చేయని లక్షణం.
* 2020 నాటికి, .
మీరు ఏదైనా చెడు చేస్తే ఏమి జరుగుతుంది? మేము MergeTree పట్టికలో ఒక అడ్డు వరుసను చొప్పించాము మరియు సెకనుకు 59 వరుసలను పొందుతాము. అంటే 10 రెట్లు తక్కువ. ReplicatedMergeTreeలో - సెకనుకు 000 వరుసలు. మరియు కోరమ్ ఆన్ చేయబడితే, అది సెకనుకు 6 లైన్లు అవుతుంది. నా అభిప్రాయం ప్రకారం, ఇది ఒక రకమైన సంపూర్ణ చెత్త. అలా నెమ్మదించడం ఎలా? క్లిక్‌హౌస్ వేగాన్ని తగ్గించకూడదని నా టీ-షర్టుపై కూడా రాసి ఉంచాను. అయితే ఇది కొన్నిసార్లు జరుగుతుంది.
నిజానికి ఇది మన లోపం. మేము సులభంగా ప్రతిదీ చక్కగా పని చేయగలము, కానీ మేము చేయలేదు. మరియు మా స్క్రిప్ట్‌కి అది అవసరం లేదు కాబట్టి మేము దీన్ని చేయలేదు. మాకు ఇప్పటికే కసాయిలు ఉన్నాయి. మేము మా ప్రవేశద్వారం వద్ద బ్యాచ్‌లను స్వీకరించాము మరియు సమస్యలు లేవు. మేము దానిని చొప్పించాము మరియు ప్రతిదీ సరిగ్గా పని చేస్తుంది. కానీ, వాస్తవానికి, అన్ని రకాల దృశ్యాలు సాధ్యమే. ఉదాహరణకు, మీరు డేటాను రూపొందించే సర్వర్‌ల సమూహాన్ని కలిగి ఉన్నప్పుడు. మరియు వారు తరచుగా డేటాను చొప్పించరు, కానీ అవి తరచుగా ఇన్సర్ట్‌లతో ముగుస్తాయి. మరియు మనం దీన్ని ఎలాగైనా నివారించాలి.
టెక్నికల్ పాయింట్ ఆఫ్ వ్యూలో, పాయింట్ ఏమిటంటే, మీరు క్లిక్‌హౌస్‌లో ఇన్సర్ట్ చేసినప్పుడు, డేటా ఏ మెమెటబుల్‌లో ముగియదు. మాకు నిజమైన లాగ్ స్ట్రక్చర్ మెర్జ్‌ట్రీ లేదు, కానీ కేవలం మెర్జ్‌ట్రీ, ఎందుకంటే లాగ్ లేదా మెమ్‌టేబుల్ లేదు. మేము ఫైల్ సిస్టమ్‌కు డేటాను వెంటనే వ్రాస్తాము, ఇది ఇప్పటికే నిలువు వరుసలలో ఏర్పాటు చేయబడింది. మరియు మీకు 100 నిలువు వరుసలు ఉంటే, 200 కంటే ఎక్కువ ఫైల్‌లను ప్రత్యేక డైరెక్టరీకి వ్రాయవలసి ఉంటుంది. ఇదంతా చాలా గజిబిజిగా ఉంది.
మరియు ప్రశ్న తలెత్తుతుంది: “ఎలా చేయాలి?” పరిస్థితి ఉంటే, మీరు ఇప్పటికీ క్లిక్‌హౌస్‌లో డేటాను రికార్డ్ చేయాలి.
విధానం 1. ఇది సులభమైన మార్గం. ఒక రకమైన పంపిణీ క్యూను ఉపయోగించండి. ఉదాహరణకు, కాఫ్కా. మీరు కాఫ్కా నుండి డేటాను సంగ్రహించి, సెకనుకు ఒకసారి బ్యాచ్ చేయండి. మరియు ప్రతిదీ బాగానే ఉంటుంది, మీరు రికార్డ్ చేయండి, ప్రతిదీ బాగా పనిచేస్తుంది.
ప్రతికూలతలు ఏమిటంటే కాఫ్కా మరొక స్థూలమైన పంపిణీ వ్యవస్థ. మీ కంపెనీలో ఇప్పటికే కాఫ్కా ఉందో లేదో కూడా నాకు అర్థమైంది. ఇది మంచిది, ఇది సౌకర్యవంతంగా ఉంటుంది. కానీ అది ఉనికిలో లేకుంటే, మీ ప్రాజెక్ట్‌లోకి మరొక పంపిణీ వ్యవస్థను లాగడానికి ముందు మీరు మూడుసార్లు ఆలోచించాలి. కాబట్టి ప్రత్యామ్నాయాలను పరిగణనలోకి తీసుకోవడం విలువ.
విధానం 2. ఇది పాత-పాఠశాల ప్రత్యామ్నాయం మరియు అదే సమయంలో చాలా సులభం. మీరు మీ లాగ్లను రూపొందించే రకమైన సర్వర్‌ని కలిగి ఉన్నారా. మరియు ఇది మీ లాగ్లను ఫైల్‌కి వ్రాస్తుంది. మరియు సెకనుకు ఒకసారి, ఉదాహరణకు, మేము ఈ ఫైల్‌కు పేరు మార్చాము మరియు క్రొత్తదాన్ని కూల్చివేస్తాము. మరియు ఒక ప్రత్యేక స్క్రిప్ట్, క్రాన్ లేదా కొన్ని డెమోన్ ద్వారా, పురాతన ఫైల్‌ను తీసుకొని క్లిక్‌హౌస్‌కి వ్రాస్తుంది. మీరు సెకనుకు ఒకసారి లాగ్లను రికార్డ్ చేస్తే, అప్పుడు అంతా బాగానే ఉంటుంది.
కానీ ఈ పద్ధతి యొక్క ప్రతికూలత ఏమిటంటే, లాగ్‌లు ఉత్పత్తి చేయబడిన మీ సర్వర్ ఎక్కడో అదృశ్యమైతే, డేటా కూడా అదృశ్యమవుతుంది.
విధానం 3. మరొక ఆసక్తికరమైన పద్ధతి ఉంది, ఇది తాత్కాలిక ఫైళ్లు అవసరం లేదు. ఉదాహరణకు, మీ వద్ద కొన్ని రకాల అడ్వర్టైజింగ్ స్పిన్నర్ లేదా డేటాను రూపొందించే కొన్ని ఇతర ఆసక్తికరమైన డెమోన్ ఉంది. మరియు మీరు ర్యామ్‌లో, బఫర్‌లో నేరుగా కొంత డేటాను కూడబెట్టుకోవచ్చు. మరియు తగినంత సమయం గడిచినప్పుడు, మీరు ఈ బఫర్‌ను పక్కన పెట్టి, కొత్తదాన్ని సృష్టించండి మరియు ప్రత్యేక థ్రెడ్‌లో, ఇప్పటికే క్లిక్‌హౌస్‌లో సేకరించిన వాటిని చొప్పించండి.
మరోవైపు, కిల్ -9తో డేటా కూడా అదృశ్యమవుతుంది. మీ సర్వర్ క్రాష్ అయితే, మీరు ఈ డేటాను కోల్పోతారు. మరియు మరొక సమస్య ఏమిటంటే, మీరు డేటాబేస్‌కు వ్రాయలేకపోతే, మీ డేటా RAMలో పేరుకుపోతుంది. మరియు RAM అయిపోతుంది, లేదా మీరు కేవలం డేటాను కోల్పోతారు.
పద్ధతి 4. మరొక ఆసక్తికరమైన పద్ధతి. మీకు కొన్ని రకాల సర్వర్ ప్రక్రియ ఉందా. మరియు ఇది వెంటనే క్లిక్‌హౌస్‌కి డేటాను పంపగలదు, కానీ ఒక కనెక్షన్‌లో దీన్ని చేయండి. ఉదాహరణకు, నేను బదిలీ-ఎన్‌కోడింగ్‌తో http అభ్యర్థనను పంపాను: ఇన్‌సర్ట్‌తో భాగం. మరియు ఇది చాలా అరుదుగా భాగాలను ఉత్పత్తి చేస్తుంది, మీరు ప్రతి పంక్తిని పంపవచ్చు, అయినప్పటికీ ఈ డేటాను రూపొందించడానికి ఓవర్‌హెడ్ ఉంటుంది.
అయితే, ఈ సందర్భంలో డేటా వెంటనే క్లిక్‌హౌస్‌కి పంపబడుతుంది. మరియు క్లిక్‌హౌస్ వాటిని స్వయంగా బఫర్ చేస్తుంది.
కానీ సమస్యలు కూడా తలెత్తుతాయి. ఇప్పుడు మీరు మీ ప్రాసెస్‌ని చంపినప్పుడు మరియు క్లిక్‌హౌస్ ప్రాసెస్‌ని చంపబడినప్పుడు సహా డేటాను కోల్పోతారు, ఎందుకంటే ఇది అసంపూర్ణ ఇన్సర్ట్ అవుతుంది. మరియు క్లిక్‌హౌస్‌లో ఇన్సర్ట్లు అడ్డు వరుసల పరిమాణంలో నిర్దిష్ట నిర్దేశిత థ్రెషోల్డ్ వరకు ఉంటాయి. సూత్రప్రాయంగా, ఇది ఒక ఆసక్తికరమైన మార్గం. కూడా ఉపయోగించవచ్చు.
విధానం 5. ఇక్కడ మరొక ఆసక్తికరమైన పద్ధతి. ఇది డేటా బ్యాచింగ్ కోసం కమ్యూనిటీ-అభివృద్ధి చేసిన ఒక రకమైన సర్వర్. నేను దానిని స్వయంగా చూడలేదు, కాబట్టి నేను దేనికీ హామీ ఇవ్వలేను. అయితే, ClickHouse కోసం ఎటువంటి హామీలు అందించబడలేదు. ఇది కూడా ఓపెన్ సోర్స్, కానీ మరోవైపు, మేము అందించడానికి ప్రయత్నించే కొన్ని నాణ్యత ప్రమాణాలకు మీరు ఉపయోగించబడవచ్చు. కానీ ఈ విషయం కోసం - నాకు తెలియదు, GitHubకి వెళ్లండి, కోడ్‌ని చూడండి. బహుశా వారు ఏదో మామూలుగా వ్రాసి ఉండవచ్చు.
* 2020 నాటికి, కూడా పరిగణనలోకి తీసుకోవాలి .
విధానం 6. బఫర్ పట్టికలను ఉపయోగించడం మరొక పద్ధతి. ఈ పద్ధతి యొక్క ప్రయోజనం ఏమిటంటే ఇది ఉపయోగించడం ప్రారంభించడం చాలా సులభం. బఫర్ పట్టికను సృష్టించండి మరియు దానిని దానిలోకి చొప్పించండి.
సమస్య పూర్తిగా పరిష్కారం కాకపోవడం ప్రతికూలత. ఒకవేళ, MergeTree వంటి రేట్‌లో, మీరు సెకనుకు ఒక బ్యాచ్ చొప్పున డేటాను సమూహపరచవలసి వస్తే, బఫర్ పట్టికలోని రేటులో, మీరు సెకనుకు కనీసం అనేక వేల వరకు సమూహపరచవలసి ఉంటుంది. సెకనుకు 10 కంటే ఎక్కువ ఉంటే, అది ఇంకా చెడ్డది. మరియు మీరు దానిని బ్యాచ్‌లలో చొప్పించినట్లయితే, అది సెకనుకు లక్ష పంక్తులుగా మారుతుందని మీరు చూశారు. మరియు ఇది ఇప్పటికే చాలా భారీ డేటాలో ఉంది.
మరియు బఫర్ పట్టికలకు లాగ్ లేదు. మరియు మీ సర్వర్‌లో ఏదైనా లోపం ఉంటే, అప్పుడు డేటా పోతుంది.
మరియు బోనస్‌గా, కాఫ్కా నుండి డేటాను తిరిగి పొందేందుకు క్లిక్‌హౌస్‌లో మాకు ఇటీవల అవకాశం లభించింది. టేబుల్ ఇంజిన్ ఉంది - కాఫ్కా. మీరు సృష్టించుకోండి. మరియు మీరు దానిపై మెటీరియలైజ్డ్ ప్రాతినిధ్యాలను వేలాడదీయవచ్చు. ఈ సందర్భంలో, ఇది కాఫ్కా నుండి డేటాను సంగ్రహిస్తుంది మరియు మీకు అవసరమైన పట్టికలలోకి చొప్పిస్తుంది.
మరియు ఈ అవకాశం గురించి ప్రత్యేకంగా సంతోషకరమైన విషయం ఏమిటంటే, దీన్ని చేసింది మేము కాదు. ఇది సంఘం లక్షణం. మరియు నేను "కమ్యూనిటీ ఫీచర్" అని చెప్పినప్పుడు, నా ఉద్దేశ్యం ఎటువంటి ధిక్కారం లేకుండా. మేము కోడ్‌ని చదివాము, సమీక్ష చేసాము, అది బాగా పని చేస్తుంది.
* 2020 నాటికి, ఇలాంటి మద్దతు కనిపించింది .
డేటాను చొప్పించేటప్పుడు ఇంకా ఏమి అసౌకర్యంగా లేదా ఊహించనిది కావచ్చు? మీరు ఇన్సర్ట్ విలువలను అభ్యర్థన చేస్తే మరియు విలువలలో కొన్ని లెక్కించిన వ్యక్తీకరణలను వ్రాయండి. ఉదాహరణకు, now() అనేది కూడా లెక్కించబడిన వ్యక్తీకరణ. మరియు ఈ సందర్భంలో, క్లిక్‌హౌస్ ప్రతి పంక్తిలో ఈ వ్యక్తీకరణల వ్యాఖ్యాతను ప్రారంభించవలసి వస్తుంది మరియు పనితీరు పరిమాణం యొక్క ఆర్డర్‌ల ద్వారా పడిపోతుంది. దీన్ని నివారించడం మంచిది.
* ప్రస్తుతానికి, సమస్య పూర్తిగా పరిష్కరించబడింది, VALUESలో ఎక్స్‌ప్రెషన్‌లను ఉపయోగిస్తున్నప్పుడు పనితీరు రిగ్రెషన్ ఉండదు.
మీరు విభజనల సమూహానికి చెందిన ఒక బ్యాచ్‌లో డేటాను కలిగి ఉన్నప్పుడు కొన్ని సమస్యలు ఉండవచ్చు మరొక ఉదాహరణ. డిఫాల్ట్‌గా, ClickHouse విభజనలు నెలవారీగా ఉంటాయి. మరియు మీరు మిలియన్ వరుసల బ్యాచ్‌ని ఇన్సర్ట్ చేస్తే, మరియు చాలా సంవత్సరాలు డేటా ఉంటే, మీరు అక్కడ అనేక డజన్ల విభజనలను కలిగి ఉంటారు. మరియు పరిమాణంలో అనేక పదుల రెట్లు చిన్న బ్యాచ్‌లు ఉంటాయి అనేదానికి ఇది సమానం, ఎందుకంటే లోపల అవి ఎల్లప్పుడూ మొదట విభజనలుగా విభజించబడతాయి.
* ఇటీవల, ప్రయోగాత్మక మోడ్‌లో, క్లిక్‌హౌస్ ర్యామ్‌లోని భాగాలు మరియు భాగాల కాంపాక్ట్ ఫార్మాట్‌కు రైట్-ఎహెడ్ లాగ్‌తో మద్దతును జోడించింది, ఇది దాదాపు పూర్తిగా సమస్యను పరిష్కరిస్తుంది.
ఇప్పుడు రెండవ రకమైన సమస్యను చూద్దాం - డేటా టైపింగ్.
డేటా టైపింగ్ కఠినంగా లేదా స్ట్రింగ్‌గా ఉండవచ్చు. స్ట్రింగ్ అంటే మీరు ఇప్పుడే దాన్ని తీసుకుని, మీ ఫీల్డ్‌లన్నీ స్ట్రింగ్ టైప్ అని ప్రకటించడం. ఇది పీల్చేది. ఇలా చేయాల్సిన అవసరం లేదు.
మన దగ్గర కొంత ఫీల్డ్, స్ట్రింగ్ ఉన్నాయని మీరు చెప్పాలనుకున్నప్పుడు ఆ సందర్భాలలో దీన్ని ఎలా సరిగ్గా చేయాలో తెలుసుకుందాం మరియు క్లిక్‌హౌస్‌ని దాని స్వంతంగా గుర్తించనివ్వండి మరియు నేను ఇబ్బంది పడను. కానీ ఇప్పటికీ కొంత ప్రయత్నం చేయడం విలువైనదే.
ఉదాహరణకు, మనకు IP చిరునామా ఉంది. ఒక సందర్భంలో, మేము దానిని స్ట్రింగ్‌గా సేవ్ చేసాము. ఉదాహరణకు, 192.168.1.1. మరియు మరొక సందర్భంలో, ఇది అనేక రకాల UInt32* అవుతుంది. IPv32 చిరునామాకు 4 బిట్‌లు సరిపోతాయి.
ముందుగా, విచిత్రమేమిటంటే, డేటా దాదాపు సమానంగా కుదించబడుతుంది. తేడా ఉంటుంది, అయితే పెద్దది కాదు. కాబట్టి డిస్క్ I/Oతో ప్రత్యేక సమస్యలు లేవు.
కానీ ప్రాసెసర్ సమయం మరియు ప్రశ్న అమలు సమయంలో తీవ్రమైన వ్యత్యాసం ఉంది.
ప్రత్యేక IP చిరునామాలు సంఖ్యలుగా నిల్వ చేయబడితే వాటి సంఖ్యను లెక్కిద్దాం. ఇది సెకనుకు 137 మిలియన్ లైన్లకు పని చేస్తుంది. అదే స్ట్రింగ్స్ రూపంలో ఉంటే, సెకనుకు 37 మిలియన్ లైన్లు. ఈ యాదృచ్చికం ఎందుకు జరిగిందో నాకు తెలియదు. ఈ అభ్యర్థనలను నేను స్వయంగా నిర్వహించాను. కానీ ఇప్పటికీ దాదాపు 4 రెట్లు నెమ్మదిగా.
మరియు మీరు డిస్క్ స్థలంలో వ్యత్యాసాన్ని లెక్కించినట్లయితే, అప్పుడు కూడా తేడా ఉంటుంది. మరియు వ్యత్యాసం దాదాపు పావు వంతు, ఎందుకంటే చాలా ప్రత్యేకమైన IP చిరునామాలు ఉన్నాయి. మరియు తక్కువ సంఖ్యలో విభిన్న అర్థాలతో పంక్తులు ఉంటే, అవి నిఘంటువు ప్రకారం దాదాపు ఒకే వాల్యూమ్‌లో సులభంగా కుదించబడతాయి.
మరియు నాలుగు రెట్లు సమయ వ్యత్యాసం రహదారిపై ఉండదు. బహుశా మీరు తిట్టుకోరు, అయితే, నేను అలాంటి తేడాను చూసినప్పుడు, అది నాకు బాధ కలిగిస్తుంది.
వివిధ కేసులను చూద్దాం.
1. మీరు కొన్ని విభిన్న ప్రత్యేక విలువలను కలిగి ఉన్నప్పుడు ఒక సందర్భం. ఈ సందర్భంలో, మేము మీకు బహుశా తెలిసిన మరియు ఏదైనా DBMS కోసం ఉపయోగించగల సాధారణ అభ్యాసాన్ని ఉపయోగిస్తాము. ఇది క్లిక్‌హౌస్‌కు మాత్రమే కాదు. డేటాబేస్‌లో సంఖ్యా ఐడెంటిఫైయర్లను వ్రాయండి. మరియు మీరు స్ట్రింగ్‌లకు మార్చవచ్చు మరియు మీ అప్లికేషన్ వైపు తిరిగి వెళ్లవచ్చు.
ఉదాహరణకు, మీకు ఒక ప్రాంతం ఉంది. మరియు మీరు దానిని స్ట్రింగ్‌గా సేవ్ చేయడానికి ప్రయత్నిస్తున్నారు. మరియు అది అక్కడ వ్రాయబడుతుంది: మాస్కో మరియు మాస్కో ప్రాంతం. మరియు అది "మాస్కో" అని నేను చూసినప్పుడు, అది ఏమీ కాదు, కానీ అది మాస్కో అయినప్పుడు, అది ఏదో ఒకవిధంగా పూర్తిగా విచారంగా మారుతుంది. ఇది ఎన్ని బైట్లు.
బదులుగా, మేము Ulnt32 మరియు 250 సంఖ్యలను వ్రాస్తాము. Yandexలో మాకు 250 ఉంది, కానీ మీది భిన్నంగా ఉండవచ్చు. ఒకవేళ, క్లిక్‌హౌస్‌కి జియోబేస్‌తో పని చేసే అంతర్నిర్మిత సామర్థ్యం ఉందని నేను చెబుతాను. మీరు క్రమానుగతమైన వాటితో సహా ప్రాంతాలతో కూడిన డైరెక్టరీని వ్రాస్తారు, అంటే మాస్కో, మాస్కో ప్రాంతం మరియు మీకు కావలసినవన్నీ ఉంటాయి. మరియు మీరు అభ్యర్థన స్థాయిలో మార్చవచ్చు.
రెండవ ఎంపిక దాదాపు అదే, కానీ క్లిక్‌హౌస్ లోపల మద్దతుతో. ఇది Enum డేటా రకం. మీరు Enum లోపల మీకు అవసరమైన అన్ని విలువలను వ్రాస్తారు. ఉదాహరణకు, పరికరం రకం మరియు అక్కడ వ్రాయండి: డెస్క్‌టాప్, మొబైల్, టాబ్లెట్, టీవీ. మొత్తం 4 ఎంపికలు ఉన్నాయి.
ప్రతికూలత ఏమిటంటే మీరు దానిని క్రమానుగతంగా మార్చాలి. కేవలం ఒక ఎంపిక జోడించబడింది. ఆల్టర్ టేబుల్ చేద్దాం. నిజానికి, క్లిక్‌హౌస్‌లోని ఆల్టర్ టేబుల్ ఉచితం. డిస్క్‌లోని డేటా మారదు కాబట్టి Enum కోసం ప్రత్యేకంగా ఉచితం. అయినప్పటికీ, ఆల్టర్ టేబుల్‌పై లాక్*ని పొందుతుంది మరియు అన్ని ఎంపికలు అమలు అయ్యే వరకు వేచి ఉండాలి. మరియు ఈ మార్పు తర్వాత మాత్రమే అమలు చేయబడుతుంది, అంటే ఇంకా కొన్ని అసౌకర్యాలు ఉన్నాయి.
* ClickHouse యొక్క తాజా వెర్షన్‌లలో, ALTER పూర్తిగా నిరోధించబడదు.
ClickHouse కోసం చాలా ప్రత్యేకమైన మరొక ఎంపిక బాహ్య నిఘంటువులను కనెక్ట్ చేయడం. మీరు క్లిక్‌హౌస్‌లో నంబర్‌లను వ్రాయవచ్చు మరియు మీ డైరెక్టరీలను మీకు అనుకూలమైన ఏదైనా సిస్టమ్‌లో ఉంచుకోవచ్చు. ఉదాహరణకు, మీరు వీటిని ఉపయోగించవచ్చు: MySQL, Mongo, Postgres. మీరు http ద్వారా ఈ డేటాను పంపే మీ స్వంత మైక్రోసర్వీస్‌ను కూడా సృష్టించవచ్చు. మరియు క్లిక్‌హౌస్ స్థాయిలో, మీరు ఈ డేటాను సంఖ్యల నుండి స్ట్రింగ్‌లకు మార్చే ఒక ఫంక్షన్‌ను వ్రాస్తారు.
బాహ్య పట్టికలో చేరడానికి ఇది ప్రత్యేకమైనది కానీ చాలా సమర్థవంతమైన మార్గం. మరియు రెండు ఎంపికలు ఉన్నాయి. ఒక అవతారంలో, ఈ డేటా పూర్తిగా కాష్ చేయబడుతుంది, RAMలో పూర్తిగా ఉంటుంది మరియు కొంత ఫ్రీక్వెన్సీతో నవీకరించబడుతుంది. మరియు మరొక ఎంపికలో, ఈ డేటా RAMకి సరిపోకపోతే, మీరు దానిని పాక్షికంగా కాష్ చేయవచ్చు.
ఇక్కడ ఒక ఉదాహరణ. Yandex.Direct ఉంది. మరియు ఒక ప్రకటనల సంస్థ మరియు బ్యానర్లు ఉన్నాయి. దాదాపు పదిలక్షల అడ్వర్టైజింగ్ కంపెనీలు ఉండవచ్చు. మరియు అవి దాదాపుగా RAMకి సరిపోతాయి. మరియు బిలియన్ల బ్యానర్లు ఉన్నాయి, అవి సరిపోవు. మరియు మేము MySQL నుండి కాష్ చేసిన నిఘంటువుని ఉపయోగిస్తాము.
ఒకే సమస్య ఏమిటంటే, హిట్ రేటు 100%కి దగ్గరగా ఉంటే కాష్ చేసిన నిఘంటువు బాగా పని చేస్తుంది. ఇది చిన్నదైతే, ప్రతి బ్యాచ్ డేటా కోసం ప్రశ్నలను ప్రాసెస్ చేస్తున్నప్పుడు, మీరు మిస్ అయిన కీలను తీసుకొని MySQL నుండి డేటాను పొందవలసి ఉంటుంది. ClickHouse గురించి, నేను ఇప్పటికీ హామీ ఇవ్వగలను - అవును, ఇది వేగాన్ని తగ్గించదు, నేను ఇతర సిస్టమ్‌ల గురించి మాట్లాడను.
మరియు బోనస్‌గా, క్లిక్‌హౌస్‌లో డేటాను ముందస్తుగా అప్‌డేట్ చేయడానికి నిఘంటువులు చాలా సులభమైన మార్గం. అంటే, మీరు ప్రకటనల కంపెనీలపై ఒక నివేదికను కలిగి ఉన్నారు, వినియోగదారు కేవలం ప్రకటనల కంపెనీని మార్చారు మరియు అన్ని పాత డేటాలో, అన్ని నివేదికలలో, ఈ డేటా కూడా మార్చబడింది. మీరు నేరుగా పట్టికకు వరుసలను వ్రాస్తే, వాటిని నవీకరించడం అసాధ్యం.
మీ స్ట్రింగ్‌ల కోసం ఐడెంటిఫైయర్లను ఎక్కడ పొందాలో మీకు తెలియనప్పుడు మరొక మార్గం. మీరు దానిని హాష్ చేయవచ్చు. అంతేకాకుండా, 64-బిట్ హాష్ తీసుకోవడం అనేది సరళమైన ఎంపిక.
ఒకే సమస్య ఏమిటంటే, హాష్ 64-బిట్ అయితే, మీరు దాదాపు ఖచ్చితంగా ఘర్షణలను కలిగి ఉంటారు. ఎందుకంటే అక్కడ ఒక బిలియన్ లైన్లు ఉంటే, సంభావ్యత ఇప్పటికే గుర్తించదగినది.
మరి ఈ విధంగా అడ్వర్టైజింగ్ కంపెనీల పేర్లను హ్యాష్ చేయడం చాలా మంచిది కాదు. వివిధ సంస్థల ప్రకటనల ప్రచారాలు కలగలిసి ఉంటే, అప్పుడు అర్థం కాని విషయం ఉంటుంది.
మరియు ఒక సాధారణ ట్రిక్ ఉంది. నిజమే, ఇది తీవ్రమైన డేటాకు కూడా చాలా సరిఅయినది కాదు, కానీ ఏదైనా చాలా తీవ్రమైనది కానట్లయితే, డిక్షనరీ కీకి క్లయింట్ ఐడెంటిఫైయర్‌ని జోడించండి. ఆపై మీరు ఘర్షణలను కలిగి ఉంటారు, కానీ ఒక క్లయింట్‌లో మాత్రమే. మరియు మేము Yandex.Metricaలో లింక్ మ్యాప్‌ల కోసం ఈ పద్ధతిని ఉపయోగిస్తాము. మేము అక్కడ URLలను కలిగి ఉన్నాము, మేము హాష్‌లను నిల్వ చేస్తాము. మరియు మనకు తెలుసు, వాస్తవానికి, ఘర్షణలు ఉన్నాయి. కానీ పేజీ ప్రదర్శించబడినప్పుడు, ఒక వినియోగదారు యొక్క ఒక పేజీలో కొన్ని URLలు ఒకదానితో ఒకటి అతుక్కుపోయి, ఇది గమనించబడే సంభావ్యతను విస్మరించవచ్చు.
బోనస్‌గా, అనేక కార్యకలాపాలకు హ్యాష్‌లు మాత్రమే సరిపోతాయి మరియు తీగలను ఎక్కడైనా నిల్వ చేయవలసిన అవసరం లేదు.
మరొక ఉదాహరణ స్ట్రింగ్స్ చిన్నగా ఉంటే, ఉదాహరణకు, వెబ్‌సైట్ డొమైన్‌లు. వాటిని యథాతథంగా నిల్వ చేసుకోవచ్చు. లేదా, ఉదాహరణకు, బ్రౌజర్ భాష ru 2 బైట్లు. అయితే, నేను నిజంగా బైట్‌ల పట్ల జాలిపడుతున్నాను, కానీ చింతించకండి, 2 బైట్లు జాలిగా లేవు. దయచేసి దానిని అలాగే ఉంచండి, చింతించకండి.
మరొక సందర్భం ఏమిటంటే, దీనికి విరుద్ధంగా, చాలా పంక్తులు ఉన్నాయి మరియు వాటిలో చాలా ప్రత్యేకమైనవి ఉన్నాయి మరియు సెట్ కూడా అపరిమితంగా ఉంటుంది. ఒక సాధారణ ఉదాహరణ శోధన పదబంధాలు లేదా URLలు. అక్షరదోషాలతో సహా పదబంధాలను శోధించండి. రోజుకు ఎన్ని ప్రత్యేకమైన శోధన పదబంధాలు ఉన్నాయో చూద్దాం. మరియు అవి అన్ని సంఘటనలలో దాదాపు సగం అని తేలింది. మరియు ఈ సందర్భంలో, మీరు డేటాను సాధారణీకరించాలని, ఐడెంటిఫైయర్లను లెక్కించి, ప్రత్యేక పట్టికలో ఉంచాలని మీరు అనుకోవచ్చు. కానీ మీరు అలా చేయవలసిన అవసరం లేదు. ఈ పంక్తులను అలాగే ఉంచండి.
దేనినీ కనిపెట్టకపోవడమే మంచిది, ఎందుకంటే మీరు దానిని విడిగా నిల్వ చేస్తే, మీరు చేరవలసి ఉంటుంది. మరియు ఈ చేరడం అనేది మెమొరీకి యాదృచ్ఛిక యాక్సెస్, ఇది ఇప్పటికీ మెమరీలో సరిపోయేది. ఇది సరిపోకపోతే, సమస్యలు వస్తాయి.
మరియు డేటా స్థానంలో నిల్వ చేయబడితే, అది ఫైల్ సిస్టమ్ నుండి అవసరమైన క్రమంలో చదవబడుతుంది మరియు ప్రతిదీ బాగానే ఉంటుంది.
మీకు URLలు లేదా కొన్ని ఇతర క్లిష్టమైన పొడవైన స్ట్రింగ్ ఉంటే, మీరు ముందుగానే కొంత సారాన్ని లెక్కించి ప్రత్యేక కాలమ్‌లో వ్రాయవచ్చని పరిగణనలోకి తీసుకోవడం విలువ.
URLల కోసం, ఉదాహరణకు, మీరు డొమైన్‌ను విడిగా నిల్వ చేయవచ్చు. మరియు మీకు నిజంగా డొమైన్ అవసరమైతే, ఈ నిలువు వరుసను ఉపయోగించండి మరియు URLలు అక్కడ ఉంటాయి మరియు మీరు వాటిని తాకలేరు.
తేడా ఏమిటో చూద్దాం. ClickHouse డొమైన్‌ను లెక్కించే ప్రత్యేక ఫంక్షన్‌ను కలిగి ఉంది. ఇది చాలా వేగంగా ఉంది, మేము దానిని ఆప్టిమైజ్ చేసాము. మరియు, నిజం చెప్పాలంటే, ఇది RFCకి కూడా అనుగుణంగా లేదు, అయితే ఇది మనకు అవసరమైన ప్రతిదాన్ని పరిగణిస్తుంది.
మరియు ఒక సందర్భంలో మేము URLలను పొందుతాము మరియు డొమైన్‌ను గణిస్తాము. అది 166 మిల్లీసెకన్ల వరకు పని చేస్తుంది. మరియు మీరు రెడీమేడ్ డొమైన్‌ను తీసుకుంటే, అది కేవలం 67 మిల్లీసెకన్లు మాత్రమే అవుతుంది, అంటే దాదాపు మూడు రెట్లు వేగంగా ఉంటుంది. మరియు ఇది వేగవంతమైనది మనం కొన్ని గణనలను చేయవలసి ఉన్నందున కాదు, కానీ మేము తక్కువ డేటాను చదవడం వలన.
అందుకే నెమ్మదిగా ఉండే ఒక అభ్యర్థన సెకనుకు గిగాబైట్ల వేగంతో ఉంటుంది. ఎందుకంటే ఇది ఎక్కువ గిగాబైట్లను చదువుతుంది. ఇది పూర్తిగా అనవసరమైన డేటా. అభ్యర్థన వేగంగా నడుస్తున్నట్లు కనిపిస్తోంది, కానీ పూర్తి కావడానికి ఎక్కువ సమయం పడుతుంది.
మరియు మీరు డిస్క్‌లోని డేటా మొత్తాన్ని చూస్తే, URL 126 మెగాబైట్లు మరియు డొమైన్ 5 మెగాబైట్లు మాత్రమే అని తేలింది. ఇది 25 రెట్లు తక్కువగా మారుతుంది. అయితే, అభ్యర్థన 4 రెట్లు వేగంగా మాత్రమే అమలు చేయబడుతుంది. కానీ డేటా వేడిగా ఉన్నందున. మరియు అది చల్లగా ఉంటే, డిస్క్ I/O కారణంగా ఇది బహుశా 25 రెట్లు వేగంగా ఉంటుంది.
అదే విధంగా, URL కంటే డొమైన్ ఎంత చిన్నదో మీరు అంచనా వేస్తే, అది దాదాపు 4 రెట్లు చిన్నదిగా మారుతుంది. కానీ కొన్ని కారణాల వల్ల, డిస్క్‌లో డేటా 25 రెట్లు తక్కువగా పడుతుంది. ఎందుకు? కుదింపు కారణంగా. మరియు URL కంప్రెస్ చేయబడింది మరియు డొమైన్ కంప్రెస్ చేయబడింది. కానీ తరచుగా URLలో చెత్త సమూహం ఉంటుంది.
మరియు, వాస్తవానికి, కావలసిన విలువల కోసం ప్రత్యేకంగా రూపొందించబడిన లేదా తగిన డేటా రకాలను ఉపయోగించడం చెల్లిస్తుంది. మీరు IPv4లో ఉన్నట్లయితే, UInt32*ని నిల్వ చేయండి. IPv6 అయితే, FixedString(16), ఎందుకంటే IPv6 చిరునామా 128 బిట్‌లు, అనగా నేరుగా బైనరీ ఫార్మాట్‌లో నిల్వ చేయబడుతుంది.
మీరు కొన్నిసార్లు IPv4 చిరునామాలను మరియు కొన్నిసార్లు IPv6ని కలిగి ఉంటే ఏమి చేయాలి? అవును, మీరు రెండింటినీ నిల్వ చేయవచ్చు. IPv4 కోసం ఒక నిలువు వరుస, IPv6 కోసం మరొకటి. వాస్తవానికి, IPv4లో IPv6ని ప్రదర్శించడానికి ఒక ఎంపిక ఉంది. ఇది కూడా పని చేస్తుంది, కానీ మీకు తరచుగా అభ్యర్థనలలో IPv4 చిరునామా అవసరమైతే, దానిని ప్రత్యేక కాలమ్‌లో ఉంచడం మంచిది.
* ClickHouse ఇప్పుడు వేర్వేరు IPv4, IPv6 డేటా రకాలను కలిగి ఉంది, ఇవి డేటాను సంఖ్యల వలె సమర్థవంతంగా నిల్వ చేస్తాయి, కానీ వాటిని స్ట్రింగ్‌ల వలె సౌకర్యవంతంగా సూచిస్తాయి.
డేటాను ముందుగానే ప్రాసెస్ చేయడం విలువైనదని కూడా గమనించడం ముఖ్యం. ఉదాహరణకు, మీరు కొన్ని ముడి లాగ్లను స్వీకరిస్తారు. మరియు మీరు వాటిని వెంటనే క్లిక్‌హౌస్‌లో ఉంచకూడదు, అయినప్పటికీ ఏమీ చేయకపోవడం చాలా ఉత్సాహం కలిగిస్తుంది మరియు ప్రతిదీ పని చేస్తుంది. కానీ ఇప్పటికీ సాధ్యమయ్యే గణనలను నిర్వహించడం విలువ.
ఉదాహరణకు, బ్రౌజర్ వెర్షన్. కొన్ని సమీప విభాగంలో, నేను వేలు పెట్టకూడదనుకుంటున్నాను, బ్రౌజర్ వెర్షన్ ఇలా నిల్వ చేయబడుతుంది, అంటే స్ట్రింగ్‌గా: 12.3. ఆపై, ఒక నివేదికను రూపొందించడానికి, వారు ఈ స్ట్రింగ్‌ను తీసుకొని దానిని శ్రేణిగా విభజించి, ఆపై శ్రేణి యొక్క మొదటి మూలకంలోకి విభజిస్తారు. సహజంగానే, ప్రతిదీ నెమ్మదిస్తుంది. ఇలా ఎందుకు చేస్తారని అడిగాను. వారు అకాల ఆప్టిమైజేషన్‌ను ఇష్టపడరని వారు నాకు చెప్పారు. మరియు నేను అకాల నిరాశావాదాన్ని ఇష్టపడను.
కాబట్టి ఈ సందర్భంలో 4 నిలువు వరుసలుగా విభజించడం మరింత సరైనది. ఇక్కడ భయపడవద్దు, ఎందుకంటే ఇది క్లిక్‌హౌస్. ClickHouse అనేది నిలువుగా ఉండే డేటాబేస్. మరియు మరింత చక్కగా చిన్న నిలువు వరుసలు, ఉత్తమం. 5 బ్రౌజర్ వెర్షన్‌లు ఉంటాయి, 5 నిలువు వరుసలను రూపొందించండి. ఇది బాగానే ఉంది.
మీకు చాలా పొడవైన తీగలు, చాలా పొడవైన శ్రేణులు ఉంటే ఏమి చేయాలో ఇప్పుడు చూద్దాం. వాటిని క్లిక్‌హౌస్‌లో నిల్వ చేయాల్సిన అవసరం లేదు. బదులుగా, మీరు క్లిక్‌హౌస్‌లో ఐడెంటిఫైయర్‌ను మాత్రమే నిల్వ చేయగలరు. మరియు ఈ పొడవైన పంక్తులను వేరే వ్యవస్థలో ఉంచండి.
ఉదాహరణకు, మా అనలిటిక్స్ సేవల్లో ఒకదానికి కొన్ని ఈవెంట్ పారామీటర్‌లు ఉన్నాయి. మరియు ఈవెంట్‌ల కోసం అనేక పారామీటర్‌లు ఉంటే, మేము అంతటా వచ్చే మొదటి 512ని సేవ్ చేస్తాము. ఎందుకంటే 512 పాపం కాదు.
మరియు మీరు మీ డేటా రకాలను నిర్ణయించలేకపోతే, మీరు క్లిక్‌హౌస్‌లో డేటాను రికార్డ్ చేయవచ్చు, కానీ లాగ్ రకం యొక్క తాత్కాలిక పట్టికలో, తాత్కాలిక డేటా కోసం ప్రత్యేకంగా ఉంటుంది. దీని తరువాత, మీరు అక్కడ ఉన్న విలువల పంపిణీని విశ్లేషించవచ్చు, సాధారణంగా ఏమి ఉంది మరియు సరైన రకాలను సృష్టించవచ్చు.
*ClickHouse ఇప్పుడు డేటా రకాన్ని కలిగి ఉంది ఇది తక్కువ శ్రమతో స్ట్రింగ్‌లను సమర్థవంతంగా నిల్వ చేయడానికి మిమ్మల్ని అనుమతిస్తుంది.
ఇప్పుడు మరో ఆసక్తికరమైన కేసు చూద్దాం. కొన్నిసార్లు విషయాలు ప్రజలకు వింతగా పని చేస్తాయి. నేను లోపలికి వచ్చి ఇది చూస్తాను. మరియు ఇది MySQL వెర్షన్ 3.23ని సెటప్ చేయడంలో విస్తృతమైన అనుభవం ఉన్న చాలా అనుభవజ్ఞులైన, స్మార్ట్ అడ్మిన్ ద్వారా చేసినట్లు వెంటనే తెలుస్తోంది.
ఇక్కడ మనం వెయ్యి పట్టికలను చూస్తాము, వీటిలో ప్రతి ఒక్కటి వెయ్యితో ఎవరికి ఏమి తెలుసు అని భాగిస్తే మిగిలిన వాటిని నమోదు చేస్తుంది.
సూత్రప్రాయంగా, ఈ అనుభవం ద్వారా పొందగలిగే బాధల అవగాహనతో సహా ఇతర వ్యక్తుల అనుభవాన్ని నేను గౌరవిస్తాను.
మరియు కారణాలు ఎక్కువ లేదా తక్కువ స్పష్టంగా ఉన్నాయి. ఇవి ఇతర సిస్టమ్‌లతో పనిచేసేటప్పుడు పేరుకుపోయిన పాత మూసలు. ఉదాహరణకు, MyISAM పట్టికలు క్లస్టర్డ్ ప్రైమరీ కీని కలిగి ఉండవు. మరియు డేటాను విభజించే ఈ మార్గం అదే కార్యాచరణను పొందడానికి తీరని ప్రయత్నం కావచ్చు.
మరొక కారణం ఏమిటంటే, పెద్ద టేబుల్‌లపై ఏదైనా ఆల్టర్ ఆపరేషన్‌లు చేయడం కష్టం. ప్రతిదీ బ్లాక్ చేయబడుతుంది. MySQL యొక్క ఆధునిక సంస్కరణల్లో ఈ సమస్య అంత తీవ్రంగా లేదు.
లేదా, ఉదాహరణకు, మైక్రోషార్డింగ్, కానీ తర్వాత మరింత.
ClickHouseలో దీన్ని చేయవలసిన అవసరం లేదు, ఎందుకంటే, మొదటగా, ప్రాథమిక కీ క్లస్టర్ చేయబడింది, డేటా ప్రాథమిక కీ ద్వారా ఆదేశించబడుతుంది.
మరియు కొన్నిసార్లు వ్యక్తులు నన్ను ఇలా అడుగుతారు: "క్లిక్‌హౌస్‌లోని శ్రేణి ప్రశ్నల పనితీరు పట్టిక పరిమాణంపై ఆధారపడి ఎలా మారుతుంది?" ఇది అస్సలు మారదని నేను చెప్తున్నాను. ఉదాహరణకు, మీరు ఒక బిలియన్ అడ్డు వరుసలతో పట్టికను కలిగి ఉన్నారు మరియు మీరు ఒక మిలియన్ వరుసల పరిధిని చదివారు. అంతా బాగానే ఉంది. ఒక టేబుల్‌లో ట్రిలియన్ అడ్డు వరుసలు ఉంటే మరియు మీరు ఒక మిలియన్ వరుసలను చదివితే, అది దాదాపు అదే విధంగా ఉంటుంది.
మరియు, రెండవది, మాన్యువల్ విభజనల వంటి అన్ని రకాల విషయాలు అవసరం లేదు. మీరు లోపలికి వెళ్లి ఫైల్ సిస్టమ్‌లో ఏముందో చూస్తే, టేబుల్ చాలా పెద్ద విషయం అని మీరు చూస్తారు. మరియు లోపల విభజనలు వంటివి ఉన్నాయి. అంటే, ClickHouse మీ కోసం ప్రతిదీ చేస్తుంది మరియు మీరు బాధపడాల్సిన అవసరం లేదు.
యాడ్/డ్రాప్ కాలమ్‌ని మార్చినట్లయితే క్లిక్‌హౌస్‌లో ఆల్టర్ ఉచితం.
మరియు మీరు చిన్న పట్టికలను తయారు చేయకూడదు, ఎందుకంటే మీరు పట్టికలో 10 వరుసలు లేదా 10 వరుసలు కలిగి ఉంటే, అది అస్సలు పట్టింపు లేదు. క్లిక్‌హౌస్ అనేది నిర్గమాంశను ఆప్టిమైజ్ చేసే సిస్టమ్, జాప్యం కాదు, కాబట్టి 000 లైన్‌లను ప్రాసెస్ చేయడంలో అర్ధమే లేదు.
ఒక పెద్ద పట్టికను ఉపయోగించడం సరైనది. పాత మూస పద్ధతులను వదిలించుకోండి, ప్రతిదీ బాగానే ఉంటుంది.
మరియు బోనస్‌గా, తాజా సంస్కరణలో వ్యక్తిగత విభజనలపై అన్ని రకాల నిర్వహణ కార్యకలాపాలను నిర్వహించడానికి మేము ఇప్పుడు ఏకపక్ష విభజన కీని సృష్టించగల సామర్థ్యాన్ని కలిగి ఉన్నాము.
ఉదాహరణకు, మీకు చాలా చిన్న పట్టికలు అవసరం, ఉదాహరణకు, కొన్ని ఇంటర్మీడియట్ డేటాను ప్రాసెస్ చేయాల్సిన అవసరం ఉన్నప్పుడు, మీరు భాగాలను స్వీకరిస్తారు మరియు తుది పట్టికకు వ్రాయడానికి ముందు మీరు వాటిపై పరివర్తన చేయాలి. ఈ సందర్భంలో, ఒక అద్భుతమైన టేబుల్ ఇంజిన్ ఉంది - స్ట్రిప్లాగ్. ఇది TinyLog లాంటిది, మాత్రమే మంచిది.
* ఇప్పుడు క్లిక్‌హౌస్ కూడా ఉంది .
మరొక యాంటీప్యాటర్న్ మైక్రోషార్డింగ్. ఉదాహరణకు, మీరు డేటాను ముక్కలు చేయాలి మరియు మీకు 5 సర్వర్లు ఉన్నాయి మరియు రేపు 6 సర్వర్లు ఉంటాయి. మరియు ఈ డేటాను ఎలా రీబ్యాలెన్స్ చేయాలో మీరు ఆలోచిస్తారు. మరియు బదులుగా మీరు 5 ముక్కలుగా కాకుండా 1 ముక్కలుగా విభజించండి. ఆపై మీరు ఈ మైక్రోషార్డ్‌లలో ప్రతి ఒక్కటి ప్రత్యేక సర్వర్‌కు మ్యాప్ చేయండి. మరియు మీరు ఉదాహరణకు, ఒక సర్వర్‌లో 000 క్లిక్‌హౌస్‌లను పొందుతారు. ప్రత్యేక పోర్ట్‌లు లేదా ప్రత్యేక డేటాబేస్‌లపై ప్రత్యేక సందర్భాలు.
కానీ క్లిక్‌హౌస్‌లో ఇది చాలా మంచిది కాదు. ఎందుకంటే ఒక క్లిక్‌హౌస్ ఉదాహరణ కూడా ఒక అభ్యర్థనను ప్రాసెస్ చేయడానికి అందుబాటులో ఉన్న అన్ని సర్వర్ వనరులను ఉపయోగించడానికి ప్రయత్నిస్తుంది. అంటే, మీకు ఒక రకమైన సర్వర్ ఉంది మరియు దీనికి 56 ప్రాసెసర్ కోర్లు ఉన్నాయి. మీరు ఒక సెకను సమయం తీసుకునే ప్రశ్నను అమలు చేస్తున్నారు మరియు అది 56 కోర్లను ఉపయోగిస్తుంది. మరియు మీరు ఒక సర్వర్‌లో 200 క్లిక్‌హౌస్‌లను ఉంచినట్లయితే, 10 థ్రెడ్‌లు ప్రారంభమవుతాయని తేలింది. సాధారణంగా, ప్రతిదీ చాలా చెడ్డగా ఉంటుంది.
మరొక కారణం ఏమిటంటే, ఈ సందర్భాలలో పని పంపిణీ అసమానంగా ఉంటుంది. కొన్ని ముందుగా పూర్తవుతాయి, కొన్ని తరువాత పూర్తవుతాయి. ఇవన్నీ ఒకే సందర్భంలో జరిగితే, థ్రెడ్‌ల మధ్య డేటాను ఎలా సరిగ్గా పంపిణీ చేయాలో ClickHouse స్వయంగా కనుగొంటుంది.
మరియు మరొక కారణం ఏమిటంటే, మీకు TCP ద్వారా ఇంటర్‌ప్రాసెసర్ కమ్యూనికేషన్ ఉంటుంది. డేటాను సీరియలైజ్ చేయాలి, డీరియలైజ్ చేయాలి మరియు ఇది భారీ సంఖ్యలో మైక్రోషార్డ్‌లు. ఇది కేవలం సమర్థవంతంగా పని చేయదు.
మరొక యాంటీప్యాటర్న్, దీనిని యాంటీప్యాటర్న్ అని పిలవలేము. ఇది ప్రీ-అగ్రిగేషన్ యొక్క పెద్ద మొత్తం.
సాధారణంగా, ప్రీ-అగ్రిగేషన్ మంచిది. మీరు ఒక బిలియన్ అడ్డు వరుసలను కలిగి ఉన్నారు, మీరు దానిని సమగ్రపరిచారు మరియు అది 1 వరుసలుగా మారింది మరియు ఇప్పుడు ప్రశ్న తక్షణమే అమలు చేయబడుతుంది. అంతా గొప్పగా ఉంది. మీరు దీన్ని చేయవచ్చు. మరియు దీని కోసం, ClickHouse కూడా ఒక ప్రత్యేక పట్టిక రకం, AggregatingMergeTreeని కలిగి ఉంది, ఇది డేటా చొప్పించినప్పుడు పెరుగుతున్న అగ్రిగేషన్‌ను నిర్వహిస్తుంది.
కానీ మేము ఇలా డేటాను అగ్రిగేట్ చేస్తాం మరియు ఇలా డేటాను సమగ్రపరుస్తాము అని మీరు అనుకునే సందర్భాలు ఉన్నాయి. మరియు కొన్ని పొరుగు డిపార్ట్‌మెంట్‌లలో, నేను ఏది చెప్పదలచుకోలేదు, వారు ప్రాథమిక కీ ద్వారా సంగ్రహించడానికి SummingMergeTree పట్టికలను ఉపయోగిస్తారు మరియు దాదాపు 20 నిలువు వరుసలు ప్రాథమిక కీగా ఉపయోగించబడతాయి. ఒకవేళ, నేను గోప్యత కోసం కొన్ని నిలువు వరుసల పేర్లను మార్చాను, కానీ అది చాలా చక్కనిది.
మరియు అలాంటి సమస్యలు తలెత్తుతాయి. ముందుగా, మీ డేటా వాల్యూమ్ ఎక్కువగా తగ్గదు. ఉదాహరణకు, ఇది మూడు రెట్లు తగ్గుతుంది. మీ డేటాను సమగ్రపరచనట్లయితే ఉత్పన్నమయ్యే అపరిమిత విశ్లేషణల సామర్థ్యాలను పొందేందుకు మూడు సార్లు మంచి ధర ఉంటుంది. డేటా సమగ్రంగా ఉంటే, విశ్లేషణలకు బదులుగా మీరు దయనీయమైన గణాంకాలను మాత్రమే పొందుతారు.
మరి ఇందులో విశేషం ఏముంది? వాస్తవం ఏమిటంటే, పొరుగు విభాగానికి చెందిన వారు కొన్నిసార్లు వెళ్లి ప్రాథమిక కీకి మరొక కాలమ్ జోడించమని అడుగుతారు. అంటే, మేము ఈ విధంగా డేటాను సమీకరించాము, కానీ ఇప్పుడు మనకు కొంచెం ఎక్కువ కావాలి. కానీ ClickHouseకి ఆల్టర్ ప్రైమరీ కీ లేదు. అందువల్ల, మనం కొన్ని స్క్రిప్ట్‌లను C++ లో వ్రాయాలి. మరియు నాకు స్క్రిప్ట్‌లు నచ్చవు, అవి C++లో ఉన్నప్పటికీ.
మరియు క్లిక్‌హౌస్ దేని కోసం సృష్టించబడిందో మీరు చూస్తే, సంగ్రహించని డేటా ఖచ్చితంగా అది పుట్టిన దృశ్యం. మీరు సమగ్ర డేటా కోసం ClickHouseని ఉపయోగిస్తుంటే, మీరు సరిగ్గానే చేస్తున్నారు. మీరు సమీకరించినట్లయితే, ఇది కొన్నిసార్లు క్షమించదగినది.
మరొక ఆసక్తికరమైన సందర్భం అనంతమైన లూప్‌లోని ప్రశ్నలు. కొన్నిసార్లు నేను కొన్ని ప్రొడక్షన్ సర్వర్‌కి వెళ్లి అక్కడ షో ప్రాసెస్‌లిస్ట్‌ని చూస్తాను. మరియు ప్రతిసారీ భయంకరమైన ఏదో జరుగుతోందని నేను కనుగొన్నాను.
ఉదాహరణకు, ఇలా. ఒక అభ్యర్థనలో ప్రతిదీ చేయవచ్చని వెంటనే స్పష్టమవుతుంది. కేవలం url మరియు అక్కడ జాబితా వ్రాయండి.
అంతులేని లూప్‌లో ఇలాంటి అనేక ప్రశ్నలు ఎందుకు చెడ్డవి? ఇండెక్స్ ఉపయోగించబడకపోతే, అదే డేటాపై మీకు చాలా పాస్‌లు ఉంటాయి. కానీ సూచిక ఉపయోగించబడితే, ఉదాహరణకు, మీరు ru కోసం ప్రాథమిక కీని కలిగి ఉంటారు మరియు మీరు అక్కడ url = ఏదో వ్రాస్తారు. మరియు మీరు టేబుల్ నుండి ఒక URL మాత్రమే చదివితే, అంతా బాగానే ఉంటుందని మీరు అనుకుంటున్నారు. కానీ నిజానికి లేదు. ఎందుకంటే క్లిక్‌హౌస్ బ్యాచ్‌లలో ప్రతిదీ చేస్తుంది.
అతను నిర్దిష్ట శ్రేణి డేటాను చదవాల్సిన అవసరం వచ్చినప్పుడు, అతను కొంచెం ఎక్కువగా చదువుతాడు, ఎందుకంటే ClickHouseలోని సూచిక చాలా తక్కువగా ఉంటుంది. ఈ సూచిక పట్టికలో ఒక వ్యక్తిగత అడ్డు వరుసను కనుగొనడానికి మిమ్మల్ని అనుమతించదు, కొన్ని రకాల పరిధి మాత్రమే. మరియు డేటా బ్లాక్‌లలో కంప్రెస్ చేయబడింది. ఒక పంక్తిని చదవడానికి, మీరు మొత్తం బ్లాక్‌ని తీసుకొని దాన్ని అన్‌క్లెంచ్ చేయాలి. మరియు మీరు ప్రశ్నల సమూహాన్ని చేస్తుంటే, మీకు చాలా అతివ్యాప్తి ఉంటుంది మరియు మీరు మళ్లీ మళ్లీ చేయడానికి చాలా పనిని కలిగి ఉంటారు.
మరియు బోనస్‌గా, క్లిక్‌హౌస్‌లో మీరు మెగాబైట్‌లను మరియు వందల కొద్దీ మెగాబైట్‌లను కూడా IN విభాగానికి బదిలీ చేయడానికి భయపడకూడదని మీరు గమనించవచ్చు. MySQLలో మనం కొన్ని విలువలను IN విభాగానికి బదిలీ చేస్తే, ఉదాహరణకు, మేము అక్కడ 100 మెగాబైట్ల కొన్ని సంఖ్యలను బదిలీ చేస్తే, MySQL 10 గిగాబైట్ల మెమరీని తింటుంది మరియు మరేమీ జరగదని మా అభ్యాసం నుండి నాకు గుర్తుంది. పేలవంగా పనిచేస్తుంది.
మరియు రెండవది క్లిక్‌హౌస్‌లో, మీ ప్రశ్నలు సూచికను ఉపయోగిస్తే, అది ఎల్లప్పుడూ పూర్తి స్కాన్ కంటే నెమ్మదిగా ఉండదు, అంటే మీరు దాదాపు మొత్తం పట్టికను చదవవలసి వస్తే, అది వరుసగా వెళ్లి మొత్తం పట్టికను చదువుతుంది. సాధారణంగా, అతను దానిని స్వయంగా కనుగొంటాడు.
అయితే, కొన్ని ఇబ్బందులు ఉన్నాయి. ఉదాహరణకు, సబ్‌క్వెరీతో IN సూచికను ఉపయోగించదు. కానీ ఇది మా సమస్య మరియు మేము దానిని పరిష్కరించాలి. ఇక్కడ ప్రాథమికంగా ఏమీ లేదు. మేము దాన్ని పరిష్కరిస్తాము*.
మరియు మరొక ఆసక్తికరమైన విషయం ఏమిటంటే, మీకు చాలా పొడవైన అభ్యర్థన ఉంటే మరియు పంపిణీ చేయబడిన అభ్యర్థన ప్రాసెసింగ్ పురోగతిలో ఉంటే, ఈ చాలా పొడవైన అభ్యర్థన కుదింపు లేకుండా ప్రతి సర్వర్‌కు పంపబడుతుంది. ఉదాహరణకు, 100 మెగాబైట్లు మరియు 500 సర్వర్లు. మరియు, తదనుగుణంగా, మీరు నెట్వర్క్లో 50 గిగాబైట్లను బదిలీ చేస్తారు. ఇది ప్రసారం చేయబడుతుంది మరియు అప్పుడు ప్రతిదీ విజయవంతంగా పూర్తవుతుంది.
* ఇప్పటికే ఉపయోగించడం; వాగ్దానం చేసినట్లు ప్రతిదీ పరిష్కరించబడింది.
మరియు API నుండి అభ్యర్థనలు వచ్చినప్పుడు చాలా సాధారణ సందర్భం. ఉదాహరణకు, మీరు మీ స్వంత సేవను సృష్టించారు. మరియు ఎవరికైనా మీ సేవ అవసరమైతే, మీరు APIని తెరిచి, అక్షరాలా రెండు రోజుల తర్వాత అపారమయిన ఏదో జరుగుతున్నట్లు మీరు చూస్తారు. ప్రతిదీ ఓవర్‌లోడ్ చేయబడింది మరియు ఎప్పుడూ జరగకూడని కొన్ని భయంకరమైన అభ్యర్థనలు వస్తున్నాయి.
మరియు ఒకే ఒక పరిష్కారం ఉంది. మీరు APIని తెరిచి ఉంటే, మీరు దానిని కట్ చేయాలి. ఉదాహరణకు, కొన్ని రకాల కోటాలను పరిచయం చేయండి. ఇతర సాధారణ ఎంపికలు లేవు. లేదంటే వెంటనే స్క్రిప్టు రాసి సమస్యలు వస్తాయి.
మరియు ClickHouseకి ప్రత్యేక ఫీచర్ ఉంది - కోటా లెక్కింపు. అంతేకాకుండా, మీరు మీ కోటా కీని బదిలీ చేయవచ్చు. ఇది, ఉదాహరణకు, అంతర్గత వినియోగదారు ID. మరియు వాటిలో ప్రతిదానికి కోటాలు స్వతంత్రంగా లెక్కించబడతాయి.
ఇప్పుడు మరో ఆసక్తికరమైన విషయం. ఇది మాన్యువల్ రెప్లికేషన్.
క్లిక్‌హౌస్‌లో అంతర్నిర్మిత ప్రతిరూపణ మద్దతు ఉన్నప్పటికీ, వ్యక్తులు క్లిక్‌హౌస్‌ని మాన్యువల్‌గా పునరావృతం చేసే అనేక సందర్భాలు నాకు తెలుసు.
సూత్రం ఏమిటి? మీకు డేటా ప్రాసెసింగ్ పైప్‌లైన్ ఉంది. మరియు ఇది స్వతంత్రంగా పనిచేస్తుంది, ఉదాహరణకు, వివిధ డేటా సెంటర్లలో. మీరు క్లిక్‌హౌస్‌లో అదే డేటాను అదే విధంగా వ్రాస్తారు. నిజమే, మీ కోడ్‌లోని కొన్ని ఫీచర్‌ల కారణంగా డేటా ఇప్పటికీ భిన్నంగా ఉంటుందని అభ్యాసం చూపిస్తుంది. ఇది మీలో ఉందని నేను ఆశిస్తున్నాను.
మరియు ఎప్పటికప్పుడు మీరు మాన్యువల్‌గా సమకాలీకరించవలసి ఉంటుంది. ఉదాహరణకు, నెలకు ఒకసారి నిర్వాహకులు rsync చేస్తారు.
వాస్తవానికి, క్లిక్‌హౌస్‌లో నిర్మించిన ప్రతిరూపణను ఉపయోగించడం చాలా సులభం. కానీ కొన్ని వ్యతిరేకతలు ఉండవచ్చు, ఎందుకంటే దీని కోసం మీరు ZooKeeperని ఉపయోగించాలి. నేను ZooKeeper గురించి చెడుగా ఏమీ చెప్పను, సూత్రప్రాయంగా, సిస్టమ్ పనిచేస్తుంది, కానీ జావా-ఫోబియా కారణంగా ప్రజలు దీనిని ఉపయోగించరు, ఎందుకంటే ClickHouse చాలా మంచి వ్యవస్థ, ఇది C++లో వ్రాయబడింది, మీరు ఉపయోగించవచ్చు మరియు అంతా బాగానే ఉంటుంది . మరియు ZooKeeper జావాలో ఉంది. మరియు ఏదో ఒకవిధంగా మీరు చూడాలని కూడా కోరుకోరు, కానీ మీరు మాన్యువల్ రెప్లికేషన్‌ని ఉపయోగించవచ్చు.
ClickHouse ఒక ఆచరణాత్మక వ్యవస్థ. ఆమె మీ అవసరాలను పరిగణనలోకి తీసుకుంటుంది. మీరు మాన్యువల్ రెప్లికేషన్ కలిగి ఉంటే, మీరు మీ మాన్యువల్ ప్రతిరూపాలను చూసే మరియు వాటి మధ్య వైఫల్యాన్ని చేసే పంపిణీ పట్టికను సృష్టించవచ్చు. మరియు మీ పంక్తులు క్రమపద్ధతిలో వేర్వేరుగా ఉన్నప్పటికీ, ఫ్లాప్‌లను నివారించడానికి మిమ్మల్ని అనుమతించే ప్రత్యేక ఎంపిక కూడా ఉంది.
మీరు ఆదిమ టేబుల్ ఇంజిన్లను ఉపయోగిస్తే మరిన్ని సమస్యలు తలెత్తవచ్చు. ClickHouse అనేది విభిన్న టేబుల్ ఇంజిన్‌ల సమూహాన్ని కలిగి ఉన్న కన్స్ట్రక్టర్. అన్ని తీవ్రమైన కేసుల కోసం, డాక్యుమెంటేషన్‌లో వ్రాసినట్లుగా, MergeTree కుటుంబం నుండి పట్టికలను ఉపయోగించండి. మరియు మిగిలినవి - ఇది వ్యక్తిగత కేసుల కోసం లేదా పరీక్షల కోసం.
MergeTree పట్టికలో, మీరు ఏ తేదీ మరియు సమయాన్ని కలిగి ఉండవలసిన అవసరం లేదు. మీరు దీన్ని ఇప్పటికీ ఉపయోగించవచ్చు. తేదీ మరియు సమయం లేకపోతే, డిఫాల్ట్ 2000 అని వ్రాయండి. ఇది పని చేస్తుంది మరియు వనరులు అవసరం లేదు.
మరియు సర్వర్ యొక్క క్రొత్త సంస్కరణలో, మీరు విభజన కీ లేకుండా అనుకూల విభజనను కలిగి ఉన్నారని కూడా పేర్కొనవచ్చు. అలాగే ఉంటుంది.
మరోవైపు, మీరు ఆదిమ టేబుల్ ఇంజిన్లను ఉపయోగించవచ్చు. ఉదాహరణకు, ఒకసారి డేటాను పూరించండి మరియు చూడండి, ట్విస్ట్ మరియు తొలగించండి. మీరు లాగ్‌ని ఉపయోగించవచ్చు.
లేదా ఇంటర్మీడియట్ ప్రాసెసింగ్ కోసం చిన్న వాల్యూమ్‌లను నిల్వ చేయడం స్ట్రిప్లాగ్ లేదా టైనీలాగ్.
డేటా మొత్తం తక్కువగా ఉంటే మెమరీని ఉపయోగించవచ్చు మరియు మీరు ర్యామ్‌లో ఏదైనా ట్విడిల్ చేయవచ్చు.
రీనార్మలైజ్ చేసిన డేటాను క్లిక్‌హౌస్ నిజంగా ఇష్టపడదు.
ఇక్కడ ఒక సాధారణ ఉదాహరణ. ఇది భారీ సంఖ్యలో URLలు. మీరు వాటిని తదుపరి పట్టికలో ఉంచండి. ఆపై వారు వారితో చేరాలని నిర్ణయించుకున్నారు, కానీ ఇది ఒక నియమం వలె పని చేయదు, ఎందుకంటే ClickHouse Hash JOINకి మాత్రమే మద్దతు ఇస్తుంది. కనెక్ట్ చేయవలసిన చాలా డేటాకు తగినంత RAM లేకపోతే, అప్పుడు JOIN పని చేయదు*.
డేటా అధిక కార్డినాలిటీని కలిగి ఉంటే, చింతించకండి, దానిని సాధారణీకరించిన రూపంలో నిల్వ చేయండి, URLలు నేరుగా ప్రధాన పట్టికలో ఉంటాయి.
* మరియు ఇప్పుడు క్లిక్‌హౌస్‌లో విలీనం చేరడం కూడా ఉంది మరియు ఇంటర్మీడియట్ డేటా RAMకి సరిపోని పరిస్థితుల్లో ఇది పని చేస్తుంది. కానీ ఇది అసమర్థమైనది మరియు సిఫార్సు అమలులో ఉంది.
మరికొన్ని ఉదాహరణలు, కానీ అవి వ్యతిరేక నమూనా కాదా అని నాకు ఇప్పటికే అనుమానం ఉంది.
ClickHouseకి తెలిసిన ఒక లోపం ఉంది. దీన్ని ఎలా అప్‌డేట్ చేయాలో తెలియదు*. కొన్ని మార్గాల్లో, ఇది కూడా మంచిది. మీకు కొన్ని ముఖ్యమైన డేటా ఉంటే, ఉదాహరణకు, అకౌంటింగ్, అప్పుడు ఎవరూ దానిని పంపలేరు, ఎందుకంటే నవీకరణలు లేవు.
* బ్యాచ్ మోడ్‌లో నవీకరణ మరియు తొలగింపు కోసం మద్దతు చాలా కాలం క్రితం జోడించబడింది.
కానీ నేపథ్యంలో ఉన్నట్లుగా నవీకరణలను అనుమతించే కొన్ని ప్రత్యేక మార్గాలు ఉన్నాయి. ఉదాహరణకు, ReplaceMergeTree వంటి పట్టికలు. వారు నేపథ్య విలీన సమయంలో నవీకరణలను చేస్తారు. ఆప్టిమైజ్ టేబుల్‌ని ఉపయోగించి మీరు దీన్ని బలవంతం చేయవచ్చు. కానీ దీన్ని చాలా తరచుగా చేయవద్దు, ఎందుకంటే ఇది విభజనను పూర్తిగా ఓవర్రైట్ చేస్తుంది.
ClickHouseలో పంపిణీ చేయబడిన JOINలు కూడా ప్రశ్న ప్లానర్ ద్వారా సరిగా నిర్వహించబడవు.
చెడ్డది, కానీ కొన్నిసార్లు సరే.
ఎంపిక*ని ఉపయోగించి డేటాను తిరిగి చదవడానికి క్లిక్‌హౌస్‌ని మాత్రమే ఉపయోగించడం.
గజిబిజిగా ఉండే లెక్కల కోసం క్లిక్‌హౌస్‌ని ఉపయోగించమని నేను సిఫార్సు చేయను. కానీ ఇది పూర్తిగా నిజం కాదు, ఎందుకంటే మేము ఇప్పటికే ఈ సిఫార్సు నుండి దూరంగా ఉన్నాము. మరియు మేము ఇటీవల క్లిక్‌హౌస్ - క్యాట్‌బూస్ట్‌లో మెషిన్ లెర్నింగ్ మోడల్‌లను వర్తింపజేసే సామర్థ్యాన్ని జోడించాము. మరియు ఇది నన్ను బాధపెడుతుంది ఎందుకంటే నేను ఇలా అనుకుంటున్నాను, “ఏం భయంకరమైనది. ఒక్కో బైట్‌కి ఇన్ని చక్రాలు ఇలా మారతాయి! బైట్‌లలో గడియారాలను వృధా చేయడాన్ని నేను నిజంగా ద్వేషిస్తున్నాను.
కానీ భయపడవద్దు, క్లిక్‌హౌస్‌ని ఇన్‌స్టాల్ చేయండి, ప్రతిదీ బాగానే ఉంటుంది. ఏదైనా ఉంటే, మాకు ఒక సంఘం ఉంది. మార్గం ద్వారా, సంఘం మీరు. మరియు మీకు ఏవైనా సమస్యలు ఉంటే, మీరు కనీసం మా చాట్‌కి వెళ్లవచ్చు మరియు వారు మీకు సహాయం చేస్తారని ఆశిస్తున్నాము.
మీ ప్రశ్నలు
నివేదికకు ధన్యవాదాలు! ClickHouse క్రాషింగ్ గురించి నేను ఎక్కడ ఫిర్యాదు చేయగలను?
మీరు ప్రస్తుతం నాకు వ్యక్తిగతంగా ఫిర్యాదు చేయవచ్చు.
నేను ఇటీవల క్లిక్‌హౌస్ ఉపయోగించడం ప్రారంభించాను. నేను వెంటనే cli ఇంటర్‌ఫేస్‌ని వదులుకున్నాను.
ఎంత స్కోర్.
కొద్దిసేపటి తర్వాత నేను చిన్న ఎంపికతో సర్వర్‌ను క్రాష్ చేసాను.
నీలో ప్రతిభ ఉంది.
నేను GitHub బగ్‌ని తెరిచాను, కానీ అది విస్మరించబడింది.
మనం చుద్దాం.
మీరు లోపల ఉన్న డేటాను ఎలా యాక్సెస్ చేస్తారో నాకు చెబుతానని వాగ్దానం చేస్తూ, నివేదికకు హాజరు కావడానికి అలెక్సీ నన్ను మోసగించాడు.
చాలా సింపుల్.
ఇది నేను నిన్న గ్రహించాను. మరిన్ని ప్రత్యేకతలు.
అక్కడ భయంకరమైన ఉపాయాలు లేవు. బ్లాక్-బై-బ్లాక్ కంప్రెషన్ మాత్రమే ఉంది. డిఫాల్ట్ LZ4, మీరు ZSTD*ని ప్రారంభించవచ్చు. 64 కిలోబైట్‌ల నుండి 1 మెగాబైట్ వరకు బ్లాక్‌లు.
* ఇతర అల్గారిథమ్‌లతో గొలుసులో ఉపయోగించగల ప్రత్యేక కంప్రెషన్ కోడెక్‌లకు కూడా మద్దతు ఉంది.
బ్లాక్‌లు కేవలం ముడి డేటా మాత్రమేనా?
పూర్తిగా ముడి కాదు. శ్రేణులు ఉన్నాయి. మీరు సంఖ్యా నిలువు వరుసను కలిగి ఉన్నట్లయితే, వరుసలోని సంఖ్యలు శ్రేణిలో ఉంచబడతాయి.
ప్రశాంతంగా.
అలెక్సీ, IPల కంటే యూనిక్‌ఎక్సాక్ట్‌తో ఉన్న ఒక ఉదాహరణ, అనగా సంఖ్యల కంటే పంక్తుల ద్వారా గణించడానికి uniqExact ఎక్కువ సమయం తీసుకుంటుంది మరియు మొదలైనవి. ప్రూఫ్ రీడింగ్ సమయంలో మనం చెవులతో ఫీంట్‌ని ఉపయోగిస్తే మరియు తారాగణం చేస్తే? అంటే, మా డిస్క్‌లో ఇది చాలా భిన్నంగా లేదని మీరు చెప్పినట్లు అనిపిస్తుంది. మేము డిస్క్ మరియు తారాగణం నుండి పంక్తులను చదివితే, మన కంకరలు వేగంగా ఉంటాయా లేదా? లేదా మేము ఇంకా ఇక్కడ కొంచెం లాభిస్తామా? మీరు దీన్ని పరీక్షించినట్లు నాకు అనిపిస్తోంది, కానీ కొన్ని కారణాల వల్ల బెంచ్‌మార్క్‌లో సూచించలేదు.
కాస్టింగ్ లేకుండా కంటే ఇది నెమ్మదిగా ఉంటుందని నేను భావిస్తున్నాను. ఈ సందర్భంలో, IP చిరునామా తప్పనిసరిగా స్ట్రింగ్ నుండి అన్వయించబడాలి. వాస్తవానికి, క్లిక్‌హౌస్‌లో, మా IP చిరునామా పార్సింగ్ కూడా ఆప్టిమైజ్ చేయబడింది. మేము చాలా కష్టపడి ప్రయత్నించాము, కానీ అక్కడ మీరు పదివేల రూపంలో వ్రాసిన సంఖ్యలను కలిగి ఉన్నారు. చాలా అసౌకర్యంగా ఉంది. మరోవైపు, uniqExact ఫంక్షన్ స్ట్రింగ్‌లపై నెమ్మదిగా పని చేస్తుంది, ఇవి స్ట్రింగ్‌లు అయినందున మాత్రమే కాకుండా, అల్గోరిథం యొక్క విభిన్న స్పెషలైజేషన్ ఎంచుకోబడినందున కూడా. స్ట్రింగ్స్ కేవలం విభిన్నంగా ప్రాసెస్ చేయబడతాయి.
మనం మరింత ప్రాచీనమైన డేటా రకాన్ని తీసుకుంటే? ఉదాహరణకు, మనం కలిగి ఉన్న యూజర్ ఐడిని వ్రాసి, దానిని లైన్‌గా వ్రాసి, ఆపై దానిని గిలకొట్టినప్పుడు, అది మరింత సరదాగా ఉంటుందా లేదా?
నాకు అనుమానం. ఇది మరింత విచారంగా ఉంటుందని నేను భావిస్తున్నాను, ఎందుకంటే అన్నింటికంటే, సంఖ్యలను అన్వయించడం తీవ్రమైన సమస్య. ఈ సహోద్యోగి పదివేల రూపంలో సంఖ్యలను అన్వయించడం ఎంత కష్టమో నివేదిక కూడా ఇచ్చినట్లు నాకు అనిపిస్తోంది, కానీ కాకపోవచ్చు.
అలెక్సీ, నివేదిక కోసం చాలా ధన్యవాదాలు! మరియు క్లిక్‌హౌస్‌కి చాలా ధన్యవాదాలు! ప్రణాళికల గురించి నాకు ఒక ప్రశ్న ఉంది. నిఘంటువులను అసంపూర్తిగా అప్‌డేట్ చేసే ఫీచర్ కోసం ఏమైనా ప్లాన్‌లు ఉన్నాయా?
అంటే, పాక్షిక రీబూట్?
అవును అవును. అక్కడ MySQL ఫీల్డ్‌ని సెట్ చేయగల సామర్థ్యం వలె, అనగా నిఘంటువు చాలా పెద్దది అయితే ఈ డేటా మాత్రమే లోడ్ అయ్యేలా అప్‌డేట్ చేయండి.
చాలా ఆసక్తికరమైన ఫీచర్. మరియు మా చాట్‌లో ఎవరో దీనిని సూచించారని నేను భావిస్తున్నాను. బహుశా అది నువ్వే కావచ్చు.
నేను అలా అనుకోవడం లేదు.
గ్రేట్, ఇప్పుడు రెండు అభ్యర్థనలు ఉన్నాయని తేలింది. మరియు మీరు నెమ్మదిగా చేయడం ప్రారంభించవచ్చు. కానీ ఈ ఫీచర్ అమలు చేయడం చాలా సులభం అని నేను వెంటనే మిమ్మల్ని హెచ్చరించాలనుకుంటున్నాను. అంటే, సిద్ధాంతపరంగా, మీరు పట్టికలో సంస్కరణ సంఖ్యను వ్రాసి, ఆపై వ్రాయాలి: అటువంటి మరియు అలాంటి వాటి కంటే తక్కువ సంస్కరణ. దీని అర్థం, చాలా మటుకు, మేము దీనిని ఔత్సాహికులకు అందిస్తాము. మీరు ఔత్సాహికులా?
అవును, కానీ, దురదృష్టవశాత్తు, C++లో కాదు.
మీ సహోద్యోగులకు C++లో ఎలా వ్రాయాలో తెలుసా?
నేను ఎవరినైనా కనుగొంటాను.
గొప్ప*.
* నివేదిక వచ్చిన రెండు నెలల తర్వాత ఫీచర్ జోడించబడింది - ప్రశ్న యొక్క రచయిత దానిని అభివృద్ధి చేసి పంపారు .
ధన్యవాదాలు!
హలో! నివేదికకు ధన్యవాదాలు! క్లిక్‌హౌస్ అందుబాటులో ఉన్న అన్ని వనరులను వినియోగించుకోవడంలో చాలా మంచిదని మీరు పేర్కొన్నారు. మరియు లక్సాఫ్ట్ పక్కన ఉన్న స్పీకర్ రష్యన్ పోస్ట్ కోసం తన పరిష్కారం గురించి మాట్లాడారు. వారు క్లిక్‌హౌస్‌ని నిజంగా ఇష్టపడతారని, అయితే వారు తమ ప్రధాన పోటీదారుకు బదులుగా దాన్ని ఉపయోగించలేదని, ఎందుకంటే ఇది మొత్తం CPUని తినేస్తున్నదని అతను చెప్పాడు. మరియు వారు దానిని తమ ఆర్కిటెక్చర్‌లోకి, డాకర్‌లతో వారి జూకీపర్‌లోకి ప్లగ్ చేయలేరు. క్లిక్‌హౌస్‌ని ఎలాగైనా పరిమితం చేయడం సాధ్యమేనా, తద్వారా అది అందుబాటులోకి వచ్చే ప్రతిదాన్ని వినియోగించదు?
అవును, ఇది సాధ్యమే మరియు చాలా సులభం. మీరు తక్కువ కోర్లను వినియోగించాలనుకుంటే, వ్రాయండి set max_threads = 1. అంతే, ఇది ఒక కోర్‌లో అభ్యర్థనను అమలు చేస్తుంది. అంతేకాకుండా, మీరు వేర్వేరు వినియోగదారుల కోసం వేర్వేరు సెట్టింగ్‌లను పేర్కొనవచ్చు. కాబట్టి సమస్య లేదు. మరియు లక్సోఫ్ట్ నుండి మీ సహోద్యోగులకు డాక్యుమెంటేషన్‌లో ఈ సెట్టింగ్ కనిపించకపోవడం మంచిది కాదని చెప్పండి.
అలెక్సీ, హలో! నేను ఈ ప్రశ్న గురించి అడగాలనుకుంటున్నాను. చాలా మంది వ్యక్తులు లాగ్‌ల కోసం క్లిక్‌హౌస్‌ని నిల్వగా ఉపయోగించడం ప్రారంభించారని నేను వినడం ఇదే మొదటిసారి కాదు. నివేదికలో మీరు దీన్ని చేయకూడదని చెప్పారు, అనగా మీరు పొడవైన తీగలను నిల్వ చేయవలసిన అవసరం లేదు. దాని గురించి మీరు ఏమనుకుంటున్నారు?
మొదట, లాగ్‌లు, ఒక నియమం వలె, పొడవైన తీగలు కాదు. వాస్తవానికి, మినహాయింపులు ఉన్నాయి. ఉదాహరణకు, జావాలో వ్రాసిన కొన్ని సేవ మినహాయింపును విసురుతుంది, అది లాగ్ చేయబడింది. మరియు అంతులేని లూప్‌లో, మరియు హార్డ్ డ్రైవ్‌లోని స్థలం అయిపోతుంది. పరిష్కారం చాలా సులభం. పంక్తులు చాలా పొడవుగా ఉంటే, వాటిని కత్తిరించండి. దీర్ఘకాలం అంటే ఏమిటి? పదుల కిలోబైట్లు చెడ్డవి*.
* ClickHouse యొక్క తాజా వెర్షన్‌లలో, “అడాప్టివ్ ఇండెక్స్ గ్రాన్యులారిటీ” ప్రారంభించబడింది, ఇది చాలా వరకు పొడవైన వరుసలను నిల్వ చేసే సమస్యను తొలగిస్తుంది.
కిలోబైట్ సాధారణమా?
ఫైన్.
హలో! నివేదికకు ధన్యవాదాలు! నేను ఇప్పటికే చాట్‌లో దీని గురించి అడిగాను, కానీ నాకు సమాధానం వచ్చిందో లేదో నాకు గుర్తు లేదు. CTE పద్ధతిలో విత్ విభాగాన్ని ఏదో ఒకవిధంగా విస్తరించే ప్రణాళికలు ఉన్నాయా?
ఇంకా లేదు. మా విత్ విభాగం కొంత పనికిమాలినది. ఇది మాకు చిన్న లక్షణం లాంటిది.
నాకు అర్థమైనది. ధన్యవాదాలు!
నివేదికకు ధన్యవాదాలు! చాలా ఆసక్తికరమైన! గ్లోబల్ ప్రశ్న. బహుశా కొన్ని రకాల స్టబ్‌ల రూపంలో డేటా తొలగింపును సవరించడానికి ఏమైనా ప్లాన్‌లు ఉన్నాయా?
తప్పనిసరిగా. మా క్యూలో ఇది మా మొదటి పని. ప్రతిదీ సరిగ్గా ఎలా చేయాలో మేము ఇప్పుడు చురుకుగా ఆలోచిస్తున్నాము. మరియు మీరు కీబోర్డ్ నొక్కడం ప్రారంభించాలి*.
* కీబోర్డ్‌లోని బటన్‌లను నొక్కి, ప్రతిదీ చేసింది.
ఇది సిస్టమ్ పనితీరును ప్రభావితం చేస్తుందా లేదా? చొప్పించడం ఇప్పుడు ఉన్నంత వేగంగా ఉంటుందా?
బహుశా వాటిని తొలగించడం మరియు నవీకరణలు చాలా భారీగా ఉంటాయి, కానీ ఇది ఎంపికల పనితీరు లేదా ఇన్‌సర్ట్‌ల పనితీరును ప్రభావితం చేయదు.
మరియు మరో చిన్న ప్రశ్న. ప్రదర్శనలో మీరు ప్రాథమిక కీ గురించి మాట్లాడారు. దీని ప్రకారం, మనకు విభజన ఉంది, ఇది డిఫాల్ట్‌గా నెలవారీ, సరియైనదా? మరియు మేము ఒక నెలకు సరిపోయే తేదీ పరిధిని సెట్ చేసినప్పుడు, ఈ విభజన మాత్రమే చదవబడుతుంది, సరియైనదా?
అవును.
ఒక ప్రశ్న. మేము ఏదైనా ప్రాథమిక కీని ఎంచుకోలేకపోతే, "తేదీ" ఫీల్డ్ ప్రకారం దీన్ని ప్రత్యేకంగా చేయడం సరైనదేనా, తద్వారా నేపథ్యంలో ఈ డేటా యొక్క తక్కువ పునర్వ్యవస్థీకరణ ఉంటుంది, తద్వారా ఇది మరింత క్రమ పద్ధతిలో సరిపోతుంది? మీకు శ్రేణి ప్రశ్నలు లేకుంటే మరియు మీరు ఏ ప్రాథమిక కీని కూడా ఎంచుకోలేకపోతే, ప్రాథమిక కీలో తేదీని ఉంచడం విలువైనదేనా?
అవును.
ఈ ఫీల్డ్ ద్వారా క్రమబద్ధీకరించబడినట్లయితే డేటాను మెరుగ్గా కుదించే ఫీల్డ్‌ను ప్రాథమిక కీలో ఉంచడం అర్ధమే కావచ్చు. ఉదాహరణకు, వినియోగదారు ID. వినియోగదారు, ఉదాహరణకు, అదే సైట్‌కు వెళతారు. ఈ సందర్భంలో, వినియోగదారు ఐడి మరియు సమయాన్ని ఉంచండి. ఆపై మీ డేటా మెరుగ్గా కుదించబడుతుంది. తేదీ విషయానికొస్తే, మీకు నిజంగా తేదీలలో శ్రేణి ప్రశ్నలు లేకుంటే మరియు ఎప్పుడూ లేనట్లయితే, మీరు తేదీని ప్రాథమిక కీలో ఉంచాల్సిన అవసరం లేదు.
సరే చాలా ధన్యవాదాలు!
మూలం: www.habr.com