Prueba del sharding en MongoDB

4
8818
En este tutorial, explicaremos los fundamentos del particionado de datos en MongoDB y configuraremos, a través de un sencillo script, una pequeña prueba de Sharding en nuestra propia máquina.

Índice de contenidos

1. Introducción y Objetivo

Junto con la réplica de datos, de la que ya hablamos en Réplica de datos en MongoDB, el particionado de datos, también conocido como Sharding, es otra de las funcionalidades que nos brinda MongoDB para gestionar la escalabilidad del almacenamiento de nuestros datos.

Con el Sharding conseguiremos distribuir la carga de datos a almacenar entre varios nodos de MongoDB, de forma que no todos los datos se almacenan en todos los nodos. Sin embargo, es importante conocer cómo funciona en detalle el sistema de particionado de datos y cómo las consultas se gestionan entre los distintos nodos, porque ello puede afectar en gran medida al rendimiento que obtengamos de nuestro sistema.

En este artículo explicaremos cómo configurar la réplica de datos (a través de ShardingTest) en MongoDB.

A lo largo del tutorial iremos viendo los pasos para montar un servicio de MongoDB configurado con el sharding activo usando tres instancias, en una misma máquina, entre las que particionaremos los datos.

Para ello se utilizará el propio API de MongoDB y la facilidad que nos proporciona para la configuración por defecto de la funcionalidad de sharding a través del objeto ShardingTest.

Los pasos que se presentan en el presente artículo NO constituyen la forma recomendada de configurar el particionado de datos, sino que pretenden mostrar cómo probar la funcionalidad de particionado de MongoDB de una forma sencilla. Por este motivo, este documento no debe utilizarse como guía para la configuración de entornos de producción.

Para configurar correctamente el particionado de datos en MongoDB, se debe configurar los mismos elementos que se levantan en este ejemplo de forma automática a través de ShardingTest, pero de forma específica y manual.

2. Requisitos

Para poder seguir las instrucciones de esta guía y probar el funcionamiento del Sharding en MongoDB, vamos a utilizar un servidor de MongoDB, que levantará varios procesos mongod en una misma máquina y sobre el que probaremos a insertar datos y comprobar cómo estos se van repartiendo a través de los distintos nodos que forman parte del grupo de Sharding.

Para realizar el proceso, utilizaremos la consola de Mongo y el API JavaScript que ofrece esta consola.

Por tanto, el único requisito es tener una versión de MongoDB instalada. Se requiere que sea al menos la versión 2.2, dado que es la primera versión donde el API incluye el objeto ShardingTest, con la estructura de la que nos valdremos para configurar las pruebas de particionado de datos.

3. Arranque y acceso a la consola con Mongo Shell

Para iniciar la prueba de Sharding necesitamos arrancar una primera consola de Mongo, desde la que iremos levantando los nodos que configuraremos para el grupo de particionado.

Por este motivo, necesitamos arrancar la consola de mongo sin conectar contra ningún servidor en concreto. Esto lo conseguimos con el parámetro --nodb

$ mongo --nodb
MongoDB shell version: 3.2.0
>

Es preferible que no tengamos una instancia de MongoDB previamente arrancada, las distintas instancias que formarán parte del grupo de particionado de prueba se irán levantando durante el proceso del script.

4. Creación del grupo de particionado para pruebas

Para probar el mecanismo de réplica de MongoDB, necesitaremos crear varias instancias de mongod que actúen como servidores y relacionarlas de forma que sepan repartirse los datos entre ellas.

El Sharding permite dividir la carga de almacenamiento de datos entre varios nodos, de forma que no todos los datos se almacenan en todos los nodos. Es decir, cada nodo, guarda un subconjunto total de los datos, de forma que el escalado horizontal de la BD es más sencillo de realizar.

MongoDB, con el Sharding, tratará de que, en la medida de lo posible, los datos se repartan de la forma más homogénea posible entre todos los nodos. El objetivo es conseguir que todos los nodos tengan más o menos el mismo volumen de datos, sin que se descompense ninguno de ellos. Aunque para conseguirlo, es necesario que tengamos en cuenta cómo funciona este particionado y lo configuremos en base a atributos que permitan hacer más homogénea dicha división de datos.

Para el grupo de Sharding, MongoDB necesita tener almacenada, en otra BD, la configuración del grupo de particionado, para saber cómo se han repartido los datos (lo que permitirá optimizar las consultas), qué nodos forman parte del grupo de particionado (lo que permitirá optimizar las inserciones) y cuál es la política de particionado, entre otra información.

Esta información sobre la “geometría de cómo se particionan los datos”, se almacena habitualmente en una instancia específica de MongoDB, que sirve para guardar esta configuración.

Esta BD de configuración del particionado de datos es crítica para el funcionamiento y rendimiento de todo el sistema de sharding, dado que si esta base de datos se para, se pierde o se corrompe, el grupo de particionado no podrá saber dónde tiene que insertar, cómo tiene que dividir o dónde tiene que redirigir las operaciones de consulta.

