JP2013200839A - 半導体記憶装置、情報処理システムおよび制御方法 - Google Patents

Abstract

【課題】ＫＶＳデータを取り出す処理を簡素かつ高速に行う。
【解決手段】半導体記憶装置は、記憶部と、受付部と、取得部と、出力制御部と、を備える。記憶部は、バリュー、および、バリューに対応するキーに基づいて生成されるキーアドレスとバリューの物理アドレスとを対応づけるアドレス情報を記憶する。受付部は、キーを含む、当該キーに対応するバリューの取得要求を受け付ける。取得部は、アドレス情報に基づいて、取得要求に含まれるキーのキーアドレスに対応する物理アドレスを取得する。出力制御部は、取得された物理アドレスのバリューを記憶部から取得し、取得したバリューを、取得要求に対する応答として出力する。
【選択図】図２

Description

本発明の実施形態は、半導体記憶装置、情報処理システムおよび制御方法に関する。

一般的なホストシステム、例えばコンピュータシステムが備えるストレージ装置として、磁気式のハードディスクドライブ（ＨＤＤ）、不揮発性半導体メモリを搭載する固体ドライブ（ＳＳＤ）、および、埋め込みＮＡＮＤフラッシュメモリなどが存在する。ＳＳＤや埋め込みＮＡＮＤフラッシュメモリはストレージに分類されるが、規模が拡張されたメモリシステムとも言える。

このようなメモリシステムは、例えばインタフェースと、第１のメモリブロックと、第２のメモリブロックと、コントローラとを備える。第１のメモリブロックはデータを格納する。第２のメモリブロックはデータ書き込み／読み出し時のバッファメモリである。第１のメモリブロックは、不揮発性メモリであり、第２のメモリブロックよりも大容量であるが、アクセス速度が遅い。第２のメモリブロックは、第１のメモリブロックのアドレス変換テーブルを処理するための一時保存メモリである。また、第２のメモリブロックは、インタフェースの通信速度と、第１のメモリブロックの書き込み／読み出し速度との速度差を補うためにも使用される。

例えば、第１のメモリブロックは不揮発性のフラッシュメモリであり、第２のメモリブロックは揮発性のＤＲＡＭまたはＳＲＡＭである。このような従来のストレージ型のメモリシステムでは、アドレスを指定したデータの書き込み／読み出し機能を実現するための構成をとっている。特に、ＳＳＤなどの大容量メモリシステムでは、フラッシュメモリ管理のために論理アドレスと物理アドレスとを分けて管理している。２種類のアドレスを使い分けることにより、管理が容易になる。

一方、メモリシステムに保存されている、あるテキストに関連付けられた別のテキスト、バイナリファイルにおける特定のビットパターン、動画ファイルにおける特定パターン、および、音声ファイルにおける特徴的な音声パターンなどのデータを効率的取り出すためには、データを指定したデータ読出し機能を持たせることが望ましい。このため、通常のデータ保存のみならず、データに関連付けられたメタデータを付属させて保存しておき、所望のデータを得るためにメタデータを参照する方法が用いられる。

メタデータの管理方法の１つとして、１対１または１対多にデータが対応するＫＶＳ（ｋｅｙ−ｖａｌｕｅ ｓｔｏｒｅ（キーバリューストア））が存在する。ＫＶＳでは、検索要求としてキー（ｋｅｙ）が与えられると、それに対応付けられるバリュー（ｖａｌｕｅ）が出力される。

特許第４５５１９５８号公報 特開２００５−２０９２１４号公報

しかしながら、従来システムでＫＶＳを実現するには、メモリシステム内に格納されたデータや複数のメタデータを、ホストシステムの主記憶装置（ＤＲＡＭなど）にデータを展開した上で、中央演算装置（ＣＰＵ）を使用して演算を施した後に、再びストレージ（メモリシステム）からデータを読み出して照合するという、繰り返しのデータ入出力処理を実行する必要があった。

実施形態の半導体記憶装置は、記憶部と、受付部と、取得部と、出力制御部と、を備える。記憶部は、バリュー、および、バリューに対応するキーに基づいて生成されるキーアドレスとバリューの物理アドレスとを対応づけるアドレス情報を記憶する。受付部は、キーを含む、当該キーに対応するバリューの取得要求を受け付ける。取得部は、アドレス情報に基づいて、取得要求に含まれるキーのキーアドレスに対応する物理アドレスを取得する。出力制御部は、取得された物理アドレスのバリューを記憶部から取得し、取得したバリューを、取得要求に対する応答として出力する。

第１の実施形態にかかる半導体記憶装置のハードウェア図。 デバイス制御部のブロック図。 Ｌ２Ｐテーブルを使ったアクセスを説明する図。 Ｋ２Ｐテーブルのデータ形式の一例を示す図。 Ｋ２Ｐテーブルのデータ形式の一例を示す図。 Ｋ２ＰテーブルをＬ２Ｐテーブルと独立に管理する例を示す図。 Ｋ２ＰテーブルとＬ２Ｐテーブルとを１つのテーブルで管理する例を示す図。 キーアドレスの衝突について説明する図。 Ｐ２Ｋテーブルのデータ形式の一例を示す図。 Ｐ２Ｌ／Ｐ２Ｋテーブルのデータ形式の一例を示す図。 登録コマンドを受け付けた場合の処理のフローチャート。 書込コマンドを受け付けた場合の処理のフローチャート。 取得コマンドを受け付けた場合の処理のフローチャート。 読出コマンドを受け付けた場合の処理のフローチャート。 物理ブロックテーブルを用いる場合のデータアクセスの仕組みを説明する図。 変形例１の物理ブロックテーブルのデータ形式の一例を示す図。 多段階の検索テーブルを用いる変形例２を説明する図。 変形例３のＫ２Ｐテーブルのデータ形式の一例を示す図。 ２種類のハッシュ関数を用いる例を説明する図。 第２の実施形態にかかる半導体記憶装置のハードウェア図。 ＣＡＭを用いた検索処理例を説明する図。 第３の実施形態にかかる半導体記憶装置のハードウェア図。 第４の実施形態にかかる半導体記憶装置のハードウェア図。 第４の実施形態の変形例にかかる半導体記憶装置のハードウェア図。 第５の実施形態にかかる半導体記憶装置のハードウェア図。

以下に添付図面を参照して、この発明にかかる半導体記憶装置の好適な実施形態を詳細に説明する。

以下では、従来システムとして、ＳＳＤを想定して説明する。以下の実施形態では、ＳＳＤは、広い意味でのＮＡＮＤフラッシュベースの固体メモリによるストレージを意味し、埋め込みＮＡＮＤフラッシュメモリシステムも含む。また、実施形態のＳＳＤは、それらよりも大型のサーバ向けストレージも含まれる。

ＳＳＤでのＫＶＳの実現方法とその問題点を説明する。従来型ＳＳＤでＫＶＳを実現する場合、例えば、データ（実データ）はファイルとして保存され、データに付属するキーバリュー型のメタデータ（ＫＶＳデータ）もまたファイルとして保存される。すなわちＫＶＳを実現しているのはファイルシステム以上の上位システムである。例えば、ＯＳ（オペレーティングシステム）に実装されたファイルシステムまたはアプリケーションがＫＶＳを実現する。この場合、汎用的なハードウェア構成でＫＶＳを実現できるという利点がある。しかしこの場合、ＫＶＳの取り扱いは、通常のデータと同じである。このため、例えばホストシステムがＫＶＳデータファイルをメインメモリ（例えばＤＲＡＭ）に読み出してから、メタデータ（ＫＶＳデータ）の読み出し／書き込み操作および検索操作を行うことになる。従って、ソフトウェア（ＳＷ）としての取り扱い以上の効果は期待できない。

一方、ＳＳＤの読み出し／書き込みの過程では、ＮＡＮＤフラッシュメモリのハードウェア（ＨＷ）の仕組みに基づいてアドレス変換が行われる仕組みになっている。ＮＡＮＤフラッシュメモリは、読み出し／書き込み時に、例えば４ＫＢや８ＫＢなどのページ単位でアクセスされる。一方、ＮＡＮＤフラッシュメモリは、例えば５１２ＫＢや１０２４ＫＢなどのページを複数まとめたブロックと呼ばれる単位で消去される仕組みとなっている。

通常、同一ページのデータ更新はできないので、更新されたデータは新しいページに書き込むことになる。このため、使われているページと使われていないページを管理するアドレス管理テーブルが必要となる。また同じページへの書き込みが集中しないように、書き込みアドレスをランダムに選択するようにしている。このため、使用している物理アドレス（物理ページアドレス）と、ホストシステム側やメモリ制御部（後述）が指定する論理アドレス（論理ページアドレス）の変換テーブルが必要になる。これが論理（Ｌｏｇｉｃａｌ）アドレス物理（Ｐｈｙｓｉｃａｌ）アドレス変換テーブルであり、通称Ｌ２Ｐテーブルと呼ばれる。Ｌ２Ｐテーブルでデータを管理することにより、ＳＳＤの寿命が向上することになるが、その反面、データ管理の仕組みは複雑化する。

以下の実施形態の半導体記憶装置は、例えばＮＡＮＤフラッシュメモリなどから構成される不揮発性メモリシステムであって、ＫＶＳデータ（キーバリュー情報）を、アドレス変換テーブルによって効率的かつ高速に処理する。また、通常のアドレス指定データ出力のためのアドレス変換テーブルとＫＶＳのためのアドレス変換テーブルとを共存させて、効率よく動作させる。なお、以下では半導体記憶装置を、メモリシステムまたはデバイスともいう。

次に、各実施形態に共通するＫＶＳデータの詳細について説明する。メモリシステムのメモリアクセス可能なアドレス空間内には、アドレス指定で実データにアクセス可能なデータ格納領域（実アドレス空間）と、ＫＶＳデータ格納領域とが存在する。実アドレス空間は、例えば従来の論理アドレス空間に対応する。ＫＶＳデータ格納領域は、メモリシステム側が適宜用いるデータ領域である。従って、ユーザまたはクライアントは、メモリシステムのインタフェースに対するＫＶＳコマンドによってアクセスする。

