Diferencia entre fragmentación y replicación en MongoDB

77

Estoy confundido acerca de Sharding and Replication sobre cómo funcionan ... Según la definición

Replicación: una réplica establecida en MongoDB es un grupo de procesos mongod que mantienen el mismo conjunto de datos.

Sharding: Sharding es un método para almacenar datos en varias máquinas.

Según tengo entendido, si hay datos de 75 GB, entonces por replicación (3 servidores), almacenará datos de 75GB en cada servidor significa 75GB en el Servidor-1, 75GB en el servidor-2 y 75GB en el servidor-3 ... (corríjame si me equivoco) ... y al fragmentarlos se almacenarán como datos de 25 GB en el servidor 1, datos de 25 Gb en el servidor 2 y datos de 25 GB en el servidor 3. (¿Correcto?) ... pero entonces encontré esta línea en el tutorial

Los fragmentos almacenan los datos. Para proporcionar alta disponibilidad y consistencia de datos, en un clúster fragmentado de producción, cada fragmento es un conjunto de réplicas

Como el conjunto de réplicas es de 75 GB pero el fragmento es de 25 GB, entonces cómo pueden ser equivalentes ... esto me hace confundir mucho ... Creo que me falta algo genial en esto. Por favor, ayúdame en esto.

Saad Saadi
fuente

Respuestas:

111

Un conjunto de réplica significa que tiene varias instancias de MongoDB que reflejan todos los datos entre sí. Un conjunto de réplicas consta de un Maestro (también llamado "Primario") y uno o más Esclavos (también conocido como Secundario). Cualquier esclavo puede realizar operaciones de lectura, por lo que puede aumentar el rendimiento de lectura agregando más esclavos al conjunto de réplicas (siempre que su aplicación cliente sea capaz de utilizar diferentes miembros de conjunto). Pero las operaciones de escritura siempre tienen lugar en el maestro del conjunto de réplicas y luego se propagan a los esclavos, por lo que las escrituras no serán más rápidas cuando agregue más esclavos.

Los conjuntos de réplica también ofrecen tolerancia a fallas. Cuando uno de los miembros del conjunto de réplicas cae, los otros se hacen cargo. Cuando el maestro cae, los esclavos elegirán un nuevo maestro. Por esa razón , se recomienda que la implementación productiva utilice siempre MongoDB como un conjunto de réplica de al menos tres servidores, dos de los cuales contienen datos (el tercero es un "árbitro" sin datos que se requiere para determinar un nuevo maestro cuando uno de los esclavos cae).

Un clúster fragmentado significa que cada fragmento del clúster (que también puede ser un conjunto de réplicas) se ocupa de una parte de los datos. Cada solicitud, tanto de lectura como de escritura, es atendida por el clúster donde residen los datos. Esto significa que se puede aumentar el rendimiento de lectura y escritura agregando más fragmentos a un clúster. Qué documento reside en qué fragmento está determinado por la clave de fragmento de cada colección. Debe elegirse de manera que los datos se puedan distribuir uniformemente en todos los clústeres y de modo que quede claro para las consultas más comunes donde reside la clave de fragmento (ejemplo: cuando consulta con frecuencia user_name, su clave de fragmento debe incluir el campo user_namepor lo que cada consulta se puede delegar a sólo el fragmento que tiene ese documento).

El inconveniente es que la tolerancia a fallos sufre. Cuando un fragmento del clúster se cae, no se puede acceder a los datos que contiene. Por esa razón, cada miembro del clúster también debe ser un conjunto de réplicas. Esto no es requerido. Cuando no le importa la alta disponibilidad, un fragmento también puede ser una sola instancia mongod sin replicación . Pero para el uso de producción siempre debe usar la replicación .

Entonces, ¿qué significa eso para tu ejemplo?

                            Sharded Cluster             
             /                    |                    \
      Shard A                  Shard B                  Shard C
        / \                      / \                      / \
