ClickHouse இன் பயனுள்ள பயன்பாடு. அலெக்ஸி மிலோவிடோவ் (யாண்டெக்ஸ்)

ClickHouse ஒரு சிறப்பு அமைப்பு என்பதால், அதைப் பயன்படுத்தும் போது அதன் கட்டமைப்பின் அம்சங்களை கணக்கில் எடுத்துக்கொள்வது முக்கியம். இந்த அறிக்கையில், கிளிக்ஹவுஸைப் பயன்படுத்தும் போது பொதுவான தவறுகளின் எடுத்துக்காட்டுகளைப் பற்றி அலெக்ஸி பேசுவார், இது பயனற்ற வேலைக்கு வழிவகுக்கும். நடைமுறை எடுத்துக்காட்டுகள், ஒன்று அல்லது மற்றொரு தரவு செயலாக்கத் திட்டத்தைத் தேர்ந்தெடுப்பது, அளவை ஒழுங்குபடுத்துவதன் மூலம் செயல்திறனை எவ்வாறு மாற்றும் என்பதைக் காண்பிக்கும்.

அனைவருக்கும் வணக்கம்! எனது பெயர் அலெக்ஸி, நான் கிளிக்ஹவுஸ் செய்கிறேன்.

முதலாவதாக, நான் இப்போதே உங்களைப் பிரியப்படுத்த விரைகிறேன், இன்று நான் கிளிக்ஹவுஸ் என்றால் என்னவென்று சொல்ல மாட்டேன். உண்மையைச் சொல்வதானால், நான் அதில் சோர்வாக இருக்கிறேன். ஒவ்வொரு முறையும் அது என்னவென்று சொல்கிறேன். மற்றும் அநேகமாக அனைவருக்கும் ஏற்கனவே தெரியும்.

அதற்கு பதிலாக, சாத்தியமான தவறுகள் என்ன என்பதை நான் உங்களுக்கு சொல்கிறேன், அதாவது கிளிக்ஹவுஸை நீங்கள் எவ்வாறு தவறாகப் பயன்படுத்தலாம். உண்மையில், பயப்படத் தேவையில்லை, ஏனென்றால் நாங்கள் கிளிக்ஹவுஸை எளிமையான, வசதியான மற்றும் பெட்டிக்கு வெளியே செயல்படும் அமைப்பாக உருவாக்குகிறோம். நான் அதை நிறுவினேன், எந்த பிரச்சனையும் இல்லை.

ஆனால் இந்த அமைப்பு சிறப்பு வாய்ந்தது என்பதை நீங்கள் இன்னும் கணக்கில் எடுத்துக்கொள்ள வேண்டும், மேலும் இந்த அமைப்பை அதன் ஆறுதல் மண்டலத்திலிருந்து வெளியேற்றும் அசாதாரண பயன்பாட்டு வழக்கை நீங்கள் எளிதாகக் காணலாம்.

எனவே, என்ன வகையான ரேக் உள்ளது? பெரும்பாலும் நான் வெளிப்படையான விஷயங்களைப் பற்றி பேசுவேன். எல்லாமே அனைவருக்கும் தெளிவாகத் தெரியும், எல்லோரும் எல்லாவற்றையும் புரிந்துகொள்கிறார்கள், அவர்கள் மிகவும் புத்திசாலி என்று மகிழ்ச்சியடையலாம், மேலும் புரியாதவர்கள் புதிதாக ஒன்றைக் கற்றுக்கொள்வார்கள்.

முதல் மற்றும் எளிமையான உதாரணம், துரதிர்ஷ்டவசமாக, அடிக்கடி நிகழ்கிறது, சிறிய தொகுதிகளுடன் கூடிய அதிக எண்ணிக்கையிலான செருகல்கள், அதாவது அதிக எண்ணிக்கையிலான சிறிய செருகல்கள்.

கிளிக்ஹவுஸ் எவ்வாறு செருகலைச் செய்கிறது என்பதைக் கருத்தில் கொண்டால், ஒரு கோரிக்கையில் குறைந்தபட்சம் ஒரு டெராபைட் தரவை அனுப்பலாம். அது ஒரு பிரச்சனை இல்லை.

மேலும் வழக்கமான செயல்திறன் என்னவாக இருக்கும் என்று பார்ப்போம். எடுத்துக்காட்டாக, Yandex.Metrica தரவிலிருந்து ஒரு அட்டவணை உள்ளது. ஹிட்ஸ். 105 சில நெடுவரிசைகள். 700 பைட்டுகள் சுருக்கப்படவில்லை. மேலும் ஒரு மில்லியன் வரிசைகள் கொண்ட தொகுதிகளில் நல்ல முறையில் செருகுவோம்.

நாங்கள் MergeTree ஐ அட்டவணையில் செருகுகிறோம், அது வினாடிக்கு அரை மில்லியன் வரிசைகளை மாற்றுகிறது. நன்று. பிரதி அட்டவணையில் அது சற்று சிறியதாக இருக்கும், வினாடிக்கு சுமார் 400 வரிசைகள்.

நீங்கள் கோரம் செருகலை இயக்கினால், நீங்கள் சிறிது குறைவாக, ஆனால் இன்னும் ஒழுக்கமான செயல்திறன், வினாடிக்கு 250 விதிமுறைகளைப் பெறுவீர்கள். கோரம் செருகல் என்பது ClickHouse* இல் ஆவணப்படுத்தப்படாத அம்சமாகும்.

* 2020 வரை, ஏற்கனவே ஆவணப்படுத்தப்பட்டுள்ளது.

கெட்டதைச் செய்தால் என்ன நடக்கும்? MergeTree அட்டவணையில் ஒரு வரிசையைச் செருகி, வினாடிக்கு 59 வரிசைகளைப் பெறுகிறோம். அது 10 மடங்கு மெதுவாக. ReplicatedMergeTree இல் - வினாடிக்கு 000 வரிசைகள். கோரம் இயக்கப்பட்டால், அது ஒரு வினாடிக்கு 6 வரிகளாக மாறும். என் கருத்துப்படி, இது ஒருவித முழுமையான முட்டாள்தனம். எப்படி இப்படி வேகத்தைக் குறைக்க முடியும்? கிளிக்ஹவுஸ் வேகத்தைக் குறைக்கக் கூடாது என்று என் டி-ஷர்ட்டில் எழுதியிருக்கிறேன். இருப்பினும், சில நேரங்களில் அது நடக்கும்.

உண்மையில் இதுவே நமது குறைபாடு. நாம் எளிதாக எல்லாவற்றையும் சரியாகச் செய்திருக்கலாம், ஆனால் நாங்கள் செய்யவில்லை. எங்கள் ஸ்கிரிப்ட் தேவையில்லை என்பதால் நாங்கள் அதை செய்யவில்லை. எங்களிடம் ஏற்கனவே இறைச்சிக் கூடங்கள் இருந்தன. எங்கள் நுழைவாயிலில் நாங்கள் தொகுதிகளைப் பெற்றோம், எந்த பிரச்சனையும் இல்லை. நாங்கள் அதைச் செருகுவோம், எல்லாம் நன்றாக வேலை செய்கிறது. ஆனால், நிச்சயமாக, எல்லா வகையான காட்சிகளும் சாத்தியமாகும். எடுத்துக்காட்டாக, தரவு உருவாக்கப்படும் சேவையகங்கள் உங்களிடம் இருக்கும்போது. மேலும் அவை அடிக்கடி தரவைச் செருகுவதில்லை, ஆனால் அவை அடிக்கடி செருகல்களுடன் முடிவடைகின்றன. மேலும் இதை எப்படியாவது தவிர்க்க வேண்டும்.

தொழில்நுட்பக் கண்ணோட்டத்தில், நீங்கள் கிளிக்ஹவுஸில் செருகும்போது, ​​​​தரவு எந்த நினைவூட்டலிலும் முடிவடையாது. எங்களிடம் உண்மையான பதிவு அமைப்பு MergeTree இல்லை, ஆனால் ஒரு MergeTree மட்டுமே உள்ளது, ஏனெனில் பதிவு அல்லது memTable எதுவும் இல்லை. ஏற்கனவே நெடுவரிசைகளில் அமைக்கப்பட்ட கோப்பு முறைமையில் தரவை உடனடியாக எழுதுகிறோம். உங்களிடம் 100 நெடுவரிசைகள் இருந்தால், 200 க்கும் மேற்பட்ட கோப்புகளை தனி கோப்பகத்தில் எழுத வேண்டும். இதெல்லாம் மிகவும் சிரமமானது.

கேள்வி எழுகிறது: "அதை எப்படிச் செய்வது?" நீங்கள் இன்னும் எப்படியாவது தரவை கிளிக்ஹவுஸில் பதிவு செய்ய வேண்டும்.

முறை 1. இது எளிதான வழி. சில வகையான விநியோகிக்கப்பட்ட வரிசையைப் பயன்படுத்தவும். உதாரணமாக, காஃப்கா. நீங்கள் காஃப்காவிலிருந்து தரவைப் பிரித்தெடுத்து, ஒரு நொடிக்கு ஒருமுறை அதைத் தொகுக்கலாம். எல்லாம் சரியாகிவிடும், நீங்கள் பதிவு செய்கிறீர்கள், எல்லாம் நன்றாக வேலை செய்கிறது.

குறைபாடுகள் என்னவென்றால், காஃப்கா மற்றொரு பருமனான விநியோக அமைப்பு ஆகும். உங்கள் நிறுவனத்தில் ஏற்கனவே காஃப்கா இருக்கிறதா என்பதையும் நான் புரிந்துகொள்கிறேன். இது நல்லது, வசதியானது. ஆனால் அது இல்லை என்றால், உங்கள் திட்டத்தில் மற்றொரு விநியோகிக்கப்பட்ட அமைப்பை இழுப்பதற்கு முன் நீங்கள் மூன்று முறை சிந்திக்க வேண்டும். எனவே மாற்று வழிகளைக் கருத்தில் கொள்வது மதிப்பு.

