ClickHouse-г бодит хэрэглээнд ашиглах онол, практик. Александр Зайцев (2018)

Одоо бараг хаа сайгүй маш их мэдээлэл байгаа хэдий ч аналитик мэдээллийн сан нь нэлээд чамин хэвээр байна. Тэдгээрийг сайн мэддэггүй бөгөөд үр дүнтэй ашиглах чадвар нь бүр дорддог. Ихэнх нь бусад хувилбарт зориулагдсан MySQL эсвэл PostgreSQL-ийг ашиглан "кактус идсээр", NoSQL-ээс болж зовж шаналж, эсвэл арилжааны шийдлүүдэд илүү их мөнгө төлдөг. ClickHouse нь тоглоомын дүрмийг өөрчилдөг бөгөөд аналитик DBMS-ийн ертөнцөд нэвтрэх босгыг мэдэгдэхүйц бууруулдаг.

BackEnd Conf 2018-ийн тайланг илтгэгчийн зөвшөөрлөөр нийтлэв.

Би хэн бэ, яагаад ClickHouse-ийн тухай яриад байна вэ? Би ClickHouse ашигладаг LifeStreet-ийн хөгжлийн захирал. Мөн би Altinity-ийн үүсгэн байгуулагч. Энэ нь Yandex-ийн түнш бөгөөд ClickHouse-г сурталчилж, Yandex-д ClickHouse-г илүү амжилттай болгоход тусалдаг. Мөн ClickHouse-ийн талаарх мэдлэгээ хуваалцахад бэлэн байна.

Би Петя Зайцевын ах биш. Энэ талаар надаас байнга асуудаг. Үгүй ээ, бид ах дүү биш.

ClickHouse-ийг "бүгд мэддэг":

• Маш хурдан,
• Үнэхээр тухтай
• Yandex-д ашигладаг.

Аль компанид, хэрхэн ашигладаг талаар бага зэрэг мэддэг.

Yandex-ээс бусад тохиолдолд ClickHouse-ийг яагаад, хаана, хэрхэн ашигладаг талаар би танд хэлэх болно.

Би өөр өөр компаниудад ClickHouse-ийн тусламжтайгаар тодорхой ажлуудыг хэрхэн шийддэг, ямар ClickHouse хэрэгслийг өөрийн даалгаварт ашиглаж болох, өөр өөр компаниудад хэрхэн ашиглаж байсныг танд хэлэх болно.

Би ClickHouse-ийг өөр өөр өнцгөөс харуулсан гурван жишээг авсан. Сонирхолтой байх болно гэж бодож байна.

Эхний асуулт бол: "Бидэнд яагаад ClickHouse хэрэгтэй байна вэ?". Энэ нь нэлээд ойлгомжтой асуулт юм шиг санагдаж байгаа ч үүнд нэгээс олон хариулт бий.

• Эхний хариулт нь гүйцэтгэлийн тухай юм. ClickHouse нь маш хурдан юм. ClickHouse дээрх аналитик нь маш хурдан байдаг. Үүнийг ихэвчлэн өөр ямар нэг зүйл маш удаан эсвэл маш муу байгаа тохиолдолд ашиглаж болно.
• Хоёрдахь хариулт бол зардал юм. Мөн юуны түрүүнд масштабын зардал. Жишээлбэл, Vertica бол үнэхээр гайхалтай мэдээллийн сан юм. Хэрэв танд маш их терабайт өгөгдөл байхгүй бол энэ нь маш сайн ажилладаг. Гэхдээ хэдэн зуун терабайт эсвэл петабайтын тухай ярих юм бол лиценз, дэмжлэгийн зардал нэлээд их хэмжээгээр ордог. Бас үнэтэй. ClickHouse нь үнэ төлбөргүй байдаг.
• Гурав дахь хариулт нь үйл ажиллагааны зардал юм. Энэ бол арай өөр арга юм. RedShift бол гайхалтай аналог юм. RedShift дээр та маш хурдан шийдвэр гаргах боломжтой. Энэ нь сайн ажиллах болно, гэхдээ тэр үед, цаг бүр, өдөр бүр, сар бүр та Amazon-д маш их мөнгө төлөх болно, учир нь энэ нь нэлээд үнэтэй үйлчилгээ юм. Google BigQuery бас. Хэрэв хэн нэгэн үүнийг ашигласан бол та тэндээс хэд хэдэн хүсэлт гаргаж, гэнэт хэдэн зуун долларын төлбөр авах боломжтой гэдгийг мэддэг.

ClickHouse-д эдгээр асуудал байхгүй.

ClickHouse одоо хаана ашиглагдаж байна вэ? Yandex-ээс гадна ClickHouse-ийг янз бүрийн бизнес, компаниудад ашигладаг.

• Юуны өмнө энэ бол вэб програмын аналитик, өөрөөр хэлбэл Yandex-ээс ирсэн хэрэглээний тохиолдол юм.
• Олон AdTech компаниуд ClickHouse ашигладаг.
• Янз бүрийн эх сурвалжаас гүйлгээний бүртгэлд дүн шинжилгээ хийх шаардлагатай олон тооны компаниуд.
• Аюулгүй байдлын бүртгэлийг хянахын тулд хэд хэдэн компаниуд ClickHouse ашигладаг. Тэд ClickHouse-д байршуулж, тайлан гаргаж, шаардлагатай үр дүнг авдаг.
• Компаниуд үүнийг санхүүгийн шинжилгээнд ашиглаж эхэлж байна, өөрөөр хэлбэл аажмаар томоохон бизнесүүд ClickHouse руу ойртож байна.
• үүлний туяа. Хэрэв хэн нэгэн ClickHouse-г дагавал энэ компанийн нэрийг сонссон байх. Энэ бол нийгэмлэгийн чухал хувь нэмэр оруулагчдын нэг юм. Мөн тэд маш ноцтой ClickHouse суулгацтай. Жишээлбэл, тэд ClickHouse-д зориулж Кафка хөдөлгүүрийг хийсэн.
• Харилцаа холбооны компаниуд ашиглаж эхэлсэн. Хэд хэдэн компаниуд ClickHouse-ийг үзэл баримтлалын нотолгоо болгон ашигладаг эсвэл аль хэдийн үйлдвэрлэсэн.
• Нэг компани үйлдвэрлэлийн үйл явцыг хянахын тулд ClickHouse ашигладаг. Тэд микро схемийг туршиж, олон тооны параметрүүдийг бичдэг, 2 орчим шинж чанар байдаг. Тэгээд тоглоом сайн уу, муу юу гэдгийг шинжилдэг.
• Блокчейн аналитик. Bloxy.info гэх орос компани бий. Энэ бол ethereum сүлжээний дүн шинжилгээ юм. Тэд бас ClickHouse дээр үүнийг хийсэн.

Мөн хэмжээ нь хамаагүй. Нэг жижиг сервер ашигладаг олон компани байдаг. Мөн тэрээр тэдэнд асуудлаа шийдвэрлэх боломжийг олгодог. Үүнээс ч илүү олон компаниуд олон сервер эсвэл олон арван серверийн том кластеруудыг ашигладаг.

Хэрэв та бичлэгийг харвал:

• Yandex: 500+ сервер, тэнд өдөрт 25 тэрбум бичлэг хадгалдаг.
• LifeStreet: 60 сервер, өдөрт ойролцоогоор 75 тэрбум бичлэг. Yandex-ээс цөөн сервер, илүү олон бичлэг байдаг.
• CloudFlare: 36 сервер, тэд өдөрт 200 тэрбум бичлэг хадгалдаг. Тэд бүр цөөхөн сервертэй бөгөөд илүү их мэдээлэл хадгалдаг.
• Bloomberg: 102 сервер, өдөрт нэг их наяд орчим мэдээлэл. рекорд эзэмшигч.

