Database

Dove un sito è veloce o lento: nel suo database.

Installiamo, ottimizziamo, replichiamo e salviamo il database dietro la vostra applicazione, e dimostriamo che i backup funzionano ripristinandoli.

Richiedi un preventivo Vedi i piani di hosting

Sette motori, disegnati come un unico schema

Ogni riquadro è un database che installiamo, ottimizziamo e salviamo. Le linee mostrano come lavorano insieme nei sistemi che gestiamo - la maggior parte delle applicazioni ne usa due o tre, non uno.

SQLiteincorporato
Uso
App e strumenti con un solo file di dati e un solo scrittore alla volta
Regoliamo
journal_mode=WAL
Backup
Una copia a caldo del file, mai la copia di un file in uso
MySQLrelazionale
Uso
Negozi, WordPress e la maggior parte delle applicazioni PHP
Regoliamo
innodb_buffer_pool_size
Backup
Backup completi più log binari, a qualsiasi istante
Perché usiamo MySQL
Redisin memoria
Uso
Cache, sessioni, code e contatori
Regoliamo
maxmemory-policy
Backup
Snapshot e un file append-only
PostgreSQLrelazionale
Uso
Contabilità, ERP, report e query complesse
Regoliamo
shared_buffers · work_mem
Backup
Backup di base più WAL archiviato, a qualsiasi istante
MariaDBrelazionale
Uso
Gli stessi usi di MySQL, più i cluster Galera
Regoliamo
innodb_buffer_pool_size
Backup
mariabackup più log binari, a qualsiasi istante
OpenSearch · Elasticsearchricerca
Uso
Ricerca tra prodotti e articoli, filtri, log
Regoliamo
JVM heap · shards
Backup
Snapshot; l'indice si può ricostruire dal database principale
MongoDBdocumenti
Uso
Record dalla forma sempre diversa: eventi, cataloghi, contenuti
Regoliamo
wiredTiger cacheSizeGB
Backup
Un replica set, con l'oplog per un istante preciso
  1. Quando un'app non sta più in un solo file, passa a un server di database.
  2. MariaDB è nato come fork di MySQL; la maggior parte delle applicazioni passa dall'uno all'altro senza modifiche.
  3. Redis sta davanti: le risposte ripetute e le sessioni restano in memoria.
  4. La stessa cache davanti alle applicazioni PostgreSQL.
  5. L'indice di ricerca è alimentato dal database principale, mai il contrario.
  6. Il JSONB di PostgreSQL copre molti usi documentali prima che serva MongoDB.

Quale database per quale lavoro

Di solito decide l'applicazione, e noi la seguiamo. Dove la scelta è aperta, ecco come scegliamo.

Il lavoro La nostra prima scelta Va bene anche Perché
Un negozio, un sito WordPress o un'applicazione PHP MySQL · MariaDB PostgreSQL Ciò su cui l'applicazione è stata costruita e testata, con il supporto più ampio.
Contabilità, ERP e report con molte join PostgreSQL MySQL 8 Transazioni rigorose, funzioni finestra e un planner pensato per le query complesse.
Cache, sessioni, code e limiti di frequenza Redis Memcached Risposte dalla memoria. Tenete lì ciò che si può ricostruire se va perso.
Ricerca tra prodotti o articoli OpenSearch · Elasticsearch MySQL · PostgreSQL full-text Pertinenza, errori di battitura, filtri e faccette che una query LIKE non può dare. Per un piccolo catalogo basta la ricerca full-text del database stesso.
Un'app mobile, uno strumento desktop o un piccolo servizio interno SQLite —Nessun altro Nessun server da gestire: un file, salvato copiandolo in modo sicuro.
Eventi, log o record dalla forma sempre diversa MongoDB PostgreSQL JSONB Documenti flessibili; PostgreSQL quando servono anche join e transazioni.
Letture che superano un solo server MySQL · MariaDB · PostgreSQL replicas —Nessun altro Le letture si distribuiscono sulle repliche mentre le scritture restano su un solo primario.

Una query lenta, trovata e corretta

