ストアのストレージとパフォーマンス要件について理解できたら、ストアの構成方法を決定できます。これを行うには、次の決定を行う必要があります。
使用するシャードの数。
使用するレプリケーション・パーティションの数。
レプリケーション係数。
最後に、ストアで使用するノードの数。
次の各項で、これらの点について詳しく説明します。
KVStoreには、1つ以上のシャードが含まれます。各シャードには、書込みリクエストをサービスする1つのノードと読取りリクエストをサービスする1つ以上のノードが含まれます。
ストアに含まれるシャードが多いほど、ストアでの書込みリクエストのサービスのパフォーマンスはよくなります。したがって、Oracle NoSQL Databaseアプリケーションでデータの書込み(レコードの作成、更新および削除)のスループット要件が高い場合、多くのシャードを使用してストアを構成します。
シャードには、1つ以上のパーティション(次の項で説明)が含まれ、キーと値のペアがこれらのパーティション間に均等に分散されます。つまり、ストアに含まれるシャードが多いほど、ストアの各ノードで必要なディスク領域は小さくなります。
たとえば、ストアに約n個のリクエストが含まれ、各レコードは合計mバイトのデータだとすると、ストアでn * mバイトのデータが管理されます。シャードが3つある場合、各ストレージ・ノードに(n * m) / 3バイトのデータを格納するのに十分なディスク領域がある必要があります。
必要なシャードの数の大まかな当初見積りを出すには、次の式を使用すると簡単に行えます。
RG = (((((avg key size * 2) + avg value size) * max kv pairs) * 2) + (avg key size * max kv pairs) / 100 ) / (node storage capacity)
式の1行目の最後の係数の2は、クリーナ使用率と呼ばれるKVStoreチューニング制御に基づきます。ここでは、クリーナ使用率は50%と仮定します。
たとえば、最高10億個のキーと値のペアを格納できるサイズのストアで2つのシャードが必要で、平均キー・サイズは10バイト、平均の値サイズは1K、各ノードで使用可能なストレージは1TB (10^12)だとします。
((((10*2)+1000) * (10^9)) * 2) + ((10 * (10^9))/100) / 10^12 = 2 RGs
この式は、大まかな見積りを出すのみだということに注意してください。より正確な見積りを出すには、IOのスループットやキャッシュ・サイズなどの他の要因を考慮に入れる必要があります。ここで求めた数値は、本番前環境で入念にテストし、必要に応じて調整します。(これは、Oracle NoSQL Databaseのインストールを計画する際に求めるどの見積りにも当てはまります。)
ストア内の各シャードには、1つ以上のパーティションが含まれる必要がありますが、多数のパーティションが含まれるようにストアを構成します。KVStore内のレコードはKVStoreパーティションに均等に分散され、その結果、シャードにも均等に分散されます。ストアを最初に作成する際、ストアに含めるパーティションの総数を特定します。この数は固定で、ストアのライフタイムの間変更できません。
選択するパーティションの数が、ストアに含まれる予定のシャードの最大数より大きいことを確認します。シャードをストアに追加すると、シャード間でパーティションが移動され(これに伴って、データが移動され)、ストアが再均衡化されます。したがって、選択するパーティションの総数は、実質的には、ストアに含めることができるシャードの総数の永続的な制限です。
非常に多数のパーティションを構成すると、一定のオーバーヘッドが伴うことに注意してください。しかし、ストアの拡張に備えて十分な余裕を持たせたパーティション値を選択してもかまいません。ストアで使用する予定のシャードの最大数の100倍のパーティション数を選択することは不適切ではありません。
KVStoreには、1つ以上のシャードが含まれます。各シャードには、書込みリクエストをサービスする1つのノード(マスター)と読取りリクエストをサービスする1つ以上のノード(レプリカ)が含まれます。
ストアのレプリケーション係数は、単に各シャードに含まれるノードの数(マスター + レプリカ)を表します。レプリケーション係数が3の場合、シャードには1つのマスターと2つのレプリカが含まれます。(当然、マスターをホストしているノードにアクセスできなくなったり、このノードを停止した場合、シャード内の他のいずれかのノードにマスターがフェイルオーバーし、1つのマスターと1つのレプリカのシャードになります。しかし、これは、このシャードにとって異例で一時的な状態です。)
レプリケーション係数を大きくすると、各シャードで読取りリクエストのサービスに使用されるノードが増えるため、リクエストのサービスのパフォーマンスはよくなります。ただし、ストレージ・ノードの数が固定の場合、レプリケーション係数が大きくなるほど、ストアに含めることができるシャードの数は少なくなります。
レプリケーション係数を大きくすると、更新を転送する必要のある各シャード内のノードが増えるため、ストアの書込みパフォーマンスが低下することにもなります。
パフォーマンス・テストによって特定の作業負荷に対する最適な数が判明している場合を除き、通常は、レプリケーション係数として3をお薦めします。また、レプリケーション係数として2を選択すると、障害が1つでも発生すると、サイトが少なすぎて新規マスターを選択できなくなるため、2は選択しないでください。
ストアに必要なストレージ・ノードの総数は、必要なシャードの数にレプリケーション係数を掛けて見積ることができます。ハード・ディスクがスループット要件を満たすIOPsを達成できないことが判明している場合以外、この数値で十分です。その場合、レプリケーション係数を大きくするか、シャードの総数を増やす必要があります。
ストレージ・ノードの数の見積りが少なすぎた場合は、ストアで使用するストレージ・ノードの数を動的に増やすことができます。コマンドライン・インタフェースを使用してストアを拡張する場合は、「トポロジ候補の変換」を参照してください。
求めた見積りは、本番環境にデプロイする前に必ず入念に構成をテストしてください。