Prácticas recomendadas para administrar relaciones de varios a varios - Amazon DynamoDB

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Prácticas recomendadas para administrar relaciones de varios a varios

Las listas de adyacencia conforman un patrón de diseño que resulta muy útil para modelar relaciones de varios a varios en Amazon DynamoDB. En otras cosas, constituyen un mecanismo para representar datos gráficos (modos y límites) en DynamoDB.

Patrón de diseño de listas de adyacencia

Cuando varias entidades de una aplicación tienen una relación de varios a varios entre ellas, la relación puede modelarse como una lista de adyacencia. En este patrón, todas las entidades del nivel superior (que se corresponderían con los nodos en el modelo gráfico) se representan utilizando la clave de partición. Cualquier relación con otras entidades (los límites en el modelo gráfico) se representa como un elemento dentro de la partición, donde el valor de la clave de ordenación se establece en el ID de la entidad de destino (nodo de destino).

Algunas de las ventajas de este patrón son la escasa duplicación de los datos y la simplificación de los patrones de consulta para buscar todas las entidades (nodos) relacionadas con una entidad de destino (que tiene un límite con un nodo de destino).

Un ejemplo real en el que este patrón resulta útil son los sistemas de facturación en los que las facturas (invoices) contienen varias cuentas (bills). Una cuenta puede ir en varias facturas. La clave de partición en este ejemplo es InvoiceID o bien BillID. Las particiones BillID tienen todos los atributos específicos de las facturas. Las particiones InvoiceID tienen un elemento que almacena atributos específicos de las facturas y un elemento para cada BillID que aparece en la factura.

El esquema sería similar al siguiente:

Esquema de tabla con un ejemplo de una lista de adyacencia de facturación.

En el esquema anterior, puede ver que las cuentas de una factura pueden consultarse utilizando la clave principal de la tabla. Para buscar todas las facturas que contienen parte de una cuenta, cree un índice secundario global de la clave de ordenación de la tabla.

Las proyecciones del índice secundario global serían similares a las siguientes.

Proyección de GSI de un ejemplo de lista de adyacencia de facturación.

Patrón de gráficos materializados

Muchas aplicaciones se crean en torno a la información que se tiene sobre las clasificaciones entre homólogos, las relaciones comunes entre entidades, el estado de las entidades adyacentes y otros tipos de flujos de trabajo gráficos. En estos tipos de aplicaciones, considere la posibilidad de utilizar el siguiente patrón de diseño de esquemas.


        Ejemplo de gráfico número 1.

        Ejemplo de gráfico número 2.

        Ejemplo de gráfico número 3.

En el esquema anterior, se muestra una estructura de datos gráficos definida por un conjunto de particiones de datos que contienen los elementos que definen los límites y los nodos del gráfico. Los elementos de límite contienen un atributo Target y Type. Estos atributos se utilizan como parte de una clave compuesta llamada "TypeTarget" para identificar el elemento de una partición de la tabla principal o de un índice secundario global.

El primer índice secundario global se basa en el atributo Data. Este atributo utiliza la sobrecarga de índices secundarios globales que se describió anteriormente para indexar varios tipos de atributos diferentes; en este caso, Dates, Names, Places y Skills. Aquí, un índice secundario global es capaz de indexar eficazmente cuatro atributos diferentes.

A medida que inserta elementos en la tabla, puede utilizar una estrategia de fragmentación inteligente para distribuir conjuntos de elementos con grandes agregaciones (Birthdate, Skill) entre tantas particiones lógicas de los índices secundarios globales como sean necesarias y evitar así el problema de que se creen puntos de lectura o escritura "calientes".

El resultado de esta combinación de patrones de diseño es un almacén de datos sólido para flujos de trabajo gráficos en tiempo real de gran eficacia. Estos flujos de trabajo pueden proporcionar consultas de agregación de estado y límite de entidades adyacentes de gran rendimiento para motores de recomendaciones, aplicaciones de redes sociales, clasificaciones de nodos, agregaciones de subárboles y otros casos de uso gráficos habituales.

Si en el caso de uso no es importante la coherencia de datos en tiempo real, puede utilizar un proceso de Amazon EMR programado para rellenar los límites con agregaciones de resumen de gráficos que sean relevantes para los flujos de trabajo. Si la aplicación no necesita saber inmediatamente cuándo se agrega un límite al gráfico, pude utilizar un proceso programado para agregar resultados.

Para mantener cierto nivel de consistencia, el diseño podría incluir Amazon DynamoDB Streams yAWS Lambdapara procesar las actualizaciones de borde. También podría usar un trabajo de Amazon EMR para validar los resultados a intervalos periódicos. Ente enfoque se ilustra en el siguiente diagrama. Normalmente, se emplea en aplicaciones de redes sociales, donde el costo de una consulta en tiempo real es elevado y la necesidad de conocer inmediatamente las actualizaciones de cada usuario es baja.


        Diagrama en el que se ilustra un flujo de trabajo gráfico.

Por lo general, las aplicaciones de seguridad y administración de servicios de TI (ITSM) tienen que responder en tiempo real a los cambios de estado de las entidades que se componen de agregaciones de límites complejas. Este tipo de aplicaciones necesitan un sistema que pueda admitir varias agregaciones en tiempo real de relaciones de segundo y tercer nivel en nodos o recorridos de límites complejos. Si el caso de uso requiere estos tipos de flujos de trabajo de consultas de gráficos en tiempo real, le recomendamos que considere la posibilidad de utilizar Amazon Neptune para administrarlos.