DB Magazine 2008/2 を読みました

こないだもちょっとだけ紹介しましたが、
一通り読みおわりました。

DB Magazine (マガジン) 2008年 02月号 [雑誌]
http://www.amazon.co.jp/DB-Magazine-%E3%83%9E%E3%82%AC%E3%82%B8%E3%83%B3-2008%E5%B9%B4-02%E6%9C%88%E5%8F%B7/dp/B0010VFVWU/ref=sr_1_1?ie=UTF8&s=books&qid=1219553257&sr=1-1


特集２：リクルート「R25」に学ぶpostgres活用
これかなり勉強になりました。
実はリクルートではOracle9i→PostgreSQL8.1という移行を行っており、
それに伴うOracleとPostgresの違い、コマンド比較表、移行の注意点などが
事細かく記載されていました。

Postgresはやはりオープンソースということもあり、
痒い所に手が届かないところもあります。
しかしそこは自前でスクリプトを作ったりサードパーティのツール使ったり
キャッシュをうまく使ったりサーバ構成を考えたりと、
工夫すればOracleなどの商用DBに見劣りしないくらいの
パフォーマンスを出すことができます。

それら工夫するための手段がこの特集では記載されています。
特に監視系の記事は目からウロコでした。

私もOracleからPostgresへ業務が変わった事もありますので
知りたかったことが満載！
OracleもPostgresも触っているエンジニアは必見だと思います。



ところで私もPostgresを触って数ヶ月。
多少見えてきた所もありますので
Oracleと比較してPostgresの良い点・いまいち点を挙げてみます。

【良い点】
・オープンソースである。
→これに尽きます。
　無料ということももちろんありますが、
　ソースも公開されているので内部で何をやっているかがわかってしまう所も
　ポイント高です。（私はまだ見れるレベルではないですが）
・Oracleと似ている（と言われているらしい）
→たしかに自分も使ってみてOracleと似ている所は多いなーと思いました。
　PL/pgSQLもそうですし、ecpg（C埋め込み）も違和感なく使えました。
・データ型が豊富
→point、polygonなどの幾何データ型、IPアドレスなどのネットワーク型、列に配列を定義できる配列型、XMLを格納するXML型、8.3から使えるようになったenum型など盛りだくさん！使い切れん…

【いまいち点】
・公式サポートがない
→やはりこれが一番大きいです。
　メーリングリストはありますが、公式ではないので解決できるとも限らないですし…。
・監視ツールがない
→「ない」というのは言いすぎかもしれません。
　上記にも書いてますが、contribや自前スクリプトでなんとかなる部分です。
・グループ関数のネストが出来ない
→count(count(*))とかOracleでよく使ってたのに、使えない。
・pl/pgsqlではファイル操作が出来ない。
→らしい。知ってる方がいたら教えて下さい…
・文字列型はTEXTで事足りる。
→TEXT型って文字数制限のない文字列型なのですが、charやvarcharも内部的にTEXTにキャストされるので
　基本的にはTEXT型を使っていればいいらしい。
　元Oracle使いとしては非常に気持ち悪い。
・VACUUMがうざい
→VACUUMというコマンドを定期的に発行しなければいけないのは
　Postgresの宿命らしい。まあこれは慣れればなんとか。
・オンラインREINDEXができない。
→こないだ気付きました。REINDEXをしている間
　「そのインデックスを使用する問い合わせは全て読み取り待ちになってしまう」。
　これは色々考える必要がありそうだ。



いまいち点が多いですねｗ

DBMSとして問題があるわけではないけど不親切というか。
今の時点では
Oracle8i＝Postgres8.?
というイメージかな。

深い部分までやったときにまた違う感想が出てくると思うので
またその時にでも。


来月中にはこれをマスターする予定です！

PC UNIXユーザのためのPostgreSQL完全攻略ガイド―豊富な機能と高い信頼性を誇るオープンソースデータベース
http://www.amazon.co.jp/PC-UNIX%E3%83%A6%E3%83%BC%E3%82%B6%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AEPostgreSQL%E5%AE%8C%E5%85%A8%E6%94%BB%E7%95%A5%E3%82%AC%E3%82%A4%E3%83%89%E2%80%95%E8%B1%8A%E5%AF%8C%E3%81%AA%E6%A9%9F%E8%83%BD%E3%81%A8%E9%AB%98%E3%81%84%E4%BF%A1%E9%A0%BC%E6%80%A7%E3%82%92%E8%AA%87%E3%82%8B%E3%82%AA%E3%83%BC%E3%83%97%E3%83%B3%E3%82%BD%E3%83%BC%E3%82%B9%E3%83%87%E3%83%BC%E3%82%BF%E3%83%99%E3%83%BC%E3%82%B9-%E7%9F%B3%E4%BA%95-%E9%81%94%E5%A4%AB/dp/477412687X/ref=sr_1_5?ie=UTF8&s=books&qid=1219553328&sr=1-5

