JP2017073162A - グラフ・データの分散キャッシュ - Google Patents

Abstract

【課題】グラフ・データの分散キャッシュを提供する。【解決手段】ノードと、エッジがグラフ内で接続するノード同士の間の関連付けまたは関係を定義するエッジとを含むグラフとしてモデル化された情報を格納し提供する、分散キャッシング・システム。【選択図】図１

Description

本開示は、全般的にはグラフ・データの格納および提供（ｓｅｒｖｉｎｇ）に関し、より詳細には、分散キャッシュ・システムを用いるグラフ・データの格納および提供に関する。

コンピュータ・ユーザは、プロプライエタリ・ネットワーク（ｐｒｏｐｒｉｅｔａｒｙ
ｎｅｔｗｏｒｋｓ）ならびにインターネットなどの公衆ネットワークを含む様々なローカル・エリア・コンピュータ・ネットワークおよび広域コンピュータ・ネットワークを介して膨大な量の情報にアクセスし、共有することができる。通常、ユーザのコンピューティング・デバイスにインストールされたウェブ・ブラウザは、たとえば関連するｕｎｉｆｏｒｍ ｒｅｓｏｕｒｃｅ ｌｏｃａｔｏｒ（ＵＲＬ）によって識別される様々なネットワーク・サーバに配置された情報へのアクセスおよびこれとのやり取り（ｉｎｔｅｒａｃｔｉｏｎ）を容易にする。ユーザ生成コンテンツの共有を可能にする従来の手法は、ソーシャル・ネットワーキング・ウェブサイトなどの様々な情報共有技術または情報共有プラットフォームを含む。そのようなウェブサイトは、ユーザが他のユーザによって作成されまたはカスタマイズされたウェブ・ページを見ることを可能にするアプリケーションのプラットフォームを含み、これにリンクされ、またはこれを提供することができ、ここで、他のユーザによるそのようなページの可視性およびこれとのやり取りは、ある特徴的なルールによって管理される（ｇｏｖｅｒｎｅｄ）。

そのようなソーシャル・ネットワーキング情報およびほとんどの情報全般は、通常、関係データベースに格納される。一般に、関係データベース（ｒｅｌａｔｉｏｎａｌ ｄａｔａｂａｓｅ）は、関係の集合（しばしばテーブルと呼ばれる）である。関係データベースは、１組の数学用語（ｍａｔｈｅｍａｔｉｃａｌ ｔｅｒｍｓ）を使用し、この数学用語は、構造化照会言語（ＳＱＬ）データベース用語法を使用する場合がある。たとえば、関係を、同一の属性を有するタプル（ｔｕｐｌｅｓ）の組として定義することができる。タプルは、通常、オブジェクトと、そのオブジェクトに関する情報とを表す。関係は、通常、テーブルとして記述され、テーブルは、行および列に編成される。一般に、ある属性によって参照されるすべてのデータは、同一のドメインにあり、同一の制約（ｃｏｎｓｔｒａｉｎｔｓ）に従う。

関係モデルは、関係タプルが特定の順序を有しないことと、タプルが属性に順序を課さないこととを指定する。アプリケーションは、クエリを指定することによってデータにアクセスし、クエリは、演算を使用して、タプルを識別し、属性を識別し、関係を組み合わせる。関係を変更することができ、新しいタプルが明示的な値を供給することができ、またはクエリから新しいタプルを導出することができる。同様に、クエリは、更新または削除のためにタプルを識別することができる。関係タプルはそれぞれ、その属性値のある組合せ（１または複数）によって一意に識別可能であることが必要である。この組合せは、主キー（ｐｒｉｍａｒｙ ｋｅｙ）と呼ばれる。関係データベースでは、すべてのデータが、関係を介して格納され、アクセスされる。データを格納する関係は、通常、テーブルを用いて実施され、またはテーブルと呼ばれる。

関係データベース管理システムによって実施される関係データベースは、たとえば金融記録、製造およびロジスティック情報、職員データ、および他のアプリケーションに使用されるデータベース内の情報の格納に関する最も主要な選択肢になっている。コンピュータ能力が高まるにつれて、関係データベースを以前に非実用的にしていた関係データベー
スの非効率性よりも、従来のアプリケーションに関する関係データベースの使い易さが優るようになった。３つの主導的なオープン・ソース実装は、ＭｙＳＱＬ、ＰｏｓｔｇｒｅＳＱＬ、およびＳＱＬｉｔｅである。ＭｙＳＱＬは、複数のデータベースへのマルチユーザ・アクセスを提供するサーバとして実行される関係データベース管理システム（ＲＤＢＭＳ）である。人気のあるＬＡＭＰソフトウェア・スタックの頭字語の「Ｍ」は、ＭｙＳＱＬを指す。ウェブ・アプリケーションと共に使用することに関するその人気は、ＰＨＰ（ＬＡＭＰの「Ｐ」）に密接に結び付けられている。複数の高トラフィック・ウェブ・サイトは、データ・ストレージおよびユーザ・データのログ記録にＭｙＳＱＬを使用する。

関係データベースとの通信が、しばしば速度ボトルネックになるので、多数のネットワークは、特定の情報クエリに応じるためにキャッシング・システムを利用する。たとえば、Ｍｅｍｃａｃｈｅｄは、汎用分散メモリ・キャッシング・システムである。これは、しばしば、外部データ・ソース（データベースまたはＡＰＩなど）を読み取らなければならない回数を減らすために、データおよびオブジェクトをＲＡＭ内にキャッシングすることによって、動的なデータベース駆動のウェブサイトを高速化するのに使用される。ＭｅｍｃａｃｈｅｄのＡＰＩは、複数の計算機にまたがって分散された巨大なハッシュ・テーブルを提供する。テーブルが満杯の時には、後続の挿入により、より古いデータがｌｅａｓｔ ｒｅｃｅｎｔｌｙ ｕｓｅｄ（ＬＲＵ）順でパージされることになる。Ｍｅｍｃａｃｈｅｄを使用するアプリケーションは、通常、データベースなどのより低速のバッキング・ストアにフォール・バックする前に、要求および追加をコアにレイヤ化する。

Ｍｅｍｃａｃｈｅｄシステムは、クライアント−サーバ・アーキテクチャを使用する。サーバは、キー−値連想配列を維持し、クライアントは、この配列を移植し、これに照会する。クライアントは、クライアント・サイド・ライブラリを使用して、サーバに連絡する。通常、各クライアントは、すべてのサーバを知っており、サーバは、お互いとは通信しない。クライアントが、あるキーに対応する値をセットするか読み取ることを望む場合には、クライアントのライブラリは、まず、使用されるサーバを判定するためにキーのハッシュを計算する。その後、クライアントは、そのサーバに連絡する。サーバは、キーの第２のハッシュを計算して、対応する値をどこに格納しまたはどこから読み取るべきかを判定する。通常、サーバは、その値をＲＡＭ内に保ち、サーバがＲＡＭを使い果たした場合には、サーバは、最も古い値を破棄する。

米国特許出願公開第２００２／０１６６０３１号明細書

したがって、クライアントは、Ｍｅｍｃａｃｈｅｄを一次的キャッシュとして扱わなければならず、Ｍｅｍｃａｃｈｅｄに格納されたデータが、必要な時にまだそこにあると仮定することはできない。

特定の実施形態は、ノードと、エッジがグラフ内で接続するノードの間の関連付けまたは関係を定義するエッジとを含むグラフとしてモデル化された情報を格納し提供する分散キャッシング・システムに関する。特定の実施形態では、グラフは、ソーシャル・グラフであるかこれを含み、分散キャッシング・システムは、より大きいネットワーキング・システム、インフラストラクチャ、または統合ソーシャル・ネットワーク環境を可能にするプラットフォームの一部である。本開示では、ソーシャル・ネットワーク環境は、ソーシャル・グラフ情報を含むソーシャル・グラフに関して説明される場合がある。実際に、本
開示の特定の実施形態は、ソーシャル・ネットワーク環境によってまたはこれのために格納されるデータのほとんどまたはすべてを、ソーシャル・グラフとして表すことができるという事実に依存し、これを活用し、またはこれを利用する。特定の実施形態は、本明細書で説明されるものなどのソーシャル・ネットワーク環境のユーザの指数関数的に増加する人数に伴って効率的に、知的に、かつ成功してスケーリングすることのできるコスト効率のよいインフラストラクチャを提供する。

本発明の１実装形態による例示的なキャッシング・システム・アーキテクチャを示す図。 例示的なコンピュータ・システム・アーキテクチャを示す図。 例示的なネットワーク環境を提供する図。 グラフに新しい関連付けを追加する例示的な方法を示す流れ図。 キャッシング・システムの様々なコンポーネントの間の例示的なメッセージ・フローを示す概略図。 グラフ・データに対する変更を処理する例示的な方法を示す流れ図。 キャッシング・システムの様々なコンポーネントの間の例示的なメッセージ・フローを示す概略図。

特定の実施形態は、ノードと、エッジがグラフ内で接続するノードの間の関連付けまたは関係を定義するエッジとを含むグラフとしてモデル化された情報を格納し提供する分散キャッシング・システムに関する。特定の実施形態では、グラフは、ソーシャル・グラフであるか又はソーシャル・グラフを含み、分散キャッシング・システムは、より大きいネットワーキング・システム、インフラストラクチャ、または統合ソーシャル・ネットワーク環境を可能にするプラットフォームの一部である。本開示では、ソーシャル・ネットワーク環境は、ソーシャル・グラフ情報を含むソーシャル・グラフに関して説明される場合がある。実際に、本開示の特定の実施形態は、ソーシャル・ネットワーク環境によってまたはソーシャル・ネットワーク環境のために格納されるデータのほとんどまたはすべてを、ソーシャル・グラフとして表すことができるという事実に依存し、これを活用し、またはこれを利用する。特定の実施形態は、本明細書で説明されるものなどのソーシャル・ネットワーク環境のユーザの指数関数的に増加する人数に伴って効率的に、知的に、かつ成功してスケーリングすることのできるコスト効率のよいインフラストラクチャを提供する。

特定の実施形態では、本明細書で説明される分散キャッシング・システムおよびバックエンド・インフラストラクチャは、大規模での低レイテンシ、１要求あたりのより低いコスト、開発者にとって使い易いフレームワーク、マルチマスタをサポートするインフラストラクチャ、格納されたデータのアクセスをＨｙｐｅｒｔｅｘｔ Ｐｒｅｐｒｏｃｅｓｓｏｒ（ＰＨＰ）以外の言語で記述されたクライアントに提供するインフラストラクチャ、本明細書で例によって説明される、ソーシャル・グラフの関連付け（エッジ）とオブジェクト（ノード）との両方を用いる組み合わされたクエリを可能にするインフラストラクチャ、および異なる永続データ・ストアを異なるタイプのデータに使用することを可能にするインフラストラクチャのうちの１または複数を提供する。さらに、特定の実施形態は、キャッシング＋永続性＋レプリケーション・インフラストラクチャからのデータ・アクセスＡＰＩのきれいな分離（ｃｌｅａｎ ｓｅｐａｒａｔｉｏｎ）を可能にするインフラストラクチャ、ライトスルー／リードスルー・キャッシングをサポートするインフラストラクチャ、計算をデータのより近くに移動するインフラストラクチャ、異なるストレージ・スキーマおよびバック・エンドへの透過的マイグレーションを可能にするインフラストラクチャ、およびデータ・オブジェクト・アクセスの効率を改善するインフラストラクチャ
のうちの１または複数を提供する。

さらに、本明細書で使用される時に、「または」は、「および」ならびに「または」を意味する場合がある、すなわち、「または」は、明示的に述べられるか暗黙のうちに暗示されない限り、「および」を必ずしも除外しない。

特定の実施形態は、インターネットなど、複数のネットワーク・アドレス可能システムを含む広域ネットワーク環境で動作することができる。図３に、様々な例示的な実施形態がその中で動作することのできる、例示的なネットワーク環境を示す。ネットワーク・クラウド６０は、一般に、本明細書で説明されるシステムおよびホストがそれを介して通信できる、１または複数の相互接続されたネットワークを表す。ネットワーク・クラウド６０は、パケットベースの広域ネットワーク（インターネットなど）、プライベートネットワーク、無線ネットワーク、衛星ネットワーク、セルラ・ネットワーク、ページング・ネットワーク、および類似物を含むことができる。図３に示されているように、特定の実施形態は、ソーシャル・ネットワーキング・システム２０および１または複数のクライアント・デバイス３０を備えるネットワーク環境内で動作することができる。クライアント・デバイス３０は、ネットワーク・サービス・プロバイダ、無線搬送波、または任意の他の適切な手段を介してネットワーク環境に動作可能に接続される。

