JP6898320B2 - インデックス確立の方法およびデバイス - Google Patents

インデックス確立の方法およびデバイス Download PDF

Info

Publication number
JP6898320B2
JP6898320B2 JP2018524442A JP2018524442A JP6898320B2 JP 6898320 B2 JP6898320 B2 JP 6898320B2 JP 2018524442 A JP2018524442 A JP 2018524442A JP 2018524442 A JP2018524442 A JP 2018524442A JP 6898320 B2 JP6898320 B2 JP 6898320B2
Authority
JP
Japan
Prior art keywords
index
column
type
time interval
search
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2018524442A
Other languages
English (en)
Other versions
JP2019502980A (ja
JP2019502980A5 (ja
Inventor
ジェン,ボーウェン
パン,ユエ
ウェイ,チュアンシャン
Original Assignee
アリババ グループ ホウルディング リミテッド
アリババ グループ ホウルディング リミテッド
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 アリババ グループ ホウルディング リミテッド, アリババ グループ ホウルディング リミテッド filed Critical アリババ グループ ホウルディング リミテッド
Publication of JP2019502980A publication Critical patent/JP2019502980A/ja
Publication of JP2019502980A5 publication Critical patent/JP2019502980A5/ja
Application granted granted Critical
Publication of JP6898320B2 publication Critical patent/JP6898320B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22Indexing; Data structures therefor; Storage structures
    • G06F16/2228Indexing structures
    • G06F16/2272Management thereof
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22Indexing; Data structures therefor; Storage structures
    • G06F16/221Column-oriented storage; Management thereof
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22Indexing; Data structures therefor; Storage structures
    • G06F16/2228Indexing structures
    • G06F16/2237Vectors, bitmaps or matrices
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22Indexing; Data structures therefor; Storage structures
    • G06F16/2228Indexing structures
    • G06F16/2246Trees, e.g. B+trees
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22Indexing; Data structures therefor; Storage structures
    • G06F16/2228Indexing structures
    • G06F16/2255Hash tables
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/30Information retrieval; Database structures therefor; File system structures therefor of unstructured textual data
    • G06F16/31Indexing; Data structures therefor; Storage structures
    • G06F16/316Indexing structures
    • G06F16/319Inverted lists

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)

Description

本願は、参照によりその全体が本明細書に援用される、2015年12月1日に出願された「INDEX ESTABLISHMENT METHOD AND DEVICE(インデックス確立の方法およびデバイス)」と題された中国特許出願第201510868254.X号の優先権を主張する。
本発明は、通信技術分野に関し、より詳細には、インデックス確立の方法に関する。本願は、さらにインデックス確立のデバイスに関する。
インデックスは、データベーステーブルの1つ以上の列の値をソートするための構造である。インデックスを用いることによって、データベーステーブルにおける特定の情報に迅速にアクセスすることができる。インデックスは、テーブルの指定された列に格納されたデータ値を指すポインタを提供する。次いで、これらのポインタはユーザが指定するソート順にしたがってソートされる。データベースでインデックスを使用する必要があるとき、特定の値を発見するためにまずインデックスが検索され、その後、その値を含む行がポインタにしたがって発見される。
インターネット技術の持続的開発とともに、莫大な量のデータが、インターネットでの人々の日常活動から生成される。格納されている莫大な量のデータから所要のデータをどのようにして迅速に発見するかは、技術者にとって大きな関心事となっている。従来のデータベースにおいて、ユーザは、インデックスのインデックス型を指定する必要がある。しかしながら、同一のインデックス型において、異なるタイプのデータに対しては必要とされるクエリ時間の長さが異なる。結果として、インデックス型が不適切に設定された場合、ユーザは、データベースにおいてクエリを作成するのに過度に長い時間を費やす必要が生じ、不十分なユーザ経験がもたらされることになる。
本願の実施の際、発明者は先行技術が以下の欠点を有することを発見している。
(1)既存のインデックス型は不変なものであり、いくつかのシナリオで不十分なクエリパフォーマンスを招く。従来のデータのインデックス型は、比較的不変のものであり、B−ツリーインデックスが多くを占めている。B−ツリーインデックスは、あらゆるデータ特徴に適したものではない。例えば、検索速度はキー−値モードにおいて非常に遅い。結合を有する構造化問い合わせ言語(SQL)では、1つのSQLに対して複数の検索が行われるだろう。結合SQLのパフォーマンスは、B−ツリーが検索に用いられるか否かに強く影響される。
(2)ログは、インデックスを最適化するために手動解析され、不十分な運用性および保全性につながる。
大量のデータが存在するとき、従来のデータベースにおいて、インデックスは非常に高額の保全コストをもたらす。結果的に、ユーザアクセスログは、どの列が新規のインデックスを必要とし、どの列がインデックスを必要とせず、複合インデックスを確立するためにどの列が組み合わされるかを決定するために、毎晩閲覧される必要がある。履歴統計を用いることによるインデックス型のそうした自動的な調整(履歴ベースの最適化、HBO)は完全に手動であり、非常に不十分な運用性および保全性につながる。
把握することができるように、データ取得効率を向上させ運用リソースおよび保全リソースを節約するために、どのようにデータベースの使用を組み合わせてデータベースの列に対する適したインデックスを確立するかは、当業者が早急に解決する必要がある技術的な課題となっている。
本発明は、インデックス確立の方法を提供する。インデックス確立の手続きは、データ取得効率を向上させ同時に労働消費を低減させるために最適化される。本方法は、以下の、
予め設定された時間閾値内のデータベースの列のインデックスの状態の情報にしたがって、インデックスが列に対して確立される必要があるかどうかを判定するステップと、
インデックスが列に対して確立される必要があると判定された場合、列のデータ情報にしたがってインデックス型を判定し、インデックス型にしたがって列に対するインデックスを確立するステップとを含む。
好ましくは、本方法は、さらに、
インデックスが列に対して確立される必要がないと判定された場合、時間閾値の後で、かつ、時間閾値内の列のインデックス使用状態の情報にしたがって、インデックスが列に対して確立される必要があるかどうかを判定することを含む。
好ましくは、予め設定された時間閾値内のデータベースの列のインデックスの状態の情報にしたがって、インデックスが列に対して確立される必要があるかどうかを判定するステップは、具体的には、
時間閾値内の列のインデックスの状態の情報を取得することと、
インデックスの状態の情報にしたがって、時間閾値内にインデックスが列に対して用いられるかどうかを判定し、判定結果が肯定であるとき、列に対するインデックスが時間閾値内に用いられる回数が予め設定された回数閾値以上であるかどうかを判定することと、
時間閾値内にインデックスが列に対して用いられない場合、または、列に対するインデックスが時間閾値内に用いられる回数が予め設定された回数閾値未満である場合、インデックスが列に対して確立される必要がないと判定すること、または、
時間閾値内に列に対するインデックスが用いられる回数が回数閾値以上である場合、インデックスが列に対して確立される必要があると判定することである。
好ましくは、インデックス型は、B−ツリーインデックス、ハッシュインデックスおよびビットマップインデックスを少なくとも含み、列のデータ情報にしたがってインデックス型を判定するステップは、具体的には、
列が連続値型である場合、インデックス型はB−ツリーインデックスであると判定することと、
列で結合が起きている場合、インデックス型はハッシュインデックスであると判定することと、
列の単語数が予め設定された単語数閾値より多い場合、インデックス型は転置インデックスであると判定すること、または、
列の単語数が予め設定された単語数閾値以下であり、結合が起きておらず、列が不連続値型である場合、インデックス型はビットマップインデックスであると判定することである。
好ましくは、本方法は、さらに、
ユーザが送信した検索式を、検索式が受信されたときに複数の部分式に分割することと、
各部分式に対応する検索結果がキャッシュ内に存在するかどうかを問い合わせることと、
検索結果が存在する場合、部分式に対応する検索結果および他の部分式の検索結果にしたがって、ユーザに戻される検索応答を生成すること、または、
部分式に対応する検索結果が存在しない場合、列のインデックスを用いることによって部分式に関する検索を行い、ユーザに戻される検索応答が検索結果および他の部分式の検索結果にしたがって生成された後、検索結果をキャッシュに格納することと、を含む。
好ましくは、予め設定された時間閾値内のデータベースの列のインデックスの状態の情報にしたがって、インデックスが列に対して確立される必要があるかどうかを判定するステップの前に、本方法は、さらに、
データベースを初期化後、デフォルトのインデックス型にしたがってデータベースの列ごとにインデックスを構築し、予め設定された時間に達すると、列ごとに再度インデックスを構築することを含む。
対応して、本願は、さらに、
予め設定された時間閾値内のデータベースの列のインデックスの状態の情報にしたがって、インデックスが列に対して確立される必要があるかどうかを判定するように構成された判定モジュールと、
判定モジュールが、インデックスが列に対して確立される必要があると判定すると、列のデータ情報にしたがってインデックス型を判定し、インデックス型にしたがって列に対するインデックスを確立するように構成された確立モジュールとを含むインデックス確立デバイスを提供する。
好ましくは、確立モジュールは、判定モジュールによりインデックスが列に対して確立される必要がないと判定されると、時間閾値後に、かつ、時間閾値内の列のインデックス使用状態の情報にしたがって、インデックスが列に対して確立される必要があるかどうかを判定するようにさらに構成される。
好ましくは、判定モジュールは、具体的には、
時間閾値内の列のインデックスの状態の情報を取得し、
インデックスの状態の情報にしたがって、時間閾値内にインデックスが列に対して用いられるかどうかを判定し、判定結果が肯定であるとき、列に対するインデックスが時間閾値内に用いられる回数が予め設定された回数閾値以上であるかどうかを判定し、
インデックスが時間閾値内に列に対して用いられない場合、または、列に対するインデックスが時間閾値内に用いられる回数が回数閾値未満である場合、インデックスが列に対して確立される必要がないと判定するか、または、
列に対するインデックスが時間閾値内に用いられる回数が回数閾値以上である場合、インデックスが列に対して確立される必要があると判定するように構成される。
好ましくは、インデックス型は、B−ツリーインデックス、ハッシュインデックスおよびビットマップインデックスを少なくとも含み、列のデータ情報にしたがってインデックス型を判定するように構成された確立モジュールは、具体的には、
列が連続値型である場合、インデックス型はB−ツリーインデックスであると判定し、
列で結合が起きている場合、インデックス型はハッシュインデックスであると判定し、
列の単語数が予め設定された単語数閾値より多い場合、インデックス型は転置インデックスであると判定するか、または、
列の単語数が予め設定された単語数閾値以下であり、結合が起きておらず、列が不連続値型である場合、インデックス型はビットマップインデックスであると判定する。
好ましくは、本デバイスは、さらに、
ユーザが送信した検索式を、検索式が受信されたときに複数の部分式に分割するように構成された分割モジュールと、
各部分式に対応する検索結果がキャッシュ内に存在するかどうかを問い合わせるように構成されたクエリモジュールと、
検索結果が存在するとき、部分式に対応する検索結果および他の部分式の検索結果にしたがって、ユーザに戻される検索応答を生成するか、または、部分式に対応する検索結果が存在しないとき、列のインデックスを用いることによって部分式に関して検索を行い、ユーザに戻される検索応答が検索結果および他の部分式の検索結果にしたがって生成された後、検索結果をキャッシュに格納するように構成された処理モジュールと、を含む。
好ましくは、本デバイスは、さらに、
データベースを初期化後、デフォルトのインデックス型にしたがってデータベースの列ごとにインデックスを構築し、予め設定された時間に達すると、列ごとにインデックスを再度構築するように構成された初期化モジュールを含む。
把握することができるように、本開示の技術的解決策を適用することによって、予め設定された時間閾値内のデータベースの列のインデックスの状態の情報にしたがって、インデックスが列に対して確立される必要があるかどうかがまず判定され、インデックスが列に対して確立される必要があると判定されると、列のデータ情報にしたがってインデックス型が判定され、インデックス型にしたがってインデックスが列に対して確立される。したがって、インデックスをデータベースの列ごとに動的に確立することができ、適したインデックス型を実際のケースにしたがって選択することができ、リソース消費および労働投入量の低減を前提として、データ検索効率を効果的に高めることができるようになる。
本願によるインデックス確立の方法の概略フローチャートである。 本願の特定の実施形態におけるデータ構造の概略図である。 本願の特定の実施形態によるストリームされた結果のマージングの概略フローチャートである。 本願の特定の実施形態によるインデックスの概略構造図である。 本願の特定の実施形態によるインデックスを確立する概略フローチャートである。 本願によるインデックス確立のデバイスの概略構造図である。
背景技術における課題を考慮して、本願は、インデックス確立の方法を提供する。データベースの各列のインデックス使用状態にしたがって、インデックスが列に対して確立される必要があるかどうかが速やかに判定され、インデックスの確立時に、適したインデックス型が列のデータ情報に照らして選択される。したがって、ハードウェアリソースの節約および労働投入量の低減を前提として、検索効率が高められる。
図1は、本願によるインデックス確立の方法の概略フローチャートである。本方法は、以下のステップを含む。
S101:予め設定された時間閾値内のデータベースの列のインデックスの状態の情報にしたがって、インデックスが列に対して確立される必要があるかどうかが判定される。
インデックスが列に対して確立される必要があると判定された場合、ステップS102が実行される。
インデックスが列に対して確立される必要がないと判定された場合、プロセスはステップS101に戻って、次の予め設定された時間閾値に対応する時間間隔内にインデックスが列に対して確立される必要があるかどうかの判定を続ける。
莫大な量のデータが存在する場合、ユーザがあらゆる列を検索または問い合わせすることはあまりないので、インデックスをデータベースの列ごとに確立することは時間と手間がかかり、不必要なものである。したがって、本願では、インデックスの状態の情報は、データベースの列ごとに導入される。一定の期間内のインデックスの状態の情報に基づいて、インデックスが列に対して確立される必要があるかどうかが判定される。一方、各列のインデックスの状態の情報をユーザの検索態様および習慣にしたがって速やかに調整することができることを確保するために、本願では、各時間閾値後に、各列のインデックスの状態の情報が更新され、例えば時間閾値内にインデックスが列に対して用いられたかどうか、インデックスが用いられた回数は特定の数に達するかどうかが判定される。特定の適用シナリオでは、時間閾値は、具体的には、対応する列のインデックス使用状態の統計を収集するための統計収集時間範囲を示す予め設定された時間間隔値である。時間閾値は、データベースの容量およびユーザ数にしたがって調整され得る。一般に、時間閾値は1日に設定されてもよく、技術者は、時間閾値をこれに基づき延長してもよくまたは短縮してもよい。これらの時間閾値は全て本願の保護範囲内に含まれる。
本願の好ましい実施形態では、このステップのために特定の判定態様が提供され、それは以下のステップを含む。
ステップa):時間閾値内の列のインデックスの状態の情報が取得される。
ステップb):インデックスの状態の情報にしたがって、時間閾値内にインデックスが列に対して用いられるかどうかが判定され、判定結果が肯定のとき、時間閾値内に列に対するインデックスが用いられる回数が予め設定された回数閾値以上であるかどうかが判定される。
前述の判定ステップに基づいて、インデックスが時間閾値内に列に対して用いられない場合、または、列に対するインデックスが時間閾値内に用いられる回数が回数閾値未満である場合、インデックスが列に対して確立される必要がないと判定されるか、または、列に対するインデックスが時間閾値内に用いられる回数が回数閾値以上である場合、インデックスが列に対して確立される必要があると判定される。
前述の実施形態において、特定のステップおよび判定ベースが、インデックスが列に対して確立される必要があるかどうかをこれに基づいて判定するために用いられているが、当業者は別のタイプの基準を用いることによって判定を行い得ることに留意されるべきである。これらの改良はすべて、本願の保護範囲内に含まれる。
さらに、データベースを初期化後、この時点では、データベースのいずれの列も確立されたインデックスを有していない。この場合、インデックスは、本願のデフォルトのインデックス型にしたがってデータベースの列ごとに構築され、予め設定された時間に達すると、インデックスは再度列ごとに構築される。このプロセスにおいて均一に確立されるインデックスは、技術者により予め設定され得る。
S102:列のデータ情報にしたがってインデックス型が判定され、インデックス型にしたがってインデックスが列に対して確立される。
S101によってインデックスが列に対して確立される必要があると判定された後、インデックス型を列のデータ情報にしたがって判定することができる。したがって、個別の検索サービスを様々なケースに基づいてユーザに提供することができ、全ユーザによる現在のデータベースへの問い合わせの平均時間が大幅に減ることになる。
反対に、ステップS101に記載したように、インデックスが列に対して確立される必要がないと判定された場合、本願の技術的解決策では、現在の時間閾値に対応する時間間隔が終了した後、次の時間閾値に対応する時間間隔内の列のインデックス使用状態の情報にしたがって、インデックスが列に対して確立される必要があるかどうかが再度判定される。言い換えると、ステップS101が再度実行される。したがって、実際のケースにしたがって柔軟な調整をなすことができる。
現在、慣用のインデックス型として、転置インデックス、B−ツリーインデックス、ハッシュインデックスおよびビットマップインデックスが挙げられる。したがって、本願の好ましい実施形態では、インデックス型は、以下の条件を用いることによって具体的に判定される。
(1)列が連続値型である場合、インデックス型はB−ツリーインデックスであると判定される。
(2)列で結合が起きている場合、インデックス型はハッシュインデックスであると判定される。