Dietro la maggior parte delle pagine lente c'è una query. Lo slow query log la indica, EXPLAIN mostra perché è lenta, e spesso un solo indice è tutta la correzione.

SELECT id, total, created_at
FROM orders
WHERE customer_id = 4821
ORDER BY created_at DESC
LIMIT 20;
Una query di esempio su una tabella di esempio

Prima

type
ALL
key
NULL
Extra
Using where; Using filesort

Legge ogni riga della tabella, poi ordina ciò che ha trovato.

La correzione: un indice

ALTER TABLE orders
  ADD INDEX idx_customer_created (customer_id, created_at);

Dopo

type
ref
key
idx_customer_created
Extra
Backward index scan

Legge solo le righe di questo cliente, già in ordine.

Un backup conta quando è stato ripristinato

Una copia notturna da sola fa perdere la giornata. Conservando anche il log delle modifiche, possiamo riportare il database al secondo prima di un errore.

Backup completo notturno00:00 Ripristinato fino a qui14:31:59 Un DELETE senza WHERE14:32:00
Ogni modifica, scritta nel log nel momento in cui avviene Rieseguito sul backup
Una giornata di esempio. Gli orari sono inventati.
  1. Ripristinare l'ultimo backup completo

    Su un server separato, così il database in produzione resta com'è mentre lavoriamo.

  2. Rieseguire il log fino all'istante prima

    I log binari per MySQL e MariaDB, il WAL archiviato per PostgreSQL, l'oplog per MongoDB.

  3. Verificarlo, poi riportare i dati

    O le righe perse vengono ricopiate, o la copia ripristinata prende il posto dell'originale - la decisione è vostra, con la differenza davanti agli occhi.

Il ripristino a un istante preciso dipende dal motore:

  • MySQL · MariaDB · PostgreSQL · MongoDBa qualsiasi secondo coperto dal log
  • Redisfino all'ultima scrittura del file append-only
  • SQLitefino all'ultima copia del file
  • OpenSearch · Elasticsearchfino all'ultimo snapshot, poi ricostruito dalla fonte

I test di ripristino fanno parte della cura che concordiamo con voi: su un server separato, con un calendario fisso, ogni risultato messo per iscritto. Un backup che nessuno ha ripristinato è una speranza, non un backup.

Il resto del lavoro

Ciò di cui un database ha bisogno dal giorno dell'installazione al giorno dell'aggiornamento, e le impostazioni che ogni passo tocca.

  • Installazione e dimensionamento

    La versione supportata dalla vostra applicazione, dal repository ufficiale del produttore. La memoria viene divisa tra database, applicazione e sistema prima di impostare qualsiasi altra cosa.

    innodb_buffer_pool_size · shared_buffers · maxmemory · -Xmx
  • Indici e query lente

    Lo slow query log viene letto, le query peggiori spiegate, e gli indici aggiunti o rimossi annotandone il motivo.

    slow_query_log · pg_stat_statements · EXPLAIN ANALYZE
  • Replica

    Una seconda copia che segue la prima, per distribuire le letture e subentrare quando il primario cade.

    GTID · Galera · streaming replication · replica set
  • Sicurezza

    In ascolto solo sulla rete privata, un utente per applicazione con i soli permessi necessari, e connessioni cifrate ovunque il traffico lasci il server.

    bind-address · TLS · GRANT · SCRAM · ACL
  • Monitoraggio

    Connessioni, ritardo di replica, spazio su disco e query lente, con un avviso prima che un limite venga raggiunto, non dopo.

    max_connections · Seconds_Behind_Source · pg_stat_replication
  • Aggiornamenti

    Provati prima su una copia, le repliche prima del primario, e la via del ritorno scritta prima di iniziare.

    pg_upgrade · mariadb-upgrade · rolling restart

Diteci cosa sta facendo il vostro database

Quale motore, quanto è grande, dove gira e cosa vi preoccupa. Prima guardiamo, poi prepariamo il preventivo per la messa in opera o la cura dopo una conversazione.

Richiedi un preventivo Vedi i piani di hosting