2009年02月

前作


PostgreSQLを本当に高速化したい人のための10のポイント


が結構受けたようなのと、外部ツールの話が書ききれなかったので次回作を。まあこっちは受けないと思うが、ついでに備忘録をかねて。内容としては「RDBMSだけ使ってもどうしようもないよね」というのは多い。しかし残念ながらL.starは、PostgreSQL本体に比べてこの種のツールの組み合わせについて精通しているとはいいがたい。なので、「PostgreSQLとしては、こんな部分は外部ツールに任せたいよね!」という思いをまとめるように書いてみた。

外部キャッシュ


最近のRDBMSはとても早くて、シンプルなselect * from table where id=? ぐらいだと、10000tps位平然とこなしちゃう。このくらい早いと、web server数台分ぐらいのバックエンドになれるので、それで十分ではないかすら思ってしまうだろう。しかし実際は、超大規模を想定するとまったくお話しにならない。slashdottedするような負荷は、web数台+DB1台では現実問題として到底捌ききれない。

また、スループットの話だけなら上記で良いが、同時にレイテンシの話もしないといけない。実はRDBMSはトランザクション管理がからむため、結構レイテンシが高い。どちらかというと中スループット、高レイテンシ、高耐障害性のソフトウェアになる。

だから、高スループット、低レイテンシ、低耐障害性なキャッシュ用オンメモリDBと組み合わせるのがよい。こいつらが捌けるスループットは一桁違う。そして、単純なkey-valueストアであるためもともとレイテンシも低く、かつ分散もきわめて容易である。最近このような形態をサポートできるフレームワークが増えているようだ。

ここらで一つ、PostgreSQLプロトコルを使い、外部にオンメモリキャッシュを作って、このツールを経由してクエリを発行したら、自動的にキャッシュに問い合わせて返す or 返答をキャッシュしつつ返すと言う動作をするproxyを作ったら受けるだろうか?

コネクションプーリング


1-Mar-2009追記:よく分からないという指摘を受けIRCで追加説明をした。それを元に修正しようとしたら、pg_pconnectその後というところで綺麗に3行でまとめられていた。なので、以下は技術的詳細について色々書いてあるが、結論が欲しい人はそのまま上記に行って欲しい。

PostgreSQLの場合、泣き所はfork()を使ってセッションを受けているところである。これにはいくつかのメリット(ここでは割愛)と2つのデメリットがある。一つはfork()がコストの高いAPIであるため、接続確立のためのコストが大きいこと。もう一つはプロセスというのがコストの高い資源であるため、たくさん生成すると重くなってしまうことにある。

前者については、実は(スレッドを使う)MySQLよりも早いと言うデータを見たことがあるので、必ずしも今となっては当てはまらない部分がある。ただし、後者は切実である。普通、2000プロセスも立ち上げるとLinuxが(もしLinux以外でPostgreSQL2000接続以上しても平気なOSがあったら、是非教えて欲しい。)管理できない。そして実質サービスダウンに等しい状態に追い込まれる。そして、接続をしていると、検索している居ないにかかわらずプロセスがいるのである。

pg_pconnectに気をつけろ!


では、この後者の点を指摘している。pg_pconnectは前者の解決策を提供しているが、後者については考えもしないろくでもない代物である。安直な大量コネクション確保は性能劣化の原因になりかねない、と心しておくべきだろう。PostgreSQLの場合、昔は目安として256接続がこの重さに引っかかる境目だった。最近のPCではまた違う結果かもしれない。


などと下書きをしているうちに


pg_pconnectに気をつけろという話に気をつけるべき理由


という対立エントリが出ている。前半の話は「負荷が下がるとプロセスも減る」という話だが、問題は負荷が高い状況の話であるため何ら議論の本質とは関係がない。




pg_pconnect使うと障害対応で人間やめることになるよなどという意味不明な極論ではなくて、例えば「PHPスクリプトを動かすhttpdと画像やCSSを送り出すhttpdは別にしよう」ということだ。



というのは正論ではある。しかし、その後でPHPスクリプトが動いているhttpdの性能が逼迫したとき「DB接続を伴うphpスクリプトとそれ以外のスクリプトを動かすhttpdを分けよう」言い出すのだろうか。


Javaのコネクションプーリング(あるいは相当品)は比較的しっかりしているので、最大リソースをきっちり指定できるし、接続しないプロセスまでコネクションを要求することはない。そのため、確保リソースを間違えなければおそらく大丈夫だと思われる。しかし、この管理が及ぶのも、Webサーバ1台の時に限られる。複数台ある場合には、動的に最適な接続割り振りをしつつ最大数を超えない、というような芸当は無理だ。


