🥇 ClickHouse руу шилжих: 3 жилийн дараа

Гурван жилийн өмнө Виктор Тарнавский, Алексей Миловидов нар Yandex-ийн тайзан дээр Өндөр ачаалал ++ гэж хэлсэн, ClickHouse хэр сайн вэ, энэ нь хэрхэн удааширдаггүй вэ. Тэгээд дараагийн шатанд байсан Александр Зайцев с тайлан руу шилжих тухай clickhouse өөр аналитик DBMS-аас мөн дүгнэлтээр clickhouse, мэдээж сайн, гэхдээ тийм ч тохиромжтой биш. Хэзээ 2016 онд компани Амьдрал, Александр тэр үед ажиллаж байсан бөгөөд олон петабайт аналитик системийг хөрвүүлж байв clickhouse, энэ бол үл мэдэгдэх аюулаар дүүрэн "шар тоосгон зам" байсан. clickhouse тэр үед уурхайн талбай шиг харагдаж байсан.

Гурван жилийн дараа clickhouse илүү сайжирсан - энэ хугацаанд Александр Altinity компанийг байгуулсан бөгөөд энэ нь хүмүүст шилжихэд тусалдаг төдийгүй clickhouse олон арван төсөл хэрэгжүүлэхээс гадна Yandex-ийн хамт олонтойгоо хамт бүтээгдэхүүнээ сайжруулдаг. Одоо clickhouse хайхрамжгүй зугаалах биш, харин уурхайн талбай байхаа больсон.

Александр 2003 оноос хойш тархсан системтэй ажиллаж, томоохон төслүүдийг боловсруулж байна MySQL, Oracle и Vertica. Хамгийн сүүлд Өндөр ачаалал++ 2019 Ашиглалтын анхдагчдын нэг бол Александр clickhouse, энэ DBMS одоо юу болохыг хэлсэн. Бид үндсэн шинж чанаруудын талаар мэдэх болно clickhouse: бусад системээс юугаараа ялгаатай, ямар тохиолдолд ашиглах нь илүү үр дүнтэй байдаг. Жишээнүүдийг ашиглан бид систем барих сүүлийн үеийн болон төслийн туршсан туршлагыг авч үзэх болно clickhouse.

Эргэн тойрон: 3 жилийн өмнө болсон явдал

Гурван жилийн өмнө бид компаниа шилжүүлсэн Амьдрал тухай clickhouse өөр аналитик мэдээллийн сангаас, зар сурталчилгааны сүлжээний аналитик шилжилт нь дараах байдалтай харагдсан:

2016 оны зургадугаар сар Нээлттэй эх сурвалж үзэгдэв clickhouse мөн манай төсөл эхэлсэн;
Наймдугаар сар. Үзэл баримтлалын баталгаа: зар сурталчилгааны томоохон сүлжээ, дэд бүтэц, 200-300 терабайт өгөгдөл;
Аравдугаар сар. Үйлдвэрлэлийн анхны өгөгдөл;
Арванхоёрдугаар сар. Бүтээгдэхүүний бүрэн ачаалал нь өдөрт 10-50 тэрбум үйл явдал юм.
2017 оны XNUMX-р сар. Хэрэглэгчдийн шилжилт хөдөлгөөн амжилттай болсон clickhouse, 2,5 серверийн кластер дээрх 60 петабайт өгөгдөл.

Шилжилт хөдөлгөөний явцад ийм ойлголт улам бүр нэмэгдэж байсан clickhouse Энэ нь ажиллахад таатай сайн систем боловч энэ нь Yandex-ийн дотоод төсөл юм. Тиймээс, нюансууд байдаг: Yandex эхлээд өөрийн дотоод үйлчлүүлэгчидтэй харьцах бөгөөд зөвхөн дараа нь олон нийт, гадаад хэрэглэгчдийн хэрэгцээ шаардлагад нийцүүлэн ажиллах бөгөөд ClickHouse дараа нь олон функциональ чиглэлээр аж ахуйн нэгжийн түвшинд хүрч чадаагүй юм. Тийм ч учраас бид 2017 оны XNUMX-р сард Altinity-г үүсгэн байгуулсан clickhouse зөвхөн Yandex төдийгүй бусад хэрэглэгчдэд илүү хурдан бөгөөд илүү тохиромжтой. Тэгээд одоо бид:

Бид сургалтад тулгуурлан шийдлийг бий болгоход тусалдаг clickhouse үйлчлүүлэгчид асуудалд орохгүйн тулд шийдэл нь эцсийн дүндээ ажиллах болно;
Бид 24/7 дэмжлэг үзүүлдэг clickhouse- суурилуулалт;
Бид өөрсдийн экосистемийн төслийг боловсруулдаг;
Бид өөрсдөдөө идэвхтэй үйлчилдэг clickhouse, тодорхой функцуудыг харахыг хүссэн хэрэглэгчдийн хүсэлтэд хариулах.

Мэдээжийн хэрэг, бид нүүхэд тусалдаг clickhouse с MySQL, Vertica, Oracle-ийн, Ногоон чавга, Redshift болон бусад системүүд. Бид янз бүрийн нүүдэлд оролцож байсан бөгөөд тэд бүгд амжилттай болсон.

Яагаад шилжих гэж clickhouse

Удахгүй! Энэ бол гол шалтгаан. clickhouse - янз бүрийн хувилбаруудын хувьд маш хурдан мэдээллийн сан:

Хүмүүстэй удаан хугацаанд ажиллаж байсан хүмүүсийн санамсаргүй ишлэлүүд clickhouse.

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

Зөөврийн чадвар. Нэг зүйлд наалдсан зүйл байхгүй. Жишээлбэл, хамт Амазоны Redshift Хаа нэг газар нүүхэд хэцүү байдаг. А clickhouse Та үүнийг зөөврийн компьютер, сервер дээрээ суулгаж, үүлэн дээр байрлуулж, очиж болно Kubernetes - дэд бүтцийн үйл ажиллагаанд ямар нэгэн хязгаарлалт байхгүй. Энэ нь хүн бүрт тохиромжтой бөгөөд энэ нь бусад ижил төстэй мэдээллийн сангуудаар сайрхаж чадахгүй том давуу тал юм.

