Questo sostanzialmente si riduce a se 10 indici di dimensione N sono più efficienti di un indice di dimensione N * 10. Se guardi semplicemente le letture, gli indici separati dovrebbero sempre essere più veloci. Le passeggiate b-tree associate esamineranno un keyset più piccolo ecc.
Ci sono un paio di punti da considerare però:
- Gli indici sui campi dell'array fondamentalmente indicizzano ogni elemento dell'array separatamente. In quanto tale, l'overhead di ricerca sarà al massimo di 1-2 passaggi aggiuntivi durante il b-tree walk, che è un risultato trascurabile in termini di prestazioni. In altre parole, saranno quasi altrettanto veloci.
- Avere 10 indici può significare che ogni aggiornamento/inserimento richiederà più di un indice per essere aggiornato (a seconda se i tuoi indici condividono un campo o se aggiorni più di 1 timestamp alla volta). Questa è una considerazione importante sulle prestazioni.
- L'utilizzo di un indice di matrice semplifica l'aggiunta di timestamp aggiuntivi (ad es. Timestamp10).
- C'è un limite al numero di spazi dei nomi che puoi usare per database (24k) e ogni indice ne occupa uno. Se crei un indice separato per campo, questo potrebbe diventare un problema.
- La cosa più importante è che l'indice dell'array è molto più semplice e semplificherà il codice e quindi la manutenibilità. Date le limitate differenze di prestazioni, direi che questa è la motivazione più forte per scegliere un indice di array qui.