そう言う場合、どこかで中央集権的な管理が可能な別のソフトウェアを使わなければならない。選択肢は2つ、pgpoolとpgbouncerである。ただ、上記エントリでも示されている、last.fmでの結果が、pgbouncerのほうがより大規模向けであることを如実に示している。


Russ ブログ ? Postgres Connection Pools: Pgpool vs. PgBouncer ? Last.fm


個人的にコネクションプーリングだけであれば、pgbouncerがお勧めだろう。ただし、pgpool-IIはもはやコネクションプーリングだけのソフトではないので、他のかねあいもあるだろう。


しかし、正直に白状すると、本当にコネクションプーリングを使うべきかどうか、L.starはもう分からなくなってしまった。Java+マルチプロセッサシステムにおいては、object poolingはわざわざ処理をしたりロックが発生する関係上かえって遅くこともあるそうだ。


[Java] ものをほじしてもはやくならない [Object Pooling しても速くならない]



Javaの理論と実践: ガベージコレクションとパフォーマンス(3/3追記:Thanks jzkeyさま。)

# 本当はdeveloperWorksに良い記事があったのだが、思い出せない。覚えている人はコメントかメールをください。

これは当然コネクションプーリングにも当てはまる。ポイントはコネクション生成のコストvsロック管理コストなどがどっちに軍配が上がるか、なのだ。しかしこの割合は日々変化しており、結局今のPCでコネクションプーリングすべきかどうかというと、とんと自信がない。古いシングルプロセッサ時代の昔は、確実にすべきだと言えたのだが。


3/3追記:ただし、上記dWの記事でも




確かに、データベースとの接続やスレッドの生成が必要なクラスオブジェクトの作成は、メモリ確保時に高い負荷がかかりますし、プール領域にオブジェクトを確保しておけば、データベースとの接続等に限られたリソースを有効に使うことができるため、この手法は有効と言えます。



とあるため、やはり有効なのだろう。言いたいのは、この種のパフォーマンス趨勢はどんどん変わる。そのため特に性能面の話においては、以前正しいと思っていたことが、あっさり覆されることがあるということである。



高可用性の追求


RDBMSは常に高い稼働率を求められる。なにしろデータストアの根幹であるから、落ちるわけにはいかない。しかし、RDBMS自体が99.99%の高可用性に対応しているようなことはまず無い。なにしろマシン単体で実現することが不可能だからだ。そのためのソフトウェアが用意されている。もっとも、ソリューションや運用体制まで含めて高可用性と言うべきであろう。PostgreSQLと組み合わせられるのは以下のようなものである

  • Cold standby (バックアップサーバを用意しておき、クラッシュしたらそこに復旧)

  • Hot standby(バックアップサーバを常時同期させる形で用意しておき、クラッシュしたら切り替え)

  • レプリケーション (pgpool-IIとか)

  • 共有ディスク型Active-Standby(例:iSCSI+Heartbeat)

  • ネットワークRAID+Active-Standby (例:DRBD+Heartbeat)

  • ノンストップ型ハードウェア


このとき注意するのは、どの程度の可用性を要求するか、とどの程度の手作業を許容するか、ということである。手作業は当然復旧時間と待機の人員コストを増加させる。また可用性追求のためのソフトウェア及びハードウェアはたいてい目が飛び出るほど高価である。そして、検証が完了した組み合わせでないとトラブル頻発しまくる、ということになる。

そして、高可用性構成はとにかくノウハウがいる。スキルの高い人材を訓練育成し、テストし、環境に適合させて、その環境がきちんと動くように現場調整して初めて真の高可用性が得られる。安くない。これも根拠のない職人感覚だが、L.starの考える高可用性構成のPostgreSQLを導入したい場合、それにかかるコストは以下のようになると考えている。

  • 稼働率99% - 数十万円(特別でもないハードウェア)

  • 稼働率99.9% - 数百万円(高価なハードウェア冗長構成+データセンター)

  • 稼働率99.99% - 数千万円(ノンストップハードウェア+データセンター+それを支える運用体制)


