mongodb - sharded - En Mongo, ¿cuál es la diferencia entre sharding y replicación?

sharding mongodb español (5)

La replicación parece ser mucho más simple que la fragmentación, a menos que me pierdan los beneficios de lo que la fragmentación realmente intenta lograr. ¿No proporcionan ambos una escala horizontal?

Sharding

Sharding es una técnica para dividir una gran colección entre múltiples servidores. Cuando hacemos shard, implementamos múltiples servidores mongod . Y en el frente, mongos que es un enrutador. La aplicación habla con este enrutador. Este enrutador luego habla con varios servidores, el mongod s. La aplicación y los mongos suelen estar ubicados conjuntamente en el mismo servidor. Podemos tener múltiples servicios mongos ejecutándose en la misma máquina. También se recomienda mantener un conjunto de múltiples mongod s (en conjunto, llamado conjunto de réplicas ), en lugar de un único mongod en cada servidor. Un conjunto de réplicas mantiene los datos sincronizados en varias instancias diferentes, de modo que si uno de ellos falla, no perderemos ningún dato. Lógicamente, cada conjunto de réplicas puede verse como un fragmento . Es transparente para la aplicación, la forma en que MongoDB elige fragmentar es si elegimos una clave de fragmento .

Supongamos que para student colección de student tenemos stdt_id como la clave del fragmento o podría ser una clave compuesta. Y el servidor mongos , es un sistema basado en rango. Por lo tanto, en función del stdt_id que enviamos como clave de fragmento, enviará la solicitud a la instancia de mongod correcta.

Entonces, ¿qué necesitamos saber realmente como desarrollador?

insert debe incluir una clave de fragmento, por lo que si se trata de una clave de fragmento dividido en múltiples partes, debemos incluir la clave de fragmento completa.
tenemos que entender qué es la clave del fragmento en la colección misma
para una update , remove , find - si a mongos no se le da una clave de fragmento - entonces tendrá que transmitir la solicitud a todos los fragmentos diferentes que cubren la colección.
para una update : si no especificamos la clave de fragmento completa, tenemos que convertirla en una actualización múltiple para que sepa que necesita transmitirla

Cada vez que piense en la fragmentación o la duplicación, debe pensar en el contexto de las operaciones de escritura / actualización. Si no necesita escalar, entonces las repeticiones, ya que son bastante simples, son una buena opción para usted.

Por otro lado, si carga cargas principalmente de actualizaciones / escrituras, en algún momento llegará a un cuello de botella de escritura. Si la solicitud de escritura llega, Mongo bloquea otra solicitud de escritura. Esos bloques de solicitudes de escritura hasta que se realice la primera solicitud. Si desea escalar esto escribe y quiere paralelizarlo, entonces necesita implementar sharding.

Considere que tiene una gran colección de música en su disco duro, la almacena en orden lógico según el año de lanzamiento en diferentes carpetas. Le preocupa que su colección se perderá si falla la unidad. Así que obtienes un disco nuevo y ocasionalmente copias toda la colección manteniendo la misma estructura de carpetas.

Sharding >> Mantener sus archivos de música en carpetas diferentes

Replicación >> Sincronización de su colección con otras unidades

En el contexto de escalar MongoDB:

replication crea copias adicionales de los datos y permite la conmutación por error automática a otro nodo. La replicación puede ayudar con el escalado horizontal de lecturas si está bien para leer datos que posiblemente no sean los más recientes.
sharding permite escalar horizontalmente las escrituras de datos dividiendo los datos en varios servidores usando una clave de fragmento . Es importante elegir una buena clave de fragmento . Por ejemplo, una mala elección de la clave de fragmento podría hacer que los "puntos calientes" de datos solo se escriban en un único fragmento.

Un entorno fragmentado agrega más complejidad porque MongoDB ahora tiene que administrar los datos de distribución y las solicitudes entre fragmentos: se agregan procesos adicionales de configuración y enrutamiento para administrar esos aspectos.

La replicación y la fusión se combinan normalmente para crear un clúster fragmentado donde cada fragmento es compatible con un conjunto de réplicas.

Desde el punto de vista de la aplicación del cliente también tiene cierto control en relación con la interacción de duplicación / fragmentación, en particular:

La replicación es una configuración de maestro / esclavo principalmente tradicional, los datos se sincronizan con los miembros de la copia de seguridad y si falla la primaria, uno de ellos puede tomar su lugar. Es una herramienta razonablemente simple. Está principalmente destinado a la redundancia, aunque puede escalar las lecturas agregando miembros del conjunto de réplicas. Eso es un poco complicado, pero funciona muy bien para algunas aplicaciones.

Sharding se encuentra en la parte superior de la replicación, por lo general. Los "fragmentos" en MongoDB son solo conjuntos de réplicas con algo llamado "enrutador" frente a ellos. Su aplicación se conectará al enrutador, emitirá consultas y decidirá a qué conjunto de réplicas (fragmento) reenviará cosas. Es significativamente más complejo que un solo conjunto de réplicas porque tiene que encargarse del enrutador y de los servidores de configuración (estos mantienen un registro de los datos almacenados).

Si quieres escalar Mongo horizontalmente, harías fragmentos. A 10gen le gusta llamar a la configuración del servidor del enrutador / config autodesmenuza. Es posible hacer una forma de sharding más gueto donde la aplicación decide qué DB escribir también.