技術者から見た都市伝説

＠ＩＴにて書かせてもらっているエンジニアライフのコラム。6/10にて公開された同タイトルのコラムの原文です。比較してもらえると、どのような点に注意しどのような方向性に持っていけばよいか、編集の方々と色々考えたというのが見えるかと思います。

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

最近シーズン３という形で新しい連載が始まっていますが、その内容については残念ながら好ましいとは言えない記載が見受けられる、悪く言えばゴシップ誌的なものへと強化されている様子です。

私は業務としてOracleもSQL Server も利用していますので、ある程度双方のメリットデメリットも、レベルは低いにしても理解しているつもりです。そのようなポジションである私が見ても、明らかに誤っている記述が見受けられたり、意図的にイメージ操作を行っている箇所が見受けられたのは、非常に残念でなりません。

最も残念なのは、この都市伝説シリーズで扱われている内容、その殆どがデータベース製品の性能に関わる部分ではなく、それを設計しているシステムエンジニアやソフトウェア企業のレベルが原因だと思える点です。穿った見方かも知れませんが、更新処理でテーブルレベルのロックが長時間にわたり行われているような事は、どう考えてもデータベース製品が原因ではなくそれを利用しているシステム側の問題です。簡潔に言えば「レベルの低いエンジニアや企業が作成したシステム」であるから発生している現象です。このような企業が作成したのであれば、Oracleを利用したところで同じ現象がほぼ間違いなく発生してしまうでしょう。
更に穿った見方をすれば、「あの」データベース製品を利用するシステム会社にはその程度のエンジニアしかいない、という見方にすら成り得ます。さすがにそこまでの意識はないと信じたい所ですが。

 

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

 

「PowerPivotではダーティリードを利用できない」は素人が見てもわかる程の誤りです。またOracleでのUNDOセグメント、SQL ServerでのREAD_COMMITED_SNAPSHOTオプション利用時のtempdbは似ている挙動だ、という事をご存じの方も多いでしょう。公のデータとしてREAD_COMMITED_SNAPSHOTオプション利用時のレスポンスについては見あたりませんでしたが、このあたりも適切にハードウェア構成を設計されているのであれば「使えない」レベルではないと思われます。
またロックがかかりすぎている事が問題としていたとしても、適切な記載がされているとは思えません。SQL Server にて多く叫ばれている「ロックエスカレーション」が原因だとしても、2005以降では結構調整することが可能になり、その方法もMSDN等で公開されています。

 

コストパフォーマンスについてTPC-Cベンチマークの結果を用いている点はイメージ操作と思える内容です。TPC-Cベンチマークは極大構成における処理性能を測る為のベンチーマークですので、この結果だけを用いて「Oracleが早い」と言い切ることはできないのは、技術者であれば当然の事かと思います。
むしろ普段関わるような規模であればTPC-Cベンチマークの結果等とは無縁でしょう。レスポンスがあがらない原因の大半は、テーブル設計やハードウェア構成、またはアプリケーションからのSQLが原因だというのも、殆どの方はご存じだと思います。同じ設計でデータベース製品を変更したらレスポンスが向上した、等という話は殆ど聞かないのではないでしょうか。

 

少々不思議に思えるのはOracleにて勤められている方々は、この都市伝説シリーズを見てどのように感じられているのでしょう。このコーナーは間もなく３年を迎えようとしている事を考えると、何かしら意見を抱えている方の数は少ないのでしょうか。それとも社内で声をあげても届かないような状況なのでしょうか。

実際に掲載された内容と比較すると、原文ではかなりOracleに対する攻撃的な箇所が見えていると思います。一番考えたのはこの部分でして、できるだけ直接的な攻撃を行うのではなく、こういった噂話が多いけど惑わされるなよ！、という方向で書くことが有益なのではないか、というのが編集者さんと私との間で決めた方向性でした。
実際には私も「その通りだ」という認識でして、変に攻撃するよりも騙されないようにという周知の方が、私も含めた技術者にとって一番有益なのだろうと思います。