Тази статия е написана от Андрю Морган от MongoDB.
От време на време ще тичам на
Обичам да поддържам архитектурата възможно най-проста – в края на краищата всеки слой носи своя собствена сложност и разходи за управление – така че ще попитам защо кеширането е там.
Все още трябва да завърша преглед на дизайна, без да препоръчвам премахването на нивото на кеша.
Така че, за да отговорим на въпроса в заглавието на тази статия - кога трябва да използвате кеш с MongoDB? - отговорът вероятно никога не е. Тази статия се опитва да обясни защо, но ако стигнете до края и все още мислите, че приложението ви се нуждае от него, тогава бих искал да обсъдя приложението си с вас.
Защо бяха измислени кеши като Memcached & Redis и защо те процъфтяват?
Нивата на кеширане бяха въведени, защото беше твърде бавно за приложенията да четат необходимите данни директно от релационна база данни.
Значи ли това, че няма умни разработчици, работещи на Oracle, DB2, Postgres, MySQL и т.н.? Защо тези разработчици не могат да направят релационни бази данни бързо?
Проблемът е, че приложението рядко трябва да чете само един запис от нормализираната релационна база данни. Вместо това обикновено трябва да изпълнява множество съединения в много таблици, за да образува един бизнес обект. Тези съединения са скъпи (те са бавни и консумират много ресурси). По тази причина приложението не иска да поема тези разходи всеки път, когато чете един и същ бизнес обект.
Има и проблем с разпространението на данните. Повечето релационни бази данни са проектирани преди 50 години, когато едно предприятие ще изпълнява базата данни и всички приложения в единния център за данни. Бързо напред към днешния ден, когато предприятията и клиентите са разпръснати по целия свят, с всеки, който иска да работи с едни и същи данни.Не искате глобално разпределени сървъри на приложения да страдат от закъснението и разходите за непрекъснато извличане на едни и същи данни от база данни, разположена на различен континент.Искате копие от данните, разположени локално близо до всеки сървър на приложения, който се нуждае от него.
Релационните бази данни не са проектирани с оглед на това изискване за разпространение на данни. доставчиците на RDBMS са се опитали да използват различни решения, за да работят около това, но те са далеч от оптимални.
Имайте предвид, че Redis и Memcached се използват широко за обработка на сесии за уеб приложения, където постоянството не е изискване. В този случай кешът е единственото хранилище на данни (т.е. не е кеш слой между приложението и MongoDB).
И така, какво не е наред с това да имаш качулка?
Въвеждането на кеширан слой често е чудесно решение, когато вашата база данни не може да осигури производителността и латентността, от които се нуждае приложението ви.
Очевидните са лицензите за софтуер и хардуера, необходими за предоставяне на услугата за кеширане.
По-малко очевидно е допълнителното натоварване на разработчиците.Това е нов език за заявки (и евентуално език за програмиране), който трябва да се овладее.Какво се случва, когато данните в RDBMS се променят?Как тези промени се разпространяват до вашия кеш?
Така че, нивото на кеша трябва да плати пътя си, като осигури осезаеми ползи от това, че приложението ви има достъп до базата данни директно.
Какво е различно от MongoDB?
Модел на документа MongoDB
В MongoDB искаме да съхранявате вашите данни структурирани по такъв начин, че да е ефективно бързо да отговаряте на най-честите заявки на вашето приложение (или тези с най-твърдите SLA). MongoDB отразява структурата на обектите, като позволява на един запис (документ) да съдържа вградени (нестни) обекти.
В много случаи бизнес обектът, изискван от приложението, ще се пренасочи към един MongoDB документ.В други случаи може да се изискват няколко документа, които могат да бъдат изтеглени с едно индексирано търсене.
MongoDB има свой собствен вътрешен LRU (най-последно използван) кеш, така че ако вашият документ е бил достъпен наскоро, шансовете са, че той вече е в паметта.
Имайте предвид, че MongoDB поддържа
Друга добавена стойност от кеширащия слой е местоположението на данните в разпределени архитектури.
Какво мисли AI?
Отговорите, създадени от генериращия ИИ, се ръководят от информацията, която е публикувана от реални хора, и така тя трябва да представлява популярното мнение по дадена тема.
Аз зададох на ChatGPT 4o този въпрос:
"Обяснете защо бих използвал кеш слой (като Redis), вместо да искам приложението ми да чете данни директно от MongoDB."
Redis работи изцяло в паметта, което го прави значително по-бърз от MongoDB, който разчита на I/O на диск за извличане на данни.
"Обяснете защо бих използвал кеш слой (като Redis), вместо да искам приложението ми да чете данни директно от MongoDB."
Redis работи изцяло в паметта, което го прави значително по-бърз от MongoDB, който разчита на I/O на диск за извличане на данни.
Както е описано по-горе, MongoDB има свой собствен кеш в паметта, така че документите, до които често имате достъп, ще бъдат в паметта и не се изисква достъп до диск.
Честото достъп до MongoDB директно за същите данни увеличава натоварването на заявките, което може да забави базата данни, особено при тежък трафик за четене.
Честото достъп до MongoDB директно за същите данни увеличава натоварването на заявките, което може да забави базата данни, особено при тежък трафик за четене.
MongoDB е мащабируем. Допълнителни вторични възли могат да бъдат добавени към набора от реплики, за да се добави допълнителна честотна лента за заявки.
Приложения с високо съотношение на четене и писане (напр. уеб приложения, API) се възползват от способността на Redis бързо да обслужва кеширани данни.
Приложения с високо съотношение на четене и писане (напр. уеб приложения, API) се възползват от способността на Redis бързо да обслужва кеширани данни.
Кешът на базата данни на MongoDB осигурява същите предимства без допълнителните усилия на разработчиците за синхронизиране на промените в данните.
Redis е идеален за кеширане на често достъпни или горещи данни (напр. потребителски сесии, конфигурации или подробности за продукта).
Redis е идеален за кеширане на често достъпни или горещи данни (напр. потребителски сесии, конфигурации или подробности за продукта).
Често достъпните горещи данни ще се съхраняват в кеша на базата данни в паметта на MongoDB.
Чрез възпроизвеждане на кеша на Redis по-близо до крайните потребители, можете да избегнете висока мрежова латентност при заявка на MongoDB от отдалечени места.
Чрез възпроизвеждане на кеша на Redis по-близо до крайните потребители, можете да избегнете висока мрежова латентност при заявка на MongoDB от отдалечени места.
Местоположението на данните може да бъде решено чрез поставяне на реплики близо до сайтовете на сървъра на приложението.
Redis има вградена функция Time-to-Live (TTL), която автоматично премахва кешираните данни след определена продължителност.
Redis има вградена функция Time-to-Live (TTL), която автоматично премахва кешираните данни след определена продължителност.
MongoDB използва LRU кеш, така че всички документи, които вече не се търсят, ще бъдат премахнати от паметта, ако пространството е необходимо за по-скоро поисканите данни.
Четенето от MongoDB многократно може да бъде ресурсно интензивно, особено при сложни заявки, което води до увеличаване на инфраструктурните разходи.
Четенето от MongoDB многократно може да бъде ресурсно интензивно, особено при сложни заявки, което води до увеличаване на инфраструктурните разходи.
Вашата MongoDB схема трябва да бъде проектирана така, че вашите важни заявки да не изискват сложни заявки.
Redis поддържа усъвършенствани структури на данни като списъци, набори, сортирани набори, хеш и потоци, които MongoDB не предоставя на практика.
Redis поддържа усъвършенствани структури на данни като списъци, набори, сортирани набори, хеш и потоци, които MongoDB не предоставя на практика.
MongoDB поддържа списъци и набори. Хашите могат да бъдат представени в MongoDB като масив от документи, съдържащи двойки с ключови стойности (парите с ключови стойности).
"Резистентност и толерантност на грешките.Кеш слой може да служи като обратна връзка, ако MongoDB е временно недостъпна или под тежко натоварване."
"Резистентност и толерантност на грешките.Кеш слой може да служи като обратна връзка, ако MongoDB е временно недостъпна или под тежко натоварване."
MongoDB може да скалира вертикално или хоризонтално, за да отговори на всички изисквания за натоварване.
MongoDB може да отнеме време за изчисляване на сложни заявки (например агрегации, съединения) за често искани резултати.
MongoDB може да отнеме време за изчисляване на сложни заявки (например агрегации, съединения) за често искани резултати.
Вашата MongoDB схема трябва да бъде проектирана така, че да избягва необходимостта от често изпълнение на сложни заявки.
Забележете, че отговорът, който получавате от ChatGPT, е силно изкривен от въпроса, който задавате.Ако променя моята покана на "Обясни защо не трябва да използвам кеш слой (като Redis) вместо да имам приложението ми да чете данни от MongoDB директно", ChatGPT е щастлив да ме възпира от добавянето на кеш слой, като цитира въпроси като повишена сложност на системата, проблеми с последователността на данните, производителност за тежки натоварвания, разходи, гъвкавост на заявките, поддръжка и надеждност, малки набори от данни (където активният набор от данни се вписва в кеша на MongoDB) и отчитане в реално време.
Резюме
Кеш слой може да добави много стойност, когато вашият RDBMS не може да осигури изпълнението на заявките, изисквани от приложението ви. Когато използвате MongoDB, базата данни на записите и функциите на кеша се комбинират в един слой, спестявайки пари и време на разработчиците.
Разпределеният кеш може да намали недостатъците в RDBMS, но MongoDB има вградено разпространение.
Отговорете на тази статия, ако все още вярвате, че вашето приложение ще се възползва от кеш слой между вашето приложение и MongoDB.
Научете повече за MongoDB дизайн отзиви
Тази статия обяснява как проектирането на MongoDB схема, която съответства на начина, по който приложението ви работи с данните, може да отговори на вашите изисквания за производителност, без да се нуждаете от кеш слой.
Ще се възползвате ли от прегледа на Вашата заявка?
