BH12.12/SPARQLthon10/MBGD

提供:TogoWiki

移動: 案内, 検索

SPARQLthon10

目次

メモ

  • Virtuoso
    • REST API で maxrows を指定できないか
    • Virtuoso7で、CONSTRUCTの結果をhtmlで表示すると結構良さげ
    • Virtuoso sparql-auth(Securing SPARQL endpoints
      • INSERT できることは確認した
      • blank node を含むデータが INSERT できない
  • blank node の必要性
    • blank node はない方が、検索しやすくない?
    • nodeとしてまとめるからには、なにか概念的なまとまりがあるはずで、その概念をあらわすURIがあってもよいはずでは
    • 既存のデータをRDF化したいが、どうしても適切なURIが割り当てられないときに、しょうがなく使うものではないだろうか
  • OPL

データベースファイルとログファイルについて

virtuoso.db

データベースファイル

  • データベースを更新しても、メモリ上で更新されるだけで、virtuoso.db には保存されてはいない
  • 周期的に来るcheckpointで virtuoso.db に保存される(defaultで60分)
  • 再起動したりしたら、基本的には virtuoso.db に保存済のデータに戻ることになる(rollback)

virtuoso.trx

transactionログファイル

  • virtuoso.db と、メモリ上のデータとの差分は、virtuoso.trx にログとして保存されている
    • DML(data manipulation language) statements
  • 再起動したりして rollback した後に、このログを使ってデータの復元を試みることになる(roll forward)
  • ログが大き過ぎると、roll forwardが終わらなくて困ることがある

Tips

  • transactionロギングをオフにすれば、単純な仕組みになる
    • 更新が速くなる(らしい)
    • 再起動したりしても roll forward しない
    • そのかわりメモリとvirtuoso.dbとの差分が再起動により失われる
  • データを更新したら、手動でcheckpointを実行して、virtuoso.db に保存するようにする
  • row-by-row autocommit [1] をオンにしてから更新する
    • 変更された行ごとにcommitする
      • rollback space の消費を抑えることができる
      • parallel updateの間でのデッドロックを防ぐ
    • good for any batch operations where concurrent updates are not expected
      • such as bulk loading of data, materialization of RDF inferred data etc.
    • 多少のペナルティはあるが10%以下らしい

関数メモ

ロードするには

  • DB.DBA.TTLP_MT()
    • transaction log を残さない。終了後に手動でcheckpointかける。
  • 最も望ましいのは、ファイルを細切れにした上で、parallelにロードすることらしい
  • 一つのファイルを、マルチスレッドでロードしても、それほどの効率は期待できないらしい

log_enable();

  • log_enable (bits, quiet) ; [2]
    • 上位bit : row-by-row autocommit (デフォルトでオフ。オンにしても、SQL等の接続が切れたらオフに戻る)
    • 下位bit : transaction logging(デフォルトでオン。オフにしても、transactionが終わったらオンに戻る)
    • quiet : エラーを抑制 (logging が既にオフなのに、オフにしようとしたとき)
  • log_enable(3) ;
    • row-by-row autocommit オン logging オン
    • This will cause every updated row to be logged in the transaction log after it is updated, which is not very efficient.
    • 更新された行毎にtransaction logに記録される。効率的とはいえない
  • log_enable(2) ;
    • row-by-row autocommit オン logging オフ
    • Since transaction-by-transaction recovery is generally not an issue in batch updates, a value of 2 is usually better.
    • バッチ処理をしているなら、transaction毎の復旧とか普通は考えないので、設定2でよい
  • log_enable(1) ;
    • デフォルトに戻す

checkpoint_interval();

  • checkpoint_interval (minutes) ; [3]
  • checkpoint_interval (0) ;
    • 再起動して roll forwad した後にだけ checkpoint 実行
  • checkpoint_interval (-1) ;
    • 全てのcheckpointをオフにする
    • バックアップしたvirtuoso.dbで戻したいとき等に使う
  • checkpoint_interval (6000) ;
    • 当然、transaction logが長くなり、roll forwad のときにも時間がかかる
    • loggingをオフにすればよいかも

bulk load

  • ld_dir();
  • DB.DBA.rdf_loader_run ();
  • 止めるときは rdf_load_stop (); を使う
  • ログを残さないので、終了後に手動でcheckpointかける
  • 内部的には、DB.DBA.ttlp() や DB.DBA.rdf_load_rdfxml を呼んでいる
  • bulk loadの最中でも、クエリーやtransactionを処理することができる


ref. RDF performance tuning

ref. Delete large graphs

個人用ツール