OrientDB-パフォーマンスチューニング

この章では、OrientDBを使用するアプリケーションを最適化する方法に関する一般的なヒントを得ることができます。さまざまなタイプのデータベースのパフォーマンスを向上させる方法は3つあります。

ドキュメントデータベースパフォーマンスチューニング-新しいドキュメントごとにドキュメントが作成されるのを回避する手法を使用します。
オブジェクトデータベースのパフォーマンスチューニング-パフォーマンスを改善するために一般的な手法を使用します。
分散構成の調整-分散構成のパフォーマンスを改善するためにさまざまな方法論を使用します。

メモリ、JVM、およびリモート接続設定を変更することにより、一般的なパフォーマンスチューニングを実現できます。

メモリ設定

メモリ設定には、パフォーマンスを改善するためのさまざまな戦略があります。

サーバーと埋め込み設定

これらの設定は、 plocal を直接使用することにより、埋め込みモードでOrientDBを使用してJavaアプリケーションが実行されるサーバーコンポーネントとJVMの両方で有効です。

チューニングで最も重要なことは、メモリ設定が正しいことを確認することです。実際の違いを生むことができるのは、ヒープとメモリマッピングで使用される仮想メモリとの間の適切なバランスです。特に、メモリ内キャッシュ構造が生のIOより少ないとカウントされる大規模なデータセット（GB、TBなど）です。

たとえば、Javaプロセスに最大8GBを割り当てることができる場合、通常は小さなヒープと大きなディスクキャッシュバッファー（オフヒープメモリ）を割り当てる方が適切です。

ヒープメモリを増やすには、次のコマンドを試してください。

java -Xmx800m -Dstorage.diskCache.bufferSize=7200 ...

*storage.diskCache.bufferSize* 設定（古い「ローカル」ストレージでは *file.mmap.maxMemory* でした）はMB単位で、ディスクキャッシュコンポーネントに使用するメモリ量を示します。 デフォルトでは4GBです。

注-最大ヒープとディスクキャッシュバッファの合計が大きすぎる場合、OSが大幅にスローダウンしてスワップする可能性があります。

JVM設定

JVM設定は、server.sh（およびserver.bat）バッチファイルにエンコードされます。これらを変更して、使用状況とhw/sw設定に従ってJVMを調整できます。 server.batファイルに次の行を追加します。

-server -XX:+PerfDisableSharedMem

この設定は、JVMに関するデバッグ情報の書き込みを無効にします。 JVMのプロファイルを作成する必要がある場合は、この設定を削除してください。

リモート接続

リモート接続を使用してデータベースにアクセスするときのパフォーマンスを改善する方法は多数あります。

フェッチ戦略

リモートデータベースを使用する場合、使用するフェッチ戦略に注意する必要があります。デフォルトでは、OrientDBクライアントは結果セットに含まれるレコードのみをロードします。たとえば、クエリが100個の要素を返すが、これらの要素をクライアントから渡した場合、OrientDBクライアントは、失われたレコードごとにサーバーへのもう1つのネットワーク呼び出しで要素を遅延ロードします。

ネットワーク接続プール

デフォルトでは、各クライアントはサーバーと通信するために1つのネットワーク接続のみを使用します。同じクライアント上の複数のスレッドが同じネットワーク接続プールを共有します。

複数のスレッドがある場合、空きネットワーク接続の待機に多くの時間が費やされるため、ボトルネックが発生する可能性があります。これが、ネットワーク接続プールを構成することが重要である理由です。

構成は非常にシンプルで、2つのパラメーターだけです-

minPool -接続プールの初期サイズです。デフォルト値は、グローバルパラメータ「client.channel.minPool」として設定されています。
maxPool -接続プールが到達できる最大サイズです。デフォルト値は、グローバルパラメータ「client.channel.maxPool」として設定されています。

すべてのプール接続がビジーの場合、クライアントスレッドは最初の空き接続を待ちます。

データベースプロパティを使用した設定コマンドの例。

database = new ODatabaseDocumentTx("remote:localhost/demo");
database.setProperty("minPool", 2);
database.setProperty("maxPool", 5);

database.open("admin", "admin");

分散構成のチューニング

分散構成のパフォーマンスを向上させる方法は多数あります。

トランザクションを使用する

グラフを更新する場合でも、常にトランザクションで作業する必要があります。 OrientDBを使用すると、それらの外部で作業できます。一般的なケースは読み取り専用クエリであるか、障害が発生した場合に大規模で非並行の操作を復元できます。分散構成で実行する場合、トランザクションを使用すると、待ち時間を短縮できます。これは、分散操作がコミット時にのみ発生するためです。 1つの大きな操作の分散は、待ち時間があるため、小さな複数の操作を転送するよりもはるかに効率的です。

レプリケーションとシャーディング

OrientDBの分散構成は完全レプリケーションに設定されています。データベースの同じコピーを持つ複数のノードを持つことは、スケール読み取りにとって重要です。実際、各サーバーは読み取りとクエリの実行に依存しません。サーバーノードが10個ある場合、読み取りスループットは10倍になります。

書き込みでは、逆になります。複数のノードで完全なレプリケーションを行うと、レプリケーションが同期的な場合、操作が遅くなります。この場合、書き込みに関与するのはノードのサブセットのみであるため、データベースを複数のノードに分割すると、書き込みをスケールアップできます。さらに、1つのサーバーノードHDよりも大きいデータベースを使用できます。

書き込みでスケールアップ

ネットワークが低速で、同期（デフォルト）レプリケーションがある場合、遅延のコストを支払うことができます。実際、OrientDBが同期的に実行される場合、少なくとも writeQuorum を待機します。つまり、writeQuorumが3で、5つのノードがある場合、コーディネーターサーバーノード（分散操作が開始される）は、クライアントに回答を提供するために、少なくとも3つのノードからの回答を待つ必要があります。

一貫性を維持するには、writeQuorumを過半数に設定する必要があります。 5つのノードがある場合、大半は3です。 4つのノードでは、まだ3です。 writeQuorumを4または5ではなく3に設定すると、待ち時間のコストを削減し、一貫性を維持できます。

非同期複製

速度を上げるために、非同期レプリケーションをセットアップして、遅延のボトルネックを解消できます。この場合、コーディネーターサーバーノードはローカルで操作を実行し、クライアントに回答を提供します。複製全体がバックグラウンドになります。クォーラムに達していない場合、変更は透過的にロールバックされます。

読み取りでスケールアップ

すでにwriteQuorumを過半数のノードに設定している場合は、 readQuorum を1（デフォルト）のままにしておくことができます。これにより、すべての読み取りが高速化されます。

Orientdb-performance-tuning

目次