Table of Contents

Gestionar grandes conjuntos de datos presenta retos importantes para las organizaciones modernas, desde cuellos de rendimiento hasta limitaciones de almacenamiento y complejidades de mantenimiento. A medida que los volúmenes de datos siguen creciendo exponencialmente, dividir una tabla grande en piezas más pequeñas y manejables dentro de la misma instancia de base, ofreciendo una solución poderosa a estos retos de escalado. Entender las diversas estrategias de partición y sus aplicaciones prácticas es esencial para los administradores de bases de datos, desarrolladores y arquitectos que necesitan mantener sistemas de alto rendimiento.

Comprender la partición de bases de datos

La partición de bases de datos se refiere a la ruptura de los datos en la base de datos de una aplicación en piezas separadas o particiones. Estas particiones pueden almacenarse, acceder y gestionarse por separado. Esta técnica fundamental se ha vuelto cada vez más importante a medida que las organizaciones se ocupan de conjuntos de datos masivos que pueden abrumar las arquitecturas tradicionales de una sola mesa.

El motor de base de datos maneja las consultas de enrutamiento a la partición correcta automáticamente — su código de aplicación no cambia. Esta transparencia es una de las ventajas clave de la partición, lo que le permite implementar estrategias de gestión de datos sofisticadas sin requerir una refactorización de aplicaciones extensas.

La partición de datos es la práctica de dividir un conjunto de datos grande en segmentos más pequeños e independientes que pueden almacenarse y procesarse en múltiples máquinas o nodos. En lugar de una base de datos monolítica que maneja todo, el sistema distribuye datos a través de particiones, permitiendo que las cargas de trabajo se escalan horizontalmente. Esta capacidad de distribución se vuelve crítica cuando las arquitecturas de un solo servidor alcanzan sus límites físicos.

¿Por qué Partitionar Asuntos

Antes de sumergirse en estrategias específicas, es importante entender los problemas que se plantean a la partición. Las organizaciones suelen recurrir a la partición cuando se encuentran con varios desafíos comunes:

Limitaciones de almacenamiento

Los límites de almacenamiento – una máquina no puede almacenar todo. A medida que los conjuntos de datos crecen más allá de los terabytes en los petabytes, el almacenamiento de un solo servidor se vuelve impráctico o imposible. El partitura permite distribuir datos a través de múltiples sistemas de almacenamiento, eliminando efectivamente el almacenamiento como un cuello de botella.

Escribir las limitaciones de rendimiento

Mediador de escritura – un solo nodo no puede procesar suficientes escritos. Aplicaciones de alta velocidad pueden abrumar a un solo servidor de bases de datos con operaciones de escritura. Al distribuir escritos a través de múltiples particiones, puede lograr una mayor rentabilidad de lo que cualquier servidor podría manejar.

Leír escalabilidad

Leer escalabilidad – volumen de consulta abruma una sola base de datos. Incluso con réplicas de lectura, una sola instancia de base tiene límites en cuántas consultas concurrentes puede procesar eficientemente. Partitioning permite que las consultas se dirijan a segmentos de datos específicos, reduciendo la contención y mejorando los tiempos de respuesta.

Distribución geográfica

Latency – usuarios geográficamente distantes de la experiencia del servidor retrasan. Para aplicaciones globales, colocar datos más cercanos a usuarios en diferentes regiones puede mejorar dramáticamente la experiencia del usuario. Partitioning permite estrategias de distribución geográfica que minimizan la latencia para usuarios de todo el mundo.

Estrategias básicas de determinación de la partición

Hay tres estrategias típicas para la partición de datos: Partición horizontal (a menudo llamada sharding). En esta estrategia, cada partición es una tienda de datos separada, pero todas las particiones tienen el mismo esquema. Entender estos enfoques fundamentales es crucial para seleccionar la estrategia correcta para su caso de uso específico.

Partición horizontal (Sharding)

Las estrategias anteriores son todos particionamiento horizontal — hileras divididas a través de particiones. Cada partición tiene las mismas columnas pero diferentes filas. Este es el enfoque de partición más común y lo que la mayoría de la gente quiere decir cuando se discute partición de bases de datos.

El particionamiento horizontal es elegido normalmente para mejorar el rendimiento y la escalabilidad. Al ejecutar una base de datos en una sola máquina, a veces puede tener sentido dividir tablas para mejorar el rendimiento de consultas específicas y usadas frecuentemente contra esos datos. A menudo, sin embargo, la partición horizontal divide tablas en varios servidores con el fin de aumentar la escalabilidad.

Dentro de la partición horizontal, hay varios métodos específicos para determinar cómo distribuir filas a través de particiones:

Partición de rango

El particiones de rango (proporcionado por fecha o rango numérico) es uno de los métodos de partición más intuitivo y ampliamente utilizado. Esta técnica divide datos basados en una gama específica de valores, como rangos de fechas o intervalos numéricos y es mejor adecuado para datos basados en el tiempo, como las transacciones de ventas por año o mes.

La división de rangos se destaca en escenarios donde los datos tienen un orden natural y las consultas frecuentemente filtran por ese pedido. Por ejemplo, una plataforma de comercio electrónico podría dividir los datos de pedido por fecha, con particiones separadas por cada mes o trimestre. Esto permite consultas que soliciten pedidos recientes para escanear sólo las particiones recientes relevantes, mejorando dramáticamente el rendimiento.

Los almacenes de datos como Snowflake y BigQuery dependen en gran medida de la partición basada en el tiempo para el análisis de registros y las secuencias de eventos. La naturaleza de los datos de registro de la serie hace que la división de rango sea un ajuste natural, permitiendo políticas eficientes de retención de datos donde las particiones antiguas pueden ser archivadas o eliminadas sin afectar los datos actuales.

Lista Partición

La partición de listas (dividir por valores categóricos como región) organiza datos basados en valores discretos y predefinidos en lugar de rangos. Los datos se agrupan en base a una lista predefinida de valores con este método. En la mayoría de los casos, es mejor para datos con valores limitados y distintos, como región o departamento.

Considere una empresa multinacional con operaciones en América del Norte, Europa, Asia y Sudamérica. La partición de listas le permite crear particiones separadas para cada región, asegurando que las consultas que apuntan a áreas geográficas específicas sólo escaneen la partición relevante. Este enfoque es particularmente eficaz cuando diferentes particiones tienen patrones de acceso significativamente diferentes o cuando usted necesita aplicar diferentes políticas a diferentes categorías de datos.

