Оваа статија е напишана од Андреј Морган од MongoDB.
Од време на време, јас ќе се кандидира за
Сакам да ја задржам архитектурата што е можно поедноставна - на крајот на краиштата, секој слој носи своја сложеност и трошоци за управување - па ќе прашам зошто слојот за кеширање е таму.
Јас сè уште нема да завршам преглед на дизајнот без да препорачам да се отстрани нивото на кеш.
Значи, да се одговори на прашањето во насловот на овој напис - кога треба да го користите кеш со MongoDB? - одговорот е веројатно никогаш.
Зошто биле измислени кеши како Memcached & Redis, и зошто тие процветаат?
Нивоата на кеширање беа воведени затоа што беше премногу бавно за апликациите да ги прочитаат потребните податоци директно од релациона база на податоци.
Дали тоа значи дека нема паметни програмери кои работат на Oracle, DB2, Postgres, MySQL, итн. Зошто тие програмери не можеа да направат релациона бази на податоци брзо?
Проблемот е во тоа што апликацијата ретко треба да прочита само еден запис од нормализираната релациона база на податоци. Наместо тоа, обично треба да изврши повеќе спојувања низ многу табели за да формира еден бизнис објект. Овие спојувања се скапи (те се бавни и трошат многу ресурси). Поради оваа причина, апликацијата не сака да понесе такви трошоци секој пат кога ќе го прочита истиот бизнис објект. Тоа е местото каде што нивото на кеширање додава вредност – спојување на нормализираните, релационални податоци еднаш, а потоа кеширање на резултатите, така што апликацијата ефикасно може да ги добие истите резултати многу пати.
Постои и прашањето за дистрибуцијата на податоците. Повеќето релационални бази на податоци беа дизајнирани пред 50 години, кога претпријатието ќе ја извршува базата на податоци и сите апликации во еден центар за податоци. Брзо напред до денес, кога претпријатијата и клиентите се шират низ целиот свет, со сите кои сакаат да работат со истите податоци. Не сакате глобално дистрибуирани сервери на апликации да страдаат од латенцијата и трошоците за континуирано собирање на истите податоци од базата на податоци лоцирана на друг континент.
Релациските бази на податоци не беа дизајнирани со ова барање за дистрибуција на податоци во предвид. RDBMS продавачите се обидоа да се борат со различни решенија за да работат околу ова, но тие се далеку од оптимални.
Имајте на ум дека Redis и Memcached се широко користат за обработка на сесијата за веб апликации каде што упорноста не е барање. Во тој случај, кешот е единственото складиште на податоци (т.е. не е кашиот слој помеѓу апликацијата и MongoDB). Додека можете (и луѓето го прават) да го користите MongoDB за управување со сесијата, тоа е надвор од опсегот на овој напис.
Значи, што не е во ред со имајќи кеширање ниво?
Воведувањето на слој за кеширање често е одлично решение кога вашата база на податоци не може да ги испорача перформансите и латентноста што ви треба вашата апликација.
Сепак, овој дополнителен ниво на податоци доаѓа со трошоци.Очигледни се софтверските лиценци и хардверот потребни за да се обезбеди услугата за кеширање.
Помалку очигледно е дополнителното оптоварување на програмерите. Тоа е нов јазик за прашање (и можеби програмски јазик) да се совлада. Што се случува кога податоците во RDBMS се менуваат?
Значи, нивото на кеш мора да го плати својот пат со обезбедување на опипливи бенефиции во однос на тоа што вашата апликација има пристап до базата на податоци директно.
Што е различно од MongoDB?
MongoDB модел на документ
Во MongoDB, сакаме да ги зачувате вашите податоци структурирани на начин што го прави ефикасен за брзо задоволување на најчестите барања на вашата апликација (или оние со најтешките СЛА). MongoDB ја одразува структурата на објектите со тоа што дозволува еден запис (документ) да содржи вградени (неставени) објекти.
Во многу случаи, деловниот објект потребен од апликацијата ќе се префрли на еден MongoDB документ.
MongoDB има своја внатрешна LRU (најмалку неодамна користена) кеш, па ако вашиот документ неодамна е пристапен, шансите се дека веќе е во меморијата.
Забележете дека MongoDB поддржува
Друга додадена вредност од слојот за кеширање е локацијата на податоците во дистрибуираните архитектури.
Што мисли AI?
Одговорите создадени од генеративната АИ се водени од информациите што се објавени од вистински луѓе, и така треба да го претставуваат популарното мислење за некоја тема.
Јас го поставив ова прашање на ChatGPT 4o:
Објаснете зошто би користел кеш слој (како Redis) наместо мојата апликација да ги чита податоците од MongoDB директно.
Redis работи целосно во меморијата, што го прави значително побрз од MongoDB, кој се потпира на дискот I/O за враќање на податоци.
Објаснете зошто би користел кеш слој (како Redis) наместо мојата апликација да ги чита податоците од MongoDB директно.
Redis работи целосно во меморијата, што го прави значително побрз од MongoDB, кој се потпира на дискот I/O за враќање на податоци.
Како што е опишано погоре, MongoDB има свој кеш во меморијата, така што документите што често ги пристапувате ќе бидат во меморијата, а нема потреба од пристап до диск.
Често пристапување до MongoDB директно за истите податоци го зголемува товарот на прашањата, што може да ја забави базата на податоци, особено под тежок сообраќај за читање.
Често пристапување до MongoDB директно за истите податоци го зголемува товарот на прашањата, што може да ја забави базата на податоци, особено под тежок сообраќај за читање.
MongoDB е скалабилен. Дополнителни секундарни јазли може да се додадат во комплетот за реплика за да се додаде дополнителна опсег за барање.
Апликациите со висок коефициент на читање и пишување (на пример, веб-апликации, APIs) имаат корист од способноста на Redis брзо да им служи на кеширани податоци.
Апликациите со висок коефициент на читање и пишување (на пример, веб-апликации, APIs) имаат корист од способноста на Redis брзо да им служи на кеширани податоци.
Кешот на базата на податоци на MongoDB обезбедува истите придобивки без дополнителни напори на програмерите за синхронизирање на промените во податоците.
„Побрз пристап до често користените податоци. Redis е идеален за кеширање на често пристапни или топли податоци (на пример, кориснички сесии, конфигурации или детали за производот).“
„Побрз пристап до често користените податоци. Redis е идеален за кеширање на често пристапни или топли податоци (на пример, кориснички сесии, конфигурации или детали за производот).“
Често пристапени, топли податоци ќе се чуваат во кешот на базата на податоци во меморијата на MongoDB.
Со реплицирање на кесите на Redis поблиску до крајните корисници, можете да избегнете висока мрежна латенција при пребарување на MongoDB од далечни локации.
Со реплицирање на кесите на Redis поблиску до крајните корисници, можете да избегнете висока мрежна латенција при пребарување на MongoDB од далечни локации.
Локацијата на податоците може да се реши со поставување реплики во близина на локациите на серверот за апликации.
Поддршка за истекување на податоци (TTL). Redis има вградена функција Time-to-Live (TTL) која автоматски ги отстранува кешираните податоци по одредено времетраење.
Поддршка за истекување на податоци (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 шема која одговара на тоа како вашата апликација работи со податоците може да ги задоволи вашите барања за перформанси без да ви треба кеш слој.
Дали вашата апликација ќе има корист од преглед?