結合はリレーショナルデータベースシステムにおいて重要な演算の1つであることに留意されるべきである。SQLサーバにおける広く知られた結合として、内部結合、外部結合、交差結合などが挙げられる。1つのテーブルの行および別のテーブルの行の一致しているデータが2つ以上のテーブルから取得される必要がある場合、結合はテーブルまたは機能を結合してクエリを実行することによって特徴付けられるので、結合演算の使用が検討される必要がある。
(3)列の単語数が予め設定された単語数閾値より多い場合、インデックス型は転置インデックスであると判定される。
ここで、列の単語数は、具体的には、列に含まれる変数値の数である。
(4)列の単語数が予め設定された単語数閾値以下であり、結合が起きておらず、列が不連続値型である場合、インデックス型はビットマップインデックスであると判定される。
本願の特定の実施形態では、列のデータが値型であり連続している場合(例えば、通貨量)、一般的に述べると、そのような値型のフィールドには範囲クエリのみが実行される必要がある。図2のデータ構造の図では、Bツリーのデータ構造の中間ノードは本来的に範囲属性を有する。したがって、連続値型の列において、Bツリーインデックスにおける範囲検索の効率は、転置インデックスおよびビットマップインデックスにおける範囲検索の効率よりもはるかに良い。
さらに、インデックススライス全体にn個のレコードが存在し、フィールドAはX個の異なる項目の値を有し、「delta+vint」の元の圧縮アルゴリズムの圧縮率はpであると仮定する。この場合、以下の結果が、「xn/32<np」の変換式「x<128p」を用いることによって取得され得、「delta+vint」の圧縮アルゴリズムの最大圧縮率は1/4である:p=1/4のとき、「x<128p」に代入することで、x<1281/4=32が取得され得る。
前述の結果から把握することができるように、単語数が32より少ない場合、ビットマップインデックスが用いられるときに占める空間は、転置インデックスが用いられるときに占める空間よりも小さい。したがって、前述の好ましい実施形態では、単語数閾値は、具体的には32に設定され得る。しかしながら、単語数閾値はその後に別のアルゴリズムに基づいて変更され得ることも指摘されるべきである。このことは、本願の保護範囲に影響を与えない。
さらに、先行技術において1つのユーザのクエリが作成された後、クエリに関する検索情報は保存されない。一般に、ユーザのクエリ式は、通常複数の異なる部分式から形成される。したがって、アトミックな部分式が従来のデータベースにキャッシュされない場合、部分式のクエリ結果を同一の式を有する異なるSQLに対して再使用することはできない。結果として、アトミックな部分式がキャッシュされないとき、オンライン分析処理(OLAP)における任意の次元のブール演算のパフォーマンスは不十分なものである。そのような状況を踏まえて、本願の好ましい実施形態は、ユーザが送信した検索式が、検索式が受信されたときに複数の部分式に分割され、各部分式に対応する検索結果がキャッシュ内に存在するかどうかが問い合わせされるという解決策を提供する。この処理は、以下のケースに基づくものである。
(1)検索結果が存在する場合、ユーザに戻される検索応答は、部分式に対応する検索結果および他の部分式の検索結果にしたがって生成されるか、または、
(2)部分式に対応する検索結果が存在しない場合、列のインデックスを用いることによって部分式に関して検索が行われ、検索結果は、ユーザに戻される検索応答が検索結果及び他の部分式の検索結果にしたがって生成された後、キャッシュに格納される。
図3のストリームされた結果のマージングの概略フローチャートは、一例として用いられる。インデックスが問い合わせされた後に圧縮解凍を通して得られた転置リンクは、ビットマップ構造を用いることによってメモリに格納される。このストリームされたマージングフレームワークでは、式間のブール演算は、いかなる中間オブジェクトも生成しないという前提のもと、マージングを介して1つずつ取得される。ストリームされたマージングプロセス全体は、以下の4つの部分を含む。
(1)クエリビルダ(キュー作成構成要素)は、where式にしたがって、エンジンクエリ(キューエンジン)オブジェクトツリーを生成する。
(2)Rowid選択ツリーがエンジンクエリオブジェクトツリーにしたがって構築される。
(3)Rowid設定は様々なインデックスから取得されリーフノードに挿入され、中間ノードは論理演算マージャーである。
(4)選択はルートノードから1つずつ行われ、Rowidは収集される。
特定の実施形態は、異なるSQL文が同一のwhere式を有してもよいケースに基づくものである。したがって、アトミックな部分式はキャッシュされて、インデックスクエリのパフォーマンスを加速させる。
前述の技術的解決策を適用することによって、列のレベルで独立しているインデックス構造に基づいて、最も適したインデックス型がコストおよび費用(costs and expenses)にしたがって自動的に選択され、履歴統計(HBO)を用いてインデックス型を自動的に調整し、同時に、アトミックな部分式がキャッシュされる。したがって、格納コストを削減しながらインデックスクエリのパフォーマンスが加速される。
本発明の技術的概念をさらに例示するために、図4のインデックスの構造図を用いて本発明の技術的解決策を説明する。特定の実施形態では、図4に示す列レベルのインデックスアーキテクチャは、転置インデックス、ビットマップインデックス、ハッシュインデックスおよびBツリーインデックスなどのインデックスの原理および特性に基づいて自立的に実装され、4つのインデックス型全てをサポートすることができる。インデックス型はユーザに対して透過的であり、ユーザが外部的に指定する必要がない。その代りに、インデックス型は、データ特徴にしたがって自動的に選択される。さらに、複数のインデックス型は、ブール演算を行うのに同一のデータ構造を用いる。where部分式の結果が発見されるインデックスは、エンジン層で認識される必要がない。さらに、インデックスは、手動での関与を必要とすることなく、履歴統計情報にしたがって自動的に最適化され得る。
具体的には、インデックスの構造図は、主に、以下の3つの部分を含む。
(1)ストリームされたマージャーは、異なるインデックスのクエリ結果および計算層間のインタラクションを統一することに関与している。異なるインデックスを用いたクエリによる結果は、ビットマップを用いることによって格納され、次いで、ストリームされたマージャーツリーが、where式のブール演算にしたがって生成され、次いで、マージャーは、where式を満たす行番号を1つずつ出力する。
(2)インデックスマネージャは、インデックス管理、型選択および自動的なインデックス最適化手続きに関与している。
(3)部分式キャッシュ(ビットマップキャッシュ)は、where部分式のキャッシングに関与している。このことから、インデックスは、異なるSQLが同一の部分式を有するとき、もはやクエリされる必要はなく、クエリは直接キャッシュ内で作成され得る。
前述の説明に基づいて、図5のインデックスを確立する概略フローチャートでは、まずインデックスがデータベースの列ごとに確立され、毎日インデックスが再度確立され、履歴SQL統計データが取得される。履歴データに基づいて、インデックスが当日に列に対して用いられるかどうか、およびインデックスが用いられる回数が閾値を超えるかどうかが判定される。インデックスが列に対して確立される必要があると判定された後、異なるインデックス型が、列のデータタイプにしたがって選択される。したがって、異なる列のフィールドに対して異なるインデックス型の使用をサポートする(転置インデックス、B−ツリーインデックス、ビットマップインデックスおよびハッシュインデックスが全てサポートされる)だけでなく、インデックス型はユーザに認識されることなく選択され、その結果、格納コストが大幅に節約されクエリ速度が大幅に早まることになる。
前述の技術的目的を達成するために、本願は、さらに、インデックス確立デバイスを提供する。図6に示すように、デバイスは、
所定時間閾値内のデータベースの列のインデックスの状態の情報にしたがって、インデックスが列に対して確立される必要があるかどうか判定するように構成された判定モジュール610と、
判定モジュールが、インデックスが列に対して確立される必要があると判定すると、列のデータ情報にしたがってインデックス型を判定し、インデックス型にしたがって列に対するインデックスを確立するように構成された確立モジュール620とを含む。
特定の適用シナリオでは、確立モジュールはさらに、判定モジュールによってインデックスが列に対して確立される必要がないと判定されたとき、時間閾値の後で、かつ、時間閾値内の列のインデックス使用状態の情報にしたがって、インデックスが列に対して確立される必要があるかどうかを判定するように構成される。
特定の適用シナリオでは、判定モジュールは、具体的には、
時間閾値内の列のインデックスの状態の情報を取得し、
インデックスの状態の情報にしたがって、時間閾値内にインデックスが列に対して用いられるかどうかを判定し、判定結果が肯定であるとき、列に対するインデックスが時間閾値内に用いられる回数が予め設定された回数閾値以上であるかどうかを判定し、
時間閾値内にインデックスが列に対して用いられない場合、または、列に対するインデックスが時間閾値内に用いられる回数が回数閾値未満である場合、インデックスが列に対して確立される必要がないと判定するか、または、
列に対するインデックスが時間閾値内に用いられる回数が回数閾値以上である場合、インデックスが列に対して確立される必要があると判定するように構成される。
特定の適用シナリオでは、インデックス型は、B−ツリーインデックス、ハッシュインデックスおよびビットマップインデックスを少なくとも含み、列のデータ情報にしたがってインデックス型を判定するように構成された確立モジュールは、具体的には、
列が連続値型である場合、インデックス型はB−ツリーインデックスであると判定し、
列で結合が起きている場合、インデックス型はハッシュインデックスであると判定し、
列の単語数が予め設定された単語数閾値よりも多い場合、インデックス型は転置インデックスであると判定するか、または、
列の単語数が予め設定された単語数閾値よりも多いものではなく、結合が起きておらず、列が不連続値型である場合、インデックス型はビットマップインデックスであると判定する。
特定の適用シナリオでは、デバイスは、さらに、
ユーザが送信した検索式を、検索式が受信されたときに複数の部分式に分割するように構成された分割モジュールと、
各部分式に対応する検索結果がキャッシュ内に存在するかどうかを問い合わせるように構成されたクエリモジュールと、
検索結果が存在するとき、部分式に対応する検索結果及び他の部分式の検索結果にしたがって、ユーザに戻される検索応答を生成するか、または、部分式に対応する検索結果が存在しないとき、列のインデックスを用いることによって部分式に関する検索を実行し、検索結果を、ユーザに戻される検索応答が検索結果および他の部分式の検索結果にしたがって生成された後、キャッシュに格納するように構成された処理モジュールと、を含む。
特定の適用シナリオでは、デバイスは、さらに、
データベースを初期化後、デフォルトのインデックス型にしたがって、データベースの列ごとにインデックスを構築し、予め設定された時間に達すると、列ごとにインデックスを再度構築するように構成された初期化モジュールを含む。
本願の技術的解決策を適用することによって、予め設定された時間閾値内のデータベースの列のインデックスの状態の情報にしたがって、インデックスが列に対して確立される必要があるかどうかがまず判定され、インデックスが確立される必要があると判定されると、列のデータ情報にしたがってインデックス型が判定され、インデックス型にしたがってインデックスが列に対して確立される。したがって、インデックスをデータベースの列ごとに動的に確立することができ、適したインデックス型を実際のケースにしたがって選択することができ、検索効率を、リソース消費および労働投入量の低減を前提として、効果的に向上させることができるようになる。
実装態様のこの説明から把握することができるように、当業者であれば、本発明はソフトウェアまたはソフトウェア加えて必要なユニバーサルハードウェアプラットフォームを用いることによって実装され得ることを明確に理解し得る。そうした理解に基づいて、本発明の技術的解決策はソフトウェア製品の形式で実装され得る。ソフトウェア製品は、不揮発性保存媒体(CD−ROM、USBフラッシュデバイス、リムーバブルハードディスクなどであってもよい)に格納されてもよく、コンピュータデバイス(パーソナルコンピュータ、サーバ、ネットワークデバイスなどであってもよい)に本発明の実装シナリオにおける方法を実行することを指示するいくつかの命令を含む。
当業者であれば、添付の図面は好ましい実装シナリオのただの概略図であることを理解し得る。添付の図面のモジュールまたは手続きは、本発明を実装するために必ずしも必須なものではない。
当業者であれば、実装シナリオの装置のモジュールは、実装シナリオの説明にしたがって実装シナリオの装置に分散され得、または、それに対応して実装シナリオの装置とは異なる1つ以上の装置に配置されるように変更され得ることを理解し得る。前述の実装シナリオのモジュールは、1つのモジュールに組み合わされ得、または、さらに複数のサブモジュールに分割され得る。
本発明の前述のシーケンスの番号は単に説明の便宜のためのものであり、実装シナリオ内の優先を意味するものではない。
前述の開示は、本発明の単なるいくつかの特定の実装シナリオであるが、本発明はそれらに限定されるものではない。当業者によって想定される任意の変更は、本発明の保護範囲内に存在しなければならない。

