シーケンスのキャッシュ機能

[awaawa]

awaawaです。

s2jdbcのようにシーケンスのキャッシュ機能をdbfluteでも実装していただけないでしょうか。
(シーケンスのインクリメント値分を使い切るまで、java側でインクリメントする。)

oracleで大量データ登録をしているのですが、
その際シーケンス発行がボトルネックになっています。
(シーケンスを使うカラムに手動で値を設定するとパフォーマンスは改善します。)

シーケンスを使わないで、該当テーブルのpkのmax値を随時インクリメントして手動設定する方法もありますが、
できればシーケンスを使いたいと思っています。

ご検討いただけないでしょうか。

#
# 別件です。
# databaseInfoMap.dfpropのcolumnExceptListがうまく動作しませんでした。
# ※おそらくadditionalSchemaMap対応の際かと。
# DfAbstractMetaDataHandler.getRealSimpleColumnExceptList()の
# schemaNameの判定が間違っているようです。。
# dbflute-basic-exampleでは、schemaNameはnullではなく空文字でした。
# ※oracleなどは確認してませんが、メインスキーマ名かもです。
#
# ちなみにこの機能、テーブル名も指定できるように拡張することは難しいでしょうか。
# あるテーブルのカラムを削除するときに、先にdbfluteで自動生成して
# 影響調査や事前にdbflute上削除できたらなと。
# (そもそもの使い方と違うので、実装上、ポリシー上可能であればで。)
#

[kubo]

jfluteです。

> s2jdbcのようにシーケンスのキャッシュ機能をdbfluteでも実装していただけないでしょうか。
> (シーケンスのインクリメント値分を使い切るまで、java側でインクリメントする。)
これもうちょい具体的な処理教えて頂けます？
(どっかにドキュメントあるかな？)

> 大量データ登録
参考までに、何件くらいを想定していますでしょうか？
あと、"batchInsert()は使ってる" でOKですか？

> # databaseInfoMap.dfpropのcolumnExceptListがうまく動作しませんでした。
> # ※おそらくadditionalSchemaMap対応の際かと。
> # DfAbstractMetaDataHandler.getRealSimpleColumnExceptList()の
> # schemaNameの判定が間違っているようです。。

あら、ありがとうございます。
どのExampleでもテストがないのが敗因ですね。
直しておきます。

> # ちなみにこの機能、テーブル名も指定できるように
> 拡張することは難しいでしょうか。
やっちゃいましょうかね。ずっと昔に取り急ぎで入れて、
それ以降ずっとマイナー機能としてそのままだったのですが....

2010/1/15 awaawa <p1us3i...@gmail.com>:

> --
> このメールは Google グループのグループ「DBFluteユーザの集い」の登録者に送られています。
> このグループに投稿するには、dbf...@googlegroups.com にメールを送信してください。
> このグループから退会するには、dbflute+u...@googlegroups.com にメールを送信してください。
> 詳細については、http://groups.google.com/group/dbflute?hl=ja からこのグループにアクセスしてください。
>
>
>
>

[kubo]

jfluteです。

> # databaseInfoMap.dfpropのcolumnExceptListがうまく動作しませんでした。
SNAPSHOTで対応してみました(EMechaでダウンロード可能)。
バグの方も同時に直しています。
(awaawaさんの言う通り明らかにif文が足りてなかったですね)

まずは、columnExceptListを設定していると例外になります。
(移行して下さいって感じのメッセージが出ます)

で、新たにcolumnExceptMapを設定すると利用可能です。
テンプレートのコメントを参考にして下さい。

; columnExceptMap = map:{
; VENDOR_CHECK = list:{COLUMN_EXCEPT_TEST}
}

dbflute-mysql-exampleにてテストしています。
(こういうDB依存じゃないちょっとした特別な状況のテストは
dbflute-mysql-exampleにて)

2010/1/15 kubo <dbf...@gmail.com>:

[kubo]

jfluteです。

シーケンスの話ですが、色々検索してみて少し理解しました。
JPAの仕様(機構)として、そういうのがあるみたいですね。

でも、これって、ここまでやっちゃったら、シーケンスを
使う意味があるのかどうかがまだよくわかってないです。
(それならば、アプリ領域で全部採番しちゃえばと)
あと、やはり別アプリとの同期ってどうなってるのか！？
タイミングによって、同じ番号でinsertしちゃう可能性ってないのか！？
(めったにないという割り切りもアリかもですが...そこどうなってるのか)
この辺の疑問を明確にしてからじゃないと、まだなんともですね。

ちなみに念のための確認、DB側のシーケンスのキャッシュを
NOCACHEにしてるってことはないですか？
(まあ、そもそもキャッシュしても効果が薄いかもですが)
http://www.shift-the-oracle.com/sequence/

2010/1/15 kubo <dbf...@gmail.com>:

[kubo]

jfluteです。

awaawaさん、

A. DB上のシーケンスの採番処理自体が重いのか
B. アプリでの "単独のシーケンスのselect" が重いのか
C. 両方それなり

ってのを明確にしたいので、
一時的に外だしSQLでinsert文を書いて、
insert文の中にSEQ.nextvalを埋め込んで
同じ処理を試して頂けませんか？

もし、B or Cであれば、

　少なくとも外だしSQLにすることで改善する

そして、

　DBFluteのオプションでinsert文にnextvalを埋め込む
　っていう改善をする道もあるかも

というのを視野に入れています。
※処理後のEntityに採番されたIDが入らないのが許容できるなら

#
# batchInsert()の何かしらのオプションで、
# 処理後のEntityに採番されたIDが入らないけど
# insert文にnextvalを埋め込む、ってのが実行できてもいいかも
#
# 特に大量データ登録のときって、処理後のEntityのIDをアプリで
# 利用しないことも多いかなぁと(それよりパフォーマンス優先で)
#

2010/1/15 kubo <dbf...@gmail.com>:

[hajimeni]

割り込みですいません。西山(hajimeni)です。

> でも、これって、ここまでやっちゃったら、シーケンスを
> 使う意味があるのかどうかがまだよくわかってないです。
> (それならば、アプリ領域で全部採番しちゃえばと)
> あと、やはり別アプリとの同期ってどうなってるのか！？
> タイミングによって、同じ番号でinsertしちゃう可能性ってないのか！？

http://d.hatena.ne.jp/agt/20080208

この辺りの話ですね。
シーケンスの取得自体が重いのではないでしょうか。

JPAの仕様でも、デフォルト50でallocationSizeが設定されますので、次のようにシーケンスを作成すれば、

create sequence seq_hoge increment 50;

アプリごと別々に50ずつ割り振られる感じになるので、同じ番号になる心配は、無いのではないでしょうか。
DBのシーケンス取得は同期のはずですし。

アプリ側でシーケンスを割り振る際の同期はしっかりしなければいけないと思いますが。

On 1月15日, 午前11:30, kubo <dbfl...@gmail.com> wrote:
> jfluteです。
>
> シーケンスの話ですが、色々検索してみて少し理解しました。
> JPAの仕様(機構)として、そういうのがあるみたいですね。
>
> でも、これって、ここまでやっちゃったら、シーケンスを
> 使う意味があるのかどうかがまだよくわかってないです。
> (それならば、アプリ領域で全部採番しちゃえばと)
> あと、やはり別アプリとの同期ってどうなってるのか！？
> タイミングによって、同じ番号でinsertしちゃう可能性ってないのか！？
> (めったにないという割り切りもアリかもですが...そこどうなってるのか)
> この辺の疑問を明確にしてからじゃないと、まだなんともですね。
>
> ちなみに念のための確認、DB側のシーケンスのキャッシュを
> NOCACHEにしてるってことはないですか？
> (まあ、そもそもキャッシュしても効果が薄いかもですが)http://www.shift-the-oracle.com/sequence/
>

> 2010/1/15 kubo <dbfl...@gmail.com>:

