Principio de fragmentación de MongoDB y arquitectura detallada

¿Qué es la fragmentación de MongoDB?


La fragmentación de MongoDB se refiere a dividir la base de datos en varias partes y distribuirlas en diferentes máquinas, de modo que se puedan almacenar más datos y procesar más solicitudes sin un servidor potente.

La idea básica del sharding de MongoDB es dividir la colección en partes pequeñas, y estas partes se dispersan en varios fragmentos, y cada fragmento es solo responsable de una parte de los datos totales.

Para la aplicación, no es necesario saber qué fragmento corresponde a qué datos, o incluso que los datos hayan sido fragmentados. Cuando una aplicación consulta datos, solo necesita conectar un enrutador previo. Esta ruta previa obtiene los datos de destino consultando el servidor de configuración para obtener el fragmento de destino donde residen los datos.

El propósito de la fragmentación de MongoDB


Las aplicaciones de base de datos con un alto volumen de datos y rendimiento ejercerán una gran presión sobre el rendimiento de la máquina independiente. El gran volumen de consultas agotará la CPU de la máquina independiente, y la gran cantidad de datos ejercerá una mayor presión sobre el almacenamiento de la máquina independiente, lo que eventualmente agotará la memoria del sistema. En su lugar, cambie la presión al disco IO.

Para resolver estos problemas, existen dos enfoques básicos: el escalado vertical y el escalado horizontal.

Expansión vertical: agregue más CPU y recursos de almacenamiento para ampliar la capacidad.

Expansión horizontal: distribuya el conjunto de datos en varios servidores y la expansión horizontal se fragmenta.

La fragmentación proporciona una forma de manejar un alto rendimiento y grandes volúmenes de datos. El uso de fragmentos reduce la cantidad de solicitudes que debe manejar cada fragmento, por lo que al escalar horizontalmente, el clúster puede aumentar su capacidad de almacenamiento y rendimiento. Por ejemplo, al insertar un dato, la aplicación solo necesita acceder al fragmento que almacena los datos.

El uso de fragmentos reduce la cantidad de datos almacenados por fragmento. Por ejemplo, si la base de datos tiene un conjunto de datos de 1 TB y tiene 4 fragmentos, cada fragmento solo puede contener 256 GB de datos. Si hay 40 fragmentos, cada fragmento puede tener solo 25 GB de datos.

Arquitectura fragmentada de MongoDB


En la arquitectura de fragmentación de MongoDB, hay tres roles:

  • Mongos: Es el enrutador mencionado anteriormente, que es el módulo que trata con el cliente. Mongos en sí mismo no tiene ningún dato, y no sabe cómo procesar estos datos, pero los obtiene a través de Config Server;

  • Servidor de configuración: servidor de configuración, toda la información del nodo de fragmentos y parte de la información de configuración de las funciones de fragmentación se almacenan en el Servidor de configuración, que puede entenderse como metadatos de datos reales;

  • Sh

ard: la ubicación real de almacenamiento de datos, almacenada en Chunk.

Mongos本身并不持久化数据,所有Shard集群的元数据都会存储到Config Server里,而用户的数据会分散存储到各个Shard。Mongos启动后,会从Config Server加载元数据,开始提供服务,将用户的请求正确路由到对应的分片上。

Shard Key


可以说,Shard Key(中文翻译成片键)是MongoDB实现分片的依仗!

MongoDB中数据的分片以集合为基本单位,集合中的数据通过Shard Key被分成多部分。其实Shard Key就是在集合中选了一个键,用该键的值作为数据拆分的依据。

举个例子,假设有个存储人员信息的文档集合,如果选择名字"name"作为Shard Key,那么第一分片可能会存放名字以 A-F 开头的文档。第二分片存 G-P 开头的文档,第三分片存Q-Z的文档。

一个好的Shard Key对分片至关重要。

有一点需要注意,一个自增的Shard Key对写入和数据均匀分布不是很友好,因为自增的Shard Key总会在一个分片上写入,后续达到某个阀值才可能会写到别的分片上。但是反过来讲,按Shard Key查询(读取)会非常高效。

Supongo que te gusta

Origin blog.csdn.net/am_Linux/article/details/129677666
Recomendado
Clasificación