Estos contenidos se han traducido de forma automática para su comodidad, pero Huawei Cloud no garantiza la exactitud de estos. Para consultar los contenidos originales, acceda a la versión en inglés.
Cómputo
Elastic Cloud Server
Bare Metal Server
Auto Scaling
Image Management Service
Dedicated Host
FunctionGraph
Cloud Phone Host
Huawei Cloud EulerOS
Redes
Virtual Private Cloud
Elastic IP
Elastic Load Balance
NAT Gateway
Direct Connect
Virtual Private Network
VPC Endpoint
Cloud Connect
Enterprise Router
Enterprise Switch
Global Accelerator
Gestión y gobernanza
Cloud Eye
Identity and Access Management
Cloud Trace Service
Resource Formation Service
Tag Management Service
Log Tank Service
Config
Resource Access Manager
Simple Message Notification
Application Performance Management
Application Operations Management
Organizations
Optimization Advisor
Cloud Operations Center
Resource Governance Center
Migración
Server Migration Service
Object Storage Migration Service
Cloud Data Migration
Migration Center
Cloud Ecosystem
KooGallery
Partner Center
User Support
My Account
Billing Center
Cost Center
Resource Center
Enterprise Management
Service Tickets
HUAWEI CLOUD (International) FAQs
ICP Filing
Support Plans
My Credentials
Customer Operation Capabilities
Partner Support Plans
Professional Services
Análisis
MapReduce Service
Data Lake Insight
CloudTable Service
Cloud Search Service
Data Lake Visualization
Data Ingestion Service
GaussDB(DWS)
DataArts Studio
IoT
IoT Device Access
Otros
Product Pricing Details
System Permissions
Console Quick Start
Common FAQs
Instructions for Associating with a HUAWEI CLOUD Partner
Message Center
Seguridad y cumplimiento
Security Technologies and Applications
Web Application Firewall
Host Security Service
Cloud Firewall
SecMaster
Data Encryption Workshop
Database Security Service
Cloud Bastion Host
Data Security Center
Cloud Certificate Manager
Situation Awareness
Managed Threat Detection
Blockchain
Blockchain Service
Servicios multimedia
Media Processing Center
Video On Demand
Live
SparkRTC
Almacenamiento
Object Storage Service
Elastic Volume Service
Cloud Backup and Recovery
Storage Disaster Recovery Service
Scalable File Service
Volume Backup Service
Cloud Server Backup Service
Data Express Service
Dedicated Distributed Storage Service
Contenedores
Cloud Container Engine
SoftWare Repository for Container
Application Service Mesh
Ubiquitous Cloud Native Service
Cloud Container Instance
Bases de datos
Relational Database Service
Document Database Service
Data Admin Service
Data Replication Service
GeminiDB
GaussDB
Distributed Database Middleware
Database and Application Migration UGO
TaurusDB
Middleware
Distributed Cache Service
API Gateway
Distributed Message Service for Kafka
Distributed Message Service for RabbitMQ
Distributed Message Service for RocketMQ
Cloud Service Engine
EventGrid
Dedicated Cloud
Dedicated Computing Cluster
Aplicaciones empresariales
ROMA Connect
Message & SMS
Domain Name Service
Edge Data Center Management
Meeting
AI
Face Recognition Service
Graph Engine Service
Content Moderation
Image Recognition
Data Lake Factory
Optical Character Recognition
ModelArts
ImageSearch
Conversational Bot Service
Speech Interaction Service
Huawei HiLens
Developer Tools
SDK Developer Guide
API Request Signing Guide
Terraform
Koo Command Line Interface
Distribución de contenido y cómputo de borde
Content Delivery Network
Intelligent EdgeFabric
CloudPond
Soluciones
SAP Cloud
High Performance Computing
Servicios para desarrolladores
ServiceStage
CodeArts
CodeArts PerfTest
CodeArts Req
CodeArts Pipeline
CodeArts Build
CodeArts Deploy
CodeArts Artifact
CodeArts TestPlan
CodeArts Check
Cloud Application Engine
aPaaS MacroVerse
KooPhone
KooDrive

Sharding

Actualización más reciente 2022-11-07 GMT+08:00

Puede fragmentar una colección de gran tamaño para una instancia de clúster fragmentada. Particionamiento distribuye los datos entre diferentes máquinas para aprovechar al máximo el espacio de almacenamiento y la capacidad de cómputo de cada shard.

