Partekatu honen bidez:

Elección de columnas de distribución en Azure Cosmos DB for PostgreSQL

  • Artikulua

SE APLICA A: Azure Cosmos DB for PostgreSQL (con tecnología de la extensión de base de datos de Citus en PostgreSQL)

Elegir la columna de distribución de cada tabla es una de las decisiones de modelado más importantes que se tiene que adoptar. Azure Cosmos DB for PostgreSQL almacena las filas en particiones en función del valor de la columna de distribución de las filas.

La elección correcta agrupa los datos relacionados en los mismos nodos físicos, lo que agiliza las consultas y agrega compatibilidad con todas las características de SQL. Una elección incorrecta hace que el sistema se ejecute lentamente.

Sugerencias generales

Estos son cuatro criterios para elegir la columna de distribución ideal para las tablas distribuidas.

  1. Elija una columna que sea una pieza central en la carga de trabajo de la aplicación.

    Puede pensar en esta columna como "núcleo", "pieza central" o "dimensión natural" para la creación de particiones de datos.

    Ejemplos:

    • device_id en una carga de trabajo de IoT
    • security_id para una aplicación financiera que realiza un seguimiento de valores bursátiles
    • user_id en el análisis de usuarios
    • tenant_id para una aplicación SaaS multiinquilino

  2. Elija una columna con una cardinalidad aceptable y una distribución estadística uniforme.

    La columna debe tener muchos valores y se debe distribuir exhaustiva e uniformemente entre todas las particiones.

    Ejemplos:

    • Cardinalidad por encima de 1000
    • No elija una columna que tenga el mismo valor en un gran porcentaje de filas (asimetría de datos)
    • En una carga de trabajo de SaaS, tener un inquilino mucho más grande que el resto puede provocar asimetría de datos. En esta situación, puede usar el aislamiento de inquilino para crear una partición dedicada para controlar el inquilino.

  3. Elija una columna que beneficie a las consultas existentes.

    Para una carga de trabajo transaccional u operativa (donde la mayoría de las consultas solo tardan unos milisegundos), elija una columna que aparezca como filtro en las cláusulas WHERE para al menos el 80 % de las consultas. Por ejemplo, la columna device_id en SELECT * FROM events WHERE device_id=1.

    Para una carga de trabajo analítica (donde la mayoría de las consultas tardan entre 1 y 2 segundos), elija una columna que permita poner en paralelo las consultas en los nodos de trabajo. Por ejemplo, una columna que aparece con frecuencia en cláusulas GROUP BY o que se consulta sobre varios valores a la vez.

  4. Elija una columna que esté presente en la mayoría de las tablas de gran tamaño.

    Se deben distribuir las tablas de más de 50 GB. La elección de la misma columna de distribución para todas ellas le permite la colocalización de los datos de esa columna en los nodos de trabajo. La colocalización hace que sea eficaz ejecutar cláusulas JOIN y acumulaciones, y aplicar claves externas.

    Las otras tablas (más pequeñas) pueden ser tablas locales o de referencia. Si la tabla más pequeña necesita cláusulas JOIN con tablas distribuidas, conviértala en una tabla de referencia.

Ejemplos de caso de uso

Hemos visto los criterios generales para elegir la columna de distribución. Ahora, veamos cómo se aplican a los casos de uso comunes.

Aplicaciones multiinquilino

La arquitectura multiinquilino usa una forma de modelado de base de datos jerárquico para distribuir consultas entre los nodos del clúster. La parte superior de la jerarquía de datos se conoce como identificador de inquilino y debe almacenarse en una columna en cada tabla.

Azure Cosmos DB for PostgreSQL inspecciona las consultas para ver el identificador de inquilino con el que se relacionan y busca la partición de tabla correspondiente. Asimismo, dirige la consulta a un único nodo de trabajo que contiene la partición. La ejecución de una consulta con todos los datos relevantes colocados en el mismo nodo se denomina colocación.

El siguiente diagrama ilustra la colocación en el modelo de datos del multiinquilino. Contiene dos tablas, Cuentas y Campañas, cada una distribuida mediante account_id. Los cuadros sombreados representan particiones. Las particiones verdes se almacenan juntas en un nodo de trabajo y las particiones azules se almacenan en otro. Observe cómo una consulta de combinación entre las tablas Accounts y Campaigns tiene todos los datos necesarios juntos en un nodo cuando ambas tablas se restringen al mismo valor de account_id.

Multi-tenantcolocation