முறை 2. இது ஒரு பழைய பள்ளி மாற்று மற்றும் அதே நேரத்தில் மிகவும் எளிமையானது. உங்கள் பதிவுகளை உருவாக்கும் சில வகையான சர்வர் உங்களிடம் உள்ளதா. அது உங்கள் பதிவுகளை ஒரு கோப்பில் எழுதுகிறது. ஒரு வினாடிக்கு ஒரு முறை, எடுத்துக்காட்டாக, இந்த கோப்பை மறுபெயரிட்டு புதியதைக் கிழிக்கிறோம். ஒரு தனி ஸ்கிரிப்ட், கிரான் அல்லது சில டீமான் வழியாக, பழமையான கோப்பை எடுத்து கிளிக்ஹவுஸில் எழுதுகிறது. வினாடிக்கு ஒரு முறை பதிவுகளை பதிவு செய்தால் எல்லாம் சரியாகிவிடும்.

ஆனால் இந்த முறையின் தீமை என்னவென்றால், பதிவுகள் உருவாக்கப்பட்ட உங்கள் சேவையகம் எங்காவது மறைந்துவிட்டால், தரவுகளும் மறைந்துவிடும்.

முறை 3. மற்றொரு சுவாரஸ்யமான முறை உள்ளது, இது தற்காலிக கோப்புகள் தேவையில்லை. எடுத்துக்காட்டாக, உங்களிடம் சில வகையான விளம்பர ஸ்பின்னர் அல்லது தரவை உருவாக்கும் வேறு சில சுவாரஸ்யமான டீமான் உள்ளது. நீங்கள் நேரடியாக ரேமில், பஃபரில் ஒரு கொத்து தரவைக் குவிக்கலாம். போதுமான நேரம் கடந்துவிட்டால், இந்த இடையகத்தை ஒதுக்கி வைத்துவிட்டு, புதிய ஒன்றை உருவாக்கி, தனி நூலில், கிளிக்ஹவுஸில் ஏற்கனவே குவிந்துள்ளதைச் செருகவும்.

மறுபுறம், கொலை -9 உடன் தரவு மறைந்துவிடும். உங்கள் சர்வர் செயலிழந்தால், இந்தத் தரவை இழப்பீர்கள். மற்றொரு சிக்கல் என்னவென்றால், நீங்கள் தரவுத்தளத்தில் எழுத முடியவில்லை என்றால், உங்கள் தரவு RAM இல் குவிந்துவிடும். மேலும் ரேம் தீர்ந்துவிடும் அல்லது தரவை இழப்பீர்கள்.

முறை 4. மற்றொரு சுவாரஸ்யமான முறை. உங்களிடம் சில வகையான சர்வர் செயல்முறை உள்ளதா. அது உடனடியாக ClickHouse க்கு தரவை அனுப்பலாம், ஆனால் அதை ஒரு இணைப்பில் செய்யலாம். எடுத்துக்காட்டாக, பரிமாற்ற-குறியாக்கத்துடன் http கோரிக்கையை அனுப்பினேன்: செருகலுடன் துண்டிக்கப்பட்டது. மேலும் இது மிகவும் அரிதாக துகள்களை உருவாக்குகிறது, நீங்கள் ஒவ்வொரு வரியையும் அனுப்பலாம், இருப்பினும் இந்தத் தரவை வடிவமைக்க மேல்நிலை இருக்கும்.

இருப்பினும், இந்த வழக்கில் தரவு உடனடியாக ClickHouse க்கு அனுப்பப்படும். மேலும் ClickHouse அவற்றையே தாங்கும்.

ஆனால் பிரச்சனைகளும் எழுகின்றன. உங்கள் செயல்முறை எப்போது அழிக்கப்பட்டது மற்றும் கிளிக்ஹவுஸ் செயல்முறை அழிக்கப்பட்டால், அது முழுமையற்ற செருகலாக இருக்கும் என்பதால், இப்போது நீங்கள் தரவை இழப்பீர்கள். மேலும் கிளிக்ஹவுஸில் உள்ள செருகல்கள் வரிசைகளின் அளவில் குறிப்பிட்ட குறிப்பிட்ட வாசல் வரை அணுவாக இருக்கும். கொள்கையளவில், இது ஒரு சுவாரஸ்யமான வழி. பயன்படுத்தவும் முடியும்.

முறை 5. இங்கே மற்றொரு சுவாரஸ்யமான முறை உள்ளது. இது தரவுத் தொகுப்பிற்கான சமூகத்தால் உருவாக்கப்பட்ட ஒரு வகையான சேவையகம். நான் அதை நானே பார்க்கவில்லை, அதனால் என்னால் எதற்கும் உத்தரவாதம் அளிக்க முடியாது. இருப்பினும், ClickHouse க்கு எந்த உத்தரவாதமும் வழங்கப்படவில்லை. இதுவும் திறந்த மூலமாகும், ஆனால் மறுபுறம், நாங்கள் வழங்க முயற்சிக்கும் சில தரநிலைகளுக்கு நீங்கள் பயன்படுத்தப்படலாம். ஆனால் இந்த விஷயத்திற்கு - எனக்குத் தெரியாது, GitHub க்குச் சென்று, குறியீட்டைப் பாருங்கள். அவர்கள் ஏதோ சாதாரணமாக எழுதியிருக்கலாம்.

* 2020 இல், கருத்தில் சேர்க்கப்பட வேண்டும் கிட்டன்ஹவுஸ்.

முறை 6. மற்றொரு முறை இடையக அட்டவணைகளைப் பயன்படுத்துவது. இந்த முறையின் நன்மை என்னவென்றால், அதைப் பயன்படுத்தத் தொடங்குவது மிகவும் எளிதானது. ஒரு இடையக அட்டவணையை உருவாக்கி அதில் செருகவும்.

குறைபாடு என்னவென்றால், பிரச்சனை முழுமையாக தீர்க்கப்படவில்லை. MergeTree போன்ற விகிதத்தில், நீங்கள் ஒரு வினாடிக்கு ஒரு தொகுதி என்ற அளவில் தரவைக் குழுவாக்க வேண்டும் என்றால், ஒரு இடையக அட்டவணையில் ஒரு விகிதத்தில், நீங்கள் வினாடிக்கு குறைந்தது பல ஆயிரம் வரை குழுவாக வேண்டும். வினாடிக்கு 10 க்கு மேல் இருந்தால், அது இன்னும் மோசமாக இருக்கும். நீங்கள் அதை தொகுதிகளாகச் செருகினால், அது வினாடிக்கு ஒரு லட்சம் வரிகளாக மாறுவதைப் பார்த்தீர்கள். இது ஏற்கனவே மிகவும் கனமான தரவுகளில் உள்ளது.

மேலும் இடையக அட்டவணையில் பதிவு இல்லை. உங்கள் சர்வரில் ஏதேனும் தவறு இருந்தால், தரவு இழக்கப்படும்.

மேலும் போனஸாக, காஃப்காவிடமிருந்து தரவை மீட்டெடுக்க கிளிக்ஹவுஸில் எங்களுக்கு சமீபத்தில் வாய்ப்பு கிடைத்தது. ஒரு டேபிள் எஞ்சின் உள்ளது - காஃப்கா. நீங்கள் வெறுமனே உருவாக்குங்கள். மேலும் நீங்கள் அதில் பொருள்படுத்தப்பட்ட பிரதிநிதித்துவங்களைத் தொங்கவிடலாம். இந்த வழக்கில், அது காஃப்காவிலிருந்து தரவைப் பிரித்தெடுத்து உங்களுக்குத் தேவையான அட்டவணையில் செருகும்.

இந்த வாய்ப்பைப் பற்றி குறிப்பாக மகிழ்ச்சியடைவது என்னவென்றால், அதைச் செய்தது நாங்கள் அல்ல. இது ஒரு சமூக அம்சம். "சமூக அம்சம்" என்று நான் கூறும்போது, ​​எந்த அவமதிப்பும் இல்லாமல் அதைக் குறிப்பிடுகிறேன். நாங்கள் குறியீட்டைப் படித்தோம், மதிப்பாய்வு செய்தோம், அது நன்றாக வேலை செய்ய வேண்டும்.

* 2020 வரை, இதே போன்ற ஆதரவு தோன்றியது முயல்MQ.

தரவைச் செருகும்போது வேறு என்ன சிரமமாக அல்லது எதிர்பாராததாக இருக்க முடியும்? நீங்கள் மதிப்புகளைச் செருகவும், சில கணக்கிடப்பட்ட வெளிப்பாடுகளை மதிப்புகளில் எழுதவும். எடுத்துக்காட்டாக, now() என்பது கணக்கிடப்பட்ட வெளிப்பாடு ஆகும். இந்த வழக்கில், கிளிக்ஹவுஸ் ஒவ்வொரு வரியிலும் இந்த வெளிப்பாடுகளின் மொழிபெயர்ப்பாளரைத் தொடங்க வேண்டிய கட்டாயத்தில் உள்ளது, மேலும் செயல்திறன் அளவு ஆர்டர்களால் குறையும். இதை தவிர்ப்பது நல்லது.

* தற்போது, ​​சிக்கல் முற்றிலும் தீர்க்கப்பட்டது, VALUES இல் வெளிப்பாடுகளைப் பயன்படுத்தும் போது எந்த செயல்திறன் பின்னடைவும் இருக்காது.

மற்றொரு உதாரணம், பகிர்வுகளின் கூட்டத்திற்கு சொந்தமான ஒரு தொகுப்பில் தரவு இருக்கும்போது சில சிக்கல்கள் இருக்கலாம். இயல்பாக, கிளிக்ஹவுஸ் பகிர்வுகள் மாதத்தின் அடிப்படையில் இருக்கும். நீங்கள் ஒரு மில்லியன் வரிசைகளின் தொகுப்பைச் செருகினால், பல ஆண்டுகளாக தரவு இருந்தால், உங்களிடம் பல டஜன் பகிர்வுகள் இருக்கும். பல பத்து மடங்கு சிறிய தொகுதிகள் இருக்கும் என்பதற்கு இது சமம், ஏனென்றால் உள்ளே அவை எப்போதும் முதலில் பகிர்வுகளாக பிரிக்கப்படுகின்றன.

* சமீபத்தில், கிளிக்ஹவுஸ், ரேமில் உள்ள துகள்கள் மற்றும் துகள்களின் சுருக்கமான வடிவமைப்பிற்கான ஆதரவைச் சேர்த்தது.

இப்போது இரண்டாவது வகை சிக்கலைப் பார்ப்போம் - தரவு தட்டச்சு.

