Vi är glada att kunna dela att vi, efter att ha lagt till ANSI SQL, sekundära index, stjärnschema och visningsmöjligheter till Clouderas operativa databas, kommer att introducera distribuerat transaktionsstöd under de kommande månaderna.
Vad är ACID?
ACID-modellen för databasdesign är ett av de viktigaste begreppen i databaser. ACID står för atomicitet, konsistens, isolering och hållbarhet. Under mycket lång tid krävdes strikt efterlevnad av dessa fyra egenskaper för en kommersiellt framgångsrik databas. Den här modellen skapade dock problem när det gällde att skala bortom en enserverdatabas. För att tillgodose denna begränsning skalade kunderna upp hårdvaran som databaserna distribuerades på.
NoSQL-databaser lossade en eller flera av dessa 4 egenskaper för att uppnå dramatiska förbättringar i skalbarhet – Cloudera Operational Database (driven av Apache HBase) var en sådan databas. Vi gjorde avvägningar om atomicitet - specifikt tillhandahöll Cloudera enrads atomicitet. För att kompensera stödde vi mycket breda tabeller (med potentiellt miljontals kolumner). Detta gjorde det möjligt för kunder att denormalisera sina stjärnscheman och representera dem som enstaka rader för att göra atomära bekräftelser i en enda rad av vad som brukade representeras som flera tabeller.
Sedan HBases födelse har vi arbetat för att bygga kapaciteter som minskar funktionsgapet med traditionella RDBM:er samtidigt som vi behåller fördelarna med NoSQL-skalbarhet, konsistens, hållbarhet och isolering.
Tidigare i år gav vi stöd för ANSI SQL, sekundära index, stjärnschema och vyer ovanpå Apache HBase, vilket ger ett gränssnitt och funktioner som är bekanta för alla applikationsutvecklare som någonsin har byggt en applikation som använder MySQL eller PostGres.
Vi är nu på väg att leverera möjligheten att göra atomära commits till data som korsar rader och tabeller över hela klustret.
Vad är en atomär transaktion?
En transaktion omfattar en uppsättning operationer i en databas som hanteras atomiskt, så alla operationer måste antingen vara helt slutförda (begärda) eller inte ha någon effekt (avbrutna).
För närvarande stöder vi endast enradiga atomtransaktioner. Detta innebär att när utvecklare vill använda Clouderas operativa databas, måste de tänka annorlunda om sitt schema.
Vi introducerar nu möjligheten att ha komplexa transaktioner som spänner över flera rader och tabeller, vilket innebär att utvecklare kan implementera traditionella stjärnscheman eller dra fördel av breda kolumner eller båda beroende på deras behov. Denna flexibilitet i kombination med Cloudera Operational Databases evolutionära schematillvägagångssätt gör det möjligt för utvecklare att dra fördel av en modern utskalningsdatabas samtidigt som de bär sina befintliga färdigheter framåt.
En viktig sak att notera är att transaktionsstöd i Cloudera Operational Database är "låsfritt" och ger ögonblicksbildisoleringsgarantier. Traditionella databaser implementerar ett "lås" för all data som är associerad med en transaktion så att andra klienter som kommer åt data inte ändrar dem innan de har anslutit sig till databasen. Detta kan dock resultera i rasförhållanden som skulle sluta med cirkulära beroenden och hänga. Lås var också orsaken till dramatiskt dålig prestanda från en applikations sida eftersom applikationer väntade på varandra så att de kunde få ett lås och fortsätta.
Vårt tillvägagångssätt tillåter att den första transaktionen som slutförs går framåt och de andra som försökte göra ändringar i samma datauppsättning måste försöka igen. Detta förhindrar all avmattning av hela ekosystemet av applikationer som körs samtidigt på databasen. Med andra ord tillåter vårt tillvägagångssätt linjär skalbarhet samtidigt som vi tillhandahåller den atomicitet som traditionella transaktionsdatabaser kan tillhandahålla.
Preliminära resultatresultat
Vår transaktionsstödskapacitet är för närvarande i beta och håller på att genomgå omfattande prestandatester.
Aktuella tester inkluderar industristandarden TPC-C benchmark med OLTP Bench-applikationen. TPC-C-riktmärket simulerar ett antal inköp som görs samtidigt över ett antal lager. Schemat som används i TPC-C är representerade i följande entitetsrelationsdiagram:
Siffrorna i entitetsblocken representerar tabellernas kardinalitet (antal rader). Dessa siffror är faktoriserade av W, antalet lager, för att illustrera databasens skalning. Siffrorna bredvid relationspilarna representerar relationernas kardinalitet (genomsnittligt antal barn per förälder). + symbolen representerar antalet små variationer av databaspopulationen.
En orderplacering kräver att följande 10 frågor körs som en enda atomär transaktion:
1.SELECT c_discount, c_last, C_credit FROM customer WHERE c_w_id = ? AND c_d_id = ? AND c_id = ? 2. SELECT w_tax FROM warehouse WHERE w_id = ? 3. SELECT d_next_o_id, D_tax FROM district WHERE 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_id FROM district WHERE d_w_id = ? AND d_id = ? 5. UPSERT INTO new_order (no_o_id, no_d_id, no_w_id) VALUES (?,?,?) 6. UPSERT INTO order (o_id, o_d_id, o_w_id, o_c_id, o_entry_d, o_ol_cnt, o_all_local) VALUES (?,?,?,?, ?,?,?) Repeat following queries for each item selected for order. 7. SELECT i_price, i_name, i_data FROM item WHERE i_id = ? 8. SELECT 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 FROM stock WHERE s_i_id = ? AND s_w_id = ? 9. UPSERT INTO stock (s_quantity, s_ytd, s_order_cnt, s_remote_cnt, s_i_id, s_w_id) SELECT ?, s_ytd + ?, s_order_cnt + 1, s_remote_cnt + ?, s_i_id, s_w_id FROM stock WHERE s_i_id = ? AND s_w_id = ? 10. INSERT INTO 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) VALUES (?,?,?,?,?,?,?,?,?)
En betalningstransaktion kräver att de 6 följande frågorna körs som en enda atomär transaktion:
1. UPSERT INTO warehouse (w_ytd, w_id) SELECT w_ytd + ?, w_id FROM warehouse WHERE w_id =? 2. SELECT w_street_1, w_street_2, w_city, w_state, w_zip, w_name FROM warehouse WHERE w_id = ? 3. UPSERT INTO district (d_ytd, d_w_id, d_id) SELECT d_ytd + ?, d_w_id, d_id FROM district WHERE d_w_id = ? AND d_id = ? 4. SELECT d_street_1, d_street_2, d_city, d_state, d_zip, d_name FROM district WHERE d_w_id = ? AND d_id = ? 6. UPSERT INTO customer (c_balance, c_ytd_payment, c_payment_cnt, c_w_id, c_d_id, c_id) SELECT ?, ?, ?, c_w_id, c_d_id, c_id FROM customer WHERE c_w_id = ? AND c_d_id = ? AND c_id = ? 7. INSERT INTO history (h_c_d_id, h_c_w_id, h_c_id, h_d_id, h_w_id, h_date, h_amount, h_data) VALUES (?,?,?,?,?,?,?,?)>
Med 3 regionservrar som kördes på Dell PowerEdge R440-noder kunde vi uppnå följande resultat:
I denna graf representerar Y-axeln antalet beställningar som kan behandlas fullt ut (inklusive skapande av nya beställningar, betalning, leverans etc.) per minut och uttrycks i tpm-C benchmark. X-axeln representerar antalet enheter som utför transaktioner parallellt.
Dessa preliminära resultat indikerar att systemet når en maximal transaktionsgenomströmning någonstans mellan 150 och 300 transaktorer och ytterligare testning krävs för att identifiera den toppen.
När denna förmåga mognar kommer både OpDB-genomströmningen och vår förmåga att mäta genomströmningen att förbättras.
Slutsats
De flesta applikationer utnyttjar transaktioner för att stödja de otaliga behov som företag möter. Men när traditionella RDBMS inte kan skalas, tvingas kunderna att manuellt klippa databasen och hantera varje fragmenterad databas som en oberoende databas för sig.
När detta blir för besvärligt att hantera bör kunder överväga att migrera den applikationen till Clouderas operativa databas. Komplext transaktionsstöd kombinerat med ANSI SQL-stöd och Apache HBases utskalningskaraktär ger en kombination som avsevärt kan minska den operationella komplexiteten för att hantera tillväxt.
Om du är trött på att hantera sönderdelade databaser och vill sänka databas-TCO, kontakta ditt Cloudera-kontoteam för att se hur vi kan hjälpa dig.