ここでＫＶＳコマンドの一例について説明する。ホストシステムからは、メモリシステムのホストインタフェースに対し、ＫＶＳに対する操作要求（ＫＶＳ要求）のための、次のＫＶＳコマンドが与えられる。
・登録コマンド（ＰＵＴ）：キーに関連付けられた新たな集合（バリュー）を登録する。
・書込コマンド（ＡＰＰＥＮＤ）：あるキーに関連付けられた集合（バリュー）に新たな要素（バリュー）を追加する。
・取得コマンド（ＧＥＴ）：キーに関連付けられた集合（バリュー）の要素をワークメモリ（またはバッファメモリ）に格納しそのサイズを返す。
・読出コマンド（ＲＥＡＤ）：ワークメモリ（またはバッファメモリ）に格納されている要素（バリュー）を読み出す。

コマンド名称は適宜変更されてもよい。ＫＶＳ要求のために新たなコマンドが追加されてもよい。例えば、集合（キー）に属する要素（バリュー）を整理するためのコマンドを用いてもよい。また、Ｋ２Ｐテーブル（後述）内の集合（キー）の並び替え、および、要素（バリュー）同士の比較などを命令するコマンドを用いてもよい。

メモリシステムは、Ｌ２ＰテーブルとＫ２Ｐテーブルとを有する。Ｌ２Ｐテーブルは、論理アドレスと物理アドレスの変換テーブルである。Ｋ２Ｐテーブルは、キーから得た固定長アドレス（キーアドレス）と物理アドレスの変換テーブルである。メモリシステム（デバイス）を制御するデバイス制御部（詳細は後述）は、ホストシステムからの要求に応じてこれら２種類のテーブルを使い分け、実アドレス空間へのアクセスと、ＫＶＳデータへのアクセスとを行う。

Ｋ２Ｐテーブルは必要に応じて作られるので、ホストシステムから作成が要求されなければ、第１のメモリブロック内に存在しない場合も有り得る。このように、ＫＶＳデータおよびＫ２Ｐテーブルは固定されて設置されているわけではなく、任意に拡張および縮小されて存在できる。このため、ユーザはＫＶＳデータを任意に扱いつつ、アクセス可能な物理メモリ空間を最大効率で利用可能となる。

ＫＶＳデータおよびＫ２Ｐテーブルの管理は、デバイス側（ローカルシステム側）の機能である。このため、ホストシステム側はメタデータ（ＫＶＳデータ）の管理から開放されている。

ＫＶＳデータおよびＫ２Ｐテーブルの実態は、第１のメモリブロックの物理ページに格納されている。通常のＬ２Ｐテーブルでアクセスすることも可能であるし、Ｌ２Ｐテーブルでアクセスできない特別領域として管理することも可能である。これらに関しては後述の実施形態で説明する。

次に、ＫＶＳデータを取り出す処理の具体例を説明する。一般的にＫＶＳとは、キー（ｋｅｙ）と値（ｖａｌｕｅ）の組を書き込み、キーを指定することで値を読み出せるデータベース管理方式を意味する。一般的にはネットワーク越しに使われる例が多い。データの格納先は、いずれかのローカルのメモリまたはストレージシステムであることは間違いない。

データは通常、保存されているメモリの先頭アドレスとデータ長を指定することで読み出される。データアドレスは、ホストシステムのＯＳやファイルシステムによって、例えば５１２バイトのセクタ単位で管理される。または、ファイルシステムを限定する必要がなければ、例えばＮＡＮＤフラッシュメモリの読み出し／書き込みページサイズに合わせて、４ＫＢや８ＫＢ単位で管理されてもよい。

最も単純な検索手順は、以下の（１）〜（３）のようになる。
（１）キーをＨａｓｈ関数などにより固定長データへ変換し、その固定長データを使用可能なメモリのアドレスに変換して固定長アドレスを得る。変換した固定長アドレスをキーアドレスとする。
（２）ＮＡＮＤフラッシュメモリ内に保存されているＫ２Ｐテーブルを参照し、物理アドレスを得る。
（３）物理アドレスのデータを読み、メモリシステム外へ出力する。

このような実データアドレスとＫＶＳデータの関係、および、キーとバリューの関係は、要素と集合の関係となっている。すなわち、通常のファイルでは、例えば「ａ−ｆｉｌｅ．ｔｘｔ」というファイル名のファイルが集合であり、そのファイルの中身に「Ｔｈｉｓ ｉｓ a ｂｏｏｋ」というテキストデータがあれば、そのそれぞれの単語が要素である。

一方、キーバリューでは集合と要素の関係が逆転して整理し直すことができる。すなわち、「転置」の関係に変換して保存することができる。例えば「ｂｏｏｋ」という集合の中には、「ａ−ｆｉｌｅ．ｔｘｔ」、「ｂ−ｆｉｌｅ．ｔｘｔ」というファイル名が要素として保存されることになる。キーバリューでは、この整理しなおされた集合名（「ｂｏｏｋ」）を検索し、その要素（「ａ−ｆｉｌｅ．ｔｘｔ」、「ｂ−ｆｉｌｅ．ｔｘｔ」）を求めていることになる。これは一般に全文検索で実行されている転置ファイル作成、および、検索手順そのものであって、キーバリューの実用上の一例といえる。

転置ファイルとは、全文検索機能の実現法の１つである転置インデックス法で用いられる検索のための索引ファイルである。転置インデックス法では、コンテンツごとに、当該コンテンツを含むファイルのリストを格納する転置ファイルと呼ばれる索引データファイルを予め作成する。そして、ファイルの追加／削除の都度、転置ファイルの内容を更新する。コンテンツ検索要求に対しては、検索対象のコンテンツに対応する転置ファイルの内容を検索結果として出力すればよい。そのため、全文検索の都度、すべてのファイルの内容を調べる必要がない。従って、検索を高速化できる。転置ファイルは、ＫＶＳデータの１つの用例である。本実施形態のＫＶＳデータは転置ファイルに限定されるものではない。また、本実施形態は全文検索に特化した技術ではない。

以下、各実施形態の詳細について説明する。

（第１の実施形態）
図１は、第１の実施形態にかかる半導体記憶装置であるデバイス１００およびホストシステム２００のハードウェア構成の一例を示すブロック図である。図１に示すように、ホストシステム２００は、ＣＰＵ２０１と、メインメモリ２０２と、ＣＰＵ２０１およびメインメモリ２０２を接続するバス２１１と、を備えている。

デバイス１００は、ホストインタフェース１０１と、デバイス制御部１１０と、メモリ制御部１２０と、記憶部１３０と、を備えている。

ホストインタフェース１０１、デバイス制御部１１０、およびメモリ制御部１２０は、バス１０２を介して接続される。デバイス１００内では、高速かつ効率的なバス線配置を取られることが望ましい。一方、例えばインタフェース規格と外部インタフェース規格の相違などで、２種類以上のバス線がデバイス１００内で用いられていてもよい。

ホストシステム２００は、例えばＡＭＢＡ（Advanced Microcontroller Bus Architecture）、などのバス２１１を介してホストインタフェース１０１に接続される。ホストインタフェース１０１は、ＳＡＴＡ（Serial Advanced Technology Attachment）、ＰＣＩ Ｅｘｐｒｅｓｓ、ｅＭＭＣ（embedded MMC）、ＵＦＳ（(Universal Flash Storage)」）および、ＵＳＢ（Universal Serial Bus）などを適宜選択する。

ホストインタフェース１０１は、ホストシステム２００からアドレス指定による通常のデータ操作要求とＫＶＳ要求とを受け付けることができる。

第１のメモリブロックに相当する記憶部１３０は、実データブロック１３１と、テーブルブロック１３２と、ＫＶＳデータブロック１３３と、を含む。実データブロック１３１は、実データを記憶するブロックを表す。テーブルブロック１３２は、各種テーブルを記憶するブロックを表す。ＫＶＳデータブロック１３３は、ＫＶＳデータを記憶するブロックを表す。

テーブルブロック１３２は、例えばＬ２Ｐテーブル１３２ａと、Ｋ２Ｐテーブル１３２ｂと、Ｐ２Ｌ／Ｐ２Ｋテーブル１３２ｃと、を記憶する。ＫＶＳデータブロック１３３は、例えば実データから抽出したＫＶＳデータを格納する。後述するように、Ｋ２Ｐテーブル１３２ｂを用いれば、キーに対応するバリューの物理アドレスを特定できる。このため、ＫＶＳデータは、少なくともバリューを含んでいればよく、キーを含まなくてもよい。

ＫＶＳ要求を処理するためには、少なくともＫ２Ｐテーブル１３２ｂが記憶されていればよい。Ｐ２Ｌ／Ｐ２Ｋテーブル１３２ｃは、実データおよびＫＶＳデータの追加や修正を行う場合に用いる逆引きテーブルである（詳細は後述）。Ｌ２Ｐテーブル１３２ａを備えない場合は、Ｋ２Ｐテーブル１３２ｂに対応する逆引きテーブル（Ｐ２Ｋテーブル）のみを備えればよい。

記憶部１３０は、例えば不揮発性半導体メモリのＮＡＮＤフラッシュメモリである。記憶部１３０は、記憶容量を増大させるため複数のチップで構成されていてもよい。記憶部１３０は、これに限定されるものではなく、記憶不揮発性を有する半導体メモリであればあらゆる記憶媒体を適用できる。例えば、記憶部１３０として、ＭＲＡＭ（Magnetoresistive Random Access Memory）やＲｅＲＡＭ（Resistance Random Access Memory）やＦｅＲＡＭ（Ferroelectric Random Access Memory）やＰＣＲＡＭ（Phase-Change Random Access Memory）などの不揮発性メモリを用いてもよい。

ＫＶＳデータは、データに関連付けられたメタデータとしてのキーと、関連付けられたデータの実データアドレスの先頭アドレスとを、例えばリストとして格納する。このＫＶＳデータを用いて、例えば、上述した転置ファイルなどを構成することができる。

メモリ制御部１２０は、記憶部１３０への書き込み／読み出し要求を受付け、書き込み／読み出し要求に応じて記憶部１３０に対するアクセスを制御する。メモリ制御部１２０は、書き込みまたは読み出しを行う際に一時的に使用する第２のメモリブロックとしてのバッファメモリ１２１を備える。バッファメモリ１２１は、例えば記憶部１３０の多値動作を制御するための演算機能を備えてもよい。メモリ制御部１２０と記憶部１３０は近い位置に接続されており、１つのチップ内に収めることができる。また、チップを分けた場合でも１つのパッケージに収めることもできる。記憶部１３０の多値動作を制御するための演算機能は、記憶部１３０内に備わっていてもよい。