La partición de listas simplifica también el cumplimiento de las normas de soberanía de datos, ya que puede garantizar que los datos para regiones específicas permanezcan almacenados físicamente en lugares apropiados, lo que resulta cada vez más importante ya que las normas de privacidad como el RGPD imponen requisitos estrictos en los casos en que los datos personales pueden almacenarse y procesarse.

Partición de Hash

El particionamiento de Hash (incluso la distribución utilizando una función hash) toma un enfoque diferente aplicando una función hash a una clave de partición para determinar qué partición debe almacenar cada fila. En este método de partición, los datos se distribuyen uniformemente a través de particiones utilizando una función de hash, asegurando un almacenamiento equilibrado.

La principal ventaja de la partición hach es su capacidad de distribuir datos uniformemente a través de particiones, evitando el problema de "partición caliente" donde algunas particiones reciben tráfico desproporcionado. Esta distribución es particularmente valiosa para datos que no tienen rango natural o límites de lista, como ID de usuario o identificadores de productos.

Sin embargo, el particionamiento hachís tiene una limitación significativa: no admite consultas eficientes de rango. Si necesita consultar todos los registros dentro de un rango específico, la base de datos debe escanear todas las particiones porque la función hah distribuye valores relacionados en diferentes particiones. Esto hace que la partición hah menos adecuado para los datos de la serie de tiempo u otros escenarios donde las consultas de rango son comunes.

Partición vertical

Particion vertical divide columnas. Se mueve raramente a las columnas (campos de texto grandes, BLOBs, metadatos de auditoría) en una tabla separada y se unen cuando sea necesario. Este enfoque difiere fundamentalmente de la partición horizontal mediante tablas divisorias basadas en columnas en lugar de filas.

En esta estrategia, cada partición tiene un subconjunto de los campos para los elementos de la tienda de datos. Los campos se dividen según su patrón de uso. Por ejemplo, los campos a menudo accedidos pueden ser colocados en una partición vertical y los campos menos a menudo accedidos en otro.

El particionamiento vertical resulta especialmente eficaz para tablas con muchas columnas donde diferentes subconjuntos de columnas tienen patrones de acceso distintos. Considere una tabla de perfil de usuario con información básica (nombre de usuario, correo electrónico, fecha de registro) que se accede con frecuencia, junto con datos detallados de perfil (biografía, preferencias, configuración) y grandes objetos binarios (imágenes de archivo, documentos cargados) que se acceden menos frecuentemente.

Al dividir estos en tablas separadas, usted consigue varios beneficios. Esto mantiene la mesa caliente estrecha y fácil de caché. La tabla a menudo accedida sigue siendo lo suficientemente pequeña para adaptarse a la memoria, mejorando dramáticamente el rendimiento de consultas para operaciones comunes. Mientras tanto, los datos menos a menudo accedidos no consumen espacio de caché valioso o frena las consultas rutinarias.

Una forma común de particionamiento vertical es dividir datos estáticos de datos dinámicos, ya que el primero es más rápido de acceso que el último, en particular para una tabla donde los datos dinámicos no se utilizan tan a menudo como la estática. Crear una vista en las dos tablas recién creadas restaura la tabla original con una penalización de rendimiento, pero acceder a los datos estáticos solo mostrará un mayor rendimiento.

Partición funcional

Particionamiento funcional. En esta estrategia, los datos se agregan según cómo se utiliza por cada contexto consolidado en el sistema. Por ejemplo, un sistema de comercio electrónico puede almacenar datos de facturas en una partición y datos de inventario de productos en otra.

El particionamiento funcional alinea la organización de datos con dominios empresariales, lo que hace que sea particularmente relevante para arquitecturas de microservicios. Cada servicio puede poseer su partición, reduciendo el acoplamiento entre servicios y permitiendo el escalado y despliegue independiente. Este enfoque también simplifica el control de seguridad y acceso, ya que puede aplicar diferentes permisos y políticas a diferentes áreas funcionales.

El desafío con particionamiento funcional radica en el manejo de consultas interfuncionales que necesitan datos de múltiples particiones. Estas consultas requieren una unión entre particiones, que pueden ser costosas. Sin embargo, si su arquitectura de aplicación separa naturalmente preocupaciones y minimiza las consultas interfuncionales, el particion funcional puede proporcionar excelentes beneficios de rendimiento y mantenimiento.

Partición compuesta

Estas estrategias pueden combinarse, y recomendamos que las considere todas cuando diseñe un esquema de partición. Por ejemplo, puede dividir los datos en fragmentos y luego utilizar partición vertical para subdivider más los datos en cada fragmento.

Considere la posibilidad de combinar múltiples estrategias, como partición compuesta, para abordar los requisitos complejos de datos y optimizar el rendimiento. Los sistemas del mundo real a menudo se benefician de enfoques híbridos que aprovechan las fortalezas de múltiples estrategias de partición.

Por ejemplo, puede utilizar la partición de rango para dividir datos por fecha, luego aplicar partición de hash dentro de cada rango de fechas para asegurar incluso la distribución. O puede combinar partición vertical para separar columnas a menudo y poco frecuentes con partición horizontal para gestionar el volumen de filas. Estas estrategias compuestas le permiten optimizar para múltiples dimensiones simultáneamente, aunque aumentan la complejidad.

Partición vs. Durmiendo: Entendiendo la Distinción

Mientras que los términos "partitioning" y "sharding" se utilizan a menudo intercambiablemente, hay una distinción importante. Esto es diferente de sharding, que distribuye datos en servidores de bases de datos separados. Partitioning es más simple de configurar, más simple de operar, y resuelve más problemas que la mayoría de los equipos se dan cuenta antes de que lleguen a sharding.

El particionamiento de bases de datos funciona dentro de un solo servidor de bases de datos. divide objetos de base como tablas e índices en segmentos más pequeños llamados particiones. El partitioning se gestiona automáticamente por el sistema de bases de datos.

Sharding extiende la partición horizontal en varios servidores de bases de datos. Mientras que la partición mantiene datos en una base de datos, sharding lo distribuye en diferentes instancias de bases de datos, cada uno potencialmente en diferentes hardware físicos. Esta distinción tiene implicaciones significativas para la complejidad, la sobrecarga operacional y cuando cada enfoque es apropiado.

