Šardas (duomenų bazė)

Straipsnis iš Vikipedijos, laisvosios enciklopedijos.
Jump to navigation Jump to search
 Broom icon.svg  Šį puslapį ar jo dalį reikia sutvarkyti pagal Vikipedijos standartus.
Jei galite, sutvarkykite.

Duomenų bazės šardas (angl. šukė) yra horizontalus DB arba paieškos variklio duomenų skaidymo būdas. Kiekvienas fragmentas yra vadinamas DB  šardu. Kiekvienas šardas yra laikomas skirtingame DB serveryje kad būtų galima subalansuoti DB apkrovimą.

Kai kurie DB duomenys išlieka visuose DB šarduose, bet kai kurie iš jų yra tik tam tikrame DB šarde. Kiekvienas DB šardas veikia kaip vienintelis duomenų šaltinis pasirinktam duomenų poaibiui. [1]

Duomenų bazės architektūra[redaguoti | redaguoti vikitekstą]

Horizontalus segmentavimas yra duomenų bazių projektavimo principas, pagal kurį atskirai yra laikomos duomenų bazės eilutės, o ne  stulpeliai (pastaruoju atveju yra atliekamas normalizavimas ir vertikalus segmentavimas). Kiekvienas segmentas suformuoja DB šardą, kuris gali būti saugoma skirtingoje duomenų bazėje ar netgi skirtingoje fizinėje vietoje.

Horizontalus segmentavimas turi daug privalumų. Kadangi lentelės yra išskirstomos į daugelį serverių, bendra eilučių suma kiekviename serveryje sumažėja. Tai sumažina DB indekso dydį, kas padidina paieškos greitaveiką. Duomenų bazės šardas gali būti paleidžiamas ant atskiros fizinės mašinos, keli DB šardai gali būti paleidžiami ant kelių mašinų. Tai leidžia išskirstyti duomenų bazę per kelias fizines mašinas taip smarkiai pagerinant greitaveiką. Be to, toks duomenų bazės segmentavimas leidžia segmentuoti duomenis pagal skirtingus klientų poreikius (pvz., Europos klientams ir Amerikos klientams), tuomet galima nesunkiai pasirinkti reikiamą DB šardą ir formuoti užklausą tik jam.[2]

Trūkumai:

  • Didesnė priklausomybė nuo ryšio tarp serverių
  • Padidėja DB dalsa atliekant užklausas, ypač tais atvejais kai paieška turi būti atliekama daugiau nei viename DB šarde.
  • Duomenys arba indeksai dažnai yra suskaldomi tik vienu pjūvių, tad kai kurios užklausos yra optimalios, tačiau kitos yra lėtos arba apskritai neįmanomos.
  • Duomenų integralumo ir nuoseklumo užtikrinimas tampa sudėtingesniu dėl sudėtingesnių paskirstytos DB sutrikimų tipų, kas dažnai sąlygoja, kad negalima užtikrinti duomenų pilnumo ir išliekamumo tarp skirtingų DB šardų.[reikalingas šaltinis][reikalingas šaltinis][reikalingas šaltinis]

Praktiškai įgyvendinti DB skaidymą šardais yra sudėtinga. Ilgą laiką tai buvo daroma rankomis (ypač tais atvejais kai eilutės gali būti nesunkiai sugrupuotos, kaip pavyzdyje viršuje), tačiau tai buvo nelankstus būdas. Nuosekli maiša (angl. consistent hashing) yra vienas iš automatinių skaidymo į šukes būdų, skirtas išskaidyti didelias apkrovas keliems serveriams.[3]

Šardavimas lyginant su horizontaliu segmentavimu[redaguoti | redaguoti vikitekstą]

Horizontalus segmentavimas išdalina vieną arba daugiau lentelių eilutėmis, dažniausiai vienos schemos ir duomenų bazės serverio ribose. Jis gali pasiūlyti pranašumą sumažindamas indekso dydį (taigi ir paieškos trukmę), su sąlyga, kad egzistuoja keletas pastovių ir akivaizdžių būdų nustatyti kuriame DB šarde galima rasti norimą eilutę prieš tai neatlikus paieškos indekse, klasikinis pavyzdys - lentelės "KaunoKlientai" ir "VilniausKlientai", kuriose išskirstymo pagal DB šardus kriterijus yra pašto indeksas.