デバイス制御部１１０は、ホストインタフェース１０１と、メモリ制御部１２０を介して記憶部１３０の相互の信号送受信を制御する。デバイス制御部１１０は、ＲＡＭなどのワークメモリ１１１を備える。

デバイス制御部１１０は、記憶部１３０から出力されたデータに対するエラー訂正符号復号（ＥＣＣ）機能を備えてもよい。また、デバイス制御部１１０は、記憶部１３０の論理アドレス物理アドレス変換を行うことができる。ＥＣＣ機能は、メモリ制御部１２０に備わっている場合がある。同様に、ＥＣＣ機能は、記憶部１３０に備わっている場合がある。２種類以上のＥＣＣ機能が別々のブロックに備わっている場合がある。本実施形態ではメモリ制御部１２０に備わっていることを前提とし、データ読み出しの際にはＥＣＣ処理が施されてからデバイス制御部に伝えられるものとする。

メモリ制御部１２０のバッファメモリ１２１は、これら処理のために用いてもよい。バッファメモリ１２１に相当する第２のメモリブロックは、メモリ制御部１２０の内部にあることは必須ではなく、デバイス制御部１１０の外部にバス線を介して接続されていてもよい。第２のメモリブロックは必須ではなく、第２のメモリブロック（バッファメモリ１２１）を備えないように構成してもよい。ただし、デバイス制御部１１０が第２のメモリブロックを利用できるのであれば、ＫＶＳデータを記憶部１３０から第２のメモリブロック内へ読み出して参照することができる。

なお、第２のメモリブロックは、例えば揮発性であり、かつ、記憶部１３０に比べて小容量であるがアクセス速度が速い記憶媒体が用いられる。例えば、第２のメモリブロックは揮発性のＤＲＡＭまたはＳＲＡＭである。または、同等の速度と容量が得られれば不揮発性のＭＲＡＭなどでもよい。

第２のメモリブロックは、ホストインタフェース１０１の通信速度と、記憶部１３０のアクセス速度との速度差を補うために使用される。記憶部１３０にフラッシュメモリを用いたメモリシステムであれば、デバイス制御部１１０、第２のメモリブロック、およびＬ２Ｐテーブル１３２ａを用いて、ウェアレベリング（メモリセル寿命の平坦化）機能を備えるのが一般的である。各実施形態でこのようなウェアレベリング機能を備えるように構成してもよい。

図２は、デバイス制御部１１０の機能構成の一例を示すブロック図である。図２に示すように、デバイス制御部１１０は、受付部１１２と、取得部１１３と、出力制御部１１４と、書込部１１５と、転記処理部１１６と、生成部１１７と、を備えている。

受付部１１２は、キーに対応するバリューの取得要求を受け付ける。

取得部１１３は、記憶部１３０から各種データを読み出す。例えば、取得部１１３は、記憶部１３０に記憶されたＫ２Ｐテーブル１３２ｂを用いて、取得要求に含まれるキーのキーアドレスに対応するバリューの物理アドレスを取得する。また、取得部１１３は、物理アドレスのバリューをＫＶＳデータから読み出す。

書込部１１５は、記憶部１３０に対して各種データを書き込む。書込部１１５が、ウェアレベリング機能を備えてもよい。例えば、書込部１１５は、Ｐ２Ｋテーブルに記憶された書換え回数（書換え頻度）を参照し、書換え回数が小さい物理ページを優先して使用するように構成してもよい。

出力制御部１１４は、読み出されたバリューを取得要求に対する応答として出力する。

転記処理部１１６は、ガベージコレクションおよびコンパクションを実行する。ガベージコレクションとは、ブロック内の不使用ページを整理する処理である。コンパクションとは、離散化した使用中ページを１つの物理ブロックにまとめて空きブロックを確保する処理である。

生成部１１７は、キーに対応する固定長のキーアドレスを生成する。生成部１１７は、例えばハッシュ関数を生成する機能を有する電子回路などにより実現できる。この電子回路は、専用回路、および、ハッシュ関数アルゴリズムを入力した汎用回路のいずれを用いてもよい。ハッシュ関数を用いたデータ格納方法および検索方法は後述する。

なお、図２に示す各部の全部または一部は、ハードウェア回路により実現してもよいし、デバイス制御部１１０に備えられるＣＰＵにより実行されるソフトウェア（プログラム）により実現してもよい。

このプログラムは、例えばＲＯＭ等に予め組み込んで提供される。または、第１のメモリブロックからシステムデータとして、デバイス起動時にプログラムが読み込まれる仕様にしてもよい。

本プログラムを、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ（Compact Disk Read Only Memory）、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ（Compact Disk Recordable）、ＤＶＤ（Digital Versatile Disk）等のコンピュータで読み取り可能な記録媒体に記録されてコンピュータプログラムプロダクトとして提供するように構成してもよい。

また、本プログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成してもよい。また、本プログラムをインターネット等のネットワーク経由で提供または配布するように構成してもよい。

本プログラムは、上述した各部を含むモジュール構成となっており、実際のハードウェアとしてはＣＰＵ（プロセッサ）が上記記憶媒体からプログラムを読み出して実行することにより上記各部が主記憶装置上にロードされ、上述した各部が主記憶装置上に生成されるようになっている。

次に、ハッシュ関数を用いたキーアドレス作成方法について説明する。デバイス制御部１１０がハッシュ関数を生成する機能またはハッシュ関数アルゴリズムを実行できるＣＰＵを備えていると、任意長ビットデータをハッシュ関数によって固定長ビットデータに変換することができる。ここでは、この機能を用いて、生成部１１７が、任意長ビットデータのキーから、固定長ビットデータのキーアドレスを生成する例を示す。

ハッシュ関数としては、なるべく均一かつ疎な暗号学的ハッシュ関数が好ましい。例えば、ＳＨＡ−１（Ｓｅｃｕｒｅ Ｈａｓｈ Ａｌｇｏｒｉｔｈｍ−１）、ＳＨＡ−２（Ｓｅｃｕｒｅ Ｈａｓｈ Ａｌｇｏｒｉｔｈｍ−１）、ＭＤ４（ＭｅｓｓａｇｅＤｉｇｅｓｔ４）、および、ＭＤ５（ＭｅｓｓａｇｅＤｉｇｅｓｔ５）などが使用される。

例えば、ＭＤ５を用いて変換すると、「abcd」は、１６バイトすなわち１２８ビット長の「e2fc714c4727ee9395f324cd2e7f331f（１６進数）」となる。同様に、ＳＨＡ−１アルゴリズムなどのアルゴリズムを用いて変換しても特定の固定長データパターンが得られる。

生成部１１７は、ハッシュ関数に従って生成された、ある固定長ビットのビット列を、所望のビット長（ＢｉｔＬｅｎｇｔｈ）に短縮する機能を有する。例えば、生成部１１７は、次式の除算機能を有する。
＜ＫｅｙＩＤ＞＝ｈａｓｈ（＜Ｋｅｙ＞） ｍｏｄ ＢｉｔＬｅｎｇｔｈ

生成部１１７は、このようにビット除算や剰余算を行ってビット列を短縮する。生成部１１７が、単純に、生成された固定長ビットのビット列の先頭から所望の長さの分だけを切り取って使用してもよい。上記の例で、１２８ビットから３２ビットを切り取ると「e2fc714c（１６進数）」である。さらにＫＶＳを格納するメモリのアドレス単位に沿ってアドレスを揃える。例えば下位８ビットを切り捨てて「e2fc7140（１６進数）」となる。これがキーアドレスとなる。

このように生成されたキーアドレスの長さを、Ｌ２Ｐテーブル１３２ａの論理アドレス長と等しくしておけば、Ｌ２Ｐテーブル１３２ａの管理方法をそのまま利用できる。すなわち、論理アドレスを物理アドレスに変換する方法と同様に、キーアドレスを物理アドレスに変換することができる。

ハッシュ関数を用いたとしても、異なるデータからのハッシュ値が同一になる問題、いわゆるハッシュ値の衝突は、数学的には確率がゼロにはならない。

ハッシュ関数以外の、任意長から固定長を生成する簡単な方法として、「ｂｏｏｋ」を「ｂｏ」、「ｂｌｕｅ」を「ｂｌ」、「ｎｏｔｅ」を「ｎｏ」というように、先頭数バイト分を切り取って、例えばそれをＡＳＣＩＩコードで変換して、「bo（1バイト文字）」を「0x62，0x6f」のようにして固定長を生成する方法を用いてもよい。ただしこの場合も衝突の可能性が生じるので注意が必要である。

ここで、一般的なＬ２Ｐテーブル１３２ａを使ったデータアクセスの仕組みを、図３を用いて説明する。

ＳＳＤ等のデバイス１００へのデータアクセスは、ホストインタフェース１０１がコマンドを受け付けて、デバイス制御部１１０がそのコマンドを解釈して実行される（ステップＳ１１）。

例えば書き込みコマンドのときには、書き込むデータは、当該コマンドと共にホストインタフェース１０１を介して送られる。このデータは、デバイス制御部１１０がアクセス可能なＲＡＭ（例えばワークメモリ１１１）に格納される。

例えば、読み出しコマンドを実行する場合、デバイス制御部１１０は、ワークメモリ１１１に事前に読み出したＬ２Ｐテーブル１３２ａを用いて、当該コマンド内で指定された論理アドレスを物理アドレスに変換する（ステップＳ１２）。

ワークメモリ１１１内に読み出されているＬ２Ｐテーブル１３２ａに、これから読む論理アドレスが存在しない場合、デバイス制御部１１０は、記憶部１３０に保存されているＬ２Ｐテーブル１３２ａを読み出して、ワークメモリ１１１に格納する（ステップＳ１３）。その後、デバイス制御部１１０は、ワークメモリ１１１に格納したＬ２Ｐテーブル１３２ａを用いて、論理アドレスを物理アドレスに変換する。デバイス制御部１１０は、得られた物理アドレスを指定して、記憶部１３０内の物理ページにアクセスし、データを読み出す（ステップＳ１４）。

上述のように、従来はＫＶＳデータも通常のデータとして管理されていた。このため、ＫＶＳデータを読み出す際には、まずＫＶＳのための管理ファイル（転置ファイル）を通常アクセスでＬ２Ｐテーブル１３２ａを使って読み出し、さらに管理ファイルを元に特定ファイル内に保存されたＫＶＳデータを読み出していた。そして、ＫＶＳデータを読み出す際にも、Ｌ２Ｐテーブル１３２ａを参照する必要があった。このため、結局Ｌ２Ｐテーブル１３２ａへのアクセスを２回以上行う必要があった。