>
> > jfluteです。
>
> >> # databaseInfoMap.dfpropのcolumnExceptListがうまく動作しませんでした。
> > SNAPSHOTで対応してみました(EMechaでダウンロード可能)。
> > バグの方も同時に直しています。
> > (awaawaさんの言う通り明らかにif文が足りてなかったですね)
>
> > まずは、columnExceptListを設定していると例外になります。
> > (移行して下さいって感じのメッセージが出ます)
>
> > で、新たにcolumnExceptMapを設定すると利用可能です。
> > テンプレートのコメントを参考にして下さい。
>
> > ; columnExceptMap = map:{
> > ; VENDOR_CHECK = list:{COLUMN_EXCEPT_TEST}
> > }
>
> > dbflute-mysql-exampleにてテストしています。
> > (こういうDB依存じゃないちょっとした特別な状況のテストは
> > dbflute-mysql-exampleにて)
>

> > 2010/1/15 kubo <dbfl...@gmail.com>:

> >> jfluteです。
>
> >>> s2jdbcのようにシーケンスのキャッシュ機能をdbfluteでも実装していただけないでしょうか。
> >>> (シーケンスのインクリメント値分を使い切るまで、java側でインクリメントする。)
> >> これもうちょい具体的な処理教えて頂けます？
> >> (どっかにドキュメントあるかな？)
>
> >>> 大量データ登録
> >> 参考までに、何件くらいを想定していますでしょうか？
> >> あと、"batchInsert()は使ってる" でOKですか？
>
> >>> # databaseInfoMap.dfpropのcolumnExceptListがうまく動作しませんでした。
> >>> # ※おそらくadditionalSchemaMap対応の際かと。
> >>> # DfAbstractMetaDataHandler.getRealSimpleColumnExceptList()の
> >>> # schemaNameの判定が間違っているようです。。
> >> あら、ありがとうございます。
> >> どのExampleでもテストがないのが敗因ですね。
> >> 直しておきます。
>
> >>> # ちなみにこの機能、テーブル名も指定できるように
> >>> 拡張することは難しいでしょうか。
> >> やっちゃいましょうかね。ずっと昔に取り急ぎで入れて、
> >> それ以降ずっとマイナー機能としてそのままだったのですが....
>

> >> 2010/1/15 awaawa <p1us3inus2...@gmail.com>:

[kubo]

jfluteです。

hajimeniさん、情報ありがとうございます。
そうですね。こちらでも色々分析してて、
要は、「1から50までを予約する」みたいな感じですね。
次に別アプリは「51から100までを予約」。
登録する順番が逆転する可能性ありますが、
incrementを50にしてる時点でそういうのは割り切りですかね。
別アプリで同じ機構をもってなければ飛び番しまくるし。

で、分析の結果、
　"デフォルトは今のまま(トラブルが発生しやすいと思われるため)"
で、
　"incrementの数値をdfpropに指定すること自体がキャッシュ利用合図"
というような仕様にすれば、ズレでトラブルこともないかと。

という感じでリアルタイムに検討しています。
(無論、それはそれでA, Bのパフォーマンスの検証情報は欲しいけど)

また、"batchInsert()でnextvalを埋め込む" って機能も、
これはこれであってもいいかなって(やるかどうかまだ検討)。
組織次第ですが、DB側に開発側の都合で "increment by 50"
ってしてもらうことができない場合もあるんじゃないかと。
その場合、EntityのID格納を犠牲にちょっとでも速くできるなら
役に立つことはあるんじゃないかなと。

2010/1/15 hajimeni <hajim...@gmail.com>:

[awaawa]

awaawaです。

columnExceptMap確認しました。ご対応ありがとうございます。(早い!!)

シーケンスのキャッシュ機能の件ですが、以下回答です。
> 参考までに、何件くらいを想定していますでしょうか？
　～10万件ぐらいです。なお、テーブルは10カラム無いぐらいです。

> あと、"batchInsert()は使ってる" でOKですか？
　使ってます。

> NOCACHEにしてるってことはないですか？
　デフォルト(20)です。

> A. DB上のシーケンスの採番処理自体が重いのか
> B. アプリでの "単独のシーケンスのselect" が重いのか
> C. 両方それなり

Bです。アプリ経由でのシーケンス採番処理が極端に重いです。
(外だしSQLであっても同様でした。)
Object Browserでは同じクエリ(シーケンス採番処理)でも大して遅くありませんでした。
何でですかね。。。

hajimeniさん、フォローありがとうございます。
jfluteさん、分析していただいたとおりの想定でいます。

できれば、この機能を使うかどうかはdfpropでboolean指定にして、
increment値はALL_SEQUENCESでとっていただけるとありがたいです。
※相互の値が違うと機能が誤作動するので。

> "batchInsert()でnextvalを埋め込む" って機能
これ、あったらうれしいです。
おっしゃるとおり、大量データ登録の場合、登録後ID利用しないことが多いので。

On 1月15日, 午後7:11, kubo <dbfl...@gmail.com> wrote:
> jfluteです。
>
> hajimeniさん、情報ありがとうございます。
> そうですね。こちらでも色々分析してて、
> 要は、「1から50までを予約する」みたいな感じですね。
> 次に別アプリは「51から100までを予約」。
> 登録する順番が逆転する可能性ありますが、
> incrementを50にしてる時点でそういうのは割り切りですかね。
> 別アプリで同じ機構をもってなければ飛び番しまくるし。
>
> で、分析の結果、
> 　"デフォルトは今のまま(トラブルが発生しやすいと思われるため)"
> で、
> 　"incrementの数値をdfpropに指定すること自体がキャッシュ利用合図"
> というような仕様にすれば、ズレでトラブルこともないかと。
>
> という感じでリアルタイムに検討しています。
> (無論、それはそれでA, Bのパフォーマンスの検証情報は欲しいけど)
>
> また、"batchInsert()でnextvalを埋め込む" って機能も、
> これはこれであってもいいかなって(やるかどうかまだ検討)。
> 組織次第ですが、DB側に開発側の都合で "increment by 50"
> ってしてもらうことができない場合もあるんじゃないかと。
> その場合、EntityのID格納を犠牲にちょっとでも速くできるなら
> 役に立つことはあるんじゃないかなと。
>

> 2010/1/15 hajimeni <hajimeni...@gmail.com>:

[kubo]

jfluteです。

> columnExceptMap確認しました。ご対応ありがとうございます。(早い!!)
ご確認ありがとうございます。

> Bです。アプリ経由でのシーケンス採番処理が極端に重いです。
> (外だしSQLであっても同様でした。)
> Object Browserでは同じクエリ(シーケンス採番処理)でも大して遅くありませんでした。
> 何でですかね。。。

ふむ、これって、
insert文にSEQ.nextvalを埋め込んだ外だしSQLでも
遅かった、って感じですか？

> increment値はALL_SEQUENCESでとっていただけるとありがたいです。
> ※相互の値が違うと機能が誤作動するので。
それは、ひたすら検討したのだが、
DB2やPostgreSQLやH2で同じことが果たしてできるかなぁと。
なので、せめて「数値を指定することが利用合図」という形にして、
ズレのミスが発生しにくいように考えています。
(要は、デフォルトで50とかはやらない)

リアルタイムで実装してますので、
できたら検証お願いしますね。
かなり厳密にテストしないといけなさそうなので。

2010/1/16 awaawa <p1us3i...@gmail.com>:

[kubo]

jfluteです。

>> increment値はALL_SEQUENCESでとっていただけるとありがたいです。
>> ※相互の値が違うと機能が誤作動するので。

ああ、でもあれかな。
Oracleだと数値の指定を省略できる。
とかなら、仕様の統一性として問題無さそうかな。

#
# それはそれとして、DB2やPostgreSQLでincrementの値を
# 取得する方法をもし知ってたら教えてね。
#

2010/1/16 kubo <dbf...@gmail.com>:

[awaawa]

awaawaです。

> ふむ、これって、
> insert文にSEQ.nextvalを埋め込んだ外だしSQLでも
> 遅かった、って感じですか？

