Un enorme database: scegliere lo schema e il modello di dati giusti

Non ne so abbastanza del tuo sistema, ma devi vedere quanto segue:

1-Come si ottengono i dati e in quale formato? Rispondere a questo fornirà opzioni su come memorizzarlo e caricarlo inizialmente se si terminerà l'utilizzo di un database.

2-Come si elaborano questi dati grezzi? Rispondere a questo, ti aiuterà a capire la dimensione del set 'attivo'. Questo aiuterà a decidere come memorizzare e come caricare anche i dati. Potresti scoprire che non hai bisogno dell'intero record di input e tutto ciò di cui hai bisogno è composto solo da pochi campi. Se la maggior parte dei campi non viene utilizzata, è possibile conservarli in un archivio archiviato separato.

3-Come si richiedono questi dati (online / batch e quali criteri è più probabile che vengano utilizzati)? Rispondere a questo sarà il fattore chiave nel rispondere a come archiviare i dati quali parti tenere on-line e quali parti tenere fuori linea. Oracle ad esempio consente di eseguire SQL su file di testo senza caricare prima i file. Questo potrebbe essere un enorme risparmio di tempo, ma ovviamente dipende dal tuo scenario.

secondo il tuo punto:

single individuals variant data could feasibly some day require a million rows of data in a table

Davvero non capisco come sia possibile. Se è accurato, non sono sicuro di come verrà utilizzato. Forse è necessario separare i concetti di semplice archiviazione dei dati dal concetto di quali parti dei dati verranno utilizzate. Se comprendi di più su come verranno utilizzati i dati, potresti essere in grado di ridurre il numero di righe per aggregazione o una tecnica simile.

In breve, è necessaria molta analisi prima che una soluzione possa essere trovata. I principi guida sono:

1-Conosci bene i tuoi dati

2-Riduci le dimensioni della riga mantenendo solo le colonne necessarie e collegandole allo storage offline, quando possibile

3-Ridurre il numero totale di righe per aggregazione quando possibile

4-Utilizzare il partizionamento delle tabelle ed evitare l'indicizzazione eccessiva

5-Sapere come gli utenti devono utilizzare questi dati

6: considera il caricamento dei dati all'arrivo

7 - Probabilmente avrai bisogno di uno schema a stella (fatto e dimensioni) per velocizzare le query, ma non possiamo dire solo con le informazioni fornite

Per (1), cerca cose comuni, potresti essere sorpreso della sua estensione. Questo è l'unico modo per risolvere il problema delle dimensioni. È così che funziona la normalizzazione e persino la compressione: trova i pattern (a.k.a. roba comune), memorizzali in un unico punto, sostituisci i valori con i riferimenti in ogni posizione utilizzata.

Un'altra soluzione per (1), utilizzare il file system anziché il database ovunque sia possibile per salvare i dati BLOB. In Oracle puoi persino indicizzare per cercarli in un secondo momento.

Per (2), utilizzare viste (più mantenibili) o stored-procedure (meno mantenibili).

Un'altra soluzione per (2), potrebbe essere la soluzione migliore per creare piccole applicazioni separate per ogni gruppo di utenti. Presumo che non ti aspetti milioni di utenti, solo poche centinaia o poche migliaia. Realizzare 10 progetti separati è più gestibile rispetto a uno grande. In alternativa puoi dividere su basi di moduli, in .net a dll è un modulo, nel database c'è uno schema. Utilizza questa soluzione se non trovi molto in comune tra i tuoi utenti, se poi utilizzi la normalizzazione.

Non dimenticare la tecnica fondamentale di indicizzazione delle tabelle!

Ho fatto uso di file esterni e link a loro. Ciò ridurrà notevolmente la tensione sul DB. Dovrai trovare un modo per recuperare i dati dal file, ma può essere fatto semplicemente con JavaScript o PHP.