Šardavimas atlieka daugiau nei horizontalų segmentavimą: jis išdalina problemines lenteles tokiu pat būdu kaip ir horizontalus segmentavimas, tačiau išskaidymas taip pat yra atliekamas ir tarp daugelio tos pačios schemos kopijų. Akivaizdus šio išskaidymo privalumas yra tas, kad daugelio paieškų apkrovos gali būti išskaidytos į kelis serverius (tiek loginius, tiek fizinius), vietoj paprasto išskaidymo į indeksus viename serveryje.

Šardavimas tarp skirtingų izoliuotų egzempliorių reikalauja ne tik horizontalaus išskaidymo. Tikėtina efektyvumo nauda prarandama, jei DB užklausa reikalauja atlikti užklausą abiejuose šarduose vien tam, kad gauti paprastą aspektų lentelę. Apart segmentavimo, šardavimas išdalina padalintinas lenteles tarp serverių, o mažesnės lentelės yra tiesiog pilnai perkopijuojamos.

Dėl šios priežasties šardavimas taip pat yra susijęs su nieko nesidalinimo architektūra — vieną kartą šarduoti duomenys atsiduria visiškai atskiroje atskirame loginės schemos kopijoje / fiziniame DB serveryje / duomenų centre / žemyne. Nebelieka poreikio nuolat išlaikyti bendrą prieigą (iš šardų) į kitas neišdalintas lenteles ir kitus šardus.

Ši architektura užtikrina lengvą replikaciją keliuose serveriuose (paprastas horizontalus segmentavimos to neužtikrina). Tai tai pat naudinga globaliam debesinių aplikacijų duomenų išskirstymui, kur naudojant kitą architektūrą ryšio kanalas tarp skirtingų duomenų centrų taptu butelio kakleliu.

Tarp skirtingų šardų išlieka poreikis turėti notifikavimo ir replikavimo mechanizmus tarp schemų kopijų tam, kad neišdalintos lentelės būtų sinchronizuotos. Tai sudėtingas šardinės architektūros klausimas, sprendimai varijuoja nuo tarp "read-only" atnaujinimų (jie būna reti ir atliekami visiems šardams iš karto) iki dinamiškai replikuojamų lentelių (prarandant kai kuriuos šardingo privalumus) ir įvarių šių strategijų kombinacijų.

Šardingą naudojančios sistemos[redaguoti | redaguoti vikitekstą]

Apache HBase
HBase numato automatinį sharding.[4]
Azure SQL Database Elastic Database tools
leidžia aplikacijos duomenų sluoksnį šardinti naudojant yprastus šardingo metodus[5]
Couchbase
Couchbase numato automatinį skaidrų šardingą, taip užtikrindamas didžausią greitaveiką.
CUBRID
CUBRID leidžia šardingą nuo 9.0 versijos
Elasticsearch
Elasticsearch enterprise search server.[6]
eXtreme Scale
eXtreme Scale yra tarpprocesinė atmintyje saugomų raktų/verčių saugykla (vienas iš NoSQL duomenų saugyklos variantų). Ji naudoja šardingą pasiekti skeilingui tarp procesų tiek duomenims tiek MapReduce tip duomenų apdorojimui.[7]
Hibernate ORM
Hibernate palaiko šardus nuo 2007 metų, tačiau nuo to laiko buvo mažai atnaujinimų.[8][9]
IBM Informix
IBM užtikrina Informix šardingą nuo 12.1 xC1 versijos kaip MACH11 technologiją. Informix 12.10 xC2 palaiko visišką suderinamumą su MongoDB tvarkyklėmis, kas užtikrina paprastų reliacinių DB darbą su NoSQL prisijungimais tuo pačiu užtikrinant šardingą, failoverį ir ACID (tranzakcines) sąvybes.[10][11]
Kdb+
Kdb+ leidžia šardingą nuo 2.0 versijos.
MonetDB
atviro kodo stulpeių saugykla MonetDB 2015 m. liepos versijoje leidžia šardingą skaitymui.[12]
MongoDB
MongoDB leidžia sharding nuo 1.6 versijos.
MySQL Cluster
Auto-Sharding: duomenų bazė yra automatiškai ir skaidriai išskaidoma tarp visų žemų kaštų serverių, taip užtikrinant skaitymo ir rašymo užklausų skeilinimą, tuo pačiu nereikalaujant modifikuoti pačios aplikacijos.[13]
MySQL Fabric (MySQL utilities dalis) palaiko šardingą.[14]
"Oracle" NoSQL duomenų bazė

