サービスの計画

Oracle NoSQL Database Cloud Serviceサービスを作成する前に、サービスを計画します。開始する前に、ここに記載する質問について検討し、実行することを決定してください。

この記事には次のトピックが含まれます:

開発者概要

サービス・アーキテクチャの概要を把握し、アプリケーション開発のニーズを満たすSDK/ドライバを選択します。

NDCS Developerのタスク

Oracle NoSQL Database Cloud Service (NDCS)は完全にHAサービスです。これは、低レイテンシのレスポンス時間、柔軟なデータ・モデル、および動的ワークロード向けの柔軟なスケーリングを必要とする要求の厳しいアプリケーション向けに設計されています。完全管理型サービスとして、Oracleはソフトウェアのアップグレード、セキュリティ・パッチ、ハードウェア障害、パッチ適用など、すべての管理タスクを処理します。

developer_overview.pngの説明が続きます
図developer_overview.pngの説明

NoSQL Database SDK/ドライバ- これらのSDKはUniversal Permissive License (UPL)でライセンスされ、NoSQL Cloud Serviceまたはオンプレミス・データベースで使用できます。これらはフル機能のSDKであり、豊富な機能セットを提供します。これらのドライバは、他のベンダー・クラウドで実行されているOracle NoSQLクラスタに対して実行されているアプリケーションでも使用できます。

SDK、APIガイドおよび例へのリンクは、次の表を参照してください。
  • SDK (GitHub) - SDKのインストール、接続および開始方法の詳細を提供します
  • APIガイド- SDKで使用可能なパッケージ、クラス、メソッドおよびインタフェースを提供します
  • 例- 試すことができるコード・サンプルを提供します
SDK(GitHub) APIガイド 例
Oracle NoSQL Java SDK Java SDK APIガイド Javaの例
Oracle NoSQL Python SDK Python SDK APIガイド Pythonの例
Oracle NoSQL Go SDK Go SDK APIガイド Goの例
Oracle NoSQL Node.js SDK Node.js SDK APIガイド Node.jsの例
Oracle NoSQL .NET SDK .NET SDK APIガイド .NETの例
Oracle NoSQL Rust SDK Rust SDK APIガイド 錆の例
Oracle NoSQL Spring SDK Spring SDK APIガイド 春の例

OCIコンソール- 表の作成、表の変更、表の削除、データのロード、索引の迅速な作成、索引の削除、基本問合せ、表容量の変更およびメトリックの表示を迅速に行うことができます。

OCI SDK/ドライバ – Oracle Cloud Infrastructureには、カスタム・ソリューションの開発を容易にするための多数のソフトウェア開発キット(SDK)が用意されています。これらは通常、UPLでライセンスされます。
  1. REST API
  2. SDK for Java
  3. SDK for Python
  4. Javascript用のSDK
  5. SDK for .NET
  6. SDK for Go
  7. SDK for Ruby
  8. SDK for PL/SQL

NoSQL Database SDK/ドライバとOCI SDK/ドライバの違い:

OCI SDKはRESTベースです。使いやすく機能も限られています。一方、NoSQL Database SDKには、豊富な機能セットが用意されています。NoSQL Database SDKはOCI SDKよりも次の利点があるため、使用することをお薦めします。
  • NoSQL Database SDKは、クラウド・サービス、オンプレミス・データ・ストアおよびNoSQL Cloud Simulatorに接続するアプリケーションで使用できます。
  • NoSQL Database SDKは、より豊富な開発エクスペリエンスを提供します。RESTを介してサポートされないSQL機能をさらにサポートします。
  • NoSQL Database SDKでは、Jakarta NoSQLやEclipse TopLinkなどのサードパーティ実装を使用できます。
参照:

Oracle NoSQL Database Cloud Serviceの制限

Oracle NoSQL Database Cloud Serviceには、様々なデフォルトの制限があります。Oracle NoSQL Database Cloud Service表を作成するたびに、リクエストが指定の制限内であることを確認します。一部の制限は表レベルで課され、一部はリージョン・レベルで課されます。

サービス制限、その範囲およびリクエストを発行してサービス制限を増やす方法の詳細は、サービス制限を参照してください。次に、Oracle NoSQL Database Cloud Serviceに適用される現在の制限を示します。

