Сүүлийн хэдэн жилийн хугацаанд цаг хугацааны цуврал мэдээллийн сан нь хачирхалтай зүйлээс (нээлттэй хяналтын системд (мөн тодорхой шийдлүүдтэй холбоотой) эсвэл Big Data төслүүдэд ашигладаг өндөр мэргэшсэн) "хэрэглээний бүтээгдэхүүн" болж хувирсан. ОХУ-ын нутаг дэвсгэр дээр Yandex болон ClickHouse-д онцгой талархал илэрхийлэх ёстой. Энэ хүртэл, хэрэв та цаг хугацааны цуврал өгөгдлийг их хэмжээгээр хадгалах шаардлагатай бол аймшигт Hadoop стек барьж, түүнийгээ хадгалах, эсвэл систем тус бүрийн протоколуудтай харилцах шаардлагатай болсон.
2019 онд TSDB-г ашиглах нь зүйтэй гэсэн нийтлэл нь зөвхөн нэг өгүүлбэрээс бүрдэх бололтой: "Зүгээр л ClickHouse-г ашигла." Гэхдээ ... нюансууд байдаг.
Үнэн хэрэгтээ ClickHouse идэвхтэй хөгжиж, хэрэглэгчийн бааз нэмэгдэж, дэмжлэг маш идэвхтэй байгаа ч бид бусад, магадгүй илүү үр дүнтэй/найдвартай шийдлүүдийг дарж чадсан ClickHouse-ийн олон нийтийн амжилтын барьцаанд орсон уу?
Өнгөрсөн оны эхээр бид өөрсдийн хяналтын системийг дахин боловсруулж эхэлсэн бөгөөд энэ үеэр өгөгдөл хадгалахад тохиромжтой мэдээллийн санг сонгох тухай асуулт гарч ирэв. Би энд энэ сонголтын түүхийн талаар ярихыг хүсч байна.
Асуудлын тодорхойлолт
Юуны өмнө шаардлагатай оршил. Бидэнд яагаад өөрийн хяналтын систем хэрэгтэй байна вэ, үүнийг хэрхэн зохион бүтээсэн бэ?
Бид 2008 онд дэмжлэг үзүүлэх үйлчилгээг үзүүлж эхэлсэн бөгөөд 2010 он гэхэд үйлчлүүлэгчийн дэд бүтцэд болж буй үйл явцын талаарх мэдээллийг тухайн үед байсан шийдлүүдтэй нэгтгэхэд хэцүү болсон нь тодорхой болсон (бид Бурхан намайг өршөөгөөч, Какти, Заббиксын тухай ярьж байна) болон шинээр гарч ирж буй графит).
Бидний гол шаардлага нь:
- нэг систем дэх үйлчлүүлэгчдийг дэмжих (тэр үед - хэдэн арван, ирээдүйд - олон зуун) үйлчлүүлэгчид, нэгэн зэрэг төвлөрсөн дохиоллын удирдлагын системтэй байх;
- дохиоллын системийг удирдах уян хатан байдал (жижүүрийн хоорондох сэрэмжлүүлгийг нэмэгдүүлэх, хуваарь, мэдлэгийн сан);
- графикийг гүнзгий нарийвчлан гаргах чадвар (Заббикс тухайн үед графикийг зураг хэлбэрээр үзүүлсэн);
- их хэмжээний өгөгдөл (нэг жил ба түүнээс дээш) урт хугацааны хадгалалт, түүнийг хурдан сэргээх чадвар.
Энэ нийтлэлд бид сүүлчийн цэгийг сонирхож байна.
Хадгалалтын тухай ярихад дараахь шаардлага тавигдсан.
- систем хурдан ажиллах ёстой;
- систем нь SQL интерфейстэй байх нь зүйтэй юм;
- систем нь тогтвортой, идэвхтэй хэрэглэгчийн бааз, дэмжлэгтэй байх ёстой (нэг удаа бид хөгжөөгүй байгаа MemcacheDB, эсвэл алдаа хянагч нь хятад хэл дээр хадгалагдсан MooseFS түгээлтийн санах ой зэрэг системийг дэмжих хэрэгцээтэй тулгарсан: Бид энэ түүхийг төслийнхөө төлөө давтахыг хүсээгүй);
- CAP теоремыг дагаж мөрдөх: Тохиромжтой байдал (шаардлагатай) - өгөгдөл нь шинэчлэгдсэн байх ёстой, бид сэрэмжлүүлгийн удирдлагын систем нь шинэ мэдээлэл хүлээн авахгүй байх, бүх төслүүдэд өгөгдөл ирэхгүй байх тухай сэрэмжлүүлэг гаргахыг хүсэхгүй байна; Хуваалтын хүлцэл (шаардлагатай) - бид Split Brain системийг авахыг хүсэхгүй байна; Бэлэн байдал (хэрэв идэвхтэй хуулбар байгаа бол чухал биш) - бид ослын үед код ашиглан нөөцлөх систем рүү өөрсдөө шилжиж болно.
Хачирхалтай нь, тэр үед MySQL нь бидний хувьд хамгийн тохиромжтой шийдэл болж хувирсан. Бидний өгөгдлийн бүтэц маш энгийн байсан: серверийн ID, тоолуурын ID, цагийн тэмдэг, утга; Халуун өгөгдлийн хурдан түүвэрлэлтийг том буферийн сан, түүхийн өгөгдлийн түүврийг SSD-ээр хангасан.
Тиймээс бид хоёр долоо хоногийн шинэ өгөгдлийн дээжийг олж авсан бөгөөд өгөгдлийг бүрэн үзүүлэхээс секундын 200 мс хүртэл нарийвчлалтай болгож, энэ системд нэлээд удаан амьдарсан.
Үүний зэрэгцээ цаг хугацаа өнгөрч, мэдээллийн хэмжээ нэмэгдэв. 2016 он гэхэд өгөгдлийн хэмжээ хэдэн арван терабайт болсон бөгөөд энэ нь түрээсийн SSD хадгалалтын хүрээнд ихээхэн зардал болсон юм.
Энэ үед багана мэдээллийн сангууд идэвхтэй тархаж, бидний идэвхтэй бодож эхэлсэн: багана мэдээллийн санд өгөгдөл нь таны ойлгож байгаагаар багана хэлбэрээр хадгалагддаг бөгөөд хэрэв та бидний өгөгдлийг харвал том хэмжээтэй байхыг харахад хялбар байдаг. Хэрэв та багана хэлбэрийн өгөгдлийн сан ашиглаж байгаа бол түүнийг шахах замаар шахаж болох давхардлын тоо.
Гэсэн хэдий ч компанийн гол систем тогтвортой ажиллаж байсан тул би өөр зүйл рүү шилжих туршилт хийхийг хүсээгүй.
2017 онд Сан Хосе хотод болсон Percona Live бага хурал дээр Clickhouse хөгжүүлэгчид анх удаа өөрсдийгөө зарласан байх. Эхлээд харахад систем нь үйлдвэрлэлд бэлэн байсан (за, Yandex.Metrica бол хатуу ширүүн үйлдвэрлэлийн систем), дэмжлэг нь хурдан бөгөөд энгийн, хамгийн чухал нь үйл ажиллагаа нь энгийн байсан. 2018 оноос хойш бид шилжилтийн үйл явцыг эхлүүлсэн. Гэхдээ тэр үед "насанд хүрэгчдийн" болон цаг хугацаагаар туршсан TSDB системүүд маш их байсан бөгөөд бидний шаардлагын дагуу Clickhouse-аас өөр шийдэл байхгүй эсэхийг шалгахын тулд бид нэлээд цаг зарцуулж, өөр хувилбаруудыг харьцуулахаар шийдсэн.
Өмнө нь тодорхойлсон хадгалах шаардлагуудаас гадна шинэ зүйлүүд гарч ирэв.
- шинэ систем нь ижил хэмжээний техник хангамж дээр MySQL-тэй ижил гүйцэтгэлийг хангах ёстой;
- шинэ системийг хадгалах нь хамаагүй бага зай эзэлнэ;
- DBMS нь удирдахад хялбар хэвээр байх ёстой;
- Би DBMS-ийг өөрчлөхдөө програмыг хамгийн бага хэмжээгээр өөрчлөхийг хүссэн.
Бид ямар системийг авч үзэж эхэлсэн бэ?
Apache Hive/Apache Impala
Хуучин, тулалдаанд туршиж үзсэн Hadoop стек. Үндсэндээ энэ нь HDFS дээр өгөгдлийг эх форматаар хадгалах дээр суурилсан SQL интерфейс юм.
Давуу тал.
- Тогтвортой ажиллагаатай бол өгөгдлийг масштаблахад маш хялбар байдаг.
- Мэдээлэл хадгалах баганын шийдлүүд байдаг (зай бага).
- Нөөц боломжтой үед зэрэгцээ даалгавруудыг маш хурдан гүйцэтгэх.
Cons
- Энэ бол Hadoop бөгөөд ашиглахад хэцүү. Хэрэв бид үүлэн дээр бэлэн шийдлийг авахад бэлэн биш байгаа бол (мөн зардлын хувьд бид бэлэн биш бол) бүх стекийг админуудын гараар угсарч, дэмжих шаардлагатай болно, бид үнэхээр хүсэхгүй байна. энэ.
- Өгөгдлийг нэгтгэсэн .
Гэсэн хэдий ч:
Тооцоолох серверүүдийн тоог нэмэгдүүлэх замаар хурдыг олж авдаг. Энгийнээр хэлэхэд, хэрэв бид аналитикийн чиглэлээр ажилладаг томоохон компани бөгөөд бизнест мэдээллийг аль болох хурдан нэгтгэх нь чухал юм (их хэмжээний тооцоолох нөөцийг ашиглах зардлаар ч гэсэн) энэ нь бидний сонголт байж магадгүй юм. Гэхдээ бид даалгавраа хурдасгахын тулд техник хангамжийн флотыг нэмэгдүүлэхэд бэлэн биш байсан.
Друид/Пинот
TSDB-ийн талаар илүү их зүйл байдаг, гэхдээ дахин Hadoop стек.
Байдаг .
Цөөн үгээр хэлбэл: Druid/Pinot дараах тохиолдолд Clickhouse-аас илүү харагддаг.
- Та өгөгдлийн янз бүрийн шинж чанартай байдаг (бидний хувьд бид зөвхөн серверийн хэмжигдэхүүнүүдийн цагийн цувааг бүртгэдэг бөгөөд үнэн хэрэгтээ энэ нь нэг хүснэгт юм. Гэхдээ өөр тохиолдол байж болно: тоног төхөөрөмжийн цагийн цуваа, эдийн засгийн цагийн цуврал гэх мэт. - тус бүр нь нэгтгэх, боловсруулах шаардлагатай өөрийн бүтэц).
- Түүгээр ч барахгүй энэ тоо баримт маш их байдаг.
- Хугацааны цуваа бүхий хүснэгт, өгөгдөл гарч ирэх ба алга болно (өөрөөр хэлбэл зарим багц өгөгдөл ирсэн, дүн шинжилгээ хийж, устгасан).
- Өгөгдлийг хуваах тодорхой шалгуур байхгүй.
Эсрэг тохиолдолд ClickHouse илүү сайн ажилладаг бөгөөд энэ нь бидний тохиолдол юм.
clickhouse
- SQL шиг
- Удирдахад хялбар.
- Хүмүүс үүнийг ажилладаг гэж хэлдэг.
Туршилтын жагсаалтад багтдаг.
InfluxDB
ClickHouse-ийн гадаад хувилбар. Сул талуудаас: Өндөр хүртээмж нь зөвхөн арилжааны хувилбарт байдаг, гэхдээ үүнийг харьцуулах шаардлагатай.
Туршилтын жагсаалтад багтдаг.
Кассандра
Нэг талаас, үүнийг жишээ нь, хяналтын системээр хэмжигдэхүүн цагийн цувааг хадгалахад ашигладаг гэдгийг бид мэднэ. эсвэл OkMeter. Гэсэн хэдий ч тодорхой зүйлүүд байдаг.
Кассандра бол уламжлалт утгаараа багана мэдээллийн сан биш юм. Энэ нь мөрийн харагдацтай илүү төстэй боловч мөр бүр өөр өөр тооны баганатай байж болох тул багана дүрсийг зохион байгуулахад хялбар болгодог. Энэ утгаараа 2 тэрбум баганын хязгаартай бол зарим өгөгдлийг баганад (мөн ижил хугацааны цуваа) хадгалах боломжтой нь тодорхой байна. Жишээлбэл, MySQL-д 4096 баганын хязгаарлалт байдаг бөгөөд хэрэв та үүнийг хийх гэж оролдвол 1117 кодтой алдаа гарахад амархан байдаг.
Кассандра хөдөлгүүр нь их хэмжээний өгөгдлийг мастергүйгээр тархсан системд хадгалахад чиглэгддэг бөгөөд дээр дурдсан Кассандра CAP теорем нь AP-ын тухай, өөрөөр хэлбэл өгөгдлийн хүртээмж, хуваагдалд тэсвэртэй байдлын тухай юм. Тиймээс, хэрэв та зөвхөн энэ мэдээллийн санд бичих шаардлагатай бөгөөд үүнээс ховор уншдаг бол энэ хэрэгсэл маш сайн байх болно. Энд Кассандраг "хүйтэн" агуулах болгон ашиглах нь логик юм. Энэ нь ховор хэрэгцээтэй боловч шаардлагатай бол буцааж авах боломжтой их хэмжээний түүхийн өгөгдлийг хадгалах урт хугацааны найдвартай газар юм. Гэсэн хэдий ч бүрэн гүйцэд байлгахын тулд бид үүнийг бас туршиж үзэх болно. Гэхдээ өмнө нь хэлсэнчлэн, сонгосон өгөгдлийн сангийн шийдлийн кодыг идэвхтэй дахин бичих хүсэл байхгүй тул бид өгөгдлийн сангийн бүтцийг Кассандрагийн онцлогт тохируулан өөрчлөхгүйгээр тодорхой хэмжээгээр туршиж үзэх болно.
Prometheus
За, сониуч зандаа бид Prometheus хадгалах сангийн гүйцэтгэлийг туршихаар шийдсэн - бид одоогийн шийдлүүдээс илүү хурдан эсвэл удаан уу, мөн хэр хэмжээгээр гэдгийг ойлгохын тулд.
Туршилтын арга зүй, үр дүн
Тиймээс бид 5 мэдээллийн санг дараах 6 тохиргоонд туршиж үзсэн: ClickHouse (1 зангилаа), ClickHouse (3 зангилааны хуваарилагдсан хүснэгт), InfluxDB, Mysql 8, Cassandra (3 зангилаа) болон Prometheus. Туршилтын төлөвлөгөө дараах байдалтай байна.
- долоо хоногийн турш түүхэн өгөгдлийг байршуулах (өдөрт 840 сая утга; 208 мянган хэмжүүр);
- бид бичлэгийн ачааллыг үүсгэдэг (ачааллын 6 горимыг авч үзсэн, доороос үзнэ үү);
- Бичлэг хийхтэй зэрэгцэн бид графиктай ажиллаж буй хэрэглэгчийн хүсэлтийг дуурайлган үе үе сонголт хийдэг. Хэт их хүндрэл учруулахгүйн тулд бид долоо хоногийн турш 10 хэмжигдэхүүнээр (CPU график дээр яг хэдэн тоо байгаа) өгөгдлийг сонгосон.
Бид хэмжигдэхүүн бүрт 15 секунд тутамд утгыг илгээдэг хяналтын агентынхаа зан төлөвийг дуурайж ачаалдаг. Үүний зэрэгцээ бид дараахь зүйлийг сонирхож байна.
- өгөгдөл бичигдсэн хэмжүүрүүдийн нийт тоо;
- утгыг нэг хэмжигдэхүүн рүү илгээх интервал;
- багцын хэмжээ.
Багцын хэмжээний тухай. Бараг бүх туршилтын мэдээллийн сангуудыг нэг оруулгатай ачаалахыг зөвлөдөггүй тул бидэнд ирж буй хэмжигдэхүүнүүдийг цуглуулж, тэдгээрийг бүлэг болгон нэгтгэж мэдээллийн санд багц оруулга болгон бичдэг реле хэрэгтэй болно.
Түүнчлэн, хүлээн авсан өгөгдлийг хэрхэн яаж тайлбарлахыг илүү сайн ойлгохын тулд бид зөвхөн олон тооны хэмжигдэхүүнүүдийг илгээгээд зогсохгүй хэмжүүрүүдийг сервер болгон зохион байгуулдаг гэж төсөөлөөд үз дээ - нэг серверт 125 хэмжүүр. Энд сервер бол зүгээр л виртуал байгууллага бөгөөд жишээлбэл, 10000 хэмжигдэхүүн нь 80 орчим сервертэй тохирч байгааг ойлгоход л хангалттай.
Энэ бүхнийг харгалзан үзэхэд манай мэдээллийн сангийн бичих ачааллын 6 горим байна:
Энд хоёр цэг байна. Нэгдүгээрт, Кассандрагийн хувьд эдгээр багцын хэмжээ хэтэрхий том болсон тул бид 50 эсвэл 100 утгыг ашигласан. Хоёрдугаарт, Прометей нь татах горимд хатуу ажилладаг тул, өөрөөр хэлбэл. Энэ нь өөрөө явж, хэмжигдэхүүнүүдийн эх сурвалжаас мэдээлэл цуглуулдаг (мөн түлхэх гарц нь ч гэсэн нэрийг нь үл харгалзан нөхцөл байдлыг эрс өөрчилдөггүй), холбогдох ачааллыг статик тохиргооны хослолоор хэрэгжүүлсэн.
Туршилтын үр дүн дараах байдалтай байна.
Юуг тэмдэглэх нь зүйтэй: Prometheus-ийн гайхалтай хурдан дээжүүд, Кассандрагийн маш удаан дээжүүд, InfluxDB-ийн хүлээн зөвшөөрөгдөөгүй удаан дээжүүд; Бичлэгийн хурдны хувьд ClickHouse хүн бүрийг ялсан бөгөөд Prometheus тэмцээнд оролцдоггүй, учир нь энэ нь өөрөө оруулга хийдэг бөгөөд бид юу ч хэмждэггүй.
Үүний үр дүнд,: ClickHouse болон InfluxDB нь өөрсдийгөө хамгийн шилдэг нь гэдгээ харуулсан боловч Influx-ийн кластерийг зөвхөн Enterprise хувилбар дээр үндэслэн байгуулах боломжтой бөгөөд энэ нь мөнгө шаарддаг бол ClickHouse нь Орост үйлдвэрлэсэн зардал багатай байдаг. АНУ-д сонголт нь inInfluxDB, харин манайд ClickHouse-ийн талд байгаа нь логик юм.
Эх сурвалж: www.habr.com