Claims (15)

  1. インデックス確立の方法であって、
    コンピュータデバイスが、データベースを初期化後、デフォルトのインデックス型にしたがって前記データベースの列ごとにインデックスを構築することと、
    前記コンピュータデバイスが、予め設定された時間間隔内の前記データベースの列のインデックスの使用状態にしたがって、インデックスが前記列に対して再構築される必要があるかどうかを判定することと、
    前記コンピュータデバイスが、インデックスが前記列に対して再構築される必要があると判定された場合、前記列のデータ情報にしたがってインデックス型を判定し、前記列に対するインデックスを前記インデックス型にしたがって再構築することとを含み、
    前記データ情報は、列が連続値型であるか否かの情報、列で結合が起きているか否かの情報、列の単語数が予め設定された単語数閾値より多いか否かの情報、のいずれかを含む、方法。
  2. 前記コンピュータデバイスが、インデックスが前記列に対して再構築される必要がないと判定された場合、次の時間間隔の経過後に、前記次の時間間隔内の前記列のインデックスの使用状態にしたがって、インデックスが前記列に対して再構築される必要があるかどうかを再び判定することをさらに含む、請求項1に記載の方法。
  3. 前記コンピュータデバイスが、予め設定された時間間隔内のデータベースの列の前記インデックスの使用状態にしたがって、インデックスが前記列に対して再構築される必要があるかどうかを判定することが
    前記コンピュータデバイスが、前記時間間隔内の前記列の前記インデックスの使用状態を判断すること、
    前記コンピュータデバイスが、前記インデックスの使用状態にしたがって、前記時間間隔内にインデックスが前記列に対して用いられたかどうかを判定し、判定結果が肯定であるとき、前記列に対するインデックスが前記時間間隔内に用いられた回数が予め設定された回数閾値以上であるかどうかを判定すること
    前記コンピュータデバイスが、インデックスが前記時間間隔内に前記列に対して用いられない場合、または、前記列に対するインデックスが前記時間間隔内に用いられた回数が前記回数閾値未満である場合、インデックスが前記列に対して再構築される必要がないと判定すること、および、
    前記コンピュータデバイスが、前記列に対するインデックスが前記時間間隔内に用いられた回数が前記回数閾値以上である場合、インデックスが前記列に対して再構築される必要があると判定することを含む、請求項2に記載の方法。
  4. 前記インデックス型が、B−ツリーインデックス、ハッシュインデックスおよびビットマップインデックスを少なくとも含み、前記コンピュータデバイスが、前記列の前記データ情報にしたがってインデックス型を判定することが
    前記コンピュータデバイスが、前記列が連続値型である場合、前記インデックス型がB−ツリーインデックスであると判定すること、
    前記コンピュータデバイスが、前記列に結合が起きている場合、前記インデックス型がハッシュインデックスであると判定すること
    前記コンピュータデバイスが、前記列の単語数が予め設定された単語数閾値より多い場合、前記インデックス型が転置インデックスであると判定すること、および、
    前記コンピュータデバイスが、前記列の単語数が予め設定された単語数閾値以下であり、結合が起きておらず、前記列が不連続値型である場合、前記インデックス型がビットマップインデックスであると判定することを含む、請求項1に記載の方法。
  5. 前記コンピュータデバイスが、ユーザが送信した検索式を、前記検索式が受信されたときに複数の部分式に分割すること、
    前記コンピュータデバイスが、各部分式に対応する検索結果がキャッシュ内に存在するかどうかを問い合わせすること
    前記コンピュータデバイスが、前記検索結果が存在する場合、前記部分式に対応する検索結果および他の部分式の検索結果にしたがって、前記ユーザに戻される検索応答を生成すること、および、
    前記コンピュータデバイスが、前記部分式に対応する検索結果が存在しない場合、前記列のインデックスを用いることによって前記部分式に関する検索を実行し、前記検索結果を、前記ユーザに戻される検索応答が前記検索結果および他の部分式の検索結果にしたがって生成された後、前記キャッシュに格納することをさらに含む、請求項1に記載の方法。
  6. データベースを初期化後、デフォルトのインデックス型にしたがって前記データベースの列ごとにインデックスを構築するように構成された初期化モジュールと、
    予め設定された時間間隔内の前記データベースの列のインデックスの使用状態にしたがって、インデックスが前記列に対して再構築される必要があるかどうかを判定するように構成された判定モジュールと、
    前記判定モジュールが、インデックスが前記列に対して再構築される必要があると判定すると、前記列のデータ情報にしたがってインデックス型を判定し、前記インデックス型にしたがって、前記列に対するインデックスを再構築するように構成された再構築モジュールとを備え
    前記データ情報は、列が連続値型であるか否かの情報、列で結合が起きているか否かの情報、列の単語数が予め設定された単語数閾値より多いか否かの情報、のいずれかを含む、インデックス確立デバイス。
  7. 前記再構築モジュールが、前記判定モジュールによりインデックスが前記列に対して再構築される必要がないと判定されたとき、次の時間間隔の経過後に、前記次の時間間隔内の前記列のインデックスの使用状態にしたがって、インデックスが前記列に対して再構築される必要があるかどうかを再び判定するようにさらに構成される、請求項6に記載のデバイス。
  8. 前記判定モジュールが
    前記時間間隔内の前記列の前記インデックスの使用状態を判断し
    前記インデックスの使用状態にしたがって、前記時間間隔内にインデックスが前記列に対して用いられたかどうかを判定し、判定結果が肯定のとき、前記列に対するインデックスが前記時間間隔内に用いられた回数が予め設定された回数閾値以上であるかどうかを判定し、
    前記時間間隔内にインデックスが前記列に対して用いられない場合、または、前記列に対するインデックスが前記時間間隔内に用いられた回数が前記回数閾値未満である場合、インデックスが前記列に対して再構築される必要がないと判定し、
    前記列に対するインデックスが前記時間間隔内に用いられた回数が前記回数閾値以上である場合、インデックスが前記列に対して再構築される必要があると判定するように構成される、請求項7に記載のデバイス。
  9. 前記インデックス型が、B−ツリーインデックス、ハッシュインデックスおよびビットマップインデックスを少なくとも含み、前記再構築モジュールが
    前記列が連続値型である場合、前記インデックス型がB−ツリーインデックスであると判定し、
    前記列で結合が起きている場合、前記インデックス型がハッシュインデックスであると判定し、
    前記列の単語数が予め設定された単語数閾値より多い場合、前記インデックス型は転置インデックスであると判定し、
    前記列の単語数が予め設定された単語数閾値以下であり、結合が起きておらず、前記列が不連続値型である場合、前記インデックス型はビットマップインデックスであると判定するように構成される、請求項6に記載のデバイス。
  10. ユーザが送信した検索式を、前記検索式が受信されたときに複数の部分式に分割するように構成された分割モジュールと、
    各部分式に対応する検索結果がキャッシュ内に存在するかどうかを問い合わせるように構成されたクエリモジュールと、
    前記検索結果が存在するとき、前記部分式に対応する検索結果および他の部分式の検索結果にしたがって、前記ユーザに戻される検索応答を生成、前記部分式に対応する検索結果が存在しないとき、前記列のインデックスを用いることによって前記部分式に関する検索を実行し、前記検索結果を、前記ユーザに戻される検索応答が前記検索結果および他の部分式の検索結果にしたがって生成された後、前記キャッシュに格納するように構成された処理モジュールと、をさらに備える、請求項6に記載のデバイス。
  11. 命令のセットを格納する非一時的コンピュータ可読媒体であって、前記命令のセットは、コンピューティングシステムにインデックス確立の方法を実行させるために、前記コンピューティングシステムの少なくとも1つのプロセッサによって実行可能であり、前記方法が、
    データベースを初期化後、デフォルトのインデックス型にしたがって前記データベースの列ごとにインデックスを構築することと、
    予め設定された時間間隔内の前記データベースの列のインデックスの使用状態にしたがって、インデックスが前記列に対して再構築される必要があるかどうかを判定することと、
    インデックスが前記列に対して再構築される必要があると判定された場合、前記列のデータ情報にしたがってインデックス型を判定し、前記列に対するインデックスを前記インデックス型にしたがって再構築することとを含み、
    前記データ情報は、列が連続値型であるか否かの情報、列で結合が起きているか否かの情報、列の単語数が予め設定された単語数閾値より多いか否かの情報、のいずれかを含む
    非一時的コンピュータ可読媒体。
  12. 前記方法が、インデックスが前記列に対して再構築される必要がないと判定された場合、次の時間間隔の経過後に、前記次の時間間隔内の前記列のインデックスの使用状態にしたがって、インデックスが前記列に対して再構築される必要があるかどうかを再び判定することをさらに含む、請求項11に記載の非一時的コンピュータ可読媒体。
  13. 予め設定された時間間隔内のデータベースの列の前記インデックスの使用状態にしたがって、インデックスが前記列に対して再構築される必要があるかどうかを判定することが
    前記時間間隔内の前記列の前記インデックスの使用状態を判断すること、
    前記インデックスの使用状態にしたがって、前記時間間隔内にインデックスが前記列に対して用いられたかどうかを判定し、判定結果が肯定であるとき、前記列に対するインデックスが前記時間間隔内に用いられた回数が予め設定された回数閾値以上であるかどうかを判定すること
    インデックスが前記時間間隔内に前記列に対して用いられない場合、または、前記列に対するインデックスが前記時間間隔内に用いられた回数が前記回数閾値未満である場合、インデックスが前記列に対して再構築される必要がないと判定すること、および、
    前記列に対するインデックスが前記時間間隔内に用いられた回数が前記回数閾値以上である場合、インデックスが前記列に対して再構築される必要があると判定することを含む請求項12に記載の非一時的コンピュータ可読媒体。
  14. 前記インデックス型が、B−ツリーインデックス、ハッシュインデックスおよびビットマップインデックスを少なくとも含み、前記列の前記データ情報にしたがってインデックス型を判定することが
    前記列が連続値型である場合、前記インデックス型がB−ツリーインデックスであると判定すること、
    前記列に結合が起きている場合、前記インデックス型がハッシュインデックスであると判定すること
    前記列の単語数が予め設定された単語数閾値より多い場合、前記インデックス型が転置インデックスであると判定すること、および、
    前記列の単語数が予め設定された単語数閾値以下であり、結合が起きておらず、前記列が不連続値型である場合、前記インデックス型がビットマップインデックスであると判定することを含む請求項11に記載の非一時的コンピュータ可読媒体。
  15. 前記方法が、
    ユーザが送信した検索式を、前記検索式が受信されたときに複数の部分式に分割すること、
    各部分式に対応する検索結果がキャッシュ内に存在するかどうかを問い合わせすること
    前記検索結果が存在する場合、前記部分式に対応する検索結果および他の部分式の検索結果にしたがって、前記ユーザに戻される検索応答を生成すること、および
    前記部分式に対応する検索結果が存在しない場合、前記列のインデックスを用いることによって前記部分式に関する検索を実行し、前記検索結果を、前記ユーザに戻される検索応答が前記検索結果および他の部分式の検索結果にしたがって生成された後、前記キャッシュに格納することをさらに含む、請求項11に記載の非一時的コンピュータ可読媒体。
