ProHoster > Blogs > Administrācija > Kā ieskatīties Kasandras acīs, nezaudējot datus, stabilitāti un ticību NoSQL

Kā ieskatīties Kasandras acīs, nezaudējot datus, stabilitāti un ticību NoSQL

Kā ieskatīties Kasandras acīs, nezaudējot datus, stabilitāti un ticību NoSQL

Viņi saka, ka dzÄ«vē visu ir vērts vismaz vienu reizi izmēģināt. Un, ja esat pieradis strādāt ar relāciju DBVS, tad ar NoSQL ir vērts iepazÄ«ties praksē, pirmkārt, vismaz vispārējai attÄ«stÄ«bai. Tagad Ŕīs tehnoloÄ£ijas straujās attÄ«stÄ«bas dēļ par Å”o tēmu ir daudz pretrunÄ«gu viedokļu un karstas diskusijas, kas Ä«paÅ”i rada interesi.
Ja iedziļināties visu Å”o strÄ«du bÅ«tÄ«bā, var redzēt, ka tie rodas nepareizas pieejas dēļ. Tie, kuri izmanto NoSQL datu bāzes tieÅ”i tur, kur tās ir vajadzÄ«gas, ir apmierināti un saņem visas Ŕī risinājuma priekÅ”rocÄ«bas. Un eksperimentētāji, kuri paļaujas uz Å”o tehnoloÄ£iju kā panaceju tur, kur tā vispār nav pielietojama, ir vÄ«luÅ”ies, zaudējot relāciju datu bāzu stiprās puses, neiegÅ«stot ievērojamas priekÅ”rocÄ«bas.

Es jums pastāstÄ«Å”u par mÅ«su pieredzi, ievieÅ”ot risinājumu, kas balstÄ«ts uz Cassandra DBVS: ar ko mums nācās saskarties, kā izgājām no sarežģītām situācijām, vai varējām gÅ«t labumu no NoSQL izmantoÅ”anas un kur bija jāiegulda papildu pÅ«les/lÄ«dzekļi. .
Sākotnējais uzdevums ir izveidot sistēmu, kas reģistrē zvanus kaut kādā krātuvē.

Sistēmas darbÄ«bas princips ir Ŕāds. Ievade ietver failus ar Ä«paÅ”u struktÅ«ru, kas apraksta zvana struktÅ«ru. Pēc tam lietojumprogramma nodroÅ”ina, ka Ŕī struktÅ«ra tiek saglabāta attiecÄ«gajās kolonnās. Nākotnē saglabātie zvani tiks izmantoti, lai parādÄ«tu informāciju par abonentu satiksmes patēriņu (maksas, zvani, bilances vēsture).

Kā ieskatīties Kasandras acīs, nezaudējot datus, stabilitāti un ticību NoSQL

Ir pilnīgi skaidrs, kāpēc viņi izvēlējās Kasandru - viņa raksta kā ložmetējs, ir viegli mērogojama un izturīga pret defektiem.

Tā, lūk, ko mums sniedza pieredze

Jā, neveiksmÄ«gs mezgls nav traģēdija. Tā ir Kasandras vainas tolerances bÅ«tÄ«ba. Bet mezgls var bÅ«t dzÄ«vs un tajā paŔā laikā sākt ciest sniegumā. Kā izrādÄ«jās, tas nekavējoties ietekmē visa klastera veiktspēju.

Kasandra nepasargās jÅ«s tur, kur Oracle jÅ«s izglāba ar saviem ierobežojumiem. Un, ja pieteikuma autors to iepriekÅ” nesaprata, tad Kasandrai atnākuÅ”ais dubultnieks nav sliktāks par oriÄ£inālu. Kad tas bÅ«s saņemts, mēs to ievietosim.

IB ļoti nepatika bezmaksas Cassandra no kastes: Nav lietotāja darbÄ«bu reÄ£istrÄ“Å”anas, tiesÄ«bu diferenciācijas. Informācija par zvaniem tiek uzskatÄ«ta par personas datiem, kas nozÄ«mē, ka visi mēģinājumi to jebkādā veidā pieprasÄ«t/mainÄ«t ir jāreÄ£istrē ar iespēju pēc tam veikt auditu. Tāpat jums ir jāapzinās, ka dažādiem lietotājiem ir jānodala tiesÄ«bas dažādos lÄ«meņos. VienkārÅ”am darbÄ«bas inženierim un superadministratoram, kas var brÄ«vi dzēst visu atslēgvietu, ir dažādas lomas, dažādi pienākumi un kompetences. Bez Ŕādas piekļuves tiesÄ«bu diferencÄ“Å”anas datu vērtÄ«ba un integritāte nekavējoties tiks apÅ”aubÄ«ta ātrāk nekā ar JEBKURU konsekvences lÄ«meni.