そこで、本実施形態では、Ｌ２Ｐテーブル１３２ａと同様のアドレス変換テーブルであるＫ２Ｐテーブル１３２ｂを用いてＫＶＳデータにアクセス可能とする。図３を用いて、Ｋ２Ｐテーブル１３２ｂを使ったＫＶＳデータへのアクセスの仕組みを説明する。

本実施形態のデバイス１００へのデータアクセスは、ホストインタフェース１０１がＫＶＳコマンドを受け付けて、デバイス制御部１１０がそのＫＶＳコマンドを解釈して実行される（ステップＳ１１）。

例えばＫＶＳコマンドが登録コマンド（ＰＵＴ）のときには、登録するデータはＫＶＳコマンドと共にホストインタフェース１０１を介して送られて、デバイス制御部１１０がアクセス可能なＲＡＭ（例えばワークメモリ１１１）に置かれる。登録するデータは、通常のデータと同じようにワークメモリ１１１に格納されてもよいし、記憶部１３０に格納する前のバッファとして他のメモリに格納されてもよい。説明を簡単化するためにワークメモリ１１１に格納されるものとする。

上述のように、本実施形態では、デバイス制御部１１０がデータの一部であるキーをアドレス（キーアドレス）に変換する仕組み（生成部１１７）を有する。例えば、キーに対応するバリューの取得要求に相当する取得コマンドを実行する場合、生成部１１７は、取得コマンド内で指定されたキーからキーアドレスを生成する（ステップＳ１５）。このキーアドレスを元に、デバイス制御部１１０は、ワークメモリ１１１内でキーアドレスと物理アドレスの変換を行う（ステップＳ１６）。

ワークメモリ１１１内に読み出されているＫ２Ｐテーブル１３２ｂに、これから読むキーアドレスが存在しない場合、デバイス制御部１１０は、記憶部１３０に保存されているＫ２Ｐテーブル１３２ｂを読み出して、ワークメモリ１１１に格納する（ステップＳ１７）。その後、デバイス制御部１１０は、ワークメモリ１１１に格納したＫ２Ｐテーブル１３２ｂを用いて、キーアドレスを物理アドレスに変換する。デバイス制御部１１０は、得られた物理アドレスを指定して、記憶部１３０内の物理ページにアクセスし、ＫＶＳデータを読み出す（ステップＳ１８）。

本実施形態によれば、ＫＶＳデータはＫ２Ｐテーブル１３２ｂで管理されているため、ＫＶＳデータを読み出す際に、Ｌ２Ｐテーブル１３２ａへのアクセスを省略して、直接記憶部１３０の物理アドレスを参照して読み出せるようになる。このため、ＫＶＳデータに対するアクセス速度が向上する。

図４−１は、Ｋ２Ｐテーブル１３２ｂのデータ形式の一例を示す図である。Ｋ２Ｐテーブル１３２ｂは、複数のエントリを含むテーブルデータの形式を取る。エントリは、キーアドレスと物理アドレスとを対応させたアドレス情報（Ｋ２Ｐペア）を少なくとも１つ含む。例えば、Ｋ２Ｐテーブル１３２ｂは、３２ビット（４バイト）のキーアドレスを、３２ビット（４バイト）の物理アドレスのペアである８バイトのＫ２Ｐペアを格納していく。アドレス長は一例であり、システムの規模に合わせて適宜変更してよい。

図４−１では、Ｋ２Ｐテーブル内にキーアドレスを格納している例を示している。図４−２のように、エントリのアドレス保存順をキーアドレス値に対応させてもよい。これにより、キーアドレスを保存する容量をなくすことができる。図４−２の例では、物理アドレス（４バイト）だけでよいので、Ｋ２Ｐテーブルの容量は、図４−１の場合に比べて半分になる。

また、１エントリあたりのＫ２Ｐペアの数は、Ｋ２Ｐテーブル１３２ｂにアクセスするデバイス制御部１１０の仕様、ワークメモリ１１１の仕様、および、記憶部１３０のページサイズなどから、速度や設計容易性などを考慮して決めればよい。例えば、Ｋ２Ｐペアのサイズが８バイトのとき、１エントリあたり８ＫＢで管理するとＫ２Ｐペアは１０００個格納される。また例えば、１エントリあたり２５６Ｂで管理するとＫ２Ｐペアは３２個格納される。

Ｋ２Ｐテーブル１３２ｂは、キーアドレスの生成に伴い、任意の拡張性を持たせることができる。例えば、ホストシステム２００からのＫＶＳコマンドの要求によって、キーアドレスが生成された場合、生成順にＫ２Ｐペアを作成していくこともできる。

この場合、Ｋ２Ｐテーブル１３２ｂ自体は小さくなるが、ランダムなキーアドレスが生成順に格納される。従って、このままＫ２Ｐペアを検索すると検索時間が増加する可能性がある。このため、検索の高速化のために、Ｋ２Ｐペアの検索のためのテーブルをさらに用意してもよい。

また反対に、Ｋ２Ｐテーブル１３２ｂは最初から固定の大きさに設定してもよい。そもそも、デバイス１００の中で記憶部１３０の容量追加の可能性がない場合、すなわち拡張性がない場合、物理ページの総数は決まっている。このため、最初からＫ２Ｐテーブル１３２ｂの大きさを固定しておいてもよい。例えばＫ２Ｐペアが８バイトで１エントリあたり８ＫＢのとき、１エントリあたり１０００ページ分の物理アドレスデータを格納していることになる。記憶部１３０の記憶容量が８ＧＢでページサイズが８ＫＢのときには、１００００００ページが存在する。従って、Ｋ２Ｐテーブル１３２ｂは１０００エントリを格納できればよい。すなわちＫ２Ｐテーブル１３２ｂの大きさは８ＭＢとなる。

どの方式を採用するかは、デバイス１００の規模および拡張性などを考慮して決めることができる。

次に、Ｋ２Ｐテーブル１３２ｂとＬ２Ｐテーブル１３２ａの管理方法について図５および図６を用いて説明する。図５は、Ｋ２Ｐテーブル１３２ｂを、Ｌ２Ｐテーブル１３２ａと独立に管理する例を示している。

本実施形態では、デバイス１００が、通常のデータを取り扱うためのＬ２Ｐテーブル１３２ａを搭載している場合、Ｌ２Ｐテーブル１３２ａおよびＫ２Ｐテーブル１３２ｂに対して同様のデータ形式を用いる。これにより、デバイス制御部１１０のアルゴリズムや命令を共通化させて、必要なハードウェアの追加分を少なくすることができる。

例えば、Ｌ２Ｐテーブル１３２ａは、論理アドレス３２ビット（４バイト）と物理アドレス３２ビット（４バイト）の合計８バイトのペアを格納する。同様に、Ｋ２Ｐテーブル１３２ｂは、キーアドレス３２ビット（４バイト）と物理アドレス３２ビット（４バイト）の合計８バイトのペア（Ｋ２Ｐペア）を格納する。

デバイス制御部１１０は、分類機能４０１を用いて、扱うべきアドレスがＬ２Ｐテーブル１３２ａのアドレスであるか、または、Ｋ２Ｐテーブル１３２ｂのアドレスであるかを判断する。デバイス制御部１１０は、判断の後は、両者を同様に処理していくことができる。

図５のように、例えば、アドレス値として「0x0000＿1000」が参照される場合であって、分類機能４０１によって、通常のデータの論理アドレスであると判断された場合は、デバイス制御部１１０はＬ２Ｐテーブル１３２ａを参照する。

また、アドレス値として「0xF356＿af14」が参照される場合であって、分類機能４０１によって、キーアドレスであると判断された場合は、デバイス制御部１１０は、Ｋ２Ｐテーブル１３２ｂを参照する。いずれかのテーブルを参照して物理アドレスが得られた後の処理は、基本的にＬ２Ｐテーブル１３２ａもＫ２Ｐテーブル１３２ｂも同様である。

分類機能４０１は、いくつかの方法で実現できる。１つ目は、デバイス制御部１１０がホストシステム２００からの要求（コマンド）を保持しているときに、保持するコマンドがＫ２ＰコマンドであればＫ２Ｐテーブル１３２ｂを読み、通常のデータアドレス指定のコマンドであればＬ２Ｐテーブル１３２ａを読む方法である。

分類機能４０１の方法の２つ目は、分類のためのテーブル（分類テーブル）を設けておき、論理アドレスとキーアドレスのいずれを参照すべきか判断する方法である。分類テーブルを用いる場合は、論理アドレスとキーアドレスとが衝突しないようにキーアドレスの生成の段階で管理しておく必要がある。例えば、論理アドレスとして「0x0000＿1000」が既に使用されていて、生成したキーアドレスが偶然「0x0000＿1000」となったとする。この場合は、アドレスが衝突しているので、分類テーブル内でキーアドレスであることを判断してＫ２Ｐテーブル１３２ｂを読むようにする。分類機能４０１は、デバイス制御部１１０の設計要件に従い、製造者が選択することができる。

分類テーブルは、例えばアドレス値と使用状況を示す値の対をエントリとして構成しておく。アドレスが与えられると、分類テーブル内をサーチして、該当するアドレスが論理アドレスで使用されているか、物理アドレスで使用されているかを調べることができる。ただし、デバイス制御部１１０は予め通常のアドレス指定による読み書きかＫＶＳコマンドなのかを把握しているので、分類テーブルは必ずしも必要ではない。

図６は、Ｋ２Ｐテーブル１３２ｂとＬ２Ｐテーブル１３２ａとを１つの全体テーブルとして管理する例を示している。

例えば、３２ビットの論理アドレスのうち、Ｌ２Ｐテーブル１３２ａで使用する数を例えば「0x1000＿0000」までのように所定サイズに制限しておく。そして、「0x1000＿0001」以上のアドレスはキーアドレスであると判断する。境となるアドレス値は、デバイス制御部１１０が管理できるようにしてもよい。図６は、キーアドレスがそのまま全体テーブルの後半のアドレスに対応している例を示している。

図６に例示するような方法では、分類機能４０１が、全体テーブルのアドレスが所定の境目よりも前半か後半かを判断することで、アクセスすべきテーブルがＬ２Ｐテーブル１３２ａおよびＫ２Ｐテーブル１３２ｂのいずれであるかを知ることができる。

