Дөрөвдүгээр сард Авитогийн инженерүүд ClickHouse-ын үндсэн хөгжүүлэгч Алексей Миловидов, Интегросын Голанг хөгжүүлэгч Кирилл Шваков нартай онлайн уулзалт хийхээр цугларав. Өгөгдлийн сангийн менежментийн системийг хэрхэн ашиглаж, ямар бэрхшээл тулгардаг талаар ярилцлаа.
Уулзалт дээр үндэслэн бид нөөцлөлт, өгөгдлийг дахин хуваах, гадаад толь бичиг, Голанг драйвер болон ClickHouse хувилбаруудыг шинэчлэх талаар манай болон үзэгчдийн асуултад мэргэжилтнүүдийн хариултыг агуулсан нийтлэлийг эмхэтгэсэн. Энэ нь Yandex DBMS-тэй идэвхтэй ажиллаж байгаа бөгөөд түүний одоо болон ирээдүйг сонирхож буй хөгжүүлэгчдэд хэрэгтэй байж магадгүй юм. Анхдагч байдлаар, өөрөөр бичээгүй бол хариултууд нь Алексей Миловидов юм.
Болгоомжтой байгаарай, зүслэгийн доор маш олон текст байна. Асуулт бүхий контент нь таныг удирдахад тусална гэж найдаж байна.
Агуулга
Хэрэв та текстийг уншихыг хүсэхгүй бол цуглаануудын бичлэгийг үзэж болно . Цагийн кодууд нь видеоны доор байгаа эхний сэтгэгдэлд байна.
ClickHouse байнга шинэчлэгдэж байдаг, гэхдээ бидний мэдээлэл тийм биш юм. Энэ талаар юу хийх вэ?
ClickHouse байнга шинэчлэгдэж байдаг бөгөөд эцсийн боловсруулалт хийсэн бидний өгөгдөл шинэчлэгдээгүй бөгөөд нөөц хуулбарт байна.
Бидэнд ямар нэг асуудал тулгараад өгөгдөл алдагдсан гэж бодъё. Бид сэргээхээр шийдсэн бөгөөд нөөц сервер дээр хадгалагдсан хуучин хуваалтууд нь ClickHouse-ийн одоо ашиглагдаж буй хувилбараас эрс ялгаатай болох нь тогтоогдсон. Ийм нөхцөлд юу хийх вэ, боломжтой юу?
Нөөцлөлтөөс өгөгдлийг хуучин форматаар сэргээсэн боловч шинэ хувилбарт холбогдоогүй нөхцөл байдал боломжгүй юм. ClickHouse дахь өгөгдлийн формат нь үргэлж буцаж нийцэж байгаа эсэхийг шалгаарай. Энэ нь зарим ховор хэрэглэгддэг функцын зан байдал өөрчлөгдсөн тохиолдолд функциональ нийцтэй байдлаас хамаагүй чухал юм. ClickHouse-ийн шинэ хувилбар нь дискэнд хадгалагдсан өгөгдлийг унших чадвартай байх ёстой. Энэ бол хууль.
ClickHouse-аас өгөгдлийг нөөцлөх хамгийн сайн туршлага юу вэ?
Эцсийн үйлдлүүдийг оновчтой болгох, терабайтын асар том мэдээллийн сан, сүүлийн гурван өдрийн турш шинэчлэгдсэн өгөгдөл, дараа нь ямар ч журам гарахгүй байгааг харгалзан нөөцлөлтийг хэрхэн хийх вэ?
Бид өөрсдийн шийдлийг гаргаж, bash дээр бичиж болно: эдгээр нөөц хуулбарыг ийм байдлаар цуглуул. Магадгүй ямар нэг юм таяглах шаардлагагүй, унадаг дугуйг аль эрт зохион бүтээсэн байх?
Хамгийн сайн туршлагаас эхэлцгээе. Хамтран ажиллагсад маань нөөцлөлтийн талаарх асуултын хариуд энэ асуудал аль хэдийн шийдэгдсэн Yandex.Cloud үйлчилгээний талаар сануулахыг үргэлж зөвлөдөг. Тиймээс боломжтой бол хэрэглээрэй.
ClickHouse-д зуун хувь суулгасан нөөцлөлтийн бүрэн шийдэл байхгүй. Ашиглаж болох зарим хоосон зай байдаг. Бүрэн шийдлийг олж авахын тулд та гараар бага зэрэг хийх эсвэл скрипт хэлбэрээр боодол үүсгэх хэрэгтэй болно.
Би өгөгдлийн хэмжээ, кластерын хэмжээ зэргээс хамааран хамгийн энгийн шийдлүүдээс эхэлж, хамгийн боловсронгуй шийдлүүдээр дуусгах болно. Кластер томрох тусам шийдэл нь илүү төвөгтэй болно.
Хэрэв өгөгдөл бүхий хүснэгт хэдхэн гигабайт эзэлдэг бол нөөцлөлтийг дараах байдлаар хийж болно.
- Хүснэгтийн тодорхойлолтыг, өөрөөр хэлбэл мета өгөгдлийг хадгалах - үүсгэх хүснэгтийг харуулах.
- ClickHouse клиентийг ашиглан хогийн цэг хийх - сонгох * ширээнээс файл болгох. Анхдагч байдлаар та TabSeparated форматаар файл хүлээн авах болно. Хэрэв та илүү үр дүнтэй байхыг хүсч байвал үүнийг Native форматаар хийж болно.
Хэрэв өгөгдлийн хэмжээ их байвал нөөцлөлт нь илүү их цаг хугацаа, их зай эзэлнэ. Үүнийг логик нөөцлөлт гэж нэрлэдэг бөгөөд энэ нь ClickHouse мэдээллийн форматтай холбоогүй юм. Хэрэв тийм бол хамгийн сүүлчийн арга бол нөөцөлж аваад MySQL-д байршуулж сэргээх боломжтой.
Илүү дэвшилтэт тохиолдлуудын хувьд ClickHouse нь дотоод файлын систем дэх хуваалтуудын агшин зуурын зургийг үүсгэх чадвартай байдаг. Энэ функцийг хүсэлтээр авах боломжтой Хүснэгтийг хөлдөөх хуваалтыг өөрчлөх. Эсвэл зүгээр л Хүснэгтийн хөлдөлтийг өөрчлөх - энэ бол бүх хүснэгтийн агшин зураг юм.
Хормын хувилбарыг нэг хэлтэрхий дээрх нэг хүснэгтэд тууштай үүсгэх бөгөөд өөрөөр хэлбэл бүх кластерын тогтвортой агшин агшныг ийм байдлаар үүсгэх боломжгүй юм. Гэхдээ ихэнх даалгавруудын хувьд ийм шаардлага байхгүй бөгөөд хэлтэрхий бүр дээр хүсэлтийг гүйцэтгэж, тогтвортой агшин зуурын зургийг авахад хангалттай. Энэ нь хатуу холбоос хэлбэрээр бүтээгдсэн тул нэмэлт зай эзэлдэггүй. Дараа нь та энэ хормын хувилбарыг нөөц сервер эсвэл нөөцлөлтөд ашигладаг хадгалах сан руу хуулна.
Ийм нөөцлөлтийг сэргээх нь маш хялбар юм. Нэгдүгээрт, одоо байгаа хүснэгтийн тодорхойлолтыг ашиглан хүснэгт үүсгэ. Дараа нь хуваалтуудын хадгалсан агшин зургуудыг эдгээр хүснэгтүүдийн лавлах-салгасан хэсэгт хуулж, асуулга ажиллуулна уу. хуваалтыг хавсаргана. Энэ шийдэл нь хамгийн ноцтой хэмжээний өгөгдлийн хувьд маш тохиромжтой.
Заримдаа сервер бүр дээр хэдэн арван, бүр хэдэн зуун терабайт, хэдэн зуун сервертэй байх тохиолдолд танд илүү сэрүүн зүйл хэрэгтэй болно. Энд би Yandex.Metrica-аас хамтран ажиллагсдаас авсан шийдэл байна. Би үүнийг хүн бүрт зөвлөхгүй - үүнийг уншиж, тохирох эсэхээ өөрөө шийдээрэй.
Эхлээд та том дискний тавиур бүхий хэд хэдэн сервер үүсгэх хэрэгтэй. Дараа нь, эдгээр серверүүд дээр хэд хэдэн 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-ийн хувьд бүх зүйл таны ашиглах туршлагаас хамаарна. Энэ бол боловсорч гүйцсэн файлын систем боловч тодорхой хувилбарт бүх зүйл практикт хэрхэн хэрэгжих талаар зарим сэжиг байсаар байна. Хэрэв танд Btrf байхгүй бол би үүнийг ашиглахыг зөвлөхгүй.
Өгөгдлийг дахин хуваалцах өнөөгийн шилдэг туршлагууд юу вэ?
Дахин хуваах асуудал нь нарийн төвөгтэй бөгөөд олон талт юм. Энд хэд хэдэн боломжит хариултууд байна. Та нэг талаас очоод ингэж хэлж болно - ClickHouse-д дахин хуваарилах функц байхгүй. Гэхдээ энэ хариулт хэнд ч тохирохгүй байх вий гэж айж байна. Тиймээс, та нөгөө талаасаа очоод ClickHouse-д өгөгдлийг дахин хуваах олон арга байдаг гэж хэлж болно.
Хэрэв кластерийн зай дүүрсэн эсвэл ачааллыг даахгүй бол та шинэ сервер нэмнэ. Гэхдээ эдгээр серверүүд нь анхдагчаар хоосон, тэдгээрт өгөгдөл байхгүй, ачаалал байхгүй. Та өгөгдлийг шинэ, илүү том кластерт жигд тархсан байхаар өөрчлөх хэрэгтэй.
Үүнийг хийх эхний арга бол хүсэлтийг ашиглан хуваалтын хэсгийг шинэ серверт хуулах явдал юм хүснэгтийг татах хуваалтыг өөрчлөх. Жишээлбэл, та сараар хуваалттай байсан бөгөөд 2017 оны эхний сарыг аваад шинэ сервер рүү хуулж, дараа нь гурав дахь сарыг өөр шинэ сервер рүү хуулна. Та үүнийг илүү их эсвэл бага тэгш болтол нь хий.
Шилжилтийг зөвхөн бичлэг хийх явцад өөрчлөгддөггүй хуваалтуудад хийж болно. Шинэхэн хуваалтуудын хувьд тэдгээрийн дамжуулалт нь атом биш тул бичлэгийг идэвхгүй болгох шаардлагатай болно. Үгүй бол та өгөгдөлд давхардсан эсвэл цоорхойтой байх болно. Гэсэн хэдий ч энэ арга нь практик бөгөөд нэлээд үр дүнтэй ажилладаг. Бэлэн шахсан хуваалтууд нь сүлжээгээр дамждаг, өөрөөр хэлбэл өгөгдлийг шахдаггүй эсвэл дахин кодчилдоггүй.
Энэ арга нь нэг сул талтай бөгөөд энэ нь хуваах схем, та энэ хуваах схемийг барьцаалсан эсэх, танд ямар хэлтэрхий түлхүүр байсан зэргээс шалтгаална. Таны жишээн дээр хэмжигдэхүүнтэй тохиолдолд хуваах түлхүүр нь замын хэш юм. Та Тархсан хүснэгтийг сонгоход энэ нь кластерын бүх хэсгүүдэд нэг дор очиж, тэндээс өгөгдлийг авдаг.
Энэ нь ямар хэлтэрхий дээр ямар өгөгдөл байх нь танд хамаагүй гэсэн үг юм. Хамгийн гол нь нэг зам дагуух өгөгдөл нэг хэлтэрхий дээр дуусдаг боловч аль нь чухал биш юм. Энэ тохиолдолд бэлэн хуваалтуудыг шилжүүлэх нь төгс төгөлдөр юм, учир нь сонгосон асуулгын тусламжтайгаар та бүрэн өгөгдлийг хүлээн авах болно - дахин хуваахаас өмнө эсвэл дараа нь схем нь хамаагүй.
Гэхдээ илүү төвөгтэй тохиолдол байдаг. Хэрэв програмын логик түвшинд та тусгай хуваах схем дээр тулгуурладаг бол энэ үйлчлүүлэгч ийм ийм хэлтэрхий дээр байрладаг бөгөөд хүсэлтийг Тархсан хүснэгт рүү биш шууд тийш нь илгээж болно. Эсвэл та ClickHouse-ийн сүүлийн үеийн хувилбарыг ашиглаж байгаа бөгөөд тохиргоог идэвхжүүлсэн байна ашиглагдаагүй хэсгүүдийг алгасах оновчтой болгох. Энэ тохиолдолд сонгох асуулгын явцад хаана хэсгийн илэрхийлэлд дүн шинжилгээ хийх ба sharding схемийн дагуу ямар хэлтэрхийг ашиглах шаардлагатайг тооцоолно. Энэ нь өгөгдлийг хуваах схемийн дагуу яг хуваасан тохиолдолд ажиллана. Хэрэв та тэдгээрийг гараар дахин зохион байгуулсан бол захидал харилцаа өөрчлөгдөж магадгүй юм.
Тэгэхээр энэ бол №XNUMX арга юм. Би таны хариултыг хүлээж байна, арга тохиромжтой эсэх, эсвэл цаашаа явцгаая.
Владимир Колобаев, Avito дахь системийн удирдагч: Алексей, таны хэлсэн арга нь ачааллыг тараах, тэр дундаа унших шаардлагатай үед тийм ч сайн ажилладаггүй. Бид сар бүр хуваах боломжтой бөгөөд өмнөх сарыг өөр зангилаа руу шилжүүлж болох боловч энэ өгөгдлийг авах хүсэлт ирэхэд бид зөвхөн ачаалах болно. Гэхдээ бид кластерыг бүхэлд нь ачаалахыг хүсч байна, учир нь өөрөөр хэлбэл хэсэг хугацаанд унших ачааллыг бүхэлд нь хоёр хэлтэрхийгээр боловсруулах болно.
Алексей Миловидов: Хариулт нь хачирхалтай байна - тийм ээ, энэ нь муу, гэхдээ энэ нь ажиллах болно. Би яг яаж гэдгийг тайлбарлах болно. Таны өгөгдлийн ард гарч буй ачааллын хувилбарыг харах нь зүйтэй. Хэрэв энэ нь хяналтын өгөгдөл юм бол хүсэлтийн дийлэнх нь шинэ өгөгдөлд зориулагдсан гэж бид бараг хэлж чадна.
Та шинэ сервер суулгаж, хуучин хуваалтуудыг шилжүүлсэн ч шинэ өгөгдлийг хэрхэн бичихийг өөрчилсөн. Мөн шинэ өгөгдөл нь кластер даяар тархах болно. Тиймээс ердөө таван минутын дараа сүүлийн таван минутын хүсэлтүүд кластерыг жигд ачаалах бөгөөд нэг өдрийн дараа XNUMX цагийн хүсэлтүүд кластерыг жигд ачаалах болно. Харамсалтай нь өмнөх сарын хүсэлтүүд нь зөвхөн кластер серверүүдийн нэг хэсэг рүү очих болно.
Гэхдээ ихэвчлэн 2019 оны 2019-р сард тусгайлан хүсэлт гаргахгүй байх болно. Хэрэв хүсэлтүүд 2019 онд ирвэл XNUMX оныг бүхэлд нь хамарсан байх магадлалтай бөгөөд зарим нэг жижиг хүрээний хувьд биш харин том хугацаанд үргэлжлэх болно. Мөн ийм хүсэлтүүд нь кластерыг жигд ачаалах боломжтой болно. Гэхдээ ерөнхийдөө энэ бол өгөгдлийг бүрэн жигд тараадаггүй түр зуурын шийдэл гэж таны хэлсэн үг туйлын зөв юм.
Асуултанд хариулах хэдэн оноо надад байна. Тэдний нэг нь дахин хуваах нь өвдөлт багатай байхын тулд эхлээд хуваах схемийг хэрхэн төлөвлөх тухай юм. Энэ нь үргэлж боломжтой байдаггүй.
Жишээлбэл, танд хяналтын мэдээлэл байна. Хяналтын мэдээлэл гурван шалтгааны улмаас нэмэгдэж байна. Эхнийх нь түүхэн мэдээллийн хуримтлал юм. Хоёр дахь нь замын хөдөлгөөний өсөлт юм. Гурав дахь нь хяналтад байгаа зүйлсийн тоог нэмэгдүүлэх. Хадгалах шаардлагатай шинэ бичил үйлчилгээ болон хэмжүүрүүд бий.
Эдгээрээс хамгийн том өсөлт нь гуравдахь шалтгаан буюу мониторингийн хэрэглээ нэмэгдсэнтэй холбоотой байж магадгүй юм. Мөн энэ тохиолдолд ачааллын шинж чанар, сонгох гол асуултууд юу вэ гэдгийг харах нь зүйтэй. Сонголт хийх үндсэн асуулга нь хэмжүүрийн зарим дэд бүлэгт тулгуурласан байх магадлалтай.
Жишээлбэл, зарим сервер дээр CPU-ийн хэрэглээ зарим үйлчилгээ. Энэ өгөгдлийг олж авах түлхүүрүүдийн тодорхой хэсэг байгаа нь харагдаж байна. Мөн энэ өгөгдлийн хүсэлт нь өөрөө маш энгийн бөгөөд хэдэн арван миллисекундэд дуусдаг. Хяналтын үйлчилгээ болон хяналтын самбарт ашигладаг. Би үүнийг зөв ойлгосон гэж найдаж байна.
Владимир Колобаев: Бид одоогийн нөхцөл байдлыг бодит цаг хугацаанд нь түүхэн нөхцөл байдалтай харьцуулж байгаа тул түүхэн өгөгдөлд байнга ханддаг нь баримт юм. Бидний хувьд их хэмжээний өгөгдөлд хурдан хандах нь чухал бөгөөд ClickHouse үүнийг маш сайн гүйцэтгэдэг.
Таны үнэхээр зөв, бид аливаа хяналтын системтэй адил сүүлийн өдөр унших хүсэлтийн ихэнхийг мэдэрдэг. Гэхдээ үүнтэй зэрэгцэн түүхэн мэдээллийн ачаалал бас нэлээд том байна. Энэ нь үндсэндээ гучин секунд тутамд ажилладаг дохиоллын системээс гаралтай бөгөөд ClickHouse-д "Сүүлийн зургаан долоо хоногийн өгөгдлийг надад өгөөч. Одоо надад тэднээс ямар нэгэн хөдөлж буй дундажийг гаргаж өгөөд, одоогийн үнэ цэнийг түүхэнтэй харьцуулъя."
Саяхны ийм хүсэлтийн хувьд бид хоёр өдрийн өгөгдөл хадгалдаг өөр нэг жижиг хүснэгттэй бөгөөд үндсэн хүсэлтүүд түүн рүү нисдэг гэдгийг хэлмээр байна. Бид зөвхөн том хэмжээний түүхийн асуулга илгээдэг.
Алексей Миловидов: Харамсалтай нь, энэ нь таны хувилбарт тохиромжгүй юм шиг санагдаж байна, гэхдээ би танд ашиглах шаардлагагүй, гэхдээ найзуудынхаа үйлчилгээнд ашигладаг хоёр муу, төвөгтэй хуваах схемийн тайлбарыг хэлье.
Yandex.Metrica үйл явдлуудтай үндсэн кластер байдаг. Үйл явдал нь хуудасны үзвэр, товшилт, хөрвүүлэлт юм. Ихэнх хүсэлт нь тодорхой вэбсайт руу ордог. Та Yandex.Metrica үйлчилгээг нээгээд, танд вэбсайт байгаа - avito.ru, тайлан руу очиж, таны вэбсайтад хүсэлт гаргана.
Гэхдээ дотоод шинжээчдийн хийсэн аналитик болон дэлхийн бусад хүсэлтүүд байдаг. Ямар ч тохиолдолд дотоод шинжээчид зөвхөн Yandex үйлчилгээнд хүсэлт гаргадаг гэдгийг би тэмдэглэж байна. Гэсэн хэдий ч Yandex үйлчилгээ хүртэл бүх мэдээллийн ихээхэн хувийг эзэлдэг. Эдгээр нь тусгай тоолуур биш, харин илүү өргөн шүүлтүүрийн хүсэлт юм.
Бүх зүйл нэг тоолуур болон глобал асуулгад үр дүнтэй ажиллахаар өгөгдлийг хэрхэн зохион байгуулах вэ? Өөр нэг бэрхшээл бол Metrics кластерт зориулсан ClickHouse дахь хүсэлтийн тоо секундэд хэдэн мянга байдаг. Үүний зэрэгцээ нэг ClickHouse сервер нь өчүүхэн бус хүсэлтийг хариуцаж чадахгүй, жишээлбэл секундэд хэдэн мянган.
Кластерын хэмжээ нь зургаан зуун сервер юм. Хэрэв та энэ кластер дээр тархсан хүснэгтийг чирээд хэдэн мянган хүсэлт илгээвэл энэ нь нэг сервер рүү илгээхээс ч дор болно. Нөгөөтэйгүүр, өгөгдөл жигд тархсан, бид очиж бүх серверээс хүсэлт гаргадаг гэсэн сонголтыг шууд хэрэгсэхгүй болгосон.
Диаметрийн эсрэг талын сонголт байдаг. Бид сайтууд дээрх өгөгдлийг хуваах бөгөөд нэг сайтын хүсэлт нэг хэсэг рүү очно гэж төсөөлөөд үз дээ. Одоо кластер секундэд арван мянган хүсэлтийг хариуцах боломжтой боловч нэг хэлтэрхий дээр нэг хүсэлт хэтэрхий удаан ажиллах болно. Энэ нь дамжуулах чадварын хувьд цаашид масштабгүй болно. Ялангуяа энэ бол avito.ru сайт юм. Avito бол RuNet-ийн хамгийн их зочилдог сайтуудын нэг гэж хэлвэл би нууцыг задлахгүй. Үүнийг нэг хэлтэрхий дээр боловсруулах нь галзуурал болно.
Тиймээс sharding схемийг илүү зальтай байдлаар зохион бүтээсэн. Бүхэл бүтэн кластер нь хэд хэдэн кластерт хуваагддаг бөгөөд бид үүнийг давхарга гэж нэрлэдэг. Кластер бүр нь араваас хэдэн арван ширхэгийг агуулдаг. Нийтдээ гучин есөн ийм кластер байдаг.
Энэ бүхэн хэрхэн хэмжигдэж байна вэ? Кластерын тоо өөрчлөгдөөгүй - хэдэн жилийн өмнө гучин есөн байсан бол энэ хэвээр байна. Гэхдээ тэдгээрийн дотор бид өгөгдөл хуримтлуулахын хэрээр хэсгүүдийн тоог аажмаар нэмэгдүүлдэг. Sharding схем нь бүхэлдээ иймэрхүү байна: эдгээр кластерууд нь вэбсайтуудад хуваагддаг бөгөөд аль вэб сайт аль кластер дээр байгааг ойлгохын тулд MySQL-д тусдаа метабааз ашигладаг. Нэг сайт - нэг кластер дээр. Үүний дотор зочдын ID-ийн дагуу хуваалт үүсдэг.
Бичлэг хийхдээ бид зочны үнэмлэхний үлдсэн хэсэгт хуваана. Гэхдээ шинэ хэлтэрхий нэмэх үед хуваах схем өөрчлөгддөг; бид үргэлжлүүлэн хуваах боловч үлдсэн хэсэг нь өөр тоогоор хуваагдана. Энэ нь нэг зочин аль хэдийн хэд хэдэн сервер дээр байрладаг гэсэн үг бөгөөд та үүнд найдаж болохгүй. Энэ нь зөвхөн өгөгдлийг илүү сайн шахах зорилгоор хийгддэг. Мөн хүсэлт гаргахдаа бид кластерыг харж, олон арван серверт ханддаг Distributed хүснэгт рүү очдог. Энэ бол ийм тэнэг схем юм.
Гэхдээ бид энэ схемийг орхисон гэж хэлэхгүй бол миний түүх бүрэн бус байх болно. Шинэ схемд бид бүгдийг өөрчилж, clickhouse-copier ашиглан бүх өгөгдлийг хуулсан.
Шинэ схемд бүх сайтыг том, жижиг гэсэн хоёр ангилалд хуваадаг. Босгыг хэрхэн сонгосныг мэдэхгүй ч үр дүнд нь том сайтуудыг нэг кластер дээр бүртгэсэн бөгөөд тус бүр нь гурван хуулбартай 120 ширхэг, өөрөөр хэлбэл 360 сервер байдаг. Мөн хуваах схем нь ямар ч хүсэлт бүх хэлтэрхий рүү нэг дор очдог. Хэрэв та одоо Yandex.Metrica-д avito.ru-д зориулсан тайлангийн хуудсыг нээвэл хүсэлт 120 серверт очно. RuNet-д цөөхөн том сайтууд байдаг. Мөн хүсэлт нь секундэд мянга биш, бүр зуу хүрэхгүй. Энэ бүгдийг 120 серверээр боловсруулдаг Түгээмэл хүснэгт чимээгүйхэн зажилдаг.
Хоёрдахь кластер нь жижиг сайтуудад зориулагдсан. Энд сайтын ID дээр суурилсан хуваах схем байгаа бөгөөд хүсэлт бүр яг нэг хэлтэрхий рүү очдог.
ClickHouse нь clickhouse-хувилагч хэрэгсэлтэй. Та түүний тухай бидэнд хэлж чадах уу?
Энэ шийдэл нь илүү төвөгтэй, бүтээмж багатай гэдгийг би шууд хэлье. Давуу тал нь таны зааж өгсөн загварын дагуу өгөгдлийг бүрэн түрхдэг. Гэхдээ энэ хэрэгслийн сул тал нь огт дахин нунтаглахгүй байх явдал юм. Энэ нь нэг кластер схемээс нөгөө кластер схемд өгөгдлийг хуулдаг.
Энэ нь ажиллахын тулд та хоёр кластертай байх ёстой гэсэн үг юм. Тэдгээрийг ижил серверүүд дээр байрлуулж болох боловч өгөгдлийг аажмаар шилжүүлэхгүй, харин хуулбарлах болно.
Жишээлбэл, дөрвөн сервер байсан бол одоо найм болсон. Та бүх серверүүд дээр шинэ Тархсан хүснэгт, шинэ локал хүснэгтүүд үүсгэж, clickhouse-copier ажиллуулж, тэндээс уншиж, шинэ хуваах схемийг хүлээн авч, өгөгдлийг тэнд шилжүүлэх ёстой ажлын схемийг зааж өгнө. Хуучин серверүүд дээр та одоогийнхоос нэг хагас дахин их зай хэрэгтэй болно, учир нь хуучин өгөгдөл нь тэдгээр дээр үлдэх ёстой бөгөөд хуучин өгөгдлийн тал нь тэдний дээр ирэх болно. Хэрэв та өгөгдлийг дахин хуваах шаардлагатай бөгөөд зай байгаа гэж урьдчилан бодож байсан бол энэ арга тохиромжтой.
Clickhouse-copier дотор хэрхэн ажилладаг вэ? Энэ нь бүх ажлыг нэг хүснэгтийн нэг хуваалтыг нэг хэлтэрхий дээр боловсруулахад зориулсан багц даалгавар болгон хуваадаг. Эдгээр бүх даалгавруудыг зэрэгцүүлэн гүйцэтгэж болох ба clickhouse-copier-ийг өөр өөр машинууд дээр олон тохиолдлоор ажиллуулж болох боловч нэг хуваалтад хийх зүйл нь оруулах сонголтоос өөр зүйл биш юм. Өгөгдлийг уншиж, задалж, дахин хувааж, дараа нь дахин шахаж, хаа нэгтээ бичиж, дахин эрэмбэлдэг. Энэ бол илүү хатуу шийдвэр юм.
Танд reshading гэдэг туршилтын зүйл байсан. Түүнтэй яах вэ?
2017 онд та дахин шарлах гэх туршилтын зүйлтэй байсан. ClickHouse-д ч гэсэн сонголт бий. Миний ойлгож байгаагаар хөөрсөнгүй. Яагаад ийм зүйл болсныг хэлж чадах уу? Энэ нь их хамааралтай юм шиг байна.
Бүх асуудал бол хэрэв өгөгдлийг байрандаа дахин хуваах шаардлагатай бол үүнийг атомын аргаар хийхийн тулд маш нарийн төвөгтэй синхрончлол шаардлагатай болно. Энэ синхрончлол хэрхэн явагддагийг судалж эхлэхэд үндсэн асуудлууд байгаа нь тодорхой болсон. Эдгээр үндсэн асуудлууд нь зөвхөн онолын хувьд төдийгүй, тэр даруйдаа практик дээр маш энгийнээр тайлбарлаж болох зүйл хэлбэрээр өөрсдийгөө харуулж эхэлсэн - юу ч ажиллахгүй байна.
Бүх өгөгдлийг удаашруулах диск рүү шилжүүлэхээс өмнө нэгтгэх боломжтой юу?
Нэгтгэх үед удаан диск рүү шилжих сонголттой TTL-ийн тухай асуулт. Бүх хэсгүүдийг удаан диск рүү шилжүүлэхээс өмнө нэг хэсэг болгон нэгтгэх cron-ээс өөр арга бий юу?
Асуултын хариулт нь шилжүүлэхээсээ өмнө бүх хэсгүүдийг автоматаар нэг болгон нааж болно - үгүй. Би үүнийг шаардлагагүй гэж бодож байна. Та бүх хэсгүүдийг нэг болгон нэгтгэх шаардлагагүй, гэхдээ тэдгээр нь автоматаар удаан диск рүү шилжих болно гэдэгт найдаж байна.
Бидэнд шилжүүлэх дүрмийн хоёр шалгуур бий. Эхнийх нь дүүрсэн байдлаараа байна. Хэрэв одоогийн хадгалалтын түвшин тодорхой хувиас бага сул зайтай бол бид нэг хэсгийг сонгоод удаан хадгалах руу шилжүүлнэ. Эсвэл илүү удаан биш, харин дараагийнх нь - таны тохируулснаар.
Хоёрдахь шалгуур бол хэмжээ юм. Энэ нь том хэсгүүдийг зөөх тухай юм. Хурдан диск дээрх сул зайд тохируулан босгыг тохируулах боломжтой бөгөөд өгөгдлийг автоматаар дамжуулах болно.
Хэрэв нийцтэй байдлыг урьдчилан шалгах боломжгүй бол ClickHouse-ийн шинэ хувилбар руу хэрхэн шилжих вэ?
Энэ сэдвийг байнга хэлэлцдэг янз бүрийн хувилбаруудыг харгалзан үзэж, одоо ч гэсэн. 19.11-ээс 19.16 хүртэл, жишээ нь 19.16-аас 20.3 хүртэл шинэчлэх нь хэр аюулгүй вэ. Хамгаалалтын орчинд нийцтэй байдлыг урьдчилан шалгахгүйгээр шинэ хувилбар руу шилжих хамгийн сайн арга юу вэ?
Энд хэд хэдэн "алтан" дүрэм байдаг. Эхлээд - . Энэ нь том хэмжээтэй боловч үл нийцэх өөрчлөлтүүдийн талаар тусдаа догол мөрүүд байдаг. Эдгээр цэгүүдийг улаан туг гэж бүү харьц. Эдгээр нь ихэвчлэн таны ашигладаггүй зарим захын функцтэй холбоотой бага зэргийн үл нийцэл юм.
Хоёрдугаарт, хэрэв хамгаалагдсан хязгаарлагдмал орчинд нийцтэй байдлыг шалгах арга байхгүй бөгөөд та үйлдвэрлэлд нэн даруй шинэчлэхийг хүсч байвал үүнийг хийх шаардлагагүй гэж зөвлөж байна. Эхлээд хамгаалагдсан хязгаарлагдмал орчин үүсгээд туршина. Хэрэв туршилтын орчин байхгүй бол танд маш том компани байхгүй байх магадлалтай бөгөөд энэ нь та зарим өгөгдлийг зөөврийн компьютер дээрээ хуулж, бүх зүйл зөв ажиллаж байгаа эсэхийг шалгах боломжтой гэсэн үг юм. Та өөрийн машин дээр хэд хэдэн хуулбарыг дотооддоо өсгөж болно. Эсвэл та ойролцоох хаа нэгтээгээс шинэ хувилбарыг нь авч, зарим өгөгдлийг тэнд байршуулж болно, өөрөөр хэлбэл туршилтын орчинг бий болгож болно.
Өөр нэг дүрэм бол хувилбарыг гаргаснаас хойш долоо хоногийн турш шинэчлэгдэхгүй байх явдал бөгөөд үйлдвэрлэлийн явцад гарсан алдаануудыг олж засварлаж, дараа нь хурдан зассан. Төөрөлдөхгүйн тулд ClickHouse хувилбаруудын дугаарыг олж мэдье.
20.3.4 хувилбар байна. 20 тоо нь үйлдвэрлэсэн оныг заана - 2020. Дотор байгаа зүйлээс харахад энэ нь хамаагүй, тиймээс бид үүнийг анхаарч үзэхгүй. Дараагийн - 20.3. Бид зарим шинэ функц бүхий хувилбар гаргах бүртээ хоёр дахь тоог - энэ тохиолдолд 3-ыг нэмэгдүүлдэг. Хэрэв бид ClickHouse-д зарим функц нэмэхийг хүсвэл энэ тоог нэмэгдүүлэх ёстой. Өөрөөр хэлбэл ClickHouse 20.4 хувилбар дээр илүү сайн ажиллах болно. Гурав дахь орон нь 20.3.4. Энд 4 нь шинэ боломжуудыг нэмээгүй боловч зарим алдааг зассан засварын хувилбаруудын тоо юм. 4 гэдэг нь бид үүнийг дөрвөн удаа хийсэн гэсэн үг.
Энэ бол аймшигтай зүйл гэж битгий бодоорой. Ихэвчлэн хэрэглэгч хамгийн сүүлийн хувилбарыг суулгаж болох бөгөөд энэ нь жил бүр ажиллах хугацаандаа ямар ч асуудалгүйгээр ажиллах болно. Гэхдээ манай хятад нөхдүүдийн нэмсэн битмап боловсруулах зарим функцэд буруу аргумент дамжуулах үед сервер гацдаг гэж төсөөлөөд үз дээ. Үүнийг засах үүрэгтэй. Бид шинэ засварын хувилбарыг гаргах бөгөөд ClickHouse илүү тогтвортой байх болно.
Хэрэв танд ClickHouse ажиллаж байгаа бөгөөд ClickHouse-ийн шинэ хувилбар нэмэлт боломжуудтай бол - жишээлбэл, 20.4.1 нь хамгийн анхных нь, эхний өдөр л үүнийг үйлдвэрлэлд оруулах гэж бүү яар. Энэ нь яагаад хэрэгтэй байна вэ? Хэрэв та ClickHouse-г ашиглаагүй бол суулгаж болно, магадгүй бүх зүйл сайхан болно. Хэрэв ClickHouse аль хэдийн тогтвортой ажиллаж байгаа бол засварууд болон шинэчлэлтүүдийг анхаарч, ямар асуудлуудыг засаж байгааг хараарай.
Кирилл Шваков: Би туршилтын орчны талаар бага зэрэг нэмэхийг хүсч байна. Хүн бүр туршилтын орчноос маш их айдаг бөгөөд ямар нэг шалтгааны улмаас хэрэв танд маш том ClickHouse кластер байгаа бол туршилтын орчин багагүй эсвэл дор хаяж арав дахин бага байх ёстой гэж үздэг. Ерөөсөө тийм биш.
Би өөрийнхөө жишээн дээр хэлж чадна. Надад нэг төсөл бий, бас ClickHouse байна. Манай туршилтын орчин нь зөвхөн түүнд зориулагдсан - энэ бол бүх зүйлийг байрлуулсан хорин еврогийн үнэтэй Хетцнер дэх жижиг виртуал машин юм. Үүнийг хийхийн тулд бид Ansible-д бүрэн автоматжуулалттай тул зарчмын хувьд хаашаа явах нь хамаагүй - техник хангамжийн серверүүд эсвэл зүгээр л виртуал машинд байршуулах.
Юу хийж болох вэ? Өөр өөр хүмүүс өөр өөр байршуулалттай байдаг тул Docker, LXC-д, магадгүй Ansible тоглоомын дэвтэр үүсгэж болно гэсэн жижиг кластерыг өөрийн гэртээ хэрхэн байрлуулах тухай ClickHouse баримт бичигт жишээ өгөх нь сайхан байх болно. Энэ нь маш их хялбарчлах болно. Таван минутын дотор кластер авч, байршуулах үед ямар нэг зүйлийг олоход илүү хялбар болно. Энэ нь илүү тохиромжтой, учир нь таны туршиж үзээгүй үйлдвэрлэлийн хувилбар руу шилжих нь хаашаа ч хүрэх зам биш юм. Заримдаа энэ нь ажилладаг, заримдаа болохгүй. Тиймээс амжилтанд найдах нь муу юм.
Максим Котяков, ахлах инженер Авито: Би томоохон компаниудад тулгардаг хэд хэдэн асуудлаас туршилтын орчны талаар бага зэрэг нэмэх болно. Бидэнд бүрэн хэмжээний ClickHouse хүлээн авах кластер байгаа бөгөөд өгөгдлийн схем, тохиргооны хувьд энэ нь үйлдвэрлэлд байгаа зүйлийн яг хуулбар юм. Энэ кластер нь хамгийн бага нөөцтэй, нэлээн муудсан саванд байрлуулсан. Бид үйлдвэрлэлийн мэдээллийн тодорхой хувийг тэнд бичдэг, аз болоход Кафка дахь урсгалыг хуулбарлах боломжтой. Тэнд бүх зүйл синхрончлогдсон, масштабтай байдаг - хүчин чадал, урсгалын хувьд хоёулаа, онолын хувьд бусад бүх зүйл тэнцүү байх ёстой, хэмжүүрийн хувьд үйлдвэрлэлийн адил байх ёстой. Тэсэрч дэлбэрэх боломжтой бүх зүйлийг эхлээд энэ тавиур дээр өнхрүүлж, бэлэн болтол тэнд хэдэн өдөр байлгана. Гэхдээ мэдээжийн хэрэг, энэ шийдэл нь үнэтэй, хэцүү бөгөөд дэмжлэгийн зардал нь тэгээс ялгаатай.
Алексей Миловидов: Yandex.Metrica-ийн найзуудын туршилтын орчин ямар байгааг би танд хэлье. Нэг кластерт 600 сондгой сервер, нөгөө нь 360 сервертэй, гурав дахь болон хэд хэдэн кластерууд байдаг. Тэдгээрийн аль нэгнийх нь туршилтын орчин нь тус бүрдээ хоёр хуулбартай хоёр хэлтэрхий юм. Яагаад хоёр хэлтэрхий гэж? Ингэснээр та ганцаараа биш байх болно. Мөн хуулбарууд бас байх ёстой. Зөвхөн таны төлж чадах хамгийн бага хэмжээ.
Энэхүү туршилтын орчин нь таны асуулга ажиллаж байгаа эсэх, ямар нэгэн томоохон зүйл эвдэрсэн эсэхийг шалгах боломжийг танд олгоно. Гэхдээ ихэнхдээ бүх зүйл ажиллахад огт өөр шинж чанартай асуудал үүсдэг, гэхдээ ачаалал бага зэрэг өөрчлөгддөг.
Би танд нэг жишээ хэлье. Бид ClickHouse-ийн шинэ хувилбарыг суулгахаар шийдсэн. Энэ нь туршилтын орчинд тавигдсан, автоматжуулсан туршилтууд Yandex.Metrica-д хийгдсэн бөгөөд хуучин болон шинэ хувилбаруудын өгөгдлийг харьцуулж, бүх дамжуулах хоолойг ажиллуулдаг. Мэдээжийн хэрэг, манай CI-ийн ногоон тестүүд. Тэгэхгүй бол бид энэ хувилбарыг санал болгох ч үгүй байсан.
Бүх зүйл сайхан байна. Бид үйлдвэрлэлд шилжиж эхэлж байна. График дээрх ачаалал хэд дахин нэмэгдсэн гэсэн мессежийг би хүлээн авдаг. Бид хувилбарыг буцааж байна. Графикийг хараад би харж байна: ашиглалтын явцад ачаалал хэд хэдэн удаа нэмэгдэж, гарч ирэхэд буцаж буурсан байна. Дараа нь бид хувилбарыг буцааж эхлэв. Тэгээд ачаалал нь тэр чигээрээ нэмэгдэж, буцаад унасан. Тиймээс дүгнэлт нь ийм байна: төлөвлөлтийн улмаас ачаалал нэмэгдсэн, гайхах зүйл алга.
Дараа нь хамт ажиллагсдаа шинэ хувилбарыг суулгахад итгүүлэхэд хэцүү байсан. Би: "Зүгээр дээ, гараад ир. Хуруугаа холбоно, бүх зүйл ажиллах болно. Одоо график дээрх ачаалал нэмэгдсэн ч бүх зүйл хэвийн байна. Тэвчээрэй." Ерөнхийдөө бид үүнийг хийсэн, тэгээд л болоо - хувилбарыг үйлдвэрлэхээр гаргасан. Гэхдээ бараг бүх зохион байгуулалттай ижил төстэй асуудлууд гарч ирдэг.
Kill query нь асуулга устгах ёстой боловч үгүй. Яагаад?
Нэгэн төрлийн шинжээч над дээр ирж, миний ClickHouse кластерийг тавьсан хүсэлтийг үүсгэсэн. Хүсэлт аль хуулбар эсвэл хэлтэрхий рүү очсоноос хамааран зарим зангилаа эсвэл бүхэл кластер. Энэ сервер дээрх бүх CPU-ийн нөөц тавиур дээр байгаа, бүх зүйл улаан өнгөтэй байгааг би харж байна. Үүний зэрэгцээ ClickHouse өөрөө хүсэлтэд хариу өгдөг. Тэгээд би бичнэ: "Надад энэ солиорлыг үүсгэсэн хүсэлтийн жагсаалтыг боловсруулна уу."
Би энэ хүсэлтийг олж аваад түүнд kill гэж бичдэг. Тэгээд юу ч болоогүйг би харж байна. Миний сервер тавиур дээр байгаа, ClickHouse дараа нь надад зарим тушаалуудыг өгч, сервер амьд байгааг харуулж, бүх зүйл сайхан байна. Гэхдээ миний бүх хэрэглэгчийн хүсэлтэд доройтол байгаа, доройтол нь ClickHouse дахь бүртгэлээс эхэлдэг бөгөөд миний kill query ажиллахгүй байна. Яагаад? Би kill query нь асуулга устгах ёстой гэж бодсон ч тийм биш.
Одоо нэлээд хачирхалтай хариулт гарах болно. Гол нь kill query нь асуултуудыг устгадаггүй.
Kill query нь "Би энэ асуулгыг устгахыг хүсч байна" гэсэн жижиг хайрцгийг шалгана. Блок бүрийг боловсруулахдаа хүсэлт нь өөрөө энэ тугийг хардаг. Хэрэв үүнийг тохируулсан бол хүсэлт ажиллахаа болино. Хүсэлтийг хэн ч алдаггүй, тэр өөрөө бүх зүйлийг шалгаж, зогсоох ёстой. Энэ нь хүсэлт нь өгөгдлийн блокуудыг боловсруулж байгаа бүх тохиолдолд ажиллах ёстой. Энэ нь дараагийн өгөгдлийн блокыг боловсруулж, тугийг шалгаад зогсох болно.
Зарим үйлдэл дээр хүсэлтийг хаасан тохиолдолд энэ нь ажиллахгүй. Үнэн, энэ нь таны хэрэг биш байх магадлалтай, учир нь таны хэлснээр энэ нь серверийн нөөцийг ашигладаг. Энэ нь гаднаас ялгах болон бусад нарийн ширийн зүйлд ажиллахгүй байж магадгүй юм. Гэхдээ ерөнхийдөө ийм зүйл болохгүй, энэ бол алдаа юм. Миний санал болгож чадах цорын ганц зүйл бол ClickHouse-г шинэчлэх явдал юм.
Унших ачааллын үед хариу өгөх хугацааг хэрхэн тооцоолох вэ?
Зүйлийн агрегатуудыг хадгалдаг хүснэгт байдаг - янз бүрийн тоолуур. Шугамын тоо ойролцоогоор зуун сая байна. Хэрэв та 1K зүйлд 1K RPS асгавал урьдчилан таамаглах боломжтой хариу өгөх хугацааг тооцох боломжтой юу?
Контекстээс харахад бид унших ачааллын талаар ярьж байна, учир нь бичихэд ямар ч асуудал байхгүй - бүр мянга, бүр зуун мянга, заримдаа хэдэн сая мөр оруулж болно.
Унших хүсэлт нь маш өөр байдаг. Сонголт 1-д ClickHouse нь секундэд хэдэн арван мянган хүсэлтийг гүйцэтгэх боломжтой тул нэг түлхүүрийн хүсэлтэд ч гэсэн зарим нөөц шаардлагатай болно. Мөн ийм цэгийн асуулга нь зарим түлхүүр утгын мэдээллийн сангаас илүү хэцүү байх болно, учир нь унших бүрт өгөгдлийн блокыг индексээр унших шаардлагатай байдаг. Манай индекс бичлэг бүрийг биш, харин муж бүрийг харуулдаг. Өөрөөр хэлбэл та бүх хүрээг унших хэрэгтэй болно - энэ нь анхдагчаар 8192 мөр юм. Мөн та шахсан өгөгдлийн блокыг 64 КБ-аас 1 МБ хүртэл задлах хэрэгтэй болно. Ихэвчлэн ийм зорилтот асуулга дуусгахад хэдэн миллисекунд шаардлагатай байдаг. Гэхдээ энэ бол хамгийн энгийн сонголт юм.
Энгийн арифметикийг туршиж үзье. Хэрэв та хэдэн миллисекундийг мянгаар үржүүлбэл хэдхэн секунд болно. Секундэд хэдэн мянган хүсэлтийг хүлээж авах боломжгүй юм шиг, гэхдээ үнэндээ боломжтой, учир нь бидэнд хэд хэдэн процессорын цөм байдаг. Тиймээс, зарчмын хувьд ClickHouse заримдаа 1000 RPS-ийг барьж чаддаг, гэхдээ богино хүсэлт, ялангуяа зорилтот хүсэлтийн хувьд.
Хэрэв та ClickHouse кластерыг энгийн хүсэлтийн тоогоор томруулах шаардлагатай бол би хамгийн энгийн зүйлийг санал болгож байна - хуулбарын тоог нэмэгдүүлж, санамсаргүй хуулбар руу хүсэлт илгээнэ үү. Хэрэв нэг хуулбар нь секундэд таван зуун хүсэлтийг агуулдаг бөгөөд энэ нь бүрэн бодитой юм бол гурван хуулбар нь нэг хагас мянгад хүрэх болно.
Заримдаа мэдээжийн хэрэг та ClickHouse-г хамгийн их онооны уншилтаар тохируулж болно. Үүнд юу хэрэгтэй вэ? Эхнийх нь индексийн ширхэглэлийг багасгах явдал юм. Энэ тохиолдолд үүнийг нэг болгон бууруулж болохгүй, гэхдээ индекс дэх оруулгуудын тоо нь сервер бүрт хэдэн сая эсвэл хэдэн арван сая байх болно. Хэрэв хүснэгт нь зуун сая мөртэй бол нарийн ширийнийг 64 болгож тохируулж болно.
Та шахсан блокны хэмжээг багасгаж болно. Үүнд зориулсан тохиргоонууд байдаг мин шахах блокийн хэмжээ, хамгийн их шахалтын блокийн хэмжээ. Тэдгээрийг багасгаж, мэдээллээр дүүргэж, дараа нь зорилтот асуулга илүү хурдан байх болно. Гэсэн хэдий ч ClickHouse нь түлхүүр утгын мэдээллийн сан биш юм. Олон тооны жижиг хүсэлтүүд нь ачааллын эсрэг загвар юм.
Кирилл Шваков: Тэнд энгийн данс байгаа тохиолдолд би зөвлөгөө өгөх болно. ClickHouse ямар нэгэн төрлийн тоолуур хадгалдаг бол энэ нь нэлээд стандарт нөхцөл юм. Надад нэг хэрэглэгч байна, тэр ийм ийм орных, гуравдагч талбар, би ямар нэг зүйлийг аажмаар нэмэгдүүлэх хэрэгтэй. MySQL-г аваад, өвөрмөц түлхүүр хий - MySQL-д энэ нь давхардсан түлхүүр, PostgreSQL-д энэ нь зөрчилтэй - нэмэх тэмдэг нэмнэ үү. Энэ нь хамаагүй дээр ажиллах болно.
Хэрэв танд тийм ч их мэдээлэл байхгүй бол ClickHouse-г ашиглах нь тийм ч чухал биш юм. Байнгын мэдээллийн сан байдаг бөгөөд тэд үүнийг сайн хийдэг.
Би ClickHouse дээр юуг өөрчлөх вэ, ингэснээр кэшэд илүү их мэдээлэл байх вэ?
Нөхцөл байдлыг төсөөлөөд үз дээ - серверүүд нь 256 ГБ RAM-тай, өдөр тутмын хэрэглээнд ClickHouse нь 60-80 ГБ, оргил үедээ - 130 хүртэл байдаг. Кэшэнд илүү их мэдээлэл байхын тулд юуг идэвхжүүлж, өөрчлөх боломжтой. диск рүү аялах нь бага байна уу?
Ерөнхийдөө үйлдлийн системийн хуудасны кэш үүнийг сайн гүйцэтгэдэг. Хэрэв та зүгээр л дээд талыг нь нээвэл кэштэй эсвэл чөлөөтэй хараарай - энэ нь мөн хэр их кэштэй болохыг зааж өгсөн болно - тэгвэл бүх чөлөөт санах ойг кэшэд ашиглаж байгааг анзаарах болно. Мөн энэ өгөгдлийг уншихдаа дискнээс биш, харин RAM-аас унших болно. Үүний зэрэгцээ кэш нь шахагдсан өгөгдөл учраас кэшийг үр дүнтэй ашигладаг гэж би хэлж чадна.
Гэсэн хэдий ч, хэрэв та зарим энгийн асуултуудыг илүү хурдасгахыг хүсвэл ClickHouse доторх задалсан өгөгдөлд кэшийг идэвхжүүлэх боломжтой. гэж нэрлэдэг шахагдаагүй кэш. config.xml тохиргооны файлд шахагдаагүй кэшийн хэмжээг шаардлагатай хэмжээнд нь тохируулаарай - би үнэгүй RAM-ийн талаас илүүгүйг санал болгож байна, учир нь үлдсэн хэсэг нь хуудасны кэшийн доор орох болно.
Үүнээс гадна хүсэлтийн түвшний хоёр тохиргоо байдаг. Эхний тохиргоо - шахагдаагүй кэш ашиглах - түүний хэрэглээ орно. Бүх өгөгдлийг уншиж, кэшийг цэвэрлэх боломжтой хүнд хүсэлтээс бусад бүх хүсэлтүүдэд үүнийг идэвхжүүлэхийг зөвлөж байна. Хоёрдахь тохиргоо нь кэшийг ашиглах мөрүүдийн хамгийн их тоотой адил зүйл юм. Энэ нь автоматаар том асуулгад хязгаарлалт тавьдаг бөгөөд ингэснээр тэд кэшийг тойрч гарах болно.
Би RAM-д хадгалах хадгалах_тохиргоог хэрхэн тохируулах вэ?
Шинэ ClickHouse баримт бичигт би холбогдох хэсгийг уншсан . Тайлбар нь хурдан SSD-ийн жишээг агуулна.
Эзлэхүүнтэй халуун санах ойтой ижил зүйлийг хэрхэн тохируулахыг би гайхаж байна. Бас нэг асуулт. Сонголт нь энэ өгөгдлийн байгууллагатай хэрхэн ажилладаг вэ, энэ нь бүхэл бүтэн багцыг унших уу эсвэл зөвхөн дискэн дээр байгаа өгөгдлийг унших уу, энэ өгөгдөл санах ойд шахагдсан уу? Ийм мэдээллийн байгууллагатай prewhere хэсэг хэрхэн ажилладаг вэ?
Энэ тохиргоо нь өгөгдлийн хэсгүүдийн хадгалалтад нөлөөлдөг бөгөөд тэдгээрийн формат ямар ч байдлаар өөрчлөгддөггүй.
Илүү дэлгэрэнгүй харцгаая.
Та RAM-д өгөгдөл хадгалах тохиргоог хийж болно. Дискэнд тохируулсан бүх зүйл бол түүний зам юм. Та файлын системийн зарим замд холбогдсон tmpfs хуваалтыг үүсгэдэг. Та энэ замыг хамгийн халуун хуваалтад өгөгдөл хадгалах зам гэж зааж өгвөл өгөгдлийн хэсгүүд ирж, тэнд бичигдэж эхэлнэ, бүх зүйл хэвийн байна.
Гэхдээ найдвартай байдал бага тул үүнийг хийхийг зөвлөдөггүй, гэхдээ өөр өөр мэдээллийн төвд дор хаяж гурван хуулбар байгаа бол энэ нь боломжтой юм. Хэрэв ямар нэг зүйл тохиолдвол өгөгдөл сэргээгдэх болно. Серверийг гэнэт унтрааж, дахин асаасан гэж төсөөлөөд үз дээ. Хуваалтыг дахин суурилуулсан боловч тэнд юу ч байсангүй. ClickHouse сервер ажиллаж эхлэхэд эдгээр хэсгүүд байхгүй байгааг харж байгаа ч ZooKeeper мета өгөгдлийн дагуу тэдгээр нь тэнд байх ёстой. Тэр ямар хуулбар байгааг харж, хүсэлт тавьж, татаж авдаг. Ингэснээр өгөгдөл сэргээгдэх болно.
Энэ утгаараа RAM-д өгөгдлийг хадгалах нь дискэн дээр хадгалахаас үндсэндээ ялгаатай биш, учир нь өгөгдлийг дискэнд бичих үед эхлээд хуудасны кэшэд орж, дараа нь физик байдлаар бичигддэг. Энэ нь файлын системийг холбох сонголтоос хамаарна. Гэхдээ ямар ч тохиолдолд ClickHouse оруулах үед fsync хийхгүй гэж би хэлье.
Энэ тохиолдолд RAM дахь өгөгдөл нь дискэн дээрхтэй яг ижил форматаар хадгалагдана. Сонгох асуулга нь унших шаардлагатай хэсгүүдийг ижил аргаар сонгож, хэсгүүдээс шаардлагатай өгөгдлийн мужийг сонгож, уншдаг. Мөн prewhere нь өгөгдөл нь RAM эсвэл дискэн дээр байсан эсэхээс үл хамааран яг адилхан ажилладаг.
Low Cardinality нь ямар тооны өвөрмөц утгууд хүртэл үр дүнтэй вэ?
Low Cardinality нь ухаалаг зохион бүтээгдсэн. Энэ нь мэдээллийн толь бичгүүдийг эмхэтгэдэг боловч тэдгээр нь орон нутгийнх юм. Нэгдүгээрт, хэсэг тус бүрт өөр өөр толь бичиг байдаг, хоёрдугаарт, нэг хэсэг дотор ч гэсэн тэдгээр нь хүрээ тус бүрт өөр байж болно. Өвөрмөц утгуудын тоо босго тоо болох нэг саяд хүрэхэд толь бичиг зүгээр л хадгалагдаж, шинээр бий болно.
Хариулт нь ерөнхийдөө: орон нутгийн хүрээ бүрийн хувьд - өдөр бүр - хаа нэгтээ нэг сая хүртэлх өвөрмөц утгууд нь бага кардинал үр дүнтэй байдаг. Дараа нь зөвхөн нэг биш олон янзын толь бичгүүдийг ашиглах нөөц бий болно. Энэ нь ердийн мөр баганатай ойролцоогоор ижилхэн ажиллах болно, магадгүй бага зэрэг үр ашиг багатай боловч гүйцэтгэлийн ноцтой доройтол байхгүй болно.
Таван тэрбум мөр бүхий хүснэгтийг бүрэн текстээр хайх шилдэг туршлагууд юу вэ?
Янз бүрийн хариултууд байдаг. Эхнийх нь ClickHouse нь бүрэн текст хайлтын систем биш гэдгийг хэлэх явдал юм. Үүний тулд тусгай системүүд байдаг, жишээлбэл, и . Гэсэн хэдий ч би хүмүүс Elasticsearch-аас ClickHouse руу шилжиж байна гэж хэлэхийг улам бүр харж байна.
Яагаад ийм зүйл болдог вэ? Тэд үүнийг Elasticsearch индексийг бүтээхээс эхлээд зарим эзлэхүүн дэх ачааллыг даван туулахаа больсонтой холбон тайлбарлаж байна. Индексүүд хэтэрхий төвөгтэй болж, хэрэв та зүгээр л ClickHouse руу өгөгдлийг шилжүүлэх юм бол тэдгээр нь эзлэхүүний хувьд хэд дахин илүү үр дүнтэй хадгалагдах болно. Үүний зэрэгцээ хайлтын асуулга нь морфологийг харгалзан бүхэл бүтэн өгөгдлийн зарим хэллэгийг олох шаардлагатай байдаггүй, гэхдээ огт өөр хэллэгийг олох шаардлагатай болдог. Жишээлбэл, сүүлийн хэдэн цагийн бүртгэлээс байтуудын зарим дарааллыг олоорой.
Энэ тохиолдолд та ClickHouse-д индекс үүсгэх бөгөөд эхний талбар нь огноо, цаг байх болно. Мөн хамгийн том өгөгдлийн таслалтыг огнооны мужид үндэслэнэ. Сонгосон огнооны хүрээнд, дүрмээр бол, лайк ашиглан бүдүүлэг хүчний аргыг ашиглан ч гэсэн бүрэн текст хайлт хийх боломжтой байдаг. ClickHouse дахь like оператор нь таны олж болох хамгийн үр дүнтэй төстэй оператор юм. Хэрэв танд илүү сайн зүйл олдвол надад хэлээрэй.
Гэсэн хэдий ч, Like бүрэн скан байна. Мөн бүрэн скан хийх нь зөвхөн CPU дээр төдийгүй дискэн дээр удаан байж болно. Хэрэв гэнэт та өдөрт нэг терабайт өгөгдөлтэй болж, өдрийн турш үг хайж байгаа бол та терабайтыг сканнердах хэрэгтэй болно. Энэ нь ердийн хатуу дискүүд дээр байж магадгүй бөгөөд эцэст нь тэдгээр нь SSH-ээр дамжуулан энэ серверт нэвтрэх боломжгүй байхаар ачаалагдах болно.
Энэ тохиолдолд би дахиад нэг жижиг заль мэхийг санал болгоход бэлэн байна. Энэ нь туршилтын шинж чанартай - энэ нь ажиллах боломжтой, үгүй байж магадгүй юм. ClickHouse нь Trigram Bloom шүүлтүүр хэлбэрээр бүрэн текстийн индекстэй. Arenadata дахь манай хамт олон эдгээр индексийг аль хэдийн туршиж үзсэн бөгөөд тэдгээр нь ихэвчлэн зориулалтын дагуу ажилладаг.
Тэдгээрийг зөв ашиглахын тулд та яг хэрхэн ажилладаг талаар сайн ойлголттой байх ёстой: триграмм Блум шүүлтүүр гэж юу вэ, түүний хэмжээг хэрхэн сонгох вэ. Тэд өгөгдөлд ховор тохиолддог зарим ховор хэллэг, дэд мөрүүдийн талаархи асуулгад тусална гэж би хэлж чадна. Энэ тохиолдолд дэд мужуудыг индексээр сонгож, бага өгөгдөл унших болно.
Саяхан ClickHouse нь бүрэн текст хайхад илүү дэвшилтэт функцүүдийг нэмсэн. Энэ нь нэгдүгээрт, нэг дамжуулалтаар олон тооны дэд мөрүүдийг хайж олох явдал бөгөөд үүнд UTF-8 эсвэл зөвхөн ASCII-ийн дэмжлэгтэй, том жижиг жижиг жижиг жижиг үсэг мэдрэгчтэй сонголтууд багтана. Танд хэрэгтэй хамгийн үр дүнтэйг сонго.
Нэг дамжуулалтаар олон тогтмол хэллэг хайх боломжтой болсон. X-г нэг дэд мөр шиг, X-г өөр дэд мөр шиг бичих шаардлагагүй. Та тэр даруй бичиж, бүх зүйл аль болох үр дүнтэй хийгддэг.
Гуравдугаарт, одоо regexps-ийн ойролцоо хайлт болон дэд мөрүүдийн ойролцоо хайлт байна. Хэрэв хэн нэгэн үг буруу бичсэн бол хамгийн их тохирохыг хайж олох болно.
Олон тооны хэрэглэгчдэд ClickHouse-д хандах хандалтыг зохион байгуулах хамгийн сайн арга юу вэ?
Олон тооны хэрэглэгчид болон шинжээчдийн хандалтыг хэрхэн хамгийн сайн зохион байгуулахыг бидэнд хэлээрэй. Хэрхэн дараалал үүсгэх, хамгийн дээд зэрэглэлийн асуулгад эрэмбэлэх, ямар хэрэгслээр хангах вэ?
Хэрэв кластер хангалттай том бол шинжээчдийн нэвтрэх цэг болох хоёр серверийг нэмэгдүүлэх нь сайн шийдэл байх болно. Өөрөөр хэлбэл, шинжээчдэд кластер дахь тодорхой хэсгүүдэд хандахыг бүү зөвшөөр, харин өгөгдөлгүйгээр хоёр хоосон сервер үүсгэж, тэдгээрт хандах эрхийг тохируулах хэрэгтэй. Энэ тохиолдолд тархсан хүсэлтийн хэрэглэгчийн тохиргоог алсын сервер рүү шилжүүлдэг. Өөрөөр хэлбэл, та эдгээр хоёр сервер дээрх бүх зүйлийг тохируулах бөгөөд тохиргоо нь бүхэл бүтэн кластерт нөлөөлдөг.
Зарчмын хувьд эдгээр серверүүд өгөгдөлгүй боловч тэдгээрийн RAM-ийн хэмжээ нь хүсэлтийг гүйцэтгэхэд маш чухал юм. Гадаад нэгтгэх эсвэл гадаад эрэмбэлэхийг идэвхжүүлсэн тохиолдолд дискийг түр зуурын өгөгдөлд ашиглаж болно.
Бүх боломжит хязгаарлалттай холбоотой тохиргоог харах нь чухал юм. Хэрэв би одоо Yandex.Metrica кластерт шинжээчээр очиж хүсэлт асуувал хитүүдээс тоо сонгоно уу, дараа нь би хүсэлтийг биелүүлэх боломжгүй гэсэн онцгой нөхцөлийг нэн даруй өгөх болно. Миний скан хийх боломжтой мөрүүдийн дээд тоо нь зуун тэрбум бөгөөд кластер дээрх нэг хүснэгтэд нийтдээ тавин их наяд байна. Энэ бол эхний хязгаарлалт юм.
Би мөрийн хязгаарыг устгаад дахин асуулга ажиллууллаа гэж бодъё. Дараа нь би дараах үл хамаарах зүйлийг харах болно - тохиргоо идэвхжсэн огноогоор хүчний индекс. Хэрэв би огнооны хязгаарыг заагаагүй бол асуулга бөглөх боломжгүй. Үүнийг гараар зааж өгөхийн тулд шинжээчдэд найдах шаардлагагүй. Ердийн тохиолдол бол огнооны мужийг долоо хоногийн хооронд үйл явдлын огноог бичих явдал юм. Тэгээд тэд зүгээр л буруу газар хаалт зааж өгсөн ба оронд нь эсвэл - эсвэл URL таарч байна. Хэрэв ямар ч хязгаарлалт байхгүй бол энэ нь URL баганыг мөлхөж, зүгээр л нэг тонн нөөцийг үрэх болно.
Нэмж дурдахад ClickHouse нь хоёр тэргүүлэх тохиргоотой. Харамсалтай нь тэд маш анхдагч юм. Нэгийг нь энгийнээр нэрлэдэг тэргүүлэх ач холбогдол. Хэрэв тэргүүлэх ач холбогдол ≠ 0, зарим давуу талтай хүсэлтүүд биелэгдэж байгаа боловч илүү чухал ач холбогдолтой гэсэн үгээс бага давуу эрхтэй хүсэлтийг гүйцэтгэж байгаа бол тэргүүлэх ач холбогдол багатай хүсэлтийг гүйцэтгэнэ. , зүгээр л түр зогссон бөгөөд энэ хугацаанд огт ажиллахгүй.
Энэ нь маш бүдүүлэг тохиргоо бөгөөд кластер тогтмол ачаалалтай тохиолдолд тохиромжгүй. Гэхдээ хэрэв танд чухал ач холбогдолтой богино, тэсрэлттэй хүсэлтүүд байгаа бөгөөд кластер нь ихэвчлэн идэвхгүй байгаа бол энэ тохиргоо тохиромжтой.
Дараагийн тэргүүлэх тохиргоог дуудна OS урсгалын тэргүүлэх чиглэл. Энэ нь зүгээр л Линукс төлөвлөгчийн хүсэлтийг гүйцэтгэх бүх хэлхээний сайхан утгыг тохируулдаг. Энэ нь тийм ч сайн ажилладаг, гэхдээ энэ нь хэвээр байна. Хэрэв та хамгийн бага сайхан утгыг тохируулсан бол энэ нь хамгийн том утга учир хамгийн бага тэргүүлэх ач холбогдолтой бөгөөд өндөр ач холбогдолтой хүсэлтүүдэд -19-ийг тохируулсан бол CPU нь тэргүүлэх ач холбогдол бүхий хүсэлтүүдээс дөрөв дахин бага ач холбогдолтой хүсэлтийг ашиглах болно.
Та мөн хүсэлтийг гүйцэтгэх хамгийн дээд хугацааг тохируулах хэрэгтэй - жишээ нь таван минут. Асуулга гүйцэтгэх хамгийн бага хурд нь хамгийн гайхалтай зүйл юм. Энэ тохиргоо нь удаан хугацааны туршид байсаар ирсэн бөгөөд ClickHouse-ийг удаашруулдаггүй гэдгийг батлахаас гадна үүнийг хүчээр хийх шаардлагатай байна.
Та тохируулсан гэж төсөөлөөд үз дээ: хэрвээ зарим асуулга нь секундэд нэг сая хүрэхгүй мөр боловсруулдаг бол та үүнийг хийж чадахгүй. Энэ нь бидний сайн нэр, сайн мэдээллийн санг гутааж байна. Үүнийг л хориглочихъё. Үнэндээ хоёр тохиргоо байдаг. Нэг гэж нэрлэдэг хамгийн бага гүйцэтгэлийн хурд - секундэд шугамаар, хоёр дахь нь хамгийн бага гүйцэтгэлийн хурдыг шалгахаас өмнө завсарлага гэж нэрлэдэг - анхдагчаар арван таван секунд. Өөрөөр хэлбэл, арван таван секунд боломжтой бөгөөд хэрэв энэ нь удаан байвал үл хамаарах зүйлээ хаяж, хүсэлтийг цуцална уу.
Та мөн квот тогтоох хэрэгтэй. ClickHouse нь нөөцийн хэрэглээг тооцдог суурилагдсан квот функцтэй. Гэвч харамсалтай нь CPU, диск гэх мэт техник хангамжийн нөөц биш, харин логик нөөц бол боловсруулсан хүсэлт, уншсан мөр, байтуудын тоо юм. Жишээлбэл, та таван минутын дотор хамгийн ихдээ нэг зуун хүсэлт, цагт нэг мянган хүсэлтийг тохируулах боломжтой.
Яагаад чухал вэ? Учир нь зарим аналитик асуулга нь ClickHouse клиентээс шууд гараар хийгдэх болно. Тэгээд бүх зүйл сайхан болно. Харин танай компанид ахисан түвшний шинжээчид байгаа бол тэд скрипт бичих бөгөөд скриптэд алдаа гарч болзошгүй. Мөн энэ алдаа нь хүсэлтийг хязгааргүй давталтаар гүйцэтгэхэд хүргэнэ. Үүнээс бид өөрсдийгөө хамгаалах ёстой.
Нэг асуулгын үр дүнг арван үйлчлүүлэгчид өгөх боломжтой юу?
Бидэнд маш том хүсэлтээр нэг дор орох дуртай хэд хэдэн хэрэглэгчид байдаг. Хүсэлт нь том хэмжээтэй бөгөөд зарчмын хувьд хурдан гүйцэтгэгддэг боловч ийм хүсэлт нэгэн зэрэг олон байдаг тул энэ нь маш их өвддөг. Арван удаа дараалан ирсэн хүсэлтийг нэг удаа биелүүлж, арван үйлчлүүлэгчид үр дүнг нь өгч болдог юм уу?
Асуудал нь бидэнд завсрын өгөгдлийн кэш эсвэл кэшийн үр дүн байхгүй байна. Үйлдлийн системийн хуудасны кэш байдаг бөгөөд энэ нь таныг дискнээс өгөгдлийг дахин уншихаас сэргийлдэг боловч харамсалтай нь өгөгдлийг задлах, цувралаас гаргах, дахин боловсруулах болно.
Завсрын өгөгдлийг кэшлэх, эсвэл ижил төстэй асуултуудыг ямар нэгэн дараалалд оруулах, үр дүнгийн кэш нэмэх замаар би үүнээс зайлсхийхийг хүсч байна. Одоогоор бидэнд хүсэлтийн кэш нэмсэн нэг татах хүсэлт байна, гэхдээ зөвхөн in болон нэгдэх хэсэг дэх дэд асуулгад зориулагдсан, өөрөөр хэлбэл шийдэл нь бүрэн бус байна.
Гэсэн хэдий ч бид ийм нөхцөл байдалтай тулгардаг. Ялангуяа каноник жишээ бол хуудасчилсан асуулга юм. Тайлан байгаа, энэ нь хэд хэдэн хуудастай, 10-ыг хязгаарлах хүсэлт байна. Дараа нь ижил зүйл, гэхдээ 10,10-ыг хязгаарлах. Дараа нь дараагийн хуудас. Асуулт нь яагаад бид энэ бүгдийг тоолж байгаа юм бэ? Гэвч одоо ямар ч шийдэлгүй, үүнээс зайлсхийх арга ч алга.
ClickHouse-ийн хажууд хажуугийн тэрэг болгон байрлуулсан өөр шийдэл бий. .
Кирилл Шваков: ClickHouse Proxy нь хурдны хязгаарлагч болон үр дүнгийн санах ойтой. Үүнтэй төстэй асуудал шийдэгдэж байсан тул тэнд маш олон тохиргоо хийсэн. Прокси нь хүсэлтийг дараалалд оруулах замаар хязгаарлах, хүсэлтийн кэш хэр удаан ажиллахыг тохируулах боломжийг олгодог. Хэрэв хүсэлтүүд үнэхээр адилхан байсан бол Прокси тэднийг олон удаа илгээх боловч ClickHouse руу зөвхөн нэг удаа очно.
Nginx нь үнэгүй хувилбарт кэштэй бөгөөд энэ нь бас ажиллах болно. Nginx-д хүсэлт нэгэн зэрэг ирвэл нэгийг нь дуустал бусдыг удаашруулдаг тохиргоо байдаг. Гэхдээ ClickHouse Proxy дээр тохиргоо нь илүү сайн хийгдсэн байдаг. Энэ нь ClickHouse-д тусгайлан зориулж, эдгээр хүсэлтүүдэд зориулагдсан тул илүү тохиромжтой. За, суулгахад хялбар.
Асинхрон үйлдлүүд болон материаллаг үзэл бодлыг яах вэ?
Дахин тоглуулах хөдөлгүүртэй үйлдлүүд асинхрон байдаг гэсэн асуудал гардаг - эхлээд өгөгдөл бичигдсэн, дараа нь нурдаг. Хэрэв зарим дүүргэгч бүхий материалжуулсан таблет нь тэмдгийн дор амьдардаг бол түүнд давхардсан тоонууд бичигдэх болно. Хэрэв нарийн төвөгтэй логик байхгүй бол өгөгдөл давхардах болно. Та энэ талаар юу хийж чадах вэ?
Тодорхой шийдэл байдаг - асинхрон уналтын үйл ажиллагааны үед тодорхой ангиллын matviews дээр гохыг хэрэгжүүлэх. Мөнгөн сум эсвэл ижил төстэй функцийг хэрэгжүүлэх төлөвлөгөө байгаа юу?
Хувилбар хэрхэн ажилладагийг ойлгох нь зүйтэй. Миний одоо танд хэлэх зүйл бол асуултад хамааралгүй, гэхдээ санаж байх хэрэгтэй.
Хуулбарласан хүснэгтэд оруулах үед оруулсан блокуудыг бүхэлд нь хувилдаг. Хэрэв та ижил тооны ижил мөрүүдийг агуулсан ижил блокыг ижил дарааллаар дахин оруулбал өгөгдөл давхардсан болно. Оруулсаны хариуд та "Ok" гэж хүлээн авах боловч үнэн хэрэгтээ нэг багц өгөгдөл бичигдэх бөгөөд энэ нь давхардагдахгүй.
Энэ нь итгэлтэй байхын тулд зайлшгүй шаардлагатай. Хэрэв та оруулах явцад "Ok" гэж хүлээн авбал таны өгөгдлийг оруулсан болно. Хэрэв та ClickHouse-ээс алдаа хүлээн авбал тэдгээрийг оруулаагүй гэсэн үг бөгөөд та оруулгыг давтах шаардлагатай болно. Гэхдээ оруулах явцад холболт тасарсан бол өгөгдөл оруулсан эсэхийг мэдэхгүй. Цорын ганц сонголт бол оруулгыг дахин давтах явдал юм. Хэрэв өгөгдөл үнэхээр оруулсан бөгөөд та үүнийг дахин оруулсан бол блок давхардалтай байна. Энэ нь давхардлаас зайлсхийхэд шаардлагатай.
Мөн бодитой үзэлд хэрхэн ажиллах нь бас чухал юм. Хэрэв өгөгдлийг үндсэн хүснэгтэд оруулахдаа давхардсан бол энэ нь материаллаг харагдах байдалд орохгүй.
Одоо асуултын талаар. Та тусдаа мөрүүдийн хуулбарыг бичиж байгаа тул таны нөхцөл байдал илүү төвөгтэй байна. Өөрөөр хэлбэл, бүх багц нь давхардсан биш, харин тодорхой шугамууд нь арын дэвсгэр дээр унадаг. Үнэн хэрэгтээ өгөгдөл нь үндсэн хүснэгтэд задрах боловч задлаагүй өгөгдөл нь материаллаг харагдах байдал руу шилжих бөгөөд нэгтгэх явцад материаллаг үзэлд юу ч тохиолдохгүй. Учир нь материаллаг харагдах байдал нь оруулах гохоос өөр зүйл биш юм. Бусад үйл ажиллагааны явцад түүнд нэмэлт зүйл тохиолддоггүй.
Тэгээд би чамайг энд аз жаргалтай болгож чадахгүй. Энэ тохиолдолд та зөвхөн тодорхой шийдлийг хайх хэрэгтэй. Жишээлбэл, үүнийг материаллаг дүр төрхөөр дахин тоглуулах боломжтой юу, мөн давхардлын арга нь ижил аргаар ажиллах боломжтой. Гэхдээ харамсалтай нь үргэлж биш. Хэрэв энэ нь нэгтгэж байгаа бол энэ нь ажиллахгүй болно.
Кирилл Шваков: Тэр үед бид бас суга таягтай барилгатай байсан. Зар сурталчилгааны сэтгэгдэлтэй холбоотой асуудал гарсан бөгөөд бидний бодит цаг хугацаанд харуулах зарим өгөгдөл байдаг - эдгээр нь зүгээр л сэтгэгдэл юм. Тэдгээрийг хуулбарлах нь ховор, гэхдээ ийм зүйл тохиолдвол бид дараа нь тэдгээрийг нураах болно. Давхардах боломжгүй зүйлүүд байсан - товшилтууд болон энэ бүх түүх. Гэхдээ би бас тэднийг бараг тэр дор нь харуулахыг хүссэн.
Бодит байдалд хүрсэн үзэл бодол хэрхэн хийгдсэн бэ? Үүнийг шууд бичсэн үзэл бодол байсан - үүнийг түүхий өгөгдөлд бичсэн, үзэл бодолд бичсэн. Тэнд зарим үед өгөгдөл нь тийм ч зөв биш, давхардсан гэх мэт. Хүснэгтийн хоёр дахь хэсэг байдаг бөгөөд тэдгээр нь материаллаг үзэл бодолтой яг адилхан харагддаг, өөрөөр хэлбэл тэдгээр нь бүтцийн хувьд туйлын ижил байдаг. Хааяа бид өгөгдлийг дахин тооцоолж, өгөгдлийг давхардалгүйгээр тоолж, тэдгээр хүснэгтэд бичдэг.
Бид API-ээр дамжсан - энэ нь ClickHouse дээр гараар ажиллахгүй. Мөн API харагдана: Би хүснэгтэд хамгийн сүүлд нэмсэн огноотой байх үед зөв өгөгдлийг аль хэдийн тооцоолсон байх баталгаатай бөгөөд энэ нь нэг хүснэгт болон өөр хүснэгтэд хүсэлт гаргадаг. Хүсэлт нь нэгээс нь тодорхой цагийг сонгох ба нөгөөгөөс нь хараахан тооцоогүй байгаа зүйлийг авдаг. Мөн энэ нь ажилладаг, гэхдээ зөвхөн ClickHouse-ээр биш.
Хэрэв танд ямар нэгэн API байгаа бол - шинжээчид, хэрэглэгчдийн хувьд - зарчмын хувьд энэ нь сонголт юм. Та үргэлж тоолж байдаг, үргэлж тоолж байдаг. Үүнийг өдөрт нэг удаа эсвэл өөр цагт хийж болно. Та өөрт хэрэгцээгүй, чухал биш хүрээг өөрөө сонгоорой.
ClickHouse нь маш олон бүртгэлтэй. Би серверт тохиолдож буй бүх зүйлийг хэрхэн шууд харах вэ?
ClickHouse нь маш олон тооны янз бүрийн логуудтай бөгөөд энэ тоо нэмэгдэж байна. Шинэ хувилбаруудад тэдгээрийн зарим нь анхдагчаар идэвхжсэн байдаг; хуучин хувилбаруудад тэдгээрийг шинэчлэх үед идэвхжүүлсэн байх ёстой. Гэсэн хэдий ч тэдний тоо улам бүр нэмэгдсээр байна. Эцэст нь би серверт юу болж байгааг харахыг хүсч байна, магадгүй ямар нэгэн хураангуй хяналтын самбар дээр.
Таны ClickHouse баг эсвэл найз нөхдийнхөө багт эдгээр бүртгэлийг бэлэн бүтээгдэхүүн болгон харуулах бэлэн хяналтын самбарын зарим функцийг дэмждэг хүмүүс байна уу? Эцэст нь ClickHouse дээрх бүртгэлүүдийг үзэх нь маш сайн хэрэг. Гэхдээ аль хэдийн хяналтын самбар хэлбэрээр бэлтгэсэн бол маш сайхан байх болно. Би үүнээс нь өшиглөх байсан.
Стандартчлагдаагүй ч хяналтын самбарууд байдаг. Манай компанид 60 орчим баг ClickHouse ашигладаг бөгөөд хамгийн хачирхалтай нь тэдний олонх нь өөрсдөдөө зориулж хийсэн хяналтын самбартай бөгөөд арай өөр юм. Зарим багууд Yandex.Cloud дотоод суулгацыг ашигладаг. Бүх шаардлагатай биш ч гэсэн бэлэн тайлангууд байдаг. Бусад нь өөрийн гэсэн байдаг.
Метрика дахь миний хамтран ажиллагсад Графана дахь өөрийн хяналтын самбартай, харин би тэдний кластерт зориулсан өөрийн гэсэн самбартай. Би serif cache-д зориулсан cache hit гэх мэт зүйлсийг харж байна. Үүнээс ч илүү хэцүү зүйл бол бид өөр өөр хэрэгсэл ашигладаг. Би Graphite-web хэмээх маш эртний хэрэглүүрийг ашиглан хяналтын самбараа бүтээсэн. Тэр үнэхээр царай муутай. Графана нь илүү тохиромжтой, үзэсгэлэнтэй байх байсан ч би үүнийг ийм байдлаар ашигладаг хэвээр байна.
Хяналтын самбар дээрх үндсэн зүйл нь адилхан. Эдгээр нь кластерын системийн хэмжүүрүүд юм: CPU, санах ой, диск, сүлжээ. Бусад нь - нэгэн зэрэг хүсэлтийн тоо, нэгэн зэрэг нэгтгэх тоо, секундэд хийх хүсэлтийн тоо, MergeTree хүснэгтийн хуваалтуудын хамгийн их тоо, хуулбарлах хоцрогдол, хуулбарлах дарааллын хэмжээ, секундэд оруулсан мөрийн тоо, секундэд оруулсан блокуудын тоо. Энэ бол бүртгэлээс бус хэмжүүрээс олж авсан бүх зүйл юм.
Владимир Колобаев: Алексей, би үүнийг бага зэрэг засмаар байна. Графана байна. Grafana нь ClickHouse гэсэн мэдээллийн эх сурвалжтай. Өөрөөр хэлбэл, би Grafana-аас ClickHouse руу шууд хүсэлт гаргах боломжтой. ClickHouse нь лог бүхий хүснэгттэй бөгөөд энэ нь хүн бүрт адилхан байдаг. Үүний үр дүнд би Графана дахь энэ бүртгэлийн хүснэгтэд нэвтэрч, серверийнхээ хүсэлтийг харахыг хүсч байна. Ийм хяналтын самбартай бол үнэхээр сайхан байх болно.
Би өөрөө дугуй унасан. Гэхдээ надад асуулт байна - хэрвээ энэ бүхэн стандартчилагдсан бөгөөд Графана-г хүн бүр ашигладаг бол Yandex яагаад ийм албан ёсны хяналтын самбаргүй байна вэ?
Кирилл Шваков: Үнэн хэрэгтээ ClickHouse руу ордог мэдээллийн эх сурвалж нь одоо Altinity-г дэмждэг. Тэгээд хаана ухах, хэнийг түлхэх вэ гэдэг вектор л өгмөөр байна. Та тэднээс асууж болно, учир нь Yandex үүнийг тойрсон түүх биш харин ClickHouse-ийг хийсээр байна. Altinity бол ClickHouse-ийг сурталчилж буй гол компани юм. Тэд түүнийг орхихгүй, харин түүнийг дэмжих болно. Учир нь зарчмын хувьд хяналтын самбарыг Grafana вэбсайтад байршуулахын тулд та зүгээр л бүртгүүлж, байршуулах хэрэгтэй - ямар ч онцгой асуудал байхгүй.
Алексей Миловидов: Өнгөрсөн нэг жилийн хугацаанд ClickHouse нь асуулгын профайл үүсгэх олон боломжуудыг нэмсэн. Нөөцийн ашиглалтын талаархи хүсэлт бүрийн хэмжүүрүүд байдаг. Саяхан бид миллисекунд тутамд асуулга хаана зарцуулж байгааг харахын тулд бүр ч доод түвшний асуулгын профайлыг нэмсэн. Гэхдээ энэ функцийг ашиглахын тулд би консолын клиентийг нээж, үргэлж мартдаг хүсэлтийг бичих ёстой. Би үүнийг хаа нэгтээ хадгалсан бөгөөд яг хаана байгааг мартсаар байна.
Би зүгээр л хэлсэн хэрэгсэл байгаа болоосой, энд таны хүнд асуултууд, асуулгын ангиллаар бүлэглэгдсэн байна. Би нэгийг нь дарахад тэд надад энэ нь хүнд байна гэж хэлэх болно. Одоо тийм шийдэл байхгүй. Хүмүүс надаас: "Надад хэлээч, Grafana-д зориулсан бэлэн хяналтын самбар байна уу?" гэж асуухад би: "Графана вэб сайт руу ор, тэнд "Хяналтын самбар" нийгэмлэг байдаг, тэнд хяналтын самбар байгаа нь үнэхээр хачирхалтай. Димкагаас Костянаас хяналтын самбар байдаг. Энэ нь юу болохыг би мэдэхгүй, би өөрөө үүнийг ашиглаагүй."
Серверийг OOM-д гацахгүйн тулд нэгтгэхэд хэрхэн нөлөөлөх вэ?
Надад хүснэгт байна, хүснэгтэд зөвхөн нэг хуваалт байна, энэ нь ReplacingMergeTree юм. Би түүнд дөрвөн жил мэдээлэл бичиж байна. Би үүнд өөрчлөлт оруулж, зарим өгөгдлийг устгах шаардлагатай болсон.
Би үүнийг хийсэн бөгөөд энэ хүсэлтийг боловсруулах явцад кластерт байгаа бүх серверийн бүх санах ой зарцуулагдаж, кластерийн бүх серверүүд OOM руу орсон. Дараа нь тэд бүгд хамтдаа босч, энэ ижил үйлдлийг, энэ мэдээллийн блокыг нэгтгэж, дахин OOM руу унав. Дараа нь тэд дахин босч, дахин унав. Тэгээд энэ зүйл зогссонгүй.
Дараа нь энэ нь залуусын зассан алдаа байсан нь тогтоогджээ. Энэ маш сайхан байна, маш их баярлалаа. Гэхдээ үлдэгдэл үлдсэн. Одоо би хүснэгтэд ямар нэгэн төрлийн нэгдэл хийх талаар бодох үед надад асуулт гарч ирж байна - яагаад би эдгээр нэгдлүүдэд нөлөөлж чадахгүй байна вэ? Жишээлбэл, тэдгээрийг шаардлагатай RAM-ийн хэмжээгээр эсвэл зарчмын хувьд энэ хүснэгтийг боловсруулах хэмжээгээр хязгаарла.
Надад "Хэмжүүр" гэсэн хүснэгт байна, үүнийг хоёр хэлхээнд боловсруулна уу. Зэрэгцээ арав, таван нэгдэл үүсгэх шаардлагагүй, хоёроор нь хий. Би хоёр санах ой хангалттай гэж бодож байна, гэхдээ арван боловсруулахад хангалтгүй байж магадгүй юм. Яагаад айдас үлддэг вэ? Учир нь хүснэгт өсөн нэмэгдэж байгаа бөгөөд хэзээ нэгэн цагт би зарчмын хувьд алдаанаас болж байхаа больсон нөхцөл байдалтай тулгарах болно, гэхдээ өгөгдөл нь маш их хэмжээгээр өөрчлөгдөх тул миний санах ой хангалтгүй байх болно. сервер. Дараа нь сервер нэгтгэх үед OOM-д гацах болно. Түүнээс гадна би мутацыг цуцалж чадна, гэхдээ Мержи байхгүй болсон.
Нэгдэх үед сервер нь OOM-д орохгүй гэдгийг та мэднэ, учир нь нэгтгэх үед RAM-ийн хэмжээг зөвхөн нэг жижиг хэмжээний өгөгдөлд ашигладаг. Тиймээс өгөгдлийн хэмжээнээс үл хамааран бүх зүйл сайхан болно.
Владимир Колобаев: Сайн байна. Алдаа зассаны дараа би өөртөө зориулж шинэ хувилбарыг татаж аваад, олон хуваалттай жижиг ширээн дээр би ижил төстэй үйлдлийг хийсэн. Мөн нэгтгэх явцад сервер дээр 100 ГБ RAM шатсан байна. Надад 150 хүн сууж, 100 нь идсэн, 50 ГБ цонх үлдсэн тул би OOM-д унасангүй.
Хэрэв үнэхээр 100 ГБ RAM ашигладаг бол OOM-д унахаас намайг юу хамгаалах вэ? Хэрэв нэгтгэсэн RAM гэнэт дуусвал яах вэ?
Алексей Миловидов: Тусгайлан нэгтгэхэд зориулагдсан RAM-ийн хэрэглээ хязгаарлагдахгүй ийм асуудал байна. Хоёрдахь асуудал бол хэрэв ямар нэгэн төрлийн нэгтгэх өгөгдсөн бол хуулбарлах бүртгэлд бүртгэгдсэн тул үүнийг гүйцэтгэх ёстой. Хуулбарлах бүртгэл нь хуулбарыг тогтвортой байдалд оруулахад шаардлагатай үйлдлүүд юм. Хэрэв та энэ хуулбарын бүртгэлийг буцаах гарын авлагын залруулга хийхгүй бол нэгтгэх үйлдлийг ямар нэг байдлаар хийх шаардлагатай болно.
Мэдээжийн хэрэг, OOM-ээс хамгаалдаг RAM-ийн хязгаарлалттай байх нь илүүц байх болно. Энэ нь нэгтгэлийг дуусгахад тус болохгүй, энэ нь дахин эхэлж, ямар нэг босгонд хүрч, үл хамаарах зүйл хаяж, дараа нь дахин эхлэх болно - үүнээс сайн зүйл гарахгүй. Гэхдээ зарчмын хувьд энэ хязгаарлалтыг нэвтрүүлэх нь ашигтай байх болно.
ClickHouse-д зориулсан Golang драйверийг хэрхэн хөгжүүлэх вэ?
Кирилл Шваковын бичсэн Голанг жолоочийг ClickHouse баг албан ёсоор дэмжиж байна. Тэр , тэр одоо том бөгөөд жинхэнэ болсон.
Жижиг тэмдэглэл. Хязгааргүй дэг журмын хэвийн хэлбэрүүдийн гайхалтай, хайртай агуулах байдаг - энэ бол Vertica юм. Тэд мөн өөрсдийн албан ёсны питон драйвертай бөгөөд үүнийг Vertica хөгжүүлэгчид дэмждэг. Хэд хэдэн удаа хадгалах хувилбарууд болон драйверуудын хувилбарууд эрс ялгаатай байсан бөгөөд драйвер нь хэзээ нэгэн цагт ажиллахаа больсон. Мөн хоёр дахь цэг. Энэхүү албан ёсны жолоочийн дэмжлэгийг "хөх" систем гүйцэтгэдэг гэж би бодож байна - та тэдэнд асуудал бичдэг бөгөөд энэ нь үүрд зогсдог.
Надад хоёр асуулт байна. Одоо Кириллийн Голанг драйвер нь Голангаас ClickHouse-тай холбогдох бараг анхдагч арга юм. Хэрэв хэн нэгэн нь http интерфэйсээр дамжуулан харилцаж байгаа бол тэр нь түүнд таалагдаж байна. Энэ жолоочийн хөгжил хэрхэн үргэлжлэх вэ? Энэ нь репозитор дахь ямар нэгэн эвдэрсэн өөрчлөлттэй синхрончлогдох уу? Мөн аливаа асуудлыг хэлэлцэх ямар журамтай вэ?
Кирилл Шваков: Эхнийх нь бүх зүйл хэрхэн хүнд сурталтай зохион байгуулагдаж байна. Энэ асуудлыг хэлэлцээгүй тул надад хариулах зүйл алга.
Асуудлын талаархи асуултанд хариулахын тулд жолоочийн бага зэрэг түүх хэрэгтэй. Би маш их мэдээлэлтэй компанид ажиллаж байсан. Энэ бол хаа нэгтээ хадгалах шаардлагатай асар олон тооны үйл явдлууд бүхий зар сурталчилгааны ээрэх хэрэгсэл байв. Тэгээд нэг удаа ClickHouse гарч ирэв. Бид үүнийг мэдээллээр дүүргэсэн бөгөөд эхлээд бүх зүйл хэвийн байсан ч дараа нь ClickHouse эвдэрсэн. Тэр үед бид үүнийг хэрэггүй гэж шийдсэн.
Жилийн дараа бид ClickHouse-ийг ашиглах санаа руу буцаж ирсэн бөгөөд бид тэнд ямар нэгэн байдлаар өгөгдөл бичих шаардлагатай болсон. Танилцуулга нь ийм байв: техник хангамж маш сул, нөөц багатай. Гэхдээ бид үргэлж ийм байдлаар ажиллаж ирсэн тул эх протокол руу хандсан.
Бид Go-д ажиллаж байсан болохоор Go жолооч хэрэгтэй гэдэг нь ойлгомжтой байсан. Би үүнийг бараг бүтэн цагаар хийсэн - энэ бол миний ажлын даалгавар байсан. Бид үүнийг тодорхой цэгт хүргэсэн бөгөөд зарчмын хувьд биднээс өөр хэн ч үүнийг ашиглах болно гэж таамаглаагүй. Дараа нь CloudFlare яг ижил асуудалтай тулгарсан бөгөөд бид тэдэнтэй ижил даалгавартай байсан тул хэсэг хугацаанд тэдэнтэй маш жигд ажилласан. Түүнээс гадна бид үүнийг ClickHouse-д өөрсдөө болон драйвер дээр хоёуланг нь хийсэн.
Хэзээ нэгэн цагт би үүнийг хийхээ больсон, учир нь миний ClickHouse болон ажлын талаархи үйл ажиллагаа бага зэрэг өөрчлөгдсөн. Тиймээс асуудал хаагдахгүй байна. Үе үе ямар нэгэн зүйл хэрэгтэй хүмүүс өөрсдөө репозитор руу ханддаг. Дараа нь би татах хүсэлтийг хараад заримдаа өөрөө ямар нэг зүйлийг засдаг ч энэ нь ховор тохиолддог.
Би жолооч руугаа буцахыг хүсч байна. Хэдэн жилийн өмнө энэ бүх зүйл эхлэхэд ClickHouse бас өөр, өөр өөр чадвартай байсан. Одоо бид драйверийг хэрхэн яаж өөрчлөх талаар ойлголттой болсон бөгөөд ингэснээр сайн ажиллах болно. Хэрэв ийм зүйл тохиолдвол 2-р хувилбар нь хуримтлагдсан таягны улмаас ямар ч тохиолдолд нийцэхгүй болно.
Энэ асуудлыг яаж зохион байгуулахаа мэдэхгүй байна. Би хувьдаа цаг зав багатай. Зарим хүмүүс жолоочоо дуусгачихвал би тэдэнд тусалж, юу хийхийг нь хэлж чадна. Гэхдээ төслийг боловсруулахад Yandex-ийн идэвхтэй оролцоо хараахан хэлэлцэгдээгүй байна.
Алексей Миловидов: Уг нь эдгээр жолооч нарын хүнд суртал одоохондоо алга. Цорын ганц зүйл бол тэдгээрийг албан ёсны байгууллагад хүргүүлсэн, өөрөөр хэлбэл энэ драйвер нь Go-ийн албан ёсны анхдагч шийдэл гэж хүлээн зөвшөөрөгдсөн явдал юм. Өөр жолооч нар байгаа ч тусдаа ирдэг.
Бидэнд эдгээр жолооч нарт зориулсан дотоод хөгжүүлэлт байхгүй. Энэ жолоочид биш, бүх нийтийн жолоочийг хөгжүүлэх зорилгоор хувь хүн авч чадах уу, эсвэл гаднаас хүн олж чадах уу гэдэг асуулт байна.
lazy_load тохиргоог идэвхжүүлсэн үед дахин ачаалсны дараа гадаад толь бичиг ачаалагдахгүй. Юу хийх вэ?
Бид lazy_load тохиргоог идэвхжүүлсэн бөгөөд серверийг дахин ачаалсны дараа толь бичиг өөрөө ачаалагдахгүй. Энэ нь хэрэглэгч толь бичигт хандсаны дараа л босдог. Тэгээд анх удаагаа хандахад алдаа гарлаа. ClickHouse ашиглан толь бичгүүдийг ямар нэгэн байдлаар автоматаар ачаалах боломжтой юу эсвэл хэрэглэгчдэд алдаа гаргахгүйн тулд тэдний бэлэн байдлыг өөрөө хянах шаардлагатай юу?
Магадгүй бидэнд ClickHouse-ийн хуучин хувилбар байгаа тул толь бичиг автоматаар ачаалагдаагүй. Ийм байж болох уу?
Нэгдүгээрт, толь бичгүүдийг асуулга ашиглан хүчээр ачаалж болно системийн толь бичгүүдийг дахин ачаалах. Хоёрдугаарт, алдааны тухайд - хэрэв толь бичиг аль хэдийн ачаалагдсан бол асуулга нь ачаалагдсан өгөгдөл дээр үндэслэн ажиллах болно. Хэрэв толь бичиг ачаалагдаагүй бол хүсэлтийн үеэр шууд ачаалагдах болно.
Энэ нь хүнд толь бичгүүдэд тийм ч тохиромжтой биш юм. Жишээлбэл, та MySQL-ээс нэг сая мөр татах хэрэгтэй. Хэн нэгэн энгийн сонголт хийх боловч энэ сонголт ижил сая мөр хүлээх болно. Энд хоёр шийдэл байна. Эхнийх нь lazy_load-ыг унтраа. Хоёрдугаарт, сервер ажиллах үед ачаалал өгөхөөс өмнө хийх хэрэгтэй системийг дахин ачаалах толь бичиг эсвэл зүгээр л толь бичиг ашигладаг асуулга хий. Дараа нь толь бичиг ачаалагдах болно. ClickHouse автоматаар ачаалахгүй тул та lazy_load тохиргоог идэвхжүүлсэн толь бичгүүдийн бэлэн байдлыг хянах хэрэгтэй.
Сүүлийн асуултын хариулт нь хувилбар нь хуучирсан эсвэл дибаг хийх шаардлагатай байна.
Системийн дахин ачаалах толь бичгүүдээс ядаж нэг нь алдаа гарвал олон толь бичгүүдийн алийг нь ч ачаалахгүй байвал яах вэ?
Системийг дахин ачаалах толь бичгүүдийн талаар өөр нэг асуулт байна. Бидэнд хоёр толь бичиг байгаа - нэг нь ачаалагдаагүй, хоёр дахь нь ачаалагдсан. Энэ тохиолдолд Системийн дахин ачаалах толь бичиг нь ямар ч толь бичгийг ачаалахгүй бөгөөд та системийн дахин ачаалах толь бичгийг ашиглан тодорхой нэгийг нэрээр нь цэгээр нь ачаалах хэрэгтэй. Энэ нь бас ClickHouse хувилбартай холбоотой юу?
Би чамайг баярлуулахыг хүсч байна. Энэ зан байдал өөрчлөгдөж байв. Энэ нь хэрэв та ClickHouse-г шинэчлэх юм бол энэ нь бас өөрчлөгдөнө гэсэн үг юм. Хэрэв та одоогийн зан чанартаа сэтгэл хангалуун бус байвал системийн толь бичгүүдийг дахин ачаалах, шинэчлээрэй, энэ нь илүү сайн болж өөрчлөгдөнө гэж найдаж байна.
ClickHouse тохиргоонд дэлгэрэнгүй мэдээллийг тохируулах арга бий, гэхдээ алдаа гарсан тохиолдолд харуулахгүй юу?
Дараагийн асуулт бол толь бичигтэй холбоотой алдаа, тухайлбал дэлгэрэнгүй мэдээлэл юм. Бид толь бичгийн ClickHouse тохиргоонд холболтын дэлгэрэнгүйг зааж өгсөн бөгөөд хэрэв алдаа гарвал бид эдгээр мэдээлэл болон нууц үгийг хариуд нь хүлээн авна.
Бид ODBC драйверын тохиргоонд дэлгэрэнгүй мэдээлэл нэмж энэ алдааг шийдсэн. ClickHouse тохиргоонд дэлгэрэнгүй мэдээллийг тохируулах ямар нэг арга бий, гэхдээ алдаа гарсан тохиолдолд эдгээр мэдээллийг харуулахгүй байна уу?
Энд байгаа бодит шийдэл бол эдгээр итгэмжлэлүүдийг odbc.ini дээр зааж өгөх бөгөөд ClickHouse-д зөвхөн ODBC мэдээллийн эх сурвалжийн нэрийг зааж өгөх явдал юм. Энэ нь бусад толь бичгийн эх сурвалжуудад тохиолдохгүй - MySQL-тэй толь бичиг ч, бусад толь бичигт ч алдааны мэдэгдэл хүлээн авахдаа нууц үгээ харах ёсгүй. ODBC-ийн хувьд би бас харах болно - хэрэв байгаа бол та үүнийг арилгах хэрэгтэй.
Бонус: цугларалтаас Zoom-д зориулсан дэвсгэр зураг
Зурган дээр дарснаар хамгийн тууштай уншигчдад цугларалтуудын урамшууллын дэвсгэр нээгдэх болно. Бид Avito технологийн сахиусуудын хамт галыг унтрааж, системийн администраторын өрөө эсвэл хуучин сургуулийн компьютерийн клубын хамт олонтой уулзаж, граффитигийн дэвсгэр дээр гүүрэн дор өдөр бүр уулзалт хийдэг.
Эх сурвалж: www.habr.com