- PR -

巨大なテーブルの結合、業務アプリの統合

«前のページへ 1|2
投稿者投稿内容
未記入
会議室デビュー日: 2004/09/12
投稿数: 5
投稿日時: 2004-09-13 19:31
引用:

VACUUMが終わらなかったので、この方法しかありませんでした。

うわっ。ｷﾓｲ、ｷﾓｽｷﾞﾙ言い訳だ。あのなあ、PostgreSQL使うんだったら、
そこらのOracle選択する以上にスケラービリティ評価に慎重でなくちゃならないの。
データベースもまともに選定できないから、そーゆーアホ設計になるんだろ。
まったくｷﾓすぎる言い訳ちゃんだなー。

引用:

設計的にはそりゃー１テーブルが理想ですが、性能的にはムダです。

いや、OLTPを当年前年とかに限定するのであれば一切性能低下しないよ？
性能的にはムダって言うか、お前がもらってるお金が顧客にとってムダだよ。
ＹＯＵ＠ＩＴ
ぬし
会議室デビュー日: 2002/03/29
投稿数: 284
お住まい・勤務地: 大阪
投稿日時: 2004-09-13 22:28
引用:

未記入さんの書き込み (2004-09-13 19:31) より:
引用:

VACUUMが終わらなかったので、この方法しかありませんでした。

うわっ。ｷﾓｲ、ｷﾓｽｷﾞﾙ言い訳だ。あのなあ、PostgreSQL使うんだったら、
そこらのOracle選択する以上にスケラービリティ評価に慎重でなくちゃならないの。
データベースもまともに選定できないから、そーゆーアホ設計になるんだろ。
まったくｷﾓすぎる言い訳ちゃんだなー。

引用:

設計的にはそりゃー１テーブルが理想ですが、性能的にはムダです。

いや、OLTPを当年前年とかに限定するのであれば一切性能低下しないよ？
性能的にはムダって言うか、お前がもらってるお金が顧客にとってムダだよ。


結局何が言いたいのかさっぱりわかりませんな。
質問者を侮辱したいだけなら投稿しないでもらいたいですね。
読んでいる第三者が不愉快です。

CHN
ぬし
会議室デビュー日: 2002/03/07
投稿数: 382
投稿日時: 2004-09-13 22:35
引用:

ＹＯＵ＠ＩＴさんの書き込み (2004-09-13 22:28) より:
結局何が言いたいのかさっぱりわかりませんな。
質問者を侮辱したいだけなら投稿しないでもらいたいですね。
読んでいる第三者が不愉快です。

おっと、いけませんよ、相手にしてはいけません！！
待ってるんですから、チャンス？を。
分かりますよね、言いたいこと＞ＹＯＵ＠ＩＴさん

_________________
猫山みやお
大ベテラン
会議室デビュー日: 2004/09/09
投稿数: 119
投稿日時: 2004-09-13 22:52
最近荒らしが多いな
iakio
会議室デビュー日: 2002/11/28
投稿数: 13
投稿日時: 2004-09-13 23:20
私も似たような状況になれば、テーブルを2つに分けるという方法を試すと思います。
正直、どのようなクエリーを実行しているのかとか、シーケンススキャンがどれくらい
発生しているのかとか、キャッシュのヒット率とかを見ないと、何がベストな方法かは
判断つかないとは思います。まずはいかにシーケンシャルスキャンを防ぐかだと
思います。

コンカレントvacuumは、ゴミ領域を再利用可能にするものです。これはデータの操作
をロックしないので、1時間に一回とか、頻繁にやったほうがよいでしょう。
頻繁にやったほうが一回にかかる時間は短いです。
vacuum fullはゴミ領域を削除するものです。バッチ処理による大量のデータ更新
などを行ったときだけやるのがよいと思います。

あと、ちょっと古いですが、
http://www.postgresql.jp/misc/seminar/2003-05-17/
この辺の資料も何か参考になるかもしれません。(A-2)が
似たようなことをしてます。
おばけ
ぬし
会議室デビュー日: 2002/11/14
投稿数: 609
お住まい・勤務地: 東京都江東区
投稿日時: 2004-09-13 23:59
引用:

Oracle の Partitioning Option は、上記１）に考え方は近いものと思います。

OracleのPartitioningを検討したことがあるんですが、エッライ高かったですよ。
確か10Mくらいしました。だから、おいそれと導入できるオプションでは無いかと
思ってしまいます。

# 本題からはそれてしまいますが
taku
ぬし
会議室デビュー日: 2002/11/12
投稿数: 918
お住まい・勤務地: 墨田区→中野区
投稿日時: 2004-09-14 09:53
引用:

彷徨える開発者さんの書き込み (2004-09-13 18:01) より:
テーブルスペース(Oracleにもあったような・・・)という概念はありません。

　だったら、単純に、過去データが入っているＤＢと、
現在のデータが入っているＤＢとを分けて、
アプリケーションも、
各々のＤＢを参照するようにするだけで、
良い気がするのですが・・・。
これなら、特に特別なテストする必要もないので、
対して工数もかかりませんし。

　「１年経過分は無いと困るが、さほど頻繁に使うものでもない」
って程度なら、これで良い気がします。
ＹＯＵ＠ＩＴ
ぬし
会議室デビュー日: 2002/03/29
投稿数: 284
お住まい・勤務地: 大阪
投稿日時: 2004-09-14 13:53
引用:

CHNさんの書き込み (2004-09-13 22:35) より:
おっと、いけませんよ、相手にしてはいけません！！
待ってるんですから、チャンス？を。
分かりますよね、言いたいこと＞ＹＯＵ＠ＩＴさん


す、すみません、ちょっと度が過ぎていると感じたものでつい反応してしまいました。

«前のページへ 1|2

スキルアップ／キャリアアップ（JOB@IT）