ClickHouse мамандандырылған жүйе болғандықтан, оны пайдалану кезінде оның архитектурасының ерекшеліктерін ескеру қажет. Бұл есепте Алексей ClickHouse пайдалану кезінде жиі кездесетін қателердің мысалдары туралы әңгімелейді, бұл тиімсіз жұмысқа әкелуі мүмкін. Тәжірибелік мысалдар деректерді өңдеудің бір немесе басқа схемасын таңдау өнімділікті шама ретімен қалай өзгерте алатынын көрсетеді.
Бәріңе сәлем! Менің атым Алексей, мен ClickHouse жасаймын.
Біріншіден, мен сізді бірден қуантуға асығамын, бүгін мен ClickHouse дегеннің не екенін айтпаймын. Шынымды айтсам одан шаршадым. Мен саған оның не екенін айтқан сайын. Және бәрі бұрыннан білетін шығар.
Оның орнына мен сізге қандай қателер болуы мүмкін екенін айтамын, яғни ClickHouse қолданбасын қалай дұрыс пайдаланбауға болады. Шын мәнінде, қорқудың қажеті жоқ, өйткені біз ClickHouse-ты қарапайым, ыңғайлы және қораптан тыс жұмыс істейтін жүйе ретінде дамытамыз. Мен оны орнаттым, ешқандай проблема жоқ.
Бірақ сіз әлі де бұл жүйенің мамандандырылған екенін ескеруіңіз керек және сіз бұл жүйені жайлылық аймағынан шығаратын әдеттен тыс пайдалану жағдайын оңай кездестіре аласыз.
Сонымен, қандай тырма бар? Мен көбінесе анық нәрселер туралы айтатын боламын. Барлығына бәрі түсінікті, барлығы бәрін түсінеді және өздерінің соншалықты ақылды екеніне қуана алады, ал түсінбейтіндер жаңа нәрсені үйренеді.
Өкінішке орай, жиі кездесетін бірінші және ең қарапайым мысал - бұл шағын партиялары бар кірістірулердің үлкен саны, яғни. шағын кірістірулердің үлкен саны.
Егер ClickHouse кірістіруді қалай орындайтынын қарастырсақ, бір сұрауда кем дегенде терабайт деректерді жіберуге болады. Бұл мәселе емес.
Ал, әдеттегі өнімділік қандай болатынын көрейік. Мысалы, бізде Yandex.Metrica деректерінен кесте бар. Хиттер. 105 кейбір бағандар. 700 байт қысылмаған. Біз миллион жолдан тұратын партияларға жақсы жолмен кірістіреміз.
Біз MergeTree-ді кестеге енгіземіз, ол секундына жарты миллион жолды құрайды. Тамаша. Қайталанатын кестеде ол сәл кішірек болады, шамамен секундына 400 000 жол.
Ал егер кворумды енгізуді қоссаңыз, секундына 250 000 термин аз, бірақ жақсы өнімділікке ие боласыз. Кворум кірістіру ClickHouse* ішіндегі құжатталмаған мүмкіндік болып табылады.
* 2020 ж. .
Егер сіз жаман нәрсе жасасаңыз не болады? MergeTree кестесіне бір жолды енгіземіз және секундына 59 жол аламыз. Бұл 10 000 есе баяу. ReplicatedMergeTree ішінде – секундына 6 жол. Ал егер кворум қосылса, секундына 2 жол шығады. Менің ойымша, бұл абсолютті ақымақтық. Бұлай қалай баяулатуға болады? Менің футболкамда ClickHouse жылдамдығын төмендетпеу керек деп жазылған. Бірақ соған қарамастан ол кейде болады.
Негізі бұл біздің кемшілігіміз. Біз бәрін оңай жасай алар едік, бірақ олай етпедік. Біз мұны жасамадық, өйткені сценарийіміз мұны қажет етпеді. Бізде бұтақтар болды. Біз тек кіреберісте партияларды алдық және ешқандай проблема жоқ. Біз оны енгіземіз және бәрі жақсы жұмыс істейді. Бірақ, әрине, барлық сценарийлер болуы мүмкін. Мысалы, деректер жасалатын көптеген серверлер болған кезде. Және олар деректерді жиі енгізбейді, бірақ олар әлі де жиі кірістірумен аяқталады. Біз мұны қалай да болдырмауымыз керек.
Техникалық тұрғыдан алғанда, мəселе мынада, сіз ClickHouse бағдарламасында кірістіру жасағанда, деректер ешбір естелік кестеде аяқталмайды. Бізде MergeTree журналының нақты құрылымы да жоқ, тек MergeTree, себебі журнал да, memTable де жоқ. Біз деректерді бірден файлдық жүйеге жазамыз, қазірдің өзінде бағандарға орналастырылған. Ал егер сізде 100 баған болса, онда 200-ден астам файлды бөлек каталогқа жазу қажет болады. Мұның бәрі өте ауыр.
Және сұрақ туындайды: «Мұны қалай дұрыс істеу керек?» Егер жағдай сіз әлі де ClickHouse-да қандай да бір түрде деректерді жазуыңыз керек болса.
1-әдіс. Бұл ең оңай жол. Бөлінген кезектің қандай да бір түрін пайдаланыңыз. Мысалы, Кафка. Сіз жай ғана Кафкадан деректерді шығарып, оны секундына бір рет жинайсыз. Және бәрі жақсы болады, сіз жазасыз, бәрі жақсы жұмыс істейді.
Кемшіліктері Кафканың басқа көлемді бөлінген жүйе болып табылады. Сіздің компанияңызда Кафка бар ма, мен де түсінемін. Бұл жақсы, бұл ыңғайлы. Бірақ егер ол жоқ болса, жобаға тағы бір бөлінген жүйені апармас бұрын үш рет ойлану керек. Сондықтан балама нұсқаларды қарастырған жөн.
2-әдіс. Бұл ескі мектеп баламасы және сонымен бірге өте қарапайым. Сізде журналдарды жасайтын қандай да бір сервер бар ма? Және ол сіздің журналдарыңызды файлға жазады. Ал секундына бір рет, мысалы, біз бұл файлдың атын өзгертіп, жаңасын жыртамыз. Жеке сценарий, не cron немесе кейбір демон арқылы, ең ескі файлды алып, оны ClickHouse-қа жазады. Егер журналдарды секундына бір рет жазсаңыз, онда бәрі жақсы болады.
Бірақ бұл әдістің кемшілігі, егер журналдар жасалған серверіңіз бір жерде жоғалып кетсе, деректер де жоғалады.
3-әдіс. Уақытша файлдарды мүлдем қажет етпейтін тағы бір қызықты әдіс бар. Мысалы, сізде жарнамалық спиннер немесе деректерді жасайтын басқа қызықты демон бар. Ал сіз деректерді тікелей жедел жадта, буферде жинақтай аласыз. Ал жеткілікті уақыт өткенде, сіз бұл буферді бір жаққа қойып, жаңасын жасайсыз және бөлек ағынға ClickHouse ішіне жинақталған нәрсені енгізесіз.
Екінші жағынан, деректер өлтіру -9 арқылы да жоғалады. Егер сіздің серверіңіз бұзылса, сіз бұл деректерді жоғалтасыз. Тағы бір мәселе, егер сіз дерекқорға жаза алмасаңыз, деректеріңіз жедел жадта жиналады. ЖЖҚ таусылады, немесе сіз жай ғана деректерді жоғалтасыз.
4-әдіс. Тағы бір қызықты әдіс. Сізде серверлік процесс бар ма? Ол деректерді бірден ClickHouse қызметіне жібере алады, бірақ оны бір қосылымда орындаңыз. Мысалы, мен http сұрауын жіберу-кодтаумен жібердім: кірістірумен кесінді. Және бұл бөліктерді генерациялау өте сирек емес, сіз әрбір жолды жібере аласыз, бірақ бұл деректерді жақтау үшін үстеме шығындар болады.
Дегенмен, бұл жағдайда деректер бірден ClickHouse қызметіне жіберіледі. Ал ClickHouse оларды өзі буферлейді.
Бірақ проблемалар да туындайды. Енді сіз деректерді жоғалтасыз, соның ішінде процессіңіз жойылғанда және ClickHouse процесі жойылса, ол аяқталмаған кірістіру болады. Ал ClickHouse-да кірістірулер жолдар өлшеміндегі белгілі бір шекке дейін атомдық болып табылады. Негізінде бұл қызықты әдіс. Сондай-ақ қолдануға болады.
5-әдіс. Міне, тағы бір қызықты әдіс. Бұл деректерді топтастыруға арналған қауымдастық әзірлеген сервердің бір түрі. Өзім қараған жоқпын, сондықтан ештеңеге кепілдік бере алмаймын. Дегенмен, ClickHouse үшін ешқандай кепілдік берілмейді. Бұл да ашық бастапқы дереккөз, бірақ екінші жағынан, сіз біз қамтамасыз етуге тырысатын кейбір сапа стандартына үйренген болуыңыз мүмкін. Бірақ бұл үшін - мен білмеймін, GitHub-қа өтіңіз, кодты қараңыз. Мүмкін олар қалыпты нәрсе жазған шығар.
* 2020 жылғы жағдай бойынша да ескеру қажет .
6-әдіс. Басқа әдіс – буфер кестелерін пайдалану. Бұл әдістің артықшылығы - оны қолдануды бастау өте оңай. Буфер кестесін жасаңыз және оны оған кірістіріңіз.
Кемшілігі – мәселенің толық шешілмеуі. MergeTree сияқты жылдамдықта деректерді секундына бір топтама бойынша топтастыру қажет болса, онда буферлік кестедегі жылдамдықта секундына кемінде бірнеше мыңға дейін топтау қажет. Егер секундына 10 000-нан жоғары болса, ол бәрібір нашар болады. Ал егер сіз оны топтамамен енгізсеңіз, оның секундына жүз мың жол болып шығатынын көрдіңіз. Бұл қазірдің өзінде өте ауыр деректерде.
Сондай-ақ буферлік кестелерде журнал жоқ. Ал егер сіздің серверіңізде ақау болса, деректер жоғалады.
Бонус ретінде біз жақында ClickHouse сайтында Кафкадан деректерді алу мүмкіндігіне ие болдық. Үстел қозғалтқышы бар - Кафка. Сіз жай ғана жасайсыз. Оған материалдандырылған бейнелерді іліп қоюға болады. Бұл жағдайда ол өзі Кафкадан деректерді шығарып, сізге қажет кестелерге кірістіреді.
Бұл мүмкіндіктің ерекше қуанғаны – мұны біз жасаған жоқпыз. Бұл қауымдастық ерекшелігі. Мен «қоғамдық ерекшелігі» дегенде, мен оны менсінбей айтамын. Біз кодты оқыдық, шолу жасадық, ол жақсы жұмыс істеуі керек.
* 2020 жылдан бастап осындай қолдау көрсетілді .
Деректерді енгізу кезінде тағы не ыңғайсыз немесе күтпеген болуы мүмкін? Мәндерді енгізу сұрауын жасасаңыз және мәндерде кейбір есептелген өрнектерді жазсаңыз. Мысалы, now() да есептелген өрнек болып табылады. Және бұл жағдайда ClickHouse әр жолда осы өрнектердің интерпретаторын іске қосуға мәжбүр болады және өнімділік шама бойынша төмендейді. Бұдан аулақ болған дұрыс.
* қазіргі уақытта мәселе толығымен шешілді, VALUES ішіндегі өрнектерді пайдалану кезінде өнімділік регрессиясы жоқ.
Басқа мысал - бөлімдер тобына жататын бір бумадағы деректер болған кезде кейбір мәселелер туындауы мүмкін. Әдепкі бойынша ClickHouse бөлімдері ай бойынша болады. Егер сіз миллион жолдың партиясын енгізсеңіз және бірнеше жыл бойы деректер болса, онда сізде бірнеше ондаған бөлімдер болады. Және бұл өлшемдері бірнеше ондаған есе аз партиялар болатынына тең, өйткені олардың ішінде әрқашан алдымен бөлімдерге бөлінеді.
* Жақында эксперименттік режимде ClickHouse алдын ала жазу журналы бар жедел жадтағы бөліктер мен бөліктердің ықшам пішімін қолдауды қосты, бұл мәселені толығымен дерлік шешеді.
Енді мәселенің екінші түрін – мәліметтерді теруді қарастырайық.
Деректерді теру қатаң немесе жолды болуы мүмкін. Жол - сіз оны жаңа ғана алып, барлық өрістеріңіз string типті екенін жариялаған кезде. Бұл сұмдық. Мұны істеудің қажеті жоқ.
Бізде қандай да бір өріс, жол бар деп айтқыңыз келген жағдайда мұны қалай дұрыс жасау керектігін анықтап көрейік және ClickHouse-ға оны өздігінен анықтауға мүмкіндік беріңіз, мен алаңдамаймын. Бірақ әлі де біраз күш салуға тұрарлық.
Мысалы, бізде IP мекенжайы бар. Бір жағдайда біз оны жол ретінде сақтадық. Мысалы, 192.168.1.1. Ал басқа жағдайда бұл UInt32* типті сан болады. IPv32 мекенжайы үшін 4 бит жеткілікті.
Біріншіден, бір қызығы, деректер шамамен бірдей қысылады. Әрине, айырмашылық болады, бірақ онша үлкен емес. Сондықтан дискінің енгізу/шығаруында ерекше проблемалар жоқ.
Бірақ процессор уақыты мен сұрауды орындау уақытында айтарлықтай айырмашылық бар.
Бірегей IP мекенжайларының санын санап көрейік, егер олар сандар ретінде сақталса. Бұл секундына 137 миллион жолды құрайды. Егер бұл жолдар түрінде болса, секундына 37 миллион жол. Неліктен бұл кездейсоқтық болғанын білмеймін. Бұл өтініштерді өзім орындадым. Бірақ әлі де шамамен 4 есе баяу.
Ал егер сіз дискілік кеңістіктегі айырмашылықты есептесеңіз, онда айырмашылық та бар. Айырмашылық шамамен төрттен бір бөлігін құрайды, өйткені бірегей IP мекенжайлары өте көп. Ал егер әртүрлі мағыналары аз жолдар болса, онда олар сөздікке сәйкес шамамен бірдей көлемге оңай қысылады.
Ал төрт есе уақыт айырмашылығы жолда жатпайды. Бәлкім, сіз ренжімейтін шығарсыз, әрине, бірақ мен мұндай айырмашылықты көргенде, мені қынжылтады.
Әртүрлі жағдайларды қарастырайық.
1. Сізде әртүрлі бірегей мәндер аз болған бір жағдай. Бұл жағдайда біз сіз білетін және кез келген ДҚБЖ үшін қолдануға болатын қарапайым тәжірибені қолданамыз. Мұның бәрі ClickHouse үшін ғана емес, мағынасы бар. Дерекқорға тек сандық идентификаторларды жазыңыз. Сіз қолданбаңыздың жағында жолдарға және кері түрлендіруге болады.
Мысалы, сізде аймақ бар. Сіз оны жол ретінде сақтауға тырысасыз. Ол сонда жазылады: Мәскеу және Мәскеу облысы. «Мәскеу» деп жазылғанын көргенде, бұл ештеңе емес, бірақ Мәскеу болғанда, ол мүлдем қайғырады. Бұл қанша байт.
Оның орнына біз жай ғана Ulnt32 және 250 санын жазамыз. Яндексте бізде 250 бар, бірақ сіздікі басқа болуы мүмкін. Қалай болғанда да, мен ClickHouse-да геобазамен жұмыс істеудің кірістірілген мүмкіндігі бар екенін айтамын. Сіз жай ғана аймақтары бар каталогты, соның ішінде иерархиялықты жазасыз, яғни Мәскеу, Мәскеу облысы және сізге қажет нәрсенің бәрі болады. Сіз сұраныс деңгейінде түрлендіруге болады.
Екінші опция шамамен бірдей, бірақ ClickHouse ішінде қолдау бар. Бұл Enum деректер түрі. Сіз жай ғана Enum ішіне барлық қажетті мәндерді жазасыз. Мысалы, құрылғы түрін және сол жерге жазыңыз: жұмыс үстелі, ұялы телефон, планшет, теледидар. Барлығы 4 нұсқа бар.
Кемшілігі - оны мезгіл-мезгіл өзгерту керек. Бір ғана опция қосылды. Кестені өзгертейік. Шын мәнінде, ClickHouse бағдарламасында кестені өзгерту тегін. Әсіресе Enum үшін тегін, себебі дискідегі деректер өзгермейді. Бірақ соған қарамастан, alter үстелде құлыпқа* ие болады және барлық таңдаулар орындалғанша күту керек. Және бұл өзгертуден кейін ғана орындалады, яғни әлі де кейбір қолайсыздықтар бар.
* ClickHouse соңғы нұсқаларында ALTER толығымен бұғатталмайды.
ClickHouse үшін өте ерекше тағы бір опция сыртқы сөздіктерді қосу болып табылады. ClickHouse бағдарламасында сандарды жазуға және каталогтарыңызды өзіңізге ыңғайлы кез келген жүйеде сақтауға болады. Мысалы, сіз мыналарды пайдалана аласыз: MySQL, Mongo, Postgres. Сіз бұл деректерді http арқылы жіберетін өзіңіздің жеке микросервисіңізді жасай аласыз. Ал ClickHouse деңгейінде сіз осы деректерді сандардан жолдарға түрлендіретін функцияны жазасыз.
Бұл сыртқы кестеде біріктіруді орындаудың мамандандырылған, бірақ өте тиімді жолы. Және екі нұсқа бар. Бір нұсқада бұл деректер толығымен кэштеледі, жедел жадта толық болады және белгілі бір жиілікпен жаңартылады. Басқа нұсқада, егер бұл деректер ЖЖҚ-ға сәйкес келмесе, оны ішінара кэштеуге болады.
Міне, мысал. 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 есе жылдам орындалады. Бірақ бұл деректер ыстық болғандықтан. Ал егер салқын болса, дискінің енгізу/шығаруына байланысты ол 25 есе жылдамырақ болар еді.
Айтпақшы, егер домен URL мекенжайынан қаншалықты кіші екенін есептесеңіз, ол шамамен 4 есе аз болып шығады.Бірақ қандай да бір себептермен деректер дискіде 25 есе аз алады. Неліктен? Қысуға байланысты. Және URL қысылған, ал домен қысылған. Бірақ көбінесе URL мекенжайында қоқыс бар.
Және, әрине, қажетті мәндер үшін арнайы жасалған немесе қолайлы деректер түрлерін пайдалану өте жақсы. Егер сіз IPv4 жүйесінде болсаңыз, UInt32* сақтаңыз. Егер IPv6 болса, FixedString(16), себебі IPv6 мекенжайы 128 бит, яғни екілік пішімде тікелей сақталады.
Бірақ сізде кейде IPv4 мекенжайлары және кейде IPv6 болса ше? Иә, екеуін де сақтауға болады. IPv4 үшін бір баған, IPv6 үшін екіншісі. Әрине, IPv4-ті IPv6-да көрсету мүмкіндігі бар. Бұл да жұмыс істейді, бірақ сұрауларда IPv4 мекенжайы жиі қажет болса, оны бөлек бағанға қою жақсы болар еді.
* ClickHouse қолданбасында қазір деректерді сандар сияқты тиімді сақтайтын, бірақ оларды жолдар сияқты ыңғайлы түрде көрсететін жеке IPv4, IPv6 деректер түрлері бар.
Сондай-ақ, деректерді алдын-ала өңдеу керек екенін атап өткен жөн. Мысалы, сіз кейбір өңделмеген журналдарды аласыз. Мүмкін сіз оларды бірден ClickHouse-ға қоймауыңыз керек, бірақ бұл ештеңе істемеу өте қызықты және бәрі жұмыс істейді. Бірақ әлі де мүмкін болатын есептеулерді жүргізуге тұрарлық.
Мысалы, браузер нұсқасы. Мен саусағыңызды көрсеткім келмейтін кейбір жақын бөлімде браузер нұсқасы келесідей сақталады, яғни жол ретінде: 12.3. Содан кейін есеп беру үшін олар осы жолды алып, оны массивке, содан кейін массивтің бірінші элементіне бөледі. Әрине, бәрі баяулайды. Мен олардың неге бұлай жасайтынын сұрадым. Олар маған мерзімінен бұрын оңтайландыруды ұнатпайтындарын айтты. Ал мен ерте пессимизацияны ұнатпаймын.
Сондықтан бұл жағдайда 4 бағанға бөлу дұрысырақ болар еді. Мұнда қорықпаңыз, өйткені бұл ClickHouse. ClickHouse — бағаналы дерекқор. Кішкентай бағандар неғұрлым ұқыпты болса, соғұрлым жақсы. 5 шолғыш нұсқасы болады, 5 баған жасаңыз. Бұл жақсы.
Енді сізде өте ұзын жолдар, өте ұзын массивтер көп болса, не істеу керектігін қарастырайық. Оларды ClickHouse-да сақтаудың қажеті жоқ. Оның орнына идентификаторды ClickHouse ішінде ғана сақтауға болады. Осы ұзын жолдарды басқа жүйеге салыңыз.
Мысалы, аналитикалық қызметтеріміздің бірінде оқиға параметрлері бар. Ал егер оқиғалардың параметрлері көп болса, біз бірінші кездескен 512-ні ғана сақтаймыз, өйткені 512 өкінішті емес.
Деректер түрлерін таңдай алмасаңыз, деректерді ClickHouse қолданбасында, бірақ уақытша деректер үшін арнайы журнал түріндегі уақытша кестеде жазуға болады. Осыдан кейін сізде құндылықтардың қандай үлестірілетінін, жалпы не бар екенін талдап, дұрыс типтерді жасауға болады.
*ClickHouse-та енді деректер түрі бар бұл аз күш жұмсай отырып, жолдарды тиімді сақтауға мүмкіндік береді.
Енді тағы бір қызық жағдайды қарастырайық. Кейде адамдар үшін біртүрлі жұмыс істейді. Мен кіріп, мынаны көремін. Мұны MySQL 3.23 нұсқасын орнатуда үлкен тәжірибесі бар өте тәжірибелі, ақылды әкімші жасаған сияқты.
Мұнда біз мың кестені көреміз, олардың әрқайсысы кім нені мыңға бөлудің қалғанын жазады.
Негізінде, мен басқа адамдардың тәжірибесін, соның ішінде осы тәжірибе арқылы алуға болатын азапты түсінуді құрметтеймін.
Ал себептері азды-көпті түсінікті. Бұл басқа жүйелермен жұмыс істеу кезінде жинақталған ескі стереотиптер. Мысалы, MyISAM кестелерінде кластерленген бастапқы кілт жоқ. Деректерді бөлудің бұл жолы бірдей функционалдылықты алудың үмітсіз әрекеті болуы мүмкін.
Тағы бір себебі, үлкен кестелерде кез келген өзгерту әрекеттерін орындау қиын. Барлығы блокталады. MySQL-тің заманауи нұсқаларында бұл мәселе енді соншалықты маңызды емес.
Немесе, мысалы, microsharding, бірақ бұл туралы кейінірек.
ClickHouse бағдарламасында мұны істеудің қажеті жоқ, себебі, біріншіден, бастапқы кілт кластерленген, деректер бастапқы кілт бойынша реттелген.
Кейде адамдар менен: «ClickHouse ішіндегі ауқым сұрауларының өнімділігі кесте өлшеміне байланысты қалай өзгереді?» Деп сұрайды. Мен бұл мүлдем өзгермейді деп айтамын. Мысалы, сізде миллиард жолдан тұратын кесте бар және сіз миллион жолдар ауқымын оқисыз. Бәрі жақсы. Егер кестеде триллион жол болса және сіз миллион жолды оқысаңыз, ол бірдей болады.
Екіншіден, қолмен бөлімдер сияқты барлық нәрселер қажет емес. Егер сіз кіріп, файлдық жүйеде не бар екенін қарасаңыз, кестенің өте үлкен мәміле екенін көресіз. Және ішінде бөлімдер сияқты нәрсе бар. Яғни, ClickHouse сіз үшін бәрін жасайды және сіз зардап шекпейсіз.
Қосу/тастыру бағанын өзгертсеңіз, ClickHouse бағдарламасында өзгерту тегін.
Кішкентай кестелерді жасамауыңыз керек, өйткені кестеде 10 жол немесе 10 000 жол болса, бұл мүлдем маңызды емес. ClickHouse - кешіктіру емес, өткізу қабілетін оңтайландыратын жүйе, сондықтан 10 жолды өңдеудің мағынасы жоқ.
Бір үлкен кестені қолданған дұрыс. Ескі стереотиптерден арылыңыз, бәрі жақсы болады.
Бонус ретінде, соңғы нұсқада бізде жеке бөлімдерде техникалық қызмет көрсету операцияларының барлық түрлерін орындау үшін еркін бөлу кілтін жасау мүмкіндігі бар.
Мысалы, сізге көптеген шағын кестелер қажет, мысалы, кейбір аралық деректерді өңдеу қажет болғанда, сіз бөліктерді аласыз және соңғы кестеге жазбас бұрын оларда түрлендіруді орындауыңыз керек. Бұл жағдайда керемет үстел қозғалтқышы бар - StripeLog. Бұл TinyLog сияқты, тек жақсырақ.
* енді ClickHouse-да да бар .
Тағы бір антипаттерн - бұл микробөлшектеу. Мысалы, деректерді бөлшектеу керек және сізде 5 сервер бар, ал ертең 6 сервер болады. Сіз бұл деректерді қалай теңестіру керектігін ойлайсыз. Оның орнына сіз 5 бөлікке емес, 1 сыныққа бөлесіз. Содан кейін сіз осы микрошардтардың әрқайсысын бөлек серверге салыстырасыз. Сіз, мысалы, бір серверде 000 ClickHouse аласыз, мысалы. Бөлек порттардағы немесе бөлек дерекқорлардағы бөлек даналарды.
Бірақ бұл ClickHouse-та өте жақсы емес. Өйткені бір ClickHouse данасы бір сұрауды өңдеу үшін барлық қолжетімді сервер ресурстарын пайдалануға тырысады. Яғни, сізде қандай да бір сервер бар және оның, мысалы, 56 процессорлық ядросы бар. Сіз бір секундты алатын сұрауды орындап жатырсыз және ол 56 ядроны пайдаланады. Егер сіз сол жерде бір серверде 200 ClickHouse орналастырсаңыз, онда 10 000 ағындар басталады. Жалпы, бәрі өте нашар болады.
Тағы бір себеп - бұл инстанциялар бойынша жұмысты бөлу біркелкі болмайды. Біреулері ерте бітірсе, біреулері кеш бітіреді. Егер мұның бәрі бір жағдайда орын алса, онда ClickHouse өзі деректерді ағындар арасында қалай дұрыс тарату керектігін анықтайды.
Тағы бір себебі, сізде TCP арқылы процессор аралық байланыс болады. Деректерді сериялауға, сериядан шығаруға тура келеді және бұл микрошардтардың үлкен саны. Бұл жай ғана тиімді жұмыс істемейді.
Басқа антипаттерн, бірақ оны антипаттерн деп атауға болмайды. Бұл алдын ала жинақтаудың үлкен көлемі.
Жалпы, алдын ала жинақтау жақсы. Сізде миллиард жол болды, сіз оны біріктірдіңіз және ол 1 жолға айналды, енді сұрау бірден орындалады. Бәрі керемет. Сіз мұны істей аласыз. Бұл үшін тіпті ClickHouse бағдарламасында деректер енгізілген кезде қосымша біріктіруді орындайтын AggregatingMergeTree арнайы кесте түрі бар.
Бірақ біз осындай деректерді жинақтаймыз және осындай деректерді біріктіреміз деп ойлайтын кездер болады. Кейбір көрші бөлімдерде мен қайсысын айтқым келмейді, олар бастапқы кілт бойынша қорытындылау үшін SummingMergeTree кестелерін пайдаланады және негізгі кілт ретінде шамамен 20 баған пайдаланылады. Мүмкін болса, мен кейбір бағандардың атын құпиялылық үшін өзгерттім, бірақ бұл өте көп.
Және осындай проблемалар туындайды. Біріншіден, деректер көлемі тым азаймайды. Мысалы, ол үш есеге төмендейді. Деректеріңіз жинақталмаған жағдайда пайда болатын шексіз аналитикалық мүмкіндіктерді алу үшін үш есе жақсы баға болар еді. Егер деректер жинақталған болса, онда аналитиканың орнына сіз тек аянышты статистиканы аласыз.
Ал оның ерекшелігі неде? Өйткені, көрші бөлімдегі бұл адамдар кейде барып, бастапқы кілтке басқа баған қосуды сұрайды. Яғни, біз деректерді осылай жинақтадық, бірақ қазір біз аздап көбірек алғымыз келеді. Бірақ ClickHouse бағдарламасында өзгертуші негізгі кілт жоқ. Сондықтан бізге C++ тілінде бірнеше сценарий жазу керек. Маған сценарийлер ұнамайды, тіпті олар C++ тілінде болса да.
Егер ClickHouse не үшін жасалғанын қарасаңыз, онда жинақталмаған деректер дәл ол дүниеге келген сценарий болып табылады. Біріктірілмеген деректер үшін ClickHouse қолданбасын пайдалансаңыз, оны дұрыс істеп жатырсыз. Егер сіз біріктірсеңіз, бұл кейде кешіріледі.
Тағы бір қызықты жағдай - шексіз циклдегі сұраулар. Кейде мен кейбір өндіріс серверіне барамын және сол жерде көрсету процестерінің тізімін қараймын. Әр кезде мен қорқынышты нәрсе болып жатқанын білемін.
Мысалы, осылай. Барлығын бір өтініште жасауға болатыны бірден түсінікті. Тек URL мекенжайын және тізімді сол жерге жазыңыз.
Неліктен шексіз циклдегі осындай көптеген сұраулар нашар? Егер индекс пайдаланылмаса, сізде бірдей деректер бойынша көптеген өтулер болады. Бірақ егер индекс пайдаланылса, мысалы, сізде ru үшін бастапқы кілт бар және сіз url = бір нәрсе жазасыз. Ал кестеден бір ғана URL оқылса, бәрі жақсы болады деп ойлайсыз. Бірақ іс жүзінде жоқ. Себебі ClickHouse барлығын топтамамен жасайды.
Ол белгілі бір деректер ауқымын оқу қажет болғанда, ол аздап көбірек оқиды, себебі ClickHouse-тағы индекс сирек. Бұл индекс кестеде бір жеке жолды табуға мүмкіндік бермейді, тек қандай да бір түрдегі ауқымды. Ал деректер блоктарда қысылады. Бір жолды оқу үшін бүкіл блокты алып, оны ашу керек. Ал егер сіз көптеген сұрауларды орындасаңыз, сізде көп қабаттасулар болады және сізде қайта-қайта көп жұмыс болады.
Бонус ретінде сіз ClickHouse-та тіпті мегабайттарды, тіпті жүздеген мегабайттарды IN бөліміне аударудан қорықпау керектігін атап өтуге болады. Біздің тәжірибемізден есімде, егер MySQL-де біз IN бөліміне мәндер тобын тасымалдасақ, мысалы, онда кейбір сандардың 100 мегабайтын тасымалдасақ, MySQL 10 гигабайт жадты жейді және оған ештеңе болмайды, бәрі нашар жұмыс істейді.
Екіншісі, ClickHouse-да, егер сұрауларыңыз индексті пайдаланса, ол әрқашан толық сканерлеуден баяу болмайды, яғни бүкіл кестені дерлік оқу қажет болса, ол дәйекті түрде өтіп, бүкіл кестені оқиды. Жалпы, ол мұны өз бетінше анықтайды.
Бірақ соған қарамастан кейбір қиындықтар бар. Мысалы, ішкі сұрауы бар IN индексті пайдаланбауы. Бірақ бұл біздің проблемамыз және біз оны түзетуіміз керек. Мұнда іргелі ештеңе жоқ. Біз оны түзетеміз*.
Тағы бір қызығы, егер сізде өте ұзақ сұрау болса және таратылған сұрауды өңдеу жүріп жатса, бұл өте ұзақ сұраныс әр серверге қысылмай жіберіледі. Мысалы, 100 мегабайт және 500 сервер. Және, тиісінше, сізде желі арқылы тасымалданатын 50 гигабайт болады. Ол жіберіледі, содан кейін бәрі сәтті аяқталады.
* бұрыннан қолданылған; Барлығы уәде етілгендей жөнделді.
Сұраныстар API-ден келген кезде өте кең таралған жағдай. Мысалы, сіз өзіңіздің қызметіңіздің қандай да бір түрін жасадыңыз. Егер біреу сіздің қызметіңізге мұқтаж болса, сіз API ашасыз және екі күннен кейін түсініксіз нәрсе болып жатқанын көресіз. Барлығы шамадан тыс жүктелген және кейбір қорқынышты сұраулар келіп жатыр, олар ешқашан болмауы керек еді.
Және бір ғана шешім бар. Егер сіз API ашқан болсаңыз, оны кесуге тура келеді. Мысалы, квотаның қандай да бір түрін енгізіңіз. Басқа қалыпты опциялар жоқ. Әйтпесе, олар бірден сценарий жазып, қиындықтар туындайды.
Ал ClickHouse-тың ерекше мүмкіндігі бар - квотаны есептеу. Сонымен қатар, сіз квота кілтін аудара аласыз. Бұл, мысалы, ішкі пайдаланушы идентификаторы. Ал олардың әрқайсысына квота дербес есептелетін болады.
Енді тағы бір қызық. Бұл қолмен қайталау.
Мен ClickHouse-да кірістірілген репликация қолдауына қарамастан, адамдар ClickHouse-ды қолмен көшіретін көптеген жағдайларды білемін.
принципі қандай? Сізде деректерді өңдеу құбыры бар. Және ол тәуелсіз жұмыс істейді, мысалы, әртүрлі деректер орталықтарында. Дәл сол деректерді ClickHouse бағдарламасында бірдей жазасыз. Рас, тәжірибе кодыңыздағы кейбір мүмкіндіктерге байланысты деректер әлі де алшақтайтынын көрсетеді. Ол сенікі деп үміттенемін.
Ал мезгіл-мезгіл қолмен синхрондауға тура келеді. Мысалы, әкімшілер айына бір рет rsync жасайды.
Шын мәнінде, ClickHouse ішіне орнатылған репликацияны пайдалану әлдеқайда оңай. Бірақ кейбір қарсы көрсеткіштер болуы мүмкін, себебі ол үшін ZooKeeper пайдалану керек. Мен ZooKeeper туралы жаман ештеңе айтпаймын, негізінен жүйе жұмыс істейді, бірақ адамдар оны java-фобияға байланысты пайдаланбайды, өйткені ClickHouse өте жақсы жүйе, C++ тілінде жазылған, сіз оны пайдалана аласыз және бәрі жақсы болады. Ал ZooKeeper java тілінде. Қандай да бір түрде сіз тіпті қарағыңыз келмейді, бірақ содан кейін қолмен қайталауды пайдалана аласыз.
ClickHouse - бұл практикалық жүйе. Ол сіздің қажеттіліктеріңізді ескереді. Қолмен репликалау мүмкіндігіңіз болса, қолмен көшірмелерді қарайтын және олардың арасында ауыстырып қосуды жүзеге асыратын Бөлінген кестені жасауға болады. Тіпті сызықтарыңыз жүйелі түрде алшақ болса да, флоптарды болдырмауға мүмкіндік беретін арнайы опция бар.
Қарапайым кесте қозғалтқыштарын пайдалансаңыз, қосымша мәселелер туындауы мүмкін. ClickHouse - бұл әртүрлі кесте қозғалтқыштары бар конструктор. Құжаттамада жазылғандай барлық маңызды жағдайлар үшін MergeTree тобының кестелерін пайдаланыңыз. Қалғанының бәрі - бұл жеке жағдайлар үшін немесе сынақтар үшін.
MergeTree кестесінде ешқандай күн мен уақыттың болуы қажет емес. Сіз оны әлі де пайдалана аласыз. Күн мен уақыт болмаса, әдепкі 2000 деп жазыңыз. Бұл жұмыс істейді және ресурстарды қажет етпейді.
Сервердің жаңа нұсқасында сізде бөлім кілтінсіз теңшелетін бөлімдер бар екенін көрсетуге болады. Дәл солай болады.
Екінші жағынан, сіз қарапайым кесте қозғалтқыштарын пайдалана аласыз. Мысалы, деректерді бір рет толтырып, қараңыз, бұраңыз және жойыңыз. Журналды пайдалануға болады.
Немесе аралық өңдеу үшін шағын көлемдерді сақтау StripeLog немесе TinyLog болып табылады.
Жадты деректер көлемі аз болса және жедел жадтағы бір нәрсені жай ғана айналдыра алатын болса пайдалануға болады.
ClickHouse қайта қалыпқа келтірілген деректерді ұнатпайды.
Міне, әдеттегі мысал. Бұл URL мекенжайларының үлкен саны. Сіз оларды келесі кестеге қоясыз. Содан кейін олар олармен JOIN жасауға шешім қабылдады, бірақ бұл әдетте жұмыс істемейді, өйткені ClickHouse тек Hash JOIN-ді қолдайды. Қосылу қажет деректердің көп саны үшін жедел жады жеткіліксіз болса, JOIN жұмыс істемейді*.
Егер деректер жоғары дәрежеде болса, алаңдамаңыз, оны нормадан тыс пішінде сақтаңыз, URL мекенжайлары тікелей негізгі кестеде орналасқан.
* және енді ClickHouse-да біріктіру қосылымы бар және ол аралық деректер ЖЖҚ-ға сәйкес келмейтін жағдайларда жұмыс істейді. Бірақ бұл тиімсіз және ұсыныс күшінде қалады.
Тағы бірнеше мысал, бірақ мен олардың үлгіге қарсы екеніне күмәнданамын.
ClickHouse бағдарламасында бір белгілі кемшілік бар. Ол қалай жаңарту керектігін білмейді*. Кейбір жағынан бұл тіпті жақсы. Егер сізде маңызды деректер болса, мысалы, бухгалтерлік есеп, оны ешкім жібере алмайды, өйткені жаңартулар жоқ.
* пакеттік режимде жаңарту және жою қолдауы бұрыннан қосылған.
Бірақ фондық режимде жаңартуларға мүмкіндік беретін кейбір арнайы жолдар бар. Мысалы, ReplaceMergeTree сияқты кестелер. Олар фондық біріктіру кезінде жаңартуларды жасайды. Оңтайландыру кестесін пайдалану арқылы мұны мәжбүрлей аласыз. Бірақ мұны жиі жасамаңыз, себебі ол бөлімді толығымен қайта жазады.
ClickHouse ішіндегі таратылған JOINдарды сұрауды жоспарлаушы да нашар өңдейді.
Нашар, бірақ кейде жақсы.
Select* көмегімен деректерді кері оқу үшін тек ClickHouse пайдаланыңыз.
Мен қиын есептеулер үшін ClickHouse пайдалануды ұсынбаймын. Бірақ бұл мүлдем дұрыс емес, өйткені біз бұл ұсыныстан қазірдің өзінде кетіп жатырмыз. Жақында біз ClickHouse - Catboost жүйесінде машиналық оқыту үлгілерін қолдану мүмкіндігін қостық. Және бұл мені алаңдатады, өйткені мен ойлаймын: «Қандай сұмдық. Бұл бір байтқа қанша цикл шығады! Мен сағаттарды байттарға жұмсауды жек көремін.
Бірақ қорықпаңыз, ClickHouse орнатыңыз, бәрі жақсы болады. Бір нәрсе болса, бізде қауымдастық бар. Айтпақшы, қоғам сізсіз. Егер сізде қандай да бір қиындықтар болса, сіз ең болмағанда біздің чатқа кіре аласыз, олар сізге көмектеседі деп үміттенеміз.
Сіздің сұрақтарыңыз
Есеп үшін рахмет! ClickHouse бұзылғанына қайда шағымдана аламын?
Дәл қазір маған жеке шағымдануға болады.
Мен жақында ClickHouse пайдалануды бастадым. Мен бірден cli интерфейсін тастадым.
Сіздің жолыңыз болды.
Біраз уақыттан кейін мен серверді кішкене таңдаумен бұздым.
Сізде талант бар.
Мен GitHub қатесін аштым, бірақ ол еленбеді.
Біз көреміз.
Алексей мені алдап репортажға барамын деп, ішіндегі деректерге қалай қол жеткізетініңді айтып беремін деп уәде берді.
Өте оңай.
Мен мұны кеше түсіндім. Толығырақ.
Онда ешқандай қорқынышты трюктар жоқ. Тек блок бойынша қысу бар. Әдепкі LZ4, ZSTD* қосуға болады. 64 килобайттан 1 мегабайтқа дейін блоктау.
* басқа алгоритмдермен тізбекте пайдалануға болатын арнайы қысу кодектеріне де қолдау бар.
Блоктар тек өңделмеген деректер ме?
Толық шикі емес. Массивтер бар. Егер сізде сандық баған болса, онда қатардағы сандар массивке орналастырылады.
Түсінікті.
Алексей, IP мекенжайлары бойынша uniqExact-пен болған мысал, яғни uniqExact-ті сандарға қарағанда жолдар бойынша есептеу ұзағырақ уақытты қажет етеді және т.б. Коррекция кезінде құлағымызбен финтті қолдансақ ше? Яғни, сіз біздің дискімізде онша ерекшеленбейді деп айтқан сияқтысыз. Егер біз дискіден және трансляциядан жолдарды оқысақ, агрегаттарымыз жылдамырақ бола ма, жоқ па? Әлде осында әлі де аздап ұтамыз ба? Менің ойымша, сіз мұны сынап көрдіңіз, бірақ қандай да бір себептермен оны эталонда көрсетпеді.
Менің ойымша, бұл кастингсіз баяуырақ болады. Бұл жағдайда IP мекенжайы жолдан талдануы керек. Әрине, ClickHouse-те біздің IP мекенжайын талдау да оңтайландырылған. Біз қатты тырыстық, бірақ сізде он мыңдық түрінде жазылған сандар бар. Өте ыңғайсыз. Екінші жағынан, uniqExact функциясы бұл жолдар болғандықтан ғана емес, сонымен қатар алгоритмнің басқа мамандануы таңдалғандықтан, жолдарда баяу жұмыс істейді. Жолдар жай ғана басқаша өңделеді.
Неғұрлым қарапайым деректер түрін алсақ ше? Мысалы, бізде бар қолданушы идентификаторын жазып алып, оны жолға түсіріп, сосын шифрладық, қызық бола ма, жоқ па?
Мен күмәнданамын. Менің ойымша, бұл одан да қайғылы болады, өйткені сандарды талдау күрделі мәселе. Менің ойымша, бұл әріптес тіпті он мыңдық түрінде сандарды талдау қаншалықты қиын екендігі туралы есеп берді, бірақ мүмкін емес.
Алексей, баяндама үшін көп рахмет! ClickHouse үшін көп рахмет! Менің жоспарлар туралы сұрағым бар. Сөздіктерді толық емес жаңарту мүмкіндігінің жоспарлары бар ма?
Яғни, ішінара қайта жүктеу?
Иә Иә. Онда MySQL өрісін орнату мүмкіндігі сияқты, яғни сөздік өте үлкен болса, тек осы деректер жүктелетіндей кейін жаңарту.
Өте қызықты функция. Менің ойымша, оны біздің чатта біреу ұсынды. Мүмкін бұл тіпті сен де болған шығарсың.
Мен солай ойламаймын.
Керемет, енді екі өтініш бар екен. Ал сіз оны біртіндеп жасай бастай аласыз. Бірақ бұл мүмкіндікті іске асыру өте қарапайым екенін бірден ескерткім келеді. Яғни, теориялық түрде кестеге нұсқа нөмірін жазып, содан кейін мынаны жазу керек: нұсқа мұндай және осындайдан аз. Бұл, ең алдымен, біз энтузиастарға ұсынамыз дегенді білдіреді. Сіз энтузиастсыз ба?
Иә, бірақ, өкінішке орай, C++ тілінде емес.
Сіздің әріптестеріңіз C++ тілінде жазуды біледі ме?
Мен біреуді табамын.
Тамаша*.
* функция есептен екі айдан кейін қосылды - сұрақтың авторы оны әзірлеп, оны жіберді .
рахмет!
Сәлеметсіз бе! Есеп үшін рахмет! Сіз ClickHouse оған қол жетімді барлық ресурстарды тұтынуда өте жақсы екенін айттыңыз. Ал Luxoft жанындағы спикер Ресей поштасы үшін өзінің шешімі туралы айтты. Ол ClickHouse-ны қатты ұнататынын айтты, бірақ олар оны негізгі бәсекелесінің орнына пайдаланбады, өйткені ол барлық процессорды жеп қойды. Және олар оны архитектурасына, докерлері бар ZooKeeper-ге қоса алмады. ClickHouse-ды қандай да бір жолмен шектеуге болады, сонда ол оған қол жетімді болатынның бәрін тұтынбайды?
Иә, бұл мүмкін және өте оңай. Егер сіз өзектерді азырақ тұтынғыңыз келсе, жай ғана жазыңыз set max_threads = 1. Міне, ол сұранысты бір ядрода орындайды. Сонымен қатар, сіз әртүрлі пайдаланушылар үшін әртүрлі параметрлерді көрсете аласыз. Сондықтан проблема жоқ. Luxoft-тағы әріптестеріңізге бұл параметрді құжаттамадан таппағаны жақсы емес екенін айтыңыз.
Алексей, сәлем! Мен осы сұрақ бойынша сұрағым келеді. Көптеген адамдар ClickHouse қолданбасын журналдар қоймасы ретінде пайдалана бастағанын бірінші рет естіп отырған жоқпын. Есепте сіз мұны жасамауды айттыңыз, яғни ұзын жолдарды сақтаудың қажеті жоқ. Бұл туралы не ойлайсыз?
Біріншіден, журналдар, әдетте, ұзын жолдар емес. Әрине, ерекше жағдайлар бар. Мысалы, java тілінде жазылған кейбір қызмет ерекше жағдайды шығарады, ол журналға жазылады. Шексіз циклде және қатты дискідегі бос орын таусылады. Шешім өте қарапайым. Егер сызықтар өте ұзын болса, оларды кесіңіз. Ұзақ деген нені білдіреді? Ондаған килобайт нашар*.
* ClickHouse соңғы нұсқаларында «бейімделетін индекс түйіршіктері» қосылған, бұл көп жағдайда ұзын жолдарды сақтау мәселесін жояды.
Килобайт қалыпты ма?
Бұл қалыпты жағдай.
Сәлеметсіз бе! Есеп үшін рахмет! Мен бұл туралы чатта сұрадым, бірақ жауап алғаным есімде жоқ. WITH бөлімін CTE үлгісінде кеңейту жоспарлары бар ма?
Әзірше емес. Біздің WITH бөліміміз біршама жеңіл. Бұл біз үшін кішкене мүмкіндік сияқты.
Мен түсіндім. Рақмет сізге!
Есеп үшін рахмет! Өте қызық! Ғаламдық сұрақ. Деректерді жоюды өзгерту жоспарлары бар ма?
Міндетті түрде. Бұл біздің кезектегі бірінші тапсырмамыз. Біз қазір бәрін қалай дұрыс жасау керектігін белсенді түрде ойластырып жатырмыз. Ал пернетақтаны* басуды бастау керек.
* пернетақтадағы түймелерді басып, бәрін жасады.
Бұл жүйенің жұмысына қандай да бір түрде әсер ете ме, жоқ па? Енгізу қазіргідей жылдам бола ма?
Мүмкін жоюлардың өзі және жаңартулардың өзі өте ауыр болуы мүмкін, бірақ бұл таңдаулардың өнімділігіне немесе кірістірулердің өнімділігіне әсер етпейді.
Және тағы бір шағын сұрақ. Тұсаукесерде сіз бастапқы кілт туралы айттыңыз. Тиісінше, бізде әдепкі бойынша ай сайынғы бөлу бар, дұрыс па? Біз бір айға сәйкес күндер ауқымын орнатқанда, тек осы бөлім оқылады, солай емес пе?
Иә.
Сұрақ. Егер біз қандай да бір бастапқы кілтті таңдай алмасақ, оны «Күн» өрісіне сәйкес орындау дұрыс па, сонда бұл деректердің фондық режимде реттелген түрде орналасуы үшін қайта реттелуі аз болады ма? Егер сізде ауқым сұраулары болмаса және кез келген негізгі кілтті таңдай алмасаңыз, негізгі кілтке күнді қою керек пе?
Иә.
Бастапқы кілтке деректерді осы өріс бойынша сұрыптаған жағдайда жақсырақ қысатын өрісті қоюдың мағынасы бар шығар. Мысалы, пайдаланушы идентификаторы. Пайдаланушы, мысалы, бір сайтқа кіреді. Бұл жағдайда пайдаланушы идентификаторы мен уақытын қойыңыз. Содан кейін деректеріңіз жақсырақ қысылады. Күнге келетін болсақ, егер сізде күндер бойынша ауқым сұраулары шынымен болмаса және ешқашан болмаса, күнді негізгі кілтке қоюдың қажеті жоқ.
Жарайды көп рахмет!
Ақпарат көзі: www.habr.com