JP2018524442A 2015-12-01 2016-11-21 インデックス確立の方法およびデバイス Active JP6898320B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
CN201510868254.X 2015-12-01
CN201510868254.XA CN106815260B (zh) 2015-12-01 2015-12-01 一种索引建立方法及设备
PCT/CN2016/106581 WO2017092583A1 (zh) 2015-12-01 2016-11-21 一种索引建立方法及设备

Publications (3)

Publication Number Publication Date
JP2019502980A JP2019502980A (ja) 2019-01-31
JP2019502980A5 JP2019502980A5 (ja) 2019-12-19
JP6898320B2 true JP6898320B2 (ja) 2021-07-07

Family

ID=58796259

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2018524442A Active JP6898320B2 (ja) 2015-12-01 2016-11-21 インデックス確立の方法およびデバイス

Country Status (5)

Country Link
US (1) US11003649B2 (ja)
EP (1) EP3385864B1 (ja)
JP (1) JP6898320B2 (ja)
CN (1) CN106815260B (ja)
WO (1) WO2017092583A1 (ja)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106815260B (zh) 2015-12-01 2021-05-04 阿里巴巴集团控股有限公司 一种索引建立方法及设备
US11023439B2 (en) * 2016-09-01 2021-06-01 Morphick, Inc. Variable cardinality index and data retrieval
CN110851438A (zh) * 2018-08-20 2020-02-28 北京京东尚科信息技术有限公司 一种数据库索引优化建议与验证的方法和装置
CN110874358B (zh) * 2018-08-30 2023-05-05 阿里巴巴集团控股有限公司 多属性列的存储、检索方法和装置以及电子设备
US10545960B1 (en) * 2019-03-12 2020-01-28 The Governing Council Of The University Of Toronto System and method for set overlap searching of data lakes
CN111046130B (zh) * 2019-11-08 2023-05-23 杭州安恒信息技术股份有限公司 结合ElasticSearch和FSM的关联检索方法
CN113535733A (zh) * 2021-07-26 2021-10-22 北京锐安科技有限公司 数据存储、查询方法、装置、计算机设备及存储介质
CN117573680B (zh) * 2024-01-17 2024-04-12 深圳市进择科技有限公司 一种基于大数据的定位数据传输管理系统及方法

