Šardas (duomenų bazė)

Šį 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. 

Duomenų bazės architektūra

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.

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]}

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 dideles apkrovas keliems serveriams.

Šardavimas lyginant su horizontaliu segmentavimu

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 įvairių šių strategijų kombinacijų.

Šardingą naudojančios sistemos

Apache HBase

HBase numato automatinį sharding.

Azure SQL Database Elastic Database tools

leidžia aplikacijos duomenų sluoksnį šardinti naudojant yprastus šardingo metodus

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.

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.

Hibernate ORM

Hibernate palaiko šardus nuo 2007 metų, tačiau nuo to laiko buvo mažai atnaujinimų.

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.

Kdb+

Kdb+ leidžia šardingą nuo 2.0 versijos.

MonetDB

atviro kodo stulpeių saugykla MonetDB 2015 m. liepos versijoje leidžia šardingą skaitymui.

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.

MySQL Fabric (MySQL utilities dalis) palaiko šardingą.

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

Įskiepiai Grails

Grails palaiko šardingą naudojant Grails Sharding Plugin.

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.

Shard Query

Atvirojo kodo lygiagrečių užklausų variklis MySQL.

Solr Search Server

Solr paieškos variklis palaiko šardingą.

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ų".

SQLAlchemy ORM

SQLAlchemy yra Python programavimo kalbos duomenų mapping'o kalba suteikianti šardingo galimybes.

Teradata

Teradata DWH buvo pirmoji masinė lygiagrečioji DB.^{[reikalingas šaltinis]}

Nuorodos

• Informix JSON duomenų sharding Archyvuota kopija 2015-07-04 iš Wayback Machine projekto.