Sharding es la solución cuando un solo servidor de base no puede manejar su carga, incluso con particionamiento. Considere el endurecimiento cuando: Escribe la entrada alcanza los límites de hardware: Un solo servidor de base sólo puede procesar tantos escritos por segundo. Cuando haya agotado el escalado vertical (herraje de motor) y optimización, sharding distribuye escrituras en varios servidores.

Comience con la partición. Muévete a endurecer solo cuando una sola instancia no puede manejar los requisitos de volumen de escritura o almacenamiento, incluso después de la afinación de rendimiento. Esta guía refleja la realidad de que el endurecimiento introduce una complejidad significativa en términos de la routa de consultas, transacciones distribuidas y gestión operacional. La mayoría de las organizaciones pueden alcanzar sus objetivos de rendimiento con la partición sola.

Beneficios clave de la partición

Comprender los beneficios concretos de la partición ayuda a justificar la inversión en la implementación y la gestión en curso. Estas ventajas abarcan el rendimiento, escalabilidad, disponibilidad y eficiencia operacional.

Mejora del rendimiento de las consultas

Mejorar el rendimiento. Las operaciones de acceso de datos en cada partición tienen lugar sobre un volumen más pequeño de datos. Se hace correctamente, el particionamiento puede hacer que su sistema sea más eficiente.

Partitioning mejora el rendimiento de la consulta a través de la poda de partición, simplifica el mantenimiento (vacuum, analizar, retención de datos), y no requiere cambios de aplicación. La poda de partición es particularmente potente: cuando una consulta incluye las condiciones en la clave de partición, la base de datos puede eliminar particiones enteras de consideración, escaneando solamente los datos pertinentes.

Considere una consulta solicitando pedidos de la última semana en un sistema con particiones mensuales. En lugar de escanear años de datos históricos, la base de datos sólo examina la partición del mes actual. Esto puede reducir el tiempo de ejecución de consultas de minutos a milisegundos, transformando la experiencia de usuario y permitiendo análisis en tiempo real que sería imposible de otra manera.

Aumento de la escalabilidad

Cuando se escala un sistema de bases de datos único, eventualmente alcanza un límite de hardware físico. Si se dividen datos en múltiples particiones, cada uno de ellos hospedado en un servidor separado, puede escalar el sistema casi indefinidamente.

La partición de datos puede mejorar la escalabilidad porque la puesta en una base de datos de una sola pieza de hardware es inherentemente limitada. Sin embargo, si los datos se dividen, entonces la base de datos se puede escalar horizontalmente, lo que significa que se pueden agregar servidores adicionales. Esto es a menudo una manera más económica de mantener la demanda creciente, y también permite la posibilidad de localizar diferentes particiones en diferentes áreas geográficas, asegurando que los usuarios de todo el mundo puedan disfrutar de una experiencia de aplicación de baja latencia.

La escalabilidad horizontal mediante el particionamiento ofrece ventajas económicas sobre el escalado vertical. La adición de servidores de productos básicos es a menudo más rentable que la actualización de hardware de alta gama cada vez más caro. Además, el escalado horizontal proporciona más flexibilidad: puede agregar capacidad de forma incremental como sea necesario en lugar de hacer grandes inversiones iniciales en infraestructuras de gran tamaño.

Mejora de la disponibilidad y tolerancia por defecto

Mejorar la disponibilidad. Separar datos en varios servidores evita un solo punto de fracaso. Si una instancia falla, sólo los datos en esa partición no están disponibles. Las operaciones en otras particiones pueden continuar.

El particionamiento de datos puede mejorar la disponibilidad porque la ejecución de una base de datos en una sola pieza de hardware significa que su base de datos tiene un único punto de fracaso. Si el servidor de base de datos se desactiva, toda su base de datos —y por extensión, su aplicación— está fuera de línea. Por el contrario, la difusión de datos en múltiples particiones permite que cada partición se almacene en un servidor separado.

Este aislamiento de fallas es particularmente valioso para sistemas a gran escala donde las fallas de hardware no son eventos excepcionales, sino ocurrencias esperadas. Al limitar el radio de explosión de cualquier fallo, el particionamiento le permite mantener alta disponibilidad incluso ante problemas de infraestructura.

Mantenimiento y gestión simplificados

Proporcionar flexibilidad operativa. Partitioning ofrece muchas oportunidades para operaciones de ajuste, maximizar la eficiencia administrativa y minimizar el costo. Por ejemplo, puede definir diferentes estrategias para la gestión, monitoreo, respaldo y restauración, y otras tareas administrativas basadas en la importancia de los datos en cada partición.

Partitioning permite una gestión más granular del ciclo de vida de datos. Puede archivar o eliminar particiones antiguas sin afectar los datos actuales, implementar diferentes cronogramas de respaldo para diferentes particiones basadas en su importancia, y realizar operaciones de mantenimiento en particiones individuales sin tener que tomar toda la base de datos fuera de línea.

Por ejemplo, en un sistema con particiones basadas en el tiempo, puede respaldar la partición del mes actual por hora, los tres meses anteriores diarios y las particiones más antiguas semanales. Este enfoque empatado optimiza los recursos de copia de seguridad al tiempo que garantiza una protección adecuada para los datos basados en sus patrones de edad y acceso.

Mejora de la seguridad

Mejora la seguridad. En algunos casos, puede separar datos sensibles y no sensibles en diferentes particiones y aplicar diferentes controles de seguridad a los datos sensibles.

Este beneficio de seguridad se extiende más allá del control de acceso simple. Puede encriptar particiones sensibles al dejar los datos no sensibles sin cifrar para un mejor rendimiento, aplicar registros de auditoría más estrictos a particiones que contienen información personal, o incluso almacenar particiones altamente sensibles en lugares físicos separados con medidas de seguridad física mejoradas.

Consideraciones prácticas para la aplicación

La implementación exitosa de particiones requiere una cuidadosa planificación y atención a varios factores críticos. Las decisiones de partición deficiente pueden degradar el rendimiento en lugar de mejorarlo, haciendo estas consideraciones esenciales.

Elegir la clave de la partición derecha

La clave de la partición determina si la base de datos puede prune particiones en sus consultas. Una clave de partición mala significa cada consulta escanea cada partición — peor que no tener particiones en absoluto.

El factor más importante es la elección de una clave de endurecimiento. Puede ser difícil cambiar la clave después de que el sistema esté en funcionamiento. La clave debe asegurarse de que los datos se participen para difundir la carga de trabajo de la manera más uniforme posible a través de los fragmentos.