Por este motivo, habitualmente la base de datos de configuración del sharding, se configura en modo de réplica (como ya describimos en el tutorial sobre Prueba de RéplicaSet en MongoDB).

En este proceso de levantar el Sharding, el objeto ShardingTest creará y levantará tantas instancias de mongod como nodos indiquemos que queremos utilizar para configurar nuestras pruebas del particionado de datos.
Además, el objeto ShardingTest también creará las instancias de mongod necesarias para guardar la configuración en un ReplicaSet.

Para levantar el clúster de réplica, desde la consola mongo que tenemos abierta, escribiremos el siguiente comando:

> cluster = new ShardingTest({shards : 3, chunksize : 1})

Con este comando indicamos que se cree un objeto ShardingTest que contiene el conjunto de procesos mongod que formarán parte del particionado de datos, así como las instancias mongod para la base de datos de configuración en modo réplica.

Como parámetro a construir el ShardingTest podemos personalizar la configuración de las instancias que formarán parte del particionado de datos. Las opciones de configuración completas se pueden consultar en la documentación de ShardingTest.

A diferencia de lo que ocurre con la creación de un grupo de réplica de prueba, a través de ReplSetTest, en el caso de un ShardingTest, al crearlo, directamente se instancian ya todos las instancias del demonio de mongo necesarias.

Vemos esta información en algunos de los fragmentos que obtendremos en las trazas (en la consola salen muchas más trazas, pero mostramos sólo las partes más descriptivas):

	> cluster = new ShardingTest({shards : 3, chunksize : 1})
	Resetting db path '/data/db/test0'
	2016-02-26T11:08:31.616+0100 I -        [thread1] shell: started program (sh8317):  mongod --dbpath /data/db/test0 --port 20000 --setParameter enableTestCommands=1
	d20000| 2016-02-26T11:08:31.698+0100 I CONTROL  [initandlisten] MongoDB starting : pid=8317 port=20000 dbpath=/data/db/test0 64-bit host=Irensaga-2.local
	d20000| 2016-02-26T11:08:31.699+0100 I CONTROL  [initandlisten] db version v3.2.0
	d20000|
	[...]
	ReplSetTest Starting Set
	ReplSetTest n is : 0
	{
		"useHostName" : true,
		"oplogSize" : 40,
		"keyFile" : undefined,
		"port" : 20003,
		"noprealloc" : "",
		"smallfiles" : "",
		"replSet" : "test-configRS",
		"dbpath" : "$set-$node",
		"pathOpts" : {
			"testName" : "test",
			"node" : 0,
			"set" : "test-configRS"
		},
		"journal" : "",
		"configsvr" : "",
		"noJournalPrealloc" : undefined,
		"storageEngine" : "wiredTiger",
		"restart" : undefined
	}
	ReplSetTest Starting....
	Resetting db path '/data/db/test-configRS-0'
	2016-02-26T11:08:35.250+0100 I -        [thread1] shell: started program (sh8320):  mongod --oplogSize 40 --port 20003 --noprealloc --smallfiles --replSet test-configRS --dbpath /data/db/test-configRS-0 --journal --configsvr --storageEngine wiredTiger --setParameter enableTestCommands=1
	2016-02-26T11:08:35.251+0100 W NETWORK  [thread1] Failed to connect to 127.0.0.1:20003, reason: errno:61 Connection refused
	[...]

Lo primero es que vemos que se levantan la base de datos de configuración y configurada en modo réplica.

Al finalizar el arranque de esta base de datos de configuración, podemos ver la estructura de instancias de mongod para sharding que se almacena en la propia base de datos de configuración:

	ShardingTest test :
	{
		"config" : "test-configRS/Irensaga-2.local:20003,Irensaga-2.local:20004,Irensaga-2.local:20005",
		"shards" : [
			connection to Irensaga-2.local:20000,
			connection to Irensaga-2.local:20001,
			connection to Irensaga-2.local:20002
		]
	}

En ella podemos ver los elementos que hemos descrito antes:

  • Base de datos config: en modo replicaSet con nombre test-configRS y con tres nodos en el grupo de réplica para el almacenamiento de dicha configuración:
    • mongod en el puerto 20003,
    • mongod en el puesto 20004
    • mongod en el puerto 20005
  • Tres instancias, denominadas “shards”, para los nodos entre los que se realizará el particionado de datos:
    • mongod en el puerto 20000
    • mongod en el puerto 20001
    • mongod en el puerto 20002

También podemos ver en otro fragmento de las trazas, cómo se arrancan los procesos mongod que forman los shards.

Por último, se levantará un proceso mongos, que actúa como balanceador y que es el encargado de recibir las peticiones de consulta y las operaciones de escritura/modificación y, tras consultar en la BD de configuración los shards y la división de datos que se ha realizado, es capaz de redirigir la consulta al proceso (o al conjunto de procesos) mongod adecuados:

	s20006| 2016-02-26T11:08:55.671+0100 I SHARDING [mongosMain] MongoS version 3.2.0 starting: pid=8323 port=20006 64-bit host=Irensaga-2.local (--help for usage)
	s200

