Una base de datos se “esclava” a un “maestro” cuando recibe un flujo de actualizaciones del maestro en tiempo casi real, funcionando como una copia. El “esclavo” simplemente debe aplicar los cambios que el maestro validó y aprobó.
En principio, uno podría crear una configuración maestro-esclavo transfiriendo archivos realmente rápido de un servidor a otro; pero en la práctica, cada base de datos tiene su propio protocolo de replicación especializado.
Hay muchas razones por las que una réplica hace que las consultas regresen más rápido. Una es que la CPU del maestro está menos cargada de consultas, mientras que la CPU de la réplica está menos cargada de escrituras; entonces hay más CPU disponible para hacer el trabajo. Otra es que los datos, aunque se almacenan nominalmente en el disco, se almacenan en caché en la RAM cuando es posible; y, de hecho, el sistema operativo hace esto si la base de datos lo solicita o no y puede ser impredecible al respecto. En el maestro, las partes de la base de datos recientemente escritas y todo lo que se use para admitir escrituras, por ejemplo, los índices utilizados para verificar la unicidad, estarán en la RAM todo el tiempo; estos deben compartir espacio con las porciones de la base de datos cargadas para atender consultas. La réplica no necesita cargar tantos datos para soportar su carga de escritura (está escribiendo en las mismas partes de la base de datos, pero puede confirmarla ingenuamente sin verificar nada) y hace que haya más RAM disponible para atender consultas.
- ¿Qué marco le gusta más a Mayank Singhal para desarrollar una aplicación web?
- ¿Cuáles son las ventajas y desventajas importantes de Symphony CMS en comparación con Ruby on Rails?
- ¿Cómo puedo hacer una aplicación web que combine dos imágenes en una?
- ¿El reloj de Gulp usa encuestas o eventos reales?
- ¿Cómo puede un inicio completamente nuevo ganar tracción para su aplicación web?
También está la cuestión del acceso al disco. Cuando los datos se escriben en el maestro, deben escribirse en el disco antes de que el maestro pueda devolver un mensaje de confirmación exitoso a la aplicación. Para escribir en el disco, el sistema operativo debe hacer que la cabeza del disco esté disponible. Si la cabeza del disco está lejos del lugar donde necesitamos escribir el registro actualizado o agregado, entonces debe moverse. Para que la cabeza del disco “busque” puede llevar bastante tiempo, en relación con otras operaciones. Por esta razón, los desarrolladores de bases de datos han elegido inteligentemente que sus bases de datos escriban todos los cambios uno tras otro, uno al lado del otro en el disco, hasta que se hayan escrito algunos cambios. Por lo tanto, la cabeza del disco no necesita moverse del lugar donde estaba cuando se escribió el último registro. Este registro de registros no los almacena de la manera más eficiente: el “montón” de la base de datos es donde se almacenan los registros de manera más eficiente, pero para algunos registros a la vez, no es un problema. De vez en cuando, el software de la base de datos toma todos los cambios registrados y los escribe en el montón. Este último paso, de hecho, mueve la cabeza del disco; pero al menos no lo hemos movido de un lado a otro en todo el montón para cada cambio. La reducción de búsquedas mejora en gran medida el rendimiento promedio de la base de datos.
Las lecturas no permiten este tipo de atajos. Para leer datos, debemos ir a su lugar en el disco y leerlo. Esto reintroduce la presión para mover la cabeza del disco hacia adelante y hacia atrás. Una réplica tiene su propia cabeza (o cabezas) de disco y, por lo tanto, puede asumir parte de esta carga de búsqueda de consultas.
Uno podría obtener estos mismos beneficios al obtener un servidor más grande también; uno con más discos, CPU y RAM. Sin embargo, hacerlo sin tiempo de inactividad es un poco difícil. Y mientras que una réplica le brinda una opción en caso de que el maestro se caiga, un servidor de base de datos grande no es más confiable que un servidor de base de datos pequeño.
