連載記事「スケーラブルなO/Rマッピングの実現手法」が面白い
野村総合研究所の石田裕三さんがITA Issueに連載されている記事「スケーラブルなO/Rマッピングの実現手法」が面白く、今後に期待しています。
- 第1回 現状のO/Rマッピング手法に潜む問題点
- 第2回 O/Rマッピングの正しいモジュラリティを探る
- 第3回 Google File Systemに学ぶスケーラビリティの真髄【前編】――“富豪的”解決手段を超えて
- 第4回 Google File Systemに学ぶスケーラビリティの真髄【中編】――アプリケーションとプラットフォームの“協調設計”
私自身はサーバ数百台といった大規模システムとは縁がないのですが、オレオレフレームワークを作ろうと思っている関係上、データベースの扱いはやはり気になります。スケーラブルにできるものならそうしたいですよね。
第3回では、スケーラブルなO/Rマッピングの設計思想が書かれています。
（1）1回のクエリでアクセスするテーブルは必ず1つにする
（2）抽出したレコードは一切加工せずにフェッチする
（3）マッピング・クラスはテーブルと1対1で作成する
JOINはアプリケーション側でおこなうわけですね。排他制御をどうするのか気になりますが、今後の回で触れられるのではないかと思います。とはいえ、アプリケーション側でなんとかするしかなさそうですが。Rubyの場合はMutexとかSync_mとかで対応できるのかな。
「大規模SNS実現のためのGREEのアプローチ (1/5) - ITmedia エンタープライズ」を読むと、GREEでも、JOINを捨て、トランザクションを諦める形でスケーラビリティを確保しているようです（2006年の記事ですが）。eBayも、「スケーラビリティに関するベストプラクティス：eBayからの教訓」によれば、トランザクションを諦めている。
ともあれ、私ごときがあれこれ考えても休むに似たりなので、続きを楽しみに待つことにします。
RubyとDIコンテナ
先日の日記のコメント欄に書いたとおり、まつもとさんの書かれた記事「探訪Ruby 第5回 ダイコン」（『Linux magazine』、2005年2月号）が読みたくて、同誌のバックナンバーがぎっしり詰まっている『Linux magazine the DVD Complete』を入手しました。
さっそく当該記事を読んだところ、下記のようにあるではないですか！
DIコンテナの基本部分がわずか20行以下で実装できるのは私にとっても驚きでした。簡単な割にはなかなか有効そうなテクニックなので、次の仕事ではDIを使ってみようかなあって考えてます。
Matzはダイコン派なのか！？ そうなのか！？ 予想外です。
ま、まあ、2005年時点だからな、今は違うかもな、と思いサクると、下記の記事が見つかりました。
$LOAD_PATHを置き換えてロードするライブラリをすり替えちゃうっていうアイディアは Rubyならではのmock実装法だと思う。下手なDIコンテナを使ってクライアントコードに無理させるより、ずっと自然だよね。
DIコンテナってあまり好きになれないのは、将来のなにか(この場合にはmockへのすり替えの容易さとか、実装の(一時的)変更とか)のためにいまコストを払えという点なのかな。
Matzにっき(2005-10-14)
2005年10月の段階で、すでに嫌ってたのね…orz まあ、個人的に考えていたライブラリのすり替えで問題ないっぽいので、問題ないっぽい。ためになったね〜。