ざっくり言うと「停止時間1/10にするためには、コストは10倍掛かる」という感じである。日本人は「落ちない」を当たり前のようなことと考えているが、実際にはとても金と手間のかかるものである、というのは、プログラマだけではなく、みんなに理解して欲しいものだと思っている。そして、コストと稼働率のかねあいについて、みんなが真剣に考えてくれればなあ、と思うのである。

ちなみに、今PostgreSQL界隈が一番力を入れているのがHot standby機能である。まだまだ実装の手間が大きいが、これがきっちり使えるようになったら、99.9%レベルの稼働率を従来より安価に使えるようになるだろうと期待している。ただし、残念ながら原理上わずかながらのデータロスが避けられない。

レプリケーション


レプリケーションを使うのは高可用性と負荷分散的な両面で、である。高可用性的な面では上で述べたが、正直高可用性「だけ」を追求するのであれば、実績のある共有ディスククラスタなどを使うことを強くお勧めする。ここでは負荷分散部分を話したい。

なお、負荷分散と書いているが、ここでは「検索の負荷分散」である。レプリケーションはデータを何らかの形で複数箇所に投入する仕組みであるため、ほぼ確実に導入前より更新が遅くなる。更新の負荷分散に有効なのは、shared-nothing式クラスタリングと呼ばれる、データを複数ノードに分散して配置する方法であり、この2つは組み合わせられるが相容れないものだ。

話がそれた。レプリケーションはいろいろな仕組みがあるが、以下のような部分に注目して選定すると良い。なお、高可用性のところで述べたのと同じく、これもまた「ソリューション」である。ソフトは無料化もしれないが、ノウハウや人的コストは結構かかるので、覚悟すべし。

  • 範囲・・・どれだけの範囲の複製を取るか。通例クエリベースは全体を一気にできるのがメリットであり、トリガベースはテーブルごとで細かく設定できる点がよい。

  • 同期or非同期 ・・・ 通常非同期のほうが色々と良い。クエリの制限が少なかったり、性能が高かったりする。ただし、データ同期が遅れるという違いだけは、アプリケーション設計で吸収しないといけない。

  • 負荷分散 ・・・ 通常レプリケーション機能には負荷分散の意味はないため、別途組み合わせる必要がある。ただし、pgpool(-II)だけは、同時に負荷分散機能を持っている。アプリケーション側でラウンドロビンを実装したり、lvsを組み合わせたり、pgpoolやpgbouncerを組み合わせる、というのはあり。

  • 制限・・・ たいていの場合、一部のクエリが使用できない。クエリベースはたいていシーケンスやnow(),random()のような特殊関数の取り扱いに難があり(絶対出来ないわけではない)、トリガベースではtruncateなど、トリガが動かないのにデータが変わるものがやばい。


生のファイルシステム


意外に思われるだろうか。しかし、RDBMSに数十KB以上の、例えば画像ファイルを格納するというのは賢明ではない。そもそも構造自体小さなレコードを格納検索するのに最適化しているのがRDBMSの歴史である。でかいファイルを入れる方法として、BLOB/CLOBのような手法も提供されているが、どうもどれもいまいちという印象がぬぐえない。

そので外部ツールという話になるのだが、特に大きなファイルをkey-value形式で格納する方法として、未だにたんなるファイルシステム以上のものを見たことがない。そりゃそうだろう。そう言う目的に特化しているのだから。そう言うこともあり、画像ファイル等を格納する場合に別途ファイルサーバを用意しているような設計のサイトはとても多い。

どの程度までのファイルを格納できるか、というのは難しい問題だ。L.starは特に根拠があげられるでもなく64KB程度と考えている。いずれにしても数百KB程度であればもうDBに置くのはつらい。

なお、たんなる格納だけと言うことであれば、あるいはとても遅くてもかまわないというのであれば、それほど問題にはならない。ただし、前述のエントリの通り「検索しないデータをRDBMS上に配置するのは無駄使い」はL.starの持論である。

全文検索


PostgreSQLを高速化する16のポイント

では、全文検索にはLudiaを使おう、と紹介されている。また同様にtsearch2やtextsearch-jaも紹介されていて、PostgreSQLには全文検索機能があると言っても良い。しかしなぜここに「全文検索」を上げるのか?なぜなら「全文検索したいデータは、たいていの場合大きい」からである。前述のファイルシステムで述べたとおり、大きいデータの格納は、RDBMSの専門分野ではない。

あと、これらのIndexは残念ながら未だ枯れているとは言い難い。tsearch2はcontrib歴こそ長いが、昇格は8.2とごく最近である。Ludiaは8.3と利用するとvacuumが出来ないしろものだ。インデックスアルゴリズムの優劣については何とも言えない。が、個人的には例えばtsearch2よりhyperestraierのほうが高速だなと感じる。