La clave de la partición debe alinearse con sus patrones de consulta más comunes. Si la mayoría de las consultas filtran por ID del cliente, partición por ID del cliente. Si las consultas suelen solicitar datos para rangos de fechas específicos, use partición basado en el tiempo. Analice su carga de trabajo de consulta real antes de tomar esta decisión—no adivine basado en supuestos sobre cómo se utilizará el sistema.

Además, considere la distribución de datos. Una buena clave de partición distribuye datos relativamente uniformemente a través de particiones. Si una partición contiene el 90% de sus datos mientras que otros están casi vacíos, no ha resuelto sus problemas de rendimiento, acaba de moverlos a una sola partición caliente.

Comprender los patrones de consultas

Considere cómo las consultas ubican la partición correcta. Si una consulta debe escanear todas las particiones para localizar los datos requeridos, hay un impacto significativo en el rendimiento, incluso cuando se están ejecutando múltiples consultas paralelas.

Antes de implementar particiones, analice a fondo sus patrones de consulta. Identificar qué consultas son más frecuentes, que son la mayoría de rendimiento crítico, y qué columnas se filtran en. Este análisis debe impulsar su estrategia de particiones. Si sus consultas más comunes no incluyen la clave de particiones en sus cláusulas WHERE, el particiones puede no ayudar y podría incluso dañar el rendimiento.

Tenga especial cuidado con las consultas que necesitan unir datos a través de particiones o datos agregados de múltiples particiones. Estas operaciones se vuelven más costosas con la partición, potencialmente compensando los beneficios. Si tales consultas son comunes en su carga de trabajo, puede que necesite reconsiderar su estrategia de partición o aceptar que algunas consultas serán más lentas.

Tamaños de la partición de equilibrio

Equilibrar los tamaños de partición para evitar tener demasiadas particiones pequeñas o algunas muy grandes. Los tamaños de particiones óptimas garantizan un rendimiento de consulta eficiente y tareas de mantenimiento manejables.

Los fragmentos no tienen que ser del mismo tamaño. Es más importante equilibrar el número de solicitudes. Aunque los tamaños de partición perfectamente iguales no son necesarios, los desequilibrios extremos causan problemas. Una partición que es demasiado grande se convierte en un cuello de botella, mientras que demasiadas particiones pequeñas aumentan sobrecarga y complejidad.

Como guía general, apunta a particiones que son lo suficientemente grandes para beneficiarse de I/O secuencial y caching pero lo suficientemente pequeñas que las consultas comunes no necesitan escanear cantidades excesivas de datos. El tamaño exacto depende de su hardware, volumen de trabajo y sistema de bases de datos, pero las particiones en el rango de decenas a cientos de gigabytes a menudo funcionan bien.

Planificación para el crecimiento de los datos

Los datos no deja de crecer después de implementar particiones. Su estrategia de particiones debe acomodar el crecimiento futuro sin requerir una reestructuración frecuente. Para particiones basadas en el tiempo, esto es relativamente sencillo: crear nuevas particiones a medida que avanza el tiempo. Para otros esquemas de particiones, es posible que necesite planificar para dividir o rebalamentar particiones.

Asegúrese de que cada partición tiene suficientes recursos para manejar los requisitos de escalabilidad, en términos de tamaño de datos y rendimiento. Dependiendo de la tienda de datos, puede haber un límite en la cantidad de espacio de almacenamiento, potencia de procesamiento, o ancho de red por partición. Si los requisitos son probables que excedan estos límites, es posible que necesite refinar su estrategia de partición o dividir datos más allá, posiblemente combinando dos o más estrategias.

Considere la implementación de la gestión automatizada de particiones. Scripts o herramientas que crean automáticamente nuevas particiones, archivos antiguos y monitorear tamaños de particiones pueden reducir significativamente la sobrecarga operacional y evitar problemas antes de que impacten a los usuarios.

Vigilancia y mantenimiento

Supervisa el sistema para verificar que los datos se distribuyen según lo esperado y que las particiones pueden manejar la carga. El uso real no siempre coincide con lo que predice un análisis. Si es así, podría ser posible reequilibrar las particiones, o de otra manera rediseñado algunas partes del sistema para ganar el equilibrio requerido.

Incluye identificadores de partición en las métricas de monitoreo de su base de datos para que pueda detectar anomalías a nivel de partición, no sólo el nivel de tabla. Este monitoreo granular le permite identificar particiones calientes, distribución desigual, u otros problemas antes de que causen problemas visuales de usuario.

Monitorear y ajustar los tamaños de partición basados en el crecimiento de datos y el rendimiento de consultas para mantener un equilibrio óptimo. Partitioning no es una solución set-it-and-forget-it. Monitorización regular y ajustes ocasionales aseguran que su estrategia de partición siga sirviendo a sus necesidades a medida que evolucionan sus datos y carga de trabajo.

Promedio de partición Pruning

Consultas de diseño para aprovechar la poda de partición, donde el motor de base de datos salta automáticamente particiones irrelevantes. Esto reduce significativamente el tiempo de ejecución de consultas limitando los datos escaneados. Asegúrese de que las claves de partición se utilizan en cláusulas WHERE para maximizar los beneficios de la poda de particiones.

La poda de partición es uno de los beneficios de rendimiento más poderosos de la partición, pero sólo funciona cuando las consultas están escritas para aprovecharla. Educa a tu equipo de desarrollo sobre el esquema de partición y asegura que entiendan cómo escribir consultas que permiten la poda de partición. Revisar consultas lentas para identificar casos en los que la poda de partición no está sucediendo y refactorizarlos cuando sea posible.

Manejo de operaciones de participación cruzada

Uno de los aspectos más difíciles de particionar es tratar con operaciones que abarcan múltiples particiones. Se une entre tablas particiones, agregaciones a todas las particiones, y transacciones que modifican datos en múltiples particiones se vuelven más complejas y potencialmente más lentas.

Complejo Se une: Se une a través de múltiples particiones puede ser más lento y difícil de manejar. Cuando sea posible, diseñe su esquema y estrategia de partición para minimizar las uniones de partición cruzada. Si algunas tablas se unen frecuentemente, considere particionarlos en la misma clave para que los datos relacionados residen en las particiones correspondientes.

Para agregaciones que deben abarcar todas las particiones, considere mantener tablas sumarias o vistas materializadas que precomputan agregaciones comunes. Si bien esto añade complejidad y almacenamiento en la sobrecarga, puede mejorar dramáticamente el rendimiento de las consultas para el volumen de trabajo de análisis.