Газарзүйн хувьд энэ нь бас их юм. Энэхүү газрын зураг нь ClickHouse-г дэлхийн хаана ашиглаж байгааг харуулсан дулааны зургийг харуулж байна. Энд Орос, Хятад, Америк тод ялгардаг. Европын орнууд цөөхөн байдаг. Мөн 4 кластер байдаг.

Энэ бол харьцуулсан дүн шинжилгээ, үнэмлэхүй тоо хайх шаардлагагүй. Энэ бол Altinity вэбсайтаас англи хэл дээрх материалыг уншсан зочдын дүн шинжилгээ юм, учир нь тэнд орос хэлээр ярьдаг хүмүүс байдаггүй. Орос, Украин, Беларусь, өөрөөр хэлбэл нийгэмлэгийн орос хэлээр ярьдаг хэсэг нь эдгээр нь хамгийн олон хэрэглэгчид юм. Дараа нь АНУ, Канад орно. Хятад улс маш их гүйцэж байна. Зургаан сарын өмнө тэнд Хятад бараг байхгүй байсан бол одоо Хятад Европыг хэдийнэ гүйцэж түрүүлж, өссөөр байна. Хуучин Европ ч бас хоцрохгүй байгаа бөгөөд ClickHouse-ийн хэрэглээний тэргүүлэгч нь хачирхалтай нь Франц юм.

Би яагаад энэ бүгдийг хэлээд байгаа юм бэ? ClickHouse нь том өгөгдөлд дүн шинжилгээ хийх стандарт шийдэл болж, олон газарт аль хэдийн ашиглагдаж байгааг харуулахын тулд. Хэрэв та үүнийг ашигладаг бол та зөв чиг хандлагад байна. Хэрэв та үүнийг хараахан ашиглаагүй байгаа бол та ганцаараа үлдэх болно гэж айж болохгүй, хэн ч танд туслахгүй, учир нь олон хүн үүнийг аль хэдийн хийж байна.

Эдгээр нь хэд хэдэн компанид ClickHouse-ийг бодитоор ашиглаж байгаа жишээ юм.

• Эхний жишээ бол зар сурталчилгааны сүлжээ юм: Vertica-аас ClickHouse руу шилжих. Би Vertica-аас шилжсэн эсвэл шилжилтийн шатандаа яваа хэдэн компанийг мэднэ.
• Хоёрдахь жишээ бол ClickHouse дээрх гүйлгээний хадгалалт юм. Энэ бол antipatterns дээр суурилсан жишээ юм. Хөгжүүлэгчдийн зөвлөгөөний дагуу ClickHouse-д хийх ёсгүй бүх зүйлийг энд хийдэг. Мөн энэ нь маш үр дүнтэй хийгдсэн тул үр дүнтэй байдаг. Мөн энэ нь ердийн гүйлгээний шийдлээс хамаагүй дээр ажилладаг.
• Гурав дахь жишээ нь ClickHouse дээр тархсан тооцоолол юм. ClickHouse-ийг Hadoop экосистемд хэрхэн нэгтгэх талаар асуулт гарч ирэв. Би компани нь ClickHouse дээрх газрын зураг бууруулах контейнертэй төстэй зүйлийг хэрхэн хийсэн, өгөгдөл локалчлалыг бүртгэх гэх мэт маш чухал бус ажлыг тооцоолох жишээг харуулах болно.

• LifeStreet бол зар сурталчилгааны сүлжээтэй хамт ирдэг бүх технологийг агуулсан Ad Tech компани юм.
• Тэрээр зар сурталчилгааны оновчлол, хөтөлбөрийн тендерт оролцдог.
• Маш их мэдээлэл: өдөрт ойролцоогоор 10 тэрбум үйл явдал. Үүний зэрэгцээ тэнд байгаа үйл явдлуудыг хэд хэдэн дэд үйл явдлуудад хувааж болно.
• Энэ өгөгдлийн олон үйлчлүүлэгчид байдаг бөгөөд эдгээр нь зөвхөн хүмүүс биш, илүү олон байдаг - эдгээр нь программын тендерт оролцдог янз бүрийн алгоритмууд юм.

Тус компани урт бөгөөд хүнд хэцүү замыг туулсан. Тэгээд би энэ тухай HighLoad дээр ярьсан. Эхлээд LifeStreet MySQL-ээс (Oracle дээр богино зогсолттой) Vertica руу шилжсэн. Мөн та энэ тухай түүхийг олж болно.

Бүх зүйл маш сайн байсан ч өгөгдөл нэмэгдэж, Vertica үнэтэй байгаа нь хурдан тодорхой болсон. Тиймээс янз бүрийн хувилбаруудыг хайж байсан. Тэдгээрийн заримыг энд жагсаав. Үнэн хэрэгтээ бид 13-аас 16-р он хүртэл зах зээл дээр байсан бараг бүх мэдээллийн сангуудын концепцийн нотолгоо эсвэл заримдаа гүйцэтгэлийн туршилтыг хийсэн бөгөөд үйл ажиллагааны хувьд ойролцоогоор тохиромжтой байдаг. Мөн би тэдний заримыг нь HighLoad дээр ярьсан.

Өгөгдөл нэмэгдэж байгаа тул эхний ээлжинд Vertica-аас шилжих даалгавар байсан. Мөн тэд олон жилийн туршид асар хурдацтай өссөн. Дараа нь тэд тавиур дээр очсон ч гэсэн. Мөн энэ өсөлтийг урьдчилан таамаглаж, ямар нэгэн төрлийн аналитик хийх шаардлагатай өгөгдлийн хэмжээний бизнесийн шаардлагууд нь петабайтуудын талаар удахгүй хэлэлцэх нь тодорхой байв. Петабайтыг төлөх нь аль хэдийн маш үнэтэй тул бид хаашаа явах өөр хувилбар хайж байсан.

Хаашаа явах? Удаан хугацааны турш хаашаа явах нь тодорхойгүй байсан, учир нь нэг талаас арилжааны мэдээллийн сан байдаг, тэд сайн ажилладаг бололтой. Зарим нь Vertica шиг бараг сайн ажилладаг бол зарим нь бүр дорддог. Гэхдээ тэд бүгд үнэтэй, үүнээс хямд, илүү сайн зүйл олдохгүй байна.

Нөгөөтэйгүүр, нээлттэй эхийн шийдлүүд байдаг бөгөөд тэдгээр нь тийм ч олон биш, өөрөөр хэлбэл аналитикийн хувьд тэдгээрийг хуруугаараа тоолж болно. Мөн тэд үнэ төлбөргүй эсвэл хямд боловч удаан байдаг. Мөн тэд ихэвчлэн шаардлагатай, ашигтай функцээр дутагдаж байна.

Арилжааны мэдээллийн санд байгаа сайн зүйл болон нээлттэй эх сурвалжид байгаа бүх үнэгүй зүйлийг нэгтгэх зүйл байхгүй.

Yandex гэнэтийн байдлаар ClickHouse-ыг малгайнаас илбэчин, туулай шиг гаргаж автал юу ч байсангүй. Энэ нь гэнэтийн шийдвэр байсан ч тэд "Яагаад?" Гэсэн асуултыг асуусаар байна.