Уян хатан байдал. clickhouse нэг зүйл дээр зогсдоггүй, жишээ нь Yandex.Metrica, харин хөгжиж, улам олон янзын төсөл, салбарт ашиглагддаг. Шинэ асуудлыг шийдвэрлэх шинэ чадавхийг нэмэх замаар үүнийг өргөжүүлж болно. Жишээлбэл, мэдээллийн санд бүртгэлийг хадгалах нь ёс суртахуунгүй гэж үздэг тул тэд үүнийг гаргаж ирэв Elasticsearch. Гэхдээ уян хатан байдлын ачаар clickhouse, та үүн дээр бүртгэлээ хадгалах боломжтой бөгөөд ихэнхдээ энэ нь үүнээс ч дээр юм Elasticsearch - үед clickhouse Энэ нь 10 дахин бага төмөр шаарддаг.

Үнэгүй Нээлттэй эх. Та юу ч төлөх шаардлагагүй. Зөөврийн компьютер эсвэл сервер дээрээ системийг суулгах зөвшөөрөл авах шаардлагагүй. Ямар ч далд хураамж байхгүй. Үүний зэрэгцээ өөр ямар ч Нээлттэй эх сурвалжийн мэдээллийн баазын технологи хурдтай өрсөлдөж чадахгүй clickhouse. MySQL, MariaDB, Greenplum - Тэд бүгд илүү удаан байдаг.

Олон нийт, жолоодох ба хөгжилтэйБайна. Үед clickhouse Маш сайн нийгэмлэг: уулзалтууд, чатууд, биднийг эрч хүч, өөдрөг үзлээр цэнэглэдэг Алексей Миловидов.

ClickHouse руу шилжиж байна

Очих гэж clickhouse Яагаад ч юм танд гурван зүйл л хэрэгтэй:

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

Хөдлөх асуудал

Зөвхөн нэг "гэхдээ" байдаг: хэрэв та нүүж очвол clickhouse өөр зүйлээс, дараа нь ихэвчлэн ямар нэг зүйл буруу болдог. Бид өөрсдийн дуртай мэдээллийн санд ажилладаг зарим дадал зуршил, зүйлд дассан. Жишээлбэл, хамтран ажилладаг хүн бүр SQL-өгөгдлийн сан нь дараах функцүүдийн багцыг заавал биелүүлэх ёстой гэж үздэг.

гүйлгээ;
хязгаарлалт;
тууштай байдал;
индексүүд;
ШИНЭЧЛЭХ/Устгах;
NULL;
миллисекунд;
автомат төрлийн цутгамал;
олон холболт;
дурын хуваалтууд;
кластерийн удирдлагын хэрэгслүүд.

Ажилд авах нь заавал байх ёстой, гэхдээ гурван жилийн өмнө clickhouse Эдгээр функцүүдийн аль нь ч боломжгүй байсан! Одоо хэрэгжээгүй байгаа зүйлийн талаас бага хувь нь үлдэж байна: гүйлгээ, хязгаарлалт, Тогтвортой байдал, миллисекунд болон төрлийн цутгалт.

Хамгийн гол нь дотор нь байгаа юм clickhouse зарим стандарт дадал, арга барил нь бидний хэрэглэж байснаас өөрөөр ажиллахгүй эсвэл өөрөөр ажилладаг. Харагдах бүх зүйл clickhouse, тохирч байна "ClickHouse арга", өөрөөр хэлбэл. функцууд нь бусад мэдээллийн сангаас ялгаатай. Жишээлбэл:

Индексүүдийг сонгоогүй, харин алгассан.
ШИНЭЧЛЭХ/Устгах синхрон биш, харин асинхрон.
Олон тооны нэгдлүүд байгаа боловч асуулга төлөвлөгч байхгүй. Дараа нь тэдгээрийг хэрхэн гүйцэтгэх нь мэдээллийн сангийн ертөнцийн хүмүүст тийм ч тодорхой биш байдаг.

ClickHouse скриптүүд

1960 онд Унгар гаралтай Америкийн математикч Wigner EP нийтлэл бичсэн "Байгалийн шинжлэх ухаанд математикийн үндэслэлгүй үр нөлөө” (“Байгалийн шинжлэх ухаан дахь математикийн үл ойлгогдох үр нөлөө”) бидний эргэн тойрон дахь ертөнц яагаад ч юм математикийн хуулиудаар сайн дүрслэгдсэн байдаг. Математик бол хийсвэр шинжлэх ухаан бөгөөд математик хэлбэрээр илэрхийлэгдсэн физикийн хуулиуд нь өчүүхэн зүйл биш бөгөөд Wigner EP Энэ нь маш хачирхалтай гэдгийг онцлон тэмдэглэв.

Миний бодлоор, clickhouse - ижил хачин байдал. Вигнерийг дахин хэлвэл бид үүнийг хэлж чадна: төсөөлшгүй үр ашиг нь гайхалтай юм clickhouse олон төрлийн аналитик хэрэглээнд!

Жишээлбэл, авч үзье Бодит цагийн мэдээллийн агуулах, үүнд өгөгдөл бараг тасралтгүй ачаалагддаг. Бид түүнээс хүсэлтийг хоёр дахь удаагаа хойшлуулахыг хүсч байна. Үүнийг ашигла clickhouse, учир нь энэ нь түүнийг зохиосон хувилбар юм. clickhouse Үүнийг зөвхөн вэб дээр төдийгүй маркетинг, санхүүгийн аналитикт ашигладаг. AdTech, түүнчлэн in Залилан илрүүлэхn. IN Бодит цагийн мэдээллийн агуулах "Од" эсвэл "цасан ширхгүүд" гэх мэт нарийн бүтэцтэй схемийг ашигладаг бөгөөд олон хүснэгтүүд байдаг. НЭГДЭХ (заримдаа олон), өгөгдөл нь ихэвчлэн зарим системд хадгалагдаж, өөрчлөгддөг.

