はてなブックマーク-不倒城: どうも世間では、思ったよりDBエンジニアが不足している様だ
DBはプログラマが作っちゃうからなぁ。DBエンジニアが何してくれるのかがむしろよくわからん理想のDBというのは、理想のインフラと同様、多分「そこにあることを意識させない」DBだと思う。セットアップして構築さえされてしまえば、後は読み込みにも書き込みにもボトルネックを作らず、ただモクモクと働くDB。
それに則って考えれば、「理想のDBエンジニア」は、開発の初期段階以外ではサボっている様にしか見えない筈だ。特に主要なロジックをアプリ担当が開発する場合、DBエンジニアがなにをする仕事なのかよくわからんというのは、多分一面で正しい。
ただ、ずーっとほっといても全くパフォーマンスが劣化しないDBがこの世に存在するなら話は別だが、システムを使い続ける限りDBにはレコードが溜まるし、レコードが溜まればDBの応答速度はいつか必ず劣化する。統計情報の自動収集が行われよーが、自動パフォーマンスチューニングが行われよーが、大体の場合劣化の速度には大差ない。劣化を防ぐには人の手が必要なのだ。
で、その「パフォーマンスの劣化」と、「劣化を防ぐ労力」がそれぞれどんなものなのか、意外に理解されていないことが、世の中にDBエンジニアが不足していたり、ひどいDBが普通に検収されてしまう理由じゃないかなあ、とか思った。
DBの難しいところは、「災難が後から来る」ことだと思う。ボトルネックは、当初ユーザーには見えない。
当たり前だが、構築時点のDBにはレコードが入っていないから、どんなひどい構造でもそれなりにサクサク動く。その為にテストデータの作成や負荷テストをやる訳なんだが、アプリにせよDBにせよ、負荷テストにも結構知識や技術が要る。その辺をごまかされてしまうと、さっきのエントリーで書いた様な、余りにもROCKなDBを検収してしまう羽目になるのかも知れない。
いやまあ、昨日の例はいくらなんでもちょっとひどすぎだとは思うけど。なんなんだアレ。製作者は前衛芸術家か。
