PDF de programación - Cluster Sharding MongoDB

MongoDB

Sharded Cluster

Carlos García Muñoz

1

Índice

1. Introducción
2. Definiciones y conceptos
2.1. MongoDB
2.1.1. ¿Qué es MongoDB?
2.1.2. ¿Cómo funciona MongoDB?
2.1.3. ¿Dónde no se debe usar MongoDB?
2.1.4. Características principales.
2.2. Sharded Cluster
2.2.1. Sharded Cluster o cluster fragmentado.
2.2.2. Sharding o fragmentar.
2.2.3. Shard Key o clave de fragmentación.
2.2.4. Chunks o trozos.
2.2.5. Ventajas de la fragmentación.
2.3. Consideraciones antes de la fragmentación.
2.4. Colecciones fragmentadas y no fragmentadas.
2.5. Conectarse a un clúster fragmentado.
2.6. Estrategia de fragmentado.
2.7. Zonas en clústeres fragmentados.
3. Creación y despliegue de un cluster fragmentado.
3.1. Config servers o servidores de configuración.
3.1.1. Replica set en los servidores de configuración
3.1.2. Operaciones de lectura y escritura.
3.1.3. Disponibilidad.
3.1.4. Configuración de los servidores
3.2. Servidores fragmentados o shard servers.
3.2.1 Configuración y despliegue de los servidores fragmentados.
3.3. Configuración y despliegue de un router mongos
4. Fragmentar una colección.
5. Balanceador del cluster.
6. Bibliografía.

3
4
4
4
4
4
5
6
6
7
7
8
8
9
9
10
10
11
13
13
13
14
15
15
18
19
21
22
24
25

2

1. Introducción

Las bases de datos no relacionales surgieron a raíz de la necesidad de almacenar de
forma rápida y sencilla cualquier tipo de información, sin importar el formato. Por lo
tanto las bases de datos no relacionales no necesitan de la existencia de un esquema para
guardar la información.

Otra de la ventajas que ofrecen estas bases de datos es la facilidad y sencillez de su
escalabilidad horizontal para hacer frente al constante crecimiento de los datos.

Las bases de datos no relacionales no son la solución a todos los problemas, pero en los
casos con gran variedad de datos y alto crecimiento de información son ideales.

Las características que presentan son las siguiente:

•

Pueden incorporar literalmente cualquier tipo de dato, al tiempo que
proporcionan todas las características necesarias para crear aplicaciones
ricas en contenido.

• El escalado está integrado en la base de datos. Es automático y

transparente. Pueden escalar a medida que crece el volumen de datos
agregando nuevos nodos sin ningún tipo de problema.

A continuación se explicará con detalle el sistema de bases de datos no relacional
Mongodb y su Cluster sharding que se utiliza para el escalado mencionado
anteriormente.

3

2. Definiciones y conceptos

2.1. MongoDB

2.1.1. ¿Qué es MongoDB?

MongoDB es una base de datos orientada a documentos. Esto quiere decir que en lugar
de guardar los datos en registros, guarda los datos en documentos. Estos documentos
son almacenados en BSON, que es una representación binaria de JSON.

Una de las diferencias más importantes con respecto a las bases de datos relacionales, es
que no es necesario seguir un esquema. Los documentos de una misma colección
(concepto similar a una tabla de una base de datos relacional ), pueden tener esquemas
diferentes.

Aunque las colecciones de MongoDB no necesitan definir un esquema, es importante
que diseñemos nuestra aplicación para seguir uno. Tendremos que pensar si necesitamos
normalizar los datos, desnormalizarlos o utilizar una aproximación híbrida. Estas
decisiones pueden afectar al rendimiento de nuestra aplicación. En definitiva el esquema
lo definen las consultas que vayamos a realizar con más frecuencia.

2.1.2. ¿Cómo funciona MongoDB?

MongoDB está escrito en C++, aunque las consultas se hacen pasando objetos JSON
como parámetro. Es algo bastante lógico, dado que los propios documentos se
almacenan en BSON.

MongoDB viene de serie con una consola desde la que podemos ejecutar los distintos
comandos. Esta consola está construida sobre JavaScript, por lo que las consultas se
realizan utilizando ese lenguaje. Además de las funciones de MongoDB, podemos
utilizar muchas de las funciones propias de JavaSciprt. En la consola también podemos
definir variables, funciones o utilizar bucles.

2.1.3. ¿Dónde no se debe usar MongoDB?

En esta base de datos no existen las transacciones. Aunque nuestra aplicación puede
utilizar alguna técnica para simular las transacciones, MongoDB no tiene esta
capacidad. Solo garantiza operaciones atómicas a nivel de documento. Si las
transacciones son algo indispensable en nuestro desarrollo, deberemos pensar en otro
sistema.

Tampoco existen los JOINS. Para consultar datos relacionados en dos o más
colecciones, tenemos que hacer más de una consulta. En general, si nuestros datos
pueden ser estructurados en tablas, y necesitamos las relaciones, es mejor que optemos
por un RDBMS clásico.