Өөр нэг хувилбарыг авч үзье - Цагийн цуврал: төхөөрөмжүүдийн хяналт, сүлжээ, хэрэглээний статистик, интернетийн зүйлс. Энд бид цаг тухайд нь захиалсан нэлээд энгийн үйл явдлуудтай тулгардаг. clickhouse анхнаасаа үүнд зориулж бүтээгдээгүй боловч сайн ажилладаг гэдгээ харуулсан тул томоохон компаниуд ашигладаг clickhouse хяналтын мэдээллийн сан болгон. Энэ нь тохиромжтой эсэхийг судлах clickhouse цаг хугацааны цувралын хувьд бид арга барил, үр дүнд үндэслэн жишиг үнэлгээ хийсэн InfluxDB и Цагийн хуваарь DB - мэргэшсэн цагийн цуваа мэдээллийн сан. Энэ нь тодорхой болов, тэр clickhouse, ийм даалгаврыг оновчтой болгохгүйгээр ч гэсэн гадаад талбарт ялалт байгуулдаг:

В цагийн цуваа Ихэвчлэн нарийн ширээг ашигладаг - хэд хэдэн жижиг багана. Мониторингоос маш олон өгөгдөл гарч ирдэг—секундэд сая сая бичлэг— тэдгээр нь ихэвчлэн жижиг тэсрэлтээр ирдэг (Бодит цаг урсгал). Тиймээс өөр оруулах скрипт хэрэгтэй бөгөөд асуулга нь өөрөө өөрийн гэсэн онцлогтой байдаг.

Лог удирдах. Мэдээллийн санд бүртгэл цуглуулах нь ихэвчлэн муу байдаг, гэхдээ clickhouse Үүнийг дээр дурдсанчлан зарим тайлбараар хийж болно. Олон компани ашигладаг clickhouse яг энэ зорилгоор. Энэ тохиолдолд бид логуудыг бүхэлд нь (жишээлбэл, хэлбэрээр) хадгалдаг хавтгай өргөн хүснэгтийг ашигладаг JSON), эсвэл хэсэг болгон хуваасан. Өгөгдлийг ихэвчлэн том багцаар (файл) ачаалдаг бөгөөд бид зарим талбараар хайдаг.

Эдгээр функц бүрийн хувьд ихэвчлэн тусгай мэдээллийн санг ашигладаг. clickhouse хүн үүнийг бүгдийг нь хийж чаддаг бөгөөд энэ нь тэднээс илүү байдаг. Одоо илүү дэлгэрэнгүй харцгаая цагийн цуваа хувилбар, хэрхэн зөв "хоол хийх" clickhouse энэ хувилбарын хувьд.

Цагийн цуврал

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

Эдгээр төрлийн ихэнх үйл явдлууд нь хяналтаас гардаг. Энэ нь зөвхөн вэбийг хянах төдийгүй бодит төхөөрөмжүүд: машин, үйлдвэрлэлийн систем, зүйлс, үйлдвэрүүд эсвэл нисгэгчгүй такси, Яндекс аль хэдийн ачаа тээшийг нь байрлуулж байна clickhouse- сервер.

Жишээлбэл, хөлөг онгоцноос мэдээлэл цуглуулдаг компаниуд байдаг. Хэдэн секунд тутамд чингэлэг хөлөг дээрх мэдрэгчүүд хэдэн зуун өөр хэмжилт илгээдэг. Инженерүүд тэдгээрийг судалж, загвар зохион бүтээж, хөлөг онгоцыг хэр үр ашигтай ашиглаж байгааг ойлгохыг хичээдэг, учир нь чингэлэг хөлөг нэг секунд ч сул зогсох ёсгүй. Аливаа зогсолт нь мөнгө алддаг тул зогсолт бага байхын тулд замыг урьдчилан таамаглах нь чухал юм.

Өнөө үед хэмждэг төрөлжсөн мэдээллийн сангууд нэмэгдэж байна цагийн цуваа. Сайт дээр DB-Хөдөлгүүрүүд Янз бүрийн мэдээллийн сангууд ямар нэгэн байдлаар эрэмблэгдсэн бөгөөд та тэдгээрийг төрлөөр нь харж болно:

Хамгийн хурдан хөгжиж буй төрөл нь хугацааны цуваас. График мэдээллийн баазууд ч мөн нэмэгдэж байна, гэхдээ хугацааны цуваасүүлийн хэдэн жилд илүү хурдацтай хөгжиж байна. Энэ гэр бүлийн мэдээллийн сангийн ердийн төлөөлөгчид InfluxDB, Prometheus, KDB, Цагийн хуваарь DB (дээр нь барьсан PostgreSQL), шийдлүүд Амазоны. clickhouse энд бас ашиглаж болно, мөн ашиглаж байна. Би танд олон нийтийн цөөн хэдэн жишээ хэлье.

Анхдагчдын нэг бол компани юм CloudFlare (CDN- нийлүүлэгч). Тэд өөрсдийнхөө үйл ажиллагааг хянадаг CDN дамжуулан clickhouse (DNS- хүсэлт, HTTP-асуулга) асар их ачаалалтай - секундэд 6 сая үйл явдал. Бүх зүйл дамждаг Kaфка, руу явдаг clickhouse, энэ нь систем дэх үйл явдлын хяналтын самбарыг бодит цаг хугацаанд харах боломжийг олгодог.

Comcast - АНУ-ын харилцаа холбооны салбарт тэргүүлэгчдийн нэг: Интернет, дижитал телевиз, телефон утас. Тэд ижил төстэй хяналтын системийг бий болгосон CDN хүрээнд Нээлттэй эх төсөл Apache Traffic Control Таны асар том өгөгдөлтэй ажиллах. clickhouse аналитикийн арын хэсэг болгон ашигладаг.

Перкона барьсан clickhouse таны дотор PMMтөрөл бүрийн мониторинг хадгалах MySQL.

Тодорхой шаардлага

Цагийн цуврал мэдээллийн сан нь өөрийн гэсэн тусгай шаардлагуудтай байдаг.

