Administración de bases de datos grandes en servidores virtuales

Por qué las bases de datos grandes se comportan distinto en un VPS

Un servidor privado virtual te da una porción de una máquina física: un número fijo de CPU virtuales, una cantidad fija de RAM y un disco que a menudo está conectado por red o compartido con otros clientes. Las bases de datos pequeñas apenas notan estos límites. Cuando una base crece hasta decenas o cientos de gigabytes, o atiende muchas consultas simultáneas, las restricciones del entorno virtual empiezan a dominar el rendimiento.

La buena noticia es que la mayoría de problemas siguen patrones previsibles. Esta guía explica cómo dimensionar un VPS para una base de datos, qué parámetros ajustar primero, cómo gestionar el almacenamiento y las copias de seguridad y cuándo toca escalar más allá de un único servidor. Los ejemplos usan MySQL/MariaDB y PostgreSQL, los dos motores más habituales en planes VPS.

Dimensionar el servidor: RAM, CPU y disco

No existe una fórmula universal, pero la relación entre tus datos y tus recursos dice mucho.

Memoria

Las bases de datos guardan datos e índices en caché en memoria. Cuando el “conjunto de trabajo” (los datos que realmente se leen con frecuencia) cabe en la RAM, la mayoría de consultas evitan por completo el disco. Cuando no cabe, cada fallo de caché se convierte en una lectura de disco y el rendimiento puede caer en picado. No necesitas tanta RAM como el tamaño total de la base; necesitas la suficiente para los datos calientes más margen para conexiones, ordenaciones y el sistema operativo.

CPU

La CPU importa en consultas complejas, con muchas conexiones concurrentes y con compresión. En hosts virtuales compartidos, comprueba si tu plan ofrece vCPU dedicadas o compartidas; los núcleos compartidos pueden limitarse cuando los vecinos están ocupados, y eso se nota en tiempos de consulta irregulares.

Disco

Las cargas de bases de datos están dominadas por lecturas y escrituras aleatorias pequeñas, así que la latencia y las IOPS importan mucho más que el rendimiento secuencial. El almacenamiento SSD o NVMe es prácticamente obligatorio para bases grandes. Nuestro artículo sobre los SSD en el rendimiento del hosting explica por qué.

Ajustar los parámetros clave

Las configuraciones por defecto son deliberadamente conservadoras para que funcionen en máquinas diminutas. Un puñado de parámetros aporta la mayor parte del beneficio en un servidor más grande. Cambia una cosa cada vez y mide el resultado.

MySQL y MariaDB (InnoDB)

• innodb_buffer_pool_size: la caché principal de datos e índices. En un servidor dedicado a la base de datos, un punto de partida habitual es entre la mitad y tres cuartas partes de la RAM, dejando margen para el sistema y las conexiones.
• innodb_log_file_size (o innodb_redo_log_capacity en versiones recientes de MySQL): unos redo logs más grandes suavizan las cargas con muchas escrituras.
• max_connections: mantenlo en un valor realista; cada conexión consume memoria.

[mysqld]
innodb_buffer_pool_size = 12G
innodb_redo_log_capacity = 2G
max_connections = 200
slow_query_log = 1
long_query_time = 1

PostgreSQL

• shared_buffers: PostgreSQL también se apoya en la caché de páginas del sistema operativo, por lo que a menudo se fija en torno a una cuarta parte de la RAM como punto de partida.
• effective_cache_size: una pista para el planificador que indica cuánta memoria hay disponible para caché en total.
• work_mem: memoria por operación de ordenación o hash, que puede usarse varias veces por consulta, así que súbela con prudencia.

shared_buffers = 4GB
effective_cache_size = 12GB
work_mem = 32MB
maintenance_work_mem = 1GB
log_min_duration_statement = 1000

Estos valores de ejemplo suponen un servidor con unos 16 GB de RAM dedicados a la base de datos. Son ilustraciones, no recomendaciones para tu carga; consulta la documentación de tu versión del motor, porque los nombres y valores por defecto cambian entre versiones.

Índices, consultas y esquema

El hardware y el ajuste solo llegan hasta cierto punto. En conjuntos de datos grandes, un solo índice que falte puede convertir una consulta de milisegundos en un recorrido completo de tabla que lee gigabytes. Convierte estos hábitos en rutina:

• Activa el log de consultas lentas y revísalo con regularidad.
• Usa EXPLAIN (o EXPLAIN ANALYZE en PostgreSQL) para ver cómo se ejecutan realmente las consultas.
• Indexa las columnas usadas con frecuencia en cláusulas WHERE, JOIN y ORDER BY, pero no lo indexes todo: cada índice ralentiza las escrituras y ocupa espacio.
• Archiva o particiona los datos antiguos. El particionado por fechas permite eliminar meses antiguos de forma barata en lugar de lanzar borrados enormes.
• En PostgreSQL, asegúrate de que autovacuum da abasto; el bloat en tablas grandes y muy actualizadas degrada el rendimiento con el tiempo.