Evitar el Skew de Datos

Data Skew: La distribución desigual de datos puede causar que ciertas particiones se ocupen de más carga que otras. Data skew es uno de los problemas más comunes con la partición y puede socavar completamente sus beneficios.

Skew puede ocurrir de dos maneras: el estiércol de almacenamiento, donde algunas particiones contienen mucho más datos que otros, y el estiércol de acceso, donde algunas particiones reciben tráfico de consulta desproporcionada. Ambos tipos causan problemas, aunque el flujo de acceso es a menudo más impactante inmediatamente en el rendimiento.

Para evitar el almacenamiento de skew, elija las teclas de partición que distribuyen datos uniformemente. La partición Hash proporciona naturalmente la distribución, mientras que el particiones de rango y lista requieren una selección de clave más cuidadosa.

Access skew es más difícil de predecir y prevenir. A menudo resulta de comportamiento de aplicación en lugar de distribución de datos. Por ejemplo, si su aplicación particiones usuarios por ID pero la mayoría de las consultas apuntan usuarios registrados recientemente, la partición más reciente será caliente independientemente de la distribución de datos. En tales casos, puede que necesite repensar su estrategia de partición o implementar caché para reducir la carga en particiones calientes.

Conceptos avanzados de partición

Más allá de las estrategias básicas de partición, varios conceptos y técnicas avanzados pueden optimizar aún más sus sistemas de bases de datos particiones.

Interruptor de partición y deslizamiento de Windows

Interruptor de partición: Una técnica que permite el movimiento de datos entre particiones de manera eficiente. Esto se utiliza a menudo para el archivo de datos, purga u otras operaciones de mantenimiento.

El conmutador de partición le permite mover particiones enteras dentro y fuera de tablas con bloqueo mínimo y ejecución casi instantánea. Esta capacidad es particularmente valiosa para implementar escenarios de ventana deslizante, donde regularmente agrega nuevas particiones para entrar datos y eliminar viejas particiones para archivo.

Por ejemplo, un sistema que retiene 13 meses de datos podría utilizar particiones mensuales. Cada mes, se agrega una nueva partición para el mes actual y se cambia la partición más antigua, moviéndola a una tabla de archivos o dejándola completamente. Esta operación completa en segundos independientemente del volumen de datos, mientras que la eliminación de filas de 13 meses de una tabla no partida podría tardar horas y afectar significativamente el rendimiento.

Subpartitioning

Subpartitioning: Algunas estrategias de partición, como el rango o la partición de lista, permiten una división adicional de particiones en subparticiones. Subpartitioning, también llamado particiones compuestas, aplica múltiples niveles de partición para lograr la organización de datos mejorada.

Un patrón común es dividir por fecha en el nivel superior y luego subpartición por otro atributo como región o tipo de cliente. Esto permite que las consultas se beneficien de la poda en ambos niveles. Una consulta para datos específicos de una región del mes pasado sólo analizaría la partición del mes pertinente y la subpartición de la región pertinente dentro de ella, reduciendo drásticamente los datos escaneados.

Sin embargo, la subpartición aumenta la complejidad y el número de segmentos físicos, que pueden aumentar la sobrecarga. Úsalo con cautela, sólo cuando los beneficios de oportunidades adicionales de poda superan la complejidad agregada.

Índices mundiales y locales

Índices globales y locales: En algunas estrategias de partición, puede crear índices globales que abarcan todas las particiones o índices locales específicos de cada partición. La elección depende del caso de uso y patrones de consulta.

Los índices locales se dividen junto con la tabla, con cada partición que tiene su propio segmento de índice. Esto hace que las operaciones de mantenimiento de particiones como conmutación o desplegamiento de particiones rápido y simple, ya que los segmentos de índice se mueven con los datos.

Los índices globales abarcan todas las particiones, proporcionando una estructura de índice única en toda la tabla. Son necesarios para consultas eficientes en columnas no clave de partición pero complican el mantenimiento de particiones. La eliminación o conmutación de una partición requiere actualizar el índice global, que puede ser consumidor de tiempo. Algunos sistemas de bases de datos soportan el mantenimiento de índice global asincrónico para mitigar este problema.

Particiones predeterminadas

Partición predeterminada: Una partición que captura datos que caen fuera de los rangos o valores definidos especificados para otras particiones. Esto es útil para el manejo de datos que no coinciden con ninguna condición de partición específica.

Las particiones predeterminadas proporcionan una red de seguridad para datos que no encajan en ninguna partición definida. Si bien son útiles para prevenir errores, también pueden ocultar problemas. Si cantidades significativas de datos terminan en la partición predeterminada, puede indicar problemas con su esquema de partición o problemas de calidad de datos que necesitan investigación.

Supervisa cuidadosamente el tamaño y el crecimiento de las particiones predeterminadas. Deben contener sólo casos excepcionales, no una parte significativa de sus datos. Si la partición predeterminada crece grande, analice qué datos se están terminando allí y considere si su esquema de partición necesita ajuste.

Casos y ejemplos de uso real mundial

Entender cómo diferentes industrias y aplicaciones utilizan partición proporciona un contexto valioso para aplicar estas técnicas a sus propios sistemas.

Plataformas de comercio electrónico

Plataformas de comercio electrónico: Los datos de los clientes se dividen por región (por ejemplo, América del Norte, Europa) para optimizar el envío, el inventario y la comercialización localizada, mejorando el rendimiento y la experiencia de los usuarios.

Los sistemas de comercio electrónico suelen utilizar múltiples estrategias de partición simultáneamente. Los datos de pedidos pueden dividirse por fecha para apoyar un análisis histórico eficiente y la retención de datos. Los datos de los clientes podrían dividirse por región para apoyar características geográficas específicas y cumplir con los requisitos de soberanía de datos. Los datos del catálogo de productos podrían utilizar particiones funcionales para separar la información de inventarios que cambia frecuentemente de descripciones de productos relativamente estáticos.

Instagram recorta los datos de usuarios por rangos de ID de usuario, permitiendo que la plataforma escala su gráfico de usuario masivo a través de miles de nodos de base. Este enfoque permite a Instagram manejar miles de millones de usuarios manteniendo un rendimiento sensible para las búsquedas de perfiles, generación de alimentación y otras características básicas.

Servicios bancarios y financieros

