Metodo preferito per viste materializzate (tabelle di riepilogo) con MySQL

Question

Sto sviluppando un progetto sul lavoro per il quale ho bisogno di creare e mantenere Tabelle di riepilogo per motivi di prestazioni. Credo che il termine corretto per questo è Viste materializzate.

ho 2 motivi principali per farlo:

1. Denormalizzazione

   Ho normalizzato i tavoli, per quanto possibile. Quindi ci sono situazioni in cui dovrei unire molte tabelle per estrarre dati. Lavoriamo con MySQL Cluster, che ha prestazioni piuttosto scarse quando si tratta di JOIN.

   Quindi ho bisogno di creare tabelle denormalizzate in grado di eseguire SELECT più veloci.

2. riepilogare i dati

   Per esempio, ho una tabella transazioni con un paio di milioni di dischi. Le transazioni provengono da diversi siti Web. L'applicazione deve generare un report per visualizzare i conteggi delle transazioni giornaliere o mensili e gli importi totali delle entrate per sito Web. Non voglio che lo script del report lo calcoli ogni volta, quindi ho bisogno di generare una tabella di riepilogo che presenterà una suddivisione per [sito, data].

   Questo è solo un semplice esempio. Ci sono molti diversi tipi di tabelle riassuntive che ho bisogno di generare e mantenere.

In passato ho eseguito queste operazioni scrivendo diversi script di cron per mantenere aggiornata ogni tabella di riepilogo. Ma in questo nuovo progetto, spero di implementare una soluzione più elegante e corretta.

Preferirei una soluzione basata su PHP, poiché non sono un amministratore di server e mi sento il più comodo quando posso controllare tutto tramite il mio codice applicazione.

---

Soluzioni che ho considerato:

1. copia del VISTA

   Se la tabella risultante può essere rappresentato come una singola query SELECT, posso generare una VISTA . Dal momento che sono lenti, ci può essere un cronjob che copia questa VISTA in una tabella reale.

   Tuttavia, alcune di queste query SELECT possono essere così lente che non è accettabile nemmeno per i cronjob. Non è molto efficiente ricreare tutti i dati di riepilogo, se le righe più vecchie non vengono nemmeno aggiornate molto.

2. Cronjobs personalizzate per ogni tabella Riassunto

   Questa è la soluzione che ho usato prima, ma ora sto cercando di evitare, se possibile. Se ci saranno molte tabelle riassuntive, può essere difficile da mantenere.

3. MySQL Trigger

   E 'possibile aggiungere trigger alle tabelle principali in modo che ogni volta che c'è un INSERT, UPDATE o DELETE, le tabelle riassuntive vengono aggiornati di conseguenza.

   Non ci sarebbero cronjobs e i riassunti sarebbero in tempo reale. Tuttavia, se è mai necessario ricostruire una tabella di riepilogo da zero, dovrebbe essere eseguita con un'altra soluzione (probabilmente la # 1 sopra).

4. Utilizzando ORM Ganci/Trigger

   Sto usando Doctrine come la mia ORM. C'è un modo per aggiungere listener di eventi che attiveranno roba su INSERT/UPDATE/DELETE, che a sua volta può aggiornare le tabelle di riepilogo. In un certo senso questa soluzione è simile alla # 3 sopra, ma avrò un controllo migliore su questi trigger poiché saranno implementati in PHP.

---

Considerazioni di attuazione:

1. completo ricostruisce

   voglio evitare di dover ricostruire le tabelle di sintesi, per l'efficienza, e solo aggiornamento per nuovi dati Ma nel caso qualcosa vada storto, ho bisogno della capacità di ricostruire la tabella di riepilogo da zero usando i dati esistenti sulle tabelle principali.

2. Ignorando UPDATE/DELETE su dati vecchi

   Alcuni riepiloghi possono assumere che le registrazioni più vecchie non saranno mai aggiornati o cancellati, ma verranno inseriti solo i nuovi record. Il processo di riepilogo può far risparmiare parecchio lavoro ipotizzando che non sia necessario verificare la disponibilità di aggiornamenti su dati meno recenti.

   Ma ovviamente questo non si applica a tutti i tavoli.

3. tenere un registro

   Supponiamo che io non avere accesso, o non vogliono utilizzare i registri MySQL binari.

   Per riepilogare i nuovi dati, il processo di riepilogo deve solo ricordare gli ultimi ID della chiave primaria per gli ultimi record riepilogati. La prossima volta che viene eseguito, può riepilogare ogni cosa dopo quell'ID. Tuttavia, per tenere traccia dei vecchi record che sono stati aggiornati/cancellati, ha bisogno di un altro registro in modo che possa tornare indietro e riassumere questi dati.

