Recomendaciones para la creación de particiones de datos

Artículo
11/15/2023

Se aplica a esta recomendación de lista de comprobación de confiabilidad de Azure Well-Architected Framework:

RE:06	Implemente una estrategia de escalado oportuna y confiable en los niveles de aplicación, datos e infraestructura.

Guía relacionada:Escalado

En esta guía se describen las recomendaciones para diseñar una estrategia de creación de particiones de datos para la tecnología de almacenamiento de datos y base de datos que implemente. Esta estrategia le ayuda a mejorar la confiabilidad del patrimonio de datos.

Estrategias de diseño principales

En muchas soluciones a gran escala, las particiones se usan para dividir los datos de modo que se pueda administrar y acceder a ellas por separado. La creación de particiones de datos mejora la escalabilidad, reduce la contención y optimiza el rendimiento. Implemente la creación de particiones de datos para dividir los datos por patrón de uso. Por ejemplo, puede archivar datos más antiguos en un almacenamiento de datos económico. Elija cuidadosamente la estrategia de creación de particiones para maximizar las ventajas y minimizar los efectos adversos.

Nota

En este artículo, el término creación de particiones hace referencia al proceso de dividir físicamente los datos en almacenes de datos independientes. Difiere de SQL Server creación de particiones de tablas.

¿Por qué es recomendable crear particiones de datos?

Mejorar la escalabilidad. Al escalar verticalmente un único sistema de base de datos, la base de datos finalmente alcanza un límite de hardware físico. Si divide los datos entre varias particiones, con cada partición hospedada en un servidor independiente, puede escalar horizontalmente el sistema casi indefinidamente.
Mejorar el rendimiento. En cada partición, las operaciones de acceso a datos se realizan en un volumen menor de datos en comparación con los datos que no tienen particiones. Particione los datos para que el sistema sea más eficaz. Las operaciones que afectan a más de una partición pueden ejecutarse en paralelo.
Mejorar la seguridad. En algunos casos, puede separar los datos confidenciales y no sensibles en distintas particiones y aplicar distintos controles de seguridad a los datos confidenciales.
Proporcionan flexibilidad operativa. Puede crear particiones de datos para ajustar las operaciones, maximizar la eficacia administrativa y minimizar el costo. Por ejemplo, puede definir estrategias para la administración, supervisión, copia de seguridad y restauración, y otras tareas administrativas en función de la importancia de los datos de cada partición.
Adaptación del almacén de datos al patrón de uso. Puede implementar cada partición en un tipo diferente de almacén de datos en función del costo y las características integradas que ofrece el almacén de datos. Por ejemplo, puede almacenar datos binarios grandes en Blob Storage y almacenar datos estructurados en una base de datos de documentos. Para más información, consulte Descripción de los modelos del almacén de datos.
Mejorar la disponibilidad. Para evitar un único punto de error, puede separar los datos entre varios servidores. Si se produce un error en una instancia, solo dejarán de estar disponibles los datos de esa partición. Las operaciones continúan en otras particiones. Esta consideración es menos relevante para los almacenes de datos de plataforma como servicio (PaaS) administrados porque tienen redundancia integrada.

Diseño de particiones

Hay tres estrategias típicas para crear particiones de datos:

Particiones horizontales (a menudo denominadas particionamiento). En esta estrategia, cada partición es un almacén de datos independiente, pero todas las particiones tienen el mismo esquema. Cada partición se conoce como partición y contiene un subconjunto de los datos, como un conjunto de pedidos de clientes.
Particionamiento vertical. En esta estrategia, cada partición contiene un subconjunto de los campos de elementos del almacén de datos. Los campos se dividen según su patrón de uso. Por ejemplo, los campos a los que se accede con frecuencia pueden colocarse en una partición vertical y los campos que se utilizan más raramente en otra.
Creación de particiones funcional. En esta estrategia, los datos se agregan según cómo cada contexto enlazado del sistema usa los datos. Por ejemplo, un sistema de comercio electrónico puede almacenar los datos de facturas en una partición y los del inventario de productos en otra.

Considere la posibilidad de combinar estas estrategias al diseñar un esquema de partición. Por ejemplo, puede dividir los datos en particiones y, a continuación, usar particiones verticales para subdividir todavía más los datos de cada partición.