தரவு தட்டச்சு கண்டிப்பாக அல்லது சரமாக இருக்கலாம். சரம் என்பது நீங்கள் அதை எடுத்து உங்கள் புலங்கள் அனைத்தும் சரம் வகை என்று அறிவித்தது. இது அசிங்கமானது. இதைச் செய்ய வேண்டிய அவசியம் இல்லை.

எங்களிடம் சில புலம், ஒரு சரம் உள்ளது என்று நீங்கள் கூற விரும்பும் போது, ​​​​அதை எவ்வாறு சரியாகச் செய்வது என்பதைக் கண்டுபிடிப்போம், மேலும் கிளிக்ஹவுஸ் அதைத் தானாகவே கண்டுபிடிக்கட்டும், நான் கவலைப்பட மாட்டேன். ஆனால் இன்னும் கொஞ்சம் முயற்சி செய்வது மதிப்பு.

உதாரணமாக, எங்களிடம் ஒரு ஐபி முகவரி உள்ளது. ஒரு சந்தர்ப்பத்தில், அதை ஒரு சரமாக சேமித்தோம். உதாரணமாக, 192.168.1.1. மற்றொரு வழக்கில், இது UInt32* வகையாக இருக்கும். IPv32 முகவரிக்கு 4 பிட்கள் போதுமானது.

முதலில், விந்தை போதும், தரவு தோராயமாக சமமாக சுருக்கப்படும். நிச்சயமாக ஒரு வித்தியாசம் இருக்கும், ஆனால் பெரியதாக இல்லை. எனவே வட்டு I/O இல் சிறப்பு சிக்கல்கள் எதுவும் இல்லை.

ஆனால் செயலி நேரம் மற்றும் வினவல் செயல்படுத்தும் நேரம் ஆகியவற்றில் கடுமையான வேறுபாடு உள்ளது.

தனிப்பட்ட ஐபி முகவரிகள் எண்களாக சேமிக்கப்பட்டால் அவற்றின் எண்ணிக்கையை எண்ணுவோம். இது ஒரு வினாடிக்கு 137 மில்லியன் கோடுகள் ஆகும். இது சரங்களின் வடிவத்தில் இருந்தால், வினாடிக்கு 37 மில்லியன் கோடுகள். இந்த தற்செயல் நிகழ்வு ஏன் என்று எனக்குத் தெரியவில்லை. இந்த கோரிக்கைகளை நானே நிறைவேற்றினேன். ஆனால் இன்னும் 4 மடங்கு மெதுவாக.

வட்டு இடத்தில் உள்ள வேறுபாட்டை நீங்கள் கணக்கிட்டால், ஒரு வித்தியாசமும் உள்ளது. வித்தியாசம் சுமார் கால் பகுதி, ஏனென்றால் நிறைய தனித்துவமான ஐபி முகவரிகள் உள்ளன. சிறிய எண்ணிக்கையிலான வெவ்வேறு அர்த்தங்களைக் கொண்ட கோடுகள் இருந்தால், அவை அகராதியின் படி தோராயமாக அதே தொகுதியில் எளிதாக சுருக்கப்படும்.

மற்றும் நான்கு மடங்கு நேர வேறுபாடு சாலையில் இல்லை. ஒருவேளை நீங்கள் ஒரு பிடி கொடுக்க மாட்டீர்கள், நிச்சயமாக, ஆனால் நான் அத்தகைய வித்தியாசத்தை பார்க்கும்போது, ​​அது எனக்கு வருத்தமாக இருக்கிறது.

வெவ்வேறு வழக்குகளைப் பார்ப்போம்.

1. உங்களிடம் சில வேறுபட்ட தனிப்பட்ட மதிப்புகள் இருக்கும்போது ஒரு வழக்கு. இந்த விஷயத்தில், உங்களுக்குத் தெரிந்த மற்றும் எந்த DBMS க்கும் பயன்படுத்தக்கூடிய எளிய நடைமுறையை நாங்கள் பயன்படுத்துகிறோம். இவை அனைத்தும் கிளிக்ஹவுஸுக்கு மட்டுமல்ல. தரவுத்தளத்தில் எண் அடையாளங்காட்டிகளை எழுதவும். நீங்கள் சரங்களாக மாற்றலாம் மற்றும் உங்கள் பயன்பாட்டின் பக்கத்தில் திரும்பலாம்.

உதாரணமாக, உங்களிடம் ஒரு பகுதி உள்ளது. நீங்கள் அதை ஒரு சரமாக சேமிக்க முயற்சிக்கிறீர்கள். அது அங்கு எழுதப்படும்: மாஸ்கோ மற்றும் மாஸ்கோ பிராந்தியம். அது "மாஸ்கோ" என்று கூறுவதை நான் பார்க்கும்போது, ​​அது ஒன்றும் இல்லை, ஆனால் அது மாஸ்கோவாக இருக்கும்போது, ​​அது எப்படியோ முற்றிலும் சோகமாகிறது. அவ்வளவுதான் பைட்டுகள்.

அதற்கு பதிலாக, Ulnt32 மற்றும் 250 என்ற எண்ணை எழுதுகிறோம். Yandex இல் 250 உள்ளது, ஆனால் உங்களுடையது வேறுபட்டிருக்கலாம். ஒரு வேளை, ஜியோபேஸுடன் பணிபுரியும் ஒரு உள்ளமைக்கப்பட்ட திறனை ClickHouse கொண்டுள்ளது என்று நான் கூறுவேன். நீங்கள் ஒரு படிநிலை உட்பட பகுதிகளுடன் ஒரு கோப்பகத்தை எழுதுங்கள், அதாவது மாஸ்கோ, மாஸ்கோ பிராந்தியம் மற்றும் உங்களுக்கு தேவையான அனைத்தும் இருக்கும். நீங்கள் கோரிக்கை மட்டத்தில் மாற்றலாம்.

இரண்டாவது விருப்பம் தோராயமாக அதே தான், ஆனால் கிளிக்ஹவுஸ் உள்ளே ஆதரவுடன். இது Enum தரவு வகை. Enum இல் உங்களுக்கு தேவையான அனைத்து மதிப்புகளையும் எழுதுங்கள். எடுத்துக்காட்டாக, சாதனத்தின் வகை மற்றும் அங்கு எழுதவும்: டெஸ்க்டாப், மொபைல், டேப்லெட், டிவி. மொத்தம் 4 விருப்பங்கள் உள்ளன.

குறைபாடு என்னவென்றால், நீங்கள் அதை அவ்வப்போது மாற்ற வேண்டும். ஒரே ஒரு விருப்பம் சேர்க்கப்பட்டது. அட்டவணையை மாற்றுவோம். உண்மையில், கிளிக்ஹவுஸில் மாற்று அட்டவணை இலவசம். குறிப்பாக Enum க்கு இலவசம் ஏனெனில் வட்டில் உள்ள தரவு மாறாது. ஆயினும்கூட, ஆல்டர் மேசையில் ஒரு பூட்டை* பெறுகிறது மற்றும் அனைத்து தேர்வுகளும் செயல்படுத்தப்படும் வரை காத்திருக்க வேண்டும். இந்த மாற்றத்திற்குப் பிறகுதான் செயல்படுத்தப்படும், அதாவது இன்னும் சில சிரமங்கள் உள்ளன.

* ClickHouse இன் சமீபத்திய பதிப்புகளில், ALTER முற்றிலும் தடுக்கப்படாமல் செய்யப்படுகிறது.

கிளிக்ஹவுஸுக்கு மிகவும் தனித்துவமான மற்றொரு விருப்பம் வெளிப்புற அகராதிகளை இணைப்பதாகும். நீங்கள் ClickHouse இல் எண்களை எழுதலாம் மற்றும் உங்களுக்கு வசதியான எந்த அமைப்பிலும் உங்கள் கோப்பகங்களை வைத்திருக்கலாம். உதாரணமாக, நீங்கள் பயன்படுத்தலாம்: MySQL, Mongo, Postgres. http வழியாக இந்தத் தரவை அனுப்பும் உங்கள் சொந்த மைக்ரோ சர்வீஸை நீங்கள் உருவாக்கலாம். கிளிக்ஹவுஸ் மட்டத்தில், இந்தத் தரவை எண்களிலிருந்து சரங்களாக மாற்றும் செயல்பாட்டை நீங்கள் எழுதுகிறீர்கள்.

வெளிப்புற அட்டவணையில் ஒரு சேருவதற்கு இது ஒரு சிறப்பு ஆனால் மிகவும் திறமையான வழியாகும். மற்றும் இரண்டு விருப்பங்கள் உள்ளன. ஒரு வடிவத்தில், இந்தத் தரவு முற்றிலும் தற்காலிகமாக சேமிக்கப்படும், RAM இல் முழுமையாக இருக்கும் மற்றும் சில அதிர்வெண்களுடன் புதுப்பிக்கப்படும். மற்றொரு விருப்பத்தில், இந்தத் தரவு RAM இல் பொருந்தவில்லை என்றால், நீங்கள் அதை ஓரளவு தற்காலிகமாக சேமிக்கலாம்.

இதோ ஒரு உதாரணம். Yandex.Direct உள்ளது. மேலும் ஒரு விளம்பர நிறுவனம் மற்றும் பேனர்கள் உள்ளன. சுமார் பத்து மில்லியன் விளம்பர நிறுவனங்கள் இருக்கலாம். மேலும் அவை தோராயமாக ரேமில் பொருந்துகின்றன. மேலும் பில்லியன் கணக்கான பேனர்கள் உள்ளன, அவை பொருந்தவில்லை. மேலும் MySQL இலிருந்து தற்காலிகச் சேமிப்பு அகராதியைப் பயன்படுத்துகிறோம்.

ஒரே பிரச்சனை என்னவென்றால், வெற்றி விகிதம் 100% க்கு அருகில் இருந்தால், தற்காலிக சேமிப்பு அகராதி நன்றாக வேலை செய்யும். இது சிறியதாக இருந்தால், ஒவ்வொரு தொகுதி தரவுகளுக்கும் வினவல்களைச் செயலாக்கும்போது, ​​நீங்கள் உண்மையில் விடுபட்ட விசைகளை எடுத்து MySQL இலிருந்து தரவைப் பெற வேண்டும். ClickHouse பற்றி, நான் இன்னும் உத்தரவாதம் அளிக்க முடியும் - ஆம், அது மெதுவாக இல்லை, மற்ற அமைப்புகளைப் பற்றி நான் பேசமாட்டேன்.

