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

10

Questo è semi-ipotetico, e dato che non ho esperienza nel gestire enormi tabelle di database, non ho idea se questo sia orribile per qualche motivo. Sulla situazione:

Immagina un'applicazione web - diciamo software di contabilità - che ha 20.000 client e ogni client ha oltre 1000 voci in una tabella. Sono 20 milioni di righe che conosco possono sicuramente rallentare query complesse.

In un caso come questo, ha più senso creare una nuova tabella nel database per ciascun client? Come reagiscono i database ad avere 20k (o più!) Tabelle?

web-applications database-development

— Volere
fonte

15

In generale, no, non ha senso avere una tabella (penso che tu intenda effettivamente un database qui) per cliente. 20 milioni di righe sono relativamente piccole per una tabella di database. La velocità delle query non dovrebbe essere un problema, a condizione che il database sia correttamente ottimizzato (indicizzato) e le query siano messe insieme correttamente. Qualunque vantaggio pensi di ottenere dalla loro separazione, sarebbe compensato dalla complessità aggiuntiva della gestione di 20.000 singoli database. Ad esempio, cosa succede quando si desidera modificare la struttura della tabella? Ora devi farlo 20.000 volte!

Peggio ancora, se alla fine scopri che le dimensioni del database stanno diventando un problema, puoi sempre dividerle in database separati in seguito.

— GrandmasterB
fonte

no, intendevo letteralmente tabelle all'interno del database. Non riesco a immaginare un motivo per creare un database per client. E se 20 milioni di righe sono piccole, che cosa è grande? E cosa fai a quel punto?

— Will

1

@ChrisF, esattamente - ci sono molti casi in cui la tecnologia o il modello di business richiedono DB separati per client. Ma non riesco a pensare a un motivo per tabelle separate all'interno dello stesso DB.

— GrandmasterB,

1

@GrandmasterB - Penso che @Will stia facendo la domanda sbagliata.

— ChrisF

1

@Will: se possibile, vai a una riunione del gruppo di utenti Oracle o equivalente per qualche altro database di fascia alta. Scoprirai che le tue idee di "piccolo" e "grande" hanno bisogno di molti aggiustamenti. È successo a me. Suggerimento: se si adatta a un disco, non è grande per gli standard DBA.

— David Thornley,

1

@Gorton, InnoDB è generalmente considerato migliore per affidabilità e concorrenza, MyISAM per velocità. Quindi è necessario valutare i diversi motori di archiviazione in base all'utilizzo previsto del database dell'applicazione specifica.

— GrandmasterB,

5

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 set di dati di grandi dimensioni. Ad esempio, ciò che stai descrivendo sembra molto vicino a un tentativo di implementare manualmente gli indici. Usa solo gli indici forniti da DB Engine, sono implementati molto meglio di quanto probabilmente sarai in grado di fare da solo, e non richiederà tanta manutenzione.

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

— JohnFx
fonte

Vorrei votare una volta per ciascuno dei tuoi due paragrafi, se consentito.

— David Thornley,

3

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

http://datacharmer.blogspot.com/2009/03/normalization-and-smoking.html

— Mchl
fonte

Non avevo idea che un DB crea un file effettivo per tabella = x

— Will,

1

Ciò potrebbe dipendere dall'RDBMS effettivo utilizzato. MySQL lo fa (fino a tre file per tabella se usi MyISAM). Altri potrebbero no.

— Mchl,

La versione Enterprise di SQL Server lo farà se lo si progetta in questo modo, ma non automaticamente.

— JeffO,

Oracle sicuramente non lo fa.

— user281377,

Oracle può farlo, allo stesso modo in cui SQL Server può farlo, ma non riesco a immaginare perché dovresti mai progettare il tuo schema per avere un file per tabella. La suddivisione di un database in più file ha senso, ma non un file per tabella.

— Dean Harding,

1

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 db non deve tenere traccia, ottimizzare e memorizzare nella cache 20.000 diverse istruzioni sql per ogni query di cui il tuo sito avrà bisogno. Puoi indicizzare per clientid. I clienti 20K possono pagare un sacco di hardware.

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

Con 20.000 client, il database potrebbe non essere il tuo collegamento più debole, quindi perché introdurre questa complessità?

— Jeffo
fonte

`Puoi partizionare una singola tabella su più file in base a clientID o un campo data per aiutare con IO. - Non sei sicuro di cosa intendi con questo. Qualche chiarimento?

— Sarà il

Più file sul sistema operativo. Un server può eseguire più operazioni di lettura / scrittura su molti file anziché solo uno.

— JeffO,

Immagino di voler dire: non ho mai sentito parlare di una cosa del genere, dove posso trovare maggiori informazioni su come farlo? :-) Ma raggiungerò google ~

— Sarà il

msdn.microsoft.com/en-us/library/ms345146(v=sql.90).aspx È possibile riscontrare problemi di prestazioni di backup se gli indici si trovano su file separati rispetto alle tabelle che indicizzano (o forse alle unità?).

— JeffO,

0

È un approccio davvero pessimo.

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

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

— Slawek
fonte