１つの例示的な実施形態では、ソーシャル・ネットワーキング・システム２０は、本明細書で説明されるように、ユーザがお互いと通信するか他の形でやり取りし、ユーザ・プロファイルなどのコンテンツにアクセスすることを可能にするコンピューティング・システムを備える。ソーシャル・ネットワーキング・システム２０は、様々な例示的な実施形態で、１または複数の物理サーバ２２およびデータ・ストア２４を備えるネットワーク・アドレス可能システムである。１または複数の物理サーバ２２は、たとえばルータおよび／またはネットワーキング・スイッチ２６のセットを介してコンピュータ・ネットワーク６０に動作可能に接続される。例示的な実施形態では、１または複数の物理サーバ２２によってホスティングされる機能性は、ウェブ・サーバまたはＨＴＴＰサーバ、ＦＴＰサーバ、ならびに、限定なしに、Ｃｏｍｍｏｎ Ｇａｔｅｗａｙ Ｉｎｔｅｒｆａｃｅ（ＣＧＩ）スクリプト、ＰＨＰ Ｈｙｐｅｒ−ｔｅｘｔ Ｐｒｅｐｒｏｃｅｓｓｏｒ（ＰＨＰ）、Ａｃｔｉｖｅ Ｓｅｒｖｅｒ Ｐａｇｅｓ（ＡＳＰ）、ハイパーテキスト・マークアップ言語（ＨＴＭＬ）、Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ（ＸＭＬ）、ＪＡＶＡ（登録商標）、ＪＡＶＡＳＣＲＩＰＴ（登録商標）、Ａｓｙｎｃｈｒｏｎｏｕｓ ＪＡＶＡＳＣＲＩＰＴ（登録商標） ａｎｄ ＸＭＬ（ＡＪＡＸ）、および類似物を使用して実施されたウェブ・ページおよびアプリケーションを含むことができる。

物理サーバ２２は、ソーシャル・ネットワーキング・システム２０の動作に関する機能性をホスティングすることができる。たとえば、ソーシャル・ネットワーキング・システム２０は、１または複数のクライアント・デバイス３０の１または複数のユーザが、情報を見、ポストすると同時に、ウェブサイトを介してお互いと通信することを可能にするウェブサイトをホスティングすることができる。以下では、複数のサーバ２２は、サーバ２２と呼ばれる場合があるが、サーバ２２は、たとえばソーシャル・ネットワーキング・システム２０ならびに他のコンテンツ配布サーバ、データ・ストア、およびデータベースをホスティングする多数のサーバを含むことができる。データ・ストア２４は、ソーシャル・ネットワーキング・システムの動作に関連し、動作を可能にするコンテンツおよびデータをディジタル・データ・オブジェクトとして格納することができる。データ・オブジェクトは、特定の実装形態で、通常はデータ・ファイル、データベース、またはレコードに格納されまたはその中で実施されるディジタル情報のアイテムである。コンテンツ・オブジェクトは、テキスト（たとえば、ＡＳＣＩＩ、ＳＧＭＬ、ＨＴＭＬ）、イメージ（たとえば、ｊｐｅｇ、ｔｉｆ、およびｇｉｆ）、グラフィックス（ベクトルベースのまたはビ
ットマップ）、オーディオ、ビデオ（たとえば、ｍｐｅｇ）、または他のマルチメディア、およびその組合せを含む多数の形をとることができる。コンテンツ・オブジェクト・データは、実行可能コード・オブジェクト（たとえば、ブラウザ・ウィンドウまたはフレーム内で実行可能なゲーム）、ポッドキャスト、その他を含むこともできる。論理的に、データ・ストア２４は、関係データベースおよびオブジェクト指向データベースなど、１または複数の物理システムに格納された論理的に関係するレコードまたはファイルの統合されたコレクションとして情報を維持する様々な別々のデータベースおよび統合されたデータベースのうちの１または複数に対応する。構造的に、データ・ストア２４は、一般に、データ・ストレージおよび管理システムの大きいクラスのうちの１または複数を含むことができる。特定の実施形態では、データ・ストア２４は、１または複数のデータベース・サーバ、マス・ストレージ・メディア、メディア・ライブラリ・システム、ストレージ・エリア・ネットワーク、データ・ストレージ・クラウド、および類似物などのコンポーネントを含む任意の適切な物理システム（１または複数）によって実施されることができる。１つの例示的な実施形態では、データ・ストア２４は、１または複数のサーバ、データベース（たとえば、ＭｙＳＱＬ）、および／またはデータ・ウェアハウスを含む。

データ・ストア２４は、異なるソーシャル・ネットワーキング・システム２０のユーザおよび／またはクライアント・デバイス３０に関連するデータを含むことができる。特定の実施形態では、ソーシャル・ネットワーキング・システム２０は、システム２０のユーザごとにユーザ・プロファイルを維持する。ユーザ・プロファイルは、ソーシャル・ネットワークのユーザを記述するデータを含み、このデータは、たとえば、正式名称（人のファースト・ネーム、ミドル・ネーム、およびラスト・ネーム、企業の商号および／または会社名など）、生物学的、人口統計的、ならびに、職歴、学歴、趣味または好み、地理的位置、および追加の記述データなどの他のタイプの記述情報を含むことができる。たとえば、ユーザ・プロファイルは、ユーザの誕生日、関係状況（ｒｅｌａｔｉｏｎｓｈｉｐ ｓｔａｔｕｓ）、居住都市、および類似物を含むことができる。システム２０はさらに、異なるユーザの間の１または複数の関係を記述するデータを格納することができる。関係情報は、類似するまたは共通の職歴、グループ・メンバシップ、趣味、または学歴を有するユーザを示すことができる。ユーザ・プロファイルは、他のユーザによるユーザの情報へのアクセスを管理するプライバシ・セッティングを含むこともできる。

クライアント・デバイス３０は、一般に、コンピュータ・ネットワークを介して（たとえば、リモートに）通信する機能性を含むコンピュータまたはコンピューティング・デバイスである。クライアント・デバイス３０は、他の適切なコンピューティング・デバイスの中でも、デスクトップ・コンピュータ、ラップトップ・コンピュータ、携帯情報端末（ＰＤＡ）、車内もしくは車外のナビゲーション・システム、スマートホンもしくは他のセルラホンもしくは携帯電話機、またはモバイル・ゲーミング・デバイスでもよい。クライアント・デバイス３０は、ウェブ・ブラウザ（たとえば、Ｍｉｃｒｏｓｏｆｔ ＷＩＮＤＯＷＳ（登録商標） Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ、Ｍｏｚｉｌｌａ Ｆｉｒｅｆｏｘ、Ａｐｐｌｅ Ｓａｆａｒｉ、Ｇｏｏｇｌｅ Ｃｈｒｏｍｅ、およびＯｐｅｒａなど）など、コンピュータ・ネットワークを介してコンテンツにアクセスし、これを見るための、１または複数のクライアント・アプリケーションを実行することができる。特定の実装形態では、クライアント・アプリケーションは、クライアント・デバイス３０のユーザが、ソーシャル・ネットワーキング・システム２０によってホスティングされるリソースなど、取り出されるべき特定のネットワーク・リソースのアドレスを入力することを可能にする。これらのアドレスを、Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ ＬｏｃａｔｏｒすなわちＵＲＬとすることができる。さらに、ページまたは他のリソースが取り出された後に、クライアント・アプリケーションは、ユーザが他のリソースへのハイパーリンクを「クリック」する時に、他のページまたは他のリソースへのアクセスを提供することができる。たとえば、そのようなハイパーリンクは、ウェブ・ページ内に配置され得、ユーザが
別のページへのＵＲＬを入力し、そのページを読み出すための自動化された形を提供することができる。

図１に、図３に示されたソーシャル・ネットワーキング・システム２０のバック・エンド機能を実施することのできるネットワーキング・システム、アーキテクチャ、またはインフラストラクチャ１００（以下ではネットワーキング・システム１００と呼ばれる）の例示的な実施形態を示す。特定の実施形態では、ネットワーキング・システム１００は、ネットワーキング・システム１００のユーザが、ネットワーキング・システム１００によって提供されるソーシャル・ネットワーキング・サービスを介してお互いとならびに第三者とやり取りすることを可能にする。たとえば、リモート・ユーザ・コンピューティング・デバイス（たとえば、パーソナル・コンピュータ、ネットブック、マルチメディア・デバイス、セルラ電話機（特にスマートホン）など）のユーザは、情報を見、情報を格納しもしくは更新（アップデート）し、情報を通信し、または他のユーザ、サード・パーティ・ウェブサイト、ウェブ・ページ、もしくはウェブ・アプリケーション、もしくはネットワーキング・システム１００によって格納され、ホスティングされ、またはアクセス可能である他の情報と他の形でやり取り（相互作用）するために、少なくとも部分的にネットワーキング・システム１００によってホスティングされまたはアクセス可能であるウェブサイト、ウェブ・ページ、またはウェブ・アプリケーションにアクセスするために、ウェブ・ブラウザまたは他のユーザ・クライアント・アプリケーションを介してネットワーキング・システム１００にアクセスすることができる。特定の実施形態では、ネットワーキング・システム１００は、下でより詳細に説明されるように、ユーザ、コンセプト、トピック、および他の情報（データ）を表すグラフ・ノードと、グラフ・ノードの間を接続するかその間の関係を定義するグラフ・エッジとを含むグラフを維持する。

図１および図５を参照すると、特定の実施形態で、ネットワーキング・システム１００は、１または複数のデータ・センタ１０２を含む。たとえば、ネットワーキング・システム１００は、様々な地理的領域内に配置されたユーザにサービス提供するためにそれぞれの領域内に戦略的に配置された複数のデータ・センタ１０２を含むことができる。特定の実施形態では、各データ・センタは、ネットワーキング・システム１００のユーザへおよびネットワーキング・システム１００のユーザから情報を通信する複数のクライアント・サーバまたはウェブ・サーバ１０４（以下ではクライアント・サーバ１０４）を含む。たとえば、リモート・ユーザ・コンピューティング・デバイスのユーザは、ロード・バランサ（ｌｏａｄ ｂａｌａｎｃｅｒｓ）または他の適切なシステムを介し、ネットワークおよびサービス・プロバイダの任意の適切な組合せを介して、クライアント・サーバ１０４と通信することができる。クライアント・サーバ１０４は、ユーザ要求に応答するために構造化文書を生成するためにデータを取り出すために、本明細書で説明されるキャッシング・システムに照会することができる。

クライアント・サーバ１０４のそれぞれは、１または複数のフォロワ分散キャッシュ・クラスタまたはフォロワ分散キャッシュ・リング１０６（以下ではフォロワ・キャッシュ・クラスタ１０６）と通信する。図示の実施形態では、データ・センタ１０２は、それぞれがウェブ・サーバ１０４のサブセットにサービス提供する３つのフォロワ・キャッシュ・クラスタ１０６を含む。特定の実施形態では、フォロワ・キャッシュ・クラスタ１０６とフォロワ・キャッシュ・クラスタ１０６とがサービス提供するクライアント・サーバ１０４は、ビルディング内、室内、または他の集中化された位置など、非常に近接して配置され、これは、インフラストラクチャに関連するコスト（たとえば、ワイヤまたは他の通信信号線など）ならびにクライアント・サーバ１０４とそれぞれのフォロワ・キャッシュ・ノード・クラスタ１０６との間のレイテンシを減らす。しかし、或る実施形態では、フォロワ・キャッシュ・クラスタ１０６のそれぞれおよびそれらがそれぞれサービス提供するクライアント・サーバ１０４を、集中化された位置内に配置することができるが、フォ
ロワ・キャッシュ・クラスタ１０６のそれぞれおよびそのフォロワ・キャッシュ・クラスタ１０６がそれぞれサービス提供するそれぞれのクライアント・サーバ１０４を、所与のデータ・センタの他のフォロワ・キャッシュ・クラスタ１０６およびそれぞれのクライアント・サーバ１０４とは異なる位置に配置することができる、すなわち、所与の領域の所与のデータ・センタのフォロワ・キャッシュ・クラスタ１０６（およびそのクラスタがサービス提供するそれぞれのクライアント・サーバ１０４）を、その領域内の様々な位置のいたるところに分散させることができる。

