Hvad er Database Sharding?<\/h2>\n
Sharding er en optimeringsteknik, der distribuerer tabeller p\u00e5 tv\u00e6rs af andre databaseservere. Det er ligesom partitionering i den forstand, at begge involverer opdeling af data i mindre delm\u00e6ngder. Forskellen er, at sharding fordeler disse delm\u00e6ngder p\u00e5 forskellige servere, mens partitionering gemmer dem i \u00e9n database. Disse servere bruger den samme databasemotor og hardwaretype for at opn\u00e5 et lignende ydelsesniveau for alle shards.<\/p>\n
Sharding har til form\u00e5l at opn\u00e5 en arkitektur med deling af intet, hvilket eliminerer flaskehalse i behandlingen og enkeltst\u00e5ende fejlpunkter.<\/p>\n Du kan implementere sharding p\u00e5 to m\u00e5der – horisontalt<\/a> og vertikalt. Horisontal sharding opdeler tabellen baseret p\u00e5 r\u00e6kker, mens vertikal sharding opdeler tabellerne baseret p\u00e5 kolonner.<\/p>\n I denne henseende er sharding ligesom partitionering, som opdeler store tabeller i mindre tabeller.<\/p>\n Horisontal sharding er effektiv til databaser, hvor de fleste foresp\u00f8rgsler returnerer en delm\u00e6ngde af r\u00e6kker, f.eks. en kundedatabase, der returnerer data (f.eks. navn, adresse, e-mail osv.) p\u00e5 en gang.<\/p>\n Vertikal sharding er effektiv til databaser, hvis foresp\u00f8rgsler returnerer enkelte kolonner. Hvis kundedatabasen f.eks. returnerede kundens navn eller e-mail separat, kunne du adskille navn og e-mail i forskellige klynger.<\/p>\n Nedenfor er nogle af fordelene ved database-sharding.<\/p>\n Du kan skalere din database vertikalt eller horisontalt. Vertikal skalering henviser til tilf\u00f8jelse af flere CPU’er (central processing units) og RAM-hukommelse (random access memory) til serveren for at forbedre ydeevnen. Vertikal skalering er en nyttig l\u00f8sning for sm\u00e5 til mellemstore databaser. N\u00e5r dine data vokser, bliver vertikal skalering imidlertid uoverkommelig. Der er kun et vist antal kr\u00e6fter, som du kan tilf\u00f8je til en enkelt server.<\/p>\n Horisontal skalering er mere fleksibel. Den giver dig mulighed for at skalere din database efter behov ved at tilf\u00f8je flere servere til dit system. Hver af disse servere leverer ressourcer til forskellige databaseshards. Dette fordeler arbejdsbyrden og forbedrer systemets evne til at h\u00e5ndtere flere anmodninger.<\/p>\n Shards har kun f\u00e5 r\u00e6kker og kolonner. P\u00e5 grund af dette tager det mindre tid at behandle databaseforesp\u00f8rgsler<\/a>. I mods\u00e6tning hertil kan en foresp\u00f8rgsel i en ikke-sharded database kr\u00e6ve en s\u00f8gning gennem hundredvis – eller endog tusindvis – af r\u00e6kker.<\/p>\n Databasestop kan forekomme af forskellige \u00e5rsager, herunder utilsigtet sletning af data, forbindelsesfejl og cybersikkerhedsangreb. Sharding minimerer virkningerne af nedbrud. Da hver shard er selvst\u00e6ndig, er det kun den ber\u00f8rte shard, der er udsat for nedetid. Hvis du f.eks. har fire shards og oplever et nedbrud i en af dem, vil kun 25 procent af driften blive p\u00e5virket.<\/p>\n Selv om sharding forbedrer en databases p\u00e5lidelighed og tilg\u00e6ngelighed, er det komplekst at implementere det<\/a>. Brug af den forkerte sharding-arkitektur kan s\u00e6nke ydelsen og f\u00f8re til tab af data.<\/p>\n S\u00f8rg for at v\u00e6lge en sharding-teknik, der giver mulighed for en afbalanceret datafordeling p\u00e5 tv\u00e6rs af alle shards. Uden denne balance risikerer du at skabe databasehotspots, hvilket sker, n\u00e5r en shard lagrer de fleste data, mens andre shards praktisk talt forbliver tomme. Dette reducerer skrivegennemstr\u00f8mningen til den enkelte shard.<\/p>\n For at l\u00f8se dette problem kan du partitionere den ubalancerede shard endnu mere, men denne proces er udfordrende og kan l\u00e6gge din database ned, mens du migrerer data.<\/p>\n En anden ulempe ved sharding er, at SQL-joins, der involverer flere tabeller i forskellige shards, kan blive for langsomme og forringe ydelsen. Med den rigtige arkitektur kan du dog undg\u00e5 dette problem.<\/p>\n Du kan implementere sharding ved hj\u00e6lp af tre arkitekturer:<\/p>\n Den arkitektur, du v\u00e6lger, afh\u00e6nger af dit brugsscenarie.<\/p>\n I en n\u00f8gle- eller hash<\/a>-baseret sharding-arkitektur bruger et databaseprogram en shardn\u00f8gle til at finde en shard. En hashing-funktion hasher sharding-n\u00f8glev\u00e6rdien, og resultatet mapper data til en bestemt shard. En simpel hashing-funktion kan v\u00e6re modulet af n\u00f8glen og antallet af shards.<\/p>\n Hashfunktionen kan tage mere end \u00e9n n\u00f8gle til opdeling af sharding. Derfor er n\u00f8glebaseret sharding velegnet til dataposter, der kan have f\u00e6lles n\u00f8gler. Algoritmisk fordeling af data minimerer muligheden for at skabe database-hotspots, hvor den ene shard indeholder flere data end den anden.<\/p>\n Da fordelingen imidlertid kun er afh\u00e6ngig af hashing-funktionen, er det umuligt at gruppere data logisk sammen. Derfor kan databaseoperationer, der kr\u00e6ver data fra flere shards, v\u00e6re ineffektive, da de kr\u00e6ver l\u00e6sning af data fra hver shard.<\/p>\n Omr\u00e5debaseret sharding<\/a> indeb\u00e6rer sharding af en database afh\u00e6ngigt af et bestemt interval af v\u00e6rdier.<\/p>\n Der bruges en shardingn\u00f8gle til at bestemme, hvilken shard en v\u00e6rdi skal tildeles. Databaseprogrammet kontrollerer den shard, der svarer til shardingn\u00f8glen i en opslagstabel, og gemmer dataene. P\u00e5 grund af dette er intervalbaseret sharding let at designe og implementere.<\/p>\n Du kan f.eks. bruge bruger-ID-v\u00e6rdien i en brugerdatabase som shardingn\u00f8gle. Du kan gemme brugere med ID’er fra 0-2.000 p\u00e5 en shard, brugere med ID’er mellem 2.000 og 4.000 p\u00e5 en anden shard osv.<\/p>\n Omr\u00e5debaseret sharding kan for\u00e5rsage databasehotspots. T\u00e6nk p\u00e5 en brugerdatabase, hvor de fleste af dine bruger-id’er ligger mellem 2.001 og 4.000. Processen tildeler dem til en enkelt shard, hvilket skaber en ubalance over tid. Omr\u00e5debaseret sharding fungerer derfor bedst til j\u00e6vnt fordelte data.<\/p>\n Katalogbaseret sharding<\/a> grupperer logisk relaterede data i den samme shard. Der anvendes en opslagstabel, som indeholder en liste over mappinger for hver enhed i databasen. Hver mapping svarer til en database shard.<\/p>\n Katalogbaseret sharding er mere fleksibel end omr\u00e5debaseret eller n\u00f8glebaseret sharding, fordi du kan tilf\u00f8je data til shards dynamisk. Der er ingen sharding-funktion, som du skal f\u00f8lge, eller intervalv\u00e6rdier, som du skal holde dig inden for. Denne fleksibilitet \u00f8ger databasens effektivitet: Du kan gemme relaterede data i \u00e9n shard, hvilket betyder, at det tager mindre tid at udf\u00f8re almindelige foresp\u00f8rgsler.<\/p>\n Hvis du f.eks. har brugt mappebaseret sharding og grupperet brugere efter deres placering, og du henter brugere fra et bestemt sted, skal du kun foresp\u00f8rge p\u00e5 en enkelt shard.<\/p>\n De fleste moderne databasemotorer underst\u00f8tter database-sharding. En af disse databasemaskiner er MariaDB, en kommercielt underst\u00f8ttet fork af MySQL. Det er et h\u00f8jtydende open source-databasesystem, der er vedtaget af virksomheder som IBM, GitHub og Wikimedia. Det er ogs\u00e5 en del af den h\u00f8jtydende serverstack hos Kinsta.<\/p>\n MariaDB tilbyder indbyggede sharding-funktioner gennem spider storage engine<\/a>. Spider storage engine er en klyngedannelsesmotor, der underst\u00f8tter partitionering og XA-transaktioner (extended architecture). Den giver dig mulighed for at behandle fjerntabeller fra forskellige instanser, som om de er i den samme instans. N\u00e5r du opretter en tabel i spider storage-motoren, linker tabellen til en anden tabel i den eksterne MariaDB-server. N\u00e5r forbindelsen er etableret, deler lagermotoren linket med alle tabeller, der er en del af den samme transaktion.<\/p>\n Database sharding er en skaleringsteknik, der opdeler tabeller i mindre delm\u00e6ngder og distribuerer dem til forskellige servere kaldet shards. Du kan implementere sharding p\u00e5 forskellige m\u00e5der, f.eks. n\u00f8glebaseret sharding, omr\u00e5debaseret sharding og mappebaseret sharding.<\/p>\n Selvom sharding forbedrer en databases skalerbarhed, p\u00e5lidelighed og tilg\u00e6ngelighed, er det meget komplekst at implementere. N\u00e5r du f\u00f8rst har oprettet en sharding, er det desuden ikke let at vende databasen tilbage til dens ushardede tilstand. P\u00e5 grund af dette skal du kun bruge sharding til optimering, n\u00e5r du er sikker p\u00e5, at andre muligheder for skalerbarhed ikke vil fungere.<\/p>\n Uanset om din virksomhed er en nonprofit<\/a>-virksomhed eller en virksomhed p\u00e5 virksomhedsniveau<\/a>, kan Kinas ekspertl\u00f8sninger fjerne dine bekymringer med hensyn til webstedshosting, s\u00e5 du kan fokusere p\u00e5 det, der betyder mest.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":" Oprettelse af et websted er det f\u00f8rste skridt, n\u00e5r du etablerer din tilstedev\u00e6relse p\u00e5 internettet. Hvis du skal klare dig godt p\u00e5 l\u00e6ngere sigt, skal du …<\/p>\n","protected":false},"author":117,"featured_media":46656,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_kinsta_gated_content":false,"_kinsta_gated_content_redirect":"","footnotes":""},"tags":[],"topic":[738],"class_list":["post-46655","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","topic-tekniske-tips"],"yoast_head":"\n![\"En](\"https:\/\/kinsta.com\/wp-content\/uploads\/2022\/11\/database-sharding-example.png\")
Fordele ved database-sharding<\/h2>\n
Forbedret horisontal skalering<\/h3>\n
Hurtigere svartider p\u00e5 foresp\u00f8rgsler<\/h3>\n
\u00d8get p\u00e5lidelighed i situationer med afbrydelser<\/h3>\n
Ulemper ved sharding<\/h2>\n
Sharding-arkitekturer<\/h2>\n
\n
N\u00f8glebaseret sharding<\/h3>\n
Omr\u00e5debaseret sharding<\/h3>\n
Katalogbaseret sharding<\/h3>\n
Database Sharding med Kinsta<\/h2>\n
Oversigt<\/h2>\n