Kas yra „MongoDB Sharding“ ir geriausia praktika?

Kaip pakeisti MongoDB? Kokia yra geriausia skutimosi praktika?


Nors lanksti schema yra tai, kaip dauguma žmonių susipažįsta su „MongoDB“, ji taip pat yra viena geriausių duomenų bazių (galbūt net pati geriausia, kai kalbama apie kasdienes programas), skirta tvarkyti labai, labai didelius duomenų rinkinius. Nors norint pagrįsti šį argumentą reikia paties straipsnio, skirto visam straipsniui (tikiuosi, kad kada nors galiu rasti laiko tam!), Bendra mintis yra ta, kad SQL pagrįsti sprendimai nepalaiko dalijimosi, o kurti jį ant jūsų sunkių žinių.

Geriausia, ko galite tikėtis, yra sukurti klasterį (kuris, beje, nieko bendro neturi su sukrėtimu) arba ieškoti valdomo sprendimo, pavyzdžiui, „Amazon“ RDS ar „Google“ „Cloud SQL“, kuris tampa nepaprastai brangus augant jūsų duomenims..

Šiame straipsnyje apžvelgsime vieną iš pagrindinių metodų horizontalus duomenų bazės mastelio keitimas, „MongoDB“, ir rekomenduokite tam pačią geriausią praktiką. Vis dėlto aš manau, kad geriau pradėti nuo shardingo pagrindų, nes daugelis žmonių, kurie nori padidinti „MongoDB“, gali būti nelabai su ja susipažinę..

Vis dėlto, jei žinote apie skaldymąsi, nesivaržykite nueiti į kitą skyrių.

Sharding pagrindai

Galbūt pastebėjote žodžio „horizontalus“ vartojimą paskutinėje ankstesnio skyriaus pastraipoje. Nesinaudodamas dar vienu masyviu aplinkkeliu, noriu greitai parodyti šį tašką. Svarstymas yra dviejų tipų mastelis: jūs arba gausite galingesnį aparatą su didesne atminties talpa (vertikalus) arba prijungiate kelis mažesnius kompiuterius ir suformuojate kolekciją (horizontalus).

Dabar, net ir geriausiuose serveriuose nėra daugiau kaip 256 GB operatyviosios atminties arba 16 TB kietojo disko, todėl bandant vertikaliai padidinti mastelį (arba „padidinti“, atsižvelgiant į terminiją) greitai atsitrenksite į plytų sieną. Tačiau jūs galite sujungti tiek daug atskirų mašinų kartu (bent jau teoriškai) ir lengvai apeiti šį apribojimą.

Be abejo, dabar iššūkis yra suderinti visų šių mašinų veiklą.

Duomenų bazės dalijimasis

Sąvoka „susiformavimas“ paprastai taikoma duomenų bazėms, turint mintyje tai, kad vieno aparato niekada negali pakakti visiems duomenims laikyti. Kai dalijama, duomenų bazė yra „suskaidoma“ į atskiras dalis, esančias skirtinguose kompiuteriuose. Paprastas pavyzdys galėtų būti: tarkime, kad įmonė turi mašinų, kuriose galima saugoti iki 2 milijonų klientų duomenų elementų. Dabar verslas pasiekia šį lūžio tašką ir greičiausiai pranoks 2,5 mln. Vartotojų. Taigi, jie nusprendžia suskaidyti savo duomenų bazę į dvi dalis:

Ir stebuklingai, dabar sistemos talpa yra dvigubai didesnė!

Na, jei tik gyvenimas buvo toks paprastas! ��

Duomenų bazių formavimo iššūkiai

Kai tik jūs šiek tiek giliai pagalvojote apie skaldymąsi, kai kurie nemandagūs iššūkiai užklupo jų bjaurią galvą.

Nėra pirminių raktų

Kai tik išeinate iš vienos duomenų bazės, pirminiai raktai praranda prasmę. Pavyzdžiui, jei jūsų pagrindiniai raktai yra nustatyti kaip automatinis padidėjimas, o pusę duomenų perkeliate į kitą duomenų bazę, dabar turėsite du skirtingus kiekvieno pirminio rakto duomenų elementus..

Jokių svetimų raktų

Kadangi duomenų bazėse nėra palaikymo, nurodančio subjektus, esančius už dabartinės duomenų bazės ribų (gerai, net nepalaikoma kita duomenų bazė tame pačiame kompiuteryje, todėl pamirškite apie duomenų bazę, esančią kitame kompiuteryje), svetimų raktų samprata yra tokia, kaip gerai. Staiga duomenų bazė tampa „niūri“, o duomenų vientisumas yra jūsų problema.

Keistos duomenų klaidos

Jei užgesta viena mašina, galutiniam vartotojui gali būti parodyta „Oi, kažkas sugedo!“ puslapis, kuris, be abejo, erzins, bet po kurio laiko gyvenimas eis į vėžes.

