web-dev-qa-db-fra.com

Utilisation de S3 comme base de données par rapport à une base de données (par exemple MongoDB)

En raison d'une configuration simple et de faibles coûts, j'envisage d'utiliser le compartiment AWS S3 au lieu d'une base de données NoSQL pour enregistrer les paramètres utilisateur simples en tant que JSON (environ 30 documents).

J'ai recherché les inconvénients suivants de ne pas utiliser une base de données qui ne sont pas pertinents pour mon cas d'utilisation:

  • La liste des compartiments/fichiers vous coûtera de l'argent.
  • Aucune mise à jour - vous ne pouvez pas mettre à jour un fichier, remplacez-le simplement.
  • Pas d'index.
  • Le versioning vous coûtera $$.
  • Pas de recherche
  • Aucune transaction
  • Aucune API de requête (SQL ou NoSQL)

Y a-t-il d'autres inconvénients à utiliser un compartiment S3 au lieu d'une base de données?

mongodbamazon-web-servicesamazon-s3nosql
21
Simon Thiel

Vous "envisagez d'utiliser le compartiment AWS S3 au lieu d'une base de données NoSQL", mais le fait est qu'Amazon S3 est effectivement est une base de données NoSQL.

Il s'agit d'un très grand magasin de valeurs-clés. La clé est le nom du fichier, la valeur est le contenu du fichier.

Si vos besoins sont simplement "Stocker une valeur avec cette clé" et "Récupérer une valeur avec cette clé", alors cela fonctionnera très bien!

En fait, les anciennes commandes sur Amazon.com (plus d'un an) sont apparemment archivées sur Amazon S3 car elles sont en lecture seule (pas de retours, pas de modifications).

Bien que plus lent que DynamoDB, Amazon S3 coûte certainement beaucoup moins cher pour le stockage!

20
John Rotenstein

Contexte: nous utilisons S3 pour certaines "bases de données" ( allumées. stockage structuré clé/valeur).

Il convient de noter que S3 a effectivement une recherche et, selon la façon dont vous structurez vos données, des requêtes sous la forme S3 Select (et, si vous avez le temps: Athena).

Cependant, le plus grand inconvénient/défi architectural est que S3 est finalement cohérent (ce qui est en fait la raison pour laquelle vous ne pouvez pas "mettre à jour" un fichier). Cela se manifeste dans certains comportements que votre architecture devra tolérer:

  • Les opérations sont mises en cache par clé, donc si vous essayez d'obtenir un objet qui n'existe pas, puis que vous le créez - pendant un certain temps * tout objet sur cet objet retournera qu'il n'existe pas.
  • Il n'y a pas de cache global, vous pouvez donc obtenir deux versions différentes du même objet pendant un certain temps * après qu'il a été remplacé.
  • Les opérations de liste fournissent un itérateur semi-instable. Si vous allez lister sur un grand nombre d'objets dans un bucket en cours de mise à jour, il est probable que vous n'allez pas visiter tous les objets à la fin de l'itérateur.

* la période de temps n'est pas délibérément définie par AWS, cependant, d'après l'observation, elle est rarement supérieure à une minute.

9
thomasmichaelwallace