Олон агентаас хурдан оруулах. Бид олон урсгалаас өгөгдлийг маш хурдан оруулах ёстой. clickhouse Түүний бүх оруулга нь бөглөрдөггүй тул үүнийг сайн хийдэг. Ямар ч оруулах нь дискэн дээрх шинэ файл бөгөөд жижиг оруулгууд нь ямар нэгэн байдлаар буферт хадгалагдах боломжтой. IN clickhouse Өгөгдлийг нэг мөр оруулахаас илүү том багцаар оруулах нь дээр.
Уян хатан схем. The цагийн цуваа Бид ихэвчлэн өгөгдлийн бүтцийг бүрэн мэддэггүй. Тодорхой хэрэглээнд зориулж хяналтын системийг бий болгох боломжтой боловч дараа нь өөр хэрэглээнд ашиглахад хэцүү байдаг. Энэ нь илүү уян хатан схемийг шаарддаг. clickhouse, энэ нь хүчтэй бичигдсэн суурь боловч үүнийг хийх боломжийг танд олгоно.
Өгөгдлийг үр дүнтэй хадгалах, мартах. Ихэвчлэн дотор цагийн цуваа асар их хэмжээний өгөгдөл учраас аль болох үр ашигтай хадгалах ёстой. Жишээлбэл, at InfluxDB сайн шахалт нь түүний гол онцлог юм. Гэхдээ та хадгалахаас гадна хуучин өгөгдлийг "мартаж" ямар нэгэн зүйлийг хийх чадвартай байх хэрэгтэй дээж авах - дүүргэгчийг автоматаар тоолох.
Нэгдсэн өгөгдөл дээр хурдан асуулга. Заримдаа сүүлийн 5 минутыг миллисекундын нарийвчлалтайгаар харах нь сонирхолтой байдаг ч сарын өгөгдлийн минут эсвэл хоёр дахь нарийвчлал шаардлагагүй байж магадгүй - ерөнхий статистик хангалттай. Энэ төрлийн дэмжлэг зайлшгүй шаардлагатай, эс тэгвээс 3 сарын хүсэлтийг биелүүлэхэд маш их хугацаа шаардагдана clickhouse.
" гэх мэт хүсэлтүүдсүүлийн цэг, байдлаар». Эдгээр нь ердийн зүйл юм цагийн цуваа асуулга: хамгийн сүүлийн хэмжилт эсвэл системийн төлөвийг агшин зуур харах t. Эдгээр нь өгөгдлийн сангийн хувьд тийм ч таатай асуулт биш боловч та тэдгээрийг гүйцэтгэх чадвартай байх хэрэгтэй.
"Наалт" цагийн цуваа. Цагийн цуврал цаг хугацааны цуврал юм. Хэрэв хоёр цагийн цуваа байгаа бол тэдгээрийг ихэвчлэн холбож, уялдуулах шаардлагатай болдог. Үүнийг бүх өгөгдлийн сан дээр, ялангуяа тэгш бус цаг хугацааны цуваа дээр хийх нь тохиромжгүй: энд зарим цаг хугацааны цэгүүд байна, бусад нь байна. Та дундаж гэж үзэж болно, гэвч гэнэт тэнд нүх байх болно, тиймээс энэ нь тодорхойгүй байна.

Эдгээр шаардлагыг хэрхэн хангаж байгааг харцгаая clickhouse.

Энэ схем

В clickhouse зориулсан схем цагийн цуваа өгөгдлийн тогтмол байдлын зэргээс хамааран янз бүрийн аргаар хийж болно. Бүх хэмжигдэхүүнийг урьдчилан мэдэж байх үед ердийн өгөгдөл дээр системийг бий болгох боломжтой. Жишээлбэл, би үүнийг хийсэн CloudFlare хяналттай CDN сайн оновчтой систем юм. Та бүхэл бүтэн дэд бүтэц, төрөл бүрийн үйлчилгээг хянадаг илүү ерөнхий системийг барьж болно. Тогтмол бус өгөгдлийн хувьд бид юу хянаж байгаагаа урьдчилан мэдэхгүй - энэ нь магадгүй хамгийн түгээмэл тохиолдол юм.

Тогтмол өгөгдөл. Багана. Энэ схем нь энгийн - шаардлагатай төрлүүдтэй баганууд:

