Сәуір айында Avito инженерлері ClickHouse негізгі әзірлеушісі Алексей Миловидовпен және Integros компаниясының Голанг әзірлеушісі Кирилл Шваковпен онлайн кездесулерге жиналды. Біз дерекқорды басқару жүйесін қалай қолданатынымызды және қандай қиындықтарға тап болатынымызды талқыладық.
Кездесу негізінде біз сақтық көшірме жасау, деректерді қайта бөлу, сыртқы сөздіктер, Golang драйвері және ClickHouse нұсқаларын жаңарту туралы біздің және аудиторияның сұрақтарына сарапшылардың жауаптары бар мақала жасадық. Бұл Яндекс ДҚБЖ-мен белсенді жұмыс істеп жатқан және оның бүгіні мен болашағына қызығушылық танытатын әзірлеушілерге пайдалы болуы мүмкін. Әдепкі бойынша, жауаптар Алексей Миловидовтікі, егер басқаша жазылмаса.
Абайлаңыз, кесіндінің астында көп мәтін бар. Сұрақтары бар мазмұн сізге шарлауға көмектеседі деп үміттенеміз.
Мазмұны
Мәтінді оқығыңыз келмесе, жиналыстардың жазбасын көруге болады . Уақыт кодтары бейне астындағы бірінші түсініктемеде.
ClickHouse үнемі жаңартылып отырады, бірақ біздің деректеріміз жоқ. Бұл туралы не істеу керек?
ClickHouse үнемі жаңартылып отырады және соңғы өңделген оңтайландырылған деректеріміз жаңартылмайды және сақтық көшірмеде.
Бізде ақаулық болды және деректер жоғалды делік. Біз қалпына келтіруді шештік және сақтық көшірме серверлерінде сақталатын ескі бөлімдер ClickHouse қолданбасының қазіргі қолданылып жүрген нұсқасынан өте ерекшеленетіні белгілі болды. Мұндай жағдайда не істеу керек және бұл мүмкін бе?
Ескі пішімдегі сақтық көшірмеден деректерді қалпына келтірген, бірақ ол жаңа нұсқаға қосылмаған жағдай мүмкін емес. ClickHouse бағдарламасындағы деректер пішімі әрқашан кері үйлесімді болып қалатынына көз жеткіземіз. Кейбір сирек қолданылатын функцияның әрекеті өзгерсе, бұл функционалдықтағы кері үйлесімділікке қарағанда әлдеқайда маңызды. ClickHouse жаңа нұсқасы әрқашан дискіде сақталған деректерді оқи алуы керек. Бұл заң.
ClickHouse қолданбасынан деректердің сақтық көшірмесін жасаудың қазіргі ең жақсы тәжірибелері қандай?
Бізде соңғы операцияларды оңтайландыру, терабайттардың үлкен дерекқоры және соңғы үш күнде жаңартылатын деректер бар екенін ескере отырып, сақтық көшірмелерді қалай жасауға болады, содан кейін олармен ешқандай процедуралар болмайды?
Біз өз шешімімізді жасай аламыз және bash-қа жаза аламыз: бұл сақтық көшірмелерді осылай және осылай жинаңыз. Мүмкін, ештеңені балдақтаудың қажеті жоқ, ал велосипед баяғыда ойлап табылған шығар?
Ең жақсы тәжірибелерден бастайық. Менің әріптестерім сақтық көшірме жасау туралы сұрақтарға жауап ретінде әрқашан бұл мәселе шешілген Yandex.Cloud қызметі туралы еске салуға кеңес береді. Сондықтан мүмкіндігінше пайдаланыңыз.
Сақтық көшірмелердің толық шешімі жоқ, ClickHouse ішіне жүз пайыз кіріктірілген. Қолдануға болатын бос орындар бар. Толық шешімді алу үшін сізге қолмен аздап өңдеу керек немесе сценарийлер түрінде қаптамалар жасау керек.
Мен ең қарапайым шешімдерден бастаймын және деректер көлемі мен кластердің өлшеміне байланысты ең күрделілерімен аяқтаймын. Кластер неғұрлым үлкен болса, шешім соғұрлым күрделі болады.
Деректер бар кесте тек бірнеше гигабайтты алып жатса, сақтық көшірмені келесідей жасауға болады:
- Кесте анықтамасын сақтау, яғни метадеректер − жасау кестесін көрсету.
- ClickHouse клиентін пайдаланып демп жасаңыз - таңдау * үстелден файлға. Әдепкі бойынша сіз TabSeparated пішіміндегі файлды аласыз. Егер сіз тиімдірек болғыңыз келсе, оны Native пішімінде орындауға болады.
Егер деректер көлемі үлкенірек болса, сақтық көшірме жасау көп уақыт пен көп орын алады. Бұл логикалық сақтық көшірме деп аталады; ол ClickHouse деректер пішіміне байланысты емес. Егер солай болса, соңғы шара ретінде сақтық көшірме жасап, оны қалпына келтіру үшін MySQL жүйесіне жүктеп салуға болады.
Неғұрлым жетілдірілген жағдайлар үшін ClickHouse қолданбасында жергілікті файлдық жүйеде бөлімдердің суретін жасаудың кірістірілген мүмкіндігі бар. Бұл мүмкіндік сұрау ретінде қол жетімді кестені мұздату бөлімін өзгерту. Немесе жай кестенің қатып қалуын өзгерту - бұл бүкіл кестенің суреті.
Сурет бір үзіндідегі бір кесте үшін дәйекті түрде жасалады, яғни бұл жолмен бүкіл кластердің дәйекті суретін жасау мүмкін емес. Бірақ көптеген тапсырмалар үшін мұндай қажеттілік жоқ және әрбір үзіндіге сұранысты орындау және дәйекті суретті алу жеткілікті. Ол қатты сілтемелер түрінде жасалған, сондықтан қосымша орын алмайды. Содан кейін сіз бұл суретті сақтық көшірме серверіне немесе сақтық көшірме жасау үшін пайдаланатын жадқа көшіресіз.
Мұндай сақтық көшірмені қалпына келтіру өте оңай. Біріншіден, бар кесте анықтамаларын пайдаланып кестелер жасаңыз. Одан кейін бөлімдердің сақталған суреттерін осы кестелер үшін Каталогтан бөлінгенге көшіріп, сұрауды іске қосыңыз. бөлімді бекітіңіз. Бұл шешім деректердің ең маңызды көлеміне өте қолайлы.
Кейде сізге одан да салқын нәрсе қажет - әрбір серверде ондаған, тіпті жүздеген терабайттар және жүздеген серверлер болған жағдайда. Мұнда Яндекс.Метрикадағы әріптестерімнен алған шешім бар. Мен оны барлығына ұсынбаймын - оны оқып шығыңыз және ол қолайлы ма, жоқ па, өзіңіз шешіңіз.
Алдымен үлкен дискілік сөрелері бар бірнеше серверлерді жасау керек. Әрі қарай, осы серверлерде бірнеше ClickHouse серверлерін көтеріп, оларды бірдей үзінділер үшін басқа көшірме ретінде жұмыс істейтіндей етіп конфигурациялаңыз. Содан кейін осы серверлерде суретті жасауға мүмкіндік беретін файлдық жүйені немесе кейбір құралды пайдаланыңыз. Мұнда екі нұсқа бар. Бірінші опция - LVM суреттері, екінші опция - Linux жүйесіндегі ZFS.
Осыдан кейін күн сайын суретті жасау керек, ол өтірік және біраз орын алады. Әрине, деректер өзгерсе, уақыт өте келе кеңістік көлемі артады. Бұл суретті кез келген уақытта алып тастауға болады және деректерді қалпына келтіруге болады, бұл таңқаларлық шешім. Сонымен қатар, біз конфигурацияда осы көшірмелерді көшбасшы болуға тырыспау үшін шектеуіміз керек.
Біліктерде репликалардың бақыланатын артта қалуын ұйымдастыру мүмкін бе?
Биыл сіз ClickHouse-да білік жасауды жоспарлап отырсыз. Оларда репликалардың бақыланатын артта қалуын ұйымдастыру мүмкін бе? Біз оны өзгертулер мен басқа өзгерістермен өзімізді теріс сценарийлерден қорғау үшін пайдаланғымыз келеді.
Өзгертулер үшін кері айналдырудың қандай да бір түрін жасауға болады ма? Мысалы, бар білікке қабылдап, осы уақытқа дейін өзгертулерді қолданатыныңызды айтыңыз және осы сәттен бастап өзгертулерді қолдануды тоқтатыңыз ба?
Егер біздің кластерге команда келіп, оны бұзса, онда бізде бір сағаттық кешігуі бар шартты көшірме бар, оны қазір қолданайық деп айта аламыз, бірақ соңғы он минутта оған өзгертулер қолданбаймыз ба?
Біріншіден, репликалардың бақыланатын лагы туралы. Пайдаланушылардан осындай сұраныс болды және біз Github-та: «Егер бұл біреуге қажет болса, лайк басып, жүрекке қойыңыз» деген сұраныспен шығарылым жасадық. Ешкім жеткізбеді, мәселе жабылды. Дегенмен, бұл мүмкіндікті ClickHouse орнату арқылы алуға болады. Рас, тек 20.3 нұсқасынан бастап.
ClickHouse үнемі фондық режимде деректерді біріктіруді орындайды. Біріктіру аяқталған кезде деректер бөліктерінің белгілі бір жинағы үлкенірек бөлікке ауыстырылады. Сонымен бірге бұрын болған деректер бөліктері дискіде біраз уақыт сақталады.
Біріншіден, бұғаттамайтын әрекетті қамтамасыз ету үшін оларды пайдаланатын таңдаулы сұраулар болғанша олар сақталады. Таңдалған сұраулар ескі бөліктерден оңай оқылады.
Екіншіден, уақыт шегі де бар - деректердің ескі бөліктері дискіде сегіз минутқа жатады. Бұл сегіз минутты теңшеуге және тіпті бір күнге айналдыруға болады. Бұл дискілік кеңістікті қажет етеді: деректер ағынына байланысты, соңғы күні деректер екі еселеніп қана қоймай, бес есе көп болуы мүмкін. Бірақ маңызды мәселе болса, ClickHouse серверін тоқтатып, барлығын сұрыптауға болады.
Енді бұл өзгерістерден қалай қорғайды деген сұрақ туындайды. Мұнда тереңірек қарастырған жөн, өйткені ClickHouse ескі нұсқаларында өзгертулер бөлшектерді тікелей өзгертетіндей жұмыс істеді. Кейбір файлдары бар деректер бөлігі бар және біз, мысалы: тастау бағанын өзгерту. Содан кейін бұл баған барлық бөліктерден физикалық түрде жойылады.
Бірақ 20.3 нұсқасынан бастап өзгерту механизмі толығымен өзгертілді, енді деректер бөліктері әрқашан өзгермейді. Олар мүлде өзгермейді - өзгертулер енді біріктіру сияқты жұмыс істейді. Бір бөлікті орнында ауыстырудың орнына, біз жаңасын жасаймыз. Жаңа бөлікте өзгермеген файлдар қатты сілтемелерге айналады, ал егер біз бағанды жойсақ, ол жай ғана жаңа бөлікте жоқ болады. Ескі бөлік әдепкі бойынша сегіз минуттан кейін жойылады және мұнда жоғарыда аталған параметрлерді өзгертуге болады.
Бұл мутация сияқты өзгерістерге де қатысты. Сіз жасаған кезде өзгерту жою немесе жаңартуды өзгерту, ол бөлікті өзгертпейді, бірақ жаңасын жасайды. Содан кейін ескісін жояды.
Кесте құрылымы өзгерсе ше?
Ескі схемамен жасалған сақтық көшірмені қалай қалпына келтіруге болады? Ал екінші сұрақ сурет және файлдық жүйе құралдары бар іс туралы. Linux LVM жүйесіндегі ZFS орнына Btrfs жақсы ма?
Егер сіз бөлімді бекітіңіз басқа құрылымы бар бөлімдерді таңдасаңыз, ClickHouse сізге бұл мүмкін емес екенін айтады. Бұл шешім. Біріншісі - ескі құрылыммен MergeTree түріндегі уақытша кестені жасау, онда тіркеме арқылы деректерді тіркеу және өзгерту сұрауын жасау. Содан кейін бұл деректерді көшіруге немесе тасымалдауға және қайта тіркеуге немесе сұрауды пайдалануға болады кестені жылжыту бөлімін өзгерту.
Енді екінші сұрақ - Btrfs қолдануға бола ма? Бастау үшін, егер сізде LVM болса, LVM суреттері жеткілікті және файлдық жүйе ext4 болуы мүмкін, бұл маңызды емес. Btrts көмегімен бәрі оны пайдалану тәжірибеңізге байланысты. Бұл жетілген файлдық жүйе, бірақ белгілі бір сценарийде бәрі іс жүзінде қалай болатыны туралы кейбір күдіктер әлі де бар. Өндірісте Btrfs болмаса, оны пайдалануды ұсынбаймын.
Деректерді қайта бөлудегі қазіргі ең жақсы тәжірибелер қандай?
Қайта бөлу мәселесі күрделі және көп қырлы. Мұнда бірнеше ықтимал жауаптар бар. Сіз бір жағынан өтіп, мынаны айта аласыз - ClickHouse-да кірістірілген қайта бөлу мүмкіндігі жоқ. Бірақ бұл жауап ешкімге ұнамайды деп қорқамын. Сондықтан, сіз екінші жағынан өтіп, ClickHouse-да деректерді қайта бөлудің көптеген жолдары бар деп айта аласыз.
Кластерде бос орын бітсе немесе ол жүктемені көтере алмаса, сіз жаңа серверлерді қосасыз. Бірақ бұл серверлер әдепкі бойынша бос, оларда деректер жоқ, жүктеме жоқ. Деректерді жаңа, үлкенірек кластерге біркелкі таралатындай етіп қайта реттеу керек.
Мұны істеудің бірінші жолы - сұрау арқылы бөлімдердің бір бөлігін жаңа серверлерге көшіру кестені алу бөлімін өзгерту. Мысалы, сізде айлар бойынша бөлімдер болды және сіз 2017 жылдың бірінші айын алып, оны жаңа серверге көшіріңіз, содан кейін үшінші айды басқа жаңа серверге көшіріңіз. Сіз мұны біркелкі болғанша жасайсыз.
Тасымалдау тек жазу кезінде өзгермейтін бөлімдер үшін ғана жүзеге асырылуы мүмкін. Жаңа бөлімдер үшін жазуды өшіру керек, өйткені олардың тасымалдануы атомдық емес. Әйтпесе, деректердің көшірмелері немесе олқылықтары болады. Дегенмен, бұл әдіс практикалық және өте тиімді жұмыс істейді. Дайын қысылған бөлімдер желі арқылы беріледі, яғни деректер қысылмайды немесе қайта кодталмайды.
Бұл әдістің бір кемшілігі бар және ол бөлу схемасына, осы бөлу схемасына кепілдік бергеніңізге, сізде қандай бөлу кілті бар екеніне байланысты. Метрикалары бар жағдайға арналған мысалда бөлу кілті жолдың хэші болып табылады. Бөлінген кестені таңдаған кезде, ол кластердегі барлық бөліктерге бірден өтеді және деректерді сол жерден алады.
Бұл дегеніміз, қандай деректердің қай бөлікте аяқталғаны сізге маңызды емес. Ең бастысы, бір жол бойындағы деректер бір үзіндіде аяқталады, бірақ қайсысы маңызды емес. Бұл жағдайда дайын бөлімдерді тасымалдау өте жақсы, өйткені таңдаулы сұраулар арқылы сіз толық деректерді аласыз - қайта бөлуге дейін немесе кейін, схема маңызды емес.
Бірақ одан да күрделі жағдайлар бар. Қолданбаның логикалық деңгейінде сіз арнайы бөлу схемасына сүйенсеңіз, бұл клиент осындай және осындай үзіндіде орналасқан және сұрауды Бөлінген кестеге емес, тікелей сол жерге жіберуге болады. Немесе ClickHouse бағдарламасының өте соңғы нұсқасын пайдаланып жатырсыз және параметрді қостыңыз пайдаланылмайтын үзінділерді өткізіп жіберуді оңтайландыру. Бұл жағдайда таңдау сұрауы кезінде қайда бөліміндегі өрнек талданады және бөлшектеу схемасына сәйкес қандай үзінділерді пайдалану керектігі есептелетін болады. Бұл деректер дәл осы бөлу схемасына сәйкес бөлінген жағдайда жұмыс істейді. Егер сіз оларды қолмен қайта реттесеңіз, сәйкестік өзгеруі мүмкін.
Сондықтан бұл бірінші әдіс. Мен сізден жауап күтемін, әдіс қолайлы ма, әлде ары қарай жалғастырайық.
Владимир Колобаев, Авитодағы жетекші жүйелік әкімші: Алексей, сіз айтқан әдіс жүктемені, соның ішінде оқуды тарату қажет болғанда жақсы жұмыс істемейді. Біз ай сайынғы бөлімді ала аламыз және алдыңғы айды басқа түйінге апара аламыз, бірақ бұл деректерге сұраныс келгенде, біз оны тек жүктейміз. Бірақ біз бүкіл кластерді жүктегіміз келеді, өйткені әйтпесе біраз уақыт бойы барлық оқу жүктемесі екі сынықпен өңделеді.
Алексей Миловидов: Жауап біртүрлі - иә, бұл жаман, бірақ ол жұмыс істеуі мүмкін. Мен дәл қалай түсіндіремін. Деректеріңіздің артында келетін жүктеу сценарийін қарастырған жөн. Егер бұл мониторинг деректері болса, онда сұраулардың басым көпшілігі жаңа деректерге арналған деп айта аламыз.
Сіз жаңа серверлерді орнаттыңыз, ескі бөлімдерді тасымалдадыңыз, сонымен қатар жаңа деректердің жазылу жолын өзгерттіңіз. Ал жаңа деректер кластерге таралады. Осылайша, бес минуттан кейін соңғы бес минуттағы сұраулар кластерді біркелкі жүктейді; бір күннен кейін XNUMX сағаттық сұраулар кластерді біркелкі жүктейді. Ал өткен айдағы сұраулар, өкінішке орай, кластерлік серверлердің бір бөлігіне ғана түседі.
Бірақ көбінесе сізде 2019 жылдың ақпан айына арналған сұраулар болмайды. Сірә, егер сұраулар 2019 жылға енсе, онда олар бүкіл 2019 жылға арналған болады - кейбір шағын диапазон үшін емес, үлкен уақыт кезеңі. Және мұндай сұраулар кластерді біркелкі жүктей алады. Бірақ тұтастай алғанда, бұл деректерді толығымен біркелкі таратпайтын арнайы шешім екендігі туралы сіздің ескертуіңіз өте дұрыс.
Сұраққа жауап беретін тағы бірнеше ұпайым бар. Олардың бірі бастапқыда бөлшектеу схемасын қалай жасау керек, осылайша қайта бөлу ауырсынуды азайтады. Бұл әрқашан мүмкін емес.
Мысалы, сізде бақылау деректері бар. Бақылау деректері үш себепке байланысты өсуде. Біріншісі – тарихи деректердің жинақталуы. Екіншісі – трафиктің өсуі. Ал үшінші – мониторингке жататын нәрселердің көбеюі. Сақтау қажет жаңа микросервистер мен көрсеткіштер бар.
Мүмкін, олардың ішінде ең үлкен өсім үшінші себеппен - мониторингті қолданудың артуымен байланысты болуы мүмкін. Және бұл жағдайда жүктеменің сипатын, негізгі таңдау сұраулары қандай екенін қарастырған жөн. Негізгі таңдау сұраулары көрсеткіштердің кейбір ішкі жиынына негізделуі мүмкін.
Мысалы, кейбір қызметтердің кейбір серверлерде CPU пайдалануы. Бұл деректерді алатын кілттердің белгілі бір жиынтығы бар екені белгілі болды. Және бұл деректерге сұраныстың өзі өте қарапайым және ондаған миллисекундта аяқталады. Бақылау қызметтері мен бақылау тақталары үшін пайдаланылады. Мен мұны дұрыс түсінемін деп үміттенемін.
Владимир Колобаев: Шындығында, біз тарихи деректерге жиі жүгінеміз, өйткені біз қазіргі жағдайды нақты уақыттағы тарихи жағдаймен салыстырамыз. Біз үшін деректердің үлкен көлеміне жылдам қол жеткізу маңызды және ClickHouse мұнымен тамаша жұмыс істейді.
Сіз өте дұрыс айтасыз, біз кез келген бақылау жүйесі сияқты оқу сұрауларының көпшілігін соңғы күнде бастан кешіреміз. Бірақ сонымен бірге тарихи деректерге түсетін жүктеме де айтарлықтай үлкен. Бұл негізінен әр отыз секунд сайын айналып өтетін және ClickHouse-қа айтатын ескерту жүйесінен: «Маған соңғы алты аптадағы деректерді беріңіз. Енді маған олардан қандай да бір жылжымалы орташа мәнді құрастырыңыз және қазіргі мәнді тарихи мәнмен салыстырайық ».
Осындай соңғы сұраулар үшін бізде тек екі күндік деректерді сақтайтын тағы бір шағын кесте бар екенін айтқым келеді және негізгі сұраулар оған түседі. Біз тек үлкен тарихи сұрауларды үлкен кесілген кестеге жібереміз.
Алексей Миловидов: Өкінішке орай, бұл сіздің сценарийіңіз үшін нашар қолданылады, бірақ мен сізге пайдаланудың қажеті жоқ, бірақ достарымның қызметінде қолданылатын екі нашар және күрделі бөлу схемасының сипаттамасын айтып беремін.
Yandex.Metrica оқиғалары бар негізгі кластер бар. Оқиғалар - бет көріністері, басулар және түрлендірулер. Көптеген сұраулар белгілі бір веб-сайтқа түседі. Сіз Yandex.Metrica қызметін ашасыз, сізде веб-сайт бар - avito.ru, есепке өтіңіз және сіздің веб-сайтыңызға сұраныс жасалады.
Бірақ ішкі талдаушылар жасайтын басқа да сұраулар бар - аналитикалық және жаһандық. Қалай болғанда да, ішкі талдаушылар тек Яндекс қызметтеріне сұраныс жасайтынын ескертемін. Дегенмен, тіпті Яндекс қызметтері барлық деректердің айтарлықтай бөлігін алады. Бұл арнайы есептегіштерге емес, кеңірек сүзгілеуге арналған сұраулар.
Барлығы бір есептегіш және жаһандық сұраулар үшін тиімді жұмыс істейтіндей деректерді қалай ұйымдастыруға болады? Тағы бір қиындық, Metrics кластеріне арналған ClickHouse бағдарламасындағы сұраулар саны секундына бірнеше мыңды құрайды. Бұл ретте бір ClickHouse сервері тривиальды емес сұрауларды өңдей алмайды, мысалы, секундына бірнеше мың.
Кластердің өлшемі - алты жүзге жуық сервер. Егер сіз жай ғана осы кластердің үстінен Бөлінген кестені тартып, сол жерге бірнеше мың сұрау жіберсеңіз, бұл оларды бір серверге жіберуден де нашар болады. Екінші жағынан, деректер біркелкі таралады және біз барамыз және барлық серверлерден сұраймыз деген опция бірден қабылданбайды.
Диаметральді қарама-қарсы опция бар. Елестетіп көріңізші, біз деректерді сайттар арасында бөлеміз және бір сайтқа сұрау бір бөлікке жіберіледі. Енді кластер секундына он мың сұрауды өңдей алады, бірақ бір бөлікте кез келген бір сұрау тым баяу жұмыс істейді. Ол бұдан былай өткізу қабілеті бойынша масштабталмайды. Әсіресе бұл avito.ru сайты болса. Avito – RuNet-те ең көп кіретін сайттардың бірі десем, құпияны ашпаймын. Ал оны бір сынықта өңдеу ақылсыздық болар еді.
Сондықтан, кесу схемасы әлдеқайда айлакер түрде жасалған. Бүкіл кластер бірнеше кластерлерге бөлінеді, оларды біз қабаттар деп атаймыз. Әрбір кластерде оннан бірнеше ондаған сынықтар бар. Барлығы отыз тоғыз осындай кластер бар.
Мұның бәрі қалай масштабталады? Кластерлердің саны өзгермейді – бірнеше жыл бұрын отыз тоғыз болса, сол күйінде қалды. Бірақ олардың әрқайсысында біз деректерді жинақтаған сайын үзінділер санын біртіндеп көбейтеміз. Жалпы бөлу схемасы келесідей: бұл кластерлер веб-сайттарға бөлінген және қай веб-сайт қай кластерде екенін түсіну үшін MySQL-де бөлек метабаза қолданылады. Бір сайт – бір кластерде. Оның ішінде келушінің идентификаторларына сәйкес бөлшектеу орын алады.
Жазу кезінде біз оларды келушінің идентификаторының бөлінуінің қалған бөлігіне бөлеміз. Бірақ жаңа бөлікті қосқанда, бөлу схемасы өзгереді; біз бөлуді жалғастырамыз, бірақ бөлінудің қалған бөлігімен басқа санмен. Бұл бір келушінің әлдеқашан бірнеше серверлерде орналасқанын білдіреді және сіз бұған сене алмайсыз. Бұл деректердің жақсырақ қысылуын қамтамасыз ету үшін ғана жасалады. Ал сұраныстарды жасау кезінде біз кластерге қарайтын және ондаған серверлерге қатынасатын Бөлінген кестеге өтеміз. Бұл сондай ақымақ схема.
Бірақ бұл схемадан бас тарттык деп айтпасам, менің әңгімем толық болмайды. Жаңа схемада біз бәрін өзгерттік және барлық деректерді clickhouse-copier көмегімен көшірдік.
Жаңа схемада барлық сайттар екі санатқа бөлінеді - үлкен және кіші. Мен шекті мәннің қалай таңдалғанын білмеймін, бірақ нәтижесінде үлкен сайттар бір кластерде жазылған, мұнда әрқайсысы үш репликасы бар 120 үзінді бар, яғни 360 сервер. Ал бөлу схемасы кез келген сұрау бірден барлық сынықтарға өтетіндей. Егер сіз қазір Yandex.Metrica сайтында avito.ru үшін кез келген есеп бетін ашсаңыз, сұрау 120 серверге өтеді. RuNet-те бірнеше үлкен сайттар бар. Ал сұраныс секундына мың емес, тіпті жүзден де аз. Мұның барлығын әрқайсысы 120 сервермен өңдейтін Бөлінген кесте тыныш шайнады.
Ал екінші кластер шағын сайттарға арналған. Міне, сайт идентификаторына негізделген бөлу схемасы және әрбір сұрау дәл бір үзіндіге өтеді.
ClickHouse бағдарламасында клик-көшіргіш утилитасы бар. Ол туралы айтып бере аласыз ба?
Мен бұл шешімнің қиынырақ және өнімділігі азырақ екенін бірден айтамын. Артықшылығы - ол сіз көрсеткен үлгіге сәйкес деректерді толығымен жағады. Бірақ утилитаның кемшілігі - ол мүлдем қайта өңделмейді. Ол деректерді бір кластер схемасынан басқа кластер схемасына көшіреді.
Бұл оның жұмыс істеуі үшін сізде екі кластер болуы керек дегенді білдіреді. Олар бір серверлерде орналасуы мүмкін, бірақ соған қарамастан деректер қадамдық түрде жылжытылмайды, бірақ көшіріледі.
Мысалы, төрт сервер болса, қазір сегізге жетті. Сіз барлық серверлерде жаңа Бөлінген кестені, жаңа жергілікті кестелерді жасайсыз және онда ол жерден оқуы керек жұмыс схемасын көрсете отырып, кликхаус-көшірме құралын іске қосасыз, жаңа бөлшектеу схемасын қабылдап, деректерді сол жерге тасымалдайсыз. Ал ескі серверлерде сізге қазіргіден бір жарым есе көп орын қажет болады, өйткені ескі деректер оларда қалуы керек, ал сол ескі деректердің жартысы олардың үстіне келеді. Егер сіз деректерді қайта бөлу керек және бос орын бар деп алдын ала ойласаңыз, онда бұл әдіс қолайлы.
Кликхаус-көшіргіш құрылғының ішінде қалай жұмыс істейді? Ол барлық жұмысты бір кестенің бір бөлігін бір бөлікте өңдеуге арналған тапсырмалар жинағына бөледі. Барлық осы тапсырмаларды параллель орындауға болады және клик-көшірме құралын әртүрлі машиналарда бірнеше данада іске қосуға болады, бірақ оның бір бөлім үшін жасайтыны кірістіру таңдаудан басқа ештеңе емес. Деректер оқылады, ашылады, қайта бөлінеді, содан кейін қайтадан қысылады, бір жерде жазылады және қайта сұрыпталады. Бұл қатаңырақ шешім.
Сізде қайта өңдеу деп аталатын пилоттық нәрсе болды. Оған не болды?
2017 жылы сізде қайта өңдеу деп аталатын пилоттық нәрсе болды. ClickHouse-да тіпті опция бар. Менің түсінуімше, ол көтерілмеді. Неліктен бұлай болғанын айта аласыз ба? Бұл өте өзекті сияқты.
Мәселе мынада, егер деректерді орнында қайта бөлу қажет болса, мұны атомдық түрде орындау үшін өте күрделі синхрондау қажет. Біз бұл синхрондау қалай жұмыс істейтінін қарастыра бастағанда, іргелі мәселелер бар екені белгілі болды. Және бұл іргелі мәселелер тек теориялық ғана емес, бірақ бірден іс жүзінде өзін өте қарапайым түсіндіруге болатын нәрсе түрінде көрсете бастады - ештеңе жұмыс істемейді.
Деректердің барлық бөліктерін баяу дискілерге жылжытпас бұрын біріктіру мүмкін бе?
Біріктіру контекстіндегі дискіні баяулату опциясы бар TTL туралы сұрақ. Барлық бөліктерді баяу дискілерге көшірмес бұрын оларды біріктірудің cron арқылы басқа жолы бар ма?
Сұрақтың жауабы - барлық бөліктерді тасымалдау алдында автоматты түрде бір-біріне жабыстыруға болады - жоқ. Менің ойымша, бұл қажет емес. Барлық бөліктерді бір бөлікке біріктірудің қажеті жоқ, бірақ олар баяу дискілерге автоматты түрде тасымалданатынына сеніңіз.
Бізде тасымалдау ережелерінің екі критерийі бар. Біріншісі толтырылғандай. Ағымдағы сақтау деңгейінде бос орынның белгілі бір пайызынан аз болса, біз бір бөлікті таңдап, оны баяуырақ сақтауға жылжытамыз. Дәлірек айтқанда, баяу емес, келесісі - сіз конфигурациялағандай.
Екінші критерий - өлшем. Бұл үлкен бөліктерді жылжыту туралы. Сіз табалдырықты жылдам дискідегі бос орынға сәйкес реттей аласыз және деректер автоматты түрде тасымалданады.
Үйлесімділікті алдын ала тексеруге мүмкіндік болмаса, ClickHouse бағдарламасының жаңа нұсқаларына қалай көшуге болады?
Бұл тақырып үнемі талқыланады әртүрлі нұсқаларды ескере отырып, және бәрібір. 19.11-ден 19.16-ға дейін және, мысалы, 19.16-дан 20.3-ке дейін жаңарту қаншалықты қауіпсіз. Құм жәшігіндегі үйлесімділікті алдын ала тексермей, жаңа нұсқаларға көшудің ең жақсы жолы қандай?
Мұнда бірнеше «алтын» ережелер бар. Бірінші - . Бұл үлкен, бірақ кері үйлесімсіз өзгерістер туралы бөлек параграфтар бар. Бұл нүктелерді қызыл жалау ретінде қабылдамаңыз. Бұл әдетте сіз пайдаланбайтын кейбір шеткі функционалдылықты қамтитын шамалы үйлесімсіздіктер.
Екіншіден, құм жәшігіндегі үйлесімділікті тексерудің ешқандай жолы болмаса және өндірісте дереу жаңартқыңыз келсе, мұны істеудің қажеті жоқ деген ұсыныс бар. Алдымен құм жәшігін жасап, сынақтан өткізіңіз. Егер сынақ ортасы болмаса, онда сізде өте үлкен компания жоқ болуы мүмкін, яғни кейбір деректерді ноутбукке көшіріп, онда бәрі дұрыс жұмыс істейтініне көз жеткізуге болады. Сіз тіпті құрылғыңызда жергілікті түрде бірнеше көшірмелерді жасай аласыз. Немесе жақын жерде жаңа нұсқаны алып, кейбір деректерді сол жерге жүктеп салуға болады, яғни импровизацияланған сынақ ортасын жасаңыз.
Тағы бір ереже - шығарылымдағы қателерді анықтауға және кейінгі жылдам түзетулерге байланысты нұсқаны шығарғаннан кейін бір апта бойы жаңартпау. Шатасып кетпеу үшін ClickHouse нұсқаларының нөмірленуін анықтайық.
20.3.4 нұсқасы бар. 20 саны шығарылған жылын көрсетеді - 2020. Ішіндегі нәрсе тұрғысынан бұл маңызды емес, сондықтан біз оған назар аудармаймыз. Келесі – 20.3. Біз екінші санды көбейтеміз - бұл жағдайда 3 - біз кейбір жаңа функционалдығы бар шығарылымды шығарған сайын. Егер біз ClickHouse-қа қандай да бір мүмкіндік қосқымыз келсе, бұл санды көбейтуіміз керек. Яғни, 20.4 ClickHouse нұсқасында одан да жақсы жұмыс істейді. Үшінші сан – 20.3.4. Мұнда 4 - біз жаңа мүмкіндіктерді қоспаған, бірақ кейбір қателерді түзететін патч шығарылымдарының саны. Ал 4 дегеніміз төрт рет орындадық.
Бұл қорқынышты нәрсе деп ойламаңыз. Әдетте пайдаланушы соңғы нұсқаны орната алады және ол жылына жұмыс уақытында еш қиындықсыз жұмыс істейді. Бірақ біздің қытайлық жолдастар қосқан нүктелік кескіндерді өңдеуге арналған кейбір функцияда қате дәлелдерді беру кезінде сервер бұзылып жатқанын елестетіп көріңіз. Біз мұны түзетуге міндеттіміз. Біз жаңа патч нұсқасын шығарамыз және ClickHouse тұрақтырақ болады.
Егер сізде ClickHouse өндірісте жұмыс істеп тұрса және ClickHouse бағдарламасының жаңа нұсқасы қосымша мүмкіндіктермен шықса - мысалы, 20.4.1 ең бірінші, оны бірінші күні өндіріске енгізуге асықпаңыз. Бұл тіпті не үшін қажет? Егер сіз ClickHouse қолданбасын пайдаланбасаңыз, оны орнатуға болады және бәрі жақсы болады. Бірақ ClickHouse қазірдің өзінде тұрақты жұмыс істеп тұрса, қандай ақауларды түзететінімізді көру үшін патчтар мен жаңартуларды қадағалаңыз.
Кирилл Шваков: Мен сынақ орталары туралы аздап қосқым келеді. Барлығы сынақ орталарынан қатты қорқады және қандай да бір себептермен олар сізде өте үлкен ClickHouse кластері болса, сынақ ортасы кем емес немесе кем дегенде он есе аз болуы керек деп санайды. Бұл мүлде олай емес.
Мен өз мысалымнан айта аламын. Менің жобам бар және ClickHouse бар. Біздің сынақ ортамыз тек оған арналған - бұл Хетцнердегі жиырма еуроға арналған шағын виртуалды машина, мұнда барлығы толығымен орналастырылған. Мұны істеу үшін бізде Ansible-де толық автоматтандыру бар, сондықтан, негізінен, қайда бару маңызды емес - аппараттық серверлерге немесе виртуалды машиналарда орналастыруға.
Не істеуге болады? ClickHouse құжаттамасында шағын кластерді өзіңіздің үйіңізде - Docker-те, LXC-де қалай орналастыруға болатыны туралы мысал келтірсеңіз жақсы болар еді, мүмкін Ansible ойын кітабын жасаңыз, себебі әртүрлі адамдар әртүрлі орналастыруға ие. Бұл көп нәрсені жеңілдетеді. Бес минут ішінде кластерді алып, орналастырғанда, бірдеңені анықтауға тырысу оңайырақ болады. Бұл әлдеқайда ыңғайлы, өйткені сіз сынақтан өтпеген өндірістік нұсқаға өту - ешқайда бармайтын жол. Кейде ол жұмыс істейді, кейде ол істемейді. Сондықтан сәттілікке үміттену жаман.
Максим Котяков, аға инженер Авито: Мен ірі компаниялар кездесетін бірқатар мәселелерден сынақ орталары туралы аздап қосамын. Бізде толыққанды ClickHouse қабылдау кластері бар; деректер схемалары мен параметрлері бойынша бұл өндірістегінің дәл көшірмесі. Бұл кластер ең аз ресурстары бар айтарлықтай жинақталған контейнерлерде орналастырылған. Біз онда өндіріс деректерінің белгілі бір пайызын жазамыз, бақытымызға орай, Кафкадағы ағынды қайталауға болады. Онда барлығы синхрондалған және масштабталған - сыйымдылық пен ағын тұрғысынан да, және теорияда, барлық басқа нәрселер тең болса, ол метрика тұрғысынан өндіріс сияқты әрекет етуі керек. Жарылғыш болуы мүмкін барлық нәрсе алдымен осы тұғырға оралып, дайын болғанша бірнеше күн қалдырылады. Бірақ, әрине, бұл шешім қымбат, қиын және нөлдік емес қолдау шығындары бар.
Алексей Миловидов: Мен сізге Yandex.Metrica-дағы достарымыздың сынақ ортасы қандай екенін айтып беремін. Бір кластерде 600 тақ сервер, екіншісінде 360, үшінші және бірнеше кластерлер бар. Олардың біреуіне арналған сынақ ортасы әрқайсысында екі репликасы бар екі үзінді болып табылады. Неліктен екі сынық? Жалғыз болмау үшін. Сондай-ақ көшірмелер болуы керек. Сіз көтере алатын белгілі бір ең төменгі сома.
Бұл сынақ ортасы сұрауларыңыздың жұмыс істеп тұрғанын және маңызды нәрсенің бұзылғанын тексеруге мүмкіндік береді. Бірақ жиі проблемалар мүлдем басқа сипатта туындайды, бәрі жұмыс істеген кезде, бірақ жүктемеде кейбір шағын өзгерістер болады.
Бір мысал келтірейін. Біз ClickHouse жаңа нұсқасын орнатуды шештік. Ол сынақ ортасына орналастырылды, Яндекс.Метриканың өзінде автоматтандырылған сынақтар аяқталды, олар ескі және жаңа нұсқадағы деректерді салыстырады, бүкіл құбырды жүргізеді. Және, әрине, біздің CI жасыл сынақтары. Әйтпесе бұл нұсқаны ұсынбас та едік.
Бәрі керемет. Біз өндіріске көшуді бастаймыз. Маған графиктердегі жүктеме бірнеше есе өскені туралы хабарлама келеді. Біз нұсқаны қайтарып жатырмыз. Мен графикке қарап, көремін: жүктеме іс жүзінде шығару кезінде бірнеше есе өсті және олар шығарылған кезде төмендеді. Содан кейін біз нұсқаны қайтара бастадық. Ал жүк сол қалпында көбейіп, қайта құлады. Сонымен, қорытынды: макетке байланысты жүктеме өсті, таңқаларлық ештеңе жоқ.
Содан кейін әріптестерді жаңа нұсқаны орнатуға сендіру қиын болды. Мен: «Жарайды, шығыңыз. Саусақтарыңызды айқастырыңыз, бәрі жұмыс істейді. Қазір графиктерге жүктеме артты, бірақ бәрі жақсы. Онда тұрыңыз». Тұтастай алғанда, біз мұны жасадық, және бұл - нұсқа өндіріске шығарылды. Бірақ әрбір орналасумен дерлік ұқсас мәселелер туындайды.
Өлтіру сұрауы сұрауларды жоюы керек, бірақ олай емес. Неліктен?
Пайдаланушы, қандай да бір талдаушы, маған келіп, менің ClickHouse кластерін орналастыратын сұрау жасады. Сұрау қай көшірмеге немесе үзіндіге барғанына байланысты кейбір түйін немесе тұтас кластер. Мен бұл сервердегі барлық процессор ресурстарының сөреде екенін көріп тұрмын, бәрі қызыл. Бұл ретте ClickHouse өзі сұраныстарға жауап береді. Мен жазамын: «Маған көрсетіңізші, тізімді өңдеңіз, бұл ақылсыздықты тудырған қандай сұраныс».
Мен бұл сұрауды тауып, оған kill жазамын. Ал мен ештеңе болмай тұрғанын көремін. Менің серверім сөреде, содан кейін ClickHouse маған бірнеше пәрмендер береді, сервердің тірі екенін және бәрі тамаша екенін көрсетеді. Бірақ менде барлық пайдаланушы сұрауларында деградация бар, деградация ClickHouse ішіндегі жазбалардан басталады және менің өлтіру сұрауым жұмыс істемейді. Неліктен? Мен өлтіру сұрауы сұрауларды жоюы керек деп ойладым, бірақ олай емес.
Енді біртүрлі жауап болады. Мәселе мынада, өлтіру сұрауы сұрауларды өлтірмейді.
Өлтірген сұрау «Мен бұл сұраудың жойылғанын қалаймын» деп аталатын кішкене ұяшықты тексереді. Ал сұраныстың өзі әрбір блокты өңдеу кезінде осы жалаушаға қарайды. Егер ол орнатылса, сұрау жұмысын тоқтатады. Өтінішті ешкім өлтірмейді, өзі бәрін тексеріп, тоқтатуы керек екен. Және бұл сұрау деректер блоктарын өңдеу күйінде болған барлық жағдайларда жұмыс істеуі керек. Ол келесі деректер блогын өңдейді, жалаушаны тексереді және тоқтайды.
Бұл сұрау кейбір операцияда блокталған жағдайларда жұмыс істемейді. Рас, бұл сіздің жағдайыңыз емес, өйткені сіздің пікіріңізше, ол көптеген сервер ресурстарын пайдаланады. Бұл сыртқы сұрыптау жағдайында және кейбір басқа бөлшектерде жұмыс істемеуі мүмкін. Бірақ жалпы алғанда бұл болмауы керек, бұл қате. Мен ұсынатын жалғыз нәрсе - ClickHouse-ды жаңарту.
Оқу жүктемесі кезінде жауап беру уақытын қалай есептеу керек?
Элементтердің агрегаттарын сақтайтын кесте бар - әртүрлі есептегіштер. Жолдар саны шамамен жүз миллионды құрайды. 1K элемент үшін 1K RPS құйсаңыз, болжамды жауап уақытына сенуге бола ма?
Мәтінмәнге сүйенсек, біз оқу жүктемесі туралы айтып отырмыз, өйткені жазуда ешқандай проблемалар жоқ - тіпті мың, тіпті жүз мың, кейде бірнеше миллион жолдарды енгізуге болады.
Оқу сұраныстары өте әртүрлі. 1-таңдауда ClickHouse секундына он мыңдаған сұрауларды орындай алады, сондықтан бір кілтке сұраулар әлдеқашан кейбір ресурстарды қажет етеді. Және мұндай нүктелік сұраулар кейбір кілт-мәндік деректер қорларына қарағанда қиынырақ болады, өйткені әрбір оқу үшін деректер блогын индекс бойынша оқу қажет. Біздің индекс әр жазбаға емес, әрбір диапазонға бағытталған. Яғни, сіз бүкіл ауқымды оқуыңыз керек - бұл әдепкі бойынша 8192 жол. Сіз қысылған деректер блогын 64 КБ-тан 1 Мбайтқа дейін ашуыңыз керек. Әдетте, мұндай мақсатты сұрауларды аяқтау үшін бірнеше миллисекунд қажет. Бірақ бұл ең қарапайым нұсқа.
Қарапайым арифметиканы қолданып көрейік. Бірнеше миллисекундты мыңға көбейтсеңіз, сіз бірнеше секунд аласыз. Секундына мыңдаған сұраныстарды орындау мүмкін емес сияқты, бірақ шын мәнінде бұл мүмкін, өйткені бізде бірнеше процессор ядролары бар. Осылайша, негізінен, ClickHouse кейде 1000 RPS-ті ұстай алады, бірақ қысқа сұраулар үшін, арнайы мақсатты.
Егер сізге ClickHouse кластерін қарапайым сұраулар саны бойынша масштабтау қажет болса, мен ең қарапайым нәрсені ұсынамын - көшірмелердің санын көбейтіп, сұрауларды кездейсоқ көшірмеге жіберіңіз. Егер бір репликада секундына бес жүз сұрау болса, бұл толығымен шынайы болса, онда үш реплика бір жарым мыңды өңдейді.
Кейде, әрине, сіз ClickHouse бағдарламасын нүктелік көрсеткіштердің максималды санына теңшей аласыз. Бұл үшін не керек? Біріншісі – индекстің түйіршіктілігін азайту. Бұл жағдайда оны біреуге дейін қысқартпау керек, бірақ индекстегі жазбалар саны серверге бірнеше миллион немесе ондаған миллион болады. Егер кестеде жүз миллион жол болса, онда түйіршіктілікті 64-ке орнатуға болады.
Қысылған блоктың өлшемін азайтуға болады. Бұл үшін параметрлер бар мин. қысу блогының өлшемі, максималды қысу блогының өлшемі. Оларды азайтуға, деректермен толтыруға болады, содан кейін мақсатты сұраулар жылдамырақ болады. Дегенмен, ClickHouse кілт-мәннің дерекқоры емес. Кішігірім сұраулардың үлкен саны жүктемеге қарсы үлгі болып табылады.
Кирилл Шваков: Онда қарапайым аккаунттар болған жағдайда кеңес беремін. Бұл ClickHouse есептегіштің қандай да бір түрін сақтаған кезде өте стандартты жағдай. Менің қолданушым бар, ол анау-мынау елден және үшінші саладан, мен бір нәрсені біртіндеп көбейтуім керек. MySQL-ті алыңыз, бірегей кілт жасаңыз - MySQL-де бұл қайталанатын кілт, ал PostgreSQL-де бұл қайшылық - және қосу белгісін қосыңыз. Бұл әлдеқайда жақсы жұмыс істейді.
Деректер көп болмаған кезде ClickHouse қолданбасын пайдаланудың қажеті жоқ. Тұрақты деректер базалары бар және олар мұны жақсы жасайды.
Кэште көбірек деректер болуы үшін ClickHouse бағдарламасында не реттей аламын?
Жағдайды елестетіп көрейік - серверлерде 256 ГБ оперативті жады бар, күнделікті режимде ClickHouse шамамен 60-80 ГБ алады, шыңында - 130-ға дейін. Кэште көбірек деректер болуы үшін нені қосуға және реттеуге болады және, тиісінше, дискіге сапарлар аз ба?
Әдетте, операциялық жүйенің бет кэші мұны жақсы орындайды. Егер сіз жай ғана үстіңгі жағын ашсаңыз, онда кэштелген немесе бос екенін қараңыз - ол сондай-ақ қанша кэштелгенін көрсетеді - онда барлық бос жад кэш үшін пайдаланылатынын байқайсыз. Ал бұл деректерді оқығанда ол дискіден емес, жедел жадтан оқылатын болады. Сонымен қатар, кэш тиімді пайдаланылады деп айта аламын, себебі ол кэштелген қысылған деректер.
Дегенмен, кейбір қарапайым сұрауларды одан да жылдамдатқыңыз келсе, ClickHouse ішіндегі қысылған деректерде кэшті қосуға болады. деп аталады қысылмаған кэш. config.xml конфигурация файлында қысылмаған кэш өлшемін қажетті мәнге орнатыңыз - мен бос жедел жадтың жартысынан артық емес ұсынамын, өйткені қалғаны бет кэшінің астында қалады.
Бұған қоса, сұрау деңгейінің екі параметрі бар. Бірінші параметр - қысылмаған кэшті пайдаланыңыз - оның қолданылуын қамтиды. Оны барлық деректерді оқи алатын және кэшті тазартатын ауыр сұраулардан басқа барлық сұраулар үшін қосу ұсынылады. Ал екінші параметр кэшті пайдалану үшін жолдардың максималды саны сияқты нәрсе. Ол кэшті айналып өту үшін үлкен сұрауларды автоматты түрде шектейді.
ЖЖҚ-да сақтау үшін storage_configuration параметрін қалай конфигурациялауға болады?
Жаңа ClickHouse құжаттамасында мен қатысты бөлімді оқыдым . Сипаттамада жылдам SSD үлгісі бар.
Мен бірдей нәрсені көлемді ыстық жадпен қалай конфигурациялауға болатынын білемін. Және тағы бір сұрақ. Таңдау бұл деректер ұйымымен қалай жұмыс істейді, ол бүкіл жиынды немесе тек дискідегіні оқиды ма және бұл деректер жадта қысылады ма? Ал Prewhere бөлімі мұндай деректер ұйымымен қалай жұмыс істейді?
Бұл параметр деректер бөліктерін сақтауға әсер етеді және олардың пішімі ешбір жолмен өзгермейді.
Толығырақ қарастырайық.
ЖЖҚ-да деректерді сақтауды конфигурациялауға болады. Диск үшін конфигурацияланғанның бәрі - оның жолы. Сіз файлдық жүйедегі кейбір жолға бекітілген tmpfs бөлімін жасайсыз. Сіз бұл жолды ең ыстық бөлім үшін деректерді сақтау жолы ретінде көрсетесіз, деректер бөліктері келіп, сонда жазыла бастайды, бәрі жақсы.
Бірақ мен мұны төмен сенімділікке байланысты ұсынбаймын, дегенмен әртүрлі деректер орталықтарында кем дегенде үш көшірме болса, бұл мүмкін. Егер бірдеңе болса, деректер қалпына келтіріледі. Сервер кенеттен өшіріліп, қайта қосылды деп елестетіп көрейік. Бөлім қайтадан орнатылды, бірақ онда ештеңе болмады. ClickHouse сервері іске қосылғанда, онда бұл бөліктер жоқ екенін көреді, дегенмен ZooKeeper метадеректеріне сәйкес олар сонда болуы керек. Ол қай көшірмелердің бар екенін қарап, оларды сұрайды және жүктейді. Осылайша деректер қалпына келтіріледі.
Бұл мағынада деректерді жедел жадта сақтау оны дискіде сақтаудан түбегейлі айырмашылығы жоқ, өйткені деректер дискіге жазылғанда, ол да алдымен бет кэшінде аяқталады және физикалық түрде кейінірек жазылады. Бұл файлдық жүйені орнату опциясына байланысты. Дегенмен, кірістіру кезінде ClickHouse синхрондалмайды деп айтамын.
Бұл жағдайда жедел жадтағы деректер дискідегідей пішімде сақталады. Таңдау сұрауы дәл осылай оқылатын бөліктерді таңдайды, бөліктердегі қажетті деректер ауқымдарын таңдайды және оларды оқиды. Prewhere деректердің жедел жадта немесе дискіде болғанына қарамастан, дәл солай жұмыс істейді.
Төмен кардиналдық бірегей мәндердің қанша санына дейін тиімді?
Төмен кардиналдық ақылды түрде жасалған. Ол деректер сөздіктерін құрастырады, бірақ олар жергілікті. Біріншіден, әр бөлім үшін әртүрлі сөздіктер бар, екіншіден, тіпті бір бөлімнің ішінде олар әр диапазон үшін әртүрлі болуы мүмкін. Бірегей мәндердің саны шекті санға жеткенде - бір миллион, менің ойымша, сөздік жай ғана сөреден өтіп, жаңасы жасалады.
Жауап жалпы: әрбір жергілікті диапазон үшін - айталық, әр күн үшін - бір жерде миллионға дейін бірегей мәндер Төмен кардиналдық тиімді. Одан кейін бір сөздік емес, көптеген әртүрлі сөздіктер қолданылатын қалпына келтіру болады. Ол кәдімгі жол бағанымен шамамен бірдей жұмыс істейді, мүмкін азырақ тиімдірек, бірақ өнімділіктің айтарлықтай нашарлауы болмайды.
Бес миллиард жолдан тұратын кестені толық мәтінді іздеудің ең жақсы тәжірибелері қандай?
Әртүрлі жауаптар бар. Біріншісі, ClickHouse толық мәтінді іздеу жүйесі емес екенін айту. Бұл үшін арнайы жүйелер бар, мысалы, и . Дегенмен, мен адамдардың Elasticsearch-тен ClickHouse-қа ауысатынын айтып жатқанын жиі көремін.
Неліктен бұл орын алады? Олар мұны Elasticsearch индекстерді құрудан бастап кейбір көлемдердегі жүктемені жеңуді тоқтататынымен түсіндіреді. Индекстер тым ауыр болады және егер сіз жай ғана деректерді ClickHouse-қа тасымалдасаңыз, олар көлем бойынша бірнеше есе тиімдірек сақталады. Сонымен қатар, іздеу сұраулары көбінесе морфологияны ескере отырып, деректердің бүкіл көлемінде қандай да бір фразаны табу қажет болған жоқ, бірақ мүлдем басқа. Мысалы, соңғы бірнеше сағаттағы журналдардағы байттардың кейбір тізбегін табыңыз.
Бұл жағдайда сіз ClickHouse ішінде индекс жасайсыз, оның бірінші өрісі күн мен уақыт болады. Ал ең үлкен деректер үзілімі күндер ауқымына негізделеді. Таңдалған күндер ауқымында, әдетте, лайкты пайдаланып, қатал күш әдісін қолданып, толық мәтінді іздеуді жүзеге асыруға болады. ClickHouse ішіндегі ұқсас оператор - сіз таба алатын ең тиімді ұқсас оператор. Егер сіз жақсы нәрсені тапсаңыз, маған айтыңыз.
Дегенмен, толық сканерлеу сияқты. Ал толық сканерлеу процессорда ғана емес, дискіде де баяу болуы мүмкін. Егер кенеттен сізде күніне бір терабайт деректер болса және сіз күн ішінде сөз іздесеңіз, онда терабайтты сканерлеуге тура келеді. Бұл кәдімгі қатты дискілерде болуы мүмкін және соңында олар осы серверге SSH арқылы қол жеткізе алмайтындай етіп жүктеледі.
Бұл жағдайда мен тағы бір кішкентай трюк ұсынуға дайынмын. Бұл эксперименталды - жұмыс істеуі мүмкін, болмауы мүмкін. ClickHouse триграммалық Bloom сүзгілері түріндегі толық мәтінді индекстерге ие. Arenadata-дағы әріптестеріміз бұл индекстерді қолданып көрді және олар жиі тағайындалғандай жұмыс істейді.
Оларды дұрыс пайдалану үшін сіз олардың қалай жұмыс істейтінін жақсы түсінуіңіз керек: триграмма Блум сүзгісі деген не және оның өлшемін қалай таңдауға болады. Кейбір сирек фразалар, деректерде сирек кездесетін ішкі жолдар бойынша сұрауларға көмектесетінін айта аламын. Бұл жағдайда ішкі ауқымдар индекстер арқылы таңдалады және аз деректер оқылады.
Жақында ClickHouse толық мәтінді іздеу үшін одан да жетілдірілген функцияларды қосты. Бұл, біріншіден, UTF-8 немесе тек ASCII үшін қолдауы бар регистрді, регистрді ескермейтін опцияларды қоса алғанда, бір өтуде бірден ішкі жолдар шоғырын іздеу. Сізге ең тиімдісін таңдаңыз.
Бір өтуде бірнеше тұрақты өрнектерді іздеу де пайда болды. Бір ішкі жол сияқты X немесе басқа ішкі жол сияқты X жазудың қажеті жоқ. Сіз бірден жазасыз және бәрі мүмкіндігінше тиімді орындалады.
Үшіншіден, енді regexps үшін шамамен іздеу және ішкі жолдарды шамамен іздеу бар. Егер біреу сөзді қате жазса, ол максималды сәйкестік үшін ізделеді.
Көптеген пайдаланушылар үшін ClickHouse-қа кіруді ұйымдастырудың ең жақсы жолы қандай?
Көптеген тұтынушылар мен талдаушылар үшін қолжетімділікті қалай ұйымдастыру керектігін айтыңыз. Кезекті қалай құруға, максималды бір уақыттағы сұрауларға басымдық беруге және қандай құралдармен?
Егер кластер жеткілікті үлкен болса, онда талдаушылар үшін кіру нүктесі болатын тағы екі серверді көтеру жақсы шешім болар еді. Яғни, талдаушыларға кластердегі белгілі бір бөліктерге қол жеткізуге рұқсат бермеңіз, тек деректерсіз екі бос сервер жасаңыз және оларға қатынас құқықтарын конфигурациялаңыз. Бұл жағдайда таратылған сұрауларға арналған пайдаланушы параметрлері қашықтағы серверлерге тасымалданады. Яғни, сіз осы екі серверде барлығын конфигурациялайсыз және параметрлер бүкіл кластерге әсер етеді.
Негізінде, бұл серверлерде деректер жоқ, бірақ олардағы жедел жад көлемі сұраныстарды орындау үшін өте маңызды. Сыртқы біріктіру немесе сыртқы сұрыптау қосылған болса, дискіні уақытша деректер үшін де пайдалануға болады.
Барлық ықтимал шектеулермен байланысты параметрлерді қарау маңызды. Енді мен аналитик ретінде Yandex.Metrica кластеріне кіріп, өтініш сұрасам соққылардан санды таңдаңыз, содан кейін маған бірден сұрауды орындай алмайтын ерекшелік беріледі. Маған сканерлеуге рұқсат етілген жолдардың максималды саны - жүз миллиард және кластердегі бір кестеде олардың барлығы елу триллион бар. Бұл бірінші шектеу.
Жол шегін алып тастап, сұрауды қайта іске қостым делік. Содан кейін мен келесі ерекшелікті көремін - параметр қосылған күні бойынша күш индексі. Күндер ауқымын көрсетпесем, сұрауды аяқтай алмаймын. Оны қолмен көрсету үшін талдаушыларға сенудің қажеті жоқ. Апта арасындағы оқиға күні күндер ауқымы жазылатын әдеттегі жағдай. Содан кейін олар жай ғана жақшаны дұрыс емес жерде көрсетті және оның орнына немесе - немесе URL сәйкестігі болып шықты. Егер шектеу болмаса, ол URL бағанын тексеріп шығады және бір тонна ресурстарды босқа жұмсайды.
Бұған қоса, ClickHouse-да екі басымдық параметрі бар. Өкінішке орай, олар өте қарабайыр. Біреуі қарапайым деп аталады басымдық. Егер басымдылық ≠ 0 болса және қандай да бір басымдылығы бар сұраулар орындалса, бірақ басымдылығы жоғарырақ мәнді білдіретін одан төмен сұраныс орындалса, басымдылығы төмен сұраныс , жай ғана тоқтатылады және осы уақыт ішінде мүлдем жұмыс істемейді.
Бұл өте өрескел параметр және кластердің тұрақты жүктемесі бар жағдайларға жарамайды. Бірақ сізде маңызды қысқа, жылдам сұраулар болса және кластер негізінен бос болса, бұл орнату қолайлы.
Келесі басымдық параметрі шақырылады ОЖ ағынының басымдығы. Ол жай ғана Linux жоспарлаушысы үшін барлық сұрауларды орындау ағындары үшін жақсы мәнді орнатады. Ол солай жұмыс істейді, бірақ ол әлі де жұмыс істейді. Егер сіз ең төменгі жақсы мәнді орнатсаңыз - бұл мән бойынша ең үлкен, демек, ең төменгі басымдық - және жоғары басымдығы бар сұраулар үшін -19 мәнін орнатсаңыз, орталық процессор басымдығы төмен сұрауларды жоғары басымдыққа қарағанда шамамен төрт есе аз тұтынады.
Сондай-ақ сұрауды орындаудың максималды уақытын конфигурациялау қажет - айталық, бес минут. Сұрауды орындаудың ең төменгі жылдамдығы - ең керемет нәрсе. Бұл параметр ұзақ уақыт бойы болды және ClickHouse жылдамдығын төмендетпейтінін растау ғана емес, оны мәжбүрлеу қажет.
Сіз орнатқаныңызды елестетіп көріңіз: егер кейбір сұраулар секундына бір миллионнан аз жолды өңдесе, сіз мұны істей алмайсыз. Бұл біздің жақсы атымызды, жақсы дерекқорымызды қорлайды. Осыған тыйым салайық. Іс жүзінде екі параметр бар. Біреуі деп аталады мин. орындау жылдамдығы - секундына жолдармен, ал екіншісі минимум орындалу жылдамдығын тексеруден бұрын күту уақыты деп аталады - әдепкі бойынша он бес секунд. Яғни, он бес секунд болуы мүмкін, содан кейін ол баяу болса, ерекше жағдайды тастап, сұрауды тоқтатыңыз.
Сондай-ақ квоталарды орнату қажет. ClickHouse бағдарламасында ресурстарды тұтынуды есептейтін кірістірілген квота мүмкіндігі бар. Бірақ, өкінішке орай, процессор, дискілер сияқты аппараттық ресурстар емес, логикалық ресурстар - өңделген сұраныстардың, оқылған жолдар мен байттардың саны. Сіз, мысалы, бес минут ішінде ең көбі жүз сұрауды және сағатына мың сұрауды теңшей аласыз.
Неліктен маңызды? Өйткені кейбір аналитикалық сұраулар ClickHouse клиентінен тікелей қолмен орындалады. Және бәрі жақсы болады. Бірақ сіздің компанияңызда озық талдаушылар болса, олар сценарий жазады және сценарийде қате болуы мүмкін. Және бұл қате сұраудың шексіз циклде орындалуына әкеледі. Міне, осыдан өзімізді қорғауымыз керек.
Бір сұраныстың нәтижесін он клиентке беруге болады ма?
Бізде бір уақытта өте үлкен сұраныстармен келгенді ұнататын бірнеше пайдаланушылар бар. Сұраныс үлкен және, негізінен, тез орындалады, бірақ бір уақытта мұндай сұраныстардың көп болуына байланысты ол өте ауыр болады. Қатарынан он рет келген сұранысты бір рет орындап, нәтижесін он клиентке беруге бола ма?
Мәселе мынада, бізде аралық деректердің кэш немесе кэш нәтижелері жоқ. Операциялық жүйенің бет кэші бар, ол дискіден деректерді қайтадан оқуға жол бермейді, бірақ, өкінішке орай, деректер әлі де шығарылады, сериядан шығарылады және қайта өңделеді.
Мен аралық деректерді кэштеу арқылы немесе қандай да бір кезекте ұқсас сұрауларды ретке келтіру және нәтиже кэшін қосу арқылы мұны болдырмас едім. Әзірге бізде сұрау кэшін қосатын бір тарту сұрауы бар, бірақ тек кіріс және қосылу бөлімдеріндегі ішкі сұраулар үшін, яғни шешім толық емес.
Алайда мұндай жағдайға біз де тап боламыз. Ерекше канондық мысал - беттелген сұраулар. Есеп бар, оның бірнеше беті бар және 10-ға дейін шектеуге сұраныс бар. Содан кейін бірдей нәрсе, бірақ шектеу 10,10. Содан кейін басқа келесі бет. Ал сұрақ мынада: біз мұның бәрін неге әр уақытта санаймыз? Бірақ қазір шешім де жоқ, одан құтылудың да жолы жоқ.
ClickHouse жанындағы арба ретінде орналастырылған балама шешім бар - .
Кирилл Шваков: ClickHouse проксиінде кірістірілген жылдамдықты шектегіш және кірістірілген нәтиже кэші бар. Онда көптеген параметрлер жасалды, себебі ұқсас мәселе шешілуде. Прокси сұрауларды кезекке қою арқылы шектеуге және сұрау кэшінің ұзақтығын конфигурациялауға мүмкіндік береді. Егер сұраулар шынымен бірдей болса, прокси оларды бірнеше рет жібереді, бірақ ClickHouse қызметіне бір рет қана барады.
Nginx тегін нұсқасында да кэш бар және бұл да жұмыс істейді. Nginx-те сұраулар бір уақытта келсе, біреуі аяқталғанша басқаларды баяулататын параметрлері бар. Бірақ ClickHouse проксиінде орнату әлдеқайда жақсырақ орындалады. Ол арнайы ClickHouse үшін, арнайы осы сұраулар үшін жасалған, сондықтан ол қолайлырақ. Жақсы, орнату оңай.
Асинхронды операциялар мен материалдандырылған көріністер туралы не деуге болады?
Қайталау қозғалтқышымен операциялар асинхронды болып табылатын мәселе бар - алдымен деректер жазылады, содан кейін ол жойылады. Белгінің астында кейбір жиынтықтары бар материалдандырылған планшет тұрса, оған көшірмелер жазылады. Ал егер күрделі логика болмаса, онда деректер қайталанады. Сіз бұл туралы не істей аласыз?
Анық шешім бар - асинхронды коллапс операциясы кезінде маткөріністердің белгілі бір класында триггерді жүзеге асыру. Күміс оқтар немесе ұқсас функционалдылықты енгізу жоспарлары бар ма?
Дедупликация қалай жұмыс істейтінін түсінген жөн. Мен сізге қазір айтатын нәрсе сұраққа қатысты емес, бірақ есте сақтау қажет болған жағдайда.
Қайталанатын кестеге кірістіру кезінде барлық кірістірілген блоктардың қайталануы орын алады. Егер сіз бірдей жолдардың бірдей санын қамтитын бірдей блокты бір ретпен қайта енгізсеңіз, деректер қайталанбайды. Сіз кірістіруге жауап ретінде «Жарайды» аласыз, бірақ іс жүзінде деректердің бір пакеті жазылады және ол қайталанбайды.
Бұл сенімділік үшін қажет. Енгізу кезінде «Жарайды» алсаңыз, деректеріңіз енгізілген. ClickHouse қолданбасынан қате алсаңыз, бұл олардың енгізілмегенін білдіреді және кірістіруді қайталау қажет. Бірақ кірістіру кезінде қосылым үзілсе, деректер енгізілген-енгізілмегенін білмейсіз. Жалғыз нұсқа - кірістіруді қайтадан қайталау. Деректер шынымен енгізілген болса және сіз оны қайта енгізсеңіз, блоктың қайталануы бар. Бұл қайталануларды болдырмау үшін қажет.
Оның материалдандырылған көріністер үшін қалай жұмыс істейтіні де маңызды. Егер деректер негізгі кестеге енгізілген кезде дедупликацияланса, онда ол материалдандырылған көрініске де кірмейді.
Енді сұрақ туралы. Сіздің жағдайыңыз күрделірек, себебі сіз жеке жолдардың көшірмелерін жазып жатырсыз. Яғни, қайталанатын бүкіл бума емес, нақты жолдар және олар фондық режимде құлайды. Шынында да, деректер негізгі кестеде жойылады, бірақ жабылмаған деректер материалдандырылған көрініске өтеді, ал біріктіру кезінде материалданған көріністерге ештеңе болмайды. Өйткені материалдандырылған көрініс кірістіру триггерінен басқа ештеңе емес. Басқа операциялар кезінде оған қосымша ештеңе болмайды.
Ал мен сені бұл жерде бақытты ете алмаймын. Бұл жағдайдың нақты шешімін іздеу керек. Мысалы, оны материалдандырылған көріністе қайта ойнатуға болады ма және қайталау әдісі бірдей жұмыс істей алады. Бірақ, өкінішке орай, әрқашан емес. Егер ол біріктірілсе, ол жұмыс істемейді.
Кирилл Шваков: Сол кезде бізде балдақ салу да болған. Жарнамалық әсерлер бар деген мәселе туындады және біз нақты уақытта көрсете алатын деректер бар - бұл жай ғана әсерлер. Олар сирек қайталанады, бірақ бұл орын алса, біз бәрібір оларды кейінірек бұзамыз. Қайталанбайтын нәрселер болды - шертулер және осы оқиға. Бірақ мен оларды бірден көрсеткім келді.
Материалдық көзқарастар қалай жасалды? Тікелей жазылған көріністер болды - ол бастапқы деректерге жазылды және көріністерге жазылды. Онда, белгілі бір уақытта деректер өте дұрыс емес, ол қайталанады және т.б. Ал кестенің екінші бөлігі бар, онда олар заттандырылған көріністермен бірдей көрінеді, яғни құрылымы жағынан олар мүлдем бірдей. Анда-санда деректерді қайта есептейміз, деректерді қайталанбай санаймыз, сол кестелерге жазамыз.
Біз API арқылы өттік - бұл ClickHouse қолданбасында қолмен жұмыс істемейді. API келесідей көрінеді: кестеге соңғы қосу күні болған кезде, онда дұрыс деректер есептелгеніне кепілдік беріледі және ол бір кестеге және басқа кестеге сұраныс жасайды. Біреуінен сұрау белгілі бір уақытқа дейін таңдайды, ал екіншісінен әлі есептелмегенді алады. Және бұл жұмыс істейді, бірақ тек ClickHouse арқылы емес.
Егер сізде қандай да бір API түрі болса - талдаушылар үшін, пайдаланушылар үшін - онда, негізінен, бұл опция. Сіз әрқашан санайсыз, әрқашан есептейсіз. Мұны күніне бір рет немесе басқа уақытта жасауға болады. Сіз өзіңіз үшін қажет емес және маңызды емес ауқымды таңдайсыз.
ClickHouse-да көптеген журналдар бар. Серверде болып жатқанның барлығын бір қарағанда қалай көруге болады?
ClickHouse-да әртүрлі журналдардың өте көп саны бар және бұл сан артып келеді. Жаңа нұсқаларда олардың кейбіреулері әдепкі бойынша қосылды; ескі нұсқаларда жаңарту кезінде қосу керек. Дегенмен, олардың саны артып келеді. Сайып келгенде, мен қазір серверде не болып жатқанын көргім келеді, мүмкін қандай да бір жиынтық бақылау тақтасында.
Сізде бұл журналдарды дайын өнім ретінде көрсететін дайын бақылау тақталарының кейбір функцияларын қолдайтын ClickHouse командасы немесе достарыңыздың топтары бар ма? Сайып келгенде, ClickHouse жүйесіндегі журналдарды қарау өте жақсы. Бірақ ол қазірдің өзінде бақылау тақтасы түрінде дайындалған болса, бұл өте жақсы болар еді. Мен одан бір тепкі алатын едім.
Бақылау тақталары бар, бірақ олар стандартталмаған. Біздің компанияда 60-қа жуық команда ClickHouse пайдаланады, ең қызығы, олардың көпшілігінде өздері үшін жасаған бақылау тақталары бар және сәл өзгеше. Кейбір командалар ішкі Yandex.Cloud орнатуын пайдаланады. Қажетті есептердің барлығы болмаса да, дайын есептер бар. Басқалардың өздері бар.
Metrica-дағы әріптестерімнің Grafana-да жеке бақылау тақтасы бар, ал менде олардың кластері үшін жеке тақта бар. Мен сериф кэшіне арналған кэш соққысы сияқты нәрселерді қарап жатырмын. Ал одан да қиын, біз әртүрлі құралдарды қолданамыз. Мен бақылау тақтасын өте ескі Graphite-web құралы арқылы жасадым. Ол мүлдем ұсқынсыз. Мен оны әлі де осылай қолданамын, бірақ Grafana ыңғайлырақ және әдемі болар еді.
Бақылау тақталарындағы негізгі нәрсе бірдей. Бұл кластерге арналған жүйелік көрсеткіштер: процессор, жад, диск, желі. Басқалары - бір уақыттағы сұраулар саны, бір уақытта біріктірулер саны, секундтағы сұраулар саны, MergeTree кестесінің бөлімдері үшін бөліктердің максималды саны, репликацияның кешігуі, репликация кезегінің өлшемі, секундына енгізілген жолдар саны, секундына енгізілген блоктар саны. Бұл журналдардан емес, метрикадан алынғанның бәрі.
Владимир Колобаев: Алексей, мен оны аздап түзеткім келеді. Графана бар. Grafana-да деректер көзі бар, ол ClickHouse. Яғни, мен Grafana-дан тікелей ClickHouse-қа сұраныс жасай аламын. ClickHouse-да журналдары бар кесте бар, ол барлығына бірдей. Нәтижесінде мен Grafana-да осы журнал кестесіне кіріп, серверім жасайтын сұрауларды көргім келеді. Осындай бақылау тақтасы болса жақсы болар еді.
Мен өзім велосипедпен жүрдім. Бірақ менің сұрағым бар - егер бәрі стандартталған болса және Grafana-ны барлығы қолданса, неге Яндекстің мұндай ресми бақылау тақтасы жоқ?
Кирилл Шваков: Шын мәнінде, ClickHouse қолданбасына баратын деректер көзі енді Altinity-ге қолдау көрсетеді. Мен қайда қазу керек және кімді итеру керек деген векторды бергім келеді. Сіз олардан сұрай аласыз, өйткені Яндекс әлі де оның айналасындағы оқиға емес, ClickHouse жасайды. Altinity - қазіргі уақытта ClickHouse-ты алға жылжытатын негізгі компания. Олар оны тастамайды, керісінше оны қолдайды. Өйткені, негізінен, Grafana веб-сайтына бақылау тақтасын жүктеп салу үшін сізге тек тіркеліп, оны жүктеп салу қажет - арнайы проблемалар жоқ.
Алексей Миловидов: Өткен жылы ClickHouse көптеген сұрауларды профильдеу мүмкіндіктерін қосты. Ресурсты пайдалану бойынша әрбір сұрау үшін көрсеткіштер бар. Жақында біз сұраудың миллисекунд сайын қайда жұмсайтынын көру үшін одан да төмен деңгейлі сұрау профилін қостық. Бірақ бұл функцияны пайдалану үшін мен консоль клиентін ашып, әрқашан ұмытып кететін сұрауды теруім керек. Мен оны бір жерде сақтап қойдым және қай жерде екенін ұмытып кетем.
Сұрау класы бойынша топтастырылған ауыр сұрауларыңыз бар деп айтатын құрал болғанын қалаймын. Мен біреуін бастым, олар маған оның ауыр екенін айтты. Қазір ондай шешім жоқ. Адамдар маған: «Айтыңызшы, Grafana үшін дайын бақылау тақталары бар ма?» деп сұрағанда, мен: «Grafana веб-сайтына өтіңіз, «Басқару тақталары» қауымдастығы бар және бақылау тақтасы бар. Димкадан, Костяннан бақылау тақтасы бар. Мен оның не екенін білмеймін, мен оны өзім пайдаланбадым ».
Сервер OOM-ге құлап кетпеуі үшін біріктірулерге қалай әсер ету керек?
Менде кесте бар, кестеде бір ғана бөлім бар, ол ReplacingMergeTree. Мен оған төрт жыл бойы деректер жазып келемін. Маған өзгертулер енгізіп, кейбір деректерді жою керек болды.
Мен мұны істедім және осы сұрауды өңдеу кезінде кластердегі барлық серверлердегі барлық жад тұтынылды және кластердегі барлық серверлер OOM жүйесіне кірді. Содан кейін олар бірге тұрып, дәл осы операцияны, осы деректер блогын біріктіре бастады және қайтадан OOM-ға түсті. Содан кейін олар қайтадан тұрып, қайтадан құлады. Және бұл іс тоқтаған жоқ.
Содан кейін бұл жігіттер жөндеген қате екені белгілі болды. Бұл өте керемет, көп рахмет. Бірақ қалдық қалды. Енді мен кестеде қандай да бір біріктіру түрін жасау туралы ойлағанда, менде сұрақ туындайды - неге мен бұл біріктірулерге әсер ете алмаймын? Мысалы, оларды талап етілетін жедел жад көлемімен немесе, негізінен, осы кестені өңдейтін мөлшермен шектеңіз.
Менде «Метрика» деп аталатын кесте бар, оны мен үшін екі ағынмен өңдеңіз. Параллельде он немесе бес біріктіруді жасаудың қажеті жоқ, оны екіде жасаңыз. Менің ойымша, менде екі жады жеткілікті, бірақ онды өңдеуге жеткіліксіз болуы мүмкін. Неліктен қорқыныш сақталады? Кесте өсіп келе жатқандықтан және бір күні мен қатеге байланысты емес жағдайға тап боламын, бірақ деректер соншалықты үлкен көлемде өзгеретіндіктен, менде жад жеткіліксіз болады. сервер. Содан кейін сервер біріктіру кезінде OOM-ге құлап кетеді. Оның үстіне, мен мутацияны жоя аламын, бірақ Мерджи енді жоқ.
Білесіз бе, біріктіру кезінде сервер OOM-ға түспейді, өйткені біріктіру кезінде ЖЖҚ көлемі деректердің бір шағын диапазоны үшін ғана пайдаланылады. Сондықтан деректер көлеміне қарамастан бәрі жақсы болады.
Владимир Колобаев: Жақсы. Міне, қате түзетілгеннен кейін мен өзім үшін жаңа нұсқаны жүктеп алдым, ал басқа кестеде, көптеген бөлімдер бар кішірек үстелде мен ұқсас операцияны орындадым. Ал біріктіру кезінде серверде шамамен 100 ГБ жедел жады өртенді. Менде 150 адам болды, 100 тамақ жеді және 50 ГБ терезе қалды, сондықтан мен OOM-ға түспедім.
Қазіргі уақытта ол 100 ГБ жедел жадты тұтынатын болса, мені OOM жүйесіне түсуден не қорғайды? Біріктірудегі жедел жады кенет таусылып қалса не істеу керек?
Алексей Миловидов: Біріктіру үшін арнайы ЖЖҚ тұтынуы шектелмейтін мәселе бар. Екінші мәселе, егер біріктірудің қандай да бір түрі тағайындалған болса, онда ол репликация журналында жазылғандықтан орындалуы керек. Репликация журналы репликаны дәйекті күйге келтіру үшін қажетті әрекеттер болып табылады. Осы репликация журналын кері қайтаратын қолмен манипуляциялар жасамасаңыз, біріктіру бір жолмен немесе басқаша орындалуы керек.
Әрине, OOM-дан «қандай жағдайда» қорғайтын ЖЖҚ шектеуінің болуы артық болмас еді. Бұл біріктіруді аяқтауға көмектеспейді, ол қайтадан басталады, белгілі бір шекке жетеді, ерекшелік тастайды, содан кейін қайтадан басталады - бұдан жақсы ештеңе болмайды. Бірақ, негізінен, бұл шектеуді енгізу пайдалы болар еді.
ClickHouse үшін Golang драйвері қалай әзірленеді?
Кирилл Шваков жазған Голанг драйверін қазір ClickHouse командасы ресми түрде қолдайды. Ол , ол қазір үлкен және шынайы.
Шағын жазба. Шексіз тәртіптің қалыпты формаларының тамаша және сүйікті репозиторийі бар - бұл Vertica. Сондай-ақ олардың Vertica әзірлеушілері қолдайтын өздерінің ресми питон драйвері бар. Бірнеше рет сақтау нұсқалары мен драйвер нұсқалары айтарлықтай ерекшеленеді және драйвер бір сәтте жұмысын тоқтатты. Және екінші нүкте. Бұл ресми жүргізушіге қолдау көрсету, меніңше, «емізік» жүйесі арқылы жүзеге асырылады - сіз оларға мәселе жазасыз және ол мәңгілікке ілініп тұрады.
Менің екі сұрағым бар. Енді Кириллдің Голанг драйвері Голангтан ClickHouse-пен байланысудың әдепкі тәсілі болып табылады. Егер біреу әлі де http интерфейсі арқылы байланыспаса, ол оны ұнататындықтан. Бұл драйвердің дамуы қалай жалғасады? Ол репозиторийдегі кез келген үзіліс өзгерістерімен синхрондалады ма? Ал мәселені қарау тәртібі қандай?
Кирилл Шваков: Біріншісі - бәрі бюрократиялық түрде қалай ұйымдастырылған. Бұл мәселе талқыланбады, сондықтан мен жауап беретін ештеңе жоқ.
Мәселе туралы сұраққа жауап беру үшін бізге жүргізушінің кішкене тарихы қажет. Мен деректері көп компанияда жұмыс істедім. Бұл бір жерде сақталуы керек оқиғалардың үлкен саны бар жарнамалық спиннер болды. Бір кезде ClickHouse пайда болды. Біз оны деректермен толтырдық, алдымен бәрі жақсы болды, бірақ кейін ClickHouse істен шықты. Сол кезде біз бұл бізге қажет емес деп шештік.
Бір жылдан кейін біз ClickHouse пайдалану идеясына қайта оралдық және бізге қандай да бір жолмен деректерді жазу керек болды. Кіріспе хабарлама мынадай болды: аппараттық құрал өте әлсіз, ресурстар аз. Бірақ біз әрқашан осылай жұмыс істедік, сондықтан біз жергілікті хаттамаға қарадық.
Біз Go-да жұмыс істегендіктен, бізге Go драйвері керек екені анық болды. Мен оны толық уақытты дерлік орындадым - бұл менің жұмысым болды. Біз оны белгілі бір деңгейге жеткіздік, бізден басқа ешкім оны пайдаланады деп принципті түрде ешкім ойлаған жоқ. Содан кейін CloudFlare дәл осындай мәселемен келді және біраз уақыт біз олармен өте тегіс жұмыс істедік, өйткені олардың міндеттері бірдей болды. Сонымен қатар, біз мұны ClickHouse-та өзіміз де, драйверде де жасадық.
Бір сәтте мен мұны істеуді тоқтаттым, өйткені ClickHouse және жұмыс бойынша белсенділігім аздап өзгерді. Сондықтан мәселелер жабылмайды. Мерзімді түрде бір нәрсеге мұқтаж адамдар репозиторийге жүгінеді. Содан кейін мен тарту сұрауына қараймын, кейде мен бірдеңені өзім өңдеймін, бірақ бұл сирек болады.
Мен жүргізушіге оралғым келеді. Бірнеше жыл бұрын, осының бәрі басталған кезде, ClickHouse да әртүрлі және әртүрлі мүмкіндіктерге ие болды. Енді біз драйверді жақсы жұмыс істеуі үшін қалай қайта жасау керектігін түсіндік. Егер бұл орын алса, онда 2-нұсқа жинақталған балдақтардың арқасында кез келген жағдайда үйлесімсіз болады.
Мен бұл мәселені қалай ұйымдастыру керектігін білмеймін. Менің өзімде көп уақыт жоқ. Кейбір адамдар жүргізушіні аяқтаса, мен оларға көмектесіп, не істеу керектігін айта аламын. Бірақ жобаны әзірлеуге Яндекстің белсенді қатысуы әлі талқыланған жоқ.
Алексей Миловидов: Негізі бұл жүргізушілерге қатысты бюрократия әлі жоқ. Жалғыз нәрсе, олар ресми ұйымға жіберіледі, яғни бұл драйвер Go үшін ресми әдепкі шешім ретінде танылады. Басқа жүргізушілер бар, бірақ олар бөлек келеді.
Бізде бұл драйверлер үшін ішкі даму жоқ. Мәселе мынада, жеке адамды жалдай аламыз ба, бұл нақты жүргізуші үшін емес, барлық қауымдастық жүргізушілерін дамыту үшін немесе сырттан біреуді таба аламыз ба?
lazy_load параметрі қосылған қайта жүктеуден кейін сыртқы сөздік жүктелмейді. Не істеу?
Бізде lazy_load параметрі қосылды және сервер қайта жүктелгеннен кейін сөздік өздігінен жүктелмейді. Ол пайдаланушы осы сөздікке кіргеннен кейін ғана көтеріледі. Ал мен оған бірінші рет кіргенде, ол қате береді. ClickHouse көмегімен сөздіктерді қандай да бір түрде автоматты түрде жүктеуге болады ма, әлде пайдаланушылар қателерді алмас үшін олардың дайындығын әрқашан өзіңіз бақылауыңыз керек пе?
Мүмкін бізде ClickHouse ескі нұсқасы бар, сондықтан сөздік автоматты түрде жүктелмеді. Бұл жағдай болуы мүмкін бе?
Біріншіден, сөздіктерді сұрау арқылы мәжбүрлеп жүктеуге болады сөздіктерді жүйені қайта жүктеңіз. Екіншіден, қате туралы - сөздік әлдеқашан жүктелген болса, онда сұраулар жүктелген деректер негізінде жұмыс істейді. Егер сөздік әлі жүктелмеген болса, ол сұрау кезінде тікелей жүктеледі.
Бұл ауыр сөздіктер үшін өте ыңғайлы емес. Мысалы, MySQL-тен миллион жолды шығару керек. Біреу қарапайым таңдау жасайды, бірақ бұл таңдау бірдей миллион жолды күтеді. Мұнда екі шешім бар. Біріншісі - lazy_load өшіру. Екіншіден, сервер жұмыс істеп тұрғанда, оған жүктеме салмас бұрын жасаңыз жүйені қайта жүктеу сөздігі немесе сөздікті пайдаланатын сұрауды орындаңыз. Содан кейін сөздік жүктеледі. lazy_load параметрі қосылған сөздіктердің қолжетімділігін бақылау керек, себебі ClickHouse оларды автоматты түрде жүктемейді.
Соңғы сұраққа жауап - бұл нұсқа ескі немесе оны түзету қажет.
Жүйені қайта жүктеу сөздіктері көп сөздіктердің ешқайсысын жүктемейді, егер олардың кем дегенде біреуі қателікпен бұзылса, не істеу керек?
Жүйені қайта жүктеу сөздіктері туралы тағы бір сұрақ бар. Бізде екі сөздік бар – біреуі жүктелмеген, екіншісі жүктелген. Бұл жағдайда Жүйені қайта жүктеу сөздіктері ешбір сөздікті жүктемейді және жүйені қайта жүктеу сөздігін пайдаланып белгілі бір сөзді оның аты бойынша нүкте-нүкте жүктеу керек. Бұл ClickHouse нұсқасына да қатысты ма?
Мен сені бақытты еткім келеді. Бұл мінез өзгерді. Бұл ClickHouse-ды жаңартсаңыз, ол да өзгеретінін білдіреді. Егер сіздің қазіргі мінез-құлқыңызға риза болмасаңыз сөздіктерді жүйені қайта жүктеңіз, жаңартыңыз және ол жақсы жаққа өзгереді деп үміттенейік.
ClickHouse конфигурациясында мәліметтерді конфигурациялаудың жолы бар ма, бірақ қателер болған жағдайда оларды көрсетпеу керек пе?
Келесі сұрақ сөздікке қатысты қателер, атап айтқанда мәліметтер туралы. Біз сөздікке арналған ClickHouse конфигурациясында қосылым мәліметтерін көрсеттік және қате болса, жауап ретінде осы мәліметтер мен құпия сөзді аламыз.
Біз бұл қатені ODBC драйвер конфигурациясына мәліметтерді қосу арқылы шештік. ClickHouse конфигурациясындағы мәліметтерді конфигурациялаудың кез келген жолы бар ма, бірақ қателер болған жағдайда бұл мәліметтер көрсетілмейді ме?
Мұндағы нақты шешім бұл тіркелгі деректерін odbc.ini ішінде көрсету және ClickHouse ішінде тек ODBC деректер көзінің атауын көрсету. Бұл басқа сөздік көздері үшін болмайды - MySQL бар сөздік үшін де, басқалары үшін де қате туралы хабарды алған кезде құпия сөзді көрмеу керек. ODBC үшін мен де қараймын - егер ол бар болса, оны жою керек.
Бонус: жиындардан Zoom фоны
Суретті басу арқылы ең табанды оқырмандар үшін жиналыстардың бонустық фоны ашылады. Біз Avito технологиясының тұмарларымен бірге өртті сөндіреміз, жүйелік әкімші бөлмесіндегі немесе ескі мектептегі компьютерлік клубтағы әріптестермен сөйлесеміз және граффити фонында көпір астында күнделікті кездесулер өткіземіз.
Ақпарат көзі: www.habr.com