Overgang fra en RDBMS-modell til HBase-dummies

Hvis du står overfor designfasen for din søknad, og du tror at HBase ville passe bra, så utformer du radnøklene og skjemaet for å passe til HBase-datamodellen og arkitekturen. riktig tilnærming. Men noen ganger er det fornuftig å flytte en database opprinnelig designet for en RDBMS til HBase.

Et vanlig scenario der denne tilnærmingen gir mening er en MySQL-databaseeksempel som har nådd grenser for skalerbarhet. Teknikker eksisterer for horisontal skalering av en MySQL-forekomst ( sharding, med andre ord), men denne prosessen er vanligvis tungvint og problematisk fordi MySQL rett og slett ikke var opprinnelig utformet for sharding.

Overgang fra relasjonsmodellen til HBase-modellen er en relativt ny disiplin. Imidlertid utvikler visse etablerte tankemønstre seg og har sammenblandet seg i tre sentrale prinsipper som skal følges når man nærmer seg en overgang. Disse prinsippene er denormalisering, duplisering, og intelligente nøkler (DDI) .

• Denormalisering: Relasjonsdatabasemodellen avhenger av a) et normalisert databaseskema og b) knytter seg til tabeller for å svare på SQL-operasjoner. Database normalisering er en teknikk som beskytter mot tap av data, redundans og andre uregelmessigheter ettersom data oppdateres og hentes.

  Det finnes en rekke regler som eksperterne følger for å komme til et normalisert databaseskema (og databasen normalisering er en hel studie selv), men prosessen innebærer vanligvis å dele større tabeller i mindre tabeller og definere relasjoner mellom dem. Database denormalisering er motsatt av normalisering, hvor mindre, mer spesifikke tabeller blir slått sammen i større, mer generelle tabeller.

  Dette er et vanlig mønster når du overfører til HBase fordi det ikke er gitt sammenføyninger på tvers av tabeller, og sammenføyning kan være sakte siden de involverer kostbare diskoperasjoner. Å overvåke oppdateringen og gjenoppretting av anomalier er nå jobben i ditt HBase-klientprogram, siden beskyttelsene du gir ved normalisering, er ugyldige.

• Duplisering: Når du deformaliserer databaseskjemaet ditt, vil du sannsynligvis ende opp med å duplisere dataene fordi det kan hjelpe deg med å unngå kostbare leseoperasjoner på tvers av flere tabeller. Ikke vær bekymret for ekstra lagring (innen grunn selvfølgelig); Du kan bruke den automatiske skalerbarheten til HBase til din fordel.

  Vær oppmerksom på at det ekstra arbeidet ditt vil kreve at klientprogrammet ditt dupliserer dataene, og husk at nasjonalt HBase bare gir rodenivå atomoperasjoner ikke krysser rad (med unntaket beskrevet i HBASE-5229 JIRA) eller kryss bord.

• Intelligent Keys: Fordi dataene som er lagret i HBase, er ordnet med radnøkkel, og radnøkkelen er den eneste innfødte indeksen som leveres av systemet, kan en forsiktig intelligent utforming av radnøkkelen gjøre en stor forskjell. For eksempel kan radnøkkelen være en kombinasjon av et bestillingsordrenummer og kundens ID-nummer som plasserte serviceordren.

  Med dette radnøkkedesignet kan du slå opp data relatert til serviceordren eller slå opp data knyttet til kunden ved å bruke samme radnøkkel i samme tabell. Denne teknikken vil bli raskere for noen spørsmål og unngå kostbare tabeller.

For å klargjøre disse spesielle tankemønstrene, ta en Kundekontaktinformasjonstabell og plasser den i sammenheng med en typisk serviceordningsdatabase. Figuren viser deg hva et normalisert serviceordningsdatabaseskema kan se ut.

Følg reglene for RDBMS-normalisering ved å sette opp kundens kontaktinformasjonstabell slik at den er skilt fra serviceordetabellen for å unngå å miste kundedata når serviceordrer er stengt og muligens slettet. Ta samme tilnærming til produkttabellen, noe som betyr at nye produkter kan legges til den fiktive bedriftsdatabasen uavhengig av serviceordrer.

Ved å stole på RDBMS-tilknytningsoperasjoner, støtter dette skjemaet spørringer som viser antall serviceordrer som åpnes mot et bestemt produkt sammen med kundens sted hvor produktet er i bruk.

Det er greit og dumt, men det er et skjema du vil bruke med RDBM. Hvordan overfører du dette skjemaet til et HBase-skjema? Neste figur illustrerer en mulig HBase-skjema - en som følger DDI-mønsteret.

Kundekontaktinformasjonstabellen er blitt denormalisert ved å inkludere kundenavnet og kontaktinformasjonen i stedet for de fremmede nøklene som tidligere ble brukt. Også, dataene blir duplisert ved å holde tabellen Customer Contact Information som det er. Nå går det på tvers av Service Order-tabellen, og kundetilknytningsinformasjonstabellen er ikke nødvendig.

I tillegg er det brukt en intelligent radnøkkeldesign som kombinerer produktnummeret med kundenummeret for å danne bestillingsnummeret (f.eks. A100 | 00001). Ved hjelp av denne intelligente nøkkelen kan serviceordetabellen gi viktige rapporter om produktmangler og kunder som for tiden opplever produktproblemer.

Alle disse spørringene kan alle støttes av HBase på radnivå atommote for applikasjonen. Fordi du vet at HBase ordner radnøkler og sorterer dem på en leksikografisk måte, kan søknaden din gjøre visse utdannede gjetninger om datalokalitet ved utstedelse av skanninger for rapportering. (Alle A * -serienummer vil bli lagret sammen, for eksempel.)

Serviceordningsdatabasen representert ved HBase-skjemaet er et relativt enkelt eksempel, men det illustrerer hvordan HBase i visse tilfeller kan krysse med RDBMS-verdenen og gir betydelig verdi. Hvis det fiktive selskapet har terabytes eller til og med petabytes av serviceanropsdata som skal lagres, ville HBase gjøre en stor forskjell når det gjelder kostnad, pålitelighet, ytelse og skala.

Du kan selvfølgelig utforme ditt HBAS-bestillingsskjema på flere forskjellige måter. Helt klart er utformingen alt avhengig av spørsmålene som må støttes, men du har muligheten til å overføre noen relasjonsdatabaser til meget kraftige HBase-applikasjoner for produksjon, så lenge du jobber med en solid forståelse av HBase-arkitekturen og DDI-mønsteret.

Dette eksemplet har antatt at forespørsler ble utført av et Java-program som utnytter HBase-klient-APIer, eller kanskje via et annet språk ved hjelp av Apache Thrift. Denne applikasjonsmodellen passer perfekt til kravene og gir nyttige ytelses- og tilpasningsalternativer for det fiktive servicefirmaet.