5

Je crée une application iOS pour mobile. Un utilisateur peut créer un compte et télécharger des chaînes. Ce sera comme Twitter, vous pouvez suivre les gens, avoir des photos de profil, etc. Je ne peux pas estimer la base d'utilisateurs, mais si l'application décolle, le jeu de données total peut être assez grand.SimpleDB Sélectionnez VS DynamoDB Scan

Je stocke les objets réels sur Amazon S3, et les clés sur une base de données, listant les clés Amazon S3 est lent. Alors, qui serait mieux pour stocker les clés?

Ceci est ma connaissance de SimpleDB et DynamoDB:

SimpleDB:

  • bon marché
  • donne de bons résultats
  • Conçu pour les petits ensembles de données/moyennes
  • peut demander l'aide d'expressions sélectionnez

DynamoDB:

  • Coûteux
  • extrêmement évolutive
  • grande Réalise; réponse milliseconde
  • ne pouvez pas interroger

Ces points sont corrects à ma connaissance, DynamoDB est plus sur tueur. Rapidité et évolutivité, SimpleDB se concentre sur l'interrogation et le prix (toujours en offrant de bonnes performances). Mais si vous regardez de cette façon, ce qui sera plus rapide, télécharger toutes les clés de DynamoDB, ou faire une requête de sélection avec SimpleDB ... dur à droite? On utilise une base de données rapide pour télécharger un lot (et ensuite nous devons les faire correspondre), et l'autre utilise une base de données raisonnablement bonne performance pour interroger et télécharger les quelques objets corrects. Donc, ce qui est plus rapide:

DynamoDB télécharger tout et correspondant OU SimpleDB Interrogation et le téléchargement que

(REMARQUE: Matching signifie simplement en utilisant -rangeOfString et comparaison de chaînes, côté puissance de rien consommer ou non un serveur de temps efficace ou quoi que ce soit)

clés Mon S3 utiliseront ce format pour chaque type d'objet

accountUsername: typeOfObject: randomGeneratedKey

E.g.Si vous faites référence à un objet de compte

Rohan: Compte: shd83SHD93028rF

Ou une photo de profil:

Rohan: ProfilePic: Nck83S348DD93028rF37849SNDh

Je la clé aléatoire pour l'unicité, il ne se réfère à rien, il est simplement là pour que les clés ne sont pas répétées là-bas re chevauchement de deux objets.

Dans mon application, je peux choisir soit SimpleDB ou DynamoDB, voici donc les deux options:

  • Utilisez SimpleDB, les clés du magasin avec le format mais pas utiliser le format pour toute référence, utilisez plutôt des attributs stocké avec SimpleDB. Donc, je stocke la clé avec des attributs comme le nom d'utilisateur, le type et peut-être d'autres que je devrais également inclure dans le format de clé. Donc, si je veux obtenir l'objet compte de l'utilisateur 'Rohan'. J'utilise simplement SimpleDB Select pour interroger l'attribut 'nom d'utilisateur' et l'attribut 'type'. (où je correspond pour 'compte')

  • DynamoDB, les clés de stockage et chaque clé auront le format illustré. Je scanne toute la base de données en retournant chaque clé. Ensuite, prenez la clé et profitez du format de clé, je peux utiliser -rangeOfString pour faire correspondre ceux que je veux, puis télécharger à partir de S3.

De même, SimpleDB est apparemment distribué géographiquement, comment puis-je l'activer?

Alors, qui est plus rapide et plus fiable? Utilisation de SimpleDB pour interroger des clés avec des attributs. Ou en utilisant DynamoDB pour stocker toutes les clés, numériser (télécharger toutes les clés) et faire correspondre, par ex. -rangeOfString? Remarquez que ce ne sont que des raccourcis qui sont des pointeurs vers des objets S3.

Voici ma dernière question, et la quantité d'objets dans la base de données varie sur la réponse décidée, dois-je:

  • Créer une clé séparée/objet pour chaque objet un utilisateur
  • Créer une clé de compte/objet et stocker toutes les informations à l'intérieur

