[pgsql-jp: 33117] Re: PostgreSQL カンファレンスお礼および MySQL のデータが壊れる件

[Hidekazu Ikeda]

池田です。

> PostgreSQLのファイル編成については、まああんなものなんじゃないかと思いま
> す。１ファイル１テーブルなので、ファイル内の配置状況などもそれほど悩む必
> 要がありません。これはシンプルな実装として評価できると思います。

　判りやすいのが利点ですね。
　これは、商用DBMS でもありました。

　もっとシンプルなのが、Informix の古い形態ですね。
　全部が１つのファイルでできていた（笑）

> 一方で弱点は、大量のテーブルに対峙した場合に大量のシステムリソースを食う
> ところ、またシステムリソース自体もテーブルとして管理しているため、システ
> ムリソースの肥大による検索性能の低下がボトルネックになりかねない点です。

　もう１つ上げると、

　テーブル間の関連情報を、DBMS として維持していない
と言うのが上げられます。

　商用DBMS 製品では、関連するテーブル群を１まとめに
する（Oracle なら tablespace、SQL Serever なら DB）
ことができ、その単位での保守（バックアップ、リカバー）
が判りやすく、やりやすいです。

> 実際、万単位で大量にテーブルを作ると、大きなパフォーマンス低下が発生しま
> す。これは実際あまり知られていないのか、ここを指摘してくる人はほとんどい
> ません。

　知っていても、、その分野で競合しないので（爆）

　それ以前に、大規模だと比較から落ちてるのが現状かと。
　レプリケーションや、クラスタ、共有ディスクを利用する
場合での実績など、などで厳しいと思いますが。
　まず、サーバのハードウェア企業が実績持ってないので。

> ＃こういうと、某社がきっと「うちなら数百万でも大丈夫」とか大々的に
> ＃宣伝しだすんだろうなぁ:-D

　DBMS の専門企業を舐めちゃいけませんよ :-p


> こういう点から、現在のストレージ関係の実装は、極端に多くないテーブル数に
> 最適化した、シンプルで明快な実装であると私は考えます。

　ストレージ関係に関しては、OSS で強化を頑張るよりも
PowerGres で、Symfoware(旧RDB2）を取り込んでるように
感じるのが惜しいかな。


ではでは。
-- 
--------------------------------------------------
 Hidekazu Ikeda 　池田　秀一
    E-mail:ikeda ＠ miraclelinux.com
    TEL 03-5562-8300   FAX 03-5562-8306
    http://www.miraclelinux.com/
--------------------------------------------------