JP6378044B2 - データ処理装置、データ処理方法およびプログラム - Google Patents

データ処理装置、データ処理方法およびプログラム Download PDF

Info

Publication number
JP6378044B2
JP6378044B2 JP2014223490A JP2014223490A JP6378044B2 JP 6378044 B2 JP6378044 B2 JP 6378044B2 JP 2014223490 A JP2014223490 A JP 2014223490A JP 2014223490 A JP2014223490 A JP 2014223490A JP 6378044 B2 JP6378044 B2 JP 6378044B2
Authority
JP
Japan
Prior art keywords
data
key
unit
value
read
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2014223490A
Other languages
English (en)
Other versions
JP2016091222A (ja
Inventor
田中 信吾
信吾 田中
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Kioxia Corp
Original Assignee
Toshiba Memory Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Toshiba Memory Corp filed Critical Toshiba Memory Corp
Priority to JP2014223490A priority Critical patent/JP6378044B2/ja
Priority to US14/847,589 priority patent/US10185783B2/en
Publication of JP2016091222A publication Critical patent/JP2016091222A/ja
Application granted granted Critical
Publication of JP6378044B2 publication Critical patent/JP6378044B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90Details of database functions independent of the retrieved data types
    • G06F16/901Indexing; Data structures therefor; Storage structures
    • G06F16/9014Indexing; Data structures therefor; Storage structures hash tables
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • G06F16/13File access structures, e.g. distributed indices

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Description

本発明の実施形態は、データ処理装置、データ処理方法およびプログラムに関する。
近年、Webメールやソーシャルネットワークなどに代表される高度なWebサービスが急速に普及している。このようなWebサービスでは、WebサーバがユーザからのWebページ表示要求を受けると、Webサーバは必要な個々のテキスト、画像や動画などのデータを、逐一バックエンドのストレージに問い合わせて取得し、ユーザに応答する。このようなストレージとしては、従来からのファイルシステムベースのデータベースも使われているが、近年では、一意のURLを指定してコンテンツデータにアクセスするという、インターネット上のコンテンツアクセス方式と親和性の高いオブジェクトストレージが、活用され始めている。このようなオブジェクトストレージでは、Webサーバといったクライアント装置から、イーサネット越しに可変長の一意のKey(キー)で、可変長のValue(バリュー)にアクセスするというキーバリューストア型のI/Fがとられている。Webサーバの場合、キーはURL、バリューはコンテンツデータであることが一般的である。キーに関して、オブジェクトIDが可変長でなく、固定長になるものもあるが、基本的な原理等は同様である。システムとしては、Ceph、Openstackなどがフリーソフトウェアとして有名である。また、ストレージデバイスとしてはHDDやSSDが用いられる。
HDDやSSDはランダム書き込み性能が悪いため、KVS(Key−Value Store:キーバリューストア)処理と組み合わせて使われる場合は、ログ形式書き込みという手法がよく使われる。ログ形式書き込みでは、書き込むべきキーとバリューの組(以下、キーバリューと記述する)は、書き込み要求を受け取った順にストレージアドレス上にシーケンシャルに書き込まれる。ハッシュテーブルを用いたKVS処理の場合は、ハッシュテーブルの各エントリに、キーバリューが書き込まれた先頭アドレスが保存される。同じキーに対する別のキーバリューの書き込みがあった場合は、後に書き込まれた方のアドレスが保存され、後に書き込まれた方が使われる。前に書き込まれたキーバリュー(あるいは意図的に削除されたキーバリュー)は、バックグラウンドで実行されるガーベジコレクションによって、アドレス上の後続するデータで上書きされ(後続するデータが、当該キーバリューが存在していたアドレスに詰められ)、その分空き領域が増加する。
ログ書き込み形式の性質上、あるキーバリューの書き込みの途中で、他のキーバリューの書き込みに移行できない。このため、書き込んでいるキーバリューは、必ず最後まで書き込み終わる必要がある。よって、書き込むキーバリューを、イーサネット等のネットワークから受け取る場合、特にそのキーバリューが複数のパケットに分割されている場合には、キーバリューを構成するすべてのパケットを完全に受信し終わってからでないと、ストレージへの書き込みを開始できない。なぜなら、ネットワーク障害やクライアント装置側の障害によって、途中でキーバリューの受信が止まる可能性があるためである。また、ネットワークは複数の通信コネクション(TCPコネクション等)によってシェアされており、1つまたは複数のクライアント装置から、複数のキーバリューを同時に受信している場合もある。その場合、単一の通信コネクションが占有している帯域は、ネットワーク帯域全体の一部に過ぎないため、受信と書き込みを同時に行ってしまうと、書き込み速度が、その占有している一部のネットワーク帯域の速度によって制約されてしまう。よって、ストレージ性能をより効率よく活用するという意味でも、完全にキーバリューを受信し終わってから、キーバリューを一気に書き込みを行った方が良い。
以上のように、キーバリューを完全に受信し終わってから、ストレージに書き込むように動作する場合、大きなサイズの受信バッファを用意する必要が生じる。例えば大規模データセンターなどを想定して1000台のクライアント装置(Webサーバ等)からのアクセスが発生するとする。各クライアント装置が例えば2ソケット(2CPU)で構成され、各CPUが12物理コアを備えたとすると、バーチャルスレッディングでCPUあたり24スレッド、クライアント装置あたり48スレッド、全クライアント装置のスレッド数は48,000スレッドになる。この各スレッドと通信コネクションを張ったとして、これらの通信コネクションから1MBのデータを例えば同時に受信することを想定すると、1MBの平均0.5MB×48000コネクション=24GBもの受信バッファが必要になる。これはあくまで同時にデータを受信している場合であり、実環境では稀なケースになる可能性はあるものの、メモリとしてはこのようなワーストケースにも対応しておくという設計もありうる。
また、バッファメモリを固定的に確保する方式だと、すべてのコネクションに最大データサイズ分のバッファを確保する必要があり、例えばそれが1MBだとすると、上記の2倍の48GB必要となる。また、受信後にストレージに書き込んでいる間、次の受信を例えばダブルバッファで同時に受け付けるようにすると、さらにこの2倍の96GBの容量が必要になる。
KVS処理は基礎的な機能のため、例えばこれを専用ハードウェアロジックで実装する場合も有り得る。ハードウェアロジックは動的なメモリ確保があまり得意ではないため、上記のような固定的なメモリ確保を行う場合があり、さらに性能を追求するために上記ダブルバッファ構成とする場合がある。このため、上記の96GBという容量は、このような場合に現実として起こりうる。通常このようなバッファはDRAMで実装されることから、これは無視できないコストアップとなる。
米国出願公開第2011/0276744号明細書
本発明の実施形態は、バッファサイズを小さく抑えることを目的とする。
本発明の実施形態としてのデータ処理装置は、要求受信部と、バッファ部と、キー生成部と、処理部とを備える。前記要求受信部は、第1キーと第1データとを含む書き込み要求を受信する。前記バッファ部は、前記書き込み要求に含まれる前記第1データを一時的にバッファリングする。前記キー生成部は、前記バッファ部における前記第1データのバッファリング状況に応じて、前記バッファ部にバッファリングされている前記第1データのうちまだ読み出していない一部データである第2データを読み出し、前記第1データにおける前記第2データの位置に応じた第2キーを、前記第1キーに基づき生成する。前記処理部は、前記第2データを含むデータ構造体を、前記第2キーに関連づけて、内部または外部の記憶装置に書き込む。
本発明の実施形態に係るデータ処理システムを示す図。 本発明の実施形態に係るデータ処理システムの他の例を示す図。 本発明の第1の実施の形態に係るデータ処理装置を示す図。 ハッシュテーブルの例を示す図。 キーテーブルの例を示す図。 元のバリューを3つの部分に分割し、それぞれに元のキーから生成した分割キーを付与する例を模式的に示す図。 KV記憶部への書き込みの例を示す図。 キーテーブルの例を示す図。 第1の実施形態の動作例のフローチャート。 第2の実施形態に係るデータ処理装置のブロック図。 第3の実施形態に係るデータ処理装置のブロック図。 第3の実施形態の動作例のフローチャート。 第4の実施形態に係るデータ処理装置のブロック図。 第4の実施形態に係るデータ処理装置の他の例のブロック図。
以下、図面を参照しながら、本発明の実施形態について説明する。
図1は、本発明の実施形態に係るデータ処理システムを示す。データ処理システムは、データ処理装置11と、複数のクライアント装置21〜23を備えている。データ処理装置11は、KV(Key Value:キーバリュー)記憶装置31を備えている。
データ処理装置11は、イーサネットなどのネットワーク越しに、クライアント装置21、22、23からのキーバリューの書き込み要求を受け付けるキーバリューストア装置である。クライアント装置21〜23は、例えばWebサーバ等のサーバであり、Webサーバの場合、一例として、URLをキー、Webページ等のコンテンツデータをバリューとして、キーとバリュー(キーバリュー)の書き込み要求をデータ処理装置11に行う。クライアント装置21〜23は、インターネット等のネットワークを介してユーザ端末と接続されており、例えば、ユーザ端末からのURLの指定と、Webページデータ(コンテンツデータ)の書き込み指示を受けて、キーバリューの書き込み要求を生成して、データ処理装置11に送る。ユーザ端末は、Webサーバの管理者用の端末でもよい。データ処理装置11は、キーバリューの書き込み要求を受けると、後述する第1または第2の実施形態に従った書き込み処理をKV記憶装置31に行う。書き込みが完了すると、書き込み完了の応答をクライアント装置21〜23に返す。
また、クライアント装置21〜23は、ユーザ端末から、キーとしてURLを指定したWebページの閲覧要求を受けると、キーを指定した、キーバリューの読み出し要求を生成してデータ処理装置11に送る。データ処理装置11は、クライアント装置21〜23からの読み出し要求を受けて、指定されたキーに基づき、KV記憶装置31から後述する第3または第4の実施形態に従って読み出し処理を行い、応答をクライアント装置21〜23に返す。
図1ではKV記憶装置がデータ処理装置11の内部に配置されていたが、図2に示すように、KV記憶装置31が、データ処理装置11に内部バスを介して外付けされてもよい。または、イーサネット等のネットワークを介して、KV記憶装置31が、データ処理装置11に接続されていてもよい。
データ処理装置11は、典型的な形態としては、CPU、メモリ、ストレージ、ネットワークインタフェースなどで構成される。一部の機能がFPGAやASICなどの専用ハードウェアによって実現されていてもよい。データ処理装置11は、書き込み機能と読み出し機能の両方を備えていたが、いずれか一方のみの機能を備えていてもよい。
(第1の実施形態)
図3は、本発明の第1の実施の形態に係るデータ処理装置を示す。図3のデータ処理装置は、図1または図2に示したデータ処理装置11が備える書き込みおよび読み出しの機能のうち書き込み機能に係わる構成を備えたデータ処理装置である。読み出し機能に係わる構成を備えたデータ処理装置については、後述する実施形態で説明する。本明細書で開示する各実施形態を組み合わせることで、図1または図2に示したデータ処理装置11のように、書き込み機能と読み出し機能の両方に係わる構成を備えたデータ処理装置も実施可能である。
図3に示すように、データ処理装置は、キー(第1キー)とバリュー(第1データ)を含む、キーバリューの書き込み要求を受信する要求受信部101と、受信した書き込み要求を一時的にバッファリングする要求バッファ部(バッファ部)102と、要求バッファ部102からバリューの部分データを分割バリュー(第2データ)として取り出し、分割バリューに対するキーである分割キー(第2キー)を生成する分割キー生成部(キー生成部)104と、データを記憶するKV記憶部(記憶装置)103と、分割キーと分割バリューとを含むデータ構造体をKV記憶部103に書き込み、分割キーとデータ構造体の書き込みアドレスとを対応情報に設定するKV処理部(処理部)105と、書き込み要求の完了応答を送信する応答送信部106を備える。図3では、KV記憶部103が、データ処理装置の内部に配置されているが、図2のKV記憶装置のように、内部バスまたはネットワークを介して、KV記憶部103が外部から接続されてもよい。以下、データ処理装置の各部についてさらに詳細に説明する。
要求受信部101は、イーサネット等のネットワーク越しに、クライアント装置からキーバリューの書き込み要求を受信する。書き込み要求には、ヘッダと、キー(第1キー)と、書き込みの対象データであるバリュー(第1データ)とが含まれる。ヘッダには、書き込み要求である要求種別の識別子と、キーとバリューのそれぞれの長さに関する情報が含まれている。書き込み要求は、書き込み要求に含まれるキーバリュー(もしくはバリュー)を書き込むことを要求する。書き込み要求は、例えばTCP/IPまたはUDP/IPなどの通信プロトコル上のメッセージとして構成され、例えばmemcachedなどのプロトコルに従ったメッセージとして構成される。書き込み要求は、1つまたは複数のパケットにより、送受される。
要求バッファ部102は、要求受信部101で受信された書き込み要求を一旦バッファリングする。より詳細には、書き込み要求のメッセージは、前述のように1つまたは複数のパケットに分割されて、順次送られてくるため、書き込み要求のバッファリングは、段階的に行われることになる。書き込み要求の構成は、その先頭側から、ヘッダ、キー、バリューの順で配置されているため、バッファリングもこの順序で行われる。パケットの到着順が必ずしも順番通りになるとは限らないが、TCPにより順序制御されて、上記の順番で要求バッファ部102に格納される。すなわち、ヘッダ、キー、バリューのバイト列がこの順で、それぞれ先頭から順番に格納される。なお、ヘッダを、要求バッファ部102とは別の記憶装置(メモリ等)に格納する構成も可能である。また、ヘッダのみならず、キーも、要求バッファ部102とは別のメモリ装置(メモリ等)に格納する構成も可能である。
KV記憶部103は、揮発性または不揮発性のメモリ、ストレージ、またはこれらの両方によって構成される記憶デバイスである。例えばDRAM、SSD、またはHDDなどで構成される。DRAMとSSDの両方、または、DRAMとHDDの両方で構成されてもよい。メモリは、DRAM以外に、MRAMやFRAMなど、他のメモリでも構わない。
KV処理部105は、いわゆるキーバリューストア処理を行う機能部である。キーバリューストア処理の形態の代表的な例を2つ示す。ここでは読み出し要求で与えられたキーに対する読み出しを例に動作を説明するが、書き込み要求で与えられたキーに対する書き込みの場合も同様にして行うことができる。一例として、図4に示すように、ハッシュ値とKV記憶部103のデータ記憶領域上のアドレスとを対応づけるハッシュテーブルを用意する。この場合、ハッシュテーブルはKV記憶部103の管理領域に記憶されている。指定されたキーに対するハッシュ値をハッシュ関数h()で計算し、計算されたハッシュ値に対応するアドレスをハッシュテーブルから取得する。取得したアドレスに基づき、データ記憶領域にアクセスして、キーバリューを読み出す。この方式によれば、高速なアクセスが可能になる。または、図5に示すように、キーとアドレスとを対応づけるキーテーブルを用意する。キーテーブルは、キーを辞書順に並べて管理するデータ構造を含む。指定されたキーに対するアドレスをキーテーブルから取得し、取得したアドレスに基づき、データ記憶領域にアクセスして、対応するキーバリューを読み出す。また、上述したキーを辞書順に並べて管理するデータ構造を有するため、指定されたキーの手前または後のキーに対するキーバリューの読み出しを要求するなどの読み出し要求にも応答することができる。ここでは、キーバリューストア処理の代表的な形態を2つ示したが、ここで述べた以外の形態も可能であり、本実施形態では、キーバリューストア処理自体の形態やアルゴリズムは限定しない。
分割キー生成部104は、要求バッファ部102で何バイトのデータがバッファリングされたかを監視している。分割キー生成部104は、要求バッファ部102のバッファリング状況に応じて、具体的に、バッファリングされているバリューのサイズ(またはキーバリューのサイズ)に応じて、要求バッファ部102からまだ取り出されていないバリューの部分データを先頭側から取り出す。例えばバリューの先頭から一定サイズに達するごとに、バリューの部分データを取り出す。バリューの部分データを取り出すことをバリュー分割と表現し、取り出した部分データは、分割バリューと呼ぶことがある。上述したように、書き込み要求のヘッダには、キーのサイズおよびバリューのサイズに関する情報が含まれている。したがって、ヘッダを利用することで、要求バッファにバッファリングされているデータから、キーおよびバリューのそれぞれの先頭位置を特定可能である。なお、前述したように、ヘッダ自身は、要求バッファ部102にバッファリングされてもかまわないし、別途のメモリ等の記憶装置に格納されてもよい。以下、書き込み要求に含まれていたキーを「元のキー」、書き込み要求に含まれていたバリューを「元のバリュー」と表現することがある。
分割キー生成部104は、元のキーを用いて、分割バリューに付与するキー(分割キーと呼ぶ)を生成する。より詳細には、元のバリューにおける当該分割バリューの位置に応じて分割キーを生成する。分割キー生成部104は、これら分割キーと分割バリュー(分割キーバリューと呼ぶ場合がある)を、KV処理部105に渡す。この際、元のバリューの全長に関する情報を含む付加情報を、KV処理部105に渡す。付加情報に分割バリューの長さに関する情報を含めてもよい。分割キー生成部104は、分割キーバリューをKV処理部105に渡した時点で、分割バリューが格納されていたバッファ領域を開放し(ヘッダおよびキーが格納されていたバッファ領域も、当該バッファ領域に格納しておく必要がなくなった時点で開放してもよい)、バリューの残り部分の受信に備える。ただし、バッファを開放しても、要求内容(ヘッダに含まれていたバリューの全長サイズなど)と、元のキーは、後続するバリュー分割、および分割キーの生成に必要なので、要求バッファ部102内の任意または所定の領域、もしくは別途のメモリ等の記憶部に保持しておく。
この後、要求バッファ部102が、バリューのまだ受信されていない残り部分を段階的に受信し、バッファリングされたサイズに応じて、まだ読み出されていないバリューの部分データを先頭側から特定して、特定した部分データ(分割バリュー)を要求バッファ部102から取り出す。確保しておいたキーから2番目の分割バリューに対する分割キーを生成し、分割バリューと分割キー(分割キーバリュー)を、KV処理部105に渡す。なお、2番目以降の分割キーバリューについても、ヘッダに含まれていたバリューの全長に関する情報を含む付加情報をKV処理部105に渡してもよい。また、付加情報には、該当する分割バリューの長さに関する情報を含めてもよい。
図6に、元のバリューを3つの部分(簡易的にそれぞれVALUE1/3、VALUE2/3、VALUE3/3と表現する)に分割し、それぞれに元のキー(KEY)から生成した分割キー(KEY0、KEY1、KEY2)を付与する例を模式的に示す。この例では、元のバリューの先頭から一定サイズごとに分割している。
バリューの分割方法についてさらに詳細に説明する。上述したように、バリューの分割は、例えばバッファリングされたサイズが、元のバリューの先頭から一定サイズ(例えば4Kバイト)に達した段階で、そこでまでのバリューの部分データを取り出すことが考えられる。この場合、以降も、バッファリングされたデータが4Kバイトに達するごとに、4K分の部分データを取り出す。バリューの末尾に達した場合は、4Kバイト未満であっても、末尾を含むバリューを取り出す。
ここでは、バリューの分割サイズを、バリューの先頭から一定サイズごとにしたが、必ずしも一定サイズごとである必要はなく、分割キーの値から、分割バリューが、元のバリューの全体内のどのバイト位置かを一意に特定できる限り、可変長でもよい。例えば、分割ごとに分割サイズが異なってもよい。分割のサイズを可変長とする場合に、バッファリングの速度に応じて分割のサイズを変更することも可能である。例えばバッファリングの速度が速いほど、分割のサイズを大きくまたは小さくしてもよい。また分割の基準を、元のバリューの先頭を基準にするのではなく、元のキーの先頭を基準にしても良い。例えばキーバリューのキーの先頭からバイトをカウントし、一定サイズに達するごとに、バリューの分割を行っても良い。このように分割方法自体は、特定の方法に限定されるものではない。
ここで、分割キーの生成方法について説明する。分割キーは、元のキーを利用して生成する。例えば、キーが“ABC”だった場合、最初に取得した分割バリューに対しては “ABC0”などと、識別子0を付加することで分割キーを生成する。2番目に取得した分割バリューに対しては、次の識別子1を付加して“ABC1”などとして、分割キーを生成する。このように分割キーは、元のキーと、元のバリューの全体における各分割バリューの位置を特定する識別子を結合することで、生成できる。ここでは、識別子を、元のキーの末尾に結合させることで分割キーを生成したが、先頭に結合してもよいし、元のキーの文字列の途中に挿入してもよい。また結合する識別子は数字である必要はなく、アルファベットや他の記号でもよい。
上述した方法で、元キーに識別子を付加して分割キーを生成すると、そもそもそれと同一のキーの書き込み要求が外部から行われる可能性があり、これらが混同される可能性が生じる。例えば先程は“ABC0”の例を示したが、クライアント装置からこれと全く同じ“ABC0”というキーを指定した、キーバリューの書き込み要求が来る可能性がある。この場合でも、これらを識別できるようにする必要がある。そこで、分割キー生成部104は、必ず固定長の識別子を付加する方法を採用することで、この問題を解消可能である。例えば、固定長が1バイト長だとすると、“ABC0”というキーを指定したキーバリューの書き込み要求をクライアント装置から受信した場合、分割キー生成部は、最初の分割キーとして、“ABC00”のように、固定長の識別子0を元のキーの末尾に付加することで生成する。2番目の分割キーは、“ABC01”のように、同じく固定長の識別子1を元のキーの末尾に付加したものとする。付加する識別子をこのように固定長とし、かつ必ず付加することで、内部的には必ず最後の1バイトが識別子、それより前の部分が、元のキーとして識別でき、混同が発生しない。なお、識別子の個数をより多く確保できるように、識別子の桁数は1バイトより多い何桁でも良い。さらには、このような固定長の識別子を必ず付与する方式(固定長識別子方式)に限るものではなく、他のどのような方法でもよい。
KV処理部105は、分割キー生成部104から分割キーバリューと付加情報とを受け取り、付加情報からヘッダ情報を生成し、ヘッダ情報と分割キーバリューとを含むデータ構造体を生成して、KV記憶部103のデータ記憶領域の空き領域に書き込む。ヘッダ情報は、付加情報そのものでもよいし、付加情報から一部情報を抽出して生成してもよい。なお、ヘッダ情報の記憶は必須ではなく、ヘッダ情報を記憶しない場合は、分割キー生成部104は、当該ヘッダ情報をKV処理部105に渡さない構成も可能である。
図7にKV記憶部103への書き込みの例を示す。ヘッダ情報HDR0と、分割キー“ABC0”および1番目の分割バリュー(VALUE1/3)とを含むデータ構造体が、アドレスP1−1から格納されている。また、当該分割バリュー(VALUE1/3)の末尾アドレスの次のアドレスP1−2から、ヘッダ情報HDR1と、分割キー“ABC1”および2番目の分割バリュー(VALUE2/3) とを含むデータ構造体が格納されている。また、分割バリュー(VALUE2/3)の末尾アドレスの次のアドレスP1−3から、ヘッダ情報HDR2と、分割キー“ABC2”および3番目の分割バリュー(VALUE3/3)とを含むデータ構造体が格納されている。
また、KV処理部105は、分割キーと、データ構造体が格納されたアドレスとの対応を、KV記憶部103の管理領域に保持されている対応情報に登録する。前述したように、キーバリューストア処理の方式は、前述したように、ハッシュを利用したものや、辞書に基づきキーテーブルを利用したものなど様々であるが、後者の場合の対応情報(キーテーブル)の例を、図8に示す。図7に示した書き込み例に対応して、分割キーとして、“ABC0”、“ABC1”、“ABC2”が登録されている。また、分割キーに対応するデータ(データ構造体)が格納されたアドレスが“P1−1”、“P1−2”、“P1−3”として、対応情報に登録されている。
図7および図8に示した例では、ヘッダ情報が分割キーバリューと同じデータ記憶領域に記憶されていたが、ヘッダ情報をキーテーブル(対応情報)に登録してもかまわない。また、ヘッダ情報自体の登録を、いずれからも省略することも可能である。また、1番目の分割キーバリューに対してのみヘッダ情報(元のバリューの全長サイズ等)を保持し、2番目以降の分割キーバリューに対しては、ヘッダ情報の保持を省略する構成も可能である。
応答送信部106は、クライアント装置から受信した書き込み要求の実行が完了すると、書き込み完了応答を、クライアント装置に送信する。すなわち、分割キー生成部104による分割キーバリューの生成と、KV処理部105によるKV記憶部103への分割キーバリューを含むデータ構造体の書き込みが繰り返し行われ、最終的に、書き込み要求されたバリューの末尾まで受信し、最後の分割キーバリューを含むデータ構造体を、KV記憶部103に書き込み終えた段階で、書き込み要求の実行が完了する。このとき、応答送信部106が、KV処理部105から書き込み要求の実行の完了通知を受けて、書き込み完了応答をクライアント装置に送信する。
以上は、元のバリューの全長が、分割サイズとして用いた固定長より長い場合を例に説明したが、もちろんその固定長より短いバリューを含む書き込み要求があった場合も、同様に対応可能である。その場合、バリューの分割は行われず、元のバリュー全体が、元のキーおよび付加情報(バリュー全長に関する情報など)と共に、KV処理部105に送られる。そして、これらに基づくデータ構造体がKV記憶部103に書き込まれる。書き込みが完了すると、応答送信部106が応答をクライアント装置に送信する。ただし、上述した固定長識別子方式を用いる場合は、元のキーに、固定長の識別子を付与したキーを生成し、元のキーの代わりに、当該固定長の識別子を付与したキーを、KV処理部105に送る。
図9に、本実施形態の動作例のフローチャートを示す。まず、要求受信部101がクライアント装置から、キーバリューの書き込み要求を1つ以上のパケットを介して受信する(S101)。要求バッファ部102が、要求受信部101で受信される書き込み要求を、内部にバッファリングする(S102)。書き込み要求は、ヘッダと、キー(キーの実データ)と、バリュー(書き込みの対象データ)とを含む。ヘッダにはキーとバリューの長さに関する情報が含まれる。
分割キー生成部104は、要求バッファ部102のバッファリング状況、具体的には、バッファリングされているデータのサイズに応じて、要求バッファ部102からまだ取り出していないバリューの部分データを、バリューの先頭側から分割バリューとして取り出す。そして、書き込み要求に含まれていたキー(元のキー)に基づいて、分割バリューに対する分割キーを生成する(S103)KV処理部105は、分割キーと分割バリューとを含むデータ構造体を、KV記憶部103のデータ記憶領域に書き込む。データ構造体には、元のバリューの全長サイズおよび分割バリューのサイズの少なくとも一方などを含むヘッダ情報を含めてもよい。また、KV記憶部103の管理領域に存在する対応情報に、分割キー(またはそのハッシュ値)と、データ構造体を書き込んだアドレスとを登録する。なお、要求バッファ部102において分割バリュー等が格納されていたバッファ領域は解放してよい。
分割キー生成部104は、要求バッファ部102からバリューの末尾までの読み出しが完了したか、すなわち、取り出すべきバリュー部分がまだ存在するかを判断し、まだバリューの末尾まで読み出しが完了していない場合(すなわち取り出すべきバリュー部分が存在する場合)、ステップS103に戻る。バリューの末尾までの読み出しが完了した場合は、書き込み要求の実行が完了したと判断し、応答送信部106に完了信号を通知する。完了信号を受信した応答送信部106は、書き込み要求を送信したクライアント装置に、書き込み完了応答を送信する(S106)。
なお、本実施形態では、分割バリューごとにキー(分割キー)が付加されることから、従来の構成より、KV記憶部103のデータ記憶領域に記憶するキー(分割キー)の量が多くなる問題がある。その問題を軽減するため、KV記憶部103として、複数の異なるビットコストのストレージデバイス、例えばDRAMとSSD、または、SSDとHDDなどを備えてもよい。一般に、ビットコストが高いストレージデバイスは、アクセス速度が高く、ビットコストが低いストレージコストは、アクセス速度が低い。そこで、一部の分割キーに関するデータ構造体は、ビットコストが高いもののアクセス速度が高いストレージデバイスに記憶し、残りの分割キーに関するデータ構造体は、アクセス速度が遅いがビットコストが低いストレージデバイスに記憶してもよい。
例えば識別子0の分割キー(1番目の分割キー)に関するデータ構造体は高速なストレージに保存し、それ以外の識別子の分割キー(2番目以降の分割キー)に関するデータ構造体は、低速だが安価なストレージに保存する。これによれば、(応答速度が要求される)分割されない小さなサイズのバリューに関するキーバリュー読み出し要求の応答速度は維持したまま、大きなキーバリューの記憶の際に増大する分割キーの記憶コストを低く抑えることが出来る。
また、KV処理部105がハッシュベースのキーバリューストア処理(図4参照)であった場合、識別子0の分割キー(1番目の分割キー)に関するエントリを記憶するハッシュテーブルは、例えば高速なDRAM上に配置し、それ以外の識別子の分割キー(2番目以降の分割キー)に関するエントリを記憶するハッシュテーブルは、SSDに配置するなどしてもよい。ハッシュベースではなく、キーを辞書順に記憶するキーテーブル(図5参照)の場合も同様にして、テーブルの配置を、DRAMとSSDに分けることができる。
以上、本実施形態によれば、書き込み要求されたバリューのすべてをバッファリングすることなく、受信されるバリューを順次バッファリングしながら、バリューの先頭側から部分データを順次、分割バリューとして取り出す。そして、取り出した分割バリューに対して分割キーを生成し、分割キーに関連づけて、分割バリューを含むデータ構造体を、KV記憶部103に書き込む。これによれば、バリューの全データのバッファリングを待つ必要なく、バリューの書き込みが可能なため、要求バッファ部102のバッファサイズを小さく抑えることができる。
また、本実施形態によれば、分割キーバリュー単位で、複数の書き込み要求間で並列して動作を実行することが可能である。例えば、ある書き込み要求についてN(Nは1以上の整数)番目の分割キーに関するデータ構造体の書き込みが完了したら、別の書き込み要求に切り替えて動作し、また、元の書き込み要求に戻って、N+1番目の分割キーに関するデータ構造体の書き込みを行うといったことも可能になる。よって、大きなサイズのバリューを指定した書き込み要求によって、他の書き込み要求の実行が大幅に待たせられることもなくなり、書き込み遅延を安定させることができる。
(変形例1)
上述した実施形態では、データ構造体内のヘッダ情報には、元のバリュー全体のサイズ情報または分割バリューのサイズ情報等を含める場合を示したが、当該データ構造体内の分割バリューに後続するデータが存在するか否か、すなわち、当該分割バリューが元のバリューの末尾を含むか否かの後続有無識別情報をさらに含めても良い。この場合、分割キー生成部104が、今回読み出した分割バリューに後続するデータが存在するか(今回読み出した分割バリューが元のバリューの末尾を含むか)を判断し、判断結果に応じた値を含む後続有無識別情報をKV処理部105に渡す。KV処理部105は、ヘッダ情報に後続有無識別情報を含め、当該ヘッダ情報や分割バリュー等に基づき、データ構造体を生成する。この後続有無識別情報は、元のバリューの読み出し要求を受けた際の読み出し処理のときに利用することができる。
(変形例2)
変形例1では、ヘッダ情報に後続有無識別情報を含める場合を示したが、他の例として、要求バッファ部102から最初に読み出す分割バリュー、すなわち、元のバリューの先頭を含む分割バリューのデータ構造体内のヘッダ情報には、元のバリューの分割回数(あるいは読み出し回数)を表す情報を含めても良い。元のバリューの分割回数は、元のバリューのサイズ情報から計算可能である。例えば、分割の単位が元のバリューの先頭から一定サイズであれば、元のバリューのサイズを一定サイズで除算したときの除算値と剰余に基づき、剰余が0であれば、除算値、0より大きい場合は、除算値に1を加算した値を、分割回数と計算できる。なお、2番目以降に読み出す分割バリューについては、分割回数の情報をヘッダに含めなくても良い。この分割回数(読み出し回数)の情報は、元のバリューの読み出し要求を受けた際の読み出し処理のときに利用することができる。
(変形例3)
上述した実施形態では要求バッファ部102にバリューのバイト列がTCPにしたがって、元のバリューの先頭から順番に格納されることを想定していたが、パケットの到着順に、受信パケット内のデータの元のバリュー内の位置に応じて、要求バッファ部102内の該当する位置に直接格納(それより前のデータが到着していなくても)してもよい。例えば、書き込み要求のヘッダから元のバリューのサイズを特定し、受信パケットのシーケンス番号等から受信パケットのデータの、元のバリュー内での相対位置を特定し、特定した位置に応じて要求バッファ部102にそのデータを格納してもよい。分割の単位が一定サイズに決まっており、バリューの先頭から一定サイズごとに分割するような場合、該当する一定サイズ分のデータが分割の単位でそろった時点で、それより先頭側のデータの読み出しが行われていなくても、そのそろったデータ(分割バリュー)を読み出して、後段の処理を行っても良い。分割キー生成部104では、読み出された分割バリューが先頭から何番目かに応じて、分割キーを生成すればよい。
(第2の実施形態)
第1の実施形態において、書き込み要求で要求された元バリューを複数の部分バリュー(分割バリュー)に分割し、KV記憶部103に段階的に、分割キーと分割バリューとを含むデータ構造体を書き込む行う場合に、途中でストレージ障害などでKV記憶部103に書き込みが出来なくなる場合があり得る。その場合、単にクライアント装置に書き込みエラーの応答を返すだけだと、そこまで書き込んだデータ構造体がKV記憶部103上に無駄なデータとして残ってしまう。本実施形態では、そのようなエラー処理にも適切に対処する形態を示す。
図10に、第2の実施形態に係るデータ処理装置のブロック図を示す。第1の実施形態に係るデータ処理装置に、障害検知部109と削除分割キー生成部(削除処理部)110が追加されている。
障害検知部109は、KV記憶部103の障害を検知し、障害検知を削除分割キー生成部110に通知する。障害の検知方法は任意でよいが、例えばKV処理部105がKV記憶部103に対するデータ構造体の書き込み要求に対する応答を監視し、応答が返ってこない、またはエラー信号が返ってきた場合に障害を検知してもよい。または、KV記憶部103が、障害が発生した場合に障害発生を示す信号を出力するようにし、この信号を検知してもよい。またはKV記憶部103の電源がオフになっていることを検出した場合に、障害が発生したと判断してもよい。
削除分割キー生成部110は、障害検知部109から障害検知の通知を受けた際に、それまでに該当の書き込み要求に関連して、KV記憶部103に書き込まれたデータ構造体を削除するための分割キーを生成する。分割キーの生成のために、分割キー生成部104から元のキーと、それまで行われたバリューの分割数に関する情報を取得し、元のキーから分割数分の分割キーを生成する。各分割キーを指定したデータ構造体の削除命令をKV処理部105に渡す。KV処理部105は、それに従いKV記憶部103からこれらの分割キーに該当するデータ構造体を削除する。KV処理部105は、削除が完了すると、応答送信部106にエラー通知を送り、応答送信部106は、書き込みエラーを示す応答をクライアント装置に送信する。
例えば、元のバリューが10個の分割バリューに分割される場合に、最初の6個の分割リューのうちの1つを各々含む6個のデータ構造体の書き込み処理後に、障害検知部109が、KV記憶部103の障害を検知したとする。このとき、削除分割キー生成部110は、それまでの分割キー、例えば元のキーが“ABC”で、識別子が固定長1バイトだったとすると、“ABC0”から“ABC5”までの6つの分割キーを生成し、これらを指定したデータ構造体の削除命令をKV処理部105に渡す。KV処理部105は、それに従いKV記憶部103からこれらの分割キーに該当するデータ構造体を削除する。KV処理部105は、削除が完了すると、応答送信部106にエラー通知を送り、応答送信部106は、書き込みエラーを示す応答を、クライアント装置に送信する。
上述した説明では、削除分割キー生成部110は、分割キー生成部104から元のキーと分割数に関する情報を取得して、分割キーを生成したが、分割キーを生成できる限り、別の方法を利用してもよい。例えば対象とする書き込み要求に関連してこれまで分割キー生成部からKV処理部105に分割キーが送られた回数をカウントすることで、分割数に関する情報を取得してもよい。または、分割数に関する情報は利用せずに、元のキーから分割キーを1番目から順次生成して、KV処理部105に削除を指示し、該当する分割キーがないとの応答がKV処理部105から返ってくるまで分割キーの生成を行っても良い。なお、分割キーの生成アルゴリズムは、削除分割キー生成部110と分割キー生成部104とで共通のものが事前に設定されているものとする。または、分割キー生成部104からKV処理部105に送られる分割キーそのものを読み込んで蓄積し、障害検知の通知時には、対象とする書き込み要求に関連してこれまで蓄積した分割キーそのものを利用してもよい。この場合、書き込み要求の実行が完了したら、蓄積した分割キーは削除すればよい。
以上、本実施形態によれば、書き込み処理の最中にKV記憶部103に障害が発生しても、そこまで書き込んでいたデータ構造体を正しく削除することが出来るようになり、障害発生時でも無駄なデータがKV記憶部103に残骸として残る問題を解消できる。
(第3の実施形態)
図11に、第3の実施形態に係るデータ処理装置のブロック図を示す。第1および第2の実施形態では、書き込み動作を実現するデータ処理装置を示したが、ここでは、読み出し動作を実現するデータ処理装置を示す。
データ処理装置は、キー(第1キー)を含む、キーバリューまたはバリュー(第1データ)の読み出し要求を受信する要求受信部201と、受信した読み出し要求を一時的にバッファリングする要求バッファ部202と、要求バッファ部102から取り出した読み出し要求で指定されたキー(元のキー)から分割キーを生成する分割キー生成部203と、データ(データ構造体、テーブル等)を記憶するKV記憶部205と、分割キーに応じたバリュー(元のバリューが分割されている場合は分割バリュー)をKV記憶部205から読み出すKV処理部204と、後続する分割バリューが存在するか(すなわち、元のバリューの末尾を含む分割バリューを読み出したか)を判定する継続判断部(判断部)206と、KV処理部204で読み出したバリュー(元のバリューが分割されている場合は、分割バリュー)に基づき、応答を送信する応答送信部207と、を備える。
なお、KV記憶部205は、図3等のデータ処理装置の書き込み機能で書き込んだKV記憶部103と同じでものでもよい。図11では、KV記憶部205が、データ処理装置の内部に配置されているが、図2のKV記憶装置のように、内部バスまたはネットワークを介して、KV記憶部207が外部から接続されてもよい。以下、データ処理装置の各部についてさらに詳細に説明する。
要求受信部201は、イーサネット等のネットワーク越しに、クライアント装置からキーバリューの読み出し要求を受信する。読み出し要求のメッセージにはヘッダおよびキー(元のキー)等が含まれ、元のキーに対応するバリューの読み出しが要求される。ヘッダには、読み出し要求である要求種別の識別子が含まれ、送信元の識別子等が含まれてもよい。書き込み要求は、例えばTCP/IPまたはUDP/IPなどの通信プロトコル上のメッセージとして構成され、例えばmemcachedなどのプロトコルに従ったメッセージとして構成される。
要求バッファ部202は、要求受信部201で受信された読み出し要求を一旦バッファリングする。少なくとも読み出し要求に含まれるキーをバッファリングする。ヘッダは、要求バッファ部202とは別の記憶装置(メモリ等)に格納する構成も可能である。この場合、キーとヘッダの対応が取れるようにしておく。
KV記憶部205は、揮発性または不揮発性のメモリ、ストレージ、またはこれらの両方によって構成される記憶デバイスである。例えばDRAM、SSD、またはHDDなどで構成される。DRAMとSSDの両方、または、DRAMとHDDの両方で構成されてもよい。メモリは、DRAM以外に、MRAMやFRAMなど、他のメモリでも構わない。
KV処理部204は、いわゆるキーバリューストア処理(ここでは読み出し機能に関する処理)を行う機能部である。第1の実施形態と同様、ハッシュテーブルを利用したハッシュベースの形態や、辞書順にキーを並べて管理するデータ構造を有するキーテーブルを利用する形態などがある。動作の詳細は、第1の実施形態で述べたため省略する。
分割キー生成部203は、要求バッファ部202から取り出した読み出し要求で指定されたキー(元のキー)から分割キー(第2キー)を生成する。より詳細には、当該分割キーで読み出そうとする分割バリューの元のバリュー内での位置に応じて、あるいは、読み出し回数(最初は1)に応じて、分割キーを生成する。KV処理部204にその分割キーを指定して、バリュー(分割されている場合は分割バリュー)の読み出し要求を行う。分割キー生成部203は、書き込み機能を有するデータ処理装置の分割キー生成部104と同様の分割キー生成アルゴリズムを搭載し、当該アルゴリズムに従って分割キーを生成する。
例えば、分割キーの生成アルゴリズムが第1の実施の形態と同様の方式だとすると、最初は、元のキーに識別子0を付加した分割キーを生成し、KV処理部204に、その分割キーを指定してバリュー(第2データ)の読み出し要求を行う。例えばキー“ABC”の場合は“ABC0”といった分割キーを生成する。KV処理部204は、KV記憶部205からこの分割キーに対応づけられたデータ構造体を読み出し、データ構造体からバリュー(分割されている場合は分割バリュー)を取り出し、更に併せてデータ構造体内のヘッダ情報に記憶されている元のバリュー全長も併せて取り出す。元のバリューの全長は、この分割キーに対応するバリューが分割バリューであった場合は、分割前のバリュー(元のバリュー)の全長である。
継続判断部206は、KV処理部204で取得された元のバリュー全長から、KV記憶部205から読み出したバリュー(または分割バリュー)に、後続する分割バリューが存在するか(すなわち当該バリュー(または分割バリュー)が元のバリューの末尾を含んでいるか)を判断する。後続する分割バリューが存在すると判断した場合、分割キー生成部203に、次の分割キーを生成するように指示する。
例えば分割バリューの長さが最大4KB(元の末尾を含む分割バリューが4KB以下、それ以外は4KB)であり、元のバリュー全長が11KBの場合、現在の分割キーの識別子が0であったとすると、ここまで読み出したバリューの最大長は4KB×(0+1)=4KBであり、これが11KBより小さいので、後続するバリューが存在する(読み出しを継続すべき)と判断する。なお、括弧の中の左側の数字(ここでは0)は、前回までの読み出し回数、右側の数字は今回の読み出しを、前回までの読み出し回数に加算する値(1)である。
指示された分割キー生成部203は、この場合は、次の識別子1を付加した分割キー“ABC1”を生成して、KV処理部204に渡す。同様に、分割キー“ABC1”に対応するバリューが読み出される。ここまで読み出したバリューの最大長は4KB×(1+1)=8KB、これが11KBより小さいので、後続するバリューが存在する(読み出しを継続すべき)と判断する。継続判断部206は、分割キー“ABC2”に対応する分割バリューが読み出された時点で、ここまでのバリューの最大長は4KB×(2+1)=12KBとなり、これは11KB以上なので、これ以上、読み出しは継続しないと判断する。なお、データ構造体内のヘッダに、分割バリューのサイズ情報が含まれている場合は、これまで読み出した分割バリューのサイズ情報と、元のバリュー全長から、継続すべきかを判断してもよい。
応答送信部207は、分割バリューが読み出される都度、それを含む応答メッセージを送信する。応答メッセージがヘッダを備える構成の場合は、最初の分割バリューの送信ときのみ、応答メッセージのヘッダを生成して、ヘッダと、その後に最初に読み出したバリューと続けて含めるように、応答メッセージを送信する。なお、応答メッセージは、応答送信部207内の送信バッファを介して、パケット送信される。送信バッファは、応答送信部207内に設けられ、送信するデータを一時的に格納するバッファである。ここで、ヘッダには、応答するバリュー(元のバリュー)の全長を含める。ヘッダに続けて、読み出し要求に含まれていたキーを含めてもよい。最初の分割バリューを読み出す際に、元のバリューの全長がヘッダ情報として併せて読み出されるため、このヘッダ情報から、元のバリューの全長を取得する。
後続する分割バリューについては、読み出される都度、その分割バリューをそのまま内部の送信バッファを介してパケット送信し、その都度、送信バッファは開放する。クライアント装置は、応答メッセージを受信し、そこに含まれるバリュー全長の情報から、バリュー全長を把握する。クライアント装置は、受信した分割バリューの合計が、把握したバリュー全長に達するまで、バリューデータの到来を待機する。データ処理装置からは、分割バリューを一つずつ順次応答していく動作になるが、そもそもバリュー全体を一度に送信したとしても、ネットワーク上ではデータが、例えば1.5KBなどのTCP/IPパケット毎に分割されて送信されるので、クライアント装置から見て、基本的にこれらの動作の違いは明示的には判別が出来ない。このため、クライアント装置が要求したバリューが、データ処理装置内部で分割されて送信されていることは、クライアント装置には隠ぺいされる。
なお、継続判断部206は、後続する分割バリューがあと何個あるかが分かるため、毎回読み出し終わってから、次の分割バリューの読み出しを一つずつ指示するのではなく、例えば最初の分割バリューが読み出されたた際に、残りの1つまたは複数の分割バリューの読み出し指示を一度に行うようにしてもよい。これにより、読み出しのスループットを向上させることができる。
図12に、本実施形態の動作例のフローチャートを示す。まず、要求受信部201がクライアント装置から、キーの読み出し要求を受信し、受信された読み出し要求を、要求バッファ部202にバッファリングする(S201)。読み出し要求には、例えばヘッダと、キー(第1キー)が含まれる。
分割キー生成部203は、要求バッファ部202にバッファリングされている読み出し要求を取り出し、読み出し要求に含まれているキーを特定する(S202)。分割キー生成部203は、特定したキーから分割キー(第2キー)を生成する(S203)。分割キー生成部203は、分割キーに対応する分割バリュー等を含むデータ構造体の読み出しを、KV処理部204に指示する。KV処理部204は、分割キーに対応するデータ構造体をデータ記憶部205から読み出し、データ構造体から分割バリューを取り出す(S204)。1回目の分割キーに対する読み出しでは、データ構造体からさらにヘッダ情報に含まれるバリュー全長の情報を取得してもよい。応答送信部207は、1回目に読み出した分割バリューについては、例えばヘッダ(バリューの全長等を含む)と、キー(読み出し要求で指定されたものと同じ)と、分割バリューとを含む応答メッセージを生成して、内部の送信バッファを介して、送信する(S205)。2回目以降に読み出した分割バリューについては、当該分割バリューのデータを、そのままパケットで、内部の送信バッファを介して送信する(S205)。応答メッセージまたは分割バリューの送信後、当該送信バッファを開放してよい。
継続判断部206は、後続して読み出すべき分割バリューが存在するかを判断し(S206)、そのような分割バリューが存在する場合は、次の分割キーの生成を、分割キー生成部104に指示する(S203)。一方、そのような分割バリューが存在しない場合は、クライアント装置が要求したバリューデータをすべて送信済みのため、本フローの処理を終了する。
以上、本実施形態によれば、分割されて記憶されたバリュー(分割バリュー)を正しく読み出すことができ、さらにクライアント装置に対して分割していることを隠ぺいして、元のバリューを一度で応答しているように見せることが出来る。また、分割バリューの送信毎に、応答送信部207内の送信バッファを開放することが出来るので、一度にバリュー全体を送信バッファに読み出してから送信する場合に比べて、バッファ容量を削減することが出来る。
また、本実施形態によれば、読み出しの単位(分割キーの単位)で、複数の読み出し要求間で並列して動作を実行することが可能である。例えば、ある読み出し要求についてN(Nは1以上の整数)番目の分割キーに対する読み出しが完了したら、別の読み出し要求に切り替えて動作し、また、元の読み出し要求に戻って、N+1番目の分割キーに対する読み出しを行うといったことも可能になる。よって、大きなサイズのバリューを指定した読み出し要求によって、他の読み出し要求の実行が大幅に待たせられることもなくなり、読み出し遅延を安定させることができる。
(変形例1)
上述した実施形態では、継続判断部206は、元のバリュー全長と、これまで読み出した分割バリューのサイズに基づき、後続の分割バリューが存在するか(元のバリューの末尾を含む分割バリューを読み出したか)を判断した。別の方法として、第1の実施形態の変形例1で述べたように、書き込み動作時にデータ構造体内のヘッダに後続有無識別情報を追加し、読み出し動作時に、この後続有無識別情報を利用することも可能である。具体的に、KV記憶部から読み出したデータ構造体内のヘッダから後続有無識別情報を特定し、この値、後続有りを示すときは、後続の分割バリューが存在する(元のバリューの末尾を含む分割バリューはまだ読み出していない)と判断する。一方、後続無を示すときは、後続の分割バリューが存在しない(元のバリューの末尾を含む分割バリューは読み出し済み)と判断する。
(変形例2)
後続有無識別情報を利用する以外の方法として、第1の実施形態の変形例2で述べたように、書き込み時にデータ構造体内のヘッダ、より詳細には、元のバリューの先頭を含む分割バリューを格納するデータ構造体内のヘッダに、分割回数(読み出し回数)を追加し、読み出し時に、この分割回数(読み出し回数)を利用することも可能である。具体的に、KV記憶部から最初に読み出したデータ構造体内のヘッダから分割回数(読み出し回数)を特定し、この値の回数だけ、分割バリューの読み出しを行った場合に、後続の分割バリューが存在しない(元のバリューの末尾を含む分割バリューは読み出し済み)と判断する。
(第4の実施形態)
第3の実施形態では、読み出し要求に対して含まれるキーから生成される複数の分割キーが、それぞれ順番に処理されているとき、途中でKV記憶部におけるストレージ障害などで、読み出しが出来なくなる場合があり得る。そのような場合でも適切にエラー処理を行う形態を示す。
図13に、第4の実施形態に係るデータ処理装置のブロック図を示す。第3の実施形態と同様、ここでも、読み出し動作を実現するデータ処理装置を示す。
図11に示した第3の実施形態に比べ、KV記憶部205の障害を検知する障害検知部208、通信コネクションを切断する通信切断部209を新たに備える。図11と同一名称の要素には、同一の符号を付して、拡張または変更された処理を除き、重複する説明を省略する。なお、図11と異なり要求バッファ部は存在しないが、図11と同様に要求受信部201の後段に要求バッファを追加してもよい。
障害検知部208は、KV記憶部205の障害を検知し、障害検知を通信切断部209に通知する。障害の検知方法は任意でよいが、例えばKV処理部204がKV記憶部205に対する読み出しの指示に対する応答を監視し、応答が返ってこない、またはエラー信号が返ってきた場合に障害を検知してもよい。または、KV記憶部205が、障害が発生した場合に障害発生を示す信号を出力するようにし、この信号を検知してもよい。またはKV記憶部205の電源がオフになっていることを検出した場合に、障害が発生したと判断してもよい。
通信切断部209は、障害検知部109から障害検知の通知を受けると、キーバリュー読み出し要求とそれに対する応答を送受している通信コネクション(TCPコネクションでもよいし、TCPより上位層のアプリケーションレベルでのコネクションでもよい)を切断する。
例えば、読み出すべきバリュー(元のバリュー)が10個に分割されている場合で、最初の6個の分割バリューを読み出した後に、障害検知部208が、KV記憶部205のストレージ障害を検知したとする。この時点で、この6個の分割バリューは、クライアント装置に送信済みであり、さらには最初の分割バリューの送信で併せて送信したヘッダ内で元のバリュー全長を通知している。このため、送信される分割バリューの合計長が、そのバリュー全長になるまで、クライアント装置は、残りの4個の分割バリューを待っている。しかしながら、データ処理装置は、障害により、その4個の分割バリューを送信できない。通信切断部209は、障害検知部208から障害検知の通知を受けると、キーバリュー読み出し要求とそれに対する応答を送受している通信コネクション(TCPコネクションでもよいし、TCPより上位層のアプリケーションレベルでのコネクションでもよい)を切断する。通信コネクションを切断すると、クライアント装置は、当該コネクションで何らかの異常が行ったことを知ることができ、残りのバリューを待っている状態から抜け出すことが出来る。
図14に、第4の実施形態に係るデータ処理装置の他の例のブロック図を示す。図13の通信切断部209が、ダミーデータ生成部210に置き換わっている。
ダミーデータ生成部210は、障害検知部208で障害が検知された際に、障害により読み出せないこととなった、残りの1つまたは複数の分割バリューの合計に相当するサイズのダミーデータを生成する。応答送信部208は、残りの分割バリューの代わりに、ダミーデータを送信する。その後に、応答送信部208は、引き続き、読み出しエラーをクライアント装置に通知する。
ダミーデータを送信する理由を以下に述べる。最初の分割バリューの送信の際に併せて通知したバリュー全長分のデータを送らないと、クライアント装置は通信コネクションを切断せず、次の動作に移行できない。そこで、本実施形態では、障害検知後、残りの分割バリュー分のダミーデータを送信することで、最初に通知したバリューの長さ分のデータを返す。そして、その後に応答送信部が読み出しエラーをクライアント装置に通知する。これによりクライアント装置は、残りのバリューを待っている状態から抜け出すことが出来る。また、受信したデータが正しくないと判断して、破棄することができる。
尚、各実施形態のデータ処理装置は、例えば、汎用のコンピュータ装置を基本ハードウェアとして用いることでも実現可能である。すなわち、上記のコンピュータ装置に搭載されたプロセッサにプログラムを実行させることにより実現出来る。このとき、データ処理装置は、上記のプログラムをコンピュータ装置にあらかじめインストールすることで実現することや、各種の記憶媒体に記憶、あるいはネットワークを介して上記のプログラムを配布、このプログラムをコンピュータ装置に適宜インストールすることで実現が出来る。また、データ処理装置内の各記憶部は、上記のコンピュータ装置に内蔵あるいは外付けされたメモリ、ハードディスクもしくはCD−R、CD−RW、DVD−RAM、DVD−Rなどの記憶媒体などを適宜利用して実現することができる。
本発明は上記実施形態そのままに限定されず、実施段階では要旨を逸脱しない範囲で構成要素を変形し具体化出来る。上記実施形態に開示されている複数の構成要素の適宜な組み合わせで、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除出来、異なる実施形態に渡る要素を適宜組み合わせることも出来る。
21〜23:クライアント装置
11:データ処理装置
31:KV記憶装置
101:要求受信部
102:要求バッファ部
103;KV記憶部
104:分割キー生成部
105:KV処理部
106:応答送信部
109:障害検知部
110:削除分割キー生成部
201:要求受信部
202:要求バッファ部202
203:分割キー生成部
204:KV処理部
205;KV記憶部
206:継続判断部
207:応答送信部
208:障害検知部
209:通信切断部
210:ダミーデータ生成部

Claims (24)

  1. 第1キーと第1データとを含む書き込み要求を受信する要求受信部と、
    前記書き込み要求に含まれる前記第1データを一時的にバッファリングするバッファ部と、
    前記バッファ部における前記第1データのバッファリング状況に応じて、前記バッファ部にバッファリングされている前記第1データのうちまだ読み出していない一部データである第2データを読み出し、前記第1データにおける前記第2データの位置に応じた第2キーを、前記第1キーに基づき生成するキー生成部と、
    前記第2データを含むデータ構造体を、前記第2キーに関連づけて、内部または外部の記憶装置に書き込処理部と
    を備えたデータ処理装置。
  2. 前記キー生成部は、前記バッファ部における前記第1データのバッファリング状況として、前記バッファ部にバッファリングされておりかつ前記第1データの先頭側からまだ読み出されていない連続するバイト列のデータサイズに応じて、前記第2データの読み出しを行う
    請求項1に記載のデータ処理装置。
  3. 前記キー生成部は、前記データサイズが一定値に達したとき、前記一定値のサイズ分の連続するバイト列の前記第2データを前記第1データの先頭側から読み出す
    請求項2に記載のデータ処理装置。
  4. 前記処理部は、前記第2データを含むデータ構造体に、前記第2データに対して生成された前記第2キーをさらに含める
    請求項1ないし3のいずれか一項に記載のデータ処理装置。
  5. 前記処理部は、前記第2データが前記第1データの先頭を含む場合、前記第2データを含むデータ構造体に、前記第1データのサイズ情報をさらに含める
    請求項1ないし4のいずれか一項に記載のデータ処理装置。
  6. 前記キー生成部は、前記バッファ部から読み出した前記第2データが前記第1データの末尾を含むかを判断し、
    前記処理部は、前記第2データが前記第1データの末尾を含むかを識別する後続有無識別情報を前記データ構造体に含める、
    請求項1ないし5のいずれか一項に記載のデータ処理装置。
  7. 前記書き込み要求は、前記第1データのサイズ情報を含み、
    前記キー生成部は、前記第1データのサイズ情報に基づき、前記バッファ部からの読み出しを何回行うかの回数情報を計算し、
    前記処理部は、前記第2データが前記第1データの先頭を含む場合、前記第2データを含むデータ構造体に、前記回数情報をさらに含める
    請求項1ないし6のいずれか一項に記載のデータ処理装置。
  8. 前記書き込み要求は、前記第1データのサイズ情報を含み、
    前記キー生成部は、前記第1データのサイズが所定サイズ以下のときは、前記第1データの全部が前記バッファ部にバッファリングされたら、前記第1データの全部を読み出し、
    前記第2データは、前記第1データの全部、または前記第1データの一部のデータである
    請求項1ないし7のいずれか一項に記載のデータ処理装置。
  9. 前記記憶装置は、第1記憶部と、前記第1記憶部よりもアクセス速度が遅い第2記憶部とを備え、
    前記第1データの先頭を含む前記第2データを含む前記データ構造体は、前記第1記憶部に格納する
    請求項1ないし8のいずれか一項に記載のデータ処理装置。
  10. 前記記憶装置の障害を検知する障害検知部と、
    前記書き込み要求に対する処理が完了する前に、前記記憶装置の故障が検知された場合に、前記記憶装置に書き込み済みの前記データ構造体を削除する前記第2キーを生成する削除処理部と、
    前記処理部は、前記削除処理部により生成された前記第2キーに対応する前記データ構造体を前記記憶装置から削除する
    請求項1ないし9のいずれか一項に記載のデータ処理装置。
  11. 前記障害検知部により前記記憶装置の障害が検知されたとき、前記書き込み要求の実行がエラーになったことの応答を送信する応答送信部
    をさらに備えた請求項10に記載のデータ処理装置。
  12. 前記キー生成部は、前記第1キーに、前記第1データにおける前記第2データの位置に応じた固定長の識別子を付与することにより前記第2キーを生成する
    請求項1ないし11のいずれか一項に記載のデータ処理装置。
  13. 前記処理部は、前記第2キーと、前記データ構造体の書き込みアドレスとの対応を、対応情報に登録する
    請求項1ないし12のいずれか一項に記載のデータ処理装置。
  14. 第1キーを指定した、第1データの読み出し要求を受信する要求受信部と、
    前記読み出し要求に含まれる前記第1キーに基づき、前記第1データにおいて前記第1データの一部または全部のデータである第2データの位置に応じた第2キーを生成するキー生成部と、
    前記第2キーに基づき、内部または外部の記憶装置から、前記第2キーに関連づけられた、前記第2データを含むデータ構造体を読み出す処理部と、
    前記処理部により読み出されたデータ構造体に含まれる第2データを送信する応答送信部と、
    前記キー生成部で生成された前記第2キーに対応する前記第2データが前記第1データの末尾を含むか判断する判断部と、を備え
    前記キー生成部は、前記判断部で前記第1データの末尾を含まないと判断された場合は、前記第1データにおいて前記第1データの末尾を含まないと判断された前記第2データに後続する一部の連続するバイト列のデータである前記第2データの位置に応じて前記第2キーを生成する
    データ処理装置。
  15. 前記第1データの先頭を含む前記第2データを含む前記データ構造体は、前記第1データのサイズ情報を含み、
    前記判断部は、前記第1データのサイズ情報と、前記記憶装置からこれまで読み出された前記第2データのサイズに基づき、前記第1データの末尾を含む前記第2データが読み出されたかを判断する
    請求項14に記載のデータ処理装置。
  16. 前記第2データを含む前記データ構造体は、前記第2データが前記第1データの末尾を含むかを識別する後続有無識別情報を含み、
    前記判断部は、前記記憶装置から読み出された前記データ構造体に含まれる前記後続有無識別情報に基づき、前記データ構造体に含まれる前記第2データが、前記第1データの末尾を含むかを判断する
    請求項14に記載のデータ処理装置。
  17. 前記第1データの先頭を含む前記第2データを含む前記データ構造体は、読み出しの回数情報を含み、
    前記判断部は、前記回数情報に応じた回数だけ前記記憶装置からの読み出しが行われたかに応じて、前記第1データの末尾を含む第2データが読み出されたかを判断する
    請求項14に記載のデータ処理装置。
  18. 前記キー生成部は、前記第1キーに、前記第1データにおける前記第2データの位置に応じた固定長の識別子を付与することにより、前記第2キーを生成する
    請求項14ないし17のいずれか一項に記載のデータ処理装置。
  19. 前記記憶装置の障害を検知する障害検知部と、
    前記読み出し要求の実行が完了する前に、前記記憶装置の故障が検知された場合に、前記読み出し要求の送信元装置と前記読み出し要求に関する通信コネクションを切断するコネクション切断部
    を備えた請求項14ないし18のいずれか一項に記載のデータ処理装置。
  20. 前記記憶装置の障害を検知する障害検知部と、
    前記読み出し要求に応じた前記記憶装置からの読み出しが完了する前に、前記記憶装置の故障が検知された場合に、前記第1データのうちまだ前記記憶装置からの読み出しが完了していないデータサイズ分のダミーデータを生成するダミーデータ生成部と、を備え、 前記応答送信部は、前記ダミーデータを、前記読み出しが完了していないデータサイズ分のデータを送信する代わりに送信する
    請求項14ないし18のいずれか一項に記載のデータ処理装置。
  21. 第1キーと第1データとを含む書き込み要求を受信する要求受信ステップと、
    前記書き込み要求に含まれる前記第1データを一時的にバッファ部にバッファリングするバッファリングステップと、
    前記バッファ部における前記第1データのバッファリング状況に応じて、前記バッファ部にバッファリングされている前記第1データのうちまだ読み出していない一部データである第2データを読み出し、前記第1データにおける前記第2データの位置に応じた第2キーを、前記第1キーに基づき生成する生成ステップと、
    前記第2データを含むデータ構造体を、前記第2キーに関連づけて記憶装置に書き込処理ステップと
    を備えたデータ処理方法。
  22. 第1キーを指定した、第1データの読み出し要求を受信する要求受信ステップと、
    前記読み出し要求に含まれる前記第1キーに基づき、前記第1データにおいて前記第1データの先頭から一部または全部の連続するバイト列のデータである第2データの位置に応じた第2キーを生成する生成ステップと、
    前記第2キーに基づき、記憶装置から、前記第2キーに関連づけられた、前記第2データを含むデータ構造体を読み出す処理ステップと、
    前記処理ステップにより読み出された前記データ構造体に含まれる第2データを送信する応答送信ステップと、
    前記生成ステップで生成された前記第2キーに対応する前記第2データが前記第1データの末尾を含むか判断する判断ステップと、を備え
    前記生成ステップは、前記判断ステップで前記第1データの末尾を含まないと判断された場合は、前記第1データにおいて前記第1データの末尾を含まないと判断された前記第2データに後続する一部の連続するバイト列のデータである前記第2データの位置に応じて前記第2キーを生成する
    データ処理方法。
  23. 第1キーと第1データとを含む書き込み要求を受信する要求受信ステップと、
    前記書き込み要求に含まれる前記第1データを一時的にバッファ部にバッファリングするバッファリングステップと、
    前記バッファ部における前記第1データのバッファリング状況に応じて、前記バッファ部にバッファリングされている前記第1データのうちまだ読み出していない一部データである第2データを読み出し、前記第1データにおける前記第2データの位置に応じた第2キーを、前記第1キーに基づき生成する生成ステップと、
    前記第2データを含むデータ構造体を、前記第2キーに関連づけて記憶装置に書き込処理ステップと
    をコンピュータに実行させるためのプログラム。
  24. 第1キーを指定した、第1データの読み出し要求を受信する要求受信ステップと、
    前記読み出し要求に含まれる前記第1キーに基づき、前記第1データにおいて前記第1データの先頭から一部または全部の連続するバイト列のデータである第2データの位置に応じた第2キーを生成する生成ステップと、
    前記第2キーに基づき、記憶装置から、前記第2キーに関連づけられた、前記第2データを含むデータ構造体を読み出す処理ステップと、
    前記処理ステップにより読み出された前記データ構造体に含まれる第2データを送信する応答送信ステップと、
    前記生成ステップで生成された前記第2キーに対応する前記第2データが前記第1データの末尾を含むか判断する判断ステップと、
    をコンピュータに実行させ、
    前記生成ステップは、前記判断ステップで前記第1データの末尾を含まないと判断された場合は、前記第1データにおいて前記第1データの末尾を含まないと判断された前記第2データに後続する一部の連続するバイト列のデータである前記第2データの位置に応じて前記第2キーを生成する、プログラム。
JP2014223490A 2014-10-31 2014-10-31 データ処理装置、データ処理方法およびプログラム Active JP6378044B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2014223490A JP6378044B2 (ja) 2014-10-31 2014-10-31 データ処理装置、データ処理方法およびプログラム
US14/847,589 US10185783B2 (en) 2014-10-31 2015-09-08 Data processing device, data processing method, and non-transitory computer readable medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2014223490A JP6378044B2 (ja) 2014-10-31 2014-10-31 データ処理装置、データ処理方法およびプログラム

Publications (2)

Publication Number Publication Date
JP2016091222A JP2016091222A (ja) 2016-05-23
JP6378044B2 true JP6378044B2 (ja) 2018-08-22

Family

ID=55852852

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2014223490A Active JP6378044B2 (ja) 2014-10-31 2014-10-31 データ処理装置、データ処理方法およびプログラム

Country Status (2)

Country Link
US (1) US10185783B2 (ja)
JP (1) JP6378044B2 (ja)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11182365B2 (en) * 2016-03-21 2021-11-23 Mellanox Technologies Tlv Ltd. Systems and methods for distributed storage of data across multiple hash tables
US10715499B2 (en) * 2017-12-27 2020-07-14 Toshiba Memory Corporation System and method for accessing and managing key-value data over networks
CN113096284B (zh) * 2021-03-19 2022-08-30 福建新大陆通信科技股份有限公司 一种ctid门禁授权信息的核验方法

Family Cites Families (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5473761A (en) * 1991-12-17 1995-12-05 Dell Usa, L.P. Controller for receiving transfer requests for noncontiguous sectors and reading those sectors as a continuous block by interspersing no operation requests between transfer requests
US5313585A (en) * 1991-12-17 1994-05-17 Jeffries Kenneth L Disk drive array with request fragmentation
US5873097A (en) * 1993-05-12 1999-02-16 Apple Computer, Inc. Update mechanism for computer storage container manager
EP1367493A1 (en) * 2002-05-30 2003-12-03 STMicroelectronics Limited Prefetch buffer
US20040049603A1 (en) * 2002-09-05 2004-03-11 International Business Machines Corporation iSCSI driver to adapter interface protocol
JP2004240514A (ja) * 2003-02-03 2004-08-26 Seiko Epson Corp 画像データ転送装置、画像データ転送方法および画像データ転送プログラムを記録した媒体
US7817721B2 (en) * 2003-05-15 2010-10-19 Lsi Corporation Posting status data in digital transport stream processing
US7958255B1 (en) * 2003-11-04 2011-06-07 Advanced Micro Devices, Inc. Partial coalescing of transmit buffers
US7783037B1 (en) * 2004-09-20 2010-08-24 Globalfoundries Inc. Multi-gigabit per second computing of the rijndael inverse cipher
JP2006338298A (ja) * 2005-06-01 2006-12-14 Sharp Corp マルチデータの分割管理方法およびそれを用いた情報端末装置
US8521955B2 (en) * 2005-09-13 2013-08-27 Lsi Corporation Aligned data storage for network attached media streaming systems
JP4912026B2 (ja) * 2006-04-27 2012-04-04 キヤノン株式会社 情報処理装置、情報処理方法
JP4234770B1 (ja) * 2007-10-10 2009-03-04 株式会社東芝 再生装置および再生制御方法
US8074014B2 (en) * 2008-03-31 2011-12-06 Microsoft Corporation Storage systems using write off-loading
US8397062B2 (en) * 2009-04-21 2013-03-12 University Of Maryland, College Park Method and system for source authentication in group communications
US8255620B2 (en) * 2009-08-11 2012-08-28 Texas Memory Systems, Inc. Secure Flash-based memory system with fast wipe feature
US9058334B2 (en) * 2010-02-11 2015-06-16 Emc Corporation Parallel file system processing
US20110276744A1 (en) 2010-05-05 2011-11-10 Microsoft Corporation Flash memory cache including for use with persistent key-value store
US8688899B2 (en) * 2010-09-28 2014-04-01 Fusion-Io, Inc. Apparatus, system, and method for an interface between a memory controller and a non-volatile memory controller using a command protocol
JP5535115B2 (ja) * 2011-03-29 2014-07-02 株式会社日立システムズ マルチスレッド型ファイル入出力システム、及びマルチスレッド型ファイル入出力プログラム
US20130179351A1 (en) * 2012-01-09 2013-07-11 George Wallner System and method for an authenticating and encrypting card reader
US9747293B2 (en) * 2012-02-28 2017-08-29 Deep Information Sciences, Inc. Method and system for storage and retrieval of information
US20150142755A1 (en) * 2012-08-24 2015-05-21 Hitachi, Ltd. Storage apparatus and data management method
US8938072B2 (en) * 2013-01-25 2015-01-20 Freescale Semiconductor, Inc. Cryptographic key derivation device and method therefor
JP2014178734A (ja) * 2013-03-13 2014-09-25 Nippon Telegr & Teleph Corp <Ntt> キャッシュ装置、データ書込方法及びプログラム
US9350550B2 (en) * 2013-09-10 2016-05-24 M2M And Iot Technologies, Llc Power management and security for wireless modules in “machine-to-machine” communications
JP6189266B2 (ja) 2014-08-20 2017-08-30 東芝メモリ株式会社 データ処理装置、データ処理方法及びデータ処理プログラム
JP6268116B2 (ja) 2015-03-20 2018-01-24 東芝メモリ株式会社 データ処理装置、データ処理方法およびコンピュータプログラム

Also Published As

Publication number Publication date
US20160124950A1 (en) 2016-05-05
JP2016091222A (ja) 2016-05-23
US10185783B2 (en) 2019-01-22

Similar Documents

Publication Publication Date Title
US11003719B2 (en) Method and apparatus for accessing a storage disk
JP5514913B2 (ja) フローアウェアネットワークノード内でデータパケットを処理するための方法
JP6564937B2 (ja) コンテンツ指向ネットワーキング(ccn)ネットワークにおいてデータをプッシュするための方法および装置
US7287136B2 (en) Cache device, and method and computer program for controlling cached data
JP5967673B2 (ja) データメンテナンス用の方法
WO2020199760A1 (zh) 数据存储方法、存储器和服务器
US9952778B2 (en) Data processing method and apparatus
JP6268116B2 (ja) データ処理装置、データ処理方法およびコンピュータプログラム
CN110235098A (zh) 存储系统访问方法及装置
US20240039995A1 (en) Data access system and method, device, and network adapter
JP6378044B2 (ja) データ処理装置、データ処理方法およびプログラム
JP2019016042A (ja) データ取得プログラム、装置、及び方法
JP2015156071A (ja) データ格納方法、ストレージシステム、プログラム及びストレージ装置
US9137780B1 (en) Synchronizing multicast data distribution on a computing device
US8914436B2 (en) Data processing device and data retriever
WO2023125630A1 (zh) 一种数据管理方法及相关装置
CN110199270B (zh) 存储系统中存储设备的管理方法及装置
WO2014153931A1 (zh) 文件存储方法、装置、访问客户端及元数据服务器系统
WO2017177400A1 (zh) 一种数据处理方法及系统
TWI420333B (zh) 分散式的重複數據刪除系統及其處理方法
JP2018504689A5 (ja)
WO2016065610A1 (zh) 访问文件的方法、分布式存储系统和存储节点
JP5494817B2 (ja) ストレージシステム、データ管理装置、方法及びプログラム
WO2019201091A1 (zh) 一种数据处理方法、设备和计算机可读存储介质
JP2017123040A (ja) サーバー装置、分散ファイルシステム、分散ファイルシステム制御方法、および、プログラム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20170301

A711 Notification of change in applicant

Free format text: JAPANESE INTERMEDIATE CODE: A712

Effective date: 20170608

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20171226

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20180112

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20180208

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20180629

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20180726

R150 Certificate of patent or registration of utility model

Ref document number: 6378044

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313111

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350