2016 оны зун бид ClickHouse гэж юу болохыг харж эхэлсэн. Заримдаа энэ нь Vertica-аас хурдан байж болох нь тогтоогдсон. Бид янз бүрийн асуулга дээр өөр хувилбаруудыг туршиж үзсэн. Хэрэв асуулгад зөвхөн нэг хүснэгт, өөрөөр хэлбэл ямар ч холболтгүй (нэгдэх) ашигласан бол ClickHouse нь Vertica-аас хоёр дахин хурдан байсан.

Би тийм ч залхуу биш байсан бөгөөд нөгөө өдөр Yandex тестүүдийг үзсэн. Тэнд адилхан: ClickHouse нь Vertica-аас хоёр дахин хурдан байдаг тул тэд энэ тухай байнга ярьдаг.

Гэхдээ асуулгад нэгдлүүд байгаа бол бүх зүйл тийм ч эргэлзээгүй болж хувирна. ClickHouse нь Vertica-аас хоёр дахин удаан ажиллах боломжтой. Хэрэв та хүсэлтийг бага зэрэг засаж, дахин бичвэл тэд ойролцоогоор тэнцүү байна. Муугүй шүү. Мөн үнэгүй.

Туршилтын үр дүнг хүлээн авч, өөр өөр өнцгөөс хараад LifeStreet ClickHouse руу явав.

Энэ бол 16 дахь жил, би танд сануулж байна. Энэ нь хулганууд уйлж, хатгаж байсан ч кактусыг үргэлжлүүлэн идэж байсан тухай хошигнол мэт байв. Энэ талаар дэлгэрэнгүй тайлбарласан, энэ тухай видео гэх мэт.

Тиймээс би энэ талаар дэлгэрэнгүй ярихгүй, зөвхөн үр дүн, тухайн үед яриагүй байсан хэдэн сонирхолтой зүйлээ л ярина.

Үр дүн нь:

• Амжилттай шилжин суурьшсан бөгөөд нэг жил гаруйн хугацаанд систем нь аль хэдийн үйлдвэрлэлд ажиллаж байна.
• Бүтээмж, уян хатан байдал нэмэгдсэн. Өдөрт, дараа нь богино хугацаанд хадгалах боломжтой 10 тэрбум бичлэгээс LifeStreet одоо өдөрт 75 тэрбум бичлэгийг хадгалдаг бөгөөд үүнийг 3 сар ба түүнээс дээш хугацаанд хийх боломжтой. Хэрэв та оргил үедээ тооцвол энэ нь секундэд сая хүртэлх үйл явдал болно. Энэ системд өдөрт нэг сая гаруй SQL асуулга ирдэг бөгөөд ихэнхдээ өөр өөр роботуудаас ирдэг.
• Vertica-аас илүү ClickHouse-д илүү олон сервер ашигладаг байсан ч Vertica-д нэлээд үнэтэй SAS дискүүдийг ашигладаг байсан тул техник хангамжийг хэмнэсэн. ClickHouse нь SATA ашигладаг. Тэгээд яагаад? Учир нь Vertica-д оруулга нь синхрон байдаг. Синхрончлол нь дискийг хэт их удаашруулдаггүй, сүлжээ хэт удаашруулдаггүй, өөрөөр хэлбэл нэлээд үнэтэй ажиллагаа шаарддаг. ClickHouse-д оруулга нь асинхрон байна. Түүнээс гадна та үргэлж бүх зүйлийг дотооддоо бичиж болно, үүнд нэмэлт зардал гарахгүй тул өгөгдлийг ClickHouse-д Vertika-аас хамаагүй хурдан, тэр ч байтугай удаан хөтчүүд дээр оруулах боломжтой. Мөн унших нь ойролцоогоор ижил юм. SATA дээр унших, хэрэв тэд RAID-д байгаа бол энэ нь хангалттай хурдан юм.
• Лицензээр хязгаарлагдахгүй, тухайлбал 3 сервер дэх 60 петабайт өгөгдөл (20 сервер нь нэг хуулбар), 6 их наяд баримт, нэгтгэсэн бичлэг. Vertica-д ийм зүйл байхгүй.

Одоо би энэ жишээн дээр практик зүйлс рүү шилжиж байна.

• Эхнийх нь үр дүнтэй схем юм. Схемээс их зүйл шалтгаална.
• Хоёр дахь нь үр дүнтэй SQL үүсгэх явдал юм.

Ердийн OLAP асуулга нь сонголт юм. Зарим багана нь бүлэгт, зарим багана нь нэгтгэх функц руу ордог. Хаана байна, үүнийг шоо зүсмэл хэлбэрээр илэрхийлж болно. Бүхэл бүтэн бүлгийг төсөөлөл гэж үзэж болно. Тийм ч учраас үүнийг олон талт өгөгдлийн шинжилгээ гэж нэрлэдэг.

Ихэнхдээ энэ баримтын гол баримт, шинж чанарууд нь хажуугийн дагуу, туяа дагуу байх үед одны схем хэлбэрээр загварчлагдсан байдаг.

Мөн физик дизайны хувьд, энэ нь ширээн дээр хэрхэн тохирох талаар тэд ихэвчлэн хэвийн дүрслэлийг хийдэг. Та хэвийн бус болгож болно, гэхдээ энэ нь диск дээр үнэтэй бөгөөд асуулгад тийм ч үр дүнтэй биш юм. Тиймээс тэдгээр нь ихэвчлэн нормчлогдсон дүрслэл, тухайлбал, баримт хүснэгт болон олон хэмжээсийн хүснэгтүүдийг хийдэг.

Гэхдээ энэ нь ClickHouse дээр сайн ажилладаггүй. Хоёр шалтгаан бий:

• Эхнийх нь ClickHouse нь тийм ч сайн холболтгүй, өөрөөр хэлбэл нэгдлүүд байдаг, гэхдээ тэдгээр нь муу байдаг. Муу байхад.
• Хоёр дахь нь хүснэгтүүд шинэчлэгдээгүй байна. Ихэвчлэн одны хэлхээний эргэн тойронд байдаг эдгээр ялтсуудад ямар нэг зүйлийг өөрчлөх шаардлагатай байдаг. Жишээлбэл, хэрэглэгчийн нэр, компанийн нэр гэх мэт. Тэгээд ажиллахгүй байна.

ClickHouse-д үүнээс гарах арга зам бий. бүр хоёр:

• Эхнийх нь толь бичиг ашиглах явдал юм. Гадаад толь бичиг нь од схем, шинэчлэлт гэх мэт асуудлыг 99% шийдвэрлэхэд тусалдаг зүйл юм.
• Хоёр дахь нь массив ашиглах явдал юм. Массивууд нь нэгдлүүд болон хэвийн байдалд орох асуудлуудаас салахад тусалдаг.

• Нэгдэх шаардлагагүй.
• Сайжруулах боломжтой. 2018 оны XNUMX-р сараас хойш толь бичгүүдийг хэсэгчлэн шинэчлэх, өөрөөр хэлбэл өөрчлөгдсөн оруулгуудыг шинэчлэх бичиг баримтгүй боломж гарч ирэв (та үүнийг баримтаас олж чадахгүй). Практикт энэ нь ширээ шиг юм.
• Үргэлж санах ойд байдаг тул толь бичигтэй нэгдэх нь дискэн дээрх хүснэгтээс илүү хурдан ажилладаг бөгөөд энэ нь кэшэд байгаа нь хараахан болоогүй, магадгүй тийм биш юм.

• Та бас нэгдэх шаардлагагүй.
• Энэ нь 1-ээс олон хүртэлх авсаархан дүрслэл юм.
• Мөн миний бодлоор массивууд нь гейкүүдэд зориулагдсан байдаг. Эдгээр нь lambda функцууд гэх мэт.

