Conception de base de données DynamoDB (magasin de valeur-clé, noSQL)

Question

Je suis habitué à MySQL et essaie maintenant de comprendre comment utiliser les magasins de valeurs clés. Ce que je n'ai pas vu sont de bons noobs comme des exemples de conception de base de données et comment vous insérer et obtenir des informations.

Est-ce une représentation correcte de la façon dont vous stockez des données de MySQL dans un magasin de valeurs clés?

TYPE: MySQL 
TABLE: users 
COLUMNS: user_id(primary), username, location 

TYPE: Key Value Store 
TABLE: users 
KEY: user_id 
VALUES: username, location 

Donc, si j'ai raison ci-dessus. Tirer des informations générales sur l'utilisateur est assez simple à comprendre. Mais comment puis-je préformer la requête suivante dans un magasin de valeurs clés? La façon dont je pensais que vous pourriez faire cela facilement est de créer une autre table. (Supposons qu'il ya plus de 5 000 utilisateurs, je suis sûr qu'il ya d'autres façons de le faire si vous aviez seulement quelques centaines)

--Original Table-- 
TYPE: Key Value Store 
TABLE: users 
KEY: user_id 
VALUES: username, location 

--Additional "query" Table-- 
TYPE: Key Value Store 
TABLE: user-location 
KEY: location 
VALUES: user_id 

Cependant, nous avons maintenant besoin de régler deux tables lorsque quelqu'un de nouveau rejoint, met à jour leur emplacement, etc. Ce n'est pas une affaire énorme, je suppose, vous devez juste être super précis avec votre code d'application.

Est-ce la meilleure façon de résoudre ces problèmes? Ou est-ce que je manque quelque chose?

Answer 1

Mise à jour Réponse (Jan-2014)

DynamoDB a commencé à soutenir Global Secondary Indices ce qui signifie que vous pouvez maintenant mettre un index sur l'emplacement et rapide de retrouver uniquement les vivent au Mexique.

Notez qu'au moment de l'écriture (cela pourrait changer) vous ne pouvez pas ajouter d'index aux tables existantes.

Réponse originale (mars-2013)

Notes sur NoSQL en général:
SGBD NoSQL se concentrent généralement sur l'évolutivité.
Ils ajoutent aussi généralement une surcharge d'application en termes de plus de code côté serveur.

Vous devriez vous demander "combien de fois aurais-je besoin pour interroger les utilisateurs du Mexique"
La réponse vous dirigera probablement dans la bonne approche lors de la modélisation de votre base de données.
C'est aussi la raison pour laquelle il n'y a pas « parfait unique » et pas vraiment « échantillons noob » (au moins à ma connaissance)

Vous voyez maintenant DynamoDB en particulier, vous n'avez pas le luxe du secondaire les index (contrairement aux autres solutions NoSQL qui en ont), vous devez donc créer des tables en tant qu'index. Dans votre modèle, vous pouvez créer une table où la clé de hachage est l'emplacement et la clé de plage est l'ID de l'utilisateur. Ainsi, avec un appel d'API QUERY, vous pouvez obtenir tous les utilisateurs de MEXICO. Vous pouvez penser à d'autres implémentations, par exemple garder les ids concaténés dans un seul objet, mais encore une fois, puisque DynamoDB n'accepte que des objets de 64 Ko - vous rencontrerez probablement un problème de mise à l'échelle ici.

Answer 2

Voici une vidéo récente sur YouTube qui constitue une bonne réponse à la question. Autour de la marque de 10 minutes est quand ils commencent à parler des spécificités de l'utilisation de DynamoDB. Mais toute la vidéo est bonne pour quelqu'un qui veut en savoir plus.

Webinar: Amazon Dynamo DB - http://youtu.be/meBjA68DeIU

Answer 3

Si votre conception est telle que vous finissez par faire beaucoup de recherches en fonction de l'emplacement, alors vous devriez re-conception de la table utilisateur Localisation comme hashkey et userId comme la clé de gamme. Mais au-dessus de la manière supprime la possibilité d'interroger les utilisateurs sur leur nom ou userID, aussi bien que l'insertion d'un nouvel utilisateur ne peut pas vérifier l'unicité dans userID (contradictoire à ce que clé primaire dans MySql faisait).

Maintenant, si vous ne faites pas une recherche basée sur l'emplacement assez souvent, l'exécution d'une opération d'analyse peut être une meilleure solution. La meilleure approche serait, comme vous l'avez mentionné, de faire tous ces traitements au niveau de l'API en fonction de vos besoins.

Answer 4

Ne pas gérer vous-même les tables d'index séparées.

Utilisez à la place la nouvelle fonctionnalité global secondary index.