Bases de datos

Donde un sitio es rápido o lento: en su base de datos.

Instalamos, optimizamos, replicamos y respaldamos la base de datos de su aplicación, y demostramos que las copias sirven restaurándolas.

Pedir presupuesto Ver planes de hosting

Funciona con y creado con

MySQL
MariaDB
PostgreSQL
Redis
MongoDB
Elasticsearch

Siete motores, dibujados como un solo esquema

Cada caja es una base de datos que instalamos, optimizamos y respaldamos. Las líneas muestran cómo trabajan juntas en los sistemas que gestionamos: la mayoría de las aplicaciones necesitan dos o tres, no una.

SQLiteembebida

Uso: Aplicaciones y herramientas con un solo archivo de datos y un solo escritor a la vez
Ajustamos: journal_mode=WAL
Copias: Una copia en caliente del archivo, nunca la copia de un archivo en uso

MySQLrelacional

Uso: Tiendas, WordPress y la mayoría de las aplicaciones PHP
Ajustamos: innodb_buffer_pool_size
Copias: Copias completas más logs binarios, a cualquier momento

Por qué usamos MySQL

Redisen memoria

Uso: Caché, sesiones, colas y contadores
Ajustamos: maxmemory-policy
Copias: Instantáneas y un archivo append-only

PostgreSQLrelacional

Uso: Contabilidad, ERP, informes y consultas complejas
Ajustamos: shared_buffers · work_mem
Copias: Copias base más WAL archivado, a cualquier momento

MariaDBrelacional

Uso: Los mismos usos que MySQL, y clústeres Galera
Ajustamos: innodb_buffer_pool_size
Copias: mariabackup más logs binarios, a cualquier momento

OpenSearch · Elasticsearchbúsqueda

Uso: Búsqueda en productos y artículos, filtros, logs
Ajustamos: JVM heap · shards
Copias: Instantáneas; el índice puede reconstruirse desde la base de datos principal

MongoDBdocumentos

Uso: Registros cuya forma cambia: eventos, catálogos, contenidos
Ajustamos: wiredTiger cacheSizeGB
Copias: Un replica set, con el oplog para un momento concreto

Cuando una aplicación se queda grande para un archivo, pasa a un servidor de base de datos.
MariaDB nació como un fork de MySQL; la mayoría de las aplicaciones pasan de una a otra sin cambios.
Redis se sitúa delante: las respuestas repetidas y las sesiones se quedan en memoria.
La misma caché delante de las aplicaciones PostgreSQL.
El índice de búsqueda se alimenta de la base de datos principal, nunca al revés.
El JSONB de PostgreSQL cubre muchos usos de documentos antes de necesitar MongoDB.

Qué base de datos para cada trabajo

Normalmente decide la aplicación, y la seguimos. Cuando la elección está abierta, así es como elegimos.

El trabajo	Nuestra primera opción	También sirve	Por qué
Una tienda, un sitio WordPress o una aplicación PHP	MySQL · MariaDB	PostgreSQL	Aquello sobre lo que se construyó y probó la aplicación, con el soporte más amplio.
Contabilidad, ERP e informes con muchas uniones	PostgreSQL	MySQL 8	Transacciones estrictas, funciones de ventana y un planificador hecho para consultas complejas.
Caché, sesiones, colas y límites de peticiones	Redis	Memcached	Respuestas desde memoria. Guarde ahí lo que pueda reconstruirse si se pierde.
Búsqueda en productos o artículos	OpenSearch · Elasticsearch	MySQL · PostgreSQL full-text	Relevancia, errores de escritura, filtros y facetas que una consulta LIKE no puede dar. Para un catálogo pequeño basta con la búsqueda de texto completo de la propia base de datos.
Una app móvil, una herramienta de escritorio o un pequeño servicio interno	SQLite	—Ninguna otra	Sin servidor que mantener: un archivo, respaldado copiándolo de forma segura.
Eventos, logs o registros cuya forma cambia	MongoDB	PostgreSQL JSONB	Documentos flexibles; PostgreSQL cuando además necesitan uniones y transacciones.
Lecturas que superan a un solo servidor	MySQL · MariaDB · PostgreSQL replicas	—Ninguna otra	Las lecturas se reparten entre réplicas y las escrituras se quedan en un único principal.

Cinco motores, uno al lado del otro

Lo que cada motor hace por sí mismo, según su propia documentación. La palabra junto a cada marca indica hasta dónde llega.

