Jsme nadšeni, že můžeme sdílet, že po přidání ANSI SQL, sekundárních indexů, hvězdného schématu a možností zobrazení do provozní databáze Cloudera zavedeme v nadcházejících měsících podporu distribuovaných transakcí.

Co je ACID?

ACID model návrhu databáze je jedním z nejdůležitějších konceptů v databázích. ACID znamená atomicitu, konzistenci, izolaci a odolnost. Po velmi dlouhou dobu bylo pro komerčně úspěšnou databázi vyžadováno přísné dodržování těchto čtyř vlastností. Tento model však způsoboval problémy, pokud šlo o škálování nad rámec databáze jednoho serveru. Aby se přizpůsobili tomuto omezení, zákazníci zvětšili hardware, na kterém byly databáze nasazeny.

Databáze NoSQL uvolnily jednu nebo více z těchto 4 vlastností, aby dosáhly dramatického zlepšení škálovatelnosti – jednou z takových databází byla Cloudera Operational Database (Powered by Apache HBase). Udělali jsme kompromisy ohledně atomicity – konkrétně Cloudera poskytla atomicitu v jedné řadě. Abychom to kompenzovali, podporovali jsme velmi široké tabulky (s potenciálně miliony sloupců). To zákazníkům umožnilo denormalizovat svá hvězdná schémata a reprezentovat je jako jednotlivé řádky, aby bylo možné vytvořit atomické potvrzení v jednom řádku toho, co bývalo reprezentováno jako více tabulek.

Od zrodu HBase pracujeme na vytváření schopností, které zužují mezeru mezi funkcemi oproti tradičním RDBM a zároveň zachovávají výhody škálovatelnosti, konzistence, trvanlivosti a izolace NoSQL.

Začátkem tohoto roku jsme poskytli podporu pro ANSI SQL, sekundární indexy, hvězdicová schémata a pohledy nad Apache HBase, čímž jsme přinesli rozhraní a možnosti, které znají všichni vývojáři aplikací, kteří kdy vytvořili aplikaci využívající MySQL nebo PostGres.

Nyní jsme na vrcholu poskytování schopnosti provádět atomické potvrzení dat, která procházejí řádky a tabulkami napříč clusterem.

Co je to atomická transakce?

Transakce obsahuje sadu operací v databázi, které jsou spravovány atomicky, takže všechny operace musí být buď zcela dokončeny (potvrzeny), nebo nemají žádný účinek (přerušeny).

V současné době podporujeme pouze jednořádkové atomické transakce. To znamená, že když vývojáři chtějí přijmout provozní databázi Cloudera, musí o svém schématu přemýšlet jinak.

Nyní zavádíme možnost mít složité transakce, které zahrnují více řádků a tabulek, což znamená, že vývojáři mohou implementovat tradiční hvězdicové schéma nebo využít široké sloupce nebo obojí v závislosti na jejich potřebách. Tato flexibilita v kombinaci s přístupem evolučního schématu Cloudera Operational Database umožňuje vývojářům využívat výhod moderní škálovatelné databáze a zároveň rozvíjet své stávající dovednosti.

Důležité je poznamenat, že podpora transakcí v Cloudera Operational Database je „bez zámku“ a poskytuje záruky izolace snímků. Tradiční databáze implementují „zámek“ na všechna data spojená s transakcí, aby je ostatní klienti, kteří k datům přistupují, nezměnili dříve, než se zadají do databáze. To by však mohlo mít za následek závodní podmínky, které by skončily s kruhovými závislostmi a zablokovaly se. Zámky byly také příčinou dramaticky slabého výkonu na straně aplikace, protože aplikace na sebe čekaly, aby mohly získat zámek a pokračovat.

Náš přístup umožňuje, aby se první transakce, která byla dokončena, posunula vpřed a ostatní, které se pokoušely provést změny ve stejné sadě dat, to budou muset opakovat. To zabraňuje jakémukoli zpomalení celého ekosystému aplikací běžících současně v databázi. Jinými slovy, náš přístup umožňuje lineární škálovatelnost a zároveň poskytuje atomicitu, kterou jsou schopny poskytnout tradiční transakční databáze.

Předběžné výsledky výkonu

Naše funkce podpory transakcí je aktuálně ve verzi beta a prochází rozsáhlým testováním výkonu.

Současné testování zahrnuje standardní benchmark TPC-C pomocí aplikace OLTP Bench. Benchmark TPC-C simuluje řadu nákupů prováděných současně v několika skladech. Schémata použitá v TPC-C jsou znázorněna v následujícím diagramu vztahů mezi entitami:

