MongoDB
 sql >> база данни >  >> NoSQL >> MongoDB

Какво е новото в MongoDB 4.2

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

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

В този блог ще обсъдим какво е включено и какви подобрения са направени в MongoDB версия 4.2

Какво е новото в MongoDB 4.2

  1. Разпределени транзакции
  2. Индекси с заместващи знаци
  3. Повторно четене и записване
  4. Автоматично криптиране на ниво поле от страна на клиента.
  5. Подобрен език на заявките за изразителни актуализации
  6. Материализирани изгледи при поискване
  7. Модерни операции по поддръжка

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

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

Въпреки това, спецификациите на клиентския драйвер са се променили малко, така че ако някой възнамерява да използва транзакции в MongoDB 4.2, трябва  да надстроите драйверите до версии, които са съвместими със сървъри 4.2.

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

Преназначаването на локал на глобалния клъстер вече е възможно с версия 4.2. Това означава, че за реализация на разделяне на геозона, ако потребител, пребиваващ в регион А, се премести в регион B, чрез промяна на стойността на полето си за местоположение, данните могат автоматично да бъдат преместени от регион А към Б чрез транзакция.

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

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

Една добра практика за използване на транзакции включва:

  1. Избягвайте използването на неиндексирани заявки в транзакция, като начин да гарантирате, че операцията няма да е бавна.
  2. Вашата транзакция трябва да включва няколко документа.

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

Индекси на заместващи знаци

В MongoDB версия 4.2 бяха въведени заместващи знаци за подобряване на заявките срещу произволни полета или полета, чиито имена не са известни предварително, чрез индексиране на целия документ или поддокумент. Те не са предназначени да заменят индексите, базирани на работното натоварване но е подходящ за работа с данни, включващи полиморфен модел. Полиморфният модел е, когато всички документи в колекцията са сходни, но нямат идентична структура. Полиморфните модели на данни могат да бъдат генерирани от приложения, включващи продуктови каталози или социални данни. По-долу е даден пример за полиморфни данни за колекция

{

Sport: ‘Chess’,

playerName: ‘John Mah’,

Career_earning: {amount: NumberDecimal(“3000”), currency: “EUR”},

gamesPlayed:25,

career_titles:10

},

