С механизма за съхранение MMAPv1 актуализациите на място често се подчертават като стратегия за оптимизация, тъй като индексите за документ сочат директно към местоположението на файловете и отместванията. Преместването на документ на ново място за съхранение (особено ако има много записи в индекса за актуализиране) има повече разходи за MMAPv1, отколкото актуализация на място, която трябва само да актуализира променените полета. Вижте:Характеристики за съхранение на записи в MMAPv1.
WiredTiger не поддържа актуализации на място, тъй като вътрешно използва MVCC (Multiversion concurrency control), който обикновено се използва от системите за управление на бази данни. Това е значително техническо подобрение спрямо опростения изглед в MMAP и позволява изграждането на по-усъвършенствани функции като нива на изолация и транзакции. Индексите на WiredTiger имат ниво на индиректност (препращат се към вътрешен идентификатор на запис вместо местоположението на файла и изместване), така че преместванията на документ на ниво съхранение не са значителна болезнена точка.
В тази статия обаче се казва също, че „Въпреки че [WiredTiger] не позволява актуализации на място, той все пак може да работи по-добре от MMAP за много натоварвания.
Това означава, че въпреки че MMAPv1 може да има по-ефективен път за актуализации на място, WiredTiger има други предимства като компресия и подобрен контрол на едновременност. Може би бихте могли да създадете работно натоварване, състоящо се само от актуализации на място на няколко документа, които може да се представят по-добре в MMAPv1, но действителните натоварвания обикновено са по-разнообразни. Единственият начин да се потвърди въздействието за дадено работно натоварване би било да се тества в представителна среда.
Въпреки това, общият избор на MMAPv1 срещу WiredTiger е спорен, ако искате да планирате бъдещето:WiredTiger е машината за съхранение по подразбиране от MongoDB 3.2 и някои по-нови функции на продукта не се поддържат от MMAPv1. Например, MMAPv1 не поддържа загриженост за мажоритарно четене, което от своя страна означава, че не може да се използва за конфигурационни сървъри на реплики (изисква се за споделяне в MongoDB 3.4+) или потоци за промяна (MongoDB 3.6+). MMAPv1 ще бъде остарял в следващата основна версия на MongoDB (4.0) и в момента е планирано да бъде премахнат в MongoDB 4.2.
Какви са точните последици, които трябва да знам, когато използвам WiredTiger? Например, без актуализации на място размерът на базата данни ще нарасне ли бързо?
Резултатите от съхранението зависят от няколко фактора, включително дизайна на вашата схема, работното натоварване, конфигурацията и версията на сървъра MongoDB. MMAPv1 и WiredTiger използват различни стратегии за разпределение на записи, но и двете ще се опитат да използват предварително разпределено пространство, което е маркирано като безплатно/използваемо повторно. Като цяло WiredTiger е по-ефективен с използването на пространство за съхранение и също така има предимството на компресиране на данни и индекси. MMAPv1 заделя допълнително пространство за съхранение, за да се опита да оптимизира за актуализации на място и да избегне преместване на документи, въпреки че можете да изберете стратегия „без допълване“ за колекции, при които работното натоварване не променя размера на документа с течение на времето.
Имаше значителни инвестиции в подобряване и настройка на WiredTiger за различни работни натоварвания откакто беше представен за първи път в MongoDB 3.0, така че силно бих насърчил тестването с най-новата серия от версии за производство за най-добър резултат. Ако имате конкретен въпрос относно дизайна на схемата и растежа на съхранението, бих предложил да публикувате подробности в DBA StackExchange за обсъждане.
Научих също, че WiredTiger в MongoDB 3.6 добави възможността за съхраняване на делта, вместо да пренаписва целия документ (https://jira.mongodb.org/browse/DOCS-11416). Какво точно означава това?
Това е детайл за внедряване, който подобрява вътрешните структури от данни на WiredTiger за някои случаи на употреба. По-специално, WiredTiger в MongoDB 3.6+ може да бъде по-ефективен при работа с малки промени в големи документи (в сравнение с предишни версии). Кешът на WiredTiger трябва да може да връща множество версии на документи, стига да се използват от отворени вътрешни сесии (MVCC, както беше споменато по-рано), така че за големи документи с малки актуализации може да е по-ефективно да се съхранява списък с делта. Ако обаче се натрупат твърде много делти (или делтите променят повечето полета в документ), този подход може да бъде по-малко ефективен от поддържането на множество копия на пълния документ.
Когато данните се записват на диск чрез контролна точка, все още трябва да бъде написана пълна версия на документа. Ако искате да научите повече за някои от вътрешните елементи, има поредица от видеоклипове за MongoDB Path To Transactions след разработването на функции за поддръжка на транзакции с множество документи в MongoDB 4.0.
Също така това, което не разбирам е, че в днешно време повечето (ако не всички) твърди дискове имат размер на сектора от 4096 байта, така че не можете да пишете на твърдия диск само 4 байта (например), а вместо това трябва да запишете пълния блок от 4096 байта (така че първо го прочетете, актуализирайте 4-те байта в него и след това го напишете). Тъй като повечето документи често са <4096 байта, това означава ли, че пренаписването на целия документ е необходимо във всеки случай (дори и с MMAP). Какво пропуснах?
Без да навлизате твърде далеч в подробностите за внедряването и да се опитвате да обясните всички включени движещи се части, помислете как различните подходи се прилагат към работните натоварвания, при които се актуализират много документи (а не на ниво един документ), както и въздействието върху използването на паметта (преди документите се записват на диск). В зависимост от фактори като размер на документа и компресия, един блок I/O може да представлява навсякъде от част от документ (максимален размер 16MB) до множество документи.
В MongoDB общият поток е, че документите се актуализират в изглед в паметта (например, кеша на WiredTiger) с промените, които се запазват на диска във формат на дневник само за бързо добавяне, преди периодично да бъдат прехвърляни към файловете с данни. Ако операционната система трябва да записва само блокове от данни, които са се променили, докосването на по-малко блокове данни изисква по-малко общо I/O.