Comparación de MySQL, MariaDB, PostgreSQL, Redis y MongoDB
Capacidad	MySQL	MariaDB	PostgreSQL	Redis	MongoDB
Uso	Tiendas, WordPress y la mayoría de las aplicaciones PHP	Los mismos usos que MySQL, y clústeres Galera	Contabilidad, ERP, informes y consultas complejas	Caché, sesiones, colas y contadores	Registros cuya forma cambia: eventos, catálogos, contenidos
Modelo de datos	Tablas y filas, consultadas con SQL.	Tablas y filas, consultadas con SQL.	Tablas y filas, consultadas con SQL, con un tipo JSONB para documentos.	Claves que guardan cadenas, hashes, listas, conjuntos, conjuntos ordenados o streams.	Documentos tipo JSON en colecciones, con el lenguaje de consulta propio de MongoDB.
Transacciones	Compatible InnoDB, el motor por defecto: commit, rollback y recuperación tras un fallo.	Compatible InnoDB también es el motor por defecto aquí.	Compatible Cada cambio es una transacción que se confirma o se revierte.	En parte Un bloque de comandos se ejecuta uno tras otro sin interrupción, pero no hay rollback.	Compatible Entre varios documentos, en conjuntos de réplicas y clústeres con sharding.
Dónde viven los datos de trabajo	En disco; InnoDB mantiene en memoria un buffer pool con los datos más usados.	En disco; InnoDB mantiene en memoria un buffer pool con los datos más usados.	En disco; los shared buffers mantienen en memoria los datos más usados.	En memoria; instantáneas y un archivo de solo adición lo escriben en disco.	En disco; WiredTiger mantiene en memoria una caché con los datos más usados.
Replicación integrada	Compatible De la fuente a las réplicas, asíncrona o semisíncrona.	Compatible De la fuente a las réplicas, y Galera Cluster para multiprimario síncrono.	Compatible Replicación en streaming; las réplicas hot standby pueden responder consultas de lectura.	Compatible Del líder a las réplicas, asíncrona por defecto; las réplicas pueden atender lecturas.	Compatible Conjuntos de réplicas: varios servidores con los mismos datos y conmutación por error automática.
Repartir los datos entre varios servidores	Complemento NDB Cluster, un motor aparte que particiona los datos automáticamente.	Complemento El motor de almacenamiento Spider, que reparte las tablas entre varios servidores MariaDB (sharding).	En parte El particionado por rango, lista o hash divide una tabla dentro de un solo servidor.	Compatible Redis Cluster reparte las claves entre nodos.	Compatible El sharding está integrado, por colección.
Restauración a un instante	Compatible a cualquier segundo que cubra el registro	Compatible a cualquier segundo que cubra el registro	Compatible a cualquier segundo que cubra el registro	En parte hasta la última escritura del archivo append-only	Compatible a cualquier segundo que cubra el registro

Desplácese hacia el lado para ver los cinco motores.

Compatible el motor lo hace por sí mismo
En parte con una salvedad
Complemento un componente o motor aparte

Las funciones varían según la versión, y la documentación de la versión que usa tiene la última palabra.

Fuentes: MySQL Reference Manual MariaDB Knowledge Base PostgreSQL Documentation Redis Documentation MongoDB Manual

Por qué usamos MySQL

Cinco capas donde una base de datos se vuelve más rápida

Una base de datos lenta rara vez se arregla en un solo sitio. Estas son las capas, en el orden en que suelen revisarse: primero el cambio más barato, al final el más caro.

Los números indican el orden habitual de trabajo.

Consultas
El registro de consultas lentas nombra las peores consultas, y EXPLAIN muestra por qué cada una es lenta.
slow_query_log · pg_stat_statements · EXPLAIN ANALYZE
Esquema e índices
Una tabla pensada para las preguntas que responde, y el índice adecuado, convierten la lectura de cada fila en una búsqueda corta: el ejemplo de más abajo es un índice haciendo justo eso.
CREATE INDEX · ADD INDEX
Ajustes del motor
La memoria se reparte entre la base de datos, la aplicación y el sistema, y después los búferes de cada motor se ajustan a ese reparto.
innodb_buffer_pool_size · shared_buffers · work_mem · wiredTiger cacheSizeGB
Caché
Las respuestas repetidas y las sesiones se quedan en memoria, así que se consulta menos a la base de datos.
maxmemory-policy
Hardware
Más memoria, discos más rápidos o más núcleos de procesador, una vez agotadas las capas de arriba.
RAM · CPU · disk I/O

