Planificación de capacidad de disco y RAM
La planificación de la capacidad de disco y memoria para un servidor de base de datos es un arte negro. Más es mejor. Más rápido es mejor.
Como pautas generales ofrezco lo siguiente:
- Desea más espacio en disco del que NUNCA necesitará.
Tome su mejor cálculo de cuánto espacio en disco necesitará para los próximos 3-5 años, luego duplíquelo.
- Necesitará suficiente RAM para mantener los índices de su base de datos en la memoria, manejar su consulta más grande al menos dos veces y aún tendrá suficiente espacio para un caché de disco del sistema operativo saludable.
El tamaño del índice dependerá de su base de datos, y todo lo demás depende en gran medida de su conjunto de datos y estructura de consulta / base de datos. Ofreceré "Al menos el doble del tamaño de su tabla más grande" como sugerencia, pero tenga en cuenta que esta sugerencia se desglosa en operaciones de almacenamiento de datos realmente grandes donde la tabla más grande puede ser decenas o cientos de gigabytes.
Todos los proveedores de bases de datos tienen algunas instrucciones sobre cómo ajustar el rendimiento de su disco / memoria / núcleo del sistema operativo: dedique algún tiempo a esta documentación antes de la implementación. Ayudará.
Benchmarking de carga de trabajo y planificación de capacidad
Suponiendo que aún no se haya desplegado ...
Muchos sistemas de bases de datos se envían con herramientas de evaluación comparativa: por ejemplo,
PostgreSQL se envía con
pgBench .
Estas herramientas deberían ser su primera parada en la evaluación comparativa del rendimiento de la base de datos. Si es posible, debe ejecutarlos en todos los nuevos servidores de bases de datos para tener una idea de "cuánto trabajo" puede hacer el servidor de bases de datos.
Armado ahora con un punto de referencia sin procesar ABSOLUTELY MEANINGLESS, consideremos un enfoque más realista para la evaluación comparativa: cargue el esquema de su base de datos y escriba un programa que lo complete con datos ficticios, luego ejecute las consultas de su aplicación contra esos datos.
Esto compara tres cosas importantes: 1. El servidor de la base de datos (hardware) 2. El servidor de la base de datos (software) 3. El diseño de su base de datos y cómo interactúa con (1) y (2) anteriores.
Tenga en cuenta que esto requiere mucho más esfuerzo que simples puntos de referencia preconstruidos como pgBench: necesita escribir algún código para completar la información, y puede que necesite escribir algo de código para hacer las consultas e informar el tiempo de ejecución.
Este tipo de prueba también es sustancialmente más precisa: dado que está trabajando con su esquema y consultas, puede ver cómo funcionarán y le ofrece la oportunidad de perfilar y mejorar su base de datos / consultas.
Los resultados de estos puntos de referencia son una vista idealizada de su base de datos. Para estar seguro, suponga que solo alcanzará el 50-70% de este rendimiento en su entorno de producción (el resto es un colchón que le permitirá manejar un crecimiento inesperado, fallas de hardware, cambios en la carga de trabajo, etc.).
¡Es demasiado tarde! ¡Está en producción!
Una vez que sus sistemas están en producción, es realmente demasiado tarde para "comparar": puede activar brevemente el registro / sincronización de consultas y ver cuánto tiempo demoran las cosas en ejecutarse, y puede ejecutar algunas consultas de "prueba de esfuerzo" en grandes conjuntos de datos durante el apagado horas También puede ver la utilización de la CPU, RAM y E / S (ancho de banda del disco) del sistema para tener una idea de qué tan cargada está.
Desafortunadamente, todas estas cosas harán una idea de lo que está haciendo el sistema y un concepto vago de cuán cerca está de la saturación.
Eso nos lleva a ...
Monitoreo continuo
Todos los puntos de referencia en el mundo no lo ayudarán si su sistema de repente ve patrones de uso nuevos / diferentes.
Para mejores o peores, las implementaciones de bases de datos no son estáticas: sus desarrolladores cambiarán las cosas, su conjunto de datos crecerá (parece que nunca se reducen) y sus usuarios crearán de alguna manera combinaciones locas de eventos que nunca predijo en las pruebas.
Para planificar adecuadamente la capacidad de su base de datos, necesitará implementar algún tipo de monitoreo de rendimiento para alertarlo cuando el rendimiento de la base de datos ya no cumpla con sus expectativas. En ese momento, puede considerar acciones correctivas (nuevo hardware, esquema de base de datos o cambios de consulta para optimizar el uso de recursos, etc.).
Nota: Esta es una guía genérica y de muy alto nivel para dimensionar el hardware de su base de datos y descubrir cuánto abuso puede soportar. Si aún no está seguro de cómo determinar si un sistema específico satisface sus necesidades, debe hablar con un experto en bases de datos.
También hay un sitio de Stack Exchange dedicado específicamente a la gestión de bases de datos: dba.stackexchange.com . Busque en su archivo de preguntas o explore las etiquetas específicas de su motor de base de datos para obtener más consejos sobre el ajuste del rendimiento.