Разгръщането на клъстери е от голямо значение за осигуряване на висока наличност на данни, както и за защитата им. MongoDB подобрява това чрез репликация и разделяне, при което репликацията осигурява вертикално мащабиране чрез повдигане на излишък, докато разделянето увеличава хоризонталното мащабиране.
Като цяло и двата подхода се опитват да разпределят натоварването между членовете и по този начин да намалят натоварването, на което може да бъде подложен един възел. След това производителността на базата данни може да се разглежда като бърза при обслужване на потребителите с операции с пропускателна способност. Въпреки това, без основна клъстерна архитектура, може да не видите същото ниво на резултати, дори ако опитате разделяне и репликация.
Ако членовете на набора от реплики са четни, тогава ще бъде трудно за членовете да гласуват и да изберат за нов първичен избор, ако съществуващият се провали в даден момент. В този блог ще обсъдим стандартната архитектура за внедряване, която човек може да използва, но това може да варира в зависимост от изискванията на приложението.
Стратегии за внедряване на MongoDB
Архитектурата на наборите реплики е много определяща за капацитета и възможностите на MongoDB.
Наборът реплики с три възела е стандартното внедряване на клъстер за MongoDB във всяка производствена среда, тъй като осигурява резервиране на данни и толерантност към грешки. Резервирането е важно особено при възстановяване на база данни след бедствие. Наборът реплики от три възли може да бъде основната архитектура за внедряване, но това може да варира в зависимост от спецификациите и изискванията на приложението. Въпреки това, не го правете твърде сложно, тъй като това може да ви доведе до някои по-големи проблеми с конфигурацията.
Стратегии за разделяне на MongoDB
Разделянето намалява натоварването, върху което базата данни трябва да работи за дадена заявка, като намалява броя на документите, върху които трябва да се предприемат действия. Поради това повишава хоризонталното мащабиране, позволявайки на базата данни да нарасне отвъд хардуерните граници на един сървър. В зависимост от търсенето на работното натоварване възлите могат да се добавят или премахват от клъстера и MongoDB ще балансира данните по оптимален начин без намеса на операцията.
Някои от най-добрите стратегии за внедряване на разчленен клъстер включват:
Гарантиране на равномерно разпределение на ключовете на сегменти
Причината за разделянето е хоризонталното мащабиране на базата данни и намаляване на броя на операциите с пропускателна способност, на които един екземпляр може да бъде подложен. Ако не разпределите равномерно ключовете на фрагментите, може да се окажете с малък брой фрагменти. С няколко фрагмента операциите могат да бъдат ограничени от капацитета на един фрагмент, което прави операциите за четене и запис бавни.
Чанковете трябва да бъдат предварително разделени и разпределени първо
Шардовете имат блокове от данни, които са групирани според някои критерии за ключ. Когато създавате нова разчленена колекция, преди да я заредите с данни, трябва да създадете празни парчета и да ги разпределите равномерно върху всички фрагменти. Когато ще попълвате MongoDB с данни, ще бъде лесно да балансирате натоварването между участващите фрагменти. Опцията numInitialChunks може да се използва за това автоматично, ако използвате базирано на хеш разделяне. Целочислената стойност обаче трябва да бъде по-малка от 8192 на фрагмент.
Брой парчета
Често се изискват два фрагмента като минимален брой за постигане на значимост на разделянето. Един фрагмент е полезен само ако искате да поставите основата за разрешаване на разделяне в бъдеще и няма нужда по време на внедряването.
Предпочетете разделяне, базирано на диапазон, пред базирано на хеш разделяне
Шардирането, базирано на обхвата, е полезно, тъй като осигурява повече фрагменти, следователно операциите могат да бъдат насочени към най-малкото необходими фрагменти и по-често към единичен фрагмент. На практика това може да е трудно, освен ако не разбирате добре използваните данни и модели на заявки. Хешираното разделяне подобрява равномерното разпределение на операциите с пропускателна способност за сметка на предоставянето на операции, базирани на по-нисък диапазон.
Използвайте заявки с разпръснато събиране само за големи агрегирани заявки
Заявките, които не могат да бъдат насочени въз основа на ключ на сегмент, трябва да се излъчват към всички сегменти за оценка и тъй като включват множество фрагменти за всяка заявка, те не се мащабират линейно, тъй като се добавят повече фрагменти, което води до допълнителни разходи което влошава производителността на базата данни. Тази операция е известна като scatter-gather и може да бъде избегната само ако включите ключа на фрагмента в заявката си.
Подходът е полезен само при работа с големи агрегирани заявки, при които всяка заявка може да бъде разрешена да се изпълнява паралелно на всички сегменти.
Стратегии за репликация на MongoDB
Репликацията подобрява вертикалното мащабиране в MongoDB, така че работното натоварване да се разпределя между участващите членове. В производствената среда това са някои от съображенията, които трябва да се вземат предвид за оптимална клъстерна архитектура.
Брой възли
Максималният брой възли, които може да има набор от реплика, е 50 със 7 членове с право на глас. Всеки член след 7-ми се счита за без право на глас. Следователно един добър клъстер трябва да има 7 членове с право на глас, за да направи изборния процес удобен.
Разположете нечетен брой членове с право на глас и ако имате само по-малко от 7, но четен брой членове, тогава ще трябва да разположите арбитър като друг член с право на глас. Арбитрите не съхраняват копие на данните, следователно ще изискват по-малко ресурси за управление. Освен това човек може да ги подложи на среда, в която не бихте могли да подложите другите членове.
Съображения за отказоустойчивост
Понякога някои членове може да станат недостъпни в резултат на фактори като прекъсвания на захранването или преходни процеси в мрежата и прекъсвания на връзката. Броят на членовете, които остават в набора и могат да изберат първични, създават ситуация, известна като отказоустойчивост. Следователно това е разликата между общия брой членове на набора реплики и мнозинството членове с право на глас, необходими за избиране на първични избори. Липсата на първичен диктува, че операциите по запис не могат да бъдат изпълнени.
Таблицата по-долу показва примерна връзка между трите.
| Общо членове на набора реплики | Необходимо е мнозинство за избор на нов първичен избор | Толерантност на грешки |
| 3 | 2 | 1 |
| 4 | 3 | 1 |
| 5 | 3 | 2 |
| 6 | 4 | 2 |
| 7 | 5 | 2 |
Връзката не е толкова пряка, тъй като ако добавите повече членове към набора, не е предвидено, че толерантността на грешки ще се увеличи, както се вижда от таблицата. Допълнителни членове осигуряват поддръжка за специални функции, като архивиране и отчитане.
Планиране на капацитет и балансиране на натоварването за тежки четения
Трябва да имате свободен капацитет за внедряването си, като добавите нови членове, преди текущото търсене да насити капацитета на съществуващия набор.
За много висок трафик на четене, разпределете пропускателната способност за четене към вторичните членове и всеки път, когато клъстерът расте, добавете или преместете членове в алтернативни центрове за данни, за да постигнете излишък и да увеличите достъпността на данните.
Можете също да използвате целеви операции с набори от етикети, за да насочите операциите за четене към конкретни членове или да промените опасенията за запис, за да поискате потвърждение от конкретни членове.
Възлите трябва да бъдат разпределени географски
Центровите за данни също могат да се провалят поради някаква катастрофа. Поради това се препоръчва да държите поне един или двама членове в отделен център за данни за целите на защитата на данните. Ако е възможно, използвайте нечетен брой центрове за данни и изберете разпределение, което максимизира вероятността дори при загуба на център за данни, останалите членове на набора от реплики да формират мнозинство или поне да предоставят копие на данните.
Използвайте дневник за неочаквани неуспехи
По подразбиране това е активирано в MongoDB. Трябва да се уверите, че тази опция е активирана, за да предпазите загубата на данни в случай на прекъсвания на услугата, като внезапни рестартиране и прекъсване на захранването.
Модели за внедряване
Има основно два подхода за внедряване, а именно:
- Набора реплики от три члена, които осигуряват минимална препоръчителна архитектура за набор от реплики.
- Комплект реплики, разпределен в два или повече центъра за данни, за да се предпази от повреди, специфични за обекта, като прекъсване на захранването.
Моделите обаче зависят от изискванията на приложението, но ако е възможно, можете да комбинирате функциите на тези две във вашата архитектура на внедряване.
Имена на хостове и именуване на набор от реплики
Използвайте логическо DNS име на хост, а не ip адрес, когато конфигурирате членове на набора от реплики или членове на разчленен клъстер. Това е, за да избегнете болката, свързана с промените в конфигурацията, които ще трябва да направите в резултат на променените IP адреси.
В случай на именуване на набор от реплики, използвайте различни имена за наборите, тъй като някои драйвери групират връзките на набор от реплики по име на набор от реплики.
Заключение
Архитектурното оформление за набор от реплики определя капацитета и възможностите на вашето внедряване. Защитата на данните и производителността на системата са основните съображения при настройката на архитектурата. Трябва да се вземат предвид жизненоважни фактори като отказоустойчивост, брой членове на набора от реплики, оптимален ключ за разделяне и модели на внедряване за висока наличност и защита на данните. Географското разпределение на възлите на набора от реплики може да се справи с голяма част от тези фактори, като гарантира излишък и осигурява отказоустойчивост, ако един от центровете за данни отсъства.
