JP2008130084A - 最適化されたインデックス検索方法及び装置 - Google Patents

最適化されたインデックス検索方法及び装置 Download PDF

Info

Publication number
JP2008130084A
JP2008130084A JP2007242525A JP2007242525A JP2008130084A JP 2008130084 A JP2008130084 A JP 2008130084A JP 2007242525 A JP2007242525 A JP 2007242525A JP 2007242525 A JP2007242525 A JP 2007242525A JP 2008130084 A JP2008130084 A JP 2008130084A
Authority
JP
Japan
Prior art keywords
index
level
field
key
key value
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.)
Pending
Application number
JP2007242525A
Other languages
English (en)
Inventor
In-Sun Kang
仁 鮮 姜
Kyoung-Gu Woo
景 久 禹
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.)
Samsung Electronics Co Ltd
Original Assignee
Samsung Electronics Co Ltd
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 Samsung Electronics Co Ltd filed Critical Samsung Electronics Co Ltd
Publication of JP2008130084A publication Critical patent/JP2008130084A/ja
Pending legal-status Critical Current

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/2246Trees, e.g. B+trees
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F17/00Digital computing or data processing equipment or methods, specially adapted for specific functions

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Physics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

【課題】 最適化されたインデックス検索方法及び装置を提供する。
【解決手段】 所定のインデックスから第1キー値に対応する第1フィールドを検索するステップと、所定の検索要請が入力される場合、検索された第1フィールドを基準にインデックスから検索要請に対応するレベルの第2フィールドを検索するステップ、及び検索された第2フィールドに対応する識別子を抽出するステップを含む。
【選択図】 図4

Description

