Las implementaciones de clúster son de gran importancia para garantizar la alta disponibilidad de los datos y protegerlos. MongoDB mejora esto a través de la replicación y la fragmentación, por lo que la replicación garantiza el escalado vertical mediante el levantamiento de la redundancia, mientras que la fragmentación infla la escala horizontal.
En general, ambos enfoques intentan distribuir la carga de trabajo entre los miembros y así reducir la carga de trabajo a la que podría estar sujeto un solo nodo. Entonces, el rendimiento de la base de datos puede verse como rápido al servir a los usuarios con operaciones de rendimiento. Sin embargo, sin una arquitectura de clúster principal, es posible que no vea el mismo nivel de resultados, incluso si intenta fragmentar y replicar.
Si los miembros del conjunto de réplicas están parejos, será difícil para los miembros votar y elegir una nueva primaria si la existente falla en algún momento. En este blog, analizaremos la arquitectura de implementación estándar que se puede usar, pero esto puede variar según los requisitos de la aplicación.
Estrategias de implementación de MongoDB
La arquitectura de los conjuntos de réplicas es muy determinante de la capacidad y la capacidad de MongoDB.
Un conjunto de réplicas de tres nodos es la implementación de clúster estándar para MongoDB en cualquier entorno de producción, ya que proporciona redundancia de datos y tolerancia a fallas. La redundancia es importante, especialmente en la recuperación de bases de datos después de un desastre. Un conjunto de réplicas de tres nodos puede ser la arquitectura de implementación básica, pero esto puede variar según las especificaciones y los requisitos de la aplicación. Sin embargo, no lo haga demasiado complejo, ya que puede ocasionarle algunos problemas de configuración mayores.
Estrategias de fragmentación de MongoDB
La fragmentación reduce la carga de trabajo sobre la que debe trabajar la base de datos para una consulta dada al reducir la cantidad de documentos sobre los que se debe actuar. Por lo tanto, eleva la escala horizontal, lo que permite que la base de datos crezca más allá de los límites de hardware de un solo servidor. Según la demanda de la carga de trabajo, se pueden agregar o eliminar nodos del clúster y MongoDB reequilibrará los datos de manera óptima sin intervención de la operación.
Algunas de las mejores estrategias de implementación para un clúster fragmentado incluyen:
Garantizar que las claves fragmentadas se distribuyan uniformemente
La razón detrás de la fragmentación es escalar la base de datos horizontalmente y reducir la cantidad de operaciones de rendimiento a las que podría estar sujeta una sola instancia. Si no distribuye las claves de fragmentos de manera uniforme, puede terminar con una pequeña cantidad de fragmentos. Con pocos fragmentos, las operaciones pueden estar limitadas por la capacidad de un solo fragmento, lo que hace que las operaciones de lectura y escritura sean lentas.
Los trozos deben dividirse previamente y distribuirse primero
Los fragmentos tienen fragmentos de datos que se agrupan según algunos criterios de clave de fragmento. Al crear una nueva colección fragmentada, antes de cargarla con datos, debe crear fragmentos vacíos y distribuirlos uniformemente en todos los fragmentos. Cuando llene MongoDB con datos, será fácil equilibrar la carga entre los fragmentos involucrados. La opción numInitialChunks se puede usar para hacer esto automáticamente si está usando fragmentación basada en hash. Sin embargo, el valor entero debe ser inferior a 8192 por fragmento.
Número de fragmentos
A menudo se requieren dos fragmentos como el número mínimo para lograr la importancia del fragmento. Un solo fragmento solo es útil si desea sentar las bases para habilitar el fragmentado en el futuro y no es necesario durante el tiempo de implementación.
Preferir fragmentación basada en rango sobre fragmentación basada en hash
La fragmentación basada en rango es beneficiosa ya que proporciona más fragmentos, por lo tanto, las operaciones se pueden enrutar a la menor cantidad de fragmentos necesarios y, con mayor frecuencia, a un solo fragmento. En la práctica, esto puede ser difícil, a menos que tenga una buena comprensión de los datos y los patrones de consulta involucrados. La fragmentación hash mejora la distribución uniforme de la operación de rendimiento a expensas de proporcionar operaciones inferiores basadas en rangos.
Usar consultas de dispersión y recopilación solo para consultas de agregación grande
Las consultas que no se pueden enrutar en función de una clave de fragmento deben transmitirse a todos los fragmentos para su evaluación y, dado que involucran múltiples fragmentos para cada solicitud, no se escalan linealmente a medida que se agregan más fragmentos, por lo que incurren en una sobrecarga. que degrada el rendimiento de la base de datos. Esta operación se conoce como dispersión y recopilación y solo se puede evitar si incluye la clave de fragmento en su consulta.
El enfoque solo es útil cuando se trata de consultas de agregación grandes en las que se puede permitir que cada consulta se ejecute en paralelo en todos los fragmentos.
Estrategias de replicación de MongoDB
La replicación mejora el escalado vertical en MongoDB de modo que la carga de trabajo se distribuye entre los miembros involucrados. En el entorno de producción, estas son algunas de las consideraciones que se deben tener para una arquitectura de clúster óptima.
Número de nodos
La cantidad máxima de nodos que puede tener un conjunto de réplicas es 50 con 7 miembros con derecho a voto. Cualquier miembro después del 7 se considera sin derecho a voto. Por lo tanto, un buen clúster debe tener 7 miembros con derecho a voto para que el proceso de elección sea conveniente.
Despliegue un número impar de miembros con derecho a voto y si solo tiene menos de 7 pero un número par de miembros, entonces deberá implementar un árbitro como otro miembro con derecho a voto. Los árbitros no almacenan una copia de los datos, por lo que requerirán menos recursos para administrar. Además, uno puede someterlos a un entorno al que no podría someter a los otros miembros.
Consideraciones de tolerancia a fallas
A veces, algunos miembros pueden no estar disponibles como resultado de factores como cortes de energía o transitorios y desconexiones de la red. El número de miembros que permanecen en el conjunto y son capaces de elegir un primario crean una situación conocida como tolerancia a fallas. Por lo tanto, es la diferencia entre el número total de miembros del conjunto de réplicas y la mayoría de los miembros votantes necesarios para elegir una primaria. La ausencia de un primario dicta que las operaciones de escritura no se pueden ejecutar.
La siguiente tabla muestra una relación de muestra entre los tres.
| Total de miembros del conjunto de réplicas | Se requiere mayoría para elegir una nueva primaria | Tolerancia a fallas |
| 3 | 2 | 1 |
| 4 | 3 | 1 |
| 5 | 3 | 2 |
| 6 | 4 | 2 |
| 7 | 5 | 2 |
La relación no es tan directa en el sentido de que si agrega más miembros al conjunto, la tolerancia a fallas no aumentará como se ve en la tabla. Los miembros adicionales brindan soporte para funciones dedicadas, como copias de seguridad e informes.
Planificación de capacidad y balanceo de carga para lecturas pesadas
Necesita tener una capacidad adicional para su implementación agregando nuevos miembros antes de que la demanda actual sature la capacidad del conjunto existente.
Para un tráfico de lectura muy alto, distribuya las lecturas de rendimiento a los miembros secundarios y cada vez que crezca el clúster, agregue o mueva miembros a centros de datos alternativos para lograr la redundancia y aumentar la disponibilidad de los datos.
También puede utilizar operaciones de destino con conjuntos de etiquetas para orientar las operaciones de lectura a miembros específicos o modificar la preocupación de escritura para solicitar el reconocimiento de miembros específicos.
Los nodos deben distribuirse geográficamente
Los centros de datos también pueden fallar debido a alguna catástrofe. Por lo tanto, se recomienda mantener al menos uno o dos miembros en un centro de datos separado para fines de protección de datos. Si es posible, utilice un número impar de centros de datos y seleccione una distribución que maximice la probabilidad de que, incluso con la pérdida de un centro de datos, los miembros restantes del conjunto de réplicas puedan formar una mayoría o, como mínimo, proporcionar una copia de los datos.
Emplear diario para fallas inesperadas
Por defecto, esto está habilitado en MongoDB. Debe asegurarse de que esta opción esté habilitada para proteger la pérdida de datos en caso de interrupciones del servicio, como reinicios repentinos y fallas de energía.
Patrones de implementación
Hay principalmente dos enfoques de implementación que son:
- Conjuntos de réplicas de tres miembros que proporcionan la arquitectura mínima recomendada para un conjunto de réplicas.
- Conjunto de réplicas distribuidas en dos o más centros de datos para proteger contra fallas específicas de las instalaciones, como cortes de energía.
Sin embargo, los patrones dependen de los requisitos de la aplicación, pero si es posible, puede combinar características de estos dos en su arquitectura de implementación.
Nombres de host y nombres de conjuntos de réplicas
Utilice un nombre de host DNS lógico en lugar de una dirección IP al configurar miembros del conjunto de réplicas o miembros del clúster fragmentado. Esto es para evitar el dolor relacionado con los cambios de configuración que deberá realizar como resultado de las direcciones IP modificadas.
En el caso de nombres de conjuntos de réplicas, utilice nombres distintos para los conjuntos, ya que algunos controladores agrupan las conexiones de conjuntos de réplicas por nombre de conjunto de réplicas.
Conclusión
El diseño de la arquitectura para un conjunto de réplicas determina la capacidad y la capacidad de su implementación. La protección de datos y el rendimiento del sistema son las consideraciones principales al configurar la arquitectura. Se deben considerar factores vitales como la tolerancia a fallas, la cantidad de miembros del conjunto de réplicas, la clave de fragmentación óptima y los patrones de implementación para una alta disponibilidad y protección de datos. La distribución geográfica de los nodos del conjunto de réplicas puede abordar gran parte de estos factores al garantizar la redundancia y proporcionar tolerancia a fallas si uno de los centros de datos está ausente.