制限 有効範囲 説明 ホストされていない環境の値 ホスト環境の値

最大表記憶域サイズ

表

テナント当たりの最大合計ストレージ・サイズ。1つ以上の表に使用される合計領域が、この値を超えることはできません。

5TB

17.5TB

表名

表

表名の最大文字数、使用可能な文字、および先頭の文字。

表名には最大256文字を使用できます。すべての名前は文字(a-z、A-Z)で始める必要があります。後続の文字には、文字(a-z、A-Z)、数字(0-9)またはアンダースコアを使用できます。

ホストされていない環境と同じ

プロビジョニングされた容量- 最大の読取りおよび書込みスループット

表

表のプロビジョニング時の最大読取りおよび書込みスループット。

表当たり40,000読取りユニットおよび20,000書込みユニット。

ホスト環境のすべての表について、最大420,000の読取りユニットおよび合計280,000の書込みユニット

オンデマンド容量- 最大の読取りおよび書込みスループット

表

On Demand Capacityを使用して表をプロビジョニングする際の最大読取りおよび書込みスループット。

表当たり10,000読み取り単位および5,000書き込み単位。

ホスト環境では許可または不要

オンデマンド容量- 表の数

領域

On Demand Capacityのテーブル数。

3

ホスト環境では許可または不要

割当てモードの変更

表

表のプロビジョニング・モードを「プロビジョニング済」から「オンデマンド」に、またはその逆に変更します。

1日に1回のみ変更できます。

N/A

表の最大数

領域

表の最大数。

30

これは、リクエスト・サービス制限の更新を使用してカスタマイズできます。

最大列数

表

列の最大数。

50

これは、リクエスト・サービス制限の更新を使用してカスタマイズできます。

表スキーマ更新の最大数

表

表スキーマ更新の最大数。

100

これは、リクエスト・サービス制限の更新を使用してカスタマイズできます。

索引の最大数

表

索引の最大数。

5

これは、リクエスト・サービス制限の更新を使用してカスタマイズできます。

スループットおよびストレージ制限の最大数

表

スループットおよびストレージ制限の最大数。

Oracleでは:

  • 1日当たりの回数無制限のスループットとストレージの引上げ

  • 24時間当たり最大4つのスループットまたはストレージが引き下げられます。

これは、リクエスト・サービス制限の更新を使用してカスタマイズできます。

索引名

索引

最大文字数、使用可能な文字、および最初の文字。

索引名には最大64文字を使用できます。すべての名前は文字(a-z、A-Z)で始める必要があります。後続の文字には、文字(a-z、A-Z)、数字(0-9)またはアンダースコアを使用できます。

これは、リクエスト・サービス制限の更新を使用してカスタマイズできます。

WriteMultipleリクエスト当たりの個別操作の最大数

リクエスト

WriteMultipleリクエスト当たりの個別操作の最大数。

50

非ホスト環境と同じです。これは、リクエスト・サービス制限の更新を使用して増やすこともできます

WriteMultipleリクエストの最大数。

リクエスト

WriteMultipleリクエストの最大数。

25 MB

非ホスト環境と同じです。これは、リクエスト・サービス制限の更新を使用して増やすこともできます

列名

列

 最大文字数、使用可能な文字、および最初の文字。

フィールド名には最大64文字を使用できます。すべての名前は文字(a-z、A-Z)で始める必要があります。後続の文字には、文字(a-z、A-Z)、数字(0-9)またはアンダースコアを使用できます。

非ホスト環境と同じです。

最大2次索引キー・サイズ

索引

索引キーの最大数。

64バイト

これは、リクエスト・サービス制限の更新を使用してカスタマイズできます。

主キーの最大サイズ

索引

主キーの最大サイズ。

64バイト

これは、リクエスト・サービス制限の更新を使用してカスタマイズできます。

最大行サイズ

行

行の最大サイズ。

512 KB

これは、リクエスト・サービス制限の更新を使用してカスタマイズできます。

問合せ文字列の最大長。

問合せ

問合せ文字列の最大長。

10 KB

これは、リクエスト・サービス制限の更新を使用してカスタマイズできます。

サポートされているDDL操作の最大レート。

領域

サポートされているDDL操作の最大レート。

4分単位

これは、リクエスト・サービス制限の更新を使用してカスタマイズできます。

