Quel est l'intérêt d'utiliser Amazon SimpleDB ?

Question

J'ai pensé que je pouvais utiliser SimpleDB pour prendre en charge la partie la plus difficile de mon application (en ce qui concerne la mise à l'échelle) - des commentaires de type twitter, mais avec la localisation en plus - jusqu'au moment où je me suis assis pour commencer à l'implémenter réellement avec SDB.

Tout d'abord, SDB est limité à 1000 octets par valeur d'attribut, ce qui n'est pas suffisant, même pour les commentaires (il faut probablement décomposer les valeurs plus longues en plusieurs attributs).

Ensuite, la taille maximale du domaine est de 10 Go. La promesse était que vous pouviez augmenter la taille de votre domaine sans vous préoccuper de la répartition de la base de données, etc. Mais si je comprends bien, avec les domaines, j'aurais exactement le même problème qu'avec le sharding, c'est-à-dire qu'à un moment donné, il faudrait mettre en œuvre la distribution des enregistrements de données et les requêtes entre les domaines au niveau de l'application.

Même pour les objets les plus simples de l'application, à savoir les évaluations atomiques des utilisateurs, SDB n'est pas une option, car il ne peut pas calculer une moyenne dans la requête (tout est basé sur des chaînes). Ainsi, pour calculer l'évaluation moyenne des utilisateurs pour un objet, je devrais charger tous les enregistrements - 250 à la fois - et la calculer au niveau de l'application.

Est-ce que je rate quelque chose à propos de SDB ? Est-ce que 10 Go est vraiment une base de données si importante pour dépasser toutes les limitations de SDB ? J'étais honnêtement enthousiaste à l'idée de profiter de SDB, puisque j'utilise déjà S3 et EC2, mais maintenant je ne vois tout simplement pas de cas d'utilisation.

Answer 1

J'utilise SDB sur quelques applications de grande taille. La limite de 10 Go par domaine m'inquiète, mais nous parions sur le fait qu'Amazon permettra d'étendre cette limite si nous en avons besoin. Ils ont un formulaire de demande sur leur site si vous voulez plus d'espace.

En ce qui concerne les jointures entre domaines, ne considérez pas SDB comme une base de données traditionnelle. Lors de la migration de mes données vers SDB, j'ai dû en dénormaliser une partie pour pouvoir effectuer manuellement les jointures interdomaines.

La limitation à 1000 octets par attribut était également difficile à contourner. L'une des applications que je possède est un service de blog qui stocke les messages et les commentaires dans la base de données. Lors de son portage vers SDB, je me suis heurté à cette limitation. J'ai fini par stocker les messages et les commentaires sous forme de fichiers dans S3, et je les ai lus dans mon code. Comme ce serveur est sur EC2, le trafic vers S3 ne coûte rien de plus.

L'un des autres problèmes à surveiller est peut-être le modèle de cohérence éventuel sur SDB. Vous ne pouvez pas écrire des données puis les relire avec la garantie que les données nouvellement écrites vous seront retournées. Les données finiront par être mises à jour.

Tout ceci étant dit, j'aime toujours SDB. Je ne regrette pas de l'avoir adopté. Je suis passé d'un serveur SQL 2005. Je pense que j'avais beaucoup plus de contrôle avec SQL, mais une fois que j'ai abandonné ce contrôle, j'ai plus de flexibilité. Ne pas avoir besoin de prédéfinir le schéma est génial. Avec une couche de mise en cache solide et robuste dans votre code, il est facile de rendre SDB plus flexible.

Answer 2

J'ai environ 50 Go dans SimpleDB, répartis sur 30 domaines. Je l'utilise pour permettre des clés multiples sur les objets stockés dans S3, et aussi pour réduire mes coûts S3. Je n'ai pas joué avec l'utilisation de SimpleDB pour la recherche en texte intégral, mais je ne m'y risquerais pas.

SimpleDB fonctionne, c'est facile, etc., mais ce n'est pas le bon ensemble de fonctionnalités pour chaque situation. Dans votre cas, si vous avez besoin d'agrégation, SimpleDB n'est pas la bonne solution. Il est construit autour de l'école de pensée selon laquelle la base de données n'est qu'un magasin de valeurs clés, et l'agrégation doit être gérée par un processus d'agrégation qui réécrit les résultats dans le magasin de valeurs clés. C'est exactement ce dont nous avons besoin pour certaines applications.

Voici une description de la façon dont j'écrase les centimes en utilisant SimpleDB

Answer 3

Il convient d'ajouter que si le fait de devoir écrire sa propre logique de sharding entre les domaines n'est pas idéal, il l'est en termes de performances. Si, par exemple, vous devez effectuer une recherche sur 100 Go de données, il est préférable de demander à 20 machines détenant 5 Go chacune d'effectuer la même recherche sur la partie dont elles sont responsables, plutôt que de demander à une seule machine d'effectuer la totalité de la tâche. Si votre objectif est d'obtenir une liste triée, vous pouvez prendre les meilleurs résultats renvoyés par les 20 requêtes simultanées et les regrouper sur la machine à l'origine de la demande.

Cela dit, je préférerais que ce soit abstrait de l'utilisation normale et qu'il y ait quelque chose comme des "conseils" dans l'API si vous voulez aller à un niveau inférieur. Ainsi, si vous stockez 100 Go de données, laissez Amazon décider si elles doivent être réparties sur 20, 10 ou 40 machines, et distribuez le travail. Par exemple, dans la conception de BigTable de Google, à mesure qu'une table grandit, elle est continuellement partitionnée en tablettes de 400 Mo. Demander une ligne d'une table est aussi simple que cela, et BigTable se charge de déterminer où elle se trouve dans une tablette ou dans des millions de tablettes.

Là encore, BigTable vous oblige à écrire des appels MapReduce pour effectuer une requête, tandis que SimpleDB s'indexe dynamiquement pour vous, donc vous gagnez un peu, vous perdez un peu.

Answer 4

Si la taille de stockage par attribut est un problème, vous pouvez utiliser S3 pour stocker des données plus importantes et stocker les liens vers les objets S3 dans SDB. S3 n'est pas uniquement destiné aux fichiers, c'est une solution de stockage générique.

Answer 5

Amazon essaie de vous faire implémenter une simple base de données objet. C'est principalement pour des raisons de vitesse. Pensez aux enregistrements SimpleDB comme étant un pointeur/une clé vers un élément dans S3. De cette façon, vous pouvez exécuter des requêtes (lentes) contre SimpleDB pour obtenir des listes de résultats ou vous pouvez directement frapper S3 avec une clé (rapide) pour extraire l'objet lorsque vous devez récupérer ou modifier des enregistrements un par un.