Съвременните бази данни трябва да имат капацитет да улавят и реагират на данни, докато те протичат в реално време. Това обяснява защо MongoDB има функция, наречена MongoDB Change Streams, отговорна за улавяне и реагиране на данни в реално време. Change Streams е функция, въведена за поточно предаване на информация от приложението към базата данни в реално време. Той се основава на рамка за агрегиране, която следи колекциите и позволява настъпване на промени в базата данни и колекцията от бази данни. Освен това MongoDB Change Stream може да улавя данни от IOT сензори и да актуализира отчети като промени в оперативните данни в предприятието. Този блог ще отвори дискурс за MongoDB Change Stream и ще промени препоръките в производството.
Промяна на потоци на MongoDB и премахване на колекция
Преименуването или премахването на база данни или колекция ще доведе до затваряне на курсора, ако е имало отворен поток от промени, работещ срещу изпуснатата колекция. Преименуването или пускането на колекция прави курсора с FullDocument:updateLookup да връща null във всеки даден документ за търсене. Възниква грешка, ако човек се опита да възобнови след отпадане на база данни с текущ поток от промени.
Освен това всички промени в данните, направени преди преименуването на колекция с протичащ поток от промени, се губят. Ограничението за документи за поток за промяна все още е 16MB BSON; следователно документи по-големи от 16MB не се приемат. Ако някой се опита да работи с документ, по-голям от 16 MB, известието е неуспешно и документът се заменя с друг документ, който отговаря на зададеното ограничение.
Когато колекция или база данни с отворени потоци от промени срещу нея бъде изпусната или преименувана, курсорите на потока от промени са склонни да се затварят, докато напредват до тази точка в oplog. Ако промените курсорите на потока с пълния документ, опцията updateLookup може да върне null в документа за търсене.
Следователно, опитът за възобновяване на потоците от промени срещу колекция, която е изпусната, ще доведе до грешка. Всяка поява на промени в данните в колекцията между последното събитие от заснетия поток от промени и събитието за отпадане на колекцията се губи.
Промяната на документите с отговор на потока трябва да отговаря на ограничението от 16 MB BSON за документи. В зависимост от размера на документите в колекцията, срещу която отваряте потока от промени, известията може да не успеят, ако полученият документ за уведомяване е повече от 16 MB. Добър пример са операциите за актуализиране на потоците от промени, настроени за връщане на напълно актуализиран документ или замяна/вмъкване на процеси с документа на границата или малко под ограничението.
MongoDB Промяна на потока и наборите реплики
Наборът реплики на MongoDB е колекция от процеси в MongoDB, чийто набор от данни не се променя; тоест наборът от данни остава същият. В случай на набори от реплики, които имат арбитрни членове, потоците от промени вероятно ще останат неактивни, ако не са налични достатъчно членове, носещи данните, така че мнозинството да не може да извърши операциите. Например, можем да разгледаме набор от реплика, който има три члена с два възела, носещи данни, заедно с арбитър. В случай, че вторичният елемент не работи, например в резултат на повреда, надстройка или поддръжка, ще бъде невъзможно операциите по запис да бъдат мажоритарно ангажирани. Потокът за промени ще остане отворен, но няма да изпраща известия. В настоящия сценарий приложението може да настигне всички операции, извършени в периода на прекъсване, стига последната получена от приложението операция все още е в oplog на този конкретен набор от реплики. Освен това командата rs.printReplicationInfo() се използва за извличане на данни от oplog; извлечените данни включват набор от операции и размер на oplog.
Ако времето на престой е значително изчислено, например за извършване на надстройка или в случай на бедствие, увеличаването на размера на oplog ще бъде най-добрият вариант за запазване на операциите за период, който е по-дълъг от приблизителното време на престой. За да извлечете информация за състоянието на oplog, използваната команда е printReplicationInfo(). Командата ще извлече не само информацията за състоянието на oplog, но също и размера на oplog и диапазона от време на операциите.
Наличност на потоци за промяна на MongoDB
Могат да се получат потоци за промени в MongoDB за набори от реплики и разчленени клъстери:Разрешаване на „мнозинство“ на загриженост, система за съхранение и версия на протокола за набор от реплики. Разрешаване на „мнозинство“ за четене:Започвайки с MongoDB версия 4.2 и по-нова, потоците от промени са достъпни въпреки преобладаващите обстоятелства на поддръжката на „мнозинството“ за четене, което означава, че поддръжката на мнозинството за четене може да бъде активирана или деактивирана. В MongoDB версия 4.0 и по-стари версии, потоците за промяна са достъпни само ако е активирана поддръжката за „мнозинство“ за четене.
- Storage Engine:Машината за съхранение на WiredTiger е типът на механизма за съхранение, използван от наборите реплики и разчленените клъстери.
- Версия на протокола за набор от реплики:Наборите от реплики и разчленените клъстери трябва винаги да използват версия 1 на протокола за набор от реплики (pv1).
Разчленени клъстери на MongoDB
Разделените клъстери в MongoDB се състоят от фрагменти, монго и конфигурационни сървъри. Шардът се състои от подмножество от разчленени данни. В случая на MongoDB 3.6, фрагментите се използват като набор от реплика. Mongos осигурява интерфейс между разчленени клъстери и клиентски приложения; mongos играе ролята на рутер за заявки. От MongoDB версия 4.4 и по-нова, mongos поддържа хеджирано четене за намаляване на латентностите. Конфигурационните сървъри са местата за съхранение на настройките за конфигурация на клъстера и метаданните.
Потоците за промени използват глобален логически часовник, за да осигурят глобално подреждане на промените в сегментите. MongoDB гарантира, че редът на промените се поддържа и че известията на потока от промени могат да бъдат интерпретирани безопасно в реда, в който са получени. Например, курсорът на потока от промени, отворен срещу клъстер с 3 фрагмента, връща известията за промяната относно общия ред на промените в трите сегмента.
За да гарантира общия ред на промените, Mongos проверява с всеки шард, за да види дали е видял по-скорошни промени за всяко известие за промяна. Раздробените клъстери с един до няколко фрагмента с малка или никаква събирателна активност или са „студени“ вероятно ще имат отрицателен ефект върху времето за реакция на потока от промени, тъй като монго все още трябва да проверяват с тези студени фрагменти, за да осигурят цялостното подреждане на промените. Този ефект може да е по-очевиден, когато фрагментите са географски разпределени или когато работните натоварвания с повечето операции възникват върху подмножество от фрагменти в клъстер. Ако разчленената колекция има високо ниво на активност, монгото може да не успее да проследи промените във всички фрагменти. Помислете за използването на филтри за уведомяване за този вид колекция, например, преминаване на $match конвейера, който е конфигуриран да филтрира само операциите за вмъкване.
В случай на разчленени колекции, много:правилните операции за актуализиране вероятно ще причинят потоци от промени, които се отварят срещу колекцията, за да изпращат известия за осиротели документи. Започвайки от момента, в който се разделя неразчленена колекция до момента, в който потокът от промени стигне до първата част за мигриране, documentKey в документа за уведомяване на потока за промени включва само идентификатора на документа, а не пълния ключ на фрагмента.
Заключение
Целта на потоците от промени е да направят възможни промените в данните на приложението в реално време, без риск от преследване на oplog и без следа от сложност. Приложенията на MongoDB използват потоци от промени, за да подпишат промените в данните в база данни, колекция или внедряване и незабавно реагират на тях. Тъй като потоците от промени използват рамката за агрегиране, приложенията могат сами да филтрират конкретните промени и да конвертират известия.