特定の実施形態では、各データ・センタ１０２はさらに、所与のデータ・センタ１０２のフォロワ・キャッシュ・クラスタ１０６とその所与のデータ・センタ１０２の永続ストレージ・データベース１１０との間で情報を通信するリーダ・キャッシュ・クラスタ１０８を含む。特定の実施形態では、データベース１１０は、関係データベースである。特定の実施形態では、リーダ・キャッシュ・クラスタ１０８は、データベース１１０の任意の適切な実装形態と相互作用するように動作可能なプラグインを含むことができる。たとえば、データベース１１０は、動的可変プラグイン・アーキテクチャ（ｄｙｎａｍｉｃａｌｌｙ−ｖａｒｉａｂｌｅ ｐｌｕｇ−ｉｎ ａｒｃｈｉｔｅｃｔｕｒｅ）として実施され得、ＭｙＳＱＬおよび／またはたとえばとりわけＨＡＹＳＴＡＣＫ、ＣＡＳＳＡＮＤＲＡなどの任意の適切な関係データベース管理システムを利用することができる。１実装形態では、プラグインは、グラフ・ノードおよびグラフ・エッジとしてキャッシング・レイヤに格納されたデータを１または複数のテーブルまたはフラット・ファイルを含む関係データベースに適するクエリおよびコマンドに変換することなど、様々な変換動作を実行する。特定の実施形態では、リーダ・キャッシュ・クラスタ１０８は、フォロワ・キャッシュ・クラスタ１０６からのデータベース１１０への書込要求をも調整し、時々、リーダ・キャッシュ・クラスタ１０８内でキャッシングされたまたは（リーダ・キャッシュ・クラスタ１０８内でキャッシングされていない場合に）データベース１１０内に格納された情報に関するフォロワ・キャッシュ・クラスタ１０６からの読取要求をも調整する。特定の実施形態では、リーダ・キャッシュ・クラスタ１０８はさらに、それぞれのデータ・センタ１０２のフォロワ・キャッシュ・クラスタ１０６内に格納された情報の同期化を調整する。すなわち、特定の実施形態では、所与のデータ・センタ１０２のリーダ・キャッシュ・クラスタ１０８は、そのデータ・センタ１０２のフォロワ・キャッシュ・クラスタ１０６同士の間のキャッシュ一貫性（たとえば、キャッシングされる情報）を維持し、フォロワ・キャッシュ・クラスタ１０６とリーダ・キャッシュ・クラスタ１０８との間のキャッシュ一貫性を維持し、リーダ・キャッシュ・クラスタ１０８内でキャッシングされた情報をデータベース１１０内に格納するように構成される。１実装形態では、リーダ・キャッシュ・クラスタ１０８およびフォロワ・キャッシュ・クラスタ１０６を、クライアント・サーバ１０４とデータベース１１０との間のキャッシング・レイヤと考えることができる。

１実装形態では、キャッシング・レイヤは、ライトスルー／リードスルー・キャッシング・レイヤであり、すべての読取および書込は、キャッシング・レイヤをトラバースする（ｔｒａｖｅｒｓｅ）。１実装形態では、キャッシング・レイヤは、関連付け情報を維持し、したがって、そのような情報に関するクエリを処理することができる。他のクエリは、実行のためにデータベース１１０にパス・スルーされる。データベース１１０は、一般に、他のクエリ・タイプを処理するための他のキャッシング・レイヤをそれ自体で含むことができるデータベース・システムを意味する。

各フォロワ・キャッシュ・クラスタ１０６は、複数のフォロワ・キャッシュ・ノード１１２を含むことができ、このフォロワ・キャッシュ・ノード１１２のそれぞれは、個々のコンピュータ、コンピューティング・システム、またはサーバ上で実行中であってもよい。しかし、上で説明したように、所与のフォロワ・キャッシュ・クラスタ１０６のフォロワ・キャッシュ・ノード１１２のそれぞれを、集中化された位置内に配置することができ
る。同様に、各リーダ・キャッシュ・クラスタ１０８は、複数のリーダ・キャッシュ・ノード１１４を含むことができ、このリーダ・キャッシュ・ノード１１４のそれぞれは、個々のコンピュータ、コンピューティング・システム、またはサーバ上で実行中であってもよい。所与のフォロワ・キャッシュ・クラスタ１０６のフォロワ・キャッシュ・ノード１１２と同様に、所与のリーダ・キャッシュ・クラスタ１０８のリーダ・キャッシュ・ノード１１４のそれぞれを、集中化された位置内に配置することができる。たとえば、各データ・センタ１０２が、数十台、数百台、または数千台のクライアント・サーバ１０４を含んでもよく、各フォロワ・キャッシュ・クラスタ１０６が、クライアント・サーバ１０４のサブセットにサービス提供する数十個、数百個、または数千個のフォロワ・キャッシュ・ノード１１２を含んでもよい。同様に、各リーダ・キャッシュ・クラスタ１０８は、数十個、数百個、または数千個のリーダ・キャッシュ・ノード１１４を含みうる。特定の実施形態では、所与のフォロワ・キャッシュ・クラスタ１０６内のフォロワ・キャッシュ・ノード１１２のそれぞれは、特定のフォロワ・キャッシュ・クラスタ１０６内の他のフォロワ・キャッシュ・ノード１１２、特定のフォロワ・キャッシュ・クラスタ１０６によってサービス提供されるクライアント・サーバ１０４、およびリーダ・キャッシュ・クラスタ１０８内のリーダ・キャッシュ・ノード１１４と通信することだけができる。

特定の実施形態では、ネットワーキング・システム１００によって格納される情報は、各データ・センタ１０２内で、それぞれデータベース１１０内とフォロワ・キャッシュ・クラスタ１０６およびリーダ・キャッシュ・クラスタ１０８のそれぞれの中との両方に格納される。特定の実施形態では、各データベース１１０内に格納される情報は、関係的に（たとえば、ＭｙＳＱＬを介してオブジェクトおよびテーブルとして）格納され、同一の情報は、フォロワ・キャッシュ・クラスタ１０６およびリーダ・キャッシュ・クラスタ１０８のそれぞれの中で、グラフ・ノードおよびノードの間の関連付けまたは接続（以下ではグラフ・エッジと呼ばれる）を含むグラフの形で、それぞれフォロワ・キャッシュ・クラスタ１０６およびリーダ・キャッシュ・クラスタ１０８のそれぞれによって格納される複数のデータ・シャード（ｄａｔａ ｓｈａｒｄ）内に格納される。特定の実施形態では、フォロワ・キャッシュ・クラスタ１０６およびリーダ・キャッシュ・クラスタ１０８のそれぞれのデータ・シャードは、それぞれのキャッシュ・クラスタ内のキャッシュ・ノード１１２または１１４の間でグループ化されまたは分割される。すなわち、それぞれのキャッシュ・クラスタ内のキャッシュ・ノード１１２または１１４のそれぞれは、クラスタによって格納されるシャードのサブセットを格納する（また、リーダ・キャッシュ・クラスタが、所与のデータ・センタ１０２のキャッシュ・クラスタのそれぞれによって格納されるシャードを同期化し、或る実施形態でデータ・センタ１０２の間で同期化するので、それぞれフォロワ・キャッシュ・クラスタ１０６およびリーダ・キャッシュ・クラスタ１０８のそれぞれによって格納されるシャードの各セットは、同一の情報を格納する）。

特定の実施形態では、各グラフ・ノードは、それぞれフォロワ・キャッシュ・クラスタ１０６およびリーダ・キャッシュ・クラスタ１０８のそれぞれと、データベース１１０とによって格納されるグラフ内のグラフ・ノードを一意に識別する一意識別子（ＩＤ）（以下ではノードＩＤと呼ばれる）に割り当てられる；すなわち、各ノードＩＤは、グローバルに一意である。１実装形態では、各ノードＩＤは、６４ビット識別子である。１実装形態では、シャード（ｓｈａｒｄ）は、ノードＩＤ空間のセグメントを割り当てられる。特定の実施形態では、各ノードＩＤは、一意の対応するシャードＩＤに（たとえば、算術的にまたは何らかの数学関数を介して）マッピングされる；すなわち、各シャードＩＤも、グローバルに一意であり、それぞれフォロワ・キャッシュ・クラスタ１０６およびリーダ・キャッシュ・クラスタ１０８のそれぞれによって格納されるシャードの各セット内の同一のデータ・オブジェクトを参照する。言い換えると、すべてのデータ・オブジェクトは、一意ノードＩＤを有するグラフ・ノードとして格納され、それぞれフォロワ・キャッシュ・クラスタ１０６およびリーダ・キャッシュ・クラスタ１０８のそれぞれのデータ・シ
ャード内のグラフ内に格納されるすべての情報は、同一の対応する一意シャードＩＤを使用して、それぞれフォロワ・キャッシュ・クラスタ１０６およびリーダ・キャッシュ・クラスタ１０８のそれぞれのデータ・シャード内に格納される。

すぐ上で説明したように、特定の実施形態では、シャードＩＤ空間（シャードＩＤと、各キャッシュ・クラスタのすべてのシャードによって格納され、他のフォロワ・キャッシュ・クラスタ１０６およびリーダ・キャッシュ・クラスタ１０８のすべてにおいてレプリケーションされる関連する情報と）は、それぞれフォロワ・キャッシュ・クラスタ１０６またはリーダ・キャッシュ・クラスタ１０８内で、それぞれフォロワ・キャッシュ・ノード１１２またはリーダ・キャッシュ・ノード１１４の間で分割される。たとえば、所与のフォロワ・キャッシュ・クラスタ１０６内の各フォロワ・キャッシュ・ノード１１２は、それぞれのフォロワ・キャッシュ・クラスタ１０６によって格納されるシャードのサブセット（たとえば、数十個、数百個、または数千個のシャード）を格納することができる。各シャードは、特定のシャードによって格納される複数のシャードＩＤの範囲内のシャードＩＤにそのそれぞれのノードＩＤがマッピングされるノードに関する情報を含む情報を格納すべき複数のノードＩＤの範囲（ｒａｎｇｅ）を割り当てられる。同様に、リーダ・キャッシュ・クラスタ１０８内の各リーダ・キャッシュ・ノード１１４は、それぞれのリーダ・キャッシュ・クラスタ１０８によって格納されるシャードのサブセット（たとえば、数十個、数百個、または数千個のシャード）を格納することができる。各シャードは、特定のシャードによって格納される複数のシャードＩＤの範囲内のシャードＩＤにそのそれぞれのノードＩＤがマッピングされるノードに関する情報を含む情報を格納すべき複数のノードＩＤの範囲を割り当てられる。

しかし、上で説明したように、所与のシャードＩＤは、それぞれフォロワ・キャッシュ・クラスタ１０６およびリーダ・キャッシュ・クラスタ１０８によって格納される同一のデータ・オブジェクトに対応する。各フォロワ・キャッシュ・クラスタ１０６内のフォロワ・キャッシュ・ノード１１２の個数およびリーダ・キャッシュ・クラスタ１０８内のリーダ・キャッシュ・ノード１１４の個数は、静的に（たとえば、フォロワ・キャッシュ・クラスタ１０６およびリーダ・キャッシュ・クラスタ１０８は、一般に、それぞれ異なる個数のフォロワ・キャッシュ・ノード１１２およびリーダ・キャッシュ・ノード１１４を含むことができる）または動的に（たとえば、所与のキャッシュ・クラスタ内のキャッシュ・ノードが、様々な理由から周期的にまたは修正、更新、もしくは保守の必要に応じてシャット・ダウンされる場合がある）変化する可能性があるので、フォロワ・キャッシュ・ノード１１２およびリーダ・キャッシュ・ノード１１４のそれぞれによって格納されるシャードの個数は、各キャッシュ・クラスタ内ならびにキャッシュ・クラスタの間で静的にまたは動的に変化する可能性がある。さらに、各シャードに割り当てられる複数のシャードＩＤの範囲も、静的にまたは動的に変化する可能性がある。

特定の実施形態では、フォロワ・キャッシュ・ノード１１２およびリーダ・キャッシュ・ノード１１４のそれぞれは、それぞれのキャッシュ・ノード内でキャッシングされる情報の格納および提供を管理するグラフ管理ソフトウェアを含む。特定の実施形態では、所与のキャッシュ・クラスタのキャッシュ・ノードのそれぞれで実行されるグラフ管理ソフトウェアは、どのシャード（および対応するシャードＩＤ）がそれぞれのキャッシュ・クラスタ内のキャッシュ・ノードのそれぞれによって格納されるのかを判定するために通信することができる。さらに、キャッシュ・ノードがフォロワ・キャッシュ・ノード１１２である場合には、フォロワ・キャッシュ・ノード１１２上で実行されるグラフ管理ソフトウェアは、クライアント・サーバ１０４から要求（たとえば、書込要求または読取要求）を受信し、フォロワ・キャッシュ・ノード内の適当なシャード内の情報を取り出し、更新し、削除し、または格納することによってその要求に応え、フォロワ・キャッシュ・ノード１１２とそれぞれのフォロワ・キャッシュ・クラスタ１０６の他のフォロワ・キャッシ
ュ・ノード１１２との間の通信ならびにフォロワ・キャッシュ・ノード１１２とリーダ・キャッシュ・クラスタ１０８のリーダ・キャッシュ・ノード１１４との間の通信を管理しまたは容易にする。同様に、キャッシュ・ノードが、リーダ・キャッシュ・ノード１１４である場合には、リーダ・キャッシュ・ノード１１４上で実行されるグラフ管理ソフトウェアは、リーダ・キャッシュ・ノード１１４とフォロワ・キャッシュ・クラスタ１０６のフォロワ・キャッシュ・ノード１１２とリーダ・キャッシュ・クラスタ１０８の他のリーダ・キャッシュ・ノード１１４との間の通信ならびにリーダ・キャッシュ・ノード１１４とデータベース１１０との間の通信を管理する。キャッシュ・ノード１１２および１１４のそれぞれの上で実行されるグラフ管理ソフトウェアは、それがグラフの形の情報を格納し提供していることを理解する。

