Тази статия се появи за първи път в InfoWorld . Препечатва се с разрешение. © IDG Communications, Inc., 2020. Всички права запазени Как MariaDB постига глобален мащаб с Xpand. Xpand вече е наличен в MariaDB SkySQL, като добавя разпределен SQL за мащабируемост и еластичност в облака.
Тъй като нуждите от информация и обработка нарастват, болезнените точки като производителността и устойчивостта налагат нови решения. Базите данни трябва да поддържат съответствие и последователност на ACID, да осигуряват висока наличност и висока производителност и да се справят с огромни работни натоварвания, без да се превръщат в източване на ресурси. Sharding предложи решение, но за много компании шардингът достигна своите граници, поради своята сложност и изисквания към ресурсите. По-добро решение е разпределеният SQL.
При разпределена SQL реализация базата данни се разпределя в множество физически системи, доставяйки транзакции на глобално мащабируемо ниво. MariaDB Platform X5, основна версия, която включва надстройки на всеки аспект на платформата MariaDB, осигурява разпределен SQL и масивна скалируемост чрез добавянето на нов интелигентен двигател за съхранение, наречен Xpand. С споделена архитектура за нищо, напълно разпределени ACID транзакции и силна последователност, Xpand ви позволява да мащабирате до милиони транзакции в секунда.
Оптимизирани интелигентни двигатели с възможност за свързване
MariaDB Enterprise Server е проектиран да използва плъзгащи се двигатели за съхранение (като Xpand) за оптимизиране за определени работни натоварвания от една платформа. Няма нужда от специализирани бази данни за обработка на специфични работни натоварвания. MariaDB Xpand, нашият интелигентен двигател за разпределен SQL, е най-новото допълнение към нашата гама. Xpand добавя масово мащабируеми разпределени транзакционни възможности към опциите, предоставени от другите ни двигатели. Другите ни плъзгащи се двигатели осигуряват оптимизация за аналитични (колонни), тежки за четене натоварвания и тежки за запис. Можете да смесвате и съпоставяте репликирани, разпределени и колонни таблици, за да оптимизирате всяка база данни за вашите специфични изисквания.
Добавянето на MariaDB Xpand позволява на корпоративните клиенти да получат всички предимства на разпределения SQL – скорост, наличност и мащабируемост – като същевременно запазват предимствата на MariaDB, с които са свикнали.
Нека да разгледаме от високо ниво как MariaDB Xpand предоставя разпределен SQL.
Разпределен SQL до индексите
Xpand предоставя разпределен SQL чрез нарязване, репликация и разпространение на данни между възли. Какво означава това? Ще използваме много прост пример с една таблица и три възела, за да демонстрираме концепциите. Непоказаното в този пример е, че всички резени се репликират.
На фигура 1 по-горе имаме таблица с два индекса. Таблицата има някои дати и имаме индекс в колона втора, а друга в колони три и една. Самите индекси са в известен смисъл таблици. Те са подмножества на таблицата. Първичният ключ е id , първият индекс в таблицата. Това ще се използва за хеширане и разпространение на данните от таблицата из базата данни.
Сега добавяме понятието резени . Срезовете са по същество хоризонтални дялове на таблицата. Имаме пет реда в нашата таблица. На фигура 2 таблицата е нарязана и разпределена. Възел №1 има два реда. Възел #2 има два реда, а възел #3 има един ред. Целта е данните да бъдат разпределени възможно най-равномерно между възлите.
Индексите също са нарязани и раздадени. Това е ключова разлика между Xpand и други разпределени решения. Обикновено разпределените бази данни имат локални индекси, така че всеки възел има индекс на собствените си данни. В Xpand индексите се разпределят и съхраняват независимо от таблицата. Това елиминира необходимостта от изпращане на заявка до всички възли (scatter/gather). В примера по-горе възел №1 съдържа редове 2 и 4 от таблицата, а също така съдържа индекси за редове 32 и 35 и редове април и март. Таблицата и индексите са независимо нарязани, разпределени и репликирани във възлите.
Машината за заявки използва разпределените индекси, за да определи къде да намери данните. Той търси само необходимите индексни дялове и след това изпраща заявки само до местата, където се намират необходимите данни. Всички заявки са разпределени. Правят се едновременно и паралелно. Къде отиват зависи изцяло от данните и какво е необходимо за разрешаване на заявката.
Всички резени се репликират поне два пъти. За всеки срез има реплики, намиращи се на други възли. По подразбиране ще има три копия на тези данни – срезът и две реплики. Всяко копие ще бъде на различен възел и ако работите в множество зони за наличност, тези копия също ще се намират в различни зони за наличност.
Обработка на четене и запис
Да вземем друг пример. На фигура 3 имаме пет екземпляра на MariaDB Enterprise Server с Xpand (възли). Има таблица за съхраняване на клиентски профили. Срезът с профила на Шейн е на възел #1 с копия на възел #3 и възел #5. Заявките могат да влязат във всеки възел и ще бъдат обработени по различен начин в зависимост от това дали се четат или записват.
Записванията се извършват до всички копия синхронно в рамките на разпределена транзакция. Всеки път, когато актуализирам профила си „Шейн“, защото промених имейла си или адреса си, тези записи отиват във всички копия едновременно в рамките на транзакция. Това осигурява силна последователност.
На фигура 3 операторът UPDATE отиде до възел #2. Няма нищо на възел #2 относно моя профил, но възел #2 знае къде е моят профил и изпраща актуализации до възел #1, възел #3 и възел #5, след което извършва тази транзакция и се връща обратно към приложението.
Четенията се обработват по различен начин. На диаграмата срезът с моя профил върху него е на възел #1 с копия на възел #3 и възел #5. Това прави възел №1 реплика за класиране. Всеки срез има реплика за класиране, за която може да се каже, че е възелът, който „притежава“ данните. По подразбиране, без значение на кой възел влиза четене, той винаги отива към репликата за класиране, така че всяко SELECT, което се разрешава до мен, ще отиде до възел №1.
Осигуряване на еластичност
Разпределените бази данни като Xpand непрекъснато се променят и развиват в зависимост от данните в приложението. Процесът на ребалансиране е отговорен за адаптирането на разпределението на данните към текущите нужди и поддържането на оптималното разпределение на срезовете между възлите. Има три общи сценария, които изискват преразпределение:добавяне на възли, премахване на възли и предотвратяване на неравномерно натоварване или „горещи точки“.
Например, да кажем, че работим с три възела, но откриваме, че трафикът се увеличава и трябва да мащабираме – добавяме четвърти възел, за да се справим с трафика. Възел №4 е празен, когато го добавим, както е показано на Фигура 4. Ребалансерът автоматично премества резени и реплики, за да използва възел №4, както е показано на Фигура 5.
Ако възел #4 се повреди, ребалансерът автоматично започва да работи отново; този път пресъздаване на резени от техните реплики. Не се губят данни. Репликите също се пресъздават, за да заменят тези, които са били на възел #4, така че всички срезове отново имат реплики на други възли, за да се гарантира висока наличност.
Фигура 6. Ако възел се повреди, Xpand rebalancer пресъздава срезовете и репликите, които се намираха на неуспешния възел, от данните за репликата на другите възли.
Балансиране на натоварването
В допълнение към мащабирането и високата наличност, ребалансерът смекчава неравномерното разпределение на работното натоварване – или горещи точки, или недостатъчно използване. Дори когато данните се разпределят на случаен принцип с перфектен хеш алгоритъм, могат да възникнат горещи точки. Например, може да се случи случайно 10-те продукта, които се продават този месец, да се намират на възел №1. Данните са равномерно разпределени, но работното натоварване не е (Фигура 7). В този тип сценарии ребалансерът ще преразпредели срезове, за да балансира използването на ресурсите (Фигура 8).
Фигура 7. Xpand е разпределил равномерно данните, но натоварването е неравномерно. Възел 1 има значително по-високо работно натоварване от останалите три възела.
Фигура 8. Xpand rebalancer преразпределя фрагменти от данни, за да балансира натоварването между възлите.
Мащабируемост, скорост, наличност, баланс
Нуждите от информация и обработка ще продължат да нарастват. Това е даденост. MariaDB Xpand предоставя последователно, съвместимо с ACID решение за мащабиране за предприятия с изисквания, които не могат да бъдат изпълнени с други алтернативи като репликация и разделяне.
Разпределеният SQL осигурява мащабируемост, а MariaDB Xpand предоставя гъвкавост, за да изберете колко мащабируемост ви е необходима. Разпределете една таблица или няколко таблици или дори цялата си база данни, изборът е ваш. Оперативно капацитетът се регулира лесно, за да отговори на променящите се изисквания на работното натоварване във всеки един момент. Никога не трябва да бъдете прекомерно обезпечени.
Xpand също така прозрачно защитава срещу неравномерно използване на ресурсите, динамично преразпределяйки данните, за да балансира натоварването между възлите и да предотврати горещи точки. За разработчиците няма нужда да се притеснявате за мащабируемостта и производителността. Xpand е еластичен. Xpand също така осигурява резервиране и висока наличност. С данни, нарязани, репликирани и разпределени между възли, данните са защитени и се поддържа излишък в случай на повреда на хардуера.
И с архитектурата на MariaDB, вашите разпределени таблици ще играят добре – включително JOIN-и между различни двигатели – с другите ви таблици MariaDB. Създайте решението за база данни, от което се нуждаете, като смесите и съпоставите репликирани, разпределени или колонни таблици в една база данни на платформата MariaDB.
