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

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
  1. Cuando una aplicación se queda grande para un archivo, pasa a un servidor de base de datos.
  2. MariaDB nació como un fork de MySQL; la mayoría de las aplicaciones pasan de una a otra sin cambios.
  3. Redis se sitúa delante: las respuestas repetidas y las sesiones se quedan en memoria.
  4. La misma caché delante de las aplicaciones PostgreSQL.
  5. El índice de búsqueda se alimenta de la base de datos principal, nunca al revés.
  6. 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.

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.
  1. Restaurar la última copia completa

    En un servidor aparte, para que la base de datos en producción quede intacta mientras trabajamos.

  2. Reproducir el registro hasta el momento anterior

    Los logs binarios en MySQL y MariaDB, el WAL archivado en PostgreSQL, el oplog en MongoDB.

  3. 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