¿Debería un desarrollador mantener las bases de datos en el nodo de cómputo o en el nodo de almacenamiento?
Por defecto, guarda los archivos activos de la base de datos en almacenamiento de baja latencia junto al cómputo y usa el nodo de almacenamiento para copias de seguridad, volcados, réplicas y archivos.
Ese criterio predeterminado cambia cuando el nodo de almacenamiento ofrece una ruta de almacenamiento en bloques diseñada específicamente para ello, una latencia medida, garantías de durabilidad correctas y una mejora de recuperación que justifique la dependencia adicional. La decisión no se reduce simplemente a capacidad local o de red: los registros de transacciones, los archivos de datos, las copias de seguridad, las cargas de la aplicación y las bases de datos de prueba desechables tienen distintos patrones de escritura y consecuencias en caso de fallo.
Separa el estado de la base de datos de los volcados y las copias de seguridad
Identifica todas las rutas relacionadas con la base de datos antes de elegir un nodo. El directorio de datos principal y el registro de transacciones son estado activo; requieren un orden de escritura coherente y una latencia predecible. Los volcados lógicos, las copias de seguridad completas, los registros archivados, las exportaciones y los archivos cargados por la aplicación tienen distintos patrones de acceso y a menudo pueden transferirse por la red de forma segura.
No montes un recurso compartido de NAS y guardes todo dentro. Mantén el volumen activo de la base de datos separado de los destinos de las copias de seguridad y de los datos masivos de las aplicaciones. Así puedes ajustar, supervisar, llenar, crear instantáneas, restaurar y migrar cada función por separado, sin asumir que todos los datos persistentes necesitan el mismo medio.
En bases de datos temporales de ramas o pruebas de CI, el tiempo de reconstrucción puede importar más que la durabilidad. Guárdalas en almacenamiento local rápido y desechable y vuelve a crearlas a partir de migraciones o datos de prueba saneados. Para la base de datos de servicio diaria de un desarrollador, considera el fallo de un SSD local un evento de recuperación y mantén la copia remota lo bastante actualizada para cumplir el objetivo de punto de recuperación declarado.
Mide la ruta de escritura antes de elegir un nodo
El rendimiento de una base de datos depende de más que la velocidad de transferencia secuencial. Mide la latencia de confirmación síncrona, las lecturas y escrituras aleatorias, la profundidad de la cola durante el tráfico de copias de seguridad y el comportamiento cuando se interrumpe la ruta de red. Un enlace de 10GbE puede transferir archivos grandes rápidamente y, aun así, añadir latencia y otro punto de fallo a cada transacción.
Una comparación publicada de PostgreSQL reveló que NVMe local ofrecía una latencia menor y más predecible que los servicios en la nube conectados por red evaluados, aunque también señaló las ventajas de elasticidad y durabilidad del almacenamiento en red. Esos análisis de rendimiento de PostgreSQL con almacenamiento local y conectado por red no garantizan los mismos resultados en un laboratorio doméstico, pero muestran por qué la ubicación de la base de datos debe decidirse midiendo la carga de trabajo, no solo la velocidad de la interfaz.
Realiza una prueba representativa con el mismo sistema de archivos, la misma configuración de sincronización, versión de la base de datos, conjunto de datos y concurrencia previstos para el servicio. Durante la prueba, inicia una copia de seguridad grande o una transferencia multimedia en la red de almacenamiento. Si la latencia de cola o el tiempo de confirmación se vuelven erráticos, la capacidad centralizada no está compensando las limitaciones de la ruta compartida.
Por defecto, coloca los archivos principales de la base de datos cerca del nodo de cómputo
Para un solo desarrollador, un nodo de cómputo y bases de datos de tamaño moderado, los SSD locales en espejo o un volumen local recuperable suelen ofrecer la propiedad más clara. El proceso de la base de datos, sus archivos de datos y su registro de escritura anticipada fallan juntos, mientras que el nodo de almacenamiento recibe copias de seguridad mediante un proceso que tiene en cuenta la base de datos, en lugar de alojar un sistema de archivos remoto siempre abierto.
Ubicar los datos localmente no significa depender de una única unidad de arranque sin protección. Cuando sea posible, separa el volumen de la base de datos del sistema operativo, supervisa el espacio libre y el estado de las unidades, reserva capacidad para las operaciones de mantenimiento y exporta copias de seguridad antes de las actualizaciones. Fija la ubicación de los contenedores o las máquinas virtuales para que un planificador no inicie la base de datos en otro nodo sin sus datos.
Usa almacenamiento local solo cuando la ruta de recuperación sea viable. Si reemplazar el nodo de cómputo obligara a recurrir a una copia desactualizada, el almacenamiento centralizado podría dejar al descubierto un fallo existente en las copias de seguridad, en vez de causarlo. Corrige el proceso de copia y restauración antes de optimizar la ruta de datos.
Usa el nodo de almacenamiento para copias de seguridad, réplicas y archivos
Un nodo de almacenamiento resulta útil cuando recibe volcados coherentes con la aplicación, copias de seguridad base, registros de transacciones archivados, instantáneas inmutables o una réplica de la base de datos con su propio propósito de recuperación. También puede almacenar archivos adjuntos grandes o exportaciones analíticas, mientras el catálogo de la base de datos y los registros sensibles a la latencia permanecen en el nodo de cómputo.
| Función de los datos | Ubicación predeterminada | Motivo | Prueba necesaria |
|---|---|---|---|
| Datos principales y registro de transacciones | SSD del nodo de cómputo | Ruta de escritura más rápida y predecible | Latencia de confirmación y recuperación ante fallos |
| Volcados lógicos | Nodo de almacenamiento | Origen de restauración portátil y compatible con versiones | Restaura en una base de datos vacía |
| Copia de seguridad base y registros archivados | Nodo de almacenamiento | Recuperación a un momento dado | Recupera hasta una marca de tiempo concreta |
| Réplica de lectura | Cualquiera de los nodos con su propio volumen | Opción de escalado de lectura o recuperación | Procedimiento de retraso y promoción |
| Cargas, exportaciones y análisis de datos fríos | Nodo de almacenamiento | La capacidad importa más que la latencia de las transacciones | Impacto de las transferencias simultáneas |
Las pruebas de la comunidad de PostgreSQL sobre NFS en un servidor de almacenamiento dieron resultados contraintuitivos y plantearon preguntas de configuración, en lugar de una respuesta universal. Por eso el almacenamiento remoto principal debe tratarse como una excepción de ingeniería: valida el comportamiento de sincronización, la gestión de fallos, las opciones de montaje, la semántica de caché y la recuperación en la pila concreta.
Valida la recuperación ante fallos y el momento de migrar
Prueba cuatro situaciones: reinicia la base de datos correctamente, bloquea el nodo de computación durante las escrituras, interrumpe la conexión de almacenamiento durante una copia de seguridad y restaura el sistema en un host vacío. Confirma el punto de recuperación, el tiempo de recuperación, las comprobaciones de integridad de la base de datos y el comportamiento de reconexión de la aplicación. Un benchmark normal rápido no demuestra que la ruta de escritura sea segura ante interrupciones.
La configuración se considera válida cuando los datos activos tienen una latencia predecible, las copias de seguridad no pueden sobrescribir ni bloquear el sistema principal y un nodo de computación de reemplazo puede restaurar el sistema sin depender de supuestos de almacenamiento no documentados. Traslada los archivos principales a un servicio de almacenamiento diseñado para ese fin solo cuando las ventajas medidas de recuperación o movilidad superen la dependencia de la red; vuelve a almacenarlos localmente cuando la latencia de cola o las interrupciones de conexión se conviertan en la principal causa de incidentes.
Para elegir la arquitectura general, la comparación de ZimaSpace entre un NAS centrado en el almacenamiento y un servidor doméstico centrado en la computación ayuda a decidir qué función debería mantenerse estable a medida que cambian las cargas de trabajo de desarrollo.
Regla final de configuración
Usa por defecto el almacenamiento local y protegido en SSD para los archivos activos de la base de datos, y el nodo de almacenamiento para las copias de seguridad verificadas, los archivos y las réplicas seleccionadas. Elige el almacenamiento remoto como principal solo después de medir su comportamiento de escritura, la latencia de cola, cómo responde ante interrupciones y las ventajas de recuperación.
Productos recomendados
Configuración de NAS y servidores
Más para leer
¿Puede un servidor en una residencia estudiantil funcionar lo bastante silenciosamente como para dormir, estudiar y hacer videollamadas?
Sí, un servidor para una residencia universitaria puede pasar desapercibido si el hardware consume poca energía, se controlan las vibraciones del almacenamiento, se programan...
Un laboratorio doméstico estudiantil que puede pasar de la habitación de la residencia universitaria al primer apartamento
Mantén portátil el laboratorio doméstico de un estudiante separando los servicios de la red específica de cada habitación, minimizando el hardware, haciendo copias de...
Cómo compartir un servidor doméstico con tus compañeros de piso sin compartir cuentas ni archivos privados
Asigna a cada compañero de piso una identidad con nombre, almacenamiento privado y solo los roles compartidos que necesite; mantén la administración, las copias...