postgresを本気で勉強

現在構築中システムのバックエンド側の処理について、
だいたい目処が付いてきました。
ですが、現在のままだと本来出て欲しいパフォーマンスまで
達していないんですよね。

ハードの性能を上げたり、ミドルウェアを使ったりという方法もありますが、
もちろんそれは最後の最後に考える手法。
とりあえずはバッチ処理のロジックとDB側のチューニングを
最大限まで引き出したいと考えました。

しかもテーブルの見積もりを取ったところ、
一番大きいテーブルになると１億件近くのBIGテーブルになりそう！
これらをうまく分散させる方法も考えないとならないですし...

さらに、Oracleのチューニングならまだしも
Postgresは全然未熟。
これは本気でPostgresの勉強をする時が来たようです。

まあ転職してからPostgresも結構触りましたが、
わりかし好きになってきましたよ。
データ型とか多彩で面白いですし、
パフォーマンスも全然商用DBに負けていませんしね。


というわけで、本日書籍を購入すべく
ジュンク堂池袋店に行ってきました。
以下は検討した３冊。

①
PostgreSQL完全機能リファレンス―実行例を通して「理解」を深める
http://www.amazon.co.jp/PostgreSQL%E5%AE%8C%E5%85%A8%E6%A9%9F%E8%83%BD%E3%83%AA%E3%83%95%E3%82%A1%E3%83%AC%E3%83%B3%E3%82%B9%E2%80%95%E5%AE%9F%E8%A1%8C%E4%BE%8B%E3%82%92%E9%80%9A%E3%81%97%E3%81%A6%E3%80%8C%E7%90%86%E8%A7%A3%E3%80%8D%E3%82%92%E6%B7%B1%E3%82%81%E3%82%8B%E3%80%82-%E9%88%B4%E6%9C%A8-%E5%95%93%E4%BF%AE/dp/4798014958/ref=sr_1_1?ie=UTF8&s=books&qid=1219553644&sr=1-1

②
PostgreSQL徹底入門 第2版
http://www.amazon.co.jp/PostgreSQL%E5%BE%B9%E5%BA%95%E5%85%A5%E9%96%80-%E7%AC%AC2%E7%89%88-%E6%B5%85%E7%BE%BD-%E7%BE%A9%E4%B9%8B/dp/4798115053/ref=sr_1_1?ie=UTF8&s=books&qid=1219553617&sr=1-1

最近出たばかりのPostgres8.3に対応した書籍です。
現在のバージョンはPostgres8.3.1を使用しているので重宝しそうです。


③
PC UNIXユーザのためのPostgreSQL完全攻略ガイド―豊富な機能と高い信頼性を誇るオープンソースデータベース
http://www.amazon.co.jp/PC-UNIX%E3%83%A6%E3%83%BC%E3%82%B6%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AEPostgreSQL%E5%AE%8C%E5%85%A8%E6%94%BB%E7%95%A5%E3%82%AC%E3%82%A4%E3%83%89%E2%80%95%E8%B1%8A%E5%AF%8C%E3%81%AA%E6%A9%9F%E8%83%BD%E3%81%A8%E9%AB%98%E3%81%84%E4%BF%A1%E9%A0%BC%E6%80%A7%E3%82%92%E8%AA%87%E3%82%8B%E3%82%AA%E3%83%BC%E3%83%97%E3%83%B3%E3%82%BD%E3%83%BC%E3%82%B9%E3%83%87%E3%83%BC%E3%82%BF%E3%83%99%E3%83%BC%E3%82%B9-%E7%9F%B3%E4%BA%95-%E9%81%94%E5%A4%AB/dp/477412687X/ref=sr_1_5?ie=UTF8&s=books&qid=1219553328&sr=1-5

定番らしいです。
初版はおよそ10年前で、現在は5版となっています。


②の8.3対応本は入門編ということもあり、
あまり内容的に濃いとは言えませんでしたので今回は却下。

①と③で悩んだのですが、結局③を購入しました。
定番本ということもありますが、一番の決め手となったのは
パフォーマンスチューニングについての説明が充実してそうだったからです。
そこが一番知りたい所ですしねｗ


