サービスの計画
作成する前に少し時間をかけてOracle NoSQL Database Cloud Serviceサービスを計画します。始める前に、ここで説明する質問について考え、実行することを決めてください。
この記事には次のトピックが含まれます:
開発者概要
サービス・アーキテクチャの概要を把握し、アプリケーション開発のニーズを満たすSDK/ドライバを選択します。
NDCS開発者タスク
Oracle NoSQL Database Cloud Service (NDCS)は完全なHAサービスです。これは、低レイテンシのレスポンス時間、柔軟なデータ・モデル、および動的ワークロードの柔軟なスケーリングを必要とする、非常に要求の厳しいアプリケーション向けに設計されています。フルマネージド・サービスとして、Oracleは、ソフトウェアのアップグレード、セキュリティ・パッチ、ハードウェア障害、パッチ適用など、すべての管理タスクを処理します。

NoSQL Database SDKs/ドライバ- これらのSDKは、Universal Permissive License (UPL)に基づいてライセンス供与されており、NoSQL Cloud Serviceまたはオンプレミス・データベースで使用できます。これらはフル機能のSDKであり、豊富な機能セットを提供します。これらのドライバは、他のベンダー・クラウドで実行されているOracle NoSQLクラスタに対して実行されるアプリケーションでも使用できます。
SDK、APIガイドおよび例へのリンクについては、次の表を参照してください。
-
SDK (GitHub) - SDKのインストール、接続および開始方法の詳細を提供します
-
APIガイド- SDKで使用可能なパッケージ、クラス、メソッドおよびインタフェースを提供します
-
例- 試用できるコード・サンプルを提供します。
OCIコンソール- 表の迅速な作成、表の変更、表の削除、データのロード、索引の迅速な作成、索引の削除、基本的な問合せ、表の容量の変更およびメトリックの表示機能を提供します。
OCI SDK/ドライバ- Oracle Cloud Infrastructureは、カスタム・ソリューションの開発を容易にするための多数のソフトウェア開発キット(SDK)を提供します。これらは通常、UPLでライセンスされます。
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書込みユニット。 | ホスト環境では許可/不要 |
| オンデマンド容量- 表の数 | 領域 | オンデマンド容量がある表の数。 | 3 | ホスト環境では許可/不要 |
| プロビジョニング・モードの変更 | 表 | 表のプロビジョニング・モードを「プロビジョニング済」から「オンデマンド」に変更するか、またはその逆に変更します。 | 1日に1回のみ変更できます。 | N/A |
| 表の最大数 | 領域 | 最大表数。 | 30 | これは、リクエスト・サービス制限の更新を使用してカスタマイズできます |
| 列の最大数。 | 表 | 最大列数。 | 50 | これは、リクエスト・サービス制限の更新を使用してカスタマイズできます |
| 表スキーマ更新の最大数 | 表 | 表スキーマ更新の最大数。 | 100 | これは、リクエスト・サービス制限の更新を使用してカスタマイズできます |
| 索引の最大数 | 表 | 最大索引数。 | 5 | これは、リクエスト・サービス制限の更新を使用してカスタマイズできます |
| スループットおよびストレージ制限の最大変更回数 | 表 | スループットおよびストレージ制限の最大変更回数。 | Oracleでは次のことが許可されます:
|
これは、リクエスト・サービス制限の更新を使用してカスタマイズできます |
| インデックス名 | 索引 | 最大文字数、使用可能な文字、および先頭の文字。 | 索引名には最大64文字を使用できます。すべての名前は文字(a-z、A-Z)、で始める必要があります。後続の文字には、文字(a-z、A/Z)、数字(0-9)またはアンダースコアを使用できます。 | これは、リクエスト・サービス制限の更新を使用してカスタマイズできます |
WriteMultipleリクエスト当たりの個別操作の最大数 |
リクエスト | WriteMultipleリクエスト当たりの個別操作の最大数。 |
50 | 非ホスト環境と同じです。これは、リクエスト・サービス制限の更新を使用して増やすこともできます。 |
WriteMultipleリクエストの最大データ・サイズ。 |
リクエスト | WriteMultipleリクエストの最大のデータ・サイズ。 |
25MB | 非ホスト環境と同じです。これは、リクエスト・サービス制限の更新を使用して増やすこともできます。 |
| 列名 | 列 | 最大文字数、使用可能な文字、および先頭の文字。 | フィールド名には最大64文字を使用できます。すべての名前は文字(a-z、A-Z)、で始める必要があります。後続の文字には、文字(a-z、a-Z)、数字(0-9)またはアンダースコアを使用できます。 | 非ホスト環境と同じです。 |
| 最大2次索引キー・サイズ | 索引 | 索引キーの最大サイズ。 | 64バイト | これは、リクエスト・サービス制限の更新を使用してカスタマイズできます |
| 最大主キー・サイズ | 索引 | 主キーの最大サイズ。 | 64バイト | これは、リクエスト・サービス制限の更新を使用してカスタマイズできます |
| 最大行サイズ | 行 | 行の最大サイズ。 | 512 KB | これは、リクエスト・サービス制限の更新を使用してカスタマイズできます |
| 問合せ文字列の最大長。 | 問合せ | 問合せ文字列の最大長。 | 10 KB | これは、リクエスト・サービス制限の更新を使用してカスタマイズできます |
| サポートされているDDL操作の最大レート。 | 領域 | サポートされているDDL操作の最大レート。 | 4 分単位 | これは、リクエスト・サービス制限の更新を使用してカスタマイズできます |
| スループットおよびデータ・ストレージ・リソースの最大値。 | 領域 | スループットおよびデータ・ストレージ・リソースの最大値。 | Oracleでは、リージョンごとに次のことを実行できます。
Oracleでは、1つのテナントにつき最大ストレージ・サイズとして5TBが許可されます。リージョンにストレージ・サイズが5TBの単一の表を組み込むことは可能ですが、その場合、そのリージョンは別の表を作成できません。複数の表を含める場合、それらのすべての表のデータが最大ストレージ・サイズの5TB以内になるようにします。 |
420,000書込みユニット、280,000読取りユニット、17.5TBストレージ |
容量の見積り
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秒当たり最大1KBのデータのスループットとして定義されます。NoSQL表には、1秒間に使用できる読取りユニット数を指定する読取り制限値があります。
たとえば、レコード・サイズが1KB未満の場合は、最終的に一貫性のある読取り操作のために1RUが必要です。レコード・サイズが1.5KBの場合、最終的に一貫性のある読取り操作のために2RU、絶対的に一貫性のある読取り操作のために4RUが必要です。
-
ストレージ容量: 1ストレージ・ユニットは、1ギガバイト(GB)のデータ・ストレージです。
-
絶対的な一貫性:返されるデータは、データベースに最後に書き込まれたデータである必要があります。
-
最終的な一貫性:返されるデータは、データベースに最近書き込まれたデータでない場合があります。データに対する新しい更新がなければ、最終的にそのデータへのすべてのアクセスで、更新された値が返されます。
ノート: Oracle NoSQL Database Cloud Serviceでは、オンデマンド容量を使用する場合、動的ワークロードのニーズを満たすように、読取りおよび書込み容量が自動的に管理されます。容量の必要量がOn Demand容量の制限を超えないことを検証することをお勧めします。詳細は、Oracle NoSQL Database Cloud Serviceの制限を参照してください。
容量ユニットに影響を与える要因
容量ユニットをプロビジョニングする前に、読取り、書込みおよびストレージ容量に影響を与える次の要因を考慮することが重要です。
-
レコード・サイズ:レコード・サイズの拡大に伴って、データの書込みまたは読取りで消費される容量ユニットも増加します。
-
データ一貫性:絶対的な一貫性読込みは、最終一貫性読込みの2倍のコストかかります。
-
第2索引:表で既存のレコードが変更(追加、更新または削除)されると、セカンダリ索引の更新で書込みユニットが消費します。書込み操作用にプロビジョニングされる合計スループット・コストは、表への書込みとローカル・セカンダリ索引の更新で消費される書込みユニットの合計です。
-
データ・モデリングの選択:スキーマレスJSONでは、各ドキュメントは自己記述型のため、全体的なレコード・サイズにメタデータのオーバーヘッドが追加されます。固定スキーマ表の場合、各レコードのオーバーヘッドは1バイトです。
-
問合せパターン:問合せ操作のコストは、取得される行数、述語の数、ソース・データのサイズ、予測、および索引の存在によって決まります。最もコストが低い問合せでは、システムがプライマリ索引とセカンダリ索引付けを利用できるように、シャード・キーまたは索引鍵を(関連する索引とともに)指定します。アプリケーションは、様々な問合せを試行して消費されるスループットを調べ、操作のチューニングに役立てることができます。
実例: アプリケーション・ワークロードを見積る方法
E-Commerceアプリケーションの例を参考にして、1秒当たりの読取りおよび書込みを見積る方法について学習します。この例では、Oracle NoSQL Database Cloud Serviceを使用して、アプリケーションの製品カタログ情報を格納します。
-
アプリケーションのデータ・モデル(JSONまたは固定表)、レコード・サイズおよびキー・サイズを確認します。
E-CommerceアプリケーションがJSONデータ・モデルに準拠し、開発者が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 -
表に対する操作(通常はCRUD操作と索引読取り)および予測される(秒当たりの)レートのリストを確認します。
操作 (秒当たりの)操作数 例 レコードを作成します。 3 製品を作成する場合。 主キーを使用したレコードの読取り。 200 製品IDを使用して製品の詳細を読み取る場合。 セカンダリ索引を使用したレコードの読取り。 1 画面サイズが13インチのすべての製品をフェッチする場合。 レコードに対する属性の更新または追加。 5 カメラの製品説明を更新する場合
または
カメラの重量に関する情報を追加する場合。
レコードを削除します。 5 既存の製品を削除する場合。 -
読取りおよび書込みの消費量(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レコード・サイズ= 1 KB 0 レコード・サイズは1KBです セカンダリ索引を使用したレコードの読取り。 100件のレコードが返されると想定します。 record_size * number_of_records_matched11KB×100 = 100KB
100KB + 10KB = 110KB
0 セカンダリ・インデックスには料金はかかりません。レコード・サイズは1KBです。100レコードの場合、100KBです。
10KBは、返されるバッチの数や、問合せに設定されているサイズ制限に応じて発生する可能性がある可変オーバーヘッドに対応しています。
オーバーヘッドは、バッチ内の最後のキーを読み取るコストです。これは、maxReadKBおよびレコード・サイズに依存する変数です。オーバーヘッドは、(numBatches - 1) *キー読取りコスト(1KB)までです。
既存のレコードの更新 更新されたレコードのサイズが古いレコードのサイズ(1KB)と同じであると想定します。 Read consumption = record_size * 2Write consumption = original_record_size + new_record_size + 1 KB (index) * (number of writes)1KB * 2 1KB + 1KB + 1KB(1) *(2) = 4KB 問合せ(SQL文)を使用して行を更新すると、読取りユニットと書込みユニットの両方が消費されます。更新によっては、主キー、セカンダリ・キー、またはレコード自体を読み取る必要がある場合があります。最新のレコードを読み取ることを保証するには、絶対一貫性読取りが必要です。絶対的な一貫性読込みは、最終的な一貫性読込みの2倍のコストかかります。これが、Formulaで2を乗算する理由です。
読取り消費:索引およびレコード・サイズは1KBです。オプションsetReturnRowを使用して実行する場合、読取り消費= 2 *レコード・サイズ
書込み消費:元のレコード・サイズと新しいレコード・サイズは、1つの索引に対して1KBおよび1KBです。
レコードの削除 Read consumption = 1 KB (index) * 2Write 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: 容量の見積りと見積りのトピックに移動します。このトピックに記載されている例および式を使用して、アプリケーション・ワークロードを見積ります。
Oracle Technology Networkから容量見積りをダウンロードして使用すると、アプリケーションの書込みユニット、読取りユニットおよびデータベース操作の条件に基づいて、アプリケーションの書込みユニット、読取りユニットおよびストレージ容量を見積ることができます。
-
ステップ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: Oracle Cloud Webサイトで、費用見積り機能にアクセスします。ドロップダウンで、「Data Management」を選択します。「データ管理」の下に様々なオプションが表示されます。スクロール・スルーしてOracle NoSQL Database Cloudを見つけます。「追加」をクリックして、「構成オプション」の下にOracle NoSQL Database Cloudのエントリを追加します。
-
ステップ4: Database - NoSQLを展開して、様々な利用および構成オプションを見つけます。「構成」には2つのオプションがあります。「Always Free」オプション(フェニックス・リージョンでのみ使用可能)から開始するか、目的の構成でインスタンスをプロビジョニングできます。
- ステップ4a: Always Freeオプションが必要な場合は、「構成」で「Oracle NoSQL Database Cloud - Read」、「Oracle NoSQL Database Cloud Service - Storage」および「Oracle NoSQL Database Cloud Service - Write」を展開し、読取り、ストレージおよび書込み容量を0に変更します。次に、合計コスト見積りが0として表示され、「Always Free」オプションに進むことができます。
-
ステップ5:または、Always Freeで使用可能なものより高い読取り、書込みおよびストレージ容量をプロビジョニングする場合は、Database-NoSQLで構成値を入力してプロビジョニングできます。
-
ステップ5a:「使用状況」で、Oracle NoSQL Database Cloud Serviceではこれらの値は使用されないため、デフォルト値を変更しないでください。
-
ステップ5b:「構成」で、前のステップで推定した読取りユニット数、書込みユニット数およびストレージ容量を追加します。コストは、入力値に基づいて見積られ、ページに表示されます。
-
ノート:自動スケール機能を使用している場合、読取りユニットおよび書込みユニットの実際の消費について、請求書が月末にリアルタイムで生成されます。そのため、アプリケーションで独自の監査ログを収集して、月末の請求を検証できます。APIコールごとに、NoSQL Database Cloudサービスによって返された消費された読取りおよび書込みユニットを記録することをお薦めします。このデータを使用して、Oracle Cloudの測定および請求システムからの月末の請求データと相互に関連付けることができます。
使用可能な様々な価格設定モデルの詳細は、NoSQL Database Cloud Serviceの価格設定を参照してください。
グローバル・アクティブ表の原価/請求
グローバル・アクティブ表の原価/請求には、2つのコンポーネントがあります。最初のコンポーネントは価格設定モデルで、1か月当たりの読取りユニット、1か月当たりの書込みユニットおよび1か月当たりのギガバイト(GB)ストレージ容量が考慮されます。 2番目のコンポーネントは、グローバル・アクティブ表のリージョナル表レプリカごとにレプリケートされた書込み用です。受信レプリケートされた書込みは、消費された書込みに基づいて課金されます。