図６の方法と、分類テーブルを用いる上述の方法とを組み合わせて用いることもできる。全体テーブルとしては、メモリシステム内の総物理ページ分を格納できる大きさのテーブルを用意する。

次に、生成部１１７が生成するキーアドレスの衝突について図７を用いて説明する。

一般にＫＶＳ方式では、キーの数に制限は設けない。このため、メモリシステム内に格納されるＫＶＳの数、言い換えるとキーの種類が多くなると、キーに対して生成されるキーアドレスが衝突するようになる。例えば、キーが「Ｂｌｕｅ」という単語のときのキーアドレスが「0x0000＿41a9b」であるとする。別のキーである「Ｃａｒ」という単語から作られるキーアドレスが偶然に「0x0000＿41a9b」と一致してしまう確率はゼロではない。キーアドレスの生成に用いるＨａｓｈ関数に高度なものを用いて、数学的に疎な数を生成したとしても、キーアドレスの値を固定長サイズで小さく変換した際に、衝突の可能性が生じる。

キーアドレスの衝突をできるだけ回避するための方法はいくつか考えられる。１つ目は、キーアドレスをできるだけ長いままで用いる方法である。例えば、Ｈａｓｈ関数で変換したままの値をキーアドレスとして用いればよい。ただし、アドレス長が長いため、Ｋ２Ｐテーブル１３２ｂが大きくなるので、その分だけ容量を消費するという問題、および、Ｌ２Ｐテーブル１３２ａとのデータ形式の整合性が失われるという問題が生じる。記憶部１３０の容量を十分に大きくし、キーの種類に対して十分大きな数の物理ページ数を用意できるならば、キーの衝突確率を下げることができる。しかし、この場合であっても衝突確率をゼロにすることはできない。

２つ目は、任意長データを固定長変換方式として２つ以上の方式を組み合わせる方法である。例えば、キーアドレスを３２ビット長にするとき、１６ビット分をＨａｓｈ関数より生成し、ＡＳＣＩＩコードなどによってキー自体を変換したバイナリデータで残り１６ビット分を表し結合させる方法を用いることができる。前半１６ビットはランダムな値だが後半１６ビットがデータそのものに由来する値となるため、キーの衝突は極力低下させることができる。しかし、この方法でも数学的に衝突の可能性はゼロではなく、キーの数が増えていくと衝突の可能性は増える。

結局、論理アドレスとは異なり、与えられるキーは任意長かつ無限のバリエーションを有していることから、キーから生成されるアドレス値は衝突を避けられない。

そこで、本実施形態では、衝突が発生した場合にも正しくバリューを読み出せる機能を備える。図７は、Ｋ２Ｐテーブル１３２ｂと、物理ページに格納されたバリュー（バリューデータ）とを模式的に示す図である。

図７の上部には、「Ｋｅｙ１」が「Ｂｌｕｅ」であり、「Ｖａｌｕｅ１」がそれに対応するコンテンツ（バリュー）「＜ｃｏｎｔｅｎｔｓ １＞」であるＫＶＳデータの例が示されている。同様に、「Ｋｅｙ２」が「Ｃａｒ」であり、「Ｖａｌｕｅ２」がそれに対応するコンテンツ「＜ｃｏｎｔｅｎｔｓ ２＞」であるＫＶＳデータの例が示されている。

生成部１１７がＨａｓｈ関数により「Ｂｌｕｅ」と「Ｃａｒ」をそれぞれ変換してキーアドレスを生成した結果、これらのキーアドレス「0x0000＿41a9b」が衝突したものとする。取得部１１３は、このキーアドレスに関連付けられた物理アドレスを参照し、バリューデータを読み出す。物理ページ内には「Ｋｅｙ１」＝「Ｂｌｕｅ」と「Ｋｅｙ２」＝「Ｃａｒ」にそれぞれ対応するバリューが保存されている。取得部１１３は、物理ページ全体を例えばワークメモリ１１１に読み出す。その後、デバイス制御部１１０またはホストシステム２００が、読み出された物理ページを参照して、目的としていたキーに対応するバリューが保存されているかを判断する。例えば、目的とするキーが「Ｂｌｕｅ」であれば、デバイス制御部１１０またはホストシステム２００は、読み出した物理ページ全体から、「Ｂｌｕｅ」に対応するバリュー「＜ｃｏｎｔｅｎｔｓ １＞」を取得できる。また、例えば、目的とするキーが「Ｃａｒ」であれば、デバイス制御部１１０またはホストシステム２００は、読み出した物理ページ全体から、「Ｃａｒ」に対応するバリュー「＜ｃｏｎｔｅｎｔｓ ２＞」を取得できる。なお、図７の例では、「＜ｃｏｎｔｅｎｔｓ ２＞」は、「＜ｃｏｎｔｅｎｔｓ ２−１＞」および「＜ｃｏｎｔｅｎｔｓ ２−２＞」として、２つのページに分割されて記憶されている。以下に述べるように、次のページを読むためのポインタを用いることで、分割されたバリューを連続して読み出すことができる。

すなわち、ＫＶＳでは、キーおよびバリューは任意長であるため、１つの物理ページ内にデータが収まるとは限らない。このため、図７に示したように、物理ページ内の特定箇所に次のページを読むためのポインタとなる記憶位置を示すアドレス（次ページアドレス：next page pointer（以下、次ページポインタという））を保存し、連続して読めるようにしておく。このようにＫＶＳデータを格納する物理ページが複数に渡る場合は、その分だけ物理ページを消費する。次ページポインタは、ＮＡＮＤフラッシュメモリを用いた記憶部１３０の場合は、１つのページ内の冗長データ部または管理データ部と呼ばれる領域に格納しておくことができる。

次に、逆引きテーブルについて説明する。実データおよびＫＶＳデータの追加や修正を行う場合、それぞれＬ２Ｐテーブル１３２ａおよびＫ２Ｐテーブル１３２ｂの逆引きテーブルが必要となる。

記憶部１３０としてＮＡＮＤフラッシュメモリを用いている場合、記憶セルは主に書き込みによって寿命が低下していく。このため、物理ページを均等に利用して記憶セルの寿命を最大限に利用する手続きが用いられる。物理ページを均等に利用して寿命を延ばすための技術は、ウェアレベリングと呼ばれる。ＮＡＮＤフラッシュメモリは、一般的にページ単位で読み書きされる。一方、ＮＡＮＤフラッシュメモリは、ブロック単位で消去が行われる。このため、特定のブロックにデータが集中すると、そのブロックの寿命が低下し、同時に信頼性も低下する。また、ＮＡＮＤフラッシュメモリは通常、同一ページに対する追記書き込みができない仕様になっていることが多い。このため、ある物理ページに書き込まれたデータを変更する場合は、別の物理ページに変更したデータを書き込み、その物理ページのアドレス（物理アドレス）に対して論理アドレスを対応させる。

このように、ＮＡＮＤフラッシュメモリを用いたメモリシステムでは、物理アドレスを論理アドレスに対応づけたＰ２Ｌテーブルを持つことが一般的である。この場合、新しく物理ページを割り当てる時に、いずれの物理ページが使用されていないか、または、いずれのページの書換え頻度が少ないかという履歴を元にして、いずれの物理ページを用いるかが決定される。

本実施形態でも、Ｐ２Ｌテーブルを用いて物理ページを管理するのと同様の手法により、Ｋ２Ｐテーブル１３２ｂの逆引きテーブルであるＰ２Ｋテーブルを用いてＫＶＳデータの物理ページを管理する。これにより、デバイス１００の寿命と信頼性を向上させることができる。

図８は、Ｐ２Ｋテーブルのデータ形式の一例を示す図である。Ｐ２Ｋテーブルは、物理アドレスとキーアドレスとのペアを各エントリに含む。

各エントリには、物理アドレスが使用されていることを示す例えば１ビットの判定情報（フラグ）を持たせることができる。このフラグを参照することにより物理アドレスの使用状況が判別できる。図８に示すように、例えば、「0x0」および「0x1」の場合に、それぞれ物理アドレスが使用されていないこと、および、使用されていること、を表すフラグを用いることができる。

なお、図８の判定情報は一例であり、これに限られるものではない。物理アドレスが使用されているか否か（物理アドレスのページが有効であるか否か）を表す情報であればどのような情報であってもよい。転記処理部１１６は、Ｐ２Ｋテーブルのフラグ（判定情報）を参照して、ガベージコレクションおよびコンパクションを実行する。例えば、転記処理部１１６は、Ｐ２Ｋテーブルのフラグが「0x1」である（使用されている（有効な））物理アドレスのページのデータを対象としてコンパクションを実行する。

Ｋ２Ｐペアが作られたあとで、Ｐ２Ｋテーブルも作成しておくことで、物理ページの管理を容易に行うことが可能となる。各エントリが、物理アドレスに対応する物理ページの書換え回数（書換え頻度）を含んでもよい。書換え回数を記録しておけば、書換え回数の少ない物理ページを選んで使用する制御が可能となる。

図９は、Ｐ２ＬテーブルとＰ２Ｋテーブルとを融合させたテーブル（Ｐ２Ｌ／Ｐ２Ｋテーブル１３２ｃ）のデータ形式の一例を示す図である。このテーブルを参照することにより、物理アドレスが論理アドレスに対応付けられているのか、キーアドレスに対応付けられているのかを知ることができる。

なお、図７に示すようにＫＶＳデータを格納する物理ページが複数に渡る場合も、各物理ページの物理アドレスと、ＫＶＳデータの論理アドレスとをＰ２Ｋテーブルに記録して管理しておく。

次に、このように構成された第１の実施形態にかかるデバイス１００による各種処理について図１０〜図１３を用いて説明する。図１０は、登録コマンドを受け付けた場合の処理の一例を示すフローチャートである。

受付部１１２が、登録コマンドを受け付けると、図１０の処理が開始される。登録コマンドは、例えば登録するＫＶＳデータを含む。生成部１１７は、登録するＫＶＳデータに含まれるキーをキーアドレスに変換する（ステップＳ１０１）。

