Può essere una buona idea creare una nuova tabella per ogni cliente di una webapp?

In generale, no, non ha senso avere un tavolo (penso che tu in realtà significhi database qui) per cliente. 20 milioni di righe sono relativamente piccole per una tabella di database. La velocità della query non dovrebbe essere un problema a patto che il database sia sintonizzato correttamente (indicizzato) e le query siano messe insieme correttamente. Qualsiasi vantaggio tu ritenga di averli separati sarebbe compensato dall'ulteriore complessità della gestione di 20.000 singoli database. Ad esempio, cosa succede quando vuoi cambiare la struttura della tabella? Ora devi farlo 20.000 volte!

Caso peggiore, se alla fine si scopre che la dimensione del database sta diventando un problema, è sempre possibile dividerli in database separati in seguito.

Sembra una cattiva idea.

Non cercare di superare in astuzia il database con costruzioni esotiche come questa. I motori di database sono progettati con molte ottimizzazioni per gestire grandi insiemi di dati. Ad esempio, ciò che stai descrivendo sembra terribilmente vicino a un tentativo di implementare manualmente gli indici. Basta usare gli indici forniti dal motore DB, sono implementati molto meglio di quanto probabilmente si sarà in grado di fare da soli, e non richiederà tanto manutenzione.

Inoltre, come regola generale. Suggerisco di non progettare un database in un modo che richiede la manipolazione o la creazione di strutture di database (tabelle, campi) durante l'uso normale dell'applicazione. Rende l'ottimizzazione delle prestazioni un orso e spesso ti costringe a concedere troppe autorizzazioni agli utenti per svolgere attività di routine, creando potenzialmente buchi di sicurezza.

Ecco un articolo che esorto sempre le persone a leggere, quando fanno questa domanda:

link

IMHO una singola tabella non dovrebbe essere un problema, quindi non creare un problema in cui uno non esiste ancora. C'è molto che puoi fare per aiutare le prestazioni. È possibile partizionare una singola tabella su più file in base a clientID o un campo data per aiutare con IO. Il tuo database non deve tenere traccia, ottimizzare e memorizzare in cache 20.000 diverse istruzioni SQL per ogni query richiesta. Puoi indicizzare per clientid. I client 20K possono pagare molto hardware.

Per questo tipo di tabella, è possibile utilizzare un db di tipo NoSQL.

Con i client 20K, il database potrebbe non essere il tuo link più debole, quindi perché introdurre questa complessità?

È un approccio davvero brutto.

Partiziona la tabella verticalmente, 2 server di database uno per ID utente dispari, e un altro per anche dovrebbe funzionare bene (i dati non sono correlati tra gli utenti).

Ordina i dati per user_id e se ciò non è possibile ottieni una quantità enorme di dischi RAM o SSD.