Энэ нь улаан үгсэд зориулагдаагүй. Энэ бол олон зүйлийг маш энгийн бөгөөд гоёмсог байдлаар хийх боломжийг олгодог маш хүчирхэг функц юм.

Массивыг шийдвэрлэхэд тусалдаг ердийн жишээнүүд. Эдгээр жишээнүүд хангалттай энгийн бөгөөд ойлгомжтой:

• Шошгоор хайх. Хэрэв танд hashtag байгаа бөгөөд hashtag-аар зарим нийтлэл хайхыг хүсч байвал.
• Түлхүүр-утга хосоор хайх. Мөн утгатай зарим шинж чанарууд байдаг.
• Өөр зүйл рүү орчуулах шаардлагатай түлхүүрүүдийн жагсаалтыг хадгалах.

Эдгээр бүх ажлыг массивгүйгээр шийдэж болно. Шошгуудыг зарим мөрөнд байрлуулж, ердийн илэрхийллээр эсвэл тусдаа хүснэгтэд сонгож болно, гэхдээ дараа нь та нэгдлүүд хийх хэрэгтэй.

ClickHouse-д та юу ч хийх шаардлагагүй, зөвхөн hashtag-д зориулсан string массивыг тайлбарлах эсвэл түлхүүр утгын системд зориулж үүрлэсэн бүтцийг хийхэд хангалттай.

Оруулсан бүтэц нь хамгийн сайн нэр биш байж магадгүй юм. Эдгээр нь нэр болон зарим холбогдох шинж чанаруудтай нийтлэг хэсэгтэй хоёр массив юм.

Мөн шошгоор хайхад маш хялбар байдаг. Функцтэй байх has, энэ нь массив элемент агуулсан эсэхийг шалгадаг. Хүн бүр манай чуулгантай холбоотой бүх бичлэгийг оллоо.

Subid-ээр хайх нь арай илүү төвөгтэй юм. Бид эхлээд түлхүүрийн индексийг олж, дараа нь энэ индекстэй элементийг авч, энэ утга нь бидэнд хэрэгтэй байгаа эсэхийг шалгах хэрэгтэй. Гэсэн хэдий ч энэ нь маш энгийн бөгөөд авсаархан юм.

Хэрэв та бүгдийг нэг мөрөнд оруулбал бичмээр байна гэсэн тогтмол хэллэг нь нэгдүгээрт, болхи байх болно. Хоёрдугаарт, энэ нь хоёр массиваас хамаагүй удаан ажилласан.

Өөр нэг жишээ. Танд ID-г хадгалах массив байна. Мөн та тэдгээрийг нэр болгон орчуулж болно. Чиг үүрэг arrayMap. Энэ бол ердийн ламбда функц юм. Та lambda илэрхийллийг тэнд дамжуулдаг. Тэгээд тэр толь бичгээс ID бүрийн нэрний утгыг гаргаж авдаг.

Хайлтыг ижил аргаар хийж болно. Элементүүд юу тохирохыг шалгадаг предикатын функцийг дамжуулдаг.

Эдгээр нь хэлхээг ихээхэн хялбарчилж, олон асуудлыг шийддэг.

Гэхдээ бидний өмнө тулгараад байгаа дараагийн асуудал бол үр дүнтэй асуулга юм.

• ClickHouse-д асуулга төлөвлөгч байхгүй. Үгүй ээ.
• Гэсэн хэдий ч нарийн төвөгтэй асуултуудыг төлөвлөх шаардлагатай хэвээр байна. Ямар тохиолдолд?
• Хэрэв асуулгад олон нэгдэл байгаа бол та тэдгээрийг дэд сонголтоор боож өгнө. Мөн тэдгээрийг гүйцэтгэх дараалал нь чухал юм.
• Хоёр дахь нь - хүсэлтийг тараасан бол. Учир нь тархсан асуулгад зөвхөн хамгийн дотоод дэд сонголтыг хуваарилж гүйцэтгэх ба бусад бүх зүйл таны холбогдсон серверт дамждаг. Тиймээс, хэрэв та олон холболттой (нэгдэх) асуулга тараасан бол дарааллыг сонгох хэрэгтэй.

Илүү энгийн тохиолдолд ч гэсэн заримдаа хуваарийн ажлыг хийж, асуултуудыг бага зэрэг дахин бичих шаардлагатай болдог.

Энд нэг жишээ байна. Зүүн талд шилдэг 5 улсыг харуулсан асуулга байна. Миний бодлоор 2,5 секунд зарцуулдаг. Мөн баруун талд, ижил асуулга, гэхдээ бага зэрэг дахин бичсэн. Мөрөөр бүлэглэхийн оронд бид түлхүүрээр (int) бүлэглэж эхлэв. Мөн энэ нь илүү хурдан юм. Тэгээд бид үр дүнд нь толь бичгийг холбосон. 2,5 секундын оронд хүсэлт 1,5 секунд болно. Энэ сайн байна.

Шүүлтүүрийг дахин бичихтэй ижил төстэй жишээ. ОХУ-ын хүсэлтийг энд оруулав. Энэ нь 5 секундын турш ажилладаг. Хэрэв бид үүнийг мөр биш, харин Оростой холбоотой хэд хэдэн товчлууртай тоонуудыг харьцуулах байдлаар дахин бичвэл энэ нь илүү хурдан болно.

Ийм заль мэх олон бий. Мөн тэд танд аль хэдийн хурдан ажиллаж байна гэж бодож байгаа асуулгыг хурдасгах боломжийг олгодог, эсвэл эсрэгээрээ удаан ажиллаж байна. Тэдгээрийг бүр ч хурдан хийж болно.

• Түгээмэл горимд хамгийн их ажиллах.
• Миний хийсэн шиг хамгийн бага төрлөөр эрэмбэлэх.
• Хэрэв ямар нэгэн нэгдэх (нэгдэх), толь бичиг байгаа бол тэдгээрийг хамгийн сүүлийн арга болгон хийх нь дээр, хэрэв танд аль хэдийн хэсэгчлэн бүлэглэсэн өгөгдөл байгаа бол нэгдэх үйлдэл эсвэл толь бичгийн дуудлага бага удаа дуудагдах бөгөөд энэ нь илүү хурдан болно. .
• Шүүлтүүрийг солих.

Зөвхөн миний үзүүлсэн техник биш, өөр аргууд байдаг. Тэд бүгд заримдаа асуулгын гүйцэтгэлийг ихээхэн хурдасгаж чаддаг.

Дараагийн жишээ рүү шилжье. АНУ-ын X компани. Тэр юу хийж байна?

Даалгавар байсан:

• Зар сурталчилгааны гүйлгээг офлайнаар холбох.
• Төрөл бүрийн холбох загварыг загварчлах.

Сценари нь юу вэ?

Жирийн нэг зочин энэ сайтад орж ирдэг, тухайлбал, сард 20 удаа янз бүрийн зар сурталчилгаанаас ирдэг, эсвэл энэ сайтыг санаж байгаа учраас заримдаа ямар ч зар сурталчилгаагүй ирдэг. Зарим бүтээгдэхүүнийг харж, сагсанд хийж, сагснаас нь гаргаж авдаг. Тэгээд эцэст нь ямар нэг зүйл худалдаж авдаг.

Үндэслэлтэй асуултууд: "Шаардлагатай бол зар сурталчилгааны төлбөрийг хэн төлөх ёстой вэ?" болон "Хэрэв байгаа бол түүнд ямар сурталчилгаа нөлөөлсөн бэ?". Тэр яагаад худалдаж авсан бэ, энэ хүн шиг хүмүүсийг яаж худалдаж авах вэ?

