問題タブ [graphdb]

オントロジーとかなり大きなデータをロードするために、GraphDB の loadrdf ツールを使用しています。pool.buffer.size=800000 と jvm -Xmx を 24g に設定しました。パラレルモードとシリアルモードの両方を試しました。レポの合計ステートメントが約 10k を超えると、どちらも遅くなります。最終的には、1 秒あたり 1 または 2 ステートメントまで遅くなります。これが loadrdf の通常の動作なのか、それともパフォーマンスを最適化する方法があるのか​​ 誰かが知っていますか?

編集tuple-index-memory を増やしました。私のレポttl構成の一部を参照してください：

しかし、どういうわけか、プロセスはまだ遅くなります。「世界平均速度: 1,402 st/s」で始まります。しかし、「リポジトリ内のステートメント: 61,831」の後、「グローバル平均レート: 20 st/s」まで減速します。私は自分のjvmを与えます: -Xms24g -Xmx36g

RDF4J (以前のセサミ) フレームワークを使用して、リモートの GraphDB トリプル ストアに対して sparql クエリを実行しています。

これは、Graphdb サーバーの URL とリポジトリ ID を受け取る rdf4j HTTPRepository インターフェースを介して正常に機能しますが、sparlq エンドポイント URL をパラメーターとして受け取る rdf4j SPARQLRepository インターフェースを使用すると失敗します。

クエリを実行すると、クエリの検証で例外が発生します

"サーバー プロトコルの取得に失敗しました。このサーバーにはそのようなリソースはありません: http:///sparql?sparql?queryLn=SPARQL&query=",

sparql エンドポイントの URLと思われる場所http://<host:port>/sparqlはどこですか。これは sesame 2.7.8 と rdf4j M3 ライブラリの両方で発生しており、2 つの「すぐに使用できる」ライブラリ、つまり起動スクリプトで開始された、graphdb free 6.6.2 と 7.0.3 のインストールでも同様に発生しています。また、rdf4j SPARQLRepository インターフェイスを介して sparlq エンドポイントhttp://factforge.net/sparqlに接続しようとしたときにも発生します。これは、graphdb で実行されることがわかっています。

実際の sparql エンドポイントの URL は http:///sparql ではなく、graphdb のドキュメントに記載されていない別のものである可能性があります。誰もがこれを照らす可能性のある光に感謝します。

編集: Factforge の sparql エンドポイントに対して実行されたコード:

次の例外が生成されます。

ご協力ありがとうございました

GraphDB のドキュメントによると、基礎となる RDF4J データベースに対して直接プログラミングすることが可能です。2 つの別々のアプリケーションが同じデータベース ファイルに同時にアクセスできるというのは、私の直感に反します。同時書き込みを含め、これは正しく処理されていますか?

GraphDB は古い Sesame 2.9 バージョンを使用していると思います。最新の RDF4J 2.1 バージョンでファイル形式は変更されましたか? それとも、代わりにこの古い Sesame バージョンを使用する必要がありますか?

上記のすべてが正しければ、HTTP 接続と比較してパフォーマンスが大幅に向上すると思います。これを裏付けるテスト結果はありますか?

ドキュメントを確認しましたが、バルク ロードの一般的なガイドラインを特定できません。

データをgraphdbに一括ロードする最良の方法は、LoadRDFツールを使用することです。

ただし、適切な設定の一般的なルールはよくわかりません。まず、SSD ドライブを搭載した「平均的な」サーバーを使用している場合、どのような解析速度が許容されますか? 1.000 ステートメント/秒、10.000 ステートメント/秒、またはそれよりも多いか少ないか?

また、良い設定は何ですか？たとえば、デフォルトの 200.000 ステートメントを持つ -Dpool.buffer.size を設定できますが、10 ギガの RAM がある場合、これを増やす経験則は何でしょうか。また、100 または 300 ギガの RAM がある場合はどうでしょうか?

もう 1 つのオプションは -Dinfer.pool.size です。最小 4 の CPU があるため、スレッドの最大数に設定されます。したがって、1 コア = 4 スレッド、32 コアは 32 スレッドです。これは特別な調整を必要としないと思いますか、それとも CPU の負荷を減らしたい場合や、32 コアの場合に 64 スレッドにオーバーシュートしたくない場合にのみ必要ですか?

configs /templatesの例を含むタートル ファイルを介して利用できる追加のオプションもあります。おそらく owlim:cache-memory と owlim:tuple-index-memory はロード中に役立ち、他の設定はロード後に役立つでしょうか?

最終的に、1 つの大きなタートル ファイルではなく、何百もの個別のファイルがあるかどうか、および/またはファイルを圧縮すると読み込み速度が向上するか、それとも初期ディスク使用量が減少するだけかどうかも問題になりますか?

個人的には、現在 290 GB RAM と 32 コア、1.8T RAID 0 SSD ドライブ (ロード後にバックアップが作成されます) のセットアップがあり、SSD から同じ SSD への 30 億トリプルの初期ロードを実行しようとしています。 1 秒あたり 16.461 ステートメントのグローバル速度ではしばらく時間がかかりますが、これを改善するかどうか、またどのように改善するかはわかりません。