Dato quel campo key è indicizzato in entrambi i casi, l'indice di complessità ricerca esso stesso sarebbe molto simile. Come valore di a sarebbe hashing
e archiviato nell'albero dell'indice.
Se cerchiamo il costo complessivo delle prestazioni, la versione con hash comporterebbe un costo aggiuntivo (trascurabile) per l'hashing del valore di a prima di far corrispondere il valore nell'albero dell'indice. Vedi anche mongo/db/index /hash_access_method.h
Inoltre, l'indice hash non sarebbe in grado di utilizzare la compressione del prefisso dell'indice ( WiredTiger) . La compressione del prefisso dell'indice è particolarmente efficace per alcuni set di dati, come quelli con cardinalità bassa (ad es. Paese) o quelli con valori ripetuti, come numeri di telefono, codici di previdenza sociale e coordinate geografiche. È particolarmente efficace per indici composti , dove il primo campo viene ripetuto con tutti i valori univoci del secondo campo.
In genere non vi è alcun motivo per eseguire l'hashing di un valore non compreso nell'intervallo. Per scegliere una chiave shard, considera la cardinalità , frequenza e tasso di variazione del valore.
L'indice hash è comunemente usato per un caso specifico di sharding . Quando una chiave shard il valore è un aumento/decrescente monotono valore, è probabile che la distribuzione dei dati vada in un solo shard. È qui che una chiave shard con hash potrebbe migliorare la distribuzione delle scritture. È un piccolo compromesso per migliorare notevolmente il tuo cluster di partizionamento orizzontale. Vedi anche Hashing vs Ranged Sharding .
Se ne vale la pena, dipende dal caso d'uso. Un valore hash personalizzato significherebbe che qualsiasi query per il valore hash dovrebbe passare attraverso un codice hash personalizzato, ad esempio un'applicazione.
Il vantaggio dell'utilizzo della funzione hash incorporata è che MongoDB calcola automaticamente gli hash durante la risoluzione delle query utilizzando indici hash. Pertanto, le applicazioni non devono calcolare gli hash.