Al final de este proceso, podemos ver la comprobación final, que realiza el balanceador (el proceso mongos) de carga entre los nodos y que se irá repitiendo cada cierto tiempo para comprobar:

  • El número de shards que están definidos en la base de datos de configuración,
  • El tamaño del bloque (chunksize) donde se agrupan los datos particionados en cada shard
  • La necesidad o no de hacer un balanceo de datos (en el caso de que un nodo del shard tenga muchos más datos que otro).
  • Por último, comprueba que el grupo de réplica para la base de datos de configuración está vivo.
	s20006| 2016-02-26T11:09:13.055+0100 D SHARDING [Balancer] found 3 shards listed on config server(s)
	s20006| 2016-02-26T11:09:13.055+0100 D SHARDING [Balancer] Refreshing MaxChunkSize: 1MB
	s20006| 2016-02-26T11:09:13.056+0100 D SHARDING [Balancer] skipping balancing round because balancing is disabled
	s20006| 2016-02-26T11:09:15.679+0100 D NETWORK  [ReplicaSetMonitorWatcher] checking replica set: test-configRS

Este chequeo se irá repitiendo cada cierto tiempo, y se volcará en la consola de mongo que hemos abierto para arrancar el objeto ShardingTest.

Podemos comprobar las instancias de mongod que se han levantado.

	$ ps -ef | grep mongo
	  501  8922  8337   0  4:35PM ttys000    0:30.02 mongod --dbpath /data/db/test0 --port 20000 --setParameter enableTestCommands=1
	  501  8923  8337   0  4:35PM ttys000    0:29.97 mongod --dbpath /data/db/test1 --port 20001 --setParameter enableTestCommands=1
	  501  8924  8337   0  4:35PM ttys000    0:29.78 mongod --dbpath /data/db/test2 --port 20002 --setParameter enableTestCommands=1
	  501  8925  8337   0  4:35PM ttys000    0:40.86 mongod --oplogSize 40 --port 20003 --noprealloc --smallfiles --replSet test-configRS --dbpath /data/db/test-configRS-0 --journal --configsvr --storageEngine wiredTiger --setParameter enableTestCommands=1
	  501  8926  8337   0  4:35PM ttys000    0:39.35 mongod --oplogSize 40 --port 20004 --noprealloc --smallfiles --replSet test-configRS --dbpath /data/db/test-configRS-1 --journal --configsvr --storageEngine wiredTiger --setParameter enableTestCommands=1
	  501  8927  8337   0  4:35PM ttys000    0:39.02 mongod --oplogSize 40 --port 20005 --noprealloc --smallfiles --replSet test-configRS --dbpath /data/db/test-configRS-2 --journal --configsvr --storageEngine wiredTiger --setParameter enableTestCommands=1
	  501  8928  8337   0  4:35PM ttys000    0:11.56 mongos --configdb test-configRS/Irensaga-2.local:20003,Irensaga-2.local:20004,Irensaga-2.local:20005 -v --chunkSize 1 --port 20006 --setParameter enableTestCommands=1

Vemos en esta salida los procesos mongod arrancados para representar los nodos que forman parte del Sharding (los tres primeros), los nodos que actuarán en modo de réplica para almacenar la base de datos de configuración (del 4 al 6) y el proceso mongos (el último) que actúa como balanceador.

5. Prueba del particionado de datos y distribución entre los nodos del Shard

Una vez levantado el Sharding en Mongo DB, realizaremos las pruebas de inserción de datos para comprobar cómo se realiza el particionado.

5.1. Inserción de datos sobre el balanceador

Para actuar sobre el conjunto de Sharding, arrancaremos una nueva consola cliente de mongo contra el balanceador:

	$ mongo --port 20006
	MongoDB shell version: 3.2.0
	connecting to: 127.0.0.1:20006/test
	mongos>

Conectamos al balanceador, que actuará a todos los efectos como nuestro servidor MongoDB que representa el conjunto de Shards completo.

Ejecutamos una inserción de documentos, en este caso vamos a simular una inserción de entradas en un blog (por ejemplo 100.000 entradas parece un buen número para probar)

	mongos> for (i = 0; i < 100000; i++) {
	... db.blog_posts.insert({
	...     author : "author" + i,
	...     post_title : "Blog Post by Author " + i,
	...     date : new Date()
	...     });
	... }

Esta operación tardará un tiempo; pero al cabo de unos segundos obtendremos la confirmación de que se ha realizado la inserción

	WriteResult({ "nInserted" : 1 })
	mongos>

Podemos comprobar el número de datos insertados, de forma global entre todos los nodos del Shard, consultando directamente a través de la conexión al balanceador:

	mongos> db.blog_posts.count();
	100000