本発明は、最適化されたインデックス検索装置に関し、より詳しくは、より効率的なインデックスによる検索方法の提供及び格納空間の活用度を高め、多様なオペレーションを提供してインデックスを利用した外部モジュール具現の効率性を高める最適化されたインデックス検索装置に関するものである。
メタデータ基盤のUI(ユーザインタフェース)はデジタル機器のコンテンツ量が多くなるにつれて非常に人気あるUI方式になった。対象コンテンツの数が数千、数万個になれば、フォルダ及びファイル名だけで所望のコンテンツを検索するのが難しい反面、メタデータ基盤のUIは検索基準を変えながら所望のコンテンツを検索することができ、ユーザがメタデータ値を容易に記憶することができるという長所を有している。
特に、メタデータ基盤のブラウジングの中でもマルチレベルクラスタリング基盤のUIはユーザがより便利にコンテンツの分布状況を把握することができ、多様な検索基準を適用して所望のコンテンツに効果的にアクセスできるようにする。また、マルチレベルクラスタリング基盤のUIはコンテンツをレベル別にクラスタ化して提示し、クラスタ間の移動のためにインデックスを使用する。
前記マルチレベルクラスタリングとは、N(N>=1)番目基準によって分けられた各クラスタがさらにN+1番目基準によってより細部的なクラスタに分けられ得ることを意味する。そして、前記クラスタリングとは、類似する部類の個体をグループ化することを意味する。したがって、コンテンツブラウザがクラスタリング基盤のUIを採択したということは、全体コンテンツが所定の基準によって複数のクラスタに分けられてユーザに提示されることを意味する。また、ユーザがクラスタ内部をブラウジングしたり、クラスタをスキップしながらブラウジングすることができることを意味する。
図1は写真情報を格納するテーブルのスキーマに関する例示図である。
図1に示すように、テーブルの各レコードについて、年、月、日に関する情報を含むフィールド12が存在する。テーブルによって管理される写真はマルチレベルクラスタリングUIを介して、年、月、日フィールド12を基準に3つのレベル別にクラスタ化されて画面に表示され、最下位レベルの「日」基準のクラスタはタイトル順に整列されて出力される。このようにマルチレベルクラスタリングUIを具現するにはクラスタに属する写真レコードをデータベースから抽出することができなければならない。
例えば、最下位クラスタの1つである2006年(1レベル)5月(2レベル)1日(3レベル)に属する写真をブラウジングする場合、以下のクエリによって画面に出力するレコードを抽出することができる。
‘Select*from Table where 年=2006 and 月=5 and 日=1 order by タイトル’
前記クエリのように複数フィールドに対して所定の条件がある場合、適切なインデックスなしでクエリを処理すれば、写真レコードの個数が増加することによってクエリ処理時間が長くなる。したがって、前記クエリのように「Equal(=)」条件で構成され、最下位フィールドに対してソーティング条件がある場合、該当フィールドを組み合わせてインデックスのキーにするマルチカラムB+ツリーインデックスを使用するのが好ましい。
図2はマルチカラムB+ツリーインデックスの構成を示す図面である。
図2に示すように、年、月、日、タイトルを組み合わせてインデックスのキーにするマルチカラムB+ツリーインデックス20を使用すれば、年、月、日が特定の値に決定されたとき、所定の条件を満足するインデックスのエントリが既にタイトル順に整列されて隣接しているため、別途の整列動作を必要としない。そして、前記整列動作の除去はクエリ応答時間を大きく改善する。また、最下位の3レベル(日単位)クラスタでない2レベル(月単位)または1レベル(年単位)でクラスタをブラウジングする場合、マルチカラムB+ツリーインデックスを使用することができる。
しかし、後述する図3に示すように追加のインデックスが必要である。その理由は、前記マルチカラムB+ツリーインデックス20だけでは上位レベルが各々示すべきクラスタ名を求める時間が長くなるためである。前記マルチカラムB+ツリーインデックス20だけで1番目レベルで示すべきクラスタ名を得るためにはインデックスのエントリを全部読み込まなければならず、このような方式のクエリ処理はインタラクティブな画面構成に必要な応答時間を満足させることができない。
図3はマルチレベルクラスタリング格納のためのマルチカラムB+ツリーインデックスを示す図面である。
前述したように、前記応答時間を減らすためには、1番目レベル(「年」)に該当するフィールドにどういう値が存在するかを速い時間内に検索できるように追加のインデックスが必要である(30)。1番目レベルを構成するクラスタを画面に出力したいときは1番目レベルのクラスタ名をインデックスとして使用する。所定のクラスタ(例えば、2005年に該当するクラスタ)に属するレコードを画面に出力したいときはマルチカラムB+ツリーインデックスから2005年度(「年=2005」)のレコードを順次に読み込む。
また、2番目レベルでクラスタをブラウジングするとき、応答時間を減らすためには「年,月」のマルチカラムB+ツリーインデックスが必要であり、3番目レベルでクラスタをブラウジングするためには「年,月,日」のマルチカラムB+ツリーインデックスが必要である(40,50)。したがって、全体レベルを構成するフィールドの数がNであれば、必要なマルチカラムB+ツリーインデックスの総数はN個である。そして、それによって1番目レベルのキー値はN個のインデックスに重複して格納され、2番目レベルのキー値はN−1個のインデックスに格納されるなど格納空間の浪費の要因となる。
韓国公開特許第10-2004-0056638号公報
本発明は、最適化されたインデックス検索方法及び装置を提供し、より効率的なインデックスによる検索方法の提供及び格納空間の活用度を高め、多様なオペレーションを提供してインデックスを利用した外部モジュール具現の効率性を高めるのにその目的がある。
本発明の目的は以上に言及した目的に制限されず、言及していないさらなる目的は下記によって当業者に明確に理解できるものである。
前記目的を達成するために、本発明の実施形態による最適化されたインデックス検索方法は、所定のインデックスから第1キー値に対応する第1フィールドを検索するステップと、所定の検索要請が入力される場合、検索された第1フィールドを基準にインデックスから検索要請に対応するレベルの第2フィールドを検索するステップ、及び検索された第2フィールドに対応する識別子を抽出するステップを含む。
本発明の実施形態による最適化されたインデックス検索装置は、所定のインデックスから第1キー値に対応する第1フィールドを検索し、所定の検索要請が入力される場合、検索された第1フィールドを基準にインデックスから検索要請に対応するレベルの第2フィールドを検索する検索部、及び検索された第2フィールドに対応する識別子を抽出する抽出部を含む。
その他、実施形態の具体的な事項は詳細な説明及び図面に含まれている。
前記のような本発明の最適化されたインデックス検索方法及び装置によれば、次のような効果が1つまたはそれ以上ある。
第一に、本発明で提案するインデックスによって格納空間の活用度を高め、多様なオペレーションを提供して外部モジュールの具現が容易であるという長所がある。
第二に、単一レベルでクラスタリングされた場合、既存のB+ツリーインデックスと同様に動作できるように設計されて、1〜Nレベルでクラスタリングされたデータに対してB+ツリーインデックスやマルチカラムB+ツリーインデックスを置きかえて適用することができるという長所もある。
本発明の利点及び特徴、そしてそれらを達成する方法は添付する図面とともに詳細に後述する実施形態を参照すれば明確になる。しかし、本発明は以下に開示される実施形態に限定されず、相異なる多様な形態によって具現でき、単に本実施形態は本発明の開示を完全なものにし、本発明の属する技術分野における通常の知識を有する者に発明の範疇を完全に知らせるために提供するものであって、本発明は請求項の範疇によってのみ定義される。明細書全体にわたって同じ参照符号は同じ構成要素を示す。
以下、添付する図面を参照して本発明の好ましい実施形態を詳細に説明する。
図4は本発明の一実施形態による最適化されたインデックス検索装置のブロック図である。
最適化されたインデックス検索装置200は、格納部205、管理部207、検索部210、UI提供部215、抽出部220、コンテンツ提供部230を含む。
格納部205はインデックスにキー値及び識別子などを格納する。このとき、フィールド単位にキー値を格納することができ、識別子はRID(Record ID)であり得る。そして、インデックスのフィールドは先行キー値及び後行キー値が格納されているノードを示すポインタのうち少なくとも1つを格納する。このとき、前記先行キー値または前記後行キー値が同じノードに存在すれば、前記ポインタの格納が省略できる。本発明で提案するインデックス構造は図6ないし図9を参照して説明する。
管理部207は前記格納部205に格納されている値を管理する。例えば、管理部207は格納されている値に対して整列、追加、削除、更新などを行う。
検索部210は所定のインデックスから所定のキー値に対応するフィールドを検索する。そして、所定の検索要請が入力される場合、前記検索されたフィールドを基準に前記インデックスから前記検索要請に対応するレベルのフィールドを検索する。このとき、検索部210はUI提供部215を含むことができる。
UI提供部215はユーザにUIを提供し、提供されたUIを介してユーザが所定のキー値に対応するフィールドを検索することができるようにする。すなわち、UI提供部215によってユーザが所定のキー値を選択すれば、それに対応するフィールドが検索部210によって検索される。これに関する実施形態として図10を参照する。
抽出部220は前記検索部210から検索されたフィールドに対応する識別子を抽出する。このとき、識別子はRID(レコードID)値であり得、キー値と対応するRID値が抽出される。
コンテンツ提供部はユーザに前記RID値によってコンテンツのメタデータまたはコンテンツを提供する。最適化されたインデックス検索装置200内に含まれている多様なオペレーションの例は図10を参照する。
図4に示すそれぞれの構成要素は一種の「モジュール」で構成され得る。前記「モジュール」は、ソフトウェアまたはField Programmable Gate Array(FPGA)または注文型半導体(Application Specific Integrated Circuit、ASIC)のようなハードウェア構成要素を意味し、モジュールはある役割を行う。しかし、モジュールはソフトウェアまたはハードウェアに限定される意味ではない。モジュールはアドレシングできる格納媒体にあるように構成することができ、1つまたはそれ以上のプロセッサを実行させるように構成することもできる。したがって、一例としてモジュールは、ソフトウェア構成要素、オブジェクト指向ソフトウェア構成要素、クラス構成要素及びタスク構成要素などのような構成要素と、プロセス、関数、属性、プロシージャ、サブルーチン、プログラムコードのセグメント、ドライバ、ファームウェア、マイクロコード、回路、データ、データベース、データ構造、テーブル、アレイ、及び変数を含む。構成要素とモジュールにより提供される機能は、さらに小さい数の構成要素及びモジュールで結合されたり、追加的な構成要素とモジュールにさらに分離できる。
図5は本発明の一実施形態による最適化されたインデックス検索方法のフローチャートである。
まず、検索部210は所定のインデックスから所定のキー値に対応するフィールドを検索する(S501)。このとき、従来技術と違って、マルチカラムでインデックスを構成した場合、検索するキー(値)のレベルを指定することができる。すなわち、ユーザに所定のUIが提供される場合、UIを介して検索するキー値のレベルを指定することができ、前記キー値に対応するフィールドが検索部210によって検索される。前記レベルを指定することは、好ましくはUIを介して検索しようとするフィールドに移動して検索要請を入力するという意味である。このとき、検索部210は所定の検索要請がUIを介して入力される場合、前記検索されたフィールドを基準に前記インデックスから前記検索要請に対応するレベルのフィールドを検索する。より具体的な例は図10を参照する。
次のステップで、抽出部220は検索されたフィールドに対応する識別子を抽出する(S511)。
したがって、コンテンツ提供部230はユーザに前記識別子(RID)によってコンテンツのメタデータまたはコンテンツを提供する(S521)。
図6は本発明の一実施形態によるインデックスのリーフノードを示す図面である。
図6に示すように、インデックスのリーフノードにおいて1番目レベルのフィールドは数字値を有し、2番目レベルのフィールドは英文字、3番目レベルのフィールドはハングルでキーが構成されると仮定する。このとき、キーとRID(レコードID)で構成されるエントリはセル600構造で格納できる。
従来にはキー全体をバイナリストリングで認識してプレフィックスを区分する反面、本実施形態におけるインデックスはフィールド別にキーを区分することができる。例えば、「2005,10」と「2005,12」で、従来のプレフィックスは「2005,1*」になるが、本実施形態では「2005」になる。したがって、図6に示すように各セルの「1,a,イ」602と「b,イ」604で、本来は「1,a,イ」と「1,b,イ」であるが、1番目レベルのフィールド値が同じであるため、これを省略して格納していることが分かる。
まず、#100番(ノードのページ番号)ノードに格納されている「3,a,ロ」606で、1番目レベルのキーである「3」は先行キーが同じノード(#100番)に格納されている「2」であり、後行キーが#300番ノードに格納されている「4」である。したがって、1番目レベルのキーである「3」は先行キーが格納されているノードである自身が属するノード(#100番)を示し、後行キーが格納されているノードとして#300番ノードを示している。
このようにインデックスの各フィールドは先行キー及び後行キーが格納されているノードを示すポインタを有しているため、迅速に先後行キーを検索することができる。
また、#200番ノードで「3,a,ニ」を格納するときには「3,a」608を「ニ」610と分離して格納する。すなわち、「3,a,ハ」607で「3,a,ニ」と異なるキーを有するキーフィールドは3番目レベルのフィールドであるため、「ニ」610のみ格納し、「3,a」608はノードプレフィックスとして別に格納する。ノードプレフィックスを格納しておく理由は、リーフノードによってキーを検索するとき、他のノードを参照しなくても上位レベルのキー値が分かるようにするためである。
例えば、#300番ノードの「4,a,ロ」612位置から3番目レベルのキーである「ロ」の先行キーを検索するとき、他のノードを参照しなくても先行キー値が「3,d,ニ」614であることが分かる。以下、図7を参照して具体的なインデックスのノード構造について説明する。
図7は本発明の一実施形態によるインデックスのノード構造を示す。
本発明で提案するインデックス構造の特性はB+−ツリーであり得る。1970年代に紹介されたB−ツリーはB+−ツリー、B*−ツリー、プレフィックスB−ツリーなどいくつの変形されたB−ツリーバージョンが存在するが、本発明で提案するインデックスはマルチレベルクラスタリングキーも効果的に格納できる変形されたB+−ツリー形態であると言える。また、本発明で提案するインデックスはB+−ツリーのようにバランスツリーであり得る。したがって、いずれのキーを検索してもリーフノードから該当キーを検索できるため、ルートノードから任意のキーを探索する時間は同じである。
一方、キーとRIDで構成されるエントリはセル構造で格納できる。そして、全体キーの長さが可変的であるため、可変長キーを格納するためにセルの格納方式を実際データを格納する領域704とデータのオフセットを格納する領域702(各データの長さを格納する領域)に区分して可変的に格納空間を活用することができる。すなわち、オフセットを格納する領域702は前から後へ、データが格納される領域704は後から前へデータを流動的に格納することによって格納空間の活用度を高めることができる。
前記両領域702,704の大きさを一定に固定させた場合、実際データの長さが長ければ、データが格納される領域704は直ちにフル(full)になり、実際データの長さが相対的に非常に短ければ、オフセットが格納される領域702はフルになるが、データが格納される領域704はまだ空いているため、格納空間を効率的に利用することができない。
そして、前記ノードプレフィックスを格納する場合のためにノードプレフィックスのオフセットを格納する領域706が必要である。ノードプレフィックスが要らないノードである場合にはノードプレフィックスオフセット領域706が0(zero)値に初期化され得る。
また、各フィールドは先行キーが格納されているノードと後行キーが格納されているノードを示すポインタを格納することができる。このとき、ポインタ1つ当たり4バイトを使用する場合、全てのキーに対してポインタを常に2つずつ保つようになれば、それだけ実際データを格納できる空間が減少し得る。
したがって、前記インデックスの各フィールドは現在検索されているキーを基準に先行キーまたは後行キーが現在ノードと同じノードにあれば、先行キーまたは後行キーが格納されているノードを示すポインタの格納を省略することによって、実際データを格納できる空間をさらに確保することができる。
このために、i番目レベルの先行/後行キーが現在ノード内に存在すれば、i+1番目レベルの先行/後行キーも現在ノード内に存在し、i番目レベルの先行/後行キーが他のノードに存在すれば、i−1番目レベルの先行/後行キーも他のノードに存在する原理を利用することができる。このとき、1番目レベルが最上位レベルであると仮定する。
このように、上位レベルに対する下位レベルの従属性を利用して現在検索されているキーを基準に先行キーまたは後行キーが格納されているノードを示すポインタの格納を省略することができる。そして、上位レベルのキー及び下位レベルのキーが1つのエントリ内に格納されるため、検索するレベルを調節するとき追加ノードのアクセスが発生しない。
前記上位レベルと下位レベルの間の従属性について具体的に例を挙げれば、第1ノード、すなわち[(2000年,8月,16日)(20日)(9月,1日)(2日)(4日)]と第2ノード、すなわち[(2001年,1月,4日),...]で、2000年9月1日が現在検索されているキー値であるとき、月単位レベルの先行キー(2000年8月)が現在ノードに存在するため、それよりさらに細分化されたクラスタリングレベルである日単位の先行キーが現在ノードに存在する。すなわち、月単位の値が変更されたことは日単位のクラスタリングでも値が変更されていることを意味する。同様に2000年8月16日が現在検索されているキー値であるとき、月単位レベルの後行キーが現在ノードにあるため、日単位の後行キーも現在ノードにあるということが保障される。
以下、図8及び図9を参照してインデックスのセル構造について説明する。このとき各フィールドに入力される値の単位はビットまたはバイト単位であり得る。単位は図面に示されており、以下の説明では単位を省略して所定値と表示する。
図8は本発明の一実施形態によるインデックスのリーフノードにおけるセルの構造を示す図面である。
図8に示すように、カウント情報領域810におけるフィールドカウント(Field Cnt)フィールド801は現在検索されているキーが存在するセルがいくつのフィールドで構成されているかを示す。セルのフィールドカウントフィールド801によってインデックスから各レベル別の境界地点を検索することができる。すなわち、同じノード内では所定レベルの境界地点をセルのフィールドカウント値で検索し、所定レベルの境界地点が同じノード内にない場合にはノードプレフィックス値を利用して検索すれば、境界地点を迅速に検索することができる。これによって、各レベル別に同じキー値を有するエントリの最初と最後を迅速に検索することができる。
そして、先行カウントフィールド802は後述する先行ポインタ(Prev Ptr)の個数を示し、後行カウントフィールド803は後述する後行ポインタ(Next Ptr)の個数を示す。パディング(Padding)フィールド804は所定の予約(reserved)された格納空間である。
ポインタ領域820はレベル別に先行キーまたは後行キーが存在するノードを示すポインタを格納する。具体的に先行ポインタフィールド822はi番目レベルでブラウジングするとき、i番目レベルを基準に先行キーが格納されているノードのポインタを格納し、このときポインタはノードのページ番号であり得る。例えば、先行ポインタ1は1番目レベルを基準に先行キーが格納されているノードを示すポインタを格納する。そして、先行ポインタ2は2番目レベルを基準に先行キーが格納されているノードを示すポインタを格納する。また、先行ポインタ3は3番目レベルを基準に先行キーが格納されているノードを示すポインタを格納する。
後行ポインタフィールド824はi番目レベルでブラウジングするとき、i番目レベルを基準に後行キーが格納されているノードを示すポインタを格納する。例えば、後行ポインタ1は1番目レベルを基準に後行キーが格納されているノードを示すポインタを格納する。そして、後行ポインタ2は2番目レベルを基準に後行キーが格納されているノードを示すポインタを格納する。また、後行ポインタ3は3番目レベルを基準に後行キーが格納されているノードを示すポインタを格納する。
次いで、キー値を格納する領域830で、キーサイズフィールド832はキーiのフィールド長を示す。例えば、全体レベル数をxとすれば(すなわち、年,月,日であれば、x=3)、キーサイズはx−N+i番目レベルのフィールドデータ長(バイト単位)を有するようになる。そして、キーフィールド834は所定レベルのデータを示し、x−N+I番目レベルのフィールドデータを格納する。
例えば、カウント情報領域810で、フィールドカウントフィールド801の値が2である場合、キーサイズは前記x−N+iで3−2+1であり、キーサイズフィールド832は2番目レベルのフィールドデータ長、すなわち月データの長さを示す。そして、キーフィールド834は月データ値を格納する。
前記図6のデータに基づいて説明すれば、まず前記図6で1番目レベルを基準に全てのキーを順に抽出するときは「1,2,3,4」に抽出でき、2番目レベルを基準に全てのキーを順に抽出するときは「1a,1b,2a,3a,3b,3c,3d,4a,5b」に抽出できる。そして、3番目レベルを基準に全てのキーを順に抽出するときは「1aイ,1bイ,2aロ,2aハ,2aニ,3aロ,3aハ,3aニ,3aホ,3bイ,3bロ」に抽出できる。したがって、3,a,ロ606(または3aロ)でフィールドカウントフィールド801は3値、先行カウントフィールド802は0値、後行カウントフィールド803は2値を格納する。後行ポインタ1フィールド824は1番目レベル(すなわち3)を基準に後行キー(すなわち4)が#300ノードに格納されているため、#300が格納される。先行ポインタフィールド822は先行カウントフィールド802の値が0(zero)、すなわち1番目レベル(すなわち3)、2番目レベル(すなわち3a)、3番目レベル(すなわち3aロ)の以前値が全て現在ノードである#100に存在するため、先行ポインタが格納されない。後行ポインタ2フィールド824は2番目レベル(すなわち3a)を基準に後行キー(すなわち3b)が#200ノードに格納されているため、#200が格納される。後行ポインタ3フィールド824は後行カウントフィールド803が2値で、3番目レベル(すなわち3aロ)の次の値が現在ノードである#100に存在するため、格納される後行ポインタ値が存在しない。また、キーサイズフィールド832でキーサイズ1フィールドは4値、キーサイズ2フィールドは1値、キーサイズ3フィールドは2値が格納され、キーフィールド834でキー1フィールドは3値、キー2フィールドはa値、キー3フィールドはロ値が格納される。
一方、内部ノードでは連続的なキーの検索が行われないため、互いに異なるノードにあるキー間にリンクを維持する必要がない。したがって、リーフノードのセル構造が有している先行ポインタ、及び後行ポインタは内部ノードのセル構造では除去できる。内部ノードでもプレフィックスを分離した構造を有することができ、または一般的なマルチカラムB+ツリーインデックスのように全体キー値を常に保つこともできる。
前述したように、ノードプレフィックスは以前ノードにある隣接キーで既にプレフィックスとして使用された上位レベルフィールド値であっても現在ノードで上位レベルフィールド値を知るために再記録することができる。ノードプレフィックスは下位レベルフィールド値と同じセルに格納せずに、ノードプレフィックス部分のみ別個のセルで構成することができる。
図9は本発明の一実施形態によるノードプレフィックスのセル構造の例示図である。
図9は前記図6で例示した#200ノードのノードプレフィックス「3,a」910のセル構造を前記図8を参考して示す。すなわち、#200ノードのノードプレフィックス「3,a」910のセル構造で、現在キーが2つのフィールドで構成されているため、フィールドカウントフィールド801には2値、先行/後行ポインタ個数がないため、先行/後行カウントフィールド802,803は0値が格納される。そして、キーサイズフィールド832には「3,a」910それぞれのキー値のサイズに対して1値と2値、そしてキーフィールド834のキー値として3とa値が格納される。各値の単位は前記図8を参照する。
図10は本発明の一実施形態によるインデックス検索のためのUIを示す図面である。
図10に示すように、ユーザはUIを介する検索要請によって所望のコンテンツを検索してサービスを受けることができる。このとき、本発明で提案するインデックス構造を利用した各オペレーション(関数)(find_key,find_next_entry,find_prev_entry,find_first_key,find_last_key,find_next_key,find_prev_key,find_upper_key,find_down_key)が利用できる。そして、優先順位が最も高いクラスタリングキー(またはキー)のレベルが1レベルと仮定するとき、年単位を1レベル、月単位を2レベル、日単位を3レベルとする。また、図示のように各フィールド別にキー値及び識別子(RID)情報を含んでおり、ユーザの選択によってフィールド間の移動が可能である。
すなわち、ユーザがUIを介してフィールド間を移動するとき検索要請が入力されるようになる。例えばUIを介して2005年5月(2005,5と表記)フィールド1000に移動すれば、2005,5値(2レベル)が入力されて該当キー値とマッチング(対応)する識別子が抽出される。このとき、前記抽出された識別子が複数である場合、該当フィールド1000の1番目値が返還でき、前記フィールド内の識別子と対応するコンテンツまたはコンテンツのメタデータがユーザに提供できる。このようにUIを介してユーザが検索しようとするキー値のレベル(2レベル)を直ちに指定することができ、指定されたレベルを基準に多様なオペレーションを利用してフィールドを検索することができる。
以下、オペレーションを図10を参考してより具体的に説明する。
まず、find_keyオペレーションは、検索しようとするキー値とマッチングするエントリ(またはフィールド)をリーフノードから検索して識別子、すなわちRIDを返還する。キー値とマッチングするRIDが多い場合には1番目RIDを返還する。このとき、従来技術と違って、マルチカラムでインデックスを構成した場合に検索するキーのレベルを指定することができる。例えば図10で、ユーザがUIを介して「2005,5」フィールド1000に移動した場合、RIDは5711(a)が返還される。すなわち、「2005,5」フィールド1000は下位レベルとして5、6フィールドを含み、各フィールドは複数のRID値を含んでいる。このとき、1番目RID値である5711(a)が返還できる。そして、検索されたフィールド1000内の識別子に対応するコンテンツまたはコンテンツのメタデータがユーザに提供できる。また、以後に動作するオペレーションは「2005,5」キー値(またはフィールド)を基準に検索を行うことができる。
次に、find_next_entryオペレーションは、最も最近に検索したエントリの次のエントリを検索してキーとRIDを返還する。現在検索中であるレベルのキー値が変更されれば、キーを構成するフィールド値の中で変化されたフィールドのうち最上位レベル番号をともに返還する。例えば、2番目レベルを基準にエントリを検索するうちに、1番目及び2番目レベルのフィールド値が変更されて新しい2レベルキーを得るようになればレベル番号1を返還する。例えば図11で、「2005,5」をfind_keyオペレーションで検索した場合、find_next_entryオペレーションを行えば、RIDは5712(b)が返還される。
次に、find_prev_entryオペレーションは、最も最近に検索したエントリの以前のエントリを検索してキーとRIDを返還する。現在検索中であるレベルのキー値が変更されれば、キーを構成するフィールド値の中で変化されたフィールドのうち最上位レベル番号をともに返還する。例えば、2番目レベルを基準にエントリを検索するうちに、1番目及び2番目レベルのフィールド値が変更されて新しい2レベルキーを得るようになればレベル番号1を返還する。例えば図11で、「2005,5」をfind_keyオペレーションで検索した場合、find_prev_entryオペレーションを行えば、新しいキー値「2005,4」とRIDは5710(c)が返還される。このとき、2番目レベルを基準にエントリを検索するうちに、2番目フィールド値が5から4に変わったため、レベル番号2がともに返還される。
次に、find_first_keyオペレーションは、リーフノード上で1番目キーと該当キーを有する1番目RIDを返還する。このとき、従来技術と違って、変換されるキーのレベルiを入力することができる。以後に動作するオペレーションはiレベルを基準にキー値を検索する。例えば図11で、2レベルに対してfind_first_keyオペレーションを行えば、「1993,1」キーを検索し、RIDは「0001」(d)が返還される。
次に、find_last_keyオペレーションは、リーフノード上で最後キーと該当キーを有する最後RIDを返還する。上位レベルのフィールド値が変更されれば、最上位レベル番号をともに返還する。例えば、3番目レベルを基準に検索するうちに、1番目及び2番目レベルのフィールド値が変更されれば、最上位レベル番号1を返還する。このとき、従来技術と違って、返還されるキーのレベルiを入力することができる。以後に動作するオペレーションはiレベルを基準にキー値を検索する。例えば図11で、2番目レベルに対してfind_last_keyオペレーションを行えば、「2006,12」キーを検索し、RIDは「6220」(e)が返還される。
次に、find_next_keyオペレーションは、リーフノードで最も最近に検索したキー値の後行キー値を検索してRIDとともに返還する。上位レベルのフィールド値が変更されれば、最上位レベル番号をともに返還する。例えば、3番目レベルを基準に検索するうちに、1番目及び2番目レベルのフィールド値が変更されれば、最上位レベル番号1を返還する。このとき、従来技術と違って、最近に検索したキーのレベルがi番目であれば、該当レベル上における後行キーを返還することができる。例えば図11で、「2005,5」をfind_keyオペレーションで検索した場合、find_next_keyオペレーションを行えば、新しいキー値「2005,6」とRIDは5720(f)が返還される。
また、find_next_keyオペレーションは現在検索中であるキーのレベルをiとするとき、検索完了条件はフィールドカウント値が(最大フィールドカウント+1−i)と同じかあるいは大きいものを検索したり、これ以上検索するノードがないときである。そして、検索方向は後述するread_key_headerオペレーションの動作を行って後行カウント値などを得る。後行カウント値がiより小さい場合は後行キーが現在ノードにある場合であるため、現在ノード内のセルを現在セル位置から後へ検索する。後行カウント値がiと同じかあるいは大きい場合は後行キーが他のノードにある場合であるため、後行ポインタ(Next Ptr)が示すノードで1番目セルから後へ検索する。
次に、find_prev_keyオペレーションは、リーフノードから最も最近に検索したキー値の先行キー値を検索してRIDとともに返還する。上位レベルのフィールド値が変更されれば、最上位レベル番号をともに返還する。例えば、3番目レベルを基準に検索するうちに、1番目及び2番目レベルのフィールド値が変更されれば、最上位レベル番号1を返還する。このとき従来技術と違って、最近に検索したキーのレベルがi番目であれば、該当レベル上における先行キーを返還することができる。例えば図11で、「2005,5」をfind_keyオペレーションで検索した場合、find_prev_keyオペレーションを行えば、新しいキー値「2005,4」とRIDは5706(g)が返還される。
また、find_prev_keyオペレーションの検索完了条件は現在検索中であるキーのレベルをiとするとき、フィールドカウント値が(最大フィールドカウント+1−i)と同じかあるいは大きいものを検索したり、これ以上検索するノードがないときである。そして、検索方向は後述するread_key_headerオペレーションの動作を行って先行カウント値などを得る。先行カウント値がiより小さい場合は先行キーが現在ノードにある場合であるため、現在ノード内のセルを現在セル位置から前へ検索する。先行カウント値がiと同じかあるいは大きい場合は先行キーが他のノードにある場合であるため、先行ポインタ(Prev Ptr)が示すノードで最後セルから最初セル方向へ検索する。
次に、find_upper_keyオペレーションは、現在検索中であるキーのレベルがiであれば、検索レベルをi−1に変更する。以後に行う全ての演算はi−1レベルキーを基準に行われる。
また、find_upper_keyペレーションは現在検索中であるキーのレベルをiとするとき、検索完了条件はiが1であったり、(現在レベルが最上位レベルであるため)フィールドカウント(Field Cnt)が(最大フィールドカウント+1−i)より大きい場合(現在セルに上位レベルのキーが含まれている)である。そして、検索方向は後述するread_key_headerオペレーションの動作を行ってフィールドカウント値などを得る。現在ノード内で検索するが、現在位置から検索完了条件を満足するまで前のセルへ移動しながら検索する。現在ノードの1番目エントリでも検索できない場合、ノードプレフィックスから上位キーを検索する。
次に、find_down_keyオペレーションは、現在検索中であるキーのレベルがiであれば、i+1番目レベルのキーを返還する。以後に行う全ての演算はi+1レベルキーを基準に行われる。
また、find_down_keyオペレーションは現在検索中であるキーのレベルをiとするとき、iが最大フィールドカウントと同じであれば、現在キーレベルが最下位レベルであるため、返還する下位キー値がない。iが最大フィールドカウントと異なれば、現在セルから下位キー値を検索して返還する。
read_key_headerオペレーションは現在検索中であるレベルのキー値を含むセルのヘッダ値を読み取る動作をする。find_next_entryオペレーション、find_prev_entryオペレーションまたはfind_upper_keyオペレーションなどを行った場合、最近検索したセルが検索中であるレベルのキーを含んでいないことがある。すなわち、現在検索中であるレベルをiとし、現在検索カーソルが位置するセルにおけるフィールドカウント値がfとすれば、f<(最大フィールドカウント+1−i)である場合が発生する。このとき、検索中であるキー値は既に知っている状態である。したがって、キー値と検索レベルiを入力してfind_keyオペレーションを行って該当キーを含むセルを検索することができる。
また、read_key_headerオペレーションはf>=(最大フィールドカウント+1−i)である場合は現在セルからi番目キーに該当する情報を読み取る。f<(最大フィールドカウント+1−i)である場合はfind_keyオペレーションを行って検索したセルからi番目キーに該当する情報を読み取る。
以上、添付する図面を参照して本発明の実施形態を説明したが、本発明の属する技術分野における通常の知識を有する者は本発明がその技術的思想や必須的な特徴を変更せずに他の具体的な形態によって実施できることを理解することができる。したがって前述した実施形態はすべての面で例示的なものであって、限定的なものではないことを理解しなければならない。
写真情報を格納するテーブルのスキーマに関する例示図である。 マルチカラムB+ツリーインデックスの構成を示す図である。 マルチレベルクラスタリング格納のためのマルチカラムB+ツリーインデックスを示す図である。 本発明の一実施形態による最適化されたインデックス検索装置のブロック図である。 本発明の一実施形態による最適化されたインデックス検索方法のフローチャートである。 本発明の一実施形態によるインデックスのリーフノードを示す図である。 本発明の一実施形態によるインデックスのノード構造を示す図である。 本発明の一実施形態によるインデックスのリーフノードにおけるセルの構造を示す図である。 本発明の一実施形態によるノードプレフィックスのセル構造の例示図である。 本発明の一実施形態によるインデックス検索のためのUIを示す図である。
符号の説明
210 検索部
220 抽出部