L.starのDB歴は結構古く、最初に真面目に使ったのは(PostgreSQLと同じルーツを持つ)Illustraである。もう10年近く前だが、日本語全文検索DataBladeを使いつつ、「うーん、あまり性能が出るものじゃないな。やっぱり外部のエンジン使った方が早いわ」と思ってた。しかしそれから10年、時代の変化はRDBMSの全文検索Indexを身近なものにしている。コネクションプーリングの項では「時代の変化で分からなくなった」と書いたが、全文検索に関しては、変化によってRDBMSに組み込めるようになった代物と言えるだろう。

さて、つらつらと書いているうちに気力が尽きてしまった。自分で思っているよりずいぶんPostgreSQLについて覚えていたな、と言う印象だが、とはいえ最新の、外部ツールまで含めた事情はやはりカバーできていないなぁ、と感じる。この辺もいずれきっちりまとめて記事にしたいと思ってはいるのだが、まだまだ文章を書く練習が必要なようだ・・・

空気を読まずにPostgreSQLのを高速化する10のポイント - 象と戯れ - postgresqlグループ.の元エントリを読んで思うところがあったのだが、

PostgreSQLを高速化する16のポイント




だからそんなせまっくるしいところでトンチンカンにdisる暇あるんだったら自分のブログでお好みの議論を書くかさもなきゃ/dev/nullにでも吐けとやんわりと言ってるんだよハゲ。



というわけでw。

だよねw。

まあ正直、上記元ネタのほうには色々突っ込みどころ満載なのだが、それは置いておくとしてL.starなりの高速化ポイントを一度書いておかないと、と思ったので記す。ただ、L.starはもうPostgreSQL界隈から離れて久しいので、必ずしも最新の内容を網羅していないことに注意されたし。また、出来るだけPostgreSQLだけでなく、一般的なDBに活用できるように記述している。

紙面と気力の都合もあるので、外部ツールとの切り分けとかの部分は記さなかった。LAP(P)ソリューションを本当に高速化したい人のための・・・がいるかもしれない。

追記:外部ツールに関するエントリを書いた。下ピンバック参照

1. そのデータベースの傾向を知らないことには、何も始まらない。


RDBMSは汎用なので、実にさまざまな特色を持ちうる。読み込み中心、書き込み中心、OLTP、OLAP... それにより、いろんなものが異なってくる。そのため、L.starの経験では、どういうタイプかの特定なしに、意味のあるチューニングは出来ない。驚くべきことに、元エントリの16の方法では、この「特性」について一切ふれられていない。上げられている項目から見て、たぶんWebのバックエンドに多い、OLTP型。更新はちょっとで検索多めと言うことだろう。一方umitanuki氏も何も書いてないが、元々internalな部分に造詣が深い氏の場合は個別SQL向けチューニングポイントだろう。あなたのDBがこういった部分から外れていると、アドバイスはあまり役に立たなかったりする。

具体的にどの程度違うかと言う例だが、ものすごく参考になる記事として、pgsql氏の以下のエントリから表を引用する。氏には是非これを8.5に入れるべく頑張っていただきたいが。
2009-02-22サンプリング・プロファイラ (仮)






















































































ID 1 2 3 4
pgbench -S -S -N (TPC-B)
shared_buffers 32MB 4MB 32MB 32MB
tps 12894 11245 1586 896
IDLE_IN_TRANSACTION 0.0% 0.0% 46.2% 44.0%
CPU 99.2% 93.7% 13.4% 12.8%
DATA_READ 0.1% 3.8% 0.0% 0.0%
DATA_WRITE 0.0% 0.0% 0.0% 0.0%
XLOG_WRITE 0.0% 0.0% 18.1% 5.6%
XLOG_FLUSH 0.0% 0.0% 0.0% 0.0%
LWLOCK_WAIT 0.7% 2.4% 22.3% 0.6%
LOCK_WAIT 0.0% 0.0% 0.0% 37.1%


