Modelado de DynamoDB con Múltiples Elementos de Consulta
Antecedentes: Tengo experiencia en bases de datos relacionales y nunca he construido nada para DynamoDB que no fuera utilizado únicamente para guardar datos de manera rápida con muy pocas consultas. Estoy tratando de aprender los patrones de DynamoDB migrando una de mis aplicaciones de mesa de ayuda de MySQL a DynamoDB.
La aplicación es bastante simple desde una perspectiva de almacenamiento de datos. Un usuario envía una solicitud y esa solicitud genera 1 o más tickets.
Configuración: Tengo pantallas donde las personas ven las solicitudes iniciales y los tickets de esa solicitud y vistas de búsqueda que permiten al equipo de soporte consultar en un montón de atributos de un ticket (apellido del usuario, estado del ticket, caso de uso del ticket, número de teléfono del usuario, departamento del usuario). Este diseño en una base de datos SQL es bastante sencillo, pero en DynamoDB realmente no sé cómo estructurar claves primarias/secundarias (si es necesario).
He creado una colección para las solicitudes y otra para los tickets. Las solicitudes individuales tienen un arreglo de ids de ticket que le pertenecen. El item del ticket tiene un atributo que almacena el id de solicitud para que pueda buscar de esa manera. Pero en lo que me quedé atascado es: ¿cómo puedo buscar en los atributos de una solicitud/ticket sin tener que hacer un examen completo?
Leí sobre claves compuestas y quizás crear una clave de ordenamiento compuesta similar a:
Pregunta: ¿Cómo diseñas colecciones/tablas de DynamoDB que requieren hacer muchas consultas en diferentes valores de atributos sin depender de una clave primaria?
davy.ai
Como experto en IT especializado en Amazon DynamoDB, existen varios patrones y mejores prácticas que pueden ser considerados al diseñar una tabla/colección DynamoDB que requiere consultar muchos valores de atributos diferentes sin depender de una clave primaria.
Una solución potencial es utilizar índices secundarios globales (GSI) e índices secundarios locales (LSI) para soportar diferentes patrones de consulta. Por ejemplo, se podría crear un GSI en los atributos que se quieren consultar, como apellido, estatus y caso de uso, y asegurarse de incluir el ID de solicitud como atributo para que pueda recuperar los registros de tickets que pertenecen a una solicitud específica.
Además, se pueden utilizar claves compuestas para soportar diferentes tipos de consultas. Como se mencionó, se puede crear una clave de ordenación compuesta que incluya los atributos que se quieren consultar, como#<NúmeroDeTeléfono>#. Esto permite realizar consultas directas en esos atributos sin tener que realizar una exploración completa.
Es importante señalar que el diseño de una tabla/colección DynamoDB depende del caso de uso y patrones de consulta específicos, por lo que es útil tener una comprensión clara del modelo de datos y el uso anticipado antes de diseñar la tabla/collection.