Banca y Finanzas: Los datos de transacción se dividen por tipo de cuenta o fecha (por ejemplo, diariamente) para un procesamiento más rápido, la presentación de informes y una detección más eficiente del fraude.

Las instituciones financieras enfrentan desafíos únicos con la partición de datos debido a los requisitos reglamentarios, la necesidad de una fuerte coherencia y el carácter crítico de los datos financieros. La partición oportuna de los datos de transacción admite requisitos eficientes de presentación de informes y cumplimiento, al tiempo que permite consultas rápidas para transacciones recientes que son más relevantes para la detección del fraude y el servicio al cliente.

Muchos bancos también utilizan particiones verticales para separar datos sensibles como saldos de cuentas e información personal de datos operacionales menos sensibles. Esta separación simplifica los controles de seguridad y la tala de auditoría al tiempo que mejora el rendimiento para operaciones rutinarias que no necesitan acceso a campos sensibles.

Aplicaciones SaaS y Multi-Tenant

Aplicaciones de software como servicio a menudo particiones de datos por inquilino (organización de clientes). Este enfoque proporciona aislamiento natural entre clientes, simplifica las operaciones de copia de seguridad y restauración de los contenedores y permite modelos de precios flexibles basados en el volumen o uso de datos.

El particiones con base en el arrendatario también admite diversos niveles de servicio. Los clientes Premium pueden tener sus datos sobre almacenamiento de mayor rendimiento o en particiones con calendarios de copia de seguridad más agresivos, mientras que los clientes estándar utilizan infraestructura más económica.

Sin embargo, el particionamiento basado en arrendatario puede llevar a un cálculo significativo de datos si los tamaños de los clientes varían ampliamente. Algunos clientes grandes podrían dominar ciertas particiones mientras que muchos clientes pequeños comparten otros. Los enfoques híbridos que combinan particionamiento basado en arrendatarios con otras estrategias pueden ayudar a resolver este desafío.

Datos de IoT y de la serie de tiempo

Las aplicaciones de Internet de las Cosas generan volúmenes masivos de datos de series temporales de sensores y dispositivos.Estos datos son adaptados naturalmente a la partición de rangos basados en el tiempo, normalmente utilizando particiones horarias o diarias dependiendo del volumen de datos.

Las cargas de trabajo de las series temporales suelen tener patrones de acceso predecibles: los datos recientes se preguntan con frecuencia para el monitoreo y alerta en tiempo real, mientras que los datos históricos se acceden principalmente para el análisis de tendencias y la presentación de informes. Partitioning permite diferentes estrategias de optimización para diferentes períodos de tiempo. Las particiones recientes pueden mantenerse en memoria o en SSD rápidas, mientras que las particiones más antiguas se mueven a almacenamiento más barato o se comprimen para ahorrar espacio.

Muchos sistemas IoT también implementan políticas de retención automática de datos utilizando el descenso de particiones. Una vez que los datos alcanzan cierta edad, las particiones enteras pueden ser bajadas en segundos, gestionando eficientemente los costos de almacenamiento sin afectar las operaciones actuales.

Pitfalls comunes y cómo evitarlos

Incluso con una planificación cuidadosa, las implementaciones de partición pueden encontrar problemas. Comprender los obstáculos comunes le ayuda a evitarlos o reconocerlos y abordarlos rápidamente.

Partición prematura

Uno de los errores más comunes es implementar partición demasiado temprano, antes de que sea realmente necesario. Partición agrega complejidad a su diseño de base de datos, planificación de consultas y procedimientos operativos. Si su volumen de datos y carga de consulta no justifica esta complejidad, usted está agregando sobrecarga sin beneficios correspondientes.

Como regla general, considere la partición cuando las tablas superan las decenas o cientos de gigabytes, cuando el rendimiento de la consulta se degrada a pesar de la indexación adecuada, o cuando las operaciones de mantenimiento como copias de seguridad o los cálculos de índice tardan inaceptablemente. Si no está experimentando estos problemas, concéntrese en optimizaciones más simples como indexación adecuada, ajuste de consultas y actualizaciones de hardware.

Ignorar los cambios de aplicaciones

Una estrategia de partición que funciona bien para su aplicación actual podría ser problemática a medida que evoluciona la aplicación. Nuevas características podrían introducir patrones de consulta que no se alinean con su esquema de partición, o cambios en el comportamiento del usuario podrían cambiar patrones de acceso de maneras inesperadas.

Revisa regularmente tu estrategia de partición a la luz de los cambios de aplicación. Monitorea patrones de consulta y métricas de rendimiento para identificar cuándo el esquema de partición ya no está sirviendo tus necesidades. Prepárate para ajustar o incluso repensar completamente tu enfoque de partición si es necesario, aunque reconoce que tales cambios pueden ser disruptivos y deben ser llevados a cabo cuidadosamente.

Pruebas inadecuadas

La partición cambia cómo la base de datos almacena y accede a los datos, que pueden tener efectos sutiles en el rendimiento y comportamiento de las consultas. La prueba inadecuada antes de desplegar particionamientos a la producción puede llevar a sorpresas desagradables.

Prueba tu implementación de particionamiento a fondo con volúmenes de datos realistas y cargas de trabajo de consulta. No solo pruebes que las consultas devuelven resultados correctos: asegura el rendimiento bajo carga, verifica que la poda de partición funciona como se espera, y asegura que las operaciones de mantenimiento se completen dentro de plazos aceptables. La prueba de carga con volúmenes de datos similares a la producción es particularmente importante, ya que las características de rendimiento pueden cambiar dramáticamente a escala.

Mantenimiento de la partición

Utiliza herramientas de automatización y scripts para gestionar tareas de mantenimiento de particiones como añadir nuevas particiones, fusionar viejas y eliminar datos obsoletos. Manejo de particiones manual es propensa a errores y no escala bien.

Implementar procesos automatizados para mantenimiento de particiones rutinarias antes de implementar particiones a la producción. Estos procesos deben manejar la creación de nuevas particiones antes de ser necesarios, archivar o soltar particiones viejas de acuerdo a las políticas de retención, y monitorear tamaños y distribución de particiones. Alerta sobre anomalías como particiones creciendo más rápido de lo esperado o consultas que no se benefician de la poda de particiones.

Sobremiradas de respaldo y recuperación implicaciones

