Най-добри практики за стартиране на MongoDB в клъстер

Разгръщането на клъстерирана база данни е едно нещо, но как поддържате своя DBM, докато сте в клъстер, може да бъде голямо начинание за последователно обслужване на вашите приложения. Човек трябва често да актуализира състоянието на базата данни, по-специално най-важните показатели, за да получи представа какво да надстрои или по-скоро промени, като начин за предотвратяване на всякакви пречки, които могат да се появят.

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

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

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

1. Надстройване до най-новата версия
2. Подходящ механизъм за съхранение
3. Разпределение на хардуерните ресурси
4. Репликация и разделяне
5. Никога не променяйте конфигурационния файл на сървъра
6. Добра стратегия за сигурност

Надстройване до най-новата версия

Работил съм с MongoDB от версии преди 3.2 и, честно казано, нещата не бяха лесни по това време. С страхотни разработки, отстранени грешки и нововъведени функции, ще ви посъветвам винаги да надграждате базата си данни до най-новата версия. Например, въвеждането на рамката за агрегиране имаше по-добро въздействие върху производителността, отколкото да разчита на концепцията за намаляване на картата, която вече съществуваше. С най-новата версия 4.0 вече има възможност да се използва функцията за транзакции с множество документи, която обикновено подобрява операциите с пропускателна способност. Последната версия също има някои допълнителни нови оператори за преобразуване на тип, като $toInt, $toString, $trim и $toBool. Тези оператори ще помогнат значително при валидирането на данните, като по този начин ще създадат известно усещане за последователност на данните. Когато надграждате, моля, направете справка с документите, за да избегнете леки грешки, които може да се превърнат в грешни.

Изберете подходящ механизъм за съхранение

MongoDB поддържа 3 механизма за съхранение в момента, които са:WiredTiger, In-Memory и MMAPv1 машини за съхранение. Всеки от тези двигатели за съхранение има предимства и ограничения пред другия, но вашият избор ще зависи от спецификацията на вашето приложение и основната функционалност на двигателя. Въпреки това, аз лично предпочитам механизма за съхранение на WiredTiger и бих го препоръчал за този, който не е сигурен кой да използва. Машината за съхранение на WiredTiger е много подходяща за повечето работни натоварвания, осигурява модел на паралелност на ниво документ, контролни точки и компресия.

Някои от съображенията относно избора на машина за съхранение зависят от тези аспекти:

1. Транзакции и атомарност: предоставяне на данни по време на вмъкване или актуализиране, което се извършва само когато всички условия и етапи в приложението са изпълнени успешно. Следователно операциите са групирани в неизменна единица. При това може да се поддържа многодокументна транзакция, както се вижда в последната версия на MongoDB за механизма за съхранение на WiredTiger.
2. Тип на заключване: това е стратегия за контрол на достъпа или актуализирането на информация. По време на продължителността на заключването никоя друга операция не може да промени данните на избрания обект, докато не бъде изпълнена текущата операция. Следователно заявките се засягат в този момент, следователно е важно да ги наблюдавате и да намалите по-голямата част от заключващия механизъм, като гарантирате, че изберете най-подходящия механизъм за съхранение на вашите данни.
3. Индексиране: Механизмите за съхранение в MongoDB предоставят различни стратегии за индексиране в зависимост от типовете данни, които съхранявате. Ефективността на тази структура от данни трябва да бъде доста съвместима с вашето работно натоварване и човек може да определи това, като се има предвид, че всеки допълнителен индекс има някои допълнителни разходи за производителност. Оптимизираните за запис структури от данни имат по-ниски разходи за всеки индекс в среда на приложения с много вмъкване, отколкото структурите от данни, които не са оптимизирани за запис. Това ще бъде сериозна пречка, особено когато са включени голям брой индекси и избор на неподходящ двигател за съхранение. Следователно изборът на подходящ механизъм за съхранение може да има драматично въздействие.

Разпределение на хардуерни ресурси

Тъй като нови потребители влизат във вашето приложение, базата данни нараства с времето и ще бъдат въведени нови фрагменти. Не можете обаче да разчитате на хардуерните ресурси, които сте установили по време на етапа на внедряване. Ще има съответно увеличение на работното натоварване и следователно ще изисква повече ресурси за обработка, като CPU и RAM, за да поддържат вашите големи клъстери от данни. Това често се нарича планиране на капацитет в MongoDB. Най-добрите практики за планиране на капацитет включват:

• Наблюдавайте непрекъснато своята база данни и се коригирайте в съответствие с очакванията. Както бе споменато по-горе, увеличаването на броя на потребителите ще задейства повече заявки оттук нататък с увеличен набор от работно натоварване, особено ако използвате индекси. Може да започнете да изпитвате това въздействие върху края на приложението, когато започне да записва промяна в процента на записвания спрямо четения с времето. Следователно ще трябва да конфигурирате отново хардуерните си конфигурации, за да разрешите този проблем. Използвайте инструмента mongoperf и MMS, за да откриете промени в параметрите на производителността на системата.
• Документирайте предварително всичките си изисквания за ефективност. Когато срещнете същия проблем, поне ще имате ориентир, което ще ви спести известно време. Вашият запис трябва да включва размера на данните, които искате да съхранявате, анализ на заявките по отношение на латентността и колко данни искате да получите достъп в даден момент. В производствената среда трябва да определите колко заявки ще обработвате в секунда и накрая колко латентност ще толерирате.
• Поставете доказателство за концепция. Изпълнете дизайн на схема/индекс и разберете моделите на заявки и след това прецизирайте оценката си за размера на работния набор. Запишете тази конфигурация като отправна точка за тестване с последователни ревизии на приложението.
• Правете тестовете си с реално натоварване. След извършване на етапа на доказателствена концепция, внедряване само след извършване на съществено тестване с реални данни и изисквания за производителност.

Репликация и разделяне

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

Разделянето основно разделя данните между сървърите на малки части, известни като фрагменти. Балансирането на данните между фрагментите е автоматично, фрагментите могат да се добавят или премахват, без непременно да се извежда базата данни офлайн.

Репликацията от другия край поддържа множество излишни копия на данните за висока наличност. Това е вградена функция в MongoDB и работи в широки мрежи без нужда от специализирани мрежи. За настройка на клъстер препоръчвам да имате поне 2+ mongo, 3 конфигурационни сървъра, 1 шард и да гарантирате свързаност между машини, участващи в раздробения клъстер. Използвайте DNS име, а не IP адреси в конфигурацията.

За производствени среди използвайте набор от реплики с поне 3 члена и не забравяйте да попълните повече конфигурационни променливи, като размер на oplog.

Когато стартирате вашите mongod екземпляри за вашите членове използвайте същия ключов файл.

Някои от съображенията за вашия shardkey трябва да включват:

• Ключът и стойността са неизменни
• Винаги обмисляйте използването на индекси в разчленена колекция
• Командата за актуализиране на драйвера трябва да съдържа ключ за сегментиране
• Уникални ограничения, които трябва да се поддържат от ключа на сегмента.
• Ключът на сегмента не може да съдържа специални типове индекси и не трябва да надвишава 512 байта.

Никога не променяйте конфигурационния файл на сървъра

След като направите първото си внедряване, препоръчително е да не променяте много параметри в конфигурационния файл, в противен случай може да се сблъскате с проблеми, особено с парчета. Най-слабата връзка с разделянето са конфигурационните сървъри. Това означава, че всички екземпляри на mongod трябва да се изпълняват, за да работи разделянето.

Добра стратегия за сигурност

MongoDB беше уязвим към външни атаки през последните години, следователно важно начинание за вашата база данни да има някои протоколи за сигурност. Освен стартиране на процесите в различни портове, човек трябва да използва поне един от 5-те различни начина за защита на бази данни на MongoDB. Можете да помислите за платформи като MongoDB Atlas, които защитават бази данни по подразбиране чрез криптиране на данните както по време, така и в състояние на покой. Можете да използвате стратегии като TLS/SSL за всички входящи и изходящи връзки.

Заключение

Контролът на клъстера на MongoDB не е лесна задача и включва много заобиколни решения. Базите данни растат в резултат на повече потребители, следователно и увеличен набор от работно натоварване. Следователно On има мандат да гарантира, че ефективността на DBM е в съответствие с този увеличен брой потребители. Най-добрите практики надхвърлят увеличаването на хардуерните ресурси и прилагането на някои концепции на MongoDB като разделяне, репликация и индексиране. Въпреки това, много от неудобствата, които могат да възникнат, се решават добре чрез надграждане на вашата MongoDB версия. По-често най-новите версии имат коригирани грешки, интегрирани заявки за нови функции и почти няма отрицателно въздействие върху надстройката дори при големи номера на ревизии.