Solución:
Dada su estructura de tabla actual, esto no es posible actualmente en DynamoDB. El gran desafío es comprender que la clave Hash de la tabla (partición) debe tratarse como si creara tablas separadas. De alguna manera, esto es realmente poderoso (piense en las claves de partición como la creación de una nueva tabla para cada usuario o cliente, etc.).
Las consultas solo se pueden realizar en una única partición. Ese es realmente el final de la historia. Esto significa que si desea consultar por fecha (querrá usar mseg desde época), entonces todos los elementos que desea recuperar en una sola consulta deben tener el mismo Hash (clave de partición).
Debo calificar esto. Absolutamente puedes scan según el criterio que está buscando, eso no es un problema, pero eso significa que estará mirando cada fila de su tabla y luego verificando si esa fila tiene una fecha que coincida con sus parámetros. Esto es realmente costoso, especialmente si, en primer lugar, está en el negocio de almacenar eventos por fecha (es decir, tiene muchas filas).
Puede tener la tentación de poner todos los datos en una sola partición para resolver el problema, y absolutamente puede, sin embargo, su rendimiento será dolorosamente bajo, dado que cada partición solo recibe una fracción de la cantidad total establecida.
Lo mejor que puede hacer es determinar particiones más útiles para crear para guardar los datos:
-
¿Realmente necesita mirar todas las filas, o son solo las filas de un usuario específico?
-
¿Estaría bien reducir primero la lista por mes y hacer varias consultas (una para cada mes)? ¿O por año?
-
Si está haciendo un análisis de series de tiempo, hay un par de opciones, cambie la clave de partición a algo calculado en
PUTpara hacer elquerymás fácil, o utilice otro producto de AWS como kinesis, que se presta al registro de solo anexos.
Respuesta actualizada:
DynamoDB permite la especificación de índices secundarios para ayudar en este tipo de consulta. Los índices secundarios pueden ser globales, lo que significa que el índice abarca toda la tabla a través de claves hash, o locales, lo que significa que el índice existiría dentro de cada partición de clave hash, lo que requiere que la clave hash también se especifique al realizar la consulta.
Para el caso de uso de esta pregunta, le recomendamos que utilice un índice secundario global en el campo “CreatedAt”.
Para obtener más información sobre los índices secundarios de DynamoDB, consulte la documentación del índice secundario
Respuesta original:
DynamoDB no permite búsquedas indexadas solo en la clave de rango. La clave hash es necesaria para que el servicio sepa en qué partición buscar para encontrar los datos.
Por supuesto, puede realizar una operación de escaneo para filtrar por el valor de la fecha, sin embargo, esto requeriría un escaneo completo de la tabla, por lo que no es ideal.
Si necesita realizar una búsqueda indexada de registros por tiempo en varias claves primarias, es posible que DynamoDB no sea el servicio ideal para su uso, o puede que necesite utilizar una tabla separada (ya sea en DynamoDB o en una tienda relacional) para almacenar el elemento. metadatos contra los que puede realizar una búsqueda indexada.
El enfoque que seguí para resolver este problema es crear un índice secundario global como se muestra a continuación. No estoy seguro de si este es el mejor enfoque, pero espero que sea útil para alguien.
Hash Key | Range Key
------------------------------------
Date value of CreatedAt | CreatedAt
Limitación impuesta al usuario de la API HTTP para especificar el número de días para recuperar datos, predeterminado a 24 horas.
De esta manera, siempre puedo especificar HashKey como el día de la fecha actual y RangeKey puede usar los operadores> y