Mēs neņēmām vērā, ka izsaukumiem ir nepiecieÅ”ama gan nopietna analÄ«ze, gan periodiska paraugu ņemÅ”ana dažādiem apstākļiem. Tā kā atlasÄ«tie ieraksti pēc tam ir jādzÄ“Å” un jāpārraksta (kā daļa no uzdevuma mums ir jāatbalsta datu atjaunināŔanas process, kad dati sākotnēji tika ievadÄ«ti nepareizi), Kasandra Å”eit nav mÅ«su draugs. Kasandra ir kā krājkasÄ«te - tajā ir ērti ievietot lietas, bet tajā nevar rēķināties.

Pārsūtot datus uz testa zonām, radās problēma (5 mezgli testā pret 20 izlaiduma ballē). Šajā gadījumā izgāztuvi nevar izmantot.

Problēma ar datu shēmas atjaunināŔanu lietojumprogrammai, kas raksta Kasandrai. AtcelÅ”ana radÄ«s ļoti daudz kapakmeņu, kas var izraisÄ«t produktivitātes zudumus neparedzamā veidā.. Cassandra ir optimizēta ierakstÄ«Å”anai, un pirms rakstÄ«Å”anas daudz nedomā.Jebkura darbÄ«ba ar esoÅ”iem datiem ir arÄ« ieraksts. Tas ir, izdzÄ“Å”ot nevajadzÄ«go, mēs vienkārÅ”i saražosim vēl vairāk ierakstu, un tikai daži no tiem tiks apzÄ«mēti ar kapu pieminekļiem.

Taimauts ievietoÅ”anas laikā. Kasandra ir skaista ierakstā, bet dažreiz ienākoŔā plÅ«sma viņu var ievērojami mulsināt. Tas notiek, kad lietojumprogramma sāk cikliski pārvietoties ap vairākiem ierakstiem, kurus kāda iemesla dēļ nevar ievietot. Un mums bÅ«s nepiecieÅ”ams Ä«sts DBA, kas uzraudzÄ«s gc.log, sistēmas un atkļūdoÅ”anas žurnālus, lai meklētu lēnus vaicājumus, metriku par sablÄ«vÄ“Å”anu.

Vairāki datu centri klasterī. No kurienes lasīt un kur rakstīt?
VarbÅ«t sadalÄ«t lasÄ«Å”anā un rakstÄ«Å”anā? Un ja jā, vai tuvāk rakstÄ«Å”anas vai lasÄ«Å”anas lietojumprogrammai vajadzētu bÅ«t DC? Un vai tad, ja izvēlēsimies nepareizu konsekvences lÄ«meni, mēs nesaņemsim patiesi sadalÄ«tas smadzenes? Ir daudz jautājumu, daudz nezināmu iestatÄ«jumu, iespēju, ar kurām jÅ«s patieŔām vēlaties padomāt.

Kā mēs izlēmām

Lai novērstu mezgla nogrimÅ”anu, SWAP tika atspējots. Un tagad, ja trÅ«kst atmiņas, mezglam vajadzētu iet uz leju un neveidot lielas gc pauzes.

Tātad mēs vairs nepaļaujamies uz datubāzes loÄ£iku. Lietojumprogrammu izstrādātāji pārkvalificējas un sāk aktÄ«vi veikt piesardzÄ«bas pasākumus savā kodā. Ideāla skaidra datu uzglabāŔanas un apstrādes nodalÄ«Å”ana.

Mēs iegādājāmies atbalstu no DataStax. Boksētās Cassandra izstrāde jau ir beigusies (pēdējā apņemÅ”anās bija 2018. gada februārÄ«). Tajā paŔā laikā Datastax piedāvā izcilu servisu un lielu skaitu modificētu un pielāgotu risinājumu esoÅ”ajiem IP risinājumiem.

Es arÄ« vēlos atzÄ«mēt, ka Cassandra nav Ä«paÅ”i ērta atlases vaicājumiem. Protams, CQL lietotājiem ir liels solis uz priekÅ”u (salÄ«dzinājumā ar Trift). Bet, ja jums ir veselas nodaļas, kas ir pieraduÅ”as pie tik ērtiem savienojumiem, bezmaksas filtrÄ“Å”anas pēc jebkura lauka un vaicājumu optimizācijas iespējām, un Ŕīs nodaļas strādā, lai atrisinātu sÅ«dzÄ«bas un negadÄ«jumus, Cassandra risinājums viņiem Ŕķiet naidÄ«gs un muļķīgs. Un mēs sākām izlemt, kā mÅ«su kolēģiem vajadzētu izgatavot paraugus.