El particionamiento afecta los procedimientos de copia de seguridad y recuperación. Mientras que el particionamiento puede hacer copias de seguridad más eficientes permitiendo copias de seguridad de nivel de partición, también añade complejidad. Necesita asegurarse de que su estrategia de copia de seguridad cuenta con la estructura partimentada y que puede restaurar los datos correctamente.

Prueba tus procedimientos de copia de seguridad y recuperación a fondo con tablas particiones. Verifica que puedes restaurar particiones individuales si es necesario, y asegura que la recuperación puntual funcione correctamente a través de los límites de particiones. Documenta cualquier consideración especial para la copia de seguridad y recuperación de tablas particiones para que los equipos de operaciones puedan manejar incidentes de manera efectiva.

Tendencias futuras en la partición de datos

A medida que la tecnología de bases de datos sigue evolucionando, también avanzan las estrategias y capacidades de partición. Comprender las tendencias emergentes le ayuda a prepararse para futuros desarrollos y tomar decisiones arquitectónicas orientadas hacia el futuro.

Partición automatizada

La base de datos desperdiciará automáticamente particiones en nodos sin servidor en respuesta a la demanda de uso. La siguiente ola de innovación de particiones se esforzará por hacer los datos distribuidos a gran escala más simples para los usuarios. En general, el panorama de la industria apunta a aumentar el uso de particiones, más automatización y estrategias de multipartición más inteligentes.

Los sistemas modernos de bases de datos están incorporando cada vez más la automatización inteligente que puede recomendar o incluso implementar automáticamente estrategias de partición basadas en patrones de carga observados. algoritmos de aprendizaje automático analizan patrones de consulta, distribución de datos y métricas de rendimiento para sugerir esquemas de partición óptimos o ajustar automáticamente particiones existentes para mantener el rendimiento a medida que evolucionan las cargas de trabajo.

Esta automatización reduce la experiencia necesaria para implementar particiones efectivas y ayuda a prevenir errores comunes. Sin embargo, sigue siendo importante entender los fundamentos de particiones para que pueda evaluar recomendaciones automatizadas y anularlas cuando sea necesario en base a conocimientos específicos de aplicaciones.

Partición nativa de la nube

Los servicios de base de datos de Cloud están desarrollando capacidades de partición que aprovechan las características únicas de la infraestructura de la nube. El tabique elástico puede escalar automáticamente el número de particiones basadas en la carga de trabajo, agregando particiones durante períodos máximos y consolidandolos durante tiempos tranquilos para optimizar los costos.

Los servicios de cloud también permiten estrategias de partición geográfica que no eran prácticas con infraestructura en locales. Los datos pueden dividirse automáticamente en múltiples regiones sobre la base de la ubicación del usuario, requisitos regulatorios o consideraciones de rendimiento, con el proveedor de la nube que maneja la complejidad de la replicación y consistencia de la inscripción cruzada.

Estrategias híbridas de fijación de piezas

Las empresas buscan aprovechar la partición antes y gestionarla holísticamente a través de entornos on-prem y cloud. A medida que las organizaciones adoptan arquitecturas de nubes híbridas, las estrategias de partición deben abarcar tanto en locales como en infraestructuras de nube.

El particionamiento híbrido podría colocar datos recientes y a menudo accesibles en particiones de nubes para escalabilidad elástica manteniendo datos históricos en particiones locales para la eficiencia de costes. O datos sensibles podrían permanecer en el local por razones de cumplimiento mientras que datos menos sensibles se mueven a la nube. Estos enfoques híbridos requieren orquestación sofisticada pero ofrecen flexibilidad que puramente en el local o arquitecturas solo en la nube no pueden coincidir.

Aplicación de la partición: un enfoque paso a paso

La implementación exitosa de particiones requiere un enfoque metódico que equilibra los objetivos de rendimiento con realidades operativas. Aquí está un marco práctico para planificar y ejecutar una implementación de particiones.

Paso 1: Analice su carga de trabajo

Comience por entender a fondo su carga de trabajo actual. Identifica sus tablas más grandes y analice sus tasas de crecimiento. Examine patrones de consulta para entender cuáles son las consultas más frecuentes y cuáles son las más críticas de rendimiento. Busque consultas que escanean grandes cantidades de datos o tomen inaceptablemente tiempo para ejecutar.

Utiliza herramientas de monitoreo de bases de datos para recopilar métricas en tiempos de ejecución de consultas, patrones I/O y utilización de recursos. Analiza registros de consultas lentas para identificar consultas problemáticas. Este enfoque basado en datos asegura que su estrategia de partición aborde problemas reales en lugar de los supuestos.

Paso 2: Define tus objetivos

¿Está tratando principalmente de mejorar el rendimiento de las consultas? ¿Simplificar la retención de datos y el archivo? ¿Apoya la distribución geográfica? ¿Puede escalar horizontalmente? Diferentes objetivos pueden llevar a diferentes estrategias de partición.

Establecer objetivos específicos y mensurables. En lugar de "mejorar rendimiento", apuntar a "reducir latencia de la consulta percentil 95 para las consultas recientes de datos de 5 segundos a menos de 500ms." Los objetivos concretos le ayudan a evaluar si su implementación de partición es exitosa y guía decisiones sobre selección de particiones clave y el dimensionamiento de particiones.

Paso 3: Elija su estrategia de partición

Basado en el análisis de la carga de trabajo y los objetivos, seleccione una estrategia de partición adecuada. Considere si la partición horizontal, vertical o funcional se ajusta mejor a sus necesidades. Dentro de la partición horizontal, decida si el rango, lista, hah o partición compuesta es más apropiado.

Seleccione una clave de partición que se alinea con sus patrones de consulta más comunes y distribuya datos de forma relativamente uniforme. Considere cómo la clave de partición afectará tanto las consultas actuales como los requisitos futuros previstos. Documente la racionalidad de sus opciones para que los futuros usuarios entiendan el pensamiento detrás del diseño.

Paso 4: Diseña tu esquema de partición

Determinar cuántas particiones crearás inicialmente y cómo manejarás el crecimiento de partición con el tiempo. Para particiones basadas en el tiempo, decida el intervalo de tiempo para cada partición (hora, diariamente, mensual). Para la partición de rango o lista, defina los rangos o valores para cada partición.

Planifique su estrategia de indexación, decidiendo qué índices deben ser locales para cada partición y que debe ser global. Considere cómo funcionan las operaciones de mantenimiento de particiones como añadir o soltar particiones.

Paso 5: Prueba a fondo

