Salesforceのデータベース
すごい良い記事。
知られざる「マルチテナントアーキテクチャ」（2）～スケーラビリティのカギは組織ID － Publickey
知られざる「マルチテナントアーキテクチャ」（3）～スキーマとメタデータの謎 － Publickey
頼まなくてもこういう記事を書いてくれる人が増えている（頼まれてないっすよね？）のは、SFDCにとって、デベロッパーマーケティングとして成功だと思う。大事にしてくださいね。
スキーマについて
上記記事では、データベースの物理スキーマについて、公開情報をもとに分析されています。
掟破りのスキーマ
セールスフォースのアプリケーションで扱われるすべての数字や文字のデータは、Dataテーブルに保存される。このことがセールスフォースのデータベーススキーマの核心です。
Dataテーブルはどんなデータでも受け入れられるよう、次のようなスキーマになっています。恐らく、データベースに詳しい方がみたらびっくりするようなスキーマです。
知られざる「マルチテナントアーキテクチャ」（3）～スキーマとメタデータの謎 － Publickey
ただ、この使い方ですが、それほど実は変な使い方ではないような気がします。少なくとも、使い方の一つとしてこういう「何でもテーブル」は現場でよくあった、と聞いてます（もちろん性能などのトレードオフを考慮した上での適用ではあったでしょうが）。その場合のインデックスについても然りです。
SFDCがスキーマ情報を公開しているのは、そういう意味でそこはもはや共有ノウハウに近く、別に差別化する所ではない、ということでもあるかと思います。
さて、これが本当にRDBMSであるべきか、という点については、ちょっと微妙に思います。まあリレーショナルでなくても、DBMSとしての扱いやすさ、という面でOracleは悪くないのかもしれません。
組織IDによるパーティショニングについて
続いてパーティショニングについて。
すべてのデータに振られる組織ID
セールスフォースはすべてのユーザーが1つのデータベースを共有するマルチテナントアーキテクチャを採用しています。ということは、ユーザーが扱うデータはすべて1つのデータベースに格納されるのです。
しかし当然ながら、ある企業が他の企業のデータを参照してしまうことがないように、厳重なセキュリティを施さなければなりません。そこで、セールスフォースのデータベースに格納されるデータには、必ず「組織ID」が付けられます。スキーマとしてテーブルに組織IDの列が設けられているのです。この組織IDを超えてデータが参照されないようにシステムは設計されています。
そしてこの組織IDが、分散処理によるスケーラビリティのカギにもなっています。
知られざる「マルチテナントアーキテクチャ」（2）～スケーラビリティのカギは組織ID － Publickey
Salesforceのスケーラビリティは、組織（Salesforceを利用する企業）単位で局所化していることにつきるような気がします。この辺が、企業向けサービスであることの優位性というか、そのままコンシューマサービスのスケーリングのテクノロジーになかなか当てはめられない点でしょうか。
そして、これの最大の弱点は、組織を超えたシェアリングはできない、ということです。一応Salesforce to Salesforceという組織間での共有の仕組みはありますが、これはリアルタイムでない。キューを使った同期になります。なぜならパーティショニングどころか、異なる組織ではインスタンスが違ってる可能性すらあるので（PODアーキテクチャ）。
ただ、たとえばCRM業務に限定すれば、企業間でのデータ共有というのはそれほどなく（パートナー企業同士の場合などあったらいい場合もあるが、おそらく必須ではない）、べつにスケーラビリティを犠牲にしてまでリアルタイムでやることではない。むしろ、キューを使ってでも同期の仕組みが標準でできるところにmulti-tenancyの強みがあるとも言えます。
SaaS
こうしてまとめてみると、セールスフォースはSaasに最適化したシステムを前提に全く新規にシステムを設計・構築したからこそ、こうした大胆なアーキテクチャを採用できたのだ、ということがよく分かります。
既存のアプリケーションをもしもここで紹介したようなマルチテナントのアーキテクチャに書き換えようとすると、SQLなどデータアクセス部分は全部書き換え、オンプレミスでは必要なかった組織IDごとのセキュリティモデルは作り込みが必要になるなど、新規にアプリケーションを開発するのとそれほど変わらないか、それ以上に苦労することは間違いないでしょう。オラクルやSAPといったオンプレミスのアプリケーションを基にSaaSを展開しようとしているベンダが、マルチテナントアーキテクチャを採用できないでいる理由もこの辺にあるのではないでしょうか。
知られざる「マルチテナントアーキテクチャ」（3）～スキーマとメタデータの謎 － Publickey
僕もそう思います。彼らがよく言う「既存のアプリがそのまま動く」ということは、つまりスケールのところについて何も考えないままである、ということであり、つまりコストはすべてユーザに転嫁されたままである、ということでもあります。マシンの仮想化レベルで何とかなる話のスケーラビリティはたいしたことじゃないと感じます*1。
