テレビのリモコンを孫の手で押すなって！
弊社でやっているSQL講座の最初の方でお話しする内容です。
どれぐらいの人が試すのかな……、知ってる人にとっては極めて当たり前のことですけれど、知らない人は、けっこうびっくりする人もいるので、実際にやってみることを強くおすすめします。（できないという人はセミナーに来なはれ）
では、ちょっとしたサンプルを作るか、それなりにデータ量のある既存のテーブルのインデックスを張ったカラムに対して、以下のSQLの実行計画を取ってみてください。
【注意事項】
実行計画を取る前に、Oracleは一応、アナライズをしておいてください。SQLServerは主キー以外のインデックスがある列を使うこと。
【準備】
SELECT
MIN（カラム）
, MAX（カラム）
FROM テーブル
※ サブクエリーではわかりにくくなるので、最小値と最大値を控えておいてください。
【実行計画を取る】
※ 詳細なやり方を知らない人はググってくださいな。
- SELECT * FROM テーブル
WHERE カラム BETWEEN 最小値 AND 最大値／１０
※ シーケンシャルでないときは10％ぐらいの範囲にする - SELECT * FROM テーブル
WHERE カラム BETWEEN 最小値 AND 最大値／４
※ シーケンシャルでないときは25％ぐらいの範囲にする
結果は、呼び方はRDBMSのベンダー毎に違うと思いますが、
- INDEX RANGE SCAN
- TABLE ACCESS FULL
となるはずです。（2.で変わらないときは少し範囲を広げてください）
これで何が分かるかというと、上の様な単純なSQLを実行するときにも、RDBMS（オプティマイザ）はインデックスのデータの分散具合からどれぐらいヒットするか予想して、インデックスを使うべきかどうか判断する処理を、実際のデータにアクセスする前に行っているということです。
なぜ、実行計画を変える必要があるかというと、例えば99％が男性という団体があり、その入会順に会員情報が記載された一覧があったとしましょう。
項目は、
会員番号↓ ・ 名前 ・ かな ・ 住所 ・ 電話番号 ・ 性別 ・ 生年月日……
その他に、性別順に並べた会員番号の一覧を作るというのが、「性別にインデックスを作る」ということになります。
項目は、次の2つです。（実際のインデックスでは会員番号ではなく物理的なアドレスになる。）
性別↓ ・ 会員番号
さて、あなたは、この99％が男性というリストから男性の一覧表を作るとき、性別順一覧を使いますか？ 逆に、女性の一覧表を作るとき性別一覧を利用しないですか？
どちらかが当てはまるなら、この先を読むのは無意味です。IT業界で仕事をするセンスが決定的に不足しているので、転職を考えた方が良いでしょう。
当たり前ですが、インデックスを使う、つまり2つの一覧を見比べながら結果を作っていく作業は、結果の件数が少ないとき効率的で、結果の件数が多いときには非常に非効率になります。
その効率の分かれ目は、B-Treeインデックスの場合、対象となる結果のデータ量が全体の20～25％を超えるかどうかというところにあり、RDBMS（オプティマイザ）は実行前にその判断をしているので、データの取得の範囲を変えるとインデックスを使ったり、使わなかったりする訳です。
それには、当然、あらかじめデータの分散ぐあいを測っておく必要があります。Oracleではアナライズという処理で行い（10g以降では自動収集がデフォルトになったのかな）、SQLServerは自動で行うのが普通です（手動に切り替えれたハズですが、面倒なのでやったことはない）。
SQLをRDBMSに渡すと、シンタックスチェックだけではなく、実行前に使われているテーブル（インデックス）のデータの分散度合いを調べてから実行します。ややこしくなるので、上の例には結合はしていませんが、結合処理がある場合には、データ数などから、どのテーブルから順にアクセスするか、どのインデックスを使うか、あるいは使わないか決めてから実行します。もちろん、SQLの書き方でも、オプティマイザの判断は変わりますから、最終的には「部下の癖を見て指示の出し方を変える」というような書き方をしないといけない訳です。
つまり、SQLはプログラムというよりも設計書、実行計画がプログラム（詳細設計かな）ともいえるものなのです。RDBMSにとってトランもマスタも関係ありませんから、汎用的に判断させアクセスパスを決める処理は複雑で重い処理です。
オプティマイザはプログラムとしては大変完成度の高いもので（もちろん、O/Rマッパーとは比べものにはならない）、年々進化していますが、それでも、人間と比べると杓子定規でデキの悪いPGレベルでしかないですから、SQL文が複雑（下手糞）だったりすると、あり得ない結果を返してきます。ですから、あるレベル以上のスキルの人は「実行計画を見ろ！」と声高にいいますが、そういう人が出るということは、裏を返せば、SQLを書いていても「実行計画を見たことがない」という恐ろしい人が多いことの証明です。
現実問題、見てない人がメチャクチャいるから怖いよね……。Oracle9i以下だと、実行計画を見るのに実行計画を保存するためのテーブルを手作業で作らないといけないのですけれど、億を超えるシステムでも、開発環境にも本番環境にも（チューニングするには本番環境にないと意味がない）そのテーブルがない！ なんてことも珍しくなかった。
それって、数百人月で（数十人）の技術者の中で、誰一人として実行計画を見てないことを意味するわけで……、当然、実行計画を見ると訳の分からないものになっているし、まぁ、グルグルが多かったけど（苦笑）、まるで悪夢のようなデスマーチで、死人が出なくて良かったが、鬱で戦線離脱した人はけっこう出てたね……（他社のプロジェクトで、わたしは、同じお客様の別プロジェクトをやってた）。
同じことで、「O/Rマッパーが良い」なんていう人は、O/Rマッパーが吐き出したSQLを確認しているかも怪しいですから、その先の実行計画を見ているとは思えない。決めつけはイカンけど、実行計画を確認するような人は、自分で書いたSQLでもオプティマイザが間違うことを知っているのに、O/Rマッパーが吐き出すSQLのレベルは推して知るべしというわけで、O/Rマッパーなんて使うのは嫌がりますね。
「何が便利と思うか」の基準は人によって違うので何とも言えませんが、2回もチェックしないといけないなんて「なんて不便な」って……。
それはともかく、実行計画ができた後は、手続き型言語で処理するのと同じように、実行計画通りDBEngineがデータにアクセスします。DBEngineも、オプティマイザも、C++などの言語で書かれたプログラムですから当たり前の話ですね。昔はCOBOLで書かれたDBEngineもあったらしいけれど……。その先は何であっても同じなわけです。
さて、手続き型言語で細切れにしてから処理しようとすると、処理自体は（十分にチューニングされたSQLの）実行計画とほぼ同じになります。差があったらおかしいでしょう。ただし、別サーバではDBサーバが備えている統計情報や、インデックスを使えない。DBサーバが行っている諸々の高速化するためのプログラムは一切使えませんから、手続き型言語で処理は、オプティマイザの実行計画以下のプログラムにしかなり得ません。
これは人によって変わるものではなく、論理的に決まります。
しかも、単純なSQLでループを多用して作ると、コンピュータは律儀ですから、毎回、実行計画を考えます（今時、バインド変数を使わないことはないでしょうけど）。RDBMSは「複雑な処理をプログラマがループを書かずにできるように」という思想の元に開発されているのですから、その思想通り使わないと威力は発揮しないどころか、デメリットばかりになってしまう。
多くの手続き型言語で書く方がよいという意見は、「余分な工数が掛かっても、別言語で人間がもう一度、実行計画以下のプログラムをコーディングして、ネットワークを挟んで非効率な実行した方が、俺たちが分かりやすいからよい」といってるわけです。
SQLでやった方が良いという人の意見は、「RDBMSを使う以上、オプティマイザが理解できるSQLを書いて、それをチェックするだけの方がよい。分からないなら分かるようになるべき」といってるわけです。
「手続き型言語で書く」ということは、開発者側の都合のメリットしか入ってない。手続き型言語で処理しようとすると、余分に工数が掛かって、中途半端で遅いモノにしかなり得ない。
前回、手続き型言語で処理するのは「テレビのリモコンを孫の手で押しているのと同じ」と書きましたが、必然的にそんな感じになるわけです。わたしは「指で押せや～（怒）！！」って言い続けていて、「SQLなんて」っていう人は「ボタンが小さいから孫の手で押しにくい」って言ってるわけで……、噛み合わない。
外側にどんなに使いやすいツールができても言語ができても、RDBMSを使う限りインピーダンスミスマッチは存在し、RDBMSを使う以上、上に書いてきた処理は変わることがないので、どこまでいっても同じ流れにしかならない。そもそも、外側でインピーダンスミスマッチを吸収しようとする試みは、RDBMSを全く理解していない人だからこそできる馬鹿げたチャレンジといわざるを得ない訳です。スタートラインから明後日を向いた無駄な努力をやってるわけです。O/Rマッパーの発展に期待とか、「もっと押しやすい孫の手を！」ってことでしょう。わたしにはまったく理解ができない（苦笑）。
その目的が、「初級シスアドレベル、つまり、素人レベルの技術」を避けるためって、さらに、意味が分からなくなるのです。
外側でインピーダンスミスマッチを乗り越えても、ある規模の複雑な処理になったらSQLで書かねばならない。「ある規模の複雑な処理」って、そのシステムのコアになる処理でしょう。そこで使えず、中途半端になるぐらいなら、インピーダンスミスマッチのラインを極力SQL側にした方がよいでしょう。できる人に取ってはSQLでやった方が工数は少なくなりますから、馬鹿げたチャレンジに意味を見いだすことは、わたしにはできない。
「そんなことできるわけがない」という人とは違う風景を見ているからね……。初級シスアドレベルから、あとは階段を2、3段のぼれば、「あれ？」っていうぐらい違う風景が見えます。それを見た後で、それでも外側でやるべきという意見は聞くに値するけれど……。初級シスアドレベルから逃げたいという感情は、わたしにはまったく分からないです。
「まぁ、ハードがカバーしてくれるから良いじゃない」というのは、「アセンブラとC言語」の関係のように、アセンブラの開発コストとよりC言語の開発コストが低いとき成り立ちます。つまり、SQLをどれほどできるようになっても、手続き型言語で処理するよりも工数が掛かるときに成り立ちますが、工数もSQLでやった方が減るのであれば、成り立たない言い訳です。作れる人が少ない以上、メンテが難しいということもあながちウソではないけれど、できる人が増えたら勝手に解消する問題でしかない。
つまり、「SQLを使わない ＝ RDBMSを使わない」以外のアプローチは、根本的な部分でおかしい。もちろん、何度も書いているとおり、「RDBMSを使わない」という考え方はまったく否定しません。
「SQLができない人でもある程度作れる」。あるいは、「オブジェクト指向で書ける」この一点しかないけれど、これは顧客に対するメリットとはいえない。
できない人って……「そもそも、SQLができない人がプロを名乗っている」ということがおかしくないか？ ということを、わたしは何度も書いているわけで「できることが常識である」という立場です。「できなくてもプロを名乗ってもおかしくない」という人とは常識のライン、つまり、議論以前の前提が違いすぎるので話は通じない。
できなくてもプロだというなら、どちらも同じSIerを名乗るとおかしくなるので、「初級シスアドレベルを避ける会社です！」って会社のWebにでも、会社案内にでも書いて欲しいモノです。
いずれにしても、簡単なSQLだろうが、複雑なSQLだろうが、バインド変数を使って実行計画を再利用しようが、「ファイルアクセスの記述が変わっただけ」程度の認識と比べると、SQLはオーバーヘッドはメチャクチャ大きい。そして、オーバーヘッド以外は、手続き型言語の方で処理するときと、SQLで処理するときと、どちらも同じ結果になるのですから、DBサーバの処理量はほぼ同じです。
手続き型言語の方で処理するとき、APサーバがDBサーバの処理を肩代わりできるのは、ソートと四則演算しかありません。基本的には、ソートと四則演算より、オーバーヘッドや余分なデータ転送に掛かるコストの方が大きいので、手続き型言語の方で処理するとDBサーバの処理も増えることになるわけです。もちろん、インデックスや共有キャッシュを使えない（マスタならキャッシュできるかも知れないけれど）APサーバの処理は、DBサーバで処理するときに比べ比較にならないほど増えます。結果、APサーバを相当数増やさないといけませんから、エコじゃない。運用コストがずいぶん違うわけです。
よく、「DBサーバで処理すると、DBサーバの負荷が増える」という人がいますが、論理的には間違いです。地球は平らだといってるぐらい、技術者として恥ずかしい意見です。もっとも、実行計画も見ない「とんでもないSQL」を書く人がいるので、現実問題としては間違いと言えないことの方が多いのですけれど……、それは「とんでもないSQL」を書く人に問題があるわけです。
何度も書いていますが、「とんでもないSQLを書く素人崩れが大勢いるから、SQLは使えない」は、短期的には正しいけれど、今後もRDBMSを使うなら、「早急に教育を実施しないといけない」という経営判断が必要です。とくに若い技術者ではなく、中堅以上の技術者の問題ですから、多くのSIerが気づいていない根深い問題です。若い技術者を教育しても上から潰してしまいますから現場ではどうしようもないのです。
そんなことが分かる経営者は大手にはいないだろうから、O/Rマッパーのようなものを作って「孫の手」は絶対に離さないってことが正論になるのでしょうけれど……。
この常識を変えれるのは、大手の情報システム部の方々が「お怒りになる」ことしかないと思う。
もちろん、何度も書いているとおり、RDBMSを使わないという経営判断も正しいですよ。RDBMSは顧客に浸透しきっているので大手では無理ですけれど、ニッチなベンチャーとしてはありかもしれない。
結局、「O/Rマッパーなどがすばらしい技術だ」と無邪気に思ってしまう人も大勢いるわけですから、担当を分けるしかないのです。
つなぎ目はストアドプロシージャの方が都合が良いと思いますけれど、まぁ、上流から順に意味を分かって設計、担当割りを行い、きっちりとしたSQLを書くなら何でやっても同じで、後は好みの問題でしょう。O/Rマッパーは、きっちりしたSQLを書いた後にマッピングために使うなら、目的外利用じゃないかと思いますけれど、何の問題もないのです。
とにかく、どうしようもなくSQLを嫌がる人が存在する以上、担当を別にするしかないのです。
コメント
インドリ
O/Rマッパーと言う言葉が出来る前に、自分でそうしたものを実装した事があります。
その作業で分かった事なんですが、結局のところストアドプロシージャを使ってその結果を受け取った方が開発効率がいいです。
その系ん件から私が思うに、基本的に厚いO/Rマッパーは必要なく、ちょっとしたオブジェクト（DataTable）などで処理する方がいいですね。
ただWANシステムともなると、データの物理的位置が離れすぎて、ネットワークの負荷を考慮しなくてはならなくなります。
そこで、遠隔地にあるデータでデータ量が多いものを端末で処理する場合、インメモリDBのようなものにデータを格納して、並列処理すると良いかと思います。
O/Rマッパーは手間を省くものではなくて、そういった方向に別進化するでしょう。
というか軌道修正しつつ進化して欲しいですね。
インドリ
誤：系ん件
正：経験
インドリさん、こんばんは。
確かに、SQLとVBとかJavaとか、最初にやったときはO/Rマッパーを企画しますな。
かく言う私も企画はしました。
「スゲーこと思いついた！」って浮かれたもので、はしかみたいなモンじゃないかな？
私は、たまたま、企画を実行するよりもSQLを先に習得したので、後から、はしかを起こしている人に「冷静になれ！」って言いたいだけです。
遠隔地というか、複数のサーバのデータを中継する機能として存在するのであれば良いのじゃないの？
そういう発展なら、個々のサーバでは、みっちりSQLを書かないといけない訳で、それをやらずに複数のサーバを挟んでグルグルしてたら、ソフトバンクモバイルがナンバーポータビリティ制に移行したときみたいになっちゃいますね。
詳しいことは知らないけど。
生島さん、お疲れ様です。
今回もすんなりと沁み込んでくる内容でした。中でも、
> SQLはプログラムというよりも設計書、実行計画がプログラム（詳細設計かな）ともいえるものなのです。
の一句で『おおぅ？』と唸り、若干酔いが覚めました（笑）
Explainまで含めた両方を知ってこそ”設計”が洗練されるという意味でも、この例えは素晴らしいですね。名言だと思いました。
9年前の話になりますが、私の客先デビューはバグ修正要員でした。なので”どうしようもないSQL”を修正するところが始まりまったのですけど、対外的に『修正できました』を公表する上で、プロとしての根拠が必要でした。なので自然と実行計画というものを知ることになったんですよね。
『よく解んないけど、こねくり回してたらなんか速くなった』とは言えませんし（笑）もう7年以上前の話です。
マイスター制度を求めている人は多いと思うんですが、技術を探求するなら、孫の手の形状を探求するのではなく、念じただけで音量やチャンネルが変えられる方向に進むべきでしょう。こっちのほうが圧倒的に便利になるわけですから。
いろいろ述べましたが、なにも今思っている常識に縛られて耳を塞いでいるわけではないんですよね。自分が長年コレで飯を食っていて、それなりに成功してきた自負があり、実際に同じ考えのスペシャリストを何人か知っている。ネット上でかじった情報ではなく、実務経験に基づいて”常識”としているんですよね。
なので世界レベルの”孫の手研究家”の意見があれば、是非私も伺いたいと思っています。その意見に感銘を受けたなら、今ある常識なんて幾らでも変わるくらいの柔軟性は持ってるつもりですから（笑）
などと前置きしつつ、絶対の自信を持っているのは生島さんも同じでしょうか。
ちょっと酔い過ぎたようなので、これにて失礼します（笑）
ちょりぽんさん、こんばんは。
>> SQLはプログラムというよりも設計書、実行計画がプログラム（詳細設計かな）
>> ともいえるものなのです。
>
> の一句で『おおぅ？』と唸り、若干酔いが覚めました（笑）
ありがとうございます。でも、十年は言い続けているのに……。
オブジェクト指向を否定しているわけではなくって、明らかに大きな段差があって、それをオブジェクト指向で乗り越えるのは、RDBMSを使う以上、無駄な努力というか、馬鹿げたチャレンジというか、オブジェクト指向で何とかしようと考える時点で、相手（RDBMS）を見ていない独りよがりだと分からないかな……。
それって、お客には何のメリットもない努力ですからね。
「実行計画を見る能力がないから……」というのは、初級シスアドのレベルを考えてもプロが口にすべきことではないし……。
まぁ、そういう連中はもうちょっと勉強して欲しいのです。
O/Rマッパーを作るなら、RDBMSじゃないものを作れと言いたいわけです。
はじめまして。
以前、データ件数が億に達するレベルのシステムで、アプリで使っている、全クエリについて、実行計画を逐一チェックしてました。多数のクエリがあると、どこかで、ボトルネックを踏みますから。Oracle 8 / Oracle 8i の時代で、まだ、ルール・ベース・オプティマイザを使ってました。
Oracle 10g は、オプティマイザがかなり賢くなっていて、以前のように、予想外の実行計画を作りだすことはなくなってますね。ヒントも使わなくなりました。
もっとも、統計情報を収集する前後で、データに大きな変動があると、当然ですが、実行計画がおかしくなりますね。月締めで夜間バッチが大量のデータを投入したりしていると、翌朝の処理がえらく遅いとか（確か、統計情報収集はデフォルトで 22:00 から開始するはず）。
> 「DBサーバで処理すると、DBサーバの負荷が増える」
これって、CAP 定理を勘違いしているような気が。RDBMS はスケール・アウトしにくい、というのは事実でしょう。RDBMS は、Consistency と Availability とを優先して選択しているから（でないと、ミッション・クリティカルでは使えないはず）。
しかし、そんなに、スケール・アウトしたい処理って、一体どんな巨大処理なのか。数千万件とか数億件とかのレベルの話じゃないと思いますけどね。
今どきの PC サーバ って、メモリが 8GB とかありますから、数百万件程度なら、メモリに全部載るんですよね。数百万件の集計 SQL を 2 回 続けて実行すると、1 回目 が数分、2 回目は 0.1 - 0.2 秒くらいで返ってきます。1 回目のクエリで、DB バッファに全件載ってしまうのですよね。
ronさん、おはようございます。
DBサーバで処理すれば、DBサーバの負荷は高くなるけれども、スケールアウトはできる。であれば、ウソではないです。
おっしゃるとおりで、企業のシステムでムーアの法則を超えて成長したのなら、スケールアウトするための作り直し費用は普通は出ます。ムーアの法則を超えるほどでもないのに、スケールアウトしなければならなくなるなら、最初の設計がおかしいと言うのが私の考えです。
昔、メモリーが少ないから遅いって言って、お客様に増設させたくせにINITxxxx.oraが初期値のまんまって笑えないのが結構あったな～。
Oracle7ぐらいの時代ですが、当時はメモリーが高かったのに、少なくとも、3回は見た。呆れてモノもいえんというか。
saki1208
生島さん、おはようございます。
saki1208です。
7.1の当時はサーバー用途のパリ付きメモリを増設しようとすると128MBとかにするのにサーバーと同じ位の値段だったりしましたよね。
PCサーバーですが…
当時は周りにわかる人がいなくてかなり苦労しました。TKPROFとかもよく使ってましたね。
昔と比べると随分チューニングし易くなりましたね。
インドリ
おはようございます。
やっぱりO/Rマッパーは一度は作りたくなりますよね（笑）
正しくはしかですね。
それはさておき、何度か話題になっているので書きますが、オブジェクト指向とSQLが合わないと言っている人は多分オブジェクト指向の事を十分に理解していないと思います。
オブジェクト指向といっても、オブジェクト指向分析・オブジェクト指向設計・オブジェクト指向プログラミングの三種があり、さらに各種沢山あります。
オブジェクト指向は統一されていません。
ここで重要なのは、オブジェクト指向の達人たちがSQLを否定していない事。
システム全体から俯瞰した場合、RDBMSも一つのオブジェクトであり、オブジェクト指向分析をちゃんとすると、SQLなんてインタフェースの一種であり何にも困りません。
オブジェクト指向はデータ＋プロセスだから、データ中心アプローチとプロセス指向アプローチも使用するのが当たり前です。
なので、SQLなんて別に気になりません。
それもオブジェクトの一部であり、虫眼鏡でオブジェクトをのぞいている感覚で設計出来ます。
おそらく、オブジェクト指向と合わないなんて言っている人は、オブジェクト指向プログラミングの一種で物事をとらえていると思います。
分析さえちゃんとすれば、別に気にする必要はなく、むしろ使うべきです。
使わないという事はif文を一切使わないオブジェクト指向プログラミングと同じ行為です。
SQLから逃げれば余計にシステム設計が複雑になります。
SQLから逃げる人は余計に複雑になっている事すらしらない。
厄介なものです。
oumi
>「DBサーバで処理すると、DBサーバの負荷が増える」という人がいます。
言います（＞＜）ノ
>論理的には間違いです。
でも論理的には正解でしょ？
つまり論理を展開する「場」「条件」の問題なんだから・・。
なので、
>地球は平らだといってるぐらい、技術者として恥ずかしい意見です。
この下りは余計。
本記事の趣旨は重々理解していますが、「理解できる人のみ解ってね」ていう部分が多くて、若干の不親切さを感じました。
多分、経験の少ないデベロッパーの中には、誤った理解を持つ人もいるかも知れません。
そういう意味では、今回の記事には大いに不満があります。なんていうか、「オカズ」の付け方が良くないと思った。
エントリーポート
生島さん、こんにちは。
それほど、SQLを嫌がるなら、何でオブジェクトデータベースを発展させようと
考えないのですかね～。
O/Rマッパーを発展させるよりかは、すっきりすると思うのですが・・・
EarlGrey
一般向けのWebシステムをメインで扱ってますが、
処理をAP側に寄せたい！という話が結構あったりします。
一般向けだと負荷動向が読みきれないですので、
負荷追従のすばやさというか、処理能力を追加しやすいほうに、
たくさん処理をさせよう、という話に落ち着くことが多い。
DB側のスケールアウトももちろん可能なんですが、
AP側は負荷分散装置の下においてあるのが普通なので、
(WebSphereとかだとM/Wで負荷分散してたりしますが)
いざとなったら箱を用意してつなぐだけですみますし。
この辺りのハンドリングのよさは、運営を考えると結構魅力です。
逆に過剰能力になったら減らせますしね。
実行計画は･･･PostgreSQL7時代のJOINはひどかった！
直積演算とか普通でしたから、当時から血眼でチェックしてました。
その点、今のプランナはPostgreSQLでもMySQLでも本当によくできてますね。
O/Rマッパーから出るSQLは正直、まだまだだと思ってます。
ただ、個人的には期待している分野なので、今回の記事は結構ショックでした(笑
Web系開発チームはSQLに強い人が少ない(弊社だけ?)ので、
実際に発行されるSQLを意識している人は少数ですね。
せっかく張ったインデックスがまったく使われてないとか、
そもそもインデックス、どこ？というレベルの話もあったり。
まあ、昨今のメモリ量なら、インデックスなくても早いことが多いけど･･･(苦笑
インドリさん、こんにちは。
大きく考えたら、DBをオブジェクトと考えれなくはないですけれど、そりゃ設計粒度としては大きすぎるような気もします。
というか、私の考え方はオブジェクト指向言語側から見れば、そうなるのですけれど、ロジックの大部分がSQLという訳の分からんブラックボックスになるのがイヤなのでしょう。
「訳が分からん」のなら、分かるようになればよいというだけの話ですけどね。
saki1208さん、こんにちは。
当時、駆け出しの私がキッティングしたPCサーバのハードディスクが1台70万でしたからね。
何回も放電を確認して触ってました。
私はもっぱら、マニュアルとNiftyServeで情報収集していました。
周りで訊ける人は一人もいなかったな～。
oumiさん、こんにちは。
イライラだらけの文章で申し訳ない。
間違いですけど、正解というのは、そうかも知れない。
本当に分かっている人が書けば、確実にDBの処理は減りますけどね。
技術者を説得するのは無理だと……。
お客様をつかまえるしかない。
神頼みです。
EarlGreyさん、こんにちは。
SQLが弱いというのはどのレベルをいうのかは分からないけれど、インデックスがしっかり当たっていれば、DBサーバの処理はDBサーバで処理した方が減ります。
APサーバの方がこけやすいので、APサーバを二重化するのは当たり前と私は考えていますが、APサーバに処理させた方が、早くAPサーバはパンクするでしょう。
これは疑いようのない事実です。
DBサーバで処理した方が、APサーバの負荷も軽く、DBサーバの負荷も軽いのですから、より長く耐えられるって言ってるのですけどね。
DBサーバのスケールアウトは大変ですけれど、APサーバで処理した方が、その大変な作業が発生する可能性も高まるわけです。
ただし、実行計画を見て、ちゃんとSQLのチューニングしていることが前提ですけれど。
しかし、DBがパンクする多くのパターンというのは、SQLのチューニングができてないパターンで、「APサーバで処理している」と言っているシステムの方がよくDBサーバがパンクしてますが、コアになる部分をストアドプロシージャで書き直したら、何の問題もなく動くなんてのはザラですけどね。
一番酷かったのは、2ヶ月掛かってO/Rマッパーで書いたシステムが、本番の数百万件のデータを入れたら、2時間返って来ないってのでした。もちろん、DBサーバにも、APサーバにも相当負荷が掛かっていた。半日ぐらいでストアドプロシージャで書いたら1秒以内で返ってきたけど……。
ビガー
ビガーです。こんばんは。
だいぶ批判的な内容なので、ご容赦くださいませ。
実行計画を見ないエンジニアってそんなにいるんですね、少なくとも私の周りには一人もいません。なぜなら、見方を教えてしまえば済む話だからです。
ルールベースの時代ならイロイロとありましたけど、本文でも挙がっています通り、現実的にはデータ量とカーディナリティに気をつけてインデックスをつけるくらいじゃないんですかね。だから大層な話ではまったくないと思います。
あと、O/Rマッパについてですが、結果セットとエンティティをマッピングする工数って、それなりにかかった記憶があるんですが、ストアドとエンティティやDTOのマッピングってそんなに無視できるものですか？
また、O/Rマッパ(私はhibernateが好き)は、キャッシュ(セッションキャッシュやクエリキャッシュ)で実現している無駄なSQL発行の回避、同時実行制御(楽観的ロックや悲観的ロック)の煩雑さを軽減できるすばらしいモノだと思っています。
このあたりをどう実現しているのか気になります。
ビガーさん、こんばんは。
確かに大層な話ではないですが、ポジションの問題もあるからね。
弊社は一括で請けるので取れてもサブシステムなんですね。100人のプロジェクトでトップに入れたら良いけれど、5人のサブシステムでは、影響範囲は5人ですからね。イロイロ引き連れて上に入るのは大変なのです。
O/Rマッパーは、何度も書いているとおり、ストアドプロシージャの結果をマッピングするのに使ったりはなんの問題もないですよ。
弊社でも使います。
SQLを隠蔽する目的がおかしいと言ってるだけです。
インドリ
おはようございます。
>大きく考えたら、DBをオブジェクトと考えれなくはないですけれど、そりゃ設計粒度としては大きすぎるような気もします。
いえ、【オブジェクト指向分析】はそんな粒度で考えます。
そして、オブジェクト指向設計時に、顧客テーブルが必要ならば、顧客オブジェクトのデータだと考えます。
データの永続化が必要ならばDB、不必要ならばメモリ上に置く（コードで）と言う事なのです。
だからこそ、今のO/Rマッパーの使い方は余計なだけなのです。
オブジェクト指向設計的に、余計な層が増えているだけです。
オブジェクトも一つの集合として考えられますので、SQLから逃げている人はオブジェクト指向もちゃんと習得していないと思われます。
すなわち、本来はO/Rマッパーは開発者の頭の中だけでするものです。
オブジェクト指向をするからSQLから逃げるは、言い訳として成立しません。
業界全体の傾向として、技術者を甘やかしすぎだと思います。
生産性を上げているつもりなのでしょうが、技術者の質が低下して反対に生産力が落ちている節があると思います。
（株）ポチ
O/Rマッパーについては最近あまり使っていないので進化の具合を
知らないのですが、過去にEJB2.0（EntityBean）などを触った時
は散々な思いをしました。
試行的なプロジェクトだったので色々好き勝手実験できましたが
あれからO/Rマッピングにはちょっと手が出ません。
なんというか、謳い文句からして詐欺じゃないのかと思うくらいです。
「自動生成で工数減」「SQL隠蔽でSQL知識不要」
結局SQLに精通していないとこりゃひどい目にあうな～と。
士郎
こんにちわ
＞ポチさん
>なんというか、謳い文句からして詐欺じゃないのかと思うくらいです。
>「自動生成で工数減」「SQL隠蔽でSQL知識不要」
同感です。この文句はいかにもあやしいというかありえないですね。
SQLをそもそも隠蔽できるとは思ってませんし、ましてや知識が不要なんて（笑）
ビガー
ビガーです。こんばんは。
前回コラムのコメントがすごい数になってますね、お疲れ様です。
>SQLを隠蔽する目的
これがORMの主目的では絶対にないと思うのですが、根拠はどこにあるんですかね？
ついでに該当するORMの実装を教えてもらえますと助かります。(自社開発以外ね)
まりもさんとの不毛な議論の後のようなので、無視してもらってもいいですが。
がる
がるです。
感じた事、気になった文言をつれづれ、っと。
> つまり、SQLはプログラムというよりも設計書、実行計画がプログラム（詳細設計かな）ともいえるものなのです。RDBMSにとってトランもマスタも関係ありませんから、汎用的に判断させアクセスパスを決める処理は複雑で重い処理です。
> しかも、単純なSQLでループを多用して作ると、コンピュータは律儀ですから、毎回、実行計画を考えます
> RDBMSは「複雑な処理をプログラマがループを書かずにできるように」という思想の元に開発されているのですから、その思想通り使わないと威力は発揮しないどころか、デメリットばかりになってしまう。
> ある規模の複雑な処理になったらSQLで書かねばならない。
というご発言を前提に。
ちなみに、おそらく私のスタンスは概ね「RDBを使いたくない」なのだろうと思います。
ただ、現実問題として現状、RDBMSよりもシンプルなデータベース(というよりはぶっちゃけデータストア)システムが、顧客への提案ベースでは(実績の観点から)載せにくいので。
故にやむを得ず、RDBMSを使っている、というのが現状です。
このあたりは
> 何度も書いているとおり、「RDBMSを使わない」という考え方はまったく否定しません。
と書かれているので、そのあたりは見解が一致しているのだろうと思います。
> できない人って……「そもそも、SQLができない人がプロを名乗っている」ということがおかしくないか？ ということを、わたしは何度も書いているわけで「できることが常識である」という立場です。
常識、という言葉自体が非常に気にはなるのですが。
まぁ「プロとして名乗れるレベル」に対する個人的一見解なのだろう、と思っています。
このあたりは人によっても環境によっても差違があるものですし、是とも非とも、というラインだと思いますので。
(昨今の趨勢から考えて、オブジェクト指向自体は、分析/設計/プログラミングの各レイヤーで、ある程度必須だとは思いますが)。
> 「DBサーバで処理すると、DBサーバの負荷が増える」という人がいますが、論理的には間違いです。
これには明確に異を唱えたいと思います。
「DBサーバで処理をすればDBサーバの負荷が増えて、Webサーバで処理をすればWebサーバの負荷が増える」は、「どの程度増えるか」はともかく、事実ですよね？
「DBサーバで処理をしてもDBサーバの負荷は全く増えない(０である)」または「DBサーバで処理をすればDBサーバの負荷が減る」のであれば、話は別ですが。
> RDBMSは顧客に浸透しきっているので大手では無理ですけれど、ニッチなベンチャーとしてはありかもしれない。
例えば。手っ取り早く、Googleさんは、コア部分のシステム(検索とかgmailとか)に、RDBをつかってらっしゃらないと思うのですが、そのあたりについてはどう思われますか？
もっとも、上述が「考察や事実よりも過去の実績などを重視する大手では無理」という趣旨でおっしゃっているのであれば、ほぼ全面的に同意いたしますが(ほぼ、の残分は「違うといいなぁ」という期待分だと思ってください(苦笑))。
> DBサーバで処理すれば、DBサーバの負荷は高くなるけれども、スケールアウトはできる。
この「スケールアウト」は、クラスタリング(多数の低廉なコンピュータを、特別なソフトウェア・ハードウェアを用いて、あたかも1つの大きなコンピュータとして利用できるように接続すること http://ja.wikipedia.org/wiki/%E3%82%AF%E3%83%A9%E3%82%B9%E3%82%BF%E3%83%AA%E3%83%B3%E3%82%B0 )によるスケールアウトでしょうか？
それとも「クラスタリングをしない」スケールアウトでしょうか？
一応、念のため。
Webサーバの場合、ロードバランサが必要ではあるのですが(DNSラウンドロビングでもよいですが…それはちょっと、議論の俎上に載せるには少々、なんぼなんでも、なので)、L3スイッチに対応出来るような作りに(プログラム側を)していると、かなりの台数まで耐えられます。
L7スイッチが必要な場合、ロードバランサがボトルネックになる事多々、ではあるのですが。
> しかし、そんなに、スケール・アウトしたい処理って、一体どんな巨大処理なのか。数千万件とか数億件とかのレベルの話じゃないと思いますけどね。
少し大きなサイトの「アクセスログ解析」で、非常に丁寧に処理をしたい、というようなケースの場合(過去数年分のデータ、など)。
やり方によっては、割と簡単に「二桁の億」に数値が届いた記憶があります。
ほんの一例ですが。
OR/M(ORマッピング)については…個人的には「あんな激しい隠蔽度が必要かどうかは疑問」だというスタンスなので、あんまり是とは思っていないですね。
複雑なデータ構造を持つのであれば「それを意識してプログラミングして欲しい」と思うほうですし。
あと、何度か俎上に載っている「オブジェクト指向とRDB」ですが。
片や「集合演算論」、片や「オブジェクトの相互作用」ですので(まぁ、現在の「クラス指向」を前提に考えると、いわゆる「メッセージパッシング」を前提に語るのはそれはそれでどんなもんかとは思いますが)。そのあたりの本質から考えると、個人的には「親和性は低い」と思っています。
ただ「低い」だけであって「ない」わけではないので。双方を「理解した」上で無理なくつなげることは、ある程度まで可能だとは思っていますが。
以上、長文な上に散文で恐縮ですが。
インドリさん、こんばんは。
まぁ、私はDBはでっかいブラックボックスと見て設計するのですけどね。
DOAとOOAのハイブリッドと思っています。
そこも含めてオブジェクト指向分析というかどうかは、私にはよく分かりません。
ビガーさん、こんばんは。
何というか、「DBの負荷が増えるからストアドプロシージャは15％まで」（意味は不明）とか、億を超えるシステムでもJOINをしたいときは申請書を書け。とか、イロイロあるのです。
世の中は広い。
そんなプロジェクトの上に立つ人はオブジェクト指向の信者です。
がるさん、こんばんは。
基本、SIerとして書いていますので、噛み合わないですね。
日本の上場企業約4000社のうち、がるさんの考えるシステムをお持ちの会社は、何社に当てはまると思いますか？せいぜい上位でもない100社で、中小企業においてはほぼゼロです。
そんな100社も、基幹システムの部分においては、ほぼ汎用機かRDBMSを使っています。
一般論を話するのに、1％を満たさないレベルを議論の対象に含めないというのは当たり前じゃないですかね。ニッチというのは割合なんですよ。
単機能で負荷が大きいのに、本文に書いたような不要に大きなオーバーヘッドがあるものを、敢えて利用するのはお馬鹿です。
それを理解して、RDBMSを利用するなら、十分に使い切れるスキルが必要です。
RDBMSを（隠蔽しようと）使うならば、SQLのスキルは必須で、常識と言える訳です。
ちなみに、利用者の立場で分かることは、Google Analyticsは1時間前後のディレイがあります。
相当にでかい（世界一じゃないかな？）アクセス解析の仕組みで、対象レコードが何百億、何千億レコードあるかは知らないし、それをどのタイミングで消しているのか、別のサーバで永久保存しているのか私は知りません。
ただ、はっきりしているのは、Google Analyticsは非常に細かいアクセス解析をしていますけれど、生データに直接アクセスしていません。（してたらディレイはありません）
何十億レコードの解析をするのに、Google Analyticsよりも細かいアクセス解析を、ディレイなしに生データにアクセスしてリアルタイムの解析をしていたのですかね？
だとしたら、SEとしての設計・提案能力に問題ないですか？
元データが10億ぐらいのアクセス解析なら、条件によってはRDBMSの方が効率的の可能性があると思いますけれど。少なくとも、その条件であれば工数は明らかにRDBMSに軍配が上がるね。
>がるさん
私のコメントに対するもののようなので。
>少し大きなサイトの「アクセスログ解析」で、非常に丁寧に処理をしたい、というようなケースの場合(過去数年分のデータ、など)。
>やり方によっては、割と簡単に「二桁の億」に数値が届いた記憶があります。
>ほんの一例ですが。
あのー、過去数年分のアクセスログ解析 っていうのは、1 回限りのバッチ・ジョブでは？
データが変更されることは、もうないわけですよね。
スケール・アウトというのは、あくまで、オンライン・リアルタイム処理を念頭においているのだと思いますが。データが変更されないのなら、データを分散して処理するのは簡単ですよね。
せっかくですので、1点、別の論点について。
「APサーバに処理を寄せる」というのが、具体的にどういうことをするのか、私にはイマイチ想像できません。
DB サーバにアクセスせずに、AP サーバだけで処理できるものは、AP サーバで処理する、というのなら話はわかりますけど、それは当たり前の話なわけで。DB サーバで処理し、さらに、APサーバでも処理する、となると、明らかに非効率ですよね。
たまに、大量のワークテーブルを使っているような、えらく非効率なアプリを見かけることがありますけど、もしかして、そういうのを念頭に置いているのでしょうかね？ ワークテーブルは極力使わず、AP サーバで処理できるものは、AP サーバで処理する、という話なら、それも当たり前の話だと思います。
生島 さんは、そうした、AP サーバに寄せられるような、非効率な処理は存在しない設計を前提に話をされているのだと思いますけど。そうした非効率な処理は、アプリに存在しないとして、それ以上の何を AP サーバにやらせようとしているのか、という問題なのでは？
ronさん、おはようございます。
単純にDBサーバでできる処理をAPサーバでしない。
ワークテーブルは基本的に使わない。
DBサーバは永続化のためにあるので、ワーク（永続化不要のデータ）をDBサーバに置いたらいけないですよね。
こういう前提が抜けているから、噛み合わないのかな。
上にも書いたけれど、JOINが申請式とかそういうところもあるし、初級シスアドレベルができなくてもプロであると主張する人も、現実に存在します。
世の中広いので、常識のラインは個々にありすぎて噛み合わないから、くどいけれど、初級シスアドレベルよりも少し高いぐらいのところにプロの線引きをすればどうかと。
国家試験の過去問でチェックできるのですから、お客様がそれをやってくれたら、かなり業界は良くなると思っています。
がるさん、おはようございます。
夜に書いているのは、基本ベロベロに酔ってるので……。抜けてました。すみません。
>> 「DBサーバで処理すると、DBサーバの負荷が増える」という人がいますが、論理的には
>> 間違いです。
> これには明確に異を唱えたいと思います。
> 「DBサーバで処理をすればDBサーバの負荷が増えて、Webサーバで処理をすればWebサーバの
> 負荷が増える」は、「どの程度増えるか」はともかく、事実ですよね？
> 「DBサーバで処理をしてもDBサーバの負荷は全く増えない(０である)」または
> 「DBサーバで処理をすればDBサーバの負荷が減る」のであれば、話は別ですが。
DBサーバで処理すると、APサーバで処理することに比べ、DBサーバの負荷は減ります。
これでよろしいでしょうか？
文脈で分かると思いますけれどね。
政府がお金をバラまけば景気が良くなる。
は正しいですよ。
しかし、政府がお金をバラまけば、バラまいた金額以上の経済効果が出る。
はほぼ間違いでしょう。
つまり、「政府がお金をバラまけば景気が悪くなる」は正しい。
前後でその内容を説明しているのですから、文脈で分かるレベルと思いますけれど……。
こんにちは。
> 単純にDBサーバでできる処理をAPサーバでしない。
付け加えると、単純に AP サーバでできる処理を DB サーバでしない、という逆もまた真ですね。例えば、HTML フォームの解析、入力データの形式チェック、入力文字列をパーズして入力データを抽出する、など。
当たり前でしょ、という話なんですが、往々にして、当たり前が当たり前でないのがこの業界ですからねえ。
> 上にも書いたけれど、JOINが申請式とかそういうところもあるし、初級シスアドレベルができなくてもプロであると主張する人も、現実に存在します。
私もこの業界に 10 年以上いますので、もちろん、存じております ^^)
すみません、もう 1 点。
生島 さんの、
> DBサーバで処理すると、APサーバで処理することに比べ、DBサーバの負荷は減ります。
というのは、より正確には、
DB サーバのみで処理 vs DB サーバ ＋ AP サーバで処理
なら、前者の DB サーバのみで処理する方が、DB サーバの負荷が減る、という意味だと思います。
前者の方がレスポンス・タイムが短くなりますから、DB サーバに処理が滞留しにくくなる。後者は、レスポンス・タイムが長くなるから、DB サーバに処理が滞留して、DB サーバの負荷が上がります。AP サーバが、カーソル、ユーザメモリ等の DB サーバのリソースを、長時間掴んでますから。
がる
がるです。
簡単に、いくつか。
> がるさんの考えるシステムをお持ちの会社は、何社に当てはまると思いますか？
さて。全国津々浦々のシステム会社さん全てにヒアリングをして回っているわけではありませんので。
ただ「私の手元には、それなりの割合で存在していた」というだけの事です。
また。
私は「いろいろな見解に触れたい」が前提なので、一般論にはあまり興味がないので。
もし生島勘富さんが「一般論を基準にされている」のであれば、確かにかみ合わないのだろうと思われます。
# 私が欲しいのは「一般論/一般的見解」ではなくて「目の前のお客様に適した考え方」なので。そうして、それは千変万化する、幅のあるものだと思っておりますので。
# 相手の姿が見えない「一般」というものには、あまり興味がありません。
> 何十億レコードの解析をするのに、Google Analyticsよりも細かいアクセス解析を、ディレイなしに生データにアクセスしてリアルタイムの解析をしていたのですかね？
> だとしたら、SEとしての設計・提案能力に問題ないですか？
依頼の背景を。つまり「どういったお客様から、どういったコスト感で、なにを目的にして、どのように依頼をされたか」をすべてご存じな上でのご発言でしょうか？
そうであれば、なにも申し上げる事はございません。
上述に関して申し上げれば。私は、お客様とそれなりの期間のヒアリングの後「それであればこの方法は如何でしょうか？」といういくつかの提案を行い、お客様がそのうちの一つをチョイスされた、という経緯がありますので。
> 前後でその内容を説明しているのですから、文脈で分かるレベルと思いますけれど……
私は「明文」という言葉が好きなので。
「暗黙のうちに理解して欲しい/理解してくれるだろう」という発想は、申し訳ないのですが少々私には把握しにくい考え方になります。
> あのー、過去数年分のアクセスログ解析 っていうのは、1 回限りのバッチ・ジョブでは？
簡単に答えだけ。「ちがいます」。
要求とその背景には「ご自身の想像以外のものがある」ことを認識される事をお勧めいたします。
> がる さん
一方で、
>「暗黙のうちに理解して欲しい/理解してくれるだろう」という発想は、申し訳ないのですが少々私には把握しにくい考え方になります。
といいながら、他方で、
> 要求とその背景には「ご自身の想像以外のものがある」ことを認識される事をお勧めいたします。
というのは、おっしゃることが矛盾していませんか？
私には、アクセスログ解析で、アクセスログ・データに変更を行なわなければならない必要性というのが、わかりませんので、なぜ必要があるのか、という点をご説明いただけないのなら、話はここまでですね。
がるさん、ronさん、こんにちは。
まぁ、お互いにプロですから、顧客に関することをダラダラと書くわけにはいかないのですから、一般論にならざるを得ない。
私の言ってることは中企業（小零細企業ではコスト的にカスタムシステムは無理）以上のほとんどの企業に使える一般論です。
IT業界にもインフラ屋さんとか、組込み屋さんとか、RDBMSにかかわらないプロは大勢存在します。
しかし、イヤイヤだろうが、隠蔽しようが、RDBMSに関わるならSQLは必須で、立場によっては相当深く知る必要がある。
数十億レコードで、毎回アクセスしていることはありえないけどね。
1バイトのレコードでギガの単位ですが、結構なレコード長がいりますから、簡単にテラを超えるサイズになります。
しかし、アクセス解析はRDBMSの方が向くでしょうね。
生データは圧縮して別メディアに逃がせばいいし、圧縮したファイルの管理テーブルと対象レコードを特定してブラウズする仕組みを作ればすむ。
数年で数十億レコードということは、1日でメガヒットクラスのサイトと思われ、@ITよりははるかにデカイ（苦笑）ですけれど、それなりのSQLのテクニックがあれば、1日分の集計＆サマリー更新処理なら、今のサーバなら10分あれば終わるし、1時間のディレイで処理するなら、対象は集中してもせいぜい数万～50万レコード、であれば数十秒～数分で終わるでしょう。それぐらいで終わらなかったら、Google Analyticsは動くわけがない。
しかし、ないとは思うけれど、RDBMSでログを採取していてAPサーバで集計・解析してたとしたら、どえらいことになっているでしょうね。夜間バッチで12時間とかありそう。それも、DBサーバにも付加をかけ続けるから、ログの書き込みがサービスのレスポンスに影響を与えてたりしたら笑えないね～。
工数もAPサーバで処理するのとは比べ物にならないぐらい少ない。
生島さん、こんばんは。
> まぁ、お互いにプロですから、顧客に関することをダラダラと書くわけにはいかないのですから、一般論にならざるを得ない。
そのとおりですね。
ただ、禅問答みたいな抽象論で議論しても不毛とも思うのですよ。架空の例でもいいですから、ある程度、具体例に即してないと。
ちなみに、日本最大級のデータ処理システムといわれる、社会保険庁の年金システムで、約 1 億件 くらいらしいですね。これは COBOL のレコード・データでしょうから、入れ子のレコードを展開して、RDBMS に入れるとすると、数百億件くらいにはなりそうですね。
がる
がるです。
To ronさん
「私には、アクセスログ解析で、アクセスログ・データに変更を行なわなければならない必要性というのが、わかりませんので」と書かれておりますが。
アクセスログ・データに変更を行なわなければならない、とは、一度も申し上げていないかと存じますが如何でしょうか？
To 生島勘富さん
> 私の言ってることは中企業（小零細企業ではコスト的にカスタムシステムは無理）以上のほとんどの企業に使える一般論です。
なるほど。「中企業以上の企業で使える一般論」というほどの豊富なご経験が、少々羨ましくはあります。
私はおそらく、(無論、いわゆる大企業とよばれる企業さんともお仕事はさせていただいておりますが)小零細企業と呼ばれる規模の案件も多く。
また、その経験上ですと「一般論」と言えるほどの傾向は、正直見あたらなかったので。
生島さん、お疲れ様です。
先程までこちら
http://el.jibun.atmarkit.co.jp/g1sys/2009/01/
を読ませて頂いておりました。
なるほど、主張は一貫されてますね。
コメント欄まで読破しましたが、そこでの議論は直近のコラムと同じ内容（笑）
2009年の始まりと終わりで、問答が同じなんですね・・・
やはり原稿料貰ってるわけでもなく聖人でもないのですから、時には『過去ログ読め』と言いたくなるだろうなぁとお察しします。
私も『SQLの重要性を伝えたい』と、生島さんの立場に成りきって考えた時、もう社会からの淘汰に期待したくなりましたよ。淘汰が推進されて”ホンモノ”に希少価値が付けば、基準価格も今より高くなるのかなぁと考えたりします。
地位向上ってヤツですね。
100％雑談でした。
それでは。
> がる さん
> アクセスログ・データに変更を行なわなければならない、とは、一度も申し上げていないかと存じますが如何でしょうか？
では、アクセスログ・データの変更はない（読み取りだけ）、ということでよろしいですか？ 元データが変更されることがないことがわかっているのに、数十億件もの集計を毎回やり直す必要があるのはなぜでしょう？
「1 回限りのバッチ・ジョブ」であることは否定されましたよね？ 「1 回限りのバッチ・ジョブ」というのは、文字通り 1 回しか走らせない、という意味ではないですよ。念のため。定常業務（毎日・毎月・毎年継続してやるような処理）ではなく、非定常業務（データ移行のように、1 度仕事が完成したら 2 度とやる必要はない）である、という意味です。
ビガー
ビガーです。おはようございます。
>世の中は広い。
>そんなプロジェクトの上に立つ人はオブジェクト指向の信者です。
何がいいたいのかよくわかりませんが、私の質問に応える気が無いと解釈しました。生島さんの狭い世界を理解するつもりもないけどね。(余計な一言)
これより下は、独り言なので無視してください。
今回の話(前回含)でよくわかったことが1点。
ORM(ORマッパね)を使いこなせている人がたぶん皆無に近い状況だということ。
もったいないなぁ。データアクセス層の設計とかって真剣にやってないのかな。というかそんなに性能要件が厳しくないのかな。
真剣にやれば、キャッシュの単位(セッションとかセッションファクトリの単位)に嫌でもフォーカスしないといけないから自然と目が向くはずなのだが。
そうするとhibernateやjbossの有難さがわかると思うんだよね。
といってもデファクトとして、使いこなせている人がいない状況というのは、廃れるしかないんだろうが、少なくともココ3年くらい私が携わっているプロジェクトでOSSのORMを使っていないプロジェクトは皆無なので、あり得ないはず。
飯のタネになりそうな気がしますわ。
ビガー
ビガーです。連投ですみません。
>ronさん
コメントを拝読する限り、高度なご経験をさせれている風に感じましたので、見解をいただけますと嬉しいです。
APサーバでの処理とDBサーバでの処理の棲み分けの話です。
5層モデル(UI/プレゼン/サービス/ドメイン/データアクセス)が前提なのですが、
以下でコメントされている処理は、プレゼンもしくはサービス層の話だと思います。
>付け加えると、単純に AP サーバでできる処理を DB サーバでしない、という
>逆もまた真ですね。例えば、HTML フォームの解析、入力データの形式チェック、
>入力文字列をパーズして入力データを抽出する、など
サービス、ドメイン、データアクセス層で無駄なデータアクセスを回避する手段として、キャッシュするアーキテクチャを設計することもあると思いますが、それぞれでどういったアプローチをさせれていますでしょうか？
私は、サービス層に位置付くレイヤにインメモリトランザクション(実際はMapとか使う)とDBトランザクション(ORMを内部で利用)を統合するアーキを実現したりします。
余談ですが、インメモリの部分って、Google等々が内で実現していることに結構近いんじゃないかなぁ～と勝手に推測したりしています。
それとDBサーバで処理させるべきコトって、オンライン処理では、永続化目的以外は「ない」と思っています。というか性能要件がきつい場合、するべきではない。
DBサーバで処理するべきことって、具体的にどういう処理があるのか、ご意見いただけますでしょうか？
インドリ
ビガーさんこんにちは。
面白そうな話なのでちょっと参加させてください。
>ORM(ORマッパね)を使いこなせている人がたぶん皆無に近い状況だということ。
8年ぐらい前のADOの時代に、データライフサイクルオブジェクトと名付けたフレームワーク（今のADO.NET+LIQに近いもの）を自分で作って、よーくわかったのですが、キャッシュ以外には無意味だと言う事です。
最適化したSQLを発行するには、プロジェクトに関する知識が必要です。
しかし、自動生成するSQLにそれを考慮しろというのは、何らかの形でメタデータを指定しない限り不可能であり、メタデータを付加する仕組みを作るのは労力の方が大きすぎるので素直に作った方がよいです。
ちなみに、私がO/Rマッパーを自作したわけは、インメモリDBを作って、遠隔地のデータベースに結果を繁栄させるためですので、SQLを知らない人にためにしようとは思いませんでした。
というのも、覚える方が早いし、プロジェクトの知識は人間が持っているしね。
それで、私は理解している人は皆無とは思いませんが、ADO.NETなどの技術がインメモリのためのものだと言う認識が世間で広まっていないのを感じます。
WAN規模のシステムを構築すれば分かると思うんだけど、何故広がらないのかな？
やはり分業化の弊害でしょうか？
>サービス、ドメイン、データアクセス層で無駄なデータアクセスを回避する手段として、キャッシュするアーキテクチャを設計することもあると思いますが、それぞれでどういったアプローチをさせれていますでしょうか？
私の場合は基本的に考え抜いたストアドを使います。
そうしないと、トランザクションの正規化が出来ないし、後で変更になった時の労力などを考えると、ロジックを一元化したいです。
それに、複数言語を使用するプロジェクトでは、素直にストアドの方がいいです。
もともと、データベースはデータの整合性をチャックするための技術体系ですので、積極的に使用した方が楽です。
それを基本方針とし、何もデータを送りたくない場合は、ローカルでチェックを行うロジックを組みますが、整合性チェックオブジェクトを独立して作り、変更に強い仕組みにします。
>それとDBサーバで処理させるべきコトって、オンライン処理では、永続化目的以外は「ない」と思っています。というか性能要件がきつい場合、するべきではない。
私はトランザクション処理のためにデーターベースは必要だと考えております。
ACID特性を保証するにはデータベースがないときついですよね？
インドリ
誤：チャック
正：チェック
> ビガー さん
こんばんは。
> サービス、ドメイン、データアクセス層で無駄なデータアクセスを回避する手段として、キャッシュするアーキテクチャを設計することもあると思いますが、それぞれでどういったアプローチをさせれていますでしょうか？
キャッシュというのは、DB からの読み取りを、AP サーバのメモリにキャッシュ、と考えてよろしいですか？
やってないですね。AP サーバに static な状態を持たせたくないです。ステートレスにして欲しい。
DB データに別のクライアント（Web AP サーバ 以外の DB クライアント、例えば CTI システムとか）から変更が入ったら、DB データの変更を AP サーバが検出して、再キャッシュとかするのでしょうか。で、トランザクションはアボートして、リトライ？
あるいは、Web AP サーバが DB サーバを占有できる前提ですか？
> それとDBサーバで処理させるべきコトって、オンライン処理では、永続化目的以外は「ない」と思っています。というか性能要件がきつい場合、するべきではない。
> DBサーバで処理するべきことって、具体的にどういう処理があるのか、ご意見いただけますでしょうか？
「永続化目的」というのは？ 書き込みしかしない、ってことですか？
例えば、オンライン・ショップで、商品を注文するとしますよね。で、商品在庫の引き当てを行なうために、DB の在庫データを読みにいくのは、「永続化目的」の範疇でしょうか？
みなさん、こんばんは。
酔ってるのでまとめですみません。
ronさん
出来る限り禅問答を避けようとはしてるのですが……すみません。
社会保険のように要件がはっきりしていたらRDBMSでもできなくはないけれど、COBOLから置き換えるべきというレベルにもないのよね～。
ログ解析ならRDBMSを選ぶよね～。
がるさん、こんばんは。
中小零細で、がるさんが心配されるような状況が発生するとは思えません。
大手でも100社もないと思いますけどね……。
一様のシステムにはならないけれど、ベースになる技術は同じで、私の考えは99％に適応できると考えています。
もちろん、現状で適応してはいないけれど、その原因は上流の技術者にあると。
ちょりぽんさん、こんばんは。
大変でしたでしょう。どうもありがとうございました。
ちょいちょいひどく荒れていますが、まぁ、精神も、会社も、生活も、一様ではないので、イラッとくることはあるのです。
ご理解いただければ、本当にありがたいです。
ビガーさん、こんばんは。
正直、APサーバのキャッシュが使える、使いたい、使うべき、という条件が私がやっているシステムでは非常に少ないので、更新がものすごく少ないマスタでしか使いません。
それは私が勉強不足なのかも知れませんが、全部のマスタをキャッシュしても、それが性能に対する影響は、現状のO/Rマッパーでするマイナスを解消することよりも遙かに小さいし、それが影響するならハードの見積が甘いと考えます。
必要になれば使うけれど、ボトルネックはそこにないから、まず、ボトルネックを責めることが私の考えです。
インドリさん、こんばんは。
そうですね。私も基本的にストアドにすべきと考えています。
次の記事に書きました。
（株）ポチ
こんにちわ。
O/Rマッパーについてですが。
業務系のシステムに多く関わってきたので特にそう感じるのかもしれませんが
複雑なSQLを発行するケースが非常に多いです。
（シンプルにできない設計が悪い？）
また、性能を最大限に出すためにRDBMS製品特有の関数などをゴリゴリ使います。
このような状況でO/Rマッパーを噛ませるとかなり苦しいことになりますね。
後者の製品固有の仕組みを使うってことに関しては一昔前まで、とりわけオブジェ
クト指向開発の中ではＮＧ的なやり方でした。
EJBやO/Rマッパーなんかは特にそういう目的もあるかと思いますがRDBMS製品
によらない開発ができて、DBが変わった時のインパクトも小さいよ、と。
でも実際DBを別の製品に変えるって、システム更改レベルなんですよね。
そういう恩恵って受けたことがない。
インドリさんも発言されてましたが、私も現状ではキャッシュ以外の有効性
（有効性があるけど、使わない有効性の方大きいという意）があまり感じられ
ません。
半端者なので深く追求してないだけなもかもしれませんが。
（株）ポチさん、こんばんは。
私も、O/Rマッパーは使っているけれど、使わない。
キャッシュも小さな範囲でしか使わない。
本当にDBサーバがボトルネックになるようなモノを手がけてないからかも知れませんが、馬鹿なループを直すぐらいで解決するモノばかりで。
ビガー
インドリさん、ronさん、生島さん、返信ありがとうございます。
コメント欄で個人的な興味を伺ってしまい、すみません。>生島さん
>インドリさん
正直私もORMまがいは、過去に実装しました。自分のは拡張性や利便性が薄いゴミでしたけど(苦笑)
>インメモリDB
インメモリにする弊害としては、どのタイミングで正とするデータと同期するかにつきますね。同期方法の基準として、どういうドメインモデル(トランザクション正規化とほぼ同じ意味かな)を構築するかや論理ERD、サブシステム分割の基準を決定するスキルがモノをいうと考えています。
あと、私が云っている「永続化」とは、CRUDを指しています。そのため、オンライン処理でロジックをDBに定義する意味はないと考えています。
>ronさん
>DB データに別のクライアント（Web AP サーバ 以外の DB クライアント、
>例えば CTI システムとか）から変更が入ったら、DB データの変更を AP
> サーバが検出して、再キャッシュとかするのでしょうか。
インドリさんへの返信でも書かせてもらいましたが、正とするデータとどのように同期するかの方針の問題で、再キャッシュの仕組みは、シンプルにしないと逆に性能が劣化してしまうので、データの特性に準じて、インメモリにするデータ構造は設計で熟慮します(実際には実装しちゃうけど)
>で、トランザクションはアボートして、リトライ？
私がやったプロジェクトでは、DBのデータを正と考え、オプティミスティックロック(私は後負けモデルと呼んでいます)を使って、当該ロックが取れなかったら、アボート(ユーザには別途通知します)して、DBデータを再キャッシュさせていました。
>あるいは、Web AP サーバが DB サーバを占有できる前提ですか？
上記の理由により、私の経験したプロジェクトでは、非占有です。
>「永続化目的」というのは？ 書き込みしかしない、ってことですか？
私の定義では、CRUDと同じ定義でReadも含みます。
在庫の引き当てのように複雑になりがちなReadや同一トランザクションで複数のテーブルを更新する必要がある場合は、データアクセス層で最適化(基本1発でDBの関数は極力使わない)したSQLを発行させます。
私の経験上、ストアドで処理させてもデータアクセス層で処理させても性能差はほとんどありません。保守性、拡張性を考えるとデータアクセス層での実装が現実的だと考えています。
>生島さん
>必要になれば使うけれど、ボトルネックはそこにないから、まず、
>ボトルネックを責めることが私の考えです。
おっしゃる通りだと私も思います。必要ないなら使わない。中途半端に使うのが最もよくないと。
今回の私の主張の趣旨は、ORMは実は枯れているものが意外にあるということでした。
すみません、生島さんのブログの軒先をあまり借りるのも心苦しいのですけど、これで最後ということで、ご容赦を。
> ビガー さん
お見事ですねえ。こちらの邪悪な意図を完全に見透かされてしまいましたか（笑）。大変失礼をいたしました。
こうなると、プロジェクト運営のスタイルの違いでしかないのかも。ビガー さんがリーダーなら、ビガー さんの方針に完全に従わせていただきますよ。
プロジェクト運営で、システムのコアの部分を、どこでコントロールするか、という問題が出てくるのですよね。ぶっちゃければ、下手くそがシステム（のデータ）を破壊するのを、どうやって防ぐか、という問題ですが。
私のやり方は、たぶん、生島さんのお考えにかなり近いです。RDBMS でコントロールします。DB への書き込みは、すべてストアド・プロシージャにします。アプリには、SELECT 権限と EXECUTE 権限しか渡さない。
先に例に挙げさせていただいた、注文と在庫の例ですけど。これ、並行処理の check-then-act 動作の典型例なんですよね。在庫が 1 つしかないところに、注文が同時に 2 つ入ったらどうなるか？ 下手くそのエンジニアなら、何も気付かずに、両方の注文を成立させてしまいそうですね。
私ならどうするかといいますと、例えば、check_and_store_order() というストアドを作成して、その中で atomic に実行するようにします。アプリはストアドを呼ぶだけで、DB 内のオブジェクトを直接ロックさせない。
書き込みを全部ストアドにする、というのは、まあ、一種の妥協の産物ですね。下手くそがプロジェクトに入ってくるのは防げないですけど。下手くそが、お客様の重要データを破壊する、という事態だけは何が何でも阻止する、という考えです。
生島さんの考えは読み取り側もストアドにする、という徹底したものですが、そこまでは辿り着いていませんでした。素晴らしいアイデアだと思います。が、現状、そこまで手が回りそうにないです（苦笑）。
がる
がるです。
これ以上あまり論を重ねても…と思われますので、端的に。
To ronさん
> アクセスログ・データの変更はない（読み取りだけ）、ということでよろしいですか？
Yesです。
> 「1 回限りのバッチ・ジョブ」であることは否定されましたよね？
これもYesです。
> 元データが変更されることがないことがわかっているのに、数十億件もの集計を毎回やり直す必要があるのはなぜでしょう？
さて。何故でしょうか？
そのあたりは適宜ご想像ください。
To 生島勘富さん
> 中小零細で、がるさんが心配されるような状況が発生するとは思えません。
あるかないかであれば、私には「過去に実際にありました」としか回答のしようがないのですが。
まぁ、或いは生島さんがご覧になると「別解が存在した」のかもしれませんね。
それでは。