Como salida del comando obtenemos el número total de documentos almacenados en la colección blog_posts entre todos los nodos del Shard.

5.2. Comprobación (fallida) de la distribución de datos entre los nodos

Desde el balanceador, siempre tenemos la visión del conjunto de datos completo, para ver cómo se ha producido de forma efectiva la distribución de datos entre los distintos nodos, podemos conectarnos a los distintos procesos que forman parte del Shard.

Para ello, abriremos una nueva consola de Mongo desde la que nos conectaremos a cada uno de los nodos con objetos distintos.:

	$ mongo --nodb
	MongoDB shell version: 3.2.0
	>

Desde esta consola, comenzamos por conectarnos al primero de los nodos del shard, el que se ha levantado escuchando en el puerto 20.000, obtenemos el acceso a la BD de test que se mantiene en este primer nodo, y consultamos el número de registros guardados en ella.

	> shard1 = new Mongo("localhost:20000")
	connection to localhost:20000
	> shard1DB = shard1.getDB("test")
	test
	> shard1DB.blog_posts.count()
	100000
	>

Repetimos la misma secuencia para comprobar los registros que se han almacenado en la base de datos del segundo nodo del Shard:

	> shard2 = new Mongo("localhost:20001")
	connection to localhost:20001
	> shard2DB = shard2.getDB("test")
	test
	> shard2DB.blog_posts.count()
	0

Por último, comprobamos sobre el tercer nodo del Shard.

	> shard3 = new Mongo("localhost:20002")
	connection to localhost:20002
	> shard3DB = shard3.getDB("test")
	test
	> shard3DB.blog_posts.count()
	0

Según esta comprobación, todos los documentos que insertamos se han almacenado en el primer nodo del shard, y los nodos 2 y 3 no contienen ningún documento en la colección blog_posts.

Según estas pruebas, podríamos concluir que el particionado de datos no funciona porque, de hecho, no se ha producido ningún tipo de reparto de datos entre los distintos nodos y el desequilibrio es obvio.

Antes de concluir que el Sharding en MongoDB no funciona, debemos saber que, por defecto, al crear el objeto para las pruebas de Sharding, no se activa el particionado y éste es el motivo de que no se reparta la carga de datos entre todos los nodos.

En el siguiente apartado veremos cómo activar el particionado en el Shard, comprobaremos cómo el balanceador detecta el desequilibrio y cómo entra en acción para corregir dicho desequilibrio moviendo datos entre los nodos y repartiendo la carga.

5.3. Activación del Sharding

Para activar la funcionalidad de particionado de datos, debemos actuar sobre el balanceador. Por tanto, volveremos a la consola de mongo que hemos arrancado contra la instancia de mongos (que corría en el puerto 20006).

En dicha consola, podremos comprobar, a través de la función status(), el estado del grupo de Sharding:

	mongos> sh.status()
	--- Sharding Status ---
	  sharding version: {
		"_id" : 1,
		"minCompatibleVersion" : 5,
		"currentVersion" : 6,
		"clusterId" : ObjectId("56d070bc76ad433b3068863d")
	}
	  shards:
		{  "_id" : "shard0000",  "host" : "Irensaga-2.local:20000" }
		{  "_id" : "shard0001",  "host" : "Irensaga-2.local:20001" }
		{  "_id" : "shard0002",  "host" : "Irensaga-2.local:20002" }
	  active mongoses:
		"3.2.0" : 1
	  balancer:
		Currently enabled:  no
		Currently running:  no
		Failed balancer rounds in last 5 attempts:  0
		Migration Results for the last 24 hours:
			No recent migrations
	  databases:
		{  "_id" : "test",  "primary" : "shard0000",  "partitioned" : false }

	mongos>

En este caso vemos, efectivamente, que el balanceador (el proceso que reparte la carga de datos entre los distintos nodos) no está activo (propiedad balancer: Currently enabled : no y balancer: Currently running: no) y, de hecho el particionado de datos para el shard0000 (el nombre que se le ha dado automáticamente a nuestro shard al crear el ShardingTest) no está particionado (partitioned : false)

Para activar el sharding utilizaremos la función enableSharding() sobre la base de datos que queremos que reparta sus datos entre todos los nodos:

	mongos> sh.enableSharding("test")
	{ "ok" : 1 }
	mongos>

Pero no es suficiente sólo con activar el particionado de datos. El proceso de reparto, se basa en un atributo (o conjunto de atributos) en función del cual MongoDB creará grupos de datos (chunks) que irá moviendo entre los distintos nodos.

Este concepto de chunks o grupos de datos en el shard se verá mucho mejor cuando comprobemos cómo se ha realizado la creación de dichos chunks y su distribución entre los nodos.

Para indicar este atributo, debemos crear un índice sobre la colección que vamos a particionar. Esto lo realizamos con la función ensureIndex() indicando como argumento el atributo de los objetos de la colección por el que queremos realizar los grupos de datos antes de repartirlos.