4

2.1.4. Características principales.

 Alto rendimiento.

MongoDB proporciona persistencia de datos de alto rendimiento. En Concreto:

- El soporte para modelos de datos incorporados reduce la actividad de E / S en el
sistema de base de datos.

- Los índices admiten consultas más rápidas y pueden incluir claves de documentos
incrustados y matrices.

 Lenguaje de consulta.

MongoDB admite un lenguaje de consulta enriquecido para dar soporte a las
operaciones de lectura y escritura (CRUD), así como:

- Agregación de datos.

- Búsqueda de texto y consultas geoespaciales.

 Alta disponibilidad.

La facilidad de replicación de MongoDB, llamada conjunto de réplicas, proporciona:

- Failover automático.

- Redundancia de datos.

Un conjunto de réplicas es un grupo de servidores MongoDB que mantienen el mismo
conjunto de datos, proporcionando redundancia y aumentando la disponibilidad de
datos.

 Soporte para múltiples motores de almacenamiento.

MongoDB soporta múltiples motores de almacenamiento, tales como WiredTiger y
MMAPv1.

Además, MongoDB proporciona una API de motor de almacenamiento, plugin que
permite a terceros desarrollar motores de almacenamiento para MongoDB.

 Escalabilidad horizontal.

MongoDB proporciona escalabilidad horizontal como parte de su funcionalidad
principal:

Sharding distribuye datos a través de un grupo de máquinas.
MongoDB soporta la creación de zonas de datos basadas en la clave shard. En un cluster
equilibrado, MongoDB dirige las lecturas y escrituras cubiertas por una zona sólo a
aquellos fragmentos dentro de la zona.

5

2.2. Sharded Cluster
2.2.1. Sharded Cluster o cluster fragmentado.

Un clúster sharded de MongoDB consta de los siguientes componentes:



Shard o fragmento: Cada fragmento contiene un subconjunto de los datos fragmentados.
Cada fragmento se puede implementar como un conjunto de réplicas.

 Mongos: Los mongos actúan como router de consulta, proporcionando una interfaz

entre las aplicaciones cliente y el clúster.



Servidores de configuración: los servidores de configuración almacenan los metadatos y
los valores de configuración del clúster. A partir de MongoDB 3.4, los servidores de
configuración deben implementarse como un conjunto de réplicas (CSRS).

El siguiente gráfico describe la interacción de componentes dentro de un clúster fragmentado:

MongoDB fragmenta los datos a nivel de colección, distribuyendo los datos de
recopilación a través de los fragmentos del clúster.

6

2.2.2. Sharding o fragmentar.

La fragmentación es un método para distribuir datos entre múltiples máquinas.
MongoDB utiliza la fragmentación para soportar despliegues con conjuntos de datos
muy grandes y operaciones de alto rendimiento.

Los sistemas de base de datos con grandes conjuntos de datos o aplicaciones de alto
rendimiento pueden desafiar la capacidad de un solo servidor. Por ejemplo, las altas
tasas de consulta pueden agotar la capacidad de la CPU del servidor.

Existen dos métodos para abordar el crecimiento del sistema: escalamiento vertical y
horizontal:

Escalado vertical implica el aumento de la capacidad de un solo servidor, como el uso
de una CPU más potente, añadir más memoria RAM, o aumentar la cantidad de espacio
de almacenamiento. Las limitaciones en la tecnología disponible pueden restringir que
una sola máquina sea suficientemente potente para una carga de trabajo determinada.
Además, los proveedores basados en la nube tienen techos rígidos basados en
configuraciones de hardware disponibles. Como resultado, existe un máximo práctico
para la escala vertical.

La escala horizontal implica dividir el conjunto de datos del sistema y la carga en varios
servidores, agregando servidores adicionales para aumentar la capacidad según sea
necesario. Aunque la velocidad o capacidad de una sola máquina puede no ser alta, cada
máquina maneja un subconjunto de la carga de trabajo global, proporcionando
potencialmente una mejor eficiencia que un único servidor de alta velocidad. La
ampliación de la capacidad de la implementación sólo requiere la adición de servidores
adicionales según sea necesario, lo que puede ser un costo total menor que el hardware
de gama alta para una sola máquina.

MongoDB soporta la escala horizontal a través de la fragmentación.

2.2.3. Shard Key o clave de fragmentación.

Para distribuir los documentos en una colección, MongoDB particiona la colección
usando la clave de fragmentación. La clave de fragmentación consiste en un campo o
campos inmutables que existen en cada documento de la colección de destino.

La clave de fragmentación se elige cuando se fragmenta una colección. La clave de
fragmentación no se puede cambiar después de la fragmentación de la colección, una
colección fragmentada solo puede tener una clave de fragmento.

Para fragmentar una colección no vacía, la colección debe tener un índice que comience
con la clave de fragmentación. Para las colecciones vacías, MongoDB crea el índice si
la colección aún no tiene un índice apropiado para la cla