Best practice per denormalizzare dati da DB relazionali a non relazionali

Question

Sto eseguendo un sito Web che sta iniziando a crescere oltre la semplice prestazione e Tunning. È un'app PHP con MySQL come backend. MySQL è sintonizzato correttamente e il codice è ottimizzato.

La cosa è che vedo che posso usare una sorta di denormalizzazione per accelerare le cose.

Supponiamo di avere un sito simile a eBay o Amazon. Hai prodotti nel tuo database con alcune informazioni correlate (venditore, clienti che hanno acquistato il prodotto, città, stato, ecc.). Sarebbe più tabelle in un DataBase relazionale, ed è buono per mantenere questo modo di fare buoni querys. Ad esempio, per la home page, potresti avere un unico documento denormalizzato (ad esempio in MongoDB). Potrebbe essere una collezione con gli ultimi prodotti, denormalied, simile a questo:

products = { 
    { 
     id:13, 
     name:"Some product", 
     city:"aCity", 
     state:"aState", 
     price:"10" 
    }, 
    { 
     id:123, 
     name:"another product", 
     city:"aCity", 
     state:"aState", 
     price:"10" 
    } 
} 

In questo modo, ho potuto query che insieme al posto del database MySQL (con tutte le join coinvolti) e le cose potuto ottenere veramente veloce.

Ora, ecco la domanda. Quando e come denormalizzeresti quei dati? Ad esempio, potrei decidere di denormalizzare i dati quando sono inseriti.

Quindi, nel mio "create-product.php" (semplicemente messo). Potrei fare tutto il "insert into" per mysql, e dopo potrei fare il salvataggio nella raccolta Mongo.

Oppure, potevo semplicemente eseguire un programma nel server. Oppure fai qualche cron per cercare gli ultimi prodotti.

Tutte queste sono posibilities. cosa fai? Qual è la tua esperienza?

Grazie mille.

Answer 1

Concettualmente si sta creando una sorta di cache, e si sta scontando che la sua compilazione sarà costosa in termini di tempo, quindi si desidera mantenerla persistente, sulla base del ragionevole presupposto che il caricamento dalla cache persistente sia in corso più veloce di tornare al DB reale.

Ci sono alcune variazioni sulla tua idea, la memorizzazione nella cache di pagine HTML o stringhe JSON e l'uso di una cache distribuita in memoria - non persistente ma tollerante ai guasti.

La grande domanda con tutte le soluzioni di memorizzazione nella cache è: "quanto posso permettermi stantio?". Per alcuni dati 24 ore non è molto importante. Ad esempio: I 10 libri più popolari? Le ultime recensioni, per quelle che solo alcuni aggiornamenti batch faranno. Per questioni più urgenti potrebbe essere necessario assicurarsi che ci sia un aggiornamento più rapido, ma si vuole davvero evitare di mettere troppa elaborazione extra nel mainstream. Ad esempio, sarebbe un peccato dare a un cliente un'esperienza di acquisto lenta perché è in attesa di un aggiornamento di una cache. In questi casi è possibile rilasciare un messaggio "Ecco un aggiornamento" su una coda o, in effetti, un messaggio "Il tuo ingresso nunber 23 è ormai obsoleto", lasciare che la cache lo ritiri come se fosse libero e se necessario aggiornarsi.