Z radością informujemy, że po dodaniu ANSI SQL, indeksów pomocniczych, schematu gwiazdy i możliwości przeglądania do operacyjnej bazy danych Cloudera, w nadchodzących miesiącach wprowadzimy obsługę transakcji rozproszonych.
Co to jest KWAS?
Model ACID projektowania baz danych jest jednym z najważniejszych pojęć w bazach danych. ACID oznacza atomowość, spójność, izolację i trwałość. Przez bardzo długi czas, aby baza danych odniosła sukces komercyjny, konieczne było ścisłe przestrzeganie tych czterech właściwości. Jednak ten model spowodował problemy, jeśli chodzi o skalowanie poza jednoserwerową bazę danych. Aby uwzględnić to ograniczenie, klienci skalowali sprzęt, na którym wdrożono bazy danych.
Bazy danych NoSQL poluzowały jedną lub więcej z tych 4 właściwości, aby osiągnąć znaczną poprawę skalowalności — jedną z takich baz danych była operacyjna baza danych Cloudera (oparta na Apache HBase). Dokonaliśmy kompromisów w kwestii atomowości — w szczególności Cloudera zapewniła atomowość jednorzędową. Aby to zrekompensować, obsługiwaliśmy bardzo szerokie tabele (potencjalnie z milionami kolumn). Umożliwiło to klientom denormalizację ich schematów gwiaździstych i przedstawienie ich jako pojedynczych wierszy w celu wykonania niepodzielnych zmian w jednym wierszu tego, co kiedyś było reprezentowane jako wiele tabel.
Od narodzin HBase pracujemy nad tworzeniem możliwości, które zmniejszają lukę między funkcjami w tradycyjnych RDBM, jednocześnie zachowując korzyści płynące ze skalowalności, spójności, trwałości i izolacji NoSQL.
Na początku tego roku zapewniliśmy obsługę ANSI SQL, indeksów pomocniczych, schematu gwiazdy i widoków na szczycie Apache HBase, zapewniając interfejs i możliwości znane wszystkim programistom aplikacji, którzy kiedykolwiek zbudowali aplikację korzystającą z MySQL lub PostGres.
Jesteśmy teraz na krawędzi zapewnienia możliwości wykonywania atomowych zatwierdzeń danych, które przecinają wiersze i tabele w klastrze.
Co to jest transakcja atomowa?
transakcja składa się z zestawu operacji w bazie danych, które są zarządzane niepodzielnie, więc wszystkie operacje muszą być całkowicie zakończone (zatwierdzone) lub nie mieć żadnego efektu (przerwane).
Obecnie obsługujemy tylko jednowierszowe transakcje atomowe. Oznacza to, że gdy programiści chcą adoptować operacyjną bazę danych Cloudera, muszą inaczej myśleć o swoim schemacie.
Wprowadzamy teraz możliwość posiadania złożonych transakcji, które obejmują wiele wierszy i tabel, co oznacza, że programiści mogą implementować tradycyjny schemat gwiaździsty lub korzystać z szerokich kolumn lub obu, w zależności od swoich potrzeb. Ta elastyczność w połączeniu z ewolucyjnym podejściem do schematów Cloudera Operational Database pozwala programistom na korzystanie z nowoczesnej bazy danych skalowalnej w poziomie przy jednoczesnym rozwijaniu ich dotychczasowych umiejętności.
Należy zauważyć, że obsługa transakcji w Operacyjnej Bazie Danych Cloudera jest „wolna od blokad” i zapewnia gwarancje izolacji migawek. Tradycyjne bazy danych implementują „blokadę” wszystkich danych związanych z transakcją, aby inni klienci uzyskujący dostęp do danych nie zmieniali ich przed zatwierdzeniem ich w bazie danych. Może to jednak skutkować warunkami wyścigu, które kończą się zależnościami kołowymi i zawieszają się. Blokady były również przyczyną dramatycznie niskiej wydajności aplikacji, ponieważ aplikacje czekały na siebie nawzajem, aby uzyskać blokadę i kontynuować.
Nasze podejście umożliwia przejście pierwszej zakończonej transakcji do przodu, a pozostałe, które próbowały wprowadzić zmiany w tym samym zestawie danych, będą musiały ponowić próbę. Zapobiega to spowolnieniu całego ekosystemu aplikacji działających jednocześnie w bazie danych. Innymi słowy, nasze podejście umożliwia liniową skalowalność, zapewniając jednocześnie atomowość, którą są w stanie zapewnić tradycyjne transakcyjne bazy danych.
Wstępne wyniki wydajności
Nasze możliwości obsługi transakcji są obecnie w fazie beta i poddawane są szeroko zakrojonym testom wydajności.
Bieżące testy obejmują standard branżowy benchmark TPC-C przy użyciu aplikacji OLTP Bench. Benchmark TPC-C symuluje wiele zakupów przeprowadzanych jednocześnie w wielu magazynach. Schemat używany w TPC-C jest reprezentowany na następującym schemacie relacji encji:
Liczby w blokach encji reprezentują liczność tabel (liczbę wierszy). Liczby te są rozłożone na czynniki przez W, liczbę Magazynów, aby zilustrować skalowanie bazy danych. Liczby obok strzałek relacji reprezentują liczność relacji (średnią liczbę dzieci na rodzica). Symbol + reprezentuje liczbę małą zmienność populacji bazy danych.
Złożenie zamówienia wymaga uruchomienia następujących 10 zapytań jako pojedynczej transakcji atomowej:
1.SELECT c_discount, c_last, C_creditFROM customerWHERE c_w_id =? ORAZ c_d_id =? ORAZ c_id =? 2. SELECT w_taxFROM magazynWHERE 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_idFROM districtWHERE d_w_id =? ORAZ d_id =? 5. WSTAW DO new_order (no_o_id, no_d_id, no_w_id)WARTOŚCI (?,?,?)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 (?,?,?,?, ?,?, dla każdego zamówienia) Powtórz przy 7. SELECT i_price, i_name, i_data, FROM item WHERE i_id =? 8. Wybierz 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 Od zapasu, gdzie s_i_id =? ORAZ s_w_id =? 9. Upsert do magazynu (S_Quantity, S_YTD, S_ORDER_CNT, S_REMOTE_CNT, S_I_ID, S_W_ID) Wybierz?, S_YTD +?, S_ORDER_CNT + 1, S_REMOTE_CNT +?, S_I_ID, S_W_IDFROM STOTES S_I_ID =? ORAZ 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, ?,?Transakcja płatnicza wymaga uruchomienia 6 następujących zapytań jako pojedynczej transakcji atomowej:
1. UPSERT INTO (w_ytd, w_ytd, w_ytd) SELECT w_ytd + ?, w_id FROM magazynu WHERE w_id =? 2. SELECT w_ulica_1, w_ulica_2, w_miasto, w_stan, w_zip, w_nameFROM magazynWHERE w_id =?3. UPSERT INTO district (d_ytd, d_w_id, d_id) SELECT d_ytd + ?, d_w_id, d_id FROM d_w_id =? ORAZ d_id =? 4. SELECT d_street_1, d_street_2, d_city, d_state, d_zip, d_name FROM powiat GDZIE d_w_id =? ORAZ 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_ _ _ c_id, c_ _ _ ORAZ c_d_id =? ORAZ c_id =? 7. WSTAW DO historii (h_c_d_id, h_c_w_id, h_c_id, h_d_id, h_w_id, h_date, h_amount, h_data) VALUES, ?,?,?,?Dzięki 3 serwerom regionalnym działającym w węzłach Dell PowerEdge R440 byliśmy w stanie osiągnąć następujące wyniki:
Na tym wykresie oś Y reprezentuje liczbę zamówień, które można w pełni przetworzyć (w tym tworzenie nowych zamówień, płatność, dostawę itp.) na minutę i jest wyrażona w benchmarku tpm-C. Oś X reprezentuje liczbę podmiotów wykonujących transakcje równolegle.
Te wstępne wyniki wskazują, że system osiąga szczytową przepustowość transakcji gdzieś pomiędzy 150 a 300 podmiotami transakcyjnymi i wymagane są dalsze testy w celu zidentyfikowania tego szczytu.
W miarę dojrzewania tej możliwości zarówno przepustowość OpDB, jak i nasza zdolność do mierzenia przepustowości ulegną poprawie.
Wniosek
Większość aplikacji wykorzystuje transakcje do obsługi niezliczonych potrzeb, z jakimi borykają się przedsiębiorstwa. Jednakże, gdy tradycyjne RDBMS nie mogą być skalowane, klienci są zmuszeni ręcznie podzielić bazę danych i zarządzać każdą podzieloną bazą danych jako niezależną bazą danych.
Gdy staje się to zbyt uciążliwe, aby zarządzać, klienci powinni rozważyć migrację tej aplikacji do operacyjnej bazy danych Cloudera. Złożona obsługa transakcji w połączeniu z obsługą ANSI SQL i skalowalnością Apache HBase zapewnia kombinację, która może znacznie zmniejszyć operacyjną złożoność zarządzania wzrostem.
Jeśli masz dość zarządzania bazami danych podzielonych na fragmenty i chcesz obniżyć całkowity koszt posiadania bazy danych, skontaktuj się z zespołem ds. kont Cloudera, aby dowiedzieć się, jak możemy Ci pomóc.