---

Gradirei qualsiasi tipo di strategie, suggerimenti o link che possono aiutare. Grazie!

Answer 1

Come già osservato, le visualizzazioni materializzate in Oracle sono diverse da quelle indicizzate in SQL Server. Sono molto interessanti e utili.Vedi http://download.oracle.com/docs/cd/B10500_01/server.920/a96567/repmview.htm per dettagli

MySql non ha tuttavia supporto per questi.

Una cosa che citi più volte è scarse prestazioni. Hai controllato la progettazione del tuo database per indicizzare correttamente ed esegui spiegazioni sui piani per vedere perché sono lenti. Vedi qui http://dev.mysql.com/doc/refman/5.1/en/using-explain.html. Questo è naturalmente presupponendo che il tuo server sia sintonizzato correttamente, hai mysql setup e tuned, ad es. cache buffer, ecc. ecc.

Alla domanda diretta. Quello che sembra che tu voglia fare è qualcosa che facciamo spesso in una situazione di data warehouse. Disponiamo di un database di produzione e di un DW che raccolgono tutti i tipi di informazioni, aggregati e precaricabili per velocizzare le query. Questo potrebbe essere eccessivo per te ma puoi decidere. A seconda della latenza definita per i report, ovvero della frequenza con cui sono necessari, di solito viene eseguito periodicamente un processo ETL (extract transform load) (giornaliero, settimanale, ecc.) Per popolare il DW dal sistema di produzione. Ciò mantiene un impatto basso sul sistema di produzione e sposta tutti i report su un altro set di server che riduce anche il carico. Dal punto di vista DW, normalmente progetterei i miei schemi in modo diverso, cioè utilizzando gli schemi a stella. (http://www.orafaq.com/node/2286) Gli schemi di stelle hanno tabelle dei fatti (cose che vuoi misurare) e dimensioni (cose che vuoi aggregare le misure per (tempo, geografia, categorie di prodotti, ecc.) SQL Server include anche un motore aggiuntivo chiamato SQL Server Analysis Services (SSAS) per esaminare tabelle e dimensioni dei fatti, pre calcolare e creare cubi di dati OLAP In questi cubi di dati è possibile eseguire il drill down e osservare tutti i tipi di pattern, fare i dati analisi e data mining Oracle fa le cose in modo leggermente diverso ma il risultato è lo stesso

Se si desidera percorrere la rotta di circa dipende molto dalle esigenze aziendali e dal valore che si ottiene dall'analisi dei dati. Come ho detto è probabilmente eccessivo se hai solo alcune tabelle riassuntive ma alcuni dei concetti che potresti trovare utili nel pensare le cose. Se la tua azienda sta andando verso un business intelligence ution allora questo è qualcosa da considerare.

PS In realtà è possibile impostare un DW fino a lavorare in "tempo reale" utilizzando qualcosa chiamato ROLAP se questa è l'esigenza aziendale. Microstrategy ha un buon prodotto che funziona bene per questo.

PPS Si potrebbe anche voler guardare PowerPivot da MS (http://www.powerpivot.com/learn.aspx) Ho solo giocato con esso in modo da non poter dire come funziona su set di dati molto grandi.

Answer 2

Flexviews (http://flexvie.ws) è un progetto basato su PHP/MySQL open source. Flexviews aggiunge viste materializzate di aggiornamento incrementale (come le viste materializzate in Oracle) a MySQL, utilizzando PHP e stored procedure.

Include FlexCDC, un'utilità di modifica dei dati basata su PHP che legge i registri binari e le stored procedure MySQL di Flexviews utilizzate per definire e gestire le visualizzazioni.

Flexviews supporta i join (solo inner join) e l'aggregazione in modo che possa essere utilizzato per creare tabelle di riepilogo. Inoltre, è possibile utilizzare Flexviews in combinazione con il progettatore di aggregazioni di Mondrian (un server ROLAP) per creare tabelle di riepilogo che lo strumento ROLAP può utilizzare automaticamente.

Se non si dispone di accesso ai registri (può leggerli in remoto, btw, quindi non è necessario l'accesso al server, ma è necessario SUPER Privs), quindi è possibile utilizzare 'COMPLETA' aggiornare con Flexviews. Questo automatizza la creazione di una nuova tabella con 'CREATE TABLE ... AS SELECT' sotto un nuovo nome di tabella. Quindi usa RENAME TABLE per scambiare la nuova tabella con quella, rinominando la vecchia con un postfisso _old. Alla fine cade il vecchio tavolo. Il vantaggio qui è che l'SQL per creare la vista è memorizzato nel database (flexviews.mview) e può essere aggiornato con una semplice chiamata API che automatizza il processo di swapping.