Con la creación de este índice lo que hacemos es marcar la restricción de que todos los documentos de la colección contienen ese atributo.

	mongos> db.blog_posts.ensureIndex({author : 1})
	{
		"raw" : {
			"Irensaga-2.local:20000" : {
				"createdCollectionAutomatically" : false,
				"numIndexesBefore" : 1,
				"numIndexesAfter" : 2,
				"ok" : 1
			}
		},
		"ok" : 1
	}
	mongos>

Una vez creado el índice, y como último paso para que MongoDB comience a distribuir los documentos de la colección entre los nodos de Shard es, precisamente, realizar el particionado de la colección mencionada. Esto lo conseguimos con la función shardCollection(), donde especificaremos los siguientes atributos:

    • base de datos y colección a particionar
    • atributo (especificado como objeto JSON, el mismo que utilizamos para definir el índice) por el que se agruparán los objetos en chunks y se distribuirán esos chunks entre los nodos.
	mongos> sh.shardCollection("test.blog_posts", {author : 1})
	{ "collectionsharded" : "test.blog_posts", "ok" : 1 }
	mongos>

Si volvemos a comprobar el estado del grupo de particionado, otra vez con la función status(), esta vez comprobaremos que:

	mongos> sh.status()
	--- Sharding Status ---
	  sharding version: {
		"_id" : 1,
		"minCompatibleVersion" : 5,
		"currentVersion" : 6,
		"clusterId" : ObjectId("56d070bc76ad433b3068863d")
	}
	  shards:
		{  "_id" : "shard0000",  "host" : "Irensaga-2.local:20000" }
		{  "_id" : "shard0001",  "host" : "Irensaga-2.local:20001" }
		{  "_id" : "shard0002",  "host" : "Irensaga-2.local:20002" }
	  active mongoses:
		"3.2.0" : 1
	  balancer:
		Currently enabled:  no
		Currently running:  no
		Failed balancer rounds in last 5 attempts:  0
		Migration Results for the last 24 hours:
			No recent migrations
	  databases:
		{  "_id" : "test",  "primary" : "shard0000",  "partitioned" : true }
			test.blog_posts
				shard key: { "author" : 1 }
				unique: false
				balancing: true
				chunks:
					shard0000	20
				too many chunks to print, use verbose if you want to force print

En este caso el shard0000 está en modo particionado (partitioned : true), sin embargo el balancer (que es quien de forma efectiva moverá los datos) no se ha llegado a ejecutar.

De hecho, podemos comprobar su estado de ejecución con getBalancerState()

	> sh.getBalancerState()
	false
	mongos>

Ahora sólo nos queda conseguir que el balancer comience a ejecutarse, para ello, utilizamos la función setBalancerState(boolean).

	mongos> sh.setBalancerState(true)
	mongos> sh.getBalancerState()
	true
	mongos> sh.isBalancerRunning()
	true
	mongos>

En este momento, si nos movemos a la consola de mongo donde creamos el objeto ShardingTest, veremos que las trazas nos indican que el balanceador ha detectado el desequilibrio y está compensándolo:

	[NetworkInterfaceASIO-ShardRegistry-0] Successfully connected to Irensaga-2.local:20002
	s20006| 2016-02-26T18:32:40.178+0100 D SHARDING [Balancer] trying to acquire new distributed lock for balancer ( lock timeout : 900000 ms, ping interval : 30000 ms, process : Irensaga-2.local:20006:1456500921:-1570693962 ) with lockSessionID: 56d08c3876ad433b3068864a, why: doing balance round
	s20006| 2016-02-26T18:32:40.205+0100 I SHARDING [Balancer] distributed lock 'balancer' acquired for 'doing balance round', ts : 56d08c3876ad433b3068864a
	s20006| 2016-02-26T18:32:40.205+0100 D SHARDING [Balancer] *** start balancing round. waitForDelete: 0, secondaryThrottle: default
	s20006| 2016-02-26T18:32:40.211+0100 D SHARDING [Balancer] shard0002 has more chunks me:0 best: shard0001:0
	s20006| 2016-02-26T18:32:40.211+0100 D SHARDING [Balancer] collection : test.blog_posts
	s20006| 2016-02-26T18:32:40.211+0100 D SHARDING [Balancer] donor      : shard0000 chunks on 20
	s20006| 2016-02-26T18:32:40.211+0100 D SHARDING [Balancer] receiver   : shard0001 chunks on 0
	s20006| 2016-02-26T18:32:40.211+0100 D SHARDING [Balancer] threshold  : 4
	s20006| 2016-02-26T18:32:40.211+0100 I SHARDING [Balancer]  ns: test.blog_posts going to move { _id: "test.blog_posts-author_MinKey", ns: "test.blog_posts", min: { author: MinKey }, max: { author: "author14669" }, shard: "shard0000", lastmod: Timestamp 1000|0, lastmodEpoch: ObjectId('56d08a5276ad433b30688648') } from: shard0000 to: shard0001 tag []
	s20006| 2016-02-26T18:32:40.212+0100 I SHARDING [Balancer] moving chunk ns: test.blog_posts moving ( ns: test.blog_posts, shard: shard0000, lastmod: 1|0||56d08a5276ad433b30688648, min: { author: MinKey }, max: { author: "author14669" }) shard0000 -> shard0001
	c20005| 2016-02-26T18:32:40.218+0100 I NETWORK  [initandlisten] connection accepted from 192.168.168.151:55261 #14 (11 connections now open)

