ClickHouse атайын система болгондуктан, аны колдонууда анын архитектурасынын өзгөчөлүктөрүн эске алуу зарыл. Бул отчетто Алексей натыйжасыз ишке алып келиши мүмкүн болгон ClickHouse колдонууда кеңири таралган каталардын мисалдары жөнүндө айтып берет. Практикалык мисалдар тигил же бул маалыматты иштетүү схемасын тандоо кандайча чоңдуктун тартибине жараша өндүрүмдүүлүктү өзгөртө аларын көрсөтөт.
Баарына салам! Менин атым Алексей, мен ClickHouse жасайм.
Биринчиден, мен сизге дароо жагууга шашам, бүгүн мен ClickHouse деген эмне экенин айтпай эле коёюн. Чынын айтсам чарчадым. Мен сага анын эмне экенин айткан сайын. Анан, балким, баары мурунтан эле билет.
Анын ордуна, мен сизге кандай каталар болушу мүмкүн экенин айтып берем, башкача айтканда, ClickHouse'ду кантип туура эмес колдонсоңуз болот. Чынында, коркуунун кереги жок, анткени биз ClickHouseду жөнөкөй, ыңгайлуу жана кутудан тышкары иштеген система катары иштеп жатабыз. Мен аны орноткон, эч кандай көйгөйлөр жок.
Бирок сиз дагы эле бул система адистештирилгендигин эске алууңуз керек жана сиз бул системаны өзүнүн комфорт зонасынан чыгара турган адаттан тыш колдонуу учуруна оңой эле туш боло аласыз.
Анда кандай тырмоо бар? Көбүнчө мен ачык-айкын нерселер жөнүндө сүйлөшөм. Баарына баары түшүнүктүү, ар бир адам баарын түшүнөт жана ушунчалык акылдуу экенине кубанса болот, ал эми түшүнбөгөндөр жаңы нерсени үйрөнүшөт.
Биринчи жана эң жөнөкөй мисал, тилекке каршы, көп кездешет, бул кичинекей партиялары бар кыстармалардын көп саны, б.а.
Эгерде ClickHouse кыстарууну кандай аткарарын карап чыксак, анда сиз бир сурамда жок дегенде терабайт маалыматтарды жөнөтө аласыз. Бул көйгөй эмес.
Ал эми типтүү аткаруу кандай болорун карап көрөлү. Мисалы, бизде Yandex.Metrica маалыматтарынын таблицасы бар. Hits. 105 кээ бир тилкелер. 700 байт кысылган эмес. Жана биз миллион катардан турган партияларга жакшы жол менен киргизебиз.
Биз MergeTreeди таблицага киргизебиз, ал секундасына жарым миллион катар чыгат. Абдан жакшы. Репликацияланган таблицада ал бир аз кичирээк болот, болжол менен секундасына 400 000 катар.
Эгерде сиз кворумду киргизүүнү иштетсеңиз, сиз секундасына 250 000 терминди бир аз азыраак, бирок дагы эле татыктуу аткарууну аласыз. Кворумду киргизүү ClickHouse* ичиндеги документтештирилбеген функция.
* 2020-жылга карата, .
Жаман иш кылсаң эмне болот? MergeTree таблицасына бир катар киргизип, секундасына 59 сапты алабыз. Бул 10 000 эсе жайыраак. ReplicatedMergeTreeде – секундасына 6 катар. Ал эми кворум күйгүзүлсө, секундасына 2 сап чыгат. Менин оюмча, бул кандайдыр бир абсолюттук башаламандык. Кантип минтип жайлайсың? Атүгүл менин футболкамда ClickHouse жайлабашы керек деп жазылган. Бирок, ошентсе да, кээде болот.
Чынында бул биздин кемчилигибиз. Биз оңой эле бардыгын жакшы кылып жасамакпыз, бирок андай кылган жокпуз. А биз муну жасаган жокпуз, анткени биздин сценарий муну талап кылган эмес. Бизде мурунтан эле бычак болгон. Биз кире бериште партияларды алдык, эч кандай көйгөй жок. Биз аны киргизебиз жана баары жакшы иштейт. Бирок, албетте, ар кандай сценарийлер болушу мүмкүн. Мисалы, сизде маалыматтар түзүлө турган бир топ серверлер болгондо. Жана алар маалыматтарды көп киргизишпейт, бирок алар дагы эле тез-тез кыстаруу менен аяктайт. Анан кандайдыр бир жол менен мындан качышыбыз керек.
Техникалык көз караштан алганда, сиз ClickHouse-да кыстаруу жасаганыңызда, маалыматтар эч кандай эстелик таблицага түшпөйт. Бизде MergeTree логунун чыныгы структурасы да жок, бирок жөн гана MergeTree, анткени журнал да, memTable да жок. Биз жөн гана маалыматтарды дароо эле тилкелерде тизилген файлдык тутумга жазабыз. Ал эми сизде 100 тилке болсо, анда 200дөн ашык файлдар өзүнчө каталогго жазылышы керек болот. Мунун баары абдан түйшүктүү.
Анан суроо туулат: "Муну кантип туура кылыш керек?" Эгерде кырдаал ушундай болсо, сиз дагы эле кандайдыр бир жол менен ClickHouse-да маалыматтарды жазышыңыз керек.
Метод 1. Бул эң оңой жол. Кандайдыр бир бөлүштүрүлгөн кезекти колдонуңуз. Мисалы, Кафка. Сиз жөн гана Кафкадан маалыматтарды чыгарып, секундасына бир жолу топтойсуз. Анан баары жакшы болот, жаздырдың, баары жакшы иштейт.
Кемчиликтери Кафка дагы бир көлөмдүү бөлүштүрүлгөн система болуп саналат. Сиздин компанияңызда Кафка бар экенин да түшүнөм. Бул жакшы, бул ыңгайлуу. Бирок, эгерде ал жок болсо, анда дагы бир бөлүштүрүлгөн системаны проектиңизге сүйрөөдөн мурун үч жолу ойлонушуңуз керек. Ошентип, альтернативаларды карап чыгуу керек.
Метод 2. Бул эски мектеп альтернатива жана ошол эле учурда абдан жөнөкөй. Сиздин журналдарыңызды түзгөн сервериңиз барбы? Ал жөн гана сиздин журналдарыңызды файлга жазат. Ал эми секундасына бир жолу, мисалы, биз бул файлдын атын өзгөртүп, жаңысын ажыратабыз. Ал эми өзүнчө скрипт, же cron же кандайдыр бир демон аркылуу, эң эски файлды алып, ClickHouseга жазат. Эгерде сиз журналдарды секундасына бир жолу жазсаңыз, анда баары жакшы болот.
Бирок бул ыкманын кемчилиги, эгерде журналдар түзүлгөн сервериңиз бир жерде жок болуп кетсе, анда маалыматтар да жок болот.
Метод 3. Убактылуу файлдарды таптакыр талап кылбаган дагы бир кызыктуу ыкма бар. Мисалы, сизде кандайдыр бир жарнамалык спиннер же маалыматтарды жаратуучу башка кызыктуу демон бар. Жана сиз түздөн-түз оперативдүү эс тутумда, буферде бир топ маалыматтарды топтой аласыз. Ал эми жетиштүү убакыт өткөндөн кийин, сиз бул буферди четке коюп, жаңысын түзүп, өзүнчө жипке мурунтан эле топтолгон нерсени ClickHouseга киргизесиз.
Башка жагынан алганда, маалыматтар да өлтүрүү -9 менен жок болот. Эгер сервериңиз бузулса, бул дайындарды жоготосуз. Жана дагы бир көйгөй, эгерде сиз маалымат базасына жаза албасаңыз, анда сиздин маалыматтарыңыз RAMга топтолот. Жана же RAM түгөнөт, же сиз жөн гана маалыматтарды жоготосуз.
Метод 4. Дагы бир кызыктуу ыкма. Сизде кандайдыр бир сервер процесси барбы. Жана ал дароо ClickHouseга маалыматтарды жөнөтө алат, бирок аны бир байланышта жасай алат. Мисалы, мен которуу-коддоо менен http өтүнүчүн жибердим: кыстаруу менен кесилген. Ал сейрек эмес бөлүктөрдү жаратат, сиз ар бир сапты жөнөтө аласыз, бирок бул маалыматтарды рамкалоо үчүн кошумча чыгымдар болот.
Бирок, бул учурда маалыматтар дароо ClickHouseга жөнөтүлөт. Жана ClickHouse аларды өзү буфер кылат.
Бирок көйгөйлөр да пайда болот. Эми сиз дайындарды жоготосуз, анын ичинде процессиңиз өлтүрүлгөндө жана ClickHouse процесси өлтүрүлгөндө, ал толук эмес кыстарма болуп калат. Ал эми ClickHouse кыстармалар саптардын өлчөмү боюнча белгилүү бир чекке чейин атомдук болуп саналат. Негизи, бул кызыктуу жол. Ошондой эле колдонсо болот.
Метод 5. Бул жерде дагы бир кызыктуу ыкма. Бул маалыматтарды топтоо үчүн коомчулук тарабынан иштелип чыккан сервердин кандайдыр бир түрү. Мен өзүм деле караган эмесмин, ошондуктан эч нерсеге кепилдик бере албайм. Бирок, ClickHouse үчүн эч кандай кепилдик жок. Бул дагы ачык булак, бирок экинчи жагынан, сиз биз камсыз кылууга аракет кылган кандайдыр бир сапат стандартына көнүп калган болушуңуз мүмкүн. Бирок бул нерсе үчүн - мен билбейм, GitHub'ка барып, кодду караңыз. Балким алар нормалдуу бир нерсе жазышкандыр.
* 2020-жылга карата, ошондой эле эске кошуу керек .
Метод 6. Дагы бир ыкма - буфердик таблицаларды колдонуу. Бул ыкманын артыкчылыгы аны колдонууга өтө оңой. Буфер таблицасын түзүп, ага киргизиңиз.
Кемчилиги – маселенин толук чечилбегендигинде. Эгер MergeTree сыяктуу ылдамдыкта маалыматтарды секундасына бир партия боюнча топтошуңуз керек болсо, анда буфердик таблицадагы ылдамдыкта, сиз секундасына бир нече миңге чейин топтошуңуз керек. Эгер секундасына 10 000ден көп болсо, ал дагы эле жаман болот. А эгер сиз аны партия менен киргизсеңиз, анда ал секундасына жүз миң сап болуп чыгаарын көрдүңүз. Жана бул кыйла оор маалыматтарда.
Ошондой эле буфердик таблицаларда журнал жок. Ал эми сервериңизде бир нерсе туура эмес болсо, анда маалыматтар жоголот.
Жана бонус катары жакында ClickHouseдан Кафкадан маалыматтарды алуу мүмкүнчүлүгүнө ээ болдук. Үстөл мотору бар - Кафка. Сиз жөн гана жаратыңыз. Жана сиз ага материалдашкан өкүлчүлүктөрдү илип койсоңуз болот. Бул учурда, ал өзү Кафкадан маалыматтарды чыгарып, сизге керектүү таблицаларга киргизет.
Бул мүмкүнчүлүктүн өзгөчө жагымдуу жагы, муну биз жасаган жокбуз. Бул коомчулуктун өзгөчөлүгү. Жана мен "коомчулуктун өзгөчөлүгү" деп айтканда, мен аны эч кандай басынтуусуз айтып жатам. Биз кодду окудук, карап чыктык, ал жакшы иштеши керек.
* 2020-жылга карата ушундай колдоо пайда болду .
Маалыматтарды киргизүүдө дагы эмне ыңгайсыз же күтүүсүз болушу мүмкүн? Эгер сиз маанилерди киргизүү өтүнүчүн жасасаңыз жана баалуулуктарга кээ бир эсептелген туюнтмаларды жазсаңыз. Мисалы, now() да эсептелген туюнтма. Жана бул учурда, ClickHouse ар бир сапта бул туюнтмалардын интерпретаторун ишке киргизүүгө аргасыз болот жана аткаруу чоңдуктун буйругу менен төмөндөйт. Мындан качканыңыз жакшы.
* учурда маселе толугу менен чечилди, VALUES ичиндеги туюнтмаларды колдонууда эч кандай майнаптуулук регрессиясы жок.
Дагы бир мисал, сизде бир топ бөлүктөргө таандык болгон бир партия боюнча маалыматтар болгондо, кандайдыр бир көйгөйлөр пайда болушу мүмкүн. Демейки боюнча, ClickHouse бөлүмдөрү ай боюнча. Эгер сиз миллион саптардын партиясын киргизсеңиз жана бир нече жылдар бою маалымат бар болсо, анда сизде бир нече ондогон бөлүмдөр болот. Жана бул бир нече ондогон эсе аз өлчөмдөгү партиялар болот дегенге барабар, анткени ичинде алар ар дайым алгач бөлүктөргө бөлүнөт.
* Жакында, эксперименталдык режимде ClickHouse алдын ала жазуу журналы менен оперативдүү эс тутумдагы кесектердин жана бөлүктөрдүн компакт форматын колдоону кошту, бул көйгөйдү дээрлик толугу менен чечет.
Эми маселенин экинчи түрүн - маалыматтарды терүүнү карап көрөлү.
Маалыматтарды терүү катуу же сап болушу мүмкүн. Стринг - бул сиз аны жаңы эле алып, бардык талааларыңыз сап тибинде деп жарыялаганыңыз. Бул жаман. Мындай кылуунун кереги жок.
Келгиле, бизде кандайдыр бир талаа, сап бар деп айткыңыз келген учурларда муну кантип туура жасоо керектигин аныктап көрөлү жана ClickHouse аны өз алдынча чечсин, мен убара болбойм. Бирок дагы эле бир аз аракет кылуу керек.
Мисалы, бизде IP дареги бар. Бир учурда биз аны сап катары сактап калдык. Мисалы, 192.168.1.1. Ал эми башка учурда, бул UInt32 * типтеги бир катар болот. IPv32 дареги үчүн 4 бит жетиштүү.
Биринчиден, таң калыштуусу, маалыматтар болжол менен бирдей кысылган. Албетте, айырма болот, бирок анча чоң эмес. Ошентип, диск I/O менен эч кандай өзгөчө көйгөйлөр жок.
Бирок процессордун убактысы менен суроону аткаруу убактысында олуттуу айырма бар.
Келгиле, уникалдуу IP даректердин санын санап көрөлү, эгерде алар сандар катары сакталса. Бул секундасына 137 миллион сапты түзөт. Ошол эле саптар түрүндө болсо, анда секундасына 37 миллион сап. Бул кокустук эмне үчүн болгонун билбейм. Бул өтүнүчтөрдү мен өзүм аткардым. Бирок дагы эле болжол менен 4 эсе жайыраак.
Жана эгер сиз диск мейкиндигиндеги айырманы эсептесеңиз, анда айырма да бар. Жана айырма төрттөн бирине жакын, анткени уникалдуу IP даректер абдан көп. Ал эми аз сандагы ар кандай маанидеги саптар болсо, анда алар сөздүккө ылайык болжол менен бирдей көлөмгө оңой кысылып калмак.
Ал эми төрт эсе убакыт айырмасы жолдо калбайт. Балким, албетте, эч нерсеге көңүл бурбай жаткандырсыз, бирок ушундай айырмачылыкты көргөндө ичим ачышат.
Келгиле, ар кандай учурларды карап көрөлү.
1. Сизде ар кандай уникалдуу баалуулуктар аз болгон бир окуя. Бул учурда, биз, балким, сиз билген жана каалаган DBMS үчүн колдоно ала турган жөнөкөй практиканы колдонобуз. Мунун баары ClickHouse үчүн гана эмес. Жөн гана маалымат базасына сандык идентификаторлорду жаз. Жана сиз тиркемеңиздин капталында саптарга жана кайра өзгөртө аласыз.
Мисалы, сизде аймак бар. Жана сиз аны сап катары сактоого аракет кылып жатасыз. Жана ал жерде жазылат: Москва жана Москва облусу. Ал эми "Москва" деп жазылганын көргөндө, бул эч нерсе эмес, бирок Москва болгондо, кандайдыр бир деңгээлде капа болуп калат. Бул канча байт.
Тескерисинче, биз жөн гана Ulnt32 жана 250 санын жазабыз. Яндексте бизде 250 бар, бирок сиздики башкача болушу мүмкүн. Болбосо, мен ClickHouse геобаза менен иштөө үчүн орнотулган жөндөмгө ээ деп айтам. Сиз жөн гана аймактарды, анын ичинде иерархиялык каталогду жазыңыз, башкача айтканда, Москва, Москва облусу жана сизге керектүү нерселердин баары болот. Жана сиз суроо-талап деңгээлинде өзгөртө аласыз.
Экинчи параметр болжол менен бирдей, бирок ClickHouse ичинде колдоосу менен. Бул Enum маалымат түрү болуп саналат. Сиз жөн гана Enum ичинде керектүү бардык баалуулуктарды жазасыз. Мисалы, аппараттын түрү жана ошол жерге жаз: рабочий, мобилдик, планшет, сыналгы. Жалпысынан 4 вариант бар.
Кемчилиги - аны мезгил-мезгили менен өзгөртүү керек. Бир гана вариант кошулду. Келгиле, үстөлдү өзгөртөлү. Чынында, ClickHouseдагы таблицаны өзгөртүү акысыз. Айрыкча Enum үчүн бекер, анткени дисктеги маалыматтар өзгөрбөйт. Бирок, ошентсе да, алтер үстөлдө кулпуга* ээ болуп, бардык тандоолор аткарылганга чейин күтүшү керек. Ошондо гана бул өзгөртүү ишке ашырылат, башкача айтканда, дагы эле кээ бир ыңгайсыздыктар бар.
* ClickHouse акыркы версияларында ALTER толугу менен бөгөттөлбөйт.
ClickHouse үчүн уникалдуу болгон дагы бир параметр тышкы сөздүктөрдү туташтыруу болуп саналат. Сиз ClickHouse ичинде сандарды жазып, каталогдоруңузду сизге ыңгайлуу каалаган системада сактай аласыз. Мисалы, сиз колдоно аласыз: MySQL, Mongo, Postgres. Сиз бул маалыматты http аркылуу жөнөтө турган өзүңүздүн микросервисиңизди түзө аласыз. Ал эми ClickHouse деңгээлинде сиз бул маалыматтарды сандардан саптарга айландыра турган функцияны жазасыз.
Бул тышкы столдо кошулууну аткаруунун адистештирилген, бирок абдан натыйжалуу жолу. Жана эки вариант бар. Бир вариантта бул маалыматтар толугу менен кэштелет, оперативдүү эс тутумда толугу менен бар жана кандайдыр бир жыштык менен жаңыртылат. Жана башка вариантта, эгерде бул маалымат RAMга туура келбесе, анда сиз аны жарым-жартылай кэштей аласыз.
Бул жерде бир мисал. Yandex.Direct бар. Ал эми жарнамалык компания жана баннерлер бар. Болжол менен он миллиондогон жарнамалык компаниялар бар. Жана алар болжол менен RAMга туура келет. Жана миллиарддаган баннерлер бар, алар туура келбейт. Жана биз MySQLден кэштелген сөздүктү колдонобуз.
Бир гана көйгөй, эгерде хит көрсөткүчү 100% жакын болсо, кэштелген сөздүк жакшы иштейт. Эгер ал азыраак болсо, анда ар бир берилиштер партиясы үчүн сурамдарды иштеп жатканда, сиз чындыгында жетишпеген ачкычтарды алып, MySQLден маалыматтарды алууга туура келет. ClickHouse жөнүндө, мен дагы эле кепилдик бере алам - ооба, ал жайлабайт, мен башка системалар жөнүндө сүйлөшпөйм.
Жана бонус катары, сөздүктөр ClickHouseдагы маалыматтарды ретроактивдүү түрдө жаңыртуунун абдан оңой жолу. Башкача айтканда, сизде жарнамалык компаниялар жөнүндө отчет бар болчу, колдонуучу жөн гана жарнамалык компанияны өзгөрткөн жана бардык эски маалыматтарда, бардык отчеттордо бул маалыматтар да өзгөргөн. Эгерде сиз саптарды түз таблицага жазсаңыз, аларды жаңыртуу мүмкүн болбой калат.
Саптарыңыз үчүн идентификаторлорду кайдан алууну билбегениңиздин дагы бир жолу. сиз жөн гана хэш аласыз. Андан тышкары, эң жөнөкөй вариант - 64 биттик хэшти алуу.
Бир гана көйгөй, эгерде хэш 64 бит болсо, анда сизде кагылышуулар болот. Анткени ал жерде бир миллиард сызык бар болсо, анда ыктымалдуулук ансыз деле байкалып калат.
Ал эми жарнак компанияларынын атын ушинтип хэш кылып коюу абдан жакшы болмок эмес. Ар кандай компаниялардын жарнамалык кампаниялары аралашып кетсе, анда түшүнүксүз нерсе болот.
Жана жөнөкөй амал бар. Ырас, бул олуттуу маалыматтар үчүн анча ылайыктуу эмес, бирок бир нерсе өтө олуттуу эмес болсо, анда жөн гана сөздүк ачкычына кардар идентификаторун кошуңуз. Ошондо сизде кагылышуулар болот, бирок бир гана кардар ичинде. Жана биз бул ыкманы Yandex.Metricaдагы шилтеме карталары үчүн колдонобуз. Бизде URL даректер бар, хэштерди сактайбыз. Жана биз билебиз, албетте, кагылышуулар бар. Бирок барак көрсөтүлгөндө, бир колдонуучунун бир бетинде кээ бир URL'дер бири-бирине жабышып калышы жана муну байкап калуу ыктымалдыгы эске алынбай калышы мүмкүн.
Бонус катары, көптөгөн операциялар үчүн хэштер гана жетиштүү жана саптардын өзүн эч жерде сактоонун кереги жок.
Дагы бир мисал, саптар кыска болсо, мисалы, веб-сайттын домендери. Аларды ошол бойдон сактаса болот. Же, мисалы, браузердин тили ru – 2 байт. Албетте, байттар үчүн чындап боорум ооруйт, бирок кабатыр болбоңуз, 2 байт аянычтуу эмес. Сураныч, ошол бойдон сактаңыз, кабатыр болбоңуз.
Дагы бир жагдай, тескерисинче, сызыктар көп жана аларда уникалдуулар көп, ал тургай топтом чексиз. Кадимки мисал - издөө фразалары же URL даректери. Фразаларды, анын ичинде каталарды издөө. Келгиле, күнүнө канча уникалдуу издөө фразалары бар экенин карап көрөлү. Анан алар бардык окуялардын дээрлик жарымы экени белгилүү болду. Жана бул учурда, сиз маалыматтарды нормалдаштыруу, идентификаторлорду санап, өзүнчө таблицага коюу керек деп ойлошуңуз мүмкүн. Бирок муну кылуунун кереги жок. Бул саптарды ошол бойдон сактаңыз.
Эч нерсе ойлоп таппаганыңыз жакшы, анткени сиз аны өзүнчө сактасаңыз, сиз кошулушуңуз керек болот. Жана бул кошулуу, эң жакшысы, эстутумга туш келди жетүү, эгерде ал дагы эле эс тутумга туура келсе. Эгерде ал туура келбесе, анда көйгөйлөр пайда болот.
Ал эми маалыматтар өз ордунда сакталган болсо, анда ал жөн гана файл тутумунан керектүү тартипте окулат жана баары жакшы.
Эгер сизде URL даректери же башка татаал узун саптар болсо, анда кандайдыр бир үзүндүнү алдын ала эсептеп, аны өзүнчө тилкеге жазсаңыз болот.
URL'дер үчүн, мисалы, сиз доменди өзүнчө сактай аласыз. Эгер сизге чындап домен керек болсо, анда бул тилкени колдонуңуз, URL даректери ошол жерде болот жана сиз аларга тийбейсиз.
Келгиле, кандай айырма бар экенин карап көрөлү. ClickHouse доменди эсептеген адистештирилген функцияга ээ. Бул абдан тез, биз аны оптималдаштырдык. Чынын айтсам, ал RFCге да туура келбейт, бирок ошентсе да, ал бизге керектүү нерселердин баарын карайт.
Жана бир учурда биз жөн гана URL'дерди алып, доменди эсептейбиз. Бул 166 миллисекундга чейин иштейт. Эгер сиз даяр доменди алсаңыз, анда ал болгону 67 миллисекунд болуп чыгат, башкача айтканда, дээрлик үч эсе тезирээк. Жана бул тезирээк, анткени биз кээ бир эсептөөлөрдү жасашыбыз керек, бирок биз азыраак маалыматтарды окугандыктан.
Ошондуктан жайыраак болгон бир суроонун ылдамдыгы секундасына гигабайттан жогору. Анткени ал көбүрөөк гигабайттарды окуйт. Бул таптакыр керексиз маалыматтар. Сурам тезирээк иштейт окшойт, бирок аны аягына чыгаруу үчүн көбүрөөк убакыт талап кылынат.
Ал эми дисктеги маалыматтардын көлөмүн карасаңыз, URL 126 мегабайт, ал эми домен болгону 5 мегабайт экени көрүнүп турат. 25 эсе аз болуп чыкты. Бирок, ошого карабастан, суроо-талап 4 эсе гана тезирээк аткарылат. Бирок бул маалыматтар ысык болгондуктан. Ал эми суук болсо, диск киргизүү/чыгаруудан улам 25 эсе ылдамыраак болмок.
Айтмакчы, эгер сиз домен URL дарегине караганда канчалык кичирээк экенин баамдасаңыз, ал болжол менен 4 эсе кичине болуп чыгат.Бирок кандайдыр бир себептерден улам дискте маалыматтар 25 эсе аз алат. Неге? Компрессиядан улам. Жана URL кысылган, жана домен кысылган. Бирок көбүнчө URL бир топ таштандыны камтыйт.
Жана, албетте, керектүү баалуулуктар үчүн атайын иштелип чыккан же ылайыктуу маалымат түрлөрүн колдонуу төлөйт. Эгер сиз IPv4 болсоңуз, UInt32* сактаңыз. Эгерде IPv6 болсо, анда FixedString(16), анткени IPv6 дареги 128 бит, б.а. түз экилик форматта сакталат.
Бирок сизде кээде IPv4, кээде IPv6 даректери болсочу? Ооба, экөөнү тең сактай аласыз. IPv4 үчүн бир тилке, IPv6 үчүн башка. Албетте, IPv4 ичинде IPv6 көрсөтүү мүмкүнчүлүгү бар. Бул да иштейт, бирок суроо-талаптарда көп учурда IPv4 дареги керек болсо, аны өзүнчө тилкеге салып койсоңуз жакшы болмок.
* ClickHouse азыр өзүнчө IPv4, IPv6 маалымат түрлөрүнө ээ, алар маалыматтарды сандар сыяктуу эффективдүү сактайт, бирок аларды саптар сыяктуу ыңгайлуу чагылдырат.
Ал алдын ала маалыматтарды алдын ала иштеп чыгууга арзырлык экенин белгилей кетүү маанилүү. Мисалы, сиз чийки журналдарды аласыз. Мүмкүн, сиз аларды дароо ClickHouse-га киргизбешиңиз керек, бирок бул эч нерсе кылбоо абдан азгырык жана баары иштейт. Бирок дагы эле мүмкүн болгон эсептөөлөрдү жүргүзүү керек.
Мисалы, браузердин версиясы. Мен сөөмөйүмдү көрсөткүм келбеген кээ бир жакынкы бөлүмдө браузердин версиясы ушундай, башкача айтканда, сап катары сакталат: 12.3. Анан отчет түзүү үчүн алар бул сапты алып, массивге, анан массивдин биринчи элементине бөлүшөт. Албетте, баары жайлайт. Эмне үчүн мындай кылышат деп сурадым. Алар мага мөөнөтүнөн мурда оптималдаштырууну жактырбай турганын айтышты. А мен эртерээк пессимизацияны жактырбайм.
Демек, бул учурда 4 тилкеге бөлүү туурараак болмок. Бул жерде коркпоңуз, анткени бул ClickHouse. ClickHouse - бул мамычалык маалымат базасы. Жана канчалык тыкан кичинекей мамычалар, ошончолук жакшы. 5 Браузер версиясы болот, 5 мамычаны түзүңүз. Бул Жакшы.
Эми сизде өтө узун саптар, өтө узун массивдер болсо, эмне кылуу керектигин карап көрөлү. Аларды ClickHouse ичинде сактоонун кереги жок. Анын ордуна, сиз ClickHouse ичинде идентификаторду гана сактай аласыз. Жана бул узун сызыктарды башка системага салыңыз.
Мисалы, биздин аналитикалык кызматтарыбыздын биринде окуянын кээ бир параметрлери бар. Ал эми окуялардын параметрлери көп болсо, биз биринчи жолуккан 512ди сактап коёбуз, анткени 512 өкүнүчтүү эмес.
Жана эгер сиз өзүңүздүн маалымат түрлөрүңүздү чече албасаңыз, анда сиз ClickHouse-да маалыматтарды жазсаңыз болот, бирок убактылуу маалыматтар үчүн атайын Log түрүндөгү убактылуу таблицага. Андан кийин, сиз ал жерде кандай баалуулуктарды бөлүштүрө аласыз, жалпысынан эмне бар экенин жана туура түрлөрүн түзө аласыз.
*ClickHouse азыр маалымат түрү бар бул аз күч менен саптарды натыйжалуу сактоого мүмкүндүк берет.
Эми дагы бир кызыктуу окуяга токтололу. Кээде адамдар үчүн кызыктай иштешет. Мен кирип, муну көрүп жатам. Бул MySQL 3.23 версиясын орнотууда чоң тажрыйбасы бар абдан тажрыйбалуу, акылдуу админ тарабынан жасалган окшойт.
Бул жерде биз миң таблицаны көрөбүз, алардын ар бири ким эмнени миңге бөлүүдө калганын жазат.
Негизи, мен башка адамдардын тажрыйбасын, анын ичинде бул тажрыйба аркылуу ээ боло турган азапты түшүнүүнү сыйлайм.
Ал эми себептери аздыр-көптүр түшүнүктүү. Бул башка системалар менен иштөөдө топтолгон эски стереотиптер. Мисалы, MyISAM таблицаларында кластердик негизги ачкыч жок. Ал эми маалыматтарды бөлүштүрүүнүн бул жолу ошол эле функцияны алуу үчүн жасалган аракет болушу мүмкүн.
Дагы бир себеби, чоң столдордо кандайдыр бир өзгөртүү операцияларын жасоо кыйын. Баары бөгөттөлөт. MySQLдин заманбап версияларында бул көйгөй анчалык деле олуттуу эмес.
Же, мисалы, microsharding, бирок бул тууралуу кийинчерээк.
ClickHouseда муну жасоонун кереги жок, анткени, биринчиден, негизги ачкыч кластерленген, маалыматтар негизги ачкыч менен иреттелген.
Кээде адамдар менден: "ClickHouseдагы диапазон сурамдарынын аткарылышы таблицанын өлчөмүнө жараша кандайча өзгөрөт?" Мен ал такыр өзгөрбөйт дейм. Мисалы, сизде миллиард саптары бар таблица бар жана сиз бир миллион сап диапазонун окуйсуз. Баары жакшы. Эгерде таблицада триллион сап болсо жана сиз бир миллион сапты окусаңыз, ал дээрлик бирдей болот.
Экинчиден, кол менен бөлүү сыяктуу нерселердин бардык түрлөрү талап кылынбайт. Эгер сиз кирип, файл тутумунда эмне бар экенин карасаңыз, үстөл абдан чоң келишим экенин көрөсүз. Ал эми ичинде бөлүмдөр сыяктуу бир нерсе бар. Башкача айтканда, ClickHouse сиз үчүн баарын кылат жана сиз азап чегишиңиз керек эмес.
ClickHouse'та өзгөртүү акысыз, эгер кошуу/тачыруу тилкесин өзгөртүү.
Ал эми кичинекей таблицаларды жасабашыңыз керек, анткени сизде 10 сап же 10 000 сап болсо, анда бул эч кандай мааниге ээ эмес. ClickHouse бул кечиктирүү эмес, өткөрүү жөндөмдүүлүгүн оптималдаштыруучу система, ошондуктан 10 сапты иштетүүнүн мааниси жок.
Бир чоң үстөлдү колдонуу туура. Эски стереотиптерден арыл, баары жакшы болот.
Бонус катары, акыркы версияда бизде жеке бөлүктөрдө ар кандай тейлөө операцияларын аткаруу үчүн ыктыярдуу бөлүү ачкычын түзүү мүмкүнчүлүгү бар.
Мисалы, сизге көптөгөн кичинекей таблицалар керек, мисалы, кээ бир ортодогу маалыматтарды иштеп чыгуу зарылчылыгы болгондо, сиз кесектерди аласыз жана акыркы таблицага жазуудан мурун аларга трансформацияны жүргүзүү керек. Бул учурда, сонун стол кыймылдаткычы бар - StripeLog. Бул TinyLog сыяктуу, жакшыраак.
* азыр ClickHouse да бар .
Дагы бир антиплаттер - бул микрошардинг. Мисалы, берилиштерди бөлүү керек жана сизде 5 сервер бар, эртең 6 сервер болот. Жана сиз бул маалыматтарды кантип балансташтыруу жөнүндө ойлоносуз. Анын ордуна сиз 5 сыныкка эмес, 1 сыныкка бөлүнөсүз. Анан сиз бул микрошарддардын ар бирин өзүнчө серверге түшүрөсүз. Жана сиз, мисалы, бир серверде 000 ClickHouse аласыз, мисалы. Өзүнчө порттордо же өзүнчө маалымат базаларында өзүнчө инстанциялар.
Бирок бул ClickHouseда анча жакшы эмес. Анткени бир гана ClickHouse инстанциясы бир суроону иштетүү үчүн бардык жеткиликтүү сервер ресурстарын колдонууга аракет кылат. Башкача айтканда, сизде кандайдыр бир сервер бар жана анын, мисалы, 56 процессордун өзөгү бар. Сиз бир секунд талап кылган суроону иштетип жатасыз жана ал 56 өзөктү колдонот. Эгер сиз ал жерге 200 ClickHouse бир серверге жайгаштырсаңыз, анда 10 000 жип башталат экен. Жалпысынан алганда, баары абдан жаман болот.
Дагы бир себеби, бул инстанциялар боюнча иштин бөлүштүрүлүшү бирдей эмес болот. Кээ бири эрте бүтөт, кээ бирлери кечирээк бүтөт. Эгерде мунун баары бир эле учурда болгон болсо, анда ClickHouse өзү маалыматтарды жиптер арасында кантип туура бөлүштүрүүнү чечмек.
Жана дагы бир себеби, сиз TCP аркылуу процессорлор аралык байланышка ээ болосуз. Берилиштерди сериялаштыруу, сериядан чыгаруу керек болот жана бул микрошарддардын көп саны. Бул жөн гана натыйжалуу иштебейт.
Дагы бир антипаттерн, бирок аны антипаттерн деп атоого болбойт. Бул алдын-ала топтоонун чоң көлөмү.
Жалпысынан алганда, алдын ала топтоо жакшы. Сизде миллиард сап бар эле, сиз аны бириктирдиңиз жана ал 1 сапка айландыңыз, эми суроо заматта аткарылат. Баары сонун. Сиз муну кыла аласыз. Жана бул үчүн, жада калса ClickHouse да атайын таблицанын түрү бар, AggregatingMergeTree, ал маалыматтар киргизилген сайын кошумча топтоону жүзөгө ашырат.
Бирок биз ушуга окшогон маалыматтарды топтоп, ушундай маалыматтарды топтойбуз деп ойлогон учурлар болот. Ал эми кээ бир кошуна бөлүмдөрүндө мен кайсынысын айткым келбейт, алар SummingMergeTree таблицаларын негизги ачкыч менен жыйынтыктоо үчүн колдонушат жана 20га жакын мамычалар негизги ачкыч катары колдонулат. Болбосо, мен кээ бир тилкелердин атын купуялуулук үчүн өзгөрткөм, бирок бул абдан көп.
Анан ушундай көйгөйлөр жаралууда. Биринчиден, сиздин маалымат көлөмү өтө эле азайбайт. Мисалы, үч эсеге азаят. Үч жолу берилиштериңиз бириктирилбесе, пайда болгон чексиз аналитика мүмкүнчүлүктөрүн алуу үчүн жакшы баа болмок. Эгерде маалыматтар топтолсо, анда аналитиканын ордуна сиз аянычтуу статистиканы гана аласыз.
Анан эмнеси менен өзгөчөлүгү бар? Чындыгында, бул кошуна бөлүмдүн адамдары кээде барып, негизги ачкычка башка тилке кошууну суранышат. Башкача айтканда, биз маалыматтарды ушундайча бириктирдик, бирок азыр биз бир аз көбүрөөк каалайбыз. Бирок ClickHouseда өзгөртүүчү негизги ачкыч жок. Ошондуктан, биз C++ тилинде кээ бир сценарийлерди жазышыбыз керек. С++ тилинде болсо дагы, мен сценарийлерди жактырбайм.
Эгерде сиз ClickHouse эмне үчүн түзүлгөнүн карасаңыз, анда топтолбогон маалыматтар дал ошол сценарий болуп саналат. Эгер сиз ClickHouse'ду топтолбогон маалыматтар үчүн колдонуп жатсаңыз, анда сиз муну туура кылып жатасыз. Эгерде сиз чогултсаңыз, бул кээде кечирилет.
Дагы бир кызыктуу учур - чексиз циклдеги сурамдар. Кээде мен кандайдыр бир өндүрүш серверине барып, ал жердеги процесстердин тизмесин карайм. Жана ар бир жолу мен коркунучтуу нерсе болуп жатканын байкадым.
Мисалы, ушул сыяктуу. Баары бир өтүнүчтө аткарылышы мүмкүн экени дароо айкын көрүнүп турат. Жөн гана url жана тизмени ошол жерге жазыңыз.
Эмне үчүн чексиз циклдеги мындай суроолордун көбү жаман? Эгерде индекс колдонулбаса, анда сизде бир эле маалымат боюнча көп өтүүлөр болот. Бирок индекс колдонулса, мисалы, сизде ru үчүн негизги ачкыч бар жана ал жерге url = бир нерсе жазасыз. Эгер таблицадан бир гана URL окулса, баары жакшы болот деп ойлойсуз. Бирок чындыгында жок. Анткени ClickHouse баарын партия менен жасайт.
Ал белгилүү бир катар маалыматтарды окуу керек болгондо, ал бир аз көбүрөөк окуйт, анткени ClickHouseдагы индекс сейрек. Бул индекс таблицадан бир гана сапты табууга мүмкүндүк бербейт, кандайдыр бир диапазонду гана. Ал эми маалыматтар блокторго кысылган. Бир сапты окуу үчүн бүт блокту алып, аны ачуу керек. А эгер сиз бир топ суроону аткарып жатсаңыз, сизде көп кайталануулар болот жана сизде көп иш кайра-кайра аткарыла берет.
Бонус катары, ClickHouseда сиз мегабайттарды, жада калса жүздөгөн мегабайттарды IN бөлүмүнө которуудан коркпоңуз. Биздин практикадан эсимде, эгерде MySQLде биз бир топ маанилерди IN бөлүмүнө өткөрүп алсак, мисалы, кээ бир сандардын 100 мегабайтын ал жерге өткөрсөк, анда MySQL 10 гигабайт эстутумду жейт жана ага эч нерсе болбойт, баары начар иштейт.
Экинчиси, ClickHouseда, эгерде сиздин сурооңуз индексти колдонсо, анда ал ар дайым толук сканерлөөдөн жайыраак болбойт, башкача айтканда, сиз дээрлик бүт таблицаны окушуңуз керек болсо, анда ал ырааттуулук менен өтүп, бүт таблицаны окуйт. Жалпысынан алганда, ал өз алдынча чечет.
Бирок ошого карабастан кээ бир кыйынчылыктар бар. Мисалы, ички суроо менен IN индексти колдонбогону. Бирок бул биздин көйгөй жана биз аны оңдошубуз керек. Бул жерде принципиалдуу эч нерсе жок. Биз аны оңдойбуз*.
Жана дагы бир кызыктуу нерсе, эгерде сизде өтө узун суроо-талап болсо жана бөлүштүрүлгөн өтүнүчтү иштетүү жүрүп жатса, анда бул өтө узун суроо ар бир серверге кысуусуз жөнөтүлөт. Мисалы, 100 мегабайт жана 500 сервер. Жана, ошого жараша, сиз тармак аркылуу 50 гигабайтка ээ болосуз. Ал өткөрүлүп берилет, анан баары ийгиликтүү аяктайт.
* мурунтан эле колдонуу; Баары убада кылынгандай оңдолду.
Ал эми сурамдар APIден келгенде кеңири таралган учур. Мисалы, сиз өзүңүздүн кандайдыр бир кызматыңызды түздүңүз. Эгер кимдир бирөө сиздин кызматыңызга муктаж болсо, анда сиз API ачасыз жана эки күндөн кийин түшүнүксүз нерсе болуп жатканын көрөсүз. Баары ашыкча жүктөлгөн жана эч качан болбошу керек болгон коркунучтуу өтүнүчтөр келип жатат.
Жана бир гана чечим бар. Эгер сиз API ачкан болсоңуз, анда аны кесип салышыңыз керек болот. Мисалы, кандайдыр бир квоталарды киргизиңиз. Башка нормалдуу варианттар жок. Болбосо дароо эле сценарий жазып, көйгөйлөр жаралат.
Ал эми ClickHouse өзгөчө өзгөчөлүгү бар - квота эсептөө. Мындан тышкары, сиз квота ачкычыңызды өткөрүп бере аласыз. Бул, мисалы, ички колдонуучу ID болуп саналат. Ал эми квоталар алардын ар бири үчүн өз алдынча эсептелинет.
Эми дагы бир кызык нерсе. Бул кол менен кайталоо.
Мен ClickHouse репликациясынын камтылган колдоосуна ээ болгонуна карабастан, адамдар ClickHouseну кол менен репликациялаган көптөгөн учурларды билем.
Принциби кандай? Сизде маалыматтарды иштетүү тутуму бар. Жана ал өз алдынча иштейт, мисалы, ар кандай маалымат борборлорунда. Ошол эле маалыматтарды ClickHouse-да ошол эле жол менен жазасыз. Ырас, практика көрсөткөндөй, маалыматтар сиздин кодуңуздагы кээ бир өзгөчөлүктөргө байланыштуу дагы эле айырмаланат. Мен сеники деп үмүттөнөм.
Жана мезгил-мезгили менен сиз дагы кол менен шайкештештирүүгө туура келет. Мисалы, айына бир жолу админдер rsync жасашат.
Чынында, ClickHouse ичинде орнотулган репликацияны колдонуу алда канча жеңил. Бирок кээ бир каршы көрсөтмөлөр болушу мүмкүн, анткени бул үчүн ZooKeeper колдонуу керек. Мен ZooKeeper жөнүндө жаман эч нерсе айтпайм, негизи система иштейт, бирок адамдар аны java-фобиядан улам колдонбой калат, анткени ClickHouse абдан жакшы система, C++ тилинде жазылган, аны сиз колдоно аласыз. баары жакшы болот. Жана ZooKeeper javaда. Жана кандайдыр бир жол менен сиз карагыңыз да келбейт, бирок андан кийин кол менен кайталоону колдоно аласыз.
ClickHouse бул практикалык система. Ал сиздин муктаждыктарыңызды эске алат. Эгерде сизде кол менен репликация болсо, анда кол менен репликаларыңызды карап, алардын ортосунда жаңылыштыктарды жасаган Бөлүштүрүлгөн таблицаны түзө аласыз. Ал тургай, сиздин сызыктарыңыз системалуу түрдө бөлүнүп кетсе дагы, флоптардан качууга мүмкүндүк берген атайын вариант бар.
Эгер примитивдүү стол кыймылдаткычтарын колдонсоңуз, андан аркы көйгөйлөр пайда болушу мүмкүн. ClickHouse - бул ар кандай стол кыймылдаткычтарынын бир тобу бар конструктор. Бардык олуттуу учурларда, документтерде жазылгандай, MergeTree үй-бүлөсүнүн таблицаларын колдонуңуз. Ал эми калганы - бул жеке учурларда же тесттер үчүн.
MergeTree жадыбалында сизде эч кандай күн жана убакыт болушунун кереги жок. Сиз дагы эле колдоно аласыз. Эгер күн жана убакыт жок болсо, демейки 2000 деп жазыңыз. Бул иштейт жана ресурстарды талап кылбайт.
Ал эми сервердин жаңы версиясында сизде бөлүү ачкычы жок ыңгайлаштырылган бөлүү бар экенин белгилей аласыз. Ошол эле болот.
Башка жагынан алганда, сиз примитивдик стол кыймылдаткычтарын колдоно аласыз. Мисалы, маалыматтарды бир жолу толтуруп, карап, буруп, жок кылыңыз. Log колдоно аласыз.
Же ортолук иштетүү үчүн кичинекей көлөмдөрдү сактоо StripeLog же TinyLog болуп саналат.
Маалыматтын көлөмү аз болсо, эстутумду колдонсо болот жана сиз оперативдүү эстутумда бир нерсени бурмалай аласыз.
ClickHouse кайра нормалдаштырылган маалыматтарды жактырбайт.
Бул жерде бир типтүү мисал. Бул абдан көп URL даректери. Сиз аларды кийинки үстөлгө коюңуз. Анан алар менен JOIN жасоону чечишти, бирок бул, эреже катары, иштебейт, анткени ClickHouse Hash JOINди гана колдойт. Эгер туташуу керек болгон көптөгөн маалыматтар үчүн RAM жетишсиз болсо, анда JOIN иштебейт*.
Эгерде маалыматтар жогорку деңгээлде болсо, кабатыр болбоңуз, аны нормадан ажыратылган түрдө сактаңыз, URL'дер түздөн-түз негизги таблицада жайгашкан.
* жана азыр ClickHouse да бириктирилген кошулууга ээ жана ал аралык маалыматтар RAMга туура келбеген шарттарда иштейт. Бирок бул натыйжасыз жана сунуш күчүндө кала берет.
Дагы бир нече мисал, бирок мен алардын анти-үлгү же жокпу деген күмөнүм бар.
ClickHouse бир белгилүү кемчилиги бар. Кантип жаңыртуу керектигин билбейт*. Кээ бир жагынан алганда, бул жакшы. Эгер сизде кээ бир маанилүү маалыматтар болсо, мисалы, бухгалтердик эсеп, анда эч ким аны жөнөтө албайт, анткени жаңыртуулар жок.
* Пакет режиминде жаңыртуу жана жок кылуу үчүн колдоо көп убакыт мурун кошулган.
Бирок жаңыртууларды арткы режимде өткөрүүгө уруксат берген атайын жолдор бар. Мисалы, ReplaceMergeTree сыяктуу таблицалар. Фонду бириктирүү учурунда алар жаңыртууларды жасашат. Сиз муну оптималдаштыруу таблицасын колдонуп мажбурласаңыз болот. Бирок муну көп жасабаңыз, анткени ал бөлүмдүн үстүнөн толугу менен жазылат.
ClickHouseдагы бөлүштүрүлгөн JOINдер да суроону пландоочу тарабынан начар иштетилет.
Жаман, бирок кээде жакшы.
ClickHouse'ду тандоо* аркылуу маалыматтарды кайра окуу үчүн гана колдонуу.
Мен түйшүктүү эсептөөлөр үчүн ClickHouse колдонууну сунуш кылбайт элем. Бирок бул таптакыр туура эмес, анткени биз бул сунуштан азыртадан эле алыстап жатабыз. Жакында биз ClickHouse - Catboost ичинде машина үйрөнүү моделдерин колдонуу мүмкүнчүлүгүн коштук. Анан мени тынчсыздандырат, анткени мен ойлойм: “Кандай коркунучтуу. Бул байт үчүн канча цикл чыгат! Сааттарды байттарга коротконду чындап жек көрөм.
Бирок коркпоңуз, ClickHouse орнотуңуз, баары жакшы болот. Бир нерсе болсо, бизде коом бар. Айтмакчы, коомчулук сизсиз. Ал эми кандайдыр бир көйгөйлөрүңүз болсо, жок дегенде биздин чатыбызга кайрылсаңыз болот, алар сизге жардам беришет деп үмүттөнөбүз.
суроолор
Кабар үчүн рахмат! ClickHouse кыйроосу жөнүндө кайда арыздансам болот?
Сиз азыр мага жеке арыздансаңыз болот.
Мен жакында ClickHouse колдоно баштадым. Мен дароо cli интерфейсин таштадым.
Кандай балл.
Бир аздан кийин мен серверди кичинекей тандоо менен кыйраттым.
Сенде талант бар.
Мен GitHub катасын ачтым, бирок ага көңүл бурулбай калды.
Көрөбүз.
Алексей мени алдап, отчетко катышам деп, ичиндеги маалыматтарга кантип кирээриңди айтып берем деп убада кылды.
Өтө жөнөкөй.
Мен муну кечээ түшүндүм. Кененирээк маалымат.
Ал жерде эч кандай коркунучтуу амалдар жок. Жөн гана блок-блок кысуу бар. Демейки LZ4, сиз ZSTD* иштете аласыз. 64 килобайттан 1 мегабайтка чейин блоктор.
* башка алгоритмдер менен чынжырда колдонула турган адистештирилген кысуу кодектери үчүн да колдоо бар.
Блоктор жөн гана чийки маалыматтарбы?
Толугу менен чийки эмес. Массивдер бар. Эгер сизде сандык тилке болсо, анда катардагы сандар массивге жайгаштырылат.
Түшүнүктүү.
Алексей, мисалы, uniqExact менен IP аркылуу болгон, башкача айтканда, uniqExact сандарга караганда сызыктар менен эсептөөгө көбүрөөк убакыт талап кылынат ж.б.у.с. Корректордук текшерүү учурунда кулагыбыз менен финтти колдонсок эмне болот? Башкача айтканда, биздин дискте анча деле айырмаланбайт деп айттыңыз окшойт. Эгерде биз дисктен саптарды окусак жана cast, биздин агрегаттар тезирээк болобу же жокпу? Же бул жерден дагы бир аз утушка ээ болобузбу? Менимче, сиз муну сынап көрдүңүз, бирок эмнегедир аны эталондо көрсөткөн жоксуз.
Кастингсиз караганда жайыраак болот деп ойлойм. Бул учурда, IP дареги саптан талданышы керек. Албетте, ClickHouseда биздин IP даректерибизди талдоо дагы оптималдаштырылган. Биз абдан аракет кылдык, бирок ал жерде он миңинчи формада жазылган сандар бар. Абдан ыңгайсыз. Башка жагынан алганда, uniqExact функциясы саптарда жайыраак иштейт, анткени булар саптар гана эмес, ошондой эле алгоритмдин башка адистиги тандалгандыктан. Саптар жөн гана башкача иштетилет.
Эгер биз жөнөкөй маалымат түрүн алсакчы? Мисалы, колубузда бар колдонуучунун идентификаторун жазып, сап кылып жазып, анан шифрлеп койдук, кызыктуураак болобу же жокпу?
Мен күмөн санап жатам. Менимче, бул андан да өкүнүчтүү болот, анткени сандарды талдоо олуттуу көйгөй. Менимче, бул кесиптеш он миңинчи формада сандарды талдоо канчалык кыйын экендиги жөнүндө отчет берген окшойт, бирок мүмкүн эмес.
Алексей, доклад үчүн чоң рахмат! Жана ClickHouse үчүн чоң рахмат! Менин пландар боюнча суроом бар. Сөздүктөрдү толук эмес жаңыртуу үчүн функциянын пландары барбы?
Башкача айтканда, жарым-жартылай кайра жүктөөбү?
Ооба ооба. Ал жерде MySQL талаасын коюу мүмкүнчүлүгү сыяктуу, башкача айтканда, сөздүк өтө чоң болсо, ушул маалымат гана жүктөлө тургандай кийин жаңыртыңыз.
Абдан кызыктуу өзгөчөлүк. Аны биздин чатта кимдир бирөө сунуштады деп ойлойм. Балким ал сен болгондур.
Андай деп ойлобойм.
Сонун, эми эки сураныч бар экен. Анан акырындык менен жасай баштасаңыз болот. Бирок мен бул функцияны ишке ашыруу өтө жөнөкөй экенин дароо эскертким келет. Башкача айтканда, теориялык жактан таблицага версиянын номерин жазып, андан кийин мындай деп жазыш керек: версиясы анча-мынчадан аз. Бул, кыязы, биз энтузиасттарга сунуштайбыз дегенди билдирет. Сиз энтузиастсызбы?
Ооба, бирок, тилекке каршы, C++ тилинде эмес.
Сиздин кесиптештериңиз C++ тилинде жазганды билеби?
Мен бирөөнү табам.
Абдан жакшы*.
* өзгөчөлүк баяндамадан эки ай өткөндөн кийин кошулган - суроонун автору аны иштеп чыгып, анын жөнөткөн .
рахмат!
Салам! Баяндама үчүн рахмат! Сиз ClickHouse ага жеткиликтүү болгон бардык ресурстарды керектөөдө абдан жакшы экенин айттыңыз. Ал эми Luxoftтун жанындагы спикер орус почтасы үчүн өзүнүн чечими жөнүндө айтып берди. Анын айтымында, аларга ClickHouse абдан жакты, бирок алар аны негизги атаандашынын ордуна колдонушкан жок, анткени ал бардык процессорду жеп салган. Алар аны архитектурасына, докерлери бар ZooKeeperге туташтыра алышкан жок. ClickHouse'ду кандайдыр бир жол менен чектөө мүмкүнбү, ал ага жеткиликтүү болгон нерселердин бардыгын керектебеши үчүн?
Ооба, бул мүмкүн жана абдан жеңил. Эгер сиз өзөктөрдү азыраак колдонгуңуз келсе, анда жазыңыз set max_threads = 1. Мына ушундай, ал өтүнүчтү бир өзөктө аткарат. Мындан тышкары, сиз ар кандай колдонуучулар үчүн ар кандай орнотууларды белгилей аласыз. Ошентип, көйгөй жок. Луксофттогу кесиптештериңизге бул жөндөөнү документациядан таппаганы жакшы эмес экенин айтыңыз.
Алексей, салам! Мен ушул суроо боюнча бергим келет. Бул көп адамдар ClickHouse'ду журналдар үчүн сактагыч катары колдоно баштаганын биринчи жолу уккан жокмун. Баяндамада сиз муну кылбаңыз, башкача айтканда, узун жиптерди сактоонун кереги жок дедиңиз. Бул тууралуу кандай ойдосуз?
Биринчиден, журналдар, эреже катары, узун саптар эмес. Албетте, баары бар. Мисалы, javaда жазылган кээ бир кызмат өзгөчөлүктү ыргытат, ал катталат. Ошентип, чексиз циклде жана катуу дисктеги бош орун түгөнөт. Чечим абдан жөнөкөй. сызыктар абдан узун болсо, анда аларды кесип. узун деген эмнени билдирет? Ондогон килобайт начар*.
* ClickHouse акыркы версияларында "адаптивдүү индекстин гранулярдуулугу" иштетилген, бул көп учурда узун саптарды сактоо көйгөйүн жок кылат.
Килобайт нормалдуубу?
Жөнөкөй.
Салам! Отчет үчүн рахмат! Мен бул тууралуу чатта сурадым, бирок жооп алганым эсимде жок. WITH бөлүмүн кандайдыр бир жол менен CTE ыкмасы менен кеңейтүү пландары барбы?
Азырынча жок. Биздин WITH бөлүмүбүз бир аз жеңилирээк. Бул биз үчүн кичинекей өзгөчөлүк сыяктуу.
Мен түшүндүм. Рахмат!
Кабар үчүн рахмат! Абдан кызыктуу! Глобалдык суроо. Маалыматтарды жок кылууну, балким, кандайдыр бир тактар түрүндө өзгөртүү пландары барбы?
Сөзсүз. Бул биздин кезектеги биринчи милдетибиз. Биз азыр бардыгын кантип туура жасоо женунде жигердуу ойлонуп жатабыз. Жана баскычтопту* басууну баштоо керек.
* клавиатурадагы баскычтарды басып, баарын жасады.
Бул кандайдыр бир жол менен системанын иштешине таасир этеби же жокпу? Киргизүү азыркыдай тез болобу?
Мүмкүн, жок кылуунун өзү жана жаңыртуулардын өзү абдан оор болот, бирок бул тандоолордун иштешине же кыстармалардын иштешине таасир этпейт.
Жана дагы бир кичинекей суроо. Презентацияда сиз негизги ачкыч жөнүндө айттыңыз. Демек, бизде демейки боюнча ай сайын болгон бөлүү бар, туурабы? Жана биз бир айга туура келген дата диапазонун койгондо, бул бөлүм гана окулат, туурабы?
Ооба.
Суроо. Эгерде биз кандайдыр бир негизги ачкычты тандай албасак, анда аны атайын "Күн" талаасына ылайык жасоо туурабы, андыктан бул маалыматтардын фонунда кайра иретке келтирилиши азыраак болуп, ал иреттүү түрдө туура келет? Эгерде сизде диапазон боюнча сурамдар жок болсо жана сиз эч кандай негизги ачкычты тандай албасаңыз, негизги ачкычка датаны коюу керекпи?
Ооба.
Балким, бул талаа боюнча сорттолгон болсо, маалыматтарды жакшыраак кысып турган талааны негизги ачкычка коюу мааниси бар. Мисалы, колдонуучунун ID. Колдонуучу, мисалы, ошол эле сайтка барат. Бул учурда, колдонуучунун идентификаторун жана убактысын коюңуз. Ошондо сиздин маалыматтар жакшыраак кысылган болот. Датага келсек, эгер сизде чындап эле даталар боюнча диапазон сурамдары жок болсо жана эч качан жок болсо, анда датаны негизги ачкычка коюунун кереги жок.
макул сага чоң рахмат!
Source: www.habr.com