மேலும் போனஸாக, 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 முகவரி தேவைப்பட்டால், அதை ஒரு தனி நெடுவரிசையில் வைப்பது நல்லது.

* கிளிக்ஹவுஸில் இப்போது தனித்தனி IPv4, IPv6 தரவு வகைகள் உள்ளன, அவை தரவை எண்களைப் போலவே திறமையாகச் சேமிக்கின்றன, ஆனால் அவை சரங்களைப் போல வசதியாகப் பிரதிபலிக்கின்றன.

தரவை முன்கூட்டியே செயலாக்குவது மதிப்புக்குரியது என்பதையும் கவனத்தில் கொள்ள வேண்டும். உதாரணமாக, நீங்கள் சில மூலப் பதிவுகளைப் பெறுவீர்கள். ஒன்றும் செய்யாமல் இருப்பது மிகவும் கவர்ச்சியாக இருந்தாலும், எல்லாம் வேலை செய்யும் என்றாலும், நீங்கள் அவற்றை இப்போதே கிளிக்ஹவுஸில் வைக்கக்கூடாது. ஆனால் சாத்தியமான கணக்கீடுகளைச் செய்வது இன்னும் மதிப்புக்குரியது.

உதாரணமாக, உலாவி பதிப்பு. நான் விரல் காட்ட விரும்பாத அருகிலுள்ள சில துறைகளில், உலாவி பதிப்பு இவ்வாறு சேமிக்கப்படுகிறது, அதாவது சரமாக: 12.3. பின்னர், ஒரு அறிக்கையை உருவாக்க, அவர்கள் இந்த சரத்தை எடுத்து அதை ஒரு வரிசையாகவும், பின்னர் வரிசையின் முதல் உறுப்புகளாகவும் பிரிக்கிறார்கள். இயற்கையாகவே, எல்லாம் குறைகிறது. ஏன் இப்படி செய்கிறார்கள் என்று கேட்டேன். அவர்கள் முன்கூட்டிய தேர்வுமுறையை விரும்புவதில்லை என்று என்னிடம் சொன்னார்கள். மேலும் நான் முன்கூட்டிய அவநம்பிக்கையை விரும்பவில்லை.

எனவே இந்த விஷயத்தில் 4 நெடுவரிசைகளாகப் பிரிப்பது மிகவும் சரியாக இருக்கும். இங்கே பயப்பட வேண்டாம், ஏனென்றால் இது கிளிக்ஹவுஸ். ClickHouse என்பது ஒரு நெடுவரிசை தரவுத்தளமாகும். மேலும் நேர்த்தியான சிறிய நெடுவரிசைகள், சிறந்தது. 5 உலாவி பதிப்புகள் இருக்கும், 5 நெடுவரிசைகளை உருவாக்கவும். இது நன்று.

இப்போது உங்களிடம் மிக நீண்ட சரங்கள், மிக நீண்ட வரிசைகள் இருந்தால் என்ன செய்வது என்று பார்ப்போம். அவற்றை கிளிக்ஹவுஸில் சேமிக்க வேண்டிய அவசியமில்லை. அதற்கு பதிலாக, நீங்கள் ClickHouse இல் ஒரு அடையாளங்காட்டியை மட்டுமே சேமிக்க முடியும். இந்த நீண்ட கோடுகளை வேறு சில அமைப்பில் வைக்கவும்.

எடுத்துக்காட்டாக, எங்கள் பகுப்பாய்வு சேவைகளில் சில நிகழ்வு அளவுருக்கள் உள்ளன. நிகழ்வுகளுக்கு பல அளவுருக்கள் இருந்தால், 512 ஒரு பரிதாபம் இல்லை என்பதால், முதலில் வரும் 512 ஐ சேமிக்கிறோம்.

உங்கள் தரவு வகைகளை உங்களால் தீர்மானிக்க முடியாவிட்டால், நீங்கள் ClickHouse இல் தரவை பதிவு செய்யலாம், ஆனால் பதிவு வகையின் தற்காலிக அட்டவணையில், தற்காலிக தரவுகளுக்கு சிறப்பு. இதற்குப் பிறகு, உங்களிடம் என்ன மதிப்புகள் உள்ளன, பொதுவாக என்ன இருக்கிறது என்பதை நீங்கள் பகுப்பாய்வு செய்து சரியான வகைகளை உருவாக்கலாம்.

*ClickHouse இப்போது ஒரு தரவு வகையைக் கொண்டுள்ளது குறைந்த கார்டினாலிட்டி இது குறைந்த முயற்சியில் சரங்களை திறமையாக சேமிக்க உங்களை அனுமதிக்கிறது.

இப்போது மற்றொரு சுவாரஸ்யமான வழக்கைப் பார்ப்போம். சில நேரங்களில் விஷயங்கள் மக்களுக்கு விசித்திரமாக வேலை செய்கின்றன. நான் உள்ளே வந்து இதைப் பார்க்கிறேன். MySQL பதிப்பு 3.23 ஐ அமைப்பதில் விரிவான அனுபவமுள்ள சில மிகவும் அனுபவம் வாய்ந்த, புத்திசாலி நிர்வாகியால் இது செய்யப்பட்டது என்று உடனடியாகத் தெரிகிறது.

இங்கே நாம் ஆயிரம் அட்டவணைகளைக் காண்கிறோம், அவை ஒவ்வொன்றும் ஆயிரத்தால் யாருக்குத் தெரியும் என்பதைப் பிரிப்பதன் மீதியைப் பதிவுசெய்கிறது.

கொள்கையளவில், இந்த அனுபவத்தின் மூலம் பெறக்கூடிய துன்பங்களைப் புரிந்துகொள்வது உட்பட, மற்றவர்களின் அனுபவத்தை நான் மதிக்கிறேன்.

மேலும் காரணங்கள் அதிகமாகவோ அல்லது குறைவாகவோ தெளிவாக உள்ளன. இவை பழைய ஸ்டீரியோடைப்கள், அவை மற்ற அமைப்புகளுடன் பணிபுரியும் போது குவிந்திருக்கலாம். எடுத்துக்காட்டாக, MyISAM அட்டவணையில் க்ளஸ்டர்டு முதன்மை விசை இல்லை. தரவைப் பிரிப்பதற்கான இந்த வழி அதே செயல்பாட்டைப் பெறுவதற்கான அவநம்பிக்கையான முயற்சியாக இருக்கலாம்.

மற்றொரு காரணம், பெரிய டேபிள்களில் ஏதேனும் மாற்று செயல்பாடுகளைச் செய்வது கடினம். அனைத்தும் தடுக்கப்படும். MySQL இன் நவீன பதிப்புகளில் இந்த சிக்கல் இனி அவ்வளவு தீவிரமாக இல்லை.

அல்லது, எடுத்துக்காட்டாக, மைக்ரோஷார்டிங், ஆனால் அதைப் பற்றி பின்னர்.

ClickHouse இல் இதைச் செய்ய வேண்டிய அவசியமில்லை, ஏனெனில், முதலில், முதன்மை விசை கிளஸ்டர் செய்யப்படுகிறது, தரவு முதன்மை விசையால் வரிசைப்படுத்தப்படுகிறது.

சில நேரங்களில் மக்கள் என்னிடம் கேட்கிறார்கள்: "கிளிக்ஹவுஸில் உள்ள வரம்பு வினவல்களின் செயல்திறன் அட்டவணை அளவைப் பொறுத்து எப்படி மாறுபடும்?" அது மாறாது என்கிறேன். எடுத்துக்காட்டாக, உங்களிடம் ஒரு பில்லியன் வரிசைகள் கொண்ட அட்டவணை உள்ளது மற்றும் நீங்கள் ஒரு மில்லியன் வரிசைகளின் வரம்பைப் படிக்கிறீர்கள். எல்லாம் நன்றாக இருக்கிறது. ஒரு அட்டவணையில் ஒரு டிரில்லியன் வரிசைகள் இருந்தால், நீங்கள் ஒரு மில்லியன் வரிசைகளைப் படித்தால், அது கிட்டத்தட்ட ஒரே மாதிரியாக இருக்கும்.

மற்றும், இரண்டாவதாக, கையேடு பகிர்வுகள் போன்ற அனைத்து வகையான விஷயங்களும் தேவையில்லை. நீங்கள் உள்ளே சென்று கோப்பு முறைமையில் என்ன இருக்கிறது என்று பார்த்தால், அட்டவணை மிகவும் பெரிய விஷயமாக இருப்பதை நீங்கள் காண்பீர்கள். மற்றும் உள்ளே பகிர்வுகள் போன்ற ஒன்று உள்ளது. அதாவது, ClickHouse உங்களுக்காக எல்லாவற்றையும் செய்கிறது மற்றும் நீங்கள் கஷ்டப்பட வேண்டியதில்லை.

ஆல்டர் இன் கிளிக்ஹவுஸ் இலவசம் சேர்/டிப் நெடுவரிசையை மாற்றினால்.

நீங்கள் சிறிய அட்டவணைகளை உருவாக்கக்கூடாது, ஏனென்றால் ஒரு அட்டவணையில் 10 வரிசைகள் அல்லது 10 வரிசைகள் இருந்தால், அது ஒரு பொருட்டல்ல. கிளிக்ஹவுஸ் என்பது செயல்திறனை மேம்படுத்தும் ஒரு அமைப்பாகும், தாமதம் அல்ல, எனவே 000 வரிகளை செயலாக்குவதில் அர்த்தமில்லை.

ஒரு பெரிய அட்டவணையைப் பயன்படுத்துவது சரியானது. பழைய பழக்கவழக்கங்களை விடுங்கள், எல்லாம் சரியாகிவிடும்.

மேலும் போனஸாக, சமீபத்திய பதிப்பில், தனித்தனி பகிர்வுகளில் அனைத்து வகையான பராமரிப்பு செயல்பாடுகளையும் செய்ய, ஒரு தன்னிச்சையான பகிர்வு விசையை உருவாக்கும் திறன் இப்போது எங்களிடம் உள்ளது.

எடுத்துக்காட்டாக, உங்களுக்கு பல சிறிய அட்டவணைகள் தேவை, எடுத்துக்காட்டாக, சில இடைநிலைத் தரவைச் செயலாக்க வேண்டிய அவசியம் ஏற்பட்டால், நீங்கள் துகள்களைப் பெறுவீர்கள், மேலும் இறுதி அட்டவணையில் எழுதும் முன் அவற்றை மாற்றியமைக்க வேண்டும். இந்த வழக்கில், ஒரு அற்புதமான அட்டவணை இயந்திரம் உள்ளது - ஸ்ட்ரைப்லாக். இது டைனிலாக் போன்றது, சிறந்தது.