Estas trazas las veremos repetirse, según va moviendo más bloques entre los nodos.

Podemos ir comprobando cuando acaba de ejecutar su tarea el balancer, invocando al método isBalancerRunning() hasta que nos diga que ha acabado.

	mongos> sh.isBalancerRunning()
	true
	mongos>
	[...]
	mongos> sh.isBalancerRunning()
	false
	mongos>

5.4. Comprobación de la réplica de datos (correcto)

Una vez que ha acabado el balancer de equilibrar la carga de datos entre todos los nodos, podemos volver a repetir la consulta del apartado 5.2 y comprobaremos que esta vez el número de datos está más equilibrado.

Para ello, volvemos a la tercera consola de MongoDB, donde teníamos las tres conexiones a los tres nodos de mongod:

	> shard1DB.blog_posts.count()
	32518
	> shard2DB.blog_posts.count()
	36336
	> shard3DB.blog_posts.count()
	31146

Ahora sí, efectivamente, podemos ver que los datos están distribuidos entre los tres nodos teniendo cada uno de ellos, aproximadamente un tercio del total y que, entre los tres, suman el grupo completo de los mismos (32.518 + 36.336 + 31.146 = 100.000).

5.5. Consulta de la distribución de chunks entre nodos

Utilizando la consola abierta contra el balanceador, podemos comprobar la agrupación de datos en chunks (en base al atributo que se utiliza como clave en el particionado) la ubicación de cada grupo en los nodos.

Para obtener esta información, ejecutaremos la función status():

	mongos> sh.status(true)
	--- Sharding Status ---
	  sharding version: {
		"_id" : 1,
		"minCompatibleVersion" : 5,
		"currentVersion" : 6,
		"clusterId" : ObjectId("56d070bc76ad433b3068863d")
	}
	  shards:
		{  "_id" : "shard0000",  "host" : "Irensaga-2.local:20000" }
		{  "_id" : "shard0001",  "host" : "Irensaga-2.local:20001" }
		{  "_id" : "shard0002",  "host" : "Irensaga-2.local:20002" }
	  active mongoses:
		{  "_id" : "Irensaga-2.local:20006",  "ping" : ISODate("2016-02-26T19:20:45.956Z"),  "up" : NumberLong(13520),  "waiting" : true,  "mongoVersion" : "3.2.0" }
	  balancer:
		Currently enabled:  yes
		Currently running:  no
		Failed balancer rounds in last 5 attempts:  0
		Migration Results for the last 24 hours:
			13 : Success
	  databases:
		{  "_id" : "test",  "primary" : "shard0000",  "partitioned" : true }
			test.blog_posts
				shard key: { "author" : 1 }
				unique: false
				balancing: true
				chunks:
					shard0000	7
					shard0001	7
					shard0002	6
				{ "author" : { "$minKey" : 1 } } -->> { "author" : "author14669" } on : shard0001 Timestamp(2, 0)
				{ "author" : "author14669" } -->> { "author" : "author19340" } on : shard0002 Timestamp(3, 0)
				{ "author" : "author19340" } -->> { "author" : "author24011" } on : shard0001 Timestamp(4, 0)
				{ "author" : "author24011" } -->> { "author" : "author28685" } on : shard0002 Timestamp(5, 0)
				{ "author" : "author28685" } -->> { "author" : "author33356" } on : shard0001 Timestamp(6, 0)
				{ "author" : "author33356" } -->> { "author" : "author38028" } on : shard0002 Timestamp(7, 0)
				{ "author" : "author38028" } -->> { "author" : "author4270" } on : shard0001 Timestamp(8, 0)
				{ "author" : "author4270" } -->> { "author" : "author47372" } on : shard0002 Timestamp(9, 0)
				{ "author" : "author47372" } -->> { "author" : "author52043" } on : shard0001 Timestamp(10, 0)
				{ "author" : "author52043" } -->> { "author" : "author56716" } on : shard0002 Timestamp(11, 0)
				{ "author" : "author56716" } -->> { "author" : "author61388" } on : shard0001 Timestamp(12, 0)
				{ "author" : "author61388" } -->> { "author" : "author6606" } on : shard0002 Timestamp(13, 0)
				{ "author" : "author6606" } -->> { "author" : "author70731" } on : shard0001 Timestamp(14, 0)
				{ "author" : "author70731" } -->> { "author" : "author75403" } on : shard0000 Timestamp(14, 1)
				{ "author" : "author75403" } -->> { "author" : "author80075" } on : shard0000 Timestamp(1, 14)
				{ "author" : "author80075" } -->> { "author" : "author84748" } on : shard0000 Timestamp(1, 15)
				{ "author" : "author84748" } -->> { "author" : "author8942" } on : shard0000 Timestamp(1, 16)
				{ "author" : "author8942" } -->> { "author" : "author94091" } on : shard0000 Timestamp(1, 17)
				{ "author" : "author94091" } -->> { "author" : "author98764" } on : shard0000 Timestamp(1, 18)
				{ "author" : "author98764" } -->> { "author" : { "$maxKey" : 1 } } on : shard0000 Timestamp(1, 19)
	mongos>