Creación de particiones horizontales (particionamiento)

En la imagen siguiente se muestra un ejemplo de creación de particiones horizontales o particionamiento. En este ejemplo se dividen los datos de inventario de productos en particiones que se basan en la clave de producto. Cada partición contiene los datos de un intervalo contiguo de claves de partición (A-G y H-Z), organizadas alfabéticamente. Al realizar particionamiento, distribuye la carga en más equipos, lo que reduce la contención y mejora el rendimiento.

El factor más importante es la clave de particionamiento que elija. Puede resultar difícil cambiar la clave después de que el sistema está en funcionamiento. La clave debe garantizar que se crean particiones de datos para distribuir la carga de trabajo lo más uniforme posible entre las particiones.

Las particiones no tienen que tener necesariamente el mismo tamaño. Es más importante equilibrar el número de solicitudes. Algunas particiones pueden ser grandes, pero cada elemento de la partición tiene un número bajo de operaciones de acceso. Es posible que otras particiones sean más pequeñas, pero se accede con más frecuencia a cada elemento de la partición. También es importante asegurarse de que una sola partición no supere los límites de escala, en términos de capacidad y procesamiento de recursos, del almacén de datos.

Evite crear particiones activas que puedan afectar al rendimiento y la disponibilidad. Por ejemplo, si usa la primera letra del nombre de un cliente, puede crear una distribución desequilibrada porque algunas letras son más comunes que otras. En su lugar, use un hash de identificador de cliente para distribuir los datos uniformemente entre particiones.

Elija una clave de particionamiento que minimice la necesidad futura de dividir particiones grandes, combinar particiones pequeñas en particiones más grandes o cambiar el esquema. Estas operaciones consumen mucho tiempo y pueden requerir que se desconecte una o varias particiones.

Si se replican particiones, puede mantener algunas de las réplicas en línea mientras que otras se dividen, combinan o reconfiguran. Sin embargo, el sistema podría limitar las operaciones que se pueden realizar durante la reconfiguración. Por ejemplo, los datos de las réplicas podrían marcarse como de solo lectura para evitar incoherencias de datos.

Para más información, consulte Patrón de particionamiento.

Particiones verticales

El uso más común para la creación de particiones verticales es reducir los costos de E/S y rendimiento asociados a la captura de elementos a los que se accede con frecuencia. En la imagen siguiente se muestra un ejemplo de creación de particiones verticales. En este ejemplo, las diferentes propiedades de un elemento se almacenan en particiones distintas. Una partición contiene datos a los que se accede con más frecuencia, incluido el nombre del producto, la descripción y el precio. Otra partición contiene datos de inventario, incluido el recuento de existencias y la última fecha ordenada.

En este ejemplo, la aplicación consulta periódicamente el nombre, la descripción y el precio del producto cuando muestra los detalles del producto a los clientes. El recuento de existencias y la última fecha ordenada están en una partición independiente porque estos dos elementos se usan normalmente juntos.

Consulte las siguientes ventajas de la creación de particiones verticales:

Puede separar datos relativamente lentos (nombre de producto, descripción y precio) de datos más dinámicos (nivel de existencias y fecha de última pedido). Los datos de movimiento lento son un buen candidato para que una aplicación se almacene en caché en la memoria.
Puede almacenar datos confidenciales en una partición independiente con controles de seguridad agregados.
El particionamiento vertical puede reducir la cantidad de acceso simultáneo necesario.

La creación de particiones verticales funciona a nivel de entidad dentro de un almacén de datos, normalizando parcialmente una entidad para dividirla de un elemento amplio en un conjunto de elementos reducido. Es ideal para almacenes de datos orientados a columnas, como HBase y Cassandra. Si es poco probable que cambien los datos de una colección de columnas, considere la posibilidad de usar almacenes de columnas en SQL Server.

Creación de particiones funcional

Cuando se puede identificar un contexto enlazado para cada área de negocio distinta de una aplicación, la creación de particiones funcionales puede mejorar el aislamiento y el rendimiento del acceso a datos. Otro uso común de la creación de particiones funcional es separar los datos de lectura y escritura de los datos de solo lectura. En la imagen siguiente se muestra información general sobre la creación de particiones funcionales que tienen datos de inventario separados de los datos del cliente.

