『Linux-DB システム 構築/運用入門』を読んだ (3)
最近 MySQL まわりで困ることが多くなってきたので、kazuhoのメモ置き場 や blog.nomadscafe.jp で勧められていた『Linux-DB システム 構築/運用入門』を読んだ。
本書がカバーする範囲は広い。実際に私がさわる場所は7, 8, 9章の memcached やアプリケーションパーティショニング、インデックス、そして14章の負荷テストのあたりだけだ。でも、その前の章で出てくる DRBD やロードバランサは、自分がさわる場所の前後左右に、後の章に出てくるファイルシステムやスケジューラは、これも自分がさわる場所の下にあるわけで、知っておくべきだしわかるのは楽しい。
いろいろハイテクもあったので、実験用に自宅 Linux サーバーでもたてようかと少し思った。8-p.info も Debian GNU/Linux で動いてはいるけど、これは Slicehost という海外の VPS だからか、コマンドを打ち込んだりするにはネットワーク的に遠くて遅い。
抽象化
例えばハードディスクというのは通電していなくてもデータが消えない回転する円盤で、それを抽象化してファイルシステムがあり、さらに抽象化した上には RDBMS がある。その上でアプリケーションを書いている人が「ランダムリードはシークが」とかいうのは変な気もするけど、下では相変わらず円盤が回転して、遅かったり速かったりするんだからしょうがない。
『Joel on Software』にはここらへんをあつかった「漏れのある抽象化の法則」という章があり、こう書いてあった。
そういうわけで、抽象化は私たちが作業する時間を減らしてはくれるが、私たちが学ぶ時間までは節約してくれないのだ。
確かに、このくらいの割り切ったつきあいが良い気はします。
基本的には、ＳＱＬは集合に対する宣言なので、
オプティマイザ層なりエスティメイタが適切にすべてを挙動させるべきなんだけど
アプリケーションとしてのデータのカーディナリティなどに関しての知識はアプリケーションプログラマのほうが持っているので、
どのような実行計画が適切なのかという判断はアプリケーションプログラマができるべきであるべきだとは思う。
「べき」は難しいなあ。抽象化レイヤは漏れの無いようにしたいし、プログラマは全部を知っててほしい。
現実の問題としては、抽象化に漏れがあったときにおこることが厳しすぎるので、そこらへんなんとかしたいですね。例外つかむことなり、止まらないで遅れるだけにするなり。
“基本的には”ね。
たとえばＳＳＤになったくらいで、ＳＱＬ文を変える必要があるアーキテクチャは不思議な気がする。
現実的には、抽象化の漏れはあり続けるので、
最近はapacheやperl5vmも勉強してます。
でも全員が知る必要はないはず。それが技術だし。DBAが要求されるスペックに対して答えられる手段を提供できればいい。