Энэ асуудлыг шийдэхийн тулд вэб сайтад тохиолдож буй үйл явдлуудыг зөв аргаар холбох, өөрөөр хэлбэл тэдгээрийн хооронд ямар нэгэн байдлаар холболт үүсгэх хэрэгтэй. Дараа нь тэдгээрийг DWH-д шинжилгээнд илгээдэг. Мөн энэ дүн шинжилгээн дээр үндэслэн хэн, ямар зар харуулах загваруудыг бүтээ.

Зарын гүйлгээ гэдэг нь зар харуулахаас эхлээд ямар нэг зүйл тохиолдох, дараа нь худалдан авалт хийх, дараа нь худалдан авалт хийх боломжтой холбоотой хэрэглэгчийн үйл явдлын багц юм. Жишээлбэл, хэрэв энэ нь гар утасны програм эсвэл гар утасны тоглоом юм бол програмыг суулгах нь ихэвчлэн үнэ төлбөргүй явагддаг бөгөөд хэрэв тэнд ямар нэг зүйл хийгдсэн бол үүнд мөнгө шаардагдах болно. Мөн хүн өргөдөлд хэдий чинээ их мөнгө зарцуулна төдий чинээ үнэ цэнэтэй байдаг. Гэхдээ үүний тулд та бүх зүйлийг холбох хэрэгтэй.

Олон тооны холбох загварууд байдаг.

Хамгийн алдартай нь:

• Сүүлийн харилцан үйлчлэл, харилцан үйлдэл нь товшилт эсвэл сэтгэгдэл юм.
• Анхны харилцан үйлчлэл, өөрөөр хэлбэл хүнийг сайт руу авчирсан анхны зүйл.
• Шугаман хослол - бүгд адилхан.
• Сунгах.
• гэх мэт.

Тэгээд энэ бүхэн анх яаж бүтсэн бэ? Runtime, Cassandra байсан. Кассандра-г гүйлгээний хадгалалт болгон ашигладаг байсан, өөрөөр хэлбэл холбогдох бүх гүйлгээг түүнд хадгалсан. Runtime-д ямар нэгэн үйл явдал тохиолдоход, жишээлбэл, ямар нэг хуудас эсвэл өөр зүйлийг харуулах үед Кассандра руу хүсэлт тавьсан - ийм хүн байгаа эсэх. Дараа нь үүнтэй холбоотой гүйлгээг авсан. Тэгээд холболт хийгдсэн.

Хэрэв хүсэлт нь гүйлгээний id-тэй байгаа нь азтай бол энэ нь хялбар юм. Гэхдээ ихэвчлэн аз байдаггүй. Тиймээс сүүлийн гүйлгээ эсвэл сүүлийн товшилтоор хийсэн гүйлгээ гэх мэтийг олох шаардлагатай байсан.

Сүүлчийн товшилт хүртэл бүх зүйл маш сайн ажилласан. Учир нь бид нэг сарын хугацаатай цонх тогтоовол өдөрт 10 сая, сард 300 сая товшилт байдаг. Кассандра-д хурдан ажиллахын тулд бүх зүйл санах ойд байх ёстой, учир нь Runtime хурдан хариу үйлдэл үзүүлэх шаардлагатай тул 10-15 сервер зарцуулсан.

Тэд гүйлгээг дэлгэцтэй холбохыг хүсэхэд тэр даруй тийм ч хөгжилтэй биш болсон. Тэгээд яагаад? Үүнээс 30 дахин их үйл явдлыг хадгалах шаардлагатай байгааг харж болно. Үүний дагуу танд 30 дахин их сервер хэрэгтэй болно. Энэ бол ямар нэгэн одон орон судлалын дүрс болох нь харагдаж байна. Runtime дээр серверүүд нэлээд цөөхөн байгаа хэдий ч холболт хийхийн тулд 500 хүртэлх сервертэй байх нь ямар нэгэн буруу үзүүлэлт юм. Тэгээд тэд юу хийхээ бодож эхлэв.

Тэгээд бид ClickHouse руу явлаа. ClickHouse дээр яаж хийх вэ? Өнгөц харахад энэ нь эсрэг хэв маягийн багц юм шиг санагддаг.

• Гүйлгээ өсөж, бид түүнд улам олон үйл явдлуудыг холбодог, өөрөөр хэлбэл энэ нь өөрчлөгддөг, ClickHouse нь өөрчлөгддөг объектуудтай тийм ч сайн ажилладаггүй.
• Манайд зочин ирэхэд бид түүний гүйлгээг түлхүүрээр нь, айлчлалын дугаараар нь гаргах хэрэгтэй. Энэ нь бас цэгийн асуулга бөгөөд тэд ClickHouse дээр үүнийг хийдэггүй. Ихэвчлэн ClickHouse нь том ... скан хийдэг, гэхдээ энд бид зарим бичлэгүүдийг авах хэрэгтэй. Мөн эсрэг загвар.
• Нэмж дурдахад, гүйлгээ json хэл дээр хийгдсэн боловч тэд үүнийг дахин бичихийг хүсээгүй тул json-г бүтэцгүй хэлбэрээр хадгалахыг хүссэн бөгөөд шаардлагатай бол түүнээс ямар нэг зүйлийг татаж авахыг хүссэн. Мөн энэ нь бас эсрэг загвар юм.

Энэ нь эсрэг хэв маягийн багц юм.

Гэсэн хэдий ч энэ нь маш сайн ажилладаг системтэй болсон.

Юу хийсэн бэ? ClickHouse гарч ирсэн бөгөөд үүнд бүртгэлүүд хаягдаж, бүртгэлд хуваагдсан. ClickHouse-аас бүртгэл хүлээн авсан холбоотой үйлчилгээ гарч ирэв. Үүний дараа би оролт бүрийн хувьд зочилсон id-ээр хараахан боловсруулагдаагүй байж болох гүйлгээ, мөн агшин зуурын зургууд, өөрөөр хэлбэл аль хэдийн холбогдсон гүйлгээ, тухайлбал өмнөх ажлын үр дүнг хүлээн авсан. Би аль хэдийн логикийг гаргаж, зөв ​​гүйлгээг сонгож, шинэ үйл явдлуудыг холбосон. Дахин нэвтэрсэн. Бүртгэл нь ClickHouse руу буцаж очсон, өөрөөр хэлбэл энэ нь байнгын мөчлөгийн систем юм. Дээрээс нь би DWH дээр очиж шинжилгээ хийсэн.

Энэ хэлбэр нь тийм ч сайн ажиллахгүй байсан. ClickHouse-д илүү хялбар болгохын тулд зочлох id-ээр хүсэлт ирэхэд тэд эдгээр хүсэлтийг 1-000 зочилсон ID-н блок болгон бүлэглэж, 2-000 хүний ​​бүх гүйлгээг татсан. Тэгээд бүх зүйл үр дүнтэй болсон.

Хэрэв та ClickHouse-ыг харвал энэ бүхэнд үйлчлэх 3 үндсэн хүснэгт л байна.

Логуудыг байршуулсан эхний хүснэгт, бүртгэлийг бараг боловсруулалгүйгээр байршуулдаг.

Хоёр дахь ширээ. Материаллаг үзлээр дамжуулан эдгээр бүртгэлээс хараахан хамааруулж амжаагүй, өөрөөр хэлбэл хамааралгүй үйл явдлуудыг хазсан. Материаллаг дүр төрхөөр дамжуулан агшин зуурын зургийг бүтээхийн тулд эдгээр бүртгэлээс гүйлгээг гаргаж авсан. Өөрөөр хэлбэл, тусгай материалжуулсан харагдац нь гүйлгээний хамгийн сүүлийн хуримтлагдсан төлөвийг агшин зуурын зургийг бүтээсэн.