スループットおよびデータ・ストレージ・リソースの最大数。

領域

スループットおよびデータ・ストレージ・リソースの最大数。

リージョンごとに、Oracleでは次のことが許可されます:

  • 最大10万読取りユニット

  • 最大40,000書込みユニット

Oracleでは、テナント当たり最大ストレージ・サイズとして5TBが許可されます。リージョンには、ストレージ・サイズが5TBの単一の表を含めることができますが、その場合、そのリージョンは別の表を作成できません。複数の表を含める場合は、それらのすべての表のデータが最大ストレージ・サイズの5TB以内になるようにします。

420,000書き込み単位、280,000読み取り単位、17.5 TBストレージ

関連項目

容量の見積り

Oracle NoSQL Database Cloud Serviceのスループットおよびストレージ容量を予測する方法について学習します。

計算に関する基本事項

サービスのスループットおよびストレージを評価する方法を学習する前に、スループットおよびストレージ・ユニットの定義を確認してみましょう。

  • 書き込み単位(WU): 1書き込み単位は、1秒あたり最大1キロバイト(KB)のデータスループットとして定義されます。書込み操作とは、レコードを挿入、更新または削除するOracle NoSQL Database Cloud Service APIコールです。NoSQL表には、1秒間に使用できる書込みユニット数を指定する書込み制限値があります。また、索引の更新によっても書込みユニットが消費されます。

    たとえば、レコード・サイズが1 KB未満の場合は、書込み操作に1WUが必要です。レコード・サイズが1.5KBの場合は、書込み操作に2WUが必要です。

  • 読み取り単位(RU): 1読み取り単位は、最終的に一貫性のある読み取り操作のための、1秒あたり最大1Kバイトのデータのスループットとして定義されます。NoSQL表には、1秒間に使用できる読取りユニット数を指定する読取り制限値があります。

    たとえば、レコード・サイズが1 KB未満の場合は、最終的に一貫性のある読取り操作のために1 RUが必要です。レコード・サイズが1.5 KBの場合、最終的に一貫性のある読取り操作のために2 RU、絶対的に一貫性のある読取り操作のために4 RUが必要です。

  • ストレージ容量: 1ストレージ・ユニットは、1ギガバイト(GB)のデータ・ストレージです。

  • Absolute Consistency:返されるデータは、データベースに最後に書き込まれたデータである必要があります。

  • 最終的な一貫性:返されるデータは、データベースに最後に書き込まれたデータでない場合があります。データに対する新しい更新がなければ、最終的にそのデータへのすべてのアクセスで、最後に更新された値が返されます。

ノート:

Oracle NoSQL Database Cloud Serviceでは、オンデマンド容量の使用時に動的ワークロードのニーズを満たすために、読取りおよび書込み容量が自動的に管理されます。容量のニーズがオンデマンド容量の制限を超えていないことを確認することをお薦めします。詳細は、Oracle NoSQL Database Cloud Serviceの制限を参照してください。

容量ユニットに影響を与える要因

容量ユニットをプロビジョニングする前に、読取り、書込みおよびストレージ容量に影響を与える次の要因を考慮することが重要です。

  • レコード・サイズ:レコード・サイズの拡大に伴い、データの書込みまたは読取りで消費される容量ユニットも増加します。

  • データ一貫性:絶対的な一貫性読取りは、最終的な一貫性読取りの2倍のコストがかかります。

  • セカンダリ索引:表で既存のレコードが変更(追加、更新または削除)されると、セカンダリ索引の更新で書込みユニットが消費されます。書込み操作用にプロビジョニングされる合計スループット・コストは、表への書込みとローカル・セカンダリ索引の更新で消費される書込みユニットの合計です。

  • データ・モデリングの選択:スキーマレスJSONの場合、各ドキュメントは自己記述型であり、全体的なレコード・サイズにメタデータ・オーバーヘッドが追加されます。固定スキーマ表の場合、各レコードのオーバーヘッドは1バイトです。

  • クエリ・パターン:クエリ操作のコストは、取得される行数、条件の数、ソース・データのサイズ、予測、インデックスの存在によって決まります。最もコストが低い問合せでは、システムが1次索引と2次索引を利用できるように、シャード・キーまたは索引キーを(関連する索引とともに)指定します。アプリケーションは、様々な問合せを試行して消費されるスループットを調べ、操作のチューニングに役立てることができます。