Esta estrategia de creación de particiones puede ayudar a reducir la contención de acceso a datos a través de distintas partes de un sistema.

Diseño de particiones para escalabilidad

Es fundamental tener en cuenta el tamaño y la carga de trabajo de cada partición. Equilibrelos para que los datos se distribuyan para lograr la máxima escalabilidad. Sin embargo, también debe particionar los datos para que no supere los límites de escalado de un único almacén de particiones.

Siga estos pasos al diseñar particiones para mejorar la escalabilidad:

Analice la aplicación para comprender los patrones de acceso a datos, como el tamaño del conjunto de resultados que devuelve cada consulta, la frecuencia de acceso, la latencia inherente y los requisitos de procesamiento de proceso del lado servidor. En muchos casos, algunas entidades principales exigen la mayoría de los recursos de procesamiento.
Use este análisis para determinar los objetivos de escalabilidad actuales y futuros, como el tamaño de los datos y la carga de trabajo. A continuación, distribuya los datos entre las particiones para cumplir el objetivo de escalabilidad. Para la creación de particiones horizontales, elija la clave de partición correcta para garantizar la distribución uniforme. Para obtener más información, consulte Patrón de particionamiento.
Asegúrese de que cada partición tenga suficientes recursos para controlar los requisitos de escalabilidad en términos del tamaño y el rendimiento de los datos. Según el almacén de datos, puede haber un límite para cada partición en la cantidad de espacio de almacenamiento, potencia de procesamiento o ancho de banda de red. Si es probable que los requisitos superen estos límites, es posible que tenga que refinar la estrategia de creación de particiones o dividir aún más los datos. Es posible que tenga que combinar dos o más estrategias.
Supervise el sistema para comprobar que los datos se distribuyen según lo previsto y que las particiones pueden controlar la carga. El uso real no siempre coincide con lo que predice un análisis. Es posible que tenga que reequilibrar las particiones o rediseñar algunas partes del sistema para producir el saldo necesario.

Algunos entornos en la nube asignan recursos en función de los límites de la infraestructura. Asegúrese de que los límites del límite seleccionado proporcionan suficiente espacio para el crecimiento previsto en el volumen de datos, el almacenamiento de datos, la potencia de procesamiento y el ancho de banda.

Por ejemplo, si usa Azure Table Storage, hay un límite en el volumen de solicitudes que una sola partición puede controlar en un período de tiempo determinado. Para más información, consulte Objetivos de escalabilidad y rendimiento para cuentas de almacenamiento estándar. Una partición ocupada puede requerir más recursos de los que una sola partición puede controlar. Es posible que tenga que volver a particionar la partición para distribuir la carga. Si el tamaño total o el rendimiento de estas tablas supera la capacidad de una cuenta de almacenamiento, es posible que tenga que crear más cuentas de almacenamiento y distribuir las tablas entre estas cuentas.

Diseño de particiones para el rendimiento de las consultas

Puede aumentar el rendimiento de las consultas mediante pequeños conjuntos de datos y la ejecución de consultas paralelas. Cada partición debe contener una pequeña proporción de todo el conjunto de datos. Esta reducción en el volumen puede mejorar el rendimiento de las consultas. Sin embargo, la creación de particiones no es una alternativa al diseño y la configuración adecuados de la base de datos. Asegúrese de implementar los índices necesarios.

Siga estos pasos al diseñar particiones para el rendimiento de las consultas:

Examine los requisitos y el rendimiento de la aplicación.
- Use requisitos empresariales para determinar las consultas más importantes que siempre deben ejecutarse rápidamente.
- Supervise el sistema para identificar las consultas que se realizan lentamente.
- Determine las consultas que realizan con más frecuencia. Incluso si una sola consulta tiene un costo mínimo, el consumo acumulativo de recursos puede ser significativo.
Particione los datos que causan un rendimiento lento.
- Limitar el tamaño de cada partición para que el tiempo de respuesta de la consulta se encuentre dentro del objetivo.
- Si usa particiones horizontales, diseñe la clave de partición para que la aplicación pueda seleccionar fácilmente la partición adecuada. Esta especificación impide que la consulta examina todas las particiones.
- Considerar la ubicación de una partición. Intente mantener los datos en particiones que están geográficamente cerca de las aplicaciones y los usuarios que acceden a ellos.
Si una entidad tiene requisitos de rendimiento y rendimiento de consultas, use la creación de particiones funcionales que se basen en esa entidad. Si esta asignación sigue sin cumplir los requisitos, puede agregar particiones horizontales. Una única estrategia de partición suele ser adecuada, pero en algunos casos es más eficaz combinar ambas estrategias.
Ejecute consultas en paralelo entre particiones para mejorar el rendimiento.

