Амьдралын бүх зүйлийг ядаж нэг удаа туршиж үзэх нь зүйтэй гэж тэд хэлдэг. Хэрэв та харилцааны DBMS-тэй ажиллахад дассан бол практик дээр NoSQL-тэй танилцах нь зүйтэй юм. Одоо энэ технологи хурдацтай хөгжиж байгаатай холбогдуулан энэ сэдвээр маш олон зөрчилдөөнтэй санал бодол, халз мэтгэлцээнүүд гарч байгаа нь ялангуяа сонирхлыг нэмэгдүүлж байна.
Хэрэв та эдгээр бүх маргааны мөн чанарыг сайтар судалж үзвэл тэдгээр нь буруу хандлагаас үүдэлтэй болохыг харж болно. NoSQL өгөгдлийн санг яг хэрэгтэй газар нь ашигладаг хүмүүс сэтгэл хангалуун байдаг бөгөөд энэ шийдлээс бүх давуу талыг олж авдаг. Энэ технологийг огт хэрэглэгдэхгүй эм гэж үздэг туршилтчид ихээхэн ашиг хүртээгүй байж, харилцааны мэдээллийн сангийн давуу талыг алдсандаа сэтгэл дундуур байдаг.
Кассандра DBMS дээр суурилсан шийдлийг хэрэгжүүлэх туршлагаа бид танд хэлэх болно: бид юутай тулгарах ёстой байсан, хүнд хэцүү нөхцөл байдлаас хэрхэн гарсан, NoSQL-ийг ашигласнаар бид ашиг тусаа авч чадсан эсэх, нэмэлт хүчин чармайлт/санхүүгийн хөрөнгө оруулалт хийх шаардлагатай байсан. .
Эхний ажил бол дуудлагыг ямар нэгэн хадгалах санд бүртгэх системийг бий болгох явдал юм.
Системийн ажиллах зарчим дараах байдалтай байна. Оролт нь дуудлагын бүтцийг тодорхойлсон тодорхой бүтэцтэй файлуудыг агуулдаг. Дараа нь програм нь энэ бүтцийг зохих баганад хадгалахыг баталгаажуулдаг. Ирээдүйд хадгалсан дуудлагууд нь захиалагчдын замын хөдөлгөөний хэрэглээний талаарх мэдээллийг харуулахад ашиглагддаг (төлбөр, дуудлага, үлдэгдлийн түүх).
Тэд яагаад Кассандра-г сонгосон нь тодорхой байна - тэр пулемёт шиг бичдэг, амархан томруулж чаддаг, алдааг тэсвэрлэдэг.
Тиймээс бидэнд ийм туршлага өгсөн
Тиймээ, бүтэлгүйтсэн зангилаа бол эмгэнэл биш юм. Энэ бол Кассандрагийн алдааг тэсвэрлэх чадварын мөн чанар юм. Гэхдээ зангилаа нь амьд байж, нэгэн зэрэг гүйцэтгэлд зовж эхэлдэг. Энэ нь бүхэл бүтэн кластерын гүйцэтгэлд шууд нөлөөлдөг.
Oracle хязгаарлалттайгаар таныг аварсан газар Кассандра таныг хамгаалахгүй. Хэрэв өргөдлийн зохиогч үүнийг урьдчилан ойлгоогүй бол Кассандрагийн хувьд ирсэн давхар нь анхныхаас муу зүйл биш юм. Нэгэнт ирвэл бид оруулах болно.
IB хайрцагнаас гарсан үнэгүй Кассандра-д маш их дургүй байсан: Хэрэглэгчийн үйлдлийг бүртгэх, эрхийн ялгаа байхгүй. Дуудлагын талаарх мэдээллийг хувийн мэдээлэл гэж үздэг бөгөөд энэ нь ямар нэгэн байдлаар хүсэлт гаргах/өөрчлөх гэсэн бүх оролдлогыг дараагийн аудитын боломжоор бүртгэх ёстой гэсэн үг юм. Түүнчлэн, та өөр өөр хэрэглэгчдэд өөр өөр түвшний эрхийг тусгаарлах хэрэгцээг мэдэж байх хэрэгтэй. Энгийн үйлдлийн инженер болон товчлуурын зайг бүхэлд нь чөлөөтэй устгаж чадах супер админ нь өөр өөр үүрэг, өөр үүрэг хариуцлага, ур чадвар юм. Хандалтын эрхийг ийм байдлаар ялгахгүйгээр өгөгдлийн үнэ цэнэ, бүрэн бүтэн байдал нь ямар ч тогтвортой байдлын түвшингээс илүү хурдан эргэлзээ төрүүлэх болно.
Дуудлага хийхэд ноцтой дүн шинжилгээ хийх, янз бүрийн нөхцөлд үе үе түүвэрлэх шаардлагатай гэдгийг бид анхаарч үзээгүй. Сонгосон бичлэгүүдийг устгаж, дахин бичих ёстой (даалгаврын нэг хэсэг болгон өгөгдөл нь бидний давталт руу буруу орсон үед өгөгдлийг шинэчлэх процессыг дэмжих ёстой) Кассандра энд бидний найз биш юм. Кассандра бол гахайн банк шиг - юм тавихад тохиромжтой, гэхдээ та үүнд тоолж чадахгүй.
Туршилтын бүс рүү өгөгдөл дамжуулахад асуудал гарлаа (Тестийн 5 зангилаа, төгсөлтийн 20 зангилаа). Энэ тохиолдолд овоолгыг ашиглах боломжгүй.
Кассандра руу бичиж буй програмын өгөгдлийн схемийг шинэчлэхтэй холбоотой асуудал. Буцах нь маш олон булшны чулуу үүсгэх бөгөөд энэ нь бүтээмжийг урьдчилан таамаглах боломжгүй байдлаар алдахад хүргэдэг.. Кассандра бичлэг хийхэд оновчтой бөгөөд бичихээсээ өмнө нэг их боддоггүй. Түүнд байгаа өгөгдөлтэй аливаа үйлдэл нь мөн бичлэг юм. Өөрөөр хэлбэл, шаардлагагүй зүйлийг устгаснаар бид зүгээр л илүү олон бичлэг хийх болно, зөвхөн заримыг нь булшны чулуугаар тэмдэглэнэ.
Оруулах үед завсарлага. Кассандра бичлэг дээр үзэсгэлэнтэй, гэхдээ Заримдаа ирж буй урсгал нь түүнийг ихээхэн төөрөгдүүлдэг. Энэ нь програм нь ямар нэг шалтгаанаар оруулах боломжгүй хэд хэдэн бичлэгийг тойрон эргэлдэж эхлэхэд тохиолддог. Мөн бидэнд gc.log, систем болон дибаг хийх логуудыг удаан асуулга, хүлээгдэж буй нягтралын хэмжүүрүүдийг хянах жинхэнэ DBA хэрэгтэй болно.
Кластерт хэд хэдэн дата төвүүд. Хаанаас уншиж, хаанаас бичих вэ?
Унших, бичих гэж хуваагдсан байх? Хэрэв тийм бол бичих эсвэл унших програмд илүү ойр DC байх ёстой юу? Хэрэв бид тууштай байдлын түвшинг буруу сонговол жинхэнэ тархи хуваагдахгүй гэж үү? Маш олон асуултууд, олон үл мэдэгдэх тохиргоонууд, танд үнэхээр оролдохыг хүсч буй боломжууд байна.
Бид яаж шийдсэн
Зангилаа живэхээс сэргийлэхийн тулд SWAP-г идэвхгүй болгосон. Одоо санах ой дутагдалтай байвал зангилаа доошоо бууж, том gc завсарлага үүсгэхгүй байх ёстой.
Тиймээс бид мэдээллийн сан дахь логикт найдахаа больсон. Аппликейшн хөгжүүлэгчид өөрсдийгөө давтан сургаж, өөрсдийн коддоо урьдчилан сэргийлэх арга хэмжээг идэвхтэй авч эхэлж байна. Мэдээллийн хадгалалт, боловсруулалтыг хамгийн сайн салгах.
Бид DataStax-аас дэмжлэг авсан. Хайрцагтай Кассандрагийн хөгжил аль хэдийн зогссон (хамгийн сүүлд 2018 оны XNUMX-р сард хийсэн). Үүний зэрэгцээ, Datastax нь одоо байгаа IP шийдлүүдийн хувьд маш сайн үйлчилгээ, олон тооны өөрчлөгдсөн, тохируулсан шийдлүүдийг санал болгодог.
Кассандра нь сонгон шалгаруулах асуулгад тийм ч тохиромжтой биш гэдгийг тэмдэглэхийг хүсч байна. Мэдээжийн хэрэг, CQL бол хэрэглэгчдийн хувьд урагшлах том алхам юм (Trift-тай харьцуулахад). Гэхдээ хэрэв танд ийм тохиромжтой нэгдэлд дассан, дурын талбараар үнэ төлбөргүй шүүж, хайлтыг оновчтой болгох чадвартай, эдгээр хэлтсүүд гомдол, ослыг шийдвэрлэхээр ажиллаж байгаа бол Кассандра дээрх шийдэл нь тэдэнд дайсагнасан бөгөөд тэнэг юм шиг санагддаг. Мөн бид хамт ажиллагсад хэрхэн дээж хийх ёстойг шийдэж эхлэв.
Бид хоёр хувилбарыг авч үзсэн.Эхний хувилбарт бид дуудлагыг зөвхөн C* хэлээр бичихээс гадна архивлагдсан Oracle мэдээллийн санд бичдэг. Зөвхөн C*-ээс ялгаатай нь энэ мэдээллийн сан нь зөвхөн тухайн сарын дуудлагыг хадгалдаг (цэнэглэхийн тулд дуудлагын санах ой хангалттай). Энд бид нэн даруй дараах асуудлыг олж харлаа: хэрэв бид синхроноор бичвэл хурдан оруулахтай холбоотой C*-ийн бүх давуу талыг алддаг; хэрэв бид асинхроноор бичвэл шаардлагатай бүх дуудлага Oracle-д орсон гэсэн баталгаа байхгүй. Нэг давуу тал байсан ч нэг том зүйл байсан: үйл ажиллагааны хувьд ижилхэн танил PL/SQL хөгжүүлэгч хэвээр үлдэнэ, өөрөөр хэлбэл бид "Facade" загварыг бараг хэрэгжүүлдэг. Өөр сонголт. Бид C*-ээс дуудлагыг буулгаж, Oracle-ийн харгалзах хүснэгтүүдээс зарим өгөгдлийг баяжуулах зорилгоор гаргаж авсан дээжүүдийг нэгтгэж, үр дүнг бидэнд өгдөг механизмыг хэрэгжүүлдэг бөгөөд бид үүнийг ямар нэгэн байдлаар ашигладаг (буцах, давтах, дүн шинжилгээ хийх, биширдэг). Сул талууд: үйл явц нь нэлээд олон үе шаттай бөгөөд үүнээс гадна үйл ажиллагааны ажилтнуудад зориулсан интерфейс байдаггүй.
Эцэст нь бид хоёр дахь хувилбар дээр тогтлоо. Apache Spark-ийг өөр өөр савнаас дээж авахад ашигласан. Механизмын мөн чанарыг Java код болгон багасгасан бөгөөд энэ нь заасан түлхүүрүүдийг (захиалагч, дуудлагын цаг - хэсгийн товчлуурууд) ашиглан C*-аас өгөгдөл, мөн бусад мэдээллийн сангаас баяжуулахад шаардлагатай өгөгдлийг гаргаж авдаг. Үүний дараа тэдгээрийг санах ойд нэгтгэж, үр дүнг хүснэгтэд харуулна. Бид оч дээр вэб нүүр зурсан бөгөөд энэ нь нэлээд ашиглах боломжтой болсон.
Аж үйлдвэрийн туршилтын өгөгдлийг шинэчлэх асуудлыг шийдэхдээ бид хэд хэдэн шийдлийг дахин авч үзсэн. Sstloader-ээр дамжуулж, туршилтын бүс дэх кластерийг хоёр хэсэгт хуваах сонголтууд тус бүр нь сурталчилгааны нэг кластерт ээлжлэн харьяалагддаг тул үүгээр тэжээгддэг. Туршилтыг шинэчлэхдээ тэдгээрийг солихоор төлөвлөж байсан: туршилтанд ажиллаж байсан хэсгийг цэвэрлэж, үйлдвэрлэлд оруулсан, нөгөө нь өгөгдөлтэй тусад нь ажиллаж эхэлдэг. Гэсэн хэдий ч, дахин бодсоны дараа бид дамжуулах үнэ цэнэтэй өгөгдлийг илүү оновчтой үнэлж, дуудлага нь өөрөө туршилтанд нийцэхгүй, шаардлагатай бол хурдан үүсгэгддэг бөгөөд энэ нь сурталчилгааны мэдээллийн багц юм гэдгийг ойлгосон. тест. Хөдлөхөд тохиромжтой хэд хэдэн хадгалах объект байдаг, гэхдээ эдгээр нь маш хүнд биш хоёр ширээ юм. Тиймээс бид шийдэл болгон Spark дахин аврах ажилд ирсэн бөгөөд үүний тусламжтайгаар бид бичиж, хүснэгт хооронд өгөгдөл дамжуулах скриптийг идэвхтэй ашиглаж эхэлсэн, prom-test.
Бидний одоогийн байршуулах бодлого нь буцаахгүйгээр ажиллах боломжийг бидэнд олгодог. Сурталчилгааны өмнө алдаа нь тийм ч үнэтэй биш байх ёстой туршилтын гүйлт байдаг. Хэрэв бүтэлгүйтсэн тохиолдолд та casepace-ыг орхиж, бүх схемийг эхнээс нь эргүүлж болно.
Кассандрагийн байнгын бэлэн байдлыг хангахын тулд танд зөвхөн түүнд төдийгүй dba хэрэгтэй. Аппликейшнтэй ажилладаг хүн бүр одоогийн нөхцөл байдлыг хаанаас, хэрхэн харж, асуудлыг хэрхэн цаг тухайд нь оношлохыг ойлгох ёстой. Үүнийг хийхийн тулд бид DataStax OpsCenter (Ачааллын удирдлага, хяналт), Cassandra Driver системийн хэмжигдэхүүнүүдийг (С* руу бичих завсарлагын тоо, С*-ээс унших завсарлагын тоо, хамгийн их хоцролт гэх мэт) идэвхтэй ашигладаг, үйл ажиллагааг хянадаг. програмын өөрөө, Кассандра хамтран ажиллаж байна.
Бид өмнөх асуултын талаар бодохдоо бидний гол эрсдэл хаана байж болохыг ойлгосон. Эдгээр нь хэд хэдэн бие даасан асуулгын өгөгдлийг хадгалах сан руу харуулах өгөгдөл харуулах хэлбэрүүд юм. Ингэснээр бид нэлээд зөрүүтэй мэдээлэл авах боломжтой. Гэхдээ хэрэв бид зөвхөн нэг дата төвтэй ажилласан бол энэ асуудал мөн адил хамааралтай байх болно. Тиймээс энд хамгийн боломжийн зүйл бол мэдээж гуравдагч талын програм дээр өгөгдлийг унших багц функцийг бий болгох бөгөөд энэ нь өгөгдлийг нэг хугацаанд хүлээн авах боломжийг олгоно. Гүйцэтгэлийн хувьд унших, бичих гэж хуваах тухайд, DC-ийн хоорондын холболт бага зэрэг тасарвал бие биентэйгээ огт нийцэхгүй хоёр кластер гарч ирэх эрсдэлийг бид энд зогсоосон.
Үүний үр дүнд одоогоор EACH_QUORUM бичих, уншихад - LOCAL_QUORUM нийцлийн түвшинд зогссон
Товч сэтгэгдэл, дүгнэлт
Үүссэн шийдлийг үйл ажиллагааны дэмжлэг, цаашдын хөгжлийн хэтийн төлөвийн үүднээс үнэлэхийн тулд бид ийм хөгжлийг өөр хаана ашиглаж болох талаар бодохоор шийдсэн.
Дараа нь "Тохиромжтой үед нь төл" (бид C* руу мэдээлэл ачаалах, Spark скрипт ашиглан тооцоолол хийх), нэхэмжлэлийг бүсээр нэгтгэн бүртгэх, үүргүүдийг хадгалах, үүрэгт үндэслэн хэрэглэгчийн хандалтын эрхийг тооцоолох зэрэг програмын өгөгдөлд оноо өгөх. матриц.
Таны харж байгаагаар репертуар өргөн, олон янз байдаг. Хэрэв бид NoSQL-ийг дэмжигчид/сөрөгчдийн баазыг сонговол бид өөрсдийн давуу талыг, яг бидний хүлээж байсан газраа хүлээн авсан тул дэмжигчидтэй нэгдэх болно.
Хайрцагнаас гарсан Кассандра сонголт ч гэсэн бодит цаг хугацаанд хэвтээ масштаблах боломжийг олгож, систем дэх өгөгдлийг нэмэгдүүлэх асуудлыг туйлын өвдөлтгүй шийддэг. Бид дуудлагын агрегатуудыг тооцоолох маш өндөр ачаалалтай механизмыг тусдаа хэлхээнд шилжүүлж, мөн хэрэглээний схем, логикийг салгаж, мэдээллийн санд захиалгат ажил, объект бичих муу туршлагаас ангижрах боломжтой болсон. Бид аль DC дээр тооцоо хийх, аль дээр нь өгөгдөл бичихээ сонгох, тохируулах, хурдасгах боломжийг олж авснаар бид бие даасан зангилаа болон бүхэлд нь DC-ийн эвдрэлээс өөрийгөө даатгуулсан.
Архитектураа шинэ төслүүдэд ашиглаж, тодорхой хэмжээний туршлагатай болсон тул дээр дурдсан нюансуудыг нэн даруй анхаарч үзэхийг хүсч, зарим алдаанаас урьдчилан сэргийлэх, эхэндээ зайлсхийх боломжгүй зарим хурц булангуудыг тэгшлэхийг хүсч байна.
Жишээ нь, Кассандрагийн шинэчлэлтүүдийг цаг тухайд нь хянаж байхУчир нь бидэнд тохиолдсон зарим асуудлууд аль хэдийн мэдэгдэж, зассан байсан.
Өгөгдлийн сан болон Spark хоёрыг нэг зангилаа дээр бүү тавь (эсвэл зөвшөөрөгдөх нөөцийн ашиглалтын хэмжээгээр хатуу хуваах), учир нь Spark нь тооцоолж байснаас илүү их хэмжээний OP идэж чаддаг тул бид жагсаалтаасаа 1-р асуудлыг хурдан авах болно.
Төслийн туршилтын үе шатанд хяналт-шинжилгээ, үйл ажиллагааны ур чадварыг сайжруулах. Эхний ээлжинд манай шийдлийн боломжит бүх хэрэглэгчдийг аль болох анхаарч үзээрэй, учир нь өгөгдлийн сангийн бүтэц эцсийн дүндээ үүнээс хамаарна.
Боломжит оновчтой болгохын тулд үүссэн хэлхээг хэд хэдэн удаа эргүүлнэ. Аль талбаруудыг цуваа болгож болохыг сонгоно уу. Хамгийн зөв, оновчтой байхын тулд бид ямар нэмэлт хүснэгт хийх ёстойг ойлгож, дараа нь хүсэлтийн дагуу шаардлагатай мэдээллээр хангах (жишээлбэл, бид ижил өгөгдлийг өөр өөр хүснэгтэд хадгалах боломжтой гэж үзвэл, өөр өөр задаргааг харгалзан үзэх). өөр өөр шалгуураар бид унших хүсэлтэд CPU-ийн цагийг ихээхэн хэмнэж чадна).
Муу биш TTL хавсаргах, хуучирсан өгөгдлийг цэвэрлэх ажлыг нэн даруй хангах.
Кассандрагаас өгөгдөл татаж авах үед Програмын логик нь FETCH зарчмаар ажиллах ёстой бөгөөд ингэснээр бүх мөрийг санах ойд нэг дор ачаалахгүй, харин багцаар сонгох хэрэгтэй.
Төслийг тайлбарласан шийдэлд шилжүүлэхээс өмнө үүнийг зөвлөж байна хэд хэдэн ослын туршилт хийх замаар системийн алдааг тэсвэрлэх чадварыг шалгана, тухайлбал нэг дата төвд өгөгдөл алдах, тодорхой хугацаанд гэмтсэн өгөгдлийг сэргээх, дата төв хоорондын сүлжээ тасрах зэрэг. Ийм туршилтууд нь зөвхөн санал болгож буй архитектурын давуу болон сул талуудыг үнэлэх боломжийг олгодог төдийгүй тэдгээрийг удирдаж буй инженерүүдэд сайн дулаацах дадлага хийх боломжийг олгодог бөгөөд хэрэв системийн доголдол үйлдвэрлэлд дахин давтагдсан бол олж авсан ур чадвар нь илүүц байх болно.
Хэрэв бид чухал мэдээлэлтэй (тооцооны мэдээлэл, захиалагчийн өрийг тооцоолох гэх мэт) ажилладаг бол DBMS-ийн онцлогоос шалтгаалан үүсэх эрсдлийг бууруулах хэрэгслүүдэд анхаарлаа хандуулах нь зүйтэй. Жишээлбэл, зангилаа синхрончлолын хэрэглүүрийг (Datastax) ашиглана уу, үүнийг дарааллаар нь ашиглах оновчтой стратеги боловсруулжээ. Тогтвортой байдлын үүднээс Кассандра дээр хэт их ачаалал үүсгэж болохгүй мөн тодорхой хугацаанд зөвхөн тодорхой хүснэгтэд ашиглах.
Амьдралын зургаан сарын дараа Кассандра юу болох вэ? Ер нь шийдэгдээгүй асуудал байхгүй. Мөн бид ноцтой осол, мэдээлэл алдагдахыг зөвшөөрөөгүй. Тийм ээ, бид өмнө нь гарч байгаагүй зарим асуудлыг нөхөх талаар бодох хэрэгтэй байсан ч эцэст нь энэ нь бидний архитектурын шийдлийг нэг их бүрхсэнгүй. Хэрэв та шинэ зүйлийг туршиж үзэхийг хүсч, айхгүй байгаа бол тэр үед хэтэрхий урам хугарахыг хүсэхгүй байгаа бол юу ч үнэ төлбөргүй биш гэдэгт бэлэн байгаарай. Та ойлгож, баримт бичгийг судалж, өөрийн хувийн тармуурыг хуучин шийдлээс илүү угсрах хэрэгтэй бөгөөд ямар ч онол таныг аль тармуур хүлээж байгааг урьдчилан хэлэхгүй.
Эх сурвалж: www.habr.com