以下の説明において、略同一の機能及び構成を有する構成要素については、同一符号を付し、重複説明は必要な場合にのみ行う。
メモリシステムに保存されるメタデータがkey−valueストア方式で保存される。そのkey−value型データの効率的な保存方法と構成を与えるための実施形態を、図を用いながら説明する。
<メタデータテーブルとkey−valueストア方式>
まず、本実施形態の基本原理となるメタデータテーブルとkey−valueストア方式について述べる。
図1は、第1のメモリブロック内の実データ領域とメタデータテーブルとの関係、及びkey−valueストア方式の仕組みを模式的に示している。なお、数値や記号は説明のために用いられており、実施形態とは必ずしも対応していない。
図1に示すように、メモリアクセス可能な物理アドレス空間内には、アドレス指定の実データ領域(実アドレス空間)161と、メタデータテーブル162が存在している。実データ領域161は、従来概念でいうところの論理アドレス空間にそのまま対応する。メタデータテーブル162は、メモリシステム側が適宜用いるデータ領域であるため、ユーザーまたはクライアントが通常利用では明示的にアクセスすることはしない。ただし、システムへのテストコマンドとしては明示的にアクセスすることも許可される。ユーザーは基本的にインターフェースコマンドを用いてメモリシステムに対し、実データあるいはメタデータを操作する要求を投げかけ、メモリシステムは内部で処理した結果、返答としての信号あるいはデータをユーザー(ホストシステム)へ返す。
メモリシステムは、論理アドレスを物理アドレスに変換するための論理アドレス−物理アドレス変換テーブルの中で、実データ領域161とメタデータテーブル162の格納領域を区別する。メタデータテーブル162内のメタデータアドレスは、必要に応じて作られるため、key−value型データの作成要求がなければ第1のメモリブロック内に存在しない場合も有り得る。
このように、本実施形態のメモリシステムでのメタデータテーブル162の記憶容量は固定されて設置されているわけではなく、key−valueストア方式に基づく要求に応じて任意に可変(拡張あるいは縮小)されて存在できるものである。このため、ユーザーはメタデータを任意に扱いつつ、アクセス可能な物理メモリ空間が最大効率で利用可能となる。極端に言えば、メタデータをまったく扱わない場合も取り得る。この場合、物理メモリ空間が最大限に利用できる。
逆に、メタデータを十分活用した場合は、実データ領域161と同サイズ以上にメタデータテーブル162を拡大する場合もあり得る。この場合でも、メタデータの管理はメモリシステム(ローカルシステム)側の仕事なので、ホストシステム側はメタデータの管理から開放されている。従って、ユーザー(ホストシステム側)は通常利用においてメタデータの管理を意識する必要はなくなる。
メタデータテーブル162にはkey−valueペアが保存されているが、データの実態は実データ領域(実アドレス空間)161に存在する。
本実施形態でのメタデータテーブル162と実データ領域161の実データとの関係について、key−valueストア方式によるデータ取り出しの具体例を示して説明する。
key−valueストア(KVS)方式とは、キー(key)と値(value)の組を書き込み、キーを指定することで値を読み出せるデータベース管理方式のことを意味する。KVS方式は、ネットワーク越しに使われる例が多いが、データの格納先はどこかのローカルのメモリあるいはストレージシステムであることは間違いない。メタデータといえども実データアドレス空間内に格納されている。
データは、通常、保存されているメモリの先頭アドレスを指定することで読み出される。ここで、データをファイルと言い替えても良い。ファイルシステムによっては、実データアドレス空間が、例えば512バイトのセクタ単位で管理される。あるいは、ファイルシステムを限定する必要がなければ、例えばNANDフラッシュメモリの読み出し/書き込みのページサイズである、4KBや8KB単位などで管理されても良い。
図1に示す実データ領域161には、概念的に実アドレスに対応したファイル(データ)の保存の様子を示している。例えば、&001の実データアドレスにファイルa-file.txtのファイルIDである%a-file.txtが保存され、&002に“This is a book”というファイル内容が保存されているとする。実際は、実データアドレスはバイト単位で管理されるのが一般的なため、&001と&002のように連続するのは特殊な例である。
図1に示すメタデータテーブル162には、保存されたkey−valueペアが示されている。keyはデータファイルから抽出されたもので、検索対象の要素あるいは集合である。この例ではkeyは集合であり、&001と&011という要素を含む。Valueはkeyが見つかったときに返される値である。この例では“book”という単語を含むデータファイルのファイルIDの集合を、実データアドレス空間のアドレスの形でvalueとして格納している。
図1中の手順に従って説明すると、
(i)keyをentryとして入力し、メタデータテーブルからvalueを探す。
(ii)見つかったkeyに対応するvalueは、keyが所属する集合を保存する実データアドレスなので、その実データアドレスを参照する。
(iii)参照された実データアドレスに書かれたデータを出力する。
となる。
このような実データアドレスとメタデータテーブルの関係、およびkey−valueペアの関係は、図2(a)及び図2(b)に示すような、要素と集合の関係となっている。
すなわち、通常のファイルでは、図2(b)に示すように、例えば“a-file.txt”というファイル名のファイルが集合であり、“This is a book”というテキストデータのそれぞれの単語が要素である。ファイルIDも1つの要素である。
一方、メタデータテーブル(メタデータアドレス空間)に置かれた場合、図2(a)に示すように、集合と要素の関係が逆転して整理し直された形態をとり得る。すなわち、「転置」の関係に変換されている。“book”という集合の中には、“a-file.txt”、“b-file.txt”というファイル名が要素として保存されることになる。key−value型データでは、この整理し直された集合名(“book”)を検索し、その要素(“a-file.txt”、“b-file.txt”)を求めていることになる。これは、一般に、全文検索で実行されている転置ファイルの作成と、検索手順そのものであって、key−value型データの実用上の一例といえる。
転置ファイルとは、全文検索機能の実現法の一つである転置インデックス法で用いられる検索のための索引ファイルである。転置インデックス法では、コンテンツ毎にそのコンテンツを含むファイルのリストを格納する転置ファイルと呼ばれる索引データファイルを予め作成し、ファイルの追加/削除の都度あるいは定期的にまとめて、転置ファイルの内容を更新する。コンテンツの検索要求に対しては、その検索対象のコンテンツに対応する転置ファイルの内容を検索結果として出力すればよい。そのため、全文検索の都度、すべてのファイルの内容を調べる必要がない。従って、検索を高速化できる。転置ファイルは、key−value型データの1つの用例であって、本実施形態はこれに限定しないことに注意すべきである。
<key−valueストア方式のコマンド>
ホストシステムからは、メモリシステムのホストインターフェースに対し、key−valueストア要求のための次のコマンドが与えられる。
key−valueストア方式に基づく要求のためのコマンドは、keyに関連付けられた新たな集合(value)を登録するコマンド(PUT)、あるkeyに関連付けられた集合(value)に新たな要素(value)を追加するコマンド(WRITE)、keyに関連付けられた集合(value)の要素をバッファに格納しそのサイズを返すコマンド(GET)、バッファに格納されている要素(value)を読み出すコマンド(READ)、を含む。
コマンド名称は適宜変更されても良く、key−valueストア方式に基づく要求のために新たなコマンドが追加されても良い。例えば、集合(key)に属する要素(value)を整理するためのコマンドや、メタデータテーブル内の集合(key)の並び替えや、要素(value)同士の比較、などを命令するコマンドである。
本実施形態では、コマンド要求に従い、メタデータテーブルと実データ領域の連携がメモリシステム内で行われる。上記コマンドを用いた場合の、key−value型データの追加、検索などの具体的な手順を図3A〜図3Dのフローチャートに示す。
(1)新たなkey−value型データを登録する場合(PUT)、図3Aに示すように、まず、そのkeyがメタデータテーブルにすでに存在しているかを検索する(ステップS1,S2)。keyが見つかれば、出力にエラーを返す、すなわち、keyが既に存在していることを返信して終了する(ステップS3)。
一方、keyが見つからなければ、valueの処理に進む。valueが実データ領域(実データアドレス)に保存されているかを検索する(ステップS4)。そのkey−value型データの登録時点で、valueが実データ領域に保存されていなければ、valueを実データ領域に追加する(ステップS5)。valueが保存されていれば、そのままkeyをメタデータテーブルに保存し、そのkeyにvalueの実データアドレスを関連付けて登録する(ステップS6)。
メモリシステム内で論理アドレス−物理アドレス変換テーブルが管理されている場合、管理している機能回路に対してメタデータテーブルの更新を通知する(ステップS7)。最後に、valueの実データサイズを出力して終了する(ステップS8)。
(2)既にあるkeyに対し、新たなvalueを追加する場合(WRITE)、図3Bに示すように、まず、そのkeyがメタデータテーブルに存在しているかを検索する(ステップS11,S12)。keyが見つからなければ、出力に、例えば、size=0を返してkeyが存在しないことを通知する(ステップS13)。
一方、keyが見つかれば、keyに対応するvalueに保存された実データアドレスが指定する格納場所を参照し(ステップS14)、その格納場所に新たなvalueを追加する。まず、valueの格納場所に空きがあるかを調べる(ステップS15)。valueの格納場所に空きがない場合、別のvalueの実データアドレスへジャンプするためのポインタを格納する(ステップS16)。続いて、そのアドレスが指定する格納場所に新たなvalueを追加する(ステップS17)。
valueの格納場所に空きがある場合は、valueの実データアドレスの空いている格納場所に新たなvalueを追加する(ステップS17)。最後に、valueの実データサイズを出力して終了する(ステップS18)。
(3)keyに関連付けられた集合(value)を得る場合(GET)、図3Cに示すように、まず、そのkeyがメタデータテーブルに存在しているかを検索する(ステップS21,S22)。keyが見つからなければ、出力に、例えば、size=0を返してkeyが存在しないことを通知する(ステップS23)。
一方、keyが見つかれば、keyに対応するvalueに保存された実データアドレスが指定する格納場所を参照する(ステップS24)。そして、その実データアドレスの格納場所に記憶されたvalueを読み出してバッファメモリあるいはレジスタメモリに格納する(ステップS25)。最後に、valueの実データサイズを出力して終了する(ステップS26)。
(4)バッファメモリ(あるいは、レジスタメモリ)に格納されている集合(value)の要素を出力させる場合(READ)、図3Dに示すように、集合(value)の要素が格納されたバッファメモリ内の保管場所を参照する(ステップS31)。そして、集合(value)の要素があるか否かを調べる(ステップS32)。集合(value)の要素が見つからなければ、出力に、例えば、S=NULLを返して集合(value)の要素が存在しないことを通知する(ステップS33)。
一方、集合(value)の要素が見つかれば、指定されたサイズ分に対応する集合(value)の要素を読み出す(ステップS34)。続いて、読み出した集合(value)の要素を出力して終了する(ステップS35)。ここでは、サイズ指定によって要素を読み出す例を示したが、実際にはバッファメモリの場所を特定して読み出しても良い。
なお(3)の手順において、ホストシステムにvalueの実データアドレスの先頭アドレスを返すという場合も有り得る。これは、この手順の後にはたいてい次の(4)の手順が行われることになるので、valueの実データを読み出すのに都合が良いからである。どう定義するかはコマンドセットの定義に依存していて、本出願ではkey−valueストア方式の手順を説明するために具体的なコマンドセットを用いて説明しているので、これに限定されない。他の手順も同様に前記説明に限定されるものではない。
メモリシステムが、Hash−CAMを用いている場合は、keyとvalueが一致していない場合、すなわちkeyとvalueが関連付けられたものでない場合があり得る。なお、Hash−CAMについては後で詳述する。
このため、Hash−CAMの場合は、メタデータテーブル内でkeyを検索する手順において、keyに対応付けられたvalueを参照し、実データとkeyが一致しているか判別する手順が加わる。一致していなければ、Hash−CAMでのkey−valueストア方式のアドレス管理ルール(例えば、隣のアドレスを調べる)に従って、別のkey範囲のメタデータアドレスに指定して検索しなおす。
なお、実際の手順やコマンドはこれに限定されない。例えば、実際の運用で、複数のkeyが見つかった場合には、一度フラグを立てておいてまとめてvalueを読むなど、方法にバリエーションを持たせることができる。
さらに上述したように、例えば、集合(key)に属する要素(value)を整理するためのコマンドや、メタデータテーブル内の集合(key)の並び替えや、要素(value)同士の比較などを命令するコマンドに対する手順があり得る。
なお、keyとvalueは、一方が集合で他方が要素、またはその逆の関係を取り得る。あるいは、1対1に対応するものであるため、両者ともに集合、または、要素ということもあり得る。
本実施形態においては、ホストインターフェースあるいは、それを介してローカルコントローラやメモリコントローラなどが上記検索コマンドを受け付けて、key−valueストア方式の一連の処理を実行することができる。また、メモリシステム内のローカルコントローラあるいはメモリコントローラにダイレクトメモリアクセスコントローラ(DMAC:Direct Memory Access Controller)が備わった構成をとることができ、この場合、メモリシステムが主体的にkey−valueストア方式の動作を制御することが可能である。場合によってはメモリシステム外の別のメモリ(例えばホストシステムのメインメモリ)に主体的にアクセスすることが可能である。
以下では、本実施形態の具体的なハードウェア構成について、適宜、図を用いて説明する。
[第1の実施形態]
第1実施形態のメモリシステムのハードウェア構成について説明する。
図4は、第1実施形態のメモリシステムのハードウェア構成を示すブロック図である。
図示するように、メモリシステム(またはローカルシステム)10は、ホストインターフェース11、ローカルコントローラ12、メモリコントローラ(あるいはチップコントローラ)13、固定長データ生成器14、レジスタメモリ(あるいはキャッシュメモリ、ページレジスタ、R/Wレジスタ、ページキャッシュなどとも呼ばれる)15、及び第1のメモリブロック16を備える。
メモリシステム10のホストインターフェース11には、例えば、AMBA、SATA、PCIe、USBなどのバスを介してホストシステムが接続されている。ホストシステムは、CPU101及びメインメモリ102を有する。
第1のメモリブロック16は、実データ領域161と、実データ領域161から抽出したメタデータテーブル162を格納する。このメタデータテーブル162は、key−value型データを有する。
メタデータテーブル162におけるkey−value型データは、データに関連付けられたメタデータとしてのkeyと、関連付けられたデータの実データアドレスの先頭アドレス(value)を、リストとして格納する。このkey−value型データを用いて、例えば、上述した転置ファイルなどを構成することができる。
第1のメモリブロック16には、例えば、不揮発性半導体メモリの1つであるNANDフラッシュメモリが用いられる。NANDフラッシュメモリは、1つのチップでもよいし、記憶容量を増大させるため複数のチップで構成されていても良い。なお、第1のメモリブロック16には、その他、記憶不揮発性を有する固体チップLSIであれば、例えば、MRAM(Magnetic Random Access Memory)やReRAM(Resistive Random Access Memory)も用いることができるが、これらに限定されるものではない。
ホストインターフェース11は、ホストシステムからアドレス指定による通常のデータ操作要求、すなわちデータ書き込み及び読み出しの要求と、メタデータテーブル162内のkey−valueストア型データへの書き込み及び読み出しの要求を受け付けることができる。
第1のメモリブロック16への書き込み及び読み出し要求は、メモリコントローラ13で受け付けられ、制御される。さらに、メモリコントローラ13と第1のメモリブロック16との間には、固定長データ生成器14とレジスタメモリ15が接続されている。レジスタメモリ15は、ページレジスタ、R/Wレジスタ、ページキャッシュなどとも呼ばれるが、書き込みあるいは読み出しを行う際に、一時的に記憶領域として使用される。特に、このレジスタメモリ15には演算機能が備わっており、一般的にNANDフラッシュメモリの多値動作を制御するために用いられ、本実施形態でも同様に用いられる。
本実施形態では、第1のメモリブロック16に対しkey−value型データの書き込み及び読み出しを行うために用いられる固定長データ生成器14、例えばハッシュ生成器を備えていることを特徴とする。ハッシュ生成器は、keyの入力に対して、key−value型データが記憶されたアドレスを取得するアドレス取得回路として機能する。ここで、ハッシュ生成器は、ハッシュ関数を生成する機能を有する電子回路と見なして良いが、専用回路を用いてもよいし、あるいは汎用演算回路にハッシュ関数アルゴリズムを入力したものを用いても良い。
ハッシュ生成器により生成されたハッシュ値(アドレス)は衝突する可能性がある。メモリコントローラ13は、ハッシュ値の衝突後の処理のための比較回路やアドレス管理回路を備える。固定長データ生成器(ハッシュ生成器)14とアドレス管理回路を用いたデータ格納・検索方法については後述する。なおここでは、メモリコントローラ13と固定長データ生成器14が個別に形成された例を示したが、メモリコントローラ13が固定長データ生成器14を含んでいてもよい。
さらに、本実施形態の構成として、ホストインターフェース11と第1のメモリブロック16の相互の信号送受信を制御するためにローカルコントローラ12を備える。ローカルコントローラ12は、第1のメモリブロック16から出力されたデータに対するエラー訂正符号復号(ECC)回路を備えることができる。なお、ECC回路は、メモリコントローラ13に備わっていればローカルコントローラ12に備える必要はない。
また、ローカルコントローラ12は、第1のメモリブロック16の論理アドレスを物理アドレスに変換する、論理アドレス−物理アドレス変換テーブルを管理する機能を備えることができる。これによりローカルコントローラ12は、実データ領域161及びメタデータテーブル162と論理アドレスとの対応を管理することができる。すなわち、ローカルコントローラ12は、論理アドレス−物理アドレス変換テーブルの中で、実データ領域161とメタデータテーブル162の記憶領域を区別する。このため、第1のメモリブロック16内おいて、実データ領域161とメタデータテーブル162の記憶領域は分離されている必要はなく、混在していてもよい。
これら処理のために、第2のメモリブロックをローカルコントローラ12の内部に含むことができる。あるいは、ローカルコントローラ12の外部にバス線を介して第2のメモリブロックを接続しても良い。
第2のメモリブロックの存在は従来型のSSDであれば自明であるが、仮に第2のメモリブロックが存在しなくとも、本実施形態の最小構成を示す上では必ずしも不都合とならないため、図4では第2のメモリブロックを図示していない。ただし、ローカルコントローラ12が第2のメモリブロックを利用できるのであれば、メタデータテーブルを第1のメモリブロック16から第2のメモリブロック内へ読み出して参照することができる。
なお、第2のメモリブロックは、ホストインターフェース11の通信速度と、第1のメモリブロック16のアクセス速度との速度差を補うためにも使用される。このため、第2のメモリブロックには、第1のメモリブロック16に比べて、揮発・小容量であるがアクセス速度が速いものが用いられる。
例えば、第2のメモリブロックには、揮発性のDRAMもしくはSRAMが用いられる。あるいは、同等の速度と容量が得られれば、不揮発性RAM(Random Access Memory)、例えば、MRAM(磁気抵抗変化膜RAM)、ReRAM(抵抗変化膜RAM)、FeRAM(強誘電体膜RAM)、PCRAM(相変化膜RAM)などを用いてもよい。第1のメモリブロック16にフラッシュメモリを用いたメモリシステムであれば、ローカルコントローラ12、第2のメモリブロック、論理アドレス−物理アドレス変換テーブルを用いて、ウェアレベリング機能を備えるのが一般的であり、本実施形態でこれを用いても良い。
<ハッシュ関数を用いたデータ格納・検索方法>
本実施形態の固定長データ生成器(ハッシュ生成器)14とアドレス管理回路を用いたデータ格納・検索方法について説明する。アドレス管理回路は、メモリコントローラ13に備えられており、ハッシュ値(アドレス)の衝突を回避する処理を行う。
本実施形態は、ハッシュ生成器を備えているため、任意長ビットデータをハッシュ関数によって固定長ビットデータに変換することができる。ここでは、この機能を用いて、ハッシュ生成器が、任意長ビットデータのメタデータから、固定長ビットデータのメタデータアドレスを生成する例を示す。
ハッシュ関数としては、なるべく均一かつ疎な暗号学的ハッシュ関数が好ましい。例えば、SHA−1(Secure Hash Algorithm-1)、SHA−2(Secure Hash Algorithm-2)、MD4(MessageDigest4)、MD5(MessageDigest5)などを使用する。
ハッシュ生成器は、与えられた任意長の<key>を、ハッシュ関数に従って固定長ビットのビット列をhash(<key>)のように得て、さらに所望のビット長(BitLength)に短縮する機能を有する。例えば、次式の除算機能を有する。
<key ID>= hash(<key>) mod BitLength
あるいは、単純に、生成された固定長ビットのビット列の先頭から所望の長さの分だけを切り取って使用しても良い。
このように生成されたkeyIDの長さを、メタデータテーブルのアドレス長と等しくしておけば、そのままメタデータテーブルのアドレスとして利用できる。例えば図1において、メタデータテーブルにおけるkey−value型データで説明すると、ハッシュ生成器による“book”の固定長ビットデータの生成(以下、hash(“book”)と記す)の結果が001であれば、メタデータテーブルの$001番地は“book”というkeyに対応する。この$001番地には対応するvalueが保存されている。
同様に“Blue”の場合もhash(“Blue”)の結果が002であれば、$002のメタデータアドレスに対応するvalueが保存される、という要領でkeyとvalueを格納していく。
keyを検索したい時には、例えば“book”の場合、そのハッシュ関数の出力値(ハッシュ値)である001は、その値がそのまま格納場所のメタデータアドレスなので、直接そのアドレスを参照すれば良い。このような、ハッシュ関数とメモリアドレスの対応を活用したデータ参照方法をHash−CAMと呼ぶ。
Hash−CAMでは、できるだけ疎なハッシュ関数を用いたとしても、確率論的にハッシュ値(アドレス)が衝突する可能性はゼロにはならない。実用上、ハッシュ値の衝突の可能性を減らす最も単純かつ有効な方法は、十分に大きなメモリ空間を用意することである。実際には、メモリサイズは制限されているため衝突は起こりえる。そこで衝突後の処理機能を備えるために、次の機能を持つ比較回路とアドレス管理回路を備えることで解決できる。比較回路は、ハッシュ値が衝突したとき、valueの中を参照してデータを取り出し、取り出したデータとそのkeyとが一致するか否か比較・照合する。アドレス管理回路は、取り出したデータとそのkeyとが一致するとき、ハッシュ値(アドレス)を変更する。
例えば、上記に加えて別のkeyとして“note”を格納するとき、hash(“note”)の結果も001になってしまったとする。その場合は、すでに$001は“book”に使用されているので、別のメタデータアドレスにジャンプする必要がある。そこで例えば、1つ隣のメタデータアドレスへ移動、すなわちアドレスをインクリメントする。図1の例で説明すると、$001が衝突したため、$002が空いているか調べる。しかし、$002もhash(“Blue”)によってすでに使用されているので、さらに次の番地$003を調べる。その結果、$003が空き番地であれば、そこに“note”に対応するvalueを格納する。
この方法を用いると、ハッシュ値が衝突した場合でもデータの格納は可能となる。ただし、key−value型データの検索には工夫が必要である。“note”を検索する場合には、hash(“note”)が001になると、$001のメタデータアドレスを参照するが、すでに格納されていた“book”のvalueが誤って得られてしまう。
そこで、必ずkeyとvalueの対応が正しいかどうか照合する必要がある。“book”のvalueは実データアドレスの&101であるため、&101を参照してデータを読み出す。その先頭データには[book]が保存されているので、“note”のkey−valueペアではないことが判明する。従って、“note”のkey−valueペアを探し当てるために、次のメタデータアドレスの$002も同様に照合し、“note”のkey−valueペアではないことが判明する。結果として、次のメタデータアドレスの$003が正しいkey−valueペアであることが判明する。このように、ハッシュ値が衝突した場合でもkey−value型データの検索は可能となる。
なお、実データ部の[book]、[Blue]、[note]はkeyの照合さえできれば良いので、実質的には、bookをbo、BlueをBl、noteをnoというように先頭の数バイト分を切り取って固定長で用いても良い。ただし、この場合も固定長にした場合に衝突の可能性がゼロではなくなるので注意が必要である。
上記では衝突後にアドレスをインクリメントする方法を用いたが、後述する変形例で示されているように、本実施形態を用いれば、keyすなわちアドレスが衝突していても、それに対応するvalueから実データアドレスを参照できるため、実データアドレス内にkey自体を格納していき、照合するという方式も用いることができる。この場合でも、検索エントリーとしてのkeyと、実データ内のkeyとの照合は必要である。Hash−CAMとしてのアドレス管理回路も必要である。従って、方式は多少異なるものの、前述したHash−CAMと同じ構成で考えれば良い。
以上のように、ハッシュ生成器を用いてハッシュ値(アドレス)を生成し、さらにアドレス管理回路によりハッシュ値の衝突回避の手順をメタデータの保存に加えることにより、メモリシステム10内で効率的にkey−valueストア方式を実現することができる。
本実施形態では、Hash−CAMを実現するために、ハードウェア機能(固定長データ生成器)を備え、さらに固定長データ(アドレス)の衝突を回避する回路をメモリコントローラ13が備えている。ここで、ハードウェア機能(固定長データ生成器)はメモリコントローラ13に備わっていてもよく、その際のkey−value型データの格納は、レジスタメモリ15内で行われても良いし、直接、第1のメモリブロック16に対して行われても良い。
なお、上記構成においてkey−valueストア方式による機能が損なわれなければ、論理アドレス−物理アドレス変換テーブルの一時保存、及びウェアレベリング処理は、メモリシステム10内部で行うことに限定せず、ホストシステムがCPUとメインメモリを駆使して行っても良い。また、メモリシステム10が主体的にkey−valueストア方式を行うために、ダイレクトメモリアクセスコントローラ(DMAC)を備えていても良い。
本実施形態では、各機能ブロック間はバス線で繋がれている。基本的にはメモリシステム内で高速かつ効率的なバス線配置を取られることが望ましいが、例えばチップインターフェース規格と外部インターフェース規格の相違などで、2種類以上のバス線がメモリシステム内で用いられていても良い。
本実施形態よれば、データに関連付けられたメタデータに対するkey−value型データにより、メモリシステムからデータを取り出す処理を簡素かつ高速に行うことができ、かつ、ユーザーはメタデータを任意に扱いつつ、アクセス可能な物理メモリ空間が最大効率で利用可能となるメモリシステムを提供することができる。すなわち、メタデータに対する操作要求をメモリシステムが受け付け、メモリシステム内部のkey−valueストア方式によって効率的かつ高速に処理し、出力することができるメモリシステムを提供できる。
[第2実施形態]
本実施形態は、第1実施形態とハードウェア構成の一部が異なり、key照合専用メモリ空間を有するハードウェアCAMを備える。
図5は、第2実施形態のメモリシステムのハードウェア構成を示すブロック図である。
メモリコントローラ13は、ローカルコントローラ12と第1のメモリブロック16との間の相互の信号送受信を制御する。また、第1のメモリブロック16に対する書き込み/読み出し時のためのレジスタメモリ15を有している。検索要求をこのレジスタメモリ15に一時的に保存し、読み出しの一致判定を行うことができる。バイト単位での並列読み出しと一致判定を行い、任意長の検索データに関しては逐次処理を行うことで一致判定が可能である。
本実施形態では、図5に示すように、メモリコントローラ13からアクセス可能な位置にコンテンツ連想メモリ(CAM:Content-Addressable Memory)24が配置されている。コンテンツ連想メモリ(CAM)とは、アドレスの入力に対してそのアドレスが指定するデータを出力する通常メモリとは異なり、検索データの入力に対して、その検索データと全ての格納データとの一致・不一致の比較演算を同時並列に行い、一致した格納データのアドレスを出力する機能を持つ高速検索用途の特殊メモリである。ここでは、CAM24は、keyの入力に対して、key−value型データが記憶されたアドレスを取得するアドレス取得回路として機能する。また、CAMは、データの一致検索に対して、一致データの有無を“Match Flag”として出力することができる。本実施形態では、CAM24はこれらの機能を実現するための電子回路で実現されているため、ハードウェアCAMと呼んでいる。
このハードウェアCAMは、レジスタメモリ15に直結されていて、メモリコントローラ13とレジスタメモリ15との間に配置されている。なおここでは、メモリコントローラ13とCAM24が個別に形成された例を示したが、メモリコントローラ13がCAM24を含んでいてもよい。
さらに、第1のメモリブロック16はRAM(random access memory)であるため、CAM24と第1のメモリブロック16によりCAM−RAMとして機能する。CAM−RAMとは、前述したCAM24でアドレスを出力させ、アドレス指定アクセスのRAMでデータを出力させるように組み合わせたシステムである。CAMの1つのエントリとRAMの1つのエントリとが一対一対応するように、CAMのアドレスデコーダとRAMのアドレスエンコーダが設計されている。
本実施形態において、keyをCAM24に格納し、それに対応する値(value)の組を第1のメモリブロック16に保存すること、あるいは、第1のメモリブロック16から値(value)をレジスタメモリ15に読み出して、RAM部として保存することにより、CAM−RAMとして機能する。
ハードウェアCAMを用いるには、第1のメモリブロック16内からメタデータテーブルがレジスタメモリ15に転送されている必要がある。このようなCAM−RAMを用いれば、第1実施形態におけるHash−CAMのような、アドレスの衝突が原理的に起こらない。
従って、keyとvalueの照合手続きと検索やり直しが発生することがないため、検索がより高速になる。また、Hash−CAMでは衝突回避の手段として、メタデータアドレスに余裕を持たせる場合が多いが、ハードウェアCAMの場合は衝突が無いためCAM24を効率良く利用することができる。
本実施形態では、CAM24がkey−value型データのkey検索にのみ用いられるため、CAMがデータ入出力のページレジスタ(レジスタメモリ)に接続されていることにより、第1のメモリブロックの物理アドレス空間を、key−value型データのために一部占有させることなく、最大限に利用することが可能となる。その他の構成及び効果は前述した第1実施形態と同様である。
[第3の実施形態]
本実施形態は、第2実施形態と同様に、key照合専用メモリ空間を有するハードウェアCAMを備えるが、第1のメモリブロック16がハードウェアCAMを備えている。
図6は、第3実施形態のメモリシステムのハードウェア構成を示すブロック図である。
図示するように、第1のメモリブロック16は、実データ領域161、及びメタデータテーブルを格納するCAM−RAM163を有する。CAM−RAMの使われ方は、第2実施形態と同様であるが、本実施形態においては、第1のメモリブロック16の一部がCAM専用のアドレス空間である。このため、メタデータテーブルのkeyを第1のメモリブロック16の外へ移動させることなく、直接保存されているkeyの検索が可能となる。
また、第1のメモリブロック16の記憶セル部に対する照合データの与え方を工夫することで、完全並列検索を行うことが可能である。例えば、第1のメモリブロック16がNANDフラッシュメモリで構成されている場合、CAM部に使用する領域は、すべてのゲートに同時に検索データとしての入力を与えられるように、読み出し回路を構成しておく。これにより、検索がヒットしたNANDストリングのみ出力が検知されるようにでき、その出力とRAM部のページアドレスを対応させておけば、CAM−RAMが実現される。その他の構成及び効果は前述した第1実施形態と同様である。
[第4の実施形態]
本実施形態は、第1実施形態と同様に、固定長データ生成器(例えば、ハッシュ生成器)を備えるが、第1実施形態とは固定長データ生成器の設置場所が異なり、ローカルコントローラ12が固定長データ生成器14を備えている。
図7は、第4実施形態のメモリシステムのハードウェア構成を示すブロック図である。
図示するように、固定長データ生成器14はローカルコントローラ12内に配置されている。必ずしも、固定長データ生成器14とローカルコントローラ12とは、物理的に同チップ内にある必要は無い。ローカルコントローラ12が他の機能ブロックと比べて容易に、固定長データ生成器14にアクセス可能な位置にあれば良い。
ローカルコントローラ12は、第2のメモリブロックとしてのバッファメモリ121を含む。このため、ローカルコントローラ12は、第1のメモリブロック16より読み出した論理アドレス−物理アドレス変換テーブルをバッファメモリ121内に格納して、論理アドレス−物理アドレス変換を行うことができる。同様に、NANDフラッシュのウェアレベリング処理を行うこともできる。さらに、ローカルコントローラ12は、メタデータテーブル162と論理アドレスの対応を管理することができる。
本実施形態の特徴として、固定長データ生成器14がローカルコントローラ12内にあるため、論理アドレス−物理アドレス変換の際に、keyのハッシュ値化とvalueへの対応付け、すなわちメタデータテーブル162のkey−value型データの作成がローカルコントローラ12内で効率的に行うことができる。
本実施形態では、Hash−CAMを第2のメモリブロックであるバッファメモリ121で行う方法、第1のメモリブロック16で行う方法の2通りを用いることができる。後者は実施形態1と同様なので説明を省略し、前者について以下説明する。
メタデータテーブルを作成する際には、第1のメモリブロック16からデータを読み出してバッファメモリ121内に格納してハッシュ値化する。Hash−CAMをバッファメモリ121内で行うので、メタデータアドレスはバッファメモリ121の物理アドレスに対応させておく。
作成したメタデータテーブルは第1のメモリブロック16に書き戻すか、第2のメモリブロックであるバッファメモリ121に保持しておく。これにより、メタデータテーブルに対してkey−value型データの参照を行うことができる。
メタデータテーブルがバッファメモリ121のサイズに比べて小さい場合は、第1のメモリブロック16よりも高速なバッファメモリ121内でkey−value型データの参照を行うことができるため、検索がより高速になる。
さらに、バッファメモリ121が不揮発性のRAMの場合は、メタデータを第1のメモリブロック16に書き戻すことなく、メモリシステムの電源をオフにすることができる。再び電源をオンにした後でも、メタデータテーブルはバッファメモリ121に保存されているので、第1のメモリブロック16から読み出す処理は必要ない。このため、結果として全体的な速度向上が得られる。その他の構成及び効果は前述した第1実施形態と同様である。
本実施形態では、Hash−CAMに必要な機能がローカルコントローラ付近に備わっているが、必ずしもHash−CAMはバッファメモリに対して行われる必要はなく、第1実施形態と同様に第1のメモリブロックに対して行われても良い。メタデータテーブルが小さい場合はバッファメモリテーブルにすべて読み出してからHash−CAMを行う方が高速だが、メタデータテーブルがバッファメモリサイズよりも大きい場合、直接第1のメモリブロックに対してHash−CAM動作を行った方が高速になる場合もある。
[第5の実施形態]
本実施形態は、第4実施形態と同様に、第2のメモリブロックであるバッファメモリ121でkey−value型データの参照を行うが、ローカルコントローラ12がハードウェアCAMを備えている。
図8は、第5実施形態のメモリシステムのハードウェア構成を示すブロック図である。
図示するように、バッファメモリ121にCAM122が接続されている。図ではバッファメモリ121とCAM122とが区別して書かれているが、これらが物理的に結合していても良い。
CAM122の出力(ヒット信号)はバッファメモリ121の一部分(例えば、半分程度のメモリ容量)と直接接続されており、CAM122とバッファメモリ121の一部分とでCAM−RAMが構成されている。このため、データ(コンテンツ)指定によるデータの読み出しが可能となっている。
ハードウェアCAM122を用いることで、Hash−CAMのようなアドレスの衝突が原理的に起こらない。このため、keyとvalueの照合手続きと検索やり直しが発生することがないので、検索がより高速になる。
さらに、バッファメモリ121はアクセス性能が高い反面、メモリ容量が第1のメモリブロック16よりも小さいので、効率的なメモリ空間の運用が求められる。本実施形態では、CAM122を追加することにより、バッファメモリ121のメモリ空間は最大効率で利用可能となる。その他の構成及び効果は前述した第2実施形態と同様である。
[第6の実施形態]
本実施形態は、第1実施形態とほぼ同様のハードウェア構成を取るが、メモリシステム10内にローカルコントローラが存在しない点で異なる。
図9は、第6実施形態のメモリシステムのハードウェア構成を示すブロック図である。
図示するように、ホストインターフェース11が直接、メモリコントローラ13へ接続されている。
key−valueストア方式の実現方法は第1実施形態と同様であるが、論理アドレス−物理アドレス変換テーブルの取り扱いが異なる。ローカルコントローラおよび第2のメモリブロックがメモリシステム10内に存在しないため、論理アドレス−物理アドレス変換テーブルは、第1のメモリブロック16から読み出されて、メモリシステム10の外部、例えばメインメモリ102内で取り扱われる。
Hash−CAMは第1実施形態と同様にメモリコントローラ13内で固定長データ生成器14を駆使して行われるため、メタデータテーブル162でのkey−value型データの格納はメモリシステム10内で行われる。key−value型データだけではなく、メタデータテーブル162の変更点もホストシステムに返され、論理アドレス−物理アドレス変換テーブルに反映された後に、適宜、第1のメモリブロック16へ書き戻される。
本実施形態では、メモリシステム10内部にバッファメモリやローカルコントローラを持たず、機能を簡素化しているため、メモリシステム自体はコンパクトになる。
なお、メモリシステム10が主体的にkey−valueストア方式を実行するために、ダイレクトメモリアクセスコントローラ(DMAC)を備え、メモリシステム10とメインメモリ102との間のデータ転送をDMACが制御しても良い。その他の構成及び効果は前述した第1実施形態と同様である。
[第7の実施形態]
本実施形態は、第2実施形態とほぼ同様のハードウェア構成を取るが、メモリシステム10内にローカルコントローラが存在しない点で異なる。
図10は、第7実施形態のメモリシステムのハードウェア構成を示すブロック図である。
ハードウェアCAMによるkey−valueストア方式の実現方法は第2実施形態と同様であり、ローカルコントローラがないことによる機能の特徴は第6の実施形態と同様であるため、説明を省略する。
[第8の実施形態]
本実施形態は、第3実施形態とほぼ同様のハードウェア構成を取るが、メモリシステム10内にローカルコントローラが存在しない点で異なる。
図11は、第8実施形態のメモリシステムのハードウェア構成を示すブロック図である。
CAM−RAMによるkey−valueストア方式の実現方法は第3の実施形態と同様であり、ローカルコントローラがないことによる機能の特徴は第6実施形態と同様であるため、説明を省略する。
以上のように、本実施形態では、key−valueストア方式の仕組みをメタデータとそのテーブル、及び検索器としてのハッシュ生成器(Hash−CAM)、ハードウェアCAM(CAM−RAM)で実現する。
前述した第1から第8実施形態を用いて、key−valueストア方式が実現される場合、さらに、以下のような変形例を取ることが可能であり、以下に具体的に示す。なお、本出願の本旨としては変形例よりも上記実施形態が優先的に解釈される。
[変形例1]
図12は、変形例1における第1のメモリブロック16内の実データ領域161とメタデータテーブル162との関係、及びkey−valueストア方式の仕組みを模式的に示す図である。
図12に示す実データ領域161では、実データアドレスに、データファイルと、そのファイルに対応するファイル名あるいはファイルIDと、ファイルから抽出したkeyと、keyが格納されたメタデータアドレスとが格納されている。このような保存の方法は、ホストシステムからの命令で行うことができるほか、メモリシステム10に予めkey抽出機能とメタデータアドレス割り当て機能が備わっていれば実現できる。
メタデータテーブル162には、実データアドレスにファイルを保存する際に抽出されたkeyと、keyに対応するvalueとして、keyが存在する実データアドレスと、keyと関連付けられる別のkey−value型データが保存されたメタデータアドレスとが保存されている。
このようなアドレス管理により、ローカルコントローラ12あるいはメモリコントローラ13がkey検索要求を指示したとき、メモリコントローラ13はメタデータアドレスからkeyを検索する。
例えば、“book”を含むファイル名を得たいとき、まずメタデータアドレスから“book”を検索する。“book”はメタデータアドレス$002に格納されている。このメタデータアドレス$002から、valueとして実アドレスの&001、&002と、メタデータアドレスの$011、$012が得られる。
ここで、検索結果として実アドレスを返すことができる。さらに、valueのメタデータアドレスをたどることで、“book”が所属する集合名をたどることができる。例えば、$011では、“a-file.txt”というkeyとそれに対するvalueの実データアドレス、メタデータアドレスを得ることができる。
このように、メタデータテーブル162を連続してたどり、検索結果として求めていた値(実データ)を得ることができる。本変形例では、メタデータテーブルに存在するのはkeyのみであって、実際のkeyは実データ領域161の実アドレスに格納されている。
[変形例2]
図13は、変形例2における第1のメモリブロック16内の実データ領域161とメタデータテーブル162との関係、及びkey−valueストア方式の仕組みを模式的に示す図である。
図13に示す実データ領域161では、実データアドレスに、ファイルと、そのファイルに対応するファイル名あるいはファイルIDが格納されている。メタデータテーブル162には、ファイルから抽出されたkeyと、それに対応するvalueとしてのkeyが存在する実アドレスと、keyに関連付けられた別集合あるいは要素を保存するメタデータアドレスが格納されている。
変形例1と同様に、ローカルコントローラ12あるいはメモリコントローラ13がkey検索要求を指示したとき、メモリコントローラ13はメタデータアドレスからkeyを検索する。
例えば、“book”を含むファイル名を得たいとき、まずメタデータアドレスから“book”を検索する。“book”はメタデータアドレス$002に格納されている。このメタデータアドレス$002から、valueとして実データアドレスの&011と、メタデータアドレスの$011、$012が得られる。
ここで、実データアドレスは“book”が所属するファイルの保管場所ではなく、keyの実データアドレス中の保存場所を示している。一方、valueのメタデータアドレスは“book”が所属する集合を示す。このため、メタデータアドレスをたどり、$011、$012のそれぞれのvalueの実データアドレスが得られて、これらを検索結果として返すか、あるいは実データアドレスをたどって&001、&002のデータを返すことになる。変形例2は、変形例1よりも実データ領域(実アドレス空間)161の一つのアドレスあたりのデータ量が少ないという利点がある。
[変形例3]
図14は、変形例3における第1のメモリブロック16内の実データ領域161とメタデータテーブル162との関係、及びkey−valueストア方式の仕組みを模式的に示す図である。
本変形例では、メタデータの実態が実データ領域161の実データアドレスに保管されていることを示す。
図14に示す実データ領域161では、実データアドレスに、ファイルと、そのファイルに対応するファイル名あるいはファイルIDと、さらにkeyのメタデータアドレスとが格納されている。
メタデータテーブル162では、メタデータアドレスに、ファイルから抽出されたkeyと、それに対応するvalueとしてのkeyが存在する実データアドレスが格納されている。また、メタデータアドレスに対応する物理アドレスが示されている。
このように、メタデータアドレスが実データアドレスと別の物理アドレス空間に割り当てられている場合、メタデータアドレスと物理アドレスの対応表は第1のメモリブロック16に保存されており、メモリシステム(ローカルシステム)あるいはホストシステムがその対応表を呼び出して使用する。
また、メタデータテーブル内のkey検索の方法と、連続したアドレスにvalueが保管されている例を示す。
メタデータテーブル162内のkey−value型データは、図15に示すように、実現することも可能である。メタデータアドレス空間は、第1のメモリブロック16の特定の物理アドレス空間に対応しているものとする。連続したメタデータアドレスの被検索領域を、Slotという単位で区切るものとする。Slot内の先頭領域にはkeyが格納されている。
図15に示す例では、“pen”というkeyを検索する。keyは一文字ずつメモリコントローラ13が与え、Slot全体を検索する。この例でのkey検索の仕組みには、実施形態で示したメモリコントローラ13、レジスタメモリ15におけるハードウェアCAMが用いられる。
“pen”のうち最初の“p”が得られたSlotは、一致フラグを立てておき、そのSlotは次に“e”を検索する。連続してヒットした場合、同様にフラグを立てて次を検索するという操作を継続する。そうして、図15では、#003と#102でkeyの一致が得られ、そのSlotでそのまま連続して読み出すとvalueが得られる。keyとvalueの区切りには、制御コードが挿入されているので区別できるものとする。
また、これを拡張すると、don‘t care マスクビットを与えた検索を行うこともできる。
[変形例4]
本変形例では、固定長のkeyを格納したkey−value型データと、それによる全文検索を例として示す。
固定長ビットの必要性は、検索方式に依存する。全文検索方式は(1)逐次検索、(2)索引検索の2つに大別される。さらに、索引作成(インデクシング)の方法で分類でき、(a)形態素解析、(b)N−gram、(c)接尾辞法、が知られている。
これらのうち、形態素解析は、予め用意された辞書内に存在する単語を抽出する方法である。N−gramは、辞書を用意する必要がなく、単語をN個の要素に分割し、任意の文字列が検索できる。例えば検索対象の集合をSとすると、Sの分割の仕方が1文字ずつならuni−gram、2文字ずつならbi−gram、N文字ずつならN−gramとなる。例えば、S=innovationを分解すると、bi−gramなら、その分割要素(トークン)がat, in, io, nn, no, n, on, ov, ti, va となる。接尾辞法は、任意長を扱うが索引ファイルの圧縮に向いている。
図16に示す実データ領域161では、実データアドレスに、ファイルと、そのファイルに対応するファイル名あるいはファイルIDとが格納されている。メタデータテーブル162では、メタデータアドレスに、ファイルからN−gram方式で抽出されたkeyが格納されている。
この例では、メタデータのkeyは、実データアドレスに保存されている“innovation”から分解抽出したbi−gramである。keyに対応するvalueとして実アドレスが示され、bi−gramでファイルから抽出された際のファイル中の出現位置(position)がペアで格納されている。bi−gramでの検索は、keyを検索したあとはkeyの出現回数でソートし、そのファイル中の位置情報を比較して連続したキーワードであることを確認し、所望の検索語の集合を求める。
ここで、keyが固定長であるため、そのままハッシュ化してkey−value型データを構成することができる。図16の例では、“at”、“in”、がその順でメタデータアドレスにそれぞれ格納されている。実際は、N−gramトークンを、ASCIIやUTF−6などのコードにてビット列で表し、それを短縮してメタデータアドレスとしても良い。
このように、本実施形態によるkey−valueストア方式は固定長を扱うN−gramと相性が良く、高速なインデクシングに向いている。全文検索では、検索は速いがインデクシングに時間がかる。インデクシングは、要素と集合であるメタデータテーブルを適宜読み出し、追加・更新・削除が必要な要素の検索と、その集合の編集を行う。このため、ファイルアクセスが頻発することになるため、本実施形態のメモリシステムを用いることで、メモリシステム内での効率的なkey−valueストア方式の実現によって、ホストシステムに負荷をかけず、高速にインデクシングを行うことも可能となる。
本実施形態においては、メモリシステムにおけるkey−valueストア方式の有用性を示す例として、度々、全文検索の手順で説明したが、本実施形態は必ずしも全文検索に特化した技術ではない。
本実施形態は、メモリシステムにデータを格納する際の、メタデータを効率的に管理するために、key−valueストア方式の仕組みとその具体的構成を提供するものである。
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。