(57)【特許請求の範囲】
【請求項１】
第１キーと第１データとを含む書き込み要求を受信する要求受信部と、
前記書き込み要求に含まれる前記第１データを一時的にバッファリングするバッファ部と、
前記バッファ部における前記第１データのバッファリング状況に応じて、前記バッファ部にバッファリングされている前記第１データのうちまだ読み出していない一部データである第２データを読み出し、前記第１データにおける前記第２データの位置に応じた第２キーを、前記第１キーに基づき生成するキー生成部と、
前記第２データを含むデータ構造体を、前記第２キーに関連づけて、内部または外部の記憶装置に書き込む処理部と
を備えたデータ処理装置。
【請求項２】
前記キー生成部は、前記バッファ部における前記第１データのバッファリング状況として、前記バッファ部にバッファリングされておりかつ前記第１データの先頭側からまだ読み出されていない連続するバイト列のデータサイズに応じて、前記第２データの読み出しを行う
請求項１に記載のデータ処理装置。
【請求項３】
前記キー生成部は、前記データサイズが一定値に達したとき、前記一定値のサイズ分の連続するバイト列の前記第２データを前記第１データの先頭側から読み出す
請求項２に記載のデータ処理装置。
【請求項４】
前記処理部は、前記第２データを含むデータ構造体に、前記第２データに対して生成された前記第２キーをさらに含める
請求項１ないし３のいずれか一項に記載のデータ処理装置。
【請求項５】
前記処理部は、前記第２データが前記第１データの先頭を含む場合、前記第２データを含むデータ構造体に、前記第１データのサイズ情報をさらに含める
請求項１ないし４のいずれか一項に記載のデータ処理装置。
【請求項６】
前記キー生成部は、前記バッファ部から読み出した前記第２データが前記第１データの末尾を含むかを判断し、
前記処理部は、前記第２データが前記第１データの末尾を含むかを識別する後続有無識別情報を前記データ構造体に含める、
請求項１ないし５のいずれか一項に記載のデータ処理装置。
【請求項７】
前記書き込み要求は、前記第１データのサイズ情報を含み、
前記キー生成部は、前記第１データのサイズ情報に基づき、前記バッファ部からの読み出しを何回行うかの回数情報を計算し、
前記処理部は、前記第２データが前記第１データの先頭を含む場合、前記第２データを含むデータ構造体に、前記回数情報をさらに含める
請求項１ないし６のいずれか一項に記載のデータ処理装置。
【請求項８】
前記書き込み要求は、前記第１データのサイズ情報を含み、
前記キー生成部は、前記第１データのサイズが所定サイズ以下のときは、前記第１データの全部が前記バッファ部にバッファリングされたら、前記第１データの全部を読み出し、
前記第２データは、前記第１データの全部、または前記第１データの一部のデータである
請求項１ないし７のいずれか一項に記載のデータ処理装置。
【請求項９】
前記記憶装置は、第１記憶部と、前記第１記憶部よりもアクセス速度が遅い第２記憶部とを備え、
前記第１データの先頭を含む前記第２データを含む前記データ構造体は、前記第１記憶部に格納する
請求項１ないし８のいずれか一項に記載のデータ処理装置。
【請求項１０】
前記記憶装置の障害を検知する障害検知部と、
前記書き込み要求に対する処理が完了する前に、前記記憶装置の故障が検知された場合に、前記記憶装置に書き込み済みの前記データ構造体を削除する前記第２キーを生成する削除処理部と、
前記処理部は、前記削除処理部により生成された前記第２キーに対応する前記データ構造体を前記記憶装置から削除する
請求項１ないし９のいずれか一項に記載のデータ処理装置。
【請求項１１】
前記障害検知部により前記記憶装置の障害が検知されたとき、前記書き込み要求の実行がエラーになったことの応答を送信する応答送信部
をさらに備えた請求項１０に記載のデータ処理装置。
【請求項１２】
前記キー生成部は、前記第１キーに、前記第１データにおける前記第２データの位置に応じた固定長の識別子を付与することにより前記第２キーを生成する
請求項１ないし１１のいずれか一項に記載のデータ処理装置。
【請求項１３】
前記処理部は、前記第２キーと、前記データ構造体の書き込みアドレスとの対応を、対応情報に登録する
請求項１ないし１２のいずれか一項に記載のデータ処理装置。
【請求項１４】
第１キーを指定した、第１データの読み出し要求を受信する要求受信部と、
前記読み出し要求に含まれる前記第１キーに基づき、前記第１データにおいて前記第１データの一部または全部のデータである第２データの位置に応じた第２キーを生成するキー生成部と、
前記第２キーに基づき、内部または外部の記憶装置から、前記第２キーに関連づけられた、前記第２データを含むデータ構造体を読み出す処理部と、
前記処理部により読み出されたデータ構造体に含まれる第２データを送信する応答送信部と、
前記キー生成部で生成された前記第２キーに対応する前記第２データが前記第１データの末尾を含むか判断する判断部と、を備え
前記キー生成部は、前記判断部で前記第１データの末尾を含まないと判断された場合は、前記第１データにおいて前記第１データの末尾を含まないと判断された前記第２データに後続する一部の連続するバイト列のデータである前記第２データの位置に応じて前記第２キーを生成する
データ処理装置。
【請求項１５】
前記第１データの先頭を含む前記第２データを含む前記データ構造体は、前記第１データのサイズ情報を含み、
前記判断部は、前記第１データのサイズ情報と、前記記憶装置からこれまで読み出された前記第２データのサイズに基づき、前記第１データの末尾を含む前記第２データが読み出されたかを判断する
請求項１４に記載のデータ処理装置。
【請求項１６】
前記第２データを含む前記データ構造体は、前記第２データが前記第１データの末尾を含むかを識別する後続有無識別情報を含み、
前記判断部は、前記記憶装置から読み出された前記データ構造体に含まれる前記後続有無識別情報に基づき、前記データ構造体に含まれる前記第２データが、前記第１データの末尾を含むかを判断する
請求項１４に記載のデータ処理装置。
【請求項１７】
前記第１データの先頭を含む前記第２データを含む前記データ構造体は、読み出しの回数情報を含み、
前記判断部は、前記回数情報に応じた回数だけ前記記憶装置からの読み出しが行われたかに応じて、前記第１データの末尾を含む第２データが読み出されたかを判断する
請求項１４に記載のデータ処理装置。
【請求項１８】
前記キー生成部は、前記第１キーに、前記第１データにおける前記第２データの位置に応じた固定長の識別子を付与することにより、前記第２キーを生成する
請求項１４ないし１７のいずれか一項に記載のデータ処理装置。
【請求項１９】
前記記憶装置の障害を検知する障害検知部と、
前記読み出し要求の実行が完了する前に、前記記憶装置の故障が検知された場合に、前記読み出し要求の送信元装置と前記読み出し要求に関する通信コネクションを切断するコネクション切断部
を備えた請求項１４ないし１８のいずれか一項に記載のデータ処理装置。
【請求項２０】
前記記憶装置の障害を検知する障害検知部と、
前記読み出し要求に応じた前記記憶装置からの読み出しが完了する前に、前記記憶装置の故障が検知された場合に、前記第１データのうちまだ前記記憶装置からの読み出しが完了していないデータサイズ分のダミーデータを生成するダミーデータ生成部と、を備え、  前記応答送信部は、前記ダミーデータを、前記読み出しが完了していないデータサイズ分のデータを送信する代わりに送信する
請求項１４ないし１８のいずれか一項に記載のデータ処理装置。
【請求項２１】
第１キーと第１データとを含む書き込み要求を受信する要求受信ステップと、
前記書き込み要求に含まれる前記第１データを一時的にバッファ部にバッファリングするバッファリングステップと、
前記バッファ部における前記第１データのバッファリング状況に応じて、前記バッファ部にバッファリングされている前記第１データのうちまだ読み出していない一部データである第２データを読み出し、前記第１データにおける前記第２データの位置に応じた第２キーを、前記第１キーに基づき生成する生成ステップと、
前記第２データを含むデータ構造体を、前記第２キーに関連づけて記憶装置に書き込む処理ステップと
を備えたデータ処理方法。
【請求項２２】
第１キーを指定した、第１データの読み出し要求を受信する要求受信ステップと、
前記読み出し要求に含まれる前記第１キーに基づき、前記第１データにおいて前記第１データの先頭から一部または全部の連続するバイト列のデータである第２データの位置に応じた第２キーを生成する生成ステップと、
前記第２キーに基づき、記憶装置から、前記第２キーに関連づけられた、前記第２データを含むデータ構造体を読み出す処理ステップと、
前記処理ステップにより読み出された前記データ構造体に含まれる第２データを送信する応答送信ステップと、
前記生成ステップで生成された前記第２キーに対応する前記第２データが前記第１データの末尾を含むか判断する判断ステップと、を備え
前記生成ステップは、前記判断ステップで前記第１データの末尾を含まないと判断された場合は、前記第１データにおいて前記第１データの末尾を含まないと判断された前記第２データに後続する一部の連続するバイト列のデータである前記第２データの位置に応じて前記第２キーを生成する
データ処理方法。
【請求項２３】
第１キーと第１データとを含む書き込み要求を受信する要求受信ステップと、
前記書き込み要求に含まれる前記第１データを一時的にバッファ部にバッファリングするバッファリングステップと、
前記バッファ部における前記第１データのバッファリング状況に応じて、前記バッファ部にバッファリングされている前記第１データのうちまだ読み出していない一部データである第２データを読み出し、前記第１データにおける前記第２データの位置に応じた第２キーを、前記第１キーに基づき生成する生成ステップと、
前記第２データを含むデータ構造体を、前記第２キーに関連づけて記憶装置に書き込む処理ステップと
をコンピュータに実行させるためのプログラム。
【請求項２４】
第１キーを指定した、第１データの読み出し要求を受信する要求受信ステップと、
前記読み出し要求に含まれる前記第１キーに基づき、前記第１データにおいて前記第１データの先頭から一部または全部の連続するバイト列のデータである第２データの位置に応じた第２キーを生成する生成ステップと、
前記第２キーに基づき、記憶装置から、前記第２キーに関連づけられた、前記第２データを含むデータ構造体を読み出す処理ステップと、
前記処理ステップにより読み出された前記データ構造体に含まれる第２データを送信する応答送信ステップと、
前記生成ステップで生成された前記第２キーに対応する前記第２データが前記第１データの末尾を含むか判断する判断ステップと、
をコンピュータに実行させ、
前記生成ステップは、前記判断ステップで前記第１データの末尾を含まないと判断された場合は、前記第１データにおいて前記第１データの末尾を含まないと判断された前記第２データに後続する一部の連続するバイト列のデータである前記第２データの位置に応じて前記第２キーを生成する、プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、データ処理装置、データ処理方法およびプログラムに関する。
【背景技術】
【０００２】
近年、Ｗｅｂメールやソーシャルネットワークなどに代表される高度なＷｅｂサービスが急速に普及している。このようなＷｅｂサービスでは、ＷｅｂサーバがユーザからのＷｅｂページ表示要求を受けると、Ｗｅｂサーバは必要な個々のテキスト、画像や動画などのデータを、逐一バックエンドのストレージに問い合わせて取得し、ユーザに応答する。このようなストレージとしては、従来からのファイルシステムベースのデータベースも使われているが、近年では、一意のＵＲＬを指定してコンテンツデータにアクセスするという、インターネット上のコンテンツアクセス方式と親和性の高いオブジェクトストレージが、活用され始めている。このようなオブジェクトストレージでは、Ｗｅｂサーバといったクライアント装置から、イーサネット越しに可変長の一意のＫｅｙ（キー）で、可変長のＶａｌｕｅ（バリュー）にアクセスするというキーバリューストア型のＩ／Ｆがとられている。Ｗｅｂサーバの場合、キーはＵＲＬ、バリューはコンテンツデータであることが一般的である。キーに関して、オブジェクトＩＤが可変長でなく、固定長になるものもあるが、基本的な原理等は同様である。システムとしては、Ｃｅｐｈ、Ｏｐｅｎｓｔａｃｋなどがフリーソフトウェアとして有名である。また、ストレージデバイスとしてはＨＤＤやＳＳＤが用いられる。
【０００３】
ＨＤＤやＳＳＤはランダム書き込み性能が悪いため、ＫＶＳ（Ｋｅｙ−Ｖａｌｕｅ  Ｓｔｏｒｅ：キーバリューストア）処理と組み合わせて使われる場合は、ログ形式書き込みという手法がよく使われる。ログ形式書き込みでは、書き込むべきキーとバリューの組（以下、キーバリューと記述する）は、書き込み要求を受け取った順にストレージアドレス上にシーケンシャルに書き込まれる。ハッシュテーブルを用いたＫＶＳ処理の場合は、ハッシュテーブルの各エントリに、キーバリューが書き込まれた先頭アドレスが保存される。同じキーに対する別のキーバリューの書き込みがあった場合は、後に書き込まれた方のアドレスが保存され、後に書き込まれた方が使われる。前に書き込まれたキーバリュー（あるいは意図的に削除されたキーバリュー）は、バックグラウンドで実行されるガーベジコレクションによって、アドレス上の後続するデータで上書きされ（後続するデータが、当該キーバリューが存在していたアドレスに詰められ）、その分空き領域が増加する。
【０００４】
ログ書き込み形式の性質上、あるキーバリューの書き込みの途中で、他のキーバリューの書き込みに移行できない。このため、書き込んでいるキーバリューは、必ず最後まで書き込み終わる必要がある。よって、書き込むキーバリューを、イーサネット等のネットワークから受け取る場合、特にそのキーバリューが複数のパケットに分割されている場合には、キーバリューを構成するすべてのパケットを完全に受信し終わってからでないと、ストレージへの書き込みを開始できない。なぜなら、ネットワーク障害やクライアント装置側の障害によって、途中でキーバリューの受信が止まる可能性があるためである。また、ネットワークは複数の通信コネクション（ＴＣＰコネクション等）によってシェアされており、１つまたは複数のクライアント装置から、複数のキーバリューを同時に受信している場合もある。その場合、単一の通信コネクションが占有している帯域は、ネットワーク帯域全体の一部に過ぎないため、受信と書き込みを同時に行ってしまうと、書き込み速度が、その占有している一部のネットワーク帯域の速度によって制約されてしまう。よって、ストレージ性能をより効率よく活用するという意味でも、完全にキーバリューを受信し終わってから、キーバリューを一気に書き込みを行った方が良い。
【０００５】
以上のように、キーバリューを完全に受信し終わってから、ストレージに書き込むように動作する場合、大きなサイズの受信バッファを用意する必要が生じる。例えば大規模データセンターなどを想定して１０００台のクライアント装置（Ｗｅｂサーバ等）からのアクセスが発生するとする。各クライアント装置が例えば２ソケット（２ＣＰＵ）で構成され、各ＣＰＵが１２物理コアを備えたとすると、バーチャルスレッディングでＣＰＵあたり２４スレッド、クライアント装置あたり４８スレッド、全クライアント装置のスレッド数は４８，０００スレッドになる。この各スレッドと通信コネクションを張ったとして、これらの通信コネクションから１ＭＢのデータを例えば同時に受信することを想定すると、１ＭＢの平均０．５ＭＢ×４８０００コネクション＝２４ＧＢもの受信バッファが必要になる。これはあくまで同時にデータを受信している場合であり、実環境では稀なケースになる可能性はあるものの、メモリとしてはこのようなワーストケースにも対応しておくという設計もありうる。
【０００６】
また、バッファメモリを固定的に確保する方式だと、すべてのコネクションに最大データサイズ分のバッファを確保する必要があり、例えばそれが１ＭＢだとすると、上記の２倍の４８ＧＢ必要となる。また、受信後にストレージに書き込んでいる間、次の受信を例えばダブルバッファで同時に受け付けるようにすると、さらにこの２倍の９６ＧＢの容量が必要になる。
【０００７】
ＫＶＳ処理は基礎的な機能のため、例えばこれを専用ハードウェアロジックで実装する場合も有り得る。ハードウェアロジックは動的なメモリ確保があまり得意ではないため、上記のような固定的なメモリ確保を行う場合があり、さらに性能を追求するために上記ダブルバッファ構成とする場合がある。このため、上記の９６ＧＢという容量は、このような場合に現実として起こりうる。通常このようなバッファはＤＲＡＭで実装されることから、これは無視できないコストアップとなる。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】米国出願公開第２０１１／０２７６７４４号明細書
【発明の概要】
【発明が解決しようとする課題】
【０００９】
本発明の実施形態は、バッファサイズを小さく抑えることを目的とする。
【課題を解決するための手段】
【００１０】
本発明の実施形態としてのデータ処理装置は、要求受信部と、バッファ部と、キー生成部と、処理部とを備える。前記要求受信部は、第１キーと第１データとを含む書き込み要求を受信する。前記バッファ部は、前記書き込み要求に含まれる前記第１データを一時的にバッファリングする。前記キー生成部は、前記バッファ部における前記第１データのバッファリング状況に応じて、前記バッファ部にバッファリングされている前記第１データのうちまだ読み出していない一部データである第２データを読み出し、前記第１データにおける前記第２データの位置に応じた第２キーを、前記第１キーに基づき生成する。前記処理部は、前記第２データを含むデータ構造体を、前記第２キーに関連づけて、内部または外部の記憶装置に書き込む。
【図面の簡単な説明】
【００１１】
【図１】本発明の実施形態に係るデータ処理システムを示す図。
【図２】本発明の実施形態に係るデータ処理システムの他の例を示す図。
【図３】本発明の第１の実施の形態に係るデータ処理装置を示す図。
【図４】ハッシュテーブルの例を示す図。
【図５】キーテーブルの例を示す図。
【図６】元のバリューを３つの部分に分割し、それぞれに元のキーから生成した分割キーを付与する例を模式的に示す図。
【図７】ＫＶ記憶部への書き込みの例を示す図。
【図８】キーテーブルの例を示す図。
【図９】第１の実施形態の動作例のフローチャート。
【図１０】第２の実施形態に係るデータ処理装置のブロック図。
【図１１】第３の実施形態に係るデータ処理装置のブロック図。
【図１２】第３の実施形態の動作例のフローチャート。
【図１３】第４の実施形態に係るデータ処理装置のブロック図。
【図１４】第４の実施形態に係るデータ処理装置の他の例のブロック図。
【発明を実施するための形態】
【００１２】
以下、図面を参照しながら、本発明の実施形態について説明する。
【００１３】
図１は、本発明の実施形態に係るデータ処理システムを示す。データ処理システムは、データ処理装置１１と、複数のクライアント装置２１〜２３を備えている。データ処理装置１１は、ＫＶ（Ｋｅｙ  Ｖａｌｕｅ：キーバリュー）記憶装置３１を備えている。
【００１４】
データ処理装置１１は、イーサネットなどのネットワーク越しに、クライアント装置２１、２２、２３からのキーバリューの書き込み要求を受け付けるキーバリューストア装置である。クライアント装置２１〜２３は、例えばＷｅｂサーバ等のサーバであり、Ｗｅｂサーバの場合、一例として、ＵＲＬをキー、Ｗｅｂページ等のコンテンツデータをバリューとして、キーとバリュー（キーバリュー）の書き込み要求をデータ処理装置１１に行う。クライアント装置２１〜２３は、インターネット等のネットワークを介してユーザ端末と接続されており、例えば、ユーザ端末からのＵＲＬの指定と、Ｗｅｂページデータ（コンテンツデータ）の書き込み指示を受けて、キーバリューの書き込み要求を生成して、データ処理装置１１に送る。ユーザ端末は、Ｗｅｂサーバの管理者用の端末でもよい。データ処理装置１１は、キーバリューの書き込み要求を受けると、後述する第１または第２の実施形態に従った書き込み処理をＫＶ記憶装置３１に行う。書き込みが完了すると、書き込み完了の応答をクライアント装置２１〜２３に返す。
【００１５】
また、クライアント装置２１〜２３は、ユーザ端末から、キーとしてＵＲＬを指定したＷｅｂページの閲覧要求を受けると、キーを指定した、キーバリューの読み出し要求を生成してデータ処理装置１１に送る。データ処理装置１１は、クライアント装置２１〜２３からの読み出し要求を受けて、指定されたキーに基づき、ＫＶ記憶装置３１から後述する第３または第４の実施形態に従って読み出し処理を行い、応答をクライアント装置２１〜２３に返す。
【００１６】
図１ではＫＶ記憶装置がデータ処理装置１１の内部に配置されていたが、図２に示すように、ＫＶ記憶装置３１が、データ処理装置１１に内部バスを介して外付けされてもよい。または、イーサネット等のネットワークを介して、ＫＶ記憶装置３１が、データ処理装置１１に接続されていてもよい。
【００１７】
データ処理装置１１は、典型的な形態としては、ＣＰＵ、メモリ、ストレージ、ネットワークインタフェースなどで構成される。一部の機能がＦＰＧＡやＡＳＩＣなどの専用ハードウェアによって実現されていてもよい。データ処理装置１１は、書き込み機能と読み出し機能の両方を備えていたが、いずれか一方のみの機能を備えていてもよい。
【００１８】
（第１の実施形態）
図３は、本発明の第１の実施の形態に係るデータ処理装置を示す。図３のデータ処理装置は、図１または図２に示したデータ処理装置１１が備える書き込みおよび読み出しの機能のうち書き込み機能に係わる構成を備えたデータ処理装置である。読み出し機能に係わる構成を備えたデータ処理装置については、後述する実施形態で説明する。本明細書で開示する各実施形態を組み合わせることで、図１または図２に示したデータ処理装置１１のように、書き込み機能と読み出し機能の両方に係わる構成を備えたデータ処理装置も実施可能である。
【００１９】
図３に示すように、データ処理装置は、キー（第１キー）とバリュー（第１データ）を含む、キーバリューの書き込み要求を受信する要求受信部１０１と、受信した書き込み要求を一時的にバッファリングする要求バッファ部（バッファ部）１０２と、要求バッファ部１０２からバリューの部分データを分割バリュー（第２データ）として取り出し、分割バリューに対するキーである分割キー（第２キー）を生成する分割キー生成部（キー生成部）１０４と、データを記憶するＫＶ記憶部（記憶装置）１０３と、分割キーと分割バリューとを含むデータ構造体をＫＶ記憶部１０３に書き込み、分割キーとデータ構造体の書き込みアドレスとを対応情報に設定するＫＶ処理部（処理部）１０５と、書き込み要求の完了応答を送信する応答送信部１０６を備える。図３では、ＫＶ記憶部１０３が、データ処理装置の内部に配置されているが、図２のＫＶ記憶装置のように、内部バスまたはネットワークを介して、ＫＶ記憶部１０３が外部から接続されてもよい。以下、データ処理装置の各部についてさらに詳細に説明する。
【００２０】
要求受信部１０１は、イーサネット等のネットワーク越しに、クライアント装置からキーバリューの書き込み要求を受信する。書き込み要求には、ヘッダと、キー（第１キー）と、書き込みの対象データであるバリュー（第１データ）とが含まれる。ヘッダには、書き込み要求である要求種別の識別子と、キーとバリューのそれぞれの長さに関する情報が含まれている。書き込み要求は、書き込み要求に含まれるキーバリュー（もしくはバリュー）を書き込むことを要求する。書き込み要求は、例えばＴＣＰ／ＩＰまたはＵＤＰ／ＩＰなどの通信プロトコル上のメッセージとして構成され、例えばｍｅｍｃａｃｈｅｄなどのプロトコルに従ったメッセージとして構成される。書き込み要求は、１つまたは複数のパケットにより、送受される。
【００２１】
要求バッファ部１０２は、要求受信部１０１で受信された書き込み要求を一旦バッファリングする。より詳細には、書き込み要求のメッセージは、前述のように１つまたは複数のパケットに分割されて、順次送られてくるため、書き込み要求のバッファリングは、段階的に行われることになる。書き込み要求の構成は、その先頭側から、ヘッダ、キー、バリューの順で配置されているため、バッファリングもこの順序で行われる。パケットの到着順が必ずしも順番通りになるとは限らないが、ＴＣＰにより順序制御されて、上記の順番で要求バッファ部１０２に格納される。すなわち、ヘッダ、キー、バリューのバイト列がこの順で、それぞれ先頭から順番に格納される。なお、ヘッダを、要求バッファ部１０２とは別の記憶装置（メモリ等）に格納する構成も可能である。また、ヘッダのみならず、キーも、要求バッファ部１０２とは別のメモリ装置（メモリ等）に格納する構成も可能である。
【００２２】
ＫＶ記憶部１０３は、揮発性または不揮発性のメモリ、ストレージ、またはこれらの両方によって構成される記憶デバイスである。例えばＤＲＡＭ、ＳＳＤ、またはＨＤＤなどで構成される。ＤＲＡＭとＳＳＤの両方、または、ＤＲＡＭとＨＤＤの両方で構成されてもよい。メモリは、ＤＲＡＭ以外に、ＭＲＡＭやＦＲＡＭなど、他のメモリでも構わない。
【００２３】
ＫＶ処理部１０５は、いわゆるキーバリューストア処理を行う機能部である。キーバリューストア処理の形態の代表的な例を２つ示す。ここでは読み出し要求で与えられたキーに対する読み出しを例に動作を説明するが、書き込み要求で与えられたキーに対する書き込みの場合も同様にして行うことができる。一例として、図４に示すように、ハッシュ値とＫＶ記憶部１０３のデータ記憶領域上のアドレスとを対応づけるハッシュテーブルを用意する。この場合、ハッシュテーブルはＫＶ記憶部１０３の管理領域に記憶されている。指定されたキーに対するハッシュ値をハッシュ関数ｈ（）で計算し、計算されたハッシュ値に対応するアドレスをハッシュテーブルから取得する。取得したアドレスに基づき、データ記憶領域にアクセスして、キーバリューを読み出す。この方式によれば、高速なアクセスが可能になる。または、図５に示すように、キーとアドレスとを対応づけるキーテーブルを用意する。キーテーブルは、キーを辞書順に並べて管理するデータ構造を含む。指定されたキーに対するアドレスをキーテーブルから取得し、取得したアドレスに基づき、データ記憶領域にアクセスして、対応するキーバリューを読み出す。また、上述したキーを辞書順に並べて管理するデータ構造を有するため、指定されたキーの手前または後のキーに対するキーバリューの読み出しを要求するなどの読み出し要求にも応答することができる。ここでは、キーバリューストア処理の代表的な形態を２つ示したが、ここで述べた以外の形態も可能であり、本実施形態では、キーバリューストア処理自体の形態やアルゴリズムは限定しない。
【００２４】
分割キー生成部１０４は、要求バッファ部１０２で何バイトのデータがバッファリングされたかを監視している。分割キー生成部１０４は、要求バッファ部１０２のバッファリング状況に応じて、具体的に、バッファリングされているバリューのサイズ（またはキーバリューのサイズ）に応じて、要求バッファ部１０２からまだ取り出されていないバリューの部分データを先頭側から取り出す。例えばバリューの先頭から一定サイズに達するごとに、バリューの部分データを取り出す。バリューの部分データを取り出すことをバリュー分割と表現し、取り出した部分データは、分割バリューと呼ぶことがある。上述したように、書き込み要求のヘッダには、キーのサイズおよびバリューのサイズに関する情報が含まれている。したがって、ヘッダを利用することで、要求バッファにバッファリングされているデータから、キーおよびバリューのそれぞれの先頭位置を特定可能である。なお、前述したように、ヘッダ自身は、要求バッファ部１０２にバッファリングされてもかまわないし、別途のメモリ等の記憶装置に格納されてもよい。以下、書き込み要求に含まれていたキーを「元のキー」、書き込み要求に含まれていたバリューを「元のバリュー」と表現することがある。
【００２５】
分割キー生成部１０４は、元のキーを用いて、分割バリューに付与するキー（分割キーと呼ぶ）を生成する。より詳細には、元のバリューにおける当該分割バリューの位置に応じて分割キーを生成する。分割キー生成部１０４は、これら分割キーと分割バリュー（分割キーバリューと呼ぶ場合がある）を、ＫＶ処理部１０５に渡す。この際、元のバリューの全長に関する情報を含む付加情報を、ＫＶ処理部１０５に渡す。付加情報に分割バリューの長さに関する情報を含めてもよい。分割キー生成部１０４は、分割キーバリューをＫＶ処理部１０５に渡した時点で、分割バリューが格納されていたバッファ領域を開放し（ヘッダおよびキーが格納されていたバッファ領域も、当該バッファ領域に格納しておく必要がなくなった時点で開放してもよい）、バリューの残り部分の受信に備える。ただし、バッファを開放しても、要求内容（ヘッダに含まれていたバリューの全長サイズなど）と、元のキーは、後続するバリュー分割、および分割キーの生成に必要なので、要求バッファ部１０２内の任意または所定の領域、もしくは別途のメモリ等の記憶部に保持しておく。
【００２６】
この後、要求バッファ部１０２が、バリューのまだ受信されていない残り部分を段階的に受信し、バッファリングされたサイズに応じて、まだ読み出されていないバリューの部分データを先頭側から特定して、特定した部分データ（分割バリュー）を要求バッファ部１０２から取り出す。確保しておいたキーから２番目の分割バリューに対する分割キーを生成し、分割バリューと分割キー（分割キーバリュー）を、ＫＶ処理部１０５に渡す。なお、２番目以降の分割キーバリューについても、ヘッダに含まれていたバリューの全長に関する情報を含む付加情報をＫＶ処理部１０５に渡してもよい。また、付加情報には、該当する分割バリューの長さに関する情報を含めてもよい。
【００２７】
図６に、元のバリューを３つの部分（簡易的にそれぞれＶＡＬＵＥ１／３、ＶＡＬＵＥ２／３、ＶＡＬＵＥ３／３と表現する）に分割し、それぞれに元のキー（ＫＥＹ）から生成した分割キー（ＫＥＹ０、ＫＥＹ１、ＫＥＹ２）を付与する例を模式的に示す。この例では、元のバリューの先頭から一定サイズごとに分割している。
【００２８】
バリューの分割方法についてさらに詳細に説明する。上述したように、バリューの分割は、例えばバッファリングされたサイズが、元のバリューの先頭から一定サイズ（例えば４Ｋバイト）に達した段階で、そこでまでのバリューの部分データを取り出すことが考えられる。この場合、以降も、バッファリングされたデータが４Ｋバイトに達するごとに、４Ｋ分の部分データを取り出す。バリューの末尾に達した場合は、４Ｋバイト未満であっても、末尾を含むバリューを取り出す。
【００２９】
ここでは、バリューの分割サイズを、バリューの先頭から一定サイズごとにしたが、必ずしも一定サイズごとである必要はなく、分割キーの値から、分割バリューが、元のバリューの全体内のどのバイト位置かを一意に特定できる限り、可変長でもよい。例えば、分割ごとに分割サイズが異なってもよい。分割のサイズを可変長とする場合に、バッファリングの速度に応じて分割のサイズを変更することも可能である。例えばバッファリングの速度が速いほど、分割のサイズを大きくまたは小さくしてもよい。また分割の基準を、元のバリューの先頭を基準にするのではなく、元のキーの先頭を基準にしても良い。例えばキーバリューのキーの先頭からバイトをカウントし、一定サイズに達するごとに、バリューの分割を行っても良い。このように分割方法自体は、特定の方法に限定されるものではない。
【００３０】
ここで、分割キーの生成方法について説明する。分割キーは、元のキーを利用して生成する。例えば、キーが“ＡＢＣ”だった場合、最初に取得した分割バリューに対しては  “ＡＢＣ０”などと、識別子０を付加することで分割キーを生成する。２番目に取得した分割バリューに対しては、次の識別子１を付加して“ＡＢＣ１”などとして、分割キーを生成する。このように分割キーは、元のキーと、元のバリューの全体における各分割バリューの位置を特定する識別子を結合することで、生成できる。ここでは、識別子を、元のキーの末尾に結合させることで分割キーを生成したが、先頭に結合してもよいし、元のキーの文字列の途中に挿入してもよい。また結合する識別子は数字である必要はなく、アルファベットや他の記号でもよい。
【００３１】
上述した方法で、元キーに識別子を付加して分割キーを生成すると、そもそもそれと同一のキーの書き込み要求が外部から行われる可能性があり、これらが混同される可能性が生じる。例えば先程は“ＡＢＣ０”の例を示したが、クライアント装置からこれと全く同じ“ＡＢＣ０”というキーを指定した、キーバリューの書き込み要求が来る可能性がある。この場合でも、これらを識別できるようにする必要がある。そこで、分割キー生成部１０４は、必ず固定長の識別子を付加する方法を採用することで、この問題を解消可能である。例えば、固定長が１バイト長だとすると、“ＡＢＣ０”というキーを指定したキーバリューの書き込み要求をクライアント装置から受信した場合、分割キー生成部は、最初の分割キーとして、“ＡＢＣ００”のように、固定長の識別子０を元のキーの末尾に付加することで生成する。２番目の分割キーは、“ＡＢＣ０１”のように、同じく固定長の識別子１を元のキーの末尾に付加したものとする。付加する識別子をこのように固定長とし、かつ必ず付加することで、内部的には必ず最後の１バイトが識別子、それより前の部分が、元のキーとして識別でき、混同が発生しない。なお、識別子の個数をより多く確保できるように、識別子の桁数は１バイトより多い何桁でも良い。さらには、このような固定長の識別子を必ず付与する方式（固定長識別子方式）に限るものではなく、他のどのような方法でもよい。
【００３２】
ＫＶ処理部１０５は、分割キー生成部１０４から分割キーバリューと付加情報とを受け取り、付加情報からヘッダ情報を生成し、ヘッダ情報と分割キーバリューとを含むデータ構造体を生成して、ＫＶ記憶部１０３のデータ記憶領域の空き領域に書き込む。ヘッダ情報は、付加情報そのものでもよいし、付加情報から一部情報を抽出して生成してもよい。なお、ヘッダ情報の記憶は必須ではなく、ヘッダ情報を記憶しない場合は、分割キー生成部１０４は、当該ヘッダ情報をＫＶ処理部１０５に渡さない構成も可能である。
【００３３】
図７にＫＶ記憶部１０３への書き込みの例を示す。ヘッダ情報ＨＤＲ０と、分割キー“ＡＢＣ０”および１番目の分割バリュー（ＶＡＬＵＥ１／３）とを含むデータ構造体が、アドレスＰ１−１から格納されている。また、当該分割バリュー（ＶＡＬＵＥ１／３）の末尾アドレスの次のアドレスＰ１−２から、ヘッダ情報ＨＤＲ１と、分割キー“ＡＢＣ１”および２番目の分割バリュー（ＶＡＬＵＥ２／３）  とを含むデータ構造体が格納されている。また、分割バリュー（ＶＡＬＵＥ２／３）の末尾アドレスの次のアドレスＰ１−３から、ヘッダ情報ＨＤＲ２と、分割キー“ＡＢＣ２”および３番目の分割バリュー（ＶＡＬＵＥ３／３）とを含むデータ構造体が格納されている。
【００３４】
また、ＫＶ処理部１０５は、分割キーと、データ構造体が格納されたアドレスとの対応を、ＫＶ記憶部１０３の管理領域に保持されている対応情報に登録する。前述したように、キーバリューストア処理の方式は、前述したように、ハッシュを利用したものや、辞書に基づきキーテーブルを利用したものなど様々であるが、後者の場合の対応情報（キーテーブル）の例を、図８に示す。図７に示した書き込み例に対応して、分割キーとして、“ＡＢＣ０”、“ＡＢＣ１”、“ＡＢＣ２”が登録されている。また、分割キーに対応するデータ（データ構造体）が格納されたアドレスが“Ｐ１−１”、“Ｐ１−２”、“Ｐ１−３”として、対応情報に登録されている。
【００３５】
図７および図８に示した例では、ヘッダ情報が分割キーバリューと同じデータ記憶領域に記憶されていたが、ヘッダ情報をキーテーブル（対応情報）に登録してもかまわない。また、ヘッダ情報自体の登録を、いずれからも省略することも可能である。また、１番目の分割キーバリューに対してのみヘッダ情報（元のバリューの全長サイズ等）を保持し、２番目以降の分割キーバリューに対しては、ヘッダ情報の保持を省略する構成も可能である。
【００３６】
応答送信部１０６は、クライアント装置から受信した書き込み要求の実行が完了すると、書き込み完了応答を、クライアント装置に送信する。すなわち、分割キー生成部１０４による分割キーバリューの生成と、ＫＶ処理部１０５によるＫＶ記憶部１０３への分割キーバリューを含むデータ構造体の書き込みが繰り返し行われ、最終的に、書き込み要求されたバリューの末尾まで受信し、最後の分割キーバリューを含むデータ構造体を、ＫＶ記憶部１０３に書き込み終えた段階で、書き込み要求の実行が完了する。このとき、応答送信部１０６が、ＫＶ処理部１０５から書き込み要求の実行の完了通知を受けて、書き込み完了応答をクライアント装置に送信する。
【００３７】
以上は、元のバリューの全長が、分割サイズとして用いた固定長より長い場合を例に説明したが、もちろんその固定長より短いバリューを含む書き込み要求があった場合も、同様に対応可能である。その場合、バリューの分割は行われず、元のバリュー全体が、元のキーおよび付加情報（バリュー全長に関する情報など）と共に、ＫＶ処理部１０５に送られる。そして、これらに基づくデータ構造体がＫＶ記憶部１０３に書き込まれる。書き込みが完了すると、応答送信部１０６が応答をクライアント装置に送信する。ただし、上述した固定長識別子方式を用いる場合は、元のキーに、固定長の識別子を付与したキーを生成し、元のキーの代わりに、当該固定長の識別子を付与したキーを、ＫＶ処理部１０５に送る。
【００３８】
図９に、本実施形態の動作例のフローチャートを示す。まず、要求受信部１０１がクライアント装置から、キーバリューの書き込み要求を１つ以上のパケットを介して受信する（Ｓ１０１）。要求バッファ部１０２が、要求受信部１０１で受信される書き込み要求を、内部にバッファリングする（Ｓ１０２）。書き込み要求は、ヘッダと、キー（キーの実データ）と、バリュー（書き込みの対象データ）とを含む。ヘッダにはキーとバリューの長さに関する情報が含まれる。
【００３９】
分割キー生成部１０４は、要求バッファ部１０２のバッファリング状況、具体的には、バッファリングされているデータのサイズに応じて、要求バッファ部１０２からまだ取り出していないバリューの部分データを、バリューの先頭側から分割バリューとして取り出す。そして、書き込み要求に含まれていたキー（元のキー）に基づいて、分割バリューに対する分割キーを生成する（Ｓ１０３）ＫＶ処理部１０５は、分割キーと分割バリューとを含むデータ構造体を、ＫＶ記憶部１０３のデータ記憶領域に書き込む。データ構造体には、元のバリューの全長サイズおよび分割バリューのサイズの少なくとも一方などを含むヘッダ情報を含めてもよい。また、ＫＶ記憶部１０３の管理領域に存在する対応情報に、分割キー（またはそのハッシュ値）と、データ構造体を書き込んだアドレスとを登録する。なお、要求バッファ部１０２において分割バリュー等が格納されていたバッファ領域は解放してよい。
【００４０】
分割キー生成部１０４は、要求バッファ部１０２からバリューの末尾までの読み出しが完了したか、すなわち、取り出すべきバリュー部分がまだ存在するかを判断し、まだバリューの末尾まで読み出しが完了していない場合（すなわち取り出すべきバリュー部分が存在する場合）、ステップＳ１０３に戻る。バリューの末尾までの読み出しが完了した場合は、書き込み要求の実行が完了したと判断し、応答送信部１０６に完了信号を通知する。完了信号を受信した応答送信部１０６は、書き込み要求を送信したクライアント装置に、書き込み完了応答を送信する（Ｓ１０６）。
【００４１】
なお、本実施形態では、分割バリューごとにキー（分割キー）が付加されることから、従来の構成より、ＫＶ記憶部１０３のデータ記憶領域に記憶するキー（分割キー）の量が多くなる問題がある。その問題を軽減するため、ＫＶ記憶部１０３として、複数の異なるビットコストのストレージデバイス、例えばＤＲＡＭとＳＳＤ、または、ＳＳＤとＨＤＤなどを備えてもよい。一般に、ビットコストが高いストレージデバイスは、アクセス速度が高く、ビットコストが低いストレージコストは、アクセス速度が低い。そこで、一部の分割キーに関するデータ構造体は、ビットコストが高いもののアクセス速度が高いストレージデバイスに記憶し、残りの分割キーに関するデータ構造体は、アクセス速度が遅いがビットコストが低いストレージデバイスに記憶してもよい。
【００４２】
例えば識別子０の分割キー（１番目の分割キー）に関するデータ構造体は高速なストレージに保存し、それ以外の識別子の分割キー（２番目以降の分割キー）に関するデータ構造体は、低速だが安価なストレージに保存する。これによれば、（応答速度が要求される）分割されない小さなサイズのバリューに関するキーバリュー読み出し要求の応答速度は維持したまま、大きなキーバリューの記憶の際に増大する分割キーの記憶コストを低く抑えることが出来る。
【００４３】
また、ＫＶ処理部１０５がハッシュベースのキーバリューストア処理（図４参照）であった場合、識別子０の分割キー（１番目の分割キー）に関するエントリを記憶するハッシュテーブルは、例えば高速なＤＲＡＭ上に配置し、それ以外の識別子の分割キー（２番目以降の分割キー）に関するエントリを記憶するハッシュテーブルは、ＳＳＤに配置するなどしてもよい。ハッシュベースではなく、キーを辞書順に記憶するキーテーブル（図５参照）の場合も同様にして、テーブルの配置を、ＤＲＡＭとＳＳＤに分けることができる。
【００４４】
以上、本実施形態によれば、書き込み要求されたバリューのすべてをバッファリングすることなく、受信されるバリューを順次バッファリングしながら、バリューの先頭側から部分データを順次、分割バリューとして取り出す。そして、取り出した分割バリューに対して分割キーを生成し、分割キーに関連づけて、分割バリューを含むデータ構造体を、ＫＶ記憶部１０３に書き込む。これによれば、バリューの全データのバッファリングを待つ必要なく、バリューの書き込みが可能なため、要求バッファ部１０２のバッファサイズを小さく抑えることができる。
【００４５】
また、本実施形態によれば、分割キーバリュー単位で、複数の書き込み要求間で並列して動作を実行することが可能である。例えば、ある書き込み要求についてＮ（Ｎは１以上の整数）番目の分割キーに関するデータ構造体の書き込みが完了したら、別の書き込み要求に切り替えて動作し、また、元の書き込み要求に戻って、Ｎ＋１番目の分割キーに関するデータ構造体の書き込みを行うといったことも可能になる。よって、大きなサイズのバリューを指定した書き込み要求によって、他の書き込み要求の実行が大幅に待たせられることもなくなり、書き込み遅延を安定させることができる。
【００４６】
（変形例１）
上述した実施形態では、データ構造体内のヘッダ情報には、元のバリュー全体のサイズ情報または分割バリューのサイズ情報等を含める場合を示したが、当該データ構造体内の分割バリューに後続するデータが存在するか否か、すなわち、当該分割バリューが元のバリューの末尾を含むか否かの後続有無識別情報をさらに含めても良い。この場合、分割キー生成部１０４が、今回読み出した分割バリューに後続するデータが存在するか（今回読み出した分割バリューが元のバリューの末尾を含むか）を判断し、判断結果に応じた値を含む後続有無識別情報をＫＶ処理部１０５に渡す。ＫＶ処理部１０５は、ヘッダ情報に後続有無識別情報を含め、当該ヘッダ情報や分割バリュー等に基づき、データ構造体を生成する。この後続有無識別情報は、元のバリューの読み出し要求を受けた際の読み出し処理のときに利用することができる。
【００４７】
（変形例２）
変形例１では、ヘッダ情報に後続有無識別情報を含める場合を示したが、他の例として、要求バッファ部１０２から最初に読み出す分割バリュー、すなわち、元のバリューの先頭を含む分割バリューのデータ構造体内のヘッダ情報には、元のバリューの分割回数（あるいは読み出し回数）を表す情報を含めても良い。元のバリューの分割回数は、元のバリューのサイズ情報から計算可能である。例えば、分割の単位が元のバリューの先頭から一定サイズであれば、元のバリューのサイズを一定サイズで除算したときの除算値と剰余に基づき、剰余が０であれば、除算値、０より大きい場合は、除算値に１を加算した値を、分割回数と計算できる。なお、２番目以降に読み出す分割バリューについては、分割回数の情報をヘッダに含めなくても良い。この分割回数（読み出し回数）の情報は、元のバリューの読み出し要求を受けた際の読み出し処理のときに利用することができる。
【００４８】
（変形例３）
上述した実施形態では要求バッファ部１０２にバリューのバイト列がＴＣＰにしたがって、元のバリューの先頭から順番に格納されることを想定していたが、パケットの到着順に、受信パケット内のデータの元のバリュー内の位置に応じて、要求バッファ部１０２内の該当する位置に直接格納（それより前のデータが到着していなくても）してもよい。例えば、書き込み要求のヘッダから元のバリューのサイズを特定し、受信パケットのシーケンス番号等から受信パケットのデータの、元のバリュー内での相対位置を特定し、特定した位置に応じて要求バッファ部１０２にそのデータを格納してもよい。分割の単位が一定サイズに決まっており、バリューの先頭から一定サイズごとに分割するような場合、該当する一定サイズ分のデータが分割の単位でそろった時点で、それより先頭側のデータの読み出しが行われていなくても、そのそろったデータ（分割バリュー）を読み出して、後段の処理を行っても良い。分割キー生成部１０４では、読み出された分割バリューが先頭から何番目かに応じて、分割キーを生成すればよい。
【００４９】
（第２の実施形態）
第１の実施形態において、書き込み要求で要求された元バリューを複数の部分バリュー（分割バリュー）に分割し、ＫＶ記憶部１０３に段階的に、分割キーと分割バリューとを含むデータ構造体を書き込む行う場合に、途中でストレージ障害などでＫＶ記憶部１０３に書き込みが出来なくなる場合があり得る。その場合、単にクライアント装置に書き込みエラーの応答を返すだけだと、そこまで書き込んだデータ構造体がＫＶ記憶部１０３上に無駄なデータとして残ってしまう。本実施形態では、そのようなエラー処理にも適切に対処する形態を示す。
【００５０】
図１０に、第２の実施形態に係るデータ処理装置のブロック図を示す。第１の実施形態に係るデータ処理装置に、障害検知部１０９と削除分割キー生成部（削除処理部）１１０が追加されている。
【００５１】
障害検知部１０９は、ＫＶ記憶部１０３の障害を検知し、障害検知を削除分割キー生成部１１０に通知する。障害の検知方法は任意でよいが、例えばＫＶ処理部１０５がＫＶ記憶部１０３に対するデータ構造体の書き込み要求に対する応答を監視し、応答が返ってこない、またはエラー信号が返ってきた場合に障害を検知してもよい。または、ＫＶ記憶部１０３が、障害が発生した場合に障害発生を示す信号を出力するようにし、この信号を検知してもよい。またはＫＶ記憶部１０３の電源がオフになっていることを検出した場合に、障害が発生したと判断してもよい。
【００５２】
削除分割キー生成部１１０は、障害検知部１０９から障害検知の通知を受けた際に、それまでに該当の書き込み要求に関連して、ＫＶ記憶部１０３に書き込まれたデータ構造体を削除するための分割キーを生成する。分割キーの生成のために、分割キー生成部１０４から元のキーと、それまで行われたバリューの分割数に関する情報を取得し、元のキーから分割数分の分割キーを生成する。各分割キーを指定したデータ構造体の削除命令をＫＶ処理部１０５に渡す。ＫＶ処理部１０５は、それに従いＫＶ記憶部１０３からこれらの分割キーに該当するデータ構造体を削除する。ＫＶ処理部１０５は、削除が完了すると、応答送信部１０６にエラー通知を送り、応答送信部１０６は、書き込みエラーを示す応答をクライアント装置に送信する。
【００５３】
例えば、元のバリューが１０個の分割バリューに分割される場合に、最初の６個の分割リューのうちの１つを各々含む６個のデータ構造体の書き込み処理後に、障害検知部１０９が、ＫＶ記憶部１０３の障害を検知したとする。このとき、削除分割キー生成部１１０は、それまでの分割キー、例えば元のキーが“ＡＢＣ”で、識別子が固定長１バイトだったとすると、“ＡＢＣ０”から“ＡＢＣ５”までの６つの分割キーを生成し、これらを指定したデータ構造体の削除命令をＫＶ処理部１０５に渡す。ＫＶ処理部１０５は、それに従いＫＶ記憶部１０３からこれらの分割キーに該当するデータ構造体を削除する。ＫＶ処理部１０５は、削除が完了すると、応答送信部１０６にエラー通知を送り、応答送信部１０６は、書き込みエラーを示す応答を、クライアント装置に送信する。
【００５４】
上述した説明では、削除分割キー生成部１１０は、分割キー生成部１０４から元のキーと分割数に関する情報を取得して、分割キーを生成したが、分割キーを生成できる限り、別の方法を利用してもよい。例えば対象とする書き込み要求に関連してこれまで分割キー生成部からＫＶ処理部１０５に分割キーが送られた回数をカウントすることで、分割数に関する情報を取得してもよい。または、分割数に関する情報は利用せずに、元のキーから分割キーを１番目から順次生成して、ＫＶ処理部１０５に削除を指示し、該当する分割キーがないとの応答がＫＶ処理部１０５から返ってくるまで分割キーの生成を行っても良い。なお、分割キーの生成アルゴリズムは、削除分割キー生成部１１０と分割キー生成部１０４とで共通のものが事前に設定されているものとする。または、分割キー生成部１０４からＫＶ処理部１０５に送られる分割キーそのものを読み込んで蓄積し、障害検知の通知時には、対象とする書き込み要求に関連してこれまで蓄積した分割キーそのものを利用してもよい。この場合、書き込み要求の実行が完了したら、蓄積した分割キーは削除すればよい。
【００５５】
以上、本実施形態によれば、書き込み処理の最中にＫＶ記憶部１０３に障害が発生しても、そこまで書き込んでいたデータ構造体を正しく削除することが出来るようになり、障害発生時でも無駄なデータがＫＶ記憶部１０３に残骸として残る問題を解消できる。
【００５６】
（第３の実施形態）
図１１に、第３の実施形態に係るデータ処理装置のブロック図を示す。第１および第２の実施形態では、書き込み動作を実現するデータ処理装置を示したが、ここでは、読み出し動作を実現するデータ処理装置を示す。
【００５７】
データ処理装置は、キー（第１キー）を含む、キーバリューまたはバリュー（第１データ）の読み出し要求を受信する要求受信部２０１と、受信した読み出し要求を一時的にバッファリングする要求バッファ部２０２と、要求バッファ部１０２から取り出した読み出し要求で指定されたキー（元のキー）から分割キーを生成する分割キー生成部２０３と、データ（データ構造体、テーブル等）を記憶するＫＶ記憶部２０５と、分割キーに応じたバリュー（元のバリューが分割されている場合は分割バリュー）をＫＶ記憶部２０５から読み出すＫＶ処理部２０４と、後続する分割バリューが存在するか（すなわち、元のバリューの末尾を含む分割バリューを読み出したか）を判定する継続判断部（判断部）２０６と、ＫＶ処理部２０４で読み出したバリュー（元のバリューが分割されている場合は、分割バリュー）に基づき、応答を送信する応答送信部２０７と、を備える。
【００５８】
なお、ＫＶ記憶部２０５は、図３等のデータ処理装置の書き込み機能で書き込んだＫＶ記憶部１０３と同じでものでもよい。図１１では、ＫＶ記憶部２０５が、データ処理装置の内部に配置されているが、図２のＫＶ記憶装置のように、内部バスまたはネットワークを介して、ＫＶ記憶部２０７が外部から接続されてもよい。以下、データ処理装置の各部についてさらに詳細に説明する。
【００５９】
要求受信部２０１は、イーサネット等のネットワーク越しに、クライアント装置からキーバリューの読み出し要求を受信する。読み出し要求のメッセージにはヘッダおよびキー（元のキー）等が含まれ、元のキーに対応するバリューの読み出しが要求される。ヘッダには、読み出し要求である要求種別の識別子が含まれ、送信元の識別子等が含まれてもよい。書き込み要求は、例えばＴＣＰ／ＩＰまたはＵＤＰ／ＩＰなどの通信プロトコル上のメッセージとして構成され、例えばｍｅｍｃａｃｈｅｄなどのプロトコルに従ったメッセージとして構成される。
【００６０】
要求バッファ部２０２は、要求受信部２０１で受信された読み出し要求を一旦バッファリングする。少なくとも読み出し要求に含まれるキーをバッファリングする。ヘッダは、要求バッファ部２０２とは別の記憶装置（メモリ等）に格納する構成も可能である。この場合、キーとヘッダの対応が取れるようにしておく。
【００６１】
ＫＶ記憶部２０５は、揮発性または不揮発性のメモリ、ストレージ、またはこれらの両方によって構成される記憶デバイスである。例えばＤＲＡＭ、ＳＳＤ、またはＨＤＤなどで構成される。ＤＲＡＭとＳＳＤの両方、または、ＤＲＡＭとＨＤＤの両方で構成されてもよい。メモリは、ＤＲＡＭ以外に、ＭＲＡＭやＦＲＡＭなど、他のメモリでも構わない。
【００６２】
ＫＶ処理部２０４は、いわゆるキーバリューストア処理（ここでは読み出し機能に関する処理）を行う機能部である。第１の実施形態と同様、ハッシュテーブルを利用したハッシュベースの形態や、辞書順にキーを並べて管理するデータ構造を有するキーテーブルを利用する形態などがある。動作の詳細は、第１の実施形態で述べたため省略する。
【００６３】
分割キー生成部２０３は、要求バッファ部２０２から取り出した読み出し要求で指定されたキー（元のキー）から分割キー（第２キー）を生成する。より詳細には、当該分割キーで読み出そうとする分割バリューの元のバリュー内での位置に応じて、あるいは、読み出し回数（最初は１）に応じて、分割キーを生成する。ＫＶ処理部２０４にその分割キーを指定して、バリュー（分割されている場合は分割バリュー）の読み出し要求を行う。分割キー生成部２０３は、書き込み機能を有するデータ処理装置の分割キー生成部１０４と同様の分割キー生成アルゴリズムを搭載し、当該アルゴリズムに従って分割キーを生成する。
【００６４】
例えば、分割キーの生成アルゴリズムが第１の実施の形態と同様の方式だとすると、最初は、元のキーに識別子０を付加した分割キーを生成し、ＫＶ処理部２０４に、その分割キーを指定してバリュー（第２データ）の読み出し要求を行う。例えばキー“ＡＢＣ”の場合は“ＡＢＣ０”といった分割キーを生成する。ＫＶ処理部２０４は、ＫＶ記憶部２０５からこの分割キーに対応づけられたデータ構造体を読み出し、データ構造体からバリュー（分割されている場合は分割バリュー）を取り出し、更に併せてデータ構造体内のヘッダ情報に記憶されている元のバリュー全長も併せて取り出す。元のバリューの全長は、この分割キーに対応するバリューが分割バリューであった場合は、分割前のバリュー（元のバリュー）の全長である。
【００６５】
継続判断部２０６は、ＫＶ処理部２０４で取得された元のバリュー全長から、ＫＶ記憶部２０５から読み出したバリュー（または分割バリュー）に、後続する分割バリューが存在するか（すなわち当該バリュー（または分割バリュー）が元のバリューの末尾を含んでいるか）を判断する。後続する分割バリューが存在すると判断した場合、分割キー生成部２０３に、次の分割キーを生成するように指示する。
【００６６】
例えば分割バリューの長さが最大４ＫＢ（元の末尾を含む分割バリューが４ＫＢ以下、それ以外は４ＫＢ）であり、元のバリュー全長が１１ＫＢの場合、現在の分割キーの識別子が０であったとすると、ここまで読み出したバリューの最大長は４ＫＢ×（０＋１）＝４ＫＢであり、これが１１ＫＢより小さいので、後続するバリューが存在する（読み出しを継続すべき）と判断する。なお、括弧の中の左側の数字（ここでは０）は、前回までの読み出し回数、右側の数字は今回の読み出しを、前回までの読み出し回数に加算する値（１）である。
【００６７】
指示された分割キー生成部２０３は、この場合は、次の識別子１を付加した分割キー“ＡＢＣ１”を生成して、ＫＶ処理部２０４に渡す。同様に、分割キー“ＡＢＣ１”に対応するバリューが読み出される。ここまで読み出したバリューの最大長は４ＫＢ×（１＋１）＝８ＫＢ、これが１１ＫＢより小さいので、後続するバリューが存在する（読み出しを継続すべき）と判断する。継続判断部２０６は、分割キー“ＡＢＣ２”に対応する分割バリューが読み出された時点で、ここまでのバリューの最大長は４ＫＢ×（２＋１）＝１２ＫＢとなり、これは１１ＫＢ以上なので、これ以上、読み出しは継続しないと判断する。なお、データ構造体内のヘッダに、分割バリューのサイズ情報が含まれている場合は、これまで読み出した分割バリューのサイズ情報と、元のバリュー全長から、継続すべきかを判断してもよい。
【００６８】
応答送信部２０７は、分割バリューが読み出される都度、それを含む応答メッセージを送信する。応答メッセージがヘッダを備える構成の場合は、最初の分割バリューの送信ときのみ、応答メッセージのヘッダを生成して、ヘッダと、その後に最初に読み出したバリューと続けて含めるように、応答メッセージを送信する。なお、応答メッセージは、応答送信部２０７内の送信バッファを介して、パケット送信される。送信バッファは、応答送信部２０７内に設けられ、送信するデータを一時的に格納するバッファである。ここで、ヘッダには、応答するバリュー（元のバリュー）の全長を含める。ヘッダに続けて、読み出し要求に含まれていたキーを含めてもよい。最初の分割バリューを読み出す際に、元のバリューの全長がヘッダ情報として併せて読み出されるため、このヘッダ情報から、元のバリューの全長を取得する。
【００６９】
後続する分割バリューについては、読み出される都度、その分割バリューをそのまま内部の送信バッファを介してパケット送信し、その都度、送信バッファは開放する。クライアント装置は、応答メッセージを受信し、そこに含まれるバリュー全長の情報から、バリュー全長を把握する。クライアント装置は、受信した分割バリューの合計が、把握したバリュー全長に達するまで、バリューデータの到来を待機する。データ処理装置からは、分割バリューを一つずつ順次応答していく動作になるが、そもそもバリュー全体を一度に送信したとしても、ネットワーク上ではデータが、例えば１．５ＫＢなどのＴＣＰ／ＩＰパケット毎に分割されて送信されるので、クライアント装置から見て、基本的にこれらの動作の違いは明示的には判別が出来ない。このため、クライアント装置が要求したバリューが、データ処理装置内部で分割されて送信されていることは、クライアント装置には隠ぺいされる。
【００７０】
なお、継続判断部２０６は、後続する分割バリューがあと何個あるかが分かるため、毎回読み出し終わってから、次の分割バリューの読み出しを一つずつ指示するのではなく、例えば最初の分割バリューが読み出されたた際に、残りの１つまたは複数の分割バリューの読み出し指示を一度に行うようにしてもよい。これにより、読み出しのスループットを向上させることができる。
【００７１】
図１２に、本実施形態の動作例のフローチャートを示す。まず、要求受信部２０１がクライアント装置から、キーの読み出し要求を受信し、受信された読み出し要求を、要求バッファ部２０２にバッファリングする（Ｓ２０１）。読み出し要求には、例えばヘッダと、キー（第１キー）が含まれる。
【００７２】
分割キー生成部２０３は、要求バッファ部２０２にバッファリングされている読み出し要求を取り出し、読み出し要求に含まれているキーを特定する（Ｓ２０２）。分割キー生成部２０３は、特定したキーから分割キー（第２キー）を生成する（Ｓ２０３）。分割キー生成部２０３は、分割キーに対応する分割バリュー等を含むデータ構造体の読み出しを、ＫＶ処理部２０４に指示する。ＫＶ処理部２０４は、分割キーに対応するデータ構造体をデータ記憶部２０５から読み出し、データ構造体から分割バリューを取り出す（Ｓ２０４）。１回目の分割キーに対する読み出しでは、データ構造体からさらにヘッダ情報に含まれるバリュー全長の情報を取得してもよい。応答送信部２０７は、１回目に読み出した分割バリューについては、例えばヘッダ（バリューの全長等を含む）と、キー（読み出し要求で指定されたものと同じ）と、分割バリューとを含む応答メッセージを生成して、内部の送信バッファを介して、送信する（Ｓ２０５）。２回目以降に読み出した分割バリューについては、当該分割バリューのデータを、そのままパケットで、内部の送信バッファを介して送信する（Ｓ２０５）。応答メッセージまたは分割バリューの送信後、当該送信バッファを開放してよい。
【００７３】
継続判断部２０６は、後続して読み出すべき分割バリューが存在するかを判断し（Ｓ２０６）、そのような分割バリューが存在する場合は、次の分割キーの生成を、分割キー生成部１０４に指示する（Ｓ２０３）。一方、そのような分割バリューが存在しない場合は、クライアント装置が要求したバリューデータをすべて送信済みのため、本フローの処理を終了する。
【００７４】
以上、本実施形態によれば、分割されて記憶されたバリュー（分割バリュー）を正しく読み出すことができ、さらにクライアント装置に対して分割していることを隠ぺいして、元のバリューを一度で応答しているように見せることが出来る。また、分割バリューの送信毎に、応答送信部２０７内の送信バッファを開放することが出来るので、一度にバリュー全体を送信バッファに読み出してから送信する場合に比べて、バッファ容量を削減することが出来る。
【００７５】
また、本実施形態によれば、読み出しの単位（分割キーの単位）で、複数の読み出し要求間で並列して動作を実行することが可能である。例えば、ある読み出し要求についてＮ（Ｎは１以上の整数）番目の分割キーに対する読み出しが完了したら、別の読み出し要求に切り替えて動作し、また、元の読み出し要求に戻って、Ｎ＋１番目の分割キーに対する読み出しを行うといったことも可能になる。よって、大きなサイズのバリューを指定した読み出し要求によって、他の読み出し要求の実行が大幅に待たせられることもなくなり、読み出し遅延を安定させることができる。
【００７６】
（変形例１）
上述した実施形態では、継続判断部２０６は、元のバリュー全長と、これまで読み出した分割バリューのサイズに基づき、後続の分割バリューが存在するか（元のバリューの末尾を含む分割バリューを読み出したか）を判断した。別の方法として、第１の実施形態の変形例１で述べたように、書き込み動作時にデータ構造体内のヘッダに後続有無識別情報を追加し、読み出し動作時に、この後続有無識別情報を利用することも可能である。具体的に、ＫＶ記憶部から読み出したデータ構造体内のヘッダから後続有無識別情報を特定し、この値、後続有りを示すときは、後続の分割バリューが存在する（元のバリューの末尾を含む分割バリューはまだ読み出していない）と判断する。一方、後続無を示すときは、後続の分割バリューが存在しない（元のバリューの末尾を含む分割バリューは読み出し済み）と判断する。
【００７７】
（変形例２）
後続有無識別情報を利用する以外の方法として、第１の実施形態の変形例２で述べたように、書き込み時にデータ構造体内のヘッダ、より詳細には、元のバリューの先頭を含む分割バリューを格納するデータ構造体内のヘッダに、分割回数（読み出し回数）を追加し、読み出し時に、この分割回数（読み出し回数）を利用することも可能である。具体的に、ＫＶ記憶部から最初に読み出したデータ構造体内のヘッダから分割回数（読み出し回数）を特定し、この値の回数だけ、分割バリューの読み出しを行った場合に、後続の分割バリューが存在しない（元のバリューの末尾を含む分割バリューは読み出し済み）と判断する。
【００７８】
（第４の実施形態）
第３の実施形態では、読み出し要求に対して含まれるキーから生成される複数の分割キーが、それぞれ順番に処理されているとき、途中でＫＶ記憶部におけるストレージ障害などで、読み出しが出来なくなる場合があり得る。そのような場合でも適切にエラー処理を行う形態を示す。
【００７９】
図１３に、第４の実施形態に係るデータ処理装置のブロック図を示す。第３の実施形態と同様、ここでも、読み出し動作を実現するデータ処理装置を示す。
【００８０】
図１１に示した第３の実施形態に比べ、ＫＶ記憶部２０５の障害を検知する障害検知部２０８、通信コネクションを切断する通信切断部２０９を新たに備える。図１１と同一名称の要素には、同一の符号を付して、拡張または変更された処理を除き、重複する説明を省略する。なお、図１１と異なり要求バッファ部は存在しないが、図１１と同様に要求受信部２０１の後段に要求バッファを追加してもよい。
【００８１】
障害検知部２０８は、ＫＶ記憶部２０５の障害を検知し、障害検知を通信切断部２０９に通知する。障害の検知方法は任意でよいが、例えばＫＶ処理部２０４がＫＶ記憶部２０５に対する読み出しの指示に対する応答を監視し、応答が返ってこない、またはエラー信号が返ってきた場合に障害を検知してもよい。または、ＫＶ記憶部２０５が、障害が発生した場合に障害発生を示す信号を出力するようにし、この信号を検知してもよい。またはＫＶ記憶部２０５の電源がオフになっていることを検出した場合に、障害が発生したと判断してもよい。
【００８２】
通信切断部２０９は、障害検知部１０９から障害検知の通知を受けると、キーバリュー読み出し要求とそれに対する応答を送受している通信コネクション（ＴＣＰコネクションでもよいし、ＴＣＰより上位層のアプリケーションレベルでのコネクションでもよい）を切断する。
【００８３】
例えば、読み出すべきバリュー（元のバリュー）が１０個に分割されている場合で、最初の６個の分割バリューを読み出した後に、障害検知部２０８が、ＫＶ記憶部２０５のストレージ障害を検知したとする。この時点で、この６個の分割バリューは、クライアント装置に送信済みであり、さらには最初の分割バリューの送信で併せて送信したヘッダ内で元のバリュー全長を通知している。このため、送信される分割バリューの合計長が、そのバリュー全長になるまで、クライアント装置は、残りの４個の分割バリューを待っている。しかしながら、データ処理装置は、障害により、その４個の分割バリューを送信できない。通信切断部２０９は、障害検知部２０８から障害検知の通知を受けると、キーバリュー読み出し要求とそれに対する応答を送受している通信コネクション（ＴＣＰコネクションでもよいし、ＴＣＰより上位層のアプリケーションレベルでのコネクションでもよい）を切断する。通信コネクションを切断すると、クライアント装置は、当該コネクションで何らかの異常が行ったことを知ることができ、残りのバリューを待っている状態から抜け出すことが出来る。
【００８４】
図１４に、第４の実施形態に係るデータ処理装置の他の例のブロック図を示す。図１３の通信切断部２０９が、ダミーデータ生成部２１０に置き換わっている。
【００８５】
ダミーデータ生成部２１０は、障害検知部２０８で障害が検知された際に、障害により読み出せないこととなった、残りの１つまたは複数の分割バリューの合計に相当するサイズのダミーデータを生成する。応答送信部２０８は、残りの分割バリューの代わりに、ダミーデータを送信する。その後に、応答送信部２０８は、引き続き、読み出しエラーをクライアント装置に通知する。
【００８６】
ダミーデータを送信する理由を以下に述べる。最初の分割バリューの送信の際に併せて通知したバリュー全長分のデータを送らないと、クライアント装置は通信コネクションを切断せず、次の動作に移行できない。そこで、本実施形態では、障害検知後、残りの分割バリュー分のダミーデータを送信することで、最初に通知したバリューの長さ分のデータを返す。そして、その後に応答送信部が読み出しエラーをクライアント装置に通知する。これによりクライアント装置は、残りのバリューを待っている状態から抜け出すことが出来る。また、受信したデータが正しくないと判断して、破棄することができる。
【００８７】
尚、各実施形態のデータ処理装置は、例えば、汎用のコンピュータ装置を基本ハードウェアとして用いることでも実現可能である。すなわち、上記のコンピュータ装置に搭載されたプロセッサにプログラムを実行させることにより実現出来る。このとき、データ処理装置は、上記のプログラムをコンピュータ装置にあらかじめインストールすることで実現することや、各種の記憶媒体に記憶、あるいはネットワークを介して上記のプログラムを配布、このプログラムをコンピュータ装置に適宜インストールすることで実現が出来る。また、データ処理装置内の各記憶部は、上記のコンピュータ装置に内蔵あるいは外付けされたメモリ、ハードディスクもしくはＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ−ＲＡＭ、ＤＶＤ−Ｒなどの記憶媒体などを適宜利用して実現することができる。
【００８８】
本発明は上記実施形態そのままに限定されず、実施段階では要旨を逸脱しない範囲で構成要素を変形し具体化出来る。上記実施形態に開示されている複数の構成要素の適宜な組み合わせで、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除出来、異なる実施形態に渡る要素を適宜組み合わせることも出来る。
【符号の説明】
【００８９】
２１〜２３：クライアント装置
１１：データ処理装置
３１：ＫＶ記憶装置
１０１：要求受信部
１０２：要求バッファ部
１０３；ＫＶ記憶部
１０４：分割キー生成部
１０５：ＫＶ処理部
１０６：応答送信部
１０９：障害検知部
１１０：削除分割キー生成部
２０１：要求受信部
２０２：要求バッファ部２０２
２０３：分割キー生成部
２０４：ＫＶ処理部
２０５；ＫＶ記憶部
２０６：継続判断部
２０７：応答送信部
２０８：障害検知部
２０９：通信切断部
２１０：ダミーデータ生成部
【図１】
0006378044.tif 000002
【図２】
0006378044.tif 000003
【図３】
0006378044.tif 000004
【図４】
0006378044.tif 000005
【図５】
0006378044.tif 000006
【図６】
0006378044.tif 000007
【図７】
0006378044.tif 000008
【図８】
0006378044.tif 000009
【図９】
0006378044.tif 000010
【図１０】
0006378044.tif 000011
【図１１】
0006378044.tif 000012
【図１２】
0006378044.tif 000013
【図１３】
0006378044.tif 000014
【図１４】
0006378044.tif 000015