Diseño de particiones para disponibilidad

Particione los datos para mejorar la disponibilidad de las aplicaciones. La creación de particiones garantiza que todo el conjunto de datos no tiene un único punto de error y puede administrar de forma independiente subconjuntos individuales del conjunto de datos.

Tenga en cuenta los siguientes factores que afectan a la disponibilidad:

Determine la importancia de los datos. Identifique los datos empresariales críticos, como las transacciones y los datos operativos menos críticos, como los archivos de registro.

Almacene datos críticos en particiones de alta disponibilidad y cree un plan de copia de seguridad adecuado.
Establezca procedimientos de administración y supervisión independientes para diferentes conjuntos de datos.
Coloque los datos que tienen el mismo nivel de importancia en la misma partición para que se pueda realizar una copia de seguridad con la misma frecuencia. Por ejemplo, es posible que tenga que realizar copias de seguridad de particiones que contienen datos de transacción con más frecuencia que las particiones que contienen información de registro o seguimiento.

Administrar particiones individuales. Diseñe particiones para admitir la administración y el mantenimiento independientes. Esta práctica proporciona varias ventajas, por ejemplo:

Si se produce un error en una partición, puede recuperarse de forma independiente sin aplicaciones que accedan a los datos de otras particiones.
La creación de particiones de datos por área geográfica permite que las tareas de mantenimiento programadas se produzcan en horas de poca actividad para cada ubicación. Asegúrese de que las particiones no sean tan grandes que impidan que el mantenimiento planeado finalice durante este período.

Replicación de datos críticos entre particiones. Esta estrategia mejora la disponibilidad y el rendimiento, pero también puede presentar problemas de coherencia. Se tarda un tiempo en sincronizar los cambios con cada réplica. Durante la sincronización, las distintas particiones contienen valores de datos diferentes.

Consideraciones sobre el diseño de aplicaciones

La creación de particiones agrega complejidad al diseño y desarrollo del sistema. Particione los datos como parte fundamental del diseño del sistema, incluso si el sistema solo contiene inicialmente una sola partición. Si direcciona la creación de particiones como una idea posterior, es difícil porque ya tiene un sistema activo para mantener. Puede hacer lo siguiente:

Tiene que modificar la lógica de acceso a datos.
Debe migrar grandes cantidades de datos existentes para distribuirlos entre particiones.
Enfrentarse a desafíos porque los usuarios esperan seguir usando el sistema durante la migración.

En algunos casos, la creación de particiones no es importante porque el conjunto de datos inicial es pequeño y un único servidor puede controlarlo fácilmente. Algunas cargas de trabajo pueden ir sin particiones, pero muchos sistemas comerciales deben expandirse a medida que aumenta el número de usuarios.

Algunos almacenes de datos pequeños también se benefician de la creación de particiones. Por ejemplo, cientos de clientes simultáneos pueden acceder a un pequeño almacén de datos. Si divide los datos en esta situación, puede ayudar a reducir la contención y mejorar el rendimiento.

Tenga en cuenta los siguientes puntos cuando se diseña un esquema de partición de datos:

Minimice las operaciones de acceso de datos entre particiones. Intente mantener juntos los datos de las operaciones de base de datos más comunes en una partición para minimizar las operaciones de acceso a datos entre particiones. Puede llevar mucho tiempo realizar consultas entre particiones en lugar de realizar consultas dentro de una sola partición. Pero la optimización de particiones para un conjunto de consultas podría afectar negativamente a otros conjuntos de consultas. Si debe realizar consultas en varias particiones, reduzca el tiempo de consulta mediante la ejecución de consultas en paralelo y la adición de los resultados en la aplicación. En algunos casos, no puede usar este enfoque, por ejemplo, si el resultado de una consulta se usa en la siguiente consulta.

