OCI NoSQL Database

解決する課題

アクセスが増減しても性能が安定する DB が欲しい
容量計画・シャーディング・パッチ当てを自分でやりたくない
ミリ秒の応答を予測可能なコストで確保したい
キーバリューだけでなく、型付きの列や JSON を SQL 風に扱いたい

主要概念と用語

テーブル / 行（Row）/ 列（Column）: DynamoDB と違い、テーブルは型付きスキーマを持つ（INTEGER STRING JSON TIMESTAMP など）
シャードキー（主キーの先頭部分）: データの分散先を決める最重要キー。DynamoDB のパーティションキーに相当
主キー（Primary Key）: シャードキー＋残りのキー列で構成。並び・範囲検索に使う部分は DynamoDB のソートキーに相当
セカンダリインデックス: 主キー以外の列で検索するためのインデックス（GSI 相当。作成後も追加可）
キャパシティモード: オンデマンド（On-Demand）/ プロビジョンド（Provisioned）
読み取り/書き込みユニット（RU / WU）とストレージ GB: スループットと容量の課金・上限単位
整合性: EVENTUAL（結果整合性・既定）と ABSOLUTE（絶対整合性・読み取りコスト2倍）
TTL: 行ごとの有効期限による自動失効
Global Active Tables: 複数リージョンへ自動レプリケーション（DynamoDB グローバルテーブル相当）
コンパートメント: リソースを論理分離する OCI の枠組み（IAM の単位）

仕様・制限・クォータ

1 行は最大 512 KB（DynamoDB の 400 KB とは別の値なので注意）
整合性は EVENTUAL と ABSOLUTE を読み取りごとに選択できる
スループットは 読み取りユニット（RU）/ 書き込みユニット（WU） で測る
- 1 RU ＝ 1 秒あたり 1 KB までの結果整合性読み取り（ABSOLUTE は 2 RU 消費）
- 1 WU ＝ 1 秒あたり 1 KB までの書き込み
データはリージョン内で複数の可用性ドメイン/フォールトドメインへ自動複製され、耐久性を確保
Global Active Tables で複数リージョンへの能動-能動レプリケーションが可能
プロビジョンドモードの RU/WU/ストレージや、テナンシあたりのテーブル数などに**サービス上限（クォータ）**があり、引き上げ申請ができる

内部の仕組み

OCI NoSQL Database はシャードキーをハッシュして内部のシャード（パーティション群）へデータを分散します。負荷や容量に応じてシャードが分割・再配置され、スループットがスケールします。したがって シャードキー設計＝性能設計であり、特定キーにアクセスが偏ると**ホットシャード（ホットパーティション）**となりスループットを使い切ってスロットリングされます。

各行は型付きスキーマに従って格納され、JSON 列によりスキーマレスな入れ子データも保持できる
読み取りは既定で結果整合性。最新値を保証したい場合のみ ABSOLUTE を指定（その分 RU を多く消費）
ストレージは自動でリージョン内に冗長化され、ノード障害やパッチはサービス側が透過的に処理

設計の鉄則

RDB の正規化ではなくアクセスパターン駆動設計。「どう問い合わせるか」を先に決めてシャードキー / 主キー / セカンダリインデックスを設計する。範囲検索やソートが必要な列は主キー後方やインデックスに寄せる。

設計パターン / ベストプラクティス

アクセスパターンを列挙 → シャードキー / 主キー / セカンダリインデックスを設計（ホットシャードを避け、キーを均等に分散）
スパイクが読めないワークロードは オンデマンド キャパシティ、定常負荷は プロビジョンド でコスト最適化
別の列で検索したくなったら セカンダリインデックス（後付け可能）
全件 SCAN ではなく、シャードキー条件付きのクエリで読み取りを絞る
一時データやセッションは TTL で自動失効させ、ストレージと不要 I/O を削減

運用・監視

OCI Monitoring のメトリクスで状態を把握: ReadUnits WriteUnits ReadThrottleCount WriteThrottleCount StorageThrottleCount StorageGB
スロットルが出たら、ホットシャード か プロビジョンド容量不足を疑う（オンデマンドへ切り替え、またはキー設計を見直す）
容量変更・テーブル操作は **Work Request（非同期ジョブ）**として実行され、進捗を追跡できる
全件 SCAN を避け、シャードキーで絞ったクエリにすることで RU 消費とレイテンシを抑制

コスト

課金はスループット（RU/WU）＋ストレージ GBが基本。キャパシティモードの使い分けが最適化の肝です。

キャパシティモード	課金の考え方	向いている用途
オンデマンド	実際に消費した読み書き量に応じて従量課金	スパイクが読めない・新規・低頻度ワークロード
プロビジョンド	確保した RU/WU（と超過分）＋ストレージで課金	負荷が安定した本番。単価を抑えやすい
ストレージ	保存データ量（GB）に対して課金（両モード共通）	データ量が多いテーブル全般

セキュリティ

保存データは既定で暗号化。鍵は Oracle 管理鍵、または OCI Vault の顧客管理鍵（CMK）を選択可能
OCI IAM ポリシーで、コンパートメント単位・テーブル単位に操作権限を最小化（Allow group ... to manage nosql-tables in compartment ...）
アプリからの認証は、ハードコードした API キーではなく インスタンスプリンシパル / リソースプリンシパルを使う
プライベート接続が必要な場合は サービスゲートウェイ経由で OCI バックボーン内から到達

アンチパターン

資格情報（ユーザー API キー）をアプリ内やインスタンスにハードコードするのは NG。コンピュート上ではインスタンスプリンシパル、Functions 等ではリソースプリンシパルを使えば、鍵の配布・ローテーション・漏洩リスクを排除できます。

観点	OCI NoSQL Database	Amazon DynamoDB
位置づけ	OCI のサーバーレス NoSQL	AWS のサーバーレス NoSQL
スキーマ	テーブルに型付きスキーマあり（JSON 列も可）	スキーマレス（項目ごとに属性自由）
クエリ	SQL 風クエリ言語 + キー操作	キー中心 API（PartiQL も可）
分散キー	シャードキー（主キー先頭）	パーティションキー
スループット単位	読み取り/書き込みユニット（RU/WU）	読み取り/書き込みキャパシティユニット（RCU/WCU）
容量モード	オンデマンド / プロビジョンド	オンデマンド / プロビジョンド
多リージョン	Global Active Tables	グローバルテーブル
権限付与	OCI IAM + インスタンス/リソースプリンシパル	IAM ロール

ハンズオン / CLI例

# テーブルを作成（DDL でスキーマ定義 + オンデマンド課金）
# 主キー: id（シャードキー）。createdAt は範囲・並び用
oci nosql table create \
  --name Orders \
  --compartment-id "$COMPARTMENT_OCID" \
  --ddl-statement "CREATE TABLE Orders (id STRING, createdAt STRING, total INTEGER, PRIMARY KEY (id))" \
  --table-limits '{"maxReadUnits": 50, "maxWriteUnits": 50, "maxStorageInGBs": 25, "capacityMode": "ON_DEMAND"}' \
  --wait-for-state ACTIVE

# 1行を投入
oci nosql row update \
  --table-name-or-id Orders \
  --compartment-id "$COMPARTMENT_OCID" \
  --value '{"id": "user-123", "createdAt": "2026-06-03T00:00:00Z", "total": 4200}'

# SQL 風クエリで特定ユーザーの注文を取得（全件 SCAN を避け、シャードキーで絞る）
oci nosql query execute \
  --compartment-id "$COMPARTMENT_OCID" \
  --statement "SELECT * FROM Orders WHERE id = 'user-123'"