En esta traza de consola podemos ver que esta vez el sharding activo y los números de grupos que contiene cada servidor (bajo la propiedad databases:chunks).

Si especificamos el nivel de detalle (pasando true como argumento a la función status()), obtendremos además la ubicación de cada chunk de datos(la lista de datos final bajo databases:chunks).

Por ejemplo, todos los documentos cuyo atributo author va desde el primero por orden natural (representado por "author" : { "$minKey" : 1 }) hasta el documento con valor del atributo author author14669, están ubicados en el nodo shard0001.

Todos los documentos con clave del author desde el author14669 al author19340 están ubicados en el nodo shard0002. Y así sucesivamente hasta los documentos con valor para el atributo author entre el author98764 y el valor máximo (representado por maxKey), que estarán ubicados en el nodo shard0000 del Shard.

6. Comprobación del mecanismo de distribución de consultas.

Toda la información sobre la agrupación de datos en chunks y la ubicación de estos sobre los distintos nodos del shard se almacenan en la base de datos de configuración (test-ConfigRS) que está, además, configurada en modo réplica dada su importancia.

Si se pierde o se corrompe esta información, mongoDB no podría, a priori, saber el estado del shard ni dónde tiene ubicados los distintos datos.

6.1. Consulta de un documento ubicado en un nodo concreto.

Internamente, MongoDB utiliza esta información de configuración para optimizar, en la medida de lo posible, las consultas sobre los distintos nodos del shard.

Así, una consulta o modificación sobre un documento buscandolo por el propio atributo que se ha definido para la división de datos (en nuestro caso por el atributo author) el balanceador puede saber a qué nodos dirigirla exclusivamente.

Podemos ver el plan de ejecución de la consulta de MongoDB, utilizando la función explain() sobre la propia consulta a realizar:

	mongos> db.blog_posts.find({author : "author 999"}).explain()
	{
		"queryPlanner" : {
			"mongosPlannerVersion" : 1,
			"winningPlan" : {
				"stage" : "SINGLE_SHARD",
				"shards" : [
					{
						"shardName" : "shard0000",
						"connectionString" : "Irensaga-2.local:20000",
						"serverInfo" : {
							"host" : "Irensaga-2.local",
							"port" : 20000,
							"version" : "3.2.0",
							"gitVersion" : "45d947729a0315accb6d4f15a6b06be6d9c19fe7"
						},
						"plannerVersion" : 1,
						"namespace" : "test.blog_posts",
						"indexFilterSet" : false,
						"parsedQuery" : {
							"author" : {
								"$eq" : "author 999"
							}
						},
						"winningPlan" : {
							"stage" : "FETCH",
							"inputStage" : {
								"stage" : "SHARDING_FILTER",
								"inputStage" : {
									"stage" : "IXSCAN",
									"keyPattern" : {
										"author" : 1
									},
									"indexName" : "author_1",
									"isMultiKey" : false,
									"isUnique" : false,
									"isSparse" : false,
									"isPartial" : false,
									"indexVersion" : 1,
									"direction" : "forward",
									"indexBounds" : {
										"author" : [
											"[\"author 999\", \"author 999\"]"
										]
									}
								}
							}
						},
						"rejectedPlans" : [ ]
					}
				]
			}
		},
		"ok" : 1
	}
	mongos>

En este caso, vemos que el proceso mongos, tras consultar la distribución de chunks en test-ConfigRS, sabe que la consulta afecta sólo a información contenida en el nodo shard0000.

7. Parada del cluster de particionado de datos

Por último, para parar nuestro ShardingTest, volveremos a la consola inicial, donde creamos el objeto que levantó todos los nodos y ejecutaremos la función stop() sobre el cluster que tenemos:

> cluster.stop()

