(57)【要約】  分散システム（１）は、複数のサーバ（１０）が有する複数の分散テーブルからデータを読み出すリードアクセス処理のキー、および当該キーから得たバリューを用いて実行する処理を定めるコールバック、を受け付ける受付部（１０２）と、リードアクセス処理のキーとコールバックをアクセス待ちリスト（１０４）に登録する登録部（１０６）と、所定の条件に従い、待機リードアクセスの発行先およびタイミングを決定する決定部（１０８）と、決定した発行先のサーバに、決定したタイミングで、待機リードアクセスを発行し、アクセス結果を受け取るリードアクセス発行部（１１０）と、アクセス結果を用いて、アクセス待ちリスト（１０４）に登録されたコールバックを実行するコールバック実行部（１１２）と、を備える。
2014034852.tif 000002
【特許請求の範囲】
【請求項１】
複数のサーバがそれぞれ有する複数の分散テーブルからデータを読み出すリードアクセス処理のキー、および、前記キーに基づき読み出した結果を用いて実行する処理を定めるコールバック、を受け付ける受付手段と、
受け付けた前記リードアクセス処理を待機させ、該当するサーバに後で発行する待機リードアクセスとして前記キーと前記コールバックをアクセス待ちリストに登録する登録手段と、
前記アクセス待ちリストに登録された前記待機リードアクセスについて、所定の条件に従い、前記待機リードアクセスを発行する発行先のサーバおよび発行タイミングを決定する決定手段と、
前記決定手段が決定した前記発行先の前記サーバに、決定した前記発行タイミングで、前記待機リードアクセスを発行し、前記サーバから当該アクセス結果を受け取るリードアクセス発行手段と、
前記リードアクセス発行手段が受け取った前記アクセス結果を用いて、前記アクセス待ちリストに登録された該当する待機リードアクセスの前記コールバックを実行し、実行した前記コールバックの前記待機リードアクセスを前記アクセス待ちリストから削除するコールバック実行手段と、を備える分散システム。
【請求項２】
請求項１に記載の分散システムにおいて、
前記登録手段は、前記サーバ毎、または前記キー毎に、前記待機リードアクセスを分類して前記アクセス待ちリストに登録し、
前記決定手段は、前記サーバ毎または前記キー毎に、前記待機リードアクセスの前記発行タイミングを決定する分散システム。
【請求項３】
請求項１または２に記載の分散システムにおいて、
前記決定手段は、前記アクセス待ちリストに登録された前記待機リードアクセスの件数が一定数以上になったときを、前記発行タイミングであると決定する分散システム。
【請求項４】
請求項１乃至３いずれかに記載の分散システムにおいて、
前記決定手段は、
前記アクセス待ちリストのメモリ量が一定量以上になった場合、前記発行タイミングになったと判断し、
前記メモリ量が一定量以上になった時点で、前記アクセス待ちリストに登録された前記待機リードアクセスの件数が多いサーバを前記待機リードアクセスの前記発行先として選択する分散システム。
【請求項５】
請求項１乃至４いずれかに記載の分散システムにおいて、
前記決定手段は、各前記サーバの性能情報に基づいて求まる、前記キー１つあたりにかかる前記アクセス結果の取得時間に基づいて、前記待機リードアクセスの前記発行先となるサーバを選択する分散システム。
【請求項６】
請求項１乃至５いずれかに記載の分散システムにおいて、
前記決定手段は、一定時間以上、前記リードアクセス発行手段により前記待機リードアクセスが発行されていないサーバを前記待機リードアクセスの前記発行先として選択する分散システム。
【請求項７】
請求項１乃至６いずれかに記載の分散システムにおいて、
前記受付手段は、前記分散テーブルのキーに対して値を書き込むライトアクセス処理をさらに受け付け、
前記アクセス待ちリストを参照し、前記ライトアクセス処理と同じキーに対する前記待機リードアクセスが存在する場合、前記コールバック実行手段は、前記ライトアクセス処理の前記値で前記待機リードアクセスの前記コールバックを実行し、前記アクセス待ちリストから当該待機リードアクセスを削除する分散システム。
【請求項８】
請求項７に記載の分散システムにおいて、
前記受付手段は、前記リードアクセス処理より後に受け付ける前記ライトアクセス処理を、先に処理することを禁止する禁止フラグを、前記リードアクセス処理の前記キーと前記コールバックとともに受け付け、
前記登録手段は、受け付けた前記禁止フラグを前記待機リードアクセスの前記キーおよび前記コールバックとともに前記アクセス待ちリストに登録し、
さらに、前記登録手段は、前記アクセス待ちリストを参照し、前記ライトアクセス処理と同じキーに対する前記待機リードアクセスの前記禁止フラグが登録されている場合、前記ライトアクセス処理を待機させ、該当するサーバに後で発行する待機ライトアクセスとして前記キーと前記値を前記アクセス待ちリストに登録する分散システム。
【請求項９】
情報処理装置が、
複数のサーバがそれぞれ有する複数の分散テーブルからデータを読み出すリードアクセス処理のキー、および、前記キーに基づき読み出した結果を用いて実行する処理を定めるコールバック、を受け付け、
受け付けた前記リードアクセス処理を待機させ、該当するサーバに後で発行する待機リードアクセスとして前記キーと前記コールバックをアクセス待ちリストに登録し、
前記アクセス待ちリストに登録された前記リードアクセスについて、所定の条件に従い、前記待機リードアクセスを発行するサーバおよび発行タイミングを決定し、
決定した前記サーバに、決定した前記発行タイミングで、前記待機リードアクセスを発行し、前記サーバから当該アクセス結果を受け取り、
受け取った前記アクセス結果を用いて、前記アクセス待ちリストに登録された該当する待機リードアクセスの前記コールバックを実行し、実行した前記コールバックの前記待機リードアクセスを前記アクセス待ちリストから削除する情報処理装置のデータ処理方法。
【請求項１０】
情報処理装置を実現するコンピュータに、
複数のサーバがそれぞれ有する複数の分散テーブルからデータを読み出すリードアクセス処理のキー、および、前記キーに基づき読み出した結果を用いて実行する処理を定めるコールバック、を受け付ける手順、
受け付けた前記リードアクセス処理を待機させ、該当するサーバに後で発行する待機リードアクセスとして前記キーと前記コールバックをアクセス待ちリストに登録する手順、
前記アクセス待ちリストに登録された前記待機リードアクセスについて、所定の条件に従い、前記待機リードアクセスを発行するサーバおよび発行タイミングを決定する手順、
決定した前記サーバに、決定した前記発行タイミングで、前記待機リードアクセスを発行し、前記サーバから当該アクセス結果を受け取る手順、
受け取った前記アクセス結果を用いて、前記アクセス待ちリストに登録された該当する待機リードアクセスの前記コールバックを実行し、実行した前記コールバックの前記待機リードアクセスを前記アクセス待ちリストから削除する手順、を実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、分散システム、情報処理装置のデータ処理方法およびプログラムに関する。
【背景技術】
【０００２】
近年、大規模なデータを対象にした機械学習やデータマイニング等の分析が行われるようになってきている。大規模なデータを扱うためのフレームワークとして、ＭａｐＲｅｄｕｃｅ（マップリデュース）がＧｏｏｇｌｅ（グーグル）社によって提案され、そのオープンソース実装であるＨａｄｏｏｐ（ハドゥープ）の利用がデータ分析に用いられるようになってきている。【０００３】
ＭａｐＲｅｄｕｃｅは、次のように動作する。まず、ＭａｐＲｅｄｕｃｅの入力として分散ファイルシステム上のファイルを用いる場合を想定する。この場合、ファイルは分割され、その断片が複数のマシン上に存在する。ＭａｐＲｅｄｕｃｅでは、まずこの各ファイル断片に対して分散して「ｍａｐ」関数を実行する。「ｍａｐ」関数の出力はKey-Value（キーバリュー）のペアである。システムは複数のマシンから生成されるKey-Valueペアをキー（Key）でグループ化する。そのため、同じキーを持つKey-Valueペアが同じマシンに転送されるよう、通信が行われる。そして、これを入力として「ｒｅｄｕｃｅ」関数を実行する。これを図２５に示す。【０００４】
ＭａｐＲｅｄｕｃｅを用いることで、様々なアルゴリズムが記述できることが知られているが、場合によっては低速になることも知られている。低速になるケースの一例に、ｍａｐ関数、あるいはｒｅｄｕｃｅ関数から、複数のマシンで共有されるデータにランダムアクセスする必要があるような場合がある。【０００５】
このような共有データへのランダムアクセス処理が必要となる例として、機械学習における「モデル」の更新がある。モデルは学習結果を表すデータで、入力データ（教師データ）により更新される。そして、もっともらしいモデルデータが得られるまで、入力データによってモデルデータの更新を何度も行う。ここで、モデルデータが更新される場所はランダムである。【０００６】
ＭａｐＲｅｄｕｃｅでは複数のマシンで共有されるデータ構造を直接はサポートしない。ＭａｐＲｅｄｕｃｅが利用する分散ファイルシステムを使うことも考えられるが、ランダムアクセスは非常に低速であり、実用的ではない。【０００７】
この問題の解決を目指したシステムの一例が、非特許文献１に記載されている。このシステムでは、複数のマシンで共有されるデータとして、汎用の分散型メモリキャッシュシステムであるｍｅｍｃａｃｈｅｄを用い、Ｈａｄｏｏｐと組み合わせて用いることでこの課題を解決しようとしている。ここで、ｍｅｍｃａｃｈｅｄはメモリ上にKey-Valueペアを保存し、キーからバリューを引けるようにしたデータストアである。複数のマシン上でｍｅｍｃａｃｈｅｄを動作させ、各マシンが担当するキーの範囲を決めておくことで、複数のマシン上に分散したオンメモリのデータストアを実現する。【０００８】
非特許文献１では、ｍａｐ関数やｒｅｄｕｃｅ関数から、これら複数のマシン上のｍｅｍｃａｃｈｅｄにアクセスすることで、前記の課題を解決しようとしている。これを図２６に示す。
また、特許文献１には、ＭａｐＲｅｄｕｃｅを実装したオープンソースソフトウェアであるＨａｄｏｏｐ等を用いて実現される分散処理システムの例が記載されている。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開２０１２−５８８３６号公報
【非特許文献】
【００１０】
【非特許文献１】Jimmy Lin、外３名、“Low-Latency, High-Throughput Access to Static Global Resources within the Hadoop Framework”、［online］、２００９年、HCIL Technical Report HCIL-2009-01、［平成２４年５月２５日検索］、インターネット〈URL：http://hcil.cs.umd.edu/trs/2009-01/2009-01.pdf〉
【発明の概要】
【発明が解決しようとする課題】
【００１１】
非特許文献１ではｍｅｍｃａｃｈｅｄを用いているが、以降、一般的な呼称として「分散テーブル」と呼ぶものとする。
非特許文献１に示されている方式では、分散テーブル上のデータにアクセスする際のレイテンシが大きいという課題があった。ネットワークを経由して他のマシン上のバリューを取得する場合、たとえば１ｍｓといったような長い時間がかかる。この場合、１秒間に１０００回しかデータにアクセスできず、このデータアクセスが全体の実行におけるボトルネックとなる。【００１２】
これを改善するためには、できるだけ複数のデータを一度に読み書きすればよい。すなわち、たとえばKey1とKey2に対応するバリューを取得したい場合、Key1とKey2が同じマシンの担当になっているのであれば、Key1のバリューを取得した後に、Key2のバリューを取得しに行くのではなく、Key1とKey2の両方のバリューを当該マシンに一度に要求する。こうすれば、２つのデータに対するアクセスが一度に行なえるため、レイテンシの影響を削減できる。【００１３】
このような改善手法は非特許文献１においても示唆されているが、これをどのように実現すれば良いかについては述べられていない。
すなわち、上述した非特許文献１に記載のシステムにおいては、プログラム上同じ場所に現れる複数のアクセスを１つにまとめることは容易であるが、プログラム上別の場所に現れる、あるいはＭａｐＲｅｄｕｃｅプログラムにおいて、（同一マシン上で動作する）複数のｍａｐ関数にまたがるアクセスを１つにまとめるのは容易ではないという問題点があった。【００１４】
本発明の目的は、上述した課題である分散テーブルへのアクセス時のレイテンシの影響による処理の遅延を解決する分散システム、情報処理装置のデータ処理方法およびプログラムを提供することにある。
【課題を解決するための手段】
【００１５】
本発明の分散システムは、
複数のサーバがそれぞれ有する複数の分散テーブルからデータを読み出すリードアクセス処理のキー、および、前記キーに基づき読み出した結果を用いて実行する処理を定めるコールバック、を受け付ける受付手段と、
受け付けた前記リードアクセス処理を待機させ、該当するサーバに後で発行する待機リードアクセスとして前記キーと前記コールバックをアクセス待ちリストに登録する登録手段と、
前記アクセス待ちリストに登録された前記待機リードアクセスについて、所定の条件に従い、前記待機リードアクセスを発行する発行先のサーバおよび発行タイミングを決定する決定手段と、
前記決定手段が決定した前記発行先の前記サーバに、決定した前記発行タイミングで、前記待機リードアクセスを発行し、前記サーバから当該アクセス結果を受け取るリードアクセス発行手段と、
前記リードアクセス発行手段が受け取った前記アクセス結果を用いて、前記アクセス待ちリストに登録された該当する待機リードアクセスの前記コールバックを実行し、実行した前記コールバックの前記待機リードアクセスを前記アクセス待ちリストから削除するコールバック実行手段と、を備える。【００１６】
本発明の情報処理装置のデータ処理方法は、
情報処理装置が、
複数のサーバがそれぞれ有する複数の分散テーブルからデータを読み出すリードアクセス処理のキー、および、前記キーに基づき読み出した結果を用いて実行する処理を定めるコールバック、を受け付け、
受け付けた前記リードアクセス処理を待機させ、該当するサーバに後で発行する待機リードアクセスとして前記キーと前記コールバックをアクセス待ちリストに登録し、
前記アクセス待ちリストに登録された前記リードアクセスについて、所定の条件に従い、前記待機リードアクセスを発行するサーバおよび発行タイミングを決定し、
決定した前記サーバに、決定した前記発行タイミングで、前記待機リードアクセスを発行し、前記サーバから当該アクセス結果を受け取り、
受け取った前記アクセス結果を用いて、前記アクセス待ちリストに登録された該当する待機リードアクセスの前記コールバックを実行し、実行した前記コールバックの前記待機リードアクセスを前記アクセス待ちリストから削除する情報処理装置のデータ処理方法である。【００１７】
本発明のコンピュータプログラムは、
情報処理装置を実現するコンピュータに、
複数のサーバがそれぞれ有する複数の分散テーブルからデータを読み出すリードアクセス処理のキー、および、前記キーに基づき読み出した結果を用いて実行する処理を定めるコールバック、を受け付ける手順、
受け付けた前記リードアクセス処理を待機させ、該当するサーバに後で発行する待機リードアクセスとして前記キーと前記コールバックをアクセス待ちリストに登録する手順、
前記アクセス待ちリストに登録された前記待機リードアクセスについて、所定の条件に従い、前記待機リードアクセスを発行するサーバおよび発行タイミングを決定する手順、
決定した前記サーバに、決定した前記発行タイミングで、前記待機リードアクセスを発行し、前記サーバから当該アクセス結果を受け取る手順、
受け取った前記アクセス結果を用いて、前記アクセス待ちリストに登録された該当する待機リードアクセスの前記コールバックを実行し、実行した前記コールバックの前記待機リードアクセスを前記アクセス待ちリストから削除する手順、を実行させるためのプログラムである。【００１８】
なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システム、記録媒体、コンピュータプログラムなどの間で変換したものもまた、本発明の態様として有効である。【００１９】
また、本発明の各種の構成要素は、必ずしも個々に独立した存在である必要はなく、複数の構成要素が一個の部材として形成されていること、一つの構成要素が複数の部材で形成されていること、ある構成要素が他の構成要素の一部であること、ある構成要素の一部と他の構成要素の一部とが重複していること、等でもよい。【００２０】
また、本発明のデータ処理方法およびコンピュータプログラムには複数の手順を順番に記載してあるが、その記載の順番は複数の手順を実行する順番を限定するものではない。このため、本発明のデータ処理方法およびコンピュータプログラムを実施するときには、その複数の手順の順番は内容的に支障のない範囲で変更することができる。【００２１】
さらに、本発明のデータ処理方法およびコンピュータプログラムの複数の手順は個々に相違するタイミングで実行されることに限定されない。このため、ある手順の実行中に他の手順が発生すること、ある手順の実行タイミングと他の手順の実行タイミングとの一部ないし全部が重複していること、等でもよい。
【発明の効果】
【００２２】
本発明によれば、分散テーブルへのアクセス時のレイテンシの影響を削減し、処理の高速化を図る分散システム、情報処理装置のデータ処理方法およびプログラムが提供される。
【図面の簡単な説明】
【００２３】
上述した目的、およびその他の目的、特徴および利点は、以下に述べる好適な実施形態、およびそれに付随する以下の図面によってさらに明らかになる。【００２４】
【図１】本発明の実施の形態に係る分散システムの構成を示す機能ブロック図である。
【図２】本発明の実施の形態に係る分散システムのアクセス待ちリストの一例を示す図である。
【図３】本発明の実施の形態に係る分散システムのクライアント装置を実現するコンピュータの構成を示すブロック図である。
【図４】本発明の実施の形態に係る分散システムにおけるクライアント装置の動作の一例を示すフローチャートである。
【図５】本発明の実施の形態に係る分散システムの利用形態の一つを示すブロック図である。
【図６】本発明の実施の形態に係る分散システムの利用形態の一つを示すブロック図である。
【図７】本発明の実施の形態に係る分散システムのクライアント装置の決定部の第１の方法による処理手順の一例を示すフローチャートである。
【図８】本発明の実施の形態に係る分散システムのクライアント装置の決定部の第２の方法による処理手順の一例を示すフローチャートである。
【図９】本発明の実施の形態に係る分散システムのクライアント装置の決定部の第３の方法による処理手順の一例を示すフローチャートである。
【図１０】本発明の実施の形態に係る分散システムのクライアント装置の決定部の第４の方法による処理手順の一例を示すフローチャートである。
【図１１】本発明の実施の形態に係る分散システムのクライアント装置の決定部の第４の方法による処理手順の他の例を示すフローチャートである。
【図１２】本発明の実施の形態に係る分散システムのクライアント装置の決定部の第４の方法による処理手順の他の例を示すフローチャートである。
【図１３】本発明の実施の形態に係る分散システムのクライアント装置の決定部の第５の方法による処理手順の一例を示すフローチャートである。
【図１４】本発明の実施の形態に係る分散システムのクライアント装置の決定部の第６の方法による処理手順の一例を示すフローチャートである。
【図１５】本発明の実施の形態に係る分散システムのクライアント装置の決定部の第７の方法による処理手順の一例を示すフローチャートである。
【図１６】本発明の実施の形態に係る分散システムのクライアント装置の決定部の第７の方法による処理手順の他の例を示すフローチャートである。
【図１７】本発明の実施の形態に係る分散システムの構成を示す機能ブロック図である。
【図１８】本発明の実施の形態に係る分散システムのアクセス待ちリストにライトアクセスが追加で登録された場合の例を示す図である。
【図１９】本発明の実施の形態に係る分散システムのアクセス待ちリストにアキュムレートアクセスが追加で登録された場合の例を示す図である。
【図２０】本発明の実施の形態に係る分散システムのアクセス待ちリストにアキュムレートアクセスの後、さらにリードアクセスが追加で登録された場合の例を示す図である。
【図２１】本発明の実施の形態に係る分散システムのリード関数実行部の動作の一例を示すフローチャートである。
【図２２】本発明の実施の形態に係る分散システムのライト関数実行部の動作の一例を示すフローチャートである。
【図２３】本発明の実施の形態に係る分散システムのアキュムレート関数実行部の動作の一例を示すフローチャートである。
【図２４】本発明の実施の形態に係る分散システムのリードアクセス発行部の動作の一例を示すフローチャートである。
【図２５】ＭａｐＲｅｄｕｃｅの動作を表す図である。
【図２６】非特許文献１のシステムの構成を表す図である。
【図２７】本発明の実施の形態に係る情報処理装置の論理的な構成を示す機能ブロック図である。
【発明を実施するための形態】
【００２５】
以下、本発明の実施の形態について、図面を用いて説明する。尚、すべての図面において、同様な構成要素には同様の符号を付し、適宜説明を省略する。
【００２６】
（第１の実施の形態）
図１は、本発明の実施の形態に係る分散システム１の構成を示す機能ブロック図である。
本発明の実施の形態に係る分散システム１は、複数のサーバ（分散テーブルサーバ１０）がそれぞれ有する複数の分散テーブル（不図示）からデータを読み出すリード（read）アクセス処理のキー（Key）、および、キーに基づき読み出した結果（バリュー：Value）を用いて実行する処理を定めるコールバック（Callback）、を受け付ける受付部１０２と、受け付けたリードアクセス処理を待機させ、該当する分散テーブルサーバ１０に後で発行する待機リードアクセスとしてキーとコールバックをアクセス待ちリスト１０４に登録する登録部１０６と、アクセス待ちリスト１０４に登録された待機リードアクセスについて、所定の条件に従い、待機リードアクセスを発行する発行先の分散テーブルサーバ１０および発行タイミングを決定する決定部１０８と、決定部１０８が決定した発行先の分散テーブルサーバ１０に、決定した発行タイミングで、待機リードアクセスを発行し、分散テーブルサーバ１０から当該アクセス結果（バリュー）を受け取るリードアクセス発行部１１０と、リードアクセス発行部１１０が受け取ったアクセス結果を用いて、アクセス待ちリスト１０４に登録された該当する待機リードアクセスのコールバックを実行し、実行したコールバックの待機リードアクセスをアクセス待ちリスト１０４から削除するコールバック実行部１１２と、を備える。
【００２７】
図１に示すように、本実施形態では、分散システム１は、複数の分散テーブルサーバ１０（図１では、３つの分散テーブルサーバＳ１、Ｓ２、およびＳ３）とネットワーク３を介して接続されるクライアント装置１００を備える。
【００２８】
本発明の分散システム１は、複数のマシン上に分散して存在するテーブルに対して値を読み書きするシステムであり、特に、読み書きに用いるキーがランダムの場合でも高速にアクセスできる分散テーブルアクセスシステムに好適に適用できる。
【００２９】
本発明の分散システム１は、たとえば、大規模なデータを対象とした機械学習やデータマイニング等の分析を行うものに好適に適用できる。本発明の分散システム１は、たとえば、ＭａｐＲｅｄｕｃｅのような大規模なデータを扱うシステムにおいて、データ処理部が、ランダムアクセスする共有データが必要な場合に、そのアクセスを高速化するといった用途に適用できる。図５に、データ処理部９０が実行するＭａｐＲｅｄｕｃｅプログラムのｍａｐ関数やｒｅｄｕｃｅ関数から分散テーブルを利用するシステムに、本発明のクライアント装置（図中、「分散テーブルクライアント９２」と示す）を適用した例を示す。
【００３０】
また、本発明の分散システム１は、Ｗｅｂアプリケーションにおいて、Ｗｅｂサーバやアプリケーション（ＡＰ：APplication）サーバがデータベースの内容をキャッシュするために分散テーブルを利用するといった用途にも適用可能である。図６に、ＷｅｂサーバまたはＡＰサーバ（図中、「Ｗｅｂサーバ／ＡＰサーバ９４」と示す）がデータベース９６の内容をキャッシュするために分散テーブルを利用する場合などに、本発明のクライアント装置（図中、「分散テーブルクライアント９８」と示す）を適用した例を示す。
本発明のクライアント装置１００は、図５または図６の分散テーブルクライアント（９２または９８）に相当する。
【００３１】
図１に戻り、本実施形態のクライアント装置１００は、分散テーブルサーバ１０にネットワーク３を介して接続されるサーバコンピュータやパーソナルコンピュータ、またはそれらに相当する情報処理装置（図３のコンピュータ６０）により実現することができる。また、クライアント装置１００は、仮想サーバなどにより構成されてもよい。なお、図１では、クライアント装置１００は１つのみ示されているが、本発明の分散システム１において、図示されない複数のクライアント装置１００が分散テーブルサーバ１０にアクセスすることができる。
【００３２】
図１の本実施形態の分散システム１のクライアント装置１００の各構成要素は、図３のＣＰＵ（Central Processing Unit）６２、ＲＡＭ（Random Access Memory）６６、ＲＡＭ６６にロードされた図１の構成要素を実現するプログラム７０、そのプログラム７０を格納するＲＯＭ（Read Only Memory）６４、ネットワーク３接続用インタフェースを含むＩ／Ｏ（Input/Output）６８を有する任意のコンピュータ６０のハードウェアとソフトウェアの任意の組合せによって実現される。ＣＰＵ６２は、コンピュータ６０の各要素とバス６９を介して接続され、各要素とともにコンピュータ６０全体を制御する。そして、その実現方法、装置にはいろいろな変形例があることは、当業者には理解されるところである。以下に説明する各機能ブロック図は、ハードウェア単位の構成ではなく、論理的な機能単位のブロックを示している。なお、コンピュータ６０は、Ｉ／Ｏ６８を介して図示されない入出力装置と接続することもできる。
また、以下に示す各図において、本発明の本質に関わらない部分の構成については省略してあり、図示されていない。
【００３３】
本実施形態において、分散システム１は、たとえば、データセンタ等に設置された複数の分散テーブルサーバ１０を備えたクラスタまたはグリッドシステムであるとする。
図１において、クライアント装置１００は、受付部１０２と、アクセス待ちリスト１０４と、登録部１０６と、決定部１０８と、リードアクセス発行部１１０と、コールバック実行部１１２と、を備える。
【００３４】
受付部１０２は、複数の分散テーブルサーバ１０がそれぞれ有する複数の分散テーブル（不図示）からデータを読み出すリードアクセス処理のキー、および、キーに基づき読み出した結果（バリュー）を用いて実行する処理を定めるコールバック、を受け付ける。
【００３５】
たとえば、分散テーブルへのアクセス処理は、一つのプログラムテキスト上の複数の箇所に現れる。
分散テーブル上のデータアクセスはレイテンシが大きく、性能劣化の原因となる。これを改善するためには、分散テーブルへのアクセス処理では、できるだけ複数のデータを一度に読み書きすればよいが、プログラム上、離れた別の場所に現れる分散テーブルへのアクセスを１つにまとめるのは容易ではない。ここで、プログラムとは、クライアント装置１００が実行する分散テーブルへのアクセスを含むプログラム、あるいは、クライアント装置１００を介して分散テーブルにアクセスする少なくとも１つの他のコンピュータで実行されるプログラムを含むことができる。
【００３６】
本発明では、プログラム上、離れた別の場所に現れる複数の分散テーブルに対するアクセスを１つにまとめるため、コールバックと呼ばれる仕組みを用いる。コールバックとは、何らかの処理を行なった後に、続けて処理を行ないたい場合、この後続の処理をオブジェクトとして登録しておく仕組みである。
本発明では、これらのアクセス処理をまとめてアクセス先であるサーバ毎にまとめて行うことで、高速化を図る。
【００３７】
本発明において、リードアクセス処理とは、たとえば、分散テーブルからデータを読み出す処理を行うリード（read）関数等のＡＰＩ（Application Program Interface）によって実行される処理を含むことができる。本実施形態では、リード関数に、分散テーブルからデータを読み出すためのキー（Key）と、読み出した結果を用いて処理を実行するコールバック（Callback）を引数として指定する。受付部１０２は、プログラムを実行時にリード関数が呼び出されたとき、リード関数で引数として指定されているキーとコールバックを受け付ける。
【００３８】
アクセス待ちリスト１０４は、図２（ａ）に示すように、リードアクセス処理の対象となるデータを保持する分散テーブルを有する分散テーブルサーバ１０（担当サーバ）と、待機リードアクセスとしてキー（Key）とコールバック（Callback）のセットとを対応付けて保持する。
なお、アクセス待ちリスト１０４において、分散テーブルサーバ１０（担当サーバ）の情報として、予め付与された識別情報、またはネットワーク３上のＩＰ（Internet Protocol）アドレス等を保持することができる。
【００３９】
本実施形態のクライアント装置１００において、キーを担当する分散テーブルサーバ１０を探索する方法は、分散システムの汎用の手法を用いて行うことができ、特に限定されない。たとえば、分散テーブルサーバ１０を探索する方法は、キーのハッシュ値を取って、サーバ数でｍｏｄ（除算した結果出た余り）を取ることで、分散テーブルサーバ１０を求めたり、予め準備された対応関係を用いて分散テーブルサーバ１０を探索してもよい。
【００４０】
本実施形態では、クライアント装置１００は、担当するサーバ毎（図２（ａ））に、待機リードアクセスとしてキーとコールバックのセットを登録する構成としているが、これに限定されるものではない。たとえば、クライアント装置１００は、キー毎（図２（ｂ））、または予め属性等によりグループ分けされた複数のキー毎に、コールバックを保持する構成としてもよい。あるいは、クライアント装置１００は、サーバ毎、かつ、キー毎（またはキーグループ毎）に分類してコールバックを保持する構成としてもよい。また、キー毎（またはキーグループ毎）にコールバックを保持する構成の場合、リードアクセス発行部１１０は、アクセスするキー（またはキーグループ）を担当する分散テーブルサーバ１０を探して、待機リードアクセスを発行することができる。キー毎（またはキーグループ毎）に分類して保持している構成の場合、リードアクセス発行部１１０は、サーバの担当キー（またはキーグループ）の変更にも柔軟に対応できる。
【００４１】
図１に戻り、登録部１０６は、受け付けたリードアクセス処理を直ぐに実行せずに、待機させ、該当する分散テーブルサーバ１０（担当サーバ）に後で発行する待機リードアクセスとしてキーとコールバックをアクセス待ちリスト１０４に登録してバッファリングする。後述するように、本実施形態において、登録部１０６は、アクセス待ちリスト１０４に待機リードアクセスを登録したとき、登録したことを決定部１０８に通知してもよい。なお、登録部１０６は、リード関数を実行するリード関数実行部とすることができ、リード関数実行部がアクセス待ちリスト１０４に登録したことを通知してもよい。
【００４２】
決定部１０８は、アクセス待ちリスト１０４に登録された待機リードアクセスについて、所定の条件に従い、待機リードアクセスを複数まとめて発行する発行先の分散テーブルサーバ１０およびその発行タイミングを決定する。たとえば、決定部１０８は、アクセス待ちリストに登録された待機リードアクセスの件数が一定数以上になったときを、発行タイミングであると決定する。
【００４３】
すなわち、決定部１０８は、分散テーブルサーバ１０毎に、アクセス待ちリスト１０４に登録された待機リードアクセス処理の数が一定数以上になったときに、その分散テーブルサーバ１０を発行先として、その分散テーブルサーバ１０に対するリードアクセス処理の発行タイミングとする。あるいは、決定部１０８は、たとえば、キー毎に、アクセス待ちリスト１０４に登録された待機リードアクセス処理の数が一定数以上になったときに、そのキーを担当する分散テーブルサーバ１０をリードアクセス処理の発行先として、その分散テーブルサーバ１０に対するリードアクセス処理の発行タイミングを決定してもよい。
【００４４】
以後、この待機処理の発行タイミングの決定方法を第１の方法と呼ぶものとする。この第１の方法では、アクセス待ちリスト１０４の保持に必要とするメモリ量や担当分散テーブルサーバ１０毎の通信速度の違いは考慮されない。したがって、クライアント装置１００では、第１の方法を、後述する他の方法と組み合わせた中から、分散システム１のシステム構成を考慮して、最適な方法を選択して採用することが望ましい。
【００４５】
また、リードアクセス処理の発行タイミングは、サーバ毎ではなく、キー毎に、または、予め属性等によりグループ分けされた複数のキー毎に、アクセス待ちリスト１０４に登録された待機リードアクセス処理の数が一定数以上になったとき、としてもよい。そして、その待機リードアクセス処理の数が一定数以上になったキーを担当する分散テーブルサーバ１０をリードアクセス処理の発行先とする。そして、その複数の待機リードアクセスは、その分散テーブルサーバ１０、あるいは、その分散テーブルサーバ１０の当該キー、または当該キーを含む同じグループの複数のキーに対して発行されてもよい。
【００４６】
リードアクセス発行部１１０は、決定部１０８が決定した発行先の分散テーブルサーバ１０に、決定した発行タイミングで、待機リードアクセスを複数まとめて発行し、分散テーブルサーバ１０から当該アクセス結果（バリュー）を受け取る。すなわち、同一サーバのリードアクセスを複数まとめて発行する。
【００４７】
リードアクセスをまとめて発行せず、その度、実行する場合、１回の処理にかかる時間は、レイテンシ＋リードデータサイズ／スループットとなる。この処理時間が、リードアクセス毎にかかることになる。一方、リードアクセスを複数まとめて発行すると、処理時間のうち、レイテンシは１処理分だけで済むこととなり、処理時間を短縮できる。
【００４８】
コールバック実行部１１２は、リードアクセス発行部１１０が受け取ったアクセス結果（バリュー）を用いて、アクセス待ちリスト１０４に登録された該当する待機リードアクセスのコールバックを実行し、実行したコールバックの待機リードアクセスをアクセス待ちリスト１０４から削除する。
【００４９】
本実施の形態のクライアント装置１００では、コンピュータプログラム７０（図３）に対応する各種の処理動作をコンピュータ６０のＣＰＵ６２（図３）が実行することにより、前述のような各種ユニットが各種機能として実現される。
本実施形態のコンピュータプログラム７０は、情報処理装置（クライアント装置１００）を実現させるためのコンピュータ６０に、複数の分散テーブルサーバ１０がそれぞれ有する複数の分散テーブルからデータを読み出すリードアクセス処理のキー、および、キーに基づき読み出した結果を用いて実行する処理を定めるコールバック、を受け付ける手順、受け付けたリードアクセス処理を待機させ、該当する分散テーブルサーバ１０に後で発行する待機リードアクセスとしてキーとコールバックをアクセス待ちリスト１０４に登録する手順、アクセス待ちリスト１０４に登録された待機リードアクセスについて、所定の条件に従い、待機リードアクセスを発行する分散テーブルサーバ１０および発行タイミングを決定する手順、決定した分散テーブルサーバ１０に、決定した発行タイミングで、待機リードアクセスを発行し、分散テーブルサーバ１０から当該アクセス結果を受け取る手順、受け取ったアクセス結果を用いて、アクセス待ちリスト１０４に登録された該当する待機リードアクセスのコールバックを実行し、実行したコールバックの待機リードアクセスをアクセス待ちリスト１０４から削除する手順、を実行させるように記述されている。
【００５０】
本実施形態のコンピュータプログラム７０は、コンピュータ６０で読み取り可能な記録媒体に記録されてもよい。記録媒体は特に限定されず、様々な形態のものが考えられる。また、プログラム７０は、記録媒体からコンピュータ６０のメモリ（ＲＯＭ６４またはＲＡＭ６６）にロードされてもよいし、ネットワークを通じてコンピュータ６０にダウンロードされ、メモリにロードされてもよい。
【００５１】
上述のような構成において、本実施の形態の分散システム１におけるクライアント装置１００によるデータ処理方法を以下に説明する。図４は、本実施形態の分散システム１の動作の一例を示すフローチャートである。以下、図１および図４を用いて説明する。
本発明の実施の形態に係る情報処理装置（図１のクライアント装置１００）のデータ処理方法は、クライアント装置１００が、複数の分散テーブルサーバ１０（図１）がそれぞれ有する複数の分散テーブルからデータを読み出すリードアクセス処理のキー、および、キーに基づき読み出した結果を用いて実行する処理を定めるコールバック、を受け付け（ステップＳ１０１）、受け付けたリードアクセス処理を待機させ、該当する分散テーブルサーバ１０に後で発行する待機リードアクセスとしてキーとコールバックをアクセス待ちリスト１０４に登録し（ステップＳ１０３）、アクセス待ちリスト１０４に登録されたリードアクセスについて、所定の条件に従い、待機リードアクセスを発行する分散テーブルサーバ１０および発行タイミングを決定し（ステップＳ１０５）、決定した分散テーブルサーバ１０に、決定した発行タイミングで（ステップＳ１０７のＹＥＳ）、待機リードアクセスを発行し、分散テーブルサーバ１０から当該アクセス結果を受け取り（ステップＳ１０９）、受け取ったアクセス結果を用いて、アクセス待ちリスト１０４に登録された該当する待機リードアクセスのコールバックを実行し（ステップＳ１１１）、実行したコールバックの待機リードアクセスをアクセス待ちリスト１０４から削除する（ステップＳ１１３）。
【００５２】
図７は、本実施形態の分散システム１のクライアント装置１００の決定部１０８のリードアクセスの発行タイミングと発行先サーバの決定処理の手順の例を示すフローチャートである。本実施形態では、決定部１０８は、上述した第１の方法により決定処理を行う。
まず、決定部１０８が、登録部１０６（リード関数）からアクセス待ちリスト１０４に登録したとの通知を受け取る度に（ステップＳ１２１のＹＥＳ）、本処理が開始する。
【００５３】
そして、決定部１０８が、アクセス待ちリスト１０４を参照し、待機リードアクセス処理の数が一定数以上の分散テーブルサーバ１０があるか否かを判定する（ステップＳ１２３）。一定数以上のサーバがない場合は（ステップＳ１２３のＮＯ）、手順は、ステップＳ１２１に戻り、決定部１０８は、次の通知の到来まで待機する（ステップＳ１２１のＮＯ）。
一定数以上のサーバがある場合（ステップＳ１２３のＹＥＳ）、決定部１０８が、当該サーバに対する待機していた複数のリードアクセスをまとめて発行する（ステップＳ１２５）。
【００５４】
あるいは、登録部１０６が、アクセス待ちリスト１０４に登録を行う度に、分散テーブルサーバ１０毎に登録数をカウントし、メモリ（ＲＡＭ６６等）に記憶してもよい。そして、決定部１０８は、メモリを参照し、各カウント値が一定値以上になった分散テーブルサーバ１０があるか否かを監視してもよい。
【００５５】
以上説明したように、本発明の実施の形態に係る分散システム１によれば、クライアント装置１００が、任意のプログラムを対象として、プログラム上の任意の場所に現れる分散テーブルサーバ１０へのリード関数による複数のリードアクセス処理を、その都度リードアクセス毎に行うのではなく、アクセス待ちリスト１０４に登録して一定数以上待機させることで、サーバ毎にまとめて実行することができる。そして、この構成により、本発明の実施の形態に係る分散システム１において、プログラム上に複数現れるリードアクセス処理を、その都度処理する場合に比較して、リードアクセス時にかかるレイテンシによるアクセス処理速度への影響を削減することができ、高速化を図ることができる。
【００５６】
特に、本発明の実施の形態に係る分散システム１によれば、クライアント装置１００は、プログラム上の何処にいつ現れるか分からないような複数のリードアクセス処理に好適に適用することが可能になる。その理由は、クライアント装置１００が、リードアクセス処理が現れた時に、その処理を受け付けて、適切に待機させる構成を有しているからである。
【００５７】
（第２の実施の形態）
本実施形態の分散システム１は、上記実施形態とは、待機アクセス処理の発行タイミングの決定方法が異なり、システム構成を考慮し、メモリ量やクラスタシステムのノード（分散テーブルサーバ１０）間のネットワーク的な距離を考慮して、高速化に最適なノードを選択して待機アクセス処理を実行する点で相違する。
本実施形態の分散システム１の構成は、図１の上記実施形態の分散システム１と同じであり、以下、図１を用いて説明する。
【００５８】
上記実施形態では、クライアント装置１００は、分散テーブルへの複数のアクセスを１つにまとめて処理することで、レイテンシの影響を抑えることができ、処理の高速化を図ることができた。本実施形態では、クライアント装置１００は、さらに、この複数のアクセスを、どのタイミングでどのサーバに対するものを優先してアクセスするか、メモリ量やマシン間の通信速度の違い等、分散システム１のシステム構成等の条件を考慮して、決定することで、より性能の向上を図るものである。
【００５９】
はじめに、第２の方法として、メモリ量を考慮して発行タイミングと発行先サーバを決定する方法について説明する。
本実施形態において、決定部１０８は、アクセス待ちリスト１０４のメモリ量が一定量以上になった場合、発行タイミングになったと判断し、メモリ量が一定量以上になった時点で、アクセス待ちリスト１０４に登録された待機リードアクセスの件数が多い分散テーブルサーバ１０を待機リードアクセスの発行先として選択する。
【００６０】
アクセス待ちリスト１０４のメモリ量は、キーとコールバックが必要とするメモリ量を加算していくことで求めることができる。ただし、複数のCallbackオブジェクト間で共有されるメモリがある場合は、コールバックが必要とするメモリ量を正確に求めることが難しい可能性もある。その場合は、リード関数の引数に、アクセス待ちリスト１０４の登録に必要となるメモリ量を、プログラマが指定するようにしてもよい。アクセス待ちリスト１０４の利用メモリ量は、コールバックの実行が完了して当該オブジェクトで利用しているメモリが解放され次第、減算する。
なお、アクセス待ちリスト１０４がキー毎に分類されて登録されている場合、アクセス待ちリスト１０４に登録された待機リードアクセスの件数が多いキーに対応する分散テーブルサーバ１０を待機リードアクセスの発行先として選択する。
なお、この第２の方法では、担当サーバごとの通信速度の違いは考慮されない。したがって、クライアント装置１００では、第２の方法を、他の方法と組み合わせた中から、分散システム１のシステム構成を考慮して、最適な方法を選択して採用することが望ましい。
【００６１】
次に、第３の方法として、マシン間の通信速度の違いを考慮して発行タイミングと発行先サーバを決定する方法について説明する。
本実施形態において、決定部１０８は、各分散テーブルサーバ１０の性能情報に基づいて求まる、キー１つあたりにかかるアクセス結果（バリュー）の取得時間に基づいて、待機リードアクセスの発行先となるサーバを選択する。
第３の方法では、決定部１０８は、アクセス待ちリスト１０４のメモリ量が一定量以上になった場合、１つのキーあたりにかかるバリュー取得時間が最も少ない分散テーブルサーバ１０を待機リードアクセスの発行先として選択する。すなわち、決定部１０８は、通信速度が速い分散テーブルサーバ１０を発行先として選択する。
【００６２】
具体的には、１つのキーあたりにかかるバリュー取得時間は、分散テーブルサーバ１０ごとに、下記の式（１）で求めることができる。
【数１】
2014034852.tif 000003
【００６３】
ここで、本実施形態の分散システム１がクラスタシステムであることを考慮すると、ノード（分散テーブルサーバ１０）間で、互いのネットワーク的な距離が近いノードと遠いノードが存在する。ここで、ネットワーク的な距離は、キー１つあたりにかかるアクセス結果（バリュー）の取得時間で評価することができ、各ノードから他のノードへの通信レイテンシおよびスループット値から求めることができる。
【００６４】
キー１つあたりにかかるアクセス結果（バリュー）の取得時間は、ノード間の距離が同じならば、待機アクセス処理が最も多くたまったノードが、最小となる。
また、待機アクセス処理数が同じならば、ノード間の距離が最も近いノードが、キー１つあたりにかかるアクセス結果（バリュー）の取得時間が最小となる。
【００６５】
よって、クライアント装置１００では、ノード間の距離が同じならば、待機アクセス処理が最も多くたまったノードから、待機アクセス処理を実行し、待機アクセス処理数が同じならば、距離が近いノードから、待機アクセス処理を実行するのが望ましい。すなわち、距離が遠いノードについては、より多くの待機アクセス処理をためてから実行するのが望ましい。本実施形態では、決定部１０８が、１つのキーあたりにかかるバリュー取得時間が最も少ないノードを、待機リードアクセスの発行先として選択することで、最もレイテンシの影響が小さくなるノードを選択できる。
【００６６】
ここで、クライアント装置１００は、担当サーバごとの通信速度の違いを考慮するために必要な、各担当分散テーブルサーバ１０への通信レイテンシおよびスループット等の情報を、予め得ておく。これらの情報は、測定した結果から得た値やシステムの構成（スイッチ／ルータの段数を含むネットワーク構成等）から算出した値をクライアント装置１００にあらかじめ登録しておいてもよい。あるいは、クライアント装置１００が、システムの初期化時に必要なデータを測定して、これらの情報を求める算出部（不図示）を備えるようにしてもよい。
【００６７】
なお、アクセス待ちリスト１０４には、同一キーに対するリードアクセスが複数登録される可能性があるが、決定部１０８は、式（１）において、それらを１つにまとめて１つのキーとしてカウントして、キー数を求める。バリューのバイトサイズがキーによって異なるなど、複数のキーに対応するバリューの総バイト数を求めるのが難しい場合は、決定部１０８は、式（１）において、近似値を用いればよい。また、通信レイテンシの影響の方がスループットの影響よりも圧倒的に大きな場合は、決定部１０８は、式（１）において、（複数のキーと対応するバリューの総バイト数）／スループットの項を削除して近似してもよい。
【００６８】
このようにすることで、全ての分散テーブルサーバ１０が同じ条件であるならば、クライアント装置１００は、第３の方法においても、第２の方法と同様に、最もアクセス待ち数が多いサーバに対してリードアクセスを発行することができる。もし、全ての分散テーブルサーバ１０でアクセス待ち数が同じであれば、ネットワーク的に近いサーバが選ばれる。すなわち、ネットワーク的に遠いサーバについては、クライアント装置１００は、なるべく多くのリードアクセスをためてから発行することになる。
【００６９】
次に、決定部１０８が発行タイミングと発行先サーバを決定する第４の方法について説明する。
第４の方法では、決定部１０８は、第３の方法で説明した各分散テーブルサーバ１０の「１つのキーあたりにかかるバリュー取得時間」を所定のタイミングで算出し、全分散テーブルサーバ１０の中での最小値を求め、最小値に基づいて発行タイミングと発行先サーバを決定する。
【００７０】
決定部１０８が、「１つのキーあたりにかかるバリュー取得時間」を算出するタイミングは、リードアクセスがアクセス待ちリスト１０４に登録される度、リードアクセスがアクセス待ちリスト１０４に所定回数登録される度、または、一定時間毎である。決定部１０８は、算出された最小値が閾値以下になった時を発行タイミングと判断し、最小値となったサーバを発行先とする。ここで、決定部１０８は、アクセス待ちリスト１０４への登録の有無や登録回数を、登録部１０６からの通知に基づいて検出することができる。
決定部１０８は、「１つのキーあたりにかかるバリュー取得時間」を、上記の第３の方法と同様に、サーバごとに上述した式（１）で求めることができ、詳細な説明は省略する。
【００７１】
ここで、決定部１０８は、リードアクセスがアクセス待ちリスト１０４に登録されたことを、登録部１０６（リード関数）からの登録通知により検知できる。この通知（リードアクセス）が所定回数以上来るまで待つ理由は、１つのキーあたりにかかるバリュー取得時間の最小値が閾値以下のサーバがあるかどうかを、リード関数からアクセス待ちリスト１０４に登録した通知を受け取るたびに計算するのが非効率な場合に、まとめて計算してそのオーバヘッドを削減するためである。
【００７２】
この第４の方法では、クライアント装置１００は、アクセス待ちリスト１０４のメモリ量を参照しないため、設定された閾値の大小によって、過小あるいは過大にアクセス待ちリスト１０４用のメモリを消費する可能性がある。したがって、クライアント装置１００では、第４の方法を、他の方法と組み合わせた中から、分散システム１のシステム構成を考慮して、最適な方法を選択して採用することが望ましい。
【００７３】
また、第５の方法として、以下の方法も考えられる。
決定部１０８は、ある一定時間（たとえば、１０ｍｓ）リードアクセスが発行されていない分散テーブルサーバ１０をリードアクセスの発行先として選択する。発行タイミングは、一定時間リードアクセスが発行されていないサーバが存在したときとなる。
【００７４】
この方法で一定時間リードアクセスが発行されていない分散テーブルサーバ１０を発行先とする理由は、図６に示したＷｅｂサーバ／ＡＰサーバ９４に本発明の分散システム１を用いるような場合、長時間ユーザを待たせるのは望ましくないためである。ただし、この場合はアクセス待ちリスト１０４のメモリ量や、１つのキーあたりにかかるバリュー取得時間を参照しないため、この第５の方法は、必ずしも効率のよいサーバの選択にはならない。したがって、クライアント装置１００では、第５の方法を、他の方法と組み合わせた中から、分散システム１のシステム構成を考慮して、最適な方法を選択して採用することが望ましい。
【００７５】
さらに、第６の方法では、プログラマがプログラム上で明示的にリードアクセスを発行するサーバおよび発行タイミングを指定する。たとえば、Ｃ＋＋で記述した関数の一例では、flush（サーバ名）のような関数を実行することで、この関数が実行されたタイミングで、リードアクセス発行部１１０が、当該サーバへのリードアクセスを発行する。
【００７６】
また、決定部１０８は、第７の方法として、第１〜第６の方法を少なくとも２つ組み合わせて決定方法として採用してもよい。詳細については、後述する。
【００７７】
図８〜図１６は、本実施形態の分散システム１のクライアント装置１００の決定部１０８の各方法による処理手順の例をそれぞれ示すフローチャートである。
図８の処理手順は、決定部１０８が上述した第２の方法を用いて決定処理を行う場合の例である。つまり、この処理手順は、メモリ量が一定以上の場合、待機リードアクセスの件数が最も多いサーバにリードアクセスを発行する決定処理の例である。
【００７８】
図８の例では、決定部１０８が、リード関数からアクセス待ちリスト１０４に登録したとの通知を受け取る度に（ステップＳ１２１のＹＥＳ）、本処理が開始する。通知を受け取り（ステップＳ１２１のＹＥＳ）、かつ、アクセス待ちリスト１０４のメモリ量が一定量以上になった時（ステップＳ１３１のＹＥＳ）、決定部１０８が、発行タイミングになったと判断する。
【００７９】
そして、決定部１０８が、その時点で、アクセス待ちリスト１０４に登録された待機リードアクセスの件数が最も多い分散テーブルサーバ１０を発行先に決定する。そして、リードアクセス発行部１１０が、発行先に決定された分散テーブルサーバ１０に、リードアクセスを発行する（ステップＳ１３３）。
一方、メモリ量が一定量以上でない場合（ステップＳ１３１のＮＯ）、手順は、ステップＳ１２１に戻り、決定部１０８は、次の通知の到来まで待機する（ステップＳ１２１のＮＯ）。
【００８０】
次に、図９の処理手順は、決定部１０８が上述した第３の方法を用いて決定処理を行う場合の例である。つまり、この処理手順は、メモリ量が一定以上の場合、１つのキーあたりにかかるバリュー取得時間が最も少ないサーバにリードアクセスを発行する決定処理の例である。
図９の例では、リード関数からアクセス待ちリスト１０４に登録したとの通知を受け取り（ステップＳ１２１のＹＥＳ）、かつ、アクセス待ちリスト１０４のメモリ量が一定量以上になった時（ステップＳ１３１のＹＥＳ）、決定部１０８が、発行タイミングになったと判断する。ここまでの図９の処理手順は、図８の例と同じである。
【００８１】
そして、決定部１０８が、１つのキーあたりにかかるバリュー取得時間が最も少ない分散テーブルサーバ１０を発行先に決定し、リードアクセス発行部１１０が、決定された発行先の分散テーブルサーバ１０に、リードアクセスを発行する（ステップＳ１４１）。
【００８２】
次に、図１０〜図１２の処理手順は、決定部１０８が上述した第４の方法を用いて決定処理を行う場合の例である。各図の手順は、１つのキーあたりにかかるバリュー取得時間を算出（または、バリュー取得時間の最小値と閾値を比較）するタイミングがそれぞれ異なる。
【００８３】
図１０は、アクセス待ちリスト１０４にリードアクセスが登録される度に、第４の方法による決定処理が行われる例を示す。図１１は、アクセス待ちリスト１０４にリードアクセスが所定回数以上登録された場合に、第４の方法による決定処理が行われる例を示す。図１２は、所定の時間間隔で第４の方法による決定処理が行われる例を示す。
まず、図１０の例では、決定部１０８が、リード関数からアクセス待ちリスト１０４に登録したとの通知を受け取る度に（ステップＳ１２１のＹＥＳ）、本処理が開始する。
【００８４】
そして、決定部１０８が、１つのキーあたりにかかるバリュー取得時間の最小値が閾値以下のサーバがあるかを判別する（ステップＳ１５１）。最小値が閾値以下のサーバがない場合は（ステップＳ１５１のＮＯ）、手順は、ステップＳ１２１に戻り、決定部１０８は、次の通知の到来まで待機する（ステップＳ１２１のＮＯ）。
最小値が閾値以下のサーバがある場合（ステップＳ１５１のＹＥＳ）、決定部１０８がそのサーバを発行先と決定し、リードアクセス発行部１１０が、当該サーバに対するリードアクセスを発行する（ステップＳ１２５）。
【００８５】
また、図１１の例では、決定部１０８が、リード関数からアクセス待ちリスト１０４に登録したとの通知を受け取り（ステップＳ１２１のＹＥＳ）、かつ、決定部１０８が、通知を受け取った回数をカウントしておき、所定回数以上、通知を受け取った場合に（ステップＳ１６１のＹＥＳ）、本処理が開始する。以降の手順は図１０と同様である。なお、決定部１０８が本処理を実行した時、カウントはリセットされる。すなわち、所定回数毎に、本処理が実行されることとなる。
【００８６】
また、図１２の例では、図示されないタイマにより、所定の時間間隔を計測し、決定部１０８がタイマからの通知（タイマ割り込み）を受け取る度に（ステップＳ１７１のＹＥＳ）、すなわち、一定時間毎に、本処理が開始する。以降の手順は図１０と同様である。なお、タイマの時間は、たとえば、１０ｍｓとすることができ、予め設定された値であってもよいし、条件に応じて変更されてもよい。
また、クライアント装置１００において、上記図１０または図１１と、図１２との手順をそれぞれ組み合わせてもよい。
【００８７】
さらに、図１３の処理手順は、決定部１０８が上述した第５の方法を用いて決定処理を行う場合の例である。図１３の例では、図示されないタイマにより、所定の時間間隔を計測し、決定部１０８がタイマからの通知（タイマ割り込み）を受け取る度に（ステップＳ１７１のＹＥＳ）、すなわち、一定時間毎に、本処理が開始する。そして、決定部１０８が、一定時間以上、リードアクセスが発行されていない分散テーブルサーバ１０があるか否かを判定する（ステップＳ１８１）。リードアクセスが発行されていない分散テーブルサーバ１０がない場合は（ステップＳ１８１のＮＯ）、手順は、ステップＳ１７１に戻り、決定部１０８は、次の通知の到来まで待機する（ステップＳ１７１のＮＯ）。リードアクセスが発行されていない分散テーブルサーバ１０がある場合（ステップＳ１８１のＹＥＳ）、決定部１０８が、そのサーバを発行先に決定し、リードアクセス発行部１１０が、当該サーバに対するリードアクセスを発行する（ステップＳ１２５）。
【００８８】
また、図１４の処理手順は、決定部１０８が上述した第６の方法を用いて決定処理を行う場合の例である。図１４の例では、まず、決定部１０８が、リードアクセスを発行するサーバおよび発行タイミングを指定した関数を呼び出す（ステップＳ１９１）。関数で指定されたタイミングになった時（ステップＳ１９３のＹＥＳ）、決定部１０８が、指定された分散テーブルサーバ１０を発行先に決定し、発行先の分散テーブルサーバ１０に対して、リードアクセス発行部１１０がリードアクセスを発行する（ステップＳ１９５）。
【００８９】
また、第７の方法として、決定部１０８が第１〜第６の方法を少なくとも２つ組み合わせて決定方法として採用した場合の処理手順を図１５と図１６に示す。ここで、図１５と図１６、さらに図１４のフローは、後述するように並列的に実行することができる。
第４の方法のように「１つのキーあたりにかかるバリュー取得時間」が閾値以下のサーバがあれば（図１５のステップＳ１５１のＹＥＳ）、リードアクセス発行部１１０が、当該サーバに対してリードアクセスを発行する（図１５のステップＳ１２５）。
【００９０】
このようなサーバが無くても（図１５のステップＳ１５１のＮＯ）、第３の方法のように、アクセス待ちリスト１０４のメモリ量が一定量以上になった場合（図１５のステップＳ１３１のＹＥＳ）、決定部１０８が「１つのキーあたりにかかるバリュー取得時間」が最も少ないサーバを発行先に選び、リードアクセス発行部１１０がリードアクセスを発行する（図１５のステップＳ１４１）。これらの条件が成立しなくても（図１５のステップＳ１３１のＮＯ、かつステップＳ１５１のＮＯ）、第５の方法のようにある一定時間リードアクセスが発行されていないサーバに対して（図１６のステップＳ１８１のＹＥＳ）、リードアクセス発行部１１０がリードアクセスを発行する（図１６のステップＳ１２５）。また、第６の方法のようにプログラム上で明示的に指定された場合もリードアクセスを発行する（図１４のステップＳ１９５）。
【００９１】
また、これらの方法でリードアクセスを発行する場合、リードアクセス発行部１１０は、この発行をリードアクセス以外の処理や以前発行したリードアクセスと同時並行に、オーバラップして実行してよい。また、第１から第４、および第６、第７の方法でリードアクセスを発行する場合、リードアクセス発行部１１０によるリードアクセスの発行の実施は、リード関数が実行されることが主な契機になる。この契機となるリード関数の中からリードアクセスの発行を行い、リード関数が終了した時点でリードアクセスの発行が終了しているように実装すれば、オーバラップは行われない。さらに、契機となるリード関数の中からリードアクセスの発行を行う際、別スレッドでリードアクセスの発行を行えば、当該リードアクセスの発行を、リードアクセス以外の処理や他のリードアクセスの発行とオーバラップして実行できる。
【００９２】
リードアクセス発行部１１０が、第５の方法や、第７の方法で「一定時間」リードアクセスが発行されていないサーバに対して（図１６のステップＳ１８１のＹＥＳ）、リードアクセスを発行する場合、あるいは、第４の方法で「一定時間」ごとに「１つのキーあたりにかかるバリュー取得時間」を計算して、閾値を下回るサーバに対して（図１５または図１６のステップＳ１５１のＹＥＳ）、リードアクセスを発行する場合、これらの「一定時間」ごとに行う判定をそれぞれ独立したスレッドで行い、当該スレッドでリードアクセスの発行をそれぞれ行うことで、オーバラップを実現することができる。このように、クライアント装置１００では、非同期にオーバラップしてリードアクセスを実行させることで処理時間を有効活用することができる。
【００９３】
以上説明したように、本発明の実施の形態に係る分散システム１によれば、上記実施形態と同様な効果を奏するとともに、メモリ量やマシン間の通信速度の違い等を考慮に入れた最適なアクセス方法を提供できる。
その理由は、決定部１０８が、アクセス待ちリスト１０４で消費されているメモリが一定量を越えると、１要素当たりの取得時間が最小のサーバを選択して当該サーバに対して複数のキーに対するリードアクセスを発行することで、マシンのメモリをできるだけ活用しながら、その時点で最も適切なサーバを選択できるためである。
【００９４】
上記非特許文献１記載の技術では、分散テーブルに対する複数のアクセスをまとめることができたとしても、どのタイミングでどのサーバに対するものを優先して行なうのが最適であるかは明らかではなかった。
すなわち、上記非特許文献１記載の技術では、複数のアクセスをまとめるためには、なんらかの形で処理を遅延させる必要がある。そのために必要となるメモリ量を一定にした上で最も効率のよいアクセス方法を実現する必要がある。
【００９５】
さらに、実際にシステムが動作する環境を考えると、分散テーブルを構成する各マシンは必ずしも同じ条件ではない。すなわち、マシンの数が多くなると、その接続は多段のツリーとして構成されることが多く、たとえば、同じラック内のマシンの方が別のラック内のマシンよりも通信速度が速いということが起こりうる。
【００９６】
本発明の実施の形態に係る分散システム１によれば、このような環境を考慮に入れた、最適なアクセス方法を実現することができる。
【００９７】
（第３の実施の形態）
図１７は、本発明の実施の形態に係る分散システム１の構成を示す機能ブロック図である。
本実施形態の分散システム１は、上記実施形態とは、分散テーブルへのリードアクセスだけでなく、ライトアクセス、またはアキュムレートアクセスもアクセス待ちリスト１０４に登録する点で相違する。
【００９８】
本発明の実施の形態に係る分散システム１は、複数の分散テーブルサーバ１０にネットワーク３（図１７には図示していない）を介して接続されるクライアント装置２００を備える。なお、本実施形態のクライアント装置（図中、「分散テーブルクライアント」と示す）２００は、上記第１の実施の形態または第２の実施の形態のクライアント装置１００の決定部１０８と同様な決定処理手順を含む手順も実行することができる。
【００９９】
本実施形態の分散システム１のクライアント装置２００は、図１の上記実施形態のクライアント装置１００と同じ、アクセス待ちリスト１０４と、リードアクセス発行部１１０と、コールバック実行部１１２と、を備える。さらに、クライアント装置２００は、リード（read）関数実行部２０２と、ライト（write）関数実行部２０４と、アキュムレート（accumulate）関数実行部２０６と、ライト／アキュムレート（write/accumulate）アクセス発行部２０８と、決定部２１０と、を備える。
【０１００】
リード関数実行部２０２は、プログラムが実行されてリード関数が呼び出されたとき、リード関数のキー（Key）とコールバック（Callback）を、分散テーブル上でそのキーを担当する分散テーブルサーバ１０ごとに分類して、アクセス待ちリスト１０４に登録する。すなわち、リード関数実行部２０２は、待機リードアクセスとしてキーとコールバックをアクセス待ちリスト１０４に登録してバッファリングする。本実施形態において、リード関数実行部２０２と、ライト関数実行部２０４と、アキュムレート関数実行部２０６は、上記実施形態の受付部１０２と登録部１０６に対応する。
【０１０１】
ライト関数実行部２０４は、プログラムが実行されてライト関数が呼び出されたとき、ライトアクセスの発行をライト／アキュムレートアクセス発行部２０８に要求、または、ライトアクセス処理を行う。ライト関数は、分散テーブルのデータに書き込みを行う関数であり、データを書き込むデータのキー（Key）と、書き込むデータ（Value）が引数として指定される。ライトアクセス処理とは、ライト関数で指定された引数のKeyのデータに、引数のValueのデータを書き込む処理である。
【０１０２】
アキュムレート関数実行部２０６は、プログラムが実行されてアキュムレート関数が呼び出されたとき、アキュムレートアクセスの発行をライト／アキュムレートアクセス発行部２０８に要求、または、アキュムレートアクセス処理を行う。アキュムレート関数は、引数として指定されたキー（Key）に対応する分散テーブルに元々あった値（データ）と、引数として指定された値（Value）の間で、引数として指定された演算処理を行い、その結果を、Keyのデータ（値）として格納するアクセスである。ここで、指定される演算処理は、結合法則が成り立つものであるとする。加算や乗算、最大値または最小値を求めるものが、演算処理の例となる。アキュムレートアクセス処理とは、アキュムレート関数で指定された引数のKeyのデータと引数で指定されたValueとの間で、引数で指定された演算処理を行い、引数のKeyのデータに演算結果の値を書き込む処理である。
【０１０３】
ライト／アキュムレートアクセス発行部２０８は、ライト関数実行部２０４またはアキュムレート関数実行部２０６からの要求または、決定部２１０によって決定された発行タイミングで、ライトまたはアキュムレートアクセスを、該当する分散テーブルサーバ１０に発行する。
【０１０４】
本実施形態の分散システム１のクライアント装置２００において、受付部（ライト関数実行部２０４）は、分散テーブルのキーに対して値（バリュー）を書き込むライトアクセス処理をさらに受け付ける。そして、リードアクセス発行部１１０は、アクセス待ちリスト１０４を参照し、ライトアクセス処理と同じキーに対する待機リードアクセスが存在する場合、ライトアクセス処理の値（バリュー）で待機リードアクセスのコールバックを実行し、アクセス待ちリスト１０４から当該待機リードアクセスを削除する。
【０１０５】
また、受付部（ライト関数実行部２０４）は、リードアクセス処理より後に受け付けるライトアクセス処理を、先に処理することを禁止する禁止フラグをリードアクセス処理のキーとコールバックとともに受け付ける。そして、登録部（ライト関数実行部２０４）は、ライト関数実行部２０４が受け付けた禁止フラグを待機リードアクセスのキーおよびコールバックとともにアクセス待ちリスト１０４に登録する。さらに、登録部（ライト関数実行部２０４）は、アクセス待ちリスト１０４を参照し、ライトアクセス処理と同じキーに対する待機リードアクセスの禁止フラグが登録されている場合、ライトアクセス処理を待機させ、該当するサーバに後で発行する待機ライトアクセスとしてキーと値（バリュー）を前記アクセス待ちリスト１０４に登録する。
【０１０６】
ここで、ライト関数またはアキュムレート関数が、対象とするキーのリードアクセスがアクセス待ちリスト１０４に登録されていない、または登録されていても追い越して処理してよい場合は、ライト関数実行部２０４またはアキュムレート関数実行部２０６は、即時ライト／アキュムレートアクセス発行部２０８にライトまたはアキュムレートアクセス発行を要求する。追い越せないリードアクセスがアクセス待ちリスト１０４に登録されている場合は、ライト関数実行部２０４またはアキュムレート関数実行部２０６は、ライトまたはアキュムレートアクセス処理を、待機アクセスとして、アクセス待ちリスト１０４に登録する。
【０１０７】
本実施形態において、決定部２１０は、アクセス待ちリスト１０４に登録されているリードアクセスと、それを待ち合わせているライトアクセス、アキュムレートアクセスについて、いつ（発行タイミング）、どの分散テーブルサーバ１０（発行先）に発行するかを決定する。
【０１０８】
本実施形態では、アクセス待ちリスト１０４で消費されているメモリが一定量を越えると、決定部２１０が、１要素当たりの取得時間が最小の分散テーブルサーバ１０を選択して、リードアクセス発行部１１０が、当該サーバに対して複数のキーに対するリードアクセスを発行する。そして、コールバック実行部１１２が、取得したキー（Key）とバリュー（Value）を用いて登録されていたコールバック（Callback）を実行する。その後、ライト／アキュムレートアクセス発行部２０８が、待ち合わせていたライトアクセス、またはアキュムレートアクセスを該当する分散テーブルサーバ１０に発行する。
【０１０９】
決定部２１０における、いつ、どのサーバにリードを発行するかの決定には、上記実施形態同様に、他の方法も考えられる。すなわち、決定方法には、一定時間以上リードアクセスが発行されていないサーバについて発行する方法、１要素当たりの取得時間が一定値以下のサーバについて発行する方法、プログラマが明示的に指定する方法、また、これらを組み合わせる方法がある。
【０１１０】
本実施形態のクライアント装置２００は、このような構成、および動作を採用することで、プログラム上任意の場所に現れる複数のリードアクセスを一つにまとめて発行し、リードアクセスのレイテンシによる影響を削減することができる。また、本実施形態では、決定部２１０により、メモリ量やマシン間の通信速度の違い等を考慮に入れた最適なアクセス方法を提供できる。これにより、本発明の目的を達成することができる。
【０１１１】
以下、各アクセス処理について具体例を示しながら説明する。
まず、分散テーブルからデータを読む場合（リードアクセス）について説明する。
本発明では、分散テーブルサーバ１０に対してアクセスする処理を含むプログラムにおいて、プログラム上、離れた場所に現れる複数の分散テーブルに対するアクセスを１つにまとめるため、コールバック（Callback）と呼ばれる仕組みを用いる。
ここでは、分散テーブルに対するアクセスを行なった後に実行する処理を、コールバックで実現する。
コールバック（Callback）をＣ＋＋で記述した一例を下記に示す。
class Callback { ／* システムが提供 *／
public:
virtual void run（string Key, string Value） = 0;
};
class MyCallback : public Callback { ／* 個々のプログラムで記述 *／
public:
MyCallback（...） {
／* オブジェクト生成時にrun（）を実行するために必要なデータを初期化 *／
}
virtual void run（string Key, string Value）{
／* Keyに対するValueを取得した結果、行う処理を記述 *／
}
private:
／* run（）を実行するために必要なデータを個々のプログラム毎に保存 *／
};
【０１１２】
ここでは、システムがCallbackクラスを提供し、それを継承することで個々のプログラムで利用するコールバック（ここではMyCallback）クラスを生成する例を示した。システムが提供するCallbackクラスは、run（）メンバ関数がvirtual関数として提供されているだけの抽象クラスであるとする。
本システム上で実行され、分散テーブルサーバ１０にアクセスする個々のプログラムは予め決まっていて、予め上記のMyCallbackクラスの宣言と下記read関数等の記述を個々のプログラムに記述することで、本システムは実現される。
【０１１３】
また、分散テーブルに対するリードアクセスを行う際のプログラムインタフェース（read関数）をＣ＋＋で記述した一例を下記に示す。
read（Key, new MyCallback（...））; 
個々のプログラムにおいて、分散テーブルにリードアクセスする時、上記プログラムインタフェースのリード（read）関数を呼び出せばよい。
【０１１４】
このリード（read）関数は、分散テーブルに対して、第１引数のKeyに対するリードアクセスを行い、その結果を引数としてMyCallbackのrunを呼び出すものである。ただし、このリード関数の記述は、リード関数が終了した時点では、分散テーブルに対するアクセスは終了しているとは限らない、という意味になる。
【０１１５】
このように定義された意味の元、リード関数は次のように動作する。
リード関数は、引数に与えられたKeyとCallbackオブジェクトを、アクセス待ちリスト１０４に登録する。このときのアクセス待ちリスト１０４の例は、上記実施形態で示した図２のようになる。図２（ａ）の例のアクセス待ちリスト１０４は、与えられたKeyとCallbackを、Keyを担当する分散テーブルサーバ１０ごとにまとめたものである。図２（ｂ）の例のアクセス待ちリスト１０４は、与えられたKeyとCallbackを、Keyごとにまとめたものである。以下、特に、断らない限り、図２（ａ）のサーバ毎にまとめたアクセス待ちリスト１０４を用いるものとして説明する。
【０１１６】
アクセス待ちリスト１０４に登録されたリードアクセス要求は、ある程度ためられ、決定部２１０によってその発行タイミングと発行先のサーバが決定される。決定部２１０の動作については、上記実施形態の決定部１０８と同様である。
【０１１７】
決定部２１０によって、ある分散テーブルサーバ１０へのリードアクセス発行が決定されると、リードアクセス発行部１１０によって、アクセス待ちリスト１０４の当該サーバ欄にある少なくとも一つのキーに対するリードアクセスが、当該分散テーブルサーバ１０に対して行われる。そして、リードアクセス発行部１１０は、それぞれのキーに対するバリューを受け取る。
【０１１８】
そして、コールバック実行部１１２によって、キーと受け取ったバリューを用いて、アクセス待ちリスト１０４の当該サーバ欄に登録されていたコールバックが実行される。上述したＣ＋＋での例を用いると、コールバック実行部１１２は、Callbackオブジェクトのrunメンバ関数をKeyとValueを引数に実行する。
【０１１９】
以上により、クライアント装置２００は、プログラム上離れた場所に存在する分散テーブルに対するリードアクセスにおいて、同一サーバに対する複数のアクセスをまとめることで、分散テーブルへのアクセスにおけるレイテンシの影響を削減することができる。
【０１２０】
なお、コールバック内部ではさらにリード関数だけでなく、ライト関数またはアキュムレート関数の実行を行うこともでき、アクセス待ちリスト１０４に、同じキーに対するリード関数とともに、ライト関数またはアキュムレート関数をアクセス待ち処理として複数一緒に登録してもよい。また、同じキーに対するリード関数が複数回プログラムで実行された場合、アクセス待ちリスト１０４に複数登録されていてもよい。
【０１２１】
次に、分散テーブルへの書き込みアクセス（ライトアクセス）がある場合について説明する。
通常、共有されるデータに対し、複数のマシン（たとえば、クライアント装置２００やクライアント装置２００に接続される他のマシン）からアクセスされる場合には、ロック等の排他制御を行うが、本システムではそのような制御は対象としない。すなわち、本実施形態では、各マシンでの分散テーブルに対する読み込みおよび書き込みアクセスは任意の順番で実行できる場合を対象とする。
【０１２２】
まず、クライアント装置２００は、書き込みアクセスを、ライト（write）アクセスとアキュムレート（accumulate）アクセスに分類する。ライトアクセスは、キー（Key）に対応する値を上書きする通常の書き込みである。アキュムレートアクセスは、元々あった値と指定された値の間で演算を行い、その結果を格納するアクセスである。ここで、指定される演算は、結合法則が成り立つものであるとする。加算や乗算、最大値または最小値を求める演算がこの例となる。
【０１２３】
たとえば、加算の場合、Key Xの値にYを加算するアクセスをaccumulate（add,X,Y）などとすると、Key Xの値が１の場合、accumulate（add,X,1）, accumulate（add,X,2）が発行されると、Key Xの値は４となる。この結果は、accumulate（add,X,1）, accumulate（add,X,2）が実行される順番に依存しない。
【０１２４】
リードの場合と同様、クライアント装置２００が受け付けるライトアクセス、およびアキュムレートアクセスはともに、個々のプログラムに記述されている、ライト関数、およびアキュムレート関数からそれぞれ呼び出されるものとする。リード関数の場合と同様、ライト関数、およびアキュムレート関数ともに、プログラム上において、その実行が終わった段階で、クライアント装置２００を介した分散テーブルサーバ１０へのライトアクセス、およびアキュムレートアクセスがそれぞれ終了しているとは限らない。
【０１２５】
まず、ライトアクセスについて説明する。ライト（write）関数をＣ＋＋で記述した一例を下記に示す。
Write（Key, Value）;
【０１２６】
ライトアクセスは、その返り値を利用しないので、処理速度はレイテンシの影響を受けない。そのため、クライアント装置２００は、ライトアクセスを基本的には無条件に発行してよい。ただし、プログラムの内容によっては、同じキーに対するリード関数の実行がライト関数の実行の前に行われていた場合、ライトがリードを追い越さないようにしたい場合も考えられる。これは同一マシン内においてであり、前述の通り、複数マシン間でのリードアクセスおよびライトアクセスの順序制御は考慮しない。そこで、本実施形態では、ライトアクセスがリードアクセスを追い越してよい場合と、追い越さない場合に分けて考える。
【０１２７】
ライトアクセスがリードアクセスを追い越してよい場合、ライト関数実行部２０４により、ライト関数が実行されると、ライト関数実行部２０４がまずアクセス待ちリスト１０４を参照し、同一キーに対するリードがアクセス待ちリスト１０４に登録されているかどうかを調べる。もし登録されていれば、ライト関数実行部２０４からの要求に従い、ライト／アキュムレートアクセス発行部２０８が、ライト要求をそのキーを担当するサーバに発行するとともに、そのキーとライト関数で書き込むバリューを引数にして、登録されていたコールバックを実行する。もし登録されていなければ、ライト関数実行部２０４からの要求に従い、ライト／アキュムレートアクセス発行部２０８が、単純にライト要求をそのキーを担当するサーバに発行する。
【０１２８】
つぎに、ライトアクセスがリードアクセスを追い越さないようにしたい場合を考える。本実施形態では、このような場合に対応するために、追い越されたくないリードにフラグ（true）を立てる。個々のプログラムでは、たとえば、先ほどのリード関数の引数を拡張し、以下のようにして、このキーに対するリードアクセスはライトに追い越されたくないことを示しておくことができる。これを以後追い越し不可のリードと呼ぶこととする。
read（Key, new MyCallback（...）, true）;
【０１２９】
このような指示がなされた場合、すなわち、追い越し不可フラグ（true）が指定された場合、登録部１０６（ライト関数実行部２０４）は、アクセス待ちリスト１０４に、その情報（追い越し不可フラグ（true））を保存する。すなわち、登録部１０６（ライト関数実行部２０４）は、図１８に示すように、待機リードアクセスとしてキー（Key1）とコールバック（Callback1）と、さらに、追い越し不可フラグ（true）をアクセス待ちリスト１０４に登録する。
【０１３０】
そして、追い越し不可のリードアクセスと同じキー（Key1）に対するライト関数が実行された場合を考える。ライト関数実行部２０４によりライト関数が実行されると、ライト関数実行部２０４がまずアクセス待ちリスト１０４を参照する。同一キー（Key1）に対する追い越し不可のリードが存在した場合（フラグtrueが登録されている場合）、ライト関数実行部２０４（登録部１０６）が、当該ライトもアクセス待ちリスト１０４に登録する。この様子を図１８に示す。
【０１３１】
次に、ライト（write）がアクセス待ちリスト１０４に登録されている状態（図１８の状態）での各関数の動作を考える。
同一キーに対するリード関数が実行された場合、コールバック実行部１１２が、待ち合わせているライトのバリューを使ってコールバックを実行する。
同一キーに対するライト関数が実行された場合、ライト／アキュムレートアクセス発行部２０８が、待ち合わせているライトのバリューを新たに実行されたライト関数のバリューで上書きする。
同一キーに対するアキュムレート関数が実行された場合、ライト／アキュムレートアクセス発行部２０８が、ライト関数に指定されているバリューを元の値としてアキュムレート関数を実行した結果を計算し、ライト関数のバリューを変更する。たとえば、ライト関数に指定されているバリューが１で、アキュムレート関数が２を加算するものであった場合、ライト／アキュムレートアクセス発行部２０８が、ライト関数に指定するバリューを３に変更する。
【０１３２】
そして、ライト（write）がアクセス待ちリスト１０４に登録されている状態（図１８の状態）で、リードアクセス発行部１１０により、アクセス待ちリスト１０４の当該リードアクセスが発行されれば、その完了を待ち、ライト／アキュムレートアクセス発行部２０８が、待ち合わせていたライトアクセスを発行する。
【０１３３】
次に、アキュムレートアクセスについて説明する。アキュムレート関数をＣ＋＋で記述した一例を下記に示す。
accumulate（TYPE, Key, Value）;
ここで、第１引数のTYPEには実行する演算（加算ならadd,乗算ならmul等）が指定される。
【０１３４】
まず、アキュムレート関数に指定されたキー（Key）について、追い越し不可のリードがアクセス待ちリスト１０４にない場合について説明する。この場合はアキュムレート関数実行部２０６からの要求に従い、ライト／アキュムレートアクセス発行部２０８が、アキュムレート関数を即時発行する。ライト関数の場合と異なり、アクセス待ちリスト１０４に追い越し不可ではないリードアクセスがあるなしに関わらず、このとき、そのリードアクセスのCallbackは実行しない。これは、現在のそのKeyに対応するValueがわからないと、アキュムレート関数の引数だけではValueが決定しないためである。
【０１３５】
次に、追い越し不可のリードがアクセス待ちリスト１０４にある場合について説明する。この場合はライト関数の場合と同様、アキュムレート関数実行部２０６が当該アキュムレートアクセスをアクセス待ちリスト１０４に登録する。この様子を図１９に示す。
【０１３６】
アキュムレートがアクセス待ちリスト１０４に登録されている状態（図１９の状態）での各関数の動作を考える。
同一キーに対するリード関数が実行された場合、リード関数実行部２０２（登録部１０６）が、（上述したライトアクセスの場合と異なり）さらにリードアクセスをアクセス待ちリスト１０４に登録する。この様子を図２０に示す。この状態からさらに同一キーに対するリード、ライト、アキュムレートアクセスがあった場合は、これまで述べてきた場合と同様の動作を行う。
【０１３７】
アキュムレートがアクセス待ちリスト１０４に登録されている状態で、同一キーに対するライト関数が実行された場合、ライト関数実行部２０４（登録部１０６）が、アクセス待ちリスト１０４のアキュムレートアクセスを当該ライトアクセスに置き換え、上書きする。
【０１３８】
アキュムレートがアクセス待ちリスト１０４に登録されている状態で、同一キーに対するアキュムレート関数が実行された場合、アキュムレート関数実行部２０６（登録部１０６）が、同じ演算タイプ（たとえば、加算（add）同士など）なら、アキュムレートのValueを合算して更新する。たとえば、accumulate（add, Key1,1）が登録されている状態で、accumulate（add, Key1,2）が実行された場合、アキュムレート関数実行部２０６（登録部１０６）が、登録されているアキュムレートアクセスをaccumulate（add, Key1,3）に変更する。異なる演算タイプの場合は、アキュムレート関数実行部２０６（登録部１０６）が、アキュムレートアクセスをさらにその後に登録する（不図示）。
【０１３９】
アキュムレートがアクセス待ちリスト１０４に登録されている状態（図１９の状態）で、リードアクセス発行部１１０により、アクセス待ちリスト１０４の当該リードアクセスが発行されれば、その完了を待ち、ライト／アキュムレートアクセス発行部２０８が、待ち合わせていたアキュムレートアクセスを発行する。ここで、待ち合わせていたアキュムレートアクセスに、さらにリードアクセスが待ち合わせていた場合（図２０の状態）、アキュムレート後の値はリードアクセスによって計算できるため、コールバック実行部１１２が、この値を用いてさらに待ち合わせているリードアクセスのコールバックを実行する。
【０１４０】
たとえば、図２０の状態から、リードアクセス発行部１１０が、リードを発行することでKey1の値が１だと判明したとする。この値を用いて、コールバック実行部１１２がCallback1を実行する。登録されているアキュムレートのValue2が２だった場合、ライト／アキュムレートアクセス発行部２０８が、アキュムレートを発行するとともに、コールバック実行部１１２が、１＋２＝３を用いてCallback5を実行する。
【０１４１】
また、決定部２１０による発行タイミングと発行先のサーバの決定処理手順については、上述したように第１〜第７の方法が考えられる。ここでは、説明は省略する。
【０１４２】
次に、図２１から図２４のフローチャートを参照して本実施の形態の全体の動作について詳細に説明する。
図２１は、本実施形態の分散システム１のクライアント装置２００のリード関数実行部２０２の動作の一例を示すフローチャートである。
リード関数実行部２０２が、まずアクセス待ちリスト１０４を確認し、アクセス待ちリスト１０４において、同一キーに対して待つアクセスをアクセス待ちリスト１０４の後ろから調べる（ステップＳ２０１）。すなわち、アクセス待ちリスト１０４は図１８から図２０のように、ライトアクセスやアキュムレートアクセス、リードアクセスがその後に登録されている場合があるため、リード関数実行部２０２は、これを後から調べる。
【０１４３】
ライトアクセスが登録されている場合（ステップＳ２０３のＹＥＳ：図１８の状態）、コールバック実行部１１２が、登録されているバリューを用いて、リード関数の引数のコールバックを実行して（ステップＳ２０５）、本処理を終了する。このとき、アクセス待ちリスト１０４は図１８の状態のままとなる。
【０１４４】
アキュムレートアクセスが登録されている場合（ステップＳ２０７のＹＥＳ：図１９の状態）、リード関数実行部２０２が、アキュムレートアクセスの後ろに引数に与えられたKeyとCallbackオブジェクトを登録する（ステップＳ２０９）。すなわち、図２０のような状態になる。その後、リード関数実行部２０２は、決定部２１０に、リードアクセスを登録した旨通知する（ステップＳ２１３）。なお、決定部２１０がこの通知を必要としない場合は、このステップは省略できる。
【０１４５】
ライトアクセス、アキュムレートアクセスが登録されていない場合は（ステップＳ２０３のＮＯ、かつ、ステップＳ２０７のＮＯ）、リード関数実行部２０２は、引数に与えられたKeyとCallbackオブジェクトをアクセス待ちリスト１０４に登録する（ステップＳ２１１）。そして、リード関数実行部２０２は、決定部２１０に、リードアクセスを登録した旨通知する（ステップＳ２１３）。先ほどと同様、決定部２１０がこの通知を必要としない場合は、このステップは省略できる。また、リードアクセスを登録する際に、必要に応じて、決定部２１０は、その登録によって必要となるメモリ量をアクセス待ちリスト１０４の消費メモリ量に加算する。
【０１４６】
前述の通り、リードアクセスのキーとコールバックが必要とするメモリ量を加算していくことでアクセス待ちリスト１０４の消費メモリ量を求めることができるし、登録毎に加算するメモリ量はプログラマが指定するようにしてもよい。決定部２１０は、後述のライト／アキュムレートアクセスを登録する際も同様に、メモリ量を加算していく。決定部２１０は、これらの場合は、ライト／アキュムレートアクセスのキーとバリューが必要とするメモリ量（アキュムレートの場合はさらにTYPE情報に必要なメモリ量）を加算する。
【０１４７】
図２２は、本実施形態の分散システム１のクライアント装置２００のライト関数実行部２０４の動作一例を示すフローチャートである。
上記リード関数の場合と同様、ライト関数実行部２０４が、アクセス待ちリスト１０４において、同一キーに対して待つアクセスをアクセス待ちリスト１０４の後ろから調べる（ステップＳ２２１）。ライトアクセスが登録されている場合（ステップＳ２２３のＹＥＳ：図１８の状態）、ライト関数実行部２０４が、登録されているライトアクセスのバリューを引数に与えられたバリューで上書きする（ステップＳ２２５）。そして、ライト関数実行部２０４は、本処理を終了する。
【０１４８】
アキュムレートアクセスが登録されている場合（ステップＳ２２７のＹＥＳ：図１９の状態）、ライト関数実行部２０４が、登録されているアキュムレートアクセスを当該ライトアクセスで上書きする（ステップＳ２２９）。すなわち、図２０の状態になる。そして、ライト関数実行部２０４は、本処理を終了する。アキュムレートアクセスが登録されていない場合で（ステップＳ２２７のＮＯ）、かつ、リードアクセスが登録されていなければ（ステップＳ２３１のＮＯ）、ライト関数実行部２０４は、ライト／アキュムレートアクセス発行部２０８を用いライトアクセスを発行する（ステップＳ２３３）。そして、ライト関数実行部２０４は、本処理を終了する。
【０１４９】
リードアクセスが登録されている場合（ステップＳ２３１のＹＥＳ）、すなわち、図２０の状態、あるいは図２の状態の場合、ライト関数実行部２０４は、登録されているリードアクセスが追い越し可能かどうかを調べる（ステップＳ２３５）。追い越し可能でなければ（ステップＳ２３５のＮＯ）、すなわち、フラグtrueが登録されている場合、ライト関数実行部２０４は、当該ライトアクセスをアクセス待ちリスト１０４のこのリードアクセスの後ろに登録する（ステップＳ２３７）。追い越し可能であった場合（ステップＳ２３５のＹＥＳ）、ライト関数実行部２０４は、ライト関数の引数のバリューを用いて当該リードアクセスのコールバックをコールバック実行部１１２によって実行させ、当該リードアクセスをアクセス待ちリスト１０４から削除する（ステップＳ２３９）。さらに、アクセス待ちリスト１０４の同一キーに対して待つアクセスの１つ前の要素に注目して、ステップＳ２２１に戻り、ライト関数実行部２０４は、上記と同様な処理を繰り返す（ステップＳ２４１）。アクセス待ちリスト１０４の同一キーに対して待つアクセスの全ての要素について処理が終了したら、ライト関数実行部２０４は、最後に空の要素に対して処理を繰り返した後、本処理を終了する。
【０１５０】
たとえば、図２０の状態からKey1を引数に持つライト関数を実行した場合（ステップＳ２３１のＹＥＳ）、アクセス待ちリスト１０４の末尾にあるリードアクセスは追い越し可能であるため（ステップＳ２３５のＹＥＳ）、ライト関数実行部２０４は、コールバック実行部１１２により当該リードアクセスのCallback5を実行させ、当該リードアクセスをアクセス待ちリスト１０４から取り除く（ステップＳ２３９）。すると、アクセス待ちリスト１０４は、図１９の状態になる。そして、ステップＳ２２１に戻り、アクセス待ちリスト１０４の末尾のアキュムレートアクセスに注目して、ライト関数実行部２０４は、処理を繰り返す（ステップＳ２４１）。
【０１５１】
また、図２の状態からKey1を引数に持つライト関数を実行した場合（ステップＳ２３１のＹＥＳ）、リードアクセスは追い越し可能であるため（ステップＳ２３５のＹＥＳ）、ライト関数実行部２０４は、コールバック実行部１１２により当該リードアクセスのコールバックを実行させ、当該アクセス待ちリスト１０４から削除する（ステップＳ２３９）。次に注目する要素がアクセス待ちリスト１０４にないので、ライト関数実行部２０４は、空の要素に対して次の繰り返し処理を行う。ここでは、ライトアクセス、アキュムレートアクセス、リードアクセスのいずれも登録されていないため、ライト関数実行部２０４は、最終的にライト／アキュムレートアクセス発行部２０８を用いライトアクセスを発行して処理を終了する（ステップＳ２３７）。
【０１５２】
図２３は、本実施形態の分散システム１のクライアント装置２００のアキュムレート関数実行部２０６の動作一例を示すフローチャートである。
ライト関数の場合と同様、アキュムレート関数実行部２０６が、アクセス待ちリスト１０４において、同一キーに対して待つアクセスをアクセス待ちリスト１０４の後ろから調べる（ステップＳ２５１）。ライトアクセスが登録されている場合（ステップＳ２５３のＹＥＳ：図１８の状態）、アキュムレート関数実行部２０６は、登録されているライトアクセスのバリューを元にアキュムレート演算を実行し、その結果で登録されているライトアクセスのバリューを上書きする（ステップＳ２５５）。たとえば、ライト関数に指定されているバリューが１で、アキュムレート関数が２を加算するものであった場合、アキュムレート関数実行部２０６は、ライト関数に指定するバリューを３に変更する。そして、アキュムレート関数実行部２０６は、本処理を終了する。
【０１５３】
アキュムレートアクセスが登録されている場合（ステップＳ２５７のＹＥＳ：図１９の状態）、アキュムレート関数実行部２０６が、まず演算タイプが登録されているものと同じかどうかを調べる（ステップＳ２５９）。演算タイプが同じでなければ（ステップＳ２５９のＮＯ）、アキュムレート関数実行部２０６は、アキュムレートアクセスをアクセス待ちリスト１０４の後ろに登録する（ステップＳ２６１）。そして、アキュムレート関数実行部２０６は、本処理を終了する。演算タイプが同じであれば（ステップＳ２５９のＹＥＳ）、アキュムレート関数実行部２０６は、登録されているアキュムレートアクセスのバリューと、関数の引数のバリューを元に、アキュムレート演算を行い、その結果で登録されているアキュムレートアクセスのバリューを上書きする（ステップＳ２６３）。そして、アキュムレート関数実行部２０６は、本処理を終了する。
【０１５４】
たとえば、accumulate（add,Key1,1）が登録されている状態でaccumulate（add, Key1,2）が実行された場合（ステップＳ２５７のＹＥＳ、かつステップＳ２５９のＹＥＳ）、アキュムレート関数実行部２０６は、登録されているアキュムレートアクセスをaccumulate（add, Key1,3）に変更する（ステップＳ２６３）。
【０１５５】
また、リードアクセスが登録されていなければ（ステップＳ２６５のＮＯ）、アキュムレート関数実行部２０６は、ライト／アキュムレートアクセス発行部２０８を用いアキュムレートアクセスを発行する（ステップＳ２７３）。そして、アキュムレート関数実行部２０６は、本処理を終了する。リードアクセスが登録されている場合（ステップＳ２６５のＹＥＳ）、すなわち、図２０の状態、あるいは図２の状態の場合、アキュムレート関数実行部２０６が、このリードアクセスが追い越し可能かどうかを調べる（ステップＳ２６７）。
【０１５６】
追い越し可能でなければ（ステップＳ２６７のＮＯ）、アキュムレート関数実行部２０６は、当該アキュムレートアクセスをこのリードアクセスの後ろに登録する（ステップＳ２６１）。そして、アキュムレート関数実行部２０６は、本処理を終了する。追い越し可能であれば（ステップＳ２６７のＹＥＳ）、アキュムレート関数実行部２０６は、アクセス待ちリスト１０４の同一キーに対して待つアクセスの１つ前の要素についてステップＳ２５１に戻り、上記と同様な処理を繰り返す（ステップＳ２７１）。アクセス待ちリスト１０４の同一キーに対して待つアクセスの全ての要素について処理が終了したら、アキュムレート関数実行部２０６は、最後に空の要素に対して処理を繰り返した後、本処理を終了する。
【０１５７】
たとえば、図２０の状態からKey1を引数に持つアキュムレート関数を実行した場合（ステップＳ２６５のＹＥＳ）、アクセス待ちリスト１０４の末尾にあるリードアクセスは追い越し可能であるため（ステップＳ２６７のＹＥＳ）、アキュムレート関数実行部２０６は、アクセス待ちリスト１０４の末尾１つ前のアキュムレートアクセスに注目して処理を繰り返す（ステップＳ２７１）。アクセス待ちリスト１０４の同一キーに対して待つアクセスの全ての要素について処理が終了したら、アキュムレート関数実行部２０６は、最後に空の要素に対して処理を繰り返した後、本処理を終了する。
【０１５８】
図２の状態からアキュムレート関数を実行した場合（ステップＳ２６５のＹＥＳ、かつ、ステップＳ２６７のＮＯ）、次に注目する要素がアクセス待ちリスト１０４にないので、アキュムレート関数実行部２０６は、空の要素に対して次の繰り返し処理を行う。ここでは、ライトアクセス、アキュムレートアクセス、リードアクセスのいずれも登録されていないため（ステップＳ２５３のＮＯ、かつ、ステップＳ２５７のＮＯ、かつ、ステップＳ２６５のＮＯ）、アキュムレート関数実行部２０６は、最終的にライト／アキュムレートアクセス発行部２０８を用いてアキュムレートアクセスを発行して処理を終了する（ステップＳ２７３）。
【０１５９】
図２４は、本実施形態の分散システム１のクライアント装置２００のリードアクセス発行部１１０の動作の一例を示すフローチャートである。ライト／アキュムレートアクセス発行部２０８は、単純にライトアクセス、アキュムレートアクセスを担当するサーバに発行するだけであるが、リードアクセス発行部１１０は、対象とするサーバを指定して呼び出され、図２４のような動作を行う。
【０１６０】
まず、リードアクセス発行部１１０は、指定されたサーバに対し、アクセス待ちリスト１０４の先頭から参照し、先頭の待機リードアクセスから順に以下の処理を繰り返し実行する（ステップＳ２８１）。リードアクセス発行部１１０は、複数のリードアクセスについて、それぞれリードアクセスを順に発行、各キーに対応するバリューを受け取る（ステップＳ２８３）。決定部２１０で必要とされる場合は、リードアクセス発行部１１０は、この発行時刻をアクセス待ちリスト１０４に記録しておく。
そして、リードアクセス発行部１１０は、得られたキーとバリューを用い、登録されていたコールバックを実行し、アクセス待ちリスト１０４から削除する（ステップＳ２８５）。アクセス待ちリスト１０４の後ろに、ステップＳ２８３で発行したキーのリードアクセスの発行を待っているライトアクセスが存在した場合（ステップＳ２８７のＹＥＳ）、リードアクセス発行部１１０は、ライト／アキュムレートアクセス発行部２０８を用いてライトアクセスを発行する（ステップＳ２８９）。
【０１６１】
同様にアキュムレートアクセスが存在した場合（ステップＳ２９１のＹＥＳ）、リードアクセス発行部１１０は、ライト／アキュムレートアクセス発行部２０８を用いてアキュムレートアクセスを発行する（ステップＳ２９３）。この場合、リードアクセス発行部１１０は、リードアクセスの発行によって得られたキーとバリューを用い、アキュムレートアクセス後のキーに対応するバリューを計算する（ステップＳ２９５）。なお、ライトアクセスもアキュムレートアクセスも存在しない場合（ステップＳ２８７のＮＯ、かつ、ステップＳ２９１のＮＯ）、リードアクセス発行部１１０は、ステップＳ２８３で受け取ったキーとバリューを用いて計算する。
そして、リードアクセス発行部１１０は、このキーとバリューの値を用い、後にある当該キーのリード／ライト／アキュムレートアクセスについて（ステップＳ２９７のＹＥＳ）、処理を繰り返し実行する（ステップＳ２９８）。存在しない場合（ステップＳ２９７のＮＯ）、リードアクセス発行部１１０は、本処理を終了する。
なお、繰り返し処理において、リードアクセスが後に存在する場合（ステップＳ２９９のＹＥＳ）、ステップＳ２８５に戻り、リードアクセスが存在しない場合（ステップＳ２９９のＮＯ）、ステップＳ２８７に戻ることとなる。
【０１６２】
たとえば、図２０の状態から分散テーブルサーバＳ１に対してリードアクセスを発行したとすると、リードアクセス発行部１１０は、得られたKey1に対するバリューを用いてアキュムレート処理を実行し、その演算後の値がKey1に対するバリューとして得られたとして、後続のリードアクセスについて繰り返し処理を行う。
【０１６３】
次に、本実施形態のクライアント装置２００の決定部２１０によって決定されるアクセス発行処理の動作について、以下説明する。上記実施形態の決定部１０８の処理手順を示した図７〜図１６を用いて、第１〜第７の方法についてそれぞれ説明する。決定部２１０は、基本的に上記実施形態の決定部１０８と同様に動作する。
【０１６４】
図７に示す第１の方法の決定処理では、まず、決定部２１０が、リード関数からアクセス待ちリスト１０４に登録した通知を受け取る（ステップＳ１２１）。この通知を受け取ると（ステップＳ１２１のＹＥＳ）、本処理が開始し、決定部２１０が、アクセス待ちリスト１０４を参照し、担当するリードアクセスの数が一定数以上のサーバがあるかを調べる（ステップＳ１２３）。もしあれば、リードアクセス発行部１１０が、当該サーバに対するリードアクセスを発行する（ステップＳ１２５）。なお、このリードアクセス発行部１１０の動作は、実際には、図２４を用いて説明した上記動作となるが、以下詳細な説明は省略し、単にリードアクセスを発行するものとして説明する。
【０１６５】
図８に示す第２の方法の決定処理では、決定部２１０が、まず、リード関数からアクセス待ちリスト１０４に登録した通知を受け取る（ステップＳ１２１）。この通知を受け取ると（ステップＳ１２１のＹＥＳ）、本処理が開始し、決定部２１０が、アクセス待ちリスト１０４で消費されているメモリ量が一定量以上かを調べる（ステップＳ１３１）。もし一定量以上であれば（ステップＳ１３１のＹＥＳ）、リードアクセス発行部１１０が、最もアクセス待ち数が多いサーバに対してリードアクセスを発行する（ステップＳ１３３）。
【０１６６】
図９に示す第３の方法の決定処理では、決定部２１０が、まず、リード関数からアクセス待ちリスト１０４に登録した通知を受け取る（ステップＳ１２１）。この通知を受け取ると（ステップＳ１２１のＹＥＳ）、本処理が開始し、決定部２１０が、アクセス待ちリスト１０４で消費されているメモリ量が一定量以上かを調べる（ステップＳ１３１）。もし一定量以上であれば（ステップＳ１３１のＹＥＳ）、リードアクセス発行部１１０が、１つのキーあたりにかかるバリュー取得時間が最も少ないサーバに対してリードアクセスを発行する（ステップＳ１４１）。１つのキーあたりにかかるバリュー取得時間は、前述の式（１）で求めることができる。
【０１６７】
図１０〜図１２に示す第４の方法の決定処理では、決定部２１０が、リード関数からアクセス待ちリスト１０４に登録した通知を受け取る（図１０のステップＳ１２１のＹＥＳ）、あるいはリード関数からアクセス待ちリスト１０４に登録した通知が所定回数以上来る（図１１のステップＳ１２１のＹＥＳ、かつ、ステップＳ１６１のＹＥＳ）、あるいはタイマから一定時間ごとに通知をうけとる（図１２のステップＳ１７１のＹＥＳ）、のいずれかを契機として、処理を開始する。そして、決定部２１０が、アクセス待ちリスト１０４を参照し、１つのキーあたりにかかるバリュー取得時間の最小値が閾値以下のサーバがあるかを調べる（ステップＳ１５１）。もしあれば（ステップＳ１５１のＹＥＳ）、リードアクセス発行部１１０が、当該サーバに対するリードアクセスを発行する（ステップＳ１２５）。
【０１６８】
図１３に示す第５の方法の決定処理では、決定部２１０が、タイマから一定時間ごとに通知を受け取り（ステップＳ１７１のＹＥＳ）、一定時間以上リードアクセスが発行されていないサーバがあるか、アクセス待ちリスト１０４に記録した前回のリード発行時刻を元に調べる（ステップＳ１８１）。もしそのようなサーバがあれば（ステップＳ１８１のＹＥＳ）、リードアクセス発行部１１０が、当該サーバに対するリードアクセスを発行する（ステップＳ１２５）。
【０１６９】
図１４に示す第６の方法の決定処理では、決定部２１０が、プログラムから明示的にリードアクセスを発行するサーバを指定した関数を呼び出す（ステップＳ１９１）。そして、リードアクセス発行部１１０が、指定されたタイミングで、指定されたサーバに対して、リードアクセスを発行する（ステップＳ１９５）。
【０１７０】
図１５および図１６に示す第７の方法の決定処理では、決定部２１０が、リード関数からアクセス待ちリスト１０４に登録した通知を受け取る（図１５のステップＳ１２１）。この通知を受け取ると（図１５のステップＳ１２１のＹＥＳ）、決定部２１０が、アクセス待ちリスト１０４で消費されているメモリ量が一定量以上かを調べる（図１５のステップＳ１３１）。もし一定量以上であれば（図１５のステップＳ１３１のＹＥＳ）、リードアクセス発行部１１０が、１つのキーあたりにかかるバリュー取得時間が最も少ないサーバに対してリードアクセスを発行する（図１５のステップＳ１４１）。そうでなければ（図１５のステップＳ１３１のＮＯ）、決定部２１０が、リード関数からアクセス待ちリストに登録した通知が所定回数以上来たかどうかを調べる（図１５のステップＳ１６１）。なお、本ステップは省略して、成立したものとして次に進んでもよい。
【０１７１】
もし所定回数以上来ていれば（図１５のステップＳ１６１のＹＥＳ）、決定部２１０が、１つのキーあたりにかかるバリュー取得時間の最小値が閾値以下のサーバがあるかを調べる（図１５のステップＳ１５１）。もしあれば（図１５のステップＳ１５１のＹＥＳ）、リードアクセス発行部１１０が、当該サーバに対するリードアクセスを発行する（図１５のステップＳ１２５）。
【０１７２】
また、本方法では、決定部２１０が、タイマから一定時間ごとに通知を受け取り（図１６のステップＳ１７１のＹＥＳ）、一定時間以上リードアクセスが発行されていないサーバがあるか、アクセス待ちリスト１０４に記録した前回のリード発行時刻を元に調べる（図１６のステップＳ１８１）。もしそのようなサーバがあれば（図１６のステップＳ１８１のＹＥＳ）、リードアクセス発行部１１０が、当該サーバに対するリードアクセスを発行する（図１６のステップＳ１２５）。もしなければ（図１６のステップＳ１８１のＮＯ）、決定部２１０が、１つのキーあたりにかかるバリュー取得時間の最小値が閾値以下のサーバがあるかを調べる（図１６のステップＳ１５１）。もしあれば（図１６のステップＳ１５１のＹＥＳ）、リードアクセス発行部１１０が、当該サーバに対するリードアクセスを発行する（図１６のステップＳ１２５）。
【０１７３】
また、本方法では、図１４に示すように、決定部２１０が、プログラムから明示的にリードアクセスを発行するサーバを指定した関数を呼び出してもよい（ステップＳ１９１）。そして、リードアクセス発行部１１０が、指定されたタイミングで指定されたサーバに対して、リードアクセスを発行する（ステップＳ１９５）。
【０１７４】
以上説明したように、本発明の実施の形態の分散システム１によれば、上記実施形態と同様な効果を奏するとともに、ライトアクセスやアキュムレートアクセスとともに、効率のよい処理を行うことができる。
【０１７５】
以上、図面を参照して本発明の実施形態について述べたが、これらは本発明の例示であり、上記以外の様々な構成を採用することもできる。
【０１７６】
たとえば、本発明の実施形態における最小構成は、図２７に示すような情報処理装置１０００とすることができる。情報処理装置１０００は、複数のサーバ（分散テーブルサーバ１０）がそれぞれ有する複数の分散テーブル（不図示）からデータを読み出すリード（read）アクセス処理のキー（Key）、および、キーに基づき読み出した結果を用いて実行する処理を定めるコールバック（Callback）、を受け付ける受付部１０２と、受け付けたリードアクセス処理を待機させ、該当する分散テーブルサーバ１０に後で発行する待機リードアクセスとしてキーとコールバックをアクセス待ちリスト１０４に登録する登録部１０６と、アクセス待ちリスト１０４に登録された待機リードアクセスについて、所定の条件に従い、待機リードアクセスを発行する発行先の分散テーブルサーバ１０および発行タイミングを決定する決定部１０８と、決定部１０８が決定した発行先の分散テーブルサーバ１０に、決定した発行タイミングで、待機リードアクセスを発行し、分散テーブルサーバ１０から当該アクセス結果を受け取るリードアクセス発行部１１０と、リードアクセス発行部１１０が受け取ったアクセス結果（バリュー）を用いて、アクセス待ちリスト１０４に登録された該当する待機リードアクセスのコールバックを実行し、実行したコールバックの待機リードアクセスをアクセス待ちリスト１０４から削除するコールバック実行部１１２と、を備える。
【０１７７】
図２７の情報処理装置１０００は、上記実施形態のクライアント装置を実現する図３のコンピュータ６０と同様なコンピュータのハードウェアとソフトウェアの任意の組み合わせによって実現される。図２７は、ハードウェア単位の構成ではなく、論理的な機能単位のブロックを示している。
本実施の形態の情報処理装置１０００では、コンピュータプログラムに対応する各種の処理動作をコンピュータのＣＰＵが実行することにより、図２７の各種ユニットが各種機能として実現される。
【０１７８】
この構成によれば、情報処理装置１０００が、任意のプログラムを対象として、プログラム上の任意の場所に現れる分散テーブルサーバ１０へのリード関数による複数のリードアクセス処理を、リードアクセス毎に行うのではなく、アクセス待ちリスト１０４に登録して一定数以上待機させることで、サーバ毎にまとめて実行することができる。そして、この構成により、プログラム上に複数現れるリードアクセス処理を、その都度処理する場合に比較して、リードアクセス時にかかるレイテンシによるアクセス処理速度への影響を削減することができ、高速化を図ることができる。
【０１７９】
以上、実施形態および実施例を参照して本願発明を説明したが、本願発明は上記実施形態および実施例に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。
【０１８０】
以下、参考形態の例を付記する。
１．  複数のサーバがそれぞれ有する複数の分散テーブルからデータを読み出すリードアクセス処理のキー、および、前記キーに基づき読み出した結果を用いて実行する処理を定めるコールバック、を受け付ける受付手段と、
受け付けた前記リードアクセス処理を待機させ、該当するサーバに後で発行する待機リードアクセスとして前記キーと前記コールバックをアクセス待ちリストに登録する登録手段と、
前記アクセス待ちリストに登録された前記待機リードアクセスについて、所定の条件に従い、前記待機リードアクセスを発行する発行先のサーバおよび発行タイミングを決定する決定手段と、
前記決定手段が決定した前記発行先の前記サーバに、決定した前記発行タイミングで、前記待機リードアクセスを発行し、前記サーバから当該アクセス結果を受け取るリードアクセス発行手段と、
前記リードアクセス発行手段が受け取った前記アクセス結果を用いて、前記アクセス待ちリストに登録された該当する待機リードアクセスの前記コールバックを実行し、実行した前記コールバックの前記待機リードアクセスを前記アクセス待ちリストから削除するコールバック実行手段と、を備える分散システム。
２．  １．に記載の分散システムにおいて、
前記登録手段は、前記サーバ毎、または前記キー毎に、前記待機リードアクセスを分類して前記アクセス待ちリストに登録し、
前記決定手段は、前記サーバ毎または前記キー毎に、前記待機リードアクセスの前記発行タイミングを決定する分散システム。
３．  １．または２に記載の分散システムにおいて、
前記決定手段は、各前記サーバの性能情報に基づいて求まる、前記キー１つあたりにかかる前記アクセス結果の取得時間に基づいて、前記リードアクセスの前記発行先となるサーバを選択する分散システム。
４．  １．乃至３．いずれかに記載の分散システムにおいて、
前記決定手段は、前記アクセス待ちリストに登録された前記待機リードアクセスの件数が一定数以上になったときを、前記発行タイミングであると決定する分散システム。
５．  １．乃至４．いずれかに記載の分散システムにおいて、
前記決定手段は、
前記アクセス待ちリストのメモリ量が一定量以上になった場合、前記発行タイミングになったと判断し、
前記メモリ量が一定量以上になった時点で、前記アクセス待ちリストに登録された前記待機リードアクセスの件数が多いサーバを前記リードアクセスの前記発行先として選択する分散システム。
６．  １．乃至５．いずれかに記載の分散システムにおいて、
前記決定手段は、一定時間以上、前記リードアクセス発行手段により前記リードアクセスが発行されていないサーバを前記リードアクセスの前記発行先として選択する分散システム。
７．  １．乃至６．いずれかに記載の分散システムにおいて、
前記受付手段は、前記分散テーブルのキーに対して値を書き込むライトアクセス処理をさらに受け付け、
前記アクセス待ちリストを参照し、前記ライトアクセス処理と同じキーに対する前記待機リードアクセスが存在する場合、前記コールバック実行手段は、前記ライトアクセス処理の前記値で前記待機リードアクセスの前記コールバックを実行し、前記アクセス待ちリストから当該待機リードアクセスを削除する分散システム。
８．  ７．に記載の分散システムにおいて、
前記受付手段は、前記リードアクセス処理より後に受け付ける前記ライトアクセス処理を、先に処理することを禁止する禁止フラグを、前記リードアクセス処理の前記キーと前記コールバックとともに受け付け、
前記登録手段は、受け付けた前記禁止フラグを前記待機リードアクセスの前記キーおよび前記コールバックとともに前記アクセス待ちリストに登録し、
さらに、前記登録手段は、前記アクセス待ちリストを参照し、受け付けた前記ライトアクセス処理と同じキーに対する前記待機リードアクセスの前記禁止フラグが登録されている場合、受け付けた前記ライトアクセス処理を待機させ、該当するサーバに後で発行する待機ライトアクセスとして前記キーと前記値を前記アクセス待ちリストに登録する分散システム。
９．  ３．に記載の分散システムにおいて、
前記決定手段は、前記キー１つあたりにかかる前記アクセス結果の取得時間を前記サーバ毎に算出し、最小値が閾値以下のサーバを前記リードアクセスの前記発行先として選択する分散システム。
１０．  ９．に記載の分散システムにおいて、
前記決定手段は、前記登録手段が、前記アクセス待ちリストに前記待機リードアクセスを登録する度に、前記キー１つあたりにかかる前記アクセス結果の取得時間を算出し、算出される度に、前記発行先の選択を行う分散システム。
１１．  ９．に記載の分散システムにおいて、
前記決定手段は、前記登録手段による前記アクセス待ちリストへの前記待機リードアクセスの登録が所定回数毎に、前記キー１つあたりにかかる前記アクセス結果の取得時間を算出し、算出される度に、前記発行先の選択を行う分散システム。
１２．  ９．に記載の分散システムにおいて、
前記決定手段は、一定時間毎に、前記キー１つあたりにかかる前記アクセス結果の取得時間を算出し、算出される度に、前記発行先の選択を行う分散システム。
１３．  １．乃至１２．いずれかに記載の分散システムにおいて、
前記決定手段は、前記リードアクセスの前記発行先と、前記発行タイミングの指定を受け付け、前記指定に従い、前記リードアクセスの前記発行先と、前記発行タイミングを決定する分散システム。
【０１８１】
１４．  情報処理装置が、
複数のサーバがそれぞれ有する複数の分散テーブルからデータを読み出すリードアクセス処理のキー、および、前記キーに基づき読み出した結果を用いて実行する処理を定めるコールバック、を受け付け、
受け付けた前記リードアクセス処理を待機させ、該当するサーバに後で発行する待機リードアクセスとして前記キーと前記コールバックをアクセス待ちリストに登録し、
前記アクセス待ちリストに登録された前記リードアクセスについて、所定の条件に従い、前記待機リードアクセスを発行するサーバおよび発行タイミングを決定し、
決定した前記サーバに、決定した前記発行タイミングで、前記待機リードアクセスを発行し、前記サーバから当該アクセス結果を受け取り、
受け取った前記アクセス結果を用いて、前記アクセス待ちリストに登録された該当する待機リードアクセスの前記コールバックを実行し、実行した前記コールバックの前記待機リードアクセスを前記アクセス待ちリストから削除する情報処理装置のデータ処理方法。
１５．  １４．に記載の情報処理装置のデータ処理方法において、
前記情報処理装置が、
前記リードアクセス処理を受け付けたとき、前記サーバ毎、または前記キー毎に、前記待機リードアクセスを分類して前記アクセス待ちリストに登録し、
前記アクセス待ちリストに登録された前記リードアクセスについて、前記サーバ毎または前記キー毎に、前記待機リードアクセスの前記発行タイミングを決定する情報処理装置のデータ処理方法。
１６．  １４．または１５．に記載の情報処理装置のデータ処理方法において、
前記情報処理装置が、
各前記サーバの性能情報に基づいて求まる、前記キー１つあたりにかかる前記アクセス結果の取得時間に基づいて、前記リードアクセスの前記発行先となるサーバを選択する情報処理装置のデータ処理方法。
１７．  １４．乃至１６．いずれかに記載の情報処理装置のデータ処理方法において、
前記情報処理装置が、
前記アクセス待ちリストに登録された前記待機リードアクセスの件数が一定数以上になったときを、前記発行タイミングであると決定する情報処理装置のデータ処理方法。
１８．  １４．乃至１７．いずれかに記載の情報処理装置のデータ処理方法において、
前記情報処理装置が、
前記アクセス待ちリストのメモリ量が一定量以上になった場合、前記発行タイミングになったと判断し、
前記メモリ量が一定量以上になった時点で、前記アクセス待ちリストに登録された前記待機リードアクセスの件数が多いサーバを前記リードアクセスの前記発行先として選択する情報処理装置のデータ処理方法。
１９．  １４．乃至１８．いずれかに記載の情報処理装置のデータ処理方法において、
前記情報処理装置が、
一定時間以上、前記リードアクセスが発行されていないサーバを前記リードアクセスの前記発行先として選択する情報処理装置のデータ処理方法。
２０．  １４．乃至１９．いずれかに記載の情報処理装置のデータ処理方法において、
前記情報処理装置が、
前記分散テーブルのキーに対して値を書き込むライトアクセス処理をさらに受け付け、
前記アクセス待ちリストを参照し、前記ライトアクセス処理と同じキーに対する前記待機リードアクセスが存在する場合、前記ライトアクセス処理の前記値で前記待機リードアクセスの前記コールバックを実行し、前記アクセス待ちリストから当該待機リードアクセスを削除する情報処理装置のデータ処理方法。
２１．  ２０．に記載の情報処理装置のデータ処理方法において、
前記情報処理装置が、
前記リードアクセス処理より後に受け付ける前記ライトアクセス処理を、先に処理することを禁止する禁止フラグを、前記リードアクセス処理の前記キーと前記コールバックとともに受け付け、
受け付けた前記禁止フラグを前記待機リードアクセスの前記キーおよび前記コールバックとともに前記アクセス待ちリストに登録し、
さらに、前記アクセス待ちリストを参照し、受け付けた前記ライトアクセス処理と同じキーに対する前記待機リードアクセスの前記禁止フラグが登録されている場合、受け付けた前記ライトアクセス処理を待機させ、該当するサーバに後で発行する待機ライトアクセスとして前記キーと前記値を前記アクセス待ちリストに登録する情報処理装置のデータ処理方法。
２２．  １６．に記載の情報処理装置のデータ処理方法において、
前記情報処理装置が、
前記キー１つあたりにかかる前記アクセス結果の取得時間を前記サーバ毎に算出し、最小値が閾値以下のサーバを前記リードアクセスの前記発行先として選択する情報処理装置のデータ処理方法。
２３．  ２２．に記載の情報処理装置のデータ処理方法において、
前記情報処理装置が、
前記アクセス待ちリストに前記待機リードアクセスを登録する度に、前記キー１つあたりにかかる前記アクセス結果の取得時間を算出し、算出される度に、前記発行先の選択を行う情報処理装置のデータ処理方法。
２４．  ２２．に記載の情報処理装置のデータ処理方法において、
前記情報処理装置が、
前記アクセス待ちリストへの前記待機リードアクセスの登録が所定回数毎に、前記キー１つあたりにかかる前記アクセス結果の取得時間を算出し、算出される度に、前記発行先の選択を行う情報処理装置のデータ処理方法。
２５．  ２２．に記載の情報処理装置のデータ処理方法において、
前記情報処理装置が、
一定時間毎に、前記キー１つあたりにかかる前記アクセス結果の取得時間を算出し、算出される度に、前記発行先の選択を行う情報処理装置のデータ処理方法。
２６．  １４．乃至２５．いずれかに記載の情報処理装置のデータ処理方法において、
前記情報処理装置が、
前記リードアクセスの前記発行先と、前記発行タイミングの指定を受け付け、前記指定に従い、前記リードアクセスの前記発行先と、前記発行タイミングを決定する情報処理装置のデータ処理方法。
【０１８２】
２７．  情報処理装置を実現するコンピュータに、
複数のサーバがそれぞれ有する複数の分散テーブルからデータを読み出すリードアクセス処理のキー、および、前記キーに基づき読み出した結果を用いて実行する処理を定めるコールバック、を受け付ける手順、
受け付けた前記リードアクセス処理を待機させ、該当するサーバに後で発行する待機リードアクセスとして前記キーと前記コールバックをアクセス待ちリストに登録する手順、
前記アクセス待ちリストに登録された前記待機リードアクセスについて、所定の条件に従い、前記待機リードアクセスを発行するサーバおよび発行タイミングを決定する手順、
決定した前記サーバに、決定した前記発行タイミングで、前記待機リードアクセスを発行し、前記サーバから当該アクセス結果を受け取る手順、
受け取った前記アクセス結果を用いて、前記アクセス待ちリストに登録された該当する待機リードアクセスの前記コールバックを実行し、実行した前記コールバックの前記待機リードアクセスを前記アクセス待ちリストから削除する手順、を実行させるためのプログラム。
２８．  ２７．に記載のプログラムにおいて、
前記リードアクセス処理を受け付けたとき、前記サーバ毎、または前記キー毎に、前記待機リードアクセスを分類して前記アクセス待ちリストに登録する手順、
前記アクセス待ちリストに登録された前記リードアクセスについて、前記サーバ毎または前記キー毎に、前記待機リードアクセスの前記発行タイミングを決定する手順をコンピュータに実行させるためのプログラム。
２９．  ２７．または２８．に記載のプログラムにおいて、
各前記サーバの性能情報に基づいて求まる、前記キー１つあたりにかかる前記アクセス結果の取得時間に基づいて、前記リードアクセスの前記発行先となるサーバを選択する手順をコンピュータに実行させるためのプログラム。
３０．  ２７．乃至２９．いずれかに記載のプログラムにおいて、
前記アクセス待ちリストに登録された前記待機リードアクセスの件数が一定数以上になったときを、前記発行タイミングであると決定する手順をコンピュータに実行させるためのプログラム。
３１．  ２７．乃至３０．いずれかに記載のプログラムにおいて、
前記アクセス待ちリストのメモリ量が一定量以上になった場合、前記発行タイミングになったと判断する手順、
前記メモリ量が一定量以上になった時点で、前記アクセス待ちリストに登録された前記待機リードアクセスの件数が多いサーバを前記リードアクセスの前記発行先として選択する手順をコンピュータに実行させるためのプログラム。
３２．  ２７．乃至３１．いずれかに記載のプログラムにおいて、
一定時間以上、前記リードアクセスが発行されていないサーバを前記リードアクセスの前記発行先として選択する手順をコンピュータに実行させるためのプログラム。
３３．  ２７．乃至３２．いずれかに記載のプログラムにおいて、
前記分散テーブルのキーに対して値を書き込むライトアクセス処理をさらに受け付ける手順、
前記アクセス待ちリストを参照し、前記ライトアクセス処理と同じキーに対する前記待機リードアクセスが存在する場合、前記ライトアクセス処理の前記値で前記待機リードアクセスの前記コールバックを実行する手順、
前記アクセス待ちリストから当該待機リードアクセスを削除する手順をコンピュータに実行させるためのプログラム。
３４．  ３３．に記載のプログラムにおいて、
前記リードアクセス処理より後に受け付ける前記ライトアクセス処理を、先に処理することを禁止する禁止フラグを、前記リードアクセス処理の前記キーと前記コールバックとともに受け付ける手順、
受け付けた前記禁止フラグを前記待機リードアクセスの前記キーおよび前記コールバックとともに前記アクセス待ちリストに登録する手順、
前記アクセス待ちリストを参照し、受け付けた前記ライトアクセス処理と同じキーに対する前記待機リードアクセスの前記禁止フラグが登録されている場合、受け付けた前記ライトアクセス処理を待機させ、該当するサーバに後で発行する待機ライトアクセスとして前記キーと前記値を前記アクセス待ちリストに登録する手順をコンピュータに実行させるためのプログラム。
３５．  ２９．に記載のプログラムにおいて、
前記キー１つあたりにかかる前記アクセス結果の取得時間を前記サーバ毎に算出し、最小値が閾値以下のサーバを前記リードアクセスの前記発行先として選択する手順をコンピュータに実行させるためのプログラム。
３６．  ３５．に記載のプログラムにおいて、
前記アクセス待ちリストに前記待機リードアクセスを登録する度に、前記キー１つあたりにかかる前記アクセス結果の取得時間を算出し、算出される度に、前記発行先の選択を行う手順をコンピュータに実行させるためのプログラム。
３７．  ３５．に記載のプログラムにおいて、
前記アクセス待ちリストへの前記待機リードアクセスの登録が所定回数毎に、前記キー１つあたりにかかる前記アクセス結果の取得時間を算出し、算出される度に、前記発行先の選択を行う手順をコンピュータに実行させるためのプログラム。
３８．  ３５．に記載のプログラムにおいて、
一定時間毎に、前記キー１つあたりにかかる前記アクセス結果の取得時間を算出し、算出される度に、前記発行先の選択を行う手順をコンピュータに実行させるためのプログラム。
３９．  ２７．乃至３８．いずれかに記載のプログラムにおいて、
前記リードアクセスの前記発行先と、前記発行タイミングの指定を受け付ける手順、
前記指定に従い、前記リードアクセスの前記発行先と、前記発行タイミングを決定する手順をコンピュータに実行させるためのプログラム。
【０１８３】
４０．  複数のサーバがそれぞれ有する複数の分散テーブルからデータを読み出すリードアクセス処理のキー、および、前記キーに基づき読み出した結果を用いて実行する処理を定めるコールバック、を受け付ける受付手段と、
受け付けた前記リードアクセス処理を待機させ、該当するサーバに後で発行する待機リードアクセスとして前記キーと前記コールバックをアクセス待ちリストに登録する登録手段と、
前記アクセス待ちリストに登録された前記待機リードアクセスについて、所定の条件に従い、前記待機リードアクセスを発行する発行先のサーバおよび発行タイミングを決定する決定手段と、
前記決定手段が決定した前記発行先の前記サーバに、決定した前記発行タイミングで、前記待機リードアクセスを発行し、前記サーバから当該アクセス結果を受け取るリードアクセス発行手段と、
前記リードアクセス発行手段が受け取った前記アクセス結果を用いて、前記アクセス待ちリストに登録された該当する待機リードアクセスの前記コールバックを実行し、実行した前記コールバックの前記待機リードアクセスを前記アクセス待ちリストから削除するコールバック実行手段と、を備える情報処理装置。
４１．  ４０．に記載の情報処理装置において、
前記登録手段は、前記サーバ毎、または前記キー毎に、前記待機リードアクセスを分類して前記アクセス待ちリストに登録し、
前記決定手段は、前記サーバ毎または前記キー毎に、前記待機リードアクセスの前記発行タイミングを決定する情報処理装置。
４２．  ４０．または４１．に記載の情報処理装置において、
前記決定手段は、各前記サーバの性能情報に基づいて求まる、前記キー１つあたりにかかる前記アクセス結果の取得時間に基づいて、前記待機リードアクセスの前記発行先となるサーバを選択する情報処理装置。
４３．  ４０．乃至４２．いずれかに記載の情報処理装置において、
前記決定手段は、前記アクセス待ちリストに登録された前記待機リードアクセスの件数が一定数以上になったときを、前記発行タイミングであると決定する情報処理装置。
４４．  ４０．乃至４３．いずれかに記載の情報処理装置において、
前記決定手段は、
前記アクセス待ちリストのメモリ量が一定量以上になった場合、前記発行タイミングになったと判断し、
前記メモリ量が一定量以上になった時点で、前記アクセス待ちリストに登録された前記待機リードアクセスの件数が多いサーバを前記待機リードアクセスの前記発行先として選択する情報処理装置。
４５．  ４０．乃至４４．いずれかに記載の情報処理装置において、
前記決定手段は、一定時間以上、前記リードアクセス発行手段により前記待機リードアクセスが発行されていないサーバを前記待機リードアクセスの前記発行先として選択する情報処理装置。
４６．  ４０．乃至４５．いずれかに記載の情報処理装置において、
前記受付手段は、前記分散テーブルのキーに対して値を書き込むライトアクセス処理をさらに受け付け、
前記アクセス待ちリストを参照し、前記ライトアクセス処理と同じキーに対する前記待機リードアクセスが存在する場合、前記コールバック実行手段は、前記ライトアクセス処理の前記値で前記待機リードアクセスの前記コールバックを実行し、前記アクセス待ちリストから当該待機リードアクセスを削除する情報処理装置。
４７．  ４６．に記載の情報処理装置において、
前記受付手段は、前記リードアクセス処理より後に受け付ける前記ライトアクセス処理を、先に処理することを禁止する禁止フラグを、前記リードアクセス処理の前記キーと前記コールバックとともに受け付け、
前記登録手段は、受け付けた前記禁止フラグを前記待機リードアクセスの前記キーおよび前記コールバックとともに前記アクセス待ちリストに登録し、
さらに、前記登録手段は、前記アクセス待ちリストを参照し、受け付けた前記ライトアクセス処理と同じキーに対する前記待機リードアクセスの前記禁止フラグが登録されている場合、受け付けた前記ライトアクセス処理を待機させ、該当するサーバに後で発行する待機ライトアクセスとして前記キーと前記値を前記アクセス待ちリストに登録する情報処理装置。
４８．  ４２．に記載の情報処理装置において、
前記決定手段は、前記キー１つあたりにかかる前記アクセス結果の取得時間を前記サーバ毎に算出し、最小値が閾値以下のサーバを前記リードアクセスの前記発行先として選択する情報処理装置。
４９．  ４８．に記載の情報処理装置において、
前記決定手段は、前記登録手段が、前記アクセス待ちリストに前記待機リードアクセスを登録する度に、前記キー１つあたりにかかる前記アクセス結果の取得時間を算出し、算出される度に、前記発行先の選択を行う情報処理装置。
５０．  ４８．に記載の情報処理装置において、
前記決定手段は、前記登録手段による前記アクセス待ちリストへの前記待機リードアクセスの登録が所定回数毎に、前記キー１つあたりにかかる前記アクセス結果の取得時間を算出し、算出される度に、前記発行先の選択を行う情報処理装置。
５１．  ４８．に記載の情報処理装置において、
前記決定手段は、一定時間毎に、前記キー１つあたりにかかる前記アクセス結果の取得時間を算出し、算出される度に、前記発行先の選択を行う情報処理装置。
５２．  ４０．乃至５１．いずれかに記載の情報処理装置において、
前記決定手段は、前記リードアクセスの前記発行先と、前記発行タイミングの指定を受け付け、前記指定に従い、前記リードアクセスの前記発行先と、前記発行タイミングを決定する情報処理装置。
【０１８４】
５３．  ４０．乃至５２．いずれかに記載の情報処理装置と、
前記情報処理装置がアクセスする複数の分散テーブルをそれぞれ有する複数のサーバと、を備える分散システム。
【０１８５】
この出願は、２０１２年８月３１日に出願された日本特許出願特願２０１２−１９２４５３を基礎とする優先権を主張し、その開示の全てをここに取り込む。
【図１】
2014034852.tif 000004
【図２】
2014034852.tif 000005
【図３】
2014034852.tif 000006
【図４】
2014034852.tif 000007
【図５】
2014034852.tif 000008
【図６】
2014034852.tif 000009
【図７】
2014034852.tif 000010
【図８】
2014034852.tif 000011
【図９】
2014034852.tif 000012
【図１０】
2014034852.tif 000013
【図１１】
2014034852.tif 000014
【図１２】
2014034852.tif 000015
【図１３】
2014034852.tif 000016
【図１４】
2014034852.tif 000017
【図１５】
2014034852.tif 000018
【図１６】
2014034852.tif 000019
【図１７】
2014034852.tif 000020
【図１８】
2014034852.tif 000021
【図１９】
2014034852.tif 000022
【図２０】
2014034852.tif 000023
【図２１】
2014034852.tif 000024
【図２２】
2014034852.tif 000025
【図２３】
2014034852.tif 000026
【図２４】
2014034852.tif 000027
【図２５】
2014034852.tif 000028
【図２６】
2014034852.tif 000029
【図２７】
2014034852.tif 000030
【国際調査報告】
2014034852.tif 000031
2014034852.tif 000032