取得部１１３は、Ｋ２Ｐテーブル１３２ｂを参照し、キーアドレスが既にＫ２Ｐテーブル１３２ｂに存在していないか検索する（ステップＳ１０２）。取得部１１３は、キーアドレスがＫ２Ｐテーブル１３２ｂ内に見つかったか否かを判断する（ステップＳ１０３）。見つかった場合（ステップＳ１０３：Ｙｅｓ）、取得部１１３は、キーアドレスに対応するバリューの物理アドレスを参照し（ステップＳ１０４）、バリューの物理ページに空きがあるかを判断する（ステップＳ１０５）。バリューの物理ページに空きがない場合（ステップＳ１０５：Ｎｏ）、取得部１１３は、次の物理アドレスへジャンプするためのポインタ（次ページポインタ）を格納して、その物理アドレスを参照する（ステップＳ１０６）。取得部１１３は、Ｐ２ＫテーブルおよびＰ２Ｌテーブルの少なくとも１つを参照して空いている物理アドレスを探し、ジャンプする物理アドレスを決定する。書込部１１５は、使用した物理アドレスをＰ２Ｋテーブルに登録する（ステップＳ１０７）。

バリューの物理ページに空きがある場合（ステップＳ１０５：Ｙｅｓ）、書込部１１５は、登録するＫＶＳデータに含まれるバリューを当該物理ページに追記する（ステップＳ１０８）。ただし、フラッシュメモリなどのように、同一ページ内への追記が禁止される場合がある。その場合は、一般的なＳＳＤなどと同様に、別の物理アドレスの物理ページにまとめてデータ（バリュー）を書き込む。出力制御部１１４は、追記後のバリューのデータサイズを出力し（ステップＳ１０９）、処理を終了する。

ステップＳ１０３で、キーアドレスがＫ２Ｐテーブル１３２ｂ内に見つからなかった場合（ステップＳ１０３：Ｎｏ）、書込部１１５は、空いている物理アドレスの物理ページにバリューを追加する（ステップＳ１１０）。書込部１１５は、キーとバリューの物理アドレスとを関連付けてＫ２Ｐテーブル１３２ｂに登録する（ステップＳ１１１）。書込部１１５は、使用した物理アドレスをＰ２Ｋテーブルに登録する（ステップＳ１１２）。出力制御部１１４は、追記後のバリューのデータサイズを出力し（ステップＳ１１３）、処理を終了する。

図１１は、書込コマンドを受け付けた場合の処理の一例を示すフローチャートである。受付部１１２が、書込コマンドを受け付けると、図１１の処理が開始される。書込コマンドは、例えばＫＶＳデータを含む。書込コマンドは、既に存在するキーに対するバリューの追記コマンドである。

ステップＳ２０１〜ステップＳ２０９は、図１０のステップＳ１０１〜ステップＳ１０９までと同様であるため説明を省略する。

ステップＳ１０３で、キーアドレスがＫ２Ｐテーブル１３２ｂ内に見つからなかった場合（ステップＳ２０３：Ｎｏ）、取得部１１３は、キーが存在しないことを返して処理を終了する（ステップＳ２１０）。取得部１１３は、例えば、ＳＩＺＥ＝０を返すことにより、キーが存在しないことを通知する。

図１２は、取得コマンドを受け付けた場合の処理の一例を示すフローチャートである。受付部１１２が、取得コマンドを受け付けると、図１２の処理が開始される。取得コマンドは、例えばキーを含む。

ステップＳ３０１〜ステップＳ３０３は、図１０のステップＳ１０１〜ステップＳ１０３までと同様であるため説明を省略する。

キーアドレスが見つかった場合（ステップＳ３０３：Ｙｅｓ）、取得部１１３は、キーアドレスに対応するバリューの物理アドレスを参照し（ステップＳ３０４）、キーアドレスに対応するバリューを読み出してワークメモリ１１１（またはバッファメモリ１２１）に格納する（ステップＳ３０５）。出力制御部１１４は、読み出したバリューのデータサイズを出力し（ステップＳ３０６）、処理を終了する。

ステップＳ３０３でキーアドレスがＫ２Ｐテーブル１３２ｂ内に見つからなかった場合（ステップＳ３０３：Ｎｏ）、取得部１１３は、キーが存在しないことを返して処理を終了する（ステップＳ３０７）。取得部１１３は、例えば、ＳＩＺＥ＝０を返すことにより、キーが存在しないことを通知する。

図１３は、読出コマンドを受け付けた場合の処理の一例を示すフローチャートである。受付部１１２が、読出コマンドを受け付けると、図１３の処理が開始される。読出コマンドは、例えばサイズの指定を含む。

取得部１１３は、集合（バリュー）の要素のワークメモリ１１１の保管場所を参照し（ステップＳ４０１）、バリューがこの保管場所内に見つかったか否かを判断する（ステップＳ４０２）。集合（バリュー）の要素が見つからなければ（ステップＳ４０２：Ｎｏ）、取得部１１３は、出力として例えばＳ＝ＮＵＬＬを返すことにより、集合（バリュー）の要素が存在しないことを通知する（ステップＳ４０５）。見つかった場合（ステップＳ４０２：Ｙｅｓ）、指定されたサイズ分に対応する集合（バリュー）の要素を読み出す（ステップＳ４０３）。取得部１１３は、読み出したバリューの要素を出力し（ステップＳ４０４）、処理を終了する。

図１３の例ではサイズ指定のみだが、ワークメモリ１１１内の場所（アドレス）を指定して読み出してもよい。

なお、実際の手順やコマンドは図１０〜図１３に示す例に限定されない。例えば、複数のキーが見つかった場合には、キーが見つかったことを示すフラグをたてておき、後でまとめてバリューを読むなどの手順を実行可能としてもよい。

以上のように、本実施形態では、ホストインタフェース１０１、または、ホストインタフェース１０１を介してデバイス制御部１１０やメモリ制御部１２０などがコマンドを受け付けてＫＶＳの一連の処理を実行することができる。

（変形例１）
変形例１では、物理ブロックテーブルを用いる例を説明する。図１４は、物理ブロックテーブルを用いる場合のデータアクセスの仕組みを説明する図である。

図１４は、論理アドレスから変換された物理アドレスを、さらに物理ブロックとページオフセットとに変換する物理ブロックテーブル１４０１を用いる例を示している。図１５は、物理ブロックテーブルのデータ形式の一例を示す図である。図１５の物理ブロックテーブルは、物理アドレスから、当該物理アドレスのページが対応する物理ブロックを特定する際に利用される。このような物理ブロックテーブルを有しておくことで、例えばＮＡＮＤフラッシュメモリを記憶部１３０として用いたデバイス１００であれば、ガベージコレクションおよびコンパクションを効率的に行うことができる。

本実施形態のＫ２Ｐテーブル１３２ｂから参照されるのは物理アドレスである。このため、物理ブロックテーブルを用いることにより、ＫＶＳデータのガベージコレクションとコンパクションを、通常のＬ２Ｐ形式のデータ（実データ）と同様に取り扱うことができる。従って、Ｋ２ＰとＬ２Ｐが同居したデバイス１００であっても、比較的容易に信頼性の高いシステムを作ることができる。

（変形例２）
変形例２では、多段階の検索テーブルを用いてＬ２Ｐテーブルへアクセスする例を説明する。図１６に示すように、分類機能４０１により論理アドレス（実データ）とキーアドレス（ＫＶＳデータ）のいずれを参照するか分類した後、さらに１以上の検索テーブルを用いて、論理アドレスに対応する物理アドレスを参照するように構成してもよい。

Ｌ２Ｐテーブルは、記憶部１３０の全ページ情報を格納しているため、ワークメモリ１１１の容量と比較して大きなサイズとなる。デバイス制御部１１０は、アドレス指定の読み出し・書込み命令を受けた時に、目的の論理アドレスを格納するＬ２Ｐテーブルのエントリを第１のメモリブロックから探す必要がある。

例えば、記憶部１３０の容量が６４ＧＢのとき、１ページ容量が４ＫＢだとすると、１６００００００ページ存在することになる。アドレス単位が３２ビット（４バイト）であるとすれば、Ｌ２Ｐテーブルの容量は６４ＭＢになる。ワークメモリ１１１は一般的にＳＲＡＭで構成されるので、全Ｌ２Ｐテーブルを格納することができない。従って、目的とするＬ２Ｐエントリを記憶部１３０から効率よく探すためには、Ｌ２Ｐエントリを探すための検索テーブルを用いることができる。検索テーブルをツリー方式でたどって目的まで到達する。Ｌ２Ｐエントリのエントリ数とワークメモリ１１１の容量に応じて、検索テーブルを多段にする。検索テーブルを多段にすると、検索テーブルの読み出し回数が増えるため、その分Ｌ２Ｐ処理が遅くなる場合もあるため、適当な段数を用いる。

上記実施形態では、Ｋ２Ｐテーブル１３２ｂを単独で用いることができるため、または、Ｌ２Ｐテーブル１３２ａと共存させることが容易なため、ユーザはＫＶＳデータに対する処理によるシステムの負荷増大を感じることがない。

共存させる場合であっても、図１６のように、Ｋ２Ｐテーブル１３２ｂの参照がＬ２Ｐテーブル１３２ａの参照よりも少ない回数で行うことができるならば、ＫＶＳデータの方がアクセス速度を速くすることができる。

なお、ＫＶＳのデータ形式を採用している時点で、要求しているキーに対応するバリューのデータが直ちに得られるので検索が速くなる。本変形例では、ＫＶＳデータへのアクセス自体が余計なＬ２Ｐ参照の手順を省略できるため、さらに高速になる。Ｌ２Ｐテーブルの管理と同様の仕組みを用いているため、ＫＶＳデータを格納することのハードウェアコストの増大はほとんど無くすことができる。

（変形例３）
図４では、キーアドレスと物理アドレスの対応を複数個まとめたものを１つのエントリとしたＫ２Ｐテーブル１３２ｂの例を示した。変形例３では、これを拡張し、物理アドレスのあとにバリューのハッシュ値を格納する例を示す。図１７は、変形例３のＫ２Ｐテーブル１３２ｂのデータ形式の一例を示す図である。

ホストシステム２００からＫＶＳ要求の、例えば、ＧＥＴコマンドと集合演算命令のＡＮＤがデバイス１００に届いたとき、デバイス１００側はハッシュ値を含むＫ２Ｐテーブル１３２ｂを参照することで、バリューの中身とその集合演算を予め記憶部１３０から読み出す前に判断することができる。無駄な読み出しが減るため、検索および集合演算に係る時間が短縮できる。

ＫＶＳではこの例のように、１つのキーに対し、複数のバリューが付与される場合がある。バリューは、物理アドレスが指し示す、記憶部１３０のページ内にそのまま保存される。図１７の例では、各バリューのハッシュ値も、Ｋ２Ｐテーブル１３２ｂにまとめて保存しておく。こうしておくことで、バリューを読み出すことなく、各バリューが一致しているか否かを、Ｋ２Ｐテーブル１３２ｂを用いて判別することができる。

前述したようにハッシュ値は衝突している可能性があるので、ハッシュ値が同一であってもバリューを読み出したあとに、実際に同一なデータかどうかは比較照合しなければならない。しかし、同一データであって異なるハッシュ値であることはないので、ハッシュ値比較の段階で、まったく条件に一致していないデータは除外しておくことができる。この仕組みにより、余計なバリューの読み出しが少なくなり、ＮＡＮＤフラッシュメモリのように比較的読み出し速度が遅いＲＡＭの場合は、検索速度が速くなる。

図１７の例のように、Ｋ２Ｐテーブル１３２ｂ内にバリューのハッシュ値が格納されている場合、そのハッシュ値と、ハッシュ値をアドレスとして格納できるＲＡＭと、を使って、ハッシュ検索を行うことができる。例えば、ハッシュ値をアドレスとして、該当するアドレスにデータが書き込まれる。

例えばアドレスごとに４バイト格納できるＲＡＭであれば、「ｖａｌｕｅ１」の値として「0x1010＿1010」を書く。次に「ｖａｌｕｅ２」の値として、「0x0101＿0101」をＸＯＲで上書きして書き込む。同じアドレスに対して書き込んだ場合、そのアドレスのデータは「0x1111＿1111」になる。これを読めば一致していることが判断できる。

ただし、上述のようにハッシュ値は衝突している可能性があるので、衝突の有無を検証する必要がある。バリューを参照して確かめれば確実であるが、ここでは図１８を用いて別の方法を例示する。各バリューは２種類以上のハッシュ関数で変換した値を持つとする。図１８の例は、２種類のハッシュ関数を用いる例である。１種類だけでは衝突していたバリューも、異なるハッシュ関数で変換した場合は異なるハッシュ値になる確率が高くなる。このため、衝突の可能性を可及的に減らすことができる。ただし、２種類以上のハッシュ値を格納することはＫ２Ｐテーブル１３２ｂの肥大化を招くため、バリューの一致判定の目的に合わせて設計する必要がある。なお、ハッシュ値が一致している条件は集合演算のＡＮＤ条件に相当する。

このように、第１の実施形態にかかる半導体記憶装置では、ＫＶＳデータを取り出す処理を、不揮発性メモリのアドレス管理方式と共存させることができる。これにより、ＫＶＳ併用による書き込みなどデータ管理の負荷を増大させずに、読み出しではＫ２Ｐテーブルを用いてキーから直接的に物理アドレスを参照できる。このため、従来の方法では必要であった途中のＬ２Ｐ処理（例えばＬ２Ｐテーブルへのアクセス）を省略し、簡素かつ高速に検索を行うことができる。

（第２の実施形態）
第２の実施形態にかかる半導体記憶装置は、ＣＡＭ（Content Addressable Memory）を用いてデータを検索可能とする。図１９は、第２の実施形態にかかるデバイス１００−２のハードウェア構成の一例を示すブロック図である。図１９に示すように、デバイス１００−２は、ホストインタフェース１０１と、デバイス制御部１１０と、メモリ制御部１２０−２と、記憶部１３０と、を備えている。

第２の実施形態では、メモリ制御部１２０−２がＣＡＭ１２２−２をさらに備える点が第１の実施形態と異なっている。その他の構成は第１の実施形態の図１と同様であるため説明を省略する。

記憶部１３０がＮＡＮＤフラッシュメモリである場合は、記憶部１３０内に存在する読み出し／書き込みのためのバッファメモリがＣＡＭであってもよい。すなわち、記憶部１３０から読み出されたデータが、デバイス１００−２内のバス１０２を通って、デバイス制御部１１０が管理するワークメモリ１１１に到達する前に、ＣＡＭ動作によってデータの照合が行われる構成であればよい。

上述したように、キーの衝突が問題となる場合、ページ内からデータを読み出して、そのページ内に特定のキーが保存されているか判断する機能が必要となる。また同様に、ページが複数に渡る場合も、例えばページの冗長データ部に保存されている次ページポインタを判別して次ページを読むための制御信号を出力するための機能が必要となる。

本実施形態で用いられるＣＡＭ１２２−２はこのために利用される。ＣＡＭ１２２−２は、予め読み出されたＫＶＳデータを記憶する。ＣＡＭ１２２−２は、読み出されたＫＶＳデータにキーが含まれていれば、正常値として当該キーに対応するバリューデータをワークメモリ１１１へ転送する。ＣＡＭ１２２−２は、キーが含まれていなければ、エラー信号をデバイス制御部１１０に返す。

この仕組みにより、デバイス制御部１１０が、例えばワークメモリ１１１内のバリューデータからＫＶＳデータを検索することが不要になり、ＫＶＳ動作がより円滑に行われるようになる。次ページポインタの検索もまた同様である。

例えば、次ページポインタはページの最後に付与されており、実データ部、または、管理データ部の中に格納されている。いずれの場合も次ページポインタの存在を示す特定のデータ（特定情報）を、同様にＣＡＭ１２２−２を用いて検索することができる。次ページポインタの発見をメモリ制御部１２０へ通知することで、例えばメモリ制御部１２０は、次ページポインタの示すアドレスを続けて読みに行くことができる。次ページポインタの発見をデバイス制御部１１０へ通知する場合も同様であって、いずれの場合も次ページポインタの存在をページ内データから読み取る方式よりは速度が向上する。

図２０は、ＣＡＭ１２２−２を用いた検索処理例を説明する図である。例えば、キー「Ｃａｒ」が入力された場合、ＣＡＭ１２２−２は、一致するキー「Ｃａｒ」を記憶しているため、このキー「Ｃａｒ」に対応するバリューである「＜ｃｏｎｔｅｎｔｓ ２−１＞」を出力する。また、例えば、次ページポインタが記憶されていることを発見した場合、ＣＡＭ１２２−２は、次ページポインタが示す位置に記憶されているバリューを出力する。

なお、特定のデータ（特定情報）は、次ページポインタの存在を示す情報に限られるものではない。当該特定情報に応じて実行する処理が予め定められた情報であればどのような情報であってもよい。

（第３の実施形態）
第３の実施形態にかかる半導体記憶装置は、ワークメモリ以外に、ワークメモリよりも大きなサイズのバッファメモリをさらに備える。図２１は、第３の実施形態にかかるデバイス１００−３のハードウェア構成の一例を示すブロック図である。図２１に示すように、デバイス１００−３は、ホストインタフェース１０１と、デバイス制御部１１０と、メモリ制御部１２０と、記憶部１３０と、に加えて、バッファメモリ１４０−３を備えている。

バッファメモリ１４０−３は、ワークメモリ１１１よりサイズが大きいメモリである。バッファメモリ１４０−３は、デバイス制御部１１０からバス１０２を介してアクセスすることができる。バッファメモリ１４０−３は、例えばＤＲＡＭやＭＲＡＭやＰＣＲＡＭなど、ＮＡＮＤフラッシュメモリよりも容量は小さいが高速なＲＡＭにより構成できる。

デバイス制御部１１０は、記憶部１３０に格納されているＫ２Ｐテーブル１３２ｂおよびＰ２Ｋテーブル（Ｐ２Ｌ／Ｐ２Ｋテーブル１３２ｃ）などの管理テーブルをバッファメモリ１４０−３にすべて転送しておく。デバイス制御部１１０は、バッファメモリ１４０−３上で、データのアクセスや変更を行う。これにより、記憶部１３０から都度読み書きするよりも高速にＫ２Ｐ処理を行うことが可能となる。

なお、バッファメモリ１４０−３に対しても、第２の実施形態のＣＡＭ１２２−２と同様のＣＡＭを備えるように構成してもよい。

（第４の実施形態）
第４の実施形態にかかる半導体記憶装置は、ダイレクトメモリアクセスコントローラ（ＤＭＡＣ）をさらに備える。図２２−１は、第４の実施形態にかかるデバイス１００−４のハードウェア構成の一例を示すブロック図である。図２２−１に示すように、デバイス１００−４は、ホストインタフェース１０１−４と、デバイス制御部１１０と、メモリ制御部１２０と、記憶部１３０と、に加えて、ＤＭＡＣ１５０−４を備えている。

ＤＭＡＣ１５０−４は、デバイス１００−４内でホストインタフェース１０１−４へデータを転送することを可能とする。ＤＭＡＣ１５０−４は、例えば、記憶部１３０内のＬ２Ｐテーブル１３２ａ、Ｋ２Ｐテーブル１３２ｂ、および、Ｐ２Ｌ／Ｐ２Ｋテーブル１３２ｃをホストインタフェース１０１−４に転送する。ホストインタフェース１０１−４は、デバイス１００−４内からのＬ２Ｐテーブル、Ｋ２Ｐテーブルの転送要求を受け付け、メインメモリ２０２−４に転送する。ホストインタフェース１０１−４は、ホストシステム２００−４にＤＭＡＣが備わっていればこれを利用することができる。ホストシステム２００−４は、転送したテーブルにアクセスすることにより、記憶部１３０から都度読み書きするよりも高速にＫ２Ｐ処理を行うことが可能となる。

なお、上述のように、Ｌ２Ｐテーブル１３２ａおよびＫ２Ｐテーブル１３２ｂに対して同様のデータ形式を用いれば、ＤＭＡＣ１５０−４およびホストインタフェース１０１−４のアルゴリズムや命令も共通化させることができる。これにより、必要なハードウェアの追加分を少なくすることができる。

（第４の実施形態の変形例）
第４の実施形態の変形例は、ダイレクトメモリアクセスコントローラ（ＤＭＡＣ）にホストとデバイスを繋ぐ別の通信線３００をさらに備える。図２２−２は、第４の実施形態の変形例のデバイス１００−５のハードウェア構成の一例を示すブロック図である。図２２−２に示すように、デバイス１００−５は、ホストインタフェース１０１−４と、デバイス制御部１１０と、メモリ制御部１２０と、記憶部１３０と、に加えて、ＤＭＡＣ１５０−５を備えている。また、ＤＭＡＣ１５０−５は、デバイス１００−５からホストシステム２００−４へのホストインタフェース１０１−４とは別の通信線３００を介してホストシステム２００−４と接続される。

ＤＭＡＣ１５０−５は、通信線３００を介して、デバイス１００−４内からホストシステム２００−４側のメインメモリ２０２−４にアクセスすることを可能とする。ＤＭＡＣ１５０−５は、例えば、記憶部１３０内のＬ２Ｐテーブル１３２ａ、Ｋ２Ｐテーブル１３２ｂ、および、Ｐ２Ｌ／Ｐ２Ｋテーブル１３２ｃをメインメモリ２０２−４に転送する。ホストシステム２００−４は、転送したテーブルにアクセスすることにより、記憶部１３０から都度読み書きするよりも高速にＫ２Ｐ処理を行うことが可能となる。

なお、上述のように、Ｌ２Ｐテーブル１３２ａおよびＫ２Ｐテーブル１３２ｂに対して同様のデータ形式を用いれば、ＤＭＡＣ１５０−４のアルゴリズムや命令も共通化させることができる。これにより、必要なハードウェアの追加分を少なくすることができる。

（第５の実施形態）
第５の実施形態では、ホストシステムが、デバイスと同様のＫ２Ｐ処理の実行機能（サブ制御部）を備える。図２３は、第５の実施形態にかかるデバイス１００−４と、ホストシステム２００−５のハードウェア構成の一例を示すブロック図である。デバイス１００−４の構成は第４の実施形態（図２２−１）と同様である。

図２３に示すように、ホストシステム２００−５は、さらにサブ制御部２２０−５を備える点が、第４の実施形態と異なっている。

サブ制御部２２０−５は、例えばデバイス制御部１１０の機能のうち、少なくともＫ２Ｐ処理に必要な機能と同様の機能を備えればよい。例えば、サブ制御部２２０−５は、キーに対応するバリューの取得要求を受け付ける機能（受付部１１２と同様の機能）を備える。また、例えばサブ制御部２２０−５は、メインメモリ２０２−４から各種データを読み出す機能（取得部１１３と同様の機能）を備える。また、例えばサブ制御部２２０−５は、メインメモリ２０２−４に対して各種データを書き込む機能（書込部１１５と同様の機能）を備える。また、例えばサブ制御部２２０−５は、読み出されたバリューを取得要求に対する応答として出力する機能（出力制御部１１４と同様の機能）を備える。

このような構成により、ホストシステム２００−５のＣＰＵ２０１が、メインメモリ２０２−４内のＫ２Ｐテーブルを直接参照できるようになる。ＣＰＵ２０１は、キーの有無を知った上でのデバイス１００−４へのＫＶＳ要求を送信することができる。

デバイス１００−４内のデバイス制御部１１０と連携して、ホストシステム２００−４がＫＶＳ要求を送信する前に、予め決められたルールでデバイス１００−４側のデータをメインメモリ２０２−４に転送するように構成してもよい。予め決められたルールとしては、例えばホストシステム２００−４側で特定のキーに対するアクセスが頻発しているときに、デバイス１００−４内のＫＶＳデータをメインメモリ２０２−４に転送してデータキャッシュするといったルールである。

本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

例えば、デバイス制御部１１０が、メモリ管理ユニット（ＭＭＵ（Memory Management Unit））を備えるように構成してもよい。一般にメモリ管理ユニットは、仮想アドレス（論理アドレス）と物理アドレスとを変換する機能などを備える。例えば、Ｌ２ＰテーブルおよびＫ２ＰテーブルなどをＭＭＵ内に記憶し、ＭＭＵ内のテーブルを参照して上記実施形態の手法を適用するように構成できる。

また、デバイス制御部１１０が、ＴＬＢ（Translation Lookaside Buffer）を備えるように構成してもよい。ＴＬＢは、仮想アドレスから物理アドレスへの変換の高速化を図るための専用キャッシュである。例えば、Ｌ２ＰテーブルおよびＫ２ＰテーブルなどをＴＬＢ内に記憶し、ＴＬＢ内のテーブルを参照して上記実施形態の手法を適用するように構成できる。

１００ デバイス
１０１ ホストインタフェース
１０２ バス
１１０ デバイス制御部
１１１ ワークメモリ
１２０ メモリ制御部
１２１ バッファメモリ
１３０ 記憶部
２００ ホストシステム
２０１ ＣＰＵ
２０２ メインメモリ
２１１ バス

Claims (17)

1. バリュー、および、前記バリューに対応するキーに基づいて生成されるキーアドレスと前記バリューの物理アドレスとを対応づけるアドレス情報を記憶する第１記憶部と、
   前記キーを含む、当該キーに対応する前記バリューの取得要求を受け付ける受付部と、
   前記アドレス情報に基づいて、前記取得要求に含まれる前記キーの前記キーアドレスに対応する前記物理アドレスを取得する取得部と、
   取得された前記物理アドレスの前記バリューを前記第１記憶部から取得し、取得した前記バリューを、前記取得要求に対する応答として出力する出力制御部と、
   を備える半導体記憶装置。
2. キーとバリューとを対応づけるキーバリュー情報を記憶し、指定された前記キーを含む前記キーバリュー情報が記憶されている場合に、指定された前記キーに対応する前記バリューを出力する第２記憶部をさらに備える、
   請求項１に記載の半導体記憶装置。
3. 前記第２記憶部は、指定された前記キーを含む前記キーバリュー情報が記憶されていない場合に、記憶されていないことを示す情報を出力する、
   請求項２に記載の半導体記憶装置。
4. 前記第２記憶部は、特定情報が記憶されている場合に、前記特定情報に応じて定められた処理を実行し、実行結果を出力する、
   請求項２に記載の半導体記憶装置。
5. 前記第２記憶部は、前記バリューの記憶位置を表す前記特定情報が記憶されている場合に、前記記憶位置に記憶されている前記バリューを出力する、
   請求項４に記載の半導体記憶装置。
6. 前記第１記憶部より高速にアクセス可能であり、前記第１記憶部から転送される前記アドレス情報を記憶する第３記憶部をさらに備え、
   前記取得部は、前記第３記憶部に記憶された前記アドレス情報に基づいて、前記取得要求に含まれる前記キーの前記キーアドレスに対応する前記物理アドレスを取得する、
   請求項１に記載の半導体記憶装置。
7. 前記第１記憶部より高速にアクセス可能な第４記憶部へのアクセスを制御するアクセス制御部をさらに備え、
   前記取得部は、前記アクセス制御部を介して、前記第４記憶部に記憶された前記アドレス情報を参照することにより、前記取得要求に含まれる前記キーの前記キーアドレスに対応する前記物理アドレスを取得する、
   請求項１に記載の半導体記憶装置。
8. 前記取得部は、起動時に前記アドレス情報を前記第１記憶部から読み出し、読み出した前記アドレス情報を前記第４記憶部に記憶する、
   請求項７に記載の半導体記憶装置。
9. 前記アクセス制御部は、前記取得要求が受付けられるインタフェースと異なるインタフェースを介して、前記第４記憶部へのアクセスを制御する、
   請求項７に記載の半導体記憶装置。
10. 前記第１記憶部は、前記バリュー、および、前記キーに基づいて生成される固定長のキーアドレスと前記物理アドレスとを対応づける前記アドレス情報を記憶する、
    請求項１に記載の半導体記憶装置。
11. 前記第１記憶部は、複数のページを含むブロックを複数含み、前記バリューが記憶される前記ページの物理アドレスを表すページアドレスと、前記キーアドレスと、前記ページアドレスのページが有効であるか否かを表す判定情報と、を対応づけてさらに記憶し、
    第１ブロックに含まれるページのうち前記判定情報が有効であることを表す有効ページを第２ブロックに書き込み、前記第１ブロックに記憶された前記有効ページを消去する転記処理部をさらに備える、
    請求項１に記載の半導体記憶装置。
12. 前記第１記憶部は、複数のページを含むブロックを複数含み、前記ページに、当該ページの次に読み出すページの物理アドレスを表す次ページアドレスを対応づけて記憶し、
    取得部は、前記ページを読み出した後に、当該ページに対応づけられた前記次ページアドレスのページを読み出す、
    請求項１に記載の半導体記憶装置。
13. 前記第１記憶部は、さらに、前記バリューと異なるデータを記憶し、
    前記アドレス情報は、前記データの論理アドレスと前記データの物理アドレスとを対応づけた情報をさらに含む、
    請求項１に記載の半導体記憶装置。
14. 前記第１記憶部は、前記ページアドレスと、前記キーアドレスと、前記判定情報と、前記ページアドレスのページの書換え頻度と、を対応づけて記憶し、
    前記書換え頻度が低い前記ページに対して優先してデータを書き込む書込部をさらに備える、
    請求項１に記載の半導体記憶装置。
15. 前記第１記憶部は、前記バリュー、および、前記キーアドレスと前記物理アドレスと前記バリューのハッシュ値とを対応づける前記アドレス情報を記憶する、
    請求項１に記載の半導体記憶装置。
16. ホスト装置と、半導体記憶装置と、を備える情報処理システムであって、
    前記半導体記憶装置は、
    バリュー、および、前記バリューに対応するキーに基づいて生成されるキーアドレスと前記バリューの物理アドレスとを対応づけるアドレス情報を記憶する第１記憶部を備え、
    前記ホスト装置は、
    前記キーを含む、当該キーに対応する前記バリューの取得要求を受け付ける受付部と、
    前記アドレス情報に基づいて、前記取得要求に含まれる前記キーの前記キーアドレスに対応する前記物理アドレスを取得する取得部と、
    取得された前記物理アドレスの前記バリューを前記第１記憶部から取得し、取得した前記バリューを、前記取得要求に対する応答として出力する出力制御部と、を備える、
    情報処理システム。
17. バリュー、および、前記バリューに対応するキーに基づいて生成されるキーアドレスと前記バリューの物理アドレスとを対応づけるアドレス情報を記憶する第１記憶部を備える半導体記憶装置で実行される制御方法であって、
    前記キーを含む、当該キーに対応する前記バリューの取得要求を受け付ける受付ステップと、
    前記アドレス情報に基づいて、前記取得要求に含まれる前記キーの前記キーアドレスに対応する前記物理アドレスを取得する取得ステップと、
    取得された前記物理アドレスの前記バリューを前記第１記憶部から取得し、取得した前記バリューを、前記取得要求に対する応答として出力する出力ステップと、
    を含む制御方法。

Images