+-------+ +---------+    +-------+ +---------+    +-------+ +---------+
|Primary| |Secondary|    |Primary| |Secondary|    |Primary| |Secondary|
|  25GB |=| 25GB    |    | 25 GB |=| 25 GB   |    | 25GB  |=| 25GB    |   
+-------+ +---------+    +-------+ +---------+    +-------+ +---------+

Cuando desee dividir sus datos de 75 GB en 3 fragmentos de 25 GB cada uno, necesita al menos 6 servidores de bases de datos organizados en tres conjuntos de réplicas. Cada conjunto de réplicas consta de dos servidores que tienen los mismos 25 GB de datos.

También necesita servidores para los árbitros de los tres conjuntos de réplicas, así como el enrutador mongos y el servidor de configuración para el clúster. Los árbitros son muy livianos y solo se necesitan cuando un miembro del conjunto de réplicas cae, por lo que generalmente pueden compartir el mismo hardware con otra cosa. Pero el enrutador y el servidor de configuración de Mongos deberían ser redundantes y estar en sus propios servidores.

Philipp
fuente
2
Muchas gracias por la respuesta detallada ... una pregunta más ... si el primario está inactivo mientras se realiza una operación de escritura o lectura, entonces ... 1) cuál es el retraso en la selección del primario de los secundarios y 2) durante ese retraso, ¿dónde se almacenarán los datos temporalmente?
Saad Saadi
44
@SaadSaadi El proceso de elección primaria se describe en la documentación . Los secundarios tardan entre 10 y 12 segundos en darse cuenta de que el primario está inactivo. La elección primaria en sí misma generalmente solo tomará milisegundos. El conjunto de réplicas es de solo lectura mientras no hay primario. Cualquier intento de las aplicaciones para escribir datos durante este tiempo fallará.
Philipp
1
@Philipp: solo dos comentarios: (1) la clave de fragmento no se puede modificar (es decir, no se puede fragmentar con una clave diferente) y (2) se puede leer desde los nodos secundarios del conjunto de réplicas, pero la coherencia depende de la preocupación de escritura (en Para que sea coherente, la opción w debe ser igual al conjunto de réplica sth que no es viable ya que cada fragmento puede tener diferentes tamaños de conjunto de réplicas deliberadamente o debido a fallas de nodo).
Mike Argyriou
@Philipp, ¿puede responder más preguntas de seguimiento en dba.stackexchange.com/questions/208482/… ?
user3198603
18
  • El particionamiento divide el conjunto de datos en partes discretas.
  • La replicación duplica el conjunto de datos.

Estas dos cosas pueden acumularse ya que son diferentes. Usar ambos significa que dividirá su conjunto de datos en múltiples grupos de réplicas. Dicho de otra manera, replicas fragmentos; un conjunto de datos sin fragmentos es un solo 'fragmento'.

Un clúster Mongo con tres fragmentos y 3 réplicas tendría 9 nodos.

  • 3 conjuntos de réplicas de 3 nodos.
  • Cada conjunto de réplicas contiene un solo fragmento.
sysadmin1138
fuente
Para un archivo grande, ¿se almacena en un fragmento o fragmento múltiple (por lo tanto, a través de los nodos)?
Tony
Tenga en cuenta que en MongoDB 3.4 o superior, también necesitará servidores mongoDB para la configuración y un servidor adicional para actuar como enrutador mongos. Esto eleva el total del clúster 3x3 en su ejemplo a un total de 13 servidores.
dthrasher
9

Al fragmentar , divide su colección en varias partes.
Replicar su base de datos significa que crea espejos de su conjunto de datos.

haper
fuente
4

En cuanto a la funcionalidad entregada. Sharding proporciona escalabilidad y paralelismo. La replicación proporciona disponibilidad

Ashish Kumar
fuente
no, la replicación solo proporciona escalabilidad y paralelismo dado que las lecturas son mucho más frecuentes que las escrituras
Kristóf Szalay