MongoDB para Big Data – replicación y sharding (II)

Como vimos en el artículo anterior, MongoDB nos permite configurarlo fácilmente para actuar en modo replicación.

La replicación Mongo da soporte a la alta disponibilidad que necesitamos para nuestros sistemas Big Data, pero tiene algunas limitaciones, tal como explicamos.

Podemos complementar la replicación con el sharding o particionado de la información. De esta manera podemos lograr los objetivos de alto rendimiento, capacidad de almacenamiento y escalabilidad horizontal necesarios para cualquier sistema Big Data.

El Sharding es una técnica que consiste en particionar los datos de una base de datos horizontalmente agrupándolos de algún modo que tenga sentido y que permita un direccionamiento (enrutado) más rápido.

Una agrupación típica puede ser por id. Por ejemplo: “los usuarios del 1 al millón están en tal base de datos”; o por nombre “los usuarios cuyo nombre va de la A a la E” están en esta otra base de datos”.

Sharding en MongoDB

Antes de entrar en el detalle técnico del particionado, vamos a entender las variables que tendremos que gestionar en Mongo.

Un clúster particionado de Mongo consta de los siguientes componentes:

• Shard: cada partición contiene un subconjunto de los datos fragmentados. Cada fragmento se puede implementar como un conjunto de replicación.
• mongos: mongos actúa como un enrutador de queries o consultas, proporcionando una interfaz entre las aplicaciones cliente y el clúster de shards.
• Servidores de configuración: los servidores de configuración almacenan metadatos y configuraciones para el clúster. A partir de MongoDB 3.4, los servidores de configuración deben implementarse como un conjunto de réplicas.

Un esquema de esta arquitectura se muestra en el siguiente diagrama.

Mongo divide los datos particionados en chunks o pedazos. Cada chunk tiene un rango inferior inclusivo y superior exclusivo, basado en la clave de shard.

Mongo migra los trozos entre los shards del clúster utilizando un balanceador; el cuál intenta lograr un equilibrio de chunks entre todos los shards del clúster.

El tamaño por defecto de los chunks es de 64MB, pero se puede configurar.

Consideraciones para el sharding en Mongo

Para distribuir los documentos de una colección, Mongo divide la colección según la clave de shard. La clave de shard consiste en un campo o campos inmutables que existen en cada documento en la colección de destino.

Escogiendo una clave Shard

Para escoger una clave shard adecuada se debe tener en cuenta que:

• La clave shard debe ser inmutable
• La clave shard debe estar indexada
• La clave shard está limitada a 512 bytes de tamaño
• La clave shard se usará para enrutar las queries o consultas

Se debe elegir un campo comúnmente utilizado en queries

• Solo la clave shard puede ser única entre todos los shards.
• Por ejemplo el campo _id es único, pero sólo en un shard individual, es decir se puede repetir en diferentes shards.

Algas buenas prácticas para escoger la clave de shard incluyen:

• Crear una clave de shard que sea fácilmente divisible
  • Una clave de shard fácil de dividir hace que sea igualmente fácil para MongoDB distribuir contenido entre los shards.
  • Las claves shard que tienen un número limitado de posibles valores pueden dar como resultado pedazos que son “no divisibles”.
  • Por ejemplo, si un fragmento representa un único valor de clave de shard, entonces Mongo no puede dividir el fragmento incluso cuando el fragmento excede el tamaño en que se producen divisiones.
• Crear una clave de shard que tenga un alto grado de aleatoriedad
  • Una clave de shard con alto grado de aleatoriedad impide que cualquier fragmento se convierta en un cuello de botella y distribuirá las operaciones de escritura entre el clúster.
• Crear una clave de shard que tenga como objetivo un fragmento único.
  • Una clave de shard que se dirige a un único fragmento hace posible que mongos devuelva la mayoría de las operaciones de consulta directamente desde una instancia de mongod específica.
  • Lu clave de shard debe ser el campo principal utilizado por tus queries.
  • Los campos con un alto grado de “aleatoriedad” dificultan dirigir operaciones a shards específicos.
• Shard con clave compuesta
  • Cuando se selecciona una clave de shard el desafío es que no siempre hay una opción obvia sencilla.
  • A menudo, un campo existente en su colección puede no ser la clave óptima.
  • En esas situaciones, generar una clave de shard de propósito especial en un campo adicional o usar una clave de shard compuesta puede ayudar a producir una que sea más idónea.

Estrategias de sharding

MongoDB admite dos estrategias de sharding para distribuir datos entre los componentes del clúster.

Hashed Sharding

Se calcula un hash del valor del campo clave del shard. A cada shard se le asigna un rango basado en los valores de la clave hasheada del shard. La distribución de datos basada en valores hash facilita una distribución de datos más homogénea entre elementos del cluster, especialmente en conjuntos de datos donde la clave del shard cambia monótonamente.

Sin embargo, una distribución basada en hash significa que las consultas basadas en rangos en la clave shard son menos probables de apuntar a un mismo shard, lo que puede resultar en más operaciones de broadcast en el cluster (para encontrar los datos, por ejemplo).

En el siguiente esquema se muestra la distribución basada en hash.

Sharding por rangos

Se divide los datos en rangos basados en los valores clave del shard. A cada fragmento se le asigna un rango basado en los valores clave del fragmento.

Con esta disposición es más probable que una gama de claves de shard cuyos valores sean “cercanos” residan en el mismo shard; lo que permite operaciones específicas ya que los mongos pueden enrutar las operaciones solo a los shards que contienen los datos requeridos.

La eficacia del particionado depende de la clave de shard elegida. Esto significa que las claves de fragmentos mal escogidas pueden dar lugar a una distribución desigual de los datos, lo que puede anular algunos beneficios del particionado o pueden causar cuellos de botella.

En el siguiente esquema se muestra la distribución basada en rangos.

Zonas de Sharding en los clústeres

Se pueden crear zonas de datos en función de la clave del shard: asociando una zona a uno o más shards en el clúster. De hecho, un mismo shard se puede asociar con varias zonas no conflictivas.

El siguiente esquema muestra una distribución por zonas:

En un clúster balanceado, MongoDB migra chunks cubiertos por una zona solo a los shards asociados con la zona.

Cada zona cubre uno o más rangos de claves de shard. Cada rango de zona siempre incluye su límite inferior y excluye su límite superior

Se debe usar los campos contenidos en la clave del shard cuando se define un nuevo rango para que abarque una zona. Si se usa una clave compuesta de shard, el rango debe incluir el prefijo de la clave.

Al elegir una clave de shard, se debe considerar cuidadosamente la posibilidad de utilización de división de zonas en el futuro, ya que una vez particionada la colección, no se puede cambiar la clave de shard.

Las zonas sirven para mejorar la localización de datos para clústeres que abarcan varios data centers.

Reflexiones finales

Tal como hemos observado en este artículo, el sharding es una técnica que nos puede ayudar a lograr los objetivos planteados para los sistemas Big Data.

Mongo nos ofrece una arquitectura que nos permitirá implementar esta técnica y usarla en conjunto con la replicación.

No obstante deberemos diseñar con cuidado la estrategia de sharding y elegir en consecuencia la clave de shard que usaremos, ya que tiene implicaciones tanto en el rendimiento, como en la disponibilidad.

Además en Mongo, una vez elegida la clave de shard, no se puede cambiar.

Una buen diseño de clave debe tomar en cuenta el “cómo se usarán los datos”, es decir las queries que se realizarán al sistema. Asimismo, deberemos visualizar su uso a futuro para determinar, por ejemplo, si usamos zonas.

En el siguiente artículo veremos la configuración técnica de Mongo en modo sharding.