En el artículo anterior, explicaba el concepto de sharding con una baraja de cartas. Básicamente el sharding trata de repartir los documentos entre servidores. De esta manera la carga se distribuye, ya que el documento solo se insertará en uno de los servidores.

Para repartir los documentos se utiliza lo que se conoce como sharding key. Esta clave no es más que un campo de MongoDB (o varios, en realidad), que nos permite decidir en qué servidor debe almacenarse el documento. El encargado de esta decisión es un proceso conocido como mongos, que recibe las peticiones y las envía al servidor correcto.

Elegir una sharding key, es seguramente la parte más importante cuándo queremos habilitar el sharding. El rendimiento de la base de datos dependerá de la clave que elijamos. Además eliminar una sharding key una vez establecida puede ser una experiencia poco recomendable. Así que mejor estar muy seguros de hacer una buena elección.

Es importante destacar, que los campos que se incluyan en una sharding key deberán tener un índice. Si quieres saber más sobre los índices en MongoDB, puedes consultar el artículo que escribí sobre los índices.

Puntos a tener en cuenta a la hora de elegir nuestra sharding key

Lo primero a tener en cuenta es qué queremos mejorar con el sharding. Si queremos mejorar la latencia de las escrituras, quizá nos interese dividir los datos de forma geográfica. Es decir, escribir en un servidor cercano. Si en cambio lo que queremos es mejorar la velocidad de escrituras o lecturas indistintamente, buscaremos dividir los datos de forma paralela. Así la carga se reparte equitativamente entre los servidores.

También podemos buscar la optimización de recursos. Por ejemplo optimizar la RAM. Para ello deberemos tener un conjunto de registros pequeño por cada servidor. Es decir, tendremos más servidores, con menos potencia, pero con menos datos que manejar. Eso sí, sin olvidarnos de cuántos shards (servidores) necesitamos realmente. Tener muchos incrementará la complejidad.

Y para terminar, hay que tener en cuenta el tipo de consultas que vamos a realizar. Para que el particionado sea efectivo, lo ideal es que las consultas se realicen sólo sobre uno de los shards. Esto implica que en las consultas deberemos incluir la sharding key. Si por ejemplo nuestra clave es el nombre de usuario, pero solo realizamos las búsquedas por fecha, la consulta se ejecutará en todos los servidores, perdiendo algunas de las ventajas del sharding. No hay que olvidar, que el tiempo de respuesta de las consultas estará determinado por el servidor más lento, ya que MongoDB tiene que esperar la respuesta de todos los servidores

Tipos de sharding key

Aunque la clave puede ser cualquier campo de nuestros documentos, podríamos decir que los tipos de claves los podemos englobar en los siguientes: claves ascendentes, aleatorias, basadas en localización y compuestas.

Claves ascendentes

En este caso elegimos un campo que va creciendo con cada inserción. Esto sucede si usamos, por ejemplo, ObjectId o un campo fecha. Al ser valores incrementales, el documento siempre se insertará en el último shard. Esto tiene algunas ventajas, pero en general da más problemas que otra cosa. Para mantener los shards balanceados, MongoDB estará moviendo documentos de un shard a otro de forma continua, para mantener la distribución. Estos movimientos van a perjudicar el rendimiento. En especial si buscamos escalar las escrituras, ya que estas irán siempre al mismo servidor.

Claves aleatorias

Son campos que tienen un valor aleatorio, y son únicos en cada inserción. GUIDS, MD5 o similares. Con claves de este tipo, las escrituras se van repartiendo de forma homogénea entre los distintos servidores. De esta manera se reducen mucho los movimientos de documentos entre shards. Lo malo de estas claves, es que hacer consultas sobre ellas no siempre es fácil. Como hemos dicho antes, lo ideal es que en la consulta vaya la clave, pero quizá esto no sea siempre posible, al ser el campo único.

Si no tenemos ningún campo único, podemos utilizar un hashed index como sharding key.

Claves basadas en localización

Ya hemos comentado, que en ocasiones podemos necesitar que los documentos se almacenen en base a su localización. Por ejemplo por IP, latitud, longitud etc. Aunque podemos hacerlo directamente, MongoDB distribuirá equitativamente los documentos como si de una clave ascendente se tratara. Esto no es deseable. Para solucionar esto, añadiremos tags.

Los tags permiten indicar de forma manual los rangos mínimo y máximo que tiene cada shard. Así podríamos añadir un rango de IP que vaya de la 192.0.0.0 a la 192.255.255.255 de manera que los documentos cuyo campo IP pertenezcan a ese rango, queden todos en el mismo servidor.

Claves compuestas

Aquí en lugar de utilizar un solo campo de un documento MongoDB, utilizaremos varios. Lo ideal es encontrar la manera de repartir equitativamente los documentos entre shards, pero que además las búsquedas se realicen exclusivamente sobre los servidores que tienen los datos.

Como ejemplo podemos pensar en una tienda online. La shard key estará compuesta por nombre de usuario (aleatorio) y el identificador del pedido (incremental). De esta manera los pedidos se distribuirán de forma homogénea al ser el usuario aleatorio, pero los datos de un mismo usuario estarán concentrados en pocos shards, lo que mejorará el tiempo de búsqueda de los pedidos.

Conclusiones

En definitiva, elegir la shard key de forma correcta es muy importante. Tanto que marcará el rendimiento futuro de nuestra base de datos.

Viendo las distintas posibilidades, quizá lo mejor sea utilizar claves compuestas (siempre que encontremos una buena manera de agrupar) o claves aleatorias.

En el próximo artículo sobre sharding, veremos como configurar los shards.

Imágen Tom Raftery

Recuerda que puedes ver el índice del tutorial y acceder a todos los artículos de la serie desde aquí.

¿Quiéres que te avisemos cuando se publiquen nuevas entradas en el blog?