Il test di MongoDB storage tiering aumenta il throughput fino a 5,2x
MongoDB storage tiering ha aumentato il throughput da 1,6x a 5,2x in una proof of concept pubblicata da Percona il 2 novembre 2026. I risultati suggeriscono che i workload incentrati principalmente sui record recenti possano avere un'alternativa all'acquisto immediato di macchine più grandi o all'introduzione dello sharding, anche se il software non è stato utilizzato in produzione e nei test ha prodotto una tail latency degli aggiornamenti significativamente peggiore.
Il problema di fondo inizia quando un replica set MongoDB, un gruppo di server di database che conserva copie degli stessi dati, cresce oltre la memoria disponibile. Il suo working set, ossia i dati usati abbastanza frequentemente da trarre vantaggio da un accesso rapido, non entra più nella WiredTiger cache, l'area di memoria utilizzata da MongoDB per fornire i dati in modo efficiente. I documenti non presenti nella cache devono quindi essere letti dallo storage. Nel cluster sottoposto al test, un read p95 di 70 millisecondi, indicante che il 95% delle letture veniva completato entro quel tempo, rifletteva un disco che operava al proprio limite di input/output operations per second (IOPS), anziché un indice inefficiente.
Lo sharding può suddividere un database di grandi dimensioni tra più macchine, ma introduce una shard key che determina dove risiedono i record, processi di routing mongos, configuration server e balancing. In genere, per rimanere efficienti, le query devono includere la shard key, mentre modificare tale key non è semplice. La proof of concept, denominata Thermocline, colloca invece davanti al cluster originale un replica set più piccolo contenente i record recenti. Il replica set esistente rimane intatto come archive e l'applicazione si connette a un proxy usando il normale protocollo di comunicazione di MongoDB, anziché direttamente al vecchio cluster.
Quattro componenti gestiscono la configurazione. Il proxy invia una query al fast tier soltanto quando tale tier può stabilire di contenere la risposta completa; in caso contrario, la query viene inviata all'archive. Le nuove scritture entrano inizialmente nel fast tier. Un feeder legge il relativo change stream, il registro continuo delle modifiche al database di MongoDB, e riproduce ogni scrittura nell'archive, in modo che quest'ultimo conservi tutti i documenti. Un evictor elimina i record dal fast tier dopo che hanno superato l'età configurata per la relativa collection, ma solo dopo aver verificato che siano presenti nell'archive. Un warmer copia dall'archive al fast tier i record più recenti rispetto a tale età. Il fast tier può quindi iniziare vuoto e riempirsi sia tramite il traffico in entrata sia mediante il warming in background, senza caricamento manuale.
Percona ha riferito che il test è stato eseguito su Hetzner Cloud. Il deployment esistente era un replica set con tre membri, contenente 40 milioni di ordini simulati e 47 GB di dati. Ogni membro era limitato a 2,5 GB di memoria, inclusa una WiredTiger cache da 1 GB, e il relativo disco dati era limitato a 3.000 letture al secondo. Il dataset era quindi circa 47 volte più grande della cache. Il secondo tier era un altro replica set con tre membri e inizialmente era vuoto.
Il workload ha utilizzato Yahoo! Cloud Serving Benchmark (YCSB) 0.17, uno strumento per generare traffico di database ripetibile, con 64 thread. Le esecuzioni sono durate dieci minuti, con due esecuzioni per ciascun lato del confronto. Ogni documento simulato aveva una data distribuita nell'arco dell'anno precedente. Il mix del negozio online comprendeva l'85% di letture, il 10% di aggiornamenti e il 5% di inserimenti, con letture orientate verso i documenti più recenti. Un mix a prevalenza di letture utilizzava il 95% di letture e il 5% di aggiornamenti, con lo stesso modello di recenza. Una variante concentrata utilizzava lo stesso mix 95 a 5, ma indirizzava il 99% di tutta l'attività verso il 9% più recente dei documenti. Ogni workload è stato eseguito sia sul solo cluster originale sia sullo stesso cluster dietro Thermocline, utilizzando la stessa release di MongoDB, gli stessi limiti di risorse e lo stesso client.
In queste esecuzioni, dietro il proxy di tiering il cluster soggetto al limite ha completato da 1,6x a 5,2x più operazioni al secondo, senza operazioni rifiutate. Il miglioramento maggiore è derivato dal workload concentrato, passato da 4.447 a 23.340 operazioni al secondo. Il relativo read p95 è sceso da 86 a 6 millisecondi, mentre il p99, il tempo entro il quale è stato completato il 99% delle letture, è diminuito da 92 a 8 millisecondi.
Un confronto a carico fisso ha richiesto 6.165 operazioni al secondo per il workload del negozio, un valore corrispondente al massimo del cluster originale. Da solo, tale cluster ha fornito 6.086 operazioni al secondo con un read p95 di 70,5 millisecondi. Dietro Thermocline, due esecuzioni hanno fornito rispettivamente 6.156 e 6.159 operazioni al secondo, con risultati p95 di 2,8 e 2,1 millisecondi. Il read p99 è variato tra 7 e 27 millisecondi nelle esecuzioni con storage tiering, rispetto agli 81 millisecondi del solo archive. Le letture disco sull'archive sono diminuite da 2.704 a 1.838 al secondo.
Il test con avvio a vuoto ha misurato il percorso di adozione più realistico. Durante 30 minuti di esecuzione del workload del negozio senza un limite di throughput imposto, la coppia ha registrato una media di 8.221 operazioni al secondo. Il risultato è stato del 42% superiore alle 5.803 operazioni al secondo del cluster originale con cache a freddo. La configurazione con storage tiering ha superato il risultato del vecchio cluster dopo 100 secondi, registrando una media di 6.417 operazioni al secondo nei primi cinque minuti e di 9.146 negli ultimi cinque. Durante questo periodo ha copiato 271.271 documenti dall'archive al fast tier.
Le limitazioni sono notevoli. Ogni scrittura deve comunque raggiungere l'archive e il mirroring di un aggiornamento richiede che l'archive legga prima dal disco il documento esistente. Gli aggiornamenti nel workload del negozio sono rimasti vincolati dal vecchio cluster, mentre il p99 degli aggiornamenti è peggiorato, raggiungendo valori compresi tra 455 e 472 millisecondi, rispetto ai 104-189 millisecondi senza Thermocline. Questo problema di tail latency rimane irrisolto nella proof of concept. Anche le query relative a record esterni al fast tier vengono inviate all'archive e rimangono lente come in precedenza; pertanto, i workload che leggono in modo uniforme l'intera cronologia dovrebbero aspettarsi benefici limitati.
Entrambi i tier devono utilizzare la stessa release di MongoDB, perché l'archive esegue direttamente le query dell'applicazione e deve essere in grado di comprenderle. Di conseguenza, un deployment meno recente dovrebbe essere aggiornato prima dell'adozione. Soprattutto, Thermocline dispone di un'ampia suite di test, ma non ha gestito traffico di produzione. I miglioramenti misurati riguardano questo cluster e questo workload di test, non ogni installazione MongoDB; le organizzazioni dovrebbero quindi riprodurre i propri modelli di traffico e i propri test di guasto prima di trarre conclusioni. Il codice e le istruzioni operative sono disponibili nel repository di Thermocline con licenza Apache 2.0.
Per le organizzazioni che stanno valutando dove eseguire i tier del database, AEU Data offre infrastrutture cloud e dati europee come una delle opzioni disponibili. La conclusione più generale è che MongoDB storage tiering può alleviare i limiti di un replica set con memoria insufficiente quando i dati recenti dominano le letture, ma non elimina i costi di scrittura sull'archive, non accelera le query storiche e non sostituisce la validazione in produzione.