そうです。

> # それはそれとして、DB2やPostgreSQLでincrementの値を
> # 取得する方法をもし知ってたら教えてね。

調べてみました。実環境が無いため実行できていませんが。
DB2 select * from SYSCAT.SEQUENCES
PostgreSQL select * from information_schema.sequences

> リアルタイムで実装してますので、
> できたら検証お願いしますね。
> かなり厳密にテストしないといけなさそうなので。
了解です。

On 1月16日, 午前2:21, kubo <dbfl...@gmail.com> wrote:
> jfluteです。
>
> >> increment値はALL_SEQUENCESでとっていただけるとありがたいです。
> >> ※相互の値が違うと機能が誤作動するので。
>
> ああ、でもあれかな。
> Oracleだと数値の指定を省略できる。
> とかなら、仕様の統一性として問題無さそうかな。
>
> #
> # それはそれとして、DB2やPostgreSQLでincrementの値を
> # 取得する方法をもし知ってたら教えてね。
> #
>

> 2010/1/16 kubo <dbfl...@gmail.com>:

>
> > jfluteです。
>
> >> columnExceptMap確認しました。ご対応ありがとうございます。(早い!!)
> > ご確認ありがとうございます。
>
> >> Bです。アプリ経由でのシーケンス採番処理が極端に重いです。
> >> (外だしSQLであっても同様でした。)
> >> Object Browserでは同じクエリ(シーケンス採番処理)でも大して遅くありませんでした。
> >> 何でですかね。。。
> > ふむ、これって、
> > insert文にSEQ.nextvalを埋め込んだ外だしSQLでも
> > 遅かった、って感じですか？
>
> >> increment値はALL_SEQUENCESでとっていただけるとありがたいです。
> >> ※相互の値が違うと機能が誤作動するので。
> > それは、ひたすら検討したのだが、
> > DB2やPostgreSQLやH2で同じことが果たしてできるかなぁと。
> > なので、せめて「数値を指定することが利用合図」という形にして、
> > ズレのミスが発生しにくいように考えています。
> > (要は、デフォルトで50とかはやらない)
>
> > リアルタイムで実装してますので、
> > できたら検証お願いしますね。
> > かなり厳密にテストしないといけなさそうなので。
>

> > 2010/1/16 awaawa <p1us3inus2...@gmail.com>:

> ...
>
> もっと読む ≫

[kubo]

jfluteです。

>> insert文にSEQ.nextvalを埋め込んだ外だしSQLでも
>> 遅かった、って感じですか？
> そうです。

あらま、そうですか。
じゃあ、"A" ということですね。
したら、batchInsert()でinsert文埋め込み機能追加しても
あんまり効果はなさそうですね。。。
ありがとうございます。

>> # それはそれとして、DB2やPostgreSQLでincrementの値を
>> # 取得する方法をもし知ってたら教えてね。
> 調べてみました。実環境が無いため実行できていませんが。
> DB2 select * from SYSCAT.SEQUENCES
> PostgreSQL select * from information_schema.sequences

おお、ありがとうございます。
ふむぅ、本当に権限が大丈夫なのか、
バージョン違いで大丈夫なのか、
ちょっと色々不安な感じもありますね...
とりあえずは、Oracleだけ省略可能って感じにするかもです。
(PostgreSQLはいけるかなぁ...でもテスト環境がつらい)

DBFlute-0.9.6.4-SNAPSHOT
(ランタイムは、0.9.6.4-03-SNAPSHOT)

を利用してみて下さい。
そして、sequenceDefinitionMap.dfpropにて

　MEMBER = SEQ_MEMBER:cache()

と、コロンに続いて "cache" そして "()"、
"()" は通常は中に数値(cacheSize)を指定しますが、
Oracleなら省略可能になっています。
※cacheSize = incrementSize

で、SelectableDataSourceを利用している場合は、
(これがとても悩みの種だった)
DBFluteConfigでSequenceCacheのキー値の生成で
カスタマイズできるようにしました。
デフォルトは "シーケンス単位" ですが、
SelectableDataSourceを使う場合は、カレントDataSourceの
名前をキーに含めるようにします。

こちらでも引き続きテストしていきます。
dbflute-oracle-exampleで試してますので参考に。
高負荷のテストも書いています。

あと、ここの話。
http://d.hatena.ne.jp/jflute/20100111/1263191486
まさしく "データのIDの増分量がシーケンスと違う" に
なりがちなので、テストデータのIDとアプリでの最初のIDの
間には少し間があきます(まあ、基本割り切りできるかと思いますが)。

#
# さすがにぶっ続けで疲れたぁ...
#

2010/1/16 awaawa <p1us3i...@gmail.com>:

[kubo]

jfluteです。

最新のSNAPSHOTで一つ変更です。
(ランタイムはそのまま)

> MEMBER = SEQ_MEMBER:cache()

を改め：

MEMBER = SEQ_MEMBER:dfcache()

というように変更しました。
DB側のシーケンスのキャッシュと紛らわしいので、
全体として、DBFluteのシーケンスキャッシュという
意味合いを持たせるようにしました。
「(シーケンスの)でぃーえふきゃっしゅ」って呼んで下され。

そして、最新だと、
DB2、H2でcacheSizeの指定を省略可能です。
PostgreSQLに関しては、メタ情報を検索したんだけど、
seqencesテーブルにもincrement情報が入ってない(!?)ので、
明示的に数値を指定する必要があります。
ex) dfcache(50)

あと、SchemaHTMLのPK制約の補足(ツールチップ)でも
シーケンスの情報を出せるだけ出してみました。

2010/1/16 kubo <dbf...@gmail.com>:

[awaawa]

awaawaです。

遅くなりましたが、こちらでもパフォーマンスに重点を置いた簡単な確認をしました。
とりあえず現時点での報告です。

以下で、1万件分のシーケンス番号を採番してみました。(とりあえずinsertなしで)
※PCスペックやネットワーク等影響はありますが、相対的に見る感じで。
1. selectNextVal() ※dfcache(100)
2. selectNextVal() ※dfcacheなし
3. 外だしSQL select XXX.nextVal from dual
4. 外だしSQL select XXX.nextVal from (select * from dual union select *
from dual union ...) ※埋め込み変数コメントで1万回unionする。

平均 1回目 2回目 3回目 4回目 5回目
1. 20.034 19.906 19.657 19.890 20.640 20.078
2. 37.826 38.187 37.781 38.460 38.453 36.250
3. 42.559 43.187 44.000 43.156 40.937 41.516
4. 8.741 8.610 7.969 10.641 8.313 8.172

dfcache(100)すると半分ぐらいになりました。
(実際、junitの実行が1→2→3の順だったのでウォームアップ分を考えると1はもう少し早いはずです。)
4は実施中に気づいたことで、やってみたら思った以上に早かったです。(トリッキーですが)
4はjuntで単独で実行したので、1と条件はほぼ同じはずです。
なので、4もウォームアップ分を考えるともう少し早いはずです。

ちなみにやっている途中に思ったことがあるので、確認させてください。
※ソース確認か実際実行すればわかることで申し訳ありませんが。。。
・デクリメントの場合も大丈夫でしょうか。(あんまり使わないと思いますが。)
・インクリメント・デクリメントが1、-1の場合は同期しないことは可能でしょうか。(すでにやっている?)

引き続き、insert含め確認します。

#
# > さすがにぶっ続けで疲れたぁ...
# お疲れ様でした。ありがとうございます。いつもホントすいません。
#
# > で、SelectableDataSourceを利用している場合は、
# > (これがとても悩みの種だった)
# このケースはまったく頭になかったです。確かに大変。さすがです。
#

