ASARI Takashi
asari****@users*****
2008年 1月 18日 (金) 21:26:48 JST
浅利です。 ご対応ありがとうございます。 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/
