データベースとしてのS3とデータベース（MongoDBなど）の使用
シンプルなセットアップと低コストのため、NoSQLデータベースの代わりにAWS S3バケットを使用して、シンプルなユーザー設定をJSON（約30ドキュメント）として保存することを検討しています。
私のユースケースに関係のないデータベースを使用しないことの次の欠点を調査しました。
- バケット/ファイルのリストはあなたにお金がかかります。
- 更新なし-ファイルを更新することはできません。置き換えるだけです。
- インデックスはありません。
- バージョニングには$$かかります。
- 検索なし
- 取引なし
- クエリAPIなし（SQLまたはNoSQL）
データベースの代わりにS3バケットを使用することの他の欠点はありますか？
あなたは「NoSQLデータベースの代わりにAWS S3バケットを使用することを検討しています」が、Amazon S3が事実上is NoSQLデータベースであることは事実です。
これは非常に大きなKey-Valueストアです。キーはファイル名、値はファイルの内容です。
あなたのニーズが単に「このキーで値を保存する」と「このキーで値を取得する」である場合、それはうまくいきます！
実際、Amazon.comでの古い注文（1年以上前）は読み取り専用（返品なし、変更なし）であるため、Amazon S3にアーカイブされているようです。
Amazon S3はDynamoDBよりも低速ですが、ストレージのコストが大幅に低くなります。
コンテキスト：一部の「データベース」にS3を使用します（lit。key/value構造化ストレージ）。
S3には実際に検索があり、データの構造に応じて S3 Select の形式でクエリを実行することに注意してください（時間がある場合：Athena）。
ただし、最大の欠点/アーキテクチャ上の課題は、S3が最終的に一貫していることです（これが実際にファイルを「更新」できない理由です）。これは、アーキテクチャーが許容する必要があるいくつかの動作に現れます。
- 操作はキーごとにキャッシュされるため、存在しないオブジェクトを取得してから作成しようとすると、一定期間*、そのオブジェクトを取得すると、存在しないことが返されます。
- グローバルキャッシュがないため、上書きされた後、一定期間*に同じオブジェクトの2つの異なるバージョンを取得できます。
- リスト操作は、準不安定な反復子を提供します。更新されているバケット内の多数のオブジェクトについてlistにアクセスする場合、すべてのイテレータの終わりまでのオブジェクト。
*期間はAWSによって意図的に定義されていませんが、観察から、それが1分を超えることはめったにありません。