On 1月16日, 午後5:00, kubo <dbfl...@gmail.com> wrote:
> jfluteです。
>
> 最新のSNAPSHOTで一つ変更です。
> (ランタイムはそのまま)
>
> > MEMBER = SEQ_MEMBER:cache()
>
> を改め：
>
> MEMBER = SEQ_MEMBER:dfcache()
>
> というように変更しました。
> DB側のシーケンスのキャッシュと紛らわしいので、
> 全体として、DBFluteのシーケンスキャッシュという
> 意味合いを持たせるようにしました。
> 「(シーケンスの)でぃーえふきゃっしゅ」って呼んで下され。
>
> そして、最新だと、
> DB2、H2でcacheSizeの指定を省略可能です。
> PostgreSQLに関しては、メタ情報を検索したんだけど、
> seqencesテーブルにもincrement情報が入ってない(!?)ので、
> 明示的に数値を指定する必要があります。
> ex) dfcache(50)
>
> あと、SchemaHTMLのPK制約の補足(ツールチップ)でも
> シーケンスの情報を出せるだけ出してみました。
>

> 2010/1/16 kubo <dbfl...@gmail.com>:

> > 2010/1/16 awaawa <p1us3inus2...@gmail.com>:

> ...
>
> もっと読む ≫

[kubo]

jfluteです。

ご確認ありがとうございます。
なるほど、単なるシーケンス取得で改善がありますね。

でも、"4" も速いんだねぇ...
DB内のでシーケンス取得処理自体が遅いという想定を
しているのですが、一つのSQL内で複数のシーケンス取得だと、
速いのかな。(DB内でのシーケンスへのアクセスが一回で済む
というのもあるかもしれませんね)

キャッシュの方式のさらなるオプションとして、
"union使ったまとめシーケンス取得" もできるかもですね。
内部でこのSQLを発行して、50個溜めておいて、アプリでは
使い切るまでそれを使って、使い終わったら再度SQLで取得。
そしたら、シーケンスのインクリメントを50とかにしなくても
"1" のままでもキャッシュ機能が利用できるのかなぁと。
(やはり組織に寄っては50に抵抗を示される場合もあると思うので)

> ・デクリメントの場合も大丈夫でしょうか。(あんまり使わないと思いますが。)
ダメですね。デクリメントの場合はキャッシュ機能が無効になります。
ただ、そもそもシーケンスの増分50で、キャッシュでの増分2という
のもサポートしてなくって、そういう特殊な状況は、
ImplementedInvokeAssistantの拡張で挙動を変えることは可能です。
ただ、簡単であれば、サポートしてみてもいいかも。検討してみます。

関連して、そもそもReplaceSchemaのシーケンス調整がダメですね。
無限ループになっちゃうかも、せめて例外にするか...

> ・インクリメント・デクリメントが1、-1の場合は
> 同期しないことは可能でしょうか。(すでにやっている?)

if (cacheSize == null || cacheSize <= 1) {
　　何もしない(キャッシュしない)
}
という感じなので、dfcacheが指定されていても、
キャッシュの必要がなければキャッシュしません。
要は自動判別という感じです。

2010/1/17 awaawa <p1us3i...@gmail.com>:

[kubo]

jfluteです。

今、アップしたSNAPSHOT(モジュールのみ)では、
ReplaceSchemaのシーケンス調整でdecrementのものは、
(二回シーケンス取得して判定した時点で)処理対象外となります。
まあ、そもそもデクリメントのシーケンスをPKに利用するとき
のみ状況に対する対応です。(相当マイナーかなと)

> DB内のでシーケンス取得処理自体が遅いという想定を
> しているのですが、一つのSQL内で複数のシーケンス取得だと、
> 速いのかな。(DB内でのシーケンスへのアクセスが一回で済む
> というのもあるかもしれませんね)

これ、今の仕組みでも、
"発行するシーケンスのunion数-1 = キャッシュサイズ"
であれば、うまく動きますね。(ちょっと試してみた)
要は、いかに効率良くシーケンスの番号を "予約するか" って
ことなんですね。単発でシーケンス取得したら無意味ですが、
要は一発のSQLで一気に50をインクリメントできればいいわけで。
内部的にちょっと色々検討するところはありますが、
もし、できたらもうちょい柔軟に利用することができるかなぁ！？

2010/1/17 kubo <dbf...@gmail.com>:

[kubo]

jfluteです。

https://www.seasar.org/issues/browse/DBFLUTE-632
こんな感じにしてみました。
大分、DBFluteらしさが出て来たんじゃないかと。

/= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
＜基本＞
o dfcache()を指定しない限りキャッシュはしない
o どんな状況であれ "cacheSize" が "1" 以下ならキャッシュしない

＜cacheSize省略 ":dfcache()" の場合＞
メタ情報から取得した "incrementSize" を "cacheSize" とする。
("incrementSize" が "1" 以下なら何も指定しないのと同じ)

＜cacheSize指定 ":dfcache(50)" の場合＞
メタ情報から取得した "incrementSize" と指定された "cacheSize"
が、一致していれば、それで通常のキャッシュ処理をする。
一致してなくて "cacheSize / incrementSize" で割り切れる場合は、
一回のシーケンス取得でunionを利用して "割った数の分をincrement" し、
キャッシュ処理をする。割り切れない場合は例外。

そもそもメタ情報から "incrementSize" を取得できないDBMSの場合は、
一致していることが大前提となる。(PostgreSQLのみ..どうにかしたいな)

＜特徴＞
incrementSizeを取得できるDBMSなら、設定のズレによる変な動きはしない。
何かがズレている場合は、自動生成時もしくは実行時に例外になる。
さらに、incrementSizeが "1" のままでキャッシュを利用可能。

PostgreSQLだけは、incrementSizeが取得できないため、ズレに気をつける
必要があるし、常にcacheSizeとincrementSizeは同じでなければならない。
(これどうにかしたい)
= = = = = = = = = =/

最新のSNAPSHOTにて反映しています。
(ランタイムは "04-SNAPSHOT")

サイズが一緒(省略も含む)であれば、awaawaさんに
検証してもらったやつの "2" に相当して、
サイズが違って割り切れるのであれば、"4" に相当します。

一万回のunionじゃないので(cacheSize分のunion)、そこまで
速い結果はでないかもしれませんが、incrementSizeが "1" の
ままでも利用出来るし、設定ズレもチェック出来るしなので、
超速くなくても良い感じなんじゃないかと。
(少なくともSQLの発行回数は減るし)

2010/1/17 kubo <dbf...@gmail.com>:

[kubo]

jfluteです。

https://www.seasar.org/issues/browse/DBFLUTE-632
さらに発展しました。
勝手ながら：

o インクリメントを50にする方法 = インクリメント方式(incrementWay)
o unionとか使って一回のSQLで一気に50回採番 = バッチ方式 (batchWay)

と名前を付けさせて頂きました。

最新のSNAPSHOTにて反映。
(ランタイムは "08-SNAPSHOT")

テストもそれぞれのDBでそれぞれの方法を試しています。

インクリメント方式：Oracle, PostgreSQL, H2, DB2
バッチ方式：Oracle, PostgreSQL, H2
※DB2でバッチ方式は未サポート (unionできない!?)

/= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
＜基本＞
o dfcache()を指定しない限りキャッシュはしない
o どんな状況であれ "cacheSize" が "1" 以下ならキャッシュしない

o decrementはキャッシュ機能をサポートしない(実行時例外)
o serial型(PostgreSQL)でも明示的にdfpropに指定すれば利用可能

＜cacheSize省略 ":dfcache()" の場合＞
メタ情報から取得した "incrementSize" を "cacheSize" とする。
("incrementSize" が "1" 以下なら何も指定しないのと同じ)

＜cacheSize指定 ":dfcache(50)" の場合＞
メタ情報から取得した "incrementSize" と指定された "cacheSize"
が、一致していれば、それで通常のキャッシュ処理をする。
一致してなくて "cacheSize / incrementSize" で割り切れる場合は、
一回のシーケンス取得でunionを利用して "割った数の分をincrement" し、
キャッシュ処理をする。割り切れない場合は例外。

そもそもメタ情報から "incrementSize" を取得できないDBMSの場合は、
一致していることが大前提となる。(サポートしているDBは全てOK)