このように、まったく同じテーブル定義だというのに、大きく差が出てくる。このタイプ分けにより、どのようなチューニングを施すべきかというのは決まってくるのである。以下に、どのようなタイプがあるか述べよう。

  • 読み込み中心だよ

    • キャッシュヒット率高いよ型(小規模DB型、CPUボトルネック)

    • キャッシュヒット率低いよ(OTLP読み込み中心型)

      • 検索で取ってくる件数少ないよ型(インデックス多用、OLTP系)

      • 全件検索や集約演算多いよ型(シーケンシャル中心、OLAP系)





  • 書き込み中心だよ

    • 1件ごとの更新が多いよ

      • update中心だよ派(OLTP書き込み中心)

      • insert中心だよ派(ログ書き込み系)



    • 一度に大量にやってくるよ派(バッチ書き込み系)




2. そもそも、スキーマ設計の段階で検索を考慮したか


これはPostgreSQLに限らずの話。RDBMSの設計の最も初歩であるはずでありながら、ほとんど知られていないことがある。RDBMSは検索するツールであるから、そのスキーマはどのように検索するか?で決定される。何を格納するかではない。格納したいだけなら、インデックスなど要らないから、たんなるログファイルで良いのだ。

スキーマを決め、そのあとSQL設計をするのは、行き先を決めずに旅行に行くぐらい愚かだと心しなさい。(それはそれで楽しいであろうことは認めるが)

ちゃんと検索を考えてスキーマを決めた人、あるいはそれで問題があるのは分かっているが、戦略的な負けを認めた上で戦術的な最善を尽くしたい人は次に進んでよろしい:)

3. 時間の掛かっているSQLから順にチューニングしろ


パレートの法則の変形であるが、問題のあるSQLはごく一部である。なので、それを修正することに集中し、ボトルネックとなっているSQLを潰そう。pgfoundryには、ログから(実行回数*平均実行時間)の統計を取得してくれるツールがあったはずである。

この種のSQL解析をおこなったあと、次々と実際に時間の掛かるSQLを潰していくことが本来のチューニングの第一歩である。個別のSQLの何が問題かは、explain文でプランを読み解くことによって明らかに出来る。

L.starの知る限り、RDBMSを導入しているシステムというのは、このようなSQL(あるいはストアドプロシージャ)がボトルネックになっている。パラメータがどうこうというより、まずSQLを見直すことが重要であると心得なさい。それをそぎ落としたところで、ディスクI/Oがボトルネックとかそう言う話が出来るのである。

4. 書き込み中心のアプリケーションなら、ディスクの同期書き込みを制しろ


これは書き込み中心のアプリケーションなら基本中の基本である。上記表の(3)にもあるとおり、データ書き込みが発生する場合のボトルネックはxlogへの書き込みである。これはWALの意図からして同期書き込みでないといけないため、発生するI/O waitなども含めつつ考えないといけない。書き込みががつんと遅くなるRAID5などは、この種のDBにとっては最悪の選択肢である。

同期書き込みを良くするためにできること:

  • WAL専用ディスク(SSDならなお良いだろうが、正直未知数)

  • RAID0,1,1+10+1によるディスクI/Oの高速化

  • バッテリーバックアップ付き書き込みキャッシュRAIDカード

  • wal_sync_methodの適正な設定(現在はたいてい勘か全数調査)

  • synchronus_commit=false(8.3)


5. 真のメンテナンスフリーのDBなどない。データの健全性のため、再構築には気を遣え


autovacuumがあるから大丈夫、と言われることも多い。いわゆる主キー持ちupdate中心のテーブルにはだいたい当てはまるが、油断してはいけない。まず、ちゃんとmax_fsm_pagesを設定しているか?というのは重要なポイントである。これが足りなければいくらvacuumしても無駄である。

また、本当の敵はTableのvacuumではなく、Indexのvacuumである。実は8.3のHOTが有効なケース(index関連行以外が更新される)は、7.4以降のindex vacuumが効率よく働くケースと酷似している。問題は、これに該当しない、大量投入大量削除ケースである。ログテーブルとか、SNSでメッセージを格納するようなのは、単調増加型のIDを持つのが普通だろうが、こういう場合にはHOTも効かないしindexは肥大する。

あと、vacuumは、deleteしてからすぐ効くのではなく、次のinsert時に再利用されると言う点は無視できない。すでに劣化した状態で、compactionによる性能向上を図りたいならvacuum fullやそれに類するもの(cluster,データが空ならtruncate。ただし、vacuumとは特性が異なるので注意)は必須である。

ところで、pg_reorgってどうなんですかね?一見良さそうなんですが。

6. メモリはwork_mem(ソート用メモリ)、shared_buffers(キャッシュ)のどっちに使うべきかは、インデックスを頻繁に使うかどうかを目安にしろ