Ajustar también la parte de PHP

Una consulta lenta, encontrada y corregida

Detrás de la mayoría de las páginas lentas hay una consulta. El registro de consultas lentas la señala, EXPLAIN muestra por qué es lenta y, a menudo, un solo índice es toda la solución.

SELECT id, total, created_at
FROM orders
WHERE customer_id = 4821
ORDER BY created_at DESC
LIMIT 20;

Una consulta de ejemplo sobre una tabla de ejemplo

Antes

type: ALL
key: NULL
Extra: Using where; Using filesort

Lee todas las filas de la tabla y luego ordena lo que encontró.

La solución: un índice

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

Después

type: ref
key: idx_customer_created
Extra: Backward index scan

Lee solo las filas de este cliente, ya ordenadas.

Una copia cuenta cuando se ha restaurado

Una copia nocturna por sí sola pierde el día. Guardando también el registro de cambios, podemos devolver la base de datos al segundo anterior a un error.

Copia completa nocturna00:00 Restaurada hasta aquí14:31:59 Un DELETE sin WHERE14:32:00

Cada cambio, escrito en el registro en el momento en que ocurre Reproducido sobre la copia

Un día de ejemplo. Las horas son inventadas.

Restaurar la última copia completa
En un servidor aparte, para que la base de datos en producción quede intacta mientras trabajamos.
Reproducir el registro hasta el momento anterior
Los logs binarios en MySQL y MariaDB, el WAL archivado en PostgreSQL, el oplog en MongoDB.
Comprobarla y recuperar los datos
O se vuelven a copiar las filas perdidas, o la copia restaurada toma el relevo: usted decide, con la diferencia delante.

La recuperación a un momento concreto depende del motor:

MySQL · MariaDB · PostgreSQL · MongoDBa cualquier segundo que cubra el registro
Redishasta la última escritura del archivo append-only
SQLitehasta la última copia del archivo
OpenSearch · Elasticsearchhasta la última instantánea, y luego se reconstruye desde el origen

Las pruebas de restauración forman parte del cuidado que acordamos con usted: en un servidor aparte, con un calendario fijo y cada resultado anotado. Una copia que nadie ha restaurado es una esperanza, no una copia.

El resto del trabajo

Lo que necesita una base de datos desde el día en que se instala hasta el día en que se actualiza, y los ajustes que toca cada paso.

Instalación y dimensionamiento
La versión que admite su aplicación, desde el repositorio oficial del fabricante. La memoria se reparte entre la base de datos, la aplicación y el sistema antes de ajustar nada más.
innodb_buffer_pool_size · shared_buffers · maxmemory · -Xmx
Índices y consultas lentas
Se lee el registro de consultas lentas, se explican las peores consultas y se añaden o quitan índices dejando anotado el motivo.
slow_query_log · pg_stat_statements · EXPLAIN ANALYZE
Replicación
Una segunda copia que sigue a la primera, para repartir las lecturas y tomar el relevo si falla el servidor principal.
GTID · Galera · streaming replication · replica set
Seguridad
Escucha solo en la red privada, un usuario por aplicación con solo los permisos que necesita y conexiones cifradas siempre que el tráfico salga del servidor.
bind-address · TLS · GRANT · SCRAM · ACL
Supervisión
Conexiones, retraso de replicación, espacio en disco y consultas lentas, con una alerta antes de llegar a un límite y no después.
max_connections · Seconds_Behind_Source · pg_stat_replication
Actualizaciones
Ensayadas primero en una copia, las réplicas antes que el principal y el camino de vuelta escrito antes de empezar.
pg_upgrade · mariadb-upgrade · rolling restart

Cuéntenos qué hace su base de datos

Qué motor, qué tamaño, dónde se ejecuta y qué le preocupa. Primero lo revisamos y después presupuestamos la puesta en marcha o el cuidado tras una conversación.

Pedir presupuesto Ver planes de hosting

Servicios relacionados

Velocidad PHP OPcache, pools de PHP-FPM, cachés y consultas: dónde se van los milisegundos y cómo los recuperamos.Servicio gestionado Gestionamos el servidor por ti: parches, monitorización, copias, incidencias.Servidores dedicados Una máquina entera, aprovisionada en horas, gestionada por el mismo equipo.Laravel Aplicaciones en Laravel con colas, tareas programadas y despliegues que no tiran el sitio.