Il y aurait évidemment différents avantages et inconvénients entre ces deux options. Par exemple, il serait plus rapide de récupérer si tout est séparé, mais c'est aussi plus organisé et moins grand d'un ensemble de données pour le stocker dans un compte d'utilisateur.

Alors, qu'en pensez-vous?

Merci pour l'aide! J'ai mis une prime sur cela, vraiment besoin d'une réponse dès que possible.

+0

Juste quelques notes pour l'amour de la clarté: 1. DynamoDB a une opération d'interrogation, il faut juste utiliser un RangeKey. 2. L'opération d'analyse vous permet de rechercher des données dans toute la table, mais ne nécessite pas de télécharger la totalité de la table. 3. SimpleDB a des réplicas redondants dans la même région que votre domaine a été créé, il n'agit pas comme un CDN pour votre base de données. –

+0

@BobKinney que voulez-vous dire par vous pouvez trouver des données dans toute la table mais n'avez pas besoin de le télécharger? – MCKapur

+0

Je veux dire exactement ce que j'ai dit. Une opération d'analyse analyse toutes les données d'une table DynamoDB et renvoie uniquement les éléments de la table qui correspondent à vos paramètres d'analyse, et seuls ceux-ci doivent être téléchargés dans votre application. Les opérations d'analyse peuvent être liées de sorte que vous ne recherchiez que les premiers N résultats correspondants, mais que vous utilisiez autant de débit de lecture que nécessaire pour trouver ces N résultats. –

Répondre

6

Wow!Quelle question :)

Ok, permet de discuter de certains aspects:

S3

S3 Performance est faible plus probable que vous n'êtes pas l'ajout d'un préfixe pour les clés de cotation.

Si vous partitionnez en stockant les objets tels que: type/owner/id, la liste de tous les identifiants d'un propriétaire donné (préfixé par type/propriétaire /) sera rapide. Ou au moins, plus vite que de tout énumérer à la fois.

Dynamo Versus SimpleDB

En général, thats mon conseil:

  • Utilisation SimpleDB lorsque:

    • Votre stockage entité ne va pas passer au-dessus 10GB
    • Vous besoin d'appliquer des requêtes complexes impliquant plusieurs champs
    • Votre question s ne sont pas bien définis
    • Vous pouvez tirer parti de valeurs multiples types de données
  • Utilisation DynamoDB lorsque:

    • Votre stockage entité passera 10GB
    • Vous voulez à l'échelle de la demande/débit en cours
    • Vos requêtes et votre modèle sont bien définis et peu susceptibles de changer.
    • Votre modèle est dynamique, impliquant un schéma lâche
    • Vous pouvez mettre en cache sur votre côté client vos requêtes (donc vous pouvez économiser sur le débit en interrogeant le cache avant Dynamo)
    • Vous voulez faire ensemble/Rollup résumés, à l'aide de mises à jour atomique

Compte tenu de votre description actuelle, il semble SimpleDB est en fait mieux, depuis: - votre modèle est pas complètement défini - Vous pouvez reporter certains aspects de la décision, car il faut un moment pour frapper le (10G iB) limite

géographique SimpleDB

Il ne supporte pas. Cela fonctionne seulement de nous-east-1 afaik.

Appellation clé

Cela vaut plus de Dynamo: Chaque fois que vous pouvez, utilisez Hash + Key Range.Mais vous pouvez aussi créer des clés à l'aide Hash et appliquer certaines requêtes, comme:

  • Liste tous mes dossiers sur la table T qui commence par accountid:
  • Liste tous mes dossiers sur la table T qui commence par accountid:image

Cependant, ce sont des scans du tout. Gardez cela à l'esprit.

(Voir ceci pour un aperçu: http://docs.amazonwebservices.com/amazondynamodb/latest/developerguide/API_Scan.html)

Bonus Track

Si vous utilisez Java, nuageuses-données sur Maven Central comprend SimpleJPA avec quelques extensions à la carte Blob Les champs à S3. Alors, donnez un coup d'oeil:

http://bitbucket.org/ingenieux/cloudy

Merci

+0

Merci! Très rassurant – MCKapur