След разработването на вашето приложение и модел на база данни (когато дойде време за преместване на средата в производство) има няколко неща, които трябва да се направят първо. Често разработчиците не успяват да вземат предвид допълнителни важни стъпки на MongoDB, преди да разположат базата данни в производство. Следователно именно в производствения режим те се сблъскват с основни неуспехи, които не са представени в режима на разработка. Понякога може да е твърде късно или по-скоро много данни биха били загубени, ако настъпи бедствие. Освен това някои от обсъжданите тук стъпки ще позволят да се прецени здравето на базата данни и следователно да се планират необходимите мерки преди бедствие.
Използвайте текущата версия и най-новите драйвери
По принцип най-новите версии на всяка технология идват с подобрени функции по отношение на основната функционалност в сравнение с техните предшественици. Последните версии на MongoDB са по-стабилни и подобрени от своите предшественици по отношение на производителност, мащабируемост и капацитет на паметта. Същото важи и за свързаните драйвери, тъй като те са разработени от основните инженери на базата данни и се актуализират по-често дори от самата база данни.
Инсталираните собствени разширения за вашия език могат лесно да поставят платформа за бързи и стандартни процедури за тестване, одобрение и надграждане на новите драйвери. Има и автомобилен софтуер като Ansible, Puppet, SaltStack и Chef, който може да се използва за лесно надграждане на MongoDB във всички ваши възли, без да правите професионални разходи и време.
Също така помислете за използването на механизма за съхранение на WiredTiger, тъй като той е най-развитият с модерни функции, които отговарят на очакванията на съвременните бази данни
Абонирайте се за пощенски списък на MongoDB, за да получавате най-новата информация по отношение на промените в новите версии и драйвери и корекции на грешки, следователно да поддържате актуална информация.
Използвайте 64-битова система за стартиране на MongoDB
В 32-битови системи процесите на MongoDB са ограничени до около 2,5 GB данни, тъй като базата данни използва картографирани в паметта файлове за производителност. Това се превръща в ограничение за процеси, които може да надхвърлят границата, водеща до смазване. Основното въздействие ще бъде:в случай на грешка, няма да можете да рестартирате сървъра до момента, в който премахнете данните си или мигрирате базата си данни към по-висока система като 64-битовата, следователно и по-голямо време на престой за вашето приложение.
Ако трябва да продължите да използвате 32-битова система, кодирането ви трябва да е много просто, за да намалите броя на грешките и забавянето на операциите с пропускателна способност.
Въпреки това за сложни кодове, като конвейер за агрегация и геоданни, е препоръчително да използвате 64-битовата система.
Уверете се, че документите са ограничени до 16MB размер
Документите на MongoDB са ограничени до 16MB размер, но не е необходимо да се доближавате до това ограничение, тъй като това ще доведе до известно влошаване на производителността. На практика документите са предимно KB или по-малко по размер. Размерът на документа зависи от стратегията за моделиране на данни между вграждането и препратката. Вграждането е за предпочитане, когато размерът на документа не се очаква да нарасне много. Например, ако имате приложение за социални медии, в което потребителите публикуват и то има коментари, най-добрата практика ще бъде да имате две колекции, едната да съхранява информация за публикации.
{
_id:1,
post: 'What is in your mind?',
datePosted: '12-06-2019',
postedBy:'xyz',
likes: 10,
comments: 30
}а другата да съхранява коментари за тази публикация.
{
_id: ObjectId('2434k23k4'),
postId: 1,
dateCommented: '12-06-2019',
commentedBy:'ABCD',
comment: 'When will we get better again',
}При наличието на такива модели на данни, коментарите ще се съхраняват в колекция, различна от публикацията. Това предотвратява израстването на документа в колекцията от публикации, в случай че има толкова много коментари. Уверете се, че избягвате модели на приложения, които биха позволили на документите да растат неограничено.
Уверете се, че работният комплект пасва в паметта
Базата данни може да не успее да прочете данни от виртуална памет (RAM), което води до грешки в страницата. Грешките в страницата ще принудят базата данни да чете данни от физически диск, което води до увеличена латентност и следователно изоставане в цялостната производителност на приложението. Грешки в страницата възникват поради работа с голям набор, който не се побира в паметта. Това може да е в резултат на някои документи с неограничен размер или лоша стратегия за разделяне. Средствата за отстраняване на грешки в страницата ще бъдат:
- Уверете се, че документите са обвързани с размера от 16 МБ.
- Осигуряване на добра стратегия за разделяне чрез избор на оптимален ключ за разделяне, който ще ограничи броя на документите, на които ще бъде подложена операцията за пропускателна способност.
- Увеличете размера на екземпляра на MongoDB, за да побере повече работни набори.
Уверете се, че имате набори реплики на място
В света на базата данни не е идеално да разчитате на една база данни поради факта, че може да се случи катастрофа. Освен това бихте очаквали увеличаване на броя на потребителите на базата данни, следователно трябва да се гарантира висока наличност на данни. Репликацията е решаващ подход за осигуряване на висока наличност в случай на отказ. MongoDB има способността да обслужва данни географски:което означава, че потребителите от различни местоположения ще бъдат обслужвани от най-близкия облачен хост като един от начините за намаляване на забавянето на заявките.
В случай, че първичният възел не успее, вторичните възли могат да изберат нов, който да поддържа операциите по запис, вместо приложението да има престой по време на отказ. Всъщност някои облачни хостинг платформи, които са доста внимателни към репликацията, не поддържат нереплициран MongoDB за производствени среди.
Активиране на водене на журнал
Доколкото воденето на журнали предполага известно влошаване на производителността, то също е важно. Журналирането подобрява операциите за предсрочно записване, което означава, че в случай, че базата данни се провали в процеса на извършване на актуализация, актуализацията би била запазена някъде и когато оживее отново, процесът може да бъде завършен. Журналирането може лесно да улесни възстановяването при срив, следователно трябва да е включено по подразбиране.
Уверете се, че сте настроили стратегия за архивиране
Много фирми не успяват да продължат след загуба на данни поради липса или лоша система за архивиране. Преди да разположите вашата база данни в производството, уверете се, че сте използвали някоя от тези стратегии за архивиране:
- Mongodump :оптимално за малки разгръщания и при създаване на резервни копия, филтрирани според специфични нужди.
- Основно копиране :оптимален за големи разгръщания и ефективен подход за вземане на пълни архиви и възстановяването им.
- Услуга за управление на MongoDB (MMS) :осигурява непрекъснато онлайн архивиране за MongoDB като напълно управлявана услуга. Оптимално за разчленен клъстер и набори от реплики.
Архивните файлове също не трябва да се съхраняват в същия хост доставчик на базата данни. Backup Ninja е услуга, която може да се използва за това.
Бъдете подготвени за бавни заявки
Едва ли човек може да реализира бавни заявки в средата за разработка поради факта, че са включени малко данни. Това обаче може да не е така в производството, като се има предвид, че ще имате много потребители или ще бъдат включени много данни. Може да възникнат бавни заявки, ако не сте успели да използвате индекси или сте използвали ключ за индексиране, който не е оптимален. Въпреки това трябва да намерим начин, който да ви покаже причината за бавните заявки.
Затова решаваме да активираме MongoDB Query Profiler. Доколкото това може да доведе до влошаване на производителността, профайлърът ще помогне за разкриването на проблеми с производителността. Преди да внедрите вашата база данни, трябва да активирате инструмента за профилиране за колекциите, за които подозирате, че може да имат бавни заявки, особено тези, които включват документи с много вграждане.
Свържете се с инструмент за наблюдение
Планирането на капацитета е много важно начинание в MongoDB. Вие също ще трябва да знаете здравето на вашия db във всеки един момент. За удобство, свързването на вашата база данни с инструмент за наблюдение ще ви спести известно време, за да разберете какво трябва да подобрите с времето. Например, графично представяне, което показва бавната производителност на процесора в резултат на увеличените заявки, ще ви насочи да добавите повече хардуерни ресурси към вашата система.
Инструментите за наблюдение също имат система за предупреждение чрез изпращане по пощата или кратки съобщения, които удобно ви информират за някои проблеми, преди те да станат катастрофални. Затова в производството се уверете, че вашата база данни е свързана с инструмент за наблюдение.
ClusterControl предоставя безплатен мониторинг на MongoDB в изданието на Общността.
Прилагане на мерки за сигурност
Сигурността на базата данни е друга важна характеристика, която трябва стриктно да се вземе предвид. Трябва да защитите инсталацията на MongoDB в производството, като се уверите, че се спазват някои предпроизводствени контролни списъци за сигурност. Някои от съображенията са:
- Конфигуриране на контрол на достъп, базиран на роли
- Активиране на контрол на достъпа и налагане на удостоверяване
- Криптиране на входящи и изходящи връзки (TLS/SSL)
- Ограничаване на излагането на мрежата
- Криптиране и защита на данни
- Имате план за проследяване на достъпа и промените в конфигурациите на базата данни
Избягвайте външни инжекции, като стартирате MongoDB със защитени опции за конфигурация. Например деактивиране на скриптовете от страна на сървъра, ако не се използват операции от страна на сървъра на JavaScript, като mapReduce и $where. Използвайте валидатора на JSON за вашите данни за събиране чрез някои модули като mongoose, за да сте сигурни, че всички съхранени документи са във валидния формат BSON.
Съображения за хардуер и софтуер
MongoDB има малко хардуерни предпоставки, тъй като е изрично проектиран с голямо внимание на необходимия стандартен хардуер. Следват основните хардуерни обсъждания за MongoDB, които трябва да вземете предвид преди внедряването в производството.
- Задайте адекватни RAM и CPU
- Използвайте механизма за съхранение на WiredTiger. Проектиран да използва кеш на файловата система и вътрешен кеш на WiredTiger, следователно повишена производителност. Например, когато работите със система от 4 GB RAM, кешът на WiredTiger използва 1,5 GB RAM ( 0,5 * (4 GB -1 GB) =1,5 GB), докато система с 1,2 GB RAM WiredTiger кеш използва само 256 MB.
- NUMA хардуер. Съществуват множество оперативни проблеми, които включват бавна производителност и високо използване на системните процеси, следователно трябва да помислите за конфигуриране на политика за преплитане на паметта.
- Диск и система за съхранение:Използвайте твърд диск (SSD):MongoDB показва по-добро съотношение цена-производителност със SATA SSD
Заключение
Базите данни в производството са много важни за осигуряване на гладко функциониране на бизнеса, следователно трябва да се третират с много съображения. Трябва да се установят някои процедури, които могат да помогнат за намаляване на грешките или по-скоро да осигурят лесен начин за намиране на тези грешки. Освен това е препоръчително да настроите система за предупреждение, която ще показва състоянието на базата данни с време за планиране на капацитета и откриване на проблеми, преди те да се смекчат в катастрофа.