Энд SQL дээр бичсэн текст байна. Үүнд хэдэн чухал зүйлийн талаар санал бодлоо хэлмээр байна.

Эхний чухал зүйл бол ClickHouse дахь json-оос багана болон талбаруудыг гаргаж авах чадвар юм. Өөрөөр хэлбэл, ClickHouse нь json-тэй ажиллах зарим аргуудтай байдаг. Тэд маш, маш анхдагч юм.

visitParamExtractInt нь json-оос шинж чанаруудыг задлах боломжийг олгодог, өөрөөр хэлбэл эхний цохилт нь ажилладаг. Ингэснээр та гүйлгээний ID-г гаргаж авах эсвэл ID руу зочлох боломжтой. Энэ удаад.

Хоёрдугаарт, энд төвөгтэй материалжуулсан талбарыг ашиглаж байна. Энэ нь юу гэсэн үг вэ? Энэ нь та үүнийг хүснэгтэд оруулах боломжгүй, өөрөөр хэлбэл оруулаагүй, оруулсны дараа тооцоолж, хадгална гэсэн үг юм. Хуулбарлах үед ClickHouse нь танд зориулж ажилладаг. Тэгээд дараа нь танд хэрэгтэй зүйл аль хэдийн json-ээс гаргачихсан байна.

Энэ тохиолдолд материаллаг харагдах байдал нь түүхий эгнээнд зориулагдсан болно. Бараг түүхий гуалин бүхий эхний хүснэгтийг зүгээр л ашиглаж байна. Тэгээд тэр юу хийдэг вэ? Нэгдүгээрт, энэ нь эрэмбэлэхийг өөрчилдөг, өөрөөр хэлбэл, одоо зочлох id-ээр эрэмбэлэх болно, учир нь бид түүний гүйлгээг тодорхой хүний ​​хувьд хурдан гаргах хэрэгтэй.

Хоёрдахь чухал зүйл бол индекс_мөхлөгт байдал юм. Хэрэв та MergeTree-г үзсэн бол энэ нь ихэвчлэн index_granularity-ээр 8 байдаг. Энэ юу вэ? Энэ бол индексийн сийрэг байдлын параметр юм. ClickHouse-д индекс нь сийрэг бөгөөд оруулга бүрийг хэзээ ч индексжүүлдэггүй. Үүнийг 192 тутамд хийдэг. Энэ нь маш их өгөгдөл тооцоолох шаардлагатай үед сайн, гэхдээ бага зэрэг тохиолдолд муу, учир нь их хэмжээний ачаалал байдаг. Хэрэв бид индексийн нарийвчлалыг бууруулбал нэмэлт зардлыг бууруулна. Үүнийг нэг болгож багасгах боломжгүй, учир нь санах ой хангалтгүй байж магадгүй юм. Индекс нь санах ойд үргэлж хадгалагддаг.

Snapshot нь бас бусад сонирхолтой ClickHouse функцуудыг ашигладаг.

Нэгдүгээрт, энэ нь AggregatingMergeTree юм. Мөн AggregatingMergeTree нь argMax-г хадгалдаг, өөрөөр хэлбэл энэ нь сүүлийн цагийн тэмдэгт харгалзах гүйлгээний төлөв юм. Тухайн зочдод зориулж гүйлгээг байнга хийдэг. Мөн энэ гүйлгээний хамгийн сүүлийн төлөвт бид үйл явдал нэмж, шинэ төлөвтэй боллоо. Энэ нь ClickHouse-г дахин цохив. Энэхүү материаллаг дүр төрх дэх argMax-аар дамжуулан бид үргэлж одоогийн төлөвийг авах боломжтой.

• Холболт нь Runtime-аас "салгасан".
• Сард 3 тэрбум хүртэлх гүйлгээг хадгалж, боловсруулдаг. Энэ нь Кассандрагийнхаас, өөрөөр хэлбэл ердийн гүйлгээний системд байснаас илүү том дараалал юм.
• 2x5 ClickHouse серверүүдийн кластер. 5 сервер ба сервер бүр хуулбартай. Энэ нь товшилт дээр суурилсан хамаарлыг хийхийн тулд Кассандрагийнхаас ч бага байгаа бөгөөд энд бид сэтгэгдэл дээр суурилсан байна. Өөрөөр хэлбэл, тэд серверийн тоог 30 дахин нэмэгдүүлэхийн оронд багасгаж чадсан.

Хамгийн сүүлийн жишээ бол хувьцааны үнийн өөрчлөлтийн хамааралд дүн шинжилгээ хийсэн санхүүгийн Y компани юм.

Тэгээд даалгавар нь:

• 5 орчим хувьцаа бий.
• 100 миллисекунд тутамд ишлэлүүд мэдэгдэж байна.
• Мэдээлэл 10 гаруй жил хуримтлагдсан. Зарим компаниудад илүү, заримд нь бага байдаг бололтой.
• Нийтдээ 100 тэрбум орчим мөр байна.

Мөн өөрчлөлтийн хамаарлыг тооцоолох шаардлагатай байв.

Энд хоёр хувьцаа болон тэдгээрийн үнийн санал байна. Хэрэв нэг нь дээшээ, нөгөө нь дээшлэх юм бол энэ нь эерэг хамаарал, өөрөөр хэлбэл нэг нь дээшлэх, нөгөө нь дээшлэх болно. Графикийн төгсгөлд байгаа шиг нэг нь дээшээ, нөгөө нь доошоо буувал энэ нь сөрөг хамаарал, өөрөөр хэлбэл нэг нь өсөхөд нөгөө нь буурдаг.

Эдгээр харилцан өөрчлөлтүүдэд дүн шинжилгээ хийснээр санхүүгийн зах зээлд таамаглал дэвшүүлж болно.

Гэхдээ даалгавар хэцүү. Үүний тулд юу хийж байна вэ? Бидэнд цаг хугацаа, хувьцаа, үнэ гэсэн 100 тэрбум бичлэг бий. Бид эхлээд үнийн алгоритмаас гүйлтийн зөрүүг 100 тэрбум дахин тооцоолох хэрэгтэй. RunningDifference нь ClickHouse дахь хоёр мөр хоорондын зөрүүг дараалан тооцдог функц юм.

Үүний дараа та хамаарлыг тооцоолох хэрэгтэй бөгөөд хос тус бүрээр хамаарлыг тооцох ёстой. 5 хувьцааны хувьд хосууд нь 000 сая байна. Энэ нь маш их, өөрөөр хэлбэл 12,5 дахин их хамааралтай ийм функцийг тооцоолох шаардлагатай.

Хэрэв хэн нэгэн мартсан бол ͞x, ͞y нь мат юм. түүврийн хүлээлт. Энэ нь зөвхөн үндэс, нийлбэрийг тооцоолохоос гадна эдгээр нийлбэрүүдийн дотор дахин нэг нийлбэрийг тооцох шаардлагатай байна. Олон тооны тооцооллыг 12,5 сая удаа хийх шаардлагатай бөгөөд бүр цаг хугацаагаар нь бүлэглэх хэрэгтэй. Бидэнд бас маш олон цаг байна. Мөн та үүнийг 60 секундын дотор хийх ёстой. Энэ бол тоглоом шүү.

ClickHouse гарч ирэхээс өмнө энэ бүхэн маш, маш удаан ажиллаж байсан тул ядаж ямар нэгэн байдлаар цаг гаргах шаардлагатай байсан.

