Vi er glade for at kunne dele, at efter at have tilføjet ANSI SQL, sekundære indekser, stjerneskemaer og visningsmuligheder til Clouderas operationelle database, vil vi introducere distribueret transaktionssupport i de kommende måneder.
Hvad er ACID?
ACID-modellen for databasedesign er et af de vigtigste begreber i databaser. ACID står for atomicitet, konsistens, isolation og holdbarhed. I meget lang tid var streng overholdelse af disse fire egenskaber påkrævet for en kommercielt succesfuld database. Denne model skabte imidlertid problemer, når det kom til at skalere ud over en database med én server. For at imødekomme denne begrænsning opskalerede kunder den hardware, som databaserne blev implementeret på.
NoSQL-databaser løsnede en eller flere af disse 4 egenskaber for at opnå dramatiske forbedringer i skalerbarhed - Cloudera Operational Database (drevet af Apache HBase) var en sådan database. Vi lavede afvejninger om atomicitet - specifikt leverede Cloudera enkeltrækket atomicitet. For at kompensere understøttede vi meget brede tabeller (med potentielt millioner af kolonner). Dette gjorde det muligt for kunderne at denormalisere deres stjerneskemaer og repræsentere dem som enkelte rækker for at foretage atomære commits i en enkelt række af det, der plejede at blive repræsenteret som flere tabeller.
Siden fødslen af HBase har vi arbejdet på at opbygge funktioner, der mindsker funktionskløften med traditionelle RDBM'er, mens vi bibeholder fordelene ved NoSQL-skalerbarhed, konsistens, holdbarhed og isolering.
Tidligere i år leverede vi support til ANSI SQL, sekundære indekser, stjerneskemaer og visninger oven på Apache HBase, hvilket bringer en grænseflade og funktioner, der er velkendte for alle applikationsudviklere, der nogensinde har bygget en applikation, der bruger MySQL eller PostGres.
Vi er nu på nippet til at levere evnen til at foretage atomære commits til data, der krydser rækker og tabeller på tværs af klyngen.
Hvad er en atomtransaktion?
En transaktion omfatter et sæt af operationer i en database, der styres atomisk, så alle operationer skal enten være fuldstændigt gennemført (committed) eller have ingen effekt (afbrudt).
I øjeblikket understøtter vi kun enkeltrækkede atomtransaktioner. Dette betyder, at når udviklere ønsker at adoptere Clouderas operationelle database, skal de tænke anderledes om deres skema.
Vi introducerer nu muligheden for at have komplekse transaktioner, der spænder over flere rækker og tabeller, hvilket betyder, at udviklere kan implementere traditionelt stjerneskema eller drage fordel af brede kolonner eller begge dele afhængigt af deres behov. Denne fleksibilitet kombineret med Cloudera Operational Databases evolutionære skematilgang giver udviklere mulighed for at drage fordel af en moderne udskaleringsdatabase, mens de viderefører deres eksisterende færdigheder.
En vigtig ting at bemærke er, at transaktionsunderstøttelse i Cloudera Operational Database er "låsefri" og giver isolationsgarantier for øjebliksbilleder. Traditionelle databaser implementerer en "lås" til alle de data, der er knyttet til en transaktion, så andre klienter, der får adgang til dataene, ikke ændrer dem, før de er forpligtet til databasen. Dette kan dog resultere i race-forhold, der ville ende med cirkulære afhængigheder og hænge. Låse var også årsagen til dramatisk dårlig ydeevne fra en applikations side, da applikationer ventede på hinanden, så de kunne få en lås og fortsætte.
Vores tilgang gør det muligt for den første transaktion, der fuldføres, at gå fremad, og de andre, der forsøgte at foretage ændringer i det samme sæt data, bliver nødt til at prøve igen. Dette forhindrer enhver opbremsning af hele økosystemet af applikationer, der kører samtidigt på databasen. Med andre ord tillader vores tilgang lineær skalerbarhed, samtidig med at den giver den atomicitet, som traditionelle transaktionsdatabaser er i stand til at give.
Foreløbige præstationsresultater
Vores transaktionssupportfunktion er i øjeblikket i beta og underkastes omfattende præstationstests.
Nuværende test inkluderer industristandarden TPC-C benchmark ved hjælp af OLTP Bench-applikationen. TPC-C benchmark simulerer et antal køb, der udføres samtidigt på tværs af en række lagre. Skemaet, der bruges i TPC-C, er repræsenteret i følgende entity-relationship diagram:
Tallene i enhedsblokkene repræsenterer tabellernes kardinalitet (antal rækker). Disse tal er faktoriseret med W, antallet af varehuse, for at illustrere databasens skalering. Tallene ved siden af relationspilene repræsenterer relationernes kardinalitet (det gennemsnitlige antal børn pr. forælder). + symbol repræsenterer antallet af små variationer af databasepopulationen.
En ordreplacering kræver, at følgende 10 forespørgsler køres som en enkelt atomtransaktion:
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 betalingstransaktion kræver, at de 6 følgende forespørgsler køres som en enkelt atomtransaktion:
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 regionsservere, der kører på Dell PowerEdge R440-noder, var vi i stand til at opnå følgende resultater:
I denne graf repræsenterer Y-aksen antallet af ordrer, der kan behandles fuldt ud (inklusive oprettelse af nye ordrer, betaling, levering osv.) pr. minut og er udtrykt i tpm-C benchmark. X-aksen repræsenterer antallet af enheder, der udfører transaktioner parallelt.
Disse foreløbige resultater indikerer, at systemet når en peak transaktionsgennemstrømning et sted mellem 150 og 300 transaktorer, og yderligere test er påkrævet for at identificere denne peak.
Efterhånden som denne evne modnes, vil både OpDB-gennemløbet og vores evne til at måle gennemløbet forbedres.
Konklusion
De fleste applikationer udnytter transaktioner til at understøtte det utal af behov, som virksomheder står over for. Men når traditionelle RDBMS'er ikke kan skaleres, er kunderne tvunget til manuelt at sønderdele databasen og administrere hver fragmenteret database som en uafhængig database for sig selv.
Når dette bliver for besværligt at administrere, bør kunderne overveje at migrere denne applikation til Clouderas operationelle database. Kompleks transaktionsunderstøttelse kombineret med ANSI SQL-understøttelse og Apache HBases udskaleringskarakter giver en kombination, der markant kan reducere den operationelle kompleksitet ved styring af vækst.
Hvis du er træt af at administrere sharded databaser og ønsker at sænke databasens TCO, kan du kontakte dit Cloudera-kontoteam for at se, hvordan vi kan hjælpe.