特定の実施形態では、各フォロワ・キャッシュ・ノード１１２上のグラフ管理ソフトウェアは、それがそれぞれのフォロワ・キャッシュ・クラスタ１０６の他のキャッシュ・ノード１１２、リーダ・キャッシュ・クラスタ１０８のリーダ・キャッシュ・ノード１１４、ならびにそれぞれのフォロワ・キャッシュ・クラスタ１０６がサービス提供するクライアント・サーバ１０４と共有するテーブルを維持する責任をも負う。このテーブルは、所与のフォロワ・キャッシュ・クラスタ１０６内の特定のキャッシュ・ノード１１２への各シャードＩＤのマッピングを提供し、所与のフォロワ・キャッシュ・クラスタ１０６は、シャードＩＤおよびそのシャードＩＤに関連する情報を格納する。このように、特定のフォロワ・キャッシュ・クラスタ１０６によってサービス提供されるクライアント・サーバ１０４は、フォロワ・キャッシュ・クラスタ１０６内のフォロワ・キャッシュ・ノード１１２のどれが、クライアント・サーバ１０４がアクセス、追加、または更新を試みつつある情報に関連するシャードＩＤを維持するのかを知る（たとえば、クライアント・サーバ１０４は、フォロワ・キャッシュ・ノード１１２のどれがシャードＩＤを割り当てられ、格納するのかを判定するためにマッピング・テーブルを使用した後に、特定のシャードＩＤに関連する情報を格納しているかこれから格納する特定のフォロワ・キャッシュ・ノード１１２に書込要求または読取要求を送信することができる）。同様に、特定の実施形態では、各リーダ・キャッシュ・ノード１１４上のグラフ管理ソフトウェアは、それぞれのリーダ・キャッシュ・クラスタ１０８の他のキャッシュ・ノード１１４ならびにそのリーダ・キャッシュ・クラスタ１０８が管理するフォロワ・キャッシュ・クラスタ１０６のフォロワ・キャッシュ・ノード１１２と共有するテーブルを維持する責任をも負う。さらに、このように、所与のフォロワ・キャッシュ・クラスタ１０６内の各フォロワ・キャッシュ・ノード１１２は、その所与のフォロワ・キャッシュ・クラスタ１０６内の他のフォロワ・キャッシュ・ノード１１２のどれが、それぞれのフォロワ・キャッシュ・クラスタ１０６によって格納されるシャードＩＤのどれを格納するのかを知る。同様に、このように、リーダ・キャッシュ・クラスタ１０８内の各リーダ・キャッシュ・ノード１１４は、そのリーダ・キャッシュ・クラスタ１０８内の他のリーダ・キャッシュ・ノード１１４のどれが、そのリーダ・キャッシュ・クラスタ１０８によって格納されるシャードＩＤのどれを格納するのかを知る。さらに、所与のフォロワ・キャッシュ・クラスタ１０６内の各フォロワ・キャッシュ・ノード１１２は、リーダ・キャッシュ・クラスタ１０８内のリーダ・キャッシュ・ノード１１４のどれがどのシャードＩＤを格納するのかを知る。同様に、リーダ・キャッシュ・クラスタ１０８内の各リーダ・キャッシュ・ノード１１４は、フォロワ・キャッシュ・クラスタ１０６のそれぞれ内のフォロワ・キャッシュ・ノード１１２のどれがどのシャードＩＤを格納するのかを知る。

特定の実施形態では、グラフ内、特定の例示的な実施形態ではソーシャル・グラフ内の各ノードに関する情報は、そのシャードＩＤに基づき、フォロワ・キャッシュ・クラスタ１０６およびリーダ・キャッシュ・クラスタ１０８のそれぞれの各シャード内に格納される。グラフ内の各ノードは、上で述べたように、ノードＩＤを有する。シャードＩＤと一緒に、それぞれのキャッシュ・ノード１１２または１１４は、ノードのタイプを識別する
ノード・タイプ・パラメータならびに１または複数のｎａｍｅ−ｖａｌｕｅペア（コンテンツ（たとえば、テキスト、メディア、またはメディアもしくは他のリソースへのＵＲＬ））およびメタデータ（たとえば、ノードが作成されまたは変更された時のタイムスタンプ）を格納することができる。特定の実施形態では、グラフ内、特定の例示的な実施形態ではソーシャル・グラフ内の各エッジは、そのエッジが接続される各ノードと共に格納される。たとえば、ほとんどのエッジは、双方向である；すなわち、ほとんどのエッジは、グラフ内の２つのノードに接続される。特定の実施形態では、各エッジは、そのエッジが接続される各ノードと共に同一のシャードに格納される。たとえば、ノードＩＤ１をノードＩＤ２に接続するエッジを、ノードＩＤ１に対応するシャードＩＤ（たとえば、シャードＩＤ１）および、異なるシャード内または所与のキャッシュ・クラスタ内の異なるキャッシュ・ノード内とすることすらできるノードＩＤ２に対応するシャードＩＤ（たとえば、シャードＩＤ２）を用いて格納することができる。たとえば、エッジを、｛ノードＩＤ１，エッジ・タイプ，ノードＩＤ２｝の形でシャードＩＤ１を用いて格納することができ、ここで、エッジ・タイプは、エッジのタイプを示す。エッジは、メタデータ（たとえば、エッジが作成されまたは変更された時を示すタイムスタンプ）をも含むことができる。エッジを、（ノードＩＤ１，エッジ・タイプ，ノードＩＤ２）の形でシャードＩＤ２を用いてキャッシングすることもできる。たとえば、ソーシャル・ネットワーキング・システム１００のユーザが、別のユーザとの連絡先関係またはコンセプトもしくはユーザとのファン関係を確立する時に、タイプ「友達」または「ファン」のエッジ関係を、２つのシャードすなわち、ユーザの識別子がマッピングされるシャードに対応する第１のシャードおよび他のユーザまたはコンセプトのオブジェクト識別子がマッピングされる第２のシャード内に格納することができる。

ネットワーキング・システム１００、特にフォロワ・キャッシュ・クラスタ１０６のフォロワ・キャッシュ・ノード１１２およびリーダ・キャッシュ・クラスタ１０８のリーダ・キャッシュ・ノード１１４上で実行されるグラフ管理ソフトウェアは、クライアント・サーバ１０４から受信されるクエリ、ならびにそれぞれ他のフォロワ・キャッシュ・ノード１１２または他のリーダ・キャッシュ・ノード１１４へのクエリもしくはそれぞれ他のフォロワ・キャッシュ・ノード１１２または他のリーダ・キャッシュ・ノード１１４から受信される複数のクエリをサポートする。たとえば、クエリｏｂｊｅｃｔ＿ａｄｄ｛ＩＤ１，ノード・タイプ１，メタデータ（必ず指定されるわけではない），ペイロード（必ず指定されるわけではない）｝は、受信するキャッシュ・ノードに、ノードＩＤ１が対応するシャード内に、指定されたノード・タイプ１の、このクエリ内で指定されるノードＩＤ１を有する新しいノードを格納させる。受信するキャッシュ・ノードは、ノードＩＤ１を用いて、指定される場合に、メタデータ（たとえば、タイムスタンプ）およびペイロード（たとえば、ｎａｍｅ−ｖａｌｕｅペアおよび／またはテキスト、メディア、リソース、もしくはリソースへの参照などのコンテンツ）をも格納する。もう１つの例として、クエリｏｂｊｅｃｔ＿ｕｐｄａｔｅ｛ＩＤ１，ノード・タイプ１（必ず指定されるわけではない），メタデータ（必ず指定されるわけではない），ペイロード（必ず指定されるわけではない）｝は、受信するキャッシュ・ノードに、対応するシャード内の、このクエリ内で指定されるノードＩＤ１によって識別されるノードを更新させる（たとえば、ノード・タイプをクエリ内で指定されるノード・タイプ１に変更する、クエリ内で指定されるメタデータを用いてメタデータを更新する、あるいは、クエリ内で指定されるペイロードを用いて格納されたコンテンツを更新する）。もう１つの例として、クエリｏｂｊｅｃｔ＿ｄｅｌｅｔｅ｛ノードＩＤ１｝は、受信するキャッシュ・ノードに、クエリ内で指定されるノードＩＤ１によって識別されるノードを削除させる。もう１つの例として、クエリｏｂｊｅｃｔ＿ｇｅｔ｛ノードＩＤ１｝は、クエリ内で指定されるノードＩＤ１によって識別されるノードを用いて格納されたコンテンツを取り出させる。

ここで、エッジ・クエリ（すぐ上で説明したノード・クエリではなく）を参照すると、
クエリａｓｓｏｃ＿ａｄｄ｛ＩＤ１，エッジ・タイプ１，ＩＤ２，メタデータ（必ず指定されるわけではない）｝は、受信するキャッシング・ノード（ノードＩＤ１を格納する）に、ノードＩＤ１によって識別されるノードとノードＩＤ２によって識別されるノードとの間にエッジ・タイプがエッジ・タイプ１のエッジを作成させ、指定される場合にメタデータ（たとえば、エッジが要求された時を示すタイムスタンプ）と一緒に、ノードＩＤ１によって識別されるノードを用いてエッジを格納させる。もう１つの例として、クエリａｓｓｏｃ＿ｕｐｄａｔｅ｛ノードＩＤ１，エッジ・タイプ１，ノードＩＤ２，メタデータ（必ず指定されるわけではない）｝は、受信するキャッシュ・ノード（ノードＩＤ１を格納する）に、ノードＩＤ１によって識別されるノードとノードＩＤ２によって識別されるノードとの間のエッジを更新させる。もう１つの例として、クエリａｓｓｏｃ＿ｄｅｌｅｔｅ｛ノードＩＤ１，エッジ・タイプ１（必ず指定されるわけではない），ノードＩＤ２｝は、受信するキャッシュ・ノード（ノードＩＤ１を格納する）に、ノードＩＤ１によって識別されるノードとノードＩＤ２によって識別されるノードとの間のエッジを削除させる。もう１つの例として、クエリａｓｓｏｃ＿ｇｅｔ｛ノードＩＤ１，エッジ・タイプ１，ソートキー（必ず指定されるわけではない），開始（必ず指定されるわけではない），限度（必ず指定されるわけではない）｝は、受信するキャッシュ・ノード（ノードＩＤ１を格納する）に、ノードＩＤ１によって識別されるノードにエッジ・タイプ１のエッジによって接続されたノードのノードＩＤを返させる。さらに、指定された場合に、ソートキーは、フィルタを指定する。たとえば、ソートキーがタイムスタンプを指定する場合には、受信するキャッシュ・ノード（ノードＩＤ１を格納する）は、ノードＩＤ１によって識別されるノードにエッジ・タイプ１のエッジによって接続されたノードのノードＩＤを返す。ここで、エッジ・タイプ１のエッジは、開始パラメータによって指定される時間値と限度パラメータによって指定される時間値との間に作成されている。もう１つの例として、クエリａｓｓｏｃ＿ｅｘｉｓｔｓ｛ノードＩＤ１，エッジ・タイプ１，他のノードＩＤのリスト，ソートキー（必ず指定されるわけではない），開始（必ず指定されるわけではない），限度（必ず指定されるわけではない）｝は、受信するキャッシュ・ノード（ノードＩＤ１を格納する）に、シャードＩＤ１によって識別されるノードにエッジ・タイプ１のエッジによって接続された、他のノードＩＤのリスト内で指定されるノードのノードＩＤを返させる。さらに、上で説明したクエリを、説明された形で送信し、リーダ・キャッシュ・ノード１１４を更新するのに使用することができる。

