JavaOne/Oracle OpenWorldレポートが書き途中ですが、Cloudforce 2010に行ってきたので割り込みでCloudforceのレポートを書きます。

マーク・ベニオフがまた日本に来ました。今回、マーク・ベニオフの芸達者ぶりが目立ちました。芸達者と言ってもモノマネをしたりするわけではありません。日本人に好印象を与える技術です。

今まで、マーク・ベニオフは今回ほどスピーチの中に日本語をまぜていなかったと思います。今回ほど深々とお辞儀をしていなかった気がします。日本語を一所懸命に話したり年配の日本人に深々とお辞儀をする外国人が日本人に受けることを知った上での計算高さを感じました。サンフランシスコで王様ラリー・エリソンを見てきたので余計そう思うのもしれません。師匠を反面教師にして、尊大キャラは良くないと判断したのでしょう。もっとも、今までのマーク・ベニオフは尊大キャラでもなかったですが。

いよいよと言うか遂にと言うか、Lotus Notesからの移行の話が徐々にsalesforce.com側から出始めました。chatterの登場で予想どおりの展開ではありますが、ビジネスに関わる微妙な話題なので多くは書きません。

展示会のブースに某SIerがいたので少し話を聞きました。最近のsalesforce.comの導入で、Lotus Notesやサイボウズからの移行案件があると聞きました。しかし実際にグループウェアの機能を期待するとギャップがあるようです。社名は出せませんが率直な感想を聞けて良かったです。

グループウェアの観点で見ると、salesforce.comもまたアメリカと日本の文化ギャップを持っています。これはLotus NotesもマイクロソフトSharePointもGoogle Appsも全部同じです。何が文化ギャップかと言うのは半分飯のタネなので書きませんが、IBM(Lotus)やマイクロソフトの日本法人がNotesやSharePointに日本向けに出している拡張機能を見ると何かはわかります。一例を挙げると会議室予約があります。社員が個室を持ち、ちょっとしたミーティングなら誰かの部屋で議論でき、大勢で集まる必要がある偉い上層部には専用会議室があり、そこを誰かと取り合うこともない環境で働いていれば、数少ない会議室を早い者勝ちで取り合う機能がグループウェアの大事な機能だとは想像もできません。まあ、文化ギャップとはそういうものです。

ただ、もしかしたら対Lotus Notesを真剣に取り組んでいるのは日本だけかもしれません。サンフランシスコのJavaOne/Oracle OpenWorldで、NoSQLのセッションを聞いたのですが、スピーカからこんな発言がありました。

「NoSQLはbuzz wordで、最近はなんでもNoSQLです。Lotus NotesがNoSQLと言われるぐらいです」

スピーカは笑いをとるために言っています。会場からも笑いが起きていました。Lotus NotesはNoSQLです、がアメリカでも受けるギャグなんだ、という思いと同時に、既にLotus Notesがまじめに向き合う対象でなくなっている雰囲気を感じました。日本ではLotus Notes移行はまじめな話題ですが、近いうちに、まだそんなこと言っているの?、というような話題になりそうです。

話を変えます。

salesforce.comのデータベース周りを語る技術セッションがありました。データの持ち方のアーキテクチャの話などがありました。基本は下記の内容の話題でした(もう少し軽めの説明)。

• 「スキーマ不定のデータをRDBに永続化する方法の比較」(http://dev.ariel-networks.com/Members/inoue/schemaless)

前々からsalesforce.comがアクセス制御のデータをどう持っているかに疑問がありました。セッションの中では軽く流されたので後で個別に聞いてみました。

以下のようにアクセス制御のデータを管理しているようです。

• ホワイトリスト的に、ユーザとそのユーザが読めるドキュメントの対応表を持つ(簡略化するとユーザIDのカラムとドキュメントIDのカラムのテーブル)
• public(全員が読めるドキュメントの意味?)なドキュメントは上記の対応表に持たない
• private(限定したユーザだけ読めるドキュメントの意味?)なドキュメントは上記の対応表に持たない

原則はユーザをキーにした、読めるドキュメントのホワイトリスト管理です。全員が読めるドキュメントはホワイトリストに入れるとムダなので別管理のようです(これは普通に納得)。privateドキュメントの部分は実装寄りの工夫かもしれません。ドキュメントに紐づくユーザ数が少なければ情報をドキュメント側に持たせる最適化のイメージでしょうか。

ホワイトリスト管理の疑問は、対応表のレコード数が膨大になりそうな点です。実際、膨大だというのが回答でした。more than billion records?に対する回答はyesでしたが、よく考えるとこんなくだらない質問ではなく、how many records?と聞けばよかったです。

ホワイトリスト管理のもうひとつの疑問はアクセス範囲の変更時に、対応表のinsert/deleteが大量に発生しそうなことです。これに対する回答はバッチ的に非同期で処理する、というものでした。つまりアクセス範囲の変更の反映には遅延があります。どのぐらいの遅延があるのか聞きましたが、モノによっては数時間とのことです。数分ならともかく数時間は予想以上の長さの遅延です。

対応表はOracleのテーブルだと思いこんで質問していましたが、別のタイプのストレージの可能性もあることに後で思い至りました。プレゼンの中で以下の4つのタイプのストレージを使い分けている、と話していたので、3番目の可能性もあります。

• 永続化に信頼度が必要なデータはOracle RAC
• 添付ファイル用ストレージ
• 永続化にそれほど信頼性が必要のないデータ用ストレージ(cursor storageと呼んでいました)
• コールドデータ(ほとんど使われなくなったデータ)用ストレージ

アクセス制御データをホワイトリスト的に持つ手法は考えなくてもないのですが、スケールしないかと思っていました。ありなのかもしれません。実用を考えると、コールドデータの管理とあわせて色々と工夫は必要そうです。