これは正直、バージョンによって大きく違うのだが、8.3系の場合はもはやshared_bufferは取れるだけ取って良いようだ。かつて古いバージョンではロック管理が芳しくなく、多くするとロック待ちのために遅くなると言うことがあった。

しかし、限りあるメモリをPostgreSQLの二大検索用メモリパラメータである、work_memとshared_buffersにどう割り振るか?である。これはOLTP系(インデックスを使った少数件数取り出し中心)かOLAP系(シーケンシャルスキャン中心になる、大量件数取り出し&多テーブルJOIN&集約)なのかによって決まる。シーケンシャルスキャンが多くなると、キャッシュヒットは見込めなくなる。そのため

  • OLTP系ならshared_buffers中心

  • OLAP系ならwork_mem多め


と言う配分が決まる。

7. ロック競合は悪。絶対必要なのを除いてとにかく避けろ。


RDBMSは、多数のプロセス/スレッドが走る。これらは競合しない限り並列実行による利益が享受できるが、ロック競合を起こすとそこはアムダールの法則の「マルチスレッドで実行できない状況」に従って、マルチスレッドでの性能向上を妨げる。マルチプロセッサシステムでの性能向上とは、すなわちこのロックを出来るだけ少なくすることにある。

だから、ユーザ側でもロックが発生する状況を熟知し、できるだけ競合が発生しないことを心がけないといけない。安直に「テーブルロックをかければいい」などというのは、性能面では御法度である。

例えば?ユニークIDの投入方法を考えてみよう。性能が良いのは以下の順である。

  1. 絶対競合しないID生成法(timestamp+pid+セッション固有数値とか)

  2. シーケンス
    (越えられない壁)

  3. lockしてからselect max()でID生成


たしかに3は、ロールバックが発生したときにIDが飛ぶケースを防ぐことが可能だ。だが、性能低下は実際には2.の10倍以上になる。

8. Indexは多すぎてもダメ、少なすぎてもダメ


ここらへんから、大きな部分は押さえ終わったのでTIPS系に。

Indexは検索を高速化するというのは周知の事実だが、更新を遅くするというのも理解しておいた方が良い。これの応用として、COPYで大量データ投入するときには、indexを全て外すというのがある。

もちろん、SQLはチューニングして、必要なだけindexを使うようにすべきである。そのとき、闇雲に増やすのではなく、考えて増やし、要らないindexは全てあとで消してしまうことを忘れないようにしよう。

9. 統計情報に注意しろ


PostgreSQLはコスト式Plannerしか持っていない。正しい統計情報があるかどうかは、SQLが高速に実行されるかどうかの重要なポイントである。コスト関連のパラメータをいじるなり、analyzeの機会を増やすなりして、できるだけその鮮度を保っておこう。

また、取得した統計が正しいかどうかもポイントである。IDのような連続したデータであればそれほど問題がない。しかし、これがトリッキーなデータになると、とたんに不正確になる。不正確なデータは不正確なプランを招き、性能低下の原因になる。8.4ではdefault_statistics_targetは10->100と大幅に増える

あとは一時テーブルの場合analyzeどうするか、とかそういう話もあるけど、PostgreSQLで一時テーブルは、そもそも使ってはいけない

10. とにかく触って、マニュアルにもソースにも書いてない「ノウハウ」をつかめ


ソース嫁とかマニュアル嫁とかは、他の2つにも書いてあるので飛ばしておこう。しかし、本当に重要なことは眺めても分からない。ソースを読み込んだり、マニュアルの行間に書かれているのを発掘しないといけない。それがノウハウである。ここに書いてあるのはノウハウとしてポイントを得ているように出来るだけ書いたつもりだ。しかし、ここに書いてあるよりもずっと重要なことは、実際に動いているものからしか知ることが出来ない。

そもそも、あなたのシステムは1.で示した分類のどれか一つに当てはまるだろうか?たぶん複数の条件を備えているだろう。そうすると、相反するパラメータをどう設定するかとか、そう言う問題に引っかかる。正解は、残念ながらソースやマニュアルから導けない。だから、試して触って、どうなるか確かめるしかないのだ。

だから、ここに書いてある9つのポイントを参考にしたりしなかったりしながら自分自身で「これは使える」「これはダメ」と言うのを確かめ、それをノウハウに昇華しよう。そうすれば、継続して最適な性能を維持できる真のDBエンジニアになれるはずだ。道のりは遠いが頑張って欲しい。

