目次
- レガシー NoSQL DB・DynamoDB への移行推奨
- 概要
- サービス現状:レガシーステータス
- Amazon SimpleDB の本質と構成要素
- SimpleDB のアーキテクチャと制限
- SimpleDB → DynamoDB への移行戦略
- SimpleDB × DynamoDB 詳細機能比較
- SimpleDB の代替サービス選定ガイド
- SimpleDB のコスト分析
- 実装パターン
- SimpleDB 移行完全チェックリスト
- まとめ
- SimpleDB × DynamoDB 詳細機能比較表(追加)
- SimpleDB のレガシー機能と DynamoDB への置き換え戦略
- SimpleDB 移行のコスト効果分析
- SimpleDB システムの監視・診断
- まとめ
- 参考リンク
Amazon SimpleDB 完全ガイド v2.0
レガシー NoSQL DB・DynamoDB への移行推奨
概要
Amazon SimpleDB は AWS が 2007 年から提供する 初期段階のレガシー NoSQL データベース です。DynamoDB の前身にあたり、スキーマレス・マルチバリュー属性・自動インデックスの特徴を持ちます。2026 年現在、AWS はメンテナンスモードで稼働しており、新規利用は推奨されていません。スケール・パフォーマンス・機能すべてで Amazon DynamoDB が優れており、すべての新規ワークロードは DynamoDB への採用が推奨されています。
初心者向けメモ
SimpleDB は「2000 年代の古い NoSQL DB」です。今なら DynamoDB を選びます。既存のレガシーアプリケーションがある場合のみ参考にしてください。
サービス現状:レガシーステータス
Amazon SimpleDB 重要ステータス(2026年4月現在)
├─ サービス状態:メンテナンスモード(新機能なし)
├─ 新規開発:非推奨(DynamoDB を選択すべき)
├─ 既存顧客:継続利用可(互換性維持)
├─ サポート:セキュリティパッチ・可用性改善のみ
├─ スケール上限:ドメインあたり 10 GB(厳しい制限)
├─ 無料枠:1 GB/月無料 + $0.17/GB/月
└─ 推奨移行先:Amazon DynamoDB(+DAX / Aurora)
SimpleDB が直面する制限:
| 制限項目 | 仕様 | DynamoDB との比較 |
|---|---|---|
| スケール上限 | ドメインあたり 10 GB | 無制限(ペタバイト規模対応) |
| スループット | 固定・手動スケーリング | プロビジョンド / オンデマンド |
| データ型 | 文字列のみ | Number / Binary / List / Map / Set / Boolean |
| 属性数 | アイテムあたり最大 256 属性 | 無制限 |
| クエリ機能 | SimpleDB Select(SQL サブセット) | DynamoDB Query / Scan + Global Secondary Indexes |
| トランザクション | 非対応 | ACID トランザクション(複数アイテム対応) |
| 一貫性 | 最終的一貫性 / 強整合性 | 強整合性 / 最終的一貫性 |
| ストリーム | 非対応 | DynamoDB Streams(変更キャプチャ) |
| グローバル | 非対応 | Global Tables(複数リージョン) |
| バックアップ | ポイントインタイムリカバリなし | PITR / AWS Backup 対応 |
| パフォーマンス | 低~中(遅い) | 高(ミリ秒) |
Amazon SimpleDB の本質と構成要素
データモデル
SimpleDB の基本単位:
Domain(テーブルに相当)
├─ Item(行に相当):item_id で一意識別
│ ├─ Attribute 1: value_set(複数値対応)
│ │ ├─ "color": ["red", "blue", "green"](マルチバリュー)
│ │ ├─ "size": ["L"](シングルバリュー)
│ │ └─ "price": ["29.99"](数値は文字列で保存)
│ │
│ ├─ Attribute 2: value_set
│ └─ Attribute N: value_set
│
└─ Domain 内全ての属性は自動インデックス化
重要な特徴:
- マルチバリュー属性: 1 つの属性が複数の値を持つ → リレーショナル DB で言う 1:N 関係を表現
- スキーマレス: アイテムごとに異なる属性構成が可能
- 全属性自動インデックス: クエリ最適化が不要
- 文字列のみ: 数値・日付も文字列として保存(クエリ時に解釈)
SimpleDB アイテム例
<!-- SimpleDB アイテム表現 -->
<Item>
<Name>product-001</Name>
<Attribute>
<Name>ProductName</Name>
<Value>MacBook Pro 16</Value>
</Attribute>
<Attribute>
<Name>Category</Name>
<Value>Computers</Value>
</Attribute>
<Attribute>
<Name>Price</Name>
<Value>2499.00</Value>
</Attribute>
<Attribute>
<Name>Tags</Name>
<Value>Apple</Value>
</Attribute>
<Attribute>
<Name>Tags</Name>
<Value>Laptop</Value>
</Attribute>
<Attribute>
<Name>Tags</Name>
<Value>2026</Value>
</Attribute>
</Item>
対応する JSON 表現:
{
"item_id": "product-001",
"ProductName": "MacBook Pro 16",
"Category": "Computers",
"Price": "2499.00",
"Tags": ["Apple", "Laptop", "2026"]
}
SimpleDB Select(クエリ言語)
SELECT * FROM products WHERE category = 'Computers'
ORDER BY price DESC
LIMIT 20
SELECT COUNT(*) FROM products WHERE price < 1000
SELECT DISTINCT category FROM products
SELECT * FROM products
WHERE tags LIKE '%Laptop%'
AND price > 500
SimpleDB のアーキテクチャと制限
一貫性モデル
SimpleDB は複数 AZ に自動レプリケーション:
アプリケーション
↓ Put Item
Primary Node (AZ-1)
↓(非同期レプリケーション)
Replica (AZ-2)
Replica (AZ-3)
↓
Get Item
├─ 最終的一貫性(デフォルト): 複製完了待たず即座に返す → 古い値を読む可能性
└─ 強整合性(要明示): レプリケーション完了を待つ → 最新値保証・スループット半減
API 使用例:
# 最終的一貫性(デフォルト)- 高速
response = sdb.get_attributes(
DomainName='products',
ItemName='product-001'
)
# 強整合性 - 遅い(レプリケーション待機)
response = sdb.get_attributes(
DomainName='products',
ItemName='product-001',
ConsistentRead=True
)
ドメイン上限とスケーリング
- Domain(テーブル)あたり最大 10 GB
- 例)
- ・各アイテム平均 1 KB → 10,000 アイテムが上限
- ・各アイテム平均 10 KB → 1,000 アイテムが上限
10 GB を超えると、ドメインを分割する必要があり、アプリケーション側でシャーディングロジックを実装:
# SimpleDB での手動シャーディング
def get_domain_for_user(user_id):
shard_num = hash(user_id) % 10 # 10 個のドメインに分散
return f"users_shard_{shard_num}"
# ユーザー取得時にシャード計算が必要
domain = get_domain_for_user('user-12345')
response = sdb.get_attributes(
DomainName=domain,
ItemName='user-12345'
)
DynamoDB なら自動的に分散・スケール:
# DynamoDB - スケーリングは AWS が自動管理
response = dynamodb.get_item(
TableName='users', # 1 つのテーブル
Key={'user_id': {'S': 'user-12345'}}
)
SimpleDB → DynamoDB への移行戦略
段階的な移行計画
Phase 1: 分析・設計(1-2 週間)
├─ SimpleDB の全アイテム数・属性構成を把握
├─ DynamoDB テーブル設計(PK / SK / GSI)
└─ マルチバリュー属性の List 型への変換ロジック設計
Phase 2: DynamoDB 環境構築(1 週間)
├─ DynamoDB テーブル作成
├─ Global Secondary Indexes(GSI)定義
└─ DAX(キャッシュ)セットアップ(オプション)
Phase 3: データ移行(1-4 週間)
├─ SimpleDB から全データをエクスポート(SDF フォーマット)
├─ 形式変換スクリプト実装(JSON → DynamoDB Item)
├─ DynamoDB Batch WriteItem で一括ロード
└─ レコード数・チェックサム検証
Phase 4: アプリケーション更新(2-4 週間)
├─ SimpleDB API → DynamoDB API への置き換え
├─ DynamoDB クエリ最適化(GSI 活用)
└─ キャッシング戦略(DAX / ElastiCache)
Phase 5: 並行検証(2-4 週間)
├─ SimpleDB と DynamoDB の並行実行
├─ 結果の差分検査・パフォーマンス比較
└─ ロールバック計画の確認
Phase 6: 本番切り替え(1 日)
├─ SimpleDB 読み取り停止
├─ 最終差分同期
└─ DynamoDB 本番流量に切り替え
データモデル変換例
SimpleDB(マルチバリュー属性):
{
"item_id": "order-001",
"customer_name": "Alice",
"items": ["product-001", "product-002", "product-003"],
"prices": ["29.99", "49.99", "19.99"],
"status": "shipped"
}
DynamoDB(List 型 + Map 型):
{
"order_id": {"S": "order-001"},
"customer_name": {"S": "Alice"},
"items": {
"L": [
{"S": "product-001"},
{"S": "product-002"},
{"S": "product-003"}
]
},
"order_items": {
"L": [
{
"M": {
"product_id": {"S": "product-001"},
"price": {"N": "29.99"}
}
},
{
"M": {
"product_id": {"S": "product-002"},
"price": {"N": "49.99"}
}
}
]
},
"status": {"S": "shipped"}
}
Python による移行スクリプト例
import boto3
import json
from decimal import Decimal
sdb = boto3.client('sdb')
dynamodb = boto3.resource('dynamodb')
source_domain = 'legacy_products'
target_table_name = 'products'
def migrate_simpledb_to_dynamodb():
"""SimpleDB から DynamoDB へのデータ移行"""
# DynamoDB テーブル参照
table = dynamodb.Table(target_table_name)
# SimpleDB から全アイテム取得
items = fetch_all_items_from_simpledb(source_domain)
batch_count = 0
with table.batch_writer(batch_size=25) as batch:
for sdb_item in items:
# SimpleDB Item → DynamoDB Item に変換
dynamo_item = convert_simpledb_to_dynamodb(sdb_item)
# バッチ書き込み
batch.put_item(Item=dynamo_item)
batch_count += 1
if batch_count % 100 == 0:
print(f"Migrated {batch_count} items...")
print(f"Migration complete: {batch_count} items")
def fetch_all_items_from_simpledb(domain_name):
"""SimpleDB からすべてのアイテムを取得(ページネーション対応)"""
items = []
next_token = None
while True:
params = {
'DomainName': domain_name,
'SelectExpression': 'SELECT * FROM `' + domain_name + '`'
}
if next_token:
params['NextToken'] = next_token
response = sdb.select(**params)
items.extend(response['Items'])
if 'NextToken' not in response:
break
next_token = response['NextToken']
return items
def convert_simpledb_to_dynamodb(sdb_item):
"""SimpleDB Item を DynamoDB Item フォーマットに変換"""
dynamo_item = {}
# Item name → PK に変換
dynamo_item['id'] = sdb_item['Name']
# Attributes → DynamoDB フォーマット
for attr in sdb_item.get('Attributes', []):
attr_name = attr['Name']
attr_values = attr['Value']
# マルチバリュー属性の場合
if isinstance(attr_values, list) and len(attr_values) > 1:
dynamo_item[attr_name] = attr_values
elif isinstance(attr_values, list) and len(attr_values) == 1:
# シングルバリュー属性
value = attr_values[0]
# 数値判定
if is_numeric(value):
dynamo_item[attr_name] = Decimal(value)
else:
dynamo_item[attr_name] = value
else:
dynamo_item[attr_name] = attr_values
return dynamo_item
def is_numeric(value):
"""値が数値かどうかの判定"""
try:
float(value)
return True
except ValueError:
return False
# 実行
if __name__ == '__main__':
migrate_simpledb_to_dynamodb()
SimpleDB × DynamoDB 詳細機能比較
| 機能 | SimpleDB | DynamoDB |
|---|---|---|
| Partition Key | item_id(自動) | PK 明示設定 |
| Sort Key | なし | オプション |
| Global Secondary Indexes | なし | 最大 20 個(無制限) |
| Local Secondary Indexes | なし | 最大 10 GB(PK あたり) |
| 属性フィルター | WHERE 句で可能 | FilterExpression で可能 |
| 複数属性のソート | ORDER BY(限定) | GSI + SortKey で自由 |
| 原子的書き込み | Put / Delete のみ | Put / Update / Delete / Transact |
| ACID トランザクション | 非対応 | 対応(複数アイテム) |
| Time To Live(TTL) | 非対応 | サポート(自動削除) |
| Point-in-Time Recovery | なし | 35 日間のフルバックアップ |
| Streams | なし | DynamoDB Streams(変更ログ) |
| Global Tables | なし | 複数リージョン自動同期 |
| キャッシング | なし | DAX(専用キャッシュレイヤー) |
| バックアップ | 手動のみ | オンデマンド / スケジュール |
SimpleDB の代替サービス選定ガイド
DynamoDB との選定基準
| 判断基準 | SimpleDB | DynamoDB |
|---|---|---|
| スケール | 10 GB 以下 | 無制限 |
| スループット | 低~中(MB/s) | 高(GB/s) |
| 一貫性要件 | 最終的一貫性で OK | 強整合性必須 |
| 複雑クエリ | SQL サブセット | キー ベースクエリ + GSI |
| トランザクション | 不要 | 複数アイテムの ACID 必須 |
| リアルタイム分析 | 不要 | DynamoDB Streams で可能 |
| マルチリージョン | 不要 | Global Tables で必須 |
| 運用・学習 | 簡単 | 少し複雑(設計・最適化) |
その他の代替サービス
| サービス | 特徴 | 推奨ケース |
|---|---|---|
| Amazon Aurora | RDB・スケーラブル・ACID トランザクション | スキーマ固定・複雑なクエリが必要 |
| Amazon Cassandra(Keyspaces) | 大規模時系列データ・高スループット | IoT / センサーデータ |
| MongoDB(DocumentDB) | ドキュメント DB・JSON フォーマット | flexible スキーマ・複雑階層構造 |
| Azure Cosmos DB | マルチ API(SQL / NoSQL)・グローバル分散 | ハイブリッドクラウド環境 |
SimpleDB のコスト分析
SimpleDB の課金
ストレージ:$0.17/GB/月(最初 1 GB は無料)
CPU:$0.14/Machine Hour
例)100 GB のドメイン・月 100 時間利用
ストレージコスト = (100 - 1) * $0.17 = $16.83/月
CPU コスト = 100 * $0.14 = $14/月
合計 = $30.83/月
DynamoDB の課金(オンデマンド)
書き込み:$1.25 / 100万 WCU
読み取り:$0.25 / 100万 RCU
例)月 1 億 RCU / 1000 万 WCU
読み取り = 100 * $0.25 = $25
書き込み = 10 * $1.25 = $12.50
合計 = $37.50/月
※ プロビジョンド容量なら、使用量に応じてさらに安価
実装パターン
Pattern 1: 簡単な Key-Value 検索(DynamoDB)
import boto3
dynamodb = boto3.resource('dynamodb')
table = dynamodb.Table('products')
# 単純な Get
response = table.get_item(
Key={'product_id': 'prod-001'}
)
product = response.get('Item', {})
print(product)
# Put
table.put_item(Item={
'product_id': 'prod-002',
'name': 'iPad',
'price': 599,
'category': 'Tablets'
})
Pattern 2: 複雑なクエリ(GSI 活用)
# カテゴリ別の商品検索
response = table.query(
IndexName='category-price-index', # GSI
KeyConditionExpression='category = :cat AND price < :max_price',
ExpressionAttributeValues={
':cat': 'Computers',
':max_price': Decimal('2000')
}
)
for product in response['Items']:
print(f"{product['name']} - ${product['price']}")
Pattern 3: バッチ操作
# 複数アイテムの一括書き込み
with table.batch_writer(batch_size=25) as batch:
for i in range(100):
batch.put_item(Item={
'product_id': f'prod-{i:04d}',
'name': f'Product {i}',
'price': 10 + i
})
SimpleDB 移行完全チェックリスト
[✓] Step 1: 現状分析
[✓] SimpleDB ドメイン数・アイテム総数確認
[✓] 平均アイテムサイズ・属性構成分析
[✓] ピークスループット・レイテンシー測定
[✓] マルチバリュー属性の一覧化
[✓] Step 2: DynamoDB 設計
[✓] テーブル PK / SK 決定
[✓] GSI / LSI 設計(クエリパターンに基づく)
[✓] キャパシティ(プロビジョンド / オンデマンド)決定
[✓] TTL / ストリーム設定
[✓] Step 3: 環境構築
[✓] DynamoDB テーブル作成
[✓] IAM ロール・セキュリティグループ設定
[✓] DAX クラスター構築(オプション)
[✓] AWS Backup ポリシー設定
[✓] Step 4: データ移行
[✓] エクスポートスクリプト実装・テスト
[✓] 形式変換・バリデーション実装
[✓] 初期ロード実行(小規模テスト)
[✓] 大規模ロード(本番スケール)
[✓] Step 5: 検証
[✓] 行数・チェックサム検証
[✓] ランダムサンプリングでデータ完全性確認
[✓] パフォーマンステスト(レイテンシー・スループット)
[✓] 負荷テスト(ピークスループット対応)
[✓] Step 6: アプリケーション更新
[✓] API 置き換え(boto3)
[✓] クエリロジック最適化(GSI 活用)
[✓] キャッシング戦略実装(DAX / ElastiCache)
[✓] 例外処理・リトライロジック更新
[✓] Step 7: 本番切り替え
[✓] カナリアデプロイ(5% → 25% → 50% → 100%)
[✓] リアルタイム監視・アラート確認
[✓] ロールバック計画実行確認
[✓] SimpleDB 読み取り停止
まとめ
| 項目 | 詳細 |
|---|---|
| SimpleDB の立場 | AWS の初代 NoSQL DB(2007 年)。DynamoDB の前身。スケール 10 GB、マルチバリュー属性特性で独自だが、機能・パフォーマンスで大きく時代遅れ。メンテナンスモードで新機能なし。 |
| 推奨判断 | 新規開発は DynamoDB 一択。既存 SimpleDB ワークロードは、スケール・パフォーマンス・コストすべてで DynamoDB への移行が優位。 |
| 移行タイムライン | 小規模(<10 GB)なら 4〜8 週間、大規模なら 12〜16 週間推奨。並行検証期間(2〜4 週間)含む。 |
| コスト | SimpleDB は固定 Machine Hour 料金で遊休コスト発生。DynamoDB はオンデマンドなら実用量ベース課金でコスト削減可能(多くのケースで安価)。 |
| サポート | AWS はセキュリティパッチ継続するが新機能なし。DynamoDB は活発な開発・継続的な機能追加。 |
SimpleDB × DynamoDB 詳細機能比較表(追加)
トランザクション・整合性
| 機能 | SimpleDB | DynamoDB |
|---|---|---|
| 単一アイテム ACID | 保証 | 保証 |
| 複数アイテム ACID | 非対応 | v1.0+ でサポート(4 KB まで) |
| トランザクション分離レベル | Read Committed 相当 | Serializable |
| 分散トランザクション | 非対応 | 複数テーブルまで対応 |
| Conditional Put/Delete | サポート | UpdateExpression で高度な条件指定 |
バックアップ・リカバリ
| 項目 | SimpleDB | DynamoDB |
|---|---|---|
| Point-in-Time Recovery(PITR) | 非対応 | 35 日間のバックアップ |
| オンデマンドバックアップ | 手動スナップショップのみ | AWS Backup で自動化可能 |
| リージョン間レプリケーション | 非対応(AZ 内のみ) | Global Tables で複数リージョン |
| リカバリ時間目標(RTO) | 数時間~数日 | 数分以内 |
| 回復ポイント目標(RPO) | 1 日程度 | 秒単位 |
開発者体験
| 項目 | SimpleDB | DynamoDB |
|---|---|---|
| クエリ言語 | SimpleDB Select(SQL サブセット) | DynamoDB API + Query Language |
| ORマッピング | 少数のライブラリ | Boto3, DynamoDB オブジェクトマッパー |
| デバッグツール | AWS Console のみ | CloudWatch, X-Ray, DAX Metrics |
| モニタリング | CloudWatch(限定) | CloudWatch + Application Insights |
| ローカル開発 | DynamoDB Local はなし(SimpleDB エミュレータなし) | DynamoDB Local で完全エミュレーション可能 |
SimpleDB のレガシー機能と DynamoDB への置き換え戦略
マルチバリュー属性の変換パターン
SimpleDB では複数の値を 1 つの属性に格納:
<!-- SimpleDB -->
<Item>
<Name>user-001</Name>
<Attribute>
<Name>phone_numbers</Name>
<Value>090-1234-5678</Value>
</Attribute>
<Attribute>
<Name>phone_numbers</Name>
<Value>080-9876-5432</Value>
</Attribute>
</Item>
DynamoDB では List/Set 型で表現:
{
"user_id": {"S": "user-001"},
"phone_numbers": {
"SS": ["090-1234-5678", "080-9876-5432"]
}
}
or
{
"user_id": {"S": "user-001"},
"phone_numbers": {
"L": [
{"S": "090-1234-5678"},
{"S": "080-9876-5432"}
]
}
}
変換のポイント:
- SimpleDB の複数値属性 → DynamoDB の List/Set 型
- 検索パターンに応じて、逆正規化・GSI の活用を検討
- 複雑な多対多関係は、別テーブルで正規化も視野
SimpleDB Select(SQL)クエリから DynamoDB Query/Scan への変換
SimpleDB:
SELECT * FROM users WHERE age > 18 AND status = 'active'
ORDER BY created_date DESC
LIMIT 20
DynamoDB(Scan + FilterExpression):
response = dynamodb.scan(
TableName='users',
FilterExpression='age > :age AND #status = :status',
ExpressionAttributeNames={'#status': 'status'},
ExpressionAttributeValues={
':age': 18,
':status': 'active'
},
Limit=20
)
DynamoDB(Query + GSI、最適化版):
# GSI: status-created_date-index が存在する場合
response = dynamodb.query(
TableName='users',
IndexName='status-created_date-index',
KeyConditionExpression='#status = :status',
FilterExpression='age > :age',
ExpressionAttributeNames={'#status': 'status'},
ExpressionAttributeValues={
':status': 'active',
':age': 18
},
ScanIndexForward=False, # DESC
Limit=20
)
SimpleDB 移行のコスト効果分析
TCO 計算例(1 年間の運用コスト)
SimpleDB の場合:
ストレージ:500 GB × $0.17/GB/月 × 12 月 = $10,200
CPU:500 Machine Hour/月 × $0.14 × 12 月 = $840/月 × 12 = $10,080
バックアップ:手動管理(運用コスト)= 月 1 万円 × 12 = $120,000
スケーリング対応:エンジニア調整(月 20 時間 × 時給 $100)= $24,000
年間合計:$164,280
DynamoDB オンデマンドの場合:
読み取り容量:月 5 億 RCU × $0.25/100万 = $1,250
書き込み容量:月 1 億 WCU × $1.25/100万 = $125
ストレージ:500 GB × $0.25/GB-月 × 12 = $1,500
バックアップ:AWS Backup 自動 = $5/月 × 12 = $60
DynamoDB Streams:オプション = $0.02/100万イベント
年間合計:$16,440
コスト削減: $164,280 - $16,440 = $147,840/年(90% 削減)
SimpleDB システムの監視・診断
ヘルスチェックスクリプト
import boto3
from datetime import datetime, timedelta
def diagnose_simpledb_domain(domain_name):
"""SimpleDB ドメインの健全性診断"""
sdb = boto3.client('sdb')
cloudwatch = boto3.client('cloudwatch')
print(f"\n=== SimpleDB Diagnostics for {domain_name} ===\n")
# 1. ドメイン情報
domain_info = sdb.describe_domains(DomainNames=[domain_name])
domain = domain_info['DomainMetadata'][0]
print(f"Item Count: {domain['ItemCount']}")
print(f"Size (bytes): {domain['ItemNamesSizeBytes']}")
print(f"Attribute Value Size: {domain['AttributeValuesSizeBytes']}")
# 2. CloudWatch メトリクス
metrics = cloudwatch.get_metric_statistics(
Namespace='AWS/SimpleDB',
MetricName='UserCounter',
Dimensions=[
{'Name': 'Domain', 'Value': domain_name}
],
StartTime=datetime.now() - timedelta(hours=1),
EndTime=datetime.now(),
Period=3600,
Statistics=['Average', 'Maximum']
)
print(f"\nQuery Activity (1h):")
if metrics['Datapoints']:
for dp in metrics['Datapoints']:
print(f" {dp['Timestamp']}: {dp['Maximum']} queries")
# 3. 10 GB 制限の警告
total_size = (
domain['ItemNamesSizeBytes'] +
domain['AttributeValuesSizeBytes']
) / (1024 ** 3)
print(f"\nDomain Size: {total_size:.2f} GB")
if total_size > 8:
print("⚠️ WARNING: Approaching 10 GB limit!")
elif total_size > 5:
print("⚠️ CAUTION: Above 5 GB - monitor closely")
return domain
まとめ
| 項目 | 詳細 |
|---|---|
| SimpleDB の立場 | AWS の初代 NoSQL DB(2007 年)。DynamoDB の前身。スケール 10 GB、マルチバリュー属性特性で独自だが、機能・パフォーマンスで大きく時代遅れ。メンテナンスモードで新機能なし。 |
| 推奨判断 | 新規開発は DynamoDB 一択。既存 SimpleDB ワークロードは、スケール・パフォーマンス・コストすべてで DynamoDB への移行が優位。 |
| 移行タイムライン | 小規模(<10 GB)なら 4〜8 週間、大規模なら 12〜16 週間推奨。並行検証期間(2〜4 週間)含む。 |
| コスト | SimpleDB は固定 Machine Hour 料金で遊休コスト発生。DynamoDB はオンデマンドなら実用量ベース課金でコスト削減可能(多くのケースで 90%+ 削減)。 |
| サポート | AWS はセキュリティパッチ継続するが新機能なし。DynamoDB は活発な開発・継続的な機能追加。 |