Transizione da un modello RDBMS a HBase - dummies

Se stai affrontando la fase di progettazione per la tua applicazione e ritieni che HBase possa essere una buona soluzione, quindi progettando le tue chiavi di riga e lo schema per adattarle al modello di dati e all'architettura di HBase è il giusto approccio. Tuttavia, a volte ha senso spostare un database originariamente progettato per un RDBMS in HBase.

Uno scenario comune in cui questo approccio ha senso è un'istanza di database MySQL che ha raggiunto i suoi limiti di scalabilità. Esistono tecniche per il ridimensionamento orizzontale di un'istanza MySQL ( sharding, in altre parole), ma questo processo è solitamente macchinoso e problematico perché MySQL semplicemente non è stato originariamente progettato per il sharding.

La transizione dal modello relazionale al modello HBase è una disciplina relativamente nuova. Tuttavia, alcuni modelli di pensiero stabiliti stanno emergendo e si sono unificati in tre principi chiave da seguire quando ci si avvicina a una transizione. Questi principi sono denormalizzazione, duplicazione, e chiavi intelligenti (DDI) .

• Denormalizzazione: Il modello di database relazionale dipende da a) uno schema di database normalizzato eb) unisce le tabelle per rispondere alle operazioni SQL. La normalizzazione del database è una tecnica che protegge dalla perdita di dati, dalla ridondanza e da altre anomalie man mano che i dati vengono aggiornati e recuperati.

  Ci sono un certo numero di regole che gli esperti seguono per arrivare a uno schema di database normalizzato (e la normalizzazione del database è un intero studio stesso), ma il processo di solito comporta la divisione di tabelle più grandi in tabelle più piccole e la definizione di relazioni fra loro. La denormalizzazione del database è l'opposto della normalizzazione, in cui tabelle più piccole e specifiche vengono unite in tabelle più grandi e più generali.

  Questo è uno schema comune quando si passa a HBase perché i join non vengono forniti tra le tabelle e i join possono essere lenti poiché comportano costose operazioni su disco. Proteggere dall'aggiornamento e dalle anomalie nel recupero è ora il compito dell'applicazione client HBase, poiché le protezioni garantite dalla normalizzazione sono nulle.

• Duplicazione: Mentre denormalizzi lo schema del tuo database, probabilmente finirai con la duplicazione dei dati perché può aiutarti a evitare costose operazioni di lettura su più tabelle. Non preoccuparti dell'archiviazione extra (ovviamente ovviamente); puoi sfruttare la scalabilità automatica di HBase a tuo vantaggio.

  Tuttavia, tieni presente che sarà necessario un ulteriore lavoro dall'applicazione client per duplicare i dati e ricordare che nativamente HBase fornisce solo operazioni atomiche a livello di riga non incrociate (con l'eccezione descritta nella HBIR-5229 JIRA) o cross tavolo.

• Chiavi intelligenti: Poiché i dati memorizzati in HBase sono ordinati per chiave di riga e la chiave di riga è l'unico indice nativo fornito dal sistema, un'accurata progettazione intelligente della chiave di riga può fare un'enorme differenza. Ad esempio, la tua chiave di riga potrebbe essere una combinazione di un numero di ordine di servizio e il numero ID del cliente che ha inserito l'ordine di servizio.

  Il design di questa riga chiave consente di cercare i dati relativi all'ordine di servizio o di cercare i dati relativi al cliente utilizzando la stessa chiave di riga nella stessa tabella. Questa tecnica sarà più veloce per alcune query ed eviterà costosi join di tabelle.

Per chiarire questi particolari schemi di pensiero, prendere una tabella di informazioni sul contatto con il cliente e inserirla nel contesto di un tipico database di ordini di assistenza. La figura mostra come potrebbe essere uno schema di database di un ordine di servizio normalizzato.

Seguendo le regole della normalizzazione RDBMS, impostare la tabella delle informazioni di contatto del cliente in modo che sia separata dalla tabella dell'ordine di servizio per evitare di perdere i dati dei clienti quando gli ordini di servizio vengono chiusi ed eventualmente cancellati. Adottare lo stesso approccio per la tabella Prodotti, il che significa che è possibile aggiungere nuovi prodotti al database aziendale fittizio indipendentemente dagli ordini di servizio.

Facendo affidamento sulle operazioni di join RDBMS, questo schema supporta query che rivelano il numero di ordini di servizio che vengono aperti rispetto a un particolare prodotto insieme alla posizione del cliente in cui il prodotto è in uso.

Va tutto bene e dandy, ma è uno schema che useresti con RDBM. Come si passa questo schema a uno schema HBase? La figura seguente illustra un possibile schema HBase, uno che segue il modello di progettazione DDI.

La tabella delle informazioni sul contatto con il cliente è stata denormalizzata includendo il nome del cliente e le informazioni di contatto al posto delle chiavi esterne utilizzate in precedenza. Inoltre, i dati vengono duplicati mantenendo la tabella Informazioni contatto cliente così com'è. Ora i join tra la tabella dell'ordine di servizio e la tabella di informazioni sul contatto con il cliente non sono necessari.

Inoltre, è stato utilizzato un design intelligente della riga di comando che combina il numero del prodotto con il numero cliente per formare il numero dell'ordine di servizio (A100 | 00001, ad esempio). Usando questa chiave intelligente, la tabella degli ordini di servizio può fornire rapporti vitali sulle carenze del prodotto e sui clienti che attualmente stanno riscontrando problemi con il prodotto.

Tutte queste query possono essere supportate da HBase in modo atomico a livello di riga per l'applicazione. Poiché tu sai che HBase ordina le chiavi di riga e le ordina in modo lessicografico, la tua applicazione può fare alcune ipotesi plausibili sulla località dei dati durante l'emissione di scansioni per la segnalazione. (Tutti i numeri dei prodotti della serie A * verranno memorizzati insieme, ad esempio.)

Il database degli ordini di servizio rappresentato dallo schema HBase è un esempio relativamente semplice, ma illustra come HBase, in alcuni casi, può intersecarsi con il mondo RDBMS e fornire un valore significativo. Se la società fittizia ha terabyte o anche petabyte di dati sulle chiamate di servizio da archiviare, HBase farebbe un'enorme differenza in termini di costi, affidabilità, prestazioni e scalabilità.

È possibile, ovviamente, progettare lo schema di HBase in diversi modi. Indubbiamente, il design dipende interamente dalle query che devono essere supportate, ma si ha la possibilità di trasferire alcuni database relazionali in applicazioni HBase molto potenti per l'uso di produzione, purché si lavori da una solida conoscenza dell'architettura HBase e del modello di progettazione DDI.

Questo esempio ha presupposto che le query siano state eseguite da un'applicazione Java sfruttando le API del client HBase, o forse tramite un'altra lingua usando Apache Thrift. Questo modello di applicazione può adattarsi perfettamente ai requisiti e fornire utili prestazioni e opzioni di personalizzazione per la società di servizi fittizi.