BH12.12/SPARQLthon10/MBGD
提供:TogoWiki
目次 |
メモ
- Virtuoso
- REST API で maxrows を指定できないか
- Virtuoso7で、CONSTRUCTの結果をhtmlで表示すると結構良さげ
- Virtuoso sparql-auth(Securing SPARQL endpoints)
- INSERT できることは確認した
- blank node を含むデータが INSERT できない
- PREFIX定義がかぶったときの動作は決まっているか
- 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%以下らしい
- 変更された行ごとにcommitする
関数メモ
ロードするには
- 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. Delete large graphs