Domanda Best practice del database SQL: utilizzo delle tabelle di archiviazione?


Non sono un DBA addestrato, ma eseguo alcune attività SQL e ho questa domanda:

Nei database SQL ho notato l'uso di tabelle di archivio che imitano un'altra tabella con gli stessi campi esatti e che vengono utilizzate per accettare righe dalla tabella originale quando tali dati vengono considerati per l'archiviazione. Poiché ho visto esempi in cui quei tavoli risiedono nello stesso database e sullo stesso disco, la mia ipotesi è che ciò sia stato fatto per aumentare le prestazioni. Tali tabelle non contenevano più di 10 milioni di file in esse ...

  • Perché questo dovrebbe essere fatto invece di usare una colonna per designare lo stato della riga, come un booleano per un flag in / active?
  • A che punto questo migliorerebbe le prestazioni?
  • Quale sarebbe il modello migliore per strutturarlo correttamente, dato che i dati potrebbero ancora essere interrogati (o uniti con i dati attuali)?
  • Cos'altro c'è da dire su questo?

12
2018-01-16 23:42


origine


risposte:


La nozione di archiviazione è fisica, non logica. Logicamente la tabella di archivio contiene la stessa identica entità e dovrebbe essere la stessa tabella.

Le preoccupazioni fisiche tendono ad essere pragmatiche. La nozione generale è che il "database sta diventando troppo (grande / lento"). Archiviare i record rende più facile fare cose come:

  1. Ottimizza la struttura dell'indice in modo diverso. Le tabelle di archivio possono contenere più indici senza influire sulle prestazioni di inserimento / aggiornamento sulla tabella di lavoro. Inoltre, gli indici possono essere ricostruiti con pagine complete, mentre il tavolo di lavoro generalmente vorrebbe avere pagine piene al 50% e bilanciate.

  2. Ottimizza i supporti di archiviazione in modo diverso. È possibile inserire la tabella di archivio su unità disco più lente / meno costose che potrebbero avere una maggiore capacità.

  3. Ottimizza le strategie di backup in modo diverso. Le tabelle di lavoro possono richiedere backup a caldo o la distribuzione dei registri mentre le tabelle di archivio possono utilizzare le istantanee.

  4. Ottimizza la replica in modo diverso, se la stai usando. Se una tabella di archivio viene aggiornata solo una volta al giorno tramite batch notturno, è possibile utilizzare lo snapshot anziché la replica transazionale.

  5. Diversi livelli di accesso. Forse vuoi diversi livelli di accesso di sicurezza per la tabella degli archivi.

  6. Blocca la contesa. Se la tua tabella di lavoro è molto calda, preferisci che i tuoi sviluppatori MIS accedano alla tabella degli archivi, dove è meno probabile che interrompano le operazioni quando eseguono qualcosa e dimenticano di specificare la semantica della lettura sporca.

La best practice non dovrebbe utilizzare tabelle di archivio ma spostare i dati dal database OLTP in un database MIS, data warehouse o data mart con dati denormalizzati. Ma alcune organizzazioni avranno difficoltà a giustificare il costo di un sistema DB aggiuntivo (che non è economico). Ci sono molti meno ostacoli nell'aggiunta di una tabella aggiuntiva a un DB esistente.


5
2018-01-17 01:27



Lo dico spesso, ma ...

Tavoli multipli di struttura identica non hanno quasi mai senso.

Una bandiera di stato è un'idea molto migliore. Esistono metodi adeguati per aumentare le prestazioni (partizionamento / indicizzazione) senza denormalizzare i dati o altrimenti creare ridondanze. 10 milioni di record sono piuttosto piccoli nel mondo dei moderni rdbms, quindi quello che stai vedendo è il prodotto di una pianificazione insufficiente o di un fraintendimento dei database.


0
2018-01-16 23:49