Testi i MongoDB storage tiering rrit throughput deri në 5.2x
MongoDB storage tiering rriti throughput me 1.6x deri në 5.2x në një proof of concept të publikuar nga Percona më 2 nëntor 2026. Rezultatet sugjerojnë se workload-et e përqendruara kryesisht te record-et e fundit mund të kenë një alternativë ndaj blerjes së menjëhershme të makinerive më të mëdha ose zbatimit të sharding, megjithëse software-i nuk është përdorur në production dhe gjatë testimit shkaktoi tail latency dukshëm më të keqe për update-et.
Problemi bazë fillon kur një MongoDB replica set, një grup serverësh database që ruajnë kopje të të njëjtave të dhëna, rritet përtej memories së disponueshme. working set i tij, domethënë të dhënat që përdoren aq shpesh sa përfitojnë nga aksesi i shpejtë, nuk futet më brenda WiredTiger cache, zona e memories që MongoDB përdor për të shërbyer të dhënat me efikasitet. Document-et që nuk ndodhen në cache duhet të lexohen më pas nga storage. Në cluster-in e testuar, read p95 prej 70 milisekondash, që do të thotë se 95 për qind e leximeve përfunduan brenda kësaj kohe, tregonte se disku po funksiononte në kufirin e tij të input/output operations per second (IOPS), dhe jo se index ishte joefikas.
Sharding mund ta ndajë një database të madh ndërmjet disa makinerive, por sjell një shard key që përcakton se ku ruhen record-et, procese mongos për routing, serverë konfigurimi dhe balancing. Query-t në përgjithësi kanë nevojë për shard key që të mbeten efikase, ndërsa ndryshimi i këtij key nuk është i thjeshtë. Proof of concept, i quajtur Thermocline, vendos në vend të kësaj përpara cluster-it origjinal një replica set më të vogël që mban record-et e fundit. replica set ekzistues mbetet i paprekur si archive dhe aplikacioni lidhet me një proxy duke përdorur protokollin normal të komunikimit të MongoDB, në vend që të lidhet drejtpërdrejt me cluster-in e vjetër.
Katër komponentë e menaxhojnë këtë strukturë. Proxy ia dërgon një query fast tier vetëm kur ky tier mund të përcaktojë se përmban përgjigjen e plotë; përndryshe, query i dërgohet archive. Write-et e reja hyjnë fillimisht në fast tier. Një feeder lexon change stream të tij, rrjedhën e vazhdueshme të MongoDB që regjistron ndryshimet në database, dhe riprodhon çdo write në archive, në mënyrë që archive t'i ruajë të gjitha document-et. Një evictor fshin record-et nga fast tier pasi ato kalojnë moshën e konfiguruar për collection-in e tyre, por vetëm pasi konfirmon se archive i ka ato. Një warmer kopjon nga archive në fast tier record-et më të reja se ajo moshë. Prandaj, fast tier mund të nisë bosh dhe të mbushet si përmes traffic hyrës, ashtu edhe përmes warming në background, pa ngarkim manual.
Percona raportoi se testi u zhvillua në Hetzner Cloud. Deployment-i ekzistues ishte një replica set me tre anëtarë, që përmbante 40 milionë porosi të simuluara dhe 47 GB të dhëna. Çdo anëtar ishte kufizuar në 2.5 GB memory, duke përfshirë një WiredTiger cache prej 1 GB, ndërsa data disk i tij kishte një kufi prej 3,000 leximesh në sekondë. Për rrjedhojë, dataset ishte rreth 47 herë më i madh se cache. Tier i dytë ishte një tjetër replica set me tre anëtarë dhe nisi bosh.
Workload përdori Yahoo! Cloud Serving Benchmark (YCSB) 0.17, një mjet për gjenerimin e traffic të përsëritshëm për database, me 64 thread-e. Ekzekutimet zgjatën dhjetë minuta, me nga dy ekzekutime në secilën anë të krahasimit. Çdo document i simuluar kishte një datë të shpërndarë përgjatë vitit paraardhës. Përzierja e dyqanit online përbëhej nga 85 për qind lexime, 10 për qind update-e dhe 5 për qind insert-e, ku leximet favorizonin document-et më të reja. Një përzierje read-heavy përdori 95 për qind lexime dhe 5 për qind update-e, me të njëjtin model recency. Një variant i përqendruar përdori këtë përzierje 95 me 5, por drejtoi 99 për qind të të gjithë aktivitetit te 9 për qind e document-eve më të reja. Çdo workload u ekzekutua si vetëm ndaj cluster-it origjinal, ashtu edhe ndaj të njëjtit cluster pas Thermocline, duke përdorur të njëjtin MongoDB release, të njëjtat kufizime burimesh dhe të njëjtin client.
Në këto ekzekutime, cluster-i me kufizim përfundoi 1.6x deri në 5.2x më shumë operacione në sekondë pas tiering proxy, pa operacione të refuzuara. Përmirësimi më i madh erdhi nga workload i përqendruar, i cili u rrit nga 4,447 në 23,340 operacione në sekondë. read p95 i tij ra nga 86 në 6 milisekonda, ndërsa p99, pika kohore brenda së cilës përfunduan 99 për qind e leximeve, ra nga 92 në 8 milisekonda.
Një krahasim me ngarkesë fikse përdori një nivel të kërkuar prej 6,165 operacionesh në sekondë për workload e dyqanit, duke përputhur maksimumin e cluster-it origjinal. I vetëm, ai cluster ofroi 6,086 operacione në sekondë me read p95 prej 70.5 milisekondash. Pas Thermocline, dy ekzekutime ofruan 6,156 dhe 6,159 operacione në sekondë, me rezultate p95 përkatësisht prej 2.8 dhe 2.1 milisekondash. read p99 ndryshoi nga 7 në 27 milisekonda gjatë ekzekutimeve me tiering, krahasuar me 81 milisekonda vetëm për archive. Leximet e diskut në archive ranë nga 2,704 në 1,838 në sekondë.
Testi me nisje bosh mati rrugën më realiste të adoptimit. Gjatë 30 minutave të workload të dyqanit, që funksionoi pa një kufi të vendosur për throughput, çifti arriti mesatarisht 8,221 operacione në sekondë. Kjo ishte 42 për qind më shumë se 5,803 operacionet në sekondë të cluster-it origjinal me cache të ftohtë. Konfigurimi me tiering e tejkaloi rezultatin e cluster-it të vjetër pas 100 sekondash, arriti mesatarisht 6,417 operacione në sekondë gjatë pesë minutave të para dhe 9,146 gjatë pesë minutave të fundit. Gjatë kësaj periudhe, ai kopjoi 271,271 document-e nga archive në fast tier.
Kufizimet janë të konsiderueshme. Çdo write duhet të arrijë përsëri në archive dhe pasqyrimi i një update kërkon që archive ta lexojë fillimisht nga disku document-in ekzistues. Update-et në workload e dyqanit mbetën të kufizuara nga cluster-i i vjetër, ndërsa update p99 u përkeqësua në 455 deri në 472 milisekonda, krahasuar me 104 deri në 189 milisekonda pa Thermocline. Ky problem i tail latency mbetet i pazgjidhur në proof of concept. Query-t që mbulojnë record-e jashtë fast tier dërgohen gjithashtu në archive dhe mbeten po aq të ngadalta sa më parë, prandaj workload-et që lexojnë në mënyrë të njëtrajtshme në të gjithë historikun e tyre duhet të presin pak përfitim.
Të dy tier-et duhet të përdorin të njëjtin MongoDB release, sepse archive ekzekuton drejtpërdrejt query-t e aplikacionit dhe duhet t'i kuptojë ato. Për rrjedhojë, një deployment më i vjetër do të duhej të përditësohej përpara adoptimit. Më e rëndësishmja, Thermocline ka një test suite të gjerë, por nuk ka përpunuar traffic production. Përfitimet e matura i përkasin këtij cluster-i dhe këtij workload-i testues, jo çdo instalimi MongoDB, ndaj organizatat do të duhej të riprodhonin modelet e tyre të traffic dhe testet e failure përpara se të nxirrnin përfundime. Kodi dhe udhëzimet e operimit janë të disponueshme në Thermocline repository nën licencën Apache 2.0.
Për organizatat që vlerësojnë se ku t'i ekzekutojnë tier-et e database, AEU Data ofron cloud dhe infrastrukturë të dhënash evropiane si një alternativë infrastrukturore e disponueshme. Mësimi më i gjerë është se MongoDB storage tiering mund ta lehtësojë një replica set të kufizuar nga memory kur të dhënat e fundit dominojnë leximet, por nuk eliminon kostot e write në archive, nuk përshpejton query-t historike dhe nuk zëvendëson validimin në production.