Siamo entusiasti di condividere che dopo aver aggiunto ANSI SQL, indici secondari, schema a stella e funzionalità di visualizzazione al database operativo di Cloudera, nei prossimi mesi introdurremo il supporto per le transazioni distribuite.

Cos'è l'ACID?

Il modello ACID di progettazione di database è uno dei concetti più importanti nei database. ACID sta per atomicità, consistenza, isolamento e durabilità. Per molto tempo, per un database di successo commerciale è stato richiesto il rigoroso rispetto di queste quattro proprietà. Tuttavia, questo modello creava problemi quando si trattava di scalare oltre un database di un server. Per soddisfare questa limitazione, i clienti hanno aumentato l'hardware su cui sono stati distribuiti i database.

I database NoSQL hanno allentato una o più di queste 4 proprietà per ottenere notevoli miglioramenti nella scalabilità:il database operativo Cloudera (con tecnologia Apache HBase) era uno di questi database. Abbiamo fatto dei compromessi sull'atomicità, in particolare Cloudera ha fornito l'atomicità a riga singola. Per compensare, abbiamo supportato tabelle molto ampie (con potenzialmente milioni di colonne). Ciò ha consentito ai clienti di denormalizzare i propri schemi a stella e rappresentarli come righe singole per eseguire commit atomici in un'unica riga di quelle che erano rappresentate come più tabelle.

Dalla nascita di HBase, abbiamo lavorato per creare funzionalità che riducano il divario di funzionalità con i tradizionali RDBM mantenendo i vantaggi di scalabilità, coerenza, durabilità e isolamento NoSQL.

All'inizio di quest'anno, abbiamo fornito supporto per ANSI SQL, indici secondari, schema a stella e viste oltre ad Apache HBase, offrendo un'interfaccia e funzionalità familiari a tutti gli sviluppatori di applicazioni che abbiano mai creato un'applicazione che utilizza MySQL o PostGres.

Siamo ora sul punto di offrire la possibilità di eseguire commit atomici su dati che incrociano righe e tabelle nel cluster.

Cos'è una transazione atomica?

Una transazione comprende un insieme di operazioni in un database che vengono gestite in modo atomico, quindi tutte le operazioni devono essere completamente completate (impegnate) o non hanno effetto (interrotte).

Attualmente, supportiamo solo transazioni atomiche a riga singola. Ciò significa che quando gli sviluppatori cercano di adottare il database operativo di Cloudera, devono pensare in modo diverso al proprio schema.

Ora stiamo introducendo la possibilità di avere transazioni complesse che si estendono su più righe e tabelle, il che significa che gli sviluppatori possono implementare lo schema a stella tradizionale o sfruttare colonne larghe o entrambi a seconda delle loro esigenze. Questa flessibilità, combinata con l'approccio dello schema evolutivo di Cloudera Operational Database, consente agli sviluppatori di sfruttare un moderno database a scalabilità orizzontale portando avanti le competenze esistenti.

Una cosa importante da notare è che il supporto delle transazioni in Cloudera Operational Database è "senza blocco" e fornisce garanzie di isolamento degli snapshot. I database tradizionali implementano un "blocco" a tutti i dati associati a una transazione in modo che altri client che accedono ai dati non li modifichino prima che vengano inseriti nel database. Tuttavia, ciò potrebbe comportare condizioni di gara che finirebbero con dipendenze circolari e si bloccano. I blocchi sono stati anche la causa di prestazioni notevolmente scarse da parte di un'applicazione poiché le applicazioni si aspettavano l'una sull'altra in modo da poter ottenere un blocco e procedere.

Il nostro approccio consente alla prima transazione completata di andare avanti e le altre che stavano cercando di apportare modifiche allo stesso set di dati dovranno riprovare. Ciò impedisce qualsiasi rallentamento dell'intero ecosistema di applicazioni in esecuzione contemporaneamente sul database. In altre parole, il nostro approccio consente la scalabilità lineare fornendo al contempo l'atomicità che i tradizionali database transazionali sono in grado di fornire.

Risultati preliminari delle prestazioni

La nostra capacità di supporto per le transazioni è attualmente in versione beta e viene sottoposta a test approfonditi delle prestazioni.

I test attuali includono il benchmark TPC-C standard del settore che utilizza l'applicazione OLTP Bench. Il benchmark TPC-C simula una serie di acquisti effettuati contemporaneamente in diversi magazzini. Lo schema utilizzato in TPC-C è rappresentato nel seguente diagramma entità-relazione:

I numeri nei blocchi di entità rappresentano la cardinalità delle tabelle (numero di righe). Questi numeri vengono fattorizzati da W, il numero di Magazzini, per illustrare il ridimensionamento del database. I numeri accanto alle frecce di relazione rappresentano la cardinalità delle relazioni (il numero medio di figli per genitore). Il simbolo + rappresenta la piccola variazione numerica della popolazione del database.

