Какво представлява MongoDB Sharding и най-добрите практики?

Как да мащабирам MongoDB? Кои са най-добрите практики за заточване?


Въпреки че гъвкавата схема е как повечето хора се запознават с MongoDB, тя е и една от най-добрите бази данни (може би дори най-добрата, когато става въпрос за ежедневните приложения) за работа с много, много големи масиви от данни. Докато обосновката на този аргумент изисква сама по себе си цяла статия (надявам се, че някой ден мога да намеря време за нея!), Общата идея е, че базирани на SQL решения не поддържат изостряне и да я надграждат трудно.

Най-доброто, на което можете да се надявате, е да създадете клъстер (който между другото няма нищо общо с изострянето) или да потърсите управлявано решение като RDS на Amazon или Cloud SQL на Google, които стават изключително скъпи с нарастването на вашите данни.

В тази статия ще разгледаме една от основните техники за хоризонтално мащабиране на база данни: изостряне, за MongoDB и препоръчайте някои най-добри практики за същото. Въпреки това смятам, че е по-добре да започнем с основите на зарязването, защото много хора, които търсят да мащабират MongoDB, може да не са много запознати с него.

Ако обаче сте наясно с рязкостта, не се колебайте да прегледате следващия раздел.

Основи на изостряне

Може би сте забелязали употребата на думата „хоризонтална“ в последния параграф от предишния раздел. Без да тръгвам в поредния масивен обход, искам бързо да докажа тази точка. Разглеждането на мащаби се счита за два вида: или получавате по-мощна машина с по-голям капацитет за съхранение (вертикален) или свържете няколко по-малки компютъра и образувате колекция (хоризонтален).

Сега, като се има предвид, че дори и най-добрите сървъри в момента нямат повече от 256 GB RAM или 16 TB твърд диск, вие удряте тухлена стена скоро, когато се опитвате да мащабирате вертикално (или “мащабирате”, както върви терминологията). Можете обаче да свържете колкото се може повече единични машини (поне теоретично) и да заобиколите това ограничение лесно.

Разбира се, сега предизвикателството е да се координира между всички тези машини.

Заточване на база данни

Терминът “заточване” обикновено се прилага за бази данни, като идеята е, че една машина никога не може да бъде достатъчна за съхраняване на всички данни. При заточване базата данни се „разделя“ на отделни парчета, които се намират на различни машини. Един прост пример може да бъде: да предположим, че бизнесът разполага с машини, които могат да съхраняват до 2 милиона елемента с данни за клиенти. Сега бизнесът достига тази граница и скоро ще надмине 2,5 милиона потребители. И така, те решават да разбият базата си данни на две:

И магически, капацитетът на системата вече се удвоява!

Е, ако само животът беше толкова прост! ��

Предизвикателства в изострянето на базата данни

Щом сте обмислили малко задълбочено, някои злобни предизвикателства отвръщат грозната им глава.

Няма първични ключове

Щом излезете от една база данни, първичните ключове губят своето значение. Например, ако вашите първични ключове са настроени на автоматично увеличение и преместите половината от данни в друга база данни, сега ще имате два различни елемента данни за всеки първичен ключ.

Без чужди ключове

Тъй като в базата данни няма поддръжка, която да сочи към субекти извън текущата база данни (добре, дори различна база данни на една и съща машина не се поддържа, така че забравете за база данни на друга машина), концепцията за чужди ключове се отнася до хвърляне като добре. Изведнъж базата данни става „тъпа“ и целостта на данните е ваш проблем.

Странни грешки в данните

Ако една машина изгасне, на крайния потребител може да се покаже „Ами сега, нещо се счупи!“ страница, която без съмнение ще дразни, но след известно време животът ще бъде на път.