Claims (16)

  1. 所定のインデックスから第1キー値に対応する第1フィールドを検索するステップと、
    所定の検索要請が入力される場合、前記検索された第1フィールドを基準に前記インデックスから前記検索要請に対応するレベルの第2フィールドを検索するステップと、
    前記検索された第2フィールドに対応する識別子を抽出するステップとを含むことを特徴とする最適化されたインデックス検索方法。
  2. 前記インデックスはフィールド単位でキー値を格納することを特徴とする請求項1に記載の最適化されたインデックス検索方法。
  3. 前記インデックスのフィールドは先行キー値及び後行キー値が格納されているノードを示すポインタのうち少なくとも1つを格納することを特徴とする請求項2に記載の最適化されたインデックス検索方法。
  4. 前記先行キー値または前記後行キー値が同じノードに存在すれば、前記ポインタの格納を省略することを特徴とする請求項3に記載の最適化されたインデックス検索方法。
  5. 前記インデックスは他のノードを参照しなくても所定のキー値の上位レベルのキー値を検索できるように現在ノードに前記上位レベルのキー値を別に格納することを特徴とする請求項1に記載の最適化されたインデックス検索方法。
  6. 前記抽出された識別子によって所定のコンテンツのメタデータまたはコンテンツを提供するステップをさらに含むことを特徴とする請求項1に記載の最適化されたインデックス検索方法。
  7. 所定のインデックスから第1キー値に対応する第1フィールドを検索し、所定の検索要請が入力される場合、前記検索された第1フィールドを基準に前記インデックスから前記検索要請に対応するレベルの第2フィールドを検索する検索部と、
    前記検索された第2フィールドに対応する識別子を抽出する抽出部とを含むことを特徴とする最適化されたインデックス検索装置。
  8. 前記インデックスはフィールド単位でキー値を格納することを特徴とする請求項7に記載の最適化されたインデックス検索装置。
  9. 前記インデックスのフィールドは先行キー値及び後行キー値が格納されているノードを示すポインタのうち少なくとも1つを格納することを特徴とする請求項8に記載の最適化されたインデックス検索装置。
  10. 前記先行キー値または前記後行キー値が同じノードに存在すれば、前記ポインタの格納を省略することを特徴とする請求項9に記載の最適化されたインデックス検索装置。
  11. 前記インデックスは他のノードを参照しなくても所定のキー値の上位レベルのキー値を検索できるように現在ノードに前記上位レベルのキー値を別に格納することを特徴とする請求項7に記載の最適化されたインデックス検索装置。
  12. 前記抽出された識別子によって所定のコンテンツのメタデータまたはコンテンツを提供するコンテンツ提供部をさらに含むことを特徴とする請求項7に記載の最適化されたインデックス検索装置。
  13. 前記検索要請を入力できるように複数レベルで構成されたUIを提供するUI提供部をさらに含むことを特徴とする請求項7に記載の最適化されたインデックス検索装置。
  14. 前記検索部は前記複数レベルのうちユーザが指定したレベルのキー値に対応するフィールドを検索することを特徴とする請求項13に記載の最適化されたインデックス検索装置。
  15. 前記検索部は前記指定されたレベルを基準に上位または下位レベルのキー値に対応するフィールドを検索することを特徴とする請求項14に記載の最適化されたインデックス検索装置。
  16. 前記検索部は前記指定されたレベルを基準に先行または後行キー値に対応するフィールドを検索することを特徴とする請求項14に記載の最適化されたインデックス検索装置。
JP2007242525A 2006-11-23 2007-09-19 最適化されたインデックス検索方法及び装置 Pending JP2008130084A (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020060116560A KR100834760B1 (ko) 2006-11-23 2006-11-23 최적화된 인덱스 검색 방법 및 장치

Publications (1)

Publication Number Publication Date
JP2008130084A true JP2008130084A (ja) 2008-06-05

Family

ID=38829759

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007242525A Pending JP2008130084A (ja) 2006-11-23 2007-09-19 最適化されたインデックス検索方法及び装置

Country Status (5)

Country Link
US (1) US7970769B2 (ja)
EP (1) EP1926030A3 (ja)
JP (1) JP2008130084A (ja)
KR (1) KR100834760B1 (ja)
CN (1) CN101187941B (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014509008A (ja) * 2011-02-21 2014-04-10 アマデウス エス.アー.エス. データウェアハウスから統計を提供する方法およびシステム
JP2015079508A (ja) * 2013-10-15 2015-04-23 ネイバー コーポレーションNAVER Corporation データベース管理方法、プログラム及び該管理システム、並びにデータベースのツリー構造

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101968807A (zh) * 2010-10-15 2011-02-09 北京思在信息技术有限责任公司 一种内容检索的方法及装置
CN102831224B (zh) * 2012-08-24 2018-09-04 北京百度网讯科技有限公司 一种数据索引库的建立方法、搜索建议生成方法和装置
KR101440475B1 (ko) * 2012-10-17 2014-09-17 주식회사 리얼타임테크 혼합 질의 처리를 위한 색인 생성 방법, 혼합 질의 처리 방법 및 색인 자료구조를 기록한 기록 매체
CN103744897A (zh) * 2013-12-24 2014-04-23 华为技术有限公司 故障信息的关联搜索方法、系统和网络管理系统
CN104182479B (zh) * 2014-08-04 2018-11-30 宇龙计算机通信科技(深圳)有限公司 一种处理信息的方法及装置
CN104408128B (zh) * 2014-11-26 2017-11-03 上海爱数信息技术股份有限公司 一种基于b+树异步更新索引的读优化方法
US10303673B2 (en) * 2015-05-11 2019-05-28 Apple Inc. Hierarchical data storage
CN106970936B (zh) * 2017-02-09 2020-07-03 阿里巴巴集团控股有限公司 数据处理方法及装置、数据查询方法及装置
CN107301208A (zh) * 2017-06-02 2017-10-27 北京奇虎科技有限公司 一种数据表处理方法和装置
KR102351846B1 (ko) * 2018-11-21 2022-01-18 한국전자기술연구원 분산형 데이터베이스상의 인덱스 병합을 활용한 질의 최적화 방법
CN109815240B (zh) 2019-01-29 2022-02-25 北京百度网讯科技有限公司 用于管理索引的方法、装置、设备和存储介质
CN109918472A (zh) * 2019-02-27 2019-06-21 北京百度网讯科技有限公司 存储和查询数据的方法、装置、设备和介质
CN109947709B (zh) * 2019-04-02 2021-10-08 北京百度网讯科技有限公司 数据存储方法和装置

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS63116232A (ja) * 1986-10-30 1988-05-20 アプル・コンピユータ・インコーポレーテツド 階層構造のファイルシステムおよびそれを構成する方法
JPH06103134A (ja) * 1992-09-18 1994-04-15 Hitachi Software Eng Co Ltd インデックスの構築方法
JP2004062475A (ja) * 2002-07-29 2004-02-26 Hitachi Ltd インデクス格納方法

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4945475A (en) 1986-10-30 1990-07-31 Apple Computer, Inc. Hierarchical file system to provide cataloging and retrieval of data
JPH07210563A (ja) 1994-01-13 1995-08-11 Hitachi Ltd 索引処理方法
US5671416A (en) * 1995-02-24 1997-09-23 Elson; David Apparatus and a method for searching and modifying source code of a computer program
KR100256686B1 (ko) 1997-11-26 2000-05-15 이계철 다중 균형 트리 구조를 이용한 관리정보 트리에서의 노드 검색,생성 및 삭제 방법
JP3849279B2 (ja) 1998-01-23 2006-11-22 富士ゼロックス株式会社 インデクス作成方法および検索方法
KR100285265B1 (ko) * 1998-02-25 2001-04-02 윤덕용 데이터 베이스 관리 시스템과 정보 검색의 밀결합을 위하여 서브 인덱스와 대용량 객체를 이용한 역 인덱스 저장 구조
US6721723B1 (en) 1999-12-23 2004-04-13 1St Desk Systems, Inc. Streaming metatree data structure for indexing information in a data base
KR100328129B1 (ko) 1999-12-27 2002-03-12 오길록 메모리 계층 구조를 고려한 압축, 탐색 및 새로운 항목삽입 방법
KR100358348B1 (ko) * 2000-06-01 2002-10-25 (주) 아이티캠프 엑스엠엘 데이터의 효과적인 검색을 위한 다중 경로인덱스 방법
US6834278B2 (en) * 2001-04-05 2004-12-21 Thothe Technologies Private Limited Transformation-based method for indexing high-dimensional data for nearest neighbour queries
US6859808B1 (en) * 2001-05-31 2005-02-22 Oracle International Corporation Mapping logical row identifiers for primary B+tree-like structures to physical row identifiers
US6970865B1 (en) * 2001-12-28 2005-11-29 Unisys Corporation Database searching using trapeze fetch
WO2004023328A1 (en) * 2002-09-05 2004-03-18 Stex Technologies Private Limited Indexed data storage system, method and data structure
KR100558765B1 (ko) * 2002-11-14 2006-03-10 한국과학기술원 적응형 경로 인덱스를 이용한 xml 질의 수행 방법
US20050102255A1 (en) 2003-11-06 2005-05-12 Bultman David C. Computer-implemented system and method for handling stored data
KR100942902B1 (ko) * 2004-01-15 2010-02-16 엔에이치엔(주) 웹페이지 검색 방법 및 상기 방법을 컴퓨터에서 구현하는 프로그램을 기록한 컴퓨터 판독 가능한 기록 매체
KR100600862B1 (ko) * 2004-01-30 2006-07-14 김선권 인터넷상의 정보자원에 대한 접근 경로를 체계적으로수집하고 검색하는 방법, 및 이 방법을 실행할 수 있는컴퓨터 프로그램을 수록한 기록매체
US7213041B2 (en) * 2004-10-05 2007-05-01 Unisys Corporation Saving and restoring an interlocking trees datastore
US20070214153A1 (en) * 2006-03-10 2007-09-13 Mazzagatti Jane C Method for processing an input particle stream for creating upper levels of KStore

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS63116232A (ja) * 1986-10-30 1988-05-20 アプル・コンピユータ・インコーポレーテツド 階層構造のファイルシステムおよびそれを構成する方法
JPH06103134A (ja) * 1992-09-18 1994-04-15 Hitachi Software Eng Co Ltd インデックスの構築方法
JP2004062475A (ja) * 2002-07-29 2004-02-26 Hitachi Ltd インデクス格納方法

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014509008A (ja) * 2011-02-21 2014-04-10 アマデウス エス.アー.エス. データウェアハウスから統計を提供する方法およびシステム
US9710506B2 (en) 2011-02-21 2017-07-18 Amadeus S.A.S. Method and system for providing statistical data from a data warehouse
JP2015079508A (ja) * 2013-10-15 2015-04-23 ネイバー コーポレーションNAVER Corporation データベース管理方法、プログラム及び該管理システム、並びにデータベースのツリー構造
US10664459B2 (en) 2013-10-15 2020-05-26 Naver Corporation Database managing method, database managing system, and database tree structure

Also Published As

Publication number Publication date
US7970769B2 (en) 2011-06-28
CN101187941A (zh) 2008-05-28
CN101187941B (zh) 2011-06-29
KR20080046905A (ko) 2008-05-28
EP1926030A2 (en) 2008-05-28
EP1926030A3 (en) 2009-12-30
KR100834760B1 (ko) 2008-06-05
US20080126298A1 (en) 2008-05-29

Similar Documents

Publication Publication Date Title
JP2008130084A (ja) 最適化されたインデックス検索方法及び装置
JP3849279B2 (ja) インデクス作成方法および検索方法
US6792414B2 (en) Generalized keyword matching for keyword based searching over relational databases
US6801904B2 (en) System for keyword based searching over relational databases
Krishnan et al. Estimating alphanumeric selectivity in the presence of wildcards
US20100106713A1 (en) Method for performing efficient similarity search
US20050125395A1 (en) Index for data retrieval and data structuring
JP2006048684A (ja) 情報検索システムにおけるフレーズに基づく検索方法
CN109857898A (zh) 一种海量数字音频指纹存储与检索的方法及系统
EP1315103B1 (en) File search method and apparatus, and index file creation method and device
US20080059432A1 (en) System and method for database indexing, searching and data retrieval
CN106547893A (zh) 一种图片分类管理系统及图片分类管理方法
KR101234795B1 (ko) 컨텐츠 브라우징 장치 및 방법
CN103473324A (zh) 基于非结构化数据存储的多维业务属性检索装置及方法
CN105404677A (zh) 一种基于树形结构的检索方法
KR20100022565A (ko) 해시트리를 이용한 url 검색방법
CN105426490A (zh) 一种基于树形结构的索引方法
JP2007048318A (ja) リレーショナルデータベースの処理方法およびリレーショナルデータベース処理装置
JP2015176407A (ja) 検索装置、検索方法、検索用プログラムおよび検索用データ構造
US6735584B1 (en) Accessing a database using user-defined attributes
JP2006092409A (ja) 複合データベース検索システムおよび複合データベース検索方法ならびにそのためのプログラム
CN107908762A (zh) 一种自定义关键词串并历史数据的方法及系统
Devignes et al. BioRegistry: Automatic extraction of metadata for biological database retrieval and discovery
CN108959308A (zh) 一种应对可追加数据的索引方法
KR101142062B1 (ko) 멀티미디어 데이터의 문자 기반 메타데이터 검색을수행하는 데이터 베이스 장치 및 방법

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20100831

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20101126

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20110329

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110729

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20110808

A912 Re-examination (zenchi) completed and case transferred to appeal board

Free format text: JAPANESE INTERMEDIATE CODE: A912

Effective date: 20110916