Se MongoDB ha un tallone d'Achille è perché supporta solo scritture a thread singolo e riduzioni di mappe a thread singolo.
Come sempre, qui ci sono dei compromessi. Le scritture a thread singolo sono il modo più semplice per evitare problemi di blocco e ridurre al minimo l'overhead. Allo stesso modo, le riduzioni di mappe multi-thread sono un ottimo modo per bloccare i dati. Quindi le riduzioni di mappe a thread singolo su un sistema di produzione sono probabilmente più facili e sicure.
Tuttavia, non sei senza strumenti qui. MongoDB fornirà un thread di scrittura a ciascuna istanza. Quindi, se shard MongoDB, otterrai un thread di scrittura per ogni shard.
Se desideri più indici su 2 miliardi di righe, ti consigliamo comunque di esaminare lo sharding. Alcuni calcoli veloci qui:MongoID è 12 byte. L'indice su MongoID sarà 2B * 12 byte =22 GB+. Se ora vuoi aggiungere altri due indici (anche solo due interi da 4 byte) stiamo parlando di 7,5 GB ciascuno.
Quindi con 2 miliardi di righe, stai parlando di avere oltre 37 GB negli indici (minimo ). Sulla maggior parte dei server a 8 core, ciò significa che non sarai nemmeno in grado di mantenere gli indici in memoria, per non parlare dei dati.
Quindi, se vuoi prestazioni serie qui, ti consigliamo di iniziare a guardare lo sharding. Solo in base ai numeri generali. FWIW, MySQL non sarebbe più abile nella gestione di documenti 2B. Con così tanti dati, vorrai davvero che più server tengano il passo con il carico.