Сега помислете какво се случва в базата данни с разрез. Да предположим, че разделената база данни в нашия по-ранен пример е банкова база данни и един клиент изпраща пари на друг. Да предположим също, че данните на първия клиент живеят в първия шейд, докато данните на втория клиент живеят във втория фрагмент (виждате ли къде отивам с това ?!). Ако машината, съдържаща втория фрагмент, не успее, можете ли да си представите в какво състояние ще се намира системата? Къде ще отидат парите за транзакцията? Какво ще види първият потребител? Какво ще види вторият потребител? Какво ще видят двамата, когато парчетата са отново онлайн?

Управление на транзакциите

Нека разгледаме също така критичния случай на управление на транзакции. Този път да предположим, че системата работи 100% глоба. Сега двама души (A и B) извършват плащане към трети (C). Много е вероятно и двете транзакции да прочетат салдото по сметката на C едновременно, причинявайки това объркване:

  • Салдо по сметката на C = 100 $.
  • Една транзакция гласи баланса на C: 100 USD.
  • В транзакцията се изписва салдото на C: 100 USD.
  • Една транзакция добавя $ 50 и актуализира салдото: $ 100 + 50 = 150 $.
  • Транзакцията на B добавя $ 50 и актуализира салдото: $ 100 + 50 = 150 $.

По дяволите! 50 долара току-що изчезнаха!

Традиционните SQL системи ви спестяват от това, като предоставят вградено управление на транзакции, но щом излезете от една машина, ще препечете.

Важното е, че с такива системи е лесно да се сблъскате с проблеми с корупцията на данни, от които е невъзможно да се възстанови. Издърпването на косата също няма да помогне! ��

MongoDB заточване

За софтуерните архитекти вълнението от MongoDB не беше толкова в гъвкавата му схема, колкото в неговата вградена поддръжка за заточване. Със само няколко прости правила и свързани машини, вие бяхте готови да стартирате стриган MongoDB клъстер за нула време.

Изображението по-долу показва как изглежда това при типично внедряване на уеб приложения.

Кредит за изображение: mongodb.com

Най-добрата част за монтирането на MongoDB е, че дори балансирането на парчетата е автоматично. Тоест ако имате пет парчета и две от тях са почти празни, можете да кажете на MongoDB да балансира нещата по начин, че всички парчета са еднакво пълни.

Като разработчик или администратор не е нужно да се притеснявате много, тъй като MongoDB зад кулисите прави повечето от тежките повдигания. Същото важи и за частичната повреда на възлите; ако имате правилно конфигурирани набори реплики и се изпълняват на вашия клъстер, частичните прекъсвания няма да повлияят на продължителността на системата.

Цялото обяснение ще стане доста кратко, затова ще затворя този раздел, като казвам, че MongoDB има няколко вградени инструмента за разширяване, репликация и възстановяване, което прави много лесно за разработчиците да изграждат мащабни приложения. Ако искате по-подробно ръководство за изострянето на възможностите на MongoDB, то официални документи са мястото, което трябва да бъде.

Може да се интересувате и от това пълно ръководство за програмисти.

MongoDB Sharding Най-добри практики

Докато MongoDB „просто работи“ извън кутията за заточване, това не означава, че можем да почиваме на лаврите си. Шардингът може да направи или разруши вашия проект завинаги, в зависимост от това колко добре или лошо е направен.

Освен това, има много малки детайли, които трябва да се отчетат, ако не се случва, не е рядкост да се вижда, че проектите се сриват. Намерението не е да ви плаши, а да подчертае необходимостта от планиране и да бъдете изключително внимателни дори и при малки решения.

Ключът за заточване неизбежно контролира заточването в MongoDB, така че е идеално да започнем проучването си с това.

Висока кардиналност

Кардиналност означава размерът на вариацията. Например, колекция от любима страна от 1 милион души ще има малки вариации (има само толкова много страни в света!), Докато колекция от техните имейл адреси ще имат (перфектно) висока кардиналност. Защо има значение? Да предположим, че сте избрали наивна схема, която изрязва данни въз основа на името на потребителя.

Тук имаме доста проста подредба; входящият документ се сканира за потребителско име и в зависимост от това къде се намира първата буква в английската азбука, той се приземява в една от трите части. По подобен начин търсенето на документ е лесно: подробностите за „Питър“, например, ще бъдат във втория шрифт със сигурност.