１実装形態では、リーダ・キャッシュ・クラスタ１０８およびフォロワ・キャッシュ・クラスタ１０６のキャッシュによって実施されるキャッシング・レイヤは、１または複数のクエリ・タイプに関する高いクエリ・レートをサポートする形で１または複数のインデックス内の関連付けデータ（ａｓｓｏｃｉａｔｉｏｎ ｄａｔａ）を維持する。或る実装形態では、本発明は、グラフ内のノードの間の関連付けを対象とする効率的な共通部分クエリ、メンバシップ・クエリ、およびフィルタリング・クエリを容易にする。たとえば、１実装形態で、キャッシング・レイヤは、ノード同士の間の様々な関連付けに関するポイント・ルックアップ・クエリ、レンジ・クエリ、およびカウント・クエリを処理するために最適化された形で、情報をキャッシングする。たとえば、ページを構成する際に、クライアント・サーバ１０４は、所与のユーザのすべての友達に関するクエリを発行しうる。クライアント・サーバ１０４は、ユーザおよび「友達」エッジ・タイプを識別するａｓｓｏｃ＿ｇｅｔクエリを発行することができる。クエリの処理を容易にするために、キャッシング・レイヤ内のキャッシング・ノードは、第１ノード（たとえば、ユーザに対応するノード）とユーザの連絡先または友達に対応するノードとの間の所与のタイプの関連付け（「友達」、「ファン」、「メンバ」、「いいね」、その他など）を格納することができる。さらに、ページの別の当事者を構成するために、クライアント・サーバ１０４は、ユーザまたはユーザ・プロファイル、「ウォールポスト（ｗａｌｌｐｏｓｔ）」エッジ・タイプ、および限度値を識別するａｓｓｏｃ＿ｇｅｔクエリを発行することによって、プロファイル上のウォール・ポストの最後のＮ個のセットのクエリを発行することができる。
同様に、特定のウォール・ポストに対するコメントを、同様の形で取り出すことができる。

１実装形態では、フォロワ・キャッシュ・クラスタ１０６およびリーダ・キャッシュ・クラスタによって実施されるキャッシング・レイヤは、高速検索を容易にし、高いクエリ・レートを処理するグラフ内のノード（ｉｄ１，ｉｄ２）同士の間の関連付けのためのインメモリ構造のセットを維持する。たとえば、（ｉｄ１，タイプ）関連付けセット（ｉｄ１で始まり、所与のタイプを有するすべての関連付けのセット）ごとに、キャッシング・レイヤは、２つのインメモリ・インデックスを維持する。上で述べたように、これらの関連付けセットは、ｉｄ１が含まれるシャードに基づく各クラスタ内のキャッシュ・ノードによって維持される。さらに、下で述べる構造を考慮すると、２つのノードの間の所与の関連付けを、関連付けのそれぞれのノードに向けられた２つの関連付けセットに格納することができる。第１インデックスは、時間的属性（たとえば、タイム・スタンプ）に基づいており、レンジ・クエリをサポートする。ｉｄ２による第２インデックスは、レンジ・クエリをサポートしないが、挿入およびルック・アップのよりよい時間計算量（ｔｉｍｅ
ｃｏｍｐｌｅｘｉｔｙ）をサポートする。１実装形態では、第１インデックスは、環状バッファ内に格納される関連付けエントリの順序付き動的配列である。環状バッファ内の各エントリは、１つの関連付けを記述しまたはこれに対応し、以下のフィールドを含む：ａ）＄ｆｌａｇｓ（１バイト）（関連付けの可視性を示す）、ｂ）＄ｉｄ２（８バイト）、ｃ）＄ｔｉｍｅ（４バイト）、ｄ）＄ｄａｔａ（８バイト）（＄ｄａｔａは、固定サイズ８バイト・フィールドである（９バイト以上が＄ｄａｔａのために必要である時には、＄ｄａｔａは、完全な＄ｄａｔａ値を保持する別のメモリ・チャンクへのポインタになる。＄ｄａｔａは、所与のａｓｓｏｃ型についてオプションである）、およびｅ）＄ｌｉｎｋ（８バイト）同一のｉｄ２インデックス・バケット内の次のエントリおよび前のエントリのオフセット（下を参照されたい）。１実装形態では、配列は、＄ｔｉｍｅ属性の昇順で順序付けられる。インデックス内のエントリの個数は、上限を設けられ（１００００など）、関連付けタイプによって構成可能である。限度に達した時には、配列がラップ・アラウンドする。配列は、＄ｔｉｍｅによってソートされるので、最も新しいエントリが、既存の要素のいずれをもシフトせずに末尾に付加される。

１実装形態では、主インデックスを、グローバルｍｅｍｃａｃｈｅｄハッシュ・テーブルを介して名前によってルック・アップできる単一のｍｅｍｃａｃｈｅキー（「ａｓｓｏｃ：＜ｉｄ１＞：＜タイプ＞」）に格納することができる。配列は、以下のフィールドを含むヘッダを前に付けることができる：ａ）ｃｏｕｎｔ（４バイト）（ｉｄ１，タイプ）関連付けセット内の可視の関連付けのカウント（インデックス内のキャッシングされるエントリだけではなく、永続的に格納される）、ｂ）ｈｅａｄ（４バイト）環状バッファ内の配列頭部（最大にソートされる要素）のバイト・オフセット、ｃ）ｔａｉｌ（４バイト）環状バッファ内の配列尾部（最小にソートされる要素）のバイト・オフセット、およびｄ）ｉｄ２ ｉｎｄｅｘ ｐｏｉｎｔｅｒ（８バイト）ｉｄ２ハッシュ・テーブルを含むブロックへのポインタ。

第２（＄ｉｄ２）インデックスは、１実施形態では、ハッシュ・テーブルとして実施され、所与の（＄ｉｄ１，＄ｔｙｐｅ，＄ｉｄ２）関連付けに関する迅速な挿入およびルックアップをサポートする。ハッシュ・テーブル自体は、１実装形態で、ｍｅｍｃａｃｈｅｄのメモリ・アロケータを用いて割り当てられる別々のブロック内に格納することができる。このテーブルは、それぞれが対応するハッシュ・バケット内の最初の要素を識別する主インデックスへのオフセットの配列である。要素は、その＄ｌｉｎｋフィールドを介してバケットにリンクされる。別々のブロック内にハッシュ・テーブルを格納することは、実装者（ｉｍｐｌｅｍｅｎｔｅｒｓ）が、テーブルおよび主インデックスのサイズを独立に変更することを可能にし、したがって、関連付けセットが増大する時にコピーされるメ
モリの量を減らす。インプレースでのバケットへの関連付けエントリのリンクも、メモリ効率を改善する。ハッシュ・テーブル（およびバケット・リスト）は、隠しまたは削除としてマークされたエントリがインデックスから抹消される時に、再構築される必要がある可能性があるが、これは、まれにしか行われない。

したがって、同一＜タイプ＞の新しい関連付けが追加される時には、キャッシュ・ノード１１２および１１４は、新たに関連付けされたオブジェクトをハッシュ・テーブルおよび環状バッファに追加し、最も古いエントリを環状バッファから除去する。上で述べたように、＜ソートキー＞値を使用して、タイム・スタンプなどの属性に基づいて、一致するエントリをソートすることができる。さらに、＜限度＞値は、返される結果の個数を最初のＮ個の値に制限し、ここで、Ｎ＝＜限度＞である。この構成は、非常に高いクエリ・レートでノード同士の間の関連付けに関するクエリに応じることを可能にする。たとえば、第１のクエリが、ウェブ・ページのセクション内に友達のセットを表示することを要求する場合がある。キャッシュ・ノードは、主インデックスにアクセスすることによってｉｄ１に対応する関連付けセットをルック・アップすることと、環状バッファ内の最初のＮ（Ｎ＝限度）個のｉｄ２エントリを取り出すこととによって、ｇｅｔ＿ａｓｓｏｃ（ｉｄ１，タイプ，ソートキー，限度）クエリにすばやく応答することができる。さらに、副インデックスのハッシュ・テーブルは、ポイント・ルック・アップを容易にする。さらに、キャッシング・レイヤによって維持されるカウント値は、所与の関連付けセット（ｉｄ１，タイプ）のカウントに対する高速応答を容易にする。

データの格納および提供のいくつかの一般的な例を、これから説明する（ソーシャル・グラフの特定の例示的な実装形態に関する、より特定の例は、その後、ソーシャル・グラフの特定の例示的な実装形態を説明した後に説明する）。たとえば、クライアント・サーバ１０４が、ネットワーキング・システム１００のユーザからまたはネットワーキング・システム１００の別のサーバ、コンポーネント、アプリケーション、もしくは処理から（たとえば、ユーザ要求に応答して）など、ウェブ・ページに関する要求を受信する時に、クライアント・サーバ１０４は、要求されたウェブ・ページを生成するために１または複数のクエリを発行する必要がある場合がある。さらに、ユーザがネットワーキング・システム１００とやり取りする時に、クライアント・サーバ１０４が、オブジェクト・ノードを確立しもしくは変更する要求および／または関連付けがオブジェクト・ノードになることの要求を受信する場合がある。或る場合に、クライアント・サーバ１０４によって受信される要求は、一般に、クライアント・サーバ１０４への要求がそのユーザの代わりに行われたユーザを表すノードＩＤを含む。この要求は、それに加えてまたはその代わりに、ユーザが、見る、更新する、削除する、または接続するか（エッジに）関連付けることを望む可能性があるオブジェクトに対応する１または複数の他のノードＩＤを含むことができる。

たとえば、要求は、ユーザが見ることを望む１または複数のオブジェクト（たとえば、ウェブ・ページを提供する１または複数のオブジェクト）に関連する情報にアクセスする読取要求でもよい。たとえば、この読取要求は、特定のノードに関して格納されたコンテンツを求める要求でもよい。たとえば、ユーザ・プロファイルに対するウォール・ポストを、「ウォールポスト」のエッジ・タイプを有するノードとして表すことができる。ウォールポストに対するコメントをも、ウォールポストに対するエッジ・タイプ「コメント」の関連付けを有する、グラフ内のノードとして表すことができる。そのような例では、特定の実施形態で、クライアント・サーバ１０４は、要求されたコンテンツまたは他の情報を含むオブジェクト（ノード）のノードＩＤに対応するシャードＩＤを判定し、（クライアント・サーバ１０４にサービス提供するフォロワ・キャッシュ・クラスタ１０６内の）フォロワ・キャッシュ・ノード１１２のどれがそのシャードＩＤを格納するのかを判定するためにマッピング・テーブルを使用し、そのシャードＩＤに関連付けられ、そのシャー
ドＩＤを用いて格納された情報を格納するフォロワ・キャッシュ・ノード１１２のうちの特定の１つに、そのシャードＩＤを含むクエリを送信する。その後、特定のフォロワ・キャッシュ・ノード１１２は、（対応するシャード内に要求された情報がキャッシングされている場合に）要求された情報を取り出し、要求するクライアント・サーバ１０４にその情報を送信し、この要求するクライアント・サーバ１０４は、その後、この情報を、要求するユーザにサービス提供することができる（たとえば、ユーザのコンピューティング・デバイス上で実行されるウェブ・ブラウザまたは他の文書をレンダリングするアプリケーションによってレンダリング可能なＨＴＭＬまたは他の構造化文書の形で）。要求された情報が、フォロワ・キャッシュ・ノード１１２内に格納／キャッシングされていない場合には、フォロワ・キャッシュ・ノード１１２は、マッピング・テーブルを使用して、リーダ・キャッシュ・ノード１１４のどれが、シャードＩＤを格納するシャードを格納するのか判定し、クエリを、シャードＩＤを格納する特定のリーダ・キャッシュ・ノード１１４に転送する。要求された情報が、その特定のリーダ・キャッシュ・ノード１１４内でキャッシングされている場合には、そのリーダ・キャッシュ・ノード１１４は、要求された情報を取り出し、これをフォロワ・キャッシュ・ノード１１２に転送することができ、このフォロワ・キャッシュ・ノード１１２は、要求された情報をシャードＩＤを用いて格納するためにフォロワ・キャッシュ・ノード１１２内の特定のシャードを更新し、説明したばかりのクエリをクライアント・サーバ１０４にサービス提供することに進み、このクライアント・サーバ１０４は、その情報を、要求するユーザにサービス提供することができる。要求された情報が、リーダ・キャッシュ・ノード１１４内でキャッシングされていない場合には、リーダ・キャッシュ・ノード１１４は、クエリをデータベース１１０の言語に変換し、新しいクエリをデータベース１１０に送信することができ、このデータベース１１０は、要求された情報を取り出し、要求された情報をこの特定のリーダ・キャッシュ・ノード１１４に送信する。このリーダ・キャッシュ・ノード１１４は、その後、取り出された情報を、グラフ管理ソフトウェアによって理解されるグラフ言語に戻って変換し、要求された情報をシャードＩＤを用いて格納するためにリーダ・キャッシュ・ノード１１４内の特定のシャードを更新し、取り出された情報を特定のフォロワ・キャッシュ・ノード１１２に送信することができる。このフォロワ・キャッシュ・ノード１１２は、要求された情報をシャードＩＤを用いて格納するためにフォロワ・キャッシュ・ノード１１２内の特定のシャードを更新し、説明したばかりのクエリをクライアント・サーバ１０４にサービス提供することに進む。そして、このクライアント・サーバ１０４は、この情報を、要求するユーザにサービス提供することができる。

