2010年6月10日木曜日

技術者から見た都市伝説

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

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

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

私は業務として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にて勤められている方々は、この都市伝説シリーズを見てどのように感じられているのでしょう。このコーナーは間もなく3年を迎えようとしている事を考えると、何かしら意見を抱えている方の数は少ないのでしょうか。それとも社内で声をあげても届かないような状況なのでしょうか。

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

2010年6月7日月曜日

Lzh形式を企業・団体では利用しないように…

UNLHA32.dllの作者であるmicco氏が発表している内容

非常にわかりやすく問題点を記述してあるので是非一度目を通しておいてほしい。

ただ。

結構企業や団体、というか業界内部にlzh形式の圧縮は入り込んでしまっているので、そう簡単に切り替えるのは無理だろうな。自分が関わっている流通系では、当然のようにlzh形式でのEDIデータ送受信が行われているし。

これがJX手順に切り替われば・・・lzhから卒業できるんだけどねぇ。
使われるようになるのは早くても、JCAプロトコル撤廃に向けて動き出す再来年くらいからかな。

2010年6月2日水曜日

第47回 CLR/H 勉強会(2010/04/17)にて発表した LT 資料

アップしようと思ってすっかり忘れていたのでアップw

SkyDriveにアップしてあります。

自分の基本姿勢は「金はない」「でもやりたい」だ!

BPOS で携帯 ( ≠ Windows Mobile )

色々あってBPOSパートナー企業登録しようと思ったので調べていると、携帯( iMode とか ezWeb とか)からアクセスというのでちょっとわからなくなったのでメモ。

  1. Exchange Online では基本 Outlook や Windows Mobile 携帯が対象
  2. 一般的な携帯ではフルブラウザを利用して参照?(未確認)
  3. ビービーシステムさんがソリューションを提供している

一般的な携帯からアクセスできる事は恐らくBPOSをユーザーに話すにあたって、確実に出てくる話題なのでちょっと押さえておきたかったのだけど、残念ながらスクリーンショットなどの類はなし。ただ、Exchange Online 自体が通常のブラウザアクセスに対応(Outlook Web Access → Outlook Web App に名称変更)しているので、これを利用するか外部ソリューションを利用するかという流れになる。

Outlook Web Access 自体はアクセス用のアドレスが公開されているのでそこにアクセスする形なのかな?