(57)【要約】  本発明は、インデックス確立の方法およびデバイスを開示している。予め設定された時間閾値内のデータベースの列のインデックスの状態の情報にしたがって、インデックスが列に対して確立される必要があるかどうかがまず判定される。インデックスが確立される必要があると判定されると、列のデータ情報にしたがってインデックス型が判定され、インデックス型にしたがってインデックスが列に対して確立される。したがって、インデックスをデータベースの列ごとに動的に確立することができ、適したインデックス型を実例にしたがって選択することができ、リソース消費および労働投入量の低減を前提に、データ検索効率を効果的に高めることができるようになる。【選択図】なし
2019502980.tif 000002
【特許請求の範囲】
【請求項１】
インデックス確立の方法であって、
予め設定された時間閾値内のデータベースの列のインデックスの状態の情報にしたがって、インデックスが前記列に対して確立される必要があるかどうかを判定することと、
インデックスが前記列に対して確立される必要があると判定された場合、前記列のデータ情報にしたがってインデックス型を判定し、前記列に対するインデックスを前記インデックス型にしたがって確立することとを含む、方法。
【請求項２】
インデックスが前記列に対して確立される必要がないと判定された場合、前記時間閾値の後で、かつ、前記時間閾値内の前記列のインデックス使用状態の情報にしたがって、インデックスが前記列に対して確立される必要があるかどうかを判定することをさらに含む、請求項１に記載の方法。
【請求項３】
予め設定された時間閾値内のデータベースの列の前記インデックスの状態の情報にしたがって、インデックスが前記列に対して確立される必要があるかどうかを判定する前記ステップが、具体的には、
前記時間閾値内の前記列の前記インデックスの状態の情報を取得すること、
前記インデックスの状態の情報にしたがって、前記時間閾値内にインデックスが前記列に対して用いられるかどうかを判定し、判定結果が肯定であるとき、前記列に対するインデックスが前記時間閾値内に用いられる回数が予め設定された回数閾値以上であるかどうかを判定すること、および、
インデックスが前記時間閾値内に前記列に対して用いられない場合、または、前記列に対するインデックスが前記時間閾値内に用いられる回数が前記回数閾値未満である場合、インデックスが前記列に対して確立される必要がないと判定することか、または、
前記列に対するインデックスが前記時間閾値内に用いられる回数が前記回数閾値以上である場合、インデックスが前記列に対して確立される必要があると判定することである、請求項２に記載の方法。
【請求項４】
前記インデックス型が、Ｂ−ツリーインデックス、ハッシュインデックスおよびビットマップインデックスを少なくとも含み、前記列の前記データ情報にしたがってインデックス型を判定する前記ステップが、具体的には、
前記列が連続値型である場合、前記インデックス型がＢ−ツリーインデックスであると判定すること、
前記列に結合が起きている場合、前記インデックス型がハッシュインデックスであると判定すること、および、
前記列の単語数が予め設定された単語数閾値より多い場合、前記インデックス型が転置インデックスであると判定することか、または、
前記列の単語数が予め設定された単語数閾値以下であり、結合が起きておらず、前記列が不連続値型である場合、前記インデックス型がビットマップインデックスであると判定することである、請求項１に記載の方法。
【請求項５】
ユーザが送信した検索式を、前記検索式が受信されたときに複数の部分式に分割すること、
各部分式に対応する検索結果がキャッシュ内に存在するかどうかを問い合わせすること、および、
前記検索結果が存在する場合、前記部分式に対応する検索結果および他の部分式の検索結果にしたがって、前記ユーザに戻される検索応答を生成することか、または、
前記部分式に対応する検索結果が存在しない場合、前記列のインデックスを用いることによって前記部分式に関する検索を実行し、前記検索結果を、前記ユーザに戻される検索応答が前記検索結果および他の部分式の検索結果にしたがって生成された後、前記キャッシュに格納することをさらに含む、請求項１に記載の方法。
【請求項６】
予め設定された時間閾値内のデータベースの列の前記インデックスの状態の情報にしたがって、インデックスが前記列に対して確立される必要があるかどうかを判定する前記ステップの前に、
前記データベースを初期化後、デフォルトのインデックス型にしたがって、前記データベースの列ごとにインデックスを構築し、予め設定された時間に達すると、列ごとに再度インデックスを構築することをさらに含む、請求項１に記載の方法。
【請求項７】
予め設定された時間閾値内のデータベースの列のインデックスの状態の情報にしたがって、インデックスが前記列に対して確立される必要があるかどうかを判定するように構成された判定モジュールと、
前記判定モジュールが、インデックスが前記列に対して確立される必要があると判定すると、前記列のデータ情報にしたがってインデックス型を判定し、前記インデックス型にしたがって、前記列に対するインデックスを確立するように構成された確立モジュールとを備える、インデックス確立デバイス。
【請求項８】
前記確立モジュールが、前記判定モジュールによりインデックスが前記列に対して確立される必要がないと判定されたとき、前記時間閾値の後で、かつ、前記時間閾値内の前記列のインデックス使用状態の情報にしたがって、インデックスが前記列に対して確立される必要があるかどうかを判定するようにさらに構成される、請求項１に記載のデバイス。
【請求項９】
前記判定モジュールが、具体的には、
前記時間閾値内の前記列の前記インデックスの状態の情報を取得し、
前記インデックスの状態の情報にしたがって、前記時間閾値内にインデックスが前記列に対して用いられるかどうかを判定し、判定結果が肯定のとき、前記列に対するインデックスが前記時間閾値内に用いられる回数が予め設定された回数閾値以上であるかどうかを判定し、
前記時間閾値内にインデックスが前記列に対して用いられない場合、または、前記列に対するインデックスが前記時間閾値内に用いられる回数が前記回数閾値未満である場合、インデックスが前記列に対して確立される必要がないと判定するか、または、
前記列に対するインデックスが前記時間閾値内に用いられる回数が前記回数閾値以上である場合、インデックスが前記列に対して確立される必要があると判定するように構成される、請求項８に記載のデバイス。
【請求項１０】
前記インデックス型が、Ｂ−ツリーインデックス、ハッシュインデックスおよびビットマップインデックスを少なくとも備え、前記列の前記データ情報にしたがってインデックス型を判定するように構成された前記確立モジュールが、具体的には、
前記列が連続値型である場合、前記インデックス型がＢ−ツリーインデックスであると判定し、
前記列で結合が起きている場合、前記インデックス型がハッシュインデックスであると判定し、
前記列の単語数が予め設定された単語数閾値より多い場合、前記インデックス型は転置インデックスであると判定するか、または、
前記列の単語数が予め設定された単語数閾値以下であり、結合が起きておらず、前記列が不連続値型である場合、前記インデックス型はビットマップインデックスであると判定するように構成される、請求項８に記載のデバイス。
【請求項１１】
ユーザが送信した検索式を、前記検索式が受信されたときに複数の部分式に分割するように構成された分割モジュールと、
各部分式に対応する検索結果がキャッシュ内に存在するかどうかを問い合わせるように構成されたクエリモジュールと、
前記検索結果が存在するとき、前記部分式に対応する検索結果および他の部分式の検索結果にしたがって、前記ユーザに戻される検索応答を生成するか、または、前記部分式に対応する検索結果が存在しないとき、前記列のインデックスを用いることによって前記部分式に関する検索を実行し、前記検索結果を、前記ユーザに戻される検索応答が前記検索結果および他の部分式の検索結果にしたがって生成された後、前記キャッシュに格納するように構成された処理モジュールと、をさらに備える、請求項８に記載のデバイス。
【請求項１２】
前記データベースを初期化後、デフォルトのインデックス型にしたがって前記データベースの列ごとにインデックスを構築し、予め設定された時間に達すると、列ごとに再度インデックスを構築するように構成された初期化モジュールをさらに備える、請求項８に記載のデバイス。
【発明の詳細な説明】
【技術分野】
【０００１】
本願は、参照によりその全体が本明細書に援用される、２０１５年１２月１日に出願された「ＩＮＤＥＸ  ＥＳＴＡＢＬＩＳＨＭＥＮＴ  ＭＥＴＨＯＤ  ＡＮＤ  ＤＥＶＩＣＥ（インデックス確立の方法およびデバイス）」と題された中国特許出願第２０１５１０８６８２５４．Ｘ号の優先権を主張する。
【０００２】
本発明は、通信技術分野に関し、より詳細には、インデックス確立の方法に関する。本願は、さらにインデックス確立のデバイスに関する。
【背景技術】
【０００３】
インデックスは、データベーステーブルの１つ以上の列の値をソートするための構造である。インデックスを用いることによって、データベーステーブルにおける特定の情報に迅速にアクセスすることができる。インデックスは、テーブルの指定された列に格納されたデータ値を指すポインタを提供する。次いで、これらのポインタはユーザが指定するソート順にしたがってソートされる。データベースでインデックスを使用する必要があるとき、特定の値を発見するためにまずインデックスが検索され、その後、その値を含む行がポインタにしたがって発見される。
【０００４】
インターネット技術の持続的開発とともに、莫大な量のデータが、インターネットでの人々の日常活動から生成される。格納されている莫大な量のデータから所要のデータをどのようにして迅速に発見するかは、技術者にとって大きな関心事となっている。従来のデータベースにおいて、ユーザは、インデックスのインデックス型を指定する必要がある。しかしながら、同一のインデックス型において、異なるタイプのデータに対しては必要とされるクエリ時間の長さが異なる。結果として、インデックス型が不適切に設定された場合、ユーザは、データベースにおいてクエリを作成するのに過度に長い時間を費やす必要が生じ、不十分なユーザ経験がもたらされることになる。
【０００５】
本願の実施の際、発明者は先行技術が以下の欠点を有することを発見している。
（１）既存のインデックス型は不変なものであり、いくつかのシナリオで不十分なクエリパフォーマンスを招く。従来のデータのインデックス型は、比較的不変のものであり、Ｂ−ツリーインデックスが多くを占めている。Ｂ−ツリーインデックスは、あらゆるデータ特徴に適したものではない。例えば、検索速度はキー−値モードにおいて非常に遅い。結合を有する構造化問い合わせ言語（ＳＱＬ）では、１つのＳＱＬに対して複数の検索が行われるだろう。結合ＳＱＬのパフォーマンスは、Ｂ−ツリーが検索に用いられるか否かに強く影響される。
（２）ログは、インデックスを最適化するために手動解析され、不十分な運用性および保全性につながる。
【０００６】
大量のデータが存在するとき、従来のデータベースにおいて、インデックスは非常に高額の保全コストをもたらす。結果的に、ユーザアクセスログは、どの列が新規のインデックスを必要とし、どの列がインデックスを必要とせず、複合インデックスを確立するためにどの列が組み合わされるかを決定するために、毎晩閲覧される必要がある。履歴統計を用いることによるインデックス型のそうした自動的な調整（履歴ベースの最適化、ＨＢＯ）は完全に手動であり、非常に不十分な運用性および保全性につながる。
【０００７】
把握することができるように、データ取得効率を向上させ運用リソースおよび保全リソースを節約するために、どのようにデータベースの使用を組み合わせてデータベースの列に対する適したインデックスを確立するかは、当業者が早急に解決する必要がある技術的な課題となっている。
【発明の概要】
【０００８】
本発明は、インデックス確立の方法を提供する。インデックス確立の手続きは、データ取得効率を向上させ同時に労働消費を低減させるために最適化される。本方法は、以下の、
予め設定された時間閾値内のデータベースの列のインデックスの状態の情報にしたがって、インデックスが列に対して確立される必要があるかどうかを判定するステップと、
インデックスが列に対して確立される必要があると判定された場合、列のデータ情報にしたがってインデックス型を判定し、インデックス型にしたがって列に対するインデックスを確立するステップとを含む。
【０００９】
好ましくは、本方法は、さらに、
インデックスが列に対して確立される必要がないと判定された場合、時間閾値の後で、かつ、時間閾値内の列のインデックス使用状態の情報にしたがって、インデックスが列に対して確立される必要があるかどうかを判定することを含む。
【００１０】
好ましくは、予め設定された時間閾値内のデータベースの列のインデックスの状態の情報にしたがって、インデックスが列に対して確立される必要があるかどうかを判定するステップは、具体的には、
時間閾値内の列のインデックスの状態の情報を取得することと、
インデックスの状態の情報にしたがって、時間閾値内にインデックスが列に対して用いられるかどうかを判定し、判定結果が肯定であるとき、列に対するインデックスが時間閾値内に用いられる回数が予め設定された回数閾値以上であるかどうかを判定することと、
時間閾値内にインデックスが列に対して用いられない場合、または、列に対するインデックスが時間閾値内に用いられる回数が予め設定された回数閾値未満である場合、インデックスが列に対して確立される必要がないと判定すること、または、
時間閾値内に列に対するインデックスが用いられる回数が回数閾値以上である場合、インデックスが列に対して確立される必要があると判定することである。
【００１１】
好ましくは、インデックス型は、Ｂ−ツリーインデックス、ハッシュインデックスおよびビットマップインデックスを少なくとも含み、列のデータ情報にしたがってインデックス型を判定するステップは、具体的には、
列が連続値型である場合、インデックス型はＢ−ツリーインデックスであると判定することと、
列で結合が起きている場合、インデックス型はハッシュインデックスであると判定することと、
列の単語数が予め設定された単語数閾値より多い場合、インデックス型は転置インデックスであると判定すること、または、
列の単語数が予め設定された単語数閾値以下であり、結合が起きておらず、列が不連続値型である場合、インデックス型はビットマップインデックスであると判定することである。
【００１２】
好ましくは、本方法は、さらに、
ユーザが送信した検索式を、検索式が受信されたときに複数の部分式に分割することと、
各部分式に対応する検索結果がキャッシュ内に存在するかどうかを問い合わせることと、
検索結果が存在する場合、部分式に対応する検索結果および他の部分式の検索結果にしたがって、ユーザに戻される検索応答を生成すること、または、
部分式に対応する検索結果が存在しない場合、列のインデックスを用いることによって部分式に関する検索を行い、ユーザに戻される検索応答が検索結果および他の部分式の検索結果にしたがって生成された後、検索結果をキャッシュに格納することと、を含む。
【００１３】
好ましくは、予め設定された時間閾値内のデータベースの列のインデックスの状態の情報にしたがって、インデックスが列に対して確立される必要があるかどうかを判定するステップの前に、本方法は、さらに、
データベースを初期化後、デフォルトのインデックス型にしたがってデータベースの列ごとにインデックスを構築し、予め設定された時間に達すると、列ごとに再度インデックスを構築することを含む。
【００１４】
対応して、本願は、さらに、
予め設定された時間閾値内のデータベースの列のインデックスの状態の情報にしたがって、インデックスが列に対して確立される必要があるかどうかを判定するように構成された判定モジュールと、
判定モジュールが、インデックスが列に対して確立される必要があると判定すると、列のデータ情報にしたがってインデックス型を判定し、インデックス型にしたがって列に対するインデックスを確立するように構成された確立モジュールとを含むインデックス確立デバイスを提供する。
【００１５】
好ましくは、確立モジュールは、判定モジュールによりインデックスが列に対して確立される必要がないと判定されると、時間閾値後に、かつ、時間閾値内の列のインデックス使用状態の情報にしたがって、インデックスが列に対して確立される必要があるかどうかを判定するようにさらに構成される。
【００１６】
好ましくは、判定モジュールは、具体的には、
時間閾値内の列のインデックスの状態の情報を取得し、
インデックスの状態の情報にしたがって、時間閾値内にインデックスが列に対して用いられるかどうかを判定し、判定結果が肯定であるとき、列に対するインデックスが時間閾値内に用いられる回数が予め設定された回数閾値以上であるかどうかを判定し、
インデックスが時間閾値内に列に対して用いられない場合、または、列に対するインデックスが時間閾値内に用いられる回数が回数閾値未満である場合、インデックスが列に対して確立される必要がないと判定するか、または、
列に対するインデックスが時間閾値内に用いられる回数が回数閾値以上である場合、インデックスが列に対して確立される必要があると判定するように構成される。
【００１７】
好ましくは、インデックス型は、Ｂ−ツリーインデックス、ハッシュインデックスおよびビットマップインデックスを少なくとも含み、列のデータ情報にしたがってインデックス型を判定するように構成された確立モジュールは、具体的には、
列が連続値型である場合、インデックス型はＢ−ツリーインデックスであると判定し、
列で結合が起きている場合、インデックス型はハッシュインデックスであると判定し、
列の単語数が予め設定された単語数閾値より多い場合、インデックス型は転置インデックスであると判定するか、または、
列の単語数が予め設定された単語数閾値以下であり、結合が起きておらず、列が不連続値型である場合、インデックス型はビットマップインデックスであると判定する。
【００１８】
好ましくは、本デバイスは、さらに、
ユーザが送信した検索式を、検索式が受信されたときに複数の部分式に分割するように構成された分割モジュールと、
各部分式に対応する検索結果がキャッシュ内に存在するかどうかを問い合わせるように構成されたクエリモジュールと、
検索結果が存在するとき、部分式に対応する検索結果および他の部分式の検索結果にしたがって、ユーザに戻される検索応答を生成するか、または、部分式に対応する検索結果が存在しないとき、列のインデックスを用いることによって部分式に関して検索を行い、ユーザに戻される検索応答が検索結果および他の部分式の検索結果にしたがって生成された後、検索結果をキャッシュに格納するように構成された処理モジュールと、を含む。
【００１９】
好ましくは、本デバイスは、さらに、
データベースを初期化後、デフォルトのインデックス型にしたがってデータベースの列ごとにインデックスを構築し、予め設定された時間に達すると、列ごとにインデックスを再度構築するように構成された初期化モジュールを含む。
【００２０】
把握することができるように、本開示の技術的解決策を適用することによって、予め設定された時間閾値内のデータベースの列のインデックスの状態の情報にしたがって、インデックスが列に対して確立される必要があるかどうかがまず判定され、インデックスが列に対して確立される必要があると判定されると、列のデータ情報にしたがってインデックス型が判定され、インデックス型にしたがってインデックスが列に対して確立される。したがって、インデックスをデータベースの列ごとに動的に確立することができ、適したインデックス型を実際のケースにしたがって選択することができ、リソース消費および労働投入量の低減を前提として、データ検索効率を効果的に高めることができるようになる。
【図面の簡単な説明】
【００２１】
【図１】本願によるインデックス確立の方法の概略フローチャートである。
【図２】本願の特定の実施形態におけるデータ構造の概略図である。
【図３】本願の特定の実施形態によるストリームされた結果のマージングの概略フローチャートである。
【図４】本願の特定の実施形態によるインデックスの概略構造図である。
【図５】本願の特定の実施形態によるインデックスを確立する概略フローチャートである。
【図６】本願によるインデックス確立のデバイスの概略構造図である。
【発明を実施するための形態】
【００２２】
背景技術における課題を考慮して、本願は、インデックス確立の方法を提供する。データベースの各列のインデックス使用状態にしたがって、インデックスが列に対して確立される必要があるかどうかが速やかに判定され、インデックスの確立時に、適したインデックス型が列のデータ情報に照らして選択される。したがって、ハードウェアリソースの節約および労働投入量の低減を前提として、検索効率が高められる。
【００２３】
図１は、本願によるインデックス確立の方法の概略フローチャートである。本方法は、以下のステップを含む。
Ｓ１０１：予め設定された時間閾値内のデータベースの列のインデックスの状態の情報にしたがって、インデックスが列に対して確立される必要があるかどうかが判定される。
インデックスが列に対して確立される必要があると判定された場合、ステップＳ１０２が実行される。
【００２４】
インデックスが列に対して確立される必要がないと判定された場合、プロセスはステップＳ１０１に戻って、次の予め設定された時間閾値に対応する時間間隔内にインデックスが列に対して確立される必要があるかどうかの判定を続ける。
【００２５】
莫大な量のデータが存在する場合、ユーザがあらゆる列を検索または問い合わせすることはあまりないので、インデックスをデータベースの列ごとに確立することは時間と手間がかかり、不必要なものである。したがって、本願では、インデックスの状態の情報は、データベースの列ごとに導入される。一定の期間内のインデックスの状態の情報に基づいて、インデックスが列に対して確立される必要があるかどうかが判定される。一方、各列のインデックスの状態の情報をユーザの検索態様および習慣にしたがって速やかに調整することができることを確保するために、本願では、各時間閾値後に、各列のインデックスの状態の情報が更新され、例えば時間閾値内にインデックスが列に対して用いられたかどうか、インデックスが用いられた回数は特定の数に達するかどうかが判定される。特定の適用シナリオでは、時間閾値は、具体的には、対応する列のインデックス使用状態の統計を収集するための統計収集時間範囲を示す予め設定された時間間隔値である。時間閾値は、データベースの容量およびユーザ数にしたがって調整され得る。一般に、時間閾値は１日に設定されてもよく、技術者は、時間閾値をこれに基づき延長してもよくまたは短縮してもよい。これらの時間閾値は全て本願の保護範囲内に含まれる。
【００２６】
本願の好ましい実施形態では、このステップのために特定の判定態様が提供され、それは以下のステップを含む。
ステップａ）：時間閾値内の列のインデックスの状態の情報が取得される。
ステップｂ）：インデックスの状態の情報にしたがって、時間閾値内にインデックスが列に対して用いられるかどうかが判定され、判定結果が肯定のとき、時間閾値内に列に対するインデックスが用いられる回数が予め設定された回数閾値以上であるかどうかが判定される。
【００２７】
前述の判定ステップに基づいて、インデックスが時間閾値内に列に対して用いられない場合、または、列に対するインデックスが時間閾値内に用いられる回数が回数閾値未満である場合、インデックスが列に対して確立される必要がないと判定されるか、または、列に対するインデックスが時間閾値内に用いられる回数が回数閾値以上である場合、インデックスが列に対して確立される必要があると判定される。
【００２８】
前述の実施形態において、特定のステップおよび判定ベースが、インデックスが列に対して確立される必要があるかどうかをこれに基づいて判定するために用いられているが、当業者は別のタイプの基準を用いることによって判定を行い得ることに留意されるべきである。これらの改良はすべて、本願の保護範囲内に含まれる。
【００２９】
さらに、データベースを初期化後、この時点では、データベースのいずれの列も確立されたインデックスを有していない。この場合、インデックスは、本願のデフォルトのインデックス型にしたがってデータベースの列ごとに構築され、予め設定された時間に達すると、インデックスは再度列ごとに構築される。このプロセスにおいて均一に確立されるインデックスは、技術者により予め設定され得る。
【００３０】
Ｓ１０２：列のデータ情報にしたがってインデックス型が判定され、インデックス型にしたがってインデックスが列に対して確立される。
【００３１】
Ｓ１０１によってインデックスが列に対して確立される必要があると判定された後、インデックス型を列のデータ情報にしたがって判定することができる。したがって、個別の検索サービスを様々なケースに基づいてユーザに提供することができ、全ユーザによる現在のデータベースへの問い合わせの平均時間が大幅に減ることになる。
【００３２】
反対に、ステップＳ１０１に記載したように、インデックスが列に対して確立される必要がないと判定された場合、本願の技術的解決策では、現在の時間閾値に対応する時間間隔が終了した後、次の時間閾値に対応する時間間隔内の列のインデックス使用状態の情報にしたがって、インデックスが列に対して確立される必要があるかどうかが再度判定される。言い換えると、ステップＳ１０１が再度実行される。したがって、実際のケースにしたがって柔軟な調整をなすことができる。
【００３３】
現在、慣用のインデックス型として、転置インデックス、Ｂ−ツリーインデックス、ハッシュインデックスおよびビットマップインデックスが挙げられる。したがって、本願の好ましい実施形態では、インデックス型は、以下の条件を用いることによって具体的に判定される。
（１）列が連続値型である場合、インデックス型はＢ−ツリーインデックスであると判定される。
（２）列で結合が起きている場合、インデックス型はハッシュインデックスであると判定される。
結合はリレーショナルデータベースシステムにおいて重要な演算の１つであることに留意されるべきである。ＳＱＬサーバにおける広く知られた結合として、内部結合、外部結合、交差結合などが挙げられる。１つのテーブルの行および別のテーブルの行の一致しているデータが２つ以上のテーブルから取得される必要がある場合、結合はテーブルまたは機能を結合してクエリを実行することによって特徴付けられるので、結合演算の使用が検討される必要がある。
（３）列の単語数が予め設定された単語数閾値より多い場合、インデックス型は転置インデックスであると判定される。
ここで、列の単語数は、具体的には、列に含まれる変数値の数である。
（４）列の単語数が予め設定された単語数閾値以下であり、結合が起きておらず、列が不連続値型である場合、インデックス型はビットマップインデックスであると判定される。
【００３４】
本願の特定の実施形態では、列のデータが値型であり連続している場合（例えば、通貨量）、一般的に述べると、そのような値型のフィールドには範囲クエリのみが実行される必要がある。図２のデータ構造の図では、Ｂツリーのデータ構造の中間ノードは本来的に範囲属性を有する。したがって、連続値型の列において、Ｂツリーインデックスにおける範囲検索の効率は、転置インデックスおよびビットマップインデックスにおける範囲検索の効率よりもはるかに良い。
【００３５】
さらに、インデックススライス全体にｎ個のレコードが存在し、フィールドＡはＸ個の異なる項目の値を有し、「ｄｅｌｔａ＋ｖｉｎｔ」の元の圧縮アルゴリズムの圧縮率はｐであると仮定する。この場合、以下の結果が、「ｘ＊ｎ／３２＜ｎ＊４＊ｐ」の変換式「ｘ＜１２８＊ｐ」を用いることによって取得され得、「ｄｅｌｔａ＋ｖｉｎｔ」の圧縮アルゴリズムの最大圧縮率は１／４である：ｐ＝１／４のとき、「ｘ＜１２８＊ｐ」に代入することで、ｘ＜１２８＊１／４＝３２が取得され得る。
【００３６】
前述の結果から把握することができるように、単語数が３２より少ない場合、ビットマップインデックスが用いられるときに占める空間は、転置インデックスが用いられるときに占める空間よりも小さい。したがって、前述の好ましい実施形態では、単語数閾値は、具体的には３２に設定され得る。しかしながら、単語数閾値はその後に別のアルゴリズムに基づいて変更され得ることも指摘されるべきである。このことは、本願の保護範囲に影響を与えない。
【００３７】
さらに、先行技術において１つのユーザのクエリが作成された後、クエリに関する検索情報は保存されない。一般に、ユーザのクエリ式は、通常複数の異なる部分式から形成される。したがって、アトミックな部分式が従来のデータベースにキャッシュされない場合、部分式のクエリ結果を同一の式を有する異なるＳＱＬに対して再使用することはできない。結果として、アトミックな部分式がキャッシュされないとき、オンライン分析処理（ＯＬＡＰ）における任意の次元のブール演算のパフォーマンスは不十分なものである。そのような状況を踏まえて、本願の好ましい実施形態は、ユーザが送信した検索式が、検索式が受信されたときに複数の部分式に分割され、各部分式に対応する検索結果がキャッシュ内に存在するかどうかが問い合わせされるという解決策を提供する。この処理は、以下のケースに基づくものである。
（１）検索結果が存在する場合、ユーザに戻される検索応答は、部分式に対応する検索結果および他の部分式の検索結果にしたがって生成されるか、または、
（２）部分式に対応する検索結果が存在しない場合、列のインデックスを用いることによって部分式に関して検索が行われ、検索結果は、ユーザに戻される検索応答が検索結果及び他の部分式の検索結果にしたがって生成された後、キャッシュに格納される。
【００３８】
図３のストリームされた結果のマージングの概略フローチャートは、一例として用いられる。インデックスが問い合わせされた後に圧縮解凍を通して得られた転置リンクは、ビットマップ構造を用いることによってメモリに格納される。このストリームされたマージングフレームワークでは、式間のブール演算は、いかなる中間オブジェクトも生成しないという前提のもと、マージングを介して１つずつ取得される。ストリームされたマージングプロセス全体は、以下の４つの部分を含む。
（１）クエリビルダ（キュー作成構成要素）は、ｗｈｅｒｅ式にしたがって、エンジンクエリ（キューエンジン）オブジェクトツリーを生成する。
（２）Ｒｏｗｉｄ選択ツリーがエンジンクエリオブジェクトツリーにしたがって構築される。
（３）Ｒｏｗｉｄ設定は様々なインデックスから取得されリーフノードに挿入され、中間ノードは論理演算マージャーである。
（４）選択はルートノードから１つずつ行われ、Ｒｏｗｉｄは収集される。
【００３９】
特定の実施形態は、異なるＳＱＬ文が同一のｗｈｅｒｅ式を有してもよいケースに基づくものである。したがって、アトミックな部分式はキャッシュされて、インデックスクエリのパフォーマンスを加速させる。
【００４０】
前述の技術的解決策を適用することによって、列のレベルで独立しているインデックス構造に基づいて、最も適したインデックス型がコストおよび費用（costs and expenses）にしたがって自動的に選択され、履歴統計（ＨＢＯ）を用いてインデックス型を自動的に調整し、同時に、アトミックな部分式がキャッシュされる。したがって、格納コストを削減しながらインデックスクエリのパフォーマンスが加速される。
【００４１】
本発明の技術的概念をさらに例示するために、図４のインデックスの構造図を用いて本発明の技術的解決策を説明する。特定の実施形態では、図４に示す列レベルのインデックスアーキテクチャは、転置インデックス、ビットマップインデックス、ハッシュインデックスおよびＢツリーインデックスなどのインデックスの原理および特性に基づいて自立的に実装され、４つのインデックス型全てをサポートすることができる。インデックス型はユーザに対して透過的であり、ユーザが外部的に指定する必要がない。その代りに、インデックス型は、データ特徴にしたがって自動的に選択される。さらに、複数のインデックス型は、ブール演算を行うのに同一のデータ構造を用いる。ｗｈｅｒｅ部分式の結果が発見されるインデックスは、エンジン層で認識される必要がない。さらに、インデックスは、手動での関与を必要とすることなく、履歴統計情報にしたがって自動的に最適化され得る。
【００４２】
具体的には、インデックスの構造図は、主に、以下の３つの部分を含む。
（１）ストリームされたマージャーは、異なるインデックスのクエリ結果および計算層間のインタラクションを統一することに関与している。異なるインデックスを用いたクエリによる結果は、ビットマップを用いることによって格納され、次いで、ストリームされたマージャーツリーが、ｗｈｅｒｅ式のブール演算にしたがって生成され、次いで、マージャーは、ｗｈｅｒｅ式を満たす行番号を１つずつ出力する。
（２）インデックスマネージャは、インデックス管理、型選択および自動的なインデックス最適化手続きに関与している。
（３）部分式キャッシュ（ビットマップキャッシュ）は、ｗｈｅｒｅ部分式のキャッシングに関与している。このことから、インデックスは、異なるＳＱＬが同一の部分式を有するとき、もはやクエリされる必要はなく、クエリは直接キャッシュ内で作成され得る。
【００４３】
前述の説明に基づいて、図５のインデックスを確立する概略フローチャートでは、まずインデックスがデータベースの列ごとに確立され、毎日インデックスが再度確立され、履歴ＳＱＬ統計データが取得される。履歴データに基づいて、インデックスが当日に列に対して用いられるかどうか、およびインデックスが用いられる回数が閾値を超えるかどうかが判定される。インデックスが列に対して確立される必要があると判定された後、異なるインデックス型が、列のデータタイプにしたがって選択される。したがって、異なる列のフィールドに対して異なるインデックス型の使用をサポートする（転置インデックス、Ｂ−ツリーインデックス、ビットマップインデックスおよびハッシュインデックスが全てサポートされる）だけでなく、インデックス型はユーザに認識されることなく選択され、その結果、格納コストが大幅に節約されクエリ速度が大幅に早まることになる。
【００４４】
前述の技術的目的を達成するために、本願は、さらに、インデックス確立デバイスを提供する。図６に示すように、デバイスは、
所定時間閾値内のデータベースの列のインデックスの状態の情報にしたがって、インデックスが列に対して確立される必要があるかどうか判定するように構成された判定モジュール６１０と、
判定モジュールが、インデックスが列に対して確立される必要があると判定すると、列のデータ情報にしたがってインデックス型を判定し、インデックス型にしたがって列に対するインデックスを確立するように構成された確立モジュール６２０とを含む。
【００４５】
特定の適用シナリオでは、確立モジュールはさらに、判定モジュールによってインデックスが列に対して確立される必要がないと判定されたとき、時間閾値の後で、かつ、時間閾値内の列のインデックス使用状態の情報にしたがって、インデックスが列に対して確立される必要があるかどうかを判定するように構成される。
【００４６】
特定の適用シナリオでは、判定モジュールは、具体的には、
時間閾値内の列のインデックスの状態の情報を取得し、
インデックスの状態の情報にしたがって、時間閾値内にインデックスが列に対して用いられるかどうかを判定し、判定結果が肯定であるとき、列に対するインデックスが時間閾値内に用いられる回数が予め設定された回数閾値以上であるかどうかを判定し、
時間閾値内にインデックスが列に対して用いられない場合、または、列に対するインデックスが時間閾値内に用いられる回数が回数閾値未満である場合、インデックスが列に対して確立される必要がないと判定するか、または、
列に対するインデックスが時間閾値内に用いられる回数が回数閾値以上である場合、インデックスが列に対して確立される必要があると判定するように構成される。
【００４７】
特定の適用シナリオでは、インデックス型は、Ｂ−ツリーインデックス、ハッシュインデックスおよびビットマップインデックスを少なくとも含み、列のデータ情報にしたがってインデックス型を判定するように構成された確立モジュールは、具体的には、
列が連続値型である場合、インデックス型はＢ−ツリーインデックスであると判定し、
列で結合が起きている場合、インデックス型はハッシュインデックスであると判定し、
列の単語数が予め設定された単語数閾値よりも多い場合、インデックス型は転置インデックスであると判定するか、または、
列の単語数が予め設定された単語数閾値よりも多いものではなく、結合が起きておらず、列が不連続値型である場合、インデックス型はビットマップインデックスであると判定する。
【００４８】
特定の適用シナリオでは、デバイスは、さらに、
ユーザが送信した検索式を、検索式が受信されたときに複数の部分式に分割するように構成された分割モジュールと、
各部分式に対応する検索結果がキャッシュ内に存在するかどうかを問い合わせるように構成されたクエリモジュールと、
検索結果が存在するとき、部分式に対応する検索結果及び他の部分式の検索結果にしたがって、ユーザに戻される検索応答を生成するか、または、部分式に対応する検索結果が存在しないとき、列のインデックスを用いることによって部分式に関する検索を実行し、検索結果を、ユーザに戻される検索応答が検索結果および他の部分式の検索結果にしたがって生成された後、キャッシュに格納するように構成された処理モジュールと、を含む。
【００４９】
特定の適用シナリオでは、デバイスは、さらに、
データベースを初期化後、デフォルトのインデックス型にしたがって、データベースの列ごとにインデックスを構築し、予め設定された時間に達すると、列ごとにインデックスを再度構築するように構成された初期化モジュールを含む。
【００５０】
本願の技術的解決策を適用することによって、予め設定された時間閾値内のデータベースの列のインデックスの状態の情報にしたがって、インデックスが列に対して確立される必要があるかどうかがまず判定され、インデックスが確立される必要があると判定されると、列のデータ情報にしたがってインデックス型が判定され、インデックス型にしたがってインデックスが列に対して確立される。したがって、インデックスをデータベースの列ごとに動的に確立することができ、適したインデックス型を実際のケースにしたがって選択することができ、検索効率を、リソース消費および労働投入量の低減を前提として、効果的に向上させることができるようになる。
【００５１】
実装態様のこの説明から把握することができるように、当業者であれば、本発明はソフトウェアまたはソフトウェア加えて必要なユニバーサルハードウェアプラットフォームを用いることによって実装され得ることを明確に理解し得る。そうした理解に基づいて、本発明の技術的解決策はソフトウェア製品の形式で実装され得る。ソフトウェア製品は、不揮発性保存媒体（ＣＤ−ＲＯＭ、ＵＳＢフラッシュデバイス、リムーバブルハードディスクなどであってもよい）に格納されてもよく、コンピュータデバイス（パーソナルコンピュータ、サーバ、ネットワークデバイスなどであってもよい）に本発明の実装シナリオにおける方法を実行することを指示するいくつかの命令を含む。
【００５２】
当業者であれば、添付の図面は好ましい実装シナリオのただの概略図であることを理解し得る。添付の図面のモジュールまたは手続きは、本発明を実装するために必ずしも必須なものではない。
【００５３】
当業者であれば、実装シナリオの装置のモジュールは、実装シナリオの説明にしたがって実装シナリオの装置に分散され得、または、それに対応して実装シナリオの装置とは異なる１つ以上の装置に配置されるように変更され得ることを理解し得る。前述の実装シナリオのモジュールは、１つのモジュールに組み合わされ得、または、さらに複数のサブモジュールに分割され得る。
【００５４】
本発明の前述のシーケンスの番号は単に説明の便宜のためのものであり、実装シナリオ内の優先を意味するものではない。
【００５５】
前述の開示は、本発明の単なるいくつかの特定の実装シナリオであるが、本発明はそれらに限定されるものではない。当業者によって想定される任意の変更は、本発明の保護範囲内に存在しなければならない。
【図１】
2019502980.tif 000003
【図２】
2019502980.tif 000004
【図３】
2019502980.tif 000005
【図４】
2019502980.tif 000006
【図５】
2019502980.tif 000007
【図６】
2019502980.tif 000008
【国際調査報告】
2019502980.tif 000009
2019502980.tif 000010
2019502980.tif 000011
2019502980.tif 000012