こんにちは。Nobuhiro Nakajima です。
OpenSocial Pages for Google Apps は OpenSocial Activities API という Twitter でいうところのタイムライン API を備えています。また Activities は Twitter でいうところの Friends (Following)、Lists、Mentions という人と人の関係(ソーシャルグラフ)で絞り込めるようになっています。
OpenSocial Pages は Google AppEngine for Java でホストしています。そして Activity の格納と検索は Data Store (JDO) で実現していて、エンティティの主な構造は、次のようにしています。
エンティティの構造
Twitter でいうところの User を表すエンティティです。この User が、誰に Follow されているか、どのグループに属するかを保持させています。
public class User {
private String id;
private Set<String> followerIds; // 誰に Follow されているか
private Set<String> groupIds; // どのグループに属するか
}
Twitter でいうところの Lists を表すエンティティです。
public class Group {
private String id;
}
Twitter でいうところの Status を表すエンティティです。この Activity が誰のもので、誰が関係するのか保持させています。followerIds と groupIds は Person のコピーを保持させています。mentionIds は Twitter でいうところの、テキスト中の @username で引用された User たちを保持させています。
public class Activity {
private Long id;
private String userId; // Person#id
private String title; // テキスト
private Set<String> followerIds; // Person#followerIds のコピー
private Set<String> groupIds; // Person#groupIds のコピー
private Set<String> mentionIds; // テキスト中の @username たち
}
Follow と Unfollow
User A が User B を Follow するとき、User B の followerIds に User A の userId を追加します。また Unfollow するときは、User B の followerIds から User A を除外します。
Group の参加と退会
User が Group に参加するときは、User の groupIds に自身の userId を追加します。また、退会するときは、User の groupIds から 自身の userId を除外します。
Activity の送信
送信する User の followerIds と groupIds を Activity の followerIds と groupIds にコピーして格納します。さらに、テキスト中の @username に該当する User の userId を mentionIds に格納します。
検索クエリ
User の Activity を検索するときは、Activity エンティティに対して、次のフィルタを使っています。
Query#setFilter("userId == :userId");User が Follow している Friends の Activity を検索するときは、次のフィルタを使っています。このときの userId は、自分自身の ID を指定します。
Query#setFilter("followerIds == :userId");Group に所属している User たちの Activity を検索するときは、次のフィルタを使っています。
Query#setFilter("groupIds == :groupId");User が関係する Activity を検索するときは、次のフィルタを使っています。
Query#setFilter("mentionIds == :mentionId");
Activity の再構築
User A が User B を Follow したとき、User B の 全 Activity (*1) の followerIds に User A の userId を追加します。また Unfollow したときは、followerIds から除外します。
User が Group に参加するときは、User A の 全 Activity (*1) の groupIds に Group の groupId を追加します。また、退会したときは、groupIds から除外します。
前者と後者とも Task Queue を使って Activity を更新しています。
利点と欠点、そして課題
まず、基本方針は、シンプルなデータ構造とすること、そして、参照のコストを均一化するの(と削除)を最優先にしました。
この方法は、どんなに User が増えて、どんなに Follow したり、Group に参加したりしても、検索クエリのコストは一定なのが利点です。ただし、Follow/UnFollow、Groupの参加/不参加が発生したとき、過去にさかのぼって Activity を再構築する必要があるのが、大きな欠点です。
Activity がいくら蓄積されようとも、Activity 自体のコピーは保持していないため、Activity の削除は用意というのも利点です。ただ、User 自体を削除したとき、その User の 全 Activity を削除する必要がありますが、現状は削除せず、残したままとしています。
*1 Activity はどんどん蓄積されるものなので、時間が経過するにしたがって、全 Activity を更新するのは、現実的に難しくなってきます。そこで OpenSocial Pages では、新しいものの内 n 件分、もしくは n 日分の Activity のみ再構築の対象にするように妥協しています。古い Activity は重要度が低いよねという考え方です。
できれば、古い Activity もすべて再構築したいというのが課題です。古い Activity は即時で再構築することは絶対条件ではないため、バッチ的なものや、無駄な再構築が起こらないようにスケジューリングするとかいった方法でもよさそうです。
何かよいアイディアはないものでしょうか? エンティティグループとか、エンティティのエンティティとかうまく使えば、別の方法があるのかもしれないです。
%20-%20manten@n35.com_1277936011823.jpg)