Un posizionamento di un ordine richiede che le seguenti 10 query vengano eseguite come una singola transazione atomica:

1.SELECT c_discount,                      c_last,        C_creditFROM   customerWHERE  c_w_id =? E c_d_id =? E c_id =? 2. SELEZIONA w_taxDA   warehouseWHERE  w_id =?3. SELECT d_next_o_id,        D_taxDA   districtWHERE  d_w_id =? E d_id =?4. UPSERT INTO district           (d_next_o_id,              d_w_id,              d_id)SELECT d_next_o_id + 1,       d_w_id,        D_idFROM   districtWHERE  d_w_id =? E d_id =? 5. UPSERT IN new_order            (no_o_id,             no_d_id,             no_w_id)VALUES (?,?,?)6. UpSert in order (o_id, o_d_id, o_w_id, o_c_id, o_entry_d, o_ol_cnt, o_all_local) valori (?,?,?,?,?,?) Ripetere le seguenti domande per ogni articolo selezionato per l'ordine. 7.   SELEZIONA i_price,             i_name,             i_data      DA   articolo      DOVE  i_id =? 8. SELEZIONA S_QUANTITY, S_DATA, S_DIST_01, S_DIST_02, S_DIST_03, S_DIST_04, S_DIST_05, S_DIST_06, S_DIST_07, S_DIST_08, S_DIST_09, S_DIST_10 da dove S_I_ID =? E s_w_id =? 9. upSert in stock (s_quantity, s_ytd, s_order_cnt, s_remote_cnt, s_i_id, s_w_id) Selezionare?, S_ytd +?, S_order_cnt + 1, s_remote_cnt +?, S_i_id, s_w_idfrom s_i_id =? E s_w_id =?10. Inserisci in order_line (ol_o_id, ol_d_id, ol_w_id, ol_number, ol_i_id, ol_supply_w_id, ol_quantity, ol_amount, ol_dist_info) valori (?,? 

 Una transazione di pagamento richiede che le 6 seguenti query vengano eseguite come una singola transazione atomica:
 1. UPSERT INTO warehouse                 (w_ytd,                  w_id)      SELECT w_ytd + ?,           w_id      DAL   warehouse      DOVE  w_id =? 2. SELEZIONA w_street_1,       w_street_2,       w_city,       w_state,       w_zip,      w_nameFROM   warehouseWHERE  w_id =?3. UpSert in District (d_ytd, d_w_id, d_id) selezionare d_ytd + ?, d_w_id, d_id dal distretto dove d_w_id =? E d_id =? 4. SELECT d_street_1,             d_street_2,            d_city,             d_state,             d_zip,            d_name      DAL distretto      DOVE  d_w_id =? E d_id =? 6. UpSert in Customer (C_Balance, c_ytd_payment, c_payment_cnt, c_w_id, c_d_id, c_id) Selezionare?,?,?, C_w_id, c_d_id, c_idfrom customerwhere c_w_id =? E c_d_id =? E c_id =? 7. Insert in History (H_C_D_ID, H_C_W_ID, H_C_ID, H_D_ID, H_W_ID, H_DATE, H_AMOUNT, H_DATA) VALORI (?,?,?,?,?,?,?,?) 

Con 3 server regionali in esecuzione su nodi Dell PowerEdge R440, siamo stati in grado di ottenere i seguenti risultati:

In questo grafico, l'asse Y rappresenta il numero di ordini che possono essere completamente elaborati (inclusa la creazione di nuovi ordini, il pagamento, la consegna ecc.) al minuto ed è espresso nel benchmark tpm-C. L'asse X rappresenta il numero di entità che eseguono transazioni in parallelo.

Questi risultati preliminari indicano che il sistema raggiunge un throughput massimo di transazioni compreso tra 150 e 300 operatori e sono necessari ulteriori test per identificare quel picco.

Man mano che questa capacità matura, sia il throughput OpDB che la nostra capacità di misurare il throughput miglioreranno.

Conclusione

La maggior parte delle applicazioni sfrutta le transazioni per supportare la miriade di esigenze che le aziende devono affrontare. Tuttavia, quando gli RDBMS tradizionali non possono essere ridimensionati, i clienti sono costretti a partizionare manualmente il database e a gestire ogni database partizionato come un database indipendente.

Quando questo diventa troppo ingombrante da gestire, i clienti dovrebbero prendere in considerazione la migrazione dell'applicazione al database operativo di Cloudera. Il supporto di transazioni complesse combinato con il supporto ANSI SQL e la natura scale-out di Apache HBase fornisce una combinazione che può ridurre significativamente la complessità operativa della gestione della crescita.

Se sei stanco di gestire database partizionati e stai cercando di ridurre il TCO del database, contatta il team del tuo account Cloudera per vedere come possiamo aiutarti.