Pourquoi DynamoDB analyse avec fin et FilterExpression pas retourner les articles qui correspondent aux exigences du filtre?

J'ai besoin de faire une analyse avec fin et une condition sur DynamoDB.

La docs dit:

Dans une réponse, DynamoDB retourne tous les résultats dans le champ d'application de la valeur Limite. Par exemple, si vous exécutez une Requête ou d'une requête d'Analyse avec une valeur Limite de 6 et sans une expression de filtre, DynamoDB renvoie les six premiers éléments dans la table qui correspond à la clé spécifiée conditions de la demande (ou seulement les six premiers éléments dans le cas d'une Analyse avec pas de filtre). Si vous aussi vous fournir un FilterExpression valeur, DynamoDB va retourner les articles dans les six premiers que de correspondre aux exigences du filtre (le nombre de résultats retourné devra être inférieur ou égal à 6).

Le code (NODEJS):

var params = {
    ExpressionAttributeNames: {"#user": "User"},
    ExpressionAttributeValues: {":user": parseInt(user.id)},
    FilterExpression: "#user = :user and attribute_not_exists(Removed)",
    Limit: 2,
    TableName: "XXXX"
};

DynamoDB.scan(params, function(err, data) {
    if (err) {
        dataToSend.message = "Unable to query. Error: " + err.message;
    } else if (data.Items.length == 0) {
        dataToSend.message = "No results were found.";
    } else {
        dataToSend.data = data.Items;
        console.log(dataToSend);
    }
});

Tableau XXXX définitions:

  • Partition primaire clés: Utilisateur (Nombre)
  • Primaire de la clé de tri: Identificateur (String)
  • INDEX:
    • Nom De L'Index: RemovedIndex
    • Type: GSI
    • Clé de Partition: Retiré (Nombre)
    • De la clé de tri: -
    • Attributs: TOUS les

Dans le code ci-dessus, si je retire la Limit paramètre, DynamoDB sera de retour les éléments qui correspondent aux critères de filtre. Ainsi, les conditions sont ok. Mais quand je scan avec Limit paramètre, le résultat est vide.

Le XXXX table, a 5 éléments. Seuls les 2 premiers ont le Removed attribut. Quand je scanne sans Limit paramètre, DynamoDB retourne les 3 éléments sans Removed attribut.

Ce que je fais mal?