Veremos como se comienza a enviar la secuencia de finalización de todos los procesos mongod y mongos y se van parando los distintos servicios.

	>cluster.stop()
	s20006| 2016-02-26T20:22:26.997+0100 I CONTROL  [signalProcessingThread] got signal 15 (Terminated: 15), will terminate after current cmd ends
	s20006| 2016-02-26T20:22:26.997+0100 D SHARDING [signalProcessingThread] CatalogManagerReplicaSet::shutDown() called.
	s20006| 2016-02-26T20:22:27.010+0100 D NETWORK  [ReplicaSetMonitorWatcher] checking replica set: test-configRS
	s20006| 2016-02-26T20:22:27.028+0100 I SHARDING [signalProcessingThread] dbexit:  rc:0
	d20002| 2016-02-26T20:22:27.029+0100 I NETWORK  [conn5] end connection 192.168.168.151:55256 (5 connections now open)
	d20001| 2016-02-26T20:22:27.029+0100 I NETWORK  [conn5] end connection 192.168.168.151:55251 (6 connections now open)
	d20000| 2016-02-26T20:22:27.029+0100 I NETWORK  [conn8] end connection 192.168.168.151:55246 (7 connections now open)
	c20003| 2016-02-26T20:22:27.029+0100 I NETWORK  [conn57] end connection 192.168.168.151:62693 (26 connec2016-02-26T20:22:27.029+0100 I NETWORK  [conn58] end connection 192.168.168.151:62698 (26 connections now open)
	d20001| 2016-02-26T20:22:27.029+0100 I NETWORK  [conn9] end connection 192.168.168.151:55320 (5 connections now open)
	d20000| 2016-02-26T20:22:27.029+0100 I NETWORK  [conn6] end connection 192.168.168.151:54606 (6 connections now open)
	c20003| 2016-02-26T20:22:27.029+0100 I NETWORK  [conn56] end connection 192.168.168.151:62688 (26 connections now open)
	d20000| 2016-02-26T20:22:27.029+0100 I NETWORK  [conn11] end connection 192.168.168.151:62500 (6 connections now open)
	c20003| 2016-02-26T20:22:27.029+0100 I NETWORK  [conn55] end connection 192.168.168.151:62683 (26 connections now open)
	d20000| 2016-02-26T20:22:27.029+0100 I NETWORK  [conn4] end connection 192.168.168.151:51425 (5 connections now open)
	c20003| 2016-02-26T20:22:27.029+0100 I NETWORK  [conn54] end connection 192.168.168.151:62678 (26 connections now open)


	[...]

	20005| 2016-02-26T20:22:39.409+0100 I STORAGE  [signalProcessingThread] shutdown: removing fs lock...
	c20005| 2016-02-26T20:22:39.409+0100 I CONTROL  [signalProcessingThread] dbexit:  rc: 0
	2016-02-26T20:22:40.039+0100 I -        [thread1] shell: stopped mongo program on port 20005
	ReplSetTest stop *** Mongod in port 20005 shutdown with code (0) ***
	ReplSetTest stopSet deleting all dbpaths
	ReplSetTest stopSet *** Shut down repl set - test worked ****
	*** ShardingTest test completed successfully in 13657.467 seconds ***

Anexo A. Resolución de problemas

A.1. Todos los datos siguen en el mismo nodo, pese a haber activado el sharding sobre la colección y activar el balancer.

El balanceador sólo activa la división de un chunk de datos en al menos otros dos más pequeños susceptibles de ser repartidos entre los nodos del shard, cuando se ha alcanzado un tamaño máximo en dicho chunk.

Este tamaño está expresado en el atributo chunksize que se pasa como argumento al construir el ShardingTest. El valor se expresa en Mb.

Para las pruebas, conviene asegurarse de que se ha arrancado el ShardingTest con un valor de 1Mb como tamaño máximo. De otro modo, tendríamos que insertar muchísimos más valores para alcanzar el tamaño máximo del chunk y provocar su división y movimiento a otro nodo.

cluster = new ShardingTest({shards : 3, chunksize : 1})
David Gómez García
Titulado en Ingeniería Técnica en Informática por la Universidad Politécnica de Madrid en 1998, David ha participado en proyectos para telecomunicaciones, comercio electrónico, banca, defensa y sistemas de transporte terrestre. Ha liderado proyectos de aplicaciones web, infraestructura SOA, aplicaciones java cliente y pasarelas de comunicación entre sistemas.

4 COMENTARIOS

  1. no me sirve man, entiendo todo pero lamentablemente me saca error tan solo ejecutar el comando para crear el cluster cluster = new ShardingTest({shards : 3, chunksize : 1})
    me manda el siguiente error

    Resetting db path ‘/data/db/test0’
    2017-11-05T20:29:10.482-0500 E QUERY [thread1] Error: Caught std::exception of type class boost::filesystem::filesystem_error: boost::filesystem::create_directory: El sistema no puede encontrar la ruta especificada: «/data/db/test0» :
    MongoRunner.runMongod@src/mongo/shell/servers.js:722:17
    ShardingTest@src/mongo/shell/shardingtest.js:1141:24
    @(shell):1:11

DEJA UNA RESPUESTA

Por favor ingrese su comentario!

He leído y acepto la política de privacidad

Por favor ingrese su nombre aquí

Información básica acerca de la protección de datos

  • Responsable:
  • Finalidad:
  • Legitimación:
  • Destinatarios:
  • Derechos:
  • Más información: Puedes ampliar información acerca de la protección de datos en el siguiente enlace:política de privacidad