Хэрэв та цаг хугацааны цуврал мэдээллийн сан ашигладаг бол (timeseries db, ) статистик бүхий сайтын үндсэн хадгалах газар болгон ашиглавал асуудлыг шийдэхийн оронд та маш их толгой өвдөх болно. Би ийм мэдээллийн баазыг ашигладаг төсөл дээр ажиллаж байгаа бөгөөд заримдаа хэлэлцэх InfluxDB нь гэнэтийн гэнэтийн бэлэг өгдөг.
Disclaimer: Жагсаалтад орсон асуудлууд нь InfluxDB 1.7.4 хувилбарт хамаарна.
Яагаад цаг хугацааны цуваа вэ?
Төсөл нь янз бүрийн блокчейн дээрх гүйлгээг хянах, статистик мэдээллийг харуулах явдал юм. Тодруулбал, бид тогтвортой зоосны ялгаралт, шаталтыг хардаг (). Эдгээр гүйлгээн дээр үндэслэн та график байгуулж, хураангуй хүснэгтүүдийг харуулах хэрэгтэй.
Гүйлгээнд дүн шинжилгээ хийх явцад нэг санаа гарч ирэв: InfluxDB цагийн цуврал мэдээллийн санг үндсэн хадгалалт болгон ашиглах. Гүйлгээ нь цаг хугацааны цэгүүд бөгөөд цаг хугацааны цувааны загварт сайн нийцдэг.
Нэгтгэх функцууд нь маш тохиромжтой харагдаж байсан - урт хугацааны график боловсруулахад тохиромжтой. Хэрэглэгчид нэг жилийн график хэрэгтэй бөгөөд мэдээллийн санд таван минутын хугацаатай өгөгдлийн багц байдаг. Түүнд бүх зуун мянган цэгийг илгээх нь утгагүй юм - удаан боловсруулалтаас гадна тэдгээр нь дэлгэцэн дээр ч багтахгүй. Та хугацааг нэмэгдүүлэхийн тулд өөрийн хэрэгжилтийг бичиж болно, эсвэл Influx-д суурилуулсан нэгтгэх функцуудыг ашиглаж болно. Тэдгээрийн тусламжтайгаар та өгөгдлийг өдрөөр нь бүлэглэж, шаардлагатай 365 оноог илгээх боломжтой.
Ийм мэдээллийн санг ихэвчлэн хэмжүүр цуглуулах зорилгоор ашигладаг нь бага зэрэг будлиантай байсан. Серверүүд, IOT төхөөрөмж, "урсдаг" хэлбэрийн олон сая цэгүүд: [<цаг хугацаа> - <метрийн утга>]. Гэхдээ хэрэв мэдээллийн сан их хэмжээний өгөгдлийн урсгалтай сайн ажилладаг бол яагаад жижиг хэмжээ нь асуудал үүсгэх ёстой гэж? Үүнийг харгалзан бид InfluxDB-г ажилд авав.
InfluxDB-д өөр юу тохиромжтой вэ
Дээр дурдсан нэгтгэх функцээс гадна өөр нэг гайхалтай зүйл бий - тасралтгүй асуулга (). Энэ бол өгөгдлийн санд суулгасан хуваарь нь хуваарийн дагуу өгөгдлийг боловсруулах боломжтой. Жишээлбэл, 24 цаг тутамд та тухайн өдрийн бүх бичлэгийг бүлэглэж, дундажийг тооцоолж, өөр хүснэгтэд нэг шинэ оноо бичиж, дугуйгаа бичихгүйгээр бичиж болно.
Мөн түүнчлэн хадгалах бодлого ()—тодорхой хугацааны дараа өгөгдөл устгах тохиргоог хийх. Жишээлбэл, та CPU-ийн ачааллыг секундэд нэг удаа хэмжилтээр долоо хоног хадгалах шаардлагатай бол энэ нь ашигтай байдаг, гэхдээ хэдэн сарын зайд ийм нарийвчлал шаардагдахгүй. Ийм нөхцөлд та дараах зүйлийг хийж болно.
- өгөгдлийг өөр хүснэгтэд нэгтгэхийн тулд тасралтгүй асуулга үүсгэх;
- Эхний хүснэгтийн хувьд тухайн долоо хоногоос хуучин хэмжигдэхүүнүүдийг устгах бодлогыг тодорхойл.
Мөн Influx нь өгөгдлийн хэмжээг бие даан багасгаж, шаардлагагүй зүйлсийг устгах болно.
Хадгалагдсан өгөгдлийн тухай
Нэг их мэдээлэл хадгалагдаагүй байна: 70 мянга орчим гүйлгээ, зах зээлийн мэдээлэл бүхий өөр нэг сая цэг. Шинэ бичлэг нэмэх - өдөрт 3000 онооноос хэтрэхгүй. Мөн сайтын хэмжүүрүүд байдаг, гэхдээ тэнд мэдээлэл бага байдаг бөгөөд хадгалах бодлогын дагуу тэдгээрийг нэг сараас илүүгүй хугацаанд хадгалдаг.
Асуудал
Үйлчилгээг хөгжүүлэх, дараа нь турших явцад InfluxDB-ийн үйл ажиллагаанд улам бүр чухал асуудлууд гарч ирэв.
1. Өгөгдлийг устгах
Гүйлгээтэй холбоотой хэд хэдэн өгөгдөл байдаг:
SELECT time, amount, block, symbol FROM transactions WHERE symbol='USDT'Үр дүн:
Би өгөгдлийг устгах тушаалыг илгээж байна:
DELETE FROM transactions WHERE symbol=’USDT’Дараа нь би аль хэдийн устгасан өгөгдлийг хүлээн авах хүсэлт гаргаж байна. Мөн хоосон хариултын оронд Influx нь устгах ёстой өгөгдлийн хэсгийг буцаана.
Би хүснэгтийг бүхэлд нь устгахыг оролдож байна:
DROP MEASUREMENT transactionsБи хүснэгтийн устгалыг шалгана:
SHOW MEASUREMENTSЖагсаалтад байгаа хүснэгтийг би харахгүй байгаа ч шинэ өгөгдлийн асуулга нь ижил гүйлгээний багцыг буцаадаг хэвээр байна.
Устгасан тохиолдол нь тусгаарлагдсан тохиолдол байсан тул асуудал надад нэг л удаа тохиолдсон. Гэхдээ мэдээллийн сангийн энэ зан байдал нь "зөв" үйл ажиллагааны хүрээнд тохирохгүй нь тодорхой байна. Дараа нь би үүнийг github дээр нээлттэй байхыг олж мэдсэн бараг жилийн өмнө энэ сэдвээр.
Үүний үр дүнд мэдээллийн санг бүхэлд нь устгаад дараа нь сэргээх нь тус болсон.
2. Хөвөгч цэгийн тоо
InfluxDB-д суурилуулсан функцуудыг ашиглах үед математикийн тооцоолол нь нарийвчлалын алдаатай байдаг. Энэ нь ер бусын зүйл биш, гэхдээ энэ нь тааламжгүй юм.
Миний хувьд өгөгдөл нь санхүүгийн бүрэлдэхүүн хэсэгтэй бөгөөд би үүнийг өндөр нарийвчлалтайгаар боловсруулахыг хүсч байна. Үүнээс болж бид тасралтгүй асуулга хийхээс татгалзахаар төлөвлөж байна.
3. Тасралтгүй асуулгыг өөр өөр цагийн бүсэд тохируулах боломжгүй
Тус үйлчилгээ нь өдөр тутмын гүйлгээний статистик бүхий хүснэгттэй. Өдөр бүрийн хувьд та тухайн өдрийн бүх гүйлгээг бүлэглэх хэрэгтэй. Гэхдээ хэрэглэгч бүрийн өдөр өөр цагт эхлэх тул гүйлгээний багц өөр байх болно. UTC гэхэд тийм ээ өгөгдлийг нэгтгэх шаардлагатай ээлжүүд.
InfluxDB дээр цаг хугацаагаар бүлэглэхдээ та ээлжийг нэмж зааж өгч болно, жишээ нь Москвагийн цагаар (UTC+3):
SELECT MEAN("supply") FROM transactions GROUP BY symbol, time(1d, 3h) fill(previous)Гэхдээ асуулгын үр дүн буруу байх болно. Зарим шалтгааны улмаас өдрөөр бүлэглэсэн өгөгдөл 1677 он хүртэл эхлэх болно (InfluxDB албан ёсоор энэ жилээс хойшхи хугацааг дэмждэг):
Энэ асуудлыг шийдэхийн тулд бид үйлчилгээг UTC+0 руу түр сольсон.
4. Гүйцэтгэл
Интернет дээр InfluxDB болон бусад мэдээллийн санг харьцуулах олон жишиг байдаг. Өнгөц харахад тэд маркетингийн материал шиг харагдаж байсан ч одоо бол зарим нэг үнэн байдаг гэж би бодож байна.
Би чамд асуудлаа хэлье.
Энэ үйлчилгээ нь сүүлийн өдрийн статистикийг буцаадаг API аргыг өгдөг. Тооцоолол хийхдээ энэ арга нь мэдээллийн баазаас гурван удаа дараах асуултуудыг асуудаг.
SELECT * FROM coins_info WHERE time <= NOW() GROUP BY symbol ORDER BY time DESC LIMIT 1SELECT * FROM dominance_info ORDER BY time DESC LIMIT 1SELECT * FROM transactions WHERE time >= NOW() - 24h ORDER BY time DESCТайлбар:
- Эхний хүсэлтээр бид зоос бүрийн сүүлийн оноог зах зээлийн өгөгдөлтэй хамт авдаг. Миний хувьд найман зоосоор найман оноо.
- Хоёр дахь хүсэлт нь хамгийн шинэ онооны нэгийг авдаг.
- Гурав дахь нь сүүлийн XNUMX цагийн гүйлгээний жагсаалтыг гаргахыг хүсч байгаа бөгөөд тэдгээр нь хэдэн зуун байж болно.
InfluxDB нь шошго болон цаг дээр суурилсан индексийг автоматаар бүтээдэг бөгөөд энэ нь асуулгын хүсэлтийг хурдасгадаг гэдгийг тодруулъя. Эхний хүсэлтэд Тэмдэг шошго юм.
Би энэ API арга дээр стресс тест хийсэн. 25 RPS-ийн хувьд сервер зургаан CPU-ийн бүрэн ачааллыг харуулсан:
Үүний зэрэгцээ NodeJs процесс нь ачааллыг огт өгөөгүй.
Гүйцэтгэлийн хурд аль хэдийн 7-10 RPS-ээр буурсан: хэрэв нэг үйлчлүүлэгч 200 мс-ийн дотор хариу хүлээн авах боломжтой бол 10 үйлчлүүлэгч секунд хүлээх шаардлагатай болсон. 25 RPS нь тогтвортой байдлын хязгаар юм; 500 алдааг үйлчлүүлэгчид буцааж өгсөн.
Ийм гүйцэтгэлтэй бол манай төсөлд Influx ашиглах боломжгүй юм. Нэмж дурдахад: хяналтыг олон үйлчлүүлэгчдэд үзүүлэх шаардлагатай төсөлд үүнтэй төстэй асуудал гарч ирж, хэмжүүрийн сервер хэт ачаалалтай байх болно.
дүгнэлт
Олж авсан туршлагаас хамгийн чухал дүгнэлт бол үл мэдэгдэх технологийг хангалттай дүн шинжилгээ хийхгүйгээр төсөлд оруулах боломжгүй юм. Github дээрх нээлттэй асуудлуудыг энгийн скрининг хийх нь InfluxDB-г үндсэн мэдээллийн сан болгон сонгохоос зайлсхийх мэдээлэл өгөх болно.
InfluxDB миний төслийн даалгавруудад тохирсон байх ёстой байсан ч практикээс харахад энэ мэдээллийн сан нь хэрэгцээ шаардлагад нийцэхгүй бөгөөд маш олон алдаатай байна.
Та төслийн репозитороос 2.0.0-бета хувилбарыг аль хэдийн олж болох бөгөөд хоёр дахь хувилбар нь мэдэгдэхүйц сайжруулалттай байх болно гэж бид найдаж байна. Энэ хооронд би TimescaleDB баримт бичгийг судлах болно.
Эх сурвалж: www.habr.com