Family Cites Families (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS63201716A (ja) 1987-02-17 1988-08-19 Nec Corp インデツクス保守方式
US5404510A (en) 1992-05-21 1995-04-04 Oracle Corporation Database index design based upon request importance and the reuse and modification of similar existing indexes
JPH0785093A (ja) 1993-09-16 1995-03-31 Nissan Motor Co Ltd インデックス自動設定方法
US5907837A (en) * 1995-07-17 1999-05-25 Microsoft Corporation Information retrieval system in an on-line network including separate content and layout of published titles
US7640244B1 (en) * 2004-06-07 2009-12-29 Teredata Us, Inc. Dynamic partition enhanced joining using a value-count index
US7392266B2 (en) * 2005-03-17 2008-06-24 International Business Machines Corporation Apparatus and method for monitoring usage of components in a database index
JP2007122405A (ja) 2005-10-28 2007-05-17 Hitachi Ltd データベース管理システムの性能チューニングシステム
JP5162215B2 (ja) 2007-11-22 2013-03-13 株式会社エヌ・ティ・ティ・データ データ処理装置、データ処理方法、および、プログラム
JP4237813B2 (ja) 2008-05-26 2009-03-11 株式会社東芝 構造化文書管理システム
US8489565B2 (en) * 2009-03-24 2013-07-16 Microsoft Corporation Dynamic integrated database index management
CN101609460B (zh) * 2009-07-22 2011-12-14 中国科学院地理科学与资源研究所 一种支持异构地学数据资源的检索方法及检索系统
US8655867B2 (en) * 2010-05-13 2014-02-18 Salesforce.Com, Inc. Method and system for optimizing queries in a multi-tenant database environment
US8412701B2 (en) * 2010-09-27 2013-04-02 Computer Associates Think, Inc. Multi-dataset global index
CN102467572B (zh) * 2010-11-17 2013-10-02 英业达股份有限公司 支持重复数据删除程序的数据区块查询方法
US8396858B2 (en) * 2011-08-11 2013-03-12 International Business Machines Corporation Adding entries to an index based on use of the index
CN102779180B (zh) * 2012-06-29 2015-09-09 华为技术有限公司 数据存储系统的操作处理方法,数据存储系统
US8825664B2 (en) * 2012-08-17 2014-09-02 Splunk Inc. Indexing preview
CN103810212B (zh) * 2012-11-14 2017-05-24 阿里巴巴集团控股有限公司 一种数据库索引的自动创建方法及系统
US20140317093A1 (en) * 2013-04-22 2014-10-23 Salesforce.Com, Inc. Facilitating dynamic creation of multi-column index tables and management of customer queries in an on-demand services environment
US20150032720A1 (en) * 2013-07-23 2015-01-29 Yahoo! Inc. Optimizing database queries
CN103390066B (zh) * 2013-08-08 2016-02-17 上海新炬网络信息技术有限公司 一种数据库全局性自动化优化预警装置及其处理方法
CN104714984A (zh) 2013-12-17 2015-06-17 中国移动通信集团湖南有限公司 一种数据库优化的方法和装置
CN104112011B (zh) * 2014-07-16 2017-09-15 深圳国泰安教育技术股份有限公司 一种海量数据提取的方法及装置
CN104182460B (zh) * 2014-07-18 2017-06-13 浙江大学 基于倒排索引的时间序列相似性查询方法
US9846746B2 (en) * 2014-11-20 2017-12-19 Facebook, Inc. Querying groups of users based on user attributes for social analytics
CN104834736A (zh) * 2015-05-19 2015-08-12 深圳证券信息有限公司 构建索引库的方法、装置及检索的方法、装置和系统
CN105045851A (zh) * 2015-07-07 2015-11-11 福建天晴数码有限公司 根据日志分析自动创建数据库索引的方法及系统
CN106815260B (zh) 2015-12-01 2021-05-04 阿里巴巴集团控股有限公司 一种索引建立方法及设备
US10601593B2 (en) * 2016-09-23 2020-03-24 Microsoft Technology Licensing, Llc Type-based database confidentiality using trusted computing

Also Published As

Publication number Publication date
EP3385864B1 (en) 2024-01-03
US11003649B2 (en) 2021-05-11
WO2017092583A1 (zh) 2017-06-08
EP3385864A4 (en) 2018-10-10
JP2019502980A (ja) 2019-01-31
CN106815260B (zh) 2021-05-04
EP3385864A1 (en) 2018-10-10
US20180276264A1 (en) 2018-09-27
CN106815260A (zh) 2017-06-09

Similar Documents

Publication Publication Date Title
JP6898320B2 (ja) インデックス確立の方法およびデバイス
Yang et al. Druid: A real-time analytical data store
US11157473B2 (en) Multisource semantic partitioning
CA2939903C (en) Transparent discovery of semi-structured data schema
JP6338817B2 (ja) データベースミドルウェアを用いたデータ管理システム及びその方法
EP3285178A1 (en) Data query method in crossing-partition database, and crossing-partition query device
CN109815283B (zh) 一种异构数据源可视化查询方法
US8949222B2 (en) Changing the compression level of query plans
US11275738B2 (en) Prefix N-gram indexing
US11372860B2 (en) Processing techniques for queries where predicate values are unknown until runtime
US10769126B1 (en) Data entropy reduction across stream shard
CN107291770B (zh) 一种分布式系统中海量数据的查询方法及装置
US9984081B2 (en) Workload aware data placement for join-based query processing in a cluster
US9405801B2 (en) Processing a data stream
CN108228654A (zh) 一种大数据分布式存储方法和系统
CN108319604B (zh) 一种hive中大小表关联的优化方法
MahmoudiNasab et al. AdaptRDF: adaptive storage management for RDF databases
Xu et al. Banian: a cross-platform interactive query system for structured big data
Guzun et al. A two-phase mapreduce algorithm for scalable preference queries over high-dimensional data
Li et al. The research of performance optimization methods based on Impala cluster
US20170293658A1 (en) Partition aware evaluation of top-n queries
US11880369B1 (en) Pruning data based on state of top K operator
Lai et al. Evaluating data storage structures of MapReduce
Wang et al. Research on the Optimization of Spark Big Table Equal Join
Ttito et al. Query co-planning for shared execution in key-value stores

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20191106

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20191106

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20201126

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20201222

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20210319

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

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20210610

R150 Certificate of patent or registration of utility model

Ref document number: 6898320

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250