そもそも一回のシーケンス取得でunionを利用することができないDBMSの場合は、
一致していることが大前提となる。(DB2のみ...これはいいかな、仕方ない)
但し、この場合は明示的な例外になるのでズレを恐れることはない

＜特徴＞
incrementSizeを取得できるDBMSなら、設定のズレによる変な動きはしない。
何かがズレている場合は、自動生成時もしくは実行時に例外になる。
さらに、incrementSizeが "1" のままでキャッシュを利用可能。

＜その他＞
PostgreSQLでincrementSizeが取得できていなかったのですが、
"pgsql-jp: 40143" にて教えて頂きました(ありがとうございます)。
"information_schema" からはやはり取得できなくて、
"select increment_by from [sequence]" と実行することで取得できました。

= = = = = = = = = =/

2010/1/17 kubo <dbf...@gmail.com>:

[awaawa]

awaawaです。

デクリメントの件、了解です。
インクリメント1の場合の動作も了解です。

> https://www.seasar.org/issues/browse/DBFLUTE-632
らしさが出てます!!ありがとうございます。
※設定次第でいろいろなケースに対応できますね～

ちょっと気になるのが、unionの一括取得でシーケンス連続取得が保障されるかですね。
同時に複数リクエストが来たときに、間があかないか。
(シーケンスのリストを持っている感じですかね。。。であれば気にすることないですが)

こちらでも確認します。(環境上h2とoracleだけですが + ちょっとお時間をいただきます。)

> 2010/1/17 kubo <dbfl...@gmail.com>:

> > 2010/1/17 kubo <dbfl...@gmail.com>:

> >> jfluteです。
>
> >> 今、アップしたSNAPSHOT(モジュールのみ)では、
> >> ReplaceSchemaのシーケンス調整でdecrementのものは、
> >> (二回シーケンス取得して判定した時点で)処理対象外となります。
> >> まあ、そもそもデクリメントのシーケンスをPKに利用するとき
> >> のみ状況に対する対応です。(相当マイナーかなと)
>
> >>> DB内のでシーケンス取得処理自体が遅いという想定を
> >>> しているのですが、一つのSQL内で複数のシーケンス取得だと、
> >>> 速いのかな。(DB内でのシーケンスへのアクセスが一回で済む
> >>> というのもあるかもしれませんね)
>
> >> これ、今の仕組みでも、
> >> "発行するシーケンスのunion数-1 = キャッシュサイズ"
> >> であれば、うまく動きますね。(ちょっと試してみた)
> >> 要は、いかに効率良くシーケンスの番号を "予約するか" って
> >> ことなんですね。単発でシーケンス取得したら無意味ですが、
> >> 要は一発のSQLで一気に50をインクリメントできればいいわけで。
> >> 内部的にちょっと色々検討するところはありますが、
> >> もし、できたらもうちょい柔軟に利用することができるかなぁ！？
>

> >> 2010/1/17 kubo <dbfl...@gmail.com>:

> >>> 2010/1/17 awaawa <p1us3inus2...@gmail.com>:

> >>>> awaawaです。
>
> >>>> 遅くなりましたが、こちらでもパフォーマンスに重点を置いた簡単な確認をしました。
> >>>> とりあえず現時点での報告です。
>
> >>>> 以下で、1万件分のシーケンス番号を採番してみました。(とりあえずinsertなしで)
> >>>> ※PCスペックやネットワーク等影響はありますが、相対的に見る感じで。
> >>>> 1. selectNextVal() ※dfcache(100)
> >>>> 2. selectNextVal() ※dfcacheなし
> >>>> 3. 外だしSQL select XXX.nextVal from dual
> >>>> 4. 外だしSQL select XXX.nextVal from (select * from dual union select *
> >>>> from dual union ...) ※埋め込み変数コメントで1万回unionする。
>
> >>>> 平均 1回目 2回目 3回目 4回目 5回目
> >>>> 1. 20.034 19.906 19.657 19.890 20.640 20.078
> >>>> 2. 37.826 38.187 37.781 38.460 38.453 36.250
> >>>> 3. 42.559 43.187 44.000 43.156 40.937 41.516
> >>>> 4. 8.741
>

> ...
>
> もっと読む ≫

[kubo]

jfluteです。

> ちょっと気になるのが、unionの一括取得でシーケンス連続取得が保障されるかですね。

それは、既に気にしてて、
H2やPostgreSQLでは、

select next value for SEQ_MEMBER
union all
select next value for SEQ_MEMBER
...
order by 1 asc

としています。union allが順序を保証しないので。
(ただ、実際にはorderしなくて順番通り来ますが)

で、Oracleはorder byができなくて困った。
というかすんごいSQLだよねこれ。
で、order byはできなかったけど、
この場合は、結果をunion allしてるわけじゃなくて、
疑似レコードをunion allで作成して、順序が決まった
その疑似レコードのselect句を評価する課程でnextvalなので、
大丈夫じゃないかなという推測。(とりあえず実際には正常に動作)

Oracleのときだけ、アプリでシーケンスを全件取得して、
ループで一番小さな値を拾うようにするかどうか...
(せっかくパフォーマンスのためにやってるのにやりたくはないねぇ)

> 同時に複数リクエストが来たときに、間があかないか。
共有ロックという考えが、シーケンスにおいても通用するか！？
現状の実装だとシーケンスのリストは取得してないです(先頭取得)。
もし、間があくとしたら、別アプリで同時にシーケンスを
利用した場合に問題が発生するね。

o ただひたすらテスト書いて大丈夫なこと保証する
o 何かしらのDBオブジェクトにロック掛ける
o シーケンス値全部取得して抜け番調べてうまく飛ばす

まだまだ戦うねぇ...

2010/1/18 awaawa <p1us3i...@gmail.com>:

[kubo]

jfluteです。

最新のSNAPSHOT
(ランタイム：09-SNAPSHOT)

で、batchWayの方は、取得したシーケンスをそのまま
割り当てるようにしました。なので、割り込みで抜け番が出ても、
取得した値をただそのまま割り当てるので問題ありません。
ただ、それを検証するのは大変で、当然のこと自アプリ内では
ガッツリsyncして固めているので、現象を発生させるためには、
別アプリから超同時にシーケンスにアクセスしなければなりません。
それはExampleでもテストできてないので、論理的な検証に留まっています。
(自アプリ内でのマルチスレッドテストはドカドカかなりきついのやってます)

また、順序もどうせ全部取得しているので、アプリ上でソートして、
小さい順で取得されるようにしています。

気になるのは、incrementWayとbatchWayのパフォーマンス差。
batchWayがちょっと安全のために処理が増えているので、
どんな感じかなと。まあやらないよりも速ければOKなのですが。

あと、batchWayの特徴としては、
比較的cacheSizeを大きめにしやすいというところです。
cacheSizeを大きくすると、登録順番が逆転する可能性が大きくなるのは
どちらの方式も同じですが、同じ仕組みを持たない(ただのスクリプトとか)
アプリからシーケンス利用したときにincrementWayは飛び番しまくりですが、
batchWayはシーケンスのインクリメントがそもそも "1" なので繋がります。
なので、同じcacheSizeでbatchWayが遅くても、一概にどっちが良いとは
言えないですね。

#
# 朝だぁ...
#

2010/1/18 kubo <dbf...@gmail.com>:

[kubo]

jfluteです。

一旦、この時点で、
DBFlute-0.9.6.4-RC1としました。
(ランタイム：RC1)

2010/1/18 kubo <dbf...@gmail.com>:

[kubo]

jfluteです。

https://www.seasar.org/issues/browse/DBFLUTE-632

"キャッシュサイズが "1" 以下の場合は何もしない"

でしたが、

"キャッシュサイズが "1" 以下の場合は明示的な例外"

としています(RC1に含まれています)。
自動生成時にチェックして例外にしています。

というのは、"キャッシュを利用する" って設定されてながら、
キャッシュサイズが "1" って間違いでしかないのでやはり例外と。