IzskatÄ«jām divus variantus.Pirmajā variantā zvanus rakstām ne tikai C*, bet arÄ« arhivētajā Oracle datubāzē. Tikai atŔķirÄ«bā no C* Å”ajā datu bāzē tiek glabāti zvani tikai par tekoÅ”o mēnesi (pietiekams zvanu uzglabāŔanas dziļums, lai uzlādētu gadÄ«jumus). Å eit mēs uzreiz redzējām Ŕādu problēmu: ja mēs rakstām sinhroni, mēs zaudējam visas C* priekÅ”rocÄ«bas, kas saistÄ«tas ar ātru ievietoÅ”anu, ja mēs rakstām asinhroni, nav garantijas, ka visi nepiecieÅ”amie zvani vispār nokļuva Oracle. Bija viens pluss, bet liels: darbÄ«bai paliek tas pats pazÄ«stamais PL/SQL Developer, t.i., praktiski ievieÅ”am ā€œFasādesā€ modeli.AlternatÄ«va iespēja. Mēs ievieÅ”am mehānismu, kas izlādē zvanus no C*, izvelk dažus datus bagātināŔanai no attiecÄ«gajām Oracle tabulām, savieno iegÅ«tos paraugus un dod mums rezultātu, ko mēs pēc tam kaut kā izmantojam (atgriežam, atkārtojam, analizējam, apbrÄ«nojam). MÄ«nusi: process ir diezgan daudzpakāpju, un turklāt nav saskarnes darbÄ«bas darbiniekiem.

Beigās izŔķīrāmies pie otrā varianta. Apache Spark tika izmantots paraugu ņemÅ”anai no dažādām burciņām. Mehānisma bÅ«tÄ«ba ir samazināta lÄ«dz Java kodam, kas, izmantojot norādÄ«tās atslēgas (abonents, zvana laiks - sadaļas atslēgas), izvelk datus no C*, kā arÄ« nepiecieÅ”amos datus bagātināŔanai no jebkuras citas datu bāzes. Pēc tam tas pievieno tos savā atmiņā un parāda rezultātu iegÅ«tajā tabulā. Mēs uzzÄ«mējām tÄ«mekļa seju virs dzirksteles, un tā izrādÄ«jās diezgan lietojama.

Kā ieskatīties Kasandras acīs, nezaudējot datus, stabilitāti un ticību NoSQL

Risinot rÅ«pniecisko testu datu atjaunināŔanas problēmu, mēs atkal apsvērām vairākus risinājumus. Gan pārsÅ«tÄ«Å”ana, izmantojot Sstloader, gan iespēja sadalÄ«t kopu testa zonā divās daļās, no kurām katra pārmaiņus pieder vienai klasterim ar reklāmas kopu, tādējādi tiek darbināta no tā. Atjauninot testu, bija plānots tos apmainÄ«t: daļa, kas darbojās testā, tiek notÄ«rÄ«ta un ievadÄ«ta ražoÅ”anā, bet otra sāk strādāt ar datiem atseviŔķi. Tomēr, vēlreiz pārdomājot, mēs racionālāk novērtējām datus, kurus bija vērts pārsÅ«tÄ«t, un sapratām, ka paÅ”i zvani ir nekonsekventa vienÄ«ba testiem, kas tiek ātri Ä£enerēti, ja nepiecieÅ”ams, un tieÅ”i reklāmas datu kopai nav vērtÄ«bas pārsÅ«tÄ«Å”anai uz pārbaude. Ir vairāki uzglabāŔanas objekti, kurus ir vērts pārvietot, bet tie ir burtiski pāris galdi, turklāt ne Ä«paÅ”i smagi. Tāpēc mēs kā risinājums atkal nāca palÄ«gā Spark, ar kura palÄ«dzÄ«bu rakstÄ«jām un sākām aktÄ«vi lietot skriptu datu pārsÅ«tÄ«Å”anai starp tabulām, prom-test.

MÅ«su paÅ”reizējā izvietoÅ”anas politika ļauj mums strādāt bez atcelÅ”anas. Pirms akcijas ir obligātais testa brauciens, kurā kļūda nav tik dārga. Neveiksmes gadÄ«jumā vienmēr varat nomest laukumu un izrullēt visu shēmu no sākuma.