もう１つの例として、ユーザ要求が、ノードに関する既存情報を更新するか追加情報を格納し、または２つのノードの間のエッジを作成するか変更する書込要求である場合がある。前者の場合に、格納される要求が既存ではないノードに関する場合には、このユーザ要求を受信するクライアント・サーバ１０４は、新しいノードのノードＩＤを求める要求を、そのクライアント・サーバ１０４にサービス提供するそれぞれのフォロワ・キャッシュ・クラスタ１０６に送信する。或る場合または実施形態では、クライアント・サーバ１０４は、新しいノードを格納すべき特定のシャードを指定することができる（たとえば、新しいノードを別のノードと同一位置に配置するために）。その場合に、クライアント・サーバ１０４は、指定されたシャードを格納する特定のフォロワ・キャッシュ・ノード１１２に新しいノードＩＤを要求する。代替案では、クライアント・サーバ１０４は、新しいノードＩＤの要求と共に既存ノードのノードＩＤを、渡されるノードＩＤを格納するシャードを格納するフォロワ・キャッシュ・ノード１１２に渡して、そのフォロワ・キャッシュ・ノード１１２に、シャード内に格納された複数のノードＩＤの範囲内にある新しいノードのノードＩＤをクライアント・サーバ１０４に応答させることができる。他の場合または実施形態では、クライアント・サーバ１０４は、新しいノードＩＤ要求をそこに送信すべき特定のフォロワ・キャッシュ・ノード１１２または特定のシャードを（たとえば、ランダムにまたは或る関数に基づいて）選択することができる。いずれの場合でも、特
定のキャッシュ・ノード１１２、またはより具体的にはそのフォロワ・キャッシュ・ノード１１２上で実行されるグラフ管理ソフトウェアは、新しいノードＩＤをクライアント・サーバ１０４に送信する。その後、クライアント・サーバ１０４は、対応するフォロワ・キャッシュ・ノード１１２に対する、新しいノードＩＤを含む書込要求を定式化する（ｆｏｒｍｕｌａｔｅ）ことができる。この書込要求は、新しいノードのノード・タイプを指定し、ノードＩＤを用いて格納されるペイロード（たとえば、新しいノードと共に格納されるコンテンツ）と、メタデータ（たとえば、他のデータの中でも、要求を行うユーザのノードＩＤ、要求がクライアント・サーバ１０４によって受信された時を示すタイムスタンプ）とのうちの少なくとも一方を含むこともできる。たとえば、フォロワ・キャッシュ・ノード１１２に送信される書込要求を、ｏｂｊｅｃｔ＿ａｄｄ｛ノードＩＤ，ノード・タイプ，ペイロード，メタデータ｝の形であるものとすることができる。同様に、ノードを更新するために、クライアント・サーバ１０４は、ノードＩＤがその中に格納されるシャードを格納するフォロワ・キャッシュ・ノード１１２に、ｏｂｊｅｃｔ＿ｍｏｄｉｆｙ｛ノードＩＤ，ノード・タイプ，ペイロード，メタデータ｝の形の書込要求を送信することができる。同様に、ノードを削除するために、クライアント・サーバ１０４は、シャードＩＤがその中に格納されるシャードを格納するフォロワ・キャッシュ・ノード１１２に、ｏｂｊｅｃｔ＿ｄｅｌｅｔｅ｛ノードＩＤ｝の形の要求を送信することができる。

特定の実施形態では、フォロワ・キャッシュ・ノードは、その後、対応するノードＩＤを格納するシャードを格納するリーダ・キャッシュ・ノード１１４に要求を送信し、その結果、リーダ・キャッシュ・ノード１１４は、シャードを更新できるようになる。その後、リーダ・キャッシュ・ノード１１４は、要求をデータベース１１０の言語に変換し、変換された要求をデータベース１１０に送信し、その結果、データベースを更新できるようにする。

図４に、２つのノードの間の関連付けを追加する要求（ａｓｓｏｃ＿ａｄｄ）を処理する例示的な方法を示す。図４に示されているように、フォロワ・キャッシュ・ノード１１２は、ａｓｓｏｃ＿ａｄｄ要求（たとえば、ａｓｓｏｃ＿ａｄｄ（ｉｄ１，ｔｙｐｅ，ｉｄ２，メタデータ）を受信する時に、インデックスにアクセスして、ｉｄ１およびタイプ（ｔｙｐｅ）に対応する関連付けセット・オブジェクトを識別する（４０２）。フォロワ・キャッシュ・ノード１１２は、ハッシュ・テーブルと関連付けセット・オブジェクトの環状バッファとの両方にｉｄ２を追加し、関連付けセット・オブジェクトのカウント値をインクリメントする（４０４）。関連付けセット・オブジェクトは、今、ノードｉｄ１とノードｉｄ２との間の所与のタイプの新しい関連付けを維持する。ｉｄ２に対する相対的な関連付けの検索を容易にするために、フォロワ・キャッシュ・ノード１１２は、ノード識別子ｉｄ２に対応するシャードＩｄを識別し、識別されたシャードを処理するクラスタ内のフォロワ・キャッシュ・ノード１１２にａｓｓｏｃ＿ａｄｄ要求を転送する（４０６）。現在のフォロワ・キャッシュ・ノード１１２がそのシャードを処理する場合には、現在のフォロワ・キャッシュ・ノード１１２が、ａｓｓｏｃ＿ａｄｄ要求を処理する。１実装形態では、転送するフォロワ・キャッシュ・ノード１１２は、変更されたａｓｓｏｃ＿ａｄｄ要求を送信することができる。変更されたａｓｓｏｃ＿ａｄｄ要求は、キャッシュ・レイヤ内の双方向関連付けを確立するのに必要な更新であることをシグナリングする。フォロワ・キャッシュ・ノード１１２は、ｉｄ１が含まれるシャードに対応するリーダ・キャッシュ・ノード１１４にもａｓｓｏｃ＿ａｄｄ要求を転送する（４０８）。リーダ・キャッシュ・ノード１１４は、同様の工程を実行して、リーダ・キャッシュ・クラスタ内で双方向関連付けを確立する。また、リーダ・キャッシュ・ノード１１４は、新しい関連付けをデータベース１１０内で永続させる。このように、ノードｉｄ１とノードｉｄ２との間の関連付けは、今、インデックス内で、ｉｄ１およびタイプならびに別々にｉｄ２およびタイプへの参照を用いて検索可能である。

特定の実施形態では、グラフは、ユーザ、ページ、イベント、ウォール・ポスト、コメント、写真、ビデオ、背景情報、コンセプト、興味、およびノードとして表すのに有用である任意の他の要素など、様々な異なるノード・タイプを維持することができる。エッジ・タイプは、ノード同士の間の関連付けに対応し、友達、フォロワ、サブスクライバ、ファン、いいね（または興味の他の表示）、ウォールポスト、コメント、リンク、提案、推奨、およびノード同士の間の他のタイプの関連付けを含むことができる。１実装形態では、グラフの一部を、ソーシャル・ネットワーク環境のそれぞれのユーザにそれぞれが対応するユーザ・ノードを含むソーシャル・グラフとすることができる。ソーシャル・グラフは、トピックノードだけでなく、それぞれが特定のコンセプトの専用であるかこれを対象とするコンセプト・ノードなどの他のノードをも含むことができる。トピック・ノードは、一時的（ｅｐｈｅｍｅｒａｌ）であってもなくてもよく、それぞれは、ソーシャル・ネットワーク環境のユーザの間で現在興味を持たれている特定のトピックの専用であるかこれを対象とする。特定の実施形態では、各ノードは、ソーシャル・ネットワーク環境内でホスティングされまたはアクセス可能である対応するウェブ・ページ（「プロファイル・ページ）を有し、表し、またはこれによって表される。たとえば、ユーザ・ノードは、対応するユーザ・プロファイル・ページを有することができる。対応するユーザ・プロファイル・ページでは、対応するユーザは、コンテンツを追加し、宣言を行い、他の形で彼自身または彼女自身を表現することができる。たとえば、下で説明するように、たとえばユーザ・プロファイル・ページ、コンセプト・プロファイル・ページ、またはトピック・プロファイル・ページなど、ソーシャル・ネットワーク環境内でホスティングされまたはアクセス可能である様々なウェブ・ページは、ユーザが、コンテンツをポストし、ステータス更新をポストし、メッセージをポストし、そのユーザまたは他のユーザによってサブミットされた他のポストに対するコメントを含むコメントをポストし、興味を宣言し、前述のポストならびにページおよび特定のコンテンツのいずれかに向かって「いいね」（下で説明する）を宣言し、あるいは、他の形で彼ら自身を表現するか様々なアクション（以下では、これらおよび他のユーザ・アクションを、集合的に「ポスト」または「ユーザ・アクション」と呼ばれる場合がある）を実行することを可能にする。或る実施形態では、ポスティング（ｐｏｓｔｉｎｇ）は、メディア・コンテンツ（たとえば、写真、ビデオ、音楽、テキストなど）、ｕｎｉｆｏｒｍ ｒｅｓｏｕｒｃｅ ｌｏｃａｔｏｒ（ＵＲＬ）、および他のノードなどの追加コンテンツに、そのそれぞれのプロファイル・ページ、他のユーザ・プロファイル・ページ、コンセプト・プロファイル・ページ、トピック・ページ、または他のウェブ・ページもしくはウェブ・アプリケーションを介してリンクしまたは他の形で参照することを含むことができる。そのようなポスト、宣言、またはアクションを、作成するユーザならびに他のユーザによって可視とすることができる。特定の実施形態では、ソーシャル・グラフはさらに、それぞれがソーシャル・グラフ内のノードの対応するペアのノード同士の間の接続を定義しまたは表す複数のエッジを含む。上で述べたように、コンテンツの各アイテムを、他のノードにリンクされたグラフ内のノードとすることができる。

すぐ上で説明したように、様々な例示的な実施形態では、１または複数の説明されるウェブ・ページまたはウェブ・アプリケーションは、ソーシャル・ネットワーク環境またはソーシャル・ネットワーキング・サービスに関連する。本明細書で使用される時に、「ユーザ」は、そのようなソーシャル・ネットワーク環境とまたはこれを介してやり取りしまたは通信する、個人（人間のユーザ）、エンティティ（たとえば、企業、商店、またはサード・パーティ・アプリケーション）、または（たとえば、個人のまたはエンティティの）グループとすることができる。本明細書で使用される時に、「登録ユーザ」は、ソーシャル・ネットワーク環境内で公式に登録されたユーザを指す（一般に、本明細書で説明されるユーザおよびユーザ・ノードは、登録ユーザだけを指すが、これは、他の実施形態では必ずしも要件ではない；すなわち、他の実施形態では、本明細書で説明されるユーザおよびユーザ・ノードが、本明細書で説明されるソーシャル・ネットワーク環境に登録され
ていないユーザを指す場合がある）。特定の実施形態では、各ユーザは、対応する「プロファイル」ページを有し、対応する「プロファイル」ページは、ソーシャル・ネットワーク環境によって格納され、ホスティングされ、またはアクセス可能であり、他のユーザのすべてまたは選択されたサブセットによって可視である。一般に、ユーザは、彼または彼女自身のそれぞれのプロファイル・ページのすべてまたは一部に対する、ならびに潜在的に、たとえば他の可能性の中でも、ホーム・ページ、ウェブ・アプリケーションをホスティングするページを含む特定のユーザによってまたはこれのために作成された他のページに対する管理権を有する。本明細書で使用される時に、「認証されたユーザ」は、そのユーザが管理権を有する対応するプロファイル・ページで主張されるユーザであるものとしてソーシャル・ネットワーク環境によって認証されたユーザを、または代替では、主張されるユーザの適切に信頼される代理人を指す。