* இப்போது கிளிக்ஹவுஸும் உள்ளது அட்டவணை செயல்பாடு உள்ளீடு.

மற்றொரு எதிர்ப்பு வடிவமானது மைக்ரோஷார்டிங் ஆகும். எடுத்துக்காட்டாக, நீங்கள் தரவைத் துண்டிக்க வேண்டும் மற்றும் உங்களிடம் 5 சேவையகங்கள் உள்ளன, நாளை 6 சேவையகங்கள் இருக்கும். இந்தத் தரவை எவ்வாறு மறுசீரமைப்பது என்பது பற்றி நீங்கள் சிந்திக்கிறீர்கள். அதற்கு பதிலாக நீங்கள் 5 துண்டுகளாக அல்ல, ஆனால் 1 துண்டுகளாக உடைக்கிறீர்கள். இந்த மைக்ரோஷார்ட்கள் ஒவ்வொன்றையும் தனித்தனி சேவையகத்திற்கு வரைபடமாக்குகிறீர்கள். எடுத்துக்காட்டாக, ஒரு சேவையகத்தில் 000 கிளிக்ஹவுஸ்களைப் பெறுவீர்கள். தனித்தனி போர்ட்கள் அல்லது தனி தரவுத்தளங்களில் தனி நிகழ்வுகள்.

ஆனால் கிளிக்ஹவுஸில் இது மிகவும் நன்றாக இல்லை. ஒரு கிளிக்ஹவுஸ் நிகழ்வு கூட ஒரு கோரிக்கையைச் செயல்படுத்த கிடைக்கக்கூடிய அனைத்து சேவையக ஆதாரங்களையும் பயன்படுத்த முயற்சிக்கிறது. அதாவது, உங்களிடம் சில வகையான சேவையகம் உள்ளது, எடுத்துக்காட்டாக, 56 செயலி கோர்கள் உள்ளன. நீங்கள் ஒரு வினாடி வினவலை இயக்குகிறீர்கள், அது 56 கோர்களைப் பயன்படுத்தும். நீங்கள் ஒரு சர்வரில் 200 கிளிக்ஹவுஸ்களை வைத்தால், 10 த்ரெட்கள் தொடங்கும். பொதுவாக, எல்லாம் மிகவும் மோசமாக இருக்கும்.

மற்றொரு காரணம், இந்த நிகழ்வுகளில் வேலை விநியோகம் சீரற்றதாக இருக்கும். சிலர் முன்னதாகவே முடிப்பார்கள், சிலர் பின்னர் முடிப்பார்கள். இவை அனைத்தும் ஒரு நிகழ்வில் நடந்தால், த்ரெட்களில் தரவை எவ்வாறு சரியாக விநியோகிப்பது என்பதை ClickHouse தானே கண்டுபிடிக்கும்.

மற்றொரு காரணம் என்னவென்றால், நீங்கள் TCP வழியாக இடைச்செயலி தொடர்பு வைத்திருப்பீர்கள். தரவு வரிசைப்படுத்தப்பட வேண்டும், சீரமைக்கப்பட வேண்டும், மேலும் இது ஒரு பெரிய எண்ணிக்கையிலான மைக்ரோஷார்டுகளாகும். இது வெறுமனே திறம்பட செயல்படாது.

மற்றொரு எதிர்ப்பு வடிவமானது, இருப்பினும் இது ஒரு எதிர்ப்பு வடிவமாக அழைக்கப்பட முடியாது. இது ஒரு பெரிய அளவு முன் திரட்டல் ஆகும்.

பொதுவாக, முன் கூட்டல் நல்லது. உங்களிடம் ஒரு பில்லியன் வரிசைகள் இருந்தன, நீங்கள் அதை ஒருங்கிணைத்தீர்கள், அது 1 வரிசைகளாக மாறியது, இப்போது வினவல் உடனடியாக செயல்படுத்தப்படுகிறது. எல்லாம் அருமை. நீங்கள் இதை செய்ய முடியும். இதற்கு, ClickHouse கூட ஒரு சிறப்பு அட்டவணை வகையை கொண்டுள்ளது, அக்ரிகேட்டிங்மெர்ஜ் ட்ரீ, இது தரவு செருகப்படும் போது அதிகரிக்கும் ஒருங்கிணைப்பை செய்கிறது.

ஆனால் இதுபோன்ற தரவுகளை நாங்கள் திரட்டுவோம், இதுபோன்ற தரவைத் திரட்டுவோம் என்று நீங்கள் நினைக்கும் நேரங்களும் உள்ளன. மேலும் சில அண்டைத் துறைகளில், எது என்று நான் சொல்ல விரும்பவில்லை, அவர்கள் முதன்மை விசையால் சுருக்கமாக SummingMergeTree அட்டவணைகளைப் பயன்படுத்துகிறார்கள், மேலும் 20 நெடுவரிசைகள் முதன்மை விசையாகப் பயன்படுத்தப்படுகின்றன. ஒரு வேளை, நான் சில நெடுவரிசைகளின் பெயர்களை இரகசியத்திற்காக மாற்றினேன், ஆனால் அது மிகவும் அதிகமாக உள்ளது.

மேலும் இதுபோன்ற பிரச்சினைகள் எழுகின்றன. முதலாவதாக, உங்கள் தரவு அளவு அதிகமாக குறையாது. உதாரணமாக, இது மூன்று மடங்கு குறைகிறது. உங்கள் தரவு ஒருங்கிணைக்கப்படாவிட்டால் ஏற்படும் வரம்பற்ற பகுப்பாய்வு திறன்களை வாங்குவதற்கு மூன்று மடங்கு நல்ல விலையாக இருக்கும். தரவு ஒருங்கிணைக்கப்பட்டால், பகுப்பாய்வுகளுக்குப் பதிலாக பரிதாபகரமான புள்ளிவிவரங்கள் மட்டுமே கிடைக்கும்.

மேலும் இதில் என்ன விசேஷம்? உண்மை என்னவென்றால், பக்கத்துத் துறையைச் சேர்ந்தவர்கள் சில சமயங்களில் சென்று முதன்மை விசையில் மற்றொரு நிரலைச் சேர்க்கச் சொல்வார்கள். அதாவது, நாங்கள் தரவை இப்படி ஒருங்கிணைத்தோம், ஆனால் இப்போது இன்னும் கொஞ்சம் வேண்டும். ஆனால் ClickHouse இல் மாற்று முதன்மை விசை இல்லை. எனவே, நாம் சில ஸ்கிரிப்ட்களை C++ இல் எழுத வேண்டும். மேலும் ஸ்கிரிப்ட்கள் C++ இல் இருந்தாலும் எனக்குப் பிடிக்காது.

கிளிக்ஹவுஸ் எதற்காக உருவாக்கப்பட்டது என்பதைப் பார்த்தால், ஒருங்கிணைக்கப்படாத தரவு சரியாக அது பிறந்த காட்சியாகும். நீங்கள் ஒருங்கிணைக்கப்படாத தரவுகளுக்கு ClickHouse ஐப் பயன்படுத்துகிறீர்கள் என்றால், நீங்கள் அதைச் சரியாகச் செய்கிறீர்கள். நீங்கள் ஒருங்கிணைத்தால், இது சில நேரங்களில் மன்னிக்கக்கூடியது.

மற்றொரு சுவாரஸ்யமான வழக்கு எல்லையற்ற சுழற்சியில் வினவல்கள். சில சமயங்களில் நான் சில தயாரிப்பு சேவையகத்திற்குச் சென்று அங்குள்ள நிகழ்ச்சிப் பட்டியலைப் பார்க்கிறேன். ஒவ்வொரு முறையும் பயங்கரமான ஒன்று நடக்கிறது என்பதை நான் கண்டுபிடிக்கிறேன்.

உதாரணமாக, இது போன்றது. எல்லாவற்றையும் ஒரே கோரிக்கையில் செய்ய முடியும் என்பது உடனடியாகத் தெளிவாகிறது. உள்ள url மற்றும் பட்டியலை எழுதவும்.

முடிவற்ற சுழற்சியில் இதுபோன்ற பல கேள்விகள் ஏன் மோசமாக உள்ளன? ஒரு குறியீடு பயன்படுத்தப்படாவிட்டால், அதே தரவின் மீது பல பாஸ்களைப் பெறுவீர்கள். ஆனால் குறியீட்டைப் பயன்படுத்தினால், எடுத்துக்காட்டாக, உங்களிடம் ru க்கு முதன்மை விசை உள்ளது மற்றும் நீங்கள் url = ஏதாவது ஒன்றை எழுதுகிறீர்கள். மேலும் ஒரே ஒரு URLஐ டேபிளில் இருந்து படித்தால் எல்லாம் சரியாகிவிடும் என்று நினைக்கிறீர்கள். ஆனால் உண்மையில் இல்லை. ஏனென்றால் கிளிக்ஹவுஸ் எல்லாவற்றையும் தொகுப்பாகச் செய்கிறது.

அவர் ஒரு குறிப்பிட்ட அளவிலான தரவைப் படிக்க வேண்டியிருக்கும் போது, ​​அவர் இன்னும் கொஞ்சம் அதிகமாகப் படிக்கிறார், ஏனெனில் கிளிக்ஹவுஸில் உள்ள குறியீடு குறைவாக உள்ளது. அட்டவணையில் ஒரு தனிப்பட்ட வரிசையைக் கண்டறிய இந்த அட்டவணை உங்களை அனுமதிக்காது, சில வகையான வரம்புகள் மட்டுமே. மற்றும் தரவு தொகுதிகளில் சுருக்கப்பட்டுள்ளது. ஒரு வரியைப் படிக்க, நீங்கள் முழு தொகுதியையும் எடுத்து அதை அவிழ்க்க வேண்டும். நீங்கள் பல வினவல்களை இயக்குகிறீர்கள் என்றால், உங்களிடம் நிறைய ஒன்றுடன் ஒன்று இருக்கும், மேலும் நீங்கள் மீண்டும் மீண்டும் செய்ய நிறைய வேலைகள் இருக்கும்.