Lai nodroÅ”inātu nepārtrauktu Cassandra pieejamÄ«bu, jums ir nepiecieÅ”ams dba un ne tikai viņŔ. Ikvienam, kurÅ” strādā ar aplikāciju, ir jāsaprot, kur un kā skatÄ«ties uz aktuālo situāciju un kā laicÄ«gi diagnosticēt problēmas. Lai to izdarÄ«tu, aktÄ«vi izmantojam DataStax OpsCenter (darba slodžu administrÄ“Å”ana un uzraudzÄ«ba), Cassandra Driver sistēmas metriku (taimautu skaits rakstÄ«Å”anai uz C*, taimautu skaits lasÄ«Å”anai no C*, maksimālais latentums utt.), uzraugām darbÄ«bu. paÅ”as lietojumprogrammas, strādājot ar Cassandra.

Kad mēs domājām par iepriekŔējo jautājumu, mēs sapratām, kur varētu bÅ«t mÅ«su galvenais risks. Å Ä«s ir datu parādÄ«Å”anas veidlapas, kas krātuvē parāda datus no vairākiem neatkarÄ«giem vaicājumiem. Tādā veidā mēs varam iegÅ«t diezgan nekonsekventu informāciju. Taču Ŕī problēma bÅ«tu tikpat aktuāla, ja strādātu tikai ar vienu datu centru. Tāpēc vissaprātÄ«gākais Å”eit, protams, ir izveidot pakeÅ”u funkciju datu nolasÄ«Å”anai treŔās puses lietojumprogrammā, kas nodroÅ”inās datu saņemÅ”anu vienā laika periodā. Runājot par iedalÄ«jumu lasÄ«Å”anā un rakstÄ«Å”anā veiktspējas ziņā, Å”eit mÅ«s apturēja risks, ka, zaudējot savienojumu starp DC, mēs varētu nonākt pie diviem klasteriem, kas ir pilnÄ«gi nesaderÄ«gi viens ar otru.

Rezultātā pagaidām apturēta konsekvences lÄ«menÄ« EACH_QUORUM rakstÄ«Å”anai, lasÄ«Å”anai - LOCAL_QUORUM

ÄŖsi iespaidi un secinājumi

Lai izvērtētu iegÅ«to risinājumu no darbÄ«bas atbalsta un tālākās attÄ«stÄ«bas perspektÄ«vu viedokļa, nolēmām padomāt, kur vēl Ŕādu izstrādi varētu pielietot.

Uzreiz, pēc tam datu vērtÄ“Å”ana tādām programmām kā ā€œMaksā, kad tas ir ērtiā€ (mēs ielādējam informāciju C*, aprēķini, izmantojot Spark skriptus), pretenziju uzskaite ar apkopoÅ”anu pēc apgabala, lomu glabāŔana un lietotāju piekļuves tiesÄ«bu aprēķināŔana, pamatojoties uz lomu. matrica.

Kā redzat, repertuārs ir plaÅ”s un daudzveidÄ«gs. Un, ja izvēlēsimies NoSQL atbalstÄ«tāju/pretinieku nometni, tad pievienosimies atbalstÄ«tājiem, jo ā€‹ā€‹ieguvām savas priekÅ”rocÄ«bas, un tieÅ”i tur, kur gaidÄ«jām.

Pat Cassandra opcija nodroÅ”ina horizontālu mērogoÅ”anu reāllaikā, absolÅ«ti nesāpÄ«gi atrisinot jautājumu par datu palielināŔanu sistēmā. Mēs varējām pārvietot ļoti augstas slodzes mehānismu zvanu agregātu aprēķināŔanai atseviŔķā shēmā, kā arÄ« nodalÄ«t lietojumprogrammas shēmu un loÄ£iku, atbrÄ«vojoties no sliktās prakses rakstÄ«t pielāgotus darbus un objektus paŔā datu bāzē. Ieguvām iespēju izvēlēties un konfigurēt, paātrināt, uz kuriem DC veiksim aprēķinus un kuros ierakstÄ«sim datus, apdroÅ”inājāmies gan pret atseviŔķo mezglu avārijām, gan DC kopumā.

Piemērojot mÅ«su arhitektÅ«ru jauniem projektiem un jau ar zināmu pieredzi, vēlos nekavējoties ņemt vērā iepriekÅ” aprakstÄ«tās nianses un novērst dažas kļūdas, izlÄ«dzināt dažus asus stÅ«rus, no kuriem sākotnēji nevarēja izvairÄ«ties.

Tā, piemēram, laicÄ«gi sekojiet lÄ«dzi Kasandras atjauninājumiemjo diezgan daudzas no mums raduÅ”ajām problēmām jau bija zināmas un novērstas.

Neievietojiet gan paÅ”u datu bāzi, gan Spark tajos paÅ”os mezglos (vai stingri dalÄ«t ar pieļaujamo resursu izmantoÅ”anas apjomu), jo Spark var ēst vairāk OP, nekā gaidÄ«ts, un mēs ātri iegÅ«sim problēmu ar numuru 1 no mÅ«su saraksta.

Uzlabot uzraudzÄ«bu un darbÄ«bas kompetenci projekta testÄ“Å”anas posmā. Sākotnēji, cik vien iespējams, ņemiet vērā visus mÅ«su risinājuma potenciālos patērētājus, jo no tā galu galā bÅ«s atkarÄ«ga datu bāzes struktÅ«ra.

Iespējamai optimizācijai vairākas reizes pagrieziet iegÅ«to ķēdi. Atlasiet, kurus laukus var serializēt. Saprast, kādas papildu tabulas mums bÅ«tu jāveido, lai vispareizāk un optimālāk ņemtu vērā, un pēc tam sniegt nepiecieÅ”amo informāciju pēc pieprasÄ«juma (piemēram, pieņemot, ka mēs varam uzglabāt vienus un tos paÅ”us datus dažādās tabulās, ņemot vērā dažādus sadalÄ«jumus atbilstoÅ”i dažādiem kritērijiem, mēs varam ievērojami ietaupÄ«t CPU laiku lasÄ«Å”anas pieprasÄ«jumiem).

Nav slikti Nekavējoties nodroÅ”iniet TTL pievienoÅ”anu un novecojuÅ”o datu notÄ«rÄ«Å”anu.

Lejupielādējot datus no Cassandra Lietojumprogrammas loģikai jādarbojas pēc FETCH principa, lai visas rindas netiktu ielādētas atmiņā uzreiz, bet tiktu atlasītas pa partijām.

Vēlams pirms projekta pārcelÅ”anas uz aprakstÄ«to risinājumu pārbaudiet sistēmas kļūdu toleranci, veicot virkni avāriju testu, piemēram, datu zudums vienā datu centrā, bojātu datu atjaunoÅ”ana noteiktā laika periodā, tÄ«kla pārtraukÅ”ana starp datu centriem. Šādi testi ļaus ne tikai novērtēt piedāvātās arhitektÅ«ras plusus un mÄ«nusus, bet arÄ« nodroÅ”inās labu iesildÄ«Å”anās praksi tos veicoÅ”ajiem inženieriem, un iegÅ«tā prasme nebÅ«t nebÅ«s lieka, ja sistēmas kļūmes tiks atkārtotas ražoÅ”anā.

Ja strādājam ar kritisku informāciju (piemēram, dati rēķinu izrakstÄ«Å”anai, abonenta parāda aprēķināŔana), tad ir vērts pievērst uzmanÄ«bu arÄ« rÄ«kiem, kas samazinās riskus, kas rodas DBVS funkciju dēļ. Piemēram, izmantojiet nodesync utilÄ«tu (Datastax), izstrādājot optimālu stratēģiju tās lietoÅ”anai, lai konsekvences labad neradi pārmērÄ«gu slodzi Kasandrai un izmantojiet to tikai noteiktām tabulām noteiktā laika posmā.

Kas notiek ar Kasandru pēc seÅ”iem dzÄ«ves mēneÅ”iem? Kopumā neatrisinātu problēmu nav. Mēs arÄ« nepieļāvām nopietnus negadÄ«jumus vai datu zudumus. Jā, mums bija jādomā par dažu problēmu kompensÄ“Å”anu, kas iepriekÅ” nebija raduŔās, taču galu galā tas mÅ«su arhitektonisko risinājumu Ä«paÅ”i neaptumÅ”oja. Ja vēlies un nebaidies izmēģināt ko jaunu, un tajā paŔā laikā nevēlies bÅ«t pārāk vÄ«lies, tad sagatavojies tam, ka nekas nav par velti. Jums bÅ«s jāsaprot, jāiedziļinās dokumentācijā un jāsamontē savs individuālais grābeklis vairāk nekā vecajā mantotajā risinājumā, un neviena teorija nepateiks priekŔā, kurÅ” grābeklis jÅ«s gaida.

Avots: www.habr.com

Pievieno komentāru