Idee sbagliate
Velocità
Anche quando non si parla di un indice multichiave, ecco cosa succede. È in corso un'enorme scansione della tabella. Quindi mongoDB scorre i documenti, prova a trovare il campo da indicizzare, valuta quel campo (to null se non esiste nel documento corrente) e scrive i suoi risultati in non meno di 6 file in quanto si tratta di 6 indici. Facendo i conti:200.000.000 / 86400 * 5 ci dice che mongoDB lo fa per circa 460 documenti al secondo o richiede solo 2,2 millisecondi per documento . Non lo definirei lento. Potrebbe volerci molto tempo, ma non è lento.
{background:true}
L'utilizzo di questo parametro non ti bloccano fuori dai database. Al contrario, come è chiaramente affermato nei documenti, sia su Sezione di creazione dell'indice e nella sezione tutorial sulla creazione di indici in background . Tuttavia, c'è una frase che può essere facilmente interpretata male:
Ciò significa che non è possibile eseguire operazioni che si applicano a tutti i database e richiedono un blocco di lettura o scrittura.
Modi per migliorare (in futuro)
Ammasso frammentato
Utilizzare un cluster condiviso con frammenti di set di repliche. È facile da configurare e presenta numerosi vantaggi oltre a prestazioni migliorate. Uno di questi è la facile scalabilità che aggiunge uno shard (e quindi aggiunge spazio e potenza di calcolo a un cluster) è molto facile. I backup hanno un impatto minore sull'applicazione. Non esiste più un singolo punto di errore (se eseguito correttamente, ciò vale anche per interruzioni su scala di un intero data center).
Usa un filesystem diverso
Siamo spiacenti, eseguire un'applicazione dipendente dalle prestazioni del disco io su un server Windows non ha senso per me, per niente. ExtFS4 o XFS sono tra il 25% e il 40% più veloci di NTFS o ReFS, a seconda dell'ottimizzazione. Questo rende un reale differenza sulle applicazioni che dipendono dall'IO del disco come il tuo caso d'uso. Si tratta di una questione di giorni (senza nemmeno tener conto della mappatura della memoria più efficiente e del ridotto consumo di memoria dell'OS su sistemi Linux).
{background:true}
Sebbene ciò non migliori realmente le prestazioni (in realtà la creazione di indici in background richiede più tempo rispetto a quella in primo piano per ovvi motivi), l'applicazione rimane disponibile durante il periodo di compilazione dell'indice. Quindi, a seconda delle tue esigenze, questa potrebbe essere un'opzione praticabile.
Nota a margine :È una Bad Idea™ , per ridimensionare verticalmente quando si utilizza mongoDB poiché è stato progettato esplicitamente per essere ridimensionato orizzontalmente. Ciò vale in particolare per raccolte di grandi dimensioni come la tua poiché l'elaborazione parallela migliorerebbe notevolmente le prestazioni della tua applicazione.