Para aplicar este diseño en su propio esquema, debe identificar qué constituye un inquilino en su aplicación. Las instancias comunes incluyen la empresa, la cuenta, la organización o el cliente. El nombre de la columna será algo como company_id o customer_id. Examine cada una de las consultas y pregúntese: ¿funcionaría si tuviera más cláusulas WHERE para restringir todas las tablas implicadas en filas con el mismo identificador de inquilino? El ámbito de las consultas en el modelo multiinquilino se limita a un inquilino. Por ejemplo, el ámbito de las consultas de ventas o inventario se limita a una tienda determinada.

Procedimientos recomendados

  • Distribuya las tablas mediante una columna tenant_id común. Por ejemplo, en una aplicación SaaS donde los inquilinos son empresas, el valor de tenant_id será probablemente company_id.
  • Convierta pequeñas tablas entre inquilinos en tablas de referencia. Cuando varios inquilinos comparten una pequeña tabla de información, distribúyala como una tabla de referencia.
  • .Restrinja la opción para filtrar todas las consultas de las aplicaciones en función del valor de tenant_id. Cada consulta debe solicitar información para un inquilino a la vez.

Lea el tutorial de multiinquilino para ver un ejemplo de cómo crear este tipo de aplicación.

Aplicaciones en tiempo real

La arquitectura de multiinquilino introduce una estructura jerárquica y utiliza la colocación de datos para enrutar las consultas por cada inquilino. Por el contrario, las arquitecturas en tiempo real dependen de las propiedades de distribución específicas de sus datos para lograr un procesamiento altamente paralelo.

Usamos "id. de entidad" como término para las columnas de distribución en el modelo en tiempo real. Las entidades típicas son usuarios, hosts o dispositivos.

Las consultas en tiempo real suelen solicitar agregados numéricos agrupados en función de la fecha o la categoría. Azure Cosmos DB for PostgreSQL envía estas consultas a cada partición para obtener los resultados parciales y ensambla la respuesta final en el nodo de coordinación. Las consultas se ejecutan más rápido cuando contribuyen tantos nodos como sea posible y cuando ningún nodo debe realizar una cantidad desproporcionada de trabajo.

Procedimientos recomendados

  • Elija una columna con alta cardinalidad, como la columna de distribución. A modo de comparación, un campo de estado en una tabla de pedidos con los valores Nuevo, Pagado y Enviado no es una buena opción como columna de distribución. Como asume solo esos pocos valores, se limita la cantidad de particiones que pueden contener los datos y la cantidad de nodos que pueden procesarlos. Entre las columnas con alta cardinalidad, también es recomendable elegir aquellas que se usan frecuentemente en cláusulas de agrupación o como claves de combinación.
  • Elija una columna con distribución uniforme. Si distribuye una tabla en una columna con tendencia a determinados valores comunes, sus datos también tenderán a acumularse en determinadas particiones. Los nodos que incluyen estas particiones terminan trabajando más que otros nodos.
  • Distribuya las tablas de hechos y dimensiones en sus columnas comunes. Su tabla de hechos solo puede tener una clave de distribución. Las tablas que se combinan con otra clave no se coubicarán con la tabla de hechos. Elija una dimensión para la coubicación en función de la frecuencia con la que se combina y del tamaño de las filas de combinación.
  • Cambie algunas tablas de dimensiones para que sean tablas de referencia. Si una tabla de dimensiones no puede coubicarse con la tabla de hechos, puede mejorar el rendimiento de la consulta distribuyendo copias de la tabla de dimensiones a todos los nodos en forma de una tabla de referencia.

Lea el tutorial del panel en tiempo real para ver un ejemplo de cómo crear este tipo de aplicación.

Datos de serie temporal

En una carga de trabajo de serie temporal, las aplicaciones consultan información reciente a la vez que archivan información antigua.

El error más común a la hora de modelar la información de serie temporal en Azure Cosmos DB for PostgreSQL es usar la propia marca de tiempo como columna de distribución. Una distribución de hash basada en el tiempo distribuye los tiempos aleatoriamente en diferentes particiones, en lugar de mantener intervalos de tiempo juntos en particiones. Las consultas que implican tiempo generalmente hacen referencia a intervalos de tiempo, por ejemplo, los datos más recientes. Este tipo de distribución de hash conduce a una sobrecarga de la red.

Procedimientos recomendados

  • No elija una marca de tiempo como columna de distribución. Elija una columna de distribución diferente. En una aplicación de multiinquilino use el id. del inquilino, o en una aplicación en tiempo real use el id. de la entidad.
  • En su lugar, use la partición de la tabla PostgreSQL para el tiempo. Use la creación de particiones de tablas para dividir una tabla grande de datos ordenados en función del tiempo en varias tablas heredadas, cada una con diferentes intervalos de tiempo. La distribución de una tabla particionada con Postgres crea particiones para las tablas heredadas.

Pasos siguientes