Dabar apsvarstykite, kas nutinka paeiliui duomenų bazėje. Tarkime, kad ankstesnio pavyzdžio duomenų bazė yra bankininkystės duomenų bazė ir vienas klientas siunčia pinigus kitam. Tarkime, kad pirmojo kliento duomenys gyvena pirmojoje skiltyje, o antrojo kliento duomenys gyvena antrojoje skardoje (matote, kur aš einu su tuo ?!). Jei mašina, kurioje yra antra skiltis, sugenda, ar galite įsivaizduoti, kokioje būsenoje sistema bus? Kur eis pinigai už operaciją? Ką pamatys pirmasis vartotojas? Ką pamatys antrasis vartotojas? Ką jie abu pamatys, kai skydinės vėl prisijungs?

Sandorių valdymas

Taip pat apsvarstykime vis kritinį operacijų valdymo atvejį. Šį kartą tarkime, kad sistema veikia 100 proc. Du žmonės (A ir B) moka trečiajam (C). Labai tikėtina, kad abi operacijos vienu metu nuskaitys C sąskaitos balansą, sukeldamos tokią painiavą:

  • C sąskaitos likutis = 100 USD.
  • Operacija rodo C balansą: 100 USD.
  • B operacija rodo C balansą: 100 USD.
  • Operacija prideda 50 USD ir atnaujina balansą: 100 USD + 50 = 150 USD.
  • B operacija prideda 50 USD ir atnaujina balansą: 100 USD + 50 = 150 USD.

Prakeiktas! 50 USD tiesiog dingo gryname ore!

Tradicinės SQL sistemos išgelbsti jus nuo to, nes teikia įmontuotą operacijų valdymą, tačiau kai tik išeinate iš vieno kompiuterio, jūs skriausite skrudinta duona.

Turint omenyje, tokiose sistemose nesunku susidurti su duomenų korupcijos problemomis, kurių neįmanoma atkurti. Plaukų kirpimas taip pat nepadės! ��

„MongoDB Sharding“

Programinės įrangos architektams jaudulys apie „MongoDB“ kilo ne tiek dėl lanksčios schemos, kiek dėl įmontuoto „sharding“ palaikymo. Prijungę tik keletą paprastų taisyklių ir mašinų, buvote pasiruošę greitai paleisti „MongoDB“ klasterį.

Žemiau pateiktame paveikslėlyje parodyta, kaip tai atrodo įprastai diegiant žiniatinklio programą.

Vaizdo kreditas: mongodb.com

Geriausia „MongoDB“ skardinimo dalis yra ta, kad net skaldų balansavimas yra automatinis. Tai yra, jei turite penkias skilteles ir dvi iš jų yra beveik tuščios, galite nurodyti „MongoDB“ subalansuoti dalykus taip, kad visos skaldos būtų vienodai pilnos.

Jums, kaip kūrėjui ar administratoriui, nereikia daug jaudintis, nes „MongoDB“ užkulisiuose sunkiausia. Tas pats pasakytina apie dalinį mazgų gedimą; jei kopijų rinkiniai teisingai sukonfigūruoti ir veikia jūsų grupėje, daliniai išjungimai neturės įtakos sistemos veikimo laikui.

Visas paaiškinimas bus gana trumpas, todėl uždarysiu šį skyrių sakydamas, kad „MongoDB“ turi keletą integruotų įrankių, skirtų nuspalvinti, atkartoti ir atkurti, todėl kūrėjams labai lengva sukurti didelio masto programas. Jei norite išsamesnio „MongoDB“ skaldos galimybių vadovo, oficialūs dokumentai yra vieta būti.

Galbūt jus tai taip pat domina išsamus kūrėjo vadovas.

„MongoDB Sharding“ geriausia praktika

Nors „MongoDB“ „veikia“ tik už laužo dėžutės, tai dar nereiškia, kad galime pailsėti ant savo laurų. Sharding gali padaryti arba sugadinti jūsų projektą visam laikui, atsižvelgiant į tai, kaip gerai ar blogai jis buvo atliktas.

Be to, yra daugybė smulkių detalių, į kurias reikia atsiskaityti, jei jų nepavyktų, nėra neįprasta, kad projektai žlunga. Siekiama ne gąsdinti jus, o pabrėžti planavimo poreikį ir būti ypač atidiems net ir priimant mažus sprendimus.

„Sharding Key“ neišvengiamai kontroliuoja „sharding“ naudojimą „MongoDB“, todėl idealu, kai savo apklausą pradedame tuo.

Aukštas kardinalumas

Kardinalumas reiškia variacijos dydį. Pvz., Mėgstamos šalies, kurioje yra 1 milijonas žmonių, kolekcija turi mažai skirtumų (pasaulyje yra tik tiek daug šalių!), Tuo tarpu jų el. Pašto adresų kolekcija (visiškai) pasižymi dideliu kardinalumu. Kodėl tai svarbu? Tarkime, kad pasirinkote naivią schemą, pagal kurią duomenys suskaidomi pagal vartotojo vardą.