Replicación de datos de referencia estáticos. Si las consultas usan datos de referencia relativamente estáticos, como tablas de código postal o listas de productos, considere la posibilidad de replicar estos datos en todas las particiones para reducir las operaciones de búsqueda independientes en distintas particiones. Este enfoque también puede reducir la probabilidad de que los datos de referencia se conviertan en un conjunto de datos frecuente con tráfico intensivo desde todo el sistema. Hay costos adicionales asociados con la sincronización de cambios en los datos de referencia.

Minimice las combinaciones entre particiones. Siempre que sea posible, minimice los requisitos de integridad referencial en las particiones verticales y funcionales. En estos esquemas, la aplicación es responsable de mantener la integridad referencial entre las particiones. Las consultas que unen datos entre varias particiones son ineficaces porque la aplicación normalmente realiza consultas consecutivas basadas en una clave y, a continuación, una clave externa. En su lugar, considere la posibilidad de replicar o anular la normalización de los datos pertinentes. Si las combinaciones entre particiones son necesarias, ejecute consultas en paralelo en las particiones y combine los datos dentro de la aplicación.

Adoptar coherencia definitiva. Evalúe si la coherencia fuerte es un requisito. Un enfoque común en los sistemas distribuidos es implementar la coherencia eventual. Los datos de cada partición se actualizan por separado y la lógica de la aplicación garantiza que las actualizaciones finalicen correctamente. La lógica de la aplicación también controla las incoherencias que surgen de consultar datos mientras se ejecuta una operación coherente con el tiempo.

Tenga en cuenta cómo buscan las consultas la partición correcta. Si una consulta debe examinar todas las particiones para buscar los datos necesarios, afecta significativamente al rendimiento, incluso cuando se ejecutan varias consultas paralelas. Con la creación de particiones verticales y funcionales, las consultas pueden especificar la partición. Por otro lado, la creación de particiones horizontales puede dificultar la localización de un elemento porque cada partición tiene el mismo esquema. Una solución típica es mantener un mapa que se usa para buscar la ubicación de las particiones de los elementos. Implemente este mapa en la lógica de particionamiento de la aplicación. También puede ser mantenido por el almacén de datos si el almacén de datos admite particionamiento transparente.

Reequilibrar las particiones periódicamente. Con la creación de particiones horizontales, las particiones de reequilibrio pueden ayudar a distribuir uniformemente los datos por tamaño y carga de trabajo. Reequilibrar particiones para minimizar las zonas activas, maximizar el rendimiento de las consultas y solucionar las limitaciones de almacenamiento físico. Esta tarea es compleja y a menudo requiere una herramienta o un proceso personalizados.

Replique las particiones. Replique cada partición para proporcionar protección adicional frente a errores. Si se produce un error en una sola réplica, las consultas se dirigen a una copia en funcionamiento.

Amplíe la escalabilidad a un nivel diferente. Si se alcanzan los límites físicos de una estrategia de creación de particiones, es posible que necesite ampliar la escalabilidad a un nivel diferente. Por ejemplo, si la creación de particiones se produce en el nivel de base de datos, puede que tenga que buscar o replicar las particiones en varias bases de datos. Si la creación de particiones ya está en el nivel de base de datos y hay limitaciones físicas, es posible que tenga que buscar o replicar particiones en varias cuentas de hospedaje.

Evite las transacciones que accedan a datos en varias particiones. Algunos almacenes de datos implementan coherencia transaccional e integridad para las operaciones que modifican los datos, pero solo cuando los datos se encuentran en una sola partición. Si necesita compatibilidad transaccional en varias particiones, impleéela como parte de la lógica de la aplicación porque la mayoría de los sistemas de creación de particiones no proporcionan compatibilidad nativa.

Todos los almacenes de datos requieren algunas operaciones de administración operativa y de supervisión de las actividades. Estas tareas incluyen la carga de datos, la copia de seguridad y la restauración de datos, la reorganización de datos y la garantía de que el sistema funciona correctamente y de forma eficaz.

