計算に関する基本事項

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

• 書込みユニット(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)のデータ・ストレージです。

• 絶対的な一貫性: 返されるデータは、データベースに最後に書き込まれたデータである必要があります。

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

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

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

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

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

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

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

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

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

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

1. アプリケーションのデータ・モデル(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	1KB	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	1 KB + 1 KB (1 ) = 2 KB	レコード・サイズは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)	1KB * 2	1Kb + 1Kb + 1KB(1) *(2) = 4Kb	問合せ(SQL文)を使用して行を更新すると、読取りユニットと書込みユニットの両方が消費されます。更新によっては、主キー、セカンダリ・キー、またはレコード自体を読み取る必要がある場合があります。最新レコードを読み取ることを保証するには、絶対整合性読取りが必要です。絶対的なコンシステンシ読取りは、最終的なコンシステンシ読取りの2倍のコストです。これは、フォーミュラで2を乗算する理由です。 読取り消費:索引およびレコード・サイズは1KBです。オプションsetReturnRowを使用して実行する場合、読取り消費= 2 *レコード・サイズ 消費量の書込み:元のレコード・サイズと新しいレコード・サイズは、1つの索引で1KBです。
   レコードの削除		Read consumption = 1 KB (index) * 2 Write consumption = record_size + 1KB (index) * (number_of_indexes)	1Kバイト(1) *2 = 2Kバイト	1Kバイト+ 1Kバイト(1) * (1) = 2Kバイト	削除によって、読取りユニットと書込みユニットの両方のコストが発生します。行の最新バージョンを確認する必要があるため、絶対的な一貫性読取りが使用されます。これは、読取りユニット式で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件の書込みであると見積られます。Oracle Technology Networkで入手できる容量見積り機能ツールをダウンロードして、これらの値を入力し、アプリケーションのスループットとストレージを見積ります。