Wir freuen uns, Ihnen mitteilen zu können, dass wir nach dem Hinzufügen von ANSI SQL, Sekundärindizes, Star-Schema und Ansichtsfunktionen zur Operational Database von Cloudera in den kommenden Monaten die Unterstützung verteilter Transaktionen einführen werden.
Was ist ACID?
Das ACID-Modell des Datenbankdesigns ist eines der wichtigsten Konzepte in Datenbanken. ACID steht für Atomarität, Konsistenz, Isolation und Dauerhaftigkeit. Lange Zeit war die strikte Einhaltung dieser vier Eigenschaften Voraussetzung für eine kommerziell erfolgreiche Datenbank. Dieses Modell führte jedoch zu Problemen bei der Skalierung über eine Ein-Server-Datenbank hinaus. Um dieser Einschränkung Rechnung zu tragen, haben Kunden die Hardware hochskaliert, auf der die Datenbanken bereitgestellt wurden.
NoSQL-Datenbanken lockerten eine oder mehrere dieser 4 Eigenschaften, um dramatische Verbesserungen der Skalierbarkeit zu erreichen – Cloudera Operational Database (unterstützt von Apache HBase) war eine solche Datenbank. Wir haben Kompromisse bei der Atomizität gemacht – insbesondere hat Cloudera eine einreihige Atomizität bereitgestellt. Als Ausgleich haben wir sehr breite Tabellen (mit möglicherweise Millionen von Spalten) unterstützt. Dadurch konnten Kunden ihre Sternschemata denormalisieren und sie als einzelne Zeilen darstellen, um atomare Commits in einer einzelnen Zeile vorzunehmen, die früher als mehrere Tabellen dargestellt wurde.
Seit der Geburt von HBase haben wir daran gearbeitet, Funktionen zu entwickeln, die die Funktionslücke zu herkömmlichen RDBMs schließen und gleichzeitig die Vorteile von NoSQL-Skalierbarkeit, -Konsistenz, -Haltbarkeit und -Isolation beibehalten.
Anfang dieses Jahres haben wir Unterstützung für ANSI SQL, Sekundärindizes, Sternschemata und Ansichten auf Apache HBase bereitgestellt, wodurch eine Schnittstelle und Funktionen bereitgestellt wurden, die allen Anwendungsentwicklern vertraut sind, die jemals eine Anwendung erstellt haben, die MySQL oder PostGres verwendet.
Wir stehen jetzt an der Schwelle zur Bereitstellung der Fähigkeit, atomare Festschreibungen für Daten vorzunehmen, die Zeilen und Tabellen im gesamten Cluster kreuzen.
Was ist eine atomare Transaktion?
Eine Transaktion umfasst eine Reihe von Operationen in einer Datenbank, die atomar verwaltet werden, sodass alle Operationen entweder vollständig abgeschlossen (festgeschrieben) oder wirkungslos (abgebrochen) sein müssen.
Derzeit unterstützen wir nur einzeilige atomare Transaktionen. Das bedeutet, dass Entwickler, wenn sie die Operational Database von Cloudera übernehmen möchten, anders über ihr Schema nachdenken müssen.
Wir führen jetzt die Möglichkeit ein, komplexe Transaktionen zu haben, die sich über mehrere Zeilen und Tabellen erstrecken, was bedeutet, dass Entwickler je nach Bedarf traditionelle Sternschemata implementieren oder breite Spalten oder beides nutzen können. Diese Flexibilität in Kombination mit dem evolutionären Schemaansatz von Cloudera Operational Database ermöglicht es Entwicklern, die Vorteile einer modernen Scale-out-Datenbank zu nutzen und gleichzeitig ihre vorhandenen Fähigkeiten weiterzuentwickeln.
Es ist wichtig zu beachten, dass die Transaktionsunterstützung in der Cloudera Operational Database „lock-free“ ist und Snapshot-Isolationsgarantien bietet. Herkömmliche Datenbanken implementieren eine „Sperre“ für alle Daten, die mit einer Transaktion verbunden sind, sodass andere Clients, die auf die Daten zugreifen, diese nicht ändern, bevor sie in die Datenbank übertragen werden. Dies könnte jedoch zu Race-Bedingungen führen, die zu zirkulären Abhängigkeiten führen und hängen bleiben. Sperren waren auch die Ursache für eine dramatisch schlechte Leistung seitens einer Anwendung, da Anwendungen aufeinander warteten, damit sie eine Sperre erhalten und fortfahren konnten.
Unser Ansatz ermöglicht es, dass die erste abgeschlossene Transaktion fortgesetzt wird und die anderen, die versucht haben, Änderungen an demselben Datensatz vorzunehmen, es erneut versuchen müssen. Dies verhindert eine Verlangsamung des gesamten Ökosystems von Anwendungen, die gleichzeitig auf der Datenbank ausgeführt werden. Mit anderen Worten, unser Ansatz ermöglicht eine lineare Skalierbarkeit und bietet gleichzeitig die Atomizität, die herkömmliche Transaktionsdatenbanken bieten können.
Vorläufige Leistungsergebnisse
Unsere Transaktionsunterstützung befindet sich derzeit in der Betaphase und wird umfangreichen Leistungstests unterzogen.
Zu den aktuellen Tests gehört der branchenübliche TPC-C-Benchmark mit der OLTP-Bench-Anwendung. Der TPC-C-Benchmark simuliert eine Reihe von Einkäufen, die gleichzeitig in mehreren Warenhäusern durchgeführt werden. Das in TPC-C verwendete Schema wird im folgenden Entity-Relationship-Diagramm dargestellt:
Die Zahlen in den Entitätsblöcken repräsentieren die Kardinalität der Tabellen (Anzahl der Zeilen). Diese Zahlen werden durch W, die Anzahl der Warehouses, faktorisiert, um die Datenbankskalierung zu veranschaulichen. Die Zahlen neben den Beziehungspfeilen stellen die Kardinalität von Beziehungen dar (die durchschnittliche Anzahl von Kindern pro Elternteil). Das +-Symbol steht für die kleine Variation der Datenbankpopulation.
Für eine Auftragserteilung müssen die folgenden 10 Abfragen als einzelne atomare Transaktion ausgeführt werden:
1.SELECT c_discount, c_last, C_creditFROM customerWHERE c_w_id =? UND c_d_id =? UND c_id =? 2. SELECT w_taxFROM WarehouseWHERE w_id =?3. SELECT d_next_o_id, D_taxFROM districtWHERE d_w_id =? UND 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 =? UND d_id =? 5. UPSERT INTO new_order (no_o_id, no_d_id, no_w_id)WERTE (?,?,?)6. Upsert in order (o_id, o_d_id, o_w_id, o_c_id, o_entry_d, o_ol_cnt, o_all_local) Werte (?,?,? 7. SELECT i_price, i_name, i_data FROM item WHERE i_id =? 8. Wählen Sie 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 FROS STOCKS, BOTER STOCKS, STOCKS S_I_ID =? UND s_w_id =? 9. Upser in 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 +? UND s_w_id =?10. Einfügen 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) Werte (?,?,?,?,?,?Für eine Zahlungstransaktion müssen die 6 folgenden Abfragen als einzelne atomare Transaktion ausgeführt werden:
1. UPSERT INTO Warehouse (w_ytd, w_id) SELECT w_ytd + ?, w_id FROM Warehouse WHERE w_id =? 2. WÄHLEN Sie 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) Wählen Sie d_ytd +?, D_w_id, d_id aus dem Distrikt, wo d_w_id =? UND d_id =? 4. SELECT d_street_1, d_street_2, d_city, d_state, d_zip, d_name VON Bezirk WHERE d_w_id =? UND d_id =? 6. Upser in den Kunden (c_balance, c_ytd_payment, c_payment_cnt, c_w_id, c_d_id, c_id) Select?,? UND c_d_id =? UND c_id =? 7. Einfügen in die Geschichte (H_C_D_ID, H_C_W_ID, H_C_ID, H_D_ID, H_W_ID, H_DATE, H_AMOUNT, H_DATA) VULE (?,?,?Mit 3 regionalen Servern, die auf Dell PowerEdge R440-Knoten ausgeführt werden, konnten wir die folgenden Ergebnisse erzielen:
In diesem Diagramm stellt die Y-Achse die Anzahl der Bestellungen dar, die vollständig pro Minute verarbeitet werden können (einschließlich neuer Auftragserstellung, Zahlung, Lieferung usw.), und wird im tpm-C-Benchmark ausgedrückt. Die X-Achse stellt die Anzahl der Entitäten dar, die Transaktionen parallel ausführen.
Diese vorläufigen Ergebnisse zeigen, dass das System einen Spitzentransaktionsdurchsatz zwischen 150 und 300 Transaktionen erreicht und weitere Tests erforderlich sind, um diesen Spitzenwert zu identifizieren.
Mit zunehmender Reife dieser Funktion werden sich sowohl der OpDB-Durchsatz als auch unsere Fähigkeit zur Messung des Durchsatzes verbessern.
Schlussfolgerung
Die meisten Anwendungen nutzen Transaktionen, um die unzähligen Anforderungen zu erfüllen, mit denen Unternehmen konfrontiert sind. Wenn herkömmliche RDBMS jedoch nicht skalieren können, sind Kunden gezwungen, die Datenbank manuell zu fragmentieren und jede fragmentierte Datenbank als eigenständige unabhängige Datenbank zu verwalten.
Wenn die Verwaltung zu umständlich wird, sollten Kunden erwägen, diese Anwendung in die Betriebsdatenbank von Cloudera zu migrieren. Komplexe Transaktionsunterstützung in Kombination mit ANSI SQL-Unterstützung und der Scale-out-Natur von Apache HBase bietet eine Kombination, die die betriebliche Komplexität des Wachstumsmanagements erheblich reduzieren kann.
Wenn Sie es leid sind, fragmentierte Datenbanken zu verwalten und die Gesamtbetriebskosten der Datenbank senken möchten, wenden Sie sich an Ihr Cloudera-Kontoteam, um zu erfahren, wie wir Ihnen helfen können.
