Апрель айында Avito инженерлери ClickHouse башкы иштеп чыгуучусу Алексей Миловидов жана Integros компаниясынан Голанг иштеп чыгуучусу Кирилл Шваков менен онлайн жолугушууларга чогулушту. Биз маалымат базасын башкаруу системасын кантип колдонобуз жана кандай кыйынчылыктарга дуушар болуп жатканыбызды талкууладык.
Жолугушуунун негизинде биз камдык көчүрмөлөр, маалыматтарды кайра бөлүштүрүү, тышкы сөздүктөр, Голанг драйвери жана ClickHouse версияларын жаңыртуу боюнча биздин жана аудиториянын суроолоруна эксперттердин жооптору менен макала түздүк. Бул Яндекс DBMS менен жигердүү иштеп жаткан жана анын азыркы жана келечегине кызыккан иштеп чыгуучулар үчүн пайдалуу болушу мүмкүн. Демейки боюнча, жооптор Алексей Миловидов тарабынан, эгерде башкача жазылбаса.
Абайлагыла, кесилгендин астында көп текст бар. Суроолор камтылган мазмун багыттоого жардам берет деп үмүттөнөбүз.
ыраазы
Эгер сиз текстти окугуңуз келбесе, анда сиз чогулуштардын жазуусун көрө аласыз . Тайм коддору видеонун астындагы биринчи комментарийде.
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-жылдын биринчи айын алып, аны жаңы серверге көчүрөсүз, андан кийин үчүнчү айды башка жаңы серверге көчүрөсүз. Жана сиз муну аздыр-көптүр тегиз болгонго чейин жасайсыз.
Өткөрүп берүү жазуу учурунда өзгөрбөгөн бөлүмдөр үчүн гана жүргүзүлүшү мүмкүн. Жаңы бөлүмдөр үчүн жазууну өчүрүү керек, анткени алардын өткөрүлүшү атомдук эмес. Болбосо, сиз маалыматтардын кайталанмалары же боштуктары менен аяктайсыз. Бирок, бул ыкма практикалык жана абдан натыйжалуу иштейт. Даяр кысылган бөлүмдөр тармак аркылуу берилет, башкача айтканда, маалыматтар кысылып же кайра коддолбойт.
Бул ыкманын бир кемчилиги бар жана бул бөлүү схемасынан көз каранды, сиз бул бөлүштүрүү схемасына күрөөгө койгонсузбу, сизде кандай sharding ачкычы бар. Сиздин мисалыңызда метрика менен иштөө үчүн, бөлүү ачкычы жолдун хэши болуп саналат. Бөлүштүрүлгөн таблицаны тандаганыңызда, ал дароо кластердеги бардык сыныктарга барат жана ошол жерден маалыматтарды алат.
Бул кайсы маалымат кайсы сыныкта аяктаганы сиз үчүн маанилүү эмес дегенди билдирет. Эң негизгиси, бир жолдогу маалыматтар бир сыныкта бүтөт, бирок кайсынысы маанилүү эмес. Бул учурда, даяр бөлүмдөрдү өткөрүп берүү идеалдуу, анткени тандалган сурамдар менен сиз толук маалыматты аласыз - кайра бөлүштүрүүгө чейин же андан кийин, схема чындыгында маанилүү эмес.
Бирок татаалыраак учурлар бар. Колдонмонун логикалык деңгээлинде сиз атайын бөлүү схемасына таянсаңыз, бул кардар баланча сыныкта жайгашкан жана сурам бөлүштүрүлгөн таблицага эмес, түздөн-түз ошол жакка жөнөтүлүшү мүмкүн. Же сиз ClickHouse'тун акыркы версиясын колдонуп жатасыз жана жөндөөнү иштеттиңиз колдонулбаган сыныктарды өткөрүп жиберүүнү оптималдаштыруу. Бул учурда, тандоо сурамынын жүрүшүндө, кайда бөлүмүндөгү туюнтма талданат жана бөлүштүрүүчү схемага ылайык кайсы сыныктар колдонулушу керектиги эсептелинет. Бул дайындар так ушул бөлүштүрүү схемасына ылайык бөлүнгөн шартта иштейт. Эгер сиз аларды кол менен иретке келтирсеңиз, кат алышуу өзгөрүшү мүмкүн.
Демек, бул биринчи ыкма. А мен сиздин жообуңузду күтүп жатам, ыкма ылайыктуубу, же уланталы.
Владимир Колобаев, Avito компаниясынын башкы системалык администратору: Алексей, сиз айткан ыкма, жүктү, анын ичинде окууну жайылтуу керек болгондо жакшы иштебейт. Биз ай сайын болгон жана мурунку айды башка түйүнгө ала турган бөлүмдү ала алабыз, бирок бул дайындарга суроо-талап келгенде, биз аны жүктөйбүз. Бирок, биз бүт кластерди жүктөөнү каалайбыз, анткени антпесе, бир нече убакытка бүт окуу жүгү эки сынык менен иштетилет.
Алексей Миловидов: Бул жерде жообу кызык - ооба, бул жаман, бирок иштеши мүмкүн. Мен так кантип түшүндүрөм. Дайындарыңыздын артында келе турган жүктөө сценарийин карап көрүү керек. Эгерде бул мониторинг маалыматтары болсо, анда биз сурамдардын басымдуу көпчүлүгү жаңы маалыматтар үчүн деп айта алабыз.
Сиз жаңы серверлерди орноттуңуз, эски бөлүмдөрдү көчүрдүңүз, бирок ошондой эле жаңы маалыматтар кантип жазыларын өзгөрттүңүз. Жана жаңы маалыматтар кластер боюнча жайылтылат. Ошентип, беш мүнөттөн кийин, акыркы беш мүнөттүк суроо-талаптар кластерди бирдей жүктөйт, бир суткадан кийин, 24 сааттык суроо-талаптар кластерди бирдей жүктөйт. Ал эми мурунку айдагы суроо-талаптар, тилекке каршы, кластердик серверлердин бир бөлүгүнө гана түшөт.
Бирок көп учурда сизде 2019-жылдын февраль айына карата өтүнүчтөр болбойт. Кыязы, эгерде суроо-талаптар 2019-жылга кирсе, анда алар бүтүндөй 2019-жылга - кээ бир кичинекей диапазонго эмес, чоң убакытка болот. Жана мындай суроо-талаптар кластерди бир калыпта жүктөй алат. Бирок, жалпысынан алганда, бул маалыматты толугу менен бирдей таратпай турган атайын чечим деп айтканыңыз туура.
Суроого жооп бере турган дагы бир нече пунктум бар. Алардын бири - кайра бөлүү азыраак оорушу үчүн, адегенде кантип сындырып алуу схемасын иштеп чыгуу керектиги жөнүндө. Бул дайыма эле мүмкүн боло бербейт.
Мисалы, сизде мониторинг маалыматтары бар. Мониторинг маалыматтары үч себептен улам өсүп жатат. Биринчиси, тарыхый маалыматтарды топтоо. Экинчиси - трафиктин өсүшү. Ал эми үчүнчүсү – мониторингге алынган нерселердин көбөйүшү. Сактоо керек болгон жаңы микросервистер жана метрикалар бар.
Мүмкүн, алардын ичинен эң чоң өсүш үчүнчү себеп – мониторингди колдонуунун көбөйүшү менен байланыштуу болушу мүмкүн. Ал эми бул учурда, жүктүн мүнөзүн карап чыгуу керек, кандай негизги тандоо сурамдары бар. Негизги тандоо сурамдары, кыязы, кээ бир көрсөткүчтөрдүн топтомуна негизделет.
Мисалы, кээ бир кызматтар тарабынан кээ бир серверлерде CPU колдонулушу. Көрсө, сиз бул маалыматты ала турган баскычтардын белгилүү бир бөлүгү бар экен. Ал эми бул маалымат үчүн суроо-талаптын өзү, кыязы, абдан жөнөкөй жана ондогон миллисекунддарда аяктайт. Мониторинг кызматтары жана панелдер үчүн колдонулат. Мен муну туура түшүнөм деп үмүттөнөм.
Владимир Колобаев: Чындыгында биз тарыхый маалыматтарга көп кайрылабыз, анткени биз учурдагы кырдаалды реалдуу убакытта тарыхый абал менен салыштырып жатабыз. Жана биз үчүн чоң көлөмдөгү маалыматтарга тез жетүү маанилүү жана ClickHouse муну менен эң сонун иштейт.
Сиз таптакыр туура айтасыз, биз ар кандай мониторинг системасы сыяктуу эле, акыркы күнү окуу сурамдарынын көбүн сезебиз. Бирок, ошол эле учурда, тарыхый маалыматтар боюнча жүк да абдан чоң. Бул, негизинен, ар бир отуз секундда айланып, ClickHouseга мындай дейт: “Мага акыркы алты жумадагы маалыматтарды бер. Эми мага алардан кандайдыр бир кыймылдуу орточо көрсөткүчтү түзүңүз, келгиле, учурдагы бааны тарыхый менен салыштырып көрөлү.
Мындай акыркы суроо-талаптар үчүн бизде эки гана күндүк маалыматтарды сактаган дагы бир кичинекей таблица бар экенин айткым келет жана ага негизги суроо-талаптар кирет. Биз чоң тарыхый суроо-талаптарды чоң сынган үстөлгө гана жөнөтөбүз.
Алексей Миловидов: Тилекке каршы, бул сиздин сценарийиңизге анча ылайыктуу эмес болуп чыкты, бирок мен сизге колдонуунун кереги жок, бирок менин досторумдун кызматында колдонулган эки жаман жана татаал бөлүү схемасынын сүрөттөмөсүн айтып берем.
Yandex.Metrica окуялары менен негизги кластер бар. Окуялар баракты көрүү, чыкылдатуулар жана конверсиялар. Көпчүлүк өтүнүчтөр белгилүү бир веб-сайтка барат. Сиз Yandex.Metrica кызматын ачасыз, сизде веб-сайт бар - avito.ru, отчетко өтүңүз жана веб-сайтыңызга суроо-талап жасалат.
Бирок ички аналитиктер тарабынан жасалган аналитикалык жана глобалдык башка суроо-талаптар бар. Болгондо да, мен ички аналитиктер Яндекс кызматтарына гана суроо-талаптарды беришерин белгилейм. Бирок, ошентсе да, ал тургай Яндекс кызматтары бардык маалыматтардын олуттуу үлүшүн ээлейт. Бул атайын эсептегичтер үчүн эмес, кененирээк чыпкалоо үчүн өтүнүчтөр.
Бир эсептегич үчүн, ошондой эле глобалдык суроо-талаптар үчүн бардыгы натыйжалуу иштей тургандай маалыматтарды кантип уюштуруу керек? Дагы бир кыйынчылык, Metrics кластери үчүн ClickHouse сурамдарынын саны секундасына бир нече миңди түзөт. Ошол эле учурда, бир ClickHouse сервери маанилүү эмес суроо-талаптарды аткара албайт, мисалы, секундасына бир нече миң.
Кластердин көлөмү алты жүздөй сервер. Эгерде сиз жөн гана бул кластердин үстүнө Бөлүштүрүлгөн таблицаны тартсаңыз жана ал жакка бир нече миң сурам жөнөтсөңүз, бул аларды бир серверге жөнөтүүдөн да жаман болуп калат. Экинчи жагынан, маалыматтар бир калыпта жайылып, биз барып, бардык серверлерден сурайбыз деген вариант дароо четке кагылган.
Диаметралдык карама-каршы болгон вариант бар. Элестеткиле, биз сайттар боюнча маалыматтарды бөлүштүрсөк жана бир сайтка суроо-талап бир сыныкка барат. Эми кластер секундасына он миң суроону аткара алат, бирок бир сыныкта каалаган бир суроо өтө жай иштейт. Ал мындан ары өткөрүү жөндөмдүүлүгү жагынан масштабдуу болбойт. Айрыкча, бул avito.ru сайты болсо. Avito RuNetтин эң көп кирген сайттарынын бири десем, сырды ачпайм. Ал эми аны бир сыныкта иштетүү акылсыздык болмок.
Ошондуктан, сынык схемасы алда канча куураак жол менен иштелип чыккан. Бүт кластер бир катар кластерлерге бөлүнөт, аларды биз катмар деп атайбыз. Ар бир кластер ондон бир нече ондогон сыныктарды камтыйт. Жалпысынан отуз тогуз мындай кластер бар.
Мунун баары кандай масштабда? Кластерлердин саны өзгөрбөйт - бир нече жыл мурун отуз тогуз болгон сыяктуу, ошол бойдон калууда. Бирок алардын ар биринин ичинде биз маалыматтарды топтоо менен акырындык менен сыныктардын санын көбөйтөбүз. Жана жалпысынан sharding схемасы мындай: бул кластерлер веб-сайттарга бөлүнөт жана кайсы веб-сайт кайсы кластерде экенин түшүнүү үчүн MySQLде өзүнчө метабаза колдонулат. Бир сайт - бир кластерде. Ал эми анын ичинде, сыныктар коноктордун идентификаторлоруна ылайык болот.
Жазып жатканда, биз аларды коноктун идентификаторунун калган бөлүгүнө бөлөбүз. Бирок жаңы сыныктарды кошкондо, бөлүү схемасы өзгөрөт; биз бөлүүнү улантабыз, бирок бөлүүнүн калган бөлүгү менен башка санга. Бул бир зыяратчы мурунтан эле бир нече серверлерде жайгашканын билдирет жана буга ишене албайсыз. Бул маалыматтардын жакшыраак кысылышын камсыз кылуу үчүн гана жасалат. Ал эми суроо-талаптарды жасап жатканда, кластерди карап, ондогон серверлерге кире турган Бөлүштүрүлгөн таблицага өтөбүз. Бул ушунчалык келесоо схема.
Бирок бул схемадан баш тарттык деп айтпасам, менин окуям толук эмес болуп калат. Жаңы схемада биз бардыгын өзгөрттүк жана бардык маалыматтарды clickhouse-copier аркылуу көчүрдүк.
Жаңы схемада бардык сайттар эки категорияга бөлүнөт - чоң жана кичине. Босого кантип тандалганын билбейм, бирок натыйжада чоң сайттар бир кластерде жазылган, мында ар биринде үч репликалуу 120 сынык бар, башкача айтканда, 360 сервер. Ал эми бөлүү схемасы ушундай, каалаган сурам бир эле учурда бардык сыныктарга кетет. Эгерде сиз азыр Yandex.Metrica сайтында avito.ru үчүн кандайдыр бир отчет баракчасын ачсаңыз, сурам 120 серверге барат. RuNetте бир нече чоң сайттар бар. Ал эми суроо-талаптар секундасына миң эмес, жүздөн да аз. Мунун бардыгы 120 сервер менен иштетилген Бөлүштүрүлгөн таблицада акырын чайналат.
Ал эми экинчи кластер чакан сайттар үчүн. Бул жерде сайттын идентификаторуна негизделген sharding схемасы жана ар бир суроо так бир сыныкка барат.
ClickHouse'тун кликхаус-көчүрмө программасы бар. Ал тууралуу айтып бере аласызбы?
Мен дароо айтам, бул чечим кыйла түйшүктүү жана бир аз жемиштүү эмес. Артыкчылыгы - ал сиз көрсөткөн үлгүгө ылайык маалыматтарды толугу менен сүртөт. Бирок, утилитанын кемчилиги - ал такыр эле майдаланбайт. Ал бир кластердик схемадан башка кластер схемасына маалыматтарды көчүрөт.
Бул анын иштеши үчүн эки кластер болушу керек дегенди билдирет. Алар бир эле серверлерде жайгаша алат, бирок, ошентсе да, маалыматтар кадам сайын жылдырылбайт, бирок көчүрүлөт.
Мисалы, төрт сервер болсо, азыр сегиз. Сиз бардык серверлерде жаңы Бөлүштүрүлгөн таблицаны, жаңы локалдык таблицаларды түзөсүз жана анда ал жерден окуй турган иш схемасын көрсөтүп, жаңы бөлүү схемасын кабыл алып, маалыматтарды ошол жерге өткөрүп берүү менен кликхаус-көчүрүүчүнү ишке киргизесиз. Ал эми эски серверлерде сизге азыркыга караганда бир жарым эсе көп орун керек болот, анткени аларда эски маалыматтар калышы керек жана ошол эле эски маалыматтардын жарымы алардын үстүнө келет. Эгер сиз алдын ала маалыматтарды кайра бөлүштүрүү керек деп ойлогон болсоңуз жана мейкиндик бар болсо, анда бул ыкма ылайыктуу.
Clickhouse-көчүрүүчү машинанын ичинде кантип иштейт? Ал бардык ишти бир столдун бир бөлүгүн бир сыныкта иштетүү үчүн тапшырмалардын жыйындысына бөлөт. Бул тапшырмалардын бардыгы параллелдүү аткарылышы мүмкүн, ал эми клик-көчүрүүчү аппаратты ар кандай машиналарда бир нече инстанцияларда иштетсе болот, бирок анын бир бөлүм үчүн кылганы кыстаруу тандоодон башка нерсе эмес. Маалыматтар окулат, декомпрессияланат, кайра бөлүштүрүлөт, андан кийин кайра кысылып, бир жерге жазылат жана кайра сорттолот. Бул катуураак чечим.
Сизде resharding деген пилоттук нерсе бар эле. Аны менен эмне болот?
2017-жылы сизде resharding деп аталган пилоттук нерсе болгон. 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 бар. Биздин тест чөйрөбүз ал үчүн - бул жыйырма еврого Hetzner кичинекей виртуалдык машина, анда таптакыр баары жайгаштырылган. Бул үчүн, бизде Ansibleде толук автоматташтыруу бар, ошондуктан, негизинен, кайда баруу - аппараттык серверлерге же виртуалдык машиналарда жайгаштыруу эч кандай айырмасы жок.
Эмне кылса болот? ClickHouse документациясында кичинекей кластерди өз үйүңүздө - Dockerде, LXCде кантип жайгаштыруу керектиги жөнүндө мисал келтирсеңиз жакшы болмок, балким Ansible окуу китебин түзүңүз, анткени ар кандай адамдар ар кандай жайгаштырууга ээ. Бул көп нерсени жөнөкөйлөтөт. Кластерди беш мүнөттүн ичинде алып, жайгаштырганыңызда, бир нерсени аныктоого аракет кылуу оңой болот. Бул алда канча ыңгайлуу, анткени сиз сынай элек өндүрүш версиясына өтүү эч жакка барбайт. Кээде иштейт, кээде иштебейт. Демек, ийгиликке үмүт кылуу жаман.
Максим Котяков, улук инженер Авито: Мен ири компаниялар туш болгон бир катар көйгөйлөрдүн ичинен тест чөйрөлөрү жөнүндө бир аз кошумчалайм. Бизде толук кандуу ClickHouse кабыл алуу кластери бар; маалымат схемалары жана орнотуулары боюнча, бул өндүрүштөгү нерсенин так көчүрмөсү. Бул кластер эң аз ресурстары бар кыйла жараксыз контейнерлерде жайгаштырылган. Биз өндүрүш маалыматтарынын белгилүү бир пайызын ошол жерге жазабыз, бактыга жараша Кафкадагы агымды кайталоого болот. Ал жерде бардыгы синхрондоштурулган жана масштабдуу - кубаттуулугу жана агымы боюнча да, теориялык жактан алганда, бардык башка нерселер бирдей болгондо, ал метрика боюнча өндүрүш сыяктуу иштеши керек. Жардыргыч болушу мүмкүн болгон нерселердин баары алгач бул стендге тоголонуп, даяр болгонго чейин бир нече күнгө калтырылат. Бирок, албетте, бул чечим кымбат, кыйын жана нөл эмес колдоо чыгымдары бар.
Алексей Миловидов: Яндекс.Метрикадагы досторубуздун сыноо чөйрөсү кандай экенин айтып берем. Бир кластерде 600, экинчисинде 360, үчүнчү жана бир нече кластер бар. Алардын бири үчүн сыноо чөйрөсү ар биринде эки репликасы бар эки сынык. Эмне үчүн эки сынык? Ошентип, сен жалгыз эмессиң. Жана ошондой эле көчүрмөлөрү болушу керек. Сиз көтөрө ала турган белгилүү бир минималдуу сумма.
Бул тестирлөө чөйрөсү сиздин сурамдарыңыз иштеп жатканын жана олуттуу бир нерсе бузулганын текшерүүгө мүмкүндүк берет. Бирок көп учурда көйгөйлөр такыр башка мүнөздө пайда болот, качан баары иштейт, бирок жүктө кээ бир кичинекей өзгөрүүлөр болот.
Мен бир мисал келтирейин. Биз ClickHouse жаңы версиясын орнотууну чечтик. Ал тестирлөө чөйрөсүндө жайгаштырылган, Яндекс.Метриканын өзүндө автоматташтырылган тесттер бүткөрүлгөн, алар эски жана жаңы версия боюнча маалыматтарды салыштырып, бүт түтүктү иштетет. Жана, албетте, биздин CI жашыл тесттер. Болбосо биз бул версияны сунуштабайт элек.
Баары сонун. Биз өндүрүшкө өтө баштайбыз. Мен графиктердеги жүк бир нече эсе көбөйдү деген кабарды алам. Биз версияны артка жылдырып жатабыз. Мен графикти карап көрөм: жүк чындыгында жайылтуу учурунда бир нече эсеге көбөйдү жана алар чыкканда кайра азайды. Андан кийин биз версияны артка жылдырып баштадык. Ал эми жүк да ошентип көбөйүп, кайра кулады. Ошентип, тыянак мындай: жүк улам макет көбөйдү, таң калыштуу эч нерсе жок.
Анан кесиптештерди жаңы версияны орнотууга көндүрүү кыйынга турду. Мен: «Эч нерсе эмес, чыгып кет. Манжаларыңызды кайчылаштырыңыз, баары иштейт. Азыр графиктерге жүктөм көбөйдү, бирок баары жакшы. Ошол жерде тургула." Жалпысынан алганда, биз муну кылдык, ушуну менен бүттү - версия өндүрүш үчүн чыгарылган. Бирок дээрлик ар бир макет менен окшош көйгөйлөр пайда болот.
Өлтүрүү суроосу сурамдарды жок кылышы керек, бирок андай эмес. Неге?
Колдонуучу, кандайдыр бир аналитик, мага келип, менин ClickHouse кластерин койгон өтүнүчтү түздү. Сурам кайсы репликага же сыныкка кеткенине жараша кээ бир түйүн же бүтүндөй кластер. Бул сервердеги бардык CPU ресурстары текчеде экенин көрүп турам, баары кызыл. Ошол эле учурда 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 конфигурация файлында, кысылбаган кэш өлчөмүн керектүү мааниге коюңуз - мен бош RAMдын жарымынан көбүн сунуштайм, анткени калганы барактын кэшинин астында калат.
Мындан тышкары, эки суроо-деңгээл орнотуулары бар. Биринчи жөндөө - кысылбаган кэш колдонуу - аны пайдаланууну камтыйт. Аны бардык маалыматтарды окуй турган жана кэшти тазалай турган оор сурамдар үчүн иштетүү сунушталат. Ал эми экинчи жөндөө кэшти колдонуу үчүн саптардын максималдуу саны сыяктуу бир нерсе. Ал кэшти айланып өтүшү үчүн чоң сурамдарды автоматтык түрдө чектейт.
Сактагыч_конфигурациясын RAMда сактоо үчүн кантип конфигурациялай алам?
Жаңы ClickHouse документтеринде мен тиешелүү бөлүмдү окудум . Сүрөттөмө тез SSD менен мисалды камтыйт.
Мен бир эле нерсени көлөмдүү ысык эс менен кантип конфигурациялоого болот деп ойлоп жатам. Жана дагы бир суроо. Тандоо бул маалымат уюму менен кантип иштейт, ал бүт топтомун окуйбу же дискте турганды гана окуйбу жана бул маалымат эстутумда кысылганбы? Ал эми алдын ала бөлүм мындай маалымат уюму менен кантип иштейт?
Бул жөндөө маалымат бөлүктөрүн сактоого таасирин тийгизет жана алардын форматы эч кандай өзгөрбөйт.
Келгиле, кененирээк карап көрөлү.
Сиз RAMдагы маалыматтарды сактоону конфигурациялай аласыз. Диск үчүн конфигурацияланган бардык нерсе - анын жолу. Сиз файл тутумундагы кандайдыр бир жолго орнотулган tmpfs бөлүмүн түзөсүз. Сиз бул жолду эң ысык бөлүмгө маалыматтарды сактоо жолу катары белгилейсиз, маалыматтар да келип, ошол жерге жазыла баштайт, баары жакшы.
Бирок мен ишенимдүүлүгү төмөн болгондуктан муну сунуштабайм, бирок ар кандай маалымат борборлорунда жок дегенде үч репликаңыз болсо, анда бул мүмкүн. Эгер бир нерсе болсо, маалыматтар калыбына келтирилет. Келгиле, сервер күтүлбөгөн жерден өчүрүлүп, кайра күйгүзүлгөнүн элестетип көрөлү. Бөлмө кайрадан орнотулду, бирок ал жерде эч нерсе жок болчу. ClickHouse сервери башталганда, ал бул бөлүктөргө ээ эмес экенин көрөт, бирок ZooKeeper метадайындарына ылайык, алар ошол жерде болушу керек. Ал алардын кайсы репликалары бар экенин карап, сурайт жана жүктөп алат. Бул жол менен маалыматтар калыбына келтирилет.
Бул жагынан алганда, оперативдүү эстутумда маалыматтарды сактоо аны дискте сактоодон принципиалдуу түрдө айырмаланбайт, анткени маалыматтар дискке жазылганда, ал да адегенде барактын кэшинде бүтөт жана физикалык түрдө кийинчерээк жазылат. Бул файл тутумун орнотуу опциясына жараша болот. Бирок, кандайдыр бир учурда, мен ClickHouse киргизип жатканда fsync эмес деп айтам.
Мында оперативдик эстутумдагы маалыматтар так дисктеги форматта сакталат. Тандоо суроосу да окула турган бөлүктөрдү тандайт, бөлүктөрдөгү керектүү маалымат диапазондорун тандап, аларды окуйт. Ал эми prewhere маалыматтар оперативдүү эсте же дискте болгонуна карабастан, дал ушундай иштейт.
Low Cardinality уникалдуу баалуулуктардын канча санына чейин натыйжалуу?
Low Cardinality акылдуу түрдө иштелип чыккан. Ал маалымат сөздүктөрүн түзөт, бирок алар жергиликтүү. Биринчиден, ар бир кесим үчүн ар кандай сөздүктөр бар, экинчиден, бир кесимдин ичинде да алар ар бир диапазон үчүн ар кандай болушу мүмкүн. Качан уникалдуу баалуулуктардын саны босого санга жеткенде - бир миллион, мен ойлойм - сөздүк жөн эле сакталып, жаңысы түзүлөт.
Жооп жалпысынан: ар бир жергиликтүү диапазон үчүн - айталы, ар бир күн үчүн - бир жерде миллионго чейин уникалдуу баалуулуктар Төмөн Кардиналдуулук натыйжалуу. Андан кийин бир эле сөздүктөр эмес, көптөгөн ар кандай сөздүктөр колдонулат. Ал болжол менен кадимки сап мамычасы менен бирдей иштейт, балким, бир аз натыйжалуураак болушу мүмкүн, бирок майнаптуулуктун олуттуу начарлашы болбойт.
Беш миллиард саптан турган таблицада толук текстти издөө үчүн кандай мыкты тажрыйбалар бар?
Ар кандай жооптор бар. Биринчиси, ClickHouse толук тексттик издөө системасы эмес деп айтуу. Бул үчүн атайын системалар бар, мисалы, и . Бирок, мен барган сайын Elasticsearch'тен ClickHouseга которулуп жатканын айтып жатышканын көрүп жатам.
Эмне үчүн мындай болуп жатат? Алар муну Elasticsearch индекстерди куруудан баштап, кээ бир көлөмдөгү жүктү көтөрө албай калганы менен түшүндүрүшөт. Индекстер өтө түйшүктүү болуп калат, эгер сиз жөн гана маалыматтарды ClickHouseга өткөрүп берсеңиз, анда алар көлөмү жагынан бир нече эсе эффективдүү сакталат экен. Ошол эле учурда, издөө сурамдары көп учурда морфологияны эске алуу менен маалыматтардын бардык көлөмүндө кандайдыр бир фразаны табуу зарыл болгон эмес, бирок такыр башка. Мисалы, акыркы бир нече сааттагы журналдардан байттардын кээ бир ырааттуулугун табыңыз.
Бул учурда, сиз ClickHouse ичинде индексти түзөсүз, анын биринчи талаасы датасы жана убактысы болот. Ал эми эң чоң маалымат кесилиши даталар диапазонуна негизделет. Тандалган даталар диапазонунда, эреже катары, лайкты колдонуу менен катаал күч ыкмасын колдонуу менен да толук тексттик издөөнү жүргүзүүгө болот. ClickHouseдагы окшош оператор сиз таба турган эң эффективдүү окшош оператор. Эгер жакшыраак нерсе тапсаңыз, айтыңыз.
Ошентсе да, толук сканерлөө сыяктуу. Жана толук сканерлөө процессордо гана эмес, дискте да жай болушу мүмкүн. Эгер күтүлбөгөн жерден сизде күнүнө бир терабайт маалымат болуп, күндүз бир сөздү издесеңиз, анда терабайтты сканерден өткөрүшүңүз керек болот. Жана бул кадимки катуу дисктерде болсо керек жана аягында алар SSH аркылуу бул серверге кире албай тургандай жүктөлөт.
Бул учурда мен дагы бир кичинекей трюк сунуштоого даярмын. Бул эксперименталдык - бул иштеши мүмкүн, жок болушу мүмкүн. ClickHouse триграмм Блум чыпкалары түрүндөгү толук тексттик индекстерге ээ. Arenadataдагы биздин кесиптештер бул индекстерди буга чейин эле сынап көрүшкөн жана алар көбүнчө ойдогудай иштешет.
Аларды туура колдонуу үчүн, алардын так кантип иштешин жакшы түшүнүшүңүз керек: Блум чыпкасы деген эмне жана анын өлчөмүн кантип тандоо керек. Алар маалыматтарда сейрек кездешүүчү кээ бир сейрек фразалар, субсаптар боюнча суроолорго жардам берет деп айта алам. Бул учурда, суб диапазон индекстер боюнча тандалып алынат жана азыраак маалымат окулат.
Жакында ClickHouse толук текстти издөө үчүн дагы өркүндөтүлгөн функцияларды кошту. Бул, биринчиден, бир өтүүдө дароо бир топ ички саптарды издөө, анын ичинде регистрге, регистрге сезимтал эмес, UTF-8 же ASCII үчүн гана колдоо бар варианттар. Эң эффективдүүсүн тандаңыз.
Бир өтүүдө бир нече туруктуу сөз айкаштарын издөө да пайда болду. Xти бир подсап сыяктуу же Xти башка подсап сыяктуу жазуунун кереги жок. Сиз дароо жазасыз жана бардыгы мүмкүн болушунча натыйжалуу жасалат.
Үчүнчүдөн, азыр regexps үчүн болжолдуу издөө жана субсаптар үчүн болжолдуу издөө бар. Эгер кимдир бирөө сөздү туура эмес жазса, ал эң көп дал келген сөздү издейт.
Колдонуучулардын көп саны үчүн ClickHouse мүмкүнчүлүгүн уюштуруунун эң жакшы жолу кайсы?
Көптөгөн керектөөчүлөр жана аналитиктер үчүн жеткиликтүүлүктү кантип мыкты уюштуруу керектигин айтыңыз. Кантип кезек түзүү керек, максимум бир убактагы суроо-талаптарга артыкчылык берүү жана кандай куралдар менен?
Эгерде кластер жетишерлик чоң болсо, анда дагы эки серверди көтөрүү жакшы чечим болуп калат, алар аналитиктердин кирүү чекити болуп калат. Башкача айтканда, аналитиктерге кластердеги белгилүү бир сыныктарга кирүүгө уруксат бербеңиз, жөн гана маалыматсыз эки бош серверди түзүп, аларга кирүү укуктарын конфигурациялаңыз. Бул учурда, бөлүштүрүлгөн суроо-талаптар үчүн колдонуучунун орнотуулары алыскы серверлерге өткөрүлүп берилет. Башкача айтканда, сиз бул эки серверде бардыгын конфигурациялайсыз жана орнотуулар бүткүл кластерге таасирин тийгизет.
Негизи, бул серверлерде маалымат жок, бирок алардагы оперативдүү эс тутумдун көлөмү суроо-талаптарды аткаруу үчүн абдан маанилүү. Сырткы топтоо же тышкы сорттоо иштетилген болсо, дискти убактылуу маалымат үчүн да колдонсо болот.
Бул мүмкүн болгон бардык чектөөлөр менен байланышкан орнотууларды карап чыгуу маанилүү. Мен азыр аналитик катары Yandex.Metrica кластерине барып, суроо берсем хиттерден санды тандаңыз, анда мага дароо эле өтүнүчтү аткара албай турган өзгөчөлүк берилет. Мага сканерлөө үчүн уруксат берилген катарлардын максималдуу саны жүз миллиард жана кластердеги бир таблицада алардын элүү триллиону бар. Бул биринчи чектөө болуп саналат.
Мен катар чегин алып салып, суроону кайра иштеттим дейли. Андан кийин мен төмөнкү өзгөчөлүктү көрөм - параметр иштетилген датасы боюнча күч индекси. Даталар диапазонун көрсөтпөгөн болсом, суроону аягына чыгара албайм. Аны кол менен тактоо үчүн аналитиктерге таянуунун кереги жок. Кадимки учур - бул даталар диапазону жуманын ортосундагы окуя датасы жазылган жерде. Анан алар жөн гана туура эмес жерде кашаа көрсөтүштү жана анын ордуна же - же URL дал келүү болуп чыкты. Эгер эч кандай чектөө жок болсо, ал URL тилкесин кыдырып, бир тонна ресурстарды текке кетирет.
Мындан тышкары, ClickHouse эки артыкчылыктуу орнотуулары бар. Тилекке каршы, алар абдан примитивдүү. Бири жөн эле деп аталат артыкчылыктуу. Эгерде артыкчылык ≠ 0 болсо жана кандайдыр бир артыкчылыкка ээ болгон суроо-талаптар аткарылып жатса, бирок артыкчылык мааниси жогору болгон суроо-талап аткарылып жатса, анда артыкчылык мааниси жогору болгон суроо-талап аткарылып жатат, бул төмөнкү артыкчылыкты билдирет. , жөн гана токтотулган жана бул убакыттын ичинде такыр иштебейт.
Бул өтө одоно параметр жана кластер туруктуу жүктөмү бар учурларда ылайыктуу эмес. Бирок эгер сизде маанилүү кыска, жарылып кеткен суроо-талаптарыңыз болсо жана кластер негизинен бош болсо, бул орнотуу ылайыктуу.
Кийинки приоритеттүү жөндөө деп аталат OS жип приоритети. Ал жөн гана Linux пландаштыргычы үчүн бардык суроо-талаптарды аткаруу жиптери үчүн жакшы маанини коёт. Ал ушунчалык иштейт, бирок дагы эле иштейт. Эгер сиз минималдуу жакшы маанини койсоңуз - бул эң чоң маани, демек, эң төмөнкү артыкчылык - жана жогорку артыкчылыктуу суроо-талаптар үчүн -19 коюңуз, анда CPU артыкчылыктуу суроо-талаптарды жогорку артыкчылыктууларга караганда төрт эсе аз керектейт.
Сиз ошондой эле максималдуу суроо-талап аткаруу убактысын конфигурациялоо керек - айталы, беш мүнөт. Суроолорду аткаруунун минималдуу ылдамдыгы эң сонун нерсе. Бул жөндөө көптөн бери болуп келген жана ClickHouse басаңдабайт деп ырастоо үчүн гана эмес, аны мажбурлоо талап кылынат.
Элестетиңиз, сиз орнотуңуз: эгер кээ бир суроо секундасына бир миллион саптан азыраак иштесе, сиз муну кыла албайсыз. Бул биздин жакшы атыбызды, жакшы базабызды жаманатты кылат. Буга тыюу салалы. Чынында эки параметр бар. Бири деп аталат мин аткаруу ылдамдыгы - секундасына сапта, ал эми экинчи минимум аткаруу ылдамдыгын текшерүүгө чейин тайм-аут деп аталат - демейки боюнча он беш секунд. Башкача айтканда, он беш секунд мүмкүн, андан кийин, ал жай болсо, анда жөн гана өзгөчө ыргытып, өтүнүчтү токтотуу.
Сиз ошондой эле квоталарды түзүшүңүз керек. ClickHouse ресурстун керектөөсүн эсептеген квота өзгөчөлүгүнө ээ. Бирок, тилекке каршы, CPU, дисктер сыяктуу аппараттык ресурстар эмес, логикалык ресурстар - иштетилген сурамдардын, саптардын жана окулган байттардын саны. Жана сиз, мисалы, беш мүнөттүн ичинде эң көп жүз суроону жана саатына миң суроону конфигурациялай аласыз.
Бул эмне үчүн маанилүү? Анткени кээ бир аналитикалык сурамдар ClickHouse кардарынан түздөн-түз кол менен аткарылат. Бардыгы жакшы болот. Бирок сиздин компанияңызда алдыңкы аналитиктер болсо, алар сценарий жазат жана сценарийде ката болушу мүмкүн. Жана бул ката сурамдын чексиз циклде аткарылышына себеп болот. Мына ушундан өзүбүздү коргошубуз керек.
Бир суроонун жыйынтыгын он кардарга берсе болобу?
Бизде бир эле учурда абдан чоң суроо-талаптар менен келген бир нече колдонуучулар бар. Сураныч чоң жана, негизинен, тез аткарылат, бирок ошол эле учурда мындай суроо-талаптар көп болгондуктан, ал абдан ооруп калат. Он жолу катары менен келген бир эле өтүнүчтү бир жолу аткарып, жыйынтыгын он кардарга берсе болобу?
Маселе, бизде кэштин же ортодогу маалыматтардын кэшинин натыйжалары жок. Операциялык системанын бет кеши бар, ал сизге дисктен маалыматтарды кайра окууга жол бербейт, бирок, тилекке каршы, маалыматтар дагы эле декомпрессияланат, сериядан чыгарылат жана кайра иштетилет.
Мен муну кандайдыр бир жол менен болтургум келет, же ортодогу маалыматтарды кэштөө, же окшош сурамдарды кандайдыр бир кезекке тизип, натыйжалардын кэшин кошуу менен. Учурда бизде суроо кэшин кошо турган бир тартуу сурамыбыз бар, бирок кирүү жана кошулуу бөлүмдөрүндөгү подсуроолор үчүн гана, башкача айтканда, чечим толук эмес.
Бирок, мындай абалга биз да туш болуп жатабыз. Өзгөчө канондук мисал - баракчаланган сурамдар. Отчет бар, ал бир нече барактан турат жана 10-лимиге суроо-талап бар. Анан ошол эле нерсе, бирок чек 10,10. Андан кийин дагы бир кийинки бет. Анан эмне үчүн мунун баарын ар бир жолу эсептейбиз деген суроо туулат? Бирок азыр эч кандай чечим жок, андан качууга да жол жок.
ClickHouse жанында каптал катары коюлган альтернативалуу чечим бар - .
Кирилл Шваков: ClickHouse Proxy-де ылдамдыкты чектөөчү жана камтылган жыйынтык кэш бар. Ал жерде көптөгөн орнотуулар жасалган, анткени ушуга окшош маселе чечилип жаткан. Прокси суроо-талаптарды кезекке коюу менен чектөөгө жана сурам кэши канча убакытка чейин иштөөсүн конфигурациялоого мүмкүндүк берет. Эгерде суроо-талаптар чындап эле бирдей болсо, прокси аларды көп жолу жөнөтөт, бирок ClickHouseга бир гана жолу барат.
Nginxтин бекер версиясында да кэш бар жана бул да иштейт. Nginxтин жөндөөлөрү да бар, эгер суроо-талаптар бир эле убакта келип түшсө, бирөө аяктаганга чейин башкаларды жайлатат. Бирок ClickHouse проксиде орнотуу алда канча жакшыраак аткарылган. Бул атайын ClickHouse үчүн, атайын ушул суроо-талаптар үчүн жасалган, ошондуктан ал көбүрөөк ылайыктуу. Ооба, орнотуу оңой.
Асинхрондук операциялар жана материалдык көрүнүштөр жөнүндө эмне айтууга болот?
Кайталоо кыймылдаткычы менен операциялар асинхрондуу болгон көйгөй бар - адегенде маалыматтар жазылат, андан кийин ал кыйрайт. Эгер кандайдыр бир агрегаттары бар материалдашкан планшет белгинин астында жашаса, анда ага дубликаттар жазылат. Ал эми татаал логика жок болсо, анда маалыматтар кайталанат. Бул тууралуу эмне кыла аласыз?
Ачык чечим бар - асинхрондук коллапс операциясы учурунда белгилүү бир класстагы matviews боюнча триггерди ишке ашыруу. Окшош функцияны ишке ашыруу үчүн күмүш ок же пландар барбы?
Депликация кантип иштээрин түшүнүү керек. Мен азыр айта турган нерсе бул суроого тиешеси жок, бирок эстеп калуу керек болсо.
Репликацияланган таблицага киргизүүдө, толугу менен киргизилген блоктордун дедупликациясы болот. Эгерде сиз ошол эле катарлардын бирдей санын камтыган бир эле блокту ошол эле тартипте кайра киргизсеңиз, анда маалыматтар кайталанбайт. Кыстарууга жооп катары сиз "OK" аласыз, бирок чындыгында бир пакет маалымат жазылат жана ал кайталанбайт.
Бул ишенимдүүлүк үчүн зарыл. Кыстаруу учурунда "Макул" дегенди алсаңыз, анда сиздин дайындарыңыз киргизилген. Эгер сиз ClickHouseдан ката алсаңыз, анда алар киргизилген эмес жана сиз киргизүүнү кайталашыңыз керек дегенди билдирет. Бирок кыстаруу учурунда байланыш үзүлгөн болсо, анда маалыматтар киргизилгенби же жокпу билбейсиз. Жалгыз вариант - киргизүүнү кайра кайталоо. Эгер маалыматтар чындап киргизилген болсо жана сиз аны кайра киргизген болсоңуз, анда блоктун кайталанышы бар. Бул кайталанмаларды болтурбоо үчүн керек.
Ошондой эле анын материалдык көрүнүштөр үчүн кандайча иштээри да маанилүү. Эгерде маалыматтар негизги таблицага киргизилгенде дедупликацияланган болсо, анда ал материалдашкан көрүнүшкө да кирбейт.
Эми суроо жөнүндө. Сиздин абалыңыз татаалыраак, анткени сиз жеке саптардын дубликатын жазып жатасыз. Башкача айтканда, бүтүндөй пакет эмес, конкреттүү сызыктар кайталанып, алар фондо кулап калат. Чынында эле, маалыматтар негизги таблицада кыйрайт, бирок урабаган маалыматтар материалдашкан көрүнүшкө өтөт, ал эми бириктирүү учурунда материалдашкан көрүнүштөр менен эч нерсе болбойт. Анткени материалдашкан көрүнүш - бул киргизүү триггеринен башка эч нерсе эмес. Башка операциялар учурунда ага кошумча эч нерсе болбойт.
А мен сени бул жерде бактылуу кыла албайм. Сиз жөн гана бул иш үчүн конкреттүү чечим издөө керек. Мисалы, аны материалдашкан көрүнүштө кайра ойнотуу мүмкүнбү, жана дедупликация ыкмасы да ушундай иштеши мүмкүн. Бирок, тилекке каршы, дайыма эмес. Ал топтоо болсо, анда ал иштебейт.
Кирилл Шваков: Бизде дагы ошол кезде балдак курган болчу. Жарнамалык таасирлер бар, ал эми биз реалдуу убакытта көрсөтө турган кээ бир маалыматтар бар - бул жөн гана таасирлер. Алар сейрек кайталанат, бирок мындай болуп кетсе, биз аларды баары бир кийинчерээк кыйратабыз. Жана кайталанбай турган нерселер бар болчу - чыкылдатуулар жана бул окуя. Бирок мен аларды дээрлик дароо көрсөткүм келди.
Материалдык көз караштар кандайча жасалган? Түздөн-түз жазылган – чийки маалыматтарга жазылган, көрүүлөргө жазылган көз караштар болгон. Ал жерде, кайсы бир учурда маалыматтар абдан туура эмес, кайталанат ж.б.у.с. Жана таблицанын экинчи бөлүгү бар, анда алар материалдашкан көз караштарга так окшош, башкача айтканда, түзүлүшү боюнча таптакыр окшош. Бир маалда биз маалыматтарды кайра эсептейбиз, маалыматтарды кайталанбастан санайбыз, ошол таблицаларга жазабыз.
Биз API аркылуу өттүк - бул ClickHouse кол менен иштебейт. Ал эми API көрүнөт: менде таблицага акыркы толуктоо датасы болгондо, анда туура маалыматтар буга чейин эсептелгенине кепилдик берилет жана ал бир таблицага жана башка таблицага суроо-талап кылат. Биринен суроо белгилүү бир убакытка чейин тандайт, экинчисинен али эсептеле элек нерсени алат. Ал иштейт, бирок ClickHouse аркылуу гана эмес.
Эгер сизде кандайдыр бир API бар болсо - аналитиктер үчүн, колдонуучулар үчүн - анда, негизинен, бул вариант. Дайыма эсептейсиң, ар дайым эсептейсиң. Муну күнүнө бир жолу же башка убакта жасаса болот. Сиз өзүңүзгө керексиз жана критикалык эмес диапазонду тандайсыз.
ClickHouseда көптөгөн журналдар бар. Серверде болуп жаткан нерселердин баарын бир караганда кантип көрө алам?
ClickHouse ар кандай журналдардын өтө көп санына ээ жана бул сан өсүп жатат. Жаңы версияларда алардын айрымдары демейки боюнча иштетилет; эски версияларда жаңыртуу учурунда иштетилиши керек. Бирок, алардын саны барган сайын көбөйүүдө. Акыр-аягы, мен азыр серверим менен эмне болуп жатканын көргүм келет, балким, кандайдыр бир жыйынтыктоочу панелде.
Сизде ClickHouse командасы же досторуңуздун командалары барбы, алар бул журналдарды даяр продукт катары көрсөтө турган даяр панелдердин айрым функцияларын колдойбу? Акыр-аягы, ClickHouseдагы журналдарды карап чыгуу сонун. Бирок, ал буга чейин тактай түрүндө даярдалган болсо, абдан сонун болмок. Мен андан тепкилеп алмакмын.
Алар стандартташтырылбаганы менен башкаруу такталары бар. Биздин компанияда 60ка жакын команда ClickHouse колдонушат, эң таң калычтуусу, алардын көбүнүн өздөрү үчүн жасаган башкаруу такталары жана бир аз башкачараактары бар. Кээ бир командалар ички Yandex.Cloud орнотуусун колдонушат. Керектүүлөрдүн баары болбосо да, даяр отчеттор бар. Башкалардын өздөрүнүн бар.
Менин Metricaдагы кесиптештеримдин Графанада өздөрүнүн башкаруу панели бар, менде алардын кластери үчүн өзүмдүн панелим бар. Мен сериф кэш үчүн кэш хит сыяктуу нерселерди карап жатам. Андан да кыйыны, биз ар кандай куралдарды колдонобуз. Мен Graphite-web деп аталган абдан эски куралды колдонуп, өзүмдүн башкаруу тактамды түздүм. Ал толугу менен чиркин. Мен дагы деле ушундай жол менен колдоном, бирок Grafana ыңгайлуураак жана сулуураак болмок.
Куралдар такталарындагы негизги нерсе бирдей. Бул кластер үчүн системалык көрсөткүчтөр: CPU, эстутум, диск, тармак. Башкалары - бир убактагы суроо-талаптардын саны, бир убактагы бириктирүүлөрдүн саны, секундасына суроо-талаптардын саны, MergeTree таблицасынын бөлүктөрүнүн максималдуу саны, репликациянын артта калуусу, репликация кезегинин өлчөмү, секундасына киргизилген саптардын саны, секундасына киргизилген блоктордун саны. Мунун баары журналдардан эмес, метрикадан алынат.
Владимир Колобаев: Алексей, мен бир аз оңдоп койгум келет. Графана бар. Grafana маалымат булагы бар, ал ClickHouse. Башкача айтканда, мен Grafanaдан түздөн-түз ClickHouse'га суроо бере алам. ClickHouse журналдары менен таблицага ээ, ал баарына бирдей. Натыйжада, мен Grafanaдагы бул журнал таблицасына киргим келет жана серверим жасаган суроо-талаптарды көргүм келет. Ушундай тактоо тактасы болсо жакшы болмок.
Мен өзүм велосипед айдадым. Бирок менде бир суроо бар - эгерде бардыгы стандартташтырылган болсо жана Grafana бардыгы тарабынан колдонулса, эмне үчүн Яндексте мындай расмий башкаруу панели жок?
Кирилл Шваков: Чындыгында, ClickHouse-га барган маалымат булагы азыр Altinity-ди колдойт. А мен жөн гана кайсы жерди казып, кимди түртүш керек дегендин векторун айткым келет. Сиз алардан сурасаңыз болот, анткени Яндекс дагы эле анын тегерегиндеги окуяны эмес, ClickHouse жасайт. Altinity учурда ClickHouse промоушн негизги компания болуп саналат. Алар аны таштабайт, тескерисинче, колдошот. Анткени, негизи, Grafana веб-сайтына башкаруу тактасын жүктөө үчүн, сиз жөн гана катталып, аны жүктөшүңүз керек - өзгөчө көйгөйлөр жок.
Алексей Миловидов: Өткөн жылдын ичинде ClickHouse көптөгөн суроо профилин түзүү мүмкүнчүлүктөрүн кошту. Ресурстарды колдонуу боюнча ар бир суроо үчүн көрсөткүчтөр бар. Жана жакында эле биз суроонун миллисекунд сайын кайда жумшап жатканын көрүү үчүн андан да төмөнкү деңгээлдеги суроо профилдерин коштук. Бирок бул функцияны колдонуу үчүн мен консолдун кардарын ачып, ар дайым унутуп калган өтүнүчтү теришим керек. Мен аны бир жерге сактап коюп, так кайда унутуп калам.
Бул жерде сиздин оор суроолоруңуз, суроо классы боюнча топтоштурулган деп айткан курал болушун каалайм. Мен бирөөсүн бастым, алар мага бул оор экенин айтышчу. Азыр андай чечим жок. Адамдар менден: “Айтчы, Grafana үчүн даяр панелдер барбы?” деп сурашканда, мен: “Grafana веб-сайтына кириңиз, ал жерде “Подборддор” коомчулугу бар, ал жерде башкаруу тактасы бар экени таң калыштуу. Димкадан, Костяндан приборлор тактасы бар. Эмне экенин билбейм, мен өзүм колдонгон эмесмин».
Сервер OOMга кулап калбашы үчүн биригүүлөргө кантип таасир этсе болот?
Менде үстөл бар, таблицада бир гана бөлүм бар, ал ReplacingMergeTree. Мен ага төрт жылдан бери маалыматтарды жазып келем. Мен ага өзгөртүү киргизип, кээ бир маалыматтарды жок кылышым керек болчу.
Мен муну жасадым жана бул суроону иштеп чыгуу учурунда кластердеги бардык серверлердеги эстутумдун баары түгөнүп, кластердеги бардык серверлер OOMга кирди. Анан баары чогуу туруп, ушул эле операцияны, бул маалымат блогун бириктире башташты жана кайрадан ООМго түштү. Анан кайра ордунан туруп, кайра жыгылды. Жана бул нерсе токтогон жок.
Анан бул чындыгында жигиттер оңдогон мүчүлүштүк экени белгилүү болду. Бул абдан сонун, чоң рахмат. Бирок калдык калды. Эми, мен таблицада кандайдыр бир бириктирүү жөнүндө ойлонуп жатканда, менде суроо пайда болду - эмне үчүн мен бул биригүүлөргө кандайдыр бир таасир бере албайм? Мисалы, аларды талап кылынган оперативдик эстутумдун көлөмү менен же, негизинен, ушул таблицаны иштете турган сумма менен чектеңиз.
Менде "Метрика" деген таблица бар, сураныч, аны мен үчүн эки жипте иштетиңиз. Параллелдүү он же беш биригүүнү түзүүнүн кереги жок, аны экиден кылыңыз. Мен эки эстутум жетиштүү деп ойлойм, бирок онду иштетүү үчүн жетишсиз болушу мүмкүн. Эмне үчүн коркуу сакталып турат? Анткени таблица өсүп жатат жана качандыр бир күнү мен бир жагдайга туш болом, бул, негизинен, мүчүлүштүктөргө байланыштуу эмес, бирок маалыматтар ушунчалык чоң өлчөмдө өзгөрүп кеткендиктен, менде эстутум жетишсиз болуп калат. сервер. Ошондо сервер бириктирилгенде OOMга кыйрап калат. Анын үстүнө, мен мутацияны жокко чыгара алам, бирок Мержи жок.
Билесизби, биригүү учурунда сервер OOMга түшпөйт, анткени биригүү учурунда оперативдүү эстутумдун көлөмү бир аз маалымат диапазону үчүн гана колдонулат. Ошентип, маалыматтардын көлөмүнө карабастан, баары жакшы болот.
Владимир Колобаев: Жакшы. Бул жерде, ката оңдолгондон кийин, мен өзүм үчүн жаңы версияны жүктөп алдым, ал эми башка столдо, көп бөлүмдөр бар кичирээк столдо мен ушундай операцияны жасадым. Ал эми бириктирүү учурунда серверде болжол менен 100 ГБ оперативдүү эс күйүп кеткен. Мен 150 ээлеп, 100 жеп, 50 ГБ терезе калды, ошондуктан мен ООМго түшкөн жокмун.
Учурда 100 ГБ оперативдүү эстутум керектесе, мени OOMга түшүп калуудан эмне коргойт? Күтүлбөгөн жерден биригүүдөгү RAM түгөнүп калса, эмне кылуу керек?
Алексей Миловидов: Биригүү үчүн атайын оперативдүү эстутум керектөө чектелген эмес, мындай көйгөй бар. Ал эми экинчи маселе, эгерде кандайдыр бир бириктирүү дайындалган болсо, анда ал репликация журналында жазылгандыктан аткарылышы керек. Репликация журналы репликаны ырааттуу абалга келтирүү үчүн зарыл болгон аракеттер. Эгерде сиз бул репликация журналын артка кайтара турган кол менен манипуляцияларды жасабасаңыз, бириктирүү тигил же бул жол менен аткарылышы керек болот.
Албетте, ООМдон коргой турган RAM чектөөсү ашыкча болбойт. Бул бириктирүүнү аягына чыгарууга жардам бербейт, ал кайра башталат, кандайдыр бир босогого жетет, өзгөчөлүктү таштайт, анан кайра башталат - мындан эч кандай жакшылык болбойт. Бирок негизи бул чектөөнү киргизүү пайдалуу болмок.
ClickHouse үчүн Голанг драйвери кантип иштелип чыгат?
Кирилл Шваков жазган Голанг айдоочусу азыр расмий түрдө 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 технологиясынын талисмандары менен бирге өрттү өчүрөбүз, системалык администратордун бөлмөсүндөгү же эски мектеп компьютер клубундагы кесиптештер менен кеңешебиз жана граффити фонунда көпүрөнүн астында күн сайын жолугушууларды өткөрөбүз.
Source: www.habr.com