Kaj je MongoDB Sharding in najboljše prakse?

Kako določiti lestvico MongoDB? Katere so najboljše prakse striženja?


Čeprav je prilagodljiva shema, kako se večina ljudi seznani z MongoDB, je tudi ena najboljših baz podatkov (morda celo najboljša, ko gre za vsakodnevne aplikacije) za ravnanje z zelo, zelo velikimi nabori podatkov. Medtem ko utemeljitev tega argumenta zahteva celoten članek sam (upam, da bom lahko našel čas za to nekega dne!), Je splošna ideja, da rešitve, ki temeljijo na SQL, ne podpirajo ostrenja in ga nadgradijo.

Najboljše, na kar se lahko nadejate, je ustvariti grozd (ki je, mimogrede, nima nobene zveze z ostrino) ali poiščite upravljano rešitev, kot je Amazonov RDS ali Googlov oblačni SQL, ki postanejo z rastjo vaših podatkov izjemno dragi.

V tem članku si bomo ogledali eno osnovnih tehnik horizontalno skaliranje baze podatkov: ostrenje, za MongoDB in priporočite nekaj najboljših praks za isto. Vendar menim, da je bolje začeti z osnovami ostrenja, ker ga mnogi, ki želijo spremeniti MongoDB, morda premalo poznajo.

Če pa se zavedate ostrenja, vseeno prosim prelistajte naslednji del.

Osnove ostrenja

Morda ste opazili uporabo besede “vodoravno” v zadnjem odstavku iz prejšnjega razdelka. Ne da bi se začel v drugo množično obvoznico, želim to točko hitro predstaviti. Razmerje se šteje za dve vrsti: bodisi dobite zmogljivejši stroj z večjo kapaciteto za shranjevanje (navpična) ali povežete več manjših računalnikov in oblikujete zbirko (vodoravni).

Glede na to, da tudi trenutno najboljši strežniki nimajo več kot 256 GB RAM-a ali 16 TB trdega diska, kmalu udarite v opečno steno, ko poskušate vertikalno meriti (ali “pomanjšati”, kot to pomeni terminologija). Vendar pa lahko skupaj (vsaj teoretično) povežete čim več posameznih strojev in preprosto omejite to omejitev.

Seveda je zdaj izziv usklajevanje med vsemi temi stroji.

Ostritev baze podatkov

Izraz „ostrenje“ se na splošno nanaša na zbirke podatkov, pri čemer ideja ne more biti nikoli dovolj za shranjevanje vseh podatkov. Pri strjevanju se baza podatkov “razdeli” na ločene kose, ki se nahajajo na različnih strojih. Preprost primer je lahko: predpostavimo, da ima podjetje stroje, ki lahko shranijo do 2 milijona podatkov o strankah. Zdaj podjetje dosega to mejo in bo verjetno kmalu preseglo 2,5 milijona uporabnikov. Tako se odločijo, da svojo bazo podatkov razdelijo na dva:

In čarobno je zmogljivost sistema zdaj podvojena!

No, ko bi bilo samo življenje tako preprosto! ��

Izzivi pri draženju podatkovnih baz

Takoj, ko ste malo poglobljeno razmišljali o ostrenju, jim grdi glavi nekateri zlobni izzivi.

Brez primarnih ključev

Ko stopite iz ene baze podatkov, primarni ključi izgubijo pomen. Primer: če so vaši primarni ključi nastavljeni na samodejno povečanje in polovico podatkov premaknete v drugo bazo podatkov, boste zdaj imeli dve različni podatkovni postavki za vsak primarni ključ.

Brez tujih ključev

Ker v bazah ni podpore, ki bi kazala na subjekte zunaj trenutne baze podatkov (no, tudi drugačna baza podatkov na istem stroju ni podprta, zato pozabite na bazo podatkov na drugem stroju), koncept tujih ključev velja za metanje dobro. Nenadoma postane baza podatkov neumna, celovitost podatkov pa je vaš problem.

Čudne napake s podatki

Če en stroj ugasne, se končnemu uporabniku prikaže »Oops, nekaj se je pokvarilo!« stran, ki bo nedvomno motila, a življenje bo čez nekaj časa na poti.

