JP4483034B2 - 異種データソース統合アクセス方法 - Google Patents
異種データソース統合アクセス方法 Download PDFInfo
- Publication number
- JP4483034B2 JP4483034B2 JP2000174201A JP2000174201A JP4483034B2 JP 4483034 B2 JP4483034 B2 JP 4483034B2 JP 2000174201 A JP2000174201 A JP 2000174201A JP 2000174201 A JP2000174201 A JP 2000174201A JP 4483034 B2 JP4483034 B2 JP 4483034B2
- Authority
- JP
- Japan
- Prior art keywords
- data
- program
- distributed index
- index
- query
- 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.)
- Expired - Fee Related
Links
- 238000000034 method Methods 0.000 title claims description 46
- 238000012545 processing Methods 0.000 description 62
- 238000007726 management method Methods 0.000 description 43
- 238000004458 analytical method Methods 0.000 description 17
- 238000005457 optimization Methods 0.000 description 5
- 238000004891 communication Methods 0.000 description 4
- 238000006243 chemical reaction Methods 0.000 description 3
- 230000000694 effects Effects 0.000 description 3
- 230000010354 integration Effects 0.000 description 3
- 230000003831 deregulation Effects 0.000 description 2
- 238000011161 development Methods 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 230000008520 organization Effects 0.000 description 2
- 238000005192 partition Methods 0.000 description 2
- 238000000638 solvent extraction Methods 0.000 description 2
- 238000010276 construction Methods 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 239000000284 extract Substances 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 230000002250 progressing effect Effects 0.000 description 1
Images
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/25—Integrating or interfacing systems involving database management systems
- G06F16/256—Integrating or interfacing systems involving database management systems in federated or virtual databases
Landscapes
- Engineering & Computer Science (AREA)
- Databases & Information Systems (AREA)
- Theoretical Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
【発明の属する技術分野】
本発明はコンピュータシステムに関し、特に1つ以上のデータベースを用いてユーザの問合せを処理するデータ処理システムに関する。
【0002】
【従来の技術】
現在、企業の計算機システムには、多数のデータが存在している。これらのデータは、歴史的に企業の発展とともに目的別に追加されてきたものである。現在、業種間の規制緩和が急速に進展しており、これに伴い各企業は新規業務を追加していく傾向が強い。この際、新規業務の導入に伴って、さらに新たなデータが導入される場面が多くなっている。これらのデータは、格納方法、形式などがまちまちである。例えば、リレーショナルデータベース管理システム中のデータベース、ファイルシステム中のフラットファイル、光磁気ディスクアーカイブ、表計算ソフトウェアのデータファイル等である。本明細書では、これらのデータ格納方法や形式のことをデータソースと呼ぶ。
【0003】
一方、規制緩和に伴い、各企業は他企業にない新たなサービスなどにより顧客によりよいサービスを提供し、その結果優良な顧客をより多く獲得しようと試みている。この際、多種のデータソース群に蓄積された過去の企業活動、顧客動向などを分析する必要性が高まり、データウェアハウスやデータマートの構築を行う企業が非常に多くなっている。
【0004】
データウェアハウスやデータマートの構築には、先に述べた多数のデータソースに蓄積されたデータを、ひとつの論理的に統合されたデータベースとすることが必要となる。また、データウェアハウスやデータマートのような分析処理の基盤となるデータベースを構築する以外にも、新規業務を迅速に立ち上げる目的で、従来のデータソース群を論理的に統合することが、企業の競争力を高める目的で必要とされている。論理的に統合したデータソース群を基盤とすることにより、新規業務のための応用プログラム(アプリケーション)構築の高速化を図ることが可能となるためである。
【0005】
データソースがデータベース管理システム(DBMS)の場合、情報基盤の統合をする方法として、データソース群とアプリケーション群の間に、DBMS群への統一的なアクセスを提供する「データベースハブ」のシステムを置く方法がある。データベースハブは、アプリケーションからの問合せ(典型的には、Structured Query Language(SQL)言語で記述された問合せ)を受けつけ、その問合せをDBMS群への問合せへ分解・変換する。そしてデータベースハブは、分解・変換した問合せをDBMS群に発行し、DBMS群から問合せ結果を作成するためのデータを収集し、アプリケーションの問合せに対する最終的な結果を得て、アプリケーションにその結果を返す。
【0006】
データベースハブを用いた情報基盤の統合は、以下の構成を取る。
【0007】
(1)ユーザアプリケーション(UAP):データベースハブによって統合された情報を用いて処理を行うプログラム。
【0008】
(2)データベースハブ:1つ以上のデータソースを統合し、1つのデータベースとしてUAPに提供する。UAPからの問合せが複数のデータソースにまたがる場合、該複数のデータソースのデータを用いて、UAPからの問合せの結果を生成する。
【0009】
(3)データソース:統合対象となるデータを保持する。
【0010】
なお、データベースハブとデータソースは、多くの場合異なる計算機上に存在するが、同一の計算機上に存在しても差し支えない。
【0011】
【発明が解決しようとする課題】
データソースの一部分は、リレーショナルデータベース管理システム(RDBMS)であるが、その他のデータソースも用いられている。例えば、階層型データベース、ファイルシステム中のフラットファイル、光磁気ディスクアーカイブ中のファイル、表計算ソフトウェアのデータファイル等である。
【0012】
これらのデータソースの中には、RDBMSが登場する以前から存在していた基幹業務のデータであったり、データ量の問題でRDBMSに記録することが難しい(またはコストパフォーマンス上最適でない)データがある。しかし、これらのデータが、RDBMS中に格納されているデータに比しても、戦略的重要度の高いデータである場合が少なくない。
【0013】
これらのデータソースは、現在RDBMSへのアクセスに広く用いられているデータベース問合せ言語SQLではアクセスできないデータソースがほとんどである。また、上記のデータベースハブでは、データソースがRDBMSであること、即ちデータソース自身がSQLを効率的に処理できることを前提として、SQLを分解・変換する。
【0014】
このため、データソースがSQLを受けつけない場合、データベースハブからのアクセスでは、結果の指定をするために特定の探索条件(結果レコード群が満たすべき条件)を与える必要があるという制限があった。この特定の探索条件は、データソース中のデータを指定するためのキー情報である。このため、ユーザ(アプリケーション)からみると、自由な検索が困難で、アプリケーション開発時の負担が大きかった。また、この制限のため、定型業務には適用可能でも、非定型問合せが主体となる情報系業務への適用が困難だった。
【0015】
また、データソースにSQLでアクセスできてもアクセス効率が悪い場合、データベースハブを介した情報基盤の統合も、日常業務で現実的に使用することが困難なほど効率が悪くなる恐れがあった。これは、範囲検索等の多件数検索時に、データソースの全件検索に近いアクセスを余儀なくされ、ごく小規模以外の構成では現実的な性能を達成することが困難なためである。
【0016】
本発明は、このような背景から、データソースが、RDBMSであっても、RDBMS以外でも、情報基盤の統合を行うための技術を実現することを目的とする。
【0017】
そこで、本発明が解決しようとする第1の課題は、非RDBMSのデータソースを、RDBMSのデータソースと同じインタフェース(SQL)でアクセスする際、非RDBMSのデータソースをRDBデータソースと同等の高い効率でアクセスすることにある。
【0018】
第1の課題を解決するための手段として、後で述べる通り、非RDBMSのデータソースから、該データソース中に格納されているデータの一部をインデックスとして取り出してデータベースハブに保持する。このインデックスを、従来のRDBMS等で内部的に使用されているインデックスと区別する意味で、「分散インデックス」と称する。
【0019】
非RDBMSのデータソースとしては、戦略的重要度の高いデータを格納しているデータソースを、特に意識する。このようなデータソースの例としては、レガシーアプリケーションプログラム(レガシーAP)と、テープアーカイブや光磁気ディスクアーカイブ等の三次記憶が挙げられる。これらのデータソースでは、上記第1の課題の解決法である分散インデックスの作成に多大な処理時間がかかることが予想される。
【0020】
そこで、本発明が解決しようとする第2の課題は、レガシーAPや三次記憶等、分散インデックス作成に多大な時間を要する恐れのある非RDBMSデータソースにおいても、分散インデックスを効率よく作成することにある。
【0021】
また、分散インデックスは、データソースの一部を取り出してデータベースハブ側に保持するデータであるため、データソース側のデータが更新された場合、適切なタイミングでインデックスも更新する必要がある。
【0022】
そこで、本発明が解決しようとする第3の課題は、データベースハブに対して、一旦作成したインデックスを管理するための方法を、データベースハブの管理者に提供することにある。
【0023】
さらにデータソースによっては、データ量が莫大であるためにRDBMSに保持することが困難なデータも含まれる。このようなデータソースに対しては、通常のRDBMSにおけるインデックスのように全レコードに対する情報を保持することすら困難となる場合が想定される。例えば、光磁気ディスクアーカイブに格納されている数TB(テラバイト)オーダーのデータは、インデックスとして必要なカラムを抽出したとしても数十GBから数百GB(ギガバイト)オーダーのデータになることも考えられる。一方で、このような大規模なデータの利用場面では、すべてのレコードを探索対象とするのではなく、特定の探索対象が設定されている場合が少なくない。そこで、本発明が解決しようとする第4の課題は、分散インデックスの対象レコードを利用場面に応じて絞り込み、分散インデックスが使用するデータ量を削減することである。
【0024】
【課題を解決するための手段】
前記第1の課題を解決するため、本発明のシステムは、非RDBMSのデータソースから、該データソース中に格納されているデータの一部をインデックスとして取り出してデータベースハブに保持する。このインデックスを、従来のRDBMS等で内部的に使用されているインデックスと区別する意味で、「分散インデックス」と称する。分散インデックスは、データソースに対する探索条件を、データソースのレコード指定に対応づけるデータである。
【0025】
データソースには、通常、1つまたは複数のキーとなる情報が存在する。キーは、データソース中の、意味のあるひとかたまりのデータ(レコードと呼ぶ)を指定することができる情報である。多くの場合、キーによって、ただ1つのレコードを一意に指定することができる。また、多くの場合、キーによって指定したレコードに対して高速にアクセスする手段がデータソース側で提供されている。
【0026】
例えば、顧客IDがふられた顧客の情報を管理する顧客管理アプリケーションというデータソースがあったとする。この場合、顧客IDをキーとして、顧客データ中のレコード(顧客ID、氏名、住所、年齢、電話番号、勤務先などの組)を特定することができる。
【0027】
また、取引履歴データが、光磁気ディスクアーカイブに時系列で入っている場合を考える。ひとつひとつの取引情報が、時刻印とともに入っているとすると、時刻印をキーと考えることができる。この例では、時刻印によって完全に一意にひとつの取引情報を指定できるかどうかは、時刻印の与え方によるが、少なくとも時刻印をもちいることによって高速に1つの(またはたまたま同時刻に行われた少数の)取引情報を得ることができる。
【0028】
分散インデックスは、データソースに対する探索条件と、このようなデータソースのキーを対応づけるデータである。より具体的には、分散インデックスは探索条件の対象となっているデータ群と、キーとを組にして格納したデータである。探索条件を分散インデックスに対して適用することによって、探索条件を満たすキー群を得ることができる。このキー群を用いてデータソースにアクセスすることによって、データソースに対する高速なアクセスが実現できる。
【0029】
従来の技術では、例えば、前記顧客管理アプリケーションが、「顧客IDから顧客レコードを得る」というインタフェースのみを提供している場合、UAPからデータベースハブに「年齢が30才以上40才未満の顧客」という探索条件の問合せが発行されると、データベースハブが全顧客IDを顧客管理アプリケーションに与えて全顧客レコードを得て、そこから該探索条件を全顧客レコードに適用して問合せの結果を得ていた。このため、データベースハブはデータソースである顧客管理アプリケーションから大量のレコードを入手する必要があり、問合せの実行時効率が極めて悪かった。
【0030】
本発明の分散インデックスを用いることにより、データベースハブは、まず分散インデックスに対して、「年齢が30才以上40才未満の顧客」という探索条件を適用して、この条件に合致する顧客ID群を得、これらの顧客IDを顧客管理アプリケーションに発行する、という方法で問合せの結果を得ることができる。この場合、「年齢が30才以上40才未満の顧客」に合致する顧客IDのみをに顧客管理アプリケーション対して発行すればよいので、顧客管理アプリケーションの処理量、およびデータベースハブと顧客管理アプリケーションとの通信が大幅に削減される。
【0031】
分散インデックスを作成する際、データベースハブがデータソースの全レコードをアクセスすると、データベースハブとデータソースの間で大量の通信が発生する。この結果、分散インデックス作成時にネットワークおよびデータソースに多大な負荷がかかり、望ましくない。このため、本発明のシステムでは、データソースの存在する計算機に、インデックス作成プログラムを置く。インデックス作成プログラムが、該データソースの分散インデックスを一括して作成し、完成した分散インデックスをデータベースハブに転送する。これにより、分散インデックス作成時のデータベースハブとデータソースとの通信が1回で済み、ネットワーク負荷が大幅に軽減される。また、ネットワーク負荷の軽減にともない、データソースを保持する計算機のネットワーク処理負荷も大幅に軽減される。
【0032】
分散インデックスは、RDBMS等が内部的に保持するインデックスと異なり、データソースに対する更新と連動して更新されない。このため、データベースハブのユーザおよび管理者が、分散インデックスを適切に利用、管理、運用するための手段が必要となる。このため、本発明のシステムでは、ユーザがどの分散インデックスを使用するか(もしくは使用しないか)を指定するインタフェースと、分散インデックスを作成し、最新のデータソースに合致させるインタフェースとを提供する。
【0033】
既に述べた通り、データソースによっては、データ量が莫大であるためにRDBMSに保持することが困難なデータも含まれる。このようなデータソースに対しては、通常のRDBMSにおけるインデックスのように全レコードに対する情報を保持することすら困難となる場合が想定される。例えば、光磁気ディスクアーカイブに格納されている数TB(テラバイト)オーダーのデータは、インデックスとして必要なカラムを抽出したとしても数十GBから数百GB(ギガバイト)オーダーのデータになることも考えられる。このため本発明のシステムでは、分散インデックスとして、対象を全レコードではなく一部のレコードのみのキーを格納した分散インデックスを用いる。一部のレコードの選択方法としては、特定の探索条件を用いる方法、ランダムに選択によって選択を行う方法などを提供する。
【0034】
これらの各手段によって、本発明のシステムはRDBMSのデータソースのみならず、レガシーAPや三次記憶等さまざまなデータソース中のデータを、1つのデータベースに格納されているかのようにユーザに提供し、かつ高い問合せ実行性能を実現することを可能にすることができる。
【0035】
【発明の実施の形態】
本発明の実施の一形態を、図面を参照しながら説明する。
【0036】
[1]全体構成
図1を用いて、本発明の実施の一形態(実施例)の全体構成を説明する。
【0037】
図1は、第1の実施例が好適に用いられるコンピュータシステムである。第1の実施例の全体は、1つ以上のコンピュータ(データ処理システム100、1つ以上のクライアントコンピュータ101、101’、…、管理用コンピュータ102、1つ以上のデータソース計算機105)が、クライアント側ネットワーク103およびサーバ側ネットワーク104で相互に接続されたコンピュータシステムである。
【0038】
クライアント側ネットワーク103とサーバ側ネットワーク104はいずれも、ある団体(企業や学校や類似の団体)の全体や位置部門でよく使用されるLANでもよく、また地理的に分散した複数の地点を結合するWANの一部または全部でもよい。またこれらのネットワークは、計算機間結合網や並列計算機内部のプロセッサ要素間の結合網でもよい。また、クライアント側ネットワーク103とサーバ側ネットワーク104が同一のネットワークであっても差し支えない。
【0039】
データ処理システム100、クライアントコンピュータ101、101’,…,管理用コンピュータ102、データソース計算機105はいずれも、いわゆるパーソナル・コンピュータ、ワークステーション、並列計算機、大型計算機、小型携帯型コンピュータ等、任意のコンピュータでよい。
【0040】
クライアントコンピュータ101,101’,…では、ユーザの処理を行うプログラムであるアプリケーション120、120’,…が動作する。アプリケーション120は、必要に応じてデータベースに対する参照または更新を、問合せを発行する。本実施例では、問合せ言語SQLで記述された問合せとする。
【0041】
データソース計算機105は、データソース中のデータを保持し、他のプログラムのアクセスに応じてデータに対する参照または更新を行う計算機である。データソース中のデータに対する参照および更新の処理は、データソース入出力プログラム122が行う。データソース入出力プログラム122は、いわゆるレガシーAPでよい。データソース計算機105は多くの場合、その管理対象のデータを二次記憶装置106上に保持する。データソース計算機105、二次記憶装置106、データソース入出力プログラム122、およびその中に格納されているデータを総称して、データソース107と称する。なお、二次記憶装置106は、光磁気ディスクアーカイブ等、一般には三次記憶と称される記憶媒体でも差し支えない。
【0042】
データソースのデータは、1つ以上の、意味のある塊をなしているものとする。この塊のひとつひとつを、RDBMSとの類似でレコードとよぶ。例えば、取引履歴というデータソースにおいて、1つの取引をレコードとみなすことができる。レコードがさらに複数のパーツからなる時、探索条件や出力項目として指定可能なパーツを、RDBMSとの類似でカラムと呼ぶ。例えば、1つの取引履歴レコードの中に「取引時刻」、「取引品名」などがある場合、これらをカラムとみなすことができる。例えば、データソース入出力プログラム122がいわゆるレガシーAPであっても、たとえば、「顧客ID」と、「住所」、「氏名」、「年齢」、「職業」とを関連づけて保持している場合、「顧客ID、住所、氏名、年齢、職業」を1つのレコード、「顧客ID」、「住所」、「氏名」、「年齢」、「職業」のそれぞれをカラムと考えて、なんら差し支えない。
【0043】
データ処理システム100は、クライアントコンピュータ101、101’、…の発行する第1の問合せを受け取り、必要に応じてデータソース107への1つ以上の第2の問合せを作成して発行し、第1の問合せが指定した参照または更新を行い、結果のデータを第1の問合せの発行元に返す。即ち、データ処理システム100は、データソース107の保持するデータベース群への統一的なアクセスを実現し、クライアントコンピュータ101,101’,…へ統合されたデータベースを提供するデータベースハブである。
【0044】
管理用コンピュータ102は、管理アプリケーション121を実行する。管理アプリケーション121は、データ処理システム100の管理を行うためのプログラムであり、典型的には、データ処理システム100または図1のシステム全体の管理者が利用する。
【0045】
入出力処理部110、問合せ解析部111、分散インデックス適用部112、問合せ実行部113、分散インデックス管理部114、二次記憶装置115は、データ処理システム100を構成する構成要素である。これらの構成要素については、ここでは概略を説明するのに留め、動作の詳細については、あとで述べる。
【0046】
入出力処理部110は、クライアントコンピュータ101,101’,…からの問合せ要求、管理用コンピュータ102からの管理要求を受けつけるとともに、これらの要求に対する返答を行う。
【0047】
問合せ解析部111は、入出力処理部110が受けつけた問合せ要求の字句解析、構文解析、意味解析、を行い、必要に応じて問合せ条件の標準型変換を行い、問合せから構文解析木(パーズツリー)を生成する。
【0048】
分散インデックス適用部112は、問合せ解析部111が作成したパーズツリーを利用して、入力された問合せを、分散インデックスを用いるように変形する。この際、どの分散インデックスを利用するかを決定する必要があるが、この決定は分散インデックス管理部114が保持する個々の分散インデックスに関する管理情報を用いて行う。そして、問合せの結果を得るための一連の操作の手順(実行プラン)を生成する。リレーショナルデータベースの場合、一連の操作とは、選択処理、射影処理、ジョイン処理、グルーピング処理、ソート処理などである。実行プランは、これらの操作を、どのデータソース107のどのデータに対し、どの順番で適用するかを記述したデータ構造である。
【0049】
問合せ実行部113は、分散インデックス適用部112が生成した実行プランを実行する。問合せ実行部113はデータソース107への問合せを発行することにより、問合せを発行して前記一連の操作の一部または全部をデータソース107に依頼する場合もあるし、データソース107から取り寄せたデータに対し、自ら前記一連の操作の一部または全部を実行する場合もあってよい。
【0050】
分散インデックス管理部114は、入出力処理部110が受けつけた管理要求を解釈し、管理要求に含まれる分散インデックスの操作を行い、必要に応じて二次記憶装置115に保存する。また、分散インデックスに関する情報を保持し、分散インデックス適用部112がどの分散インデックスを適用するのが適当かを決定するのを支援する。
【0051】
以上が実施例の全体構成である。
【0052】
[2]データ構造
図2を用いて、分散インデックスの実現に用いるデータ構造について説明する。
【0053】
主に2種類のデータ構造を用いる。
【0054】
分散インデックス情報210は、データ処理システム100が保持する分散インデックスに関する情報を保持する。図2に示した分散インデックス情報210は、1つの分散インデックスに対して保持する情報であり、データ処理システム100中に1つ以上存在する。
【0055】
インデックスID 211は、分散インデックスの名前である。インデックスID 211によって、各分散インデックスを一意に識別する。
【0056】
対象データソース212は、該分散インデックスのもとになったデータソースである。後に述べるデータソース情報220のデータソース名221と対応する。
【0057】
インデックスカラム213は、該分散インデックスが保持するカラム群である。分散インデックス適用部112は、このインデックスカラム213を用いて、ある探索条件を分散インデックスを用いて評価可能か否かを判定する。
【0058】
キーカラム214は、該分散インデックスの対象データソースのキーである。ある探索条件を該分散インデックスを用いて評価した場合に、データソースへの問合せにおけるレコードの指定に用いるカラム群が何かを示す。キーカラム214のカラム集合は、インデックスカラム213のカラム集合に包含される。
【0059】
インデックス格納テーブル214は、二次記憶装置115中に存在する該分散インデックスの実体の名前である。問合せ実行部113が分散インデックスを用いて探索条件の評価を行う場合には、インデックス格納テーブル214にアクセスする。
【0060】
最終更新日付215は、該分散インデックスが最後に更新(データソースから作成)された時刻である。
【0061】
データソース情報220は、データソース107に関する情報を保持する。図2に示したデータソース情報220は、1つのデータソースに対して保持する情報であり、データ処理システム100中に1つ以上存在する。
【0062】
データソース名221は、1つのデータソースを一意に識別する名前である。
【0063】
主キー222は、該データソースの主キーを保持する。主キーとは、該データソースにアクセス可能なカラム群を指す。データソースに対し、主キーを引数として指定したレコード参照(ここではgetRecord(主キー)と呼ぶ)が可能である。主キーは、物理的な格納順に対応したカラム群である場合が多い。主キー情報は、分散インデックスを自動的に作成する際のヒント情報として用いる。
【0064】
分割223は、該データソースの分割方法(パーティショニング)の情報を保持する。大規模なデータソースの場合、物理的に複数の二次記憶装置に分割してデータを格納することにより、二次記憶装置の並列度を増したり、必要な容量を確保する。これがパーティショニングである。データソースの分割方法を活用する順序でアクセスを行うことにより、実行時間が大幅に改善されることが知られている。分割方法の情報も、分散インデックスを自動的に作成する際のヒント情報として用いる。
【0065】
内蔵インデックス224は、該データソース内で、該データソースに定義しているインデックス群に関する情報を保持する。該データソース内部にインデックスがある場合、インデックスを利用した順序でアクセスを行うことにより、実行時間が大幅に改善されることが知られている。内蔵インデックスに関する情報も、分散インデックスを自動的に作成する際のヒント情報として用いる。
【0066】
[3]問合せに対する分散インデックスの適用
図1と図3とを用いて、分散インデックス適用部112が問合せに対して分散インデックスを適用する処理の流れを説明する。
【0067】
アプリケーション120が発行した第1の問合せは、クライアント側ネットワーク103を経由してデータ処理システム100の入出力処理部110に到達する(150)。入出力処理部110は、入力がアプリケーションからの問合せ要求であるか、管理用アプリケーションからの管理要求であるかを判定し、その結果に応じて、要求を問合せ解析部111へ送るか(151)分散インデックス管理部114へ送る(160)。
【0068】
問合せ解析部111が第1の問合せを受け取ると、第1の問合せの字句解析、構文解析、意味解析を行う。この一連の処理により、第1の問合せから第1のパーズツリーを生成する。なお、字句解析、構文解析、意味解析の動作については、コンパイラ、データベース管理システムなど多くの分野で用いられている技術であるため、ここではこれ以上詳細には述べない。
【0069】
問合せ解析部111は、第1のパーズツリーを分散インデックス適用部112へ送る(152)。
【0070】
分散インデックス適用部112では、第1のパーズツリーを検査し、分散インデックスが適用可能かどうかを判定する。図3の処理である。
【0071】
図3で示す一連の処理で問合せの探索条件を処理する。探索条件とは、データソースの一群のレコードを絞りこむための指定である。SQL言語では、WHERE句やHAVING句などがこれにあたる。
【0072】
ステップ301で、探索条件をCNF変換する。CNF(Conjunctive Normal Form)とは、探索条件の要素がまずORで連接され、それらの連接がANDで連接された形式である。例えば、「(c1=10 and c2=20)or c3=30」の CNF変換の結果は、「(c1=10 or c3=30)and(c2=20 or c3=30)」となる。すべての結果レコードが、CNF変換後の探索条件の各OR連接条件を満たすという性質がある(上記の例では、「c1=10 or c3=30」と「c2=20 or
c3=30」がOR連接条件)。
【0073】
ステップ302で、探索条件について、データ処理システム100が保持する各分散インデックスを検査する。すべての分散インデックスを検査したら(判定Y)、分散インデックス適用の処理を終了する。
【0074】
ステップ303で、分散インデックスを1つ取り出す。ここで、該分散インデックスをXと呼ぶ。
【0075】
ステップ304で、Xに対応する分散インデックス情報210の対象データソース212を参照((153))してXの対象データソースを得て、探索条件を検査することにより、Xの対象データソースが探索条件に含まれるか否かを判定する。含まれれば(判定Y)ステップ305に制御を移し、含まれなければ(判定N)、ステップ302に制御を移す。
【0076】
ステップ305で、探索条件中に含まれるXの対象データソースから、対象データソースを1つ選択する。選択したデータソースをYと呼ぶ。このステップでは、1つの問合せ中で1つのデータソースが複数回参照される可能性を考慮している。例えば、「SELECT×FROM T1 A、T1 B WHERE A.C1=B.C2」という問合せでは、T1というデータソースが2回、AとBという名前で登場している。
【0077】
ステップ306で、探索条件中の各OR連接条件に着目した場合に、該OR連接条件中で使用するデータソースYのカラム集合が分散インデックスXのカラム集合によって包含されているか否かを検査する。包含している場合(判定Y)、ステップ307に制御を移し、包含していなければれば(判定N)、ステップ305に制御を移す。分散インデックスXのカラム集合は、Xのインデックスカラム213に格納されている。
【0078】
ステップ307では、分散インデックスXのカラム集合によって包含されているOR連接条件を、Xを用いた探索条件に書換える。具体的には、もともとT1にかかっていた探索条件を分散インデックスXに対して適用してキー(X.key)を得、該キー集合を用いてT1にアクセスし、結果レコードを得る、という問合せに書換える。例えば、Xのインデックスカラム213がT1.C1を含む場合、「SELECT×FROM T1,T2 WHERE T1.C1=10」を、「SELECT×FROM T1,T2 WHERE T1.key in(SELECT X.key FROM X WHERE X.C1=10)」とする。
【0079】
ステップ308では、すべてのYを検査したか否かによって、ステップ305またはステップ302に制御を移し、繰り返しを続ける。
【0080】
以上の一連の処理により、入力された問合せを、分散インデックスを利用した問合せに書換えることができる。
【0081】
図1に戻り、分散インデックス適用部112の残りの部分の処理を説明する。分散インデックス適用部112ではさらに、問合せ解析部111から得た第1のパーズツリーを用いて、問合せ最適化を行い、第1の問合せの実行プランを作成する。なお、場合によっては、第1の問合せ動作指示以外に追加の問合せ動作指示を得る必要がある場合がある。例えば、コストベース最適化の中間段階で表のレコード数が判明し、このレコード数をもちいて問合せ分類定義を検索し、新たな問合せ動作指定を得る場合である。この場合の問合せ動作指定の取得方法は、前記問合せ照合処理と同様であるため、特に改めて説明はしない。
【0082】
第1の問合せの実行プランは、コストベース最適化により作成するが、コストベース最適化は文献1等ですでに広く知られているため、コストベース最適化の詳細についてはここでは述べない。
【0083】
分散インデックス適用部112が生成した実行プラン(第1の実行プラン)の例をひとつ挙げる。以下のリスト表現で表されるツリーである:(database―hub―join [left.c1=right.c2 and left.c3<10,output left.c1,right.c2,left.c1+left.c3](join at DBMS1 [left.c1<10 and left.c1=right.c4,output left.c1,left.c3](selection at DBMS1 CustomerTable [1990<year and year<1999,output c1,c3])(selection at DBMS1 ProductTable [1000<price and price<2000,output c4]))(selection at DBMS2 OrderTable [1990<year and year<1999,outputc2]))この実行プランは、『(1)DBMS1でCustomerTableに対し、探索条件「1990<year and year<1999」の選択処理を行い、射影処理によってカラムc1とc3を出力し、(2)DBMS1でProductTableに対し、探索条件「1000<price and price<2000」の選択処理を行い、射影処理によってカラムc4を出力し、(3)DBMS2でOrderTableに対し探索条件「1990<year and year<1999」の選択処理を行い、射影処理によってカラムc2を出力し、(4)DBMS1でジョイン条件「left.c1<10 and left.c1=right.c4」((1)の中間結果がleft、(2)の中間結果がrightとする)でジョインを行って、射影処理によってカラムc1、c3を出力し、(5)データ処理システム100でジョイン条件「left.c1=right.c2 and left.c3<10」((4)の中間結果がleft、(5)の中間結果がrightとする)のジョインを行い、射影処理によりleft.c1,right.c2,left.c1+left.c3を出力する』という一連の処理を表現している。
【0084】
分散インデックス適用部112は、生成した第1の実行プランを問合せ実行部113に送る(154)。
【0085】
問合せ実行部113は、分散インデックス適用部112から得た第1の実行プランを用いて、第1の問合せの実行を行う。問合せ実行部113は、上述の例の第1の実行プランを、ボトムアップに、即ち上記(1)、(2)、(3)、(4)、(5)の順に処理していく(正確には、(1)、(2)、(3)は並列に実行することが可能である)。問合せ実行部113が最終的に実行プランに定められたすべてのステップを実行し、第1の問合せに対する最終的な結果が得られると、該結果は第1の問合せを発行したアプリケーション120へ入出力処理部110を経て返される(155、155’、156、156’および157)。
【0086】
以上が、分散インデックスの適用を含む問合せ処理の流れである。
【0087】
[4]分散インデックス利用を含む問合せの実行
分散インデックスを利用する問合せは、基本的には上記の問合せ実行部113の処理で述べた通りであるが、1つの分散インデックスが探索条件中に複数回登場する場合には、より効率的な実行方法を取ることができる。この手順を図4を用いて説明する。
【0088】
ステップ401で、1つの分散インデックスを用いた複数のOR連接条件(cond1,cond2,...,condNとする)を得る。これらcond1,cond2,...,condNを実行し、それぞれ結果を得る。この結果を、K1,K2,...,Knとする。K1,K2,...,Knはそれぞれ、該分散インデックスの対象データソースのキーの集まりである。
【0089】
ステップ402で、K1,K2,...,Knの共通部分Kを得る。ただし、この共通部分は、SQLにおける”INTERSECT ALL”である。
【0090】
ステップ403で、Kに含まれるキーのそれぞれについて、該分散インデックスの対象データソースに対し、getRecord(key)を発行する。ここで、getRecord(key)は、対象データソース中でキー値がkeyのレコードを参照する、データソース107への呼び出しである。この一連の呼び出しで得たレコード群を結果表とする。
【0091】
ステップ404で、結果表に対して、まだ処理していない探索条件を実行する。
【0092】
この一連の処理により、複数のOR連接条件にまたがった絞り込みを一括して分散インデックスで処理し、しかるのちにデータソースにアクセスする、というアクセス方法が実現できる。このアクセスは、各OR連接条件を個々に処理する方法に比べ、データソースへのアクセス回数を大幅に削減できる可能性がある。
【0093】
[5]分散インデックスの作成
図5と図6を用いて、分散インデックス作成の処理の手順を説明する。
【0094】
ここで説明する処理は、分散インデックス作成の3種のインタフェースである。これらのインタフェースは、管理用アプリケーションが用いるインタフェースであり、入出力処理部110が管理用アプリケーションからの要求を受付け、要求を分散インデックス管理部114へ送った場合(160)に起動される。なお、本実施例ではアプリケーション120と管理アプリケーション121を区別しているが、これらを、双方の機能をあわせ持ったアプリケーションプログラムとして実現しても差し支えない。
【0095】
分散インデックス作成の第1のインタフェースは、createDistributedIndex(対象データソース、キーカラム、インデックスカラム)という形式である。第2のインタフェースは、キーカラムを省略した、createDistributedIndex(対象データソース・インデックスカラム)という形式である。第3の形式は、キーカラム、インデックスカラムともに省略したcreateDistributedIndex(対象データソース,インデックスタイプ)という形式である。インデックスタイプは、「主キー優先」、「分割優先」、「内蔵インデックス優先(内蔵インデックス名)」の3種がある。これら3種のインタフェースは、完全に管理者が指定した分散インデックスを生成する方法から、データ処理システム100が半自動で分散インデックスを生成する方法までをカバーする。
【0096】
ステップ501からステップ506で、3種のインタフェースをサポートする。まずステップ501で、キーカラムが指定されたか否かによって、ステップ502またはステップ503に分岐する。
【0097】
ステップ502では、第1のインタフェースに従って、指定されたキーカラムを用いて分散インデックスの作成を進める。
【0098】
ステップ503では、すでに参照可能なデータソース情報220がデータ処理システム100中に存在しているか否かによって、ステップ504またはステップ505に分岐する。データソース情報220が存在している場合、504でデータソース情報220の主キー222を新規に生成する分散インデックスのキーカラムとする。
【0099】
また、データソース情報220が存在していない場合、分散インデックス管理部114が該データソースに対しアクセスを行い、キーカラムの情報(および分割およびインデックスが存在していればこれらの情報)を取得する。取得できない場合はエラーとなる。そして、主キーをキーカラムに設定する。
【0100】
506では、インデックスカラムが決定していない場合、インデックスカラムを決定する。インデックスカラムの決定を要するのは、第3のインタフェースであるので、「主キー優先」、「分割優先」、「内蔵インデックス優先(内蔵インデックス名)」のいずれかによって、データソース情報220の主キー222、分割223、内蔵インデックス224のいずれかを参照し、分散インデックスのインデックスカラムを決定する。決定したキーカラム、インデックスカラムを、分散インデックス作成対象のデータソースに存在する分散インデックス作成部123に送る(161)。なお、主キー優先の場合、データソースの主キーのみで構成される分散インデックスが生成される。
【0101】
507では、分散インデックス作成部123が作成した分散インデックスを二次記憶装置115に格納し、508で、分散インデックス情報210を更新(なければ作成)を行う。特に、最終更新日付215を現在時刻に設定する。
【0102】
一方、分散インデックス作成部123では、以下の処理を行う。601で、506で送られた分散インデックス管理部114からの要求を受取り、インデックス作成対象のデータソースの各レコードに対し、getRecord()を発行する(162)。得られたレコードのそれぞれから、インデックスカラムとキーカラムのユニオンとなるカラム集合を得て、結果の分散インデックスとして一時記憶領域に蓄積していく。そして、602で、できあがった分散インデックスを分散インデックス管理部114に送る(163)。
【0103】
以上が分散インデックス作成のインタフェースおよび処理手順である。
【0104】
[6]部分的な分散インデックスの作成
上述の手順では、分散インデックス作成部123は分散インデックス作成対象のデータソースの全レコードに対するインデックスを作成する。しかし、常に全レコードを対象にした分散インデックスを作成していると、データソースのデータ量が莫大である場合、分散インデックスのデータ量も大量となり、分散インデックスを保持するためのコスト、管理のためのコストが非常に大きくなる恐れがある場合がある。
【0105】
このため本発明のシステムでは、分散インデックス作成のインタフェースのオプションとして、「分散インデックス作成条件」を分散インデックス作成時に用いる探索条件として管理アプリケーション121が指定できる。
【0106】
分散インデックス作成時に、分散インデックス管理部114が分散インデックス作成条件を受取ると、前記506で、該分散インデックス作成条件をキーカラム、インデックスカラムとともに、分散インデックス作成対象のデータソースの分散インデックス作成部123に送る(161)。
【0107】
該分散インデックス作成条件を受取った分散インデックス作成部123は、前記601で各レコードに対し、getRecord()を発行する(162)。得られたレコードのそれぞれに対し、該分散インデックス作成条件に合致するレコードのみを抽出し、インデックスカラムとキーカラムのユニオンとなるカラム集合を得て,結果の分散インデックスとして一時記憶領域に蓄積していく。この処理によって、結果としてできあがる分散インデックスのデータ量を、管理アプリケーション121の指定した分散インデックス作成条件にしたがって制御することが可能となる。
【0108】
分散インデックス作成条件としては、例えば「住所=’東京’」のような指定のほか、「全体のX%を選択」という条件を許す。「全体のX%を選択」が指定された場合、分散インデックス作成部123はgetRecord()で得られたレコード群のうち、全体のX%を乱数発生により選択する。この方法により、データソースの全体傾向を統計的に分析するアプリケーション等、すべてのレコードに対するインデックスが必ずしも必要でない場合に好適な分散インデックスを作成することが可能となる。
【0109】
[7]分散インデックスの選択的な使用
分散インデックスはデータソース107への更新とは独立にデータ処理システム100が保持されるので、分散インデックスの内容とデータソース107中のデータとが一時的に不一致を生じる場合がある。このため、アプリケーションによっては、分散インデックスを選択的に利用して、最新データをアクセスする必要が生じる場合がある。また、前述のように「全体のX%を選択」という指定で作成した分散インデックスは、全体傾向を統計的に分析する等、特定のアプリケーションに特に合致するが、他のアプリケーションには不適な場合もある。
【0110】
このため本発明のシステムでは、分散インデックスを選択的に使用する方法をアプリケーション120に提供する。
【0111】
分散インデックスを探索的に使用する第1の方法として、分散インデックスの最終更新時刻等に関する探索条件を指定する方法を提供する。この方法では、問合せ発行前または問合せ発行時に、分散インデックスに対する探索条件を与えることによって、分散インデックスを選択する。例えば、「最終更新時刻が1週間以内である分散インデックスを使用許可」、「最終更新時刻が1週間以内で、対象データソースが取引履歴である分散インデックスを使用」等である。この指定は、前記ステップ303で、分散インデックスを選択する際に分散インデックス適用部112が評価し、条件に合致する分散インデックスのみを前記ステップ304以降で処理する。
【0112】
分散インデックスを選択的に使用する第2の方法として、分散インデックスの名称を明示的に指定する方法である。「インデックスID 211がIX11である分散インデックスの使用許可」等である。この指定も、前記ステップ303で、分散インデックスを選択する際に分散インデックス適用部112が評価し、条件に合致する分散インデックスのみを前記ステップ304以降で処理する。
【0113】
以上の処理により、各アプリケーションが分散インデックスを選択的に利用することが可能となる。
【0114】
【発明の効果】
(1)データソース107に対する分散インデックスをデータ処理システム100にあらかじめ生成、分散インデックス適用部112が分散インデックスを用いた問合せの変形と分解を行うことにより、レガシーAPや三次記憶などのデータソースに対する高速なアクセスが実現できる。
【0115】
(2)分散インデックス作成部123をデータソース107に配置することにより、分散インデックス作成に際し、大量通信の発生を避ける。これにより、ネットワーク負荷が大幅に軽減される。また、ネットワーク負荷の軽減にともない、データソースを保持する計算機のネットワーク処理負荷も大幅に軽減される。
【0116】
(3)インデックス更新インタフェースをデータ処理システム100が提供し、インデックス更新要求を受け取ったら分散インデックス作成部123が分散インデックスを作成する。このインタフェースにより、適切なタイミングで分散インデックスの更新が実現される。また、分散インデックスを使うか使わないか、どれを使うかを指定するインタフェースを備えることにより、適切な分散インデックスを選択的に利用することが可能となる。
【0117】
(4)分散インデックスとして、分散インデックス適用部112がデータソースの一部のレコードを対象とした分散インデックスを用いる。これにより、分散インデックスのデータ量を削減、大量のデータを保持するデータソースに対する分散インデックス作成が可能となる。
【0118】
以上4つの効果により、企業内、企業間の複数のDBMSを統合する情報基盤の統合に際し、リレーショナルデータベース管理システムに格納されたデータのみならず、レガシーAPや三次記憶等、問合せを効率的に実行できないデータソースに格納されたデータの統合が可能となり、これらデータソースに対する高速な問合せが実現できる。
【図面の簡単な説明】
【図1】実施例の全体構成を示すブロック図。
【図2】データ構造の構成図。
【図3】分散インデックス適用の処理を示すフローチャート。
【図4】分散インデックス利用を含む問合せ実行の処理を示すフローチャート。
【図5】分散インデックスの作成における分散インデックス管理部側の処理を示すフローチャート。
【図6】分散インデックスの作成におけるインデックス作成プログラム側の処理を示すフローチャート。
【符号の説明】
100:データ処理システム
101,101’,…:クライアントコンピュータ
102:管理用コンピュータ
103:クライアント側ネットワーク
104:サーバ側ネットワーク
105:データソース計算機
106:二次記憶装置
107:データソース
110:入出力処理部
111:問合せ解析部
112:分散インデックス適用部
113:問合せ実行部
114:分散インデックス管理部
115:二次記憶装置
120,120’,…:アプリケーション
121:管理アプリケーション
122:データソース入出力プログラム
123:分散インデックス作成部。
Claims (3)
- 第1のコンピュータと第2のコンピュータがネットワークで結合され、前記第2のコンピュータの持つ二次記憶には、ぞれぞれが複数のカラムからなる複数のレコードで構成された第1のデータが保持され、該第1のデータに対してアプリケーションプログラムから発行される問合せを受け付ける第1のプログラムが前記第1のコンピュータに準備され、前記第1のデータの入出力を行う第2のプログラムが前記第2のコンピュータに準備されたコンピュータシステムにおけるデータアクセス方法であって、
前記第1のプログラムで受け付ける前記問合せは、前記第1のデータに含まれる1つもしくは複数のカラムに関する探索条件を含み、
前記第1のプログラムは、
前記問合せの受付けに先立ち、前記第1のデータから、該第1のデータの前記複数のカラムの一部であり前記探索条件の対象となるカラムであるインデックスカラムと、該第1のデータの前記複数のカラムの一部であり前記第2のプログラムにアクセスするための引数となるカラムであるキーカラムとを組にした分散インデックスを抽出して保持し、
前記問合せを受け付けると、該問合せ中の前記探索条件を変形し、前記分散インデックスから前記探索条件に合致するレコード群のキーカラムを取得し、
該キーカラムを用いて前記第2のプログラム経由で前記第1のデータにアクセスすることにより、前記探索条件に合致するレコードを得て前記問合せの結果として前記アプリケーションプログラムに返送することを特徴とする請求項1記載のデータアクセス方法。 - 第1のコンピュータと第2のコンピュータがネットワークで結合され、前記第2のコンピュータの持つ二次記憶には、ぞれぞれが複数のカラムからなる複数のレコードで構成された第1のデータが保持され、前記第1のデータに対してアプリケーションプログラムから発行される問合せを受け付ける第1のプログラムが前記第1のコンピュータに準備され、前記第1のデータの入出力を行う第2のプログラムが前記第2のコンピュータに準備されたコンピュータシステムにおけるデータアクセス方法であって、
前記第1のプログラムで受け付ける前記問合せは、前記第1のデータに含まれる1つもしくは複数のカラムに関する探索条件を含み、
前記第1のプログラムは、前記問合せの受付けに先立ち、前記第1のデータから、該第1のデータの前記複数のカラムの一部であり前記探索条件の対象となるカラムであるインデックスカラムと、該第1のデータの前記複数のカラムの一部であり前記第2のプログラムにアクセスするための引数となるカラムであるキーカラムとの対応関係を示す分散インデックスを複数抽出して保持し、
前記アプリケーションプログラムは、前記問合せを、前記複数の分散インデックスのうちの該問合せで使用を許可する分散インデックスを指定する情報とともに発行し、
前記第1のプログラムは、
前記問合せを受け付けると、該問合せ中の前記探索条件を変形し、許可された分散インデックスから前記探索条件に合致するレコード群のキーカラムを取得し、
該キーカラムを用いて前記第2のプログラム経由で前記第1のデータにアクセスすることにより、前記第1の探索条件に合致するレコードを得て前記問い合わせの結果として前記アプリケーションプログラムに返答することを特徴とするデータアクセス方法。 - 第1のコンピュータと第2のコンピュータがネットワークで結合され、前記第2のコンピュータの持つ二次記憶には、ぞれぞれが複数のカラムからなる複数のレコードで構成された第1のデータが保持され、前記第1のデータに対してアプリケーションプログラムから発行される問合せを受け付ける第1のプログラムが前記第1のコンピュータに準備され、前記第1のデータの入出力を行う第2のプログラムが前記第2のコンピュータに準備され、前記第1のプログラムは、前記問合せの受付けに先立ち、前記第1のデータから該第1のデータの前記複数のカラムの一部であり前記問合せの探索条件の対象となるカラムであるインデックスカラムと、該第1のデータの前記複数のカラムの一部であり前記第2のプログラムにアクセスするための引数となるカラムであるキーカラムとを組にした分散インデックスを前記第1のコンピュータの二次記憶に格納するコンピュータシステムにおける前記分散インデックスの作成方法であって、
前記第2のコンピュータに準備された分散インデクス作成プログラムが、前記第1のプログラムから前記分散インデックスの作成要求を受け、
前記分散インデクス作成プログラムは、前記第1のデータから作成対象の分散インデックスのインデックスカラムとキーカラムを取り出し、取り出した結果を前記第1のプログラムに返答することを特徴とする分散インデックスの作成方法。
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2000174201A JP4483034B2 (ja) | 2000-06-06 | 2000-06-06 | 異種データソース統合アクセス方法 |
US09/791,808 US20020049747A1 (en) | 2000-06-06 | 2001-02-26 | Method for integrating and accessing of heterogeneous data sources |
US11/010,266 US20050091210A1 (en) | 2000-06-06 | 2004-12-14 | Method for integrating and accessing of heterogeneous data sources |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2000174201A JP4483034B2 (ja) | 2000-06-06 | 2000-06-06 | 異種データソース統合アクセス方法 |
Publications (3)
Publication Number | Publication Date |
---|---|
JP2001350656A JP2001350656A (ja) | 2001-12-21 |
JP2001350656A5 JP2001350656A5 (ja) | 2007-03-22 |
JP4483034B2 true JP4483034B2 (ja) | 2010-06-16 |
Family
ID=18676280
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2000174201A Expired - Fee Related JP4483034B2 (ja) | 2000-06-06 | 2000-06-06 | 異種データソース統合アクセス方法 |
Country Status (2)
Country | Link |
---|---|
US (2) | US20020049747A1 (ja) |
JP (1) | JP4483034B2 (ja) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN108415964A (zh) * | 2018-02-07 | 2018-08-17 | 平安科技(深圳)有限公司 | 数据表查询方法、装置、终端设备及存储介质 |
Families Citing this family (19)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN100478943C (zh) * | 2002-05-31 | 2009-04-15 | 国际商业机器公司 | 访问不同类型后端数据存储器的***和方法 |
US7668864B2 (en) * | 2003-01-17 | 2010-02-23 | International Business Machines Corporation | Digital library system with customizable workflow |
US9015197B2 (en) * | 2006-08-07 | 2015-04-21 | Oracle International Corporation | Dynamic repartitioning for changing a number of nodes or partitions in a distributed search system |
US7725470B2 (en) * | 2006-08-07 | 2010-05-25 | Bea Systems, Inc. | Distributed query search using partition nodes |
US20080033910A1 (en) * | 2006-08-07 | 2008-02-07 | Bea Systems, Inc. | Dynamic checkpointing for distributed search |
US20080033958A1 (en) * | 2006-08-07 | 2008-02-07 | Bea Systems, Inc. | Distributed search system with security |
US20080033925A1 (en) * | 2006-08-07 | 2008-02-07 | Bea Systems, Inc. | Distributed search analysis |
US20080033943A1 (en) * | 2006-08-07 | 2008-02-07 | Bea Systems, Inc. | Distributed index search |
US20080033964A1 (en) * | 2006-08-07 | 2008-02-07 | Bea Systems, Inc. | Failure recovery for distributed search |
JP2009223512A (ja) * | 2008-03-14 | 2009-10-01 | Toshiba Corp | 情報処理システム及びその制御方法 |
CN102597969A (zh) * | 2009-06-25 | 2012-07-18 | 西山修平 | 带属性的键值存储的数据库管理装置及其键值存储结构的高速缓存装置 |
US9665620B2 (en) | 2010-01-15 | 2017-05-30 | Ab Initio Technology Llc | Managing data queries |
CN102129425B (zh) * | 2010-01-20 | 2016-08-03 | 阿里巴巴集团控股有限公司 | 数据仓库中大对象集合表的访问方法及装置 |
CN102737061B (zh) * | 2011-04-14 | 2015-06-03 | 中兴通讯股份有限公司 | 分布式话单查询管理***及方法 |
US20140181438A1 (en) * | 2012-12-21 | 2014-06-26 | Commvault Systems, Inc. | Filtered reference copy of secondary storage data in a data storage system |
US9665662B1 (en) | 2013-06-13 | 2017-05-30 | DataRPM Corporation | Methods and system for providing real-time business intelligence using natural language queries |
US10417281B2 (en) | 2015-02-18 | 2019-09-17 | Ab Initio Technology Llc | Querying a data source on a network |
CN105302896B (zh) * | 2015-10-22 | 2018-12-25 | 江苏国泰新点软件有限公司 | 一种电子评标***中的数据存储方法和装置 |
US11093223B2 (en) | 2019-07-18 | 2021-08-17 | Ab Initio Technology Llc | Automatically converting a program written in a procedural programming language into a dataflow graph and related systems and methods |
Family Cites Families (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5555409A (en) * | 1990-12-04 | 1996-09-10 | Applied Technical Sysytem, Inc. | Data management systems and methods including creation of composite views of data |
US5379419A (en) * | 1990-12-07 | 1995-01-03 | Digital Equipment Corporation | Methods and apparatus for accesssing non-relational data files using relational queries |
US5737732A (en) * | 1992-07-06 | 1998-04-07 | 1St Desk Systems, Inc. | Enhanced metatree data structure for storage indexing and retrieval of information |
US5345586A (en) * | 1992-08-25 | 1994-09-06 | International Business Machines Corporation | Method and system for manipulation of distributed heterogeneous data in a data processing system |
US5542078A (en) * | 1994-09-29 | 1996-07-30 | Ontos, Inc. | Object oriented data store integration environment for integration of object oriented databases and non-object oriented data facilities |
US5974409A (en) * | 1995-08-23 | 1999-10-26 | Microsoft Corporation | System and method for locating information in an on-line network |
JPH10333953A (ja) * | 1997-04-01 | 1998-12-18 | Kokusai Zunou Sangyo Kk | 統合データベースシステムおよびそのデータベース構造を管理するプログラムを記録したコンピュータ読み取り可能な記録媒体 |
US6061677A (en) * | 1997-06-09 | 2000-05-09 | Microsoft Corporation | Database query system and method |
US6185552B1 (en) * | 1998-03-19 | 2001-02-06 | 3Com Corporation | Method and apparatus using a binary search engine for searching and maintaining a distributed data structure |
US6502088B1 (en) * | 1999-07-08 | 2002-12-31 | International Business Machines Corporation | Method and system for improved access to non-relational databases |
US6408300B1 (en) * | 1999-07-23 | 2002-06-18 | International Business Machines Corporation | Multidimensional indexing structure for use with linear optimization queries |
US6510434B1 (en) * | 1999-12-29 | 2003-01-21 | Bellsouth Intellectual Property Corporation | System and method for retrieving information from a database using an index of XML tags and metafiles |
US6704728B1 (en) * | 2000-05-02 | 2004-03-09 | Iphase.Com, Inc. | Accessing information from a collection of data |
-
2000
- 2000-06-06 JP JP2000174201A patent/JP4483034B2/ja not_active Expired - Fee Related
-
2001
- 2001-02-26 US US09/791,808 patent/US20020049747A1/en not_active Abandoned
-
2004
- 2004-12-14 US US11/010,266 patent/US20050091210A1/en not_active Abandoned
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN108415964A (zh) * | 2018-02-07 | 2018-08-17 | 平安科技(深圳)有限公司 | 数据表查询方法、装置、终端设备及存储介质 |
Also Published As
Publication number | Publication date |
---|---|
US20050091210A1 (en) | 2005-04-28 |
JP2001350656A (ja) | 2001-12-21 |
US20020049747A1 (en) | 2002-04-25 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP4483034B2 (ja) | 異種データソース統合アクセス方法 | |
JP4552242B2 (ja) | 仮想表インタフェースと該インタフェースを用いた問合せ処理システム及び方法 | |
US10007698B2 (en) | Table parameterized functions in database | |
US7272598B2 (en) | Structured indexes on results of function applications over data | |
US6801903B2 (en) | Collecting statistics in a database system | |
US6278994B1 (en) | Fully integrated architecture for user-defined search | |
CN1705945B (zh) | 提供查询的属性的方法和*** | |
US7856462B2 (en) | System and computer program product for performing an inexact query transformation in a heterogeneous environment | |
US6789071B1 (en) | Method for efficient query execution using dynamic queries in database environments | |
US6505189B1 (en) | Aggregate join index for relational databases | |
US6560594B2 (en) | Cube indices for relational database management systems | |
JP2001084257A (ja) | 問合せ処理方法及びシステム | |
US11797483B2 (en) | Data pruning based on metadata | |
US20030088546A1 (en) | Collecting and/or presenting demographics information in a database system | |
US20040015486A1 (en) | System and method for storing and retrieving data | |
CN111767303A (zh) | 一种数据查询方法、装置、服务器及可读存储介质 | |
US7185004B1 (en) | System and method for reverse routing materialized query tables in a database | |
Carey et al. | Data access interoperability in the IBM database family | |
KR100228548B1 (ko) | 지리정보 시스템용 시간지원 데이타베이스 관리 장치 | |
Barlos et al. | A load balanced multicomputer relational database system for highly skewed data | |
Crookshanks et al. | Just Enough SQL | |
Beckman | An assistant expert system: assisting assistors in assisting taxpayers | |
Bakker | Database Integration and Federation | |
Castrejon-Castillo | HAL Id: hal-01002695 | |
Hakim et al. | Experiment of Query Optimization Techniques to get the Efficient Query |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
RD01 | Notification of change of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7421 Effective date: 20060418 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070202 |
|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20070202 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20091006 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20091013 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20091214 |
|
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: 20100302 |
|
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20100315 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130402 Year of fee payment: 3 |
|
LAPS | Cancellation because of no payment of annual fees |