La risposta breve è che se hai impostato correttamente le cose, è uno spreco sia di spazio che di tempo per mantenere una mappatura master centrale separata di quali chiavi primarie esistono a livello globale.
La tua funzione shard ti dice quale frammento ha autorevolezza per una determinata chiave primaria. Un elenco principale centrale di quali file sono attualmente nel database distribuito sarebbe un'aggregazione tra i frammenti dell'elenco di chiavi primarie per le quali tale frammento è autorevole. Mantenere questa mappatura centrale coerente con i set di chiavi presenti su ciascun frammento comporta un sovraccarico non necessario e diventa rapidamente un collo di bottiglia per tutte le modifiche del database su qualsiasi frammento a livello globale. Tutte le inserzioni o eliminazioni di righe richiederebbero l'interrogazione di questa mappatura centrale centrale per vedere se è coerente, eventualmente seguita dalla modifica della mappatura centrale del master.
Anche con la tua proposta di mappatura principale delle chiavi primarie per i frammenti, devi comunque contattare ogni frammento per eseguire la tua riduzione. (Ovviamente, salti tutti i frammenti che la tua funzione sharding ti dice che non contengono righe rilevanti per l'operazione di riduzione.)
Se la tua lista principale proposta può rispondere alla tua domanda senza contattare i frammenti, probabilmente non vorrai interrogarla comunque, poiché è già un collo di bottiglia per tutte le operazioni di scrittura. Ovviamente è possibile suddividere questo elenco principale di chiavi primarie per prestazioni migliori, ma poi non è più l'elenco centrale proposto di chiavi primarie. Ciò dovrebbe essere considerato come un secondo database distribuito di sola lettura che contiene un mirror di un sottoinsieme delle colonne nel database distribuito primario. Ora, una seconda copia di sola lettura distribuita di un sottoinsieme di dati ha senso per alcuni schemi di utilizzo. Tuttavia, il suo significato è strongmente dipendente dai modelli di utilizzo e introduce un ritardo di replica tra il database distribuito primario e il database distribuito secondario.