மேலும் போனஸாக, கிளிக்ஹவுஸில் மெகாபைட்கள் மற்றும் நூற்றுக்கணக்கான மெகாபைட்களைக் கூட IN பிரிவுக்கு மாற்ற நீங்கள் பயப்படக்கூடாது என்பதை நீங்கள் கவனிக்கலாம். MySQL இல் ஒரு சில மதிப்புகளை IN பிரிவுக்கு மாற்றினால், எடுத்துக்காட்டாக, 100 மெகாபைட் சில எண்களை அங்கு மாற்றினால், MySQL 10 ஜிகாபைட் நினைவகத்தை சாப்பிடுகிறது, அதற்கு வேறு எதுவும் நடக்காது என்பதை எங்கள் நடைமுறையில் இருந்து நான் நினைவில் கொள்கிறேன். மோசமாக வேலை செய்கிறது.

இரண்டாவது, ClickHouse இல், உங்கள் வினவல்கள் ஒரு குறியீட்டைப் பயன்படுத்தினால், அது எப்போதும் முழு ஸ்கேன் செய்வதை விட மெதுவாக இருக்காது, அதாவது நீங்கள் கிட்டத்தட்ட முழு அட்டவணையையும் படிக்க வேண்டும் என்றால், அது வரிசையாகச் சென்று முழு அட்டவணையையும் படிக்கும். பொதுவாக, அவர் அதை தானே கண்டுபிடிப்பார்.

ஆனாலும் சில சிரமங்கள் உள்ளன. எடுத்துக்காட்டாக, துணை வினவலுடன் IN என்பது குறியீட்டைப் பயன்படுத்தாது. ஆனால் இது எங்கள் பிரச்சனை, அதை நாம் சரிசெய்ய வேண்டும். இங்கே அடிப்படை எதுவும் இல்லை. சரி செய்வோம்*.

மற்றொரு சுவாரஸ்யமான விஷயம் என்னவென்றால், உங்களிடம் மிக நீண்ட கோரிக்கை இருந்தால் மற்றும் விநியோகிக்கப்பட்ட கோரிக்கை செயலாக்கம் செயல்பாட்டில் இருந்தால், இந்த மிக நீண்ட கோரிக்கை சுருக்கம் இல்லாமல் ஒவ்வொரு சேவையகத்திற்கும் அனுப்பப்படும். உதாரணமாக, 100 மெகாபைட் மற்றும் 500 சர்வர்கள். மேலும், அதன்படி, நீங்கள் நெட்வொர்க்கில் 50 ஜிகாபைட்களை மாற்றுவீர்கள். அது கடத்தப்படும், பின்னர் அனைத்தும் வெற்றிகரமாக முடிக்கப்படும்.

* ஏற்கனவே பயன்படுத்தி; வாக்குறுதியளித்தபடி எல்லாம் சரி செய்யப்பட்டது.

API இலிருந்து கோரிக்கைகள் வரும்போது மிகவும் பொதுவான வழக்கு. உதாரணமாக, நீங்கள் உங்கள் சொந்த சேவையை உருவாக்கியுள்ளீர்கள். ஒருவருக்கு உங்கள் சேவை தேவைப்பட்டால், நீங்கள் API ஐத் திறந்து, இரண்டு நாட்களுக்குப் பிறகு புரிந்துகொள்ள முடியாத ஒன்று நடப்பதைக் காண்கிறீர்கள். எல்லாமே ஓவர்லோட் ஆகி, நடக்கக்கூடாத சில பயங்கரமான கோரிக்கைகள் வருகின்றன.

மற்றும் ஒரே ஒரு தீர்வு உள்ளது. நீங்கள் API ஐத் திறந்திருந்தால், நீங்கள் அதை வெட்ட வேண்டும். உதாரணமாக, சில வகையான ஒதுக்கீட்டை அறிமுகப்படுத்துங்கள். வேறு எந்த சாதாரண விருப்பங்களும் இல்லை. இல்லையெனில், அவர்கள் உடனடியாக ஒரு ஸ்கிரிப்ட் எழுதுவார்கள், சிக்கல்கள் இருக்கும்.

கிளிக்ஹவுஸ் ஒரு சிறப்பு அம்சத்தைக் கொண்டுள்ளது - ஒதுக்கீடு கணக்கீடு. மேலும், உங்கள் ஒதுக்கீட்டு விசையை நீங்கள் மாற்றலாம். இது, எடுத்துக்காட்டாக, உள் பயனர் ஐடி. மற்றும் ஒதுக்கீடுகள் ஒவ்வொன்றிற்கும் தனித்தனியாக கணக்கிடப்படும்.

இப்போது மற்றொரு சுவாரஸ்யமான விஷயம். இது கையேடு பிரதியீடு.

கிளிக்ஹவுஸில் உள்ளமைக்கப்பட்ட பிரதிபலிப்பு ஆதரவு இருந்தபோதிலும், மக்கள் கிளிக்ஹவுஸை கைமுறையாக நகலெடுக்கும் பல நிகழ்வுகளை நான் அறிவேன்.

கொள்கை என்ன? உங்களிடம் தரவு செயலாக்க பைப்லைன் உள்ளது. இது சுயாதீனமாக வேலை செய்கிறது, எடுத்துக்காட்டாக, வெவ்வேறு தரவு மையங்களில். கிளிக்ஹவுஸில் அதே தரவை அதே வழியில் எழுதுகிறீர்கள். உண்மை, உங்கள் குறியீட்டில் உள்ள சில அம்சங்கள் காரணமாக தரவு இன்னும் வேறுபடும் என்பதை நடைமுறை காட்டுகிறது. அது உன்னுடையது என்று நம்புகிறேன்.

மேலும் அவ்வப்போது நீங்கள் கைமுறையாக ஒத்திசைக்க வேண்டும். உதாரணமாக, மாதம் ஒருமுறை நிர்வாகிகள் rsync செய்கிறார்கள்.

உண்மையில், ClickHouse இல் கட்டமைக்கப்பட்ட பிரதியைப் பயன்படுத்துவது மிகவும் எளிதானது. ஆனால் சில முரண்பாடுகள் இருக்கலாம், ஏனென்றால் இதற்காக நீங்கள் ZooKeeper ஐப் பயன்படுத்த வேண்டும். ZooKeeper பற்றி நான் தவறாக எதுவும் சொல்ல மாட்டேன், கொள்கையளவில், கணினி வேலை செய்கிறது, ஆனால் ஜாவா-ஃபோபியா காரணமாக மக்கள் அதைப் பயன்படுத்துவதில்லை, ஏனென்றால் கிளிக்ஹவுஸ் என்பது C++ இல் எழுதப்பட்ட ஒரு நல்ல அமைப்பு, நீங்கள் பயன்படுத்தலாம் மற்றும் எல்லாம் சரியாகி விடும் . மற்றும் ZooKeeper ஜாவாவில் உள்ளது. எப்படியோ நீங்கள் பார்க்க விரும்பவில்லை, ஆனால் நீங்கள் கையேடு நகலெடுப்பைப் பயன்படுத்தலாம்.

ClickHouse ஒரு நடைமுறை அமைப்பு. அவள் உங்கள் தேவைகளை கணக்கில் எடுத்துக்கொள்கிறாள். உங்களிடம் கைமுறையாக நகலெடுக்கப்பட்டிருந்தால், உங்கள் கையேடு பிரதிகளைப் பார்த்து, அவற்றுக்கிடையே தோல்வியைச் செய்யும் ஒரு விநியோகிக்கப்பட்ட அட்டவணையை நீங்கள் உருவாக்கலாம். உங்கள் கோடுகள் முறையாக வேறுபட்டாலும், தோல்விகளைத் தவிர்க்க உங்களை அனுமதிக்கும் ஒரு சிறப்பு விருப்பம் கூட உள்ளது.

நீங்கள் பழமையான அட்டவணை இயந்திரங்களைப் பயன்படுத்தினால் மேலும் சிக்கல்கள் ஏற்படலாம். ClickHouse என்பது பல்வேறு டேபிள் இன்ஜின்களைக் கொண்ட ஒரு கட்டமைப்பாகும். ஆவணத்தில் எழுதப்பட்ட அனைத்து தீவிர நிகழ்வுகளுக்கும், MergeTree குடும்பத்தின் அட்டவணைகளைப் பயன்படுத்தவும். மற்ற அனைத்தும் - இது தனிப்பட்ட வழக்குகளுக்கு அல்லது சோதனைகளுக்கு.

MergeTree அட்டவணையில், நீங்கள் எந்த தேதியும் நேரத்தையும் வைத்திருக்க வேண்டியதில்லை. நீங்கள் இன்னும் அதைப் பயன்படுத்தலாம். தேதி மற்றும் நேரம் இல்லை என்றால், இயல்புநிலை 2000 என்று எழுதவும். இது வேலை செய்யும் மற்றும் ஆதாரங்கள் தேவையில்லை.

சேவையகத்தின் புதிய பதிப்பில், பகிர்வு விசை இல்லாமல் தனிப்பயன் பகிர்வு இருப்பதை நீங்கள் குறிப்பிடலாம். அப்படியே இருக்கும்.

மறுபுறம், நீங்கள் பழமையான அட்டவணை இயந்திரங்களைப் பயன்படுத்தலாம். எடுத்துக்காட்டாக, தரவை ஒரு முறை நிரப்பவும், பார்க்கவும், திருப்பவும் மற்றும் நீக்கவும். நீங்கள் பதிவைப் பயன்படுத்தலாம்.

அல்லது இடைநிலை செயலாக்கத்திற்காக சிறிய தொகுதிகளை சேமிப்பது ஸ்ட்ரைப்லாக் அல்லது டைனிலாக் ஆகும்.

டேட்டாவின் அளவு சிறியதாக இருந்தால் நினைவகத்தைப் பயன்படுத்தலாம் மற்றும் நீங்கள் ரேமில் எதையாவது சுழற்றலாம்.

மறுசீரமைக்கப்பட்ட தரவை ClickHouse உண்மையில் விரும்பவில்லை.