あと、DBマガジンのバックナンバーも置いていたので
Postgresの情報ないかなーと探していたところ、
良いのを見つけました。

http://www.amazon.co.jp/DB-Magazine-%E3%83%9E%E3%82%AC%E3%82%B8%E3%83%B3-2008%E5%B9%B4-02%E6%9C%88%E5%8F%B7/dp/B0010VFVWU/ref=sr_1_1?ie=UTF8&s=books&qid=1219553692&sr=1-1

【特集】リクルート「R25」に学ぶPostgreSQL活用
R25のサイトは月間1.5億PVのデータを
Postgresで運用しているそうです。
コレはかなり参考になりそう！
早く読みきりたいなー

システムの信頼性とか

今のうちのシステムは常時稼動が必須。
24時間サービスを提供し続ける必要があります。

その目的を果たすために
いろいろと負荷分散・冗長化を試みてるわけですが
そううまい事いかない訳でして。
こないだも１時間ほど停止してしまいました
（俺のせいじゃないですよ！）


しかもボトルネックはDBサーバなんですよ。
４台（×２）に負荷分散してるにもかかわらずこの有様。
たしかにDBへの問い合わせ数が異常に多いシステムなので
仕方ないんでしょうけど。
自分自身、こんなにリクエスト数が多いシステムは
経験してないのでアドバイスも出来ません。

しかし、まあ落ちるのはしょうがないにしても
すぐに復旧できるシステム構成になってなかったのは
良くなかった。
やっぱりこういう常時稼動のシステムの場合、
「いかにサーバを落ちにくくするか」よりも
「いかにすぐに復旧するか」を最優先して考えるべきですね。
MTTR（平均修理時間）を短くすると。
だって落ちちゃうときは落ちちゃいますから。

何十分もシステムが停止して、
その間クライアントに影響を及ぼしてしまうのは
システムとして不完全と言わざるを得ない。


実はDBクラスタリングも行っていましたが
それもうまくいかなかったんですよね。

ということは、もう「システム自体を冗長化」するしかないかなと。
DBサーバのレプリケーションを自前で行う感じですね。
…といったことも提案してみようかな。



しかしまあ今回の一件でpostgresの事も
勉強しなきゃいかんなーと思いました。
だって内部構造が全然わからんもん。
そうすれば今の環境で出来ることが見えてくると思うし。
そして何だかんだでOracleは偉大なんだということもわかりました。
やっぱOracleやりたいなー。

なんだかもっとシステムの事もDBの事もOracleの事も
勉強したくなってきました。
資格に対しても今までと違って
「一応取っておこうかな」というスタンスではなく
「本当に身になる勉強がしたい」という気になってきた。
とりあえず11g移行試験が出来たら取得しようかな。

みなさんも、一つのDBに固執するのではなく
いろんなDBに触ってみて欲しいです。
それで見えるてくる事ってすごく大きいと思いますよ。

column "aaa" does not exist

postgresで新規にテーブル作ってselectした時のこと。


普通に

select * from テーブル名;

でやると表示されるのですが、

select 列名 from テーブル名;

とすると
「column "列名" does not exist」
というエラーが出てしまう。

なんで？（・ω・）？


エラーの内容は「そんな列ありませんよ」というごくごく普通のメッセージ。
もちろん、列名は絶対に間違ってはいない。
\\d で列名表示してそれをコピペしてもエラーになる。

なんで？（・ω・）？


意味がわからないながらも
いろいろと試してみた結果
create文に原因がありました。

create table my_table
("COL1" text ,
"COL2" text,
…,
);

このように、「""で囲って、かつ大文字」で定義したときに起こる現象の様子。
列名を小文字にしたらエラーは発生しなくなりました。
なんじゃそら。
しかもpgAdminで生成されるSQL文で発生してます。
なんじゃそら。

これはわけがわからんなぁ

Postgresqlのバックアップ・リストア

PostgresでOracleのSQL*Loaderみたいなのないかな～と思い
調べてみました。

■COPYコマンド（psqlで実行）
・テーブルにインポート
　copy テーブル名 from 'ファイル名' using delimiters 't';
・テーブルをエクスポート
　copy テーブル名 to ～

■pg_dumpコマンド（バイナリ？）
これはあんまり詳しく調べてませんが、
Oracleのimp/expみたいにバイナリ形式で行うものですかね？
「pg_dump」「pg_restore」コマンドを使用するようです。



ただ、COPYコマンドはコントロールファイル未使用なんですよね。
これだとインポートするファイルの形式を
テーブルと完全に一致させないとエラーになっちゃうんです。
定義ファイル使う方法無いのかなー？