Cantidad de particiones

A continuación se muestra un ejemplo usando la base de datos mytable, la colección mycoll y el name del campo como clave de shard.

  1. Inicie sesión en una instancia de clúster fragmentada con Mongo Shell.
  2. Habilite el sharding para las bases de datos que pertenecen a la instancia del clúster.

    • Método 1
      sh.enableSharding("<database>") 

      Ejemplo:

      sh.enableSharding("mytable")
    • Método 2
      use admin 
      db.runCommand({enablesharding:"<database>"})

  3. Shard una colección.

    • Método 1
      sh.shardCollection("<database>.<collection>",{"<keyname>":<value> })

      Ejemplo:

      sh.shardCollection("mytable.mycoll",{"name":"hashed"})
    • Método 2
      use admin
      db.runCommand({shardcollection:"<database>.<collection>",key:{"keyname":<value> }})
    Tabla 1 Descripción del parámetro

    Parámetro

    Descripción

    <database>

    Nombre de la base de datos

    <collection>

    Nombre de colección

    <keyname>

    Clave de shard

    Las instancias de clúster se fragmentan según el valor de este parámetro. Seleccione una clave de shard adecuada para la colección en función de sus requisitos de servicio. Para más detalles, consulte Selección de una clave de fragmento.

    <value>

    El orden basado en el rango de la clave de shard.
    • 1: Índices ascendentes
    • -1: Índices descendentes
    • hashed: indica que se utiliza el sharding de hash. El sharding de hash proporciona una distribución de datos más uniforme en todo el clúster sharded.

    Para obtener más información, consulte sh.shardCollection ().

  4. Compruebe el estado de almacenamiento de datos de la base de datos en cada shard.

    sh.status()

    Ejemplo:

Selección de una clave de fragmento

  • Antecedentes

    Cada clúster sharded contiene colecciones como su unidad básica. Los datos de la colección son particionados por la clave de shard. La clave de shard es un campo de la colección. Distribuye los datos de manera uniforme entre shards. Si no selecciona una clave de shard adecuada, el rendimiento del clúster puede deteriorarse y el proceso de ejecución de la sentencia de shard puede estar bloqueado.

    Una vez que se determina la clave de shard, no se puede cambiar. Si ninguna clave de fragmento es adecuada para el sharding, debe usar una política de sharding y migrar datos a una nueva colección para el sharding.

  • Características de las claves de shard apropiadas
    • Todas las inserciones, actualizaciones y eliminaciones se distribuyen uniformemente a todos los shards de un clúster.
    • La distribución de claves es suficiente.
    • Raras consultas de scatter-gather.

    Si la clave de shard seleccionada no tiene todas las características anteriores, la escalabilidad de lectura y escritura del clúster se ve afectada. Por ejemplo, si la carga de trabajo de la operación find () se distribuye de manera desigual en los shards, se generarán shards calientes. Del mismo modo, si su carga de escritura (insertos, actualizaciones y eliminaciones) no se distribuye uniformemente en tus shards, entonces podrías terminar con un shard caliente. Por lo tanto, debe ajustar las claves de shard en función de los requisitos de servicio, como el estado de lectura/escritura, los datos consultados con frecuencia y los datos escritos.

    Después de fragmentar los datos existentes, si filtro archivado de la solicitud de actualización no contiene claves de shard y upsert:true o multi:false, la solicitud de actualización reportará un error y devolverá el mensaje "Un upsert en una colección de shard debe contener la clave de shard y tener la simple intercalación".

  • Criterios de juicio
    Puede utilizar las dimensiones proporcionadas en Tabla 2 para determinar si las claves de shard seleccionadas cumplen con los requisitos de servicio:
    Tabla 2 Claves de shard razonables

    Criterios de identificación

    Descripción

    Cardinalidad

    La cardinalidad se refiere a la capacidad de dividir trozos. Por ejemplo, si necesita registrar la información del estudiante de una escuela y usar la edad como clave de shard, los datos de los estudiantes de la misma edad se almacenarán en un solo segmento de datos, lo que puede afectar el rendimiento y la capacidad de administración de sus clústeres. Una clave de shard mucho mejor sería el número de estudiante porque es único. Si el número de estudiante se utiliza como una clave de shard, la cardinalidad relativamente grande puede garantizar la distribución uniforme de los datos.

    Escribir la distribución

    Si se realizan un gran número de operaciones de escritura en el mismo período de tiempo, desea que la carga de escritura se distribuya uniformemente sobre los shards del clúster. Si la política de distribución de datos es sharding por intervalo, una clave de shard monótonamente creciente garantizará que todas las inserciones vayan a un solo shard.

    Leer la distribución

    De manera similar, si se realizan un gran número de operaciones de lectura en el mismo período, desea que su carga de lectura se distribuya uniformemente sobre los shards en un clúster para utilizar plenamente el rendimiento informático de cada shard.

    Lectura dirigida

    El router de consulta mongos puede realizar una consulta dirigida (consulta de solo un shard) o una consulta de dispersión/recopilación (consulta todos los shards). La única manera de que los mongos puedan apuntar a un solo shard es tener la clave de shard presente en la consulta. Por lo tanto, debe elegir una clave de shard que estará disponible para su uso en las consultas comunes mientras se ejecuta la aplicación. Si elige una clave de shard sintética y su aplicación no puede usarla durante consultas típicas, todas sus consultas se convertirán en scatter/gather, limitando así su capacidad de escalar la carga de lectura.