{

Sport: Tennis,

playerName: ‘Semenya Jones,

Career_earning: {amount: NumberDecimal(“34545”), currency: “USD”},

Event: {

name:”Olympics”,

career_titles:10,

career_tournaments:14

}

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

За да създадете индекс с заместващи символи

$db.collection.createIndex({“fieldA.$**”: 1})

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

Повторно четене и записване

Обикновено една база данни може да предизвика някои чести преходни прекъсвания на мрежата, които могат да доведат до частично или пълно неизпълнение на заявка. Тези мрежови грешки може да не са толкова сериозни, следователно дават шанс за повторен опит на тези заявки, след като бъдат свързани отново. Започвайки с MongoDB 4.2, конфигурацията за повторен опит е активирана по подразбиране. Драйверите на MongoDB могат да опитат отново неуспешно четене и запис за определени транзакции, когато срещнат незначителни мрежови грешки или по-скоро когато не могат да намерят здравословен първичен в раздробения набор от клъстер/реплика. Ако обаче не искате записите с възможност за повторен опит, можете изрично да ги деактивирате във вашите конфигурации, но не намирам убедителна причина, поради която трябва да ги деактивирате.

Тази функция е да гарантира, че при всякакви промени в инфраструктурата на MongoDB кодът на приложението не трябва да бъде засегнат. По отношение на пример, обяснен от Елиът Хоровиц, съосновател на MongoDB, за уеб страница, която извършва 20 различни операции с база данни, вместо да презарежда цялото нещо или да трябва да увие цялата уеб страница в някакъв цикъл, драйверът под завивките може просто да реши да опита отново операцията. Всеки път, когато записът не успее, той ще се опита отново автоматично и ще има договор със сървъра, който гарантира, че всяко записване се случва само веднъж.

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

Повторното записване не адресира случаи, при които периодът на отказ надвишава стойността на serverSelectionTimoutMs в конфигурациите на параметрите.

С тази версия на MongoDB човек може да актуализира стойностите на ключа на фрагмента на документа (освен ако shardkey е неизменяемото поле _id) чрез издаване на операции findAndModify/update с един документ или в транзакция, или като повторно записване .

MongoDB версия 4.2 вече може да опита отново операция за прехвърляне на един документ (т.е. upsert:true и multi:false), която може да е неуспешна поради грешка с дублиран ключ, ако операцията отговаря на следните ключови условия:

  1. Целевата колекция съдържа уникален индекс, който е допуснал грешка в дублирания ключ.
  2. Операцията за актуализиране няма да промени нито едно от полетата в предиката на заявката.
  3. Условието за съвпадение на актуализацията е или единичен предикат за равенство {field:“value”}, или логическо И на предикати за равенство {filed:“value”, field0:“value0”}
  4. Набор от полета в уникалния шаблон на ключа на индекса съответства на набора от полета в предиката на заявката за актуализиране.

Автоматично криптиране на ниво поле от страна на клиента

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

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

Забележка:тази функция е достъпна само с MongoDB Enterprise.

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

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

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

Материализирани изгледи при поискване

Рамката на конвейера за агрегиране на данни в MongoDB е страхотна функция с различни етапи на трансформиране на документ в някакво желано състояние. MongoDB версия 4.2 въвежда нов етап $merge, което за мен ще кажа, че ми спести известно време при работа с крайния изход, който трябваше да бъде съхранен в колекция. Първоначално етапът $out позволява създаване на нова колекция въз основа на агрегиране и попълва колекцията с получените резултати. Ако колекцията вече съществува, тя ще презапише колекцията с новите резултати, противно на етапа $merge, който само включва резултатите от конвейера в съществуващ изход, вместо да замества изцяло колекцията. Регенерирането на цяла колекция всеки път с етап $out консумира много CPU и IO, което може да влоши производителността на базата данни. Следователно изходното съдържание ще бъде своевременно актуализирано, което позволява на потребителите да създават материализирани изгледи при поискване

Модерни операции по поддръжка

Разработчиците вече могат да имат страхотно оперативно изживяване с MongoDB версия 4.2 с интегрирани функции, които подобряват високата наличност, управлявана от облак стратегия за архивиране,  подобряват мощността за наблюдение и системите за предупреждение. MongoDB Atlas и MongoDB Ops Manager са предоставящите платформи за тези функции. Последният е определен като най-добрият за стартиране на MongoDB в предприятието. Той също така е интегриран с оператор Kubernetes за потребители на място, които преминават към частен облак. Този интерфейс позволява директно управление на Ops Manager.

Има някои вътрешни промени, направени в MongoDB версия 4.2, които включват:

  1. Изписване на отворени курсори.
  2. Премахване на механизма за съхранение на MMAPv1.
  3. Подобрение на поправката на файла с данни на WiredTiger.
  4. Диагностичните полета вече могат да имат queryHash
  5. Автоматично разделящата се нишка за mongos възли е премахната.

Заключение

MongoDB версия 4.2 идва с някои подобрения по отношение на сигурността и производителността на базата данни. Той включва автоматично криптиране на ниво поле от страна на клиента, което гарантира, че данните са защитени от ъгъла на клиента. Повече функции като търсачка на трета страна и включването на етапа $merge в рамката за агрегиране правят известно подобрение в производителността на базата данни. Преди да пуснете тази версия в производство, моля, уверете се, че всичките ви нужди са напълно задоволени.


  1. Redis
  2.   
  3. MongoDB
  4.   
  5. Memcached
  6.   
  7. HBase
  8.   
  9. CouchDB
  1. Нормализация на MongoDB, външен ключ и присъединяване

  2. съюз за същата колекция в mongodb

  3. Как да изградите URL Shortener с Node.js и MongoDB

  4. TypeError:db.collection не е функция

  5. Смесване на PostgreSQL и MongoDB (като Django backends)