ストアをデプロイするには、ユーザーはレプリケーション係数、必要な数のパーティションおよびストアをデプロイするストレージ・ノードを指定する必要があります。次の項では、アプリケーションの要件に基づいてこれらの値を計算する方法、およびストアをホストするために使用できるハードウェアの特性について説明します。
リソース見積は2段階のプロセスです。
アプリケーションの特性を考慮して、代表的なシャードのストレージおよびI/Oスループットの容量、各マシンのディスク構成およびディスク・スループットを決定します。各マシンで必要な物理メモリーの量、およびネットワーク・スループット容量も、この手順の一部として見積もります。
ストア全体のアプリケーション要件を考慮して、あるシャードから必要な数のシャードおよびマシンまでのスループットを推定する基準として、シャード・レベルのストレージおよびI/Oスループット容量を使用します。
計画プロセスで使用する必要があるスプレッドシートが用意されています。このスプレッドシートは、Oracle NoSQL Databaseディストリビューションの<KVHOME>/doc/misc/InitialCapacityPlanning.xlsにあります。
この付録の項は、スプレッドシートの名前付きの項に対応しています。スプレッドシートの列Aには、列Bの値に関連付けられたセル名がリストされます。赤のセル名は、入力として指定する必要がある値を表します。列Cは、列Bの値に関連付けられた値または計算を表します。「アプリケーションの特性」、「ハードウェアの特性」および「マシンの物理メモリー」の各項には、必要な入力が記載されています。緑のセル名はオプション入力を示します。スプレッドシートに指定されているデフォルト値は、ほとんどの見積に適しています。その他のセルはすべて、次に説明する式を使用してスプレッドシートで計算されます。
必要な入力を行った後、セルStoreMachinesの値により、ストレージ・ノード・プールで使用できるストレージ・ノードの数がわかります。StorePartitions値は、ストアの作成時に指定する必要があるパーティションの数を示します。
次の計算により生成されるのは見積であることに注意してください。見積の基準として使用される基になるモデルで行われるのは簡単な推測です。これは、幅広いアプリケーション要件で機能する、基になる単純なモデルを考えるのは困難なためです。したがって、このような見積は、開始点の基準としてのみ使用し、シミュレーションまたは実際の負荷に基づいて調整します。
シャードの容量を決定するには、まずこの項で説明するアプリケーションおよびハードウェアの特性を確認します。このような特性を確認した後、添付のスプレッドシートに入力します。スプレッドシートでは、指定されたアプリケーションおよびハードウェアの特性に基づいてシャードの容量が計算されます。
通常、レプリケーション係数3はほとんどのアプリケーションに適しており、適切な開始点です。パフォーマンス・テストによって特定の作業負荷に対する最適な数が判明している場合、数を調整できます。レプリケーション係数として2を選択した場合、障害が1つでも発生すると、サイトが少なすぎて新しいマスターを選択できなくなるため、2は選択しないでください。Oracle NoSQL Databaseにはデータのコピーが1つしかないため、通常は、レプリケーション係数1は使用しないでください。データをホストするストレージ・デバイスが失敗した場合、データが失われます。
レプリケーション係数を大きくすると、2つの利点があります。
ディスクやマシンの障害に耐えられるように永続性が向上します。
ただし、永続性と読取りスループットの向上には、それに関連するコストが発生します。各シャードには更新をレプリケートする必要があるノードが増えるため、データの追加のコピーをホストおよびサービスするハードウェア・リソースがそれだけ増え、書込みパフォーマンスが低下します。
レプリケーション係数は、セルRFによって定義されます。
平均的なキー長は、アプリケーションのキー・スキーマと様々なキーの相対分布を調べればわかります。ディスク上のキーの長さは、キーのコンポーネントを表すために必要なUTF-8バイト数にコンポーネント数を加えて1を引いたものです。
この値は、セルAvgKeySizeによって定義されます。
平均的なシリアル値サイズを調べるには、アプリケーションを調べればわかります。値サイズは、アプリケーションで使用される特定のシリアル化形式によって異なります。
この値は、セルAvgValueSizeによって定義されます。
アプリケーションで使用されるKVS API操作に基づいて、ストア・レベルの読取りおよび書込み操作の相対的な頻度を概算します。
最も基本的なレベルでは、各KVS get()コールはストア・レベルの読取り操作になり、各put()操作はストア・レベルの書込み操作になります。各KVSの複数キー操作(KVStore.execute()、multiGet()またはmultiDelete())は、複数のストア・レベルの読取り/書込み操作になる可能性があります。それで、アプリケーションにおいてこのような操作でアクセスされるキーの数を考慮に入れて、見積を作成します。
見積は読取りの割合として表します。つまり、ストア上の操作合計に対する読取り操作の割合です。残りの操作は、書込み操作であるとみなされます。
この値は、セルReadOpsPercentによって定義されます。
ファイル・システム・キャッシュからで満たされる可能性がある読取り操作の割合を見積もります。この割合は、主にアプリケーションのデータ・アクセス・パターンおよびファイル・システム・キャッシュのサイズによって異なります。「サイズ設定に関する注意事項」には、このキャッシュの使用方法に関する説明が記載されています。
この値は、セルReadCacheHitPercentによって定義されます。
ストアのホストに使用されるマシンのタイプの概略に基づいて、次のハードウェア特性を決定します。
KVペアの格納に使用されるマシン当たりのディスク数。この値は、セルDisksPerMachineによって定義されます。「ストレージ・ノード・パラメータ」で説明されているように、通常、このマシン当たりのディスク数によりストレージ・ノードの容量が決定されます。
各ディスクの使用可能なストレージ容量。この値は、セルDiskCapacityGBによって定義されます。
各ディスクのIOP容量。この情報は通常、ディスクが提供できる継続的なランダムIO操作/秒の数として、ディスクの仕様書に記載されています。この値は、セルDiskIopsPerSecによって定義されます。
次の説明は、システムがディスク当たり1つのRNで構成されることを前提としています。
この説明に関連する容量には、1)ストレージ容量、2)スループット容量の2つのタイプがあります。次の項では、この2つの容量の基準を計算する方法について説明します。以前に示したアプリケーションとハードウェアの特性に基づいて、基になる計算は付属のスプレッドシートによって自動的に実行されます。
ストレージ容量は、1つのシャードに格納できるKVペアの最大数です。(安全マージンおよびクリーナ使用率として取り分けられるストレージを考慮した後の)生のKVペアに実際に使用できるストレージを、各KVペアで必要なストレージ(Btreeオーバーヘッドの概算を含む)で割ることで計算されます。
KVストレージの容量は、セルMaxKVPairsPerShardによって計算されます。
スループット容量は、1つのシャードでサポートできる読取りおよび書込み操作の基準です。次の計算では、論理的なスループット容量を、キャッシュ・ヒット数を考慮した後に実際にディスクIOPに変換される論理操作の割合に基づいて、ディスクIOPの容量から導出します。「マシンの物理メモリー」の項には、Oracle NoSQL Databaseで使用されるキャッシュの構成に関する詳細情報が含まれています。
論理的な読取り操作の場合、シャード全体のIOPは次のように計算されます。
(ReadOpsPercent * (1 - ReadCacheHitPercent))
すべての割合が分数で表されることに注意してください。
論理的な書込み操作の場合、シャード全体のIOPは次のように計算されます。
(((1 - ReadOpsPercent) / WriteOpsBatchSize) * RF)
書込み操作の計算は非常に大まかなものです。ログ構造化ストレージ・システムで使用される連続書込みにより、読取り操作よりも書込み操作の方がIOP負荷に対する関与は少なくなります。WriteOpsBatchSizeを使用するのは、基になるJEログ構造化ストレージ・システムへの書込みの連続性を考慮することを目的としています。ワークロードに読取りがない、つまり純粋な挿入または更新負荷の場合、前述の算式は機能しません。純粋な挿入では、書込みは主に式でモデル化されていない確認レイテンシによって制限されます。純粋な更新負荷では、確認レイテンシとクリーナのパフォーマンスの両方が重要な役割を果たします。
前述の2つの数の合計は、実際にディスク操作になる論理操作の割合(DiskIopsPercentセル)を表します。その後、シャードの論理スループットを次のように計算できます。
(DiskIopsPerSec * RF)/DiskIopsPercent
セルOpsPerShardPerSecによって計算されます。
シャードのストレージおよびスループットの容量を設定した後、各マシンで必要な物理メモリーおよびネットワークの量を決定できます。ストアが適切に動作するためには、物理メモリーおよびネットワーク・リソースを正しく構成する必要があります。ストアの合計サイズを決定することが主な目的の場合は、「シャードおよびマシンの総数の見積」に進みます。ただし、後でマシン・レベルのハードウェア要件を最終決定する段階になったら、必ずこの項に戻ってください。
makebootconfigユーティリティのmemory_mbパラメータまたはmemorymbストレージ・ノード・パラメータを使用して、ストア内のストレージ・ノードごとに使用可能なメモリー・サイズを設定することもできます。詳細は、それぞれ「インストールの構成」および「ストレージ・ノード・パラメータ」を参照してください。
シャードのストレージ容量(セルMaxKVPairsPerShardによって計算)および平均キー・サイズ(セルAvgKeySizeによって定義)を使用すると、マシンの物理メモリー要件を見積もることができます。マシンの物理メモリーには、Oracle NoSQL Databaseで使用されるキャッシュがバックアップされます。
ストアのパフォーマンス目標を満たすためには、メモリー内キャッシュのサイズを適切に設定する必要があります。ディスクI/Oは、パフォーマンスの観点ではメモリーの消費が多い動作です。キャッシュからサービスされる動作が多いほど、ストアのパフォーマンスが向上します。
続行する前に、この説明に関連する2つのキャッシュがある点に注目してください。
JEキャッシュ。Oracle NoSQL Databaseで使用されるベースとなるストレージ・エンジンはBerkeley DB Java Edition (JE)です。JEには、メモリー内キャッシュが備わっています。ほとんどの場合、これは制御および構成が最も簡単なキャッシュであるため、最も重要なキャッシュ・サイズです。
ファイルシステム(FS)キャッシュ。最新のオペレーティング・システムでは、ディスクI/O専用のキャッシュやバッファを用意してI/Oサブシステムのパフォーマンスが向上するようになっています。FSキャッシュを使用すると、キャッシュに格納されているデータによって読取りが完結する場合、読取り操作を非常に高速に行うことができます。
JEでは、格納するデータの編成にBツリーが使用されます。Bツリーでは、木のようなデータ編成構造で高速な情報検索を実現します。木構造は、内部ノード(IN)とリーフ・ノード(LN)で構成されます。INは、データのナビゲーションに使用されます。LNは、Bツリーでデータが実際に格納される場所です。
Oracle NoSQL Databaseアプリケーションで使用される予定のデータ・セットが非常に大きいため、データの一部でさえJEのメモリー内キャッシュに格納することはあまりありません。したがって、最もよい方法は、データベースのINの大半(すべてではなくても)を保持するのに十分な大きさにキャッシュのサイズを設定し、ノードの残りのメモリーがシステム・オーバーヘッド(ごくわずか)とFSキャッシュに使用されるようにします。
INとLNの両方ともFSキャッシュを使用できます。FSキャッシュにある場合、INとLNにはJavaオブジェクト・オーバーヘッドがない(JEキャッシュの場合はある)ため、JEキャッシュ・メモリーよりもFSキャッシュ・メモリーの方が効率的に使用できます。
当然、このFSキャッシュが十分に機能するには、データ・アクセス・パターンが完全にランダムではないようにします。有用なキャッシュ・ヒット率を達成するには、一部のキーと値のペアが他のペアよりも優先される必要があります。アクセス・パターンがランダムでなないアプリケーションの場合、LNとINのファイルシステム・キャッシュ・ヒット率が高いと、スループットが向上し、平均読取りレイテンシが低下します。また、適切にチューニングされている場合、ファイルシステム・キャッシュが大きいほど、ログ・ファイルへの順次書込みの際のストールの数が減り、書込みレイテンシが低下します。キャッシュが大きい場合、ほとんどの書込みを非同期に行うこともでき、スループットが向上します。
JEキャッシュの適切なサイズを決定するには、com.sleepycat.je.util.DbCacheSizeユーティリティを使用します。このユーティリティでは、レコードの数とアプリケーション・キーのサイズを入力として必要とします。必要に応じて、予想されるデータのサイズなどの他の情報を指定することもできます。ユーティリティによって、短い表形式の情報が表示されます。必要な数値は、Minimum, internal nodes only行のCache Size列に示されます。
たとえば、平均キー・サイズが12バイトで平均値サイズが1000バイトの1億個のレコードを含む環境のJEキャッシュ・サイズを決定する場合、次のようにDbCacheSizeを起動します。
java -Xmx256m -Xms256m \
-d64 -XX:+UseCompressedOops -jar je.jar DbCacheSize \
-key 12 -data 1000 -records 100000000
=== Environment Cache Overhead ===
3,156,253 minimum bytes
To account for JE daemon operation and record locks,
a significantly larger amount is needed in practice.
=== Database Cache Size ===
Minimum Bytes Maximum Bytes Description
--------------- --------------- -----------
2,888,145,968 3,469,963,312 Internal nodes only
107,499,427,952 108,081,245,296 Internal nodes and leaf nodes
=== Internal Node Usage by Btree Level ===
Minimum Bytes Maximum Bytes Nodes Level
--------------- --------------- ---------- -----
2,849,439,456 3,424,720,608 1,123,596 1
38,275,968 44,739,456 12,624 2
427,512 499,704 141 3
3,032 3,544 1 4
次のjvm引数を書き留めてください(DbCacheSizeに対して指定した場合、特別な意味があります)。
これらの引数をDatabase Cache Sizeに対して指定すると、JEアプリケーションにもこれらの引数が渡されることを意味し、Database Cache Sizeによって計算が適切に調整されます。これらのキャッシュを使用するレプリケーション・ノードを起動するときに、Oracle NoSQL Databaseでこれらの引数が使用されます。
必要な数は、出力の「Internal nodes only」行の「Minimum Bytes」列にあるDatabase Cache Sizeセクションに記載されています。この出力は、JEキャッシュ内のBtreeを表すすべてのINノードを保持するには2.9 GBのキャッシュ・サイズで十分であることを示しています。このサイズのJEキャッシュでは、INノードはJEキャッシュから取得され、LNはFSキャッシュまたはディスクから取得されます。
DbCacheSizeユーティリティの使用方法の詳細は、Javadocページhttp://docs.oracle.com/cd/E17277_02/html/java/com/sleepycat/je/util/DbCacheSize.htmlを参照してください。このユーティリティを使用するためには、<KVHOME>/lib/je.jarファイルをJavaクラスパスに追加する必要があることに注意してください。<KVHOME>は、Oracle NoSQL Databaseパッケージ・ファイルを配置したディレクトリを表します。
DbCacheSizeを使用してJEキャッシュ・サイズを取得した後、その値からヒープ・サイズを計算できます。これを行うには、DbCacheSizeから取得した数値をDbCacheSizeMBという名前のセルに入力します。必ず、単位をバイトからMBに変換してください。ヒープ・サイズは、次のようにセルRNHeapMBによって計算されます。
(DBCacheSizeMB/RNCachePercent)
ここで、RNCachePercentはJEキャッシュに使用されるヒープの割合です。java VMが効率的なCompressedOops形式を使用してメモリー内のjavaオブジェクトを表せるように、計算されるヒープ・サイズが32GBを超えないようにしてください。32GBを超える値のヒープ・サイズは、この要件を強調するためにRNHeapMBセルでは取消線付きで表示されます。ヒープ・サイズが32GBを超える場合は、キーのサイズを小さくしてJEキャッシュのサイズを小さくし、ヒープ・サイズ全体が32GBを下回るようにしてください。
ヒープ・サイズは、次のようにマシンで必要なメモリーを計算するための基準として使用されます。
(RNHeapMB * DisksPerMachine)/SNRNHeapPercent
ここで、SNRNHeapPercentは、マシンでホストされるRNに使用できる物理メモリーの割合です。結果は、セルMachinePhysicalMemoryMBで使用できます。
マシンに付属するNICが、「シャードのI/Oスループット容量」で以前に計算したアプリケーションI/Oスループットを提供できることを確認する必要があります。これは、提供できない場合にボトルネックになる可能性があるためです。
クライアントで開始された書込み操作の結果としてネットワーク経由でマシンが受信するバイト数は、次のように計算されます。
(OpsPerShardPerSec * (1 - ReadOpsPercent) * (AvgKeySize + AvgValueSize)) * DisksPerMachine
スプレッドシートではReceiveBytesPerSecで示されます。計算の際には、ノードがマスターかレプリカかは問題ではないことに注意してください。受信書込みバイトは、マスターのクライアントおよびマシンのレプリカのマスターから発生します。
読取りリクエストの結果としてマシンが受信するバイト数は、次のように計算されます。
((OpsPerShardPerSec * ReadOpsPercent)/RF) * (AvgKeySize + ReadRequestOverheadBytes) * DisksPerMachine
ここで、ReadRequestOverheadBytesは100バイトの固定定数オーバーヘッドです。
読取り操作の結果としてネットワーク経由でマシンが送信するバイト数には、基になる2つのコンポーネントがあります。
アプリケーションの読取りリクエストに対する直接応答で送信されるバイト数は、次のように表されます。
((OpsPerShardPerSec * ReadOpsPercent)/RF) * (AvgKeySize + AvgValueSize) * DisksPerMachine
マシンのマスターによってレプリケーション・トラフィックとして送信されるバイト数は、次のように表されます。
(OpsPerShardPerSec * (1 - ReadOpsPercent) * (AvgKeySize + AvgValueSize) * (RF-1)) * MastersOnMachine
前述の2つの値の合計は、スプレッドシートのSendBytesPerSecで表される送信トラフィックの合計を表します。
受信トラフィックと送信トラフィックの合計が、NICの容量内に適切に収まる必要があります。スプレッドシートでは、トラフィックのサポートに必要なネットワーク・カードの種類(GigEまたは10GigE)が計算されます。