Implemente su esquema de partición en un entorno de prueba con volúmenes de datos realistas. Ejecute su carga de trabajo de consulta real contra las tablas particiones y mida el rendimiento. Verifique que la poda de partición está funcionando como se espera examinando planes de ejecución de consultas.

Casos de borde de prueba y escenarios de fracaso. ¿Qué sucede si una partición se llena? ¿Cómo se comporta el sistema si la automatización de mantenimiento de partición falla? ¿Puede restaurar de copias de seguridad correctamente? Pruebas a fondo en un entorno seguro evita incidentes de producción.

Paso 6: Planifica tu migración

Desarrollar un plan detallado para migrar los datos existentes a la estructura partitiva. Para tablas grandes, esta migración puede tomar tiempo significativo y puede ser necesario que ocurra durante una ventana de mantenimiento o utilizando técnicas de migración en línea que permitan que la aplicación siga funcionando.

Considere si puede implementar la partición gradual, tal vez comenzando con nuevos datos al dejar temporalmente los datos históricos en la antigua estructura. Plan para la reversión en caso de que la migración encuentre problemas. Comuníquese el plan de migración a todos los interesados y asegure que los equipos de operaciones estén preparados para apoyar la nueva estructura partitiva.

Paso 7: Monitor y Optimización

Después de implementar particiones a la producción, monitorear el rendimiento de cerca. Seguimiento de tiempos de ejecución de consultas, tamaños de particiones y utilización de recursos. Busque consultas que no se beneficien de la poda de particiones e investigue por qué. Monitore para los patrones de acceso de particiones desiguales y desviado.

Prepárate para hacer ajustes basados en el comportamiento real del mundo. Es posible que necesite modificar los límites de partición, añadir índices o incluso reconsiderar su estrategia de partición si no está entregando beneficios esperados. Monitorización y optimización continua aseguran que el particionamiento siga sirviendo a sus necesidades a medida que su aplicación evoluciona.

Partición en diferentes sistemas de bases de datos

Mientras que los conceptos de partición son universales, los detalles de implementación varían significativamente en los sistemas de bases de datos. Entender estas diferencias le ayuda a aprovechar las fortalezas de su base de datos y trabajar en torno a sus limitaciones.

PostgreSQL

PostgreSQL admite partición declarativa a partir de la versión 10, con mejoras significativas en versiones posteriores. Admite el particionado de rango, lista y hash, así como el particionado multinivel. La poda de partición de PostgreSQL es bastante sofisticada, eliminando particiones innecesarias durante la planificación de consultas cuando sea posible.

PostgreSQL maneja particiones como tablas separadas que heredan de una tabla matriz. Este enfoque proporciona flexibilidad pero requiere una gestión cuidadosa de las restricciones e índices a través de particiones. Se une y agregaciones de partición permiten consultas eficientes a través de tablas particiones cuando se alinean los esquemas de partición.

MySQL

MySQL ha soportado la partición durante muchos años, con implementaciones que varían entre motores de almacenamiento. InnoDB, el motor de almacenamiento más común, soporta el rango, lista, hash y partición clave. El particiones de MySQL es transparente para aplicaciones, con la selección de particiones de manipulación del servidor automáticamente.

MySQL tiene algunas limitaciones en comparación con otros sistemas, como restricciones a las teclas extranjeras con tablas particiones y limitaciones en los tipos de expresiones que pueden utilizarse en definiciones de particiones. Sin embargo, para casos de uso común como particiones de rango basados en el tiempo, la implementación de MySQL funciona bien y es relativamente sencillo de usar.

Base de datos de Oracle

Oracle tiene una de las implementaciones de partición más maduras y ricas en características, apoyando una amplia variedad de métodos de partición incluyendo rango, lista, hash, intervalo (creación de partición de rango automático), referencia (partición basado en relaciones clave extranjeras), y varias opciones de partición compuesta.

Las operaciones de Oracle a base de particiones pueden mejorar dramáticamente el rendimiento de las consultas y las operaciones de DML en tablas particiones. Características como la carga de intercambio de particiones permiten la carga eficiente de datos a granel, mientras que la compresión de particiones puede reducir significativamente los requisitos de almacenamiento de datos históricos.

SQL Server

SQL Server implementa particiones a través de funciones de particiones y esquemas de particiones. Admite la partición de rango con especificaciones de límites izquierda y derecha. Las vistas particiones de SQL Server proporcionan un enfoque alternativo que puede funcionar en múltiples bases de datos o servidores.

La capacidad de conmutación de particiones de SQL Server permite operaciones de carga y archivo de datos muy rápidos. Los escenarios de ventana deslizante, donde se agregan regularmente nuevas particiones y se eliminan las antiguas, son especialmente compatibles. SQL Server también soporta índices alineados con particiones y índices de columnería en tablas partimentadas para cargas de análisis.

Conclusión

La partición de datos es una técnica potente para gestionar grandes conjuntos de datos, mejorar el rendimiento de las consultas y permitir la escalabilidad horizontal. La partición de bases de datos es una técnica de escalado potente, pero requiere una planificación cuidadosa y mantenimiento continuo. El éxito requiere entender su carga de trabajo, elegir estrategias de partición apropiadas, y aplicar procedimientos de monitoreo y mantenimiento robustos.

El particionamiento de bases de datos no es solo acerca de dividir datos, sino que se trata de entender cómo los patrones de acceso de su aplicación, los requisitos de consistencia y los modos de falla interactúan con diferentes estrategias de particionamiento.

La clave para la partición exitosa radica en alinear su estrategia con sus necesidades específicas. Elija la estrategia correcta: Particionado vertical para tablas anchas con patrones de acceso distintos. Particion horizontal para tablas masivas donde las consultas se filtran naturalmente en una columna específica.

Recuerde que el particionamiento no es una bala de plata. Añade complejidad y requiere una gestión continua. Implementarlo cuando tenga evidencia clara de que resolverá problemas específicos que está experimentando, no como una optimización prematura. Con la planificación, implementación y mantenimiento adecuados, el particionado puede transformar una base de datos sobrecargada en un sistema escalable de alto rendimiento capaz de manejar volúmenes de datos masivos y cargas de búsqueda.

Para obtener más información sobre estrategias de optimización y escalado de bases de datos, explore los recursos de لеровов="https://www.postgresql.org/docs/current/ddl-partitioning.html"Consejo de correosLa documentación oficial de SQL indicada/a título, "apartado href="https://learn.microsoft.com/en-us/azure/archiprase