Je regarde DynamoDB d'Amazon car il semble qu'il enlève tous les tracas de la maintenance et de la mise à l'échelle de votre serveur de base de données. J'utilise actuellement MySQL, et la maintenance et la mise à l'échelle de la base de données est un casse-tête complet.
J'ai parcouru la documentation et j'ai du mal à comprendre comment vous structureriez vos données afin qu'elles puissent être facilement récupérées.
Je suis totalement nouveau sur NoSQL et les bases de données non relationnelles.
D'après la documentation Dynamo, il semble que vous ne pouvez interroger une table que sur la clé de hachage principale et la clé de plage principale avec un nombre limité d'opérateurs de comparaison.
Ou vous pouvez exécuter une analyse complète de la table et lui appliquer un filtre. Le problème est qu'il ne numérisera que 1 Mo à la fois, vous devrez donc probablement répéter votre analyse pour trouver un nombre X de résultats.
Je me rends compte que ces limitations leur permettent de fournir des performances prévisibles, mais il semble que cela rend très difficile la sortie de vos données. Et effectuer des analyses complètes de table semble comme si ce serait vraiment inefficace, et deviendrait seulement moins efficace au fil du temps à mesure que votre table grandit.
Par exemple, disons que j'ai un clone Flickr. Ma table Images pourrait ressembler à ceci:
Donc, en utilisant la requête, je serais en mesure de répertorier toutes les images des 7 derniers jours et de le limiter à X nombre de résultats assez facilement.
Mais si je voulais lister toutes les images d'un utilisateur particulier, je devrais faire une analyse complète de la table et filtrer par nom d'utilisateur. Il en irait de même pour les balises.
Et comme vous ne pouvez numériser que 1 Mo à la fois, vous devrez peut-être effectuer plusieurs numérisations pour trouver un nombre X d'images. Je ne vois pas non plus de moyen de m'arrêter facilement au nombre X d'images. Si vous essayez de saisir 30 images, votre première numérisation peut en trouver 5, et votre seconde peut en trouver 40.
Ai-je ce droit? Est-ce essentiellement un compromis? Vous obtenez des performances de base de données prévisibles très rapides et pratiquement sans entretien. Mais le compromis est que vous devez construire beaucoup plus de logique pour gérer les résultats?
Ou suis-je totalement hors de la base ici?
Oui, vous avez raison sur le compromis entre performances et flexibilité des requêtes.
Mais il existe quelques astuces pour réduire la douleur - les indices secondaires/dénormalisation étant probablement les plus importants.
Vous auriez une autre table saisie sur l'ID utilisateur, répertoriant toutes leurs images, par exemple. Lorsque vous ajoutez une image, vous mettez à jour ce tableau ainsi que l'ajout d'une ligne au tableau saisi sur l'ID d'image.
Vous devez décider des requêtes dont vous avez besoin, puis concevoir le modèle de données qui les entoure.
Je pense que vous devez créer votre propre index secondaire, en utilisant une autre table.
Ce "schéma" de table pourrait être:
User ID (String, Primary Key)
Date Added (Number, Range Key)
Image ID (Number)
-
De cette façon, vous pouvez également interroger par ID utilisateur et filtrer par date
Vous pouvez utiliser clé composite de plage de hachage comme index principal.
Depuis la page DynamoDB:
Une clé primaire peut être une clé de hachage à attribut unique ou une clé de plage de hachage composite. Une clé primaire de hachage à attribut unique pourrait être, par exemple, "UserID". Cela vous permettrait de lire et d'écrire rapidement des données pour un élément associé à un ID utilisateur donné.
Une clé composite de plage de hachage est indexée en tant qu'élément de clé de hachage et élément de clé de plage. Cette clé en plusieurs parties maintient une hiérarchie entre les première et deuxième valeurs d'élément. Par exemple, une clé composite de plage de hachage peut être une combinaison de "UserID" (hachage) et "Timestamp" (plage). En maintenant l'élément clé de hachage constant, vous pouvez rechercher dans l'élément clé de plage pour récupérer des éléments. Cela vous permettrait d'utiliser l'API de requête pour, par exemple, récupérer tous les éléments pour un seul ID utilisateur sur une plage d'horodatages.