Čia turime gana paprastą išdėstymą; gaunamas dokumentas skenuojamas vartotojo vardu ir, atsižvelgiant į tai, kur pirmoji raidė yra angliškoje abėcėlėje, jis nusileidžia į vieną iš trijų skilčių. Panašiai yra lengva ieškoti dokumento: pavyzdžiui, „Petro“ informacija, be abejo, bus antroje skiltyje.

Viskas atrodo gerai, bet esmė ta, kad mes nekontroliuojame gaunamų dokumentų vartotojų vardų. Ką daryti, jei didžiąją laiko dalį mes gauname tik vardus iš B į F? Jei taip, mes turėsime vadinamąjį „jumbo“ riekį „shard1“: didžioji dalis sistemos duomenų bus užpildyti ten, veiksmingai paversdami sąranką į vieną duomenų bazės sistemą.

Vaistai?

Pasirinkite raktą, kuriame yra didelis kardinalumas – pavyzdžiui, vartotojų el. Pašto adresus arba netgi galite ieškoti sudėtinio šrifto rakto, kuris yra kelių laukų derinys.

Monotoniškai besikeičiantis

Dažna „MongoDB“ šešėliavimo klaida yra naudoti monotoniškai didėjančius (arba, jei norite, automatiškai didinančius) klavišus kaip „shard“ klavišą..

Paprastai naudojamas pagrindinis dokumento raktas. Idėja čia yra geranoriška, būtent, kadangi nuolat kuriami nauji dokumentai, jie tolygiai pateks į vieną iš galimų skilčių. Deja, tokia konfigūracija yra klasikinė klaida. Taip yra todėl, kad jei shard raktas visada didėja, po taško duomenys pradės kauptis didelės vertės skaldelių pusėje, sukeldami sistemos disbalansą.

Vaizdo kreditas: mongodb.com

Kaip matote paveikslėlyje, kai mes peržengsime 20 diapazoną, visi dokumentai pradeda kauptis „Chunk C“, o ten susidaro monolitas. Sprendimas yra ieškoti išskaidytos šifravimo rakto schemos, kuri sukuria šifravimo raktą maišant vieną iš pateiktų laukų ir naudojant jį nustatant riekę..

Vaizdo kreditas: Mongodb.com

Maišytas skardinis raktas atrodo taip:

{
"_id" :"6b85117af532da651cc912cd"
}

. . . ir gali būti sukurtas „Mongo“ kliento apvalkale naudojant:

db.collection.createIndex ({_id: hashedValue})

Shard Early

Vienas naudingiausių patarimų, tiesiogiai gaunamas iš tranšėjų, yra shard anksti, net jei jūs turite mažą dviejų dalių sankaupą. Kai duomenys peržengs 500 GB ar daugiau, „MongoDB“ duomenų tvarkymas tampa nepatogiu procesu, todėl turėtumėte būti pasirengę nemaloniems netikėtumams. Be to, balansavimo procesas sunaudoja labai daug tinklo pralaidumo, kuris gali uždusti sistemą, jei nesate atsargūs.

Vis dėlto ne visi tai palaiko. Kaip įdomų pavyzdį (mokymasis yra tikrai komentaruose), skaitykite šį gražų „Percona“ dienoraštis.

Veikia balansavimo įrenginys

Kita gera idėja yra stebėti savo eismo įpročius ir naudoti „shard“ balansavimo įrenginį tik mažo srauto metu. Kaip jau minėjau, iš naujo subalansuoti reikia nemažai pralaidumo, o tai galėtų greitai priversti visą sistemą nuskaityti. Atminkite, kad nesubalansuotos skaldos nėra tiesioginės panikos priežastis. Tiesiog leiskite įprastam naudojimui išlikti, laukite mažo srauto galimybių ir leiskite likusiam darbui atlikti balansavimo įrenginį!

Štai kaip galite tai padaryti (darant prielaidą, kad srautas yra mažas nuo 3 iki 5 ryto):

naudoti konfig
db.settings.update (
{_id: "balansyras" },
{$ rinkinys: {activeWindow: {pradžia: "03:00", sustabdyti : "05:00" }}},
{upsert: true}
)

Išvada

Bet kurios duomenų bazės sukūrimas ir mastelio keitimas yra sudėtingas uždavinys, tačiau, laimei, „MongoDB“ leidžia ją lengviau valdyti nei kitas populiarias duomenų bazes..

Iš tiesų buvo laikas, kai „MongoDB“ nebuvo tinkamas pasirinkimas jokiam projektui (dėl kelių svarbių problemų ir numatyto elgesio), tačiau jų jau seniai nebėra. „MongoDB“, naudodamas ekranizavimą, balansavimą, automatinį suspaudimą, agregato lygio paskirstytą užraktą ir daugelį tokių funkcijų, pasiekė mylią, šiandien yra pirmasis programinės įrangos architekto pasirinkimas.

Tikiuosi, kad šis straipsnis sugebėjo šiek tiek paaiškinti, koks yra „MongoDB“ tinklelis ir kuo kūrėjas turi pasirūpinti, kai siekia masto. Norėdami sužinoti daugiau, galite tai gauti internetinis kursas MongoDB įsisavinimui.

ŽENKLAI:

  • Duomenų bazė

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map