価値の判断基準が自分の外にある人間は表現者になれない - 発声練習.

この文章の主題は「他人の移ろいやすい価値観に惑わされるのではなく、精神的に背骨が通ってないといけないよ」というもので、良くできていて、とても耳にいたい。だけど、何故か違和感がぬけない。微妙にしっくりこないように感じる。

例えば、この文面は芸術家にとって半分正しくない。芸術にとっては、作品そのものやそれを生み出すプロセスに対して、「精神的な背骨」が通ってないといけない。しかし一方で、芸術にとって自分の外「だけ」が唯一絶対の価値判断基準である。どれだけ背骨が通っていようが、聴衆に評価されない芸術には何の価値もない。聴衆がどれだけ間違っていて、芸術家がどれだけ正しかろうが、だ。

#ただし、聴衆は変わりうるので、一度ダメだからと言って常にダメとは限らない。死後評価されるなどと言うのも珍しくないし。また、実査には聴衆もある程度予測可能ではあるので、よほどとんでもないチャレンジでもしない限り、おおむね「背骨」とも矛盾しない。

違和感の原因は価値観の置き所であろう。このエントリの作者は大学の先生っぽいが、しかも理系の学問では無かろうか。理系の場合、理論によって評価が決まる部分が大きい。絶対の価値判断基準は「理論」であり、聴衆ではない。理論が正しければ、聴衆に対して「お前は間違っている」と堂々と説明できるのである。だから、この人は「自分の内に価値観を持つ」ということを強く信じられるのだろう。自分の内の価値判断とはすなわち体得した理論であり、それに対する自信である。

一方で、このように「絶対的な、自己完結可能な価値基準」というのは世の中では少ない。例えば、教育は基本的に与えられた問題に対して教師が設定した「正しい」解答(理論ではない)を与えると言うことに特化している。会社組織での行動とは、端的に言うとエアリーディングの固まりであり、理論による解答があったところでみんなに納得されなければ「協調性がない」と一発で断罪(ひどいときには粛正)の材料になる。

もちろん、学問にしたところで完全に自己完結可能ではなく、学会のような組織もあるわけで、程度問題である。言いたいのは価値基準を形成する部分に、大きな前提の違いがあると言うことだ。

このエントリの筆者がそういう状況を認識できていないな、というのはコメント欄にあった以下の部分を見て確信した。

(コメント中の質問者)
> 一つお聞きしたいのですが、価値の判断基準が自分の外にある人間の「利点」は何だと思われますか? 長所と短所は背中合わせと言うくらいですから、逆に精神的な背骨のある人には出来ない事があるのではと感じたのです。

(エントリ作者)
価値判断の基準が自分の外にある人の利点ってなんでしょうね?
他人の望むことが分かっており、かつ、自分がその望まれていること
ができるときに、双方ともに幸せになれることでしょうか。


価値基準を自分の外に置くことの利点は、いうまでもなく社会の大多数を占めるビジネスマンなど、エアリーディング能力が最大限要求される世界に対する適応しやすさである。そして、それに適応して勝ち残ったのが大学生なのである。彼らはまず「ルールが変わった」と言うことを理解しないといけないのだ。これが必ずしもうまくいっていない。

おそらく今回卒業する彼は、このルールの変更に最後まで気づかなかったか、適応できなかったのだろう。このルールの変更はかなり大きなもので、高校生以前に制度的に教わる余地はまずない。そこで問題になるのはエントリの以下の部分である。
どうして、自信がなかったのかといえば、たぶん、間違うことに対して恐怖をいだいているからだと思うよ。何で間違うことに対して恐怖を抱いているのかというと、まだ君には精神的な背骨が育っていないからだと思う。

この人の理解ではたぶんこれは正しいのだろうが、学生から見ては間違っている。なぜなら彼らが間違うことをおそれるのは、洗脳されているといっていいほど社会からたたき込まれているからだ。だからまず「間違うことにたいして恐怖を抱く必要がない」という洗脳解除をしないといけない。さもないと、参照されている増田のように萎縮した考えを持つことになってしまう。

はてな匿名ダイアリー:大学院の教授がクソだと言われる一つの理由
精神的な背骨が育っていないから」ではなくて、自分意見を言わないのはそもそも研究目的が理解できてないから。間違うのがわかってて、それを論破されるのがもうほぼ確実に予想出来てるのに、わざわざ自分からフルボッコされるようなこと言うわけないじゃん。もう黙ってるしかないじゃん。