Čísla v blocích entit představují mohutnost tabulek (počet řádků). Tato čísla jsou vynásobena W, počtem skladů, pro ilustraci škálování databáze. Čísla vedle šipek vztahu představují mohutnost vztahů (průměrný počet dětí na rodiče). symbol + představuje malou variaci počtu databázových souborů.

Zadání objednávky vyžaduje, aby následujících 10 dotazů bylo spuštěno jako jediná atomická transakce:

1.SELECT c_discount,                        c_last,        C_creditFROM   customerWHERE  c_w_id =? A c_d_id =? A c_id =? 2. VYBERTE w_taxFROM   skladWHERE  w_id =?3. SELECT d_next_o_id,        D_taxFROM   districtWHERE  d_w_id =? AND 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_ wRE id d_w   A d_id =? 5. UPSERT INTO new_order             (no_o_id,             no_d_id,             no_w_id)VALUES (?,?,?)6. UPSERT do pořadí (O_ID, O_D_ID, O_W_ID, O_C_ID, O_ENTRY_D, O_OL_CNT, O_ALL_LOCAL) HODNOTY (??,?,?,?,?,?,?,?,?) 7.   SELECT i_price,             i_name,              i_data      FROM   item      WHERE  i_id =? 8. Vyberte 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 z akcií, kde S_I_ID =?? AND s_w_id =? 9. UPSERT do skladu (S_QUANTITY, S_YTD, S_ORDER_CNT, S_REMOTE_CNT, S_I_ID, S_W_ID) Vyberte?, S_YTD +?, S_ORDER_CNT + 1, S_REMOTE_CNT +?, S_I_ID, S_W_IDFOM Stock kde AND s_w_id =?10. Vložte do 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) hodnoty (?,?,?,?,?,?,?,?) 

 Platební transakce vyžaduje, aby 6 následujících dotazů bylo spuštěno jako jediná atomická transakce:
 
1. UPSERT INTO sklad 2. VYBERTE w_ulice_1,       w_ulice_2,       w_city,       w_state,       w_zip,       w_nameFROM   sklad WHERE  w_id =?3. UPSERT do okresu (D_YTD, D_W_ID, D_ID) Vyberte d_ytd +?, D_w_id, d_id z okresu, kde d_w_id =? A d_id =? 4. VYBERTE d_ulice_1,             d_ulice_2,             d_city,              d_state,               d_zip, W HE id       HE  id                            A d_id =? 6. UPSERT na zákazníka (C_balance, C_YTD_PAYMENT, C_PAYMENT_CNT, C_W_ID, C_D_ID, C_ID) Vyberte? ,?,?,?, C_W_ID, C_D_ID, C_IDFOM CUSCUCIONSHE CUSCICKES A c_d_id =? A c_id =? 7. Vložte do historie (H_C_D_ID, H_C_W_ID, H_C_ID, H_D_ID, H_W_ID, H_DATE, H_AMOUNT, H_DATA) Hodnoty (?,?,?,?,?,?,?)  

 Se 3 regionálními servery běžícími na uzlech Dell PowerEdge R440 jsme byli schopni dosáhnout následujících výsledků:
 

 
 

 V tomto grafu osa Y představuje počet objednávek, které lze plně zpracovat (včetně vytvoření nové objednávky, platby, doručení atd.) za minutu a je vyjádřen v benchmarku tpm-C. Osa X představuje počet subjektů provádějících transakce paralelně.
 

 Tyto předběžné výsledky naznačují, že systém dosahuje špičkové transakční propustnosti někde mezi 150 a 300 transaktory a k identifikaci této špičky je zapotřebí další testování. 
 

 Jak tato schopnost dospěje, zlepší se jak propustnost OpDB, tak naše schopnost měřit propustnost.
 
Závěr
 

 Většina aplikací využívá transakce k podpoře nesčetných potřeb, kterým podniky čelí. Když se však tradiční RDBMS nemohou škálovat, zákazníci jsou nuceni databázi ručně skartovat a každou sdílenou databázi spravovat jako nezávislou databázi samostatně.
 

 Když se to stane příliš těžkopádným na správu, měli by zákazníci zvážit migraci této aplikace do provozní databáze Cloudera. Komplexní podpora transakcí v kombinaci s podporou ANSI SQL a škálovatelná povaha Apache HBase poskytuje kombinaci, která může výrazně snížit provozní složitost řízení růstu.
 

 Pokud vás nebaví spravovat sdílené databáze a chcete snížit TCO databáze, obraťte se na svůj tým pro účty Cloudera a zjistěte, jak vám můžeme pomoci.