Тэд үүнийг Hadoop, Spark, Greenplum дээр тооцоолохыг оролдсон. Мөн энэ бүхэн маш удаан эсвэл үнэтэй байсан. Энэ нь ямар нэгэн байдлаар тооцоолох боломжтой байсан ч дараа нь үнэтэй байсан.

Дараа нь ClickHouse гарч ирээд бүх зүйл илүү сайжирсан.

Корреляцийг нутагшуулах боломжгүй тул бид өгөгдлийн байршилтай холбоотой асуудал байгааг би танд сануулж байна. Бид өгөгдлүүдийн заримыг нэг сервер дээр, заримыг нь нөгөө сервер дээр байрлуулж, тооцоолж чадахгүй, бүх өгөгдөл нь хаа сайгүй байх ёстой.

Тэд юу хийсэн бэ? Эхний ээлжинд өгөгдлийг нутагшуулсан байна. Сервер бүр тодорхой багц хувьцааны үнийн талаархи мэдээллийг хадгалдаг. Мөн тэд давхцдаггүй. Тиймээс logReturn-ийг зэрэгцээ, бие даасан байдлаар тооцоолох боломжтой бөгөөд энэ бүхэн зэрэгцээ, тархсан хэвээр байна.

Дараа нь бид илэрхийлэлтэй байдлаа алдахгүйгээр эдгээр өгөгдлийг багасгахаар шийдсэн. Массив ашиглахаа багасгах, тухайлбал цаг хугацаа бүрт хувьцааны массив болон үнийн массивыг гаргах. Тиймээс энэ нь өгөгдлийн зай бага эзэлдэг. Мөн тэдэнтэй ажиллахад арай хялбар байдаг. Эдгээр нь бараг зэрэгцээ үйлдлүүд юм, өөрөөр хэлбэл бид хэсэгчлэн зэрэгцээ уншиж, дараа нь сервер рүү бичдэг.

Үүний дараа үүнийг хуулбарлах боломжтой. "R" үсэг нь бид энэ өгөгдлийг хуулбарласан гэсэн үг юм. Өөрөөр хэлбэл, бид бүх гурван сервер дээр ижил өгөгдөлтэй байдаг - эдгээр нь массивууд юм.

Дараа нь тооцоолох шаардлагатай 12,5 сая корреляцийн багцын тусгай скриптээр та багц хийж болно. Өөрөөр хэлбэл, 2 хос хамаарал бүхий 500 даалгавар. Мөн энэ ажлыг тодорхой ClickHouse сервер дээр тооцоолох ёстой. Түүнд бүх өгөгдөл байгаа, учир нь өгөгдөл нь адилхан бөгөөд тэр тэдгээрийг дараалан тооцоолж чаддаг.

Дахин хэлэхэд энэ нь иймэрхүү харагдаж байна. Нэгдүгээрт, бид энэ бүтцэд байгаа бүх өгөгдөлтэй: цаг хугацаа, хувьцаа, үнэ. Дараа нь бид logReturn-ийг тооцоолсон, өөрөөр хэлбэл ижил бүтэцтэй өгөгдөл, гэхдээ үнийн оронд бид logReturn-ийг аль хэдийн авсан. Дараа нь тэдгээрийг дахин хийсэн, өөрөөр хэлбэл бид хувьцаа болон үнийн талаар цаг хугацаа, groupArray-ийг авсан. Хувилсан. Үүний дараа бид хэд хэдэн даалгавруудыг үүсгэж, тэдгээрийг тоолохын тулд ClickHouse-д өгсөн. Тэгээд ажилладаг.

Үзэл баримтлалыг нотлоход даалгавар нь дэд даалгавар байсан, өөрөөр хэлбэл бага өгөгдөл авсан. Зөвхөн гурван сервер.

Эдгээр эхний хоёр үе шат: Log_return-ийг тооцоолох, массиваар ороох нь нэг цаг орчим үргэлжилсэн.

Мөн корреляцийн тооцоо нь ойролцоогоор 50 цаг байна. Гэхдээ 50 цаг хангалттай биш, учир нь тэд долоо хоногоор ажилладаг байсан. Энэ бол том амжилт байлаа. Хэрэв та тоолох юм бол энэ кластерт бүх зүйл секундэд 70 удаа тооцогддог.

Гэхдээ хамгийн чухал зүйл бол энэ систем нь бараг ямар ч саад бэрхшээлгүй, өөрөөр хэлбэл бараг шугаман масштабтай байдаг. Тэгээд тэд үүнийг шалгасан. Үүнийг амжилттай томруулж чадсан.

• Зөв схем бол амжилтын тал хувь юм. Зөв схем бол шаардлагатай бүх ClickHouse технологийг ашиглах явдал юм.
• Summing/AggregatingMergeTrees нь төлөвийн агшин зуурын зургийг нэгтгэх эсвэл онцгой тохиолдол болгон авч үзэх боломжийг олгодог технологи юм. Мөн энэ нь маш олон зүйлийг хялбаршуулдаг.
• Материалжуулсан харагдац нь нэг индексийн хязгаарыг давах боломжийг танд олгоно. Магадгүй би үүнийг тодорхой хэлээгүй байж магадгүй, гэхдээ бид логуудыг ачаалах үед түүхий бүртгэлүүд нь нэг индекстэй хүснэгтэд байсан бөгөөд шинж чанарын бүртгэлүүд нь хүснэгтэд байсан, өөрөөр хэлбэл ижил өгөгдөл нь зөвхөн шүүгдсэн боловч индекс бүрэн байсан. бусад. Энэ нь ижил өгөгдөл юм шиг санагддаг, гэхдээ ялгаатай эрэмбэлэгдсэн. Материалжуулсан харагдац нь танд хэрэгтэй бол ийм ClickHouse хязгаарлалтыг давах боломжийг олгоно.
• Цэгийн асуулгад индексийн нарийвчлалыг багасгах.
• Мөн өгөгдлийг ухаалаг тарааж, аль болох сервер доторх өгөгдлийг нутагшуулахыг хичээ. Мөн хүсэлтүүд аль болох нутагшуулах аргыг аль болох ашиглахыг хичээгээрэй.

Энэхүү товч яриаг дүгнэж хэлэхэд ClickHouse нь арилжааны мэдээллийн сан болон нээлттэй эх сурвалжийн мэдээллийн баазын аль алиных нь нутаг дэвсгэрийг, тухайлбал аналитикийн хувьд бүрэн эзэмшсэн гэж хэлж болно. Тэр энэ ландшафттай төгс тохирно. Үүнээс гадна, энэ нь аажмаар бусдыг шахаж эхэлдэг, учир нь танд ClickHouse байгаа үед танд InfiniDB хэрэггүй болно. Хэрэв тэд ердийн SQL дэмжлэгийг хийвэл Вертика удахгүй хэрэггүй болно. Сайхан амраарай!

-Мэдээлэл өгсөнд баярлалаа! Маш сонирхолтой! Apache Phoenix-тэй харьцуулах зүйл байсан уу?

Үгүй ээ, би хэн нэгнийг харьцуулахыг сонсоогүй. Бид болон Yandex нь өөр өөр мэдээллийн сантай бүх ClickHouse харьцуулалтыг хянахыг хичээдэг. Учир нь гэнэт ямар нэг зүйл ClickHouse-аас хурдан болвол Леша Миловидов шөнө унтаж чадахгүй, хурдан хурдасгаж эхэлдэг. Би ийм харьцуулалт сонсож байгаагүй.

