Радваме се да споделим, че след добавяне на ANSI SQL, вторични индекси, звездна схема и възможности за изглед към оперативната база данни на Cloudera, ще въведем поддръжка за разпределени транзакции през следващите месеци.
Какво е КИСЕЛИНА?
ACID моделът на проектиране на база данни е една от най-важните концепции в базите данни. ACID означава атомност, консистенция, изолация и издръжливост. За много дълго време се изискваше стриктно спазване на тези четири свойства за търговски успешна база данни. Този модел обаче създаде проблеми, когато ставаше дума за мащабиране извън една база данни от един сървър. За да се справят с това ограничение, клиентите разшириха хардуера, на който са разгърнати базите данни.
Базите данни NoSQL разхлабиха едно или повече от тези 4 свойства, за да постигнат драматични подобрения в мащабируемостта - Cloudera Operational Database (захранвана от Apache HBase) беше една такава база данни. Направихме компромиси с атомарността - по-специално, Cloudera предостави атомарност в един ред. За да компенсираме, ние поддържахме много широки таблици (с потенциално милиони колони). Това позволи на клиентите да денормализират своите звездни схеми и да ги представят като единични редове, за да направят атомни ангажименти в един ред от това, което преди е било представено като множество таблици.
От раждането на HBase ние работим за изграждане на възможности, които намаляват пропастта между функциите с традиционните RDBM, като същевременно поддържаме предимствата на NoSQL мащабируемостта, последователността, издръжливостта и изолацията.
По-рано тази година предоставихме поддръжка за ANSI SQL, вторични индекси, звездна схема и изгледи върху Apache HBase, като предоставихме интерфейс и възможности, познати на всички разработчици на приложения, които някога са създавали приложение, което използва MySQL или PostGres.
Сега сме на крачка от предоставянето на възможността за извършване на атомни ангажименти към данни, които пресичат редове и таблици в клъстера.
Какво е атомна транзакция?
транзакция включва набор от операции в база данни, които се управляват атомарно, така че всички операции трябва или да бъдат изцяло завършени (ангажирани), или да нямат ефект (прекратени).
Понастоящем поддържаме само едноредови атомни транзакции. Това означава, че когато разработчиците искат да приемат оперативната база данни на Cloudera, те трябва да мислят по различен начин за своята схема.
Сега въвеждаме възможността да имаме сложни транзакции, които обхващат множество редове и таблици, което означава, че разработчиците могат да прилагат традиционна звездна схема или да се възползват от широки колони или и двете в зависимост от техните нужди. Тази гъвкавост, съчетана с подхода на еволюционната схема на Cloudera Operational Database, позволява на разработчиците да се възползват от модерна мащабирана база данни, като същевременно продължат съществуващите си умения.
Важно нещо, което трябва да се отбележи, е, че поддръжката на транзакции в Cloudera Operational Database е „без заключване“ и осигурява гаранции за изолиране на моментни снимки. Традиционните бази данни прилагат „заключване“ към всички данни, свързани с транзакция, така че други клиенти, които имат достъп до данните, да не ги променят, преди да бъдат ангажирани в базата данни. Това обаче може да доведе до условия на състезание, които ще завършат с кръгови зависимости и ще увиснат. Заключванията също бяха причина за драматично ниска производителност от страна на приложението, тъй като приложенията чакаха едно друго, за да могат да получат заключване и да продължат.
Нашият подход позволява на първата транзакция, която завърши, да продължи напред, а останалите, които са се опитвали да направят промени в същия набор от данни, ще трябва да опитат отново. Това предотвратява всяко забавяне на цялата екосистема от приложения, работещи едновременно в базата данни. С други думи, нашият подход позволява линейна мащабируемост, като същевременно осигурява атомарността, която традиционните транзакционни бази данни могат да осигурят.
Предварителни резултати от изпълнението
Възможността ни за поддръжка на транзакции в момента е в бета версия и се подлага на обширно тестване на производителността.
Текущите тестове включват стандартния за индустрията бенчмарк TPC-C с помощта на приложението OLTP Bench. Показателят TPC-C симулира множество покупки, извършени едновременно в редица складове. Схемата, използвана в TPC-C, е представена в следната диаграма на връзката между обект и връзка:
Числата в блоковете за обекти представляват мощността на таблиците (брой редове). Тези числа са разложени на фактор W, броят на складовете, за да се илюстрира мащабирането на базата данни. Числата до стрелките за връзката представляват кардиналността на връзките (средния брой деца на родител). + символът представлява малкия брой вариации на популацията на базата данни.
Поставянето на поръчка изисква следните 10 заявки да се изпълняват като една атомна транзакция:
1.ИЗБЕРЕТЕ c_discount, c_last, C_creditFROM customerWHERE c_w_id =? И c_d_id =? И c_id =? 2. ИЗБЕРЕТЕ w_taxFROM warehouseWHERE w_id =?3. ИЗБЕРЕТЕ d_next_o_id, D_taxFROM districtWHERE d_w_id =? И d_id =?4. UPSERT INTO район (d_next_o_id, d_w_id, d_id)ИЗБЕРЕТЕ d_next_o_id + 1, d_w_id, _ d_w_id, _ HER d_w_id, _ F И d_id =? 5. UPSERT INTO new_order (no_o_id, no_d_id, no_w_id)VALUES (?,?,?)6. UpSert в поръчка (o_id, o_d_id, o_w_id, o_c_id, o_entry_d, o_ol_cnt, o_all_local) стойности (?,?,?,?,?,?) Повторете следните заявки за всеки елемент, избран за поръчка. 7. ИЗБЕРЕТЕ i_price, i_name, i_data ОТ артикул КЪДЕ i_id =? 8. Изберете 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 от запасите, където s_i_id =? И s_w_id =? 9. Upsert в акции (s_quantity, s_ytd, s_order_cnt, s_remote_cnt, s_i_id, s_w_id) Изберете?, S_YTD +?, S_ORDER_CNT + 1, s_REMOTE_CNT +? И s_w_id =?10. Вмъкнете в 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) стойности (?,?,?,?,?,?,?,?)Платежната транзакция изисква 6-те следните заявки да се изпълняват като единична атомна транзакция:
1. UPSERT INTO warehouse (w_ytd, w_id) ИЗБЕРЕТЕ w_ytd + ?, w_id w_id w_id w_id W = 2. ИЗБЕРЕТЕ w_street_1, w_street_2, w_city, w_state, w_zip, w_nameFROM warehouseWHERE w_id =?3. Upsert в областта (d_ytd, d_w_id, d_id) Изберете d_ytd +?, D_w_id, d_id от област, където d_w_id =? И d_id =? 4. ИЗБЕРЕТЕ d_street_1, d_street_2, d_city, d_state, d_zip, d_zip, d_zip, d_zip, d_zip, d_zip, d_zip, d_zip, d_zip, d_zip, d_zip, d_zip, d_zip, d_zip, d_zip, d_zip, d_zip, d_zip, d_zip, d_zip, d_zip, И d_id =? 6. Upsert в клиента (c_balance, c_ytd_payment, c_payment_cnt, c_w_id, c_d_id, c_id) изберете?,?, ?, c_w_id, c_d_id, c_idfrom customerwhere c_w_id =? И c_d_id =? И c_id =? 7. Вмъкнете в историята (h_c_d_id, h_c_w_id, h_c_id, h_d_id, h_w_id, h_date, h_amount, h_data) стойности (?,?,?,?, ?, ?,?)С 3 регионални сървъра, работещи на възли Dell PowerEdge R440, успяхме да постигнем следните резултати:
В тази графика оста Y представлява броя на поръчките, които могат да бъдат напълно обработени (включително създаване на нова поръчка, плащане, доставка и т.н.) на минута и се изразява в tpm-C еталон. Оста X представлява броя на обектите, изпълняващи транзакции паралелно.
Тези предварителни резултати показват, че системата достига пикова транзакционна пропускателна способност някъде между 150 и 300 транзакции и е необходимо допълнително тестване, за да се идентифицира този пик.
С нарастването на тази способност както пропускателната способност на OpDB, така и способността ни да измерваме пропускателната способност ще се подобрят.
Заключение
Повечето приложения използват транзакции, за да поддържат безбройните нужди, пред които са изправени предприятията. Въпреки това, когато традиционните RDBMS не могат да се мащабират, клиентите са принудени ръчно да разделят базата данни и да управляват всяка разделена база данни като независима база данни самостоятелно.
Когато това стане твърде тромаво за управление, клиентите трябва да обмислят мигрирането на това приложение към оперативната база данни на Cloudera. Поддръжка на сложни транзакции, съчетана с поддръжка на ANSI SQL и естеството на мащабиране на Apache HBase осигурява комбинация, която може значително да намали оперативната сложност на управлението на растежа.
Ако сте уморени да управлявате разчленени бази данни и искате да намалите TCO на базата данни, свържете се с екипа на вашия акаунт в Cloudera, за да видите как можем да помогнем.
