Servidor para bases de datos: cómo calcular memoria, disco y CPU

Primero medí cuánto pesa lo que se consulta

Todo el dimensionamiento sale de un dato: cuánto ocupan las tablas y los índices que se leen seguido. Si entran en la memoria del motor, las lecturas se resuelven sin tocar el disco; si no entran, cada consulta que no encuentra lo suyo en memoria espera al disco, y la diferencia se mide en órdenes de magnitud.

El tamaño por base sale de la primera consulta de abajo. La segunda, en MySQL y MariaDB, compara las lecturas que el motor resolvió en memoria (read_requests) con las que tuvo que ir a buscar al disco (reads). Si de forma sostenida más de una de cada cien va al disco, la memoria queda corta. En PostgreSQL, la misma relación sale de las columnas blks_hit y blks_read de pg_stat_database.

SELECT table_schema AS base,
       ROUND(SUM(data_length + index_length) / 1024 / 1024) AS mb
FROM information_schema.tables
GROUP BY table_schema
ORDER BY mb DESC;
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%';

Cuánta memoria darle al motor

Los motores reparten la memoria de forma distinta. InnoDB, el de MySQL y MariaDB, quiere tener su propia caché grande; PostgreSQL se apoya mucho más en la caché de archivos del sistema operativo, y por eso su número es más bajo.

La memoria que queda fuera del motor no se desperdicia: la usan el sistema, las conexiones y la caché de archivos. Pasarse obliga a usar swap, y una base en swap anda peor que una con menos caché.

El disco: latencia antes que capacidad

Una base no lee archivos de corrido: salta de una página a otra y, en cada transacción confirmada, espera a que el registro quede escrito en disco. Lo que importa es cuánto tarda cada operación chica, no cuántos megabytes por segundo se pueden copiar. Un SSD resuelve una lectura aleatoria en décimas de milisegundo; un disco mecánico, en varios milisegundos.

La forma del arreglo también cuenta. RAID 10 es el estándar para bases de datos porque escribe sin el cálculo de paridad que frena a RAID 5 y 6, y sigue funcionando si falla un disco. Los servidores cloud de InHosting usan RAID 10 con un disco de reserva que entra en el arreglo apenas otro falla. Entre sus dos opciones, 240 GB SSD o 1 TB SAS, una base transaccional con mucha escritura va mejor en SSD; el volumen grande conviene cuando la prioridad es el espacio y lo caliente entra en memoria.

Dejá margen: al menos el doble de lo que ocupa hoy la base. Un ALTER TABLE sobre una tabla grande puede necesitar por un rato tanto espacio libre como la tabla, y los volcados también ocupan lugar.

Núcleos: cuentan las consultas simultáneas

En MySQL y MariaDB cada consulta corre en un solo hilo. Más núcleos significan más consultas a la vez, no que una consulta pesada termine antes: un reporte lento en un servidor de 8 núcleos tarda casi lo mismo que en uno de 4. PostgreSQL puede repartir algunas consultas grandes entre varios núcleos, pero el criterio general se mantiene.

Para estimar, mirá cuántas consultas corren a la vez en el pico con SHOW GLOBAL STATUS LIKE 'Threads_running';. Si ese número supera seguido la cantidad de núcleos, hay cola. Los servidores cloud de InHosting vienen con 4 u 8 núcleos, y la memoria se amplía hasta 128 GB sin cambiar de equipo.

La red entre la aplicación y la base

Cuando la base se separa del servidor web, cada consulta suma un viaje de ida y vuelta por la red. Una página de una tienda puede hacer 80 consultas. Con 0,2 milisegundos por viaje, dentro del mismo datacenter, son 16 milisegundos; con 20 milisegundos, entre ciudades o por internet, son 1,6 segundos antes de que se dibuje nada.

Por eso la base va cerca de la aplicación y por una red privada: los servidores cloud de InHosting pueden conectarse entre sí por red privada dentro del mismo datacenter. De paso, el puerto de la base no queda expuesto a internet.

Lo que rinde más que cualquier ampliación

Antes de sumar hardware, pasá una semana mirando qué consultas tardan. Activar el registro de consultas lentas no requiere reiniciar el motor:

SET GLOBAL slow_query_log = 1;
SET GLOBAL long_query_time = 1;

1. Pasá las peores por EXPLAIN: si recorre la tabla entera, falta un índice en las columnas del WHERE, del JOIN o del ORDER BY.
2. Pedí solo las columnas que usás. Un SELECT de todo sobre una tabla ancha mueve datos que nadie mira.
3. Agrupá las escrituras en transacciones en lugar de confirmar fila por fila.
4. Mové a tablas de archivo los datos históricos que casi no se consultan.
5. Si la aplicación abre y cierra conexiones sin parar, poné un pool delante: ProxySQL para MySQL y MariaDB, PgBouncer para PostgreSQL.

Respaldo y réplica: se complementan

• Una réplica copia cada cambio en segundos, incluido un DELETE sin WHERE. Te salva de una falla de hardware, no de un error humano.
• Un volcado lógico consistente, sin frenar la base, sale con mysqldump --single-transaction en InnoDB o con pg_dump en PostgreSQL.
• Para bases grandes, las copias físicas son más rápidas: mariadb-backup, Percona XtraBackup o pg_basebackup.
• Con los registros binarios de MySQL o el WAL de PostgreSQL se puede volver a un minuto exacto, por ejemplo al instante anterior a un borrado.
• En un servidor cloud el respaldo lo organizás vos, y tiene que quedar en otro equipo: una copia en el mismo disco se pierde con él. Qué hacer si falla el servidor entero está en plan de continuidad para pymes.

Cuándo separar la base y cuándo no

Con el 10 % de descuento del código INH, que ya va en los enlaces de contratación. Los precios se leen de la tienda. Ver el detalle de cada plan.