L.starは文章を書きながら頭を整理しつつ、この溝の深さを誰も理解していないことこそ、高等教育が行き詰まっている一つの理由なのではないかと思ってしまった。

もう一つ先の増田から引用するが、
修士のころはもうほんとに教授と会うのがいやでいやで仕方なかった。絶対怒られるから。今になって思えば怒られてるんじゃなくて、研究を進める上で重要ないろいろな視点を提供してくれてただけなんだけど、なにしろなんもわかってない状態だから自分のこと全否定されているように感じてた。博士課程に進まずに就職してたら、私だって間違いなく、大学院なんて教授が偉そうにしててろくでもないところ、あいつらは社会経験がないからな、博士なんて進まずにさっさと就職すべし、とか増田に書き込みしてたと思う。

この文章を見る限り彼はおそらく修士から博士に移行する過程で溝を超えられたのだと思う。しかし同時に、博士課程に進むべきでない理由というのは、なによりそこで教わる価値基準が異質だと言うことだ。自分の外に価値判断の基準を持たない人は、前述のエアリーディングの世界では生きていけない。そこは、どれだけその価値が正しかろうが、みんなの中に同じものがない、というだけで全て否定される恐ろしい世界だからだ。

長くなってしまったが、これを書きつつ企業と大学、一体どっちの価値観が優先されるべきなのだろうかとずいぶん考えてしまった。もちろんケースバイケースで結論は出ないのだが。しかし、この溝をきちんと埋める努力がなされない限り、強い社会というのは生まれないのでは無かろうか。学者vsビジネスマンで戦争をしていられるほど、社会は余裕があるわけではない。

エアリーディングと明文化されていないしかも矛盾だらけの暗黙のルールに疲れたL.star個人としては、願わくばもっと絶対的な価値観が要求される方向がいいな、と思う:)

仕事柄、と言うわけではないがメッセージングクライアントが手放せない人間である。個人的には、やはりメッセンジャーを使うのが一番しっくり来る。しかし、最近クライアントがあまりにも増えすぎているので、どうにか統合できないかと思っている。今の所会社ではPidginを使っているが、これはあらゆる部分を統合できている反面、使っていても全然しっくり来ないという欠点もある。もう一つのパターンはbitlbee使って全部IRCにしてしまうやつで、これもインストールしている。だが、これもいまいち使い込めていない。そして他の問題点として、たいていのクライアントはSkypeに対応していない。

そこで最近使っているのがimo.imというWeb版のクライアント。これはWebベースのありきたりの機能を実現しつつ、SkypeもWeb上で使えるというしろものだ。

http://imo.im/

あともう一つ今日から使い出しているのがDigsbyというやつ。こいつはアプリケーションだが、たいていのIM以外にメールのクイックチェッカーと、facebook、linkedin,twitterとも連携できるようになっている点が新しい。ようは、ユーザー体験を全部一つに収めてしまおうという狙いだ。しかも、多機能なのに案外メモリ消費量も少ない。

http://www.digsby.com

いずれももうちょっと使ってみたいかなと思っている。

しかし、やはり個人的には、ブラウザが全ての情報のフロントエンドに立てるように、全ての情報の流れを管理する、個人秘書のような統合型クライアントが欲しいと思っている。RSS、メールやニュース、各種サイト、メッセージングなどを全部統合して見せたり、データを管理したり、自分から興味深そうなものを整理提案してくれるようなものだ。ソーシャルサイトはその機能の一部を代行してくれるのだが、しかしソーシャルブックマークから出てくるサイトだけでも膨大である。

まあそう思いつつクライアントをえっちら書いていたことがあるのだが挫折してしまっている。また重い腰を上げて、プログラムの練習がてらやってみるべきだろうか。

ハヤカワFTより出ている時の車輪シリーズ、特に4-6部は非常に面白いが、後半だれてきて伏線回収が進まず、次が最終話だというのにどうするんだろうね?と思っていたら作者は難病で無くなっていてショックだった。以下Wikipedia

http://ja.wikipedia.org/wiki/%E6%99%82%E3%81%AE%E8%BB%8A%E8%BC%AA

と思ったら、なんと遺稿等を元に最終話を別の人が書くんだそうな。話のふくらみすぎた大ヒットシリーズの収拾を付けるなんてやりたくない仕事だな。

まあ、非常に楽しみである。

↑このページのトップヘ