２つのユーザ同士またはコンセプト同士の間の接続は、ソーシャル・ネットワーク環境のユーザ同士またはコンセプト同士の間の定義された関係を表すことができ、それに関して関連付けが行われたソーシャル・ネットワーク環境のユーザ、コンセプト、イベント、または他のノードに対応するノード同士の間のエッジとしてソーシャル・ネットワーク環境の適切なデータ構造内で論理的に定義され得る。本明細書で使用される時に、「ｆｒｉｅｎｄｓｈｉｐ」は、ソーシャル・ネットワーク環境のユーザのペアのユーザ同士の間の、定義されたソーシャル関係などの関連付けを表す。本明細書で使用される時に、「友達」は、別のユーザが接続、ｆｒｉｅｎｄｓｈｉｐ、関連付け、または関係を形成し、２人のユーザの間にエッジを生成させた、ソーシャル・ネットワーク環境の任意のユーザを指すことができる。たとえば、２人の登録ユーザは、たとえば、２人のユーザの一方が、他方のユーザにｆｒｉｅｎｄｓｈｉｐ要求を送信するか送信させた結果としてｆｒｉｅｎｄｓｈｉｐについて他方を選択することによるなど、明示的にお互いに友達になることができる。その要求について、他方のユーザは、受け入れまたは拒否することができる。代替案では、ｆｒｉｅｎｄｓｈｉｐまたは他の接続を、自動的に確立することができる。そのようなソーシャルｆｒｉｅｎｄｓｈｉｐを、他のユーザ、特に彼ら自身が登録ユーザの一方または両方の友達であるユーザに可視とすることができる。登録ユーザの友達は、登録ユーザのプロファイルまたは他のページ上のコンテンツ、特にユーザ生成コンテンツまたは宣言されたコンテンツに対する高められたアクセス特権（ｉｎｃｒｅａｓｅｄ ａｃｃｅｓｓ ｐｒｉｖｉｌｅｇｅｓ）を有することもできる。しかし、ソーシャル・グラフ内で彼らの間に友達接続を確立させた２人のユーザが、実生活（ソーシャル・ネットワーキング環境の外部）では必ずしも（通常の意味での）友達ではない場合があることに留意されたい。たとえば、或る実装形態で、あるユーザが、ビジネスまたは他の人間以外のエンティティであり、したがって、この単語の伝統的な意味で、人間のユーザの友達になることができない場合がある。

本明細書で使用される時に、「ファン」は、特定のユーザ、ウェブ・ページ、ウェブ・アプリケーション、またはソーシャル・ネットワーク環境内でアクセス可能な他のウェブ・コンテンツのサポータまたはフォロワであるユーザを指すことができる。特定の実施形態では、あるユーザが特定のウェブ・ページのファンである（特定のウェブ・ページを「愛好する（ｆａｎ）」）時に、そのユーザを、他の登録ユーザまたは一般大衆が見るために、ファンとしてそのページ上でリストすることができる。さらに、ユーザのアバタまたはプロファイル写真を、そのページに（または、下で説明されるページのいずれかの中／上に）示すことができる。本明細書で使用される時に、「いいね」は、ユーザ、特に登録ユーザまたは認証されたユーザが、限定ではなく例として、彼または彼女がそれを「いいね」と思い、そのファンであり、それを支持し、楽しみ、または他の形で肯定的に捉えていることを宣言しまたは他の形で実証した、他の可能性の中でもポスト、コメント、興味、リンク、媒体（たとえば、写真、写真アルバム、ビデオ、音楽など）、コンセプト、エンティティ、またはページなどのものを指すことができる（或る実装形態では、ユーザは
、ソーシャル・ネットワーク・システムまたはソーシャル・ネットワーク環境によってホスティングされまたはアクセス可能である任意のページに対して、いいねまたは事実上何でも示しまたは宣言することができる）。１実施形態では、「いいね」を示しもしくは宣言することまたはユーザがあるものの「ファン」であることを示しもしくは宣言することを、ソーシャル・ネットワーキング環境内で同等に処理し、定義することができ、交換可能に使用することができる。同様に、自分自身がコンセプトもしくはコンセプト・プロファイル・ページなど、何かの「ファン」であると宣言することまたは自分自身があることを「いいね」と思うことを宣言することを、ソーシャル・ネットワーキング環境内で同等に定義し、本明細書で交換可能に使用することができる。さらに、本明細書で使用される時に、「興味」は、ユーザのプロファイル・ページ内で提示される、ユーザの宣言した興味など、ユーザが宣言した興味を指すことができる。本明細書で使用される時に、「ほしい（ｗａｎｔ）」は、ユーザが欲しがる事実上すべてのものを指すことができる。上で説明したように、「コンセプト」は、たとえば、スポーツ、スポーツ・チーム、音楽のジャンル、作曲家、趣味、会社（企業）、エンティティ、グループ、有名人、登録ユーザではない人、またはイベント、或る実施形態では別のユーザ（たとえば、認証されないユーザ）、その他などへの興味、いいねと思う気持ち、または関係をユーザが宣言しまたは他の形で実証できる事実上すべてのものを指すことができる。たとえば、複数のユーザのうちの１または複数（たとえば、ジェリー・ライス以外）によって作成され、管理される、有名なプロ・フットボール・プレイヤである「ジェリー・ライス」のコンセプト・ノードおよびコンセプト・プロファイル・ページがあると同時に、ソーシャル・グラフが、さらに、ジェリー・ライス自身（またはジェリー・ライスの信頼されもしくは認可された代理人）によって作成され、管理されるジェリー・ライスのユーザ・ノードおよびユーザ・プロファイル・ページを含む場合がある。

図５に、分散冗長システムを示す。図示の実装形態では、分散冗長システムは、少なくとも第１データ・センタ１０２ａおよび第２データ・センタ１０２ｂを含む。データ・センタ１０２ａおよび１０２ｂのそれぞれは、１または複数のフォロワ・キャッシュ・クラスタ１０６ならびにリーダ・キャッシュ・クラスタ１０８ａおよび１０８ｂを含む。１実装形態では、リーダ・キャッシュ・クラスタ１０８ａは、主（マスタ）キャッシュ・クラスタとして働き、リーダ・キャッシュ・クラスタ１０８ｂは、副（スレーブ）キャッシュ・クラスタとして働く。１実装形態では、データ・センタ１０２ａ、１０２ｂは、データベース１１０の複製されたコピーを達成するために同期化機能が使用されるという意味で、冗長である。１実装形態では、データ・センタ１０２ａを、ある地理的領域（米国の西海岸など）に物理的に配置して、その領域からのトラフィックにサービス提供することができ、データ・センタ１０２ｂを、別の地理的領域（米国の東海岸など）に物理的に配置することができる。これらの領域のいずれからのユーザも、同一のデータおよび関連付けにアクセスできると仮定すると、効率的な同期化機構が望ましい。

図６に、リーダ・キャッシュ・ノード１１４が書込コマンドをどのように処理するのかの例示的な方法を示す。上で図５を参照して述べたように、フォロワ・キャッシュ・ノード１１２が、オブジェクトまたは関連付けを追加／更新する書込コマンドをクライアント・サーバ１０４から受信する場合がある（図５、１）。フォロワ・キャッシュ・ノード１１２は、この書込コマンドを、対応するリーダ・キャッシュ・ノード１１４に転送する（図５、２）。リーダ・キャッシュ・ノード１１４は、フォロワ・キャッシュ・ノードから書込コマンドを受信する（６０２）時に、リーダ・キャッシュ・クラスタ１０８ａによって維持されるキャッシュ内の１または複数のエントリを更新するために書込コマンドを処理し（６０４）、更新を永続データベース１１０ａに書き込む（６０６）（図５、３）。また、リーダ・キャッシュ・ノード１１４は、フォロワ・キャッシュ・ノード１１２に書込コマンドを肯定応答し（ＡＣＫ）、更新をデータ・センタ１０２ａの他のフォロワ・キャッシュ・クラスタ１０６（図５、４ａ）および副リーダ・キャッシュ・クラスタ１０８
ｂにブロードキャストし、副リーダ・キャッシュ・クラスタ１０８ｂは、更新をそのフォロワ・キャッシュ・クラスタ１０６に転送する（図５、４ｂ）（６０８）。図６に示されているように、リーダ・キャッシュ・ノード１１４は、更新をレプリケーション・ログにも追加する（６１０）。データベース１１０ａ、１１０ｂは、永続データベースを同期化するために、ＭｙＳＱＬ Ｒｅｐｌｉｃａｔｉｏｎなどの同期化機構を実施する。

図７に、本発明の１実装形態によるメッセージ・フローを示す。書込コマンドが、主リーダ・キャッシュ・クラスタ１０８ａに直接には関連しないリング１０６内のフォロワ・キャッシュ・ノード１１２で受信される（図７、１）時に、そのフォロワ・キャッシュ・ノード１１２は、書込メッセージを処理のために主リーダ・キャッシュ・クラスタ１０８ａに転送する（図７、２）。主リーダ・キャッシュ・クラスタ１０８ａ内のリーダ・キャッシュ・ノード１１４は、そのフォロワ・キャッシュ・クラスタ１０６に更新をブロードキャストし（図７、３）、変更をデータベース１１０ａに書き込むことができる（図７、４）。図７に示されているように、書込コマンドを受信したフォロワ・キャッシュ・ノード１１２も、書込コマンドをその副リーダ・キャッシュ・クラスタ１０８ｂに転送することができ（図７、５）、この副リーダ・キャッシュ・クラスタ１０８ｂは、他のフォロワ・キャッシュ・クラスタ１０６に更新をブロードキャストする（図７、６）。したがって、前述のアーキテクチャは、データベース１１０ａ、１１０ｂの間の別々のレプリケーションがデータ・セキュリティを可能にすると同時に、キャッシング・レイヤに対する変更をデータ・センタにまたがってすばやく複製することを可能にする。

本明細書で説明されるアプリケーションまたは工程を、実行された時に１または複数のプロセッサに上で説明した動作を実施させるように動作可能である、有形のデータ記憶媒体上でまたはこれの中で実施されまたは符号化される一連のコンピュータ可読命令として実施することができる。前述の工程および機構を、様々な物理システムによってならびに様々なネットワーク環境およびコンピューティング環境内で実施することができるが、下で説明されるコンピューティング・システムは、限定する目的ではなく教訓的な目的のために、上で説明されるサーバ・システムおよびクライアント・システムの例示的なコンピューティング・システム・アーキテクチャを提供する。

図２に、サーバ２２ａ、２２ｂを実施するのに使用できる、例示的なコンピューティング・システム・アーキテクチャを示す。１実施形態では、ハードウェア・システム１０００は、プロセッサ１００２、キャッシュ・メモリ１００４、ならびに、有形のコンピュータ可読媒体上に格納された、明細書で説明される機能を対象とする、１または複数の実行可能モジュールおよびドライバを備える。さらに、ハードウェア・システム１０００は、高性能入出力（Ｉ／Ｏ）バス１００６および標準Ｉ／Ｏバス１００８を含む。ホスト・ブリッジ１０１０は、プロセッサ１００２を高性能Ｉ／Ｏバス１００６に結合し、Ｉ／Ｏバス・ブリッジ１０１２は、２つのバス１００６および１００８を互いに結合する。システム・メモリ１０１４および１または複数のネットワーク／通信インターフェース１０１６は、バス１００６に結合される。ハードウェア・システム１０００はさらに、ビデオ・メモリ（図示せず）およびビデオ・メモリに結合された表示デバイスを含むことができる。マス・ストレージ１０１８およびＩ／Ｏポート１０２０は、バス１００８に結合される。ハードウェア・システム１０００は、オプションで、キーボードおよびポインティング・デバイスと、バス１００８に結合された表示デバイス（図示せず）とを含むことができる。集合的に、これらの要素は、米国カリフォルニア州サンタ・クララのインテル（Ｉｎｔｅｌ Ｃｏｒｐｏｒａｔｉｏｎ）によって製造されるｘ８６互換プロセッサおよび米国カリフォルニア州サニーベールのアドバンスド・マイクロ・デバイセズ（Ａｄｖａｎｃｅｄ
Ｍｉｃｒｏ Ｄｅｖｉｃｅｓ（ＡＭＤ），Ｉｎｃ．）によって製造されるｘ８６互換プロセッサ、ならびに任意の他の適切なプロセッサに基づく汎用コンピュータ・システムを含むがこれに限定されないコンピュータ・ハードウェア・システムの広いカテゴリを表す
ことが意図されている。

ハードウェア・システム１０００の要素を、下でより詳細に説明する。具体的には、ネットワーク・インターフェース１０１６は、ハードウェア・システム１０００と、ＥＴＨＥＲＮＥＴ（登録商標）（たとえば、ＩＥＥＥ ８０２．３）ネットワーク、バックプレーン、その他など、広範囲のネットワークのいずれかとの間の通信を提供する。マス・ストレージ１０１８は、サーバ２２ａ、２２ｂ内で実施される上で説明した機能を実行するためのデータおよびプログラミング命令の永久ストレージを提供し、システム・メモリ１０１４（たとえば、ＤＲＡＭ）は、プロセッサ１００２によって実行される時にデータおよびプログラミング命令の一次ストレージを提供する。Ｉ／Ｏポート１０２０は、ハードウェア・システム１０００に結合され得る追加の周辺デバイス同士の間の通信を提供する、１または複数のシリアル通信ポートおよび／またはパラレル通信ポートである。