CREATE TABLE cpu (
  created_date Date DEFAULT today(),  
  created_at DateTime DEFAULT now(),  
  time String,  
  tags_id UInt32,  /* join to dim_tag */
  usage_user Float64,  
  usage_system Float64,  
  usage_idle Float64,  
  usage_nice Float64,  
  usage_iowait Float64,  
  usage_irq Float64,  
  usage_softirq Float64,  
  usage_steal Float64,  
  usage_guest Float64,  
  usage_guest_nice Float64
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

Энэ бол зарим төрлийн системийг ачаалах үйл ажиллагааг хянадаг ердийн хүснэгт юм (хэрэглэгчийн, систем, сул зогсож байгаа, сайхан). Энгийн бөгөөд тохиромжтой, гэхдээ уян хатан биш. Хэрэв бид илүү уян хатан схемийг хүсч байвал массив ашиглаж болно.

Тогтмол бус өгөгдөл. Массив:

CREATE TABLE cpu_alc (
  created_date Date,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metrics Nested(
    name LowCardinality(String),  
    value Float64
  )
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

SELECT max(metrics.value[indexOf(metrics.name,'usage_user')]) FROM ...

бүтэц Оруулсан хоёр массив байна: хэмжүүр.нэр и хэмжүүр.утга. Энд та үйл явдал бүрийн нэрийн массив, хэмжилтийн массив гэх мэт дур зоргоороо хяналтын өгөгдлийг хадгалах боломжтой. Цаашид оновчтой болгохын тулд нэг ийм бүтцийн оронд та хэд хэдэн зүйлийг хийж болно. Жишээлбэл, нэг нь ° в ° гч-утга, өөр - төлөө INT- учир нь гэсэн үг INT Би илүү үр дүнтэй хадгалахыг хүсч байна.

Гэхдээ ийм бүтцэд хандах нь илүү хэцүү байдаг. Та эхлээд индекс, дараа нь массивын утгыг гаргаж авахын тулд тусгай функцуудыг ашиглан тусгай бүтэц ашиглах шаардлагатай болно.

SELECT max(metrics.value[indexOf(metrics.name,'usage_user')]) FROM ...

Гэхдээ энэ нь маш хурдан ажилладаг хэвээр байна. Тогтмол бус өгөгдлийг хадгалах өөр нэг арга бол мөр юм.

Тогтмол бус өгөгдөл. Мөр. Энэхүү уламжлалт аргаар массивгүйгээр нэр, утгыг нэгэн зэрэг хадгалдаг. Хэрэв нэг төхөөрөмжөөс 5 хэмжилт нэгэн зэрэг ирвэл мэдээллийн санд 000 мөр үүсдэг.

CREATE TABLE cpu_rlc (
  created_date Date,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metric_name LowCardinality(String),  
  metric_value Float64
) ENGINE = MergeTree(created_date, (metric_name, tags_id, created_at), 8192);


SELECT 
    maxIf(metric_value, metric_name = 'usage_user'),
    ... 
FROM cpu_r
WHERE metric_name IN ('usage_user', ...)

clickhouse Үүнийг даван туулж байна - энэ нь тусгай өргөтгөлүүдтэй clickhouse SQL. Жишээлбэл, maxIf — зарим нөхцөл хангагдсан үед дээд хэмжээг хэмжүүрээр тооцдог тусгай функц. Та нэг хүсэлтэд хэд хэдэн ийм илэрхийлэл бичиж, хэд хэдэн хэмжүүрийн утгыг шууд тооцоолж болно.

Гурван аргыг харьцуулж үзье:

мэдээлэл

Энд би зарим туршилтын өгөгдлийн багцад "Дискний өгөгдлийн хэмжээ"-г нэмсэн. Баганын хувьд бид хамгийн бага өгөгдлийн хэмжээтэй байдаг: хамгийн их шахалт, хамгийн их хайлтын хурд, гэхдээ бид бүгдийг нэг дор бүртгэх замаар төлбөр төлдөг.

Массивын хувьд бүх зүйл арай дорддог. Өгөгдөл сайн шахагдсан хэвээр байгаа бөгөөд жигд бус хэв маягийг хадгалах боломжтой. Гэхдээ clickhouse - багана өгөгдлийн сан бөгөөд бид бүх зүйлийг массив дотор хадгалж эхлэхэд энэ нь нэг эгнээ болж хувирдаг бөгөөд бид уян хатан байдлыг үр ашигтайгаар төлдөг. Аливаа үйлдлийн хувьд та массивыг бүхэлд нь санах ойд уншиж, тэндээс хүссэн элементээ олох хэрэгтэй бөгөөд хэрэв массив томрох юм бол хурд нь буурдаг.

Энэ аргыг ашигладаг компаниудын нэгэнд (жишээлбэл, Uber), массивуудыг 128 элементийн хэсэг болгон хуваасан. Өдөрт 200 TB өгөгдөл бүхий хэдэн мянган хэмжүүрээс авсан өгөгдлийг нэг массиваар биш, харин тусгай санах ойн логикоор 10 эсвэл 30 массиваар хадгалдаг.

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

Гибрид схем

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

CREATE TABLE cpu_alc (
  created_date Date,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metrics Nested(
    name LowCardinality(String),  
    value Float64
  ),
  usage_user Float64 
             MATERIALIZED metrics.value[indexOf(metrics.name,'usage_user')],
  usage_system Float64 
             MATERIALIZED metrics.value[indexOf(metrics.name,'usage_system')]
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

Оруулах үед clickhouse тэдгээрийг автоматаар тоолох болно. Ингэснээр та бизнесийг таашаалтай хослуулж чадна: схем нь уян хатан, ерөнхий боловч бид хамгийн их ашиглагддаг багануудыг гаргаж авсан. Энэ нь оруулгыг өөрчлөх шаардлагагүй гэдгийг анхаарна уу ETLЭнэ нь хүснэгтэд массив оруулсаар байна. Бид сая хийсэн Хүснэгтийг өөрчлөх, хэд хэдэн чанга яригч нэмсэн бөгөөд бид эрлийз бөгөөд илүү хурдан схемтэй болсон бөгөөд та үүнийг шууд ашиглаж эхлэх боломжтой.

Кодек ба шахалт

Хэрэгтэй цагийн цуваа Мэдээллийн хэмжээ маш том байж болох тул та өгөгдлийг хэр сайн багцалж байгаа нь чухал юм. IN clickhouse 1:10, 1:20, заримдаа илүү шахалтын үр дүнд хүрэх олон тооны хэрэгслүүд байдаг. Энэ нь дискэн дээрх 1 TB задалсан өгөгдөл 50-100 ГБ эзэлнэ гэсэн үг юм. Жижиг хэмжээ нь сайн, өгөгдлийг хурдан уншиж, боловсруулах боломжтой.

Шахалтын өндөр түвшинд хүрэхийн тулд, clickhouse дараах кодлогчийг дэмждэг:

Жишээ хүснэгт:

CREATE TABLE benchmark.cpu_codecs_lz4 (
    created_date Date DEFAULT today(), 
    created_at DateTime DEFAULT now() Codec(DoubleDelta, LZ4), 
    tags_id UInt32, 
    usage_user Float64 Codec(Gorilla, LZ4), 
    usage_system Float64 Codec(Gorilla, LZ4), 
    usage_idle Float64 Codec(Gorilla, LZ4), 
    usage_nice Float64 Codec(Gorilla, LZ4), 
    usage_iowait Float64 Codec(Gorilla, LZ4), 
    usage_irq Float64 Codec(Gorilla, LZ4), 
    usage_softirq Float64 Codec(Gorilla, LZ4), 
    usage_steal Float64 Codec(Gorilla, LZ4), 
    usage_guest Float64 Codec(Gorilla, LZ4), 
    usage_guest_nice Float64 Codec(Gorilla, LZ4), 
    additional_tags String DEFAULT ''
)
ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

Энд бид кодлогчийг тодорхойлно DoubleDelta нэг тохиолдолд, хоёр дахь нь - Gorilla, мөн бид илүү ихийг нэмэх нь гарцаагүй LZ4 шахалт. Үүний үр дүнд диск дээрх өгөгдлийн хэмжээ ихээхэн багассан:

Энэ нь ижил өгөгдөл хэр их зай эзэлдэг боловч өөр өөр кодлогч, шахалтыг ашиглаж байгааг харуулж байна:

диск дээрх GZIP файлд;
ClickHouse дээр кодлогчгүй, гэхдээ ZSTD шахалттай;
ClickHouse-д LZ4 болон ZSTD кодлогч, шахалттай.

Эндээс харахад кодлогчтой хүснэгтүүд хамаагүй бага зай эзэлдэг.

Хэмжээ нь чухал

Чухал ач холбогдол багатай сонгох зөв өгөгдлийн төрөл:

Дээрх бүх жишээн дээр би ашигласан Хөвөгч64. Гэхдээ бид сонгосон бол Хөвөгч32, тэгвэл энэ нь илүү дээр байх болно. Үүнийг дээр дурдсан нийтлэлд Перконагийн залуус сайн харуулсан. Даалгаварт тохирсон хамгийн авсаархан төрлийг ашиглах нь чухал: асуулгын хурдаас илүү дискний хэмжээ бага. clickhouse үүнд маш мэдрэмтгий.

Хэрэв та ашиглаж чадвал int32 оронд нь int64, дараа нь гүйцэтгэл бараг хоёр дахин өснө гэж найдаж байна. Өгөгдөл нь бага санах ой эзэлдэг бөгөөд бүх "арифметик" илүү хурдан ажилладаг. clickhouse дотооддоо энэ нь маш нарийн бичигдсэн систем бөгөөд орчин үеийн системүүдийн өгч буй бүх боломжийг дээд зэргээр ашигладаг.

Нэгтгэх ба Материалжуулсан үзэгдэл

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

Жишээлбэл, та нэгтгэгдээгүй эх өгөгдөлтэй байж болох бөгөөд та тусгай хөдөлгүүрээр дамжуулан автомат нийлбэрээр төрөл бүрийн материаллаг үзлийг хавсаргаж болно. SummingMergeTree (SMT). SMT нь агрегатуудыг автоматаар тооцдог тусгай нэгтгэсэн өгөгдлийн бүтэц юм. Түүхий өгөгдлийг мэдээллийн санд оруулж, автоматаар нэгтгэж, хяналтын самбарыг үүн дээр шууд ашиглах боломжтой.

TTL - хуучин өгөгдлийг "мартах"

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

CREATE TABLE aggr_by_minute
…
TTL time + interval 1 day

CREATE TABLE aggr_by_day
…
TTL time + interval 30 day

CREATE TABLE aggr_by_week
…
/* no TTL */

Олон давхаргат - өгөгдлийг дискээр хуваах

Энэ санааг цааш нь авч үзвэл өгөгдлийг хадгалах боломжтой clickhouse өөр өөр газар. Бид сүүлийн долоо хоногийн халуун мэдээллийг маш хурдан локал дээр хадгалахыг хүсч байна гэж бодъё SSD, мөн бид өөр газар илүү түүхийн мэдээллийг байрлуулсан. IN clickhouse Энэ нь одоо боломжтой:

Та хадгалах бодлогыг тохируулж болно (хадгалах бодлого) Тэгэхээр clickhouse тодорхой нөхцөлд хүрэхэд автоматаар өгөгдлийг өөр хадгалах сан руу шилжүүлэх болно.

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

CREATE TABLE 
... 
TTL date + INTERVAL 7 DAY TO VOLUME 'cold_volume', 
    date + INTERVAL 180 DAY DELETE

Өвөрмөц боломжууд clickhouse

Бараг бүх зүйлд clickhouse Ийм "онцлох үйл явдлууд" байдаг, гэхдээ тэдгээрийг онцгой байдлаар нөхдөг - бусад мэдээллийн санд байдаггүй зүйл. Жишээлбэл, зарим өвөрмөц онцлогуудыг энд оруулав clickhouse:

Нүднүүд. The clickhouse массивуудад маш сайн дэмжлэг үзүүлэхээс гадна тэдгээрийн дээр нарийн төвөгтэй тооцоолол хийх чадвар.
Мэдээллийн бүтцийг нэгтгэх. Энэ бол "алуурчин шинж чанаруудын" нэг юм. clickhouse. Yandex-ийн залуус бид өгөгдлийг нэгтгэхийг хүсэхгүй байна гэж хэлж байгаа ч бүх зүйлийг нэгтгэсэн болно. clickhouse, учир нь энэ нь хурдан бөгөөд тохиромжтой.
Материалжуулсан үзэл бодол. Өгөгдлийн бүтцийг нэгтгэхтэй хамт материаллаг харагдах байдал нь танд тохиромжтой болгох боломжийг олгодог Бодит цаг нэгтгэх.
ClickHouse SQL. Энэ бол хэлний өргөтгөл юм SQL зарим нэмэлт, онцгой шинж чанаруудыг зөвхөн ашиглах боломжтой clickhouse. Өмнө нь энэ нь нэг талаасаа тэлэлттэй адил, нөгөө талаар сул талтай байсан. Одоо бараг бүх сул талуудтай харьцуулахад SQL 92 Бид үүнийг устгасан, одоо энэ бол зүгээр л өргөтгөл юм.
Lambda- илэрхийллүүд. Тэд ямар нэгэн мэдээллийн санд хэвээр байна уу?
ML- дэмжлэг. Энэ нь өөр өөр мэдээллийн санд байдаг бөгөөд зарим нь илүү сайн, зарим нь илүү муу байдаг.
Нээлттэй эх сурвалж. Бид өргөжүүлж чадна clickhouse хамтдаа. Одоо орлоо clickhouse 500 орчим хувь нэмэр оруулагчид байгаа бөгөөд энэ тоо байнга өссөөр байна.

Муухай асуултууд

В clickhouse ижил зүйлийг хийх олон янзын арга байдаг. Жишээлбэл, та хүснэгтийн сүүлчийн утгыг гурван өөр аргаар буцааж болно CPU-ийн (Дөрөв дэх нь бас байдаг, гэхдээ энэ нь илүү чамин юм).

Эхнийх нь үүнийг хийхэд хэр тохиромжтой болохыг харуулж байна clickhouse Та үүнийг шалгахыг хүссэн үедээ асууна булан дэд асуулгад агуулагдсан. Энэ бол миний хувьд бусад мэдээллийн санд үнэхээр санаж байсан зүйл юм. Хэрэв би ямар нэг зүйлийг дэд асуулгатай харьцуулахыг хүсвэл бусад мэдээллийн санд зөвхөн скалярыг харьцуулж болно, гэхдээ би хэд хэдэн баганад бичих хэрэгтэй. НЭГДЭХ. The clickhouse та tuple ашиглаж болно:

SELECT *
  FROM cpu 
 WHERE (tags_id, created_at) IN 
    (SELECT tags_id, max(created_at)
        FROM cpu 
        GROUP BY tags_id)

Хоёрдахь арга нь ижил зүйлийг хийдэг боловч нэгтгэх функцийг ашигладаг argMax:

SELECT 
    argMax(usage_user), created_at),
    argMax(usage_system), created_at),
...
 FROM cpu

В clickhouse Хэдэн арван нэгтгэсэн функц байдаг бөгөөд хэрэв та комбинатор ашигладаг бол комбинаторикийн хуулиудын дагуу та тэдгээрийн мянга орчимыг авах болно. ArgMax - хамгийн их утгыг тооцдог функцүүдийн нэг: хүсэлт нь утгыг буцаана хэрэглээ_хэрэглэгч, хамгийн их утгад хүрсэн байна үүсгэсэн_цаг:

SELECT now() as created_at,
       cpu.*
  FROM (SELECT DISTINCT tags_id from cpu) base 
  ASOF LEFT JOIN cpu USING (tags_id, created_at)

ASOF NOIN - өөр өөр хугацаатай мөрүүдийг "наах". Энэ нь зөвхөн өгөгдлийн санд байдаг өвөрмөц онцлог юм kdb+. Хэрэв өөр өөр цагтай хоёр цагийн цуваа байгаа бол, ASOF NOIN тэдгээрийг нэг хүсэлтээр зөөж, нэгтгэх боломжийг танд олгоно. Нэг цагийн цувааны утга бүрийн хувьд нөгөө дэх хамгийн ойрын утгыг олох ба тэдгээрийг ижил мөрөнд буцаана.

Аналитик функцууд

Стандартад SQL-2003 Та ингэж бичиж болно:

SELECT origin,
       timestamp,
       timestamp -LAG(timestamp, 1) OVER (PARTITION BY origin ORDER BY timestamp) AS duration,
       timestamp -MIN(timestamp) OVER (PARTITION BY origin ORDER BY timestamp) AS startseq_duration,
       ROW_NUMBER() OVER (PARTITION BY origin ORDER BY timestamp) AS sequence,
       COUNT() OVER (PARTITION BY origin ORDER BY timestamp) AS nb
  FROM mytable
ORDER BY origin, timestamp;

В clickhouse Та үүнийг хийж чадахгүй - энэ нь стандартыг дэмждэггүй SQL-2003 мөн үүнийг хэзээ ч хийхгүй байх магадлалтай. Үүний оронд in clickhouse Ингэж бичдэг заншилтай.

Би ламбда нарт амласан - тэд энд байна!

Энэ нь стандарт дахь аналитик асуулгын аналог юм SQL-2003: тэр хоёрын ялгааг тоолдог цагийн тэмдэг, үргэлжлэх хугацаа, дарааллын тоо - бидний ихэвчлэн аналитик функц гэж үздэг бүх зүйл. IN clickhouse Бид тэдгээрийг массиваар тоолдог: эхлээд бид өгөгдлийг массив болгон задалж, дараа нь массив дээр хүссэн бүхнээ хийж, дараа нь дахин өргөжүүлдэг. Энэ нь тийм ч тохиромжтой биш, хамгийн багадаа функциональ програмчлалыг хайрлахыг шаарддаг, гэхдээ энэ нь маш уян хатан байдаг.

Онцгой шинж чанар

Үүнээс гадна, in clickhouse олон тусгай функцууд. Жишээлбэл, хэд хэдэн хуралдаан зэрэг явагдаж байгааг хэрхэн тодорхойлох вэ? Ердийн хяналтын даалгавар бол нэг хүсэлтээр хамгийн их ачааллыг тодорхойлох явдал юм. IN clickhouse Энэ зорилгоор тусгай функц байдаг:

Ерөнхийдөө ClickHouse нь олон зорилгоор тусгай функцтэй байдаг.

ажиллаж байгаа Ялгаа, ажиллаж байгаа Хуримтлах, хөрш;
sumMap(түлхүүр, утга);
timeSeriesGroupSum(uid, цагийн тэмдэг, утга);
timeSeriesGroupRateSum(uid, цагийн тэмдэг, утга);
skewPop, skewSamp, kurtPop, kurtSamp;
WITH FILL / WITH Зангиатай;
энгийнLinearRegression, stochasticLinearRegression.

Энэ бол функцүүдийн бүрэн жагсаалт биш, нийтдээ 500-600 байна. Зөвлөмж: бүх функцууд clickhouse системийн хүснэгтэд байгаа (бүгд баримтжуулаагүй, гэхдээ бүгд сонирхолтой):

select * from system.functions order by name

clickhouse тэр дундаа өөрийнхөө тухай маш их мэдээллийг хадгалдаг бүртгэлийн хүснэгтүүд, query_log, мөрийн бүртгэл, өгөгдлийн блок бүхий үйлдлийн бүртгэл (хэсэг_лог), хэмжүүрийн бүртгэл болон системийн бүртгэлийг ихэвчлэн диск рүү бичдэг. Лог хэмжүүр нь цагийн цуваа в clickhouse үнэндээ clickhouse: Өгөгдлийн сан нь өөрөө үүрэг гүйцэтгэх боломжтой цагийн цуваа өгөгдлийн сан, ингэснээр өөрийгөө "залгиж" байна.

Энэ нь бас өвөрмөц зүйл юм - бид сайн ажил хийдэг болохоор цагийн цуваа, яагаад бид өөрт хэрэгтэй бүхнээ өөртөө хадгалж чаддаггүй юм бэ? Бидэнд хэрэггүй Prometheus, бид бүх зүйлийг өөртөө хадгалдаг. Холбогдсон Графана мөн бид өөрсдийгөө хянадаг. Гэсэн хэдий ч хэрэв clickhouse уналтанд орвол бид яагаад гэдгийг олж харахгүй, тиймээс тэд ихэвчлэн тэгдэггүй.

Том кластер эсвэл олон жижиг clickhouse

Аль нь дээр вэ - нэг том кластер эсвэл олон жижиг ClickHouses уу? Уламжлалт хандлага DWH нь хэрэглээ бүрт хэлхээг хуваарилсан том кластер юм. Бид өгөгдлийн сангийн администратор дээр ирсэн - бидэнд диаграм өг, тэд бидэнд нэгийг өгсөн:

В clickhouse та өөрөөр хийж болно. Та програм бүрийг өөрийн гараар хийж болно clickhouse:

Бидэнд том аймшигт амьтан хэрэггүй болсон DWH болон хэцүү админууд. Бид програм тус бүрийг тус тусад нь өгөх боломжтой clickhouse, мөн хөгжүүлэгч өөрөө үүнийг хийж чадна, оноос хойш clickhouse суулгахад маш хялбар бөгөөд нарийн төвөгтэй удирдлага шаарддаггүй:

Гэхдээ бидэнд маш их байвал clickhouse, мөн та үүнийг байнга суулгах хэрэгтэй бол энэ үйл явцыг автоматжуулахыг хүсч байна. Үүний тулд бид жишээ нь ашиглаж болно Kubernetes и clickhouse- оператор. IN Kubernetes ClickHouse Та үүнийг "товшилт дээр" тавьж болно: Би товчлуур дээр дарж, манифестыг ажиллуулж, мэдээллийн сан бэлэн болсон. Би нэн даруй диаграмм үүсгэж, тэнд хэмжүүрүүдийг байршуулж эхлэх бөгөөд 5 минутын дараа би хяналтын самбар бэлэн болно Графана. Энэ маш энгийн!

Эцсийн эцэст юу вэ?

Тэгэхээр clickhouse - энэ бол:

Быстро. Үүнийг хүн бүр мэддэг.
Зүгээр л. Бага зэрэг маргаантай, гэхдээ бэлтгэл хийхэд хэцүү, тулалдаанд амархан гэдэгт би итгэдэг. Хэрэв та хэрхэн ойлгож байгаа бол clickhouse энэ нь ажилладаг, тэгвэл бүх зүйл маш энгийн.
Бүх нийтийн хувьд. Энэ нь янз бүрийн хувилбаруудад тохиромжтой: DWH, Time Series, Log Storage. Гэхдээ тийм биш OLTP мэдээллийн сан, тиймээс тэнд богино оруулга, уншихыг бүү оролдоорой.
Сонирхолтой. Хамт ажилладаг хүн байх clickhouse, сайн муу утгаараа олон сонирхолтой мөчүүдийг туулсан. Жишээлбэл, шинэ хувилбар гарсан, бүх зүйл ажиллахаа больсон. Эсвэл та хоёр өдрийн турш нэг даалгавартай тэмцэж байсан ч Telegram чатаар асуулт асуусны дараа хоёр минутын дотор даалгавар шийдэгдсэн. Эсвэл Леша Миловидовын илтгэл дээр бага хурал дээр байгаа шиг, дэлгэцийн зураг clickhouse нэвтрүүлгийг таслав Өндөр ачаалал ++. Иймэрхүү зүйл байнга тохиолддог бөгөөд бидний амьдралыг хүндрүүлдэг. clickhouse тод, сонирхолтой!

Та танилцуулгыг үзэж болно энд.

Өндөр ачаалалтай систем хөгжүүлэгчдийн удаан хүлээсэн уулзалт Өндөр ачаалал ++ 9-р сарын 10, XNUMX-нд Сколковод болно. Эцэст нь, HighLoad++-ийн энергийг онлайнаар багцлах боломжгүй тул энэ нь офлайн хурал болно (бүх урьдчилан сэргийлэх арга хэмжээ авсан ч гэсэн).

Хуралд зориулж бид технологийн дээд зэргийн чадавхитай холбоотой тохиолдлуудыг олж, үзүүлж байна: HighLoad++ нь Facebook, Yandex, VKontakte, Google, Amazon хэрхэн ажилладагийг хоёр өдрийн дотор мэдэх боломжтой цорын ганц газар байсан, одоо ч байх болно.

2007 оноос хойш тасралтгүй хуралдаж ирсэн бид энэ жил 14 дэх удаагаа хуралдах гэж байна. Энэ хугацаанд чуулган 10 дахин өргөжин тэлж, өнгөрсөн жил салбарын гол арга хэмжээ нь 3339 оролцогч, 165 илтгэгч, илтгэл, уулзалтуудыг цуглуулж, 16 трек нэгэн зэрэг явагдаж байв.
Өнгөрсөн онд 20 автобус, 5280 литр цай, кофе, 1650 литр жимсний ундаа, 10200 шил устай байсан. Бас 2640 кг хоол, 16 мянган таваг, 000 мянган аяга. Дашрамд хэлэхэд, дахин боловсруулсан цааснаас цуглуулсан мөнгөөр 25 ширхэг царс модны суулгац тарьсан :)

Та тасалбар худалдаж авах боломжтой энд, хурлын талаар мэдээ авах - энд, мөн бүх нийгмийн сүлжээн дээр ярих: цахилгаан, Facebook-ийн, Vkontakte и Twitter.

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

ClickHouse руу шилжих: 3 жилийн дараа