nagatsuma satoshi
nagat****@gmail*****
2008年 1月 20日 (日) 22:19:13 JST
長妻です。
> 全文検索を行ったインスタンスと SELECT pgs2getnhits() を実行する
> インスタンスが異なってしまうこともあるかもしれないな、と思ったりしました。
うっ、言われてみればそうですね・・・
今手元に試せる環境がないのですぐには何とも言えませんが、原理的には
そういう動作になる気がします。もしそうだとするなら回避方法としては、
Forestの負荷分散動作をラウンドロビン方式ではなく、コネクションごとに
インスタンス振り分けする方式に変えてあげればうまくいくように思えます。
> あまり関係ない話題ですが、パーティションのキーになる文字列が
> 2007001110000000 のような長い数字の列でしたので、
> Long.parseLong(aString) するようなハッシュ関数があると便利かなあ、
> などと思いながら Forest の配置関数のソースを眺めてみたことがあります。
> 結局 Long.parseLong() よりも String#hashCode() のほうがずっと高速というオチでした。
確かに、配置関数に渡った時点でStringインスタンスが生成されているとしたら
その段階でhashCode値は生成済みですからね。Long.parseLongはパースという
重い処理が入るので圧倒的にパフォーマンスは悪そうですね・・・。
> ただ、僭越ながら、当面は無理なものは無理ということで放置して、
> ドキュメントなど全体の完成度を高めつつユーザー数を増やしていく
> 方向性も重視なさっては、とも思います。
> 個人的には、パーティション(2)での制限事項リストとか…。
ごもっともです(^^;
今のところ、そういった方針で少しずつやっている感じです。
開発関係でいうと、レプリケーションテーブルをメインに、周辺ツールの
ユーザビリティ向上であったり、JDBCのメッセージ品質向上などなど。
ドキュメント類ではマニュアルの拡充、制限事項リストやAPIの対応状況等
といったあたりをチマチマと進めています。
いろいろとやりたいこと、やるべきことはあるものの、開発メンバーが
その他の仕事で忙しかったり・・・なかなか余力がなく悩ましい状況です。
そういった意味でも
> と、いうことで、私も何か例えば PHP で使うための howto みたいなものを
> 書いて貢献できればいいのですが…。うむむ。
期待してます！（笑）
こんな改善案はどう？というような案やら意見やら
（あるいはこんな実装やら改造やらしちゃったんですが・・・なんて話でも）
情報共有できるとよいですね。
> 浅利です。
> ご対応ありがとうございます。
>
> 08/01/18 に Satoshi.Nagatsuma<nagat****@nttda*****> さんは書きました:
> > ですので、ちょっとトリッキーな書き方になってしまいますが・・・。
> >
> > for(台数分) {
> > rs = stmt.executeQuery("select pgs2getnhits()");
> > rs.next();
> > count += rs.getInt(1);
> > }
> >
> > という感じで全PostgreSQLインスタンスから結果を集約できるはずです。
>
> な、なるほど！ お教えいただき、ありがとうございます。
> これなら簡単にできますね。
>
> 全ノードに同じ内容のクエリを投げて結果の UNION を得るための
> キーワード (PASSTHROUGH SELECT ... とか?) を PostgresForest の
> パーサに追加して… などと考えたりもしていましたが、
> これはそんな大げさなこともなく、よさそうです。
>
> > 実はレプリケーション（多重化）テーブルの場合、この問題は起きません。
> > 全てのPostgreSQLインスタンスで内容が同じなので、どのインスタンスで
> > クエリを実行したとしても得られる結果は同じだからです。
>
> なるほど。
> 全文検索を行ったインスタンスと SELECT pgs2getnhits() を実行する
> インスタンスが異なってしまうこともあるかもしれないな、と思ったりしました。
>
> > 推奨する使い方ではないですが、最初からどのデータがどのパーティションに
> > 含まれるかわかっていて、なおかつ初期データを投入する状況に限っていえば、
> > 事前に何らかの方法でデータを各パーティションの内容ごとに分割しておき、
> > psqlで直接各パーティションテーブルに投入するという方法もありますね。
> > （試してみる or ソースを見てみればわかりますが、
> > Forestデフォルトの配置関数は、配置属性のHash値で分割しています）
>
> まさにそのようなことを想像していました。
>
> あまり関係ない話題ですが、パーティションのキーになる文字列が
> 2007001110000000 のような長い数字の列でしたので、
> Long.parseLong(aString) するようなハッシュ関数があると便利かなあ、
> などと思いながら Forest の配置関数のソースを眺めてみたことがあります。
> 結局 Long.parseLong() よりも String#hashCode() のほうがずっと高速というオチでした。
>
> > > フロントエンドの開発は PHP を主に使っていますので、
> > > PHP/Java Bridge (http://php-java-bridge.sourceforge.net/) を試しています。
> > > 今のところ、 Tomcat を経由して PHP で無事に PostgresForest を使えています。
> >
> > PHPとJavaのブリッジの存在は認識していましたが、なかなか手を出せる時間がなく
> > ずっと放置していました。これは貴重な動作報告ですね！ありがとうございます。
>
> そんな私もPostgresForest開発日記を読んで試してみようと思いました！
>
> > パーティション化2は柔軟性に富みすぎていて、そのせいで色々と扱いづらい
> > 部分も多々ありますが、それだけに面白い（まだまだ改善のし甲斐がある）
> > ところです。なんとかもっと使いやすくしていきたいところですね。。。
>
> 期待しております！
>
> ただ、僭越ながら、当面は無理なものは無理ということで放置して、
> ドキュメントなど全体の完成度を高めつつユーザー数を増やしていく
> 方向性も重視なさっては、とも思います。
> 個人的には、パーティション(2)での制限事項リストとか…。
>
> 全体的にユーザが増えてきて、「試してみました！」のような報告を
> カジュアルなユーザーがブログに書くようになってくれば、
> OSS ならではの盛り上がりもでてくるんじゃないでしょうか。
>
> と、いうことで、私も何か例えば PHP で使うための howto みたいなものを
> 書いて貢献できればいいのですが…。うむむ。
>
> --
> ASARI Takashi @ Todai Fink Team
> http://fink.sodan.ecc.u-tokyo.ac.jp/