Tenga en cuenta los siguientes factores que afectan a la administración operativa:

Implemente las tareas operativas y de administración adecuadas cuando se particionen los datos. Estas tareas pueden incluir la realización de copias de seguridad y su restauración, el archivado de datos, la supervisión del sistema y otras tareas administrativas. Por ejemplo, puede resultar difícil mantener la coherencia lógica durante las operaciones de copia de seguridad y restauración.
Cargue datos en varias particiones y agregue nuevos datos procedentes de otros orígenes. Es posible que algunas herramientas y utilidades no admitan operaciones de datos particionadas, como cargar datos en la partición correcta.
Archivar y eliminar datos con regularidad. Para evitar el crecimiento excesivo de las particiones, archive y elimine los datos cada mes. Es posible que tenga que transformar los datos para que coincidan con un esquema de archivo diferente.
Busque problemas de integridad de datos. Considere la posibilidad de ejecutar un proceso periódico para localizar problemas de integridad de datos, como los datos de una partición que hace referencia a la falta de información en otra. El proceso puede intentar corregir estos problemas automáticamente o generar un informe para su revisión manual.

Reequilibrar particiones

Cuando un sistema madure es posible que tenga que ajustar el esquema de partición. Por ejemplo, las particiones individuales pueden empezar a recibir un volumen desproporcionada de tráfico y volverse activas, lo que conduce a una contención excesiva. O bien, es posible que haya subestimado el volumen de datos en algunas particiones, lo que hace que las particiones se acerquen a los límites de capacidad.

Algunos almacenes de datos, como Azure Cosmos DB, pueden reequilibrar automáticamente las particiones. En otros casos, puede reequilibrar particiones en dos fases:

Determine una nueva estrategia de creación de particiones.
- ¿Qué particiones deben dividirse o combinarse?
- ¿Cuál es la nueva clave de partición?
Migre los datos del esquema de partición antiguo al nuevo conjunto de particiones.

Es posible que tenga que dejar de estar disponible las particiones mientras reubica los datos, lo que se denomina migración sin conexión. En función del almacén de datos, puede migrar datos entre particiones mientras están en uso. Esta técnica se denomina migración en línea.

Migración sin conexión

La migración sin conexión reduce la posibilidad de que se produzca la contención. Para realizar la migración sin conexión:

Marque la partición como sin conexión. Puede marcar una partición como de solo lectura para que las aplicaciones puedan seguir leyendo los datos mientras lo mueve.
Dividir, combinar y mover los datos a las nuevas particiones.
Comprobar los datos.
Conectar las nuevas particiones.
Quitar la partición antigua.

Migración en línea

La migración en línea es más compleja pero menos perjudicial en comparación con la migración sin conexión. El proceso es similar a la migración sin conexión, pero no marca la partición original como sin conexión. Según la granularidad del proceso de migración, por ejemplo, elemento por elemento frente a partición por partición, el código de acceso a datos en las aplicaciones cliente podría tener que leer y escribir datos que se encuentra en dos ubicaciones, la partición original y la nueva partición.

Facilitación de Azure

En las secciones siguientes se describen las recomendaciones para crear particiones de datos almacenados en servicios de Azure.

Partición en Azure SQL Database

Una única base de datos SQL puede contener un volumen de datos limitado. El rendimiento está restringido por factores arquitectónicos y el número de conexiones simultáneas que admite.

Los grupos de bases de datos elásticas admiten el escalado horizontal de las bases de datos SQL. Use grupos elásticos para particionar los datos en particiones que se distribuyen entre varias bases de datos SQL. También puede agregar o quitar particiones a medida que crece y se reduce el volumen de datos. Los grupos de bases de datos elásticas también pueden ayudar a reducir la contención, ya que distribuyen la carga entre las bases de datos.

Cada partición se implementa como una base de datos SQL. Una partición puede contener más de un conjunto de datos. Cada conjunto de datos se denomina shardlet. Cada base de datos tiene metadatos que describen los shardlets que contiene. Un shardlet puede ser un solo elemento de datos o un grupo de elementos que comparten la misma clave de shardlet. Por ejemplo, en una aplicación multiinquilino, la clave de shardlet puede ser el identificador de inquilino y todos los datos de un inquilino pueden estar en el mismo shardlet.