Zdaj razmislite, kaj se zgodi v podatkovni zbirki. Predpostavimo, da je osnovana baza podatkov v našem prejšnjem primeru bančna baza podatkov, ena stranka pa denar pošilja drugi. Predpostavimo, da prvi podatki o strankah živijo v prvem odseku, medtem ko podatki druge stranke živijo v drugem delu (vidite, kam grem s tem ?!). Če stroj, ki vsebuje drugi delček, odpove, ali si lahko predstavljate, v kakšnem stanju bo sistem? Kam bo odšel transakcijski denar? Kaj bo videl prvi uporabnik? Kaj bo videl drugi uporabnik? Kaj bosta oba videla, ko bodo osterčki spet na spletu?

Upravljanje transakcij

Upoštevajmo tudi vedno kritičen primer upravljanja transakcij. Tokrat predpostavimo, da sistem deluje 100% v redu. Zdaj dve osebi (A in B) plačata tretji osebi (C). Zelo verjetno je, da bosta obe transakciji hkrati prebrali stanje računa C in povzročila to zmedo:

  • Stanje na računu C = 100 USD.
  • V transakciji se bere stanje C: 100 USD.
  • V transakciji B se bere stanje C: 100 USD.
  • Transakcija doda 50 USD in posodobi stanje: 100 + 50 + 150 $.
  • Transakcija B doda 50 USD in posodobi preostanek: 100 $ + 50 = 150 USD.

Prekleto! 50 dolarjev je ravnokar izginilo v zraku!

Tradicionalni sistemi SQL vam prihranijo to z zagotavljanjem vgrajenega upravljanja transakcij, a ko stopite iz enega stroja, nazdravite.

Glede na to, da je s takšnimi sistemi enostavno naleteti na težave s korupcijo podatkov, ki jih ni mogoče obnoviti. Tudi nategovanje las ne bo pomagalo! ��

MongoDB Sharding

Za programske arhitekte vznemirjenje MongoDB ni bilo toliko v njegovi prožni shemi, kot v vgrajeni podpori za ostrenje. Z le nekaj preprostimi pravili in povezanimi stroji ste bili pripravljeni v nobenem trenutku zagnati ostriženo gručo MongoDB.

Spodnja slika prikazuje, kako je to videti v običajni namestitvi spletnih aplikacij.

Kreditna slika: mongodb.com

Najboljši del ostrenja MongoDB je, da je tudi ravnovesje ožilja avtomatsko. Če imate pet posnetkov in sta dva skoraj prazna, lahko MongoDB poveste, naj stvari ponovno uravnoteži, tako da so vsi delci enako polni.

Kot razvijalec ali skrbnik vam ni treba veliko skrbeti, saj MongoDB v zakulisju opravi večino težkega dviga. Enako velja za delno odpoved vozlišč; če imate pravilno nastavljen niz replik in deluje v grozdu, delni izpadi ne bodo vplivali na čas delovanja sistema.

Celotno razlago bi postalo precej kratko, zato bom ta del zaključil z besedami, da ima MongoDB več vgrajenih orodij za strjevanje, podvajanje in obnovo, kar razvijalcem zelo olajša izdelavo obsežnih aplikacij. Če želite bolj izčrpen vodnik o zmogljivostih MongoDB za ostrenje, lahko uradni dokumenti so kraj za to.

Morda vas bo zanimalo tudi to popoln vodnik za razvijalce.

MongoDB Sharding Best Practices

Medtem ko MongoDB “samo deluje” iz škatle za ostrenje, to še ne pomeni, da se lahko opiramo na lovorike. Ostrenje lahko vaš projekt za vedno ustavi ali prekine, odvisno od tega, kako dobro ali slabo je bil izveden.

Poleg tega je treba upoštevati veliko majhnih podrobnosti, v nasprotju s tem pa ni redko, da se projekti sesujejo. Namen vas ni prestrašiti, temveč poudariti potrebo po načrtovanju in biti zelo previdni tudi pri majhnih odločitvah.

Tipka za ostrenje neizogibno nadzoruje ostrenje v MongoDB, zato je idealno, da začnemo z raziskavo s tem.

Visoka kardinalnost

Kardinalnost pomeni količino variacije. Na primer, zbirka najljubše države z milijonom ljudi bo zelo majhna (na svetu je samo toliko držav!), Medtem ko bo zbirka njihovih e-poštnih naslovov imela (popolnoma) visoko kardinalnost. Zakaj je to pomembno? Predpostavimo, da izberete naivno shemo, ki ostri podatke na podlagi uporabnikovega imena.

Tu imamo precej preprost dogovor; dohodni dokument se skenira za uporabniško ime in glede na to, kje prva črka leži v angleški abecedi, pristane v enem od treh ostrih. Podobno je iskanje dokumenta enostavno: podrobnosti za na primer “Peter” bodo zagotovo v drugem odseku.