実例: アプリケーション・ワークロード見積り方法

Eコマース・アプリケーションの例を参考にして、1秒当たりの読取りおよび書込みを見積る方法について学習します。この例では、Oracle NoSQL Database Cloud Serviceを使用して、アプリケーションの製品カタログ情報を格納します。

  1. アプリケーションのデータ・モデル(JSONまたは固定表)、レコード・サイズおよびキー・サイズを確認します。

    {\f2 E-Commerce}アプリケーションが{\f2 JSON}データ・モデルに準拠しており、開発者が{\f2 2}つの列を含む単純な表を作成したと想定します。1つはレコード識別子(主キー)で、もう1つは製品の機能と属性を示す JSONドキュメントです。JSONドキュメントは次のとおりで、1KB (0.8KB)未満です:

    {
  "additionalFeatures": "Front Facing 1.3MP Camera",
  "os": "Macintosh OS X 10.7", 
  "battery": {      
    "type": "Lithium Ion (Li-Ion) (7000 mAH)",
    "standbytime" : "24 hours" },
  "camera": {    
    "features": ["Flash","Video"],
    "primary": "5.0 megapixels" },
  "connectivity": {
    "bluetooth": "Bluetooth 2.1",
    "cell": "T-mobile HSPA+ @ 2100/1900/AWS/850 MHz",
    "gps": true,
    "infrared": false,
    "wifi": "802.11 b/g" },
  "description": "Apple iBook is the best in class computer
    		for your professional and personal work.",
  "display": {
    "screenResolution": "WVGA (1280 x 968)",
    "screenSize": "13.0 inches" },
  "hardware": {
    "accelerometer": true,
    "audioJack": "3.5mm",
    "cpu": "Intel i7 2.5 GHz",
    "fmRadio": false,
    "physicalKeyboard": false,
    "usb": "USB 3.0" },
  "id": "appleproduct_1",
  "images": ["img/apple-laptop.jpg"],
  "name": "Myshop.com : Apple iBook",
  "sizeAndWeight": {
    "dimensions": [
      "300 mm (w)",
      "300 mm (h)",
      "12.4 mm (d)" ],
    "weight": "1250.0 grams" },
  "storage": {
    "hdd": "750GB",
    "ram": "8GB" }
}

    アプリケーションに100,000件のレコードがあり、主キーのサイズが約20バイトであると想定します。また、セカンダリ索引を使用してレコードを読取りする問合せが存在すると想定します。たとえば、画面サイズが13インチのすべてのレコードを検索する場合です。そのために、screenSizeフィールドに索引が作成されています。

    この情報を要約すると、次のようになります:

    表 表当たりの行数 表当たりの列数 キー・サイズ(バイト) 値サイズ(バイト) (すべての列の合計 指数 索引キー・サイズ(バイト)

    1

    100000

    2

    20

    1 KB

    1

    20

  2. 表に対する操作(通常はCRUD操作と索引読取り)および予測される(秒当たりの)レートのリストを確認します。

    操作 (秒当たりの)操作数 例

    レコードの作成

    3

    製品を作成する場合。

    主キーを使用したレコードの読取り。

    200

    製品IDを使用して製品の詳細を読み取る場合。

    セカンダリ索引を使用したレコードの読取り。

    1

    画面サイズが13インチのすべての製品をフェッチする場合。

    レコードに対する属性の更新または追加。

    5

    カメラの製品説明を更新する場合

    または

    カメラの重量に関する情報を追加する場合。

    レコードを削除

    5

    既存の製品を削除する場合。

  3. 読取りおよび書込み消費量(KB)を確認します。

    操作 想定(ある場合) 式 読取り消費量(KB) 書込み消費量(KB) ノート/説明
    レコードの作成 条件チェックを実行せずにレコードが作成されると想定します(存在する場合)。 Record size (rounded to next KB) + 1 KB(index) * (number of indexes) 0 1KB + 1KB (1) = 2KB

    レコード・サイズは1KB (JSON列の場合は0.8KB、キー列の場合は20バイト)で、サイズが1KBのインデックスが1つあります。

    いくつかのオプションを指定してputコマンドを実行すると、作成操作で読取りユニット・コストが発生します。最新バージョンの行を読み取ることを保証する必要があるため、絶対一貫性読取りが使用されます。このような場合は、読取りユニット式で乗数2を使用します。読取りユニット原価を決定する様々なオプションは、次のとおりです。
    • Option.IfAbsentまたはOption.IfPresentが使用されている場合、読取り消費量= 2
    • setReturnRowを使用する場合、読取り消費量= 2 *レコード・サイズ
    • Option.IfAbsentおよびsetReturnRowが使用されている場合、読取り消費量= 2 *レコード・サイズ
    主キーを使用したレコードの読取り。   Record size round up to KB レコード・サイズ= 1KB 0 レコード・サイズは1KB
    セカンダリ索引を使用したレコードの読取り。 100件のレコードが返されます。 record_size * number_of_records_matched

    11KB *100 = 100KB

    100KB + 10KB = 110KB

    		 0

    セカンダリ・インデックスの料金はかかりません。レコード・サイズは1KBです。100レコードの場合、100KBです。

    追加の10KBは、返されるバッチの数や問合せに設定されているサイズ制限に応じて発生する可能性がある可変オーバーヘッドです。

    オーバーヘッドは、バッチの最後のキーの読取りコストです。これは、maxReadKBおよびレコード・サイズに依存する変数です。オーバーヘッドは、(numBatches - 1) *キー読取りコスト(1KB)までです。
    既存のレコードの更新 更新されたレコードのサイズが古いレコードのサイズ(1KB)と同じであると想定します。 Read consumption = record_size * 2

    Write consumption = original_record_size + new_record_size + 1 KB (index) * (number of writes)

    		 1 KB * 2 1KB + 1KB + 1KB(1) *(2) = 4KB

    問合せ(SQL文)を使用して行を更新すると、読取りユニットと書込みユニットの両方が消費されます。更新によっては、主キー、セカンダリ・キーまたはレコード自体を読み取る必要がある場合があります。最新のレコードを読み取ることを保証するには、絶対的な一貫性読取りが必要です。絶対一貫性読取りは、最終一貫性読取りの2倍のコストがかかります。これが、フォーミュラで2を乗算した理由です。

    読取り消費量:索引およびレコード・サイズは1KBです。オプションsetReturnRowを使用して実行する場合、読取り消費量= 2 *レコード・サイズ

    書込み消費:元のレコード・サイズと新しいレコード・サイズは、1つの索引に対して1KBおよび1KBです。

    レコードを削除   Read consumption = 1 KB (index) * 2

    Write consumption = record_size + 1KB (index) * (number_of_indexes)

    		 1KB (1) *2 = 2KB 1KB + 1KB(1) * (1) = 2KB

    削除では、読取りと書込みの両方の単価が発生します。最新バージョンの行を確認する必要があるため、絶対的な一貫性読取りが使用されます。これは、読取りユニット式で2乗数を使用する理由です。

    オプションsetReturnRowを使用して実行する場合、読取り消費量= 2 *レコード・サイズ。それ以外の場合、1つの索引の読取り消費量= 1KB

    書込み消費:レコード・サイズは1KBで、索引は1KBです。索引の数は1です。

    ステップ2および3を使用して、アプリケーション・ワークロードの読取りユニットと書込みユニットを決定します。

    操作 操作のレート 読取り/秒 書込み/秒

    レコードの作成

    3

    0

    6

    主キーを使用したレコードの読取り

    300

    300

    0

    セカンダリ索引を使用したレコードの読取り

    10

    1100

    0

    既存のレコードの更新

    5

    10

    20

    レコードを削除

    1

    2

    2

    合計読取りユニット: 1412

    合計書込みユニット: 28

    したがって、E-Commerceアプリケーションのワークロードは、1秒当たり1412件の読取り、および1秒当たり28件の書込みであると見積されます。容量見積りツールをダウンロードして、これらの値を入力し、アプリケーションのスループットとストレージを見見積もります。

ノート:

前述の計算では、最終的に一貫性のある読取りリクエストを想定しています。絶対的な一貫性読取りリクエストの場合、操作で消費される容量ユニットは2倍になります。したがって、読取り容量ユニットは4844読取りユニットになります。

月次コストの見積り

Oracle Cloudサブスクリプションの月次費用を推定する方法について学習します。

Oracle Cloudサービスをオーダーする準備ができたら、サブスクリプション・モデルまたは金額にコミットする前に月次使用量とコストを把握するためのコスト見積り機能がOracleから提供されます。

この費用の見積りは、入力した読取りユニット、書込みユニットおよびストレージに基づいて、月次コストを自動的に計算します。ただし、アプリケーションの読み取り単位と書き込み単位をどのように計算するかを理解するために、次の手順に従ってください。

  1. ステップ1: 容量の見積りのトピックに移動します。このトピックに記載されている例および式を使用して、アプリケーション・ワークロードを見積ります。

    ステップ2: Oracle Technology Networkから容量見積り機能をダウンロードして使用し、アプリケーション・ワークロードおよびデータベース操作の条件に基づいて、アプリケーションの書込みユニット、読取りユニットおよびストレージ容量を見積ります。

  2. ステップ2: Oracle Cloud Webサイトでコスト見積り機能にアクセスします。[データ管理]チェック ボックスをオンにします。スクロールしてOracle NoSQL Database Cloudを探し、「追加」をクリックして「構成オプション」の下にOracle NoSQL Database Cloudのエントリを追加します。NoSQLデータベースを展開して、様々な使用率および構成のオプションを見つけます。「使用率」および「構成」パラメータの値を入力して、Oracle Cloudの「Pay-As-You-Go」および「月次フレックス」のサブスクリプションからOracle NoSQL Database Cloud Serviceの使用量に対する費用を見積ります。

  3. ステップ3: Oracle Cloud Webサイトで、コスト見積り機能にアクセスします。ドロップダウンで、「データ管理」を選択します。「データ管理」の下に様々なオプションが表示されます。スクロールしてOracle NoSQL Database Cloudを見つけます。「追加」をクリックして、「構成オプション」の下にOracle NoSQL Database Cloudのエントリを追加します。

  4. ステップ4: データベース- NoSQLを展開して、様々な使用状況および構成オプションを検索します。「構成」には2つのオプションがあります。「Always Free」オプション(フェニックス・リージョンでのみ使用可能)から開始するか、目的の構成でインスタンスをプロビジョニングできます。
    • ステップ4a: Always Freeオプションが必要な場合は、「構成」で「Oracle NoSQL Database Cloud - Read」、「Oracle NoSQL Database Cloud Service - Storage」および「Oracle NoSQL Database Cloud Service - Write and change the Read、 Storage and Write capacity as 0」を展開します。次に、合計コスト見積りが0と表示され、「Always Free」オプションに進むことができます。
  5. ステップ5: または、Always Freeで使用可能な容量より高い読取り、書込みおよびストレージ容量をプロビジョニングする場合は、「Database-NoSQL」に構成値を入力してプロビジョニングできます。
    • ステップ5a: Oracle NoSQL Database Cloud Serviceではこれらの値は使用されないため、「使用率」でデフォルト値を変更しないでください。
    • ステップ5 b: 「構成」で、前のステップで推定した読取りユニット、書込みユニットおよびストレージ容量の数を追加します。費用は、入力パラメータに基づいて見積もられ、ページに表示されます。

ノート:

自動スケール機能を使用している場合、読取りおよび書込みユニットの実際の消費について、請求書が月末にリアルタイムで生成されます。そのため、アプリケーションで独自の監査ログを収集して、月末の請求を確認することもできます。APIコールごとに、NoSQL Database Cloudサービスによって返される消費された読取りおよび書込みユニットを記録することをお薦めします。このデータを使用して、Oracle Cloudの測定および請求システムからの月末の請求データに関連付けることができます。

使用可能な様々な価格モデルの詳細は、NoSQL Database Cloud Serviceの価格を参照してください。

グローバル・アクティブ表の原価/請求

グローバル・アクティブ表の原価/請求には2つのコンポーネントがあります。最初のコンポーネントは、シングルトン表に続く価格設定モデルで、1か月当たりの読取りユニット、1か月当たりの書込みユニットおよび1か月当たりのギガバイト(GB)ストレージ容量が考慮されます。2つ目のコンポーネントは、グローバル・アクティブ表の各リージョナル表レプリカに対してレプリケートされた書込み用です。受信レプリケートされた書込みは、消費された書込みに基づいて課金されます。