Come posso risolvere questo problema di ridimensionamento con l'eliminazione soft degli elementi?

Question

Ho un database in cui la maggior parte delle tabelle ha un flag di eliminazione per le tabelle. Pertanto, il sistema elimina gli elementi (quindi non sono più accessibili se non per esempio dagli amministratori)

Ciò che mi preoccupa è tra qualche anno, quando i tavoli saranno molto più grandi, è che la velocità complessiva del sistema verrà ridotta.

Cosa posso fare per contrastare effetti del genere.

• Devo indicizzare il campo di eliminazione?
• Sposto i dati eliminati in una tabella di eliminazione identica e viceversa quando vengono eliminati?
• Distribuisco i dati su alcuni server MySQL nel tempo? (basato sulla crescita)

Gradirei qualsiasi suggerimento o storia.

UPDATE:

Quindi il partizionamento sembra essere la chiave per questo. Ma il partizionamento non creerebbe semplicemente due & Quot; tabelle & Quot ;, uno con gli elementi eliminati e uno senza gli elementi eliminati.

Quindi nel tempo la partizione eliminata diventerà grande e gli occasionali recuperi da essa saranno lenti (e più lenti nel tempo)

La differenza di velocità sarebbe qualcosa di cui dovrei preoccuparmi? Dal momento che prendo la maggior parte dei dati (se non tutti) per un valore chiave (alcuni sono ricerche ma possono essere lenti per questa configurazione)

Answer 1

Partizionerei la tabella sul DELETE flag.

Le righe eliminate verranno mantenute fisicamente in un altro posto, ma dal punto di vista di SQL la tabella rimane invariata.

Answer 2

Oh, diavolo sì, indicizza il campo di eliminazione. Ti interrogherai continuamente, giusto? Anche gli indici composti con altri campi su cui si interrogano molto, come gli ID padre, potrebbero essere una buona idea.

Answer 3

Probabilmente, questa decisione potrebbe essere presa in seguito se e solo se compaiono effettivamente problemi di prestazioni. Dipende molto da quante righe vengono aggiunte a quale velocità, dalle specifiche della tua scatola, ecc. Ovviamente, il livello di astrazione nella tua applicazione (e i limiti di tutte le librerie che stai usando) ti aiuteranno a determinare quanto sarà difficile una tale modifica .

Se diventa un problema, o sei sicuro che lo sarà, inizia partizionando il flag eliminato tra due tabelle, una che contiene i dati correnti e una che contiene i dati storici / eliminati. SE, come hai detto, il & Quot; cancellato & Quot; i dati saranno disponibili solo per gli amministratori, è ragionevole supporre che (nella maggior parte delle applicazioni) il numero totale di utenti (qui limitato solo agli amministratori) non sarà sufficiente a causare un problema. Ciò significa che i tuoi amministratori potrebbero dover aspettare un po 'di più durante la ricerca di quella particolare tabella, ma la tua base di utenti (probabilmente più importante nella maggior parte delle applicazioni) subirà una latenza molto inferiore. Se le prestazioni diventano inaccettabili per gli amministratori, è probabile che tu voglia indicizzare il campo user_id (o transazione_id o qualsiasi altra cosa) a cui accedi ai record eliminati da (generalmente indicizzo tutti i campi in cui accedo alla tabella, ma a una certa scala ci possono essere scambi -off su quali indici sono più utili).

A seconda di come si accede ai dati, ci sono altri semplici trucchi che è possibile utilizzare. Se l'amministratore sta cercando un record specifico per la maggior parte del tempo (al contrario, diciamo, leggendo un & Quot; history & Quot; o & Quot; log & Quot; dell'attività dell'utente), spesso si può presumere che i record più recenti verranno esaminati più spesso di quelli vecchi. Alcuni DB includono opzioni di ottimizzazione per rendere più facili da trovare i record recenti rispetto ai record precedenti, ma dovrai cercare il tuo database specifico. In caso contrario, puoi farlo manualmente. Il modo più semplice sarebbe avere una tabella ancient_history che contenga tutti i record più vecchi di n giorni, settimane o mesi, a seconda dei vincoli e dei modelli di utilizzo sospetti. I dati più recenti vivono quindi all'interno di una tabella molto più piccola. Anche se l'amministratore sta per & Quot; sfogliare & Quot; tutti i record piuttosto che cercarne uno specifico, puoi iniziare mostrando i primi n giorni e avere un link per vedere tutti i giorni se non trovano quello che stanno cercando (ad esempio, la maggior parte dei servizi bancari online applicazioni che ti consentono di sfogliare le transazioni ma mostra solo i primi 30 giorni della cronologia, salvo diversa richiesta.)

Si spera che tu possa evitare di fare un ulteriore passo in avanti e condividere su user_id o alcuni di questi schemi. A seconda della scala del resto dell'applicazione, potrebbe essere necessario farlo comunque. A meno che tu non sia sicuro di doverlo fare, ti consiglio vivamente di utilizzare prima il partizionamento verticale (ad esempio, mantenendo i forum_posts su una macchina separata rispetto ai tuoi sales_record), poiché è MOLTO più facile da configurare e mantenere. Se finisci per dover condividere su user_id, ti suggerisco di usare google; -]

Buona fortuna. A proposito, non sono un DBA, quindi prendi questo con un granello di sale.