"Oracle" NoSQL duomenų bazė turi automatizuotą šardingą, taip pat galimybę plėsti elastinį klasterį dinamiškai (pridedant papildomus šardus).

OrientDB
OrientDB leidžia šardingą nuo 1.7 versijos.
pg_shard
PostgreSQL plėtinys šardingo palaikymui. Jis šardina ir replikuoja PostgreSQL lenteles horizontaliai didelės greitaveikos užtikrinimui. Šis plėtinis taip pat lygiagrečiai išskirsto SQL užklausas nereikalaudamas pačios aplikacijos modifikacijos.[15]
Įskiepiai Grails
Grails palaiko šardingą naudojant Grails Sharding Plugin.[16]
Ruby ActiveRecord
Octopus yra ActiveRecord ORM šardingo ir replikavimo plėtinys.
ScaleBase's Data Traffic Manager
ScaleBase duomenų srauto valdytojas yra produktas, skirtas automatizuoti MySQL duomenų bazės šardingą be poreikio modifikuoti pačias aplikacijas.[17]
Shard Query
Atvirojo kodo lygiagrečių užklausų variklis MySQL.[18]
Solr Search Server
Solr paieškos variklis palaiko šardingą.[19]
Spanner
Spanner, "Google" globali išskirstytoji duomenų bazė, šardina duomenis keliuose Paxos būsenų automatuose, taip palaikydama "milijonus mašinų šimtuose duomenų centrų su trilijonais duomenų bazių eilučių".[20]
SQLAlchemy ORM
SQLAlchemy yra Python programavimo kalbos duomenų mapping'o kalba suteikianti šardingo galimybes.[21]
Teradata
Teradata DWH buvo pirmoji masinė lygiagrečioji DB.[reikalingas šaltinis]

Nuorodos[redaguoti | redaguoti vikitekstą]

  1. Pramod J. Sadalage & Martin Fowler (2012), "4: Distribution Models", NoSQL Distilled, ISBN 0321826620 
  2. Rahul Roy (July 28, 2008). „Shard - A Database Design“. 
  3. Tuščia citata (pagalba) 
  4. Tuščia citata (pagalba) 
  5. Tuščia citata (pagalba) 
  6. Tuščia citata (pagalba) 
  7. http://publib.boulder.ibm.com/infocenter/wxsinfo/v7r1/index.jsp?topic=%2Fcom.ibm.websphere.extremescale.over.doc%2
  8. Tuščia citata (pagalba) 
  9. Tuščia citata (pagalba) 
  10. Tuščia citata (pagalba) 
  11. Tuščia citata (pagalba) 
  12. Tuščia citata (pagalba) 
  13. „MySQL Cluster Features & Benefits“. 2012-11-23. 
  14. Tuščia citata (pagalba) 
  15. Tuščia citata (pagalba) 
  16. Tuščia citata (pagalba) 
  17. Tuščia citata (pagalba) 
  18. Tuščia citata (pagalba) 
  19. Tuščia citata (pagalba) 
  20. Tuščia citata (pagalba) 
  21. Tuščia citata (pagalba) 

Nuorodos[redaguoti | redaguoti vikitekstą]