(57)【特許請求の範囲】
【請求項１】
制御モジュールと、
ストレージモジュールと、を含むデータ管理デバイスであって、
ここで、前記ストレージモジュールは、複数のデータセットが割り当てられたような複数のデータ・セット・グループの前記複数のデータセットを、全てのデータ・セット・グループが少なくとも１つのデータセットを含みかつ全てのデータセットが１つのデータ・セット・グループにだけ保存されたような、前記複数のデータ・セット・グループに保存するように構成され、
前記制御モジュールは、複数の排他的実行コンテキストを生成し、各排他的実行コンテキストを1つのデータ・セット・グループに割り当てるように構成され、前記排他的実行コンテキストは、前記データ・セット・グループ上でトランザクションの処理について排他的に責任を持ち、前記排他的実行コンテキストはスレッドであり、
前記制御モジュールは、全てのデータセットに関してデータセット要求の数を推定するように構成され、
前記制御モジュールは、データセット要求の前記推定された数に基づいて全てのデータ・セット・グループに関してデータセットを決定し、およびデータ・セット・グループのデータセット要求の前記推定された数が、前記複数のデータ・セット・グループのうちの１つに割り当てられた少なくとも１つの排他的実行コンテキストのためのデータセット要求の所定の数以下であるような、前記データ・セット・グループに、前記データセットを再割り当てするように構成され、
前記制御モジュールは、１つの排他的実行コンテキストの平均負荷を決定し、および前記平均負荷が所定の負荷値を超える場合、追加の排他的実行コンテキストを生成するように構成され、
前記制御モジュールは、任意の排他的実行コンテキストの作業負荷を決定し、および前記排他的実行コンテキストの第１の作業過程の作業負荷が、前記排他的実行コンテキストの第２の作業過程の作業負荷を超える場合、前記排他的実行コンテキストを前記データ・セット・グループに再割り当てするように構成された、
データ管理デバイス。
【請求項２】
前記制御モジュールが、前記データ管理デバイスの動作中に前記複数のデータ・セット・グループのうちの１つに割り当てられた少なくとも１つの排他的実行コンテキストに、前記所定の数のデータセット要求を動的に適合するように構成された、
請求項１に記載のデータ管理デバイス。
【請求項３】
前記制御モジュールが、全てのデータセットに関してデータセット要求の尤度を推定するように構成され、
前記制御モジュールが、前記ストレージモジュールにわたる要求の累積尤度関数に基づいて全てのデータ・セット・グループに関して前記データセットを決定し、およびデータ・セット・グループの前記要求の数の前記尤度が、前記複数のデータ・セット・グループのうちの１つに割り当てられた少なくとも１つの排他的実行コンテキストのためのデータセット要求の所定の数以下であるような、前記データ・セット・グループに、前記データセットを再割り当てするように構成された、
請求項１または２に記載のデータ管理デバイス。
【請求項４】
データセット当たりの前記データセット要求の数の前記尤度が、各データセットに適用され、個々の要求重みパラメータとデータセット上の要求の前記尤度で計算された累積尤度分布関数（CDF）とによって量られた、前記データセット要求の数を測定することによって近似される、
請求項３に記載のデータ管理デバイス。
【請求項５】
前記制御モジュールが、１つのデータ・セット・グループに含まれる前記データセットの数及び／又はアイデンティティを動的に変えるように構成された、
請求項１乃至４の何れか一項に記載のデータ管理デバイス。
【請求項６】
前記制御モジュールが、少なくとも最初のデータ・セット・グループについて前記データセットを繰り返し決定し、および少なくとも最初のデータ・セット・グループについて決定された前記データセットの数と、少なくとも最初のデータ・セット・グループにおけるデータセットの現在の数との間の差が所定の閾値を超える場合、前記データセットを前記データ・セット・グループに再割り当てするように構成された、
請求項１乃至５の何れか一項に記載のデータ管理デバイス。
【請求項７】
前記制御モジュールが、最初のデータ・セット・グループのデータセット要求の最初の数と二番目のデータ・セット・グループのデータセット要求の二番目の数との間の差が前記所定の閾値と等しいか大きい場合、前記データセットを前記データ・セット・グループに再割り当てするように構成された、
請求項１乃至６の何れか一項に記載のデータ管理デバイス。
【請求項８】
前記制御モジュールは、データセット要求の数及び／又は種類の昇順で前記データセットをデータ・セット・グループに割り当てるように構成された、
請求項１乃至７の何れか一項に記載のデータ管理デバイス。
【請求項９】
前記制御モジュールは、データセット要求の数の降順で前記データセットをデータ・セット・グループに割り当てるように構成された、
請求項１乃至７の何れか一項に記載のデータ管理デバイス。
【請求項１０】
前記ストレージモジュールが、非永続的ストレージである、
請求項１乃至９の何れか一項に記載のデータ管理デバイス。
【請求項１１】
前記制御モジュールが、複数の排他的実行コンテキストを１つのデータ・セット・グループに少なくとも一時的に再割り当てするように構成された、請求項１０に記載のデータ管理デバイス。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ管理デバイスの技術分野に関し、例えば、特に大量のデータを保存および管理し、およびこれらのデータを読み取りまたは書き込み動作のためにクライアントに提供するためのコンピュータデバイスに関する。
【背景技術】
【０００２】
大規模メモリ内データベースは、キー値ストア、オンライントランザクション処理（OLTP）データベース、大規模ウェブアプリケーション、大量のオンライン・マルチプレーヤ・ゲーム、ソフトウェア定義ネットワーク（SDN）コントローラ・ネットワーク・ビュー、科学的シミュレーションなどとして機能するために、現在、生産拠点で使用されている。これらのアプリケーションは、非一様メモリアクセス(NUMA)シェアドエブリシング（shared-everything）アーキテクチャのスレッドなど、複数の実行コンテキストを使用して高いトランザクション率を維持するように構築されており、これによりデータセットは、論理的にパーティション化され、各パーティションは、そのパーティション上のトランザクションを処理する責任がある実行コンテキストに関連付けられている。
【０００３】
Kalman, Robert他：H-store：A High-performance, Distributed Main Memory Transaction Processing System, VLDB Endowment、２００８年８月に記載されているように、分割方法は、パーティション上で実行コンテキストの排他性を強化し、そうすることによってトランザクションは任意のロックまたはラッチを使用することなく、シングルスレッド物理アクセス環境において実行される。このアプローチは、パーティション上で高効率の順次処理と、トランザクション処理をスケールアップすることができるパーティション全体にわたって採用された並列処理とを組み合わせるものとして、説明されることができる。
【０００４】
しかしながら、静的分割方法は、効率の問題が伴い、いくつかの実行コンテキストが例外的に高い更新レートに遭遇することがあり、他のものは不十分であるため、分割することは役に立たず、さらにわずかに歪んだ作業負荷分布がデータセットに課されるとき、拡張性を厳しく制限する。何名かの著者が述べているように、現実の例における可変の作業負荷の歪みは、Pinar Tozun他：Scalable and dynamically balanced shared-everything OLTP with physiological partitioning, The VLDB Journal DOI 1007/s00778-012-0278-6,２０１２年６月に記載されているような例外ではなく、むしろルールである。
【０００５】
Hyeontaek Lim他: MICA: A Holistic Approach to Fast In-Memory Key-Value Storage, NSDI’14, ２０１４年４月, Seattle, WA USAは、パーティション内でキーの位置を分配しようとするスペシャル静的ハッシュ関数を使用することによって作業負荷の歪みをアドレス指定するメモリ内キー値ストアについて記載している。それによって、パーティション上の平均負荷は、Zipf分布実験で５３％偏差未満である。しかしながら、静的な配置および分割方法では、システムは非適応型であり、従って、例えば負荷が低い場合に効率が低下する可能性がある。
【発明の概要】
【０００６】
本発明の目的は、歪み問題を解決するデータ管理デバイスを提供する、つまり異なる排他的実行コンテキスト間の効率的な作業負荷分散を可能にする分割を提供することである。
【０００７】
この目的は、独立請求項の主題によって解決される。さらなる実施形態は、従属請求項および以下の説明において記載される。
【０００８】
本発明の一態様に従って、データ管理デバイスが提供される。データ管理デバイスは、制御モジュールと、ストレージモジュールと、を含むデータ管理デバイスであって、ここで、ストレージモジュールは、複数のデータセットが割り当てられたような複数のデータ・セット・グループの複数のデータセットを、全てのデータ・セット・グループが少なくとも１つのデータセットを含みかつ全てのデータセットが１つのデータ・セット・グループにだけ保存されたような、複数のデータ・セット・グループに保存するように構成され、制御モジュールは、排他的実行コンテキストを各データ・セット・グループに割り当て、および全てのデータセットに関してデータセット要求の数を推定するように構成される。該制御モジュールは、データセット要求の推定された数に基づいて全てのデータ・セット・グループに関してデータセットを決定し、およびデータ・セット・グループのデータセット要求の推定された数が、複数のデータ・セット・グループのうちの１つに割り当てられた少なくとも１つの排他的実行コンテキストのためのデータセット要求の所定の数以下であるような、データ・セット・グループに、データセットを再割り当てするようにさらに構成される。
【０００９】
特に、本明細書で説明されるデータ管理デバイスは、共有された全てのアーキテクチャの分割されたメモリ内データストアにおいて歪み問題を解決してもよい。グローバル動的作業負荷分布の正確な瞬間統計モデルが構築され、およびデータセットが、知覚された負荷に従って再割り当てされることがデータ管理デバイスの一態様であってもよい。データ管理デバイスは、メモリ内データベースまたはデータ保存に適用されるプロアクティブメソッド（pro-active method）を実装するものとして説明されてもよい。
【００１０】
排他的実行コンテキストは、コンピューティングデバイスの処理ユニット上で実行されるスレッドであってもよい。以下では、スレッドを参照するとき、各記述が一般的に排他的実行コンテキストにも関連することを理解されたい。上記で引用されたようなデータセットは、少なくとも１つのキー値エントリ（好ましくは、分類された、または一緒に集められた２つ以上のキー値エントリ）を含む１つのストライプとして記述されてもよく、およびデータ・セット・グループは、複数のデータセットを含む１つのパーティションである。これらの用語は、それぞれ互いを代表して使用されてもよい。
【００１１】
データセット要求は、クライアントによって開始され、およびパーティションの１つのデータセット上で実行されるスレッドの１つに転送される、データセットへの特に１つの作業（読み/書き）に関してもよい。データセット要求は、（それぞれ排他的コンテキストを備えた）パーティションで処理されてもよく、および様々なタイプ、例えばストラクチャード・クエリ・ランゲージ（structured query language、SQL）またはOLTPトランザクションなどにすることができる。制御モジュールが再分割を開始するとき、実行される要求の総数およびタイプの両方が考慮されてもよく、およびパーティションを崩す/マージする可能性もある。
【００１２】
一般的に、制御ユニットは、その再分割の決定において、どんなプラットフォーム依存のアプリケーションおよび動的情報であっても使用してもよい。
【００１３】
各データ・セット・グループは、複数のデータセットを含み、および各データセットは、１つのデータ・セット・グループにのみ含まれる。この関係は、データ・セット・グループへのデータセットのN対１の関係として説明されてもよい。
【００１４】
スレッドごとの要求は、割り当てられたスレッドの初期数で割られた要求到着率の現在の及び／又は将来の分布の尤度として取られたデータストア上で処理された測定された要求の数に基づいて価値関数として説明されてもよい。制御モジュールが、スレッドの性能を決定できる、または決定した、かつ割り当てられるべきスレッド数を決めることができるとき、スレッドあたりの要求を静的にすることができ、それによって、そのように決めたならば、スレッド数を減少させ、電力消費を節約する。
【００１５】
データ管理装置および特に制御ユニットは、全てのデータ・セット・グループに関するデータセットを決定するように構成される。例えば、全てのデータ・セット・グループの構成が決定される、すなわち、全ての単一のデータセットのために、どのデータ・セット・グループに割り当てられるかが決定される。
【００１６】
例えば、制御モジュールは、データ・セット・グループにわたるデータセット要求の分布に基づいて全てのデータ・セット・グループに関するデータセットを決定し、およびデータ・セット・グループの予想されたデータセット要求の数が、複数のデータ・セット・グループの内の１つに割り当てられる少なくとも１つの排他的実行コンテキストのためのデータセット要求の所定の数より少ないかまたは等しいといったデータ・セット・グループにデータセットを再割り当てするように構成されてもよい。従って、分割は、パーティションごとの要求の予想された数に基づいて実行される。
【００１７】
一実施形態において、制御モジュールは、全てのデータセットに関してデータセット要求の尤度を決定し、及び／又はストレージモジュールの全域で特定の要求タイプの累積尤度関数に基づいて全てのデータ・セット・グループに関してデータセットを決定し、およびデータ・セット・グループにおける数要求の尤度が排他的実行コンテキストごとの要求の所定の数より少ないか等しいようなデータ・セット・グループにデータセットを再割り当てするようにさらに構成されてもよい。例えば、OLTP要求は、読み／書きのためのいくつかのデータストア位置にアクセスしてもよい。言い換えると、OLTP要求は、データストアの特定の位置をカバーする確率を有するゲット／プット（get/put）の拡張である前記サブセット・データ・ストアをカバーする確率を有する。
【００１８】
データ・セット・グループへのデータセットのマッピングが再割り当てされるようにパーティションのサイズ変更をすることは、データ管理デバイスの一態様であってもよい。この再割り当ては、データストアにわたる要求分布の統計的尤度に基づいてもよく、従って、データ・セット・グループにアクセスするプロセスが、要求分散において歪みの存在する状態でシリアライゼーションを回避し、および要求処理の並列化とスケーラビリティを可能にするように、補正および予測ロードバランシングを可能にする。
【００１９】
本発明の態様によれば、制御モジュールが、データ管理デバイスの動作中に複数のデータ・セット・グループのうちの１つに割り当てられた少なくとも１つの排他的実行コンテキストに、所定の数のデータセット要求を動的に適合するように構成される。
【００２０】
従って、例えばデータセット要求の総数が増加または減少する場合、およびデータ・セット・グループおよびスレッドの数が一定のままである場合、閾値はデータ管理デバイスの変更された負荷状態に適合されることができる。
【００２１】
本発明の更なる態様によれば、制御モジュールが、全てのデータセットに関してデータセット要求の尤度を推定し、およびストレージモジュールにわたる要求の累積尤度関数に基づいて全てのデータ・セット・グループに関してデータセットを決定し、およびデータ・セット・グループの要求の数の尤度が、複数のデータ・セット・グループのうちの１つに割り当てられた少なくとも１つの排他的実行コンテキストのためのデータセット要求の所定の数以下であるような、データ・セット・グループに、データセットを再割り当てするように構成される。
【００２２】
言い換えると、制御モジュールは、ストレージモジュールにわたる要求分布の累積尤度関数に基づいて全てのデータ・セット・グループに関してデータセットを決定するように構成されてもよく、ここで各要求に重み、すなわちメトリック値が割り当てられてもよく、および制御モジュールは、データ・セット・グループにおける要求の数の尤度が排他的実行コンテキストごとの要求の所定の数より少ないか等しいような、データ・セット・グループにデータセットを再割り当てするように構成されてもよい。
【００２３】
本発明の更なる態様によれば、データセット当たりのデータセット要求の数の尤度が、各データセットに適用され、個々の要求重みパラメータとデータセット上の要求の尤度で計算された累積尤度分布関数（CDF）とによって量られたデータセット要求の数を測定することによって近似される。
【００２４】
データセット上の要求の尤度は、ストレージモジュールの所定の順序で並べられたデータセット上で計算されてもよい。再分割方法は、以下のような累積分布関数の逆を計算することによって取得されてもよい。
j= CDF-1(work-per-thread*k)
ここで1≦k≦Num_of_threads、jは全順序のデータセットのインデックスである。
【００２５】
従って、データセットごとの要求は、（分類または別の手段によって定義される）ある順序で配列に配置される。例えば、データセットiにおける認められた要求の数を保持する配列pdf[i]であってもよく、１つのデータ・セット・グループにおけるデータセットの数であるNを使用して、0≦i≦Nである。次いで、CDFは、次のように漸化式として計算される。
CDF [0] = pdf [0]
CDF [i] = pdf [i] + CDF [i-1]
ここで、where 1≦i≦Nである。
【００２６】
CDF-1の計算は、以下のようにカスタマイズされた二分探索法を使用することによって行われてもよい。
bin_search (CDF, work-per-thread*k) returns index j
ここで、CDF [j] ≦ work-per-thread*kである。
【００２７】
本発明のさらなる態様によれば、制御モジュールは、１つのデータ・セット・グループに含まれるデータセットの数及び／又はアイデンティティを動的に変えるように構成される。
【００２８】
データ・セット・グループのサイズは、データ管理デバイスの動作中に変更されることができる。１つのデータ・セット・グループに含まれるデータセットのアイデンティティを変更することは、データセットの割り当てをデータ・セット・グループへ再割り当てすることとして説明されてもよく、例えば、データセット１はデータセットの再割り当て後に別のデータ・セット・グループに配置されてもよい。
【００２９】
従って、データ・セット・グループのサイズ及び／又はコンテンツは、データセット要求の数及び／又は種類に基づいて適合されてもよい。データ・セット・グループのサイズを変更することは、要求頻度の低いデータセットを含むデータ・セット・グループが、より大きくされることができ、およびさらに頻繁に要求されるデータセットを含むデータ・セット・グループが、より小さくされることができ（ここで、頻度は例えば上述したような尤度分布関数によって近似される）、そうすることによってデータ・セット・グループの全体的な作業負荷が均一にされ、および（同時に並列化が有効であり）作業要求歪みがある場合にシリアライゼーションを回避することができる、という効果を得ることができる。
【００３０】
例えば、１つのデータ・セット・グループがほとんどの要求を取得した場合、作業負荷歪みが存在する。この場合、１つのスレッドのみがそれらを連続的に処理する。次いでデータ管理デバイスの性能は、通常、２つのスレッドが並列で（２回のスループットで）動作している場合と同じくらいに、２倍に増やされたレイテンシを備えた１つのスレッドのスループットに制限される。
【００３１】
本発明のさらなる態様によれば、制御モジュールが、少なくとも最初のデータ・セット・グループについてデータセットを繰り返し決定し、および少なくとも最初のデータ・セット・グループについて決定されたデータセットの数と、少なくとも最初のデータ・セット・グループにおけるデータセットの現在の数との間の差が所定の閾値を超える場合、データセットをデータ・セット・グループに再割り当てするように構成される。
【００３２】
言い換えると、再分割の計算は、例えば数秒ごとなどのシステムのイベントによって周期的に繰り返されるか、またはトリガされる。最初のデータ・セット・グループの新しいサイズと最初のデータ・セット・グループの古いサイズとの間の差が閾値を超えない場合、分割の計算は破棄される。
【００３３】
制御モジュールは、各データ・セット・グループに関してデータセットの数を繰り返し決定してもよく、および最初のデータ・セット・グループだけでなく各データ・セット・グループにステップを実行してもよい。
【００３４】
一方では、再分割を実行することは計算能力を必要とするため、システムリソースを消費し、および一方で再分割はパーティションおよび割り当てられたスレッドのより良い作業ロードバランスを導く。従って、再割り当ての結果としてのシステム性能上の予想される利得が再分割のために必要とされる計算能力よりも高い場合、査定することが有益であり得る。
【００３５】
この実施形態において、再分割によるシステム性能の予想される利得が再分割のリソースコストよりも高い場合にのみ、再分割は実行され、これは、現在のパーティションサイズと予想される新しいパーティションサイズを比較し、およびそれらの間の差分を決定することによって達成される。
【００３６】
本発明のさらなる態様によれば、制御モジュールが、最初のデータ・セット・グループのデータセット要求の最初の数と二番目のデータ・セット・グループのデータセット要求の二番目の数との間の差が所定の閾値と等しいか大きい場合、データセットをデータ・セット・グループに再割り当てするように構成される。
【００３７】
この実施形態において、２つのデータ・セット・グループ間の差分が所定の閾値よりも大きい場合、再分割が開始される。言い換えると、システム性能の全体的な利得（再分割コスト−システム性能の利得）は、現在のパーティションサイズおよび予想されるパーティションサイズだけでなく、２つ以上のパーティションの相対的なパーティションサイズの変更を考慮してもよい。
【００３８】
これは特に、データ・セット・グループのデータセットを再配置することに関連し、および２つの既存のパーティション間の歪んだ作業負荷の場合に有利であってもよい。
【００３９】
閾値（第１と第２のパーティションとの間の差分）は、再分割があまり行われないように、あるいは計算能力を要する最小の差分で行われないように選択されることができ、および、データ・セット・グループの作業負荷が、歪んだ作業負荷が原因による追加の計算能力が再割り当てプロセスの計算能力と等しいかそれ以上であるようなものである場合、再分割が実行される。
【００４０】
本発明のさらなる態様によれば、制御モジュールは、データセット要求の数及び／又は種類の昇順でデータセットをデータ・セット・グループに割り当てるように構成される。
【００４１】
データセット要求の数の昇順とは、データセット要求の数が増加するようにデータセットが論理的に配置され、次いでこの順序に従ってデータセットのデータ・セット・グループへの割り当てが実行されることを意味する。例えば、少ないデータセット要求を有するデータセットは、最初のデータ・セット・グループがデータセット要求の閾値（＝最初のデータ・セット・グループの全てのデータセットのデータセット要求の合計）に達する等しいデータセットだけ割り当てられるまで、最初のデータ・セット・グループに割り当てられる。後続のデータセットは、各データ・セット・グループについてデータ・セット・グループごとのデータセット要求の閾値に到達するまで、後続のデータ・セット・グループに同様に割り当てられてもよい。
【００４２】
制御モジュールは、ストレージモジュールのデータセットの全順序でデータセットを割り当てるように構成されてもよい。
【００４３】
この実施形態において、比較可能なデータセット要求の数を有するデータセットを含むデータ・セット・グループが生成される。データ・セット・グループの要求の数（すなわち、１つのグループの全てのデータセットの要求の合計）は、同様のレベルに調整され、および個々のデータ・セット・グループのデータセットは、データセットの要求の数がほぼ同じになるようにグループ化されてもよい。
【００４４】
これは、スレッドごとの要求分布において非隣接スパイクを克服する。再分割のあと、データセットは、スレッドおよび一致したパーティションが、それらの作業負荷に従って互いに隣接するようなデータ・セット・グループに配置され、および任意の作業負荷を備えたスレッドは間に配置されない。マルチデータセットトランザクションに関連するデータセット上でスケール(scale)された適切な重みは、総順序においてこれらのデータセットの隣接性を保証してもよく、およびデータ・セット・グループをそれに応じてマージすることを可能にしてもよい。
【００４５】
本発明の更なる態様によれば、制御モジュールは、データセット要求の数の降順でデータセットをデータ・セット・グループに割り当てるように構成される。
【００４６】
この態様において、データセットは、データセット要求の数が減少し、およびデータ・セット・グループへのデータセットの割り当てが、この順序に従って実行されるように論理的に配置される。データセット要求の大きい数を有するデータセットは、最初のデータ・セット・グループが多くのデータセットとして割り当てられデータセット要求の閾値に達するまで、最初のデータ・セット・グループに割り当てられる（＝最初のデータ・セット・グループの全てのデータセットのデータセット要求の合計）。後続のデータセットは、データ・セット・グループごとのデータセット要求の閾値がこのデータ・セット・グループのための閾値に達するまで、後続のデータ・セット・グループに同様に割り当てられる。
【００４７】
この態様において、強く要求されるまたは必要とされるデータセットの位置は、決定されることができる。強く要求されたデータセットは、最初のデータ・セット・グループに配置される。
【００４８】
あるいは、制御モジュールは、ストレージモジュールのデータセットの全順序においてデータ・セット・グループにデータセットを割り当てるように構成されてもよい。
【００４９】
本発明の更なる態様によれば、ストレージモジュールは、非永続的ストレージである。
【００５０】
非永続的ストレージは、ランダム・アクセス・メモリ（RAM）であってもよく、データ・セット・グループは、それにより高いトランザクション率を可能にするためにメモリ内データベースを構築してもよい。
【００５１】
本発明の更なる態様によれば、制御モジュールは、複数の排他的実行コンテキストを生成し、および各排他的実行コンテキストを１つのデータ・セット・グループに割り当てるように構成される。
【００５２】
従って、排他的実行コンテキストは、このデータ・セット・グループのデータセット上の動作を実行するために、１つのデータ・セット・グループに割り当てられる作業スレッドとして説明されてもよい。
【００５３】
複数の排他的実行コンテキストを持つことは、排他的実行コンテキストの階層的なレベルでロードバランシングを可能にし、および既存の排他的実行コンテキストが過負荷である場合、新しい排他的実行コンテキストの作成を可能にする。
【００５４】
ロードバランシングの異なるレベルは、以下のように言及されてもよい。すなわち、ロードバランシングの１番目のレベルは上述したように再分割され、ロードバランシングの２番目のレベルは既存のスレッドの平均作業負荷を減少するために未処理の要求を処理する追加の排他的実行コンテキスト（作業スレッド）を作成することによって実行される。
【００５５】
システム作業負荷が減少した場合、すなわち全体的な作業負荷が許可する場合、制御モジュールは、電力を低減するために少なくとも１つまたは複数の排他的実行コンテキストをシャットダウンし、および残りの排他的実行コンテキストにパーティションを再割り当てする。
【００５６】
本発明の更なる態様によれば、制御モジュールが、複数の排他的実行コンテキストを１つのデータ・セット・グループに少なくとも一時的に再割り当てするように構成される。
【００５７】
制御モジュールは、プロセッサの１つまたは複数のプロセッサあるいはコアにすることができる。制御モジュールは、μ秒の時間スケールで作業負荷を達成するために、スレッドの作業を取得し、それを別のスレッドに割り当ててもよい。この割り当ては、一時的な割り当てであることが好ましい。すなわち、１つの排他的実行コンテキストが過負荷であり、別の排他的実行コンテキストがその要求キューに未解決の要求を有さない場合である。
【００５８】
この実施形態において、特に、１つの排他的実行コンテキストが１つのデータ・セット・グループの利用可能な作業負荷を利用できない場合、分散されたシステム、すなわち排他的実行コンテキストとデータ・セット・グループが同じくらいのレベル、例えば、それらの最大容量の75％と85％の間の両方の範囲でロードされる分散されたシステムを有するために、２つ以上の排他的実行コンテキストを１つのデータ・セット・グループに割り当てることが有利である。
【００５９】
本発明のさらなる実施形態によれば、制御モジュールが、１つの排他的実行コンテキストの平均負荷を決定し、および平均負荷が所定の負荷値を超える場合、追加の排他的実行コンテキストを生成するように構成される。
【００６０】
従って、排他的実行コンテキストの数は、現在のシステム全体の負荷に基づいて適切に決定されることができる。同様に、作業負荷が許可する場合、排他的実行コンテキストの数は減らされてもよい。
【００６１】
本発明のさらなる実施形態によれば、制御モジュールが、任意の排他的実行コンテキストの作業負荷を決定し、および第１の排他的実行コンテキストの作業負荷が第２の作業過程の作業負荷を超える所定の閾値である場合、排他的実行コンテキストをデータ・セット・グループに再割り当てするように構成される。
【００６２】
これは、追加のレベルでロードバランシングを可能にする。最初のロード・バランシング・メカニズムは、データ・セット・グループのサイズ変更であり、２番目のロード・バランシング・メカニズムは、データ・セット・グループへの作業プロセスの再割り当てである。従って、ロードバランシングの粒度が改善され、異なるメカニズムが異なるシナリオで使用されることができる。特に、データ・セット・グループへの作業プロセスの再割り当ては、データ・セット・グループをサイズ変更するよりも低い計算能力が必要とされる。
【００６３】
言い換えると、データ管理デバイスは、以下のように説明されてもよい。データ管理デバイスの態様は、作業負荷のダイナミクスを考慮することによって、データセットのパーティション上のスレッド排他性の概念をさらに一歩進めることが見られ得る。キー値ストアをストライプの集合としてモデル化し、およびそのストライプパーティションに適用される各スレッド動作のコストをモデル化することにより、パーティションにわたるグローバルな負荷分散の統計モデルが構築される。このモデルは、プラットフォーム特性によって、およびシリアル-パラレルトレードオフ推論を適用することと組み合わされることによって強化され、知覚された負荷の下で十分なスループット−レイテンシ全体性能に到達するデータセットの新しい動的に均衡のとれた分割を計算するために使用される。シェアドエブリシングアーキテクチャの利点を得ることにより、パーティションのサイズ変更は、任意のデータ移動することなしに生じてもよい。
【００６４】
このアプローチは、知覚された作業負荷に従って全てのマシンリソース利用のグローバルな視点を可能にしてもよく、それによって知覚された作業負荷をより効率的なリソース利用と一致させることができてもよく、従って高効率を促進する。データ管理デバイスは軽量であり、歪んだ作業負荷分散と変動に迅速に対応し、および１つのスレッドから作業を盗み、盗んだ作業を別のスレッドに再割り当てすることを通じて、瞬間的な分散を可能にしてもよい。本明細書で説明する手法は、例えばホット/コールド（hot/cold）クラスタリングのような動的キャプチャ情報に基づいて高度な最適化を可能にしてもよい。静的な知識および制約は、シングルスレッドの性能を向上するために使用されてもよい。動的情報は、マルチスレッドの性能を向上するために使用されてもよい。要するに、これらの全ての性質は、非常に高い効率をスケーラブル(scalable)なキー値ストアに提供してもよい。
【図面の簡単な説明】
【００６５】
本発明の実施形態を、以下の図面に関して説明する。
【図１】複数の要求デバイスに接続された、本発明の例示的な実施形態に従った、データ管理デバイスを概略的に示す図である。
【図２】本発明の例示的な実施形態に従ったデータ管理デバイスのキー値ストア・スレッド・モデルを概略的に示す図である。
【図３】本発明の例示的な実施形態に従ったデータ管理デバイスの複数のデータ・セット・グループにわたる確率分布関数のヒストグラムを概略的に示す図である。
【図４】本発明の例示的な実施形態に従ったデータ管理デバイスにおけるソートされた確率分布関数上の累積分布関数に基づくデータ・セット・グループの分割を概略的に示す図である。
【図５】本発明の例示的な実施形態に従ったデータ管理デバイスにおけるデータ・セット・グループの構成を概略的に示す図である。
【図６】本発明の例示的な実施形態に従ったデータ管理デバイスにおける要求ルーティング処理を概略的に示す図である。
【図７】本発明の例示的な実施形態に従ったデータ管理デバイスにおけるデータ・セット・グループを再分割するステップを概略的に示す図である。
【発明を実施するための形態】
【００６６】
図１は、制御モジュール１００と、ストレージモジュール１１０と、を備えたデータ管理デバイス１０を図示しており、データ管理デバイス１０は、クライアント呼ばれ得る１つまたは複数の要求デバイス２０に通信可能に接続される。データ管理デバイスはサーバと呼ばれてもよい。
【００６７】
ストレージモジュール１１０は、各々が複数のデータ・セット・エントリを有する多数のデータ・セット・グループを含むメモリ内データベースを含むように構成される。制御モジュール１００は、要求するクライアントのストレージモジュール１１０へのアクセスをスケジュールし、およびメモリ内データベースの構造を編成（データ管理デバイスを参照して上述されたように、再分割、パーティションへのスレッド再割り当て等）するように構成される。
【００６８】
図２は、データ管理デバイス１０によって使用されてもよい共有キー値ストア・スレッド・モデルを図示する。特に、図２はメモリ内キー値ストア内の分割およびスレッド割り当てを説明するために参照されてもよい。ストレージレイアウト抽象化１２０は、ストライプ１２２のセットを指定し、各ストライプはキー値ストア内に定義された、いくつかのテーブルの行の集合を表す。キー値ストア演算処理は、フロントエンド（FE）１４０とバックエンド(BE)１３０との間で分割される。ペア動作要求キューおよびその応答キューをそれぞれ含む作業キュー１４２のセットは、FE１４０とBE１３０との間のメインインタフェースである。各キューは、BE作業スレッドに関連付けられている。
【００６９】
FE１４０は、１組の通信スレッド１４４とデマルチプレクサ１４８から成る。デマルチプレクサ１４８は、要求をエンキューする特定のキューを決定するために使用される。通信スレッド１４４は、要求を取得する通信ソケットを読出し、デマルチプレクサを使用してターゲットキューを決定し、および要求を要求キュー上にポストする。逆方向において、通信スレッドは、応答キューを読出し、および関連したソケット１４６に応答を配信する。
【００７０】
BE１３０は、１組の作業スレッド、および各スレッドについてパーティション１２１と呼ばれる異なるテーブルから来ることができる、ストライプ１２２の対応するセットからなる。全てのストライプのパーティションへの分配、およびパーティションへのスレッドの割り当ては分割を決定する。
【００７１】
作業スレッドは、その要求キューから要求をデキューし、そのパーティション内のストライプの１つでそれを実行し、およびその応答キューに応答をポストする。分割が静的である場合、歪んだ作業負荷の元では、要求は少数のパーティションだけをターゲットにしてもよい。少数の作業スレッドは、多くの要求を処理する必要があり、残りのスレッドはアイドル状態であるため、キー値ストアの動作は、高いレイテンシで低いスループットを特徴とする。
【００７２】
歪み問題に対応するために、各ストライプは、ストライプの実行カウントおよびそのグローバルな順序付け位置を全てのストライプの全順序列挙に保存するために追加のメンバでデータセット内で拡張される。最初に、ストライプは、任意に順序付けされることができ、および分割は、各パーティションの同数のストライプを含むことができる。
【００７３】
アプリケーションが実行されるとき、スレッドは、実行された操作の“重み”に比例する数ずつストライプの実行カウントをインクリメントする。確率分布関数（PDF）は、ｘ軸に沿った実行カウントのヒストグラムで（ｘ軸と呼ばれるストライプの全順序位置で識別される）順序付け次元に沿って関連付けられる。
【００７４】
図３は、６２０のストライプに渡るガウスPDFのヒストグラムを示す。
【００７５】
ストライプは、プラットフォームの特性または任意のアプリケーション定義のポリシーから生成された任意のストライプ間の隣接関係を使用してｘ軸に沿って再配置されることができ、これによって、ｘ軸に沿ったストライプの新しい全順序を定義する。ｘ軸がインターバルに分割されると、新しい順序はパーティション間の隣接関係を決定する。例えば、ストライプは、それらの実行カウントによってソートされることができ、それによって“heat”によってストライプを順序付けし、次いで段階的なホット／コールドクラスタリングを取得する。同様に、ストライプ上のトランザクション実行の他の動的なインジケータは、隣接関係としてキャプチャされかつモデルになることができる。
【００７６】
PDFは、新しいｘ軸に沿って統合され、それによって作業負荷の累積分布関数（CDF）を計算する。平均のスレッドごとの作業の値は、右端の境界CDF値を実行スレッドの数で除算することによって計算される。あるいは、ピーク-パフォーマンス状態下で、最大の起こり得るスレッドごとの作業値を学習して、望ましい作業スレッドの数が把握された作業負荷のために適切に生成されることができ、それによって供給されたスループットとレイテンシ間のトレードオフを行い、およびスレッドリソースをほかの所へ割り当てる。
【００７７】
その後、CDFのｙ軸は、スレッドごとの作業値の増分で除算され、次いでｘ軸上に投影され、それによって各インターバルがCDFにおいて等しい増分を有するように、インターバルへのｘ軸の分割を取得する。
【００７８】
図４は、ソートされたガウスPDFにわたって集められた、８つのインターバル、つまり、パーティション２１０，２２０，２３０，２４０，２５０，２６０，２７０，および２８０に分割されたCDFを図示する。最後のパーティション２８０は、６２０で終了し、図３を参照して述べられたストライプの数を参照されたい。
【００７９】
各インターバルは、いくつかのスレッドによって所有されるストライプのパーティションに関連付けられる。従って、これらのパーティションをサイズ変更することにより、実行スレッドにわたる負荷は均一にされる。
【００８０】
関連付けによって、パーティションに対する要求/応答が、接続スレッドによって供給された関連する接続を介して配信されるように、通信スレッドがパーティションを供給するために割り当てられる場合、通信スレッドの負荷は再分割の後に均一にされる。これは、クライアント２０が要求を送信する特定の接続を選択できるような、分割情報のデータ・ストア・クライアント２０への配信を必要とする。
【００８１】
従って、再分割はその上通信を保護し、複数の通信スレッドが一般的なパーティションにそれらの要求をエンキューしたい場合、競合管理に費やされるパフォーマンスのオーバヘッドを回避する。
【００８２】
インバランス検出の手法は、再分割アルゴリズムから導き出されてもよい。すなわち、新しい分割が計算され、および新しいパーティションのサイズが古いもののサイズと比較される。差分が閾値を超える場合、新しい分割は、古いものの代わりにインストールされる。そうでなければ、新しい分割計算は破棄される。
【００８３】
インバランス検出は、定期的に実行されてもよく、あるいは再分割は、重大なインバランス状態を示すいくつかのキュー上の空き要求バッファの枯渇のような、いくつかのシステムイベントによってトリガされてもよい。ゆっくり変化する作業負荷の場合、インバランス検出アルゴリズムはまれにしか実行されなくてもよい。作業スレッド間の負荷分散において瞬間的なスパイクを補償するために、ワーク・スティーリング・ポリシ（work stealing policy）が採用されてもよい。つまり、空のキューを有するスレッドは、その隣接キューを探査してもよく、および隣接のパーティション上で要求を実行してもよい。従って、ワークスティーリングは、瞬間的な動的ロードバランシングも隣接するパーティションにまたがるトランザクションも可能にする。
【００８４】
説明された方法は、シェアドエブリシングアーキテクチャ上の分割されたキー値ストアにわたってグローバルな方法で様々な粒度の歪み問題を解決することを可能にしてもよい。
【００８５】
１つの例示的な実装例が、図５乃至図７を参照して説明される。
【００８６】
この例は、使用可能なハッシュベースのキー値ストアに関する。つまり、ストアはそれらのキーによって識別された行をある順序で保存する。デマルチプレクサ内のハッシュテーブルは、キーをストライプに位置づけし、行はストライプに関連する。
【００８７】
中央のデータ構造は、Ranges[]配列５２０とStripes[]配列５１０の合成である。Stripes[]要素は、ストライプ１２２を表すデータ構造への参照を含む。ストライプデータ構造は、ストライプ上で実行される全ての動作のコストを反映する実行カウンタ５４０を含む。さらに、ストライプデータ構造は、ストライプのグローバル全順序におけるストライプの最初の行の位置を指定する整数値RasMap５３０を含む。
【００８８】
Stripes[]配列５１０は、この全順序に従って順序付けられる。Ranges[]配列５１０は、Stripes[]配列における範囲の高い境界を定義する高インデックスを保持する。範囲の低い境界は、Ranges[]配列の前の要素の“高”インデックスによって暗黙的に定義される。さらに、Ranges[]要素は、作業キュー５２５を含み、ストライプの範囲に関連する。従って、Ranges[]はStripes[]配列を範囲に分割し、および作業キューに範囲を位置づけする。
【００８９】
図５は、２つのテーブルを表し、Ranges[]および５つのストライプ構造への参照を保持し、および各ストライプのRasMapおよびExecCounterメンバを保持するStripes[]の構成を図示する。Stripes[]参照は、RasMap値５３０によって順序付られ、これはExecCount５４０の値に従って、実行カウントによってストライプの順序を反映する。また、ここで留意すべきは、各範囲が異なるテーブルからストライプを保持することである。
【００９０】
Ranges[]とStripes[]の構成がサポートする基本的な動作は、特定のキューへの要求のルーティング、および再分割、つまり、動的なパーティションのサイズ変更、言い換えると、スレッドのパーティションにストライプを含めるという動的な制御である。要求ルーティングプロセスは、図５の下部に概略的に図示される。図６は、要求ルーティングプロセスの制御フローを示す。
【００９１】
ステップ５５１で、テーブル、キー、およびポイント動作オペコードを示す要求が受信される。対応するハッシュテーブル５５０は、アクセスされ、テーブルおよびキーをストライプおよびrowidの参照に変換する。“挿入”動作の場合、テーブルのキーへの参照は無い。従って、対応するテーブルの挿入方法が呼び出され、これは挿入のためのストライプとrowidを指定し、対応するハッシュテーブルに配置される。そこから、挿入は更新として処理される。
【００９２】
ステップ552で、ストライプ参照を保持し、そのRasMapが読み出され、およびオペコードが対応するストライプのメソッド呼び出しポインタに“translated”される。要求-応答バッファ560が取得され、およびメソッド、rowid、および任意の追加の変数で埋められる。
【００９３】
ステップ５５３で、Ranges[]配列は、取得されたRasMapを使用して二分探索される。ステップ５５４で、二分探索では、Stripes[]のサブ範囲の低いおよび高い要素がそれらのRasMapにデリファレンス（dereference）され、取得されたRasMapと比較される。RasMapがサブ範囲に含まれるのに対して、要求−応答バッファはサブ範囲の作業キューにプッシュされる。
【００９４】
言い換えると、図６に示すように、ステップ６１０で、要求のプライマリキーは、ストライプおよび要求が実行される行の行ＩＤを取得するためにデマルチプレクサハッシュテーブル５５０を介してハッシュされる。取得されたストライプ構造を得ると、行のRasMapは、ステップ６２０で行IDとストライプのRasMapを加算することによって計算される。ステップ６３０で、取得されたRasMapを用いて、範囲および関連した作業キューを見出すRanges[]配列上で二分探索が実行される。最後に、ステップ６４０で、要求は、見出された作業キューにキューイングされる。
【００９５】
図７は、説明の簡略化のために、ストライプが分割できないと見なされる再分割の基本的な制御フローを示すフローチャートを含む。ストライプは、分割されてもよく、および分割に従ってマージされてもよい。この例において、ストライプは「heat」つまり要求の数によってクラスタ化される。
【００９６】
周期的に実行される別のスレッドにおいて、ステップ７１０で、全てのストライプ構造に対する参照を保持する一時的なStripes[]配列が、実行カウンタに従ってソートされる。ストライプの構造RasMap’sは、ソート順を反映した後で更新される。次に、ステップ720で、CDFが、一時的な配列にわたって単純再帰を使用して計算される。スレッドごとの平均作業値は、最後のCDF要素を作業スレッドの数で除算することによって、ステップ７３０で計算される。新しく、一時的なRanges[]配列が、多様なスレッドごとの平均作業値によってCDF配列を二分探索することによってステップ740で計算される。最後に、ステップ750で、全ての通信スレッドを一時停止する間に、古いRanges[]およびStripes[]は、一時的なRanges[]およびStripes[]によって置き換えられ、およびStripesのRasMapは、更新される。最終的に、ストライプは、ステップ760で対応するスレッドコアに徐々にリバウンドされ、およびステップ770で、通信スレッドを放棄する。再割り当ての大半は、キー値ストアの通常の動作に影響を与えることなく行われ得、従って比較的軽量にすることに留意されたい。
【符号の説明】
【００９７】
１０  データ管理デバイス
２０  クライアント
１００  制御モジュール
１１０  ストレージモジュール
１２１  パーティション
１２２  ストライプ
１３０  バックエンド（ＢＥ）
１４０  フロントエンド（ＦＥ）
１４２  作業キュー
１４４  通信スレッド
１４６  ソケット
１４８  デマルチプレクサ
２１０  パーティション
２２０  パーティション
２３０  パーティション
２４０  パーティション
２５０  パーティション
２６０  パーティション
２７０  パーティション
２８０  パーティション
５１０  配列
５２０  配列
５２５  作業キュー
５３０  ＲａｓＭａｐ
５４０  実行カウンタ
５５０  ハッシュテーブル
５６０  要求−応答バッファ
【図１】
0006429262.tif 000002
【図２】
0006429262.tif 000003
【図３】
0006429262.tif 000004
【図４】
0006429262.tif 000005
【図５】
0006429262.tif 000006
【図６】
0006429262.tif 000007
【図７】
0006429262.tif 000008