• (Алексей Миловидов) Apache Phoenix бол Hbase-ээр ажилладаг SQL хөдөлгүүр юм. Hbase нь голчлон гол утгын ажлын хувилбарт зориулагдсан. Тэнд, мөр бүрт дурын нэр бүхий дурын тооны багана байж болно. Үүнийг Hbase, Cassandra зэрэг системүүдийн талаар хэлж болно. Мөн энэ нь маш хүнд аналитик асуулга нь тэдний хувьд хэвийн ажиллахгүй болно. Эсвэл та ClickHouse-г ашиглаж байгаагүй бол сайн ажилладаг гэж бодож магадгүй.

• Спасибо

  • Өдрийн мэнд Би аналитик дэд системтэй тул энэ сэдвийг аль хэдийн сонирхож байна. Гэхдээ би ClickHouse-г харахад ClickHouse нь үйл явдлын дүн шинжилгээ хийхэд маш сайн тохирдог, өөрчлөгдөх чадвартай юм шиг санагддаг. Хэрэв би олон тооны том хүснэгтээр бизнесийн олон өгөгдөлд дүн шинжилгээ хийх шаардлагатай бол миний ойлгосноор ClickHouse надад тийм ч тохиромжтой биш гэж үү? Ялангуяа тэд өөрчлөгдвөл. Энэ зөв үү эсвэл үүнийг үгүйсгэх жишээ бий юу?

  • Энэ зөв. Энэ нь ихэнх тусгай аналитик мэдээллийн сангуудад үнэн юм. Тэдгээр нь өөрчлөгддөг нэг буюу хэд хэдэн том хүснэгтүүд байдаг ба аажмаар өөрчлөгддөг олон жижиг хүснэгтүүдэд зориулагдсан байдаг. Өөрөөр хэлбэл ClickHouse нь Oracle-тай адил биш бөгөөд та бүх зүйлийг байрлуулж, маш нарийн төвөгтэй асуулга үүсгэж болно. ClickHouse-г үр дүнтэй ашиглахын тулд та ClickHouse дээр сайн ажиллах схемийг бүтээх хэрэгтэй. Өөрөөр хэлбэл, хэт их хэвийн байдлаас зайлсхийх, толь бичиг ашиглах, цөөн урт холбоос хийхийг хичээ. Хэрэв схемийг ийм байдлаар бүтээсэн бол ижил төстэй бизнесийн даалгавруудыг ClickHouse дээр уламжлалт харилцааны мэдээллийн сангаас хамаагүй илүү үр дүнтэй шийдвэрлэх боломжтой.

Мэдээлэл өгсөнд баярлалаа! Сүүлийн үеийн санхүүгийн хэргийн талаар асуух зүйл байна. Тэд аналитиктай байсан. Тэднийг хэрхэн дээш, доошилж байгааг харьцуулах шаардлагатай байсан. Та энэ аналитикийн системийг тусгайлан бүтээсэн гэж би ойлгож байна уу? Хэрэв маргааш, жишээлбэл, тэдэнд энэ өгөгдлийн талаар өөр тайлан хэрэгтэй бол тэд схемийг дахин бүтээж, өгөгдлийг байршуулах шаардлагатай юу? Энэ нь хүсэлтийг авахын тулд ямар нэгэн урьдчилсан боловсруулалт хийх үү?

Мэдээжийн хэрэг, энэ бол ClickHouse-ийг маш тодорхой даалгаварт ашиглах явдал юм. Үүнийг илүү уламжлалт байдлаар Hadoop дотор шийдэж болно. Hadoop-ийн хувьд энэ бол хамгийн тохиромжтой ажил юм. Гэхдээ Hadoop дээр энэ нь маш удаан байна. Миний зорилго бол ClickHouse нь ихэвчлэн огт өөр хэрэгслээр шийдэгддэг даалгавруудыг шийдэж чаддаг, гэхдээ үүний зэрэгцээ үүнийг илүү үр дүнтэй гүйцэтгэдэг гэдгийг харуулах явдал юм. Энэ нь тодорхой даалгаварт зориулагдсан болно. Хэрэв үүнтэй ижил төстэй асуудал байгаа бол үүнийг ижил төстэй байдлаар шийдэж болох нь ойлгомжтой.

Энэ нь тодорхой байна. Та 50 цаг боловсруулсан гэж хэлсэн. Энэ нь анхнаасаа юм уу, хэзээ өгөгдөл ачаалсан юм бэ, үр дүн нь гарсан юм уу?

Тийм тийм.

За танд маш их баярлалаа.

Энэ нь 3 серверийн кластер дээр байна.

Мэндчилгээ! Мэдээлэл өгсөнд баярлалаа! Бүх зүйл маш сонирхолтой байдаг. Би функциональ байдлын талаар бага зэрэг асуухгүй, харин тогтвортой байдлын хувьд ClickHouse-ийг ашиглах талаар асуух болно. Энэ нь танд байсан уу, сэргээх шаардлагатай байсан уу? Энэ тохиолдолд ClickHouse хэрхэн ажилладаг вэ? Танд бас хуулбар байсан уу? Жишээлбэл, ClickHouse нь хязгаараасаа гарч, унах үед бид асуудалтай тулгарсан.

Мэдээжийн хэрэг, хамгийн тохиромжтой систем гэж байдаггүй. ClickHouse ч бас өөрийн гэсэн асуудалтай байдаг. Гэхдээ Yandex.Metrica удаан хугацаанд ажиллахгүй байгаа талаар та сонссон уу? Тийм биш байх. ClickHouse дээр 2012-2013 оноос хойш найдвартай ажиллаж байна. Би өөрийн туршлагын талаар ижил зүйлийг хэлж чадна. Бид хэзээ ч бүрэн бүтэлгүйтэж байгаагүй. Зарим хэсэгчилсэн зүйл тохиолдож болох ч бизнест ноцтой нөлөөлөхүйц чухал зүйл байгаагүй. Энэ нь хэзээ ч тохиолдоогүй. ClickHouse нь нэлээд найдвартай бөгөөд санамсаргүй байдлаар унадаггүй. Та үүнд санаа зовох хэрэггүй. Энэ бол түүхий эд биш. Үүнийг олон компани нотолсон.

Сайн уу? Та өгөгдлийн схемийг нэн даруй бодох хэрэгтэй гэж хэлсэн. Хэрэв ийм зүйл болсон бол яах вэ? Миний өгөгдөл цутгаж, цутгаж байна. Зургаан сар өнгөрч, ийм амьдрах боломжгүй гэдгийг би ойлгож байна, би өгөгдлийг дахин байршуулж, тэдэнтэй ямар нэг зүйл хийх хэрэгтэй байна.

Энэ нь мэдээж таны системээс хамаарна. Үүнийг бараг зогсолтгүй хийх хэд хэдэн арга бий. Жишээлбэл, хэрэв та өвөрмөц зураглал хийх боломжтой бол өөр өгөгдлийн бүтцийг бий болгох Материалжуулсан харагдац үүсгэж болно. Хэрэв энэ нь ClickHouse ашиглан зураглал хийхийг зөвшөөрвөл, өөрөөр хэлбэл зарим зүйлийг задлах, үндсэн түлхүүрийг өөрчлөх, хуваалтыг өөрчлөх, дараа нь та Материалжуулсан харагдацыг хийж болно. Тэнд хуучин өгөгдлөө дарж бичээрэй, шинийг автоматаар бичих болно. Тэгээд зүгээр л Материалжуулсан харагдац руу шилжиж, бичлэгээ сольж, хуучин хүснэгтийг устгана уу. Энэ нь ерөнхийдөө зогсолтгүй арга юм.

Баярлалаа.

Эх сурвалж: www.habr.com