技術者から見た都市伝説

業界動向

» 2010/06/10

　日本オラクルが 2007 年 8 月頃から始めている都市伝説キャンペーンというものがあります。「間違った認識や古い認識を改めたい」という思いで始められたと思われるこのキャンペーンですが、ある時期を境に、対抗商品に対するネガティブキャンペーン的な内容が増えてきたようにも思えます。

　最近「シーズン 3」 という形で新しい連載が始まっていますが、その内容について、技術者としていろいろと気になる点が見受けられました。

　わたしは業務として Oracle も SQL Server も利用していますので、ある程度双方のメリット・デメリットについて、レベルが低いながらも理解しているつもりです。そのようなポジションであるわたしが見ても、不審に思える記述があったり、自身が感じていたイメージと異なる内容を展開されている個所が見受けられたのは、不思議に感じました。

■多くの都市伝説の原因

　多くの記載の中で最も気になったのは、この都市伝説シリーズで扱われている内容、その多くが

　「データベース製品の性能に関わる部分ではなく、それを設計しているシステムエンジニアやソフトウェア企業のレベルが原因」

だと思える点です。

　更新処理でテーブルレベルのロックが長時間にわたって行われているようなことは、いままでの経験も含め、データベース製品が直接の原因ではなく、それを利用しているシステム側の問題に起因していることがほとんどかと思います。簡潔に言えば、

　「レベルの低いエンジニアや企業が作成したシステム」

であるから発生している可能性が、非常に高いと思われる現象です。このような企業が作成したのであれば、どのようなデータベース製品を利用したところで、同じ現象がほぼ間違いなく発生してしまうでしょう。

　やや穿った見方をすれば、「あの」データベース製品を利用するシステム会社にはその程度のエンジニアしかいない、という見方にすら成り得ます。さすがにそこまでの悪意はないと信じたいところです。

■さらにいくつかの気になる記載

　個人的に、比較広告的手法を用いたセールス・マーケティングを否定するつもりはありません。ですが、そうであるならば「正しいデータ」に基づいた「正しい情報」を記載したうえで行ってほしいと思います。誤った情報を元にしたコマーシャルは、開発者にとってもユーザーにとっても何の利益もありません。嘘を元にされるよりはまだ、正しいデータを部分的に抽出したコマーシャルの方が良いです。

　「Power Pivot ではダーティリードを利用できない」は、実際に利用している人間として、非常に不思議に思えた点でした。実際に利用すると分かると思いますが、Power Pivot では抽出方法を2とおり用意してあります。「テーブルやビューを指定して抽出」と「 SQL を指定して抽出」です。このようにデータ抽出用の SQL が直接指定できますので、そこでダーティリードを行うことが可能です。

　また Oracle でのUNDOセグメント、SQL Server でのREAD_COMMITTED_SNAPSHOT オプション利用時の tempdb は似ている挙動だ、ということをご存じの方も多いでしょう。公開されたデータとしてREAD_COMMITTED_SNAPSHOT オプション利用時のレスポンスについては見あたりませんでしたが、このあたりも適切にハードウェア構成を設計されているのであれば「使えない」レベルではないと思われます。実際、マイクロソフト 北川さんが過去に実測した話を非公式ながら記載されています。その際の結果としては、大体10％程度のレスポンス低下が見られたとのことです。
　
　仮にロックが多数発生しエスカレーションが起きていることを問題としていたとして、そこでも適切な記載がされているとは思えません。SQL Server にて多く叫ばれている「ロックエスカレーション」が原因だとしても、2005 以降では結構調整することが可能になり、その方法はMSDNなどで公開されています。

2005 では DBCC TRACEON 1224 または 1211
2008 では ALTER TABLE の SET LOCK_ESCALATION オプション

　初期値でOFFになっているというのは、その製品のメインターゲット層をどこにおくかで決定される面が非常に大きく、性能上の問題のために OFF になっているとは言えません。何も考えずに利用した際には性能問題が発生しますが、それは適切な構成を用意しないで利用したことが原因です。それを踏まえると、データベース製品による差はほとんど存在しないのではないか、わたしはそのように考えます。

　コストパフォーマンスについて TPC-C ベンチマークの結果を用いている点はイメージ操作と思える内容です。TPC-C ベンチマークは極大構成における処理性能を測るためのベンチマークですので、この結果だけを用いて「 ○○ が早い」と言い切ることができないのは、技術者であれば理解できるかと思います。

　むしろ普段かかわるような規模であれば TPC-C ベンチマークの結果とは無縁でしょう。レスポンスがあがらない原因の大半は、テーブル設計やハードウェア構成、またはアプリケーションからの SQL が原因だというのも、ほとんどの方はご存じだと思います。同じ設計でデータベース製品を変更したらレスポンスが向上した、という話はほとんど聞かないのではないでしょうか。

　ちなみに TPC-C はその性質上あまり一般的なベンチマークとはならない点が以前より指摘されており、それを踏まえた形で TPC-E が提唱されているのですが、残念ながらこちらではまだベンチマーク結果が少なく、希望に沿う結果を見つけることができませんでした（探し方の問題もあると思いますので、ここにつきましては情報提供をお願いしたいと思います）。

■コマーシャルのターゲット層はどこか

　このように、技術者であれば指摘できる点が多く、「都市伝説」という言葉どおり笑ってスルーすればよいのですが、果たしてこのコンテンツは、わたしたち技術者に向けられたものなのでしょうか。わたしは、どうもそうではないように思えます。

　どちらかというと、これはユーザー側へのメッセージなのではないか、と思います。俗に言う FUD がこれにあたると思います。最初に与えられたイメージは後々まで尾を引きますので、それを利用した販売戦略なのではないでしょうか。それ自体は、企業としての行為ですので、特に疑問視はしていません。

■実はほかにも…

　調べてみるとこのような都市伝説は他のデータベース製品にもある様子で、MySQL については Mikiya Okuno さんが記事を公開していました。恐らく実際には、まだまだ多くの都市伝説、誤った認識というのが多く出回っていると思います。

　技術者としては、このような都市伝説に惑わされることなく、ユーザーに対して、真実を元にした仕事を行っていきたいものです。噂ベースの記事や話に惑わされ、実態と異なる提案をしてしまうことを、わたしたちエンジニアは避けなくてはいけないと考えます。そのためにも、日ごろから多くの情報に触れ、真偽を見抜く目を養わなくてはいけないのではないでしょうか。