Cambios de esquema en tablas grandes

Añadir una columna o un índice a una tabla con cientos de millones de filas puede bloquearla o tardar horas. Comprueba si tu versión del motor admite cambios de esquema online o instantáneos para la operación que necesitas, prueba el cambio antes en una copia de los datos de producción y prográmalo para un momento tranquilo. En MySQL se usan mucho herramientas de cambio de esquema online para esto; en PostgreSQL, CREATE INDEX CONCURRENTLY evita bloquear las escrituras mientras se crea un índice.

Organización del almacenamiento y gestión del disco

Las bases de datos grandes llenan los discos más rápido de lo esperado, sobre todo si cuentas los binary logs, los WAL, los archivos temporales y las copias locales. Quedarse sin espacio puede detener la base de datos y, en el peor caso, poner en riesgo su integridad.

• Volúmenes separados para datos y copias de seguridad facilitan el redimensionado y evitan que las copias llenen el disco de datos.
• Define la retención de logs para los binary logs de MySQL y vigila el crecimiento del WAL de PostgreSQL, especialmente si usas replication slots.
• Configura alertas de espacio libre mucho antes de que se agote, por ejemplo al 80 % y al 90 % de uso.
• Conoce los límites de tu proveedor. Algunos planes VPS limitan las IOPS o el rendimiento por volumen; volúmenes mayores o planes superiores pueden elevar esos límites.

df -h
iostat -x 5
du -sh /var/lib/mysql /var/lib/postgresql

Copias de seguridad y recuperación

En una base de datos grande, la estrategia de copias es tan importante como el rendimiento. Un plan debe responder a dos preguntas: cuántos datos te puedes permitir perder y cuánto tiempo te puedes permitir estar caído.

Copias lógicas

Herramientas como mysqldump o pg_dump exportan los datos como SQL o archivos comprimidos. Son portables y sencillas, pero se vuelven lentas de generar, y sobre todo de restaurar, a medida que crece la base.

Copias físicas

Herramientas como Percona XtraBackup o MariaDB Backup para la familia MySQL, y pg_basebackup para PostgreSQL, copian directamente los archivos de datos. Combinadas con binary logs o con el archivado del WAL, permiten la recuperación a un momento concreto (point-in-time recovery).

Snapshots

Los snapshots de disco del proveedor son cómodos, pero un snapshot de una base de datos en ejecución solo es seguro si el motor puede recuperarse de él de forma consistente. Revisa las indicaciones de tu proveedor y prueba restauraciones antes de confiar en ellos.

pg_dump -Fc -d appdb -f /backup/appdb.dump
mysqldump --single-transaction --routines appdb | gzip > /backup/appdb.sql.gz

Uses el método que uses, guarda copias fuera del servidor, a ser posible con otro proveedor o en otra región, y programa pruebas de restauración periódicas. Una copia que nunca has restaurado es una suposición, no un plan.

Monitorización y mantenimiento

Observa tendencias, no momentos aislados. Métricas útiles son el ratio de aciertos de caché, las consultas por segundo, las consultas lentas, el retraso de replicación, las conexiones en uso, el espacio en disco, el I/O wait y la presión de memoria. Muchas plataformas de monitorización traen paneles de bases de datos listos para usar; incluso unos scripts sencillos que avisen del espacio en disco y del estado de la replicación evitan las caídas más comunes.

No olvides la infraestructura que rodea a la base de datos. Un plan VPS caducado, una factura sin pagar o un dominio vencido pueden dejar una aplicación fuera de línea igual que una base de datos caída. TLDix te permite seguir juntas las renovaciones de hosting y dominios en el panel de hosting, para que las fechas de renovación de los servidores que alojan tus bases no dependan de la memoria.

Cuándo escalar más allá de un VPS

Un único servidor bien ajustado aguanta mucho, pero hay señales de que se te ha quedado pequeño: un conjunto de trabajo que ya no cabe en el plan más grande que puedes pagar, una CPU saturada de forma constante tras optimizar las consultas o tiempos de copia y restauración que superan tus objetivos de recuperación.

Siguientes pasos habituales, más o menos por orden de complejidad:

1. Escalado vertical: pasar a un plan mayor con más RAM y almacenamiento más rápido.
2. Réplicas de lectura: enviar los informes y el tráfico de lectura intensiva a una o varias réplicas.
3. Pool de conexiones: herramientas como PgBouncer o ProxySQL reducen el coste de muchas conexiones de corta duración.
4. Capa de caché: guardar los resultados de consultas frecuentes en una caché en memoria.
5. Servicios de base de datos gestionados o sharding para cargas que de verdad superan una máquina.

Si vas a elegir un nuevo proveedor para la siguiente etapa, nuestra guía para elegir el mejor hosting web recoge las preguntas que conviene hacer sobre almacenamiento, soporte y opciones de ampliación.