こんばんは。
今日はORマッピングの功罪について話をします。
ORマッピングっていいなーと思ったのは
Seasar2 でのs2jdbc との出会いでした。
中規模くらいのシステムでしたが、本当にほとんどSQLを書かずとも機能追加できちゃうんです。
営業さんから
って仕様追加があってもなんのその。
一瞬で改修ができちゃうこともよくありました。
９割くらいはSQLを直に書かなくても、システムを作成できるっていいますが、
９５%くらいは書いていなかったと思います。
テーブルを作成すれば、そこから entity, service , manager まで自動作成してくれる
ツールもあらかじめ用意されています。
また、階層でリストのリストで表示したい時も、すぐに作成できます。
普通だったらSQLは１階層のリストしか取れないので、
とってきたデータを自分で加工しないとダメなんですが、
これがORマッピングだと、何も意識せずに、すぐにリストのリストのデータを作れちゃいます。
開発効率はだいぶ上がりました。
Seasar2 大好きです。
でも、ひょんなことから、ふとORマッピングに？？？？
と思う出来事がありました。
いつもの
確かに動いていない。
調査すると JAVAさんが暴走してるじゃないですか。
うーん、とりあえず、tomcat 再起動だ！！
はい、すぐに落ち着きました。
と伝えて、原因調査。
中規模のシステムだったので、全行動をろぐにとっていて、どれくらい時間がかかっているかも
すぐにツールからわかるようになっていました。
すると１分以上かかっている、機能がありました。
こいつか、、
ふむふむ
自分のローカルにデータを持ってきて、同じように実行してみると
すぐにJAVA様がお暴れになる。
何となくわかってきました。
データを取り過ぎてたんですね。
結合しまくって、さらにデータが多かったんです。
オブジェクトのリストが発生しまくって、JAVAさんも参っていたみいです。
ORマッピングは何も指定しないと、全カラムをとってきます。
そしてそれをオブジェクトに詰め込んで、という作業を全部自動でやってくれます。
めちゃくちゃメモリー食っちゃうんですよ。
なので大量データを扱うときは、あまり向いていません。
ここで初めて、ORマッピングの弱点を知りました。
この時は、ここの画面をあまり使用しないでください！ってことで終着しました。
社内システムだったんで、これでOKでした。
そして別の会社での話です。
そこの会社ではORマッピングは禁止されていました。
なんじゃこの会社。めっちゃ開発効率上がるのに、、
面倒くさいなー、開発効率めっちゃ悪いなー
なんて思っていました。
実際、開発にすごく時間が、かかっていました。
でも事件が起きたんです。
ある時サーバに負荷がかかっていることが、私の元に報告がきました。
WEBサーバとDBサーバの間の通信量がかなり圧迫していて、ボトルネックになっているとのこと。
原因を調査すると、そんな大したことをやっていることではない機能なんですが
呼ばれる頻度が非常に高い機能が原因でした。
この機能が select * from で無駄に全カラムとっちゃってたんですね。
必要なのは２カラムなのに、全部とっちゃってたんです。
このせいで、WEBサーバとDBサーバ間の通信量がハンパなくなっていたんです。
ここにカラム名を指定するだけで、ことは収まりました。
そうなんです。これがORマッピングを使ってはいけない理由なんです。
ORマッピングは、大は小を兼ねるの精神で全カラムを抽出します。
（カラム指定はできますが、そんなことしていたら、開発効率が下がっちゃうんで、意味がありません。）
これをアクセス回数が多い、BtoCのシステムでやっちゃうと
もうメモリやら、ネットワーク帯域やら、どれほど確保しても足りないんです。
ORマッピング信者だった、私もこれで目が覚めました。
BtoCや、多量アクセス、などのシステムには、ORマッピング向かないね、、、
開発で目指すべきところって、正直私の中で、効率化以外考えたことがなかったんですよ。
効率化することで、開発者は得をするし、いい商品が作れるし、
いいサービスを提供できる。
そんな単純な発想しかなかった私にはショッキングでした。
効率化を捨てでも、負荷対策を優先させなきゃいけないんですね。
それにはORマッピングとの決別が必要です。
便利ツールは、その分余計な処理をしてしまうことろがあります。
例えば sprint なんかめちゃ便利ですが、負荷を考えるとあまり使えたものじゃないので
独自関数を作ったりすることもあります。
あまりに、いろんなことに対応できるということは、それだけ無駄な処理がされるってことです。
シンプルな処理をしたいなら、シンプルな関数で対応するべきです。
はい、本日の教訓
ひとーつ：便利すぎるものは、それなりに無駄な処理がありますぞい。
システムの規模によって、便利なフレームワークや、ツール、関数をどう使っていくかは、協議しましょう。
ではさようならー