Всичко това звучи добре, но въпросът е, че ние не контролираме имената на потребителите на входящите документи. Ами ако през повечето време получаваме само имена в диапазона от B до F? Ако е така, ще имаме онова, наречено „джъмбо” парче в shard1: повечето от системните данни ще бъдат препълнени там, което ефективно превръща настройката в единна база данни.

Лекарството?

Изберете ключ с висока кардиналност – например имейл адреса на потребителите или дори можете да потърсите комбиниран ключ за разделяне, който е комбинация от множество полета.

Монотонно се променя

Често срещана грешка при заострянето на MongoDB е да използвате монотонно увеличаващи се (или автоматично увеличаващи се, ако желаете) клавиши като клавиш за разместване.

Като цяло се използва първичният ключ на документа. Идеята тук е добронамерена, а именно, тъй като новите документи продължават да се създават, те ще попадат равномерно в една от наличните части. За съжаление подобна конфигурация е класическа грешка. Това е така, защото ако клавишът за острие винаги се увеличава, след като данните от точките ще започнат да се натрупват във висококачествената страна на частиците, причинявайки дисбаланс в системата.

Кредит за изображение: mongodb.com

Както можете да видите на изображението, след като преминем през 20-те гами, всички документи започват да се събират в Chunk C, предизвиквайки монолит там. Решението е да се премине към хеширана клавишна схема, която създава ключ за заточване чрез бъркане на едно от предоставените полета и използване на това за определяне на парчето.

Кредитна снимка: Mongodb.com

Хешираният ключ за острие изглежда така:

{
"_документ за самоличност" :"6b85117af532da651cc912cd"
}

. . . и може да бъде създаден в клиентската обвивка на Mongo, като използвате:

db.collection.createIndex ({_id: hashedValue})

Остъргвам рано

Един от най-полезните съвети директно от окопите е да се стриете по-рано, дори ако в крайна сметка имате малък, двукратен клъстер. След като данните преминат 500 GB или нещо подобно, рязкостта се превръща в разхвърлян процес в MongoDB и трябва да сте готови за гадни изненади. Освен това процесът на балансиране консумира много големи количества пропускателна способност на мрежата, което може да задуши системата, ако не сте внимателни.

Не всички обаче се усилват. Като интересен пример (ученето наистина е в коментарите) вижте тази хубава Перкона блог.

Пускане на баланс

Друга добра идея е да следите моделите си на трафик и да стартирате балансиращия механизъм само в ниско трафик време. Както вече споменах, самото балансиране отнема значителна честотна лента, което бързо може да доведе до обхождане на цялата система. Не забравяйте, че неуравновесените парчета не са причина за незабавна паника. Просто оставете нормалното използване да продължи, изчакайте възможностите за нисък трафик и оставете балансиращия да направи останалото!

Ето как можете да постигнете това (при условие че имате малък трафик от 3 до 5 часа сутринта):

използвайте config
db.settings.update (
{ _документ за самоличност: "стабилизатор" },
{$ set: {activeWindow: {старт: "03:00", Спри се : "05:00" }}},
{upsert: true}
)

заключение

Свиването и мащабирането на всяка база данни е сложно начинание, но за щастие MongoDB го прави по-управляем от други популярни бази данни там.

Наистина имаше момент, в който MongoDB не беше правилният избор за всеки проект (благодарение на няколкото критични проблема и поведението по подразбиране), но тези отдавна са изчезнали. Наред с изострянето, балансирането, автоматичното компресиране, разпределеното заключване на агрегатно ниво и много такива функции, MongoDB се измина с километри напред, днес е първият избор на софтуерния архитект.

Надявам се, че тази статия е успяла да хвърли малко светлина върху това какво заточване е в MongoDB и за какво трябва да се грижи разработчикът, когато преминава към мащаб. За да научите повече, може да получите това онлайн курс за овладяване на MongoDB.

ЕТИКЕТИ:

  • База данни

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map