実行時のチェックは実はそのままで "キャッシュしないだけ"
ですが、もっと前の段階の自動生成時でのチェックということで。

2010/1/18 kubo <dbf...@gmail.com>:

[awaawa]

awaawaです。

たくさんの考慮、お疲れ様です。

> 気になるのは、incrementWayとbatchWayのパフォーマンス差。
> batchWayがちょっと安全のために処理が増えているので、
> どんな感じかなと。まあやらないよりも速ければOKなのですが。

これは、時間あるときに数値を出してみたいと思います。

> "キャッシュサイズが "1" 以下の場合は明示的な例外"
了解です。
> 実行時のチェックは実はそのままで "キャッシュしないだけ"
そもそも自動生成時にインクリメントサイズを決定(静的)しているのであれば、
ありえないってことですよね。
(それとも、実行時にインクリメントサイズを問い合わせていて場合によってはありえるんですかね。)

On 1月18日, 午後11:35, kubo <dbfl...@gmail.com> wrote:
> jfluteです。
>
> https://www.seasar.org/issues/browse/DBFLUTE-632
>

> "キャッシュサイズが "1" 以下の場合は何もしない"
>
> でしたが、
>
> "キャッシュサイズが "1" 以下の場合は明示的な例外"
>
> としています(RC1に含まれています)。
> 自動生成時にチェックして例外にしています。
>
> というのは、"キャッシュを利用する" って設定されてながら、
> キャッシュサイズが "1" って間違いでしかないのでやはり例外と。
>
> 実行時のチェックは実はそのままで "キャッシュしないだけ"
> ですが、もっと前の段階の自動生成時でのチェックということで。
>

> 2010/1/18 kubo <dbfl...@gmail.com>:

>
> > jfluteです。
>
> > 一旦、この時点で、
> > DBFlute-0.9.6.4-RC1としました。
> > (ランタイム：RC1)
>

> > 2010/1/18 kubo <dbfl...@gmail.com>:

> >> 2010/1/18 kubo <dbfl...@gmail.com>:

> >>> 2010/1/18 awaawa <p1us3inus2...@gmail.com>:

> ...
>
> もっと読む ≫

[kubo]

jfluteです。

>> 気になるのは、incrementWayとbatchWayのパフォーマンス差。
>> batchWayがちょっと安全のために処理が増えているので、
>> どんな感じかなと。まあやらないよりも速ければOKなのですが。
> これは、時間あるときに数値を出してみたいと思います。

よろしくーー
さて、気合いの入ったBlogも書くかなぁ。

> そもそも自動生成時にインクリメントサイズを決定(静的)しているのであれば、
> ありえないってことですよね。
曹操

2010/1/19 awaawa <p1us3i...@gmail.com>:

[kubo]

jfluteです。

http://d.hatena.ne.jp/jflute/20100119/1263871052
気合い入ったの書いた。
意識合わせって感じで読めるときに読んでおいて下さい。
(できれば、他の皆さんも)

2010/1/19 kubo <dbf...@gmail.com>:

[awaawa]

jfluteさん

ブログコメントの続きです。
いろいろ検証中にバッチ方式で問題が。
パフォーマンス検証で、バッチ方式で10,000で行ったのですが、
union連結でSQL文のサイズ限界(?)になり、例外になりました。
・java.sql.SQLException: ソケットから読み込むデータはこれ以上ありません。
2,820はOK(2,830はNG)でした。
※10,000で1MBちょっと。長すぎですね・・・

で、ちょっと削減されるかと、以下を直叩きでやったんですが、同じ行は同じシーケンス番号が戻ってきますね!
(不思議ー)
select SEQ_TEST.nextval, SEQ_TEST.nextval from (select * from dual
union all ...)

ってことで、ある程度制限したほうがいいみたいです。
(ただどれぐらいがOKって指針がないんですよね。)
要は複数行返ってくればいいんですけどね。(表関数が手軽に使えれば)

後、1つ提案が。
以前外だしSQLでinsert文にnextvalを埋め込んで大量件数を実行したのですが、
for文でexecute実行でした。(なので検証の仕方が悪かったかもです。)
外だしSQLでexecuteBatchがあれば早いかもです。(現状サポートしていないと思いますが)
で、これが早ければ、jfluteさんが以前おっしゃった
「batchInsert()でinsert文埋め込み機能」が有効に。

[awaawa]

awaawaです。

> 要は複数行返ってくればいいんですけどね。(表関数が手軽に使えれば)
ひらめきました!　単純結合(cross join)!! (またまたトリッキーですが)
select SEQ_MEMBER_SEQ_CACHE_BATCH.nextval from
(select * from dual union all ...(計10回))
, (select * from dual union all ...(計10回))
, (select * from dual union all ...(計10回))
...(実際ほしい行数より1桁多い行数になるまで繰り返す)
where rownum <= 実際ほしい行数

これなら10のn剰で戻る行数を増やせます。(+rownumで制限しているので、シーケンス番号も飛びません)
どうですかねー

[kubo]

jfluteです。

awaawaさん、ありがとう！
まとめると...

[問題]
Oracleでのバッチ方式では、キャッシュサイズに限界がある
2,820はOK(2,830はNG)

追加：
PostgreSQLだと、10000でも問題なし。
でもシーケンス取得SQL自体が遅い。(3秒近い)
H2だと、単独スレッドで10000で実行できたけど、20000で
SQLが返ってこない、メモリエラー、"StackOverFlowError"
と不安定。あと、やっぱりそのSQLの実行自体が遅い。
Oracleでもキャッシュサイズ "2000" で一秒半近く。

[試行]
select SEQ_TEST.nextval, SEQ_TEST.nextval from
だと、同じレコード内で同じ番号になってしまう。
(同じレコード内では内部的に番号を使い回してるのかもね)

[解決案]
<A>
Oracleでは "Cross Join" を利用する。

select SEQ_MEMBER_SEQ_CACHE_BATCH.nextval from
(select * from dual union all ...(計10回))
, (select * from dual union all ...(計10回))
, (select * from dual union all ...(計10回))
...(実際ほしい行数より1桁多い行数になるまで繰り返す)
where rownum <= 実際ほしい行数

<B>
2,820ならキャッシュサイズとして十分ということで、
DBFluteの仕様としても制限とする。
(2000くらいで明示的な制限を掛けておく!?)

[懸念]
o "A" の案のSQLは、SQLの実行自体が遅くならないだろうか？
o そもそも、キャッシュサイズが大きすぎると、シーケンス取得の
速度にバラツキが発生してしまわないだろうか？
シーケンス取得SQL発行時だけ目立って遅いのはまずいかなと、
バッチならまだしもオンラインだと画面処理に影響しちゃう。

[考察]
懸念事項を考えると、そもそもキャッシュサイズに制限を
設けてもいいかなと思うのですが、どうでしょう？
あんまり、シーケンス発行時のSQLが重くなるのもよくないし、
キャッシュサイズ "100" から "1000" あたりでも、かなり
パフォーマンスは向上するかと。

batchInsert()の件は、キャッシュ機能のバッチ方式が
うまくいけば、必要性がなくなるかなぁと。

2010/1/24 awaawa <p1us3i...@gmail.com>:

[awaawa]

awaawaです。

ちょっと確かめてみました。
シーケンス10,000取得で、バッチ方式キャッシュサイズ2000で。
・unionで2000回の場合、初回約4000ミリ秒で2回目以降が約150ミリ秒
・単純結合(unionで10回を4回単純結合でrownum2000指定)の場合、初回約1200ミリ秒で2回目以降が約150ミリ秒
双方とも2回目はクエリの解析分のコストがかかっていないと思われます。
(実際はいろいろなクエリが実行されるので、キャッシュが使われることはまれかと)

> Oracleでもキャッシュサイズ "2000" で一秒半近く。
これは、マシンスペックの違いですかね。

> o "A" の案のSQLは、SQLの実行自体が遅くならないだろうか？
これは、おそらく上記から大丈夫かと。むしろクエリ解析分早い。