இங்கே ஒரு பொதுவான உதாரணம். இது ஒரு பெரிய எண்ணிக்கையிலான URLகள். நீங்கள் அவற்றை அடுத்த அட்டவணையில் வைக்கவும். பின்னர் அவர்கள் அவர்களுடன் சேர முடிவு செய்தனர், ஆனால் இது ஒரு விதியாக வேலை செய்யாது, ஏனெனில் கிளிக்ஹவுஸ் ஹாஷ் சேனை மட்டுமே ஆதரிக்கிறது. இணைக்கப்பட வேண்டிய பல தரவுகளுக்கு போதுமான ரேம் இல்லை என்றால், JOIN வேலை செய்யாது*.

தரவு அதிக கார்டினலிட்டியாக இருந்தால், கவலைப்பட வேண்டாம், அதை இயல்புநிலைப்படுத்தப்பட்ட வடிவத்தில் சேமிக்கவும், URL கள் நேரடியாக பிரதான அட்டவணையில் இருக்கும்.

* இப்போது ClickHouse ஆனது ஒரு ஒன்றிணைப்பைக் கொண்டுள்ளது, மேலும் இது இடைநிலை தரவு ரேமில் பொருந்தாத நிலையில் வேலை செய்கிறது. ஆனால் இது பயனற்றது மற்றும் பரிந்துரை நடைமுறையில் உள்ளது.

இன்னும் இரண்டு எடுத்துக்காட்டுகள், ஆனால் அவை முறைக்கு எதிரானவையா இல்லையா என்று நான் ஏற்கனவே சந்தேகிக்கிறேன்.

ClickHouse ஒரு அறியப்பட்ட குறைபாடு உள்ளது. அதை எப்படி மேம்படுத்துவது என்று தெரியவில்லை*. சில வழிகளில், இதுவும் நல்லது. உங்களிடம் சில முக்கியமான தரவு இருந்தால், எடுத்துக்காட்டாக, கணக்கியல், யாரும் அதை அனுப்ப முடியாது, ஏனெனில் புதுப்பிப்புகள் எதுவும் இல்லை.

* பேட்ச் பயன்முறையில் புதுப்பித்தல் மற்றும் நீக்குவதற்கான ஆதரவு நீண்ட காலத்திற்கு முன்பே சேர்க்கப்பட்டது.

ஆனால் பின்னணியில் இருப்பது போல் புதுப்பிப்புகளை அனுமதிக்கும் சில சிறப்பு வழிகள் உள்ளன. எடுத்துக்காட்டாக, ReplaceMergeTree போன்ற அட்டவணைகள். பின்னணி ஒன்றிணைக்கும் போது அவை புதுப்பிப்புகளைச் செய்கின்றன. மேம்படுத்தப்பட்ட அட்டவணையைப் பயன்படுத்தி இதை நீங்கள் கட்டாயப்படுத்தலாம். ஆனால் இதை அடிக்கடி செய்யாதீர்கள், ஏனெனில் இது பகிர்வை முழுமையாக மேலெழுதும்.

ClickHouse இல் விநியோகிக்கப்பட்ட JOINகள் வினவல் திட்டமிடுபவரால் மோசமாகக் கையாளப்படுகின்றன.

மோசமானது, ஆனால் சில நேரங்களில் சரி.

தேர்ந்தெடு* ஐப் பயன்படுத்தி தரவை மீண்டும் படிக்க கிளிக்ஹவுஸை மட்டும் பயன்படுத்தவும்.

சிக்கலான கணக்கீடுகளுக்கு ClickHouse ஐப் பயன்படுத்த நான் பரிந்துரைக்க மாட்டேன். ஆனால் இது முற்றிலும் உண்மை இல்லை, ஏனென்றால் நாங்கள் ஏற்கனவே இந்த பரிந்துரையிலிருந்து விலகிச் செல்கிறோம். கிளிக்ஹவுஸ் - கேட்பூஸ்டில் இயந்திர கற்றல் மாதிரிகளைப் பயன்படுத்துவதற்கான திறனை நாங்கள் சமீபத்தில் சேர்த்துள்ளோம். அது என்னைத் தொந்தரவு செய்கிறது, ஏனென்றால் நான் நினைக்கிறேன், "என்ன ஒரு திகில். இது ஒரு பைட்டுக்கு எத்தனை சுழற்சிகள் ஆகும்! பைட்டுகளில் கடிகாரங்களை வீணாக்குவதை நான் உண்மையில் வெறுக்கிறேன்.

ஆனால் பயப்பட வேண்டாம், ClickHouse ஐ நிறுவவும், எல்லாம் சரியாகிவிடும். ஏதாவது இருந்தால், எங்களுக்கு ஒரு சமூகம் உள்ளது. சொல்லப்போனால், சமூகம் நீங்கள்தான். உங்களுக்கு ஏதேனும் சிக்கல்கள் இருந்தால், நீங்கள் குறைந்தபட்சம் எங்கள் அரட்டைக்குச் செல்லலாம், மேலும் அவர்கள் உங்களுக்கு உதவுவார்கள் என்று நம்புகிறேன்.

உங்கள் கேள்விகள்

அறிக்கைக்கு நன்றி! கிளிக்ஹவுஸ் செயலிழந்ததைப் பற்றி நான் எங்கே புகார் செய்யலாம்?

நீங்கள் இப்போது என்னிடம் தனிப்பட்ட முறையில் புகார் செய்யலாம்.

நான் சமீபத்தில் கிளிக்ஹவுஸைப் பயன்படுத்தத் தொடங்கினேன். நான் உடனடியாக cli இடைமுகத்தை கைவிட்டேன்.

என்ன மதிப்பெண்.

சிறிது நேரம் கழித்து நான் ஒரு சிறிய தேர்வில் சேவையகத்தை செயலிழக்கச் செய்தேன்.

உங்களிடம் திறமை இருக்கிறது.

நான் ஒரு GitHub பிழையைத் திறந்தேன், ஆனால் அது புறக்கணிக்கப்பட்டது.

நாம் பார்ப்போம்.

அலெக்ஸி என்னை ஏமாற்றி அறிக்கைக்கு வரச் செய்தார், உள்ளே உள்ள தரவை நீங்கள் எவ்வாறு அணுகுகிறீர்கள் என்பதை என்னிடம் கூறுவதாக உறுதியளித்தார்.

இது மிகவும் எளிது.

இதை நான் நேற்று உணர்ந்தேன். மேலும் விவரங்கள்.

அங்கே பயங்கரமான தந்திரங்கள் எதுவும் இல்லை. தொகுதி-மூலம்-தொகுதி சுருக்கம் உள்ளது. இயல்புநிலை LZ4 ஆகும், நீங்கள் ZSTD*ஐ இயக்கலாம். 64 கிலோபைட் முதல் 1 மெகாபைட் வரை தொகுதிகள்.

* பிற அல்காரிதம்களுடன் ஒரு சங்கிலியில் பயன்படுத்தக்கூடிய சிறப்பு சுருக்க கோடெக்குகளுக்கான ஆதரவும் உள்ளது.

தொகுதிகள் வெறும் மூல தரவுதானா?

முற்றிலும் பச்சையாக இல்லை. வரிசைகள் உள்ளன. உங்களிடம் எண் நெடுவரிசை இருந்தால், ஒரு வரிசையில் உள்ள எண்கள் ஒரு வரிசையில் வைக்கப்படும்.

தெளிவாக உள்ளது.

Alexey, IPs மீது uniqExact உடன் இருந்த ஒரு உதாரணம், அதாவது uniqExact ஆனது எண்களைக் காட்டிலும் கோடுகளால் கணக்கிடுவதற்கு அதிக நேரம் எடுக்கும், மற்றும் பல. ப்ரூஃப் ரீடிங் செய்யும் போது காதுகளில் ஃபைன்ட் போட்டு வார்த்தால் என்ன செய்வது? அதாவது, எங்கள் வட்டில் இது மிகவும் வித்தியாசமாக இல்லை என்று நீங்கள் கூறியதாகத் தெரிகிறது. வட்டில் இருந்து வரிகளைப் படித்தால் மற்றும் வார்ப்பு செய்தால், நமது திரட்டுகள் வேகமாக இருக்குமா இல்லையா? அல்லது நாம் இன்னும் கொஞ்சம் இங்கே பெறலாமா? நீங்கள் இதை சோதித்தீர்கள் என்று எனக்குத் தோன்றுகிறது, ஆனால் சில காரணங்களால் அதை அளவுகோலில் குறிப்பிடவில்லை.

நடிப்பு இல்லாமல் மெதுவாக இருக்கும் என்று நினைக்கிறேன். இந்த வழக்கில், ஐபி முகவரி சரத்தில் இருந்து பாகுபடுத்தப்பட வேண்டும். நிச்சயமாக, ClickHouse இல், எங்கள் IP முகவரி பாகுபடுத்துதலும் உகந்ததாக உள்ளது. நாங்கள் மிகவும் கடினமாக முயற்சித்தோம், ஆனால் உங்களிடம் பத்தாயிரமாவது வடிவத்தில் எண்கள் எழுதப்பட்டுள்ளன. மிகவும் சங்கடமான. மறுபுறம், uniqExact செயல்பாடு சரங்களில் மெதுவாகச் செயல்படும், இவை சரங்களாக இருப்பதால் மட்டுமின்றி, அல்காரிதத்தின் வேறுபட்ட சிறப்பும் தேர்ந்தெடுக்கப்பட்டிருப்பதால். சரங்கள் வெறுமனே வித்தியாசமாக செயலாக்கப்படுகின்றன.

நாம் மிகவும் பழமையான தரவு வகையை எடுத்துக் கொண்டால் என்ன செய்வது? உதாரணத்திற்கு, நம்மிடம் உள்ள பயனர் ஐடியை எழுதி, அதை ஒரு வரியாக எழுதி, பின்னர் அதை துருவினால், அது வேடிக்கையாக இருக்குமா இல்லையா?

நான் சந்தேகிக்கிறேன். இது இன்னும் சோகமாக இருக்கும் என்று நான் நினைக்கிறேன், ஏனென்றால் எண்களை பாகுபடுத்துவது ஒரு தீவிர பிரச்சனை. பத்தாயிரமாவது வடிவத்தில் எண்களை அலசுவது எவ்வளவு கடினம் என்பது குறித்த அறிக்கையை இந்த சக ஊழியர் கொடுத்ததாக எனக்குத் தோன்றுகிறது, ஆனால் ஒருவேளை இல்லை.