InformationsquelleAutor Gabriel Cunha | 2016-08-04
  1. 16

    De la documentation que vous avez cité:

    Si vous aussi vous fournir un FilterExpression valeur, DynamoDB sera de retour le
    les éléments dans les six premiers que de correspondre aux exigences du filtre

    En combinant Limite et FilterExpression vous avez dit DynamoDB pour qu'à regarder les deux premiers éléments dans le tableau, et d'évaluer la FilterExpression contre ces éléments. Limite de DynamoDB peut être source de confusion car il fonctionne différemment de limit dans une expression SQL dans un SGBDR.

    • Merci pour votre réponse! Je n'ai pas compris la doc, vous clarifié pour moi. Avez-vous des conseils sur comment je peux l'utiliser limit comme une expression SQL dans les SGBDR?
    • Il y a certainement une confusion sur ceci: github.com/clarkie/dynogels/issues/12 Comment est-ce utile de comportement? Sûrement le balayage jusqu'à ce que vous avez des 6 éléments qui correspondent au filtre ou à la fin de la table serait plus utile?
    • Il est utile, car elle permet de limiter le nombre d'enregistrements d'une opération d'Analyse évalue, pour des raisons de performances. Juste parce qu'il ne fonctionne pas de la même façon qu'un SGBDR ne signifie pas qu'il n'est pas utile. Aussi votre commentaire sur Github à propos de l'existence "d'une certaine confusion sur ce que les docs disent" semble incorrect pour moi. Les docs (comme je l'ai cité dans ma réponse) sont parfaitement claires. La confusion vient de personnes qui assument limit fonctionne de la même manière dans DynamoDB comme il le fait dans un SGBDR, sans prendre le temps de lire la documentation.
    • B Mais comment atteindre cette "limite" comme dans une expression SQL dans un SGBDR?
    • Avez-vous trouvé la réponse? Dynamo de documentation est horrible. Les choses simples semblent être caché quelque part dans le trou.
    • Je havn'pas trouvé une solution encore, toujours dans le doute. Cela est dû à la conception de base idears dans Dynamodb, où les filtres sont ajoutés à la suite de limite.
    • en regardant quelques choses, je me sens DynamoDB est pas le bon choix pour mon cas d'utilisation. MongoDB a beaucoup mieux en interrogeant les modèles. J'irai peut-être avec MongoDB ou Cassandra.
    • bien dépend de ce que vous faites, mon approche consiste à utiliser dynamodb simple CRUD, puis-je utiliser AWS lambda dans l'index de certains tableaux d'elastic search et puis ne lourde les requêtes en élastique
    • mais si je ne peux pas utiliser quelque chose comme des élastiques, seule la dynamo? Je pensais à la requête de toutes les données, puis de renvoyer les données en tranches avec de la longueur, mais c'est une mauvaise solution, car j'ai aussi besoin de la pagination...
    • vous pouvez paginer, c'est juste pour analyser 'startKey'
    • mais comment puis-je filtrer dans tous les champs de la table, de limiter à 2 et de la pagination? Si je me limite à 2, c'filtres seuls les deux premiers champs de la table.
    • Cela est dû à l'idée de merde qu'ils ont dans le dynamo, qui applique des filtres après ils sont de retour - le meilleur moyen de résoudre ce est avec index - ou utiliser les flux de les avoir dans elastic search et de faire des requêtes compliquées
    • Je vois... quand vous parlez d'un index, parlons des index secondaires? Si oui, indices à l'échelle mondiale ou locale indices? Parce que j'ai besoin de payer pour chaque indice global, sûr?
    • indices locaux sont pour si vous avez besoin d'un secondaire gamme de clé pour l'original hashkey, le mondial sont si vous avez besoin de nouvelles global hashkeys
    • Merci!!!!

    InformationsquelleAutor Mark B
  2. 1

    Également rencontré ce problème, je suppose que vous aurez juste besoin de parcourir l'ensemble du tableau à un maximum de 1 MO

    Scan
    Les résultats à partir d'une Analyse est limitée à 1 MO par appel. Vous pouvez utiliser le LastEvaluatedKey à partir de l'analyse de la réponse à récupérer plus de résultats.

    http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Limits.html

    InformationsquelleAutor Samuel Okpapi
  3. 1

    Vous pourriez être en mesure d'obtenir ce dont vous avez besoin à l'aide d'un index secondaire. À l'aide de la classique RDB exemple, la commande client par exemple: vous avez une table pour les clients et un pour les commandes. Les Commandes de la table a une Clé composée de Client de HACHAGE, de l'Ordre de la PLAGE. Donc si vous voulez obtenir les 10 derniers ordres, il n'y aurait aucun moyen de le faire sans une analyse

    Mais si vous créez un Index Secondaire Global sur les commandes de "Certains Constante" -- HASH, PLAGE de dates, et interrogé à l'encontre de cet indice, ils requête serait de faire ce que vous voulez et ne vous facturer pour le RCUs impliqués avec les enregistrements renvoyés. Pas cher et d'analyse nécessaires. Remarque, écrit sera plus cher, mais dans la plupart des cas, il y a beaucoup plus de lectures que de l'écrit.

    Maintenant vous avez votre problème d'origine si vous voulez obtenir les 10 plus gros des commandes pour un jour de plus de $1000. La requête retourne les 10 dernières commandes, puis filtrer ceux de moins de $1000.

    Dans ce cas, vous pourriez créer une clé calculée de Date-OrderAmount, et les requêtes à l'encontre de cet indice serait de retour que vous souhaitez.

    Il n'est pas aussi simple que SQL, mais vous devez penser à des modèles d'accès à SQL trop. Si vous avez beaucoup de données, vous devez créer des Index dans SQL ou de la DB sera heureusement pour les analyses de table sur votre nom, ce qui va entraver la performance et augmenter vos coûts.

    Remarque que tout ce que j'ai proposé est normalisé dans le sens qu'il n'existe qu'une seule source de vérité. Vous n'êtes pas dupliquer des données -- vous êtes simplement à la refonte des vues sur elle pour obtenir ce que vous avez besoin de DynamoDB.

    Garder à l'esprit que la CONSTANTE d'un algorithme de HACHAGE s sous réserve de l'10 go par partition de limite, de sorte que vous devez à la conception autour d'elle si vous avez eu beaucoup de données active. Par exemple, en fonction de votre modèle d'accès, vous pouvez utiliser le Client et pas une constante d'un algorithme de HACHAGE. Ou utiliser les Flux d'organiser les données (ou sous-ensembles) par d'autres moyens.

    InformationsquelleAutor Andy Brand
  4. -1

    Petit hack - Itérer jusqu'à ce que vous obtenez les résultats 

    lastEvaluatedKey = null;
do {

    if(lastEvaluatedKey != null) {
        //query or scan data with last evaluated key 
    } else {
        //query or scan data WITHOUT last evaluated key 
    }        

    lastEvaluatedKey == key of last item retrieved

} while(lastEvaluatedKey != null && retrievedResultSize == 0); //== 0 or < yourLimit

    Si le nombre d'éléments récupérés est 0 et lastEvaluatedKey n'est pas null, ce qui signifie qu'il a scanné ou interrogé le nombre de lignes qui correspondent à votre limite. (et la taille de résultat est zéro, parce qu'ils ne correspondent pas l'expression de filtre)

    InformationsquelleAutor Naween Niroshan