We zijn verheugd om te delen dat we, na het toevoegen van ANSI SQL, secundaire indices, sterschema's en weergavemogelijkheden aan Cloudera's operationele database, in de komende maanden gedistribueerde transactieondersteuning zullen introduceren.
Wat is ACID?
Het ACID-model van databaseontwerp is een van de belangrijkste concepten in databases. ACID staat voor atomiciteit, consistentie, isolatie en duurzaamheid. Lange tijd was strikte naleving van deze vier eigenschappen vereist voor een commercieel succesvolle database. Dit model zorgde echter voor problemen bij het schalen buiten een database met één server. Om aan deze beperking tegemoet te komen, hebben klanten de hardware waarop de databases zijn geïmplementeerd opgeschaald.
NoSQL-databases maakten een of meer van deze 4 eigenschappen los om dramatische verbeteringen in schaalbaarheid te bereiken - Cloudera Operational Database (Powered by Apache HBase) was zo'n database. We hebben compromissen gesloten op het gebied van atomiciteit - in het bijzonder zorgde Cloudera voor atomiciteit met één rij. Ter compensatie ondersteunden we zeer brede tabellen (met mogelijk miljoenen kolommen). Hierdoor konden klanten hun sterschema's denormaliseren en ze weergeven als enkele rijen om atomaire commits te maken in een enkele rij van wat vroeger werd weergegeven als meerdere tabellen.
Sinds de geboorte van HBase hebben we gewerkt aan het bouwen van mogelijkheden die de functiekloof met traditionele RDBM's verkleinen, terwijl we de voordelen van NoSQL-schaalbaarheid, consistentie, duurzaamheid en isolatie behouden.
Eerder dit jaar boden we ondersteuning voor ANSI SQL, secundaire indices, sterschema en views bovenop Apache HBase, waardoor een interface en mogelijkheden werden geboden die bekend zijn bij alle applicatieontwikkelaars die ooit een applicatie hebben gebouwd die MySQL of PostGres gebruikt.
We staan nu aan de vooravond van het leveren van de mogelijkheid om atomaire commits te maken voor gegevens die rijen en tabellen over het cluster kruisen.
Wat is een atomaire transactie?
Een transactie omvat een reeks bewerkingen in een database die atomair worden beheerd, dus alle bewerkingen moeten ofwel volledig worden voltooid (toegewezen) of geen effect hebben (afgebroken).
Momenteel ondersteunen we alleen atomaire transacties met één rij. Dit betekent dat wanneer ontwikkelaars de operationele database van Cloudera willen gebruiken, ze anders moeten nadenken over hun schema.
We introduceren nu de mogelijkheid om complexe transacties uit te voeren die meerdere rijen en tabellen beslaan, wat betekent dat ontwikkelaars een traditioneel sterschema kunnen implementeren of kunnen profiteren van brede kolommen of beide, afhankelijk van hun behoeften. Deze flexibiliteit in combinatie met de evolutionaire schemabenadering van Cloudera Operational Database stelt ontwikkelaars in staat te profiteren van een moderne scale-out database terwijl ze hun bestaande vaardigheden verder ontwikkelen.
Een belangrijk ding om op te merken is dat transactie-ondersteuning in Cloudera Operational Database "lock-free" is en snapshot-isolatiegaranties biedt. Traditionele databases implementeren een "vergrendeling" voor alle gegevens die aan een transactie zijn gekoppeld, zodat andere klanten die toegang hebben tot de gegevens deze niet wijzigen voordat deze aan de database zijn vastgelegd. Dit kan echter resulteren in race-omstandigheden die zouden eindigen met circulaire afhankelijkheden en vastlopen. Vergrendelingen waren ook de oorzaak van dramatisch slechte prestaties van een applicatie, omdat applicaties op elkaar wachtten zodat ze een slot konden krijgen en verder konden gaan.
Onze aanpak zorgt ervoor dat de eerste transactie die is voltooid, verder kan gaan en dat de anderen die probeerden wijzigingen aan te brengen in dezelfde set gegevens het opnieuw moeten proberen. Dit voorkomt een vertraging van het hele ecosysteem van applicaties die tegelijkertijd op de database draaien. Met andere woorden, onze aanpak maakt lineaire schaalbaarheid mogelijk en biedt tegelijkertijd de atomiciteit die traditionele transactiedatabases kunnen bieden.
Voorlopige prestatieresultaten
Onze mogelijkheid om transacties te ondersteunen is momenteel in bèta en wordt onderworpen aan uitgebreide prestatietests.
De huidige tests omvatten de industriestandaard TPC-C-benchmark met behulp van de OLTP Bench-toepassing. De TPC-C-benchmark simuleert een aantal aankopen die tegelijkertijd worden gedaan in een aantal magazijnen. Het schema dat in TPC-C wordt gebruikt, wordt weergegeven in het volgende entiteit-relatiediagram:
De getallen in de entiteitsblokken vertegenwoordigen de kardinaliteit van de tabellen (aantal rijen). Deze getallen zijn ontbonden door W, het aantal magazijnen, om de schaal van de database te illustreren. De getallen naast de relatiepijlen geven de kardinaliteit van relaties weer (het gemiddelde aantal kinderen per ouder). + symbool staat voor het aantal kleine variaties van de databasepopulatie.
Voor het plaatsen van een bestelling moeten de volgende 10 zoekopdrachten worden uitgevoerd als een enkele atomaire transactie:
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 (?,?,?,?,?,?,?,?,?)
Voor een betalingstransactie moeten de volgende 6 zoekopdrachten worden uitgevoerd als een enkele atomaire transactie:
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 (?,?,?,?,?,?,?,?)
Met servers in 3 regio's die op Dell PowerEdge R440-knooppunten draaien, konden we de volgende resultaten behalen:
In deze grafiek geeft de Y-as het aantal orders weer dat volledig kan worden verwerkt (inclusief nieuwe ordercreatie, betaling, levering etc.) per minuut en wordt uitgedrukt in de tpm-C benchmark. De X-as vertegenwoordigt het aantal entiteiten dat parallel transacties uitvoert.
Deze voorlopige resultaten geven aan dat het systeem een piek in de transactiedoorvoer bereikt ergens tussen de 150 en 300 transacties en dat verdere tests nodig zijn om die piek te identificeren.
Naarmate deze mogelijkheid volwassener wordt, zullen zowel de OpDB-doorvoer als ons vermogen om de doorvoer te meten verbeteren.
Conclusie
De meeste toepassingen maken gebruik van transacties om de talloze behoeften van ondernemingen te ondersteunen. Wanneer traditionele RDBMS'en echter niet kunnen schalen, worden klanten gedwongen de database handmatig te sharden en elke gesharde database als een onafhankelijke database op zichzelf te beheren.
Als dit te omslachtig wordt om te beheren, moeten klanten overwegen om die applicatie te migreren naar de operationele database van Cloudera. Complexe transactieondersteuning gecombineerd met ANSI SQL-ondersteuning en het schaalbare karakter van Apache HBase biedt een combinatie die de operationele complexiteit van het beheer van groei aanzienlijk kan verminderen.
Als u het beheer van shard-databases beu bent en de TCO van de database wilt verlagen, neem dan contact op met uw Cloudera-accountteam om te zien hoe we u kunnen helpen.