Las aplicaciones son responsables de asociar un conjunto de datos con una clave de shardlet. Una base de datos SQL independiente actúa como administrador global de mapas de particiones. Esta base de datos tiene una lista de todas las particiones y shardlets del sistema. La aplicación se conecta a la base de datos del administrador del mapa de particiones para obtener una copia de este. Almacena en caché el mapa de particiones localmente y usa el mapa para enrutar las solicitudes de datos a la partición adecuada. Esta funcionalidad está oculta detrás de una serie de API que se encuentran en la biblioteca cliente de la característica Elastic Database de SQL Database, que está disponible para Java y .NET.

Para más información sobre los grupos elásticos, consulte Escalado horizontal con SQL Database.

Para reducir la latencia y mejorar la disponibilidad, puede replicar la base de datos de administrador global del mapa de particiones. Con los planes de tarifa Premium, puede configurar la replicación geográfica activa para copiar continuamente datos en bases de datos de diferentes regiones.

Como alternativa, use SQL Data Sync para SQL Database o Azure Data Factory para replicar la base de datos del administrador de mapas de particiones entre regiones. Esta forma de replicación se ejecuta periódicamente y es más adecuada si el mapa de particiones cambia con poca frecuencia y no requiere el nivel Premium.

Elastic Database proporciona dos esquemas para asignar datos a shardlets y para almacenarlos en particiones:

Un mapa de particiones de lista asocia una sola clave a un shardlet. Por ejemplo, en un sistema de varios inquilinos, los datos de cada inquilino podrían asociarse a una clave única y almacenarse en su propio shardlet. Para garantizar el aislamiento, cada shardlet puede mantenerse dentro de su propia partición.

Descargue un archivo de Visio de este diagrama.
Un mapa de particiones de intervalo asocia un conjunto de valores de clave contiguos a un shardlet. Por ejemplo, puede agrupar los datos de un conjunto de inquilinos, cada uno con su propia clave, dentro del mismo shardlet. Este esquema es menos costoso que un mapa de particiones de lista porque los inquilinos comparten el almacenamiento de datos, pero proporciona menos aislamiento.

Descargue un archivo de Visio de este diagrama.

Una partición individual puede contener los datos de varios shardlets. Por ejemplo, puede utilizar shardlets de lista para almacenar datos de varios inquilinos no contiguos en la misma partición. También puede mezclar shardlets de rango y shardlets de lista en la misma partición, pero luego se abordan a través de diferentes mapas. En el siguiente diagrama se ilustra este enfoque:

Descargue un archivo de Visio de este diagrama.

Con los grupos elásticos, puede agregar y quitar particiones a medida que el volumen de datos crece y se reduce. Las aplicaciones cliente pueden crear y eliminar particiones de forma dinámica y transparente actualizan el administrador de mapas de particiones. sin embargo, eliminar una partición es una operación destructiva que también requiere la eliminación de todos los datos de esa partición.

Si una aplicación necesita dividir una partición en dos particiones independientes o combinar particiones, use la herramienta de división y combinación. Esta herramienta se ejecuta como un servicio web de Azure y migra los datos de forma segura entre particiones.

El esquema de particiones puede afectar considerablemente al rendimiento del sistema. También puede afectar a la frecuencia con que deben agregarse o quitarse particiones, o con que se deben volver a crear particiones de datos. Considere los siguientes puntos:

Agrupe los datos que se usan juntos en la misma partición y evite las operaciones que acceden a los datos de varias particiones. Una partición es una base de datos SQL de su propio derecho y las combinaciones entre bases de datos se deben realizar en el lado cliente cuando las operaciones tienen acceso a varias particiones.