> o そもそも、キャッシュサイズが大きすぎると、シーケンス取得の
> 速度にバラツキが発生してしまわないだろうか？

これは確かにそうですね。

できれば、単純結合パターンにして、サイズは自己責任でいいかと。
SQL文のサイズ限界(?)が何か明確にわからないので。(DB仕様か、マシン依存か、設定依存か)
+ びっくりSQLが若干改善するかと。キャッシュサイズ "100" から "1000" あたりでも。
PostgreSQLも単純結合OK。H2もおそらく大丈夫かと。

いかがでしょうか。

> 2010/1/24 awaawa <p1us3inus2...@gmail.com>:

[kubo]

jfluteです。

とりあえず、cross join方式の方が、SQL自体が速いということで、
Oracleの場合に限り、そのようにしてみました。
PostgreSQLやH2の場合、dual表みたいなのが(多分)無さそうなのと、
そもそも問題にはなってないのでそのままです。
(Oracleだけの特殊処理という感じで扱っています)

あとキャッシュサイズの制限に関しては、ドキュメントに、
"大きすぎるとキャッシュ取得のSQLが目立って重いから厳重注意"
と、しっかり書くようにして、制限なしとしましょうかね。
(大きいサイズはドキュメント上のみの非推奨という感じで)

DBFluteランタイム: 0.9.6.4-12-SNAPSHOT

でお試し下さい。(モジュールはRC2のままで)
キャッシュサイズが小さいとき大きいときの
両方のテストお願いします。
(SQLの組立て処理が複雑になっているので)

2010/1/25 awaawa <p1us3i...@gmail.com>:

[kubo]

jfluteです。

"膨大なキャッシュサイズを制限していないこと"
というのもしっかりテストされるように、

モジュール・ランタイム共に "RC3" として公開しました。
(モジュールは、EMechaからダウンロード可能)

こちらでは "dbflute-oracle-example" にて、
キャッシュサイズ[8, 12, 10000, 10001]で試しました。
(コミットしているのは "12")

内部的な処理として、
SQLの組み立て時に、"cross join" された場合のレコード数
というのを計算するようにして、取得したシーケンス数に
達したら "dual" の追加をやめるようにしています。
なので、"10000" だったらジャストサイズになります。
その場合、実際にはrownumによる絞りがなくても大丈夫に
なります。(一応、一律条件は付与していますが)
"10001" だったら、"100000" ではなく "20000" レコードに
なります。という感じで、極力パフォーマンス劣化がない
ようにしていますが、100を超える指定をする場合は、
基本的には、100, 200, 1000, 2000, 5000, 10000
というように、キリの良いサイズがお奨めです。
(100以下はあまり気にする必要はないかと)

2010/1/25 kubo <dbf...@gmail.com>:

[awaawa]

awaawaです。

ご対応ありがとうございます。確認しました。

> 内部的な処理として、
> SQLの組み立て時に、"cross join" された場合のレコード数
> というのを計算するようにして、取得したシーケンス数に
> 達したら "dual" の追加をやめるようにしています。

さすがです。

検証続けますー

On 1月25日, 午後12:54, kubo <dbfl...@gmail.com> wrote:
> jfluteです。
>
> "膨大なキャッシュサイズを制限していないこと"
> というのもしっかりテストされるように、
>
> モジュール・ランタイム共に "RC3" として公開しました。
> (モジュールは、EMechaからダウンロード可能)
>
> こちらでは "dbflute-oracle-example" にて、
> キャッシュサイズ[8, 12, 10000, 10001]で試しました。
> (コミットしているのは "12")
>
> 内部的な処理として、
> SQLの組み立て時に、"cross join" された場合のレコード数
> というのを計算するようにして、取得したシーケンス数に
> 達したら "dual" の追加をやめるようにしています。
> なので、"10000" だったらジャストサイズになります。
> その場合、実際にはrownumによる絞りがなくても大丈夫に
> なります。(一応、一律条件は付与していますが)
> "10001" だったら、"100000" ではなく "20000" レコードに
> なります。という感じで、極力パフォーマンス劣化がない
> ようにしていますが、100を超える指定をする場合は、
> 基本的には、100, 200, 1000, 2000, 5000, 10000
> というように、キリの良いサイズがお奨めです。
> (100以下はあまり気にする必要はないかと)
>

> 2010/1/25 kubo <dbfl...@gmail.com>:

>
> > jfluteです。
>
> > とりあえず、cross join方式の方が、SQL自体が速いということで、
> > Oracleの場合に限り、そのようにしてみました。
> > PostgreSQLやH2の場合、dual表みたいなのが(多分)無さそうなのと、
> > そもそも問題にはなってないのでそのままです。
> > (Oracleだけの特殊処理という感じで扱っています)
>
> > あとキャッシュサイズの制限に関しては、ドキュメントに、
> > "大きすぎるとキャッシュ取得のSQLが目立って重いから厳重注意"
> > と、しっかり書くようにして、制限なしとしましょうかね。
> > (大きいサイズはドキュメント上のみの非推奨という感じで)
>
> > DBFluteランタイム: 0.9.6.4-12-SNAPSHOT
>
> > でお試し下さい。(モジュールはRC2のままで)
> > キャッシュサイズが小さいとき大きいときの
> > 両方のテストお願いします。
> > (SQLの組立て処理が複雑になっているので)
>

> > 2010/1/25 awaawa <p1us3inus2...@gmail.com>:

[jflute]

jfluteです。

今週末リリース(２月１日!?)を考えています。
とりあえずパフォーマンス検証は後追いでも
動作が問題なければいいかなと。

何か気付いたところ気になるところあれば言って下さい。

> ...
>
> もっと読む ≫

[awaawa]

awaawaです。

大変遅くなりましたー。検証しました!
(すいません、ちょっと忙しくて。できる範囲内でのご報告になりますが。)

> キャッシュサイズが小さいとき大きいときの
> 両方のテストお願いします。
> (SQLの組立て処理が複雑になっているので)
ばっちりOKでした。
SequenceCacheHandlerTest.test_filterNextValSql_half_Oracle()
をちょっと改良して、
String actual = handler.filterNextValSql(i, 1, sql);
String actual = handler.filterNextValSql(i, 2, sql); ※iは2の倍数
で10,000まで確認しました。(splitListでのサイズチェック)

あと、実際にデータ登録するパターンでいくつか確認しました。
3、45、89、99、100、101、199、200、201、900、901、999、1000、1001

パフォーマンス検証ですが、以前のキャッシュなしと比べると、
インクリメント方式、バッチ方式、複合どのパターンも約半分の時間で実行できました。
前提
・Oracle10gXE
・ログレベルはINFO
・登録データの作成からbatchInsertし終わるまでの時間を計測

1. キャッシュなし　　　　　　　-
2. インクリメント方式　　　　　dfcache(10,000)　incrementSize=10,000
3. バッチ方式　　　　　　　　　dfcache(10,000)
4. インクリメント・バッチ方式　dfcache(10,000)　incrementSize=100

10,000件
平均 1回目 2回目 3回目
1. 7.306 7.744 7.048 7.126
2. 2.849 2.941 2.973 2.634
3. 3.281 3.517 3.141 3.186
4. 2.707 2.985 2.581 2.555

20,000件
平均 1回目 2回目 3回目
1. 12.790 12.240 13.036 13.095
2. 5.489 6.194 5.147 5.127
3. 6.175 6.148 6.204 6.173
4. 4.992 4.947 5.055 4.975

30,000件
平均 1回目 2回目 3回目
1. 19.893 18.892 21.736 19.051
2. 7.916 7.490 8.866 7.392
3. 9.660 9.497 10.505 8.978
4. 8.177 8.506 8.736 7.288

> 今週末リリース(２月１日!?)を考えています。
そうしていただけるとありがたいです。

> ...
>
> もっと読む ≫

[kubo]

jfluteです。

おおお、ありがとうー