ハードウェア・システム１０００は、様々なシステム・アーキテクチャを含むことができ、ハードウェア・システム１０００の様々なコンポーネントは、再配置されうる。たとえば、キャッシュ１００４を、プロセッサ１００２と共にオンチップとすることができる。その代わりに、キャッシュ１００４およびプロセッサ１００２を、「プロセッサ・モジュール」として一緒にパックすることができ、その場合、プロセッサ１００２は、「プロセッサ・コア」と呼ばれる。さらに、本発明の或る種の実施形態は、上記のコンポーネントのすべてを、必要としないかまたは含まなくてもよい。たとえば、標準Ｉ／Ｏバス１００８に結合されて図示された周辺デバイスを、高性能Ｉ／Ｏバス１００６に結合することができる。さらに、或る実施形態では、単一のバスだけが存在する場合があり、ハードウェア・システム１０００のコンポーネントは、その単一のバスに結合される。さらに、ハードウェア・システム１０００は、追加のプロセッサ、ストレージ・デバイス、またはメモリなど、追加のコンポーネントを含むことができる。

１実装形態では、本明細書で説明される実施形態の動作は、ハードウェア・システム１０００によって実行される一連の実行可能モジュールとして、分散コンピューティング環境内で個別にまたは集合的に実施される。特定の実施形態では、１組のソフトウェア・モジュールおよび／またはドライバは、ネットワーク通信プロトコル・スタック、ブラウジング機能および他のコンピューティング機能、最適化工程、ならびに類似物を実施する。前述の機能モジュールは、ハードウェア、コンピュータ可読媒体上に格納された実行可能モジュール、またはこの両方の組合せによって実現されうる。たとえば、機能モジュールは、プロセッサ１００２など、ハードウェア・システム内のプロセッサによって実行される複数のまたは一連の命令を備えることができる。当初に、一連の命令を、マス・ストレージ１０１８などのストレージ・デバイス上に格納することができる。しかし、一連の命令を、ディスケット、ＣＤ−ＲＯＭ、ＲＯＭ、ＥＥＰＲＯＭ、その他などの任意の適切な記憶媒体上に有形に格納することができる。さらに、一連の命令を、ローカルに格納する必要はなく、ネットワーク／通信インターフェース１０１６を介して、ネットワーク上のサーバなどのリモート・ストレージ・デバイスから受信することができる。命令は、マス・ストレージ１０１８などのストレージ・デバイスからメモリ１０１４にコピーされ、その後、プロセッサ１００２によってアクセスされ、実行される。

オペレーティング・システムは、ソフトウェア・アプリケーション（図示せず）へおよびソフトウェア・アプリケーションからのデータの入力および出力を含む、ハードウェア・システム１０００の動作を管理し、制御する。オペレーティング・システムは、システム上で実行されつつあるソフトウェア・アプリケーションとシステムのハードウェア・コンポーネントとの間のインターフェースを提供する。ＬＩＮＵＸ（登録商標）オペレーティング・システム、米国カリフォルニア州カパティーノのアップル・コンピュータ（Ａｐｐｌｅ Ｃｏｍｐｕｔｅｒ Ｉｎｃ．）から入手可能なＡｐｐｌｅ Ｍａｃｉｎｔｏｓｈ
オペレーティング・システム、ＵＮＩＸ（登録商標）オペレーティング・システム、マイクロソフト（Ｍｉｃｒｏｓｏｆｔ）（登録商標）Ｗｉｎｄｏｗｓ（登録商標）オペレーティング・システム、ＢＳＤオペレーティング・システム、および類似物など、任意の適切なオペレーティング・システムを使用することができる。もちろん、他の実装形態が可能である。たとえば、本明細書で説明されるニックネーム生成機能を、ファームウェア内または特定用途向け集積回路上で実施することができる。

さらに、上で説明した要素および動作は、記憶媒体上に格納される命令からなるものとすることができる。命令を、処理システムによって取り出し、実行することができる。命令の或る例は、ソフトウェア、プログラム・コード、およびファームウェアである。記憶媒体の或る例は、メモリ・デバイス、テープ、ディスク、集積回路、およびサーバである。命令は、処理システムによって実行される時に、本発明に従って動作するように処理システムに指示するように動作可能である。用語「処理システム」は、単一の処理デバイスまたは相互動作可能な処理デバイスのグループを指す。処理デバイスの或る例は、集積回路および論理回路網である。当業者は、命令、コンピュータ、および記憶媒体を熟知している。

本開示は、当業者が理解するはずの、本明細書の例示的な実施形態に対するすべての変更、置換、変形、改変、および修正を包含する。同様に、適当である場合には、添付の特許請求の範囲は、当業者が理解するはずの、本明細書の例示的な実施形態に対するすべての変更、置換、変形、改変、および修正を包含する。たとえば、本発明の実施形態は、ソーシャル・ネットワーキング・ウェブサイトに関連して動作するものとして説明されたが、本発明を、ウェブ・アプリケーションをサポートし、関連付けのグラフとしてデータをモデル化する任意の通信ファシリティに関連して使用することができる。さらに、或る実施形態では、用語「ウェブ・サービス」および「ウェブサイト」が、交換可能に使用される場合があり、さらに、サーバに直接にＡＰＩ呼出しを行う、モバイル・デバイス（たとえば、セルラ電話機、スマートホン、パーソナルＧＰＳ、携帯情報端末、パーソナル・ゲーミング・デバイスなど）などのデバイス上のカスタムＡＰＩまたは一般化されたＡＰＩを指すことができる。

Claims (20)

1. ソーシャル・グラフを維持するよう構成されるデータベースと、１以上のリーダ・キャッシュ・クラスタを含むリーダ・キャッシュ・レイヤと、１以上のフォロワ・キャッシュ・クラスタを含むフォロワ・キャッシュ・レイヤとを備えるシステムであって、前記リーダ・キャッシュ・レイヤは、
   前記フォロワ・キャッシュ・クラスタと前記データベースとの間においてソーシャル・グラフ情報を通信する工程であって、各フォロワ・キャッシュ・クラスタは、前記ソーシャル・グラフの少なくとも一部を維持する、工程と、
   前記データベース内にソーシャル・グラフ情報を格納する要求を前記フォロワ・キャッシュ・クラスタの１つから受信する工程と、
   前記要求に応答して、前記ソーシャル・グラフを格納している前記データベースを更新する工程と、
   前記要求に関連付けられている前記ソーシャル・グラフの前記一部を格納している前記フォロワ・キャッシュ・クラスタの１以上を更新する工程と、が行われるように構成される、システム。
2. 前記ソーシャル・グラフは、複数のグラフ・ノードと前記グラフ・ノード同士を接続する複数のグラフ・エッジとを含み、２つのグラフ・ノード同士を接続する各グラフ・エッジは、前記２つのグラフ・ノード間の関連付けを示す、請求項１に記載のシステム。
3. 前記ソーシャル・グラフの各グラフ・ノードは、一意識別子に関連付けられている、請求項２に記載のシステム。
4. 各一意識別子は、前記１以上のフォロワ・キャッシュ・クラスタまたは１以上のリーダ・キャッシュ・クラスタの１以上内にその対応するグラフ・ノードと共に格納されている、請求項３に記載のシステム。
5. 前記１以上のリーダ・キャッシュ・クラスタは、前記データベースと相互作用するよう構成されるプラグインを含む、請求項１に記載のシステム。
6. 前記プラグインは、１以上の変換動作を実行する、請求項５に記載のシステム。
7. 前記ソーシャル・グラフは、複数のグラフ・ノードと前記グラフ・ノード同士を接続する複数のグラフ・エッジとを含み、前記１以上の変換動作は、前記１以上のフォロワ・キャッシュ・クラスタ内に格納されている前記グラフ・ノードおよび前記グラフ・エッジを前記データベースに送信される１以上のクエリに変換することを含む、請求項６に記載のシステム。
8. 前記データベースは、ＣＡＳＳＡＮＤＲＡを利用する、請求項１に記載のシステム。
9. 前記１以上のリーダ・キャッシュ・クラスタの各々は、前記１以上のフォロワ・キャッシュ・クラスタの各々と前記データベースとの間のキャッシュ一貫性を維持する、請求項１に記載のシステム。
10. 前記１以上のリーダ・キャッシュ・クラスタの各々は、前記１以上のフォロワ・キャッシュ・クラスタの各々と前記リーダ・キャッシュ・クラスタの各々との間のキャッシュ一貫性を維持する、請求項１に記載のシステム。
11. 前記１以上のリーダ・キャッシュ・クラスタは、前記１以上のリーダ・キャッシュ・ク
    ラスタ内にキャッシングされた前記ソーシャル・グラフ情報について前記データベースを更新する工程が行われるようにさらに構成される、請求項１に記載のシステム。
12. 前記１以上のリーダ・キャッシュ・クラスタおよび１以上のフォロワ・キャッシュ・クラスタは、クライアント・サーバと前記データベースとの間のキャッシング・レイヤとして動作する、請求項１に記載のシステム。
13. 各フォロワ・キャッシュ・クラスタは、複数のフォロワ・キャッシュ・ノードを含む、請求項１に記載のシステム。
14. 特定のフォロワ・キャッシュ・クラスタの前記フォロワ・キャッシュ・ノードは、前記特定のキャッシュ・クラスタおよび前記１以上のリーダ・キャッシュ・クラスタ内の前記フォロワ・キャッシュ・ノードとだけ通信する、請求項１１に記載のシステム。
15. 各リーダ・キャッシュ・クラスタは、複数のリーダ・キャッシュ・ノードを含む、請求項１に記載のシステム。
16. 前記データベースによって維持されている前記ソーシャル・グラフは、前記１以上のフォロワ・キャッシュ・クラスタおよび前記１以上のリーダ・キャッシュ・クラスタにまたがる分散グラフとして格納される、請求項１に記載のシステム。
17. 前記データベース内に格納される前記ソーシャル・グラフ情報は、関係的に格納される、請求項１に記載のシステム。
18. 前記１以上のフォロワ・キャッシュ・クラスタおよび前記１以上のリーダ・キャッシュ・クラスタは、対応するキャッシュ・クラスタの１以上のデータ・シャード内にソーシャル・グラフ情報を格納するように構成される、請求項１に記載のシステム。
19. コンピュータ読み取り可能な命令を記憶したシステムの非一時的記憶媒体であって、前記システムは、ソーシャル・グラフを維持するよう構成されるデータベースと、１以上のリーダ・キャッシュ・クラスタを含むリーダ・キャッシュ・レイヤと、１以上のフォロワ・キャッシュ・クラスタを含むフォロワ・キャッシュ・レイヤとを備え、前記命令は、実行されたとき、
    前記フォロワ・キャッシュ・クラスタと前記データベースとの間においてソーシャル・グラフ情報を通信する工程であって、各フォロワ・キャッシュ・クラスタは、前記ソーシャル・グラフの少なくとも一部を維持する、工程と、
    前記データベース内にソーシャル・グラフ情報を格納する要求を前記フォロワ・キャッシュ・クラスタの１つから受信する工程と、
    前記要求に応答して、前記ソーシャル・グラフを格納している前記データベースを更新する工程と、
    前記要求に関連付けられている前記ソーシャル・グラフの前記一部を格納している前記フォロワ・キャッシュ・クラスタの１以上を更新する工程と、を前記リーダ・キャッシュ・クラスタに行わせる、記憶媒体。
20. システムのリーダ・キャッシュ・レイヤによる方法であって、前記システムは、ソーシャル・グラフを維持するよう構成されるデータベースと、１以上のリーダ・キャッシュ・クラスタを含むリーダ・キャッシュ・レイヤと、１以上のフォロワ・キャッシュ・クラスタを含むフォロワ・キャッシュ・レイヤとを備え、前記リーダ・キャッシュ・レイヤによる前記方法は、
    前記フォロワ・キャッシュ・クラスタと前記データベースとの間においてソーシャル・
    グラフ情報を通信する工程であって、各フォロワ・キャッシュ・クラスタは、前記ソーシャル・グラフの少なくとも一部を維持する、工程と、
    前記データベース内にソーシャル・グラフ情報を格納する要求を前記フォロワ・キャッシュ・クラスタの１つから受信する工程と、
    前記要求に応答して、前記ソーシャル・グラフを格納している前記データベースを更新する工程と、
    前記要求に関連付けられている前記ソーシャル・グラフの前記一部を格納している前記フォロワ・キャッシュ・クラスタの１以上を更新する工程と、を備える、方法。

Images