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