まずは動作確認ありがとう。
問題無さそうですね。

そしてパフォーマンス検証。
インクリメント方式が一番速いのはもちろんだけど、
バッチ方式でもしっかりとした改善があるようですね。
(よかった！価値がある！)

おかげでDBFluteが良い機能を身につけたよ。
ありがとう。今日の夜リリースします。

2010/1/31 awaawa <p1us3i...@gmail.com>:

> --
> このメールは Google グループのグループ「DBFluteユーザの集い」の登録者に送られています。
> このグループに投稿するには、dbf...@googlegroups.com にメールを送信してください。

[jflute]

jfluteです。

リリースしました。

そして、ブログにて貴重なコメント頂きました。
http://d.hatena.ne.jp/jflute/20100119#c1265014834

なんとOracleのシーケンスキャッシュのバッチ方式で、
一行のSQLで実現できてしまうようです。
無論、そのSQL自体のパフォーマンスやOracle9iでの動作、
あと、基本的にはawaawaさんのプロジェクトで採用された
その時点でのやり方を(最終仕様として)優先するつもりなので、
(まあ、まだアップグレードする時間的余裕あるならいいけど)
色々あるのですぐに反映というわけにはいきませんが、
少なくとも代替手段があるというのは安心です。

DB2は、やっぱりうまくできない...
(情報提供してもらったバッチ方式のSQL)
シーケンスを取得する場合は、もう "シーケンスを取得する"
こと以外は何もできない感じなのかなぁ...
まあ、いずれにせよもうちょい試行錯誤が必要ですね。

On 1月31日, 午前4:55, kubo <dbfl...@gmail.com> wrote:
> jfluteです。
>
> おおお、ありがとうー
>
> まずは動作確認ありがとう。
> 問題無さそうですね。
>
> そしてパフォーマンス検証。
> インクリメント方式が一番速いのはもちろんだけど、
> バッチ方式でもしっかりとした改善があるようですね。
> (よかった！価値がある！)
>
> おかげでDBFluteが良い機能を身につけたよ。
> ありがとう。今日の夜リリースします。
>

> 2010/1/31 awaawa <p1us3inus2...@gmail.com>:

> ...
>
> もっと読む ≫

[jflute]

jfluteです。

DB2はできるかも。

> ...
>
> もっと読む ≫

[jflute]

jfluteです。

> [Blogのコメントからの抜粋]
> awaawaさん
> 今回はリリースが近いので

参考までに、どのくらいの時期までならアップグレードできそうですか？？？
A. もう締め切り
B. 今週中までならなんとか
C. 来週くらいまでならなんとか
D. 再来週くらいまでならなんとか
E. 二月一杯までならなんとか

Oracle部分に変わりはないけど、SequenceCacheHandlerは
DB2の関連で修正されているので(リファクタリングも少し)、
なんとなくその修正後のやつで実績にしたいなぁと思ったり...

> ...
>
> もっと読む ≫

[awaawa]

awaawaです。

すいませんー。Aです。。。
0.9.4のパッチって形で今日、明日にご提供いただけるのであれば取り込めるかもですが。
(できれば、runtimeの修正のみで。)
ホントすいません!

で、以下「connect by」の検証結果です。

1. キャッシュなし　　　　　　　-
2. インクリメント方式　　　　　dfcache(10,000)　incrementSize=10,000
3. バッチ方式　　　　　　　　　dfcache(10,000)
4. インクリメント・バッチ方式　dfcache(10,000)　incrementSize=100

※1、2は前回と条件は同じですが、参考値として入れてあります。前回と環境は同じです。

若干union all、cross joinの方が早いかもって結果でした。(検証数が少ないのでまだなんともいえませんが)
20,000件と30,000件がほぼ同じ速度もしくは若干早いのはクエリキャッシュの影響もあるのかと。
時間あるときにもう少し正確に検証してみます。

10,000件
平均 1回目 2回目 3回目

1. 7.327 7.403 7.467 7.111
2. 2.826 2.920 2.893 2.666
3. 4.100 4.142 4.407 3.750
4. 2.784 2.841 2.947 2.565

20,000件
平均 1回目 2回目 3回目

1. 13.225 13.282 13.392 13.001
2. 5.168 5.580 4.956 4.968
3. 6.862 7.598 6.438 6.550
4. 4.907 4.989 4.824 4.907

30,000件
平均 1回目 2回目 3回目

1. 19.059 19.063 18.815 19.298
2. 7.407 7.439 7.322 7.460
3. 9.757 9.595 10.353 9.322
4. 7.743 7.158 8.183 7.889

> ...
>
> read more ≫

[kubo]

jfluteです。

了解です。
ランタイムだけの0.9.6.4.1とか今日出そうかとも思ったけど、
まあやっぱり、中途半端なのでやめておきますね。
Oracleの部分は何も変わってないし、Exampleで豪華なテストはあるし。

検証ありがとうございます。
特に遜色無く利用可能ということで
結論付けていいかなとは思います。
Oracleに関しては、0.9.6.4の時点のやり方
でいくことにしますね。

#
# とにもかくにもDB2でもできるようになったのは大きい
#

2010/2/2 awaawa <p1us3i...@gmail.com>:

[jflute]

jfluteです。

columnExceptListのスレッドってこれだっけかな？？？
まあ、いずれにせよ、

awaawaさん、
除外できるカラムをPK/FK/UQ以外のものに限定する予定です。
そっちで実際に使ってるんでしたっけ？
そういう仕様で問題はないですよね？？？
(つまり、PK/FK/UQのカラムは自動生成必須ということで)

あと、ReplaceSchemaでメインスキーマをFK参照する
サブスキーマをdropできるようにしました(0.9.6.5)。
スキーマ間でFK関係にあると片方のReplaceSchemaが
失敗してしまうので、そういう場合に対応しました。
(additionalDropMapListを利用します)
特にこの機能が欲しいとかあります？
(もしあれば、即リリースしちゃってもいいかなと)

On 2月2日, 午前8:53, kubo <dbfl...@gmail.com> wrote:
> jfluteです。
>
> 了解です。
> ランタイムだけの0.9.6.4.1とか今日出そうかとも思ったけど、
> まあやっぱり、中途半端なのでやめておきますね。
> Oracleの部分は何も変わってないし、Exampleで豪華なテストはあるし。
>
> 検証ありがとうございます。
> 特に遜色無く利用可能ということで
> 結論付けていいかなとは思います。
> Oracleに関しては、0.9.6.4の時点のやり方
> でいくことにしますね。
>
> #
> # とにもかくにもDB2でもできるようになったのは大きい
> #
>

> 2010/2/2 awaawa <p1us3inus2...@gmail.com>:

[awaawa]

> ランタイムだけの0.9.6.4.1とか今日出そうかとも思ったけど、
> まあやっぱり、中途半端なのでやめておきますね。
> Oracleに関しては、0.9.6.4の時点のやり方
もろもろ了解です!!

> columnExceptListのスレッドってこれだっけかな？？？
そうです。
除外できるカラムはPK/FK/UQ以外のもので問題ないと思います。
※もしかしたらUQ除外したいとかあるかもですが、
　複数UQで一部除外とか考えると、キリがないので。

> ReplaceSchemaでメインスキーマをFK参照する
> サブスキーマをdropできるようにしました(0.9.6.5)。
おー、ReplaceSchemaさらにパワーアップですね!
今はそのパターンはないので大丈夫です。
ご配慮ありがとうございます!

> ...
>
> もっと読む ≫- 引用テキストを表示しない -
>
> - 引用テキストを表示 -

[kubo]

jfluteです。

awaawaさん、ありがとう。
とりあえず大丈夫そうということで、
0.9.6.4で頑張って下さい。

#
# dbflute-oracle-exampleで、
# additionalDropMapListを実際に使ってるので、
# 気の向いたときにでも参考まで見てみて下さい。
# (nextexampledb側でexampledbをdropしています)
#

2010/2/3 awaawa <p1us3i...@gmail.com>: