JP2019029011A - 最適なソートキーの圧縮およびインデックスの再構築 - Google Patents

最適なソートキーの圧縮およびインデックスの再構築 Download PDF

Info

Publication number
JP2019029011A
JP2019029011A JP2018135727A JP2018135727A JP2019029011A JP 2019029011 A JP2019029011 A JP 2019029011A JP 2018135727 A JP2018135727 A JP 2018135727A JP 2018135727 A JP2018135727 A JP 2018135727A JP 2019029011 A JP2019029011 A JP 2019029011A
Authority
JP
Japan
Prior art keywords
index
key
bit position
bitmap
bit
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.)
Granted
Application number
JP2018135727A
Other languages
English (en)
Other versions
JP6847079B2 (ja
Inventor
ヨン・シク・クウォン
Yong Sik Kwon
クンス・パク
Kunsoo Park
チョル・ユ
Cheol Yoo
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.)
SAP SE
Original Assignee
SAP SE
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 SAP SE filed Critical SAP SE
Publication of JP2019029011A publication Critical patent/JP2019029011A/ja
Application granted granted Critical
Publication of JP6847079B2 publication Critical patent/JP6847079B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22—Indexing; Data structures therefor; Storage structures
    • G06F16/2228—Indexing structures
    • G06F16/2272—Management thereof
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22—Indexing; Data structures therefor; Storage structures
    • G06F16/2228—Indexing structures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (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)

Abstract

【課題】最適なソートキーの圧縮およびインデックスの再構築方法およびシステムを提供すること。
【解決手段】データベースインデックスのインデックスキーに関する弁別ビット位置をプロセッサによって決定することと、インデックスキーのビットの連結をプロセッサによって決定することと、連結のレコードを生成することとを含むシステムおよび方法。他のシステムおよび方法は、データベースインデックスのインデックスキーを並列にプロセッサによって収集することであって、目標テーブルのデータページが複数のプロセッサコアに均等に分散される、ことと、データページをコアの各々によってスキャンして、圧縮されたキーおよび対応するレコード識別子を抽出することと、並列ソートアルゴリズムに従って、圧縮されたキーと対応するレコード識別子とのペアを複数のプロセッサコアによってソートすることと、インデックスツリーをボトムアップで生成することと、生成されたインデックスツリーのレコードを記憶することとを含む。
【選択図】図5

Description

本願は、最適なソートキーの圧縮およびインデックスの再構築に関する。
インデックスがデータベーステーブルに関して維持され、インデックスキーがテーブルの1つまたは複数の列からなる状況では、インデックスが何らかの理由で失われるかまたはその他の形で利用不可能であるかのどちらかとなる時点が存在する可能性がある。そのような場合、インデックスが再構築される必要がある。インデックスを正確に再構築するために、インデックスキーは、キー値の順序でソートされるべきである。データベーステーブルのインデックスを再構築する際の1つの考慮事項は、インデックスを正しくソートするために保持すべき最小限の情報(たとえば、インデックスキー内のビット数)が何であるかということである可能性がある。この最小限の情報は、インデックスが再構築され得るインデックスキーの正しいソートされた順序を決定するのに十分であるべきである。
データベースレプリケーションを含む一部のシナリオにおいては、マスタサーバにおいて作成されたインデックスが他の複製に反映されるべきである。このタスクを達成する1つの方法は、インデックスイメージ(index image)をネットワークを介して他の複製に送信することである。しかし、この方法は、レプリケーションシステムの性能のボトルネックになる可能性があるネットワークのオーバーヘッドを招く。別のインデックスレプリケーション方法は、ネットワークのオーバーヘッドをさけるために複製におけるインデックスの作成の再現を含む可能性がある。いくつかのその他の手法は、複製におけるインデックスの作成のコストを下げるために使用される可能性がある何らかの情報が存在するかどうかの判定を試みることによって、インデックスのレプリケーションまたは再構築の改善を追究する可能性がある。
一部の状況においては、システムリソースを温存しながらインデックス再構築動作をより効率的に実行したいという要望が存在する可能性がある。
インデックスビットの図である。 インデックスビットの図である。 インデックスキー値の例示的な2進表現の図である。 インデックスキー値の例示的な2進表現の図である。 インデックスキー値の例示的な2進表現の図である。 例示的なインデックスキーの図である。 例示的なインデックスキーの図である。 インデックスツリーの図である。 インデックス再構築手順の図である。 一部の実施形態による例示的なデータのフォーマットおよび処理の図である。 一部の実施形態による例示的なシステムのブロック図である。
以下の説明は、当業者が記載された実施形態を作り、使用することを可能にするために提供される。しかし、当業者には、様々な修正が、容易に明らかであろう。
通常のデータベースは、インデックスを永続的な構造として扱い、したがって、いずれのインデックスの更新も、実行時ディスクI/O (入力/出力)が永続的な更新ログおよびインデックスノードページ(index node page)に書き込むことを招く。インメモリデータベースには、インメモリ(すなわち、永続的でない)インデックス構造を維持する異なる手法が使用される可能性がある。たとえば、更新トランザクションは、インデックスの更新に関連する実行時ディスクI/Oを排除するのでこの手法から恩恵を受ける可能性がある。しかし、この手法は、データベースリカバリ中にインデックスを構築するコストを招く。本開示は、データベースリカバリ中のインデックスの再構築のコストを著しく削減し得るシステムおよび方法を提供する。出願人は、たとえば、ディスク上にあるインデックスイメージのメモリへのロードよりも高速である、本明細書において開示されるマルチコアCPUによる並列的なインデックス再構築方法およびシステムを(たとえば、実験により)実現した。
本開示は、いくつかの技術革新を含む。本明細書においては、インデックスキーの「弁別ビット(distinction bit)」が、インデックスキーを正しくソートするために必要とされる(すなわち、インデックスキーの正しい順序を決定するために必要かつ十分な)最小限の情報であることが示される。その他の開示される態様は、一実施形態において、インデックスキーの弁別ビットのみを記憶するソートキー圧縮方式を含む。このソートキー圧縮方式は、インデックスを再構築するコストを削減するのに有用である可能性があるメカニズムを提供する。弁別ビットがインデックスキーの順序を正確に決定するために必要とされ、使用される最小限のあり得る情報であるという意味で、本明細書において開示されるキー圧縮方式は、最適であると考えられ得る。
一部の実施形態において、本明細書のキー圧縮方式の圧縮比は、関連するデータセットの特徴に応じて変わり得る。出願人は、約2.4:1から約5:1までのサンプルデータセットに関する圧縮比を実現しており、このことは、大規模なインデックスの再構築中の大きなメモリ空間の節約および性能の向上につながる。本明細書において開示されるソートキーの圧縮は、軽量な方式とみなされ得る(たとえば、保有する情報の量が少なく、キーから最小限の数のビットを抽出するコストが小さい)。しかし、メモリ空間の節約および性能の向上へのそのソートキーの圧縮の恩恵は、非常に大きい。さらに、開示されるソートキー圧縮方式は、ワードサイズよりも長いソートキーによるソートを含む様々な異なる用途で使用され得る。
一部の実施形態において、データベーステーブルのためのインデックスキーは、4バイトしかない可能性があるが、一部のビジネスアプリケーションにおいては30バイトを超える可能性がある。したがって、インデックスツリーおよびすべての関連するアルゴリズム(たとえば、インデックスキーをソートする、インデックスを構築する、クエリキーを用いて検索するなど)は、長いキーおよび短いキーを扱うことが可能であるべきである。本明細書のソートキー圧縮およびインデックス再構築プロセスは、この幅広いインデックスキーサイズを仮定する。一部の実施形態においては、本明細書のソートキー圧縮方式が、商用のインメモリDBMSのインデックスツリーに適用され得る。
一部の実施形態においては、インデックス再構築プロセスを高速化するために、マルチコア並列処理が、以下の4段階でDB (データベース)テーブルからオンザフライでインデックスツリーを再構築する際に利用され得る。
1. DBテーブルのデータページ(data page)が、利用可能なコアに均等に分散される。
2. 各コアが、データページから圧縮されたキー(弁別ビット)を抽出する。
3. 本明細書においては行-列ソートと呼ばれる並列ソートアルゴリズムによって圧縮されたキーをソートする。
4. インデックスツリーを並列に構築する。
TPC-Eベンチマークの様々なDBテーブルおよびインメモリデータベースシステムの1つのDBテーブルを用いて、出願人は、4つのデータセットに関して平均で約3.7:1の本明細書のソートキー圧縮方式の圧縮比を観測した。また、本明細書において開示されるキー圧縮方式は、インデックスの再構築のための時間を4つのデータセットに関して平均で約40%削減することも観測された。1つのデータセットに関してDBテーブルからオンザフライでインデックスツリーを構築するための時間は、16コアで1.76秒であった。このインデックスツリーのイメージが6.74GBであることを考えると、本開示による並列的なインデックスの構築のための実行時間は、200MB/秒のディスクI/Oに対して33.7秒かかり、550MB/秒のSSDに対して12.3秒かかるインデックスイメージのメモリへの単純なロードよりもずっと速い。
ソートキー圧縮方式を詳細に説明する前に、まず、いくつかの用語が導入される。キー値のすべてが同一であるビットの位置は、不変ビット位置と呼ばれ、これらの位置のビットは、不変ビットと呼ばれる。その他のビットは、可変ビット位置と呼ばれ、ビット自体は、可変ビットと呼ばれる。図1Aの各行は、インデックスキー値を表す。図1Aにおいて、ビット位置0(105)、3、4(110)、および8、9、10(115)は、不変ビット位置であり、ビット位置1、2(120)、5、6、7(125)、および11(130)は、可変ビット位置である。
Keyiが辞書式順序でi番目のキー値である、すなわち、key0 < key1 <・・・< keynであるものとする。2つのキーkeyiおよびkeyjが異なる最上位ビットの位置は、D-bit(keyi, keyj)と表記される2つのキーの弁別ビット位置と呼ばれ、ビット自体は、「弁別ビット」と呼ばれる。1≦i≦nに対してDi = D-bit(keyi-1, keyi)、すなわち、辞書式順序での2つの隣接するキーの弁別ビット位置とする。補題1は、すべての可能なキーのペアのn(n + 1)/2個の弁別ビット位置が1≦i≦nに対してn個の弁別ビット位置Diによって特徴付けられる可能性があり、これは、本明細書のソートキー圧縮方式における重大な事実である。
補題1. 0≦i < j≦nに対してD-bit(keyi, keyj) = mini<k≦j Dk
d = j - iについて帰納法によって証明する。d = 1のとき、補題が成り立つことは自明である。帰納法の仮説として、補題がd≧1に対して成り立つと仮定する。ここで、d+1に対して補題を証明する。D = mini<k≦j-1 Dkとする。(j - 1) - i = dであるので、帰納法の仮説によりD-bit(keyi, keyj-1) = Dである。DおよびDjを考える。
・D > Djである場合、DjはD-bit(keyi, keyj)であり、Dj = mini<k≦j Dkである。
・D < Djである場合、DはD-bit(keyi, keyj)であり、D = mini<k≦j Dkである。
一つのビット位置に2つの可能な状態0および1のみを有するので、DがDjと等しいことはあり得ないことに留意されたい。たとえば、図1Aにおいては、D1 = 5 > D2 = 1であるのでD-bit(key0, key2) = 1であり、D2 = 1 < D3 = 7であるのでD-bit(key1, key3) = 1である。
補題1によって、すべてのキーに関するすべての可能な弁別ビット位置は、Di, 1≦i≦nである。図1Aにおいて、ビット位置1、2、5、および7は、D1 = 5、D2 = 1などであるので弁別ビット位置135である。弁別ビット位置は可変ビット位置であることが分かる。しかし、弁別ビット位置ではない可変ビット位置が存在し得る。図1Aにおいて、ビット位置6および11はそのような位置である(すなわち、可変ビット位置であるが弁別ビット位置ではない)。
インデックスツリー内で部分キー(partial key)を定義するために、パラメータpが与えられる。本明細書において言及されるように、keyiの部分キーは、弁別ビット位置に続くpビットである。図1Aにおいては、D1 = 5であるので、p = 4であるときのkey1の部分キーは、1010である。
本明細書のキー圧縮をさらに説明するために上の定義を用いて、Compress(keyi)は、弁別ビット位置のkeyiのビットの連結であるものとする。本明細書において、図1Bに示されるように、弁別ビットスライス(distinction bit slice) (またはD-bitスライス(D-bit slice))をすべてのキーに関するCompress(keyi)の集合として定義する。弁別ビットスライス150は、Compress(keyi)によって必ずしもソートされないCompress(keyi)の集合である。
定理1. 弁別ビットスライスは、キーの辞書式順序を決定するために必要かつ十分である。
十分性に関して、次の関係、すなわち、すべてのiおよびjに対してCompress(keyi) < Compress(keyj)である場合かつその場合に限りkeyi < keyjが成り立つことを示す。D = D-bit(keyi, keyj)とする。keyiおよびkeyjの初めのDビットが同じであるので、keyiおよびkeyjの順序は、ビット位置Dのビットによって決定される。補題1によって、ビット位置Dのビットは、Compress内にある(したがって、弁別ビットスライス内にある)。したがって、keyiとkeyjとの間の順序は、Compress(keyi)とCompress(keyj)との間の順序と同じである。
上の関係により、キーの辞書式順序が、Compressによって正しく決定され得る。
一部の態様において、弁別ビットスライスのいずれかのビット位置が見当たらない場合にキーの辞書式順序が適切に決定され得ない例を得ることは、容易である。
定理1は、弁別ビットスライスがキーの辞書式順序を正しく決定するための最小限のあり得る情報であることを意味する。
D'-bitスライス(D'-bit slice)は、本明細書においては、すべての弁別ビット位置およびゼロ以上のその他のビット位置のインデックスキーのビットとして定義される。CompressT (keyi)は、D'-bitスライスT内のkeyiのビットであるものとする。図1においては、ビット位置1、2、5、6、および7のすべてのキーのビットが、例示的なD'-bitスライスを作る。
定理2. D'-bitスライスTは、キーの辞書式順序を正しく決定し得る。
定理1の証明と同様に、すべてのiおよびjに対してCompressT (keyi) < CompressT (keyj)である場合かつその場合に限りkeyi < keyjであることを示し得る。
一部の態様においては、DBテーブルのためのインデックスを維持するとき、インデックスキーが、データベース操作によって挿入されるか、削除されるか、または更新される可能性がある。そのような場合、弁別ビット位置が、実行時に変更される可能性がある。たとえば、図1Aにおいてkey3が削除される場合、位置7は、もはや弁別ビット位置ではなく、可変ビット位置になる。key0がさらにkey3まで削除される場合、弁別ビット位置は変わらないが、位置7は不変ビット位置になる。さらなる例によれば、インデックスキーが挿入される場合、新しい弁別ビット位置が追加される可能性がある。
いくつかの点で、多くの挿入、削除、および更新操作が存在するときに弁別ビット位置を実行時に厳密に維持することは非常に高費用である可能性がある。定理2は、アルゴリズムの正しさに影響を与えることなく、弁別ビット位置に加えていくつかのその他のビット位置が認められ得るので、弁別ビット位置を維持することを定理1よりもずっと容易にする。たとえ弁別ビット位置がまったく知られていないとしても、定理2によってすべての可変ビットをD'-bitスライスとして使用することができる。(一部の実施形態においては、実行時にD'-bitスライスを使用し、バッチプロセスとしてまたはバックグラウンド動作においてD-bitスライスを計算する。)
B+木およびその変化形は、検索キーによるデータへの高速なアクセスを可能にするために最新のDBMSにおいてインデックスとして広く使用される。インデックスがテーブルの列A1,..., Akに対して定義される場合、そのキーは、形態(a1,..., ak)の列の値のタプルとして表され得る。タプルの順序は、辞書式順序である。たとえば、k = 2のときの2つのタプル(a1, a2)および(b1, b2)の順序は、以下の通り、すなわち、a1 < b1または(a1 = b1およびa2 < b2)である場合、(a1, a2) < (b1, b2)として決定される。
ここで、タプルの辞書式順序を保つために列の値のタプルから実際のインデックスキーを作成する方法を以下で説明する。インデックスの葉ノードは、テーブルのインデックスキーおよびレコードIDを含む。以下の開示は、まず、異なるデータタイプからインデックスキーを作成する方法を説明し、それから、複数の列からインデックスキーを作成する方法を説明する。
各データタイプ(たとえば、int(eger)、decimal、float、stringなど)に関して、そのインデックスキーフォーマットは、インデックスキーフォーマットの辞書式の2進値の比較(binary comparison)が元のデータ値の比較に対応するように定義される。
整数に関しては、符号付き整数値の領域が、符号なし整数値の領域にマッピングされる。たとえば、符号付き整数が2つの補数を使用する場合、単純に、符号付き整数の最上位ビットをトグル式に切り替える。そして、符号付き整数が、符号なし整数値の領域にマッピングされ、マッピングされた数の順序は、図2Aに示されるように符号付き整数の順序に対応する。
固定小数点数(decimal)に関しては、10進数(decimal number) xが、1Bのヘッダおよび小数部(decimal part)によって表される。ヘッダの最後のビットは、10進数の符号であり(プラスに対して1)、最後から2番目のビットは、エントリがヌルであるか否かを示す(ヌルに対して0)。小数部は、
バイトのxに対応する2進数を含む。小数点の位置は、列のメタデータに記憶される。マッピングに関しては、符号ビットが0である場合、小数部のすべてのビットをトグル式に切り替え、そうでない場合、何もしない。そして、マッピングされた値の順序は、10進数の順序に対応する。decimal(m, n)が合計でm桁で、そのうちのn桁が小数点の右側にあることを意味する図2Bを参照されたい。
浮動小数点数に関しては、符号付き浮動小数点数の領域が、符号なし整数の領域にマッピングされる。たとえば、浮動小数点数は、符号ビット、指数、および仮数として表されると仮定する。符号ビットが0である場合、その符号ビットをトグル式に切り替え、そうでない場合、すべてのビットをトグル式に切り替える。そして、マッピングされた数の順序は、図2Cに見られるように、符号付き浮動小数点数の順序に対応する。
固定文字列(fixed string)に関しては、固定サイズ文字列がそのまま使用される。
最大長の可変サイズ文字列に関しては、ヌル文字(すなわち、φ)は可変サイズ文字列内で認められないと仮定される。(ヌル文字が許される場合、符号化された文字列がヌル文字を持たないように文字の何らかの符号化を使用する必要がある。) 1つのヌル文字が、インデックスキー値を作成するために可変サイズ文字列の最後に付与される。そして、インデックスキー値の辞書式順序は、以下の通り可変サイズ文字列の辞書式順序に対応する。2つのインデックスキーが同じ長さである場合、それらのインデックスキーの間の順序が文字列の順序であることは自明である。2つのインデックスキーが異なる長さを有し(kがより短いキーの長さであるものとする)、それらのインデックスキーの最初のk - 1バイトが異なる値を有する場合、それらのインデックスキーの順序は、最初のk - 1バイトによって決定される。2つのキーが異なる長さを有し、それらのキーの最初のk - 1バイトが同じ値である場合、より短いキーがkバイト目にヌル文字を有し、より長いキーがkバイト目に非ヌル文字を有するので、より短いキーは、辞書式順序内でより小さい。たとえば、2つのキーがABφおよびABAφである場合、ABφは、3バイト目が原因でABAφよりも小さく、これは、2つの文字列ABとABAとの間の辞書式順序である。さらに、弁別ビット位置は、より短いキーのヌル文字に現れる。
各データタイプにおいて、2つのインデックスキーの間の順序は、2つのインデックスキーの辞書式の2進値の比較によって決定され得る。
ここで、複数の列からインデックスキーを作成する方法が、説明される。複数の列に対するインデックスキーが、複数の列からのインデックスキーの連結であるように定義される。たとえば、インデックスキーが以下の5つの列、すなわち、PART(int)、NAME(varchar(30))、XXX(int)、YYY(int)、およびZZZ(varchar(15))に対して定義されると仮定する。いくつかの行内の例示的な列の値が図3Aのテーブル300に示され、3つの行のインデックスキーが図3Bに示される。
上で検討された弁別ビット位置が、これらの完全なインデックスキーに対して定義される。インデックス列のデータタイプが固定長(たとえば、int、decimal、float、および固定サイズ文字列)である場合、列の値が、インデックスキー内で位置を揃えられ、インデックスキーの間の順序が、列の値の辞書式順序によって決定される。
しかし、インデックス列のデータタイプが可変長(たとえば、可変サイズ文字列)である場合、列の値は、図3Bに示されるように、インデックス内で位置を揃えられない可能性がある。依然として、弁別ビット位置は、これらの完全なインデックスキーに対して定義される。2つの行が列内に異なる長さの可変サイズ文字列を有する場合(それらの行は、図3Bに示されるように同じ値の前の列を有する可能性がある)、弁別ビット位置は、上述のようにその列に現れ、2つのインデックスキーの間の順序は、その列内の可変サイズ文字列の辞書式順序によって決定される。
2つのインデックスキーを比較するために、2つのキーの(ワードサイズずつの) 2進値の比較が実行される。1つのインデックスキーがより短い場合、そのインデックスキーには、2進値の比較の際に0がパディングされる。パディングされた値は2つのキーの順序に影響を与えないことに留意されたい。このようにして、弁別ビットおよび弁別ビット位置が、複数の列から導出された完全なインデックスキーに対して定義される。
本明細書において開示されるソートキー圧縮方式はB+木インデックス構造の任意の変化形によって機能し得るが、一部の実施形態においては、そのソートキー圧縮方式は、商用のインメモリDBMSのインデックスツリーに適用される可能性がある。図4Aは、本明細書のいくつかの実施形態に適合する例示的なインデックスツリー400の構造を示す。インデックスツリーの葉ノード(たとえば、図4D)は、各インデックスキーにつき1つずつのエントリのリストと、次のノードへのポインタとを含む。葉ノードエントリ(図4E)は、部分キー値、弁別ビット位置、インデックスキーの長さ、およびレコードIDからなる。レコードIDを入力として取得し、レコードIDに対応する完全なインデックスキーを返すレコードリーダが、存在する。葉ノードのヘッダ405は、その葉ノード内のエントリの最後のインデックスキーへのポインタを含む。非葉ノード(図4B)は、エントリのリストと次のノードへのポインタとを含む。非葉ノードエントリ(図4C)は、部分キー、弁別ビット位置、インデックスキーの長さ、エントリに対応する子ノードへのポインタ、および子の子孫の葉(descendant leave)内の最後のインデックスキーへのポインタを含み、部分キーおよびインデックスキーの長さは、最後の完全なインデックスキーの部分キーおよびインデックスキーの長さであり、弁別ビット位置は、前のエントリの最後の完全なインデックスキーに対する最後の完全なインデックスキーの弁別ビット位置である。
加えて、本明細書においてDS-Infoと呼ばれる各インデックスツリーに関する以下の情報が維持され(すなわち、保有され)、DSは、D-bitスライスを意味する。
D'ビットマップ: 本明細書の圧縮方式は、ビットマップによって表され得る弁別ビット位置を必要とする。ビットマップ内の各ビットの位置は、完全なインデックスキー内の位置を表し、値0は、ビット位置が弁別ビット位置ではないことを意味し、値1は、そのビット位置が弁別ビット位置である可能性があることを意味する。
可変ビットマップ: 可変ビット位置がビットマップに記憶され、ビット位置の値0は、ビット位置が可変ビット位置ではないことを意味し、値1は、そのビット位置が可変ビット位置である可能性があることを意味する。
参照キー値(reference key value): 参照キー値が、不変ビットに関して維持され、参照キー値は、不変ビットがすべてのインデックスキーに関して同じであるので任意のインデックスキー値である可能性がある。
可変ビットマップおよび参照キー値は、インデックスツリーを再構築するときに部分キーを取得するために維持することができる。部分キーがインデックス内で必要とされない場合、可変ビットマップおよび参照キー値は不要であり、効率的なインデックスの再構築のために保有する主要な情報であるD'ビットマップのみが、維持される必要がある。
検索、挿入、および削除操作は、以下で記載されるように、インデックスツリーおよびDS-Infoを用いて実行され得る。
検索操作および所与の検索キー値Kに関して、インデックスツリーは、以下のようにKに関して検索される。
非葉ノードにおいて、Kを非葉ノードエントリ内のインデックスキーと比較する。エントリは子孫の葉内の最後の完全なインデックスキー値(たとえば、A)へのポインタを有するので、2進値の比較は、2つの完全なキー値KおよびAから成り立つ。
葉ノードは、完全なキーである最後のものを除く部分キーのリストを含む。したがって、検索キーKを部分キーのリストと比較する。
挿入操作に関して、挿入キー値Kが与えられると、Kをインデックスツリーに以下のように挿入する。
1. Kを用いてインデックスツリーを下に検索し、挿入のための適切な場所(たとえば、2つのキーAとBとの間)を見つける。
2. 弁別ビット位置D-bit(A, K)およびD-bit(K, B)を計算する。
3. 挿入に対応するインデックスツリー内の変更を行い、D'ビットマップおよび可変ビットマップを以下のように更新する。D'ビットマップに関しては、ビット位置D-bit(A, B)を削除し、新しい弁別ビット位置D-bit(A, K)およびD-bit(K, B)を追加する。しかし、補題1により、D-bit(A, B) = min(D-bit(A, K), D-bit(K, B))である。最小の位置がD'ビットマップ内に既に設定されているので、max(D-bit(A, K), D-bit(K, B))がまだ設定されていない場合、D'ビットマップにmax(D-bit(A, K), D-bit(K, B))を設定しさえすればよい。可変ビットマップに関しては、Kおよび参照キー値に対してビット毎の排他的ORを実行し、可変ビットマップおよび上述のビット毎の排他的ORの結果に対してビット毎のORを実行する。結果は、新しい可変ビットマップになる。D'ビットマップに対する実際の書き込み操作の数は、D'ビットマップ内の1の数によって制限されることに留意されたい。したがって、D'ビットマップに対する実際の書き込み操作が挿入中に発生する可能性は非常に低い。これは、可変ビットマップに関しても同じである。
削除操作に関して、削除キー値Kが与えられると、Kをインデックスツリーから以下のように削除する。
インデックスツリー内で通常の削除が行われるときにKを削除し、D'ビットマップおよび可変ビットマップを変更せずにそのままにする。Kを削除した後、D'ビットマップが有効であることを示す必要がある。AおよびBが、それぞれ、Kの前のキー値および次のキー値であるものとする。Kを削除した後、D-bit(A, B)が、D'ビットマップにおいて設定されるべきである。やはり補題1により、D-bit(A, B) = min(D-bit(A, K), D-bit(K, B))である。D-bit(A, K)およびD-bit(K, B)がD'ビットマップにおいて設定されるので、D-bit(A, B)は、D-bit(A, K)であるのかまたはD-bit(K, B)であるのかに関わらず既に設定されている。
更新操作は、削除操作とその後の挿入操作とによって実現される。
DBテーブル内のデータが変わるとき、DS-Infoは、上で開示されたように漸進的に更新される。たとえば、挿入が起こるとき、多くても1つの弁別ビット位置が、D'ビットマップに追加され、いくつかの可変ビット位置が、可変ビットマップに追加される可能性がある。この操作は、逆戻りが非常に高費用であるため、たとえ削除またはロールバックがあったとしても逆戻りしない。したがって、値が1であるが弁別ビット位置ではないD'ビットマップ内の位置が存在する可能性がある。また、可変ビットマップは、値が1であるが可変ビット位置ではない位置を有する可能性がある。しかし、それらの位置は、定理2に示されたように正しさに影響を与えない。これらのビット位置は、ときどきインデックスをスキャンし、DS-Infoを計算することによって削除され得る。インデックスがあらためて再構築される場合、そのようなビット位置は存在しなくなる。
現在のDS-Infoを用いて、(以下でより詳細に説明さ記載されるように)インデックスツリーを再構築し、DS-Infoが失われたかまたは利用不可能であるときに新しいDS-Infoを再構築することができる。現在のDS-Infoを計算されている新しいDS-Infoと区別するために、現在のDS-Infoは、所与のDS-Infoと呼ばれる。インデックスツリーが再構築された後でさえも、所与のDS-InfoをDS-Infoとして使用し得る。しかし、インデックスの再構築は、DS-Infoをあらためて計算するのにちょうどよいときである。新しいD'ビットマップを作成するために、圧縮されたキーが、所与のD'ビットマップによってインデックスキーから抽出され、圧縮されたキーが、ソートされ、隣接する圧縮されたキーの間の弁別ビットが、計算される(3つのステップのすべては、インデックスの再構築の一部である)。一部の実施形態においては、圧縮されたキーのうちの任意の1つが、参照キー値とみなされる。新しい可変ビットマップを作成するために、可変ビットマップは最初すべて0であり、以下が行われる、すなわち、圧縮されたキーを1つずつ取得し(たとえば、K)、Kおよび参照キー値に対してビット毎の排他的ORを実行し、その後に、上の挿入操作と同様に可変ビットマップを用いてビット毎のORを実行する。(所与の可変ビットマップが0であったビット位置は、新しい可変ビットマップにおいて不変ビット位置のままであることに留意されたい。)インデックスツリーを初めて構築する(すなわち、DS-Infoがまったくない)場合、上記のように、ただし、圧縮されたキーではなく完全なインデックスキーを用いてD'ビットマップおよび可変ビットマップを計算する。
ここから以下に記載されるのは、DS-Infoを使用することによってDBテーブルからインデックスツリーをオンザフライで構築する方法の例である。一部の実施形態において、インデックスキー値からD'ビットマップにおいて設定される位置のビットのみを抽出し、これは、本明細書においてソートキー圧縮と呼ばれる。ソートキー圧縮は、本明細書のインデックスの構築のより小さな空間の利用および高速化の主たる理由である。
図5は、本明細書のいくつかの例示的な実施形態による並列的なインデックスの構築の全体的な手順の図である。特に、インデックスキーを並列に収集するために、目標テーブル505のデータページは、異なるコアに分散されたページのグループ分け510および515によって示されるようにコア(図5に示されていない)に均等に分散される。各コアは、割り当てられたデータページをスキャンし、圧縮されたキーおよび対応するレコードID(RID)を抽出する。圧縮されたキーおよび対応するレコードIDを含むペアは、ソートキーを作る。本例のキー-RIDペアは、図5において520および525に示される。圧縮されたキー-RIDペアは、並列ソートアルゴリズムによって図5の530および535においてソートされる。ソートされた圧縮されたキー-RIDペアに基づいて、インデックスツリー550が、複数のコアからのツリー540および545を合併することによってボトムアップで構築される。
一部の態様において、ソートキー圧縮は、D'ビットマップ内で値1を有する位置のビットを抽出することによってなされ得る。ここから記載されるのは、インデックスキーから圧縮されたキーを得る方法である。実際の実装は特定のプロセッサのリトルエンディアンフォーマットを使用する可能性があるが、図6は、ビッグエンディアンフォーマットの例を示す。
完全なキー605に関して、8バイトの長さのマスク615、620、および625が、D'ビットマップ610から計算される。第1のマスクは、ビットマップ内の最初の1を含むバイトから始まり、8バイトの長さである。第2のマスクは、第1のマスクの後の最初の1を含むバイトから始まり、8バイトの長さであり、以下同様である。図6の例においては、D'ビットマップ610から3つのマスクが得られる。
たとえば、(コピー元からの選択されたビットをコピー先の連続する下位ビットにコピーする) BMI命令PEXTによって、図6において630に示されるように、マスクが値1を有する位置にあるビットがインデックスキーから抽出される。図6のプロセスは、シフトおよびビット毎のOR操作によって抽出されたビットを連結することによって継続する。図6には3つのマスク(たとえば、マスク615、620、および625)があるので、抽出されたビットは、図6に示されるように、各ステップのシフト(635)およびビット毎のOR(640)によって3つのステップ(i)、(ii)、および(iii)において連結される。図6において、645のビット列は、完全なキー605から抽出された圧縮されたキーである。
圧縮されたインデックスキーとレコードIDとのペアがキーの順序でソートされると、インデックスツリーが、ボトムアップで構築され得る。まず、葉ノードが、ソートされた圧縮されたキーおよびレコードIDから構築され得る。弁別ビット位置を計算するために、D'ビットマップ内のi番目の1の位置を記憶する配列D'-offset[i]をD'ビットマップから作成する。そのとき、keyiおよびkeyi+1の弁別ビット位置は、D'-offset[D-bit(Compress(keyi), Compress(keyi+1))]である。次に、非葉ノードをボトムアップで構築する。keyiおよびkeyjに対応する非葉ノード内の2つの隣接するエントリに関して、弁別ビット位置は、D'-offset[D-bit(Compress(keyi), Compress(keyj))]である。
本例のインデックスツリーの場合、葉ノードおよび非葉ノードは、予め定義された長さpの部分キーを含む。部分キーのオフセットは、キー値の弁別ビット位置と同じである。部分キーのオフセットおよび予め定義された部分キーの長さpが与えられると、部分キーのビットが、以下のように決定される。
1. 部分キーのビット位置が圧縮されたキーに含まれる場合、ビット値が、圧縮されたキーから直接コピーされ得る。
2. ビット位置が可変ビットマップ内に値0を有する位置(すなわち、不変ビット位置)である場合、ビット値が、参照キー値からコピーされ得る。
3. それ以外の場合(すなわち、D'ビットマップ内に値0を有し、可変ビットマップ内に値1を有するビット位置)、2つの選択肢を有する。
a. 部分キーの構築のために必要とされるビット(弁別ビット位置の後のpビット)を圧縮されたキーに加え、それらのビットをここでインデックス構築のために使用する。
a. レコードIDもソートキーに含まれるので、必要なビットが、レコードからコピーされる可能性があり、そのために、参照先のデータを得ることが必要とされる。
インデックスを構築するために、2つのパラメータ、すなわち、最大ファンアウト(max fanout)および充填率(fill factor)が維持される。各(葉または非葉)ノードは、256Bのサイズであり、ヘッダ(24B)および次のノードへのポインタ(8B)を有する。葉ノード内の各エントリは16Bを取るので、葉ノード内の最大ファンアウト(すなわち、エントリの最大数)は、14である。非葉ノード内の各エントリは24Bを取るので、非葉ノード内の最大ファンアウトは、9である。充填率は、インデックスの構築中に各インデックスに関して定義され、葉および非葉ノードは、最大ファンアウト×充填率まで埋められる。この例の充填率のデフォルト値は、0.9である。所与の数のレコード、充填率、および最大ファンアウトに関して、インデックスツリーの高さが決定され得る。
インデックスの構築は、インデックスキーとレコードIDとのソートされたペアを区分けし、部分木を並列に構築することによって並列化され得る。すなわち、n個のソートキーが、p個のブロックおよびそれぞれ
個のソートキーに分割され、1つのブロックが、スレッドに割り当てられる(これは、行-列ソートの終わりの状況である)。スレッドi(1≦i≦p)は、i番目のブロック内のすべてのソートキーからなる部分木を構築する。部分木のすべてが構築されるとき、それらの部分木は、以下のように1つのツリーへと合併される。部分木の根ノードのファンアウトは最大ファンアウト×充填率よりもずっと小さい可能性があるので、部分木の根ノードを単にリンクすることは、ツリー全体の高さを不必要に高くする可能性がある。したがって、部分木の根ノードを削除し、部分木の根ノードの個をリンクすることによってツリー全体の最上位層を構築する。このようにして、ツリー全体の高さが最小化され得る。
本開示の様々な態様が、添付の対応する図面を含め、いくつかの例示的な実施形態および応用を通して示された。しかし、本開示は、特定の例示的な実施形態に限定されない。本明細書において開示された技術的なおよび有用なソートキー圧縮の特徴(たとえば、性能およびメモリの改善に結びつけられる、維持される情報の量が比較的少ない(すなわち、ソートキーからの最小限の数のビット)という意味での軽量さ)は、一時的データセットなしに最初のまたは第1のソート操作の後にデータを用いる可能性がある任意の応用に適用され得る。
図7は、本明細書に記載されたプロセスを実行するための例示的なシステムの図を示す。装置700は、通信デバイス720、データストレージデバイス730、1つまたは複数の入力デバイス715、1つまたは複数の出力デバイス725、およびメモリ710に動作可能なように結合されたプロセッサ705を含む。プロセッサ705は、内部の複数のコアによって複数のスレッドを同時に実行することができるマルチコアプロセッサを含み得る。通信デバイス720は、レポートクライアントまたはデータストレージデバイスなどの外部デバイスとの通信を容易にし得る。入力デバイス715は、たとえば、キーボード、キーアッド、マウスもしくはその他のポインティングデバイス、マイクロフォン、ノブもしくはスイッチ、赤外線(IR)ポート、ドッキングステーション、および/またはタッチスクリーンを含み得る。入力デバイス715は、たとえば、装置700に情報を入力するために使用され得る。出力デバイス725は、たとえば、ディスプレイ(たとえば、ディスプレイスクリーン)、スピーカ、および/またはプリンタを含み得る。
データストレージデバイス730は、磁気ストレージデバイス(たとえば、磁気テープ、ハードディスクドライブ、およびフラッシュメモリ)、光ストレージデバイス、読み出し専用メモリ(ROM)デバイスなどの組合せを含む任意の適切な永続的ストレージデバイスを含む可能性があり、一方、メモリ710は、ランダムアクセスメモリ(RAM)、ストレージクラスメモリ(SCM)、または任意のその他の高速アクセスメモリを含む可能性がある。
データベースエンジン735は、本明細書に記載されたプロセス(たとえば、インデックス再構築およびソートキー圧縮プロセス)のうちの任意の1つまたは複数を装置700に実行させるためにプロセッサ705によって実行される論理を含み得る。実施形態は、単一の装置によるこれらのプロセスの実行に限定されない。
データ740(キャッシュされたデータベースかまたは完全なデータベースかのどちらか)が、メモリ725などの揮発性メモリに記憶される可能性がある。データストレージデバイス730は、追加的な機能を提供するための、ならびに/またはデバイスドライバ、オペレーティングシステムファイルなどの装置700の動作のために必要であるデータおよびその他のプログラムコードおよび命令を記憶する可能性もある。
上記の図面は、一部の実施形態によるプロセスを説明するための論理的なアーキテクチャを表し、実際の実装は、その他の方法で配列されたより多くのまたは異なる構成要素を含む可能性がある。その他のプラットフォーム、フレームワーク、およびアーキテクチャが、その他の実施形態と連携して使用され得る。さらに、本明細書に記載された各構成要素またはデバイスは、任意の数のその他のパブリックおよび/またはプライベートネットワークを介して通信する任意の数のデバイスによって実装され得る。そのようなコンピューティングデバイスのうちの2つ以上は、互いに離れて置かれる可能性があり、ネットワークおよび/または専用接続の任意の知られている方法によって互いに通信する可能性がある。各構成要素またはデバイスは、本明細書に記載された機能および任意のその他の機能を提供するのに好適な任意の数のハードウェアおよび/またソフトウェア要素を含み得る。たとえば、一部の実施形態によるシステムの1つの実装において使用される任意のコンピューティングデバイスが、コンピューティングデバイスが本明細書に記載されたように動作するようにプログラムコードを実行するためのプロセッサを含み得る。
本明細書において検討されたすべてのシステムおよびプロセスは、1つまたは複数の非一時的コンピュータ可読媒体に記憶されたプログラムコードに具現化され得る。そのような媒体は、たとえば、フロッピーディスク、CD-ROM、DVD-ROM、フラッシュドライブ、磁気テープ、およびソリッドステートランダムアクセスメモリ(RAM)もしくは読み出し専用メモリ(ROM)ストレージユニットを含み得る。したがって、実施形態は、ハードウェアとソフトウェアとの任意の特定の組合せに限定されない。
本明細書に記載された実施形態は、例示のみを目的とする。当業者は、上述の実施形態に対する修正および変更によってその他の実施形態が実施され得ることを認めるであろう。
150 弁別ビットスライス
300 テーブル
400 インデックスツリー
405 葉ノードのヘッダ
505 目標テーブル
510 ページのグループ分け
515 ページのグループ分け
540 ツリー
545 ツリー
550 インデックスツリー
605 完全なキー
610 D'ビットマップ
615 マスク
620 マスク
625 マスク
635 シフト
640 ビット毎のOR
700 装置
705 プロセッサ
710 メモリ
715 入力デバイス
720 通信デバイス
725 出力デバイス
730 データストレージデバイス

Claims (20)

  1. コンピュータによって実施される方法であって、
    データベースインデックスのインデックスキーに関する弁別ビット位置をプロセッサによって決定するステップと、
    前記インデックスキーの前記ビットの連結を前記プロセッサによって決定するステップと、
    前記連結のレコードを生成するステップとを含む、方法。
  2. 前記連結が、データベース上の前記インデックスキーのすべてに関して決定される、請求項1に記載の方法。
  3. 前記連結に基づいて前記インデックスキーの辞書式順序を決定するステップをさらに含む請求項1に記載の方法。
  4. コンピュータによって実施される方法であって、
    データベースインデックスのインデックスキーに関する弁別ビット位置をプロセッサによって決定するステップと、
    前記弁別ビット位置を第1のビットマップとして表すステップであって、前記第1のビットマップ内の各弁別ビットの位置が、前記インデックスキー内の前記弁別ビットの位置に対応する、ステップと、
    前記インデックスキーの可変ビット位置を第2のビットマップとして表すステップであって、前記可変ビット位置が、ビット位置に関するすべてのキー値が同一ではないビット位置である、ステップと、
    前記インデックスキーの不変ビット位置に関する参照キー値を割り当てるステップであって、前記不変ビット位置が、ビット位置に関するすべてのキー値が同一であるビット位置である、ステップと、
    前記データベースインデックスに関するデータベース操作中に前記第1のビットマップ、前記第2のビットマップ、および前記参照キー値のレコードを維持するステップとを含む、方法。
  5. 前記データベース操作が、挿入操作、削除操作、および更新操作のうちの少なくとも1つである、請求項4に記載の方法。
  6. 前記第1のビットマップに関して、前記第1のビットマップ内のビットに関するゼロに等しい値が、前記ビット位置が弁別ビット位置でないことを示し、前記第1のビットマップ内のビットに関する値1が、前記ビット位置が弁別ビット位置である可能性があることを示す、請求項4に記載の方法。
  7. 前記第2のビットマップに関して、前記第2のビットマップ内のビットに関するゼロに等しい値が、前記ビット位置が可変ビット位置でないことを示し、前記第2のビットマップ内のビットに関する値1が、前記ビット位置が可変ビット位置である可能性があることを示す、請求項4に記載の方法。
  8. 前記不変ビット位置に関する前記キー値が同一であるので、前記不変ビット位置に割り当てられた前記参照キー値が、任意のインデックスキー値である、請求項4に記載の方法。
  9. コンピュータによって実施される方法であって、
    データベースインデックスのインデックスキーを並列にプロセッサによって収集するステップであって、目標テーブルのデータページが複数のプロセッサコアに均等に分散される、ステップと、
    前記データページを前記コアの各々によってスキャンして、圧縮されたキーおよび対応するレコード識別子を抽出するステップと、
    並列ソートアルゴリズムに従って、前記圧縮されたキーと前記対応するレコード識別子とのペアを複数の前記プロセッサコアによってソートするステップと、
    インデックスツリーをボトムアップで生成するステップと、
    生成された前記インデックスツリーのレコードを記憶するステップとを含む、方法。
  10. 圧縮されたキーおよび対応するレコード識別子がソートキーを含む、請求項9に記載の方法。
  11. システムであって、
    プロセッサ実行可能命令を記憶するメモリと、
    前記プロセッサ実行可能命令を実行して、前記システムに、
    データベースインデックスのインデックスキーに関する弁別ビット位置を決定させ、
    前記インデックスキーの前記ビットの連結を決定させ、
    前記連結のレコードを生成させる、
    プロセッサと、を含むシステム。
  12. 前記連結が、データベース上の前記インデックスキーのすべてに関して決定される、請求項11に記載のシステム。
  13. 前記プロセッサが前記プロセッサ実行可能命令を実行して、前記システムに前記連結に基づいて前記インデックスキーの辞書式順序を決定させることをさらに含む、請求項11に記載のシステム。
  14. システムであって、
    プロセッサ実行可能命令を記憶するメモリ、ならびに、
    前記プロセッサ実行可能命令を実行して、前記システムに、
    データベースインデックスのインデックスキーに関する弁別ビット位置を決定することと、
    前記弁別ビット位置を第1のビットマップとして表すことであって、前記第1のビットマップ内の各弁別ビットの位置が、前記インデックスキー内の前記弁別ビットの位置に対応する、ことと、
    前記インデックスキーの可変ビット位置を第2のビットマップとして表すことであって、前記可変ビット位置が、ビット位置に関するすべてのキー値が同一ではないビット位置である、ことと、
    前記インデックスキーの不変ビット位置に関する参照キー値を割り当てることであって、前記不変ビット位置が、ビット位置に関するすべてのキー値が同一であるビット位置である、ことと、
    前記データベースインデックスに関するデータベース操作中に前記第1のビットマップ、前記第2のビットマップ、および前記参照キー値のレコードを維持することと
    を行わせるプロセッサ、
    を含むシステム。
  15. 前記データベース操作が、挿入操作、削除操作、および更新操作のうちの少なくとも1つである、請求項14に記載のシステム。
  16. 前記第1のビットマップに関して、前記第1のビットマップ内のビットに関するゼロに等しい値が、前記ビット位置が弁別ビット位置でないことを示し、前記第1のビットマップ内のビットに関する値1が、前記ビット位置が弁別ビット位置である可能性があることを示す、請求項14に記載のシステム。
  17. 前記第2のビットマップに関して、前記第2のビットマップ内のビットに関するゼロに等しい値が、前記ビット位置が可変ビット位置でないことを示し、前記第2のビットマップ内のビットに関する値1が、前記ビット位置が可変ビット位置である可能性があることを示す、請求項14に記載のシステム。
  18. 前記不変ビット位置に関する前記キー値が同一であるので、前記不変ビット位置に割り当てられた前記参照キー値が、任意のインデックスキー値である、請求項14に記載のシステム。
  19. システムであって、
    プロセッサ実行可能命令を記憶するメモリ、ならびに
    複数のプロセッサコアであって、前記プロセッサ実行可能命令を実行して、前記システムに、
    データベースインデックスのインデックスキーを並列に収集することであって、目標テーブルのデータページが前記複数のプロセッサコアに均等に分散される、ことと、
    前記データページを前記コアの各々によってスキャンして、圧縮されたキーおよび対応するレコード識別子を抽出することと、
    並列ソートアルゴリズムに従って、前記圧縮されたキーと前記対応するレコード識別子とのペアを複数の前記プロセッサコアによってソートすることと、
    インデックスツリーをボトムアップで生成することと、
    生成された前記インデックスツリーのレコードを記憶することと、
    を行わせる複数のプロセッサコア、
    を含むシステム。
  20. 圧縮されたキーおよび対応するレコード識別子がソートキーを含む、請求項19に記載のシステム。
JP2018135727A 2017-07-25 2018-07-19 最適なソートキーの圧縮およびインデックスの再構築 Active JP6847079B2 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US15/658,671 2017-07-25
US15/658,671 US10671586B2 (en) 2017-07-25 2017-07-25 Optimal sort key compression and index rebuilding

Publications (2)

Publication Number Publication Date
JP2019029011A true JP2019029011A (ja) 2019-02-21
JP6847079B2 JP6847079B2 (ja) 2021-03-24

Family

ID=63165155

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2018135727A Active JP6847079B2 (ja) 2017-07-25 2018-07-19 最適なソートキーの圧縮およびインデックスの再構築

Country Status (4)

Country Link
US (1) US10671586B2 (ja)
EP (1) EP3435256B1 (ja)
JP (1) JP6847079B2 (ja)
CN (1) CN109299086B (ja)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11074235B2 (en) * 2017-08-10 2021-07-27 Io-Tahoe Llc Inclusion dependency determination in a large database for establishing primary key-foreign key relationships
US10839019B2 (en) * 2017-09-29 2020-11-17 Micro Focus Llc Sort function race
US11451371B2 (en) * 2019-10-30 2022-09-20 Dell Products L.P. Data masking framework for information processing system
CN111680095B (zh) * 2020-06-10 2021-01-12 上海城市地理信息系统发展有限公司 一种处理点云数据的方法、装置和电子设备
CN112364027B (zh) * 2020-12-09 2023-06-30 北京海量数据技术股份有限公司 并行创建openGauss分区表索引方法、装置及系统
CN112579612B (zh) * 2020-12-31 2023-05-16 厦门市美亚柏科信息股份有限公司 数据库索引表记录分析方法、装置、计算设备及存储介质
US20230195705A1 (en) * 2021-12-20 2023-06-22 Sap Se Branching for tree structure in database system
CN115374127B (zh) * 2022-10-21 2023-04-28 北京奥星贝斯科技有限公司 数据存储方法及装置
CN115617878B (zh) * 2022-11-17 2023-03-10 浪潮电子信息产业股份有限公司 一种数据查询方法、系统、装置、设备及计算机存储介质

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS582938A (ja) * 1981-06-27 1983-01-08 Fujitsu Ltd インデックスの作成方式
US4677550A (en) * 1983-09-30 1987-06-30 Amalgamated Software Of North America, Inc. Method of compacting and searching a data index

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4819156A (en) * 1986-06-13 1989-04-04 International Business Machines Corporation Database index journaling for enhanced recovery
JPH02195480A (ja) * 1989-01-25 1990-08-02 Hitachi Ltd 画像データの検索方式
EP1217541A1 (en) * 2000-11-29 2002-06-26 Lafayette Software Inc. Method of processing queries in a database system, and database system and software product for implementing such method
GB2405499A (en) * 2003-09-01 2005-03-02 Isis Innovation Information system development
US8156156B2 (en) * 2006-04-06 2012-04-10 Universita Di Pisa Method of structuring and compressing labeled trees of arbitrary degree and shape
US20100146003A1 (en) 2008-12-10 2010-06-10 Unisys Corporation Method and system for building a B-tree
CN102411634B (zh) * 2011-12-27 2016-01-13 北京人大金仓信息技术股份有限公司 一种提升嵌入式数据库实时性的数据存储方法
WO2014201047A1 (en) * 2013-06-11 2014-12-18 InfiniteBio Fast, scalable dictionary construction and maintenance

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS582938A (ja) * 1981-06-27 1983-01-08 Fujitsu Ltd インデックスの作成方式
US4677550A (en) * 1983-09-30 1987-06-30 Amalgamated Software Of North America, Inc. Method of compacting and searching a data index

Also Published As

Publication number Publication date
JP6847079B2 (ja) 2021-03-24
US20190034467A1 (en) 2019-01-31
EP3435256A3 (en) 2019-03-06
EP3435256B1 (en) 2020-09-02
CN109299086A (zh) 2019-02-01
EP3435256A2 (en) 2019-01-30
CN109299086B (zh) 2021-11-23
US10671586B2 (en) 2020-06-02

Similar Documents

Publication Publication Date Title
JP6847079B2 (ja) 最適なソートキーの圧縮およびインデックスの再構築
US11899641B2 (en) Trie-based indices for databases
US11520780B2 (en) Distributed database systems and structures
CN111046034B (zh) 管理内存数据及在内存中维护数据的方法和系统
US9600513B2 (en) Database table comparison
US9405806B2 (en) Systems and methods of modeling object networks
WO2021258848A1 (zh) 数据字典生成方法、数据查询方法、装置、设备及介质
US10042914B2 (en) Database index for constructing large scale data level of details
KR20160130256A (ko) 데이터 유형에 관련된 데이터 프로파일링 동작 관리
US20210390089A1 (en) Code dictionary generation based on non-blocking operations
US11962330B2 (en) Advanced database decompression
US11379450B2 (en) Relational method for transforming unsorted sparse dictionary encodings into unsorted-dense or sorted-dense dictionary encodings
Wang et al. Rencoder: A space-time efficient range filter with local encoder
US9400817B2 (en) In-place index repair
US20180275961A1 (en) Method and system for fast data comparison using accelerated and incrementally synchronized cyclic data traversal algorithm
Carter et al. Nanosecond indexing of graph data with hash maps and VLists
Nakamura et al. Content-defined merkle trees for efficient container delivery
Kwon et al. Compressed key sort and fast index reconstruction
KR102013839B1 (ko) 데이터베이스 관리 방법, 시스템 및 데이터베이스 트리 구조
US20230195705A1 (en) Branching for tree structure in database system
US11119999B2 (en) Zero-overhead hash filters
US20220114144A1 (en) Frameworks for data source representation and compression
Theodorakis et al. An Empirical Evaluation of Variable-length Record B+ Trees on a Modern Graph Database System
Jadhav et al. GUI BASED QUERYING AND MIGRATION APPROACH FOR MONGODB
Xie et al. Electrical Engineering and Computer Science Department

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20191015

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20200722

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20200824

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20201001

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: 20210201

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20210302

R150 Certificate of patent or registration of utility model

Ref document number: 6847079

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250