Vse se sliši dobro, ampak poanta je, da ne nadzorujemo imen uporabnikov dohodnih dokumentov. Kaj če večino časa dobimo samo imena v območju od B do F? V tem primeru bomo imeli tisto, kar imenujemo “jumbo” kos v shard1: večina sistemskih podatkov bo tam gneča, kar bo dejansko pretvorilo v enoten sistem baz podatkov.

Zdravilo?

Izberite ključ z visoko kardinalnostjo – na primer e-poštni naslov uporabnikov ali pa pojdite celo na sestavljeni ključ za deljenje, ki je kombinacija več polj.

Monotonsko spreminjanje

Običajna napaka pri ostrenju v MongoDB je, da kot tipko za brisanje uporabite monotonsko naraščajoče (ali samodejno povečanje, če želite).

Na splošno se uporablja primarni ključ dokumenta. Ideja v tem primeru je dobronamerna, in sicer, ko bodo novi dokumenti ustvarjeni, bodo enakomerno padli v enega izmed razpoložljivih drobcev. Žal je takšna konfiguracija klasična napaka. To je tako, če se ključ za senčenje vedno povečuje, potem ko se bodo točkovni podatki začeli kopičiti na strani velike vrednosti, ki povzročajo neravnovesje v sistemu.

Kreditna slika: mongodb.com

Kot lahko vidite na sliki, ko smo že mimo 20-ih, se vsi dokumenti začnejo zbirati v Chunk C, kar povzroča monolit tam. Rešitev je v tem, da uporabimo shemo ključnega ostrenja, ki ustvari ključ za ostrenje tako, da eno od podanih polj zmeša s pomočjo tega, da določi kos.

Kreditna slika: Mongodb.com

Ključ z razrezanimi deli je videti tako:

{
"_id" :"6b85117af532da651cc912cd"
}

. . . in ga lahko ustvarite v lupini odjemalca Mongo z uporabo:

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

Strga zgodnja

Eden od najbolj uporabnih nasvetov, ki je neposreden iz rovov, je, da zgodaj raztresete, četudi na koncu postavite majhen grozd. Ko bodo podatki prešli 500 GB ali kaj podobnega, postane ostrenje v MongoDB zmeden postopek in morali bi biti pripravljeni na grda presenečenja. Poleg tega postopek izravnave porabi zelo velike količine pasovne širine omrežja, kar lahko zaduši sistem, če niste previdni.

Vendar se vsi ne zaostrijo. Kot zanimiv primer (učenje je res v komentarjih) glej to lepo Percono blog.

Vodenje ravnotežja

Druga dobra ideja je nadzirati prometne vzorce in zagnati izravnalnik oranž le v času nizkega prometa. Kot sem že omenil, je treba pri ponovnem uravnoteženju precej pasovne širine, kar bi lahko celoten sistem hitro priplazilo. Ne pozabite, da neuravnoteženi drobci niso razlog za takojšnjo paniko. Pustite, da se običajna uporaba vztraja, počakajte, da se prikažejo prometne priložnosti z nizkim prometom, in naj pusti ostalo tehtnico!

Tukaj je opisano, kako lahko to dosežete (ob predpostavki, da imate malo prometa od 3. do 5. ure):

uporabi config
db.settings.update (
{_id: "ravnotežje" },
{$ set: {activeWindow: {začetek: "03:00", stop: "05:00" }}},
{upsert: true}
)

Zaključek

Ostritev in spreminjanje številnih podatkovnih baz je zahtevno, vendar MongoDB na srečo omogoča bolj obvladljivost kot druge priljubljene baze podatkov tam.

Res je bil čas, ko MongoDB ni bila prava izbira za noben projekt (zahvaljujoč več kritičnim težavam in privzeto vedenjem), vendar teh že dolgo ni več. MongoDB je poleg ostrenja, ponovnega uravnavanja, samodejnega stiskanja, porazdeljene ključavnice na ravni agregatov in številnih takih funkcij dosegel kilometre naprej, danes pa je prva izbira arhitekta programske opreme.

Upam, da je ta članek lahko osvetlil, kaj je ostrenje v MongoDB in na kaj mora razvijalci paziti, ko gre za merjenje. Če želite izvedeti več, boste morda dobili to spletni tečaj za obvladovanje MongoDB.

Oznake:

  • Baza podatkov

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