Aunque SQL Database no admite combinaciones entre bases de datos, puede usar herramientas de Elastic Database para realizar consultas de particiones múltiples. Una consulta en varias particiones envía consultas individuales a cada base de datos y combina los resultados.
Diseñe un sistema que no tenga dependencias entre particiones. Las restricciones de integridad referencial, los desencadenadores y los procedimientos almacenados de una base de datos no pueden hacer referencia a objetos de otra.
Considere la posibilidad de replicar datos entre particiones si tiene datos de referencia que las consultas usan con frecuencia. Este enfoque puede eliminar la necesidad de combinar datos entre bases de datos. Lo ideal es que estos datos sean estáticos o lentos para minimizar el esfuerzo de replicación y reducir la posibilidad de que se vuelvan obsoletos.
Use el mismo esquema para los shardlets que pertenecen al mismo mapa de particiones. Esta guía no se aplica mediante SQL Database, pero la administración y la consulta de datos son complejas si cada shardlet tiene un esquema diferente. En su lugar, cree mapas de particiones independientes para cada esquema. Puede almacenar datos que pertenecen a diferentes shardlets en la misma partición.
Almacene datos en la misma partición o implemente la coherencia final si la lógica de negocios necesita realizar transacciones. Las operaciones transaccionales solo se admiten para los datos que se encuentran en una partición y no entre particiones. Las transacciones pueden abarcar shardlets si forman parte de la misma partición.
Coloque las particiones cerca de los usuarios que acceden a los datos de dichas particiones. Esta estrategia ayuda a reducir la latencia.
Evite tener una combinación de particiones muy activas y relativamente inactivas. Pruebe a distribuir la carga uniformemente entre las particiones. Es posible que tenga que aplicar un algoritmo hash a las claves de particionamiento. Si está localizando geográficamente particiones, asegúrese de que las claves con hash se asignan a shardlets contenidos en particiones que se almacenan cerca de los usuarios que acceden a esos datos.

Partición en Azure Blob Storage

Con Blob Storage, puede almacenar objetos binarios grandes. Use blobs en bloques en escenarios que requieran que cargue o descargue rápidamente grandes volúmenes de datos. Use blobs en páginas para aplicaciones que requieran acceso aleatorio, en lugar de serial, a partes de los datos.

Cada blob en bloques o blob en páginas se mantiene en un contenedor de una cuenta de almacenamiento de Azure. Use contenedores para agrupar blobs relacionados que tengan los mismos requisitos de seguridad. Esta agrupación es más lógica que física. Dentro de un contenedor, cada blob tiene un nombre único.

La clave de partición de un blob es el nombre de la cuenta, el nombre del contenedor y el nombre del blob. La clave de partición se usa para particionar los datos en rangos. Estos intervalos están equilibrados de carga en todo el sistema. Los blobs se pueden distribuir entre muchos servidores para escalar horizontalmente el acceso a ellos. Un solo blob solo se puede atender mediante un solo servidor.

Si el esquema de nomenclatura usa marcas de tiempo o identificadores numéricos, puede provocar un tráfico excesivo a una partición. Impide que el sistema equilibre la carga de forma eficaz. Por ejemplo, si tiene operaciones diarias que usan un objeto de blob con una marca de tiempo, como aaaa-mm-dd, todo el tráfico de esa operación va a un único servidor de partición. En su lugar, anteponga el nombre con un hash de tres dígitos. Para más información, consulte Convención de nomenclatura de particiones.

Las acciones de escribir un solo bloque o página son atómicas, pero las operaciones que abarcan bloques, páginas o blobs no. Si necesita garantizar la coherencia cuando se realizan operaciones de escritura entre bloques, páginas y blobs, saque un bloqueo de escritura mediante una concesión de blobs.

Consideraciones

La creación de particiones de datos presenta algunos desafíos y complejidades que debe tener en cuenta.

La sincronización de datos entre las particiones puede convertirse en un desafío. Asegúrese de que las actualizaciones o los cambios en una partición se propagan a las demás particiones de forma oportuna y coherente.
Los procesos de conmutación por error y recuperación ante desastres se vuelven complejos cuando es necesario coordinar la copia de seguridad y restauración de varias particiones. Pueden surgir problemas de integridad de datos si algunas particiones o sus copias de seguridad están dañadas o no están disponibles.
La creación de particiones de datos puede afectar al rendimiento y la confiabilidad si necesita consultar entre particiones y al reequilibrar las particiones si los datos crecen de forma desigual.

Lista de comprobación de confiabilidad

Consulte el conjunto completo de recomendaciones.

Lista de comprobación de confiabilidad

Recomendaciones para la creación de particiones de datos

Estrategias de diseño principales