Elección de una política de distribución

Un clúster con fragmentos puede almacenar los datos de una colección en varios shards. Puede distribuir datos basados en las claves de shard de los documentos de la colección.

Hay dos políticas de distribución de datos: sharding por rango y sharding por hash. Para más detalles, consulte 3.

A continuación se describen las ventajas y desventajas de los dos métodos.

  • Sharding por rango

    El sharding basado en rango implica dividir los datos en intervalos contiguos determinados por los valores de clave del shard. Si asume que una clave de shard es una línea estirada desde el infinito positivo y el infinito negativo, cada valor de la clave de shard es la marca en la línea. También puede asumir segmentos pequeños y separados de una línea y que cada fragmento contiene datos de una clave de shard dentro de un rango determinado.

    Figura 1 Distribución de datos

    Como se muestra en la figura anterior, el campo x indica la clave de shard de sharding por rango. El rango de valores es [minKey,maxKey] y el valor es un entero. El rango de valores se puede dividir en múltiples fragmentos, y cada fragmento (normalmente 64 MB) contiene un pequeño segmento de datos. Por ejemplo, el fragmento 1 contiene todos los documentos en el rango [minKey, -75] y todos los datos de cada fragmento se almacenan en el mismo fragmento. Eso significa que cada shard contiene múltiples chunks. Además, los datos de cada shard se almacenan en el servidor de configuración y se distribuyen uniformemente por mongos en función de la carga de trabajo de cada shard.

    El sharding por rango puede cumplir fácilmente los requisitos de consulta en un cierto rango. Por ejemplo, si necesita consultar documentos cuya clave de shard está en el rango [-60,20], mongos solo necesita reenviar la solicitud al chunk 2.

    Sin embargo, si las claves de shard están en orden ascendente o descendente, es probable que los documentos recién insertados se distribuyan en el mismo chunk, lo que afecta a la expansión de la capacidad de escritura. Por ejemplo, si se usa _id como clave de fragmento, los bits altos de _id generados automáticamente en el clúster son ascendentes.

  • Sharding por hash

    El sharding por hash calcula el valor hash (entero de 64 bits) de un solo campo como valor de índice; este valor se utiliza como clave de shard para particionar datos en el clúster compartido. El sharding hashed proporciona una distribución de datos más uniforme en el clúster hashed, ya que es posible que los documentos con claves de shard similares no se almacenen en el mismo chunk.

    Figura 2 Distribución de datos

    El sharding hashed distribuye aleatoriamente documentos a cada chunk, lo que amplía completamente la capacidad de escritura y compensa la deficiencia del rango de shanrding. Sin embargo, las consultas en un cierto rango deben distribuirse a todos los shards de backend para obtener documentos que cumplan las condiciones, lo que resulta en una baja eficiencia de la consulta.

Utilizamos cookies para mejorar nuestro sitio y tu experiencia. Al continuar navegando en nuestro sitio, tú aceptas nuestra política de cookies. Descubre más

Comentarios

Comentarios

Comentarios

0/500

Seleccionar contenido

Enviar el contenido seleccionado con los comentarios