அலெக்ஸி, அறிக்கைக்கு மிக்க நன்றி! கிளிக்ஹவுஸுக்கு மிக்க நன்றி! திட்டங்களைப் பற்றி எனக்கு ஒரு கேள்வி உள்ளது. அகராதிகளை முழுமையடையாமல் புதுப்பிக்கும் அம்சத்திற்கான திட்டங்கள் ஏதேனும் உள்ளதா?

அதாவது, ஒரு பகுதி மறுதொடக்கம்?

ஆம் ஆம். MySQL புலத்தை அங்கு அமைக்கும் திறனைப் போலவே, அதாவது அகராதி மிகப் பெரியதாக இருந்தால் மட்டுமே இந்தத் தரவு ஏற்றப்படும் வகையில் புதுப்பிக்கவும்.

மிகவும் சுவாரஸ்யமான அம்சம். எங்கள் அரட்டையில் சிலர் அதை பரிந்துரைத்ததாக நான் நினைக்கிறேன். ஒருவேளை அது நீங்கள் கூட இருக்கலாம்.

நான் அப்படி நினைக்கவில்லை.

நல்லது, இப்போது இரண்டு கோரிக்கைகள் உள்ளன என்று மாறிவிடும். நீங்கள் மெதுவாக அதை செய்ய ஆரம்பிக்கலாம். ஆனால் இந்த அம்சம் செயல்படுத்த மிகவும் எளிதானது என்பதை நான் உடனடியாக உங்களுக்கு எச்சரிக்க விரும்புகிறேன். அதாவது, கோட்பாட்டில், நீங்கள் அட்டவணையில் பதிப்பு எண்ணை எழுத வேண்டும், பின்னர் எழுத வேண்டும்: பதிப்பு போன்றவற்றை விட குறைவானது. இதன் பொருள், பெரும்பாலும், நாங்கள் இதை ஆர்வலர்களுக்கு வழங்குவோம். நீங்கள் ஒரு ஆர்வலரா?

ஆம், ஆனால், துரதிர்ஷ்டவசமாக, C++ இல் இல்லை.

உங்கள் சக ஊழியர்களுக்கு C++ இல் எழுதத் தெரியுமா?

நான் யாரையாவது கண்டு பிடிக்கிறேன்.

நன்று*.

அறிக்கைக்கு இரண்டு மாதங்களுக்குப் பிறகு அம்சம் சேர்க்கப்பட்டது - கேள்வியின் ஆசிரியர் அதை உருவாக்கி அனுப்பினார் கோரிக்கையை இழுக்கவும்.

நன்றி!

வணக்கம்! அறிக்கைக்கு நன்றி! கிளிக்ஹவுஸ் தனக்கு கிடைக்கும் அனைத்து வளங்களையும் பயன்படுத்துவதில் மிகவும் சிறந்தது என்று நீங்கள் குறிப்பிட்டுள்ளீர்கள். மேலும் லக்ஸாஃப்டின் பக்கத்து பேச்சாளர் ரஷ்ய போஸ்டுக்கான தனது தீர்வைப் பற்றி பேசினார். அவர்கள் ClickHouse ஐ மிகவும் விரும்புவதாகவும், ஆனால் அவர்கள் அதை தங்கள் முக்கிய போட்டியாளருக்கு பதிலாக பயன்படுத்தவில்லை, ஏனெனில் அது அனைத்து CPU ஐயும் தின்றுவிட்டதாக அவர் கூறினார். மேலும் அவர்களால் அதை அவர்களின் கட்டிடக்கலையில், டாக்கர்களுடன் தங்கள் ZooKeeper இல் இணைக்க முடியவில்லை. கிளிக்ஹவுஸை எப்படியாவது மட்டுப்படுத்த முடியுமா, அதனால் அது கிடைக்கும் அனைத்தையும் நுகராது?

ஆம், இது சாத்தியம் மற்றும் மிகவும் எளிதானது. நீங்கள் குறைவான கோர்களை உட்கொள்ள விரும்பினால், எழுதுங்கள் set max_threads = 1. அவ்வளவுதான், இது கோரிக்கையை ஒரு மையத்தில் செயல்படுத்தும். மேலும், வெவ்வேறு பயனர்களுக்கு வெவ்வேறு அமைப்புகளை நீங்கள் குறிப்பிடலாம். அதனால் பிரச்சனை இல்லை. மேலும் லக்ஸாஃப்டில் உள்ள உங்கள் சகாக்களிடம் இந்த அமைப்பை ஆவணத்தில் கண்டுபிடிக்காதது நல்லதல்ல என்று சொல்லுங்கள்.

அலெக்ஸி, வணக்கம்! இந்தக் கேள்வியைப் பற்றி நான் கேட்க விரும்புகிறேன். பலர் பதிவுகளுக்கான சேமிப்பகமாக ClickHouse ஐப் பயன்படுத்தத் தொடங்குகிறார்கள் என்று நான் கேள்விப்படுவது இது முதல் முறை அல்ல. அறிக்கையில் நீங்கள் இதைச் செய்ய வேண்டாம் என்று சொன்னீர்கள், அதாவது நீங்கள் நீண்ட சரங்களை சேமிக்க தேவையில்லை. அதைப் பற்றி நீங்கள் என்ன நினைக்கிறீர்கள்?

முதலாவதாக, பதிவுகள், ஒரு விதியாக, நீண்ட சரங்கள் அல்ல. நிச்சயமாக, விதிவிலக்குகள் உள்ளன. எடுத்துக்காட்டாக, ஜாவாவில் எழுதப்பட்ட சில சேவைகள் விதிவிலக்கு அளிக்கின்றன, அது உள்நுழைந்துள்ளது. மேலும் முடிவில்லாத சுழற்சியில், மற்றும் வன்வட்டில் உள்ள இடம் தீர்ந்துவிடும். தீர்வு மிகவும் எளிது. கோடுகள் மிக நீளமாக இருந்தால், அவற்றை வெட்டுங்கள். நீளம் என்றால் என்ன? பத்து கிலோபைட்டுகள் மோசமானவை*.

* ClickHouse இன் சமீபத்திய பதிப்புகளில், “அடாப்டிவ் இன்டெக்ஸ் கிரானுலாரிட்டி” இயக்கப்பட்டது, இது நீண்ட வரிசைகளை சேமிப்பதில் உள்ள சிக்கலை நீக்குகிறது.

ஒரு கிலோபைட் சாதாரணமா?

இது சாதாரணமானது.

வணக்கம்! அறிக்கைக்கு நன்றி! இதைப் பற்றி நான் ஏற்கனவே அரட்டையில் கேட்டேன், ஆனால் எனக்கு பதில் கிடைத்ததா என்பது எனக்கு நினைவில் இல்லை. எப்படியாவது CTE முறையில் WITH பிரிவை விரிவுபடுத்தும் திட்டம் உள்ளதா?

இதுவரை இல்லை. எங்கள் வித் பிரிவு ஓரளவு அற்பமானது. இது எங்களுக்கு ஒரு சிறிய அம்சம் போன்றது.

எனக்கு புரிகிறது. நன்றி!

அறிக்கைக்கு நன்றி! மிகவும் சுவாரஸ்யமானது! உலகளாவிய கேள்வி. தரவு நீக்கத்தை மாற்றுவதற்கான திட்டங்கள் ஏதேனும் உள்ளதா?

அவசியம். இது எங்கள் வரிசையில் எங்கள் முதல் பணி. எல்லாவற்றையும் எவ்வாறு சரியாகச் செய்வது என்பது பற்றி இப்போது தீவிரமாக சிந்திக்கிறோம். நீங்கள் விசைப்பலகை * அழுத்தத் தொடங்க வேண்டும்.

* விசைப்பலகையில் உள்ள பட்டன்களை அழுத்தி எல்லாவற்றையும் செய்தேன்.

இது எப்படியாவது கணினி செயல்திறனை பாதிக்குமா இல்லையா? இப்போது உள்ளதைப் போல் செருகுவது வேகமாக இருக்குமா?

ஒருவேளை தங்களை நீக்குவது மற்றும் புதுப்பிப்புகள் மிகவும் அதிகமாக இருக்கும், ஆனால் இது தேர்வுகளின் செயல்திறன் அல்லது செருகல்களின் செயல்திறனை பாதிக்காது.

மேலும் ஒரு சிறிய கேள்வி. விளக்கக்காட்சியில் நீங்கள் முதன்மை விசையைப் பற்றி பேசியுள்ளீர்கள். அதன்படி, எங்களிடம் பகிர்வு உள்ளது, இது மாதாந்திர முன்னிருப்பாக, சரியானதா? ஒரு மாதத்திற்கு பொருந்தக்கூடிய தேதி வரம்பை நாம் அமைக்கும்போது, ​​​​இந்த பகிர்வு மட்டுமே படிக்கப்படும், இல்லையா?

ஆமாம்.

ஒரு கேள்வி. எந்த முதன்மை விசையையும் நம்மால் தேர்ந்தெடுக்க முடியாவிட்டால், "தேதி" புலத்தின்படி அதைச் செய்வது சரியானதா, இதனால் பின்னணியில் இந்தத் தரவின் மறுசீரமைப்பு குறைவாக இருப்பதால் அது மிகவும் ஒழுங்கான முறையில் பொருந்துமா? உங்களிடம் வரம்பு வினவல்கள் இல்லையென்றால், எந்த முதன்மை விசையையும் உங்களால் தேர்ந்தெடுக்க முடியவில்லை என்றால், முதன்மை விசையில் தேதியை வைப்பது மதிப்புள்ளதா?

ஆமாம்.

முதன்மை விசையில் ஒரு புலத்தை வைப்பது அர்த்தமுள்ளதாக இருக்கலாம், இது இந்த புலத்தால் வரிசைப்படுத்தப்பட்டால் தரவை சிறப்பாக சுருக்கும். உதாரணமாக, பயனர் ஐடி. எடுத்துக்காட்டாக, பயனர் அதே தளத்திற்குச் செல்கிறார். இந்த வழக்கில், பயனர் ஐடி மற்றும் நேரத்தை வைக்கவும். பின்னர் உங்கள் தரவு சிறப்பாக சுருக்கப்படும். தேதியைப் பொறுத்தவரை, உங்களிடம் உண்மையில் தேதிகளில் வரம்பு வினவல்கள் இல்லை என்றால், நீங்கள் தேதியை முதன்மை விசையில் வைக்க வேண்டியதில்லை.

சரி மிக்க நன்றி!

ஆதாரம்: www.habr.com