¿Qué es el MongoDB Pre-Splitting?

pre_splitting

En los posts Two steps to shard a MongoDB collection y What is a MongoDB chunk? explicamos cómo se particiona una colección, qué es un chunk, cuál de ellos es movido de Shard cuando nuestro sistema no está balanceado y cuál será su shard destino.

En el post de hoy vamos a hacer uso de la técnica de pre-splitting, la cual nos permite tener creados los chunks, y distribuidos entre los shards, antes de comenzar a insertar datos.  Además, somos nosotros los que vamos a decidir a qué rango de datos debe estar referido cada chunk.

Cuándo se utiliza el pre-splitting

El pre-splitting es utilizado cuando necesitamos cargar una gran cantidad de datos en nuestra colección y queremos evitar a la base de datos todo el trabajo del split y del movimiento de chunks (balanceado). Nuestros datos serán insertados directamente en el shard que contenga el chunk referido a la clave que vamos a insertar.

En el siguiente ejemplo, en el que no hemos utilizado pre-splitting, vemos cómo MongoDB ha distribuido los chunks del namespace “school.students” entre los tres shards (s0, s1 y s2) de un cluster:

Sin haber intervenido nosotros MongoDB es el que hace el split del chunk, cuando este ha sobrepasado su tamaño máximo (64MB por defecto), el que escoge el chunk a mover y también cuál es su shard destino.

Vamos a utilizar la misma colección “school.students” en todo el post así que, lo primero que vamos a hacer es borrarla (también sus chunks) para poder empezar de nuevo. Lo haremos mediante el comando “drop”, ya que si utilizamos “remove” no eliminaremos sus chunks.

Ahora tenemos que particionar de nuevo la colección:

Si ejecutamos “sh.status()” comprobamos que efectivamente MongoDB sólo ha creado un chunk, el que recoge todo el rango de posibles valores para la shardkey (student_id) escogida. Además, vemos también que ese chunk reside en el shard s0, que es al que pertenece la base de datos “school”.

Estableciendo el rango de los chunks

Ahora creamos nuestros chunks escogiendo su rango (en este caso cada uno de ellos acogerá 10.000 valores, hasta un máximo de 100.000):

Este es el resultado una vez ha terminado su trabajo el balanceador:

Ya hemos conseguido nuestro objetivo, que era tener creados los chunks (escogiendo su rango) y distribuidos entre los shards de nuestro cluster antes del volcado de nuestros datos.

En este momento, cada insert irá directamente al chunk/shard que le corresponda en función de su shardkey.

En el siguiente post veremos cómo podemos hacer para poder escoger el shard en el que queremos almacenar cada uno de nuestros datos.

Como siempre, vuestros comentarios son bienvenidos. Espero haber podido aportar un poco de conocimiento y que os haya sido útil.

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

2 + trece =