Dit artikel verscheen voor het eerst in InfoWorld . Het is herdrukt met toestemming. © IDG Communications, Inc., 2020. Alle rechten voorbehouden Hoe MariaDB wereldwijde schaal bereikt met Xpand. Xpand is nu beschikbaar in MariaDB SkySQL en voegt gedistribueerde SQL toe voor schaalbaarheid en elasticiteit in de cloud.
Naarmate de informatie- en verwerkingsbehoeften zijn gegroeid, hebben pijnpunten zoals prestaties en veerkracht nieuwe oplossingen nodig. Databases moeten ACID-compliance en -consistentie behouden, hoge beschikbaarheid en hoge prestaties bieden en enorme workloads verwerken zonder de resources te belasten. Sharding heeft een oplossing geboden, maar voor veel bedrijven heeft sharding zijn grenzen bereikt vanwege de complexiteit en de benodigde middelen. Een betere oplossing is gedistribueerde SQL.
In een gedistribueerde SQL-implementatie wordt de database gedistribueerd over meerdere fysieke systemen, waardoor transacties op een wereldwijd schaalbaar niveau worden geleverd. MariaDB Platform X5, een belangrijke release met upgrades voor elk aspect van MariaDB Platform, biedt gedistribueerde SQL en enorme schaalbaarheid door de toevoeging van een nieuwe slimme opslagengine genaamd Xpand. Met een gedeelde niets-architectuur, volledig gedistribueerde ACID-transacties en sterke consistentie, stelt Xpand u in staat om te schalen naar miljoenen transacties per seconde.
Geoptimaliseerde inplugbare slimme motoren
MariaDB Enterprise Server is ontworpen om pluggable storage-engines (zoals Xpand) te gebruiken om te optimaliseren voor bepaalde workloads vanaf een enkel platform. Er zijn geen gespecialiseerde databases nodig om specifieke workloads af te handelen. MariaDB Xpand, onze slimme engine voor gedistribueerde SQL, is de meest recente toevoeging aan onze line-up. Xpand voegt enorm schaalbare gedistribueerde transactiemogelijkheden toe aan de opties die door onze andere engines worden geboden. Onze andere pluggable engines bieden optimalisatie voor analytische (kolommen), leeszware workloads en schrijfzware workloads. U kunt gerepliceerde, gedistribueerde en kolomvormige tabellen mixen en matchen om elke database te optimaliseren voor uw specifieke vereisten.
Door MariaDB Xpand toe te voegen, kunnen zakelijke klanten profiteren van alle voordelen van gedistribueerde SQL - snelheid, beschikbaarheid en schaalbaarheid - met behoud van de MariaDB-voordelen waaraan ze gewend zijn.
Laten we eens op hoog niveau bekijken hoe MariaDB Xpand gedistribueerde SQL biedt.
SQL tot in de indexen gedistribueerd
Xpand biedt gedistribueerde SQL door gegevens over knooppunten te segmenteren, te repliceren en te distribueren. Wat betekent dit? We gebruiken een heel eenvoudig voorbeeld met één tabel en drie knooppunten om de concepten te demonstreren. In dit voorbeeld wordt niet getoond dat alle plakjes worden gerepliceerd.
In figuur 1 hierboven hebben we een tabel met twee indexen. De tabel heeft enkele datums en we hebben een index op kolom twee en een andere op kolommen drie en één. Indexen zijn in zekere zin tabellen zelf. Het zijn subsets van de tabel. De primaire sleutel is id , de eerste index in de tabel. Dat is wat zal worden gebruikt om de tabelgegevens te hashen en te verspreiden over de database.
Nu voegen we het begrip plakken toe . Slices zijn in wezen horizontale partities van de tafel. We hebben vijf rijen in onze tabel. In figuur 2 is de tabel opgedeeld en verdeeld. Knooppunt #1 heeft twee rijen. Knooppunt #2 heeft twee rijen en Knooppunt #3 heeft één rij. Het doel is om de gegevens zo gelijkmatig mogelijk over de knooppunten te verdelen.
De indexen zijn ook gesneden en verdeeld. Dit is een belangrijk verschil tussen Xpand en andere gedistribueerde oplossingen. Gewoonlijk hebben gedistribueerde databases lokale indexen, dus elk knooppunt heeft een index van zijn eigen gegevens. In Xpand worden indexen onafhankelijk van de tabel gedistribueerd en opgeslagen. Dit elimineert de noodzaak om een query naar alle nodes te sturen (scatter/gather). In het bovenstaande voorbeeld bevat Node #1 rijen 2 en 4 van de tabel, en ook indexen voor rijen 32 en 35 en rijen april en maart. De tabel en de indexen worden onafhankelijk van elkaar gesegmenteerd, gedistribueerd en gerepliceerd over de knooppunten.
De query-engine gebruikt de gedistribueerde indexen om te bepalen waar de gegevens te vinden zijn. Het zoekt alleen de benodigde indexpartities op en verzendt vervolgens alleen query's naar de locaties waar de benodigde gegevens zich bevinden. Query's worden allemaal uitgedeeld. Ze worden gelijktijdig en parallel uitgevoerd. Waar ze heen gaan, hangt volledig af van de gegevens en wat nodig is om de vraag op te lossen.
Alle plakjes worden minstens twee keer gerepliceerd. Voor elk segment zijn er replica's die zich op andere knooppunten bevinden. Standaard zijn er drie kopieën van die gegevens:het segment en twee replica's. Elk exemplaar bevindt zich op een ander knooppunt en als u in meerdere beschikbaarheidszones zou werken, zouden die exemplaren zich ook in verschillende beschikbaarheidszones bevinden.
Lees- en schrijfverwerking
Laten we nog een voorbeeld nemen. In figuur 3 hebben we vijf instanties van MariaDB Enterprise Server met Xpand (nodes). Er is een tabel om klantprofielen op te slaan. Het segment met het profiel van Shane bevindt zich op Node #1 met kopieën op Node #3 en Node #5. Query's kunnen op elk knooppunt binnenkomen en worden anders verwerkt, afhankelijk van of het lees- of schrijfopdrachten zijn.
Schrijft synchroon naar alle kopieën binnen een gedistribueerde transactie. Elke keer dat ik mijn "Shane" -profiel bijwerk omdat ik mijn e-mailadres of mijn adres heb gewijzigd, gaan die schrijfacties tegelijkertijd naar alle kopieën binnen een transactie. Dit zorgt voor een sterke consistentie.
In Afbeelding 3 ging de UPDATE-instructie naar Knooppunt #2. Er is niets op Knooppunt #2 met betrekking tot mijn profiel, maar Knooppunt #2 weet waar mijn profiel is en stuurt updates naar Knooppunt #1, Knooppunt #3 en Knooppunt #5, voert vervolgens die transactie uit en keert terug naar de toepassing.
Lezen wordt anders behandeld. In het diagram bevindt het segment met mijn profiel erop zich op Knooppunt #1 met kopieën op Knooppunt #3 en Knooppunt #5. Dit maakt Node #1 de ranking replica. Elk segment heeft een rangordereplica, waarvan zou kunnen worden gezegd dat het het knooppunt is dat de gegevens "bezit". Standaard gaat het, ongeacht op welk knooppunt een read binnenkomt, altijd naar de rangschikkingsreplica, dus elke SELECT die naar mij wordt opgelost, gaat naar Node #1.
Zorgt voor elasticiteit
Gedistribueerde databases zoals Xpand veranderen en evolueren voortdurend, afhankelijk van de gegevens in de applicatie. Het rebalancer-proces is verantwoordelijk voor het aanpassen van de gegevensdistributie aan de huidige behoeften en het handhaven van de optimale verdeling van slices over knooppunten. Er zijn drie algemene scenario's die herverdeling vereisen:het toevoegen van knooppunten, het verwijderen van knooppunten en het voorkomen van ongelijke werkbelastingen of 'hot spots'.
Stel bijvoorbeeld dat we met drie knooppunten werken, maar dat het verkeer toeneemt en dat we moeten schalen - we voegen een vierde knooppunt toe om het verkeer af te handelen. Knooppunt #4 is leeg wanneer we het toevoegen zoals weergegeven in Afbeelding 4. De herbalancer verplaatst automatisch slices en replica's om gebruik te maken van Knooppunt #4, zoals weergegeven in Afbeelding 5.
Mocht Node #4 uitvallen, dan gaat de rebalancer automatisch weer aan het werk; deze keer opnieuw segmenten van hun replica's. Er gaan geen gegevens verloren. Replica's worden ook opnieuw gemaakt om degenen die zich op Node #4 bevonden te vervangen, dus alle slices hebben weer replica's op andere nodes om een hoge beschikbaarheid te garanderen.
Afbeelding 6. Als een knooppunt uitvalt, maakt de Xpand-rebalancer de segmenten en replica's die zich op het defecte knooppunt bevonden opnieuw op basis van de replicagegevens op de andere knooppunten.
De werklast in evenwicht brengen
Naast scale-out en hoge beschikbaarheid, vermindert de rebalancer ongelijke verdeling van de werklast - ofwel hotspots of onderbenutting. Zelfs wanneer gegevens willekeurig worden verspreid met een perfect hash-algoritme, kunnen er hotspots optreden. Het kan bijvoorbeeld toeval zijn dat de 10 producten die deze maand te koop zijn, toevallig op Node #1 staan. De gegevens zijn gelijkmatig verdeeld, maar de werklast niet (Figuur 7). In dit type scenario zal de herbalancer de segmenten herverdelen om het gebruik van hulpbronnen in evenwicht te brengen (Figuur 8).
Afbeelding 7. Xpand heeft de gegevens gelijkmatig verdeeld, maar de werkbelasting is ongelijkmatig. Knooppunt 1 heeft een aanzienlijk hogere werklast dan de andere drie knooppunten.
Afbeelding 8. Xpand-rebalancer verdeelt gegevenssegmenten opnieuw om de werklast over knooppunten te verdelen.
Schaalbaarheid, snelheid, beschikbaarheid, balans
De behoefte aan informatie en verwerking zal blijven groeien. Dat is een gegeven. MariaDB Xpand biedt een consistente, ACID-compatibele schaaloplossing voor ondernemingen met vereisten waaraan niet kan worden voldaan met andere alternatieven zoals replicatie en sharding.
Gedistribueerde SQL biedt schaalbaarheid en MariaDB Xpand biedt de flexibiliteit om te kiezen hoeveel schaalbaarheid u nodig hebt. Verspreid één tabel of meerdere tabellen of zelfs uw hele database, de keuze is aan u. Operationeel kan de capaciteit eenvoudig worden aangepast aan de veranderende werklast op elk moment. U hoeft nooit overprovisioning te hebben.
Xpand beschermt ook transparant tegen ongelijkmatig gebruik van bronnen, door gegevens dynamisch opnieuw te verdelen om de werklast over knooppunten te verdelen en hotspots te voorkomen. Ontwikkelaars hoeven zich geen zorgen te maken over schaalbaarheid en prestaties. Xpand is elastisch. Xpand biedt ook redundantie en hoge beschikbaarheid. Met gegevens die worden gesegmenteerd, gerepliceerd en gedistribueerd over knooppunten, worden gegevens beschermd en blijft redundantie behouden in het geval van hardwarestoringen.
En met de architectuur van MariaDB zullen je gedistribueerde tafels goed spelen - inclusief cross-engine JOINs - met je andere MariaDB-tafels. Creëer de database-oplossing die u nodig hebt door gerepliceerde, gedistribueerde of kolomvormige tabellen te mixen en matchen, allemaal in één database op MariaDB Platform.