ホームページ  >  記事  >  バックエンド開発  >  XML データ クエリ テクノロジは、今日の注目の研究テーマになっています。

XML データ クエリ テクノロジは、今日の注目の研究テーマになっています。

黄舟
黄舟オリジナル
2017-02-13 15:49:191351ブラウズ

XML (Extensible Markup Language) は、インターネットの急速な発展、特に電子商取引、Web サービス、その他のアプリケーションの普及に伴い、XML タイプのデータが Web アプリケーションでのデータ表現とデータ交換の標準になりました。現在主流のデータ形式。したがって、XML データ管理テクノロジ、特に XML データ クエリテクノロジが現在の研究のホットスポットになっています。


リレーショナル データと比較すると、XML にはさまざまな利点がありますが、最大の欠点はその効率性です。リレーショナル データ ファイルでは、データ フィールド名は 1 回だけ出現する必要があるのに対し、XML データ ファイルでは要素名が繰り返し出現するため、クエリの効率に確実に影響します。 XML のクエリ効率をできるだけ向上させるためには、XML 型に対するインデックス機能を提供する必要があります。


World Wide Web Consortium は、2007 年 1 月 23 日に XPath2.0 と XQuery1.0 を推奨標準として特定し、さまざまなクエリ言語間の以前の競争に終止符を打ちました。 この標準に基づいて、従来のメーカーに加えて、さまざまな科学研究機関が、さまざまなストレージ モデル、さまざまなクエリ アルゴリズム、および最適化手法を使用した XPath および XQuery (文献には十数以上が記載されています) の実装を提案しています。これに関連して、Dameng Database Company も独自の開発戦略に基づいて独自の XML クエリ エンジン モデルを提案しており、現在、Dameng の XML クエリ エンジンは鋭意開発中であり、XML データに対する効果的なインデックスの確立は XML に影響を与える重要な要素です。データクエリのパフォーマンス。既存のデータベース製品のインデックス技術の詳細な分析に基づいて、Dameng XML クエリ エンジンが最適なパフォーマンスを達成できるように、より合理的なインデックス構造が設計されています。


XML インデックス技術の紹介


現在、XML に関する研究は主に 2 つの側面に分かれています。 1 つは、XML などの半構造化データの保存、クエリ、管理のためのネイティブ データベースです。データとメタデータは完全に XML 構造で表現され、その基礎となるデータ ストレージ形式 (オブジェクト モデル、リレーショナル モデルなど) とは何の関係もありません。 、など)。もう 1 つは、リレーショナル データベースの成熟したテクノロジを使用して XML データを処理する、リレーショナル データベースとの間の相互変換です。後者の方向はより実際的な重要性があるため、XML 研究の焦点となっています。


ストレージ ソリューションに加えて、インデックス作成テクノロジもデータベース システムを決定する際の最も重要な要素の 1 つです。 XML ドキュメント用のインデックス構造が構築されていない場合、XML データに対するクエリはドキュメント ツリー全体を走査することになる可能性があり、XML データ セットが増加するにつれて、このオーバーヘッドは許容できなくなります。したがって、XML インデックス技術の研究は理論的かつ実用的価値が高くなります。


従来のインデックス作成テクノロジーは長期的な蓄積を経て比較的成熟しましたが、このタイプのインデックス作成テクノロジーは主に(特定の関係を持つパターンではなく)値に基づいてデータレコードを検索する機能をターゲットにしており、お金はかかりませんXML データクエリの基本的な特徴は、データ間の論理的な関係 (正規のパス式で記述された構造的な関係) の入力に基づいてデータを抽出することです。 XML インデックスの内容は、パターン マッチング技術の設計と適用です。


XMLインデックス分類


パスベースのXMLインデックス


パスベースのインデックスは、XMLツリー構造内のノードのパス情報に基づいており、特定の削減方法を採用して作成されます結果のツリー構造は、異なるパス情報を維持するだけであり、同じパスを持つ 2 つのノードは存在しません。 提案されているインデックスには、DataGuides インデックス、Index Fabric インデックス、Adaptive Path Index for XML Data (APEX) が含まれます


Dataguides インデックスは、ルート ノードから始まる洗練されたパスです。 の構造概要。エッジ ラベルの連結によって形成される文字列パスは、データガイド内で 1 回だけ記述されます。データガイドは、パス クエリを走査するときに必要なノードの数を減らし、XML ドキュメントをルートから効率的に走査します。ただし、ワイルドカード文字を含むパス クエリや、XPath 標準で定義されている子孫または自己軸を使用したパス クエリでは、複数の接続操作が必要となるため、クエリの効率が低くなり、データの冗長性が生じます。


次に、これら 2 つの大きなフィールドに関する Java オブジェクト ファイル TestLob.java を作成し、型を CLOB として定義し、BLOB 属性フィールドをそれぞれ String および byte[] として定義します。 CLOB は大きなテキスト型であるため、これは The に対応します。 Java の String 型と BLOB は、厳密に定義されておらず、バイナリ ストリームの形式で保存されている大きなファイルを処理するために使用されます。そのため、byte[] 型を使用し、これら 2 つのプロパティの Getter メソッドと Setter メソッドを定義します。関連するコードは次のとおりです:


Dataguides インデックスは、ルート ノードから始まる洗練されたパスの構造的な概要です。エッジ ラベルの連結によって形成される文字列パスは、データガイド内で 1 回だけ記述されます。データガイドは、パス クエリを走査するときに必要なノードの数を減らし、XML ドキュメントをルートから効率的に走査します。ただし、ワイルドカード文字を含むパス クエリや、XPath 標準で定義されている子孫または自己軸を使用したパス クエリでは、複数の接続操作が必要となるため、クエリの効率が低くなり、データの冗長性が生じます。


Index Fabric は、Patricia Trie ツリー上に開発されたインデックス構造であり、各要素ノードへのマークされたパスを文字列でエンコードし、これらのエンコードされた値を Patricia Trie ツリーに挿入します。パスは文字列のクエリに変換されます。クエリを実行するときは、まずクエリ パスを文字列形式にエンコードしてから、インデックス ツリー内で検索します。 Index Fabric インデックスの利点は、XML データの階層構造情報を格納し、スキーマのある XML データとスキーマのない情報の取得を均一に処理し、XML データのクエリと更新に必要な時間が、階層に関係なく済むことです。インデックスキーの長さが関係します。 Index Fabric インデックスの欠点は、テキスト値を持つ要素ノードの情報のみを保持するため、要素ノード間の構造的関係が失われることです。したがって、DataGuide インデックスと同様に、Index Fabric インデックスは、XPath 標準で定義されている子孫または自己軸を使用した部分一致クエリ式の処理には効率的ではありません。このため、APEX [14] では、XML データ クエリ分散情報への依存関係が導入されました。頻繁に発生する XML クエリ ステートメントに対応するラベル ノードをハッシュ構造に事前保存します。その機能はキャッシュの機能に似ています。新しいクエリの処理が必要な場合、まずハッシュ テーブルを検索して、満足のいくノード セットがあるかどうかを確認します。ただし、要素値または属性値を含むクエリ式の場合は効率が低くなります。


ノードベースのインデックス


本質的に、ノードベースのインデックス作成は、XMLデータをデータユニットのレコードセットに分解し、同時にユニットの位置情報をXMLデータに保存することです。記録にある。パスベースのインデックスとは異なり、ノードベースのインデックスは、ラベル パスを通じてノードを見つける必要があるという制限を破り、XML データを正規形式のノード レコードに分解します。ノードの位置情報を保存し、成熟したリレーショナル データベース管理システムにうまく統合できるため、現在最も広く使用されているインデックスです。


位置情報のさまざまなエンコード方法に従って、ノードベースのインデックスは一般に次のカテゴリに分類できます:


1. プレフィックスベースのインデックス


は主にプレフィックスベースのインデックスに基づいています。 Dewey [12] では、生成されたインデックスをエンコードしています。文献 [13] の ORDPATH エンコードでは、同様の方法が使用されており、ORDPATH を圧縮する方法が SQL Server 2005 のインデックス構成に適用されています。



プレフィックスエンコーディングの基本的な考え方は、ノードの親ノードのエンコーディングをノードエンコーディングのプレフィックスとして直接使用し、ノード v が別のノードの子孫であるかどうかを判断することです。ノード u、u を決定するだけです。エンコーディングは v のエンコーディングのプレフィックスです。プレフィックス コーディング インデックスの重要な特性は、その辞書の順序付けです。ノード r をルートとするサブツリー内の任意のノード u について、そのプレフィックス コーディング c(u) は、その左の兄弟サブツリー (右の兄弟サブツリー) より大きい (小さい) です。内のすべてのノードの。したがって、プレフィックスベースのインデックスは、包含関係の計算を効果的にサポートできるだけでなく、ドキュメントの位置関係の計算も効果的にサポートできます。


2. 間隔コーディングに基づくインデックス


間隔コーディングインデックスの場合、ツリー T 内の各ノードには間隔コード [開始、終了] が割り当てられます。これは次の条件を満たします。言い換えると、ツリー T のノード u は、start(u)


の場合に限り、ノード v の祖先になります。最初の間隔エンコーディング スキームはディーツ エンコーディングであり、ツリー T の各ノードは次のとおりです。前順走査番号と後順走査番号を持つタプルを割り当てます。ツリー T 内の祖先ノード u は、前順走査中 (後順走査) ノード v の前 (後) にその子孫に出現する必要があるため、したがって、ノード u と v は、PRe(u)


の場合に限り、祖先/子孫の関係になります


間隔でエンコードされたインデックスのもう 1 つの典型的な例は、XISS インデックスです。これは各ノードに番号ペアを割り当てます。順序は次のとおりです。拡張プリオーダー コードとサイズは、ノードの子孫の範囲です。ドキュメント ツリー内の任意のノード X および Y について、order(x)


XISS インデックスが元のクエリ ステートメントを部分式に分解する場合に限ります。次に、これらの部分式に対してそれぞれクエリを実装し、最後にこれらの中間結果を結合してクエリ結果セットを取得します。これにより、ワイルドカード文字を含むクエリ ステートメントをより適切にサポートできるようになります。ただし、最終的なクエリ結果は、各中間結果を連結した後に取得されます。このような方法は確かにすべてのワイルドカード問題を解決できますが、そのような中間結果の連結は、特に長いパスを持つ単純な式の場合、非常に時間がかかる可能性があります。


2 つのインデックス作成メカニズムの比較


パスベースのインデックス作成は、主にノードの等価性やパスの等価性などの手法に基づいており、元のドキュメントよりもはるかに小さいインデックス構造になります。構造は依然としてツリーであるため、クエリを処理するときは、基本的に結果を取得するためにインデックス ツリー全体を走査する必要があります。パスベースのインデックスは、単純なパス式クエリを適切にサポートできますが、正規のパス式の場合はあまり適切に機能しません。


ノードベースのインデックスは、エンコード技術を通じて各ノードにインデックスを付けます。ノード間の構造的関係は、通常のパス式を適切にサポートできますが、特に多数の中間結果が発生する場合の長いパス式をサポートします。が生成されると、ノード インデックスの結合操作にコストがかかります。


パスベースのインデックス作成とノードベースのインデックス作成にはそれぞれ長所と短所がありますが、相互に補完し合うことができます。現在、実際のアプリケーションでは、ノードベースのインデックス作成がより広く使用されており、研究は比較的成熟しています。そのため、Dameng Company の XML インデックス構造に関する研究は主にノードベースのインデックス作成に焦点を当てており、パスベースのインデックス作成を参照して適切な改善を行っています。 。

上記は、今日注目の研究テーマとなっている XML データ クエリ技術の内容です。その他の関連コンテンツについては、PHP 中国語 Web サイト (www.php.cn) に注目してください。

声明:
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。