Qualsiasi architetto di database che progetta un database MySQL deve affrontare il problema della selezione del motore di archiviazione appropriato. Di solito, un'applicazione utilizza un solo motore:MyISAM o InnoDB . Ma cerchiamo di essere un po' più flessibili e immaginiamo come possono essere utilizzati diversi motori di archiviazione.
Il modello di dati iniziale
Per iniziare, costruiamo un modello di dati semplificato per un sistema CRM (gestione delle relazioni con i clienti) che utilizzeremo per illustrare il punto. Il design riguarderà le principali funzioni del CRM:dati di vendita, definizioni di prodotto e informazioni per l'analisi. Non conterrà dettagli generalmente utilizzati nei sistemi CRM.
Come puoi vedere, questo modello di dati ha tabelle che memorizzano informazioni transazionali chiamate sale e sale_item . Quando un cliente acquista qualcosa, l'applicazione crea una nuova riga nella sale tavolo. Ogni prodotto acquistato sarà riportato nel sale_item tavolo. Una tabella correlata, sale_status , serve per memorizzare possibili stati (ad esempio, in sospeso, completo, ecc.).
Il product la tabella memorizza le informazioni sulle merci. Definisce ogni prodotto ei suoi descrittori di base. In un diagramma più dettagliato, aggiungerei più tabelle per gestire le specifiche e la categorizzazione del prodotto. Ma per le nostre esigenze attuali, non è necessario.
La tabella dei clienti conserva i dati sui clienti. Questo è parte integrante di qualsiasi sistema CRM e di solito tiene traccia delle attività individuali di tutti gli utenti. Ovviamente, spesso contiene informazioni molto dettagliate. Ma come ho notato, non abbiamo bisogno di questi dettagli in questo momento.
Il log la tabella memorizza ciò che ogni cliente ha fatto all'interno dell'applicazione. E il report_sales la tabella è progettata per l'utilizzo dell'analisi dei dati.
Successivamente, descriverò i motori di archiviazione MySQL che potrebbero essere utilizzati in questo progetto. E più tardi, discuteremo quale motore è adatto per ogni tipo di tavolo.
Una panoramica dei motori di archiviazione MySQL
Un motore di archiviazione è un modulo software utilizzato da MySQL per creare, leggere o aggiornare i dati da un database. Non è consigliabile scegliere a caso un motore, ma molti sviluppatori sono felici di utilizzare MyISAM o InnoDB, sebbene siano disponibili anche altre opzioni. Ogni motore ha i suoi pro e contro e la corretta selezione del motore dipende da diversi fattori. Diamo un'occhiata ai motori più popolari.
- Il mioISAM ha una lunga storia con MySQL. Era il motore predefinito per i database MySQL prima della versione 5.5. MyISAM non supporta le transazioni e ha solo il blocco a livello di tabella. Viene utilizzato principalmente per applicazioni ad alta intensità di lettura.
- InnoDB è un motore di archiviazione generale che bilancia alta affidabilità e buone prestazioni. Supporta transazioni, blocco a livello di riga, ripristino di arresto anomalo e controllo della concorrenza multi-versione. Inoltre, fornisce un vincolo di integrità referenziale della chiave esterna.
- La memoria il motore memorizza tutti i dati nella RAM. Può essere utilizzato per memorizzare i riferimenti di ricerca.
- Un altro motore, CSV , conserva i dati nei file di testo con valori separati da virgole. Questo formato viene utilizzato principalmente per l'integrazione con altri sistemi.
- Unisci è una buona scelta per i sistemi di reporting, ad esempio nel data warehousing. Consente il raggruppamento logico di un insieme di tabelle MyISAM identiche, che possono anche essere referenziate come un unico oggetto.
- Archivia è ottimizzato per l'inserimento ad alta velocità. Memorizza le informazioni in tabelle compatte e non indicizzate e non supporta le transazioni. Il motore di archiviazione Archivio è l'ideale per conservare grandi quantità di dati storici o archiviati raramente referenziati.
- La Federata engine offre la possibilità di separare i server MySQL o di creare un database logico da molti server fisici. Nessun dato viene memorizzato sulle tabelle locali e le query vengono eseguite automaticamente sulle tabelle remote (federate).
- Il buco nero il motore agisce come un "buco nero" che accetta i dati ma non li archivia. Tutte le selezioni restituiscono un set di dati vuoto.
- Il motore Esempio viene utilizzato per mostrare come sviluppare nuovi motori di archiviazione.
Questo non è un elenco completo dei motori di archiviazione. MySQL 5.x ne supporta nove direttamente dalla scatola, più dozzine di altre sviluppate dalla comunità MySQL. Maggiori dettagli sui motori di archiviazione possono essere trovati nella documentazione ufficiale di MySQL.
Aggiornamento della progettazione del modello di dati
Guarda di nuovo il nostro modello di dati. Ovviamente, tabelle diverse verranno utilizzate in modi diversi. La sale la tabella deve supportare le transazioni. D'altra parte, il log e report_sales le tabelle non richiedono questa funzione. La missione principale del log table sta memorizzando i dati con la massima efficienza. Il recupero rapido è il requisito principale per il report_sales tavolo.
Teniamo presente i punti precedenti e modifichiamo il nostro schema del database. In Vertabelo, puoi impostare "Motore di archiviazione" nelle Proprietà tabella pannello. Si prega di dare un'occhiata alle immagini qui sotto.
Impostazione del motore di archiviazione
Quindi, vediamo il design aggiornato del database.
Ho specificato i motori di archiviazione per le tabelle esistenti e ho riorganizzato il report_sales tavolo. Come puoi vedere, le tabelle sono divise in tre gruppi:
- Tabelle delle transazioni, utilizzate con l'applicazione principale
- Tabelle di report per analisi BI
- Tabella di registro per la memorizzazione di tutte le attività degli utenti
Parliamo di tutti separatamente.
Tabelle delle transazioni
Queste tabelle contengono i dati inseriti dagli utenti durante le operazioni di routine quotidiane. Nel nostro caso, ci sarebbero informazioni sulla vendita, come:
- quale dipendente ha effettuato la vendita
- che ha acquistato il prodotto
- cosa è stato venduto
- quanto costa
Nella maggior parte dei casi, InnoDB è la soluzione migliore per le tabelle delle transazioni. Questo motore di archiviazione supporta il blocco delle righe e alcuni utenti sono in grado di collaborare. Allo stesso modo InnoDB consente l'uso di transazioni e chiavi esterne. Ma, come sai, questi vantaggi non sono gratuiti; il motore può eseguire istruzioni selezionate più lentamente di MyISAM e salvare i dati con meno efficacia di Archive.
Tutti i motori sopra descritti hanno alcune protezioni in atto, quindi gli sviluppatori non devono scrivere complesse funzioni di rollback per ogni operazione. In una tipica applicazione di vendita, mantenere la coerenza dei dati è più importante dei possibili problemi di prestazioni.
Tabelle dei rapporti
Nel nuovo design, ho diviso un tavolo in un paio di tavoli più piccoli. Ciò consente di risparmiare fatica quando arriva il momento di gestire i dati ed eseguire la manutenzione di tabelle e indici. Ci consente inoltre di creare la tabella MERGE sale_report per combinare altre tabelle di report. Di conseguenza, lo strumento BI recupera ancora i dati da una tabella enorme (a fini di analisi), ma abbiamo il vantaggio di lavorare con tabelle più piccole.
Il Report_sale_{year} le tabelle sono tabelle MyISAM. Questo motore di archiviazione non supporta le transazioni e può solo bloccare la tabella nel suo insieme. Poiché MyISAM non si preoccupa di questi elementi complessi, esegue rapidamente operazioni di manipolazione dei dati. Grazie alla sua struttura di file, questo motore di archiviazione legge i dati più velocemente del più popolare InnoDB.
La tabella di registro
Il motore di archiviazione archivio è una buona scelta per l'archiviazione dei dati di registro. Può inserire righe e comprimere rapidamente i dati archiviati. Ci sono grandi vantaggi per mantenere le informazioni sulle attività degli utenti. Tuttavia, l'archivio ha alcune restrizioni. Non supporta le operazioni di aggiornamento e recupera i dati lentamente. Ma in una tabella di registro, i vantaggi descritti sono più importanti degli svantaggi.
Integrazione dei motori di archiviazione
Ogni sistema deve integrarsi con la vita esterna. Per le applicazioni, possono trattarsi di utenti che popolano le tabelle di riferimento e di transazione. Può essere servizi e integrazione tramite REST, SOAP, WCF o qualcosa del genere. E, ultimo ma non meno importante, può essere l'integrazione del database.
MySQL e Oracle hanno sviluppato due motori di archiviazione davvero utili:Federato e CSV . Il primo, Federato , dovrebbe essere utilizzato per caricare i dati da un database MySQL esterno. Il secondo motore di archiviazione, CSV , consente ai database di salvare i record in formato CSV e leggere i file separati da virgole in onda, senza ulteriori sforzi.
Come puoi vedere, l'utilizzo di diversi motori di archiviazione per scopi diversi offre al tuo database una maggiore flessibilità. Se un architetto di database prende una decisione dopo aver considerato tutti i pro e i contro, il risultato può essere davvero impressionante.
Hai esperienza nell'utilizzo di diversi motori di archiviazione nella progettazione di database? Mi piacerebbe vedere i vostri consigli e suggerimenti. Si prega di condividerli nella sezione commenti.
