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).
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.
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
