Бид Zabbix нь TimescaleDB мэдээллийн сантай хэрхэн ажилладаг талаар авч үзэх болно. Бид танд хэрхэн эхнээс нь эхлэх, PostgreSQL-ээс хэрхэн шилжихийг харуулах болно. Мөн бид хоёр тохиргооны гүйцэтгэлийн харьцуулсан туршилтуудыг өгөх болно.
HighLoad++ Сибирь 2019. Томскийн танхим. 24-р сарын 16, 00:XNUMX. Дипломууд болон . Дараагийн HighLoad++ бага хурал 6 оны 7-р сарын 2020, XNUMX-ны өдрүүдэд Санкт-Петербург хотод болно. Дэлгэрэнгүй мэдээлэл, тасалбар .
Андрей Гущин (цаашид - AG): – Би ZABBIX техникийн дэмжлэг үзүүлэх инженер (цаашид “Заббикс” гэх) сургагч багш. Би техникийн туслалцааны чиглэлээр 6 жил гаруй ажиллаж байгаа бөгөөд гүйцэтгэлийн талаар шууд туршлагатай. Өнөөдөр би TimescaleDB нь ердийн PostgreSQL 10-тай харьцуулахад үзүүлж чадах гүйцэтгэлийн талаар ярих болно. Мөн энэ нь ерөнхийдөө хэрхэн ажилладаг талаар танилцуулах хэсэг юм.
Бүтээмжийн гол сорилтууд: өгөгдөл цуглуулахаас эхлээд өгөгдлийг цэвэрлэх хүртэл
Эхлэхийн тулд, хяналтын систем бүрт тулгардаг гүйцэтгэлийн тодорхой сорилтууд байдаг. Бүтээмжийн эхний сорилт бол өгөгдлийг хурдан цуглуулах, боловсруулах явдал юм.
Сайн хяналтын систем нь бүх өгөгдлийг хурдан, цаг тухайд нь хүлээн авч, триггер илэрхийллийн дагуу боловсруулж, өөрөөр хэлбэл зарим шалгуурын дагуу (өөр өөр системд энэ нь өөр байдаг) боловсруулж, мэдээллийн санд хадгалах ёстой. ирээдүй.
Гүйцэтгэлийн хоёр дахь сорилт бол түүхийг хадгалах явдал юм. Мэдээллийн санд байнга хадгалж, тодорхой хугацаанд цуглуулсан эдгээр хэмжигдэхүүнүүдэд хурдан бөгөөд хялбар хандах боломжтой. Хамгийн чухал зүйл бол энэ өгөгдлийг олж авах, тайлан, график, триггер, зарим босго утга, сэрэмжлүүлэг гэх мэт ашиглахад тохиромжтой.
Гүйцэтгэлийн гурав дахь сорилт бол түүхийг цэвэрлэх явдал юм, өөрөөр хэлбэл та 5 жил (сар, хоёр сар ч гэсэн) цуглуулсан дэлгэрэнгүй хэмжүүрүүдийг хадгалах шаардлагагүй болсон үед. Зарим сүлжээний зангилаа устгагдсан, эсвэл зарим хостууд, хэмжигдэхүүнүүд нь аль хэдийн хуучирсан бөгөөд цуглуулагдахаа больсон. Таны мэдээллийн сан хэт томрохгүйн тулд энэ бүгдийг цэвэрлэх хэрэгтэй. Ерөнхийдөө түүхийг цэвэрлэх нь ихэвчлэн хадгалалтын хувьд ноцтой сорилт болдог - энэ нь гүйцэтгэлд маш хүчтэй нөлөө үзүүлдэг.
Кэшийн асуудлыг хэрхэн шийдвэрлэх вэ?
Би одоо Zabbix-ийн талаар тусгайлан ярих болно. Zabbix-д эхний болон хоёр дахь дуудлагыг кэш ашиглан шийддэг.
Мэдээлэл цуглуулах, боловсруулах - Бид энэ бүх өгөгдлийг хадгалахын тулд RAM ашигладаг. Эдгээр өгөгдлийг одоо илүү дэлгэрэнгүй авч үзэх болно.
Мөн өгөгдлийн сангийн тал дээр үндсэн сонголтууд болох график болон бусад зүйлсийн зарим кэш байдаг.
Zabbix серверийн хажуу талд кэш хийх: бидэнд ConfigurationCache, ValueCache, HistoryCache, TrendsCache байна. Энэ юу вэ?
ConfigurationCache нь бидний хэмжүүр, хост, өгөгдлийн зүйл, триггерүүдийг хадгалах үндсэн кэш юм; Урьдчилан боловсруулалт хийх, өгөгдөл цуглуулах, аль хостоос ямар давтамжтайгаар цуглуулах зэрэгт хэрэгтэй бүх зүйл. Мэдээллийн сан руу орж шаардлагагүй асуулга үүсгэхгүйн тулд энэ бүгдийг ConfigurationCache-д хадгалдаг. Сервер ажиллаж эхэлсний дараа бид энэ кэшийг шинэчилж (үүнийг бий болгож), үе үе шинэчилдэг (тохиргооны тохиргооноос хамааран).
Zabbix дээр кэш хийх. Өгөгдөл цуглуулах
Энд диаграм нь нэлээд том байна:
Схемийн гол нь эдгээр цуглуулагчид юм.
Эдгээр нь угсралтын процессууд, янз бүрийн төрлийн угсралтыг хариуцдаг янз бүрийн "санал авагчид" юм. Тэд icmp, ipmi болон төрөл бүрийн протоколуудаар дамжуулан өгөгдлийг цуглуулж, бүгдийг нь урьдчилан боловсруулахад шилжүүлдэг.
Урьдчилан боловсруулалтын түүхийн кэш
Мөн хэрэв бид тооцоолсон өгөгдлийн элементүүдтэй (Zabbix-ийг мэддэг хүмүүс мэддэг), өөрөөр хэлбэл тооцоолсон, нэгтгэсэн өгөгдлийн элементүүдтэй бол бид тэдгээрийг ValueCache-ээс шууд авдаг. Хэрхэн дүүргэхийг би дараа нь хэлье. Эдгээр бүх цуглуулагчид ConfigurationCache ашиглан ажлаа хүлээн авч, дараа нь урьдчилсан боловсруулалтад шилжүүлдэг.
Урьдчилан боловсруулах нь мөн ConfigurationCache-г ашиглан урьдчилсан боловсруулалтын үе шатуудыг авч, энэ өгөгдлийг янз бүрийн аргаар боловсруулдаг. 4.2 хувилбараас эхлэн бид үүнийг прокси руу шилжүүлсэн. Энэ нь маш тохиромжтой, учир нь урьдчилан боловсруулах нь өөрөө нэлээд хэцүү ажиллагаа юм. Хэрэв танд маш том Zabbix байгаа бол олон тооны өгөгдлийн элемент, цуглуулах давтамж өндөр байвал энэ нь ажлыг ихээхэн хөнгөвчлөх болно.
Үүний дагуу бид урьдчилан боловсруулалтыг ашиглан энэ өгөгдлийг ямар нэгэн байдлаар боловсруулсны дараа бид үүнийг цаашид боловсруулахын тулд HistoryCache-д хадгалдаг. Энэ нь мэдээлэл цуглуулах ажлыг дуусгаж байна. Бид үндсэн процесс руу шилждэг.
Түүхийн синхрончлолын ажил
Zabbix-ийн үндсэн процесс (энэ нь цул архитектур учраас) Түүхийн синхрончлол юм. Энэ нь өгөгдлийн элемент бүрийн атомын боловсруулалтыг тусгайлан авч үздэг гол процесс, өөрөөр хэлбэл утга тус бүрийн:
- утга ирдэг (энэ нь HistoryCache-ээс авдаг);
- Тохиргооны синхрончлолыг шалгана: тооцоолол хийх өдөөгч байгаа эсэхийг - тэдгээрийг тооцоолно;
хэрэв байгаа бол - тохиргооны дагуу шаардлагатай бол сэрэмжлүүлэг үүсгэхийн тулд үйл явдлуудыг бий болгож, өсөлтийг бий болгодог; - дараагийн боловсруулалт, нэгтгэх өдөөлтийг бүртгэдэг; хэрэв та сүүлийн нэг цаг гэх мэтийг нэгтгэвэл түүхийн хүснэгт рүү орохгүйн тулд энэ утгыг ValueCache санах болно; Тиймээс ValueCache нь өдөөгч, тооцоолсон элементүүд гэх мэтийг тооцоолоход шаардлагатай шаардлагатай мэдээллээр дүүрдэг;
- дараа нь History syncer нь бүх өгөгдлийг мэдээллийн санд бичдэг;
- өгөгдлийн сан нь тэдгээрийг диск рүү бичдэг - энд боловсруулалтын процесс дуусдаг.
Өгөгдлийн сан. Кэш хийх
Өгөгдлийн сангийн тал дээр та график эсвэл үйл явдлын зарим тайланг үзэхийг хүсвэл янз бүрийн кэшүүд байдаг. Гэхдээ энэ тайланд би тэдний талаар ярихгүй.
MySQL-ийн хувьд Innodb_buffer_pool, мөн тохируулж болох өөр өөр кэшүүд байдаг.
Гэхдээ эдгээр нь гол зүйлүүд юм:
- хуваалцсан_буфер;
- үр дүнтэй_кэшийн_хэмжээ;
- хуваалцсан_цөөрөм.
Бүх өгөгдлийн сангийн хувьд асуулгад ихэвчлэн шаардлагатай өгөгдлийг RAM-д хадгалах боломжийг олгодог тодорхой кэшүүд байдаг гэж би хэлсэн. Тэд үүнд зориулж өөрийн гэсэн технологитой.
Өгөгдлийн сангийн гүйцэтгэлийн тухай
Үүний дагуу өрсөлдөөнт орчин бий, өөрөөр хэлбэл Zabbix сервер нь өгөгдлийг цуглуулж, бүртгэдэг. Дахин эхлүүлэх үед энэ нь ValueCache-г дүүргэхийн тулд түүхээс уншина гэх мэт. Энд та вэб интерфэйс дээр бүтээгдсэн Zabbix API-г ашигладаг скриптүүд болон тайлангуудтай байж болно. Zabbix API нь мэдээллийн санд нэвтэрч, график, тайлан эсвэл зарим төрлийн үйл явдлын жагсаалт, сүүлийн үеийн асуудлуудыг олж авахад шаардлагатай өгөгдлийг хүлээн авдаг.
Мөн маш алдартай дүрслэлийн шийдэл бол манай хэрэглэгчдийн ашигладаг Grafana юм. Zabbix API болон мэдээллийн баазаар дамжуулан шууд нэвтрэх боломжтой. Энэ нь мөн өгөгдөл олж авах тодорхой өрсөлдөөнийг бий болгодог: үр дүн, туршилтыг хурдан хүргэхийн тулд мэдээллийн санг илүү нарийн, илүү сайн тохируулах шаардлагатай.
Түүхийг цэвэрлэж байна. Заббикс гэрийн үйлчлэгчтэй
Zabbix-д ашигладаг гурав дахь дуудлага бол Housekeeper ашиглан түүхийг цэвэрлэх явдал юм. Гэрийн үйлчлэгч нь бүх тохиргоог дагаж мөрддөг, өөрөөр хэлбэл манай өгөгдлийн элементүүд нь хэр удаан хадгалах (өдөрөөр), чиг хандлагыг хэр удаан хадгалах, өөрчлөлтийн динамикийг заадаг.
Бид шууд тооцоолдог TrendCache-ийн талаар би яриагүй: өгөгдөл ирдэг, бид үүнийг нэг цагийн турш нэгтгэдэг (ихэвчлэн эдгээр нь сүүлийн нэг цагийн тоонууд), дүн нь дундаж/хамгийн бага бөгөөд бид үүнийг цагт нэг удаа бүртгэдэг. өөрчлөлтийн динамикийн хүснэгт ("Тренд"). "Гэрийн ажилтан" нь ердийн сонголтуудыг ашиглан мэдээллийн сангаас өгөгдлийг эхлүүлж устгадаг бөгөөд энэ нь үргэлж үр дүнтэй байдаггүй.
Энэ нь үр дүнгүй гэдгийг яаж ойлгох вэ? Дотоод үйл явцын гүйцэтгэлийн график дээр та дараах зургийг харж болно.
Таны Түүхийн синхрончлогч байнга завгүй байдаг (улаан график). Мөн дээд талд байрлах "улаан" график. Энэ бол мэдээллийн санг эхлүүлж, заасан бүх мөрийг устгахыг хүлээдэг "Гэрийн ажилтан" юм.
Зүйлийн ID-г авъя: та сүүлийн 5 мянгыг устгах хэрэгтэй; Мэдээжийн хэрэг, индексээр. Гэхдээ ихэвчлэн өгөгдлийн багц нь нэлээд том байдаг - өгөгдлийн сан нь үүнийг дискнээс уншиж, кэш рүү оруулдаг бөгөөд энэ нь мэдээллийн сангийн хувьд маш үнэтэй үйлдэл юм. Хэмжээнээс хамааран энэ нь гүйцэтгэлийн тодорхой асуудалд хүргэж болзошгүй юм.
Та Housekeeper-ийг энгийн аргаар идэвхгүй болгож болно - бидэнд танил вэб интерфэйс бий. Захиргааны ерөнхий тохиргоо ("Гэрийн үйлчлэгч"-ийн тохиргоо) бид дотоод түүх, чиг хандлагын үүднээс дотоод цэвэрлэгээг идэвхгүй болгодог. Тиймээс гэрийн үйлчлэгч үүнийг хянахаа больсон:
Та дараа нь юу хийж чадах вэ? Та үүнийг унтраасан, графикууд чинь жигдэрсэн байна ... Энэ тохиолдолд өөр ямар асуудал үүсч болох вэ? Юу тусалж чадах вэ?
Хуваалт (хэсэглэх)
Ерөнхийдөө энэ нь миний жагсаасан харилцааны мэдээллийн сан бүр дээр өөр өөр аргаар тохируулагдсан байдаг. MySQL өөрийн гэсэн технологитой. Гэхдээ PostgreSQL 10 болон MySQL-ийн хувьд тэд ерөнхийдөө маш төстэй юм. Мэдээжийн хэрэг, энэ бүхэн хэрхэн хэрэгжиж, гүйцэтгэлд хэрхэн нөлөөлж байгаа талаар маш олон дотоод ялгаа бий. Гэхдээ ерөнхийдөө шинэ хуваалт үүсгэх нь ихэвчлэн тодорхой асуудалд хүргэдэг.
Таны тохиргооноос хамааран (нэг өдөрт хэр их өгөгдөл үүсгэдэг) тэд ихэвчлэн хамгийн бага хэмжээг тогтоодог - энэ нь 1 өдөр / багц, "трэнд", өөрчлөлтийн динамикийн хувьд - 1 сар / шинэ багц. Хэрэв та маш том тохиргоотой бол энэ нь өөрчлөгдөж магадгүй юм.
Тохируулгын хэмжээг шууд хэлье: секундэд 5 мянга хүртэлх шинэ утгууд (nvps гэж нэрлэгддэг) - энэ нь жижиг "тохируулга" гэж тооцогддог. Дунджаар - секундэд 5-25 мянган утгууд. Дээрх бүх зүйл бол өгөгдлийн сангийн маш нарийн тохиргоог шаарддаг том бөгөөд маш том суулгацууд юм.
Маш том суурилуулалтанд 1 өдөр оновчтой биш байж магадгүй юм. Би хувьдаа MySQL дээр өдөрт 40 гигабайтын хуваалтуудыг харсан (мөн үүнээс ч их байж болно). Энэ нь маш их хэмжээний өгөгдөл бөгөөд энэ нь зарим асуудалд хүргэж болзошгүй юм. Үүнийг багасгах хэрэгтэй.
Яагаад танд хуваалт хэрэгтэй байна вэ?
Хуваалтаар хангадаг зүйл бол хүснэгтийг хуваах явдал юм. Ихэнхдээ эдгээр нь диск болон span хүсэлт дээрх тусдаа файлууд юм. Энэ нь ердийн хуваалтын нэг хэсэг бол нэг хуваалтыг илүү оновчтой сонгоно.
Ялангуяа Zabbix-ийн хувьд үүнийг муж, мужаар ашигладаг, өөрөөр хэлбэл бид цагийн тэмдэг (энгийн тоо, эриний эхэн үеэс хойшхи цаг) ашигладаг. Та өдрийн эхлэл/өдрийн төгсгөлийг зааж өгөх бөгөөд энэ нь хуваалт юм. Үүний дагуу, хэрэв та хоёр хоногийн хугацаатай өгөгдөл хүсч байгаа бол бүх зүйл өгөгдлийн сангаас хурдан сэргээгддэг, учир нь та кэш рүү зөвхөн нэг файлыг ачаалж, буцааж өгөх хэрэгтэй (том хүснэгт биш).
Олон мэдээллийн сан нь оруулах (нэг хүүхэд хүснэгтэд оруулах) хурдасгадаг. Би одоохондоо хийсвэрээр ярьж байна, гэхдээ энэ нь бас боломжтой. Хуваалт нь ихэвчлэн тусалдаг.
NoSQL-д зориулсан Elasticsearch
Саяхан 3.4-т бид NoSQL шийдлийг хэрэгжүүлсэн. Elasticsearch дээр бичих чадварыг нэмсэн. Та тодорхой төрлүүдийг бичиж болно: та сонгох - тоо эсвэл зарим тэмдэг бичих; Бидэнд мөр текст байгаа тул та Elasticsearch-д лог бичиж болно... Үүний дагуу вэб интерфэйс нь Elasticsearch-д хандах болно. Энэ нь зарим тохиолдолд маш сайн ажилладаг боловч одоогоор үүнийг ашиглаж болно.
TimescaleDB. Гипер таблицууд
4.4.2-ын хувьд бид TimescaleDB гэх мэт нэг зүйлд анхаарлаа хандуулсан. Энэ юу вэ? Энэ бол PostgreSQL-ийн өргөтгөл бөгөөд өөрөөр хэлбэл уугуул PostgreSQL интерфэйстэй. Нэмж дурдахад энэхүү өргөтгөл нь танд цагийн цуваа өгөгдөлтэй илүү үр дүнтэй ажиллах, автомат хуваах боломжийг олгоно. Энэ нь ямар харагдаж байна:
Энэ бол hypertable - Timescale-д ийм ойлголт байдаг. Энэ бол таны үүсгэсэн гипер хүснэгт бөгөөд хэсэг хэсгүүдийг агуулсан. Хэсэг хэсгүүд нь хуваалтууд, хэрэв би андуураагүй бол эдгээр нь хүүхдийн хүснэгтүүд юм. Энэ үнэхээр үр дүнтэй.
TimescaleDB болон PostgreSQL
TimescaleDB үйлдвэрлэгчдийн баталж байгаагаар тэд асуулга, тухайлбал оруулгыг боловсруулахдаа илүү зөв алгоритм ашигладаг бөгөөд энэ нь өгөгдлийн багцын хэмжээ нэмэгдэж байгаа үед ойролцоогоор тогтмол гүйцэтгэлтэй байх боломжийг олгодог. Өөрөөр хэлбэл, Postgres-ийн 200 сая эгнээний дараа ердийнх нь маш их унжиж, гүйцэтгэлийг тэг болгож алддаг бол Timescale нь ямар ч хэмжээний өгөгдөлтэй аль болох үр дүнтэй оруулах боломжийг олгодог.
TimescaleDB-г хэрхэн суулгах вэ? Энэ бол энгийн!
Энэ нь баримт бичигт байгаа, үүнийг тайлбарласан - та үүнийг ямар ч багцаас суулгаж болно ... Энэ нь албан ёсны Postgres багцаас хамаарна. Гараар эмхэтгэх боломжтой. Тиймээс би мэдээллийн санд зориулж эмхэтгэх шаардлагатай болсон.
Zabbix дээр бид зүгээр л өргөтгөлийг идэвхжүүлдэг. Postgres-д Өргөтгөл ашигласан хүмүүс ... Та зүгээр л Extension-г идэвхжүүлж, ашиглаж байгаа Zabbix мэдээллийн сандаа зориулж үүсгэнэ гэж бодож байна.
Тэгээд сүүлчийн алхам ...
TimescaleDB. Түүхийн хүснэгтүүдийг шилжүүлэх
Та гипер хүснэгт үүсгэх хэрэгтэй. Үүнд зориулсан тусгай функц байдаг - Hypertable үүсгэх. Үүний эхний параметр нь энэ мэдээллийн санд шаардлагатай хүснэгт юм (үүнд та гипер хүснэгт үүсгэх хэрэгтэй).
Үүсгэх талбар ба chunk_time_interval (энэ нь хэсгүүдийн интервал (ашиглах шаардлагатай хуваалтууд). 86 нь нэг өдөр.
Migrate_data параметр: Хэрэв та үнэн гэж оруулбал энэ нь одоогийн бүх өгөгдлийг урьдчилан үүсгэсэн хэсгүүд рүү шилжүүлнэ.
Би өөрөө migrate_data ашигласан - энэ нь таны өгөгдлийн сан хэр том байгаагаас шалтгаалж нэлээд хугацаа шаарддаг. Надад терабайт гаруй байсан - бүтээхэд нэг цаг гаруй хугацаа зарцуулагдсан. Зарим тохиолдолд туршилтын явцад би текст (history_text) болон string (history_str)-ийн түүхэн өгөгдлийг устгасан бөгөөд тэдгээрийг шилжүүлэхгүй байсан - тэдгээр нь надад тийм ч сонирхолтой байгаагүй.
Мөн бид хамгийн сүүлийн шинэчлэлтийг db_extension-дээ хийж байна: бид timescaledb-г суулгаж өгснөөр мэдээллийн бааз, ялангуяа манай Zabbix нь db_extension байгааг ойлгох болно. Тэрээр үүнийг идэвхжүүлж, TimescaleDB-д шаардлагатай "боломжуудыг" ашиглан мэдээллийн санд зөв синтакс болон асуулга ашигладаг.
Серверийн тохиргоо
Би хоёр сервер ашигласан. Эхний сервер нь нэлээд жижиг виртуал машин, 20 процессор, 16 гигабайт RAM юм. Би үүн дээр Postgres 10.8-г тохируулсан:
Үйлдлийн систем нь Debian, файлын систем нь xfs байсан. Би энэ мэдээллийн санг ашиглахын тулд хамгийн бага тохиргоог хийсэн ба Zabbix өөрөө ашиглахыг хассан. Нэг машин дээр Zabbix сервер, PostgreSQL болон ачаалах агентууд байсан.
Би өөр өөр үр дүнг хурдан гаргахын тулд LoadableModule ашигладаг 50 идэвхтэй агентыг ашигласан. Тэд бол мөр, тоо гэх мэтийг үүсгэсэн хүмүүс юм. Би мэдээллийн санг маш их мэдээллээр дүүргэсэн. Эхэндээ тохиргоо нь нэг хост бүрт 5 мянган өгөгдлийн элементийг агуулж байсан бөгөөд ойролцоогоор өгөгдлийн элемент бүр нь триггер агуулж байсан бөгөөд энэ нь жинхэнэ тохиргоо байх болно. Заримдаа ашиглахын тулд нэгээс олон гох хэрэгтэй болдог.
Би шинэчлэлтийн интервал болон ачааллыг өөрөө зохицуулж, зөвхөн 50 агент (илүү нэмж) ашиглаад зогсохгүй динамик өгөгдлийн элементүүдийг ашиглаж, шинэчлэлтийн интервалыг 4 секунд хүртэл багасгасан.
Гүйцэтгэлийн туршилт. PostgreSQL: 36 мянган NVP
Анхны хөөргөлт, миний хийсэн анхны тохиргоо нь энэ техник хангамж дээрх цэвэр PostreSQL 10 дээр байсан (секундэд 35 мянган утга). Ерөнхийдөө, дэлгэцэн дээр харж байгаагаар өгөгдөл оруулах нь секундын хэдэн хэсгийг шаарддаг - бүх зүйл сайн, хурдан, SSD хөтчүүд (200 гигабайт). Цорын ганц зүйл бол 20 ГБ-ыг маш хурдан дүүргэдэг.
Цаашид ийм графикууд нэлээд олон байх болно. Энэ бол стандарт Zabbix серверийн гүйцэтгэлийн хяналтын самбар юм.
Эхний график нь секундын утгын тоо (цэнхэр, зүүн дээд), энэ тохиолдолд 35 мянган утга юм. Энэ (дээд төв) нь бүтээх процессыг ачаалах бөгөөд энэ нь (баруун дээд талд) дотоод процессуудыг ачаалах явдал юм: түүх синхрончлол ба гэрийн үйлчлэгч, энд (доод төв) нэлээд удаан ажиллаж байна.
Энэ график (доод төвд) ValueCache-ийн хэрэглээг харуулдаг - триггерүүдэд хэдэн ValueCache цохиж байгааг (секундэд хэдэн мянган утга) харуулав. Өөр нэг чухал график бол өгөгдлийн санд оруулахын өмнө буфер болох миний ярьсан HistoryCache-ийн хэрэглээг харуулсан дөрөв дэх (зүүн доод) график юм.
Гүйцэтгэлийн туршилт. PostgreSQL: 50 мянган NVP
Дараа нь би ижил тоног төхөөрөмж дээрх ачааллыг секундэд 50 мянган утга болгон нэмэгдүүлсэн. Гэрийн үйлчлэгч ачаалах үед 10-2 секундын дотор 3 мянган утгыг тооцоолсон байдлаар тэмдэглэв. Үнэн хэрэгтээ дараах дэлгэцийн агшинд юу харагдаж байна:
"Байрны үйлчлэгч" ажилд аль хэдийн саад болж эхэлсэн боловч ерөнхийдөө түүхийн живэгчийн ачаалал 60% (гурав дахь график, баруун дээд талд) хэвээр байна. Housekeeper ажиллаж байх үед HistoryCache аль хэдийн идэвхтэй дүүргэж эхэлдэг (зүүн доод талд). Энэ нь ойролцоогоор хагас гигабайт буюу 20% дүүрэн байсан.
Гүйцэтгэлийн туршилт. PostgreSQL: 80 мянган NVP
Дараа нь би үүнийг секундэд 80 мянган утга болгон нэмэгдүүлсэн:
Энэ нь ойролцоогоор 400 мянган өгөгдлийн элемент, 280 мянган өдөөгч байв. Түүхийн живэгчийн ачааллын хувьд (тэдгээрийн 30 нь байсан) оруулга нь аль хэдийн нэлээд өндөр байсан. Дараа нь би янз бүрийн параметрүүдийг нэмэгдүүлсэн: түүх шингээгч, кэш ... Энэ техник хангамж дээр түүхийн шингээгчийн ачаалал дээд тал нь, бараг "тавиур дээр" нэмэгдэж эхэлсэн - үүний дагуу HistoryCache маш өндөр ачаалалтай болсон:
Энэ бүх хугацаанд би системийн бүх параметрүүдийг (процессорыг хэрхэн ашигладаг, RAM) хянаж, дискний ашиглалт хамгийн их байгааг олж мэдсэн - би энэ техник хангамж, энэ виртуал машин дээр энэ дискний хамгийн дээд хүчин чадалд хүрсэн. "Postgres" нь ийм эрчимтэй өгөгдлийг нэлээд идэвхтэй хаяж эхэлсэн бөгөөд диск нь бичих, унших цаггүй болсон ...
Би 48 процессортой, 128 гигабайт RAM-тай өөр сервер авсан:
Би бас үүнийг "тохируулсан" - History syncer (60 ширхэг) суулгаж, хүлээн зөвшөөрөгдсөн гүйцэтгэлд хүрсэн. Үнэн хэрэгтээ бид "тавиур дээр" биш, гэхдээ энэ нь бүтээмжийн хязгаар бөгөөд энэ талаар ямар нэгэн зүйл хийх шаардлагатай байна.
Гүйцэтгэлийн туршилт. TimescaleDB: 80 мянган NVP
Миний гол ажил бол TimescaleDB ашиглах явдал байв. График бүр уналтыг харуулж байна:
Эдгээр бүтэлгүйтэл нь мэдээллийн шилжилт хөдөлгөөн юм. Үүний дараа Zabbix сервер дээр түүхийг шингээгчийн ачаалах профайл, таны харж байгаагаар маш их өөрчлөгдсөн. Энэ нь танд өгөгдлийг бараг 3 дахин хурдан оруулах, HistoryCache-г бага ашиглах боломжийг олгодог - үүний дагуу та өгөгдлийг цаг тухайд нь хүргэх болно. Дахин хэлэхэд секундэд 80 мянган утга нь нэлээд өндөр үзүүлэлт юм (мэдээжийн хэрэг Yandex-ийн хувьд биш). Ерөнхийдөө энэ бол нэг сервертэй нэлээд том тохиргоо юм.
PostgreSQL гүйцэтгэлийн тест: 120 мянган NVP
Дараа нь би өгөгдлийн элементийн тоог хагас сая болгон нэмэгдүүлж, секундэд 125 мянган тооцоолсон утгыг авсан.
Тэгээд би эдгээр графикуудыг авсан:
Зарчмын хувьд энэ бол ажлын тохиргоо бөгөөд нэлээд удаан ажиллах боломжтой. Гэхдээ надад ердөө 1,5 терабайт диск байсан болохоор хоёр хоногийн дотор дууслаа. Хамгийн гол нь TimescaleDB дээр нэгэн зэрэг шинэ хуваалтууд үүссэн бөгөөд энэ нь гүйцэтгэлийн хувьд огт анзаарагдаагүй байсан бөгөөд үүнийг MySQL-ийн талаар хэлэх боломжгүй юм.
Дүрмээр бол хуваалтыг шөнийн цагаар хийдэг, учир нь энэ нь хүснэгтийг оруулах, ажиллахыг хориглодог бөгөөд энэ нь үйлчилгээг доройтуулж болзошгүй юм. Энэ тохиолдолд энэ нь тийм биш юм! Гол ажил бол TimescaleDB-ийн чадварыг шалгах явдал байв. Үр дүн нь дараах үзүүлэлт байв: секундэд 120 мянган утга.
Нийгэмд бас жишээ бий:
Тухайн хүн мөн TimescaleDB-г асаасан бөгөөд io.weight ашиглах ачаалал процессор дээр буурсан; мөн TimescaleDB-г оруулснаар дотоод процессын элементүүдийн хэрэглээ багассан. Түүгээр ч барахгүй эдгээр нь энгийн бин дискүүд, өөрөөр хэлбэл энгийн дискэн дээрх энгийн виртуал машин (SSD биш) юм!
Дискний гүйцэтгэлээр хязгаарлагддаг зарим жижиг тохиргооны хувьд TimescaleDB нь миний бодлоор маш сайн шийдэл юм. Энэ нь мэдээллийн сангийн илүү хурдан техник хангамж руу шилжихээс өмнө үргэлжлүүлэн ажиллах боломжийг танд олгоно.
Би та бүхнийг манай арга хэмжээнд урьж байна: Москва дахь бага хурал, Рига дахь дээд хэмжээний уулзалт. Манай сувгуудыг ашиглана уу - Telegram, форум, IRC. Хэрэв танд асуух зүйл байвал манай ширээн дээр ирээрэй, бид бүх зүйлийн талаар ярилцаж болно.
Үзэгчдийн асуултууд
Үзэгчдийн асуулт (цаашид - A): - Хэрэв TimescaleDB-ийг тохируулахад маш хялбар бөгөөд энэ нь гүйцэтгэлийн өсөлтийг өгдөг бол үүнийг Postgres-тэй Zabbix-ийг тохируулах шилдэг туршлага болгон ашиглах хэрэгтэй болов уу? Мөн энэ шийдлийн ямар нэгэн бэрхшээл, сул тал бий юу, эсвэл хэрэв би өөрөө Zabbix хийхээр шийдсэн бол Postgres-ийг хялбархан авч, Timescale програмыг шууд суулгаж, ашиглаж, ямар ч асуудлын талаар бодохгүй байх боломжтой юу?
AG: – Тийм ээ, би үүнийг сайн зөвлөмж гэж хэлмээр байна: Postgres-ийг TimescaleDB өргөтгөлөөр нэн даруй ашигла. Би аль хэдийн хэлсэнчлэн энэ "онцлог" нь туршилтын шинж чанартай байсан ч олон сайн тоймууд байдаг. Гэхдээ үнэндээ туршилтууд энэ бол гайхалтай шийдэл гэдгийг харуулж байна (TimescaleDB-тэй) бөгөөд энэ нь хөгжих болно гэж би бодож байна! Энэ өргөтгөл хэрхэн хөгжиж байгааг бид хянаж байгаа бөгөөд шаардлагатай бол өөрчлөлт оруулах болно.
Хөгжлийн явцад ч бид тэдний нэг алдартай "онцлог" дээр тулгуурласан: хэсгүүдтэй арай өөрөөр ажиллах боломжтой байсан. Гэвч дараа нь тэд дараагийн хувилбарт үүнийг хассан тул бид энэ кодонд найдахаа болих хэрэгтэй болсон. Би энэ шийдлийг олон тохиргоонд ашиглахыг зөвлөж байна. Хэрэв та MySQL ашигладаг бол... Дундаж тохиргооны хувьд ямар ч шийдэл сайн ажилладаг.
БОЛОН: – Нийгэмлэгийн хамгийн сүүлийн график дээр “Гэрийн үйлчлэгч” гэсэн график байсан.
Тэр үргэлжлүүлэн ажиллав. Гэрийн үйлчлэгч TimescaleDB-тэй юу хийдэг вэ?
AG: - Одоо би тодорхой хэлж чадахгүй байна - Би кодыг хараад илүү дэлгэрэнгүй хэлье. Энэ нь TimescaleDB асуулгыг хэсэг хэсгүүдийг устгахын тулд биш харин тэдгээрийг нэгтгэхийн тулд ашигладаг. Би энэ техникийн асуултад хариулахад бэлэн биш байна. Бид өнөөдөр эсвэл маргааш стенд дээр илүү ихийг олж мэдэх болно.
БОЛОН: - Надад ижил төстэй асуулт байна - Timescale дээрх устгах үйлдлийн гүйцэтгэлийн талаар.
Х (үзэгчдийн хариулт): – Хүснэгтээс өгөгдлийг устгахдаа устгах замаар үүнийг хийвэл хүснэгтээр дамжих хэрэгтэй - устгаж, цэвэрлэж, ирээдүйн вакуумд зориулж бүх зүйлийг тэмдэглэх хэрэгтэй. Timescale-д хэсэг хэсгүүд байгаа тул та буулгаж болно. Товчоор хэлбэл, та том өгөгдөлд байгаа файлд "Устга!"
Цагийн хуваарь нь ийм хэсэг байхаа больсон гэдгийг зүгээр л ойлгодог. Энэ нь асуулга төлөвлөгчтэй нэгтгэгдсэн тул сонголт эсвэл бусад үйлдлүүдэд таны нөхцөлийг барихын тулд дэгээ ашигладаг бөгөөд энэ хэсэг байхгүй болсныг шууд ойлгодог - "Би тийшээ явахгүй!" (мэдээлэл байхгүй). Тэгээд л болоо! Өөрөөр хэлбэл, хүснэгтийн сканнер нь хоёртын файл устгах замаар солигддог тул энэ нь хурдан юм.
БОЛОН: – Бид аль хэдийн SQL бус сэдвийг хөндсөн. Миний ойлгож байгаагаар Zabbix нь өгөгдлийг өөрчлөх шаардлагагүй бөгөөд энэ бүхэн бүртгэлтэй төстэй зүйл юм. Өгөгдлөө өөрчлөх боломжгүй, гэхдээ нэгэн зэрэг илүү хурдан хадгалж, хуримтлуулж, түгээх тусгайлсан мэдээллийн санг ашиглах боломжтой юу - Clickhouse, жишээ нь Кафкатай төстэй зүйл үү?.. Кафка ч гэсэн бүртгэл юм! Тэднийг ямар нэгэн байдлаар нэгтгэх боломжтой юу?
AG: - Буулгах боломжтой. 3.4 хувилбараас хойш бидэнд тодорхой "онцлог" бий: та бүх түүхэн файл, үйл явдал, бусад бүх зүйлийг файлд бичиж болно; дараа нь зарим зохицуулагчийг ашиглан өөр мэдээллийн сан руу илгээнэ үү. Үнэн хэрэгтээ олон хүмүүс мэдээллийн сан руу дахин боловсруулж, шууд бичдэг. Яваандаа түүхийг буулгагчид энэ бүгдийг файл болгон бичих, эдгээр файлуудыг эргүүлэх гэх мэт зүйлсийг хийх ба та үүнийг Clickhouse руу шилжүүлж болно. Төлөвлөгөөний талаар би хэлж чадахгүй, гэхдээ магадгүй NoSQL шийдлүүдийг (Clickhouse гэх мэт) цаашид дэмжих болно.
БОЛОН: – Ерөнхийдөө постгрессээс бүрэн ангижрах боломжтой болж байна?
AG: - Мэдээжийн хэрэг, Zabbix-ийн хамгийн хэцүү хэсэг бол хамгийн их асуудал, үйл явдлыг үүсгэдэг түүхэн хүснэгтүүд юм. Энэ тохиолдолд, хэрэв та үйл явдлыг удаан хугацаанд хадгалахгүй, түүхийг чиг хандлагатай өөр хурдан хадгалах санд хадгалах юм бол ерөнхийдөө ямар ч асуудал гарахгүй гэж бодож байна.
БОЛОН: – Жишээлбэл, хэрэв та Clickhouse руу шилжвэл бүх зүйл хэр хурдан ажиллахыг та тооцоолж чадах уу?
AG: - Би үүнийг туршиж үзээгүй. Clickhouse нь өөрийн гэсэн интерфэйстэй учраас наад зах нь ижил тоонд хүрч болно гэж би бодож байна, гэхдээ би баттай хэлж чадахгүй. Туршилт хийх нь дээр. Энэ бүхэн тохиргооноос шалтгаална: танд хэдэн хост байгаа гэх мэт. Оруулах нь нэг зүйл, гэхдээ та энэ өгөгдлийг сэргээх хэрэгтэй - Grafana эсвэл өөр зүйл.
БОЛОН: – Тэгэхээр бид эдгээр хурдан мэдээллийн сангуудын давуу тал биш харин тэгш эрхийн тухай ярьж байна уу?
AG: – Интеграцид орвол илүү нарийвчлалтай тестүүд гарах байх гэж бодож байна.
БОЛОН: – Сайн хуучин РРД хаашаа явсан бэ? Таныг SQL мэдээллийн сан руу шилжихэд юу нөлөөлсөн бэ? Эхэндээ бүх хэмжүүрийг RRD дээр цуглуулсан.
AG: – Заббикс RRD-тэй байсан, магадгүй маш эртний хувилбартай. SQL мэдээллийн сан байсаар ирсэн - сонгодог арга. Сонгодог арга бол MySQL, PostgreSQL (тэдгээр нь маш удаан хугацаанд оршин тогтнож ирсэн). Бид SQL болон RRD мэдээллийн сангийн нийтлэг интерфейсийг бараг ашигладаггүй.
Зарим зар 🙂
Бидэнтэй хамт байсанд баярлалаа. Манай нийтлэл танд таалагдаж байна уу? Илүү сонирхолтой контент үзэхийг хүсч байна уу? Захиалга өгөх эсвэл найзууддаа санал болгох замаар биднийг дэмжээрэй, , Бидний танд зориулж бүтээсэн анхны түвшний серверүүдийн өвөрмөц аналоги: (RAID1 болон RAID10, 24 хүртэлх цөм, 40 ГБ хүртэл DDR4-тэй байх боломжтой).
Амстердам дахь Equinix Tier IV дата төвд Dell R730xd 2 дахин хямд байна уу? Зөвхөн энд Нидерландад! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 доллараас! тухай уншина уу
Эх сурвалж: www.habr.com