Overgang van een RDBMS-model naar HBase - dummies

Als u geconfronteerd wordt met de ontwerpfase voor uw toepassing en u gelooft dat HBase een goede match zou zijn, dan is het ontwerpen van uw rijsleutels en schema om in te passen op het HBase-gegevensmodel en de architectuur de juiste aanpak. Soms is het echter zinvol om een ​​database te verplaatsen die oorspronkelijk is ontworpen voor een RDBMS naar HBase.

Een veelvoorkomend scenario waarbij deze aanpak zinvol is, is een MySQL-databasetoepassing die de grenzen van schaalbaarheid heeft bereikt. Technieken bestaan ​​voor het horizontaal schalen van een MySQL-instantie ( sharding, met andere woorden), maar dit proces is meestal omslachtig en problematisch omdat MySQL eenvoudig niet oorspronkelijk was ontworpen voor sharding.

Overgang van het relationele model naar het HBase-model is een relatief nieuwe discipline. Bepaalde gevestigde denkpatronen zijn echter in opkomst en zijn samengevoegd in drie hoofdprincipes die moeten worden gevolgd bij het naderen van een transitie. Deze principes zijn denormalisatie, duplicatie, en intelligente sleutels (DDI) .

• Denormalisatie: Het relationele databasemodel is afhankelijk van a) een genormaliseerd databaseschema en b) joins tussen tabellen om te reageren op SQL-bewerkingen. Database-normalisatie is een techniek die gegevensverlies, redundantie en andere anomalieën beschermt wanneer gegevens worden bijgewerkt en opgehaald.

  Er zijn een aantal regels die de experts volgen om tot een genormaliseerd databaseschema te komen (en database-normalisatie is een volledige studie zelf), maar het proces omvat meestal het verdelen van grotere tabellen in kleinere tabellen en het definiëren van relaties tussen hen. Database denormalisatie is het tegenovergestelde van normalisatie, waarbij kleinere, meer specifieke tabellen worden samengevoegd in grotere, meer algemene tabellen.

  Dit is een gebruikelijk patroon bij het overstappen naar HBase, omdat joins niet worden aangeboden in tabellen en joins soms traag zijn omdat ze dure schijfbewerkingen met zich meebrengen. Bewaken tegen de anomalieën voor het bijwerken en ophalen is nu de taak van uw HBase-clienttoepassing, omdat de beveiligingen die u door normalisatie worden geboden, nietig en ongeldig zijn.

• Duplicatie: Terwijl u uw databaseschema denormaliseert, zult u waarschijnlijk de gegevens dupliceren omdat het u kan helpen kostbare leesbewerkingen in meerdere tabellen te voorkomen. Maak je geen zorgen over de extra opslag (uiteraard binnen de rede); u kunt de automatische schaalbaarheid van HBase in uw voordeel gebruiken.

  Houd er echter rekening mee dat extra werk door uw clienttoepassing nodig zal zijn om de gegevens te dupliceren en onthoud dat native alleen op atomaire operaties op rijniveau niet in de rij voorkomt (met de uitzondering die wordt beschreven in de HBASE-5229 JIRA) of kruis tafel.

• Intelligente sleutels: Omdat de gegevens die in HBase zijn opgeslagen, per rijsleutel worden gerangschikt en de rijsleutel de enige door het systeem geleverde native index is, kan een zorgvuldig intelligent ontwerp van de rijsleutel een groot verschil maken. Uw rijsleutel kan bijvoorbeeld een combinatie zijn van een serviceordernummer en het ID-nummer van de klant dat de serviceorder heeft geplaatst.

  Met dit ontwerp met rijsleutels kunt u gegevens met betrekking tot de serviceorder opzoeken of gegevens met betrekking tot de klant opzoeken met dezelfde rijsleutel in dezelfde tabel. Deze techniek zal sneller zijn voor sommige zoekopdrachten en dure tafeljoins vermijden.

Om deze specifieke denkpatronen te verduidelijken, neemt u een tabel met klantcontactinformatie en plaatst u deze in de context van een typische database met serviceorders. In de afbeelding ziet u hoe een genormaliseerd database-schema voor serviceorders eruit kan zien.

Volg de regels voor RDBMS-normalisatie door de voorbeeldtabel Klantcontactinformatie zodanig in te stellen dat deze los staat van de tabel met serviceorders, om te voorkomen dat klantgegevens verloren gaan wanneer serviceorders worden gesloten en mogelijk worden verwijderd. Neem dezelfde benadering voor de tabel Producten, wat betekent dat nieuwe producten kunnen worden toegevoegd aan de fictieve bedrijfsdatabase onafhankelijk van serviceorders.

Door te vertrouwen op bewerkingen in RDBMS-join, ondersteunt dit schema query's die het aantal serviceorders weergeven dat wordt geopend voor een bepaald product, samen met de locatie van de klant waar het product in gebruik is.

Dat is allemaal goed en grappig, maar het is een schema dat u zou gebruiken met RDBM. Hoe zet je dit schema over naar een HBase-schema? De volgende afbeelding illustreert een mogelijk HBase-schema - een schema dat het DDI-ontwerppatroon volgt.

De tabel Klantcontactinformatie is gedenormaliseerd door de naam van de klant en contactgegevens op te nemen in plaats van de eerder gebruikte externe sleutels. Ook worden de gegevens gedupliceerd door de tabel met klantcontactinformatie te houden zoals deze is. Nu zijn koppelingen in de tabel Servicebestelling en de tabel Klantcontactinformatie niet nodig.

Daarnaast is een intelligent ontwerp met rijsleutels gebruikt dat het productnummer combineert met het klantnummer om het serviceordernummer te vormen (bijvoorbeeld A100 | 00001). Met behulp van deze intelligente sleutel kan de serviceordertabel essentiële rapporten over productdeficiënties en klanten die momenteel problemen met het product ondervinden, leveren.

Al deze query's kunnen allemaal worden ondersteund door HBase op atoommanierniveau op rijniveau voor de toepassing. Omdat u weet dat HBase rijsleutels bestelt en ze sorteert op een lexicografische manier, kan uw toepassing bepaalde goedgewerkte gissingen doen over gegevenslocatie bij het genereren van scans voor rapportage. (Alle productnummers van een A * -reeks worden bijvoorbeeld samen opgeslagen.)

De serviceorderdatabase die door het HBase-schema wordt vertegenwoordigd, is een relatief eenvoudig voorbeeld, maar het illustreert hoe HBase in bepaalde gevallen de RDBMS-wereld kan kruisen en bieden aanzienlijke waarde. Als het fictieve bedrijf terabytes of zelfs petabytes aan servicegesprekgegevens heeft om op te slaan, zou HBase een enorm verschil maken in termen van kosten, betrouwbaarheid, prestaties en schaal.

U kunt het HBase-schema van uw serviceorder natuurlijk op verschillende manieren ontwerpen. Toegegeven, het ontwerp hangt allemaal af van de vragen die moeten worden ondersteund, maar je hebt de mogelijkheid om sommige relationele databases over te zetten naar zeer krachtige HBase-toepassingen voor productiegebruik, zolang je werkt vanuit een goed begrip van de HBase-architectuur en het DDI-ontwerppatroon.

In dit voorbeeld is aangenomen dat query's zijn uitgevoerd door een Java-toepassing die de API's van de HBase-client gebruikt, of misschien via een andere taal met Apache Thrift. Dit applicatiemodel kan prima voldoen aan de vereisten en biedt nuttige prestatie- en aanpassingsmogelijkheden voor het fictieve servicebedrijf.