JP2014130492A - インデックスの生成方法及び計算機システム - Google Patents

インデックスの生成方法及び計算機システム Download PDF

Info

Publication number
JP2014130492A
JP2014130492A JP2012288087A JP2012288087A JP2014130492A JP 2014130492 A JP2014130492 A JP 2014130492A JP 2012288087 A JP2012288087 A JP 2012288087A JP 2012288087 A JP2012288087 A JP 2012288087A JP 2014130492 A JP2014130492 A JP 2014130492A
Authority
JP
Japan
Prior art keywords
index
filling rate
buffer memory
capacity
page
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
JP2012288087A
Other languages
English (en)
Inventor
Yuya ISODA
有哉 礒田
Kazutomo Ushijima
一智 牛嶋
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.)
Hitachi Ltd
Original Assignee
Hitachi 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 Hitachi Ltd filed Critical Hitachi Ltd
Priority to JP2012288087A priority Critical patent/JP2014130492A/ja
Publication of JP2014130492A publication Critical patent/JP2014130492A/ja
Pending legal-status Critical Current

Links

Images

Landscapes

  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

【課題】データベースを参照する際の参照コストの増加を抑制したインデックス生成方法及び計算機システムを提供する。
【解決手段】SQL処理部111、パラメータ管理部112、バッファメモリ115、バッファメモリ管理部114、パラメータ生成部113、インデックス生成部116からなり、パラメータ生成部はパラメータ管理部から生成するインデックスの基本情報、テーブル情報、バッファメモリ容量を取得し、バッファメモリ容量と生成するインデックスの容量を比較してインデックスの階層ごとに充填率を計算する手段と、新たに生成する前記インデックスの容量と前記バッファメモリの前記格納領域の容量とを比較する手段と、比較の結果、前記バッファメモリ容量の容量が不足する場合には、該インデックスの前記葉ノードの充填率を高くして前記階層ごとに前記充填率を再設定した新たな前記インデックスを生成する手段とを持つ計算機システム。
【選択図】図1

Description

本発明は、インデックスを生成する方法及び計算機システムに係り、特に、大規模なデータを処理して情報検索を行う計算機システムにおいて、計算機システムが保持するバッファメモリの容量に最適な木構造のインデックスを生成する方法及び装置に関する。
従来から、データベースやファイルシステムなどで検索を行う際に、情報が格納されたテーブルを高速に検索するために、インデックスと呼ばれるデータ構造が用いられている。また、インデックスは、レコードの追加、削除、更新などにも使用され、一般的にレコードの操作を補助する役割を持つ。
インデックスのデータ構造として、木構造のインデックスであるBalanced Tree(B木)がよく知られており、データベースやファイルシステムなどに用いられている。木構造は、接点(ノード:node)と辺(エッジ:edge)で構成されている。一般的には、各ノードは1つ以上のエッジを格納するページと呼ばれるデータ構造を持ち、エッジはキー値とポインタで構成されている。インデックスは、テーブルの特定列の値を高速に検索するために、特定列の値をもとに生成されている。キー値とは、インデックスを生成する特定列の値である。ポインタは、インデックスのページを示す情報である。また、木構造の最上位層のノードを根ノード(root node)、中間層のノードを内部ノード(internal node)、最下位層のノードを葉ノード(leaf node)と呼び、これらが相互にリンクしている。非特許文献1によれば、B木アルゴリズムは、根ノードから全ての葉ノードまでの階層数を全て同じにする木構造を有していることが特徴である。
B木インデックスにレコードを追加するとき、レコードのエッジは葉ノードのページに空きがあれば、エッジを追加することができる。しかし、ページにエッジを格納する空きが無ければ、エッジ数が半分となるようにページを2つに分割し、上位層の内部ノードのページに分割したページに対するエッジを追加する必要がある。また、内部ノードのページにもエッジを格納する空きが無ければ、同様の処理がより上位層のノードにも伝播する。このページ分割が根ノードに達し、根ノードのページにもエッジを格納する空きが無ければ、B木インデックスの階層数は1つ増える。
このように、B木インデックスのレコード追加で発生するページ分割は、処理負荷が大きく、インデックスの階層が増える場合には検索速度の低下を招く。
レコード追加時のページ分割回数を削減する手法として、特許文献1に開示の技術がある。特許文献1では、時間経過に伴ってインデックスに追加するレコードのキー値の単調増加、単調減少、ゆらぎ(キー傾向)を判定する。このキー傾向の判定結果に基づいてレコード追加時に発生するページ分割で、2つのページが持つエッジの分割割合(充填率)を変更する手法が開示されている。この手法によって、ページの分割回数削減によるレコードの追加処理負荷軽減とページの充填率変更によるインデックス容量の削減が実現されている。
また、処理速度を向上させる手法としては、非特許文献1に開示の技術がある。非特許文献1では、計算機システムのメモリに従来よりも多くのインデックスを格納するために、インデックスのページを圧縮することやメモリとストレージでページの構造を変える手法が開示されている。非特許文献1に開示の技術を用いることによって、レスポンス時間の大きいストレージアクセス回数の削減、処理速度の向上を実現できる。
B木インデックスでは、上述したレコードの追加やインデックスの作成以外にも、レコードの追加や削除によって生じる各ページに格納するエッジの充填率の偏りやインデックスの階層数の増加に対処するために、B木インデックスの再構成を行う。B木インデックスの再構成のタイミングやページの充填率を求める手法としては、特許文献2に開示の技術がある。特許文献2によれば、B木インデックスの作成後に追加されたページ数や削除されたページ数などによって再構成が必要か判断する。再構成が必要と判断した場合、ページの充填率を計算し、B木インデックスの再構成を行う手法が開示されている。
また、特許文献2には、B木インデックスを作成する際に、レコードの追加を想定して予めページの充填率を低くする手法についても開示されている。
特開2008−123426号公報 米国特許第5、446、887号公報
Goetz Graefe、Modern B−Tree Techniques、In proc.of the Foundations and Trends(登録商標) in Databases、Vol.3、No.4、pp 203−402、April、 2011
近年、大容量・高速なストレージ技術の進歩によって、従来では管理・活用しきれなかった膨大なデータを、計算機システムのデータベースやファイルシステム(以下、データベース)で記録・保管し短時間で検索することでビジネス上有利な情報の抽出や新たなサービスの創出が期待されている。
データベースを用いた大規模な検索を行うとき、必要なデータを高速に取得するためにインデックスを使用する。一般的に、データベースで扱うデータはストレージに格納されており、データを取得する際に複数回のストレージアクセスが必要となる。
従来、データを高速に取得するために、一部又は全てのインデックスをサーバのメモリに格納しストレージへのアクセス回数(平均I/O数)を削減してきた。しかし、データベースに記録・保管するデータ量の増加に伴いインデックス容量が増加し、メモリに格納できるインデックス容量の比率が減少することによって、レスポンス時間の大きいストレージアクセス回数が増加しデータベースの処理速度が低下する問題が発生している。
例えば、ビックデータの活用を図るデータ処理システムでは、データベースに格納するレコード数が大幅に増加している。これに起因して、インデックスのデータも大規模化し、上下の階層数も大きくなっている。そのため、従来は、インデックスの殆どをサーバのバッファメモリにキャッシュできていたものが、インデックスの一部しかバッファメモリにキャッシュできない状況が発生している。このような状況下では、下位の階層の殆どのインデックスがストレージに格納されることにより、サーバのI/O発行回数が増加し、クリエの実行時間が長くなるという問題が発生している。
一方、ストレージへのアクセス回数を削減するためにインデックスの階層数を減らす変更を行うと、その変更に伴う追加処理(インデックスの再構成の処理等)に時間を要し、コストアップの要因となる。
非特許文献1に開示された技術では、データベースのインデックスの更新のコストが低減される。しかし、非特許文献1では、更新のための空き容量を確保するのにインデックスのページの圧縮やメモリとストレージでページの構造を変える方式を採用しているため、データ量が大幅に増加したことに伴うインデックスデータの大規模化に伴い、インデックスを再構成する処理のコストが大幅に増加すると考えられる。
上記特許文献1に開示された技術では、インデックス毎にキー系列の傾向をモニタリングし、この傾向に応じてインデックス毎の充填率を変更している。しかし特許文献1では、インデックスデータの大規模化に伴う上記課題、すなわち階層数の増加に伴うサーバのI/O発行回数の増加については配慮されていない。
上記特許文献2に開示された技術では、B木インデックスの再構成を行う際の最適化方法として、全てのページで最も高くなる平均充填率を計算し、この平均充填率を全てのページに割り当てている。しかし、特許文献2では、インデックスデータの大規模化に伴う上記課題、すなわち階層数の増加に伴うサーバのI/O発行回数の増加については配慮されていない。また、追加処理に伴う性能の維持についても配慮されていない。
本発明の主たる解決課題は、サーバ等の計算機システムのバッファメモリに格納できるインデックス容量が制限された状況下において、データベースを参照する際の参照コストの増加を抑制したインデックスを生成することのできる、インデックス生成方法及び計算機システムを提供することにある。
本発明の代表的なものを示すと、次のとおりである。プロセッサとバッファメモリと記憶装置とを備えた計算機システムであって、前記記憶装置は、情報が格納されたテーブルを有し、前記バッファメモリ及び前記記憶装置は、各々、前記テーブルを検索するためのインデックスの格納領域を有しており、前記インデックスは、根ノードと葉ノードを含む複数のノードからなる階層構造のインデックスであり、前記計算機システムは、新たに生成する前記インデックスの容量と前記バッファメモリ容量とを比較して前記インデックスの階層ごとに充填率を計算する機能と、設定された条件の範囲で各階層の前記充填率を小さくする機能と、新たに生成する前記インデックスの容量と前記バッファメモリの前記格納領域の容量とを比較する機能と、比較の結果、前記バッファメモリ容量の容量が不足する場合には、該インデックスの前記葉ノードの充填率を高くして前記階層ごとに前記充填率を再設定した新たな前記インデックスを生成する機能とを有することを特徴とする。
本発明により、大規模なデータを処理する計算機システムにおいて、ストレージのアクセス回数を削減することができ、計算機システムの処理時間を短くする、ひいては参照コストを低減することができる。
本発明の一実施形態に係る計算機システムの構成を示す機能ブロック図である。 図1のユーザ設定情報の一例を示す図である。 図1のテーブル管理情報の一例を示す図である。 図1のインデックス管理情報の一例を示す図である。 図1のテーブルの一例を示す図である。 図1のインデックスの一例を示す図である。 本発明の一実施形態に係る計算機システムのハードウェア及びソフトウェアの構成例を示す図である。 本発明の一実施形態の動作を示すブロック図である。 本発明の一実施形態の動作を示すブロック図である。 図1に示すパラメータ生成部の動作を示すフローチャート図である。 図9に示す動作におけるインデックスの計算の処理の詳細を示すフローチャート図である。 図9に示す動作におけるステップS810の処理の詳細を示すフローチャート図である。 最適化処理前のインデックス管理情報と最適化処理後のインデックス管理情報の例を示す図である。 初期状態のインデックスの階層構造の例を示す図である。 最適化処理後のインデックスの階層構造の例を示す図である。
本発明は、サーバのメモリに格納できるインデックス容量が制限された状況下において、メモリに格納できるインデックス容量に応じてインデックスの階層ごとにページの充填率を変更することによって、ストレージアクセス回数を削減するインデックスを生成する方法及び計算機システムである。
本発明の1つの実施形態によれば、計算機システムは、ユーザや他の計算機システムからの処理要求を実行するSQL処理部、処理結果の情報を管理するパラメータ管理部、バッファメモリ、バッファメモリの使用用途や容量を管理するバッファメモリ管理部、インデックスを生成するためのパラメータを生成するパラメータ生成部、インデックスを生成するインデックス生成部からなり、パラメータ生成部はパラメータ管理部から生成するインデックスの基本情報、テーブル情報、バッファメモリ容量を取得し、バッファメモリ容量と生成するインデックスの容量を比較してインデックスの階層ごとに充填率を計算する手段と、新たに生成する前記インデックスの容量と前記バッファメモリの前記格納領域の容量とを比較する手段と、比較の結果、前記バッファメモリ容量の容量が不足する場合には、該インデックスの前記葉ノードの充填率を高くして前記階層ごとに前記充填率を再設定した新たな前記インデックスを生成する手段とを持つ。
なお、以下の実施例では、木構造のインデックスとしてB木を例に説明するが、本発明はこれに限定されるものではなく、B*木や、B+木にも適用可能である。
以下、本発明のインデックスを生成する方法およびインデックスを生成するための計算機システムの一実施例を説明する。
図1は本発明における、ストレージのアクセス回数を削減するために、インデックスの階層ごとに異なる充填率を指定してインデックスを生成するシステム構成を示すブロック図である。
計算機システム110は、SQL(Structured Query Language)処理部111、パラメータ管理部112、パラメータ生成部113、バッファメモリ管理部114、バッファメモリ115、インデックス生成部116、及び、データ部120を備えている。
ユーザ100は、計算機システム110へ処理命令、パラメータの設定値、テーブルのレコード情報を、入力データ130として送信する。計算機システム110は、この入力データ130の処理命令等に基づいて処理を実行し出力データ140としてのインデックスを生成し、この出力データ140をユーザ101へ送信する。
計算機システム110のデータ部(記憶装置)120は、1以上のユーザ設定情報200、1以上のテーブル管理情報300、1以上のインデックス管理情報400、1以上のテーブル500、1以上のインデックス600を含む。バッファメモリ115は、記憶装置120が保持する上記情報やテーブル(200、300、400、500、600)のデータの一部又は全てを一時的に保持する。
パラメータ生成部113は、テーブル500に対するパラメータの階層構造を最適化する機能、インデックス生成部116は、テーブル500に対するインデックスの階層構造を最適化する機能を備えている。
図2Aは、ユーザ設定情報200の構成例である。ユーザ設定情報200は、各インデックス名に対応して複数(200A〜200N)存在する。ユーザ設定情報200には、テーブル500やインデックス600を生成するための情報201〜206が含まれており、これらの情報はテーブルやインデックスごとに指定することもできる。
パラメータ名201は、インデックス名202、レコードのキー値及びページのポインタからなるエッジやレコードを格納するページサイズ203、ページに格納するエッジやレコードの最大充填率204、ページに格納するエッジやレコードの最小充填率205、テーブルやインデックスが利用可能なバッファメモリ容量206を持つ。設定値210には、パラメータ名201に対応する数値データが格納される。
図2Aのユーザ設定情報200Aは、各パラメータの設定値210として、インデックス名202を社員番号、ページサイズ203を4KB、最大充填率204を90%、最小充填率205を60%、バッファメモリ容量206を1GBとした例である。最大充填率204は,ページサイズ203の90%まで使用できることを示しており,残りの10%を追加処理で使用する領域である。最小充填率205は、少なくとも60%以上の領域を使用することを示している。ここでは、計算機システムのバッファメモリに格納できるインデックス容量が10GBに制限されたとすると、この中で社員番号に関して1GBが割り当てられているものとする。
なお、ユーザ設定情報200を記憶装置120に保持せず、ユーザ100がユーザ設定情報を入力データ130に含めて計算機システム110に通知してもよい。
図2Bは、テーブル管理情報300の構成例である。テーブル管理情報300は、テーブルごとに生成され、パラメータ名301とパラメータ名301に対応する数値310を保持する。パラメータ名301は、インデックス名302、テーブルのレコード数303、テーブルのレコードの列のキー長304を持つ。
図2Bのテーブル管理情報300は各パラメータの数値310として、インデックス名302を社員番号、レコード数303を100000000、キー長304を12Bとした例である。
図3は、インデックス管理情報400の構成例である。インデックス管理情報400は、インデックスごとに生成され、パラメータ名401とパラメータ名401に対応する数値410を保持する。パラメータ名401は、インデックス名402、インデックスの階層数403、葉ノードの最大エッジ格納数404、内部ノードの最大エッジ格納数405、根ノードの最大エッジ格納数406、インデックスの各階層のページ数420〜423、インデックスの各階層の充填率430〜433、インデックスの各階層のページの総容量440〜443を保持する。図3の420〜423、430〜433、440〜443で示すインデックスの階層は、420、430、440が葉ノード、421、422、431、432、441、442が内部ノード、423、433、443が根ノードを示す。
図3は、各パラメータの数値410として、階層数(n)403を4、葉ノードの最大エッジ格納数404を200、内部ノードの最大エッジ格納数405を200、根ノードの最大エッジ格納数406を200、1階層のページ数420を625000、2階層のページ数421を3125、n−1階層のページ数422を16、n階層のページ数423を1、1階層の充填率430を80%、2階層の充填率431を100%、n−1階層の充填率432を100%、n階層の充填率433を8%、1階層の容量440を2500MB、2階層の容量441を12500KB、n−1階層の容量442を64KB、n階層の容量443を4KBとした例である。
インデックスの各階層のページ数420〜423は、インデックスの各ノードの最大エッジ格納数404〜406、インデックスの各階層の充填率430〜433、テーブルのレコード数303によって求まる。例えば、インデックスのページ数である420をp1、421をp2、422をp3、423をp4とし、インデックスの最大エッジ格納数である404をe1、405をe2、406をe3とし、インデックスの充填率である430をf1、431をf2、432をf3、433をf4とし、テーブルのレコード数をrとするとき、p1〜4は式(1〜4)となる。このとき、p1〜4は小数点以下切り上げの整数値とする。
p1=r/(e1×f1)・・・(1)
p2=p1/(e2×f2)・・(2)
p3=p2/(e2×f3)・・(3)
p4=p3/(e3×f4)・・(4)
このとき、インデックスの各階層のページの総容量440〜443は、それぞれインデックスの各階層のページ数420〜423とインデックスのページサイズ203を乗算することによって求めることができる。例えば、インデックスの各階層のページの総容量である440をsizep1とし、インデックスのページサイズである203をpagesizeとしたとき、sizep1は式(5)とする。
sizep1=p1×pagesize・・・(5)
図4は、テーブル500の一例を示すものである。本実施例では、テーブルとして従業員テーブルを用いて説明する。テーブル500は、「社員番号」、「名前」、「部署」、「年齢」等のインデックスがあり、何れかのインデックスをキーにして従業員に関する情報の検索・利用ができる。
図5は、インデックス600の構造例としてB木インデックスの構造を示す。インデックス600の最上位層を根ノード601、中間位層を内部ノード603、最下位層を葉ノード604と呼び、インデックス600の上下の階層は1つ以上のエッジ602によって関連付けられている。テーブル500、本実施例では従業員テーブルが、1以上のページ501〜503を含む。エッジ602は、キー値611とインデックスのページ610又はテーブルのページ501〜503へのポインタ612によって構成されており、インデックスのページ610に1以上格納されている。
ページ610が保持可能なエッジ602の最大格納数404〜406は、インデックスのページサイズ203、キー値611のキー長304、ページのポインタ612のサイズ、ページの構成内容によって定まる。ページの構成内容は、データベースやファイルシステムによって異なる。本発明の一実施形態では、式(6)を用いてエッジの最大格納数404〜406を設定する。例えば、インデックスのエッジの最大格納数である404をe1とし、インデックスのページサイズである203をpagesizeとし、キー長である304をkとし、インデックスのページのポインタ612のサイズをpointersizeとし、ページサイズ203のうちエッジ602を格納することができない領域をnsizeとするとき、e1は式(6)とする。
e1=(pagesize−nsize)/(k+pointersize)・・・(6)
図5の例では、インデックス600の階層数が3であり、1階層の葉ノード604には60個余のエッジ602があり、テーブルのページ501〜503に対するエッジ(ポインタ612)が6枚のページ610に均等に格納され、エッジのキー値611として1、6、−、−、59が設定されている。2階層の内部ノード603には2枚のページに均等にエッジが格納され、キー値611として10、21、42、53が設定され、これに基づいて上下の階層である内部ノード603と葉ノード604は、6つのエッジ(ポインタ612)によって関連付けられている。同様に、3階層の根ノード601には1枚のページ610に全エッジが格納されており、キー値611として、30が設定され、これに基づいて上下の階層が2つのエッジ(ポインタ)によって関連付けられている。
図6は、コンピュータすなわち汎用のサーバ、ストレージ、サーバ上で動作するアプリケーションを用いて本発明のインデックス生成装置を実現するときのハードウェア構成例である。計算機システム700は、ネットワーク710と通信するための入出力装置701、データや命令を転送するためのバス702、命令を実行するためのプロセッサ703、メモリ705にデータや命令を格納するメモリコントローラ704を含む。ネットワーク710は、1つ以上の計算機システム700、720、1つ以上の外部記憶装置(ストレージ)730を繋ぐ。計算機システム700、720は、ユーザ100、101によって処理命令を指定することが可能である。計算機システム700、720が使用するデータは、外部記憶装置730と計算機システム700、720が保持するメモリ705に格納される。
例えば、図1のSQL処理部111、パラメータ管理部112、パラメータ生成部113、バッファメモリ管理部114、インデックス生成部116を、図6のプロセッサ703で動作するプログラムにより実現し、メモリ705の一部をバッファメモリ115とし、外部記憶装置(ストレージ)730をデータ部120として実装することができる。また、バッファメモリ管理部114は、メモリコントローラ704にハードウェア又はソフトウェアで実装することもできる。
図7は、本発明における、テーブル管理情報300やテーブル500の作成及び更新処理、ユーザ設定情報200の作成及び更新処理の流れを示すブロック図である。
計算機システム110は、SQL処理部111にユーザ100から処理命令132、設定値133、レコード134の少なくとも1つを入力データ131として通信150を通して受信する。
SQL処理部111は、処理命令132が「テーブルの作成」を指示する場合、テーブル500の作成を行うためにバッファメモリ115が必要になるならば、通信151を通してバッファメモリ管理部114へバッファメモリ115の確保を命令する。
バッファメモリ管理部114は、バッファメモリ115を監視しておりSQL処理部111の命令に基づいてバッファメモリ115を確保し、SQL処理部111へ通信151を通じてバッファメモリ115の確保完了通知を送信する。
SQL処理部111は、バッファメモリ115の確保が完了すると、通信153を通じてデータ部120にテーブル500を作成しレコード134を追加する。このとき、SQL処理部111は、作成するテーブル500のテーブル名(インデックス名)302、レコード数303、レコード134のキー長304をパラメータ管理部112へ通信154を通じて送信する。
パラメータ管理部112は、SQL処理部111から受信したデータに基づき、通信155を通じてデータ部120にテーブル管理情報300を作成し、インデックス名302、レコード数303、キー長304を更新する。このとき、パラメータ管理部112がバッファメモリ115を必要とするならば、通信156を通じてSQL処理部111と同様の命令をバッファメモリ管理部114へ送信し、バッファメモリ115を確保する。パラメータ管理部112は、SQL処理部111からのデータを全てテーブル管理情報300に更新すると、通信154を通じてSQL処理部111へ完了通知を送信する。
SQL処理部111は、パラメータ管理部112からの完了通知を受け取ると、通信157を通じてユーザ101へ処理命令132の完了通知を出力データ141として送信する。
SQL処理部111は、処理命令132が「レコード134の更新又は追加又は削除」を指示する場合、処理命令132の実行にバッファメモリ115が必要になるならば、前記と同様にバッファメモリ115を確保する。SQL処理部111は、バッファメモリ115の確保が完了すると、通信153を通じてデータ部120に対して「レコード134の更新又は追加又は削除」を、バッファメモリ115を使用して行う。このとき、SQL処理部111は、テーブル500のテーブル名、レコード134のキー長、レコード数を、パラメータ管理部112へ通信154を通じて送信する。
パラメータ管理部112は、前記と同様にテーブル管理情報300を更新する。パラメータ管理部112は、SQL処理部111からのデータを全てテーブル管理情報300に更新すると、通信154を通じてSQL処理部111へ完了通知を送信する。SQL処理部111は、パラメータ管理部112からの完了通知を受け取ると、通信157を通じてユーザ101へ処理命令132の完了通知を出力データ141として送信する。
SQL処理部111は、処理命令132が「ユーザ設定情報200に設定値133を更新又は追加」である場合、通信154を通じて設定値133と設定値133を反映するユーザ設定情報200の識別子をパラメータ管理部112へ送信する。パラメータ管理部112がバッファメモリ115を必要とするならば、通信156を通じて前記と同様の命令をバッファメモリ管理部114へ送信し、バッファメモリ115を確保する。パラメータ管理部112は、SQL処理部111からのデータをユーザ設定情報200に反映すると、通信154を通じてSQL処理部111へ完了通知を送信する。SQL処理部111は、パラメータ管理部112からの完了通知を受け取ると、通信157を通じてユーザ101へ処理命令132の完了通知を出力データ141として送信する。
図8は、本発明の実施例における、インデックス管理情報400やインデックス600の作成処理の流れを示すブロック図である。
計算機システム110は、インデックス生成部116にユーザ100から処理命令136、設定値137の少なくとも1つを入力データ135として通信160を通して受信する。
インデックス生成部116は、処理命令136からテーブル500のテーブル管理情報300に記載されているキー長304に対する「インデックス600の生成命令」を受信すると、インデックス管理情報400を作成するために通信161を通じてパラメータ生成部113へ入力データ135を送信する。
パラメータ生成部113は、入力データ135に基づいて、ユーザ設定情報200、テーブル管理情報300、テーブル500の情報を、通信162を通じてパラメータ管理部112から受信する。
パラメータ管理部112は、通信164を通じてバッファメモリ管理部からバッファメモリ115の監視情報を取得し、通信163を通じてデータ部120からユーザ設定情報200、テーブル管理情報300、テーブル500を取得する。
パラメータ生成部113は、入力データ135、ユーザ設定情報200、テーブル管理情報300、テーブル500に基づいて、パラメータの階層構造の最適化機能により最適化された「インデックス管理情報」400を作成する。パラメータ生成部113は、生成したインデックス管理情報400を、通信162を通じてパラメータ管理部112へ送信する。また、パラメータ生成部113は、通信161を通じてインデックス生成部116にインデックス管理情報の生成完了通知を送信する。
パラメータ管理部112は、受信したインデックス管理情報400を、通信163を通じてデータ部120に送信する。
インデックス生成部116は、インデックス管理情報400の生成完了通知を受信すると、パラメータ管理部112からインデックス管理情報400の取得を、通信166を通じて要求する。インデックス生成部116は、取得したインデックス管理情報400と入力データ135に基づいて、インデックスの階層構造の最適化機能により最適化された「インデックス」600を生成する。インデックス600は、インデックスの階層によって充填率を指定するが、充填率が均一な一般的なインデックスの生成方法をもとにして生成することができる。インデックス生成部116は、生成したインデックス600を、配線167を通じてデータ部120に格納する。このとき、インデックス生成部116は、インデックス600の根ノードのページから順に配線168、165を通じてバッファメモリ115に格納してもよい。
インデックス生成部113は、インデックス600を指定した場所に格納したあと、配線169を通じてインデックスの完了通知を出力データ142としてユーザ101に送信する。
次に、パラメータ生成部113によるパラメータの階層構造の最適化処理、及び、インデックス生成部116によるインデックスの階層構造の最適化処理に関して、図9〜図14を参照しながら説明する。
図9は、パラメータ生成部113における、インデックスの各階層のページ数420〜423、インデックスの各階層の充填率430〜433、インデックスの各階層のページの総容量440〜443を計算する処理を実行するフローチャート800である。
フローチャート800は、「インデックスの生成命令」によって処理が開始される。ステップS801ではバッファメモリの容量に関する情報を取得する。ステップS802ではテーブル500の1つのインデックス名を取得し、このインデックス名に関して、ステップS803はユーザ設定情報200、ステップS804はテーブル管理情報300、ステップS805はインデックス管理情報400を参照し、各々、最適なインデックス600を生成するために必要なパラメータを取得する。
ここでは、処理の対象となるテーブルのインデックス名を「社員番号」とし、サーバのバッファメモリに格納できるインデックス容量が制限された状況下において、ユーザにより「社員番号」のバッファメモリ容量が1GBに設定されており、バッファメモリ格納領域が4ページ(ノード)のデータをキャッシュすることができるものとする。
図12に、最適化処理前のインデックス管理情報400Aと最適化処理後のインデックス管理情報400Bの例を示す。最適化処理前の各パラメータの数値は、インデックスの階層数が3であり、葉ノード、内部ノード及び根ノードの各最大エッジ格納数が5、3、3であり、1階層、2階層及び3階層の各ページ数が9、3、1であり、1階層、2階層及び3階層の各充填率が60%、100%、100%となっている。
図13に、初期状態のインデックス600の階層構造を示す。この例では、下層のテーブル500のページ501〜503に対応する、1階層の9ページの葉ノード604がストレージ格納領域に存在し、葉ノードの各ページに均等に3個ずつエッジ602が格納されている。バッファメモリ格納領域620に存在する2階層の内部ノード603には、3枚のページに均等にエッジが格納され、キー値611として4、7、13、16、22、25が設定され、これに基づいて内部ノード603と葉ノード604は、9つのエッジ(ポインタ612)によって関連付けられている。同様に、バッファメモリ格納領域620に存在する3階層の根ノード601には、1枚のページ610に全エッジが格納され、キー値611として10、19が設定され、これに基づいて根ノード601と内部ノード603とが3つのエッジ(ポインタ612)によって関連付けられている。
図9に戻って、ステップS806では、各ノードの最大エッジ格納数404〜406を式(6)に基づいて計算する。
すなわち、ステップS806では、インデックスの階層数403、インデックスの各階層の充填率430〜433、インデックスの各階層のページ数420〜423をテーブルのレコード数304、各ノードの最大エッジ格納数404〜406、インデックスの最大充填率205、インデックスの最小充填率206から、「最大エッジ格納数」を計算する。
図13の例では、インデックスの階層数が3、インデックスの1〜3階層の充填率が60%、100%、100%であり、各ノードの「最大エッジ格納数」は、各々、5、3、3であり、各ノードのページ数は、各々、9、3、1である。
ステップS807では、インデックスの各階層のページの総容量440〜443を式(5)に基づいて、最適なインデックスを計算する。ステップS807の「インデックスの計算」の処理内容は、図10のフローチャート900に記載する。
ステップS808では、バッファメモリの容量と計算によって求められたインデックスの容量とを比較し、インデックスの全階層のページをバッファメモリに配置可能か否かを判定する。ステップS808の判定でNoの場合は、1階層すなわち葉ノードの充填率を高くして、再計算を行う(S810)。図13に示した例では、バッファメモリ格納領域が4ページであり、インデックス「社員番号」の全階層のページをバッファメモリに格納できないので、ステップS808の判定がNoとなり、ステップS810の処理が必要になる。このステップS810の処理内容は、図11のフローチャート1000に記載する。
一方、ステップS808の判定でYesの場合、インデックスの全てのページを格納してもバッファメモリに空き容量があると判断できる。
そこで、各ノードの充填率を小さくして、再計算を行う(S809)。すなわち、バッファメモリからインデックスの全てのページが溢れないように、インデックスの各階層の充填率430〜433を最大充填率205と最小充填率206の範囲内で小さくする最適化処理を行う。もし、最大充填率205及び最小充填率206の設定がなければ、インデックスの各階層の充填率430〜433を可能な限り小さくする。
このように、パラメータ生成部113は、パラメータの階層構造の最適化機能により各ページが持つエッジのポインタの充填率を最適値に管理する、すなわち、各階層の充填率を設定された条件の範囲で小さくすることによって、計算機システムのデータ解析の処理速度を維持しつつ、レコード追加時のページ分割の回数を削減することができる。
上記の各処理を、テーブル500の全てのインデックス名に対して行い(S811)、終了する(S812)。
図10は、インデックスの計算(S807)のフローチャート900である。
ステップS902では、インデックスの各階層の充填率430〜433を最大充填率205か最小充填率206のうち大きい値とする。もし、最大充填率205と最小充填率206の指定が無ければ、インデックスの各階層の充填率430〜433に一時的に適当な値を指定する。例えば、作成するインデックスが参照のみの処理命令を実行する場合、インデックスの各階層の充填率430〜433を100%とする。
ステップS903では、葉ノードのページ数420を式(1)に基づいて計算する。
ステップS904では、次に計算するインデックスの階層が根ノードであるか判定する。判定方法として、葉ノードのページ数420が根ノードの最大エッジ格納数406より小さいか判断する。
ステップS904の判定でNoの場合、ステップS905で内部ノードのページ数を式(2、3)に基づいて計算する。ここで、ステップS904の判定でYesになるまで、繰り返しインデックスの各階層の内部ノード421、422を式(2、3)に基づいて計算する。
ステップS904の判定でYesの場合、ステップS906で根ノードのページ数423を式(4)に基づいて計算する。このとき、ページ数を求めた回数を0からカウントし、カウントした値がインデックスの階層数403となる。このようにして、インデックスの階層構造の最適化処理機能により、ユーザ設定情報やバッファメモリの容量などに応じた、最適のインデックスの階層構造が生成される。
図11は、図9のステップ810の葉ノードの充填率の処理、すなわち、インデックスのバッファメモリ容量207にインデックスの全てのページが格納できない場合に、インデックスの各階層の充填率430〜433を算出するフローチャート1000である。
ステップS1002では、葉ノードの充填率430を求め、余裕があるかを判定する。ステップS1002で余裕がなければ、そのままステップS1004に進む。余裕があれば、ステップS1003で葉ノードの充填率を最大充填率205以下の範囲で大きく設定してから、ステップS1004に進む。ステップS1003において、もし、最大充填率205の設定があれば、葉ノードの充填率430を最大充填率205まで引き上げる。次に、最大充填率205の設定が無く最小充填率206の設定があれば、葉ノードの充填率430を最小充填率206とする。もし、最大充填率205及び最小充填率206の設定が無ければ、葉ノードの充填率430に一時的に適当な値を指定する。例えば、作成するインデックスが参照のみの処理命令を実行する場合、葉ノードの充填率430を100%とする。
図13の例では、葉ノードの充填率が60%になっているので、この充填率をここでは100%と高く設定し、インデックス管理情報400B(図12)の数値を更新する。なお、ここでは説明を簡単にするために葉ノードの充填率を便宜上100%として説明するが、実際の葉ノードの充填率は図2Aの最大充填率(90%)もしくはそれ以下に設定する。これは、高コストなページ分割を避け、追加処理を容易にするためである。
ステップS1004では、新たな設定に基づき、葉ノードの各エッジの充填率を再計算する。図13の例では、「最大エッジ格納数」が5なので、27個のエッジを、各ページに最大5個ずつ(100%)格納することができる。
ステップS1005では、葉ノードのページ数420を式(1)に基づいて計算する。図13の例では、1階層のページ数が6となり、この値がインデックス管理情報400Bに反映される。
ステップS1006は、内部ノードの充填率とページ数を、葉ノードのページ数420、最小充填率206から算出する。このとき、葉ノードに近い内部ノードから順番に充填率を算出する。また、内部ノードの充填率は、最小充填率206以上であり、葉ノードに近い内部ノードの充填率431ほど高く設定し、根ノードに近い内部ノードの充填率432ほど低くなるように設定する。葉ノードに近い内部ノードの充填率から順に、充填率を可能な限り大きくしてまで計算する。もし、ある階層のページ数422が根ノードの充填率433と最大エッジ格納数406の積より小さい場合、根ノードの充填率433はページ数422を最大エッジ格納数406で割った値とする。このとき、ページ数を求めた回数を0からカウントし、カウントした値がインデックスの階層数となる。これらの計算結果に基づき、インデックス管理情報400B(図12)の数値が更新される。この例では、インデックスの階層数は3のままである。
次にステップS1007では、ステップS807で計算したインデックスの階層数403とステップS1006で計算したインデックスの階層数を比較する。
ステップS1006で求めた階層数がステップS807で求めた階層数より大きい場合、ステップS1008で葉ノードの充填率430をユーザ設定の範囲で低くした再設定を行い、ステップS1005の処理に戻る。
以下、ステップS1007の判定でYesになるまで、繰り返しインデックスの葉ノードの充填率430を変更し、階層数に変更が無い範囲で、葉ノードの充填率を最適化し、これに応じて内部ノードと根ノードのページ数や充填率を再設定する(ステップS1005〜S1007)。例えば、あるインデックスの初期状態の階層数が4で、かつ、葉ノードの充填率が60%であった状態から、葉ノードの充填率を90%に上げた結果、インデックスの階層数が3に減少し上記判定がNoになったと仮定する。この場合には、葉ノードの充填率を下げて各ノードのページ数や充填率を再設定してステップS1005〜ステップS1006を実行し、その結果、例えば充填率80%でインデックスの階層数が4となった場合には、葉ノードの充填率を80%に決定する。
ステップS1006で求めた階層数がステップS806で求めた階層数以下の場合、インデックスの階層数403をステップS1006で求めた階層数に更新し、フローチャート1000の処理を終了し、フローチャート800の処理に戻る。フローチャート800に戻ってきた処理は、ステップS811に移り処理を継続、若しくは終了する。
図14に、インデックス管理情報400Bに対応する最適化処理後のインデックス600の階層構造の例を示す。この例では、ステップS1006で求められる階層数が3で変更がなく、1階層の葉ノードの27個のエッジが5枚のページに5個ずつ(100%)格納され、残りの2個のエッジが1枚のページに格納されている。2階層の内部ノード603には2枚のページに均等に全エッジが格納され、キー値として6、11、21、26が設定され、これに基づいて内部ノードと葉ノードは、6つのエッジ(ポインタ)によって関連付けられている。同様に、3階層の根ノード601には1枚のページに全エッジが格納されており、キー値として、16が設定され、これに基づいて根ノードと内部ノードとが2つのエッジ(ポインタ)によって関連付けられている。
図14の最適化処理後のインデックス600の階層構造を、図13の階層構造と比べると、インデックスの階層数に変化はない。一方、最適化処理前には、葉ノードの全てのエッジがストレージ格納領域に存在していたのに対し、最適化処理後には、1階層の葉ノードの5個のエッジを格納した1枚のページが、バッファメモリ領域620に存在している。これにより、テーブルに対する平均I/O数(ストレージへのアクセス回数)を削減できる。
すなわち、最適化処理前のインデックス階層構造によれば、バッファメモリ格納領域には内部ノード603までしかキャッシュすることができない。一方、最適化処理後のインデックス階層構造では、葉ノードの充填率を上げることで、内部ノードのみならず葉ノード604の一部(エッジ1〜5)までバッファメモリ格納領域630にキャッシュすることができ、根ノードから葉ノードを介してテーブル500のデータに直接アクセスできる。このように、従来であればI/Oの発行が必要であったインデックスの一部の領域をバッファメモリ格納領域630に変更して格納することができ、その結果、テーブル500のデータを取得するための平均I/O数を削減することが可能になっている。
B木インデックスの作成後に追加されたページ数や削除されたページ数などによって再構成が必要か判断され、再構成が必要と判断した場合、上記最適化処理が実行される。
本実施例によれば、サーバのバッファメモリ容量に応じてインデックス階層構造を変更することにより、サーバのストレージアクセス回数を削減することができる。すなわち、本実施例では、インデックス階層構造の階層毎に、各ページが持つエッジのポインタの充填率を最適値に管理することによって、バッファメモリにより多くのインデックスを格納することが可能となり、これにより、ストレージへのアクセス回数を削減し、かつ、追加処理コストの削減も図ることができる。
100…ユーザ、101…ユーザ、110…計算機システム、111…SQL処理部、112…パラメータ管理部、113…パラメータ生成部、114…バッファメモリ管理部、115…バッファメモリ、116…インデックス生成部、120…データ部(記憶装置)、130…入力データ、140…出力データ、ユーザ設定情報…ユーザ設定情報、300…テーブル管理情報、400…インデックス管理情報、500…テーブル、600…インデックス。

Claims (15)

  1. プロセッサとバッファメモリと記憶装置とを備えた計算機システムであって、
    前記記憶装置は、情報が格納されたテーブルを有し、
    前記バッファメモリ及び前記記憶装置は、各々、前記テーブルを検索するためのインデックスの格納領域を有しており、
    前記インデックスは、根ノードと葉ノードを含む複数のノードからなる階層構造のインデックスであり、
    前記計算機システムは、
    新たに生成する前記インデックスの容量と前記バッファメモリ容量とを比較して前記インデックスの階層ごとに充填率を計算する機能と、
    設定された条件の範囲で各階層の前記充填率を小さくする機能と、
    新たに生成する前記インデックスの容量と前記バッファメモリの前記格納領域の容量とを比較する機能と、
    比較の結果、前記バッファメモリ容量の容量が不足する場合には、該インデックスの前記葉ノードの充填率を高くして前記階層ごとに前記充填率を再設定した新たな前記インデックスを生成する機能とを有する
    ことを特徴とする計算機システム。
  2. 請求項1において、
    新たに生成する前記インデックスの階層数が元のインデックスの階層数に対して減少している場合には、前記葉ノードの充填率を低くし前記階層ごとに前記充填率を再設定することにより前記階層数が変化しないようにした新たな前記インデックスを生成する機能を有する
    ことを特徴とする計算機システム。
  3. 請求項2において、
    前記インデックスは、データを格納するページと、前記テーブルのページが保持するキー値と、前記各ページへのポインタを含み、
    前記記憶装置は、前記インデックスごとに生成されるインデックス管理情報を有し、
    前記インデックス管理情報は、前記インデックスの階層ごとの各階層のページ数及び充填率の情報を有しており、
    前記インデックスの容量と前記格納領域の容量との比較において、前記インデックスの全階層の前記ページを前記バッファメモリに配置可能か否かを判定する機能と、
    前記インデックスの前記ページの全てを格納しても前記バッファメモリに空き容量がある場合には、前記各階層のノードの充填率を小さくして新たな前記インデックスを生成するする機能とを有する
    ことを特徴とする計算機システム。
  4. 請求項2において、
    前記インデックスは、前記根ノードと前記葉ノードの間に少なくとも2階層の内部ノードを有し、かつ、データを格納するページと、前記テーブルのページが保持するキー値と、前記各ページへのポインタを含み、
    前記インデックスの容量と前記格納領域の容量との比較において、前記インデックスの全階層のページを前記バッファメモリに配置可能か否かを判定する機能と、
    前記インデックスの前記ページの全てを格納できない場合には、前記内部ノードの充填率が、前記葉ノードに近い前記内部ノードの充填率ほど高く、前記根ノードに近い前記内部ノードの充填率ほど低くなるように再設定して新たな前記インデックスを生成するする機能とを有する
    ことを特徴とする計算機システム。
  5. プロセッサとバッファメモリと記憶装置とを備えた計算機システムであって、
    前記記憶装置は、情報が格納されたテーブルを有し、
    前記バッファメモリ及び前記記憶装置は、各々、前記テーブルを検索するためのインデックスの格納領域を有しており、
    前記インデックスは、根ノードと葉ノードを含む複数のノードからなる階層構造のインデックスであり、
    前記計算機システムは、
    入力データに基づいて、前記インデックスを生成するためのパラメータをインデックス管理情報として生成するパラメータ生成部と、
    前記インデックス管理情報と前記入力データに基づいて、前記インデックスを生成するインデックス生成部とを備えており、
    前記インデックス管理情報は、前記インデックスの階層ごとのページ数及び充填率の情報を有しており、
    新たに生成する前記インデックスの容量と前記バッファメモリの前記格納領域の容量とを比較し、前記バッファメモリ容量の容量が不足している場合には、該インデックスの前記葉ノードの充填率を高くして前記階層ごとに前記充填率を再設定した新たな前記インデックスを生成する
    ことを特徴とする計算機システム。
  6. 請求項5において、
    新たに生成する前記インデックスの階層数が元のインデックスの階層数に対して減少している場合には、前記葉ノードの充填率を低くし前記階層ごとに前記充填率を再設定することにより前記階層数が変化しないようにした新たな前記インデックスを生成する
    ことを特徴とする計算機システム。
  7. 請求項6において、
    前記インデックスの容量と前記格納領域の容量との比較において、前記インデックスの全階層のページを前記バッファメモリに配置可能か否かを判定し、
    前記インデックスの前記ページの全てを格納しても前記バッファメモリに空き容量がある場合には、前記各階層のノードの充填率を小さくして新たな前記インデックスを生成する
    ことを特徴とする計算機システム。
  8. 請求項6において、
    前記入力データを受け付けて処理するSQL処理部と、
    前記SQL処理部の処理結果の情報を管理するパラメータ管理部と、
    前記バッファメモリの使用用途や容量を管理するバッファメモリ管理部とを備えており、
    前記記憶装置は、前記インデックスのインデックス名、レコード数、キー長の情報を含むテーブル管理情報を有し、
    前記パラメータ管理部は、前記SQL処理部から受信したデータに基づき、前記記憶装置に前記テーブル管理情報を作成し、前記インデックス名、前記レコード数、前記キー長を更新し、
    前記パラメータ管理部は、前記SQL処理部からの前記データを全て前記テーブル管理情報に更新し、
    前記パラメータ生成部及び前記インデックス生成部は、前記インデックス名毎に、前記階層構造の設定、更新を行う
    ことを特徴とする計算機システム。
  9. 請求項7において、
    前記記憶装置は、ユーザ設定情報及び前記インデックスごとに生成される前記インデックス管理情報を有し、
    前記ユーザ設定情報は、前記インデックス名毎に、レコードのキー値及び前記ページのポインタからなるエッジやレコードを格納するページサイズ、前記ページに格納するエッジやレコードの最大充填率、前記ページに格納する前記エッジや前記レコードの最小充填率、前記テーブルや前記インデックスが利用可能な前記バッファメモリ容量に関して、各々に対応する数値データが格納されており、
    前記インデックス管理情報は、前記パラメータ名として、前記インデックス名、前記インデックスの階層数、前記葉ノードの最大エッジ格納数、内部ノードの最大エッジ格納数、前記根ノードの最大エッジ格納数、前記インデックスの各階層の前記ページ数、前記インデックスの各階層の前記充填率、前記インデックスの各階層のページの総容量を保持しており、
    前記パラメータ生成部及び前記インデックス生成部は、前記ユーザ設定情報及び前記インデックス管理情報に基づいて前記階層構造の設定、更新を行う
    ことを特徴とする計算機システム。
  10. 計算機システムにおけるインデックスの生成方法であって、
    前記計算機システムは、プロセッサとバッファメモリと記憶装置とを備え、
    前記記憶装置は、情報が格納されたテーブルを有し、
    前記バッファメモリ及び前記記憶装置は、各々、前記テーブルを検索するためのインデックスの格納領域を有しており、
    前記インデックスは、根ノードと葉ノードを含む複数のノードからなる階層構造のインデックスであり、
    設定された条件の範囲で各階層の充填率を小さくしながら、新たに生成する前記インデックスの階層ごとに前記充填率を計算し、
    新たに生成する前記インデックスの容量と前記バッファメモリの前記格納領域の容量とを比較し、
    比較の結果、前記バッファメモリ容量の容量が不足する場合には、該インデックスの前記葉ノードの充填率を高くして前記階層ごとに前記充填率を再設定した新たな前記インデックスを生成する
    ことを特徴とするインデックスの生成方法。
  11. 請求項10において、
    新たに生成する前記インデックスの階層数が元のインデックスの階層数に対して減少している場合には、前記葉ノードの充填率を低くし前記階層ごとに前記充填率を再設定することにより前記階層数が変化しないようにした新たな前記インデックスを生成する
    ことを特徴とするインデックスの生成方法。
  12. 請求項11において、
    前記インデックスは、データを格納するページと、前記テーブルのページが保持するキー値と、前記各ページへのポインタを含み、
    前記インデックスの容量と前記格納領域の容量との比較において、前記インデックスの全階層の前記ページを前記バッファメモリに配置可能か否かを判定し、
    前記インデックスの前記ページの全てを格納しても前記バッファメモリに空き容量がある場合には、前記各階層のノードの充填率を小さくして新たな前記インデックスを生成する
    ことを特徴とするインデックスの生成方法。
  13. 請求項12において、
    新たに生成する前記インデックスの階層数が元のインデックスの階層数に対して減少している場合には、前記葉ノードの充填率を低くし前記階層ごとに前記充填率を再設定することにより前記階層数が変化しないようにした新たな前記インデックスを生成する
    ことを特徴とするインデックスの生成方法。
  14. 請求項12において、
    前記インデックスの容量と前記格納領域の容量との比較において、前記インデックスの全階層のページを前記バッファメモリに配置可能か否かを判定し、
    前記インデックスの前記ページの全てを格納しても前記バッファメモリに空き容量がある場合には、前記各階層のノードの充填率を小さくして新たな前記インデックスを生成する
    ことを特徴とするインデックスの生成方法。
  15. 請求項13において、
    前記インデックスは、前記根ノードと前記葉ノードの間に少なくとも2階層の内部ノードを有し、
    前記インデックスの容量と前記格納領域の容量との比較において、前記インデックスの全階層のページを前記バッファメモリに配置可能か否かを判定し、
    前記インデックスの前記ページの全てを格納できない場合には、前記内部ノードの充填率が、前記葉ノードに近い前記内部ノードの充填率ほど高く、前記根ノードに近い前記内部ノードの充填率ほど低くなるように再設定して新たな前記インデックスを生成する
    ことを特徴とするインデックスの生成方法。
JP2012288087A 2012-12-28 2012-12-28 インデックスの生成方法及び計算機システム Pending JP2014130492A (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2012288087A JP2014130492A (ja) 2012-12-28 2012-12-28 インデックスの生成方法及び計算機システム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2012288087A JP2014130492A (ja) 2012-12-28 2012-12-28 インデックスの生成方法及び計算機システム

Publications (1)

Publication Number Publication Date
JP2014130492A true JP2014130492A (ja) 2014-07-10

Family

ID=51408826

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2012288087A Pending JP2014130492A (ja) 2012-12-28 2012-12-28 インデックスの生成方法及び計算機システム

Country Status (1)

Country Link
JP (1) JP2014130492A (ja)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108268639A (zh) * 2018-01-18 2018-07-10 成都嗨翻屋文化传播有限公司 一种大数据环境下的指标计算方法
JP2019008788A (ja) * 2017-06-20 2019-01-17 三星電子株式会社Samsung Electronics Co.,Ltd. 貯蔵装置並びに貯蔵装置を管理するためのシステム及び方法
JP2022058529A (ja) * 2016-08-10 2022-04-12 ムーンシャドウ モバイル,インコーポレイテッド 大規模データセットの高速検索またはフィルタリングのためのシステム、方法、およびデータ構造
US11664979B2 (en) 2019-09-13 2023-05-30 Kioxia Corporation Storage system of key-value store which executes retrieval in processor and control circuit, and control method of the same

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008123426A (ja) * 2006-11-15 2008-05-29 Hitachi Ltd インデックス処理方法及び計算機システム
JP2012099133A (ja) * 2011-12-27 2012-05-24 Hitachi Ltd インデックス処理方法及び計算機システム

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008123426A (ja) * 2006-11-15 2008-05-29 Hitachi Ltd インデックス処理方法及び計算機システム
JP2012099133A (ja) * 2011-12-27 2012-05-24 Hitachi Ltd インデックス処理方法及び計算機システム

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2022058529A (ja) * 2016-08-10 2022-04-12 ムーンシャドウ モバイル,インコーポレイテッド 大規模データセットの高速検索またはフィルタリングのためのシステム、方法、およびデータ構造
JP7257068B2 (ja) 2016-08-10 2023-04-13 ムーンシャドウ モバイル,インコーポレイテッド 大規模データセットの高速検索またはフィルタリングのためのシステム、方法、およびデータ構造
JP2019008788A (ja) * 2017-06-20 2019-01-17 三星電子株式会社Samsung Electronics Co.,Ltd. 貯蔵装置並びに貯蔵装置を管理するためのシステム及び方法
JP7001544B2 (ja) 2017-06-20 2022-01-19 三星電子株式会社 貯蔵装置並びに貯蔵装置を管理するためのシステム及び方法
US11809722B2 (en) 2017-06-20 2023-11-07 Samsung Electronics Co., Ltd. System and method for managing a memory device using indexes
CN108268639A (zh) * 2018-01-18 2018-07-10 成都嗨翻屋文化传播有限公司 一种大数据环境下的指标计算方法
CN108268639B (zh) * 2018-01-18 2022-02-11 成都嗨翻屋科技有限公司 一种大数据环境下的指标计算方法
US11664979B2 (en) 2019-09-13 2023-05-30 Kioxia Corporation Storage system of key-value store which executes retrieval in processor and control circuit, and control method of the same

Similar Documents

Publication Publication Date Title
US11182356B2 (en) Indexing for evolving large-scale datasets in multi-master hybrid transactional and analytical processing systems
US9678969B2 (en) Metadata updating method and apparatus based on columnar storage in distributed file system, and host
CN106021266B (zh) 支持动态更新的快速多层索引
Papagiannis et al. Tucana: Design and implementation of a fast and efficient scale-up key-value store
US8229968B2 (en) Data caching for distributed execution computing
Shukla et al. Schema-agnostic indexing with Azure DocumentDB
US20210303537A1 (en) Log record identification using aggregated log indexes
Kyrola Drunkardmob: billions of random walks on just a pc
US9898501B2 (en) Method and system for performing transactional updates in a key-value store
Nguyen et al. Zing database: high-performance key-value store for large-scale storage service
JPWO2010084754A1 (ja) データベースシステム、データベース管理方法、及びデータベース構造
Chrysafis et al. Foundationdb record layer: A multi-tenant structured datastore
Carniel et al. A generic and efficient framework for spatial indexing on flash-based solid state drives
JP2014130492A (ja) インデックスの生成方法及び計算機システム
US9229968B2 (en) Management of searches in a database system
WO2022033099A1 (zh) 一种构建索引方法及装置
Ni et al. Adaptive database schema design for multi-tenant data management
US9558221B2 (en) Multi-pass, parallel merge for partitioned intermediate pages
Mao et al. Comparison and evaluation of state-of-the-art LSM merge policies
Chao-Qiang et al. RDDShare: reusing results of spark RDD
Azez et al. JOUM: an indexing methodology for improving join in hive star schema
Joldzic et al. The impact of cluster characteristics on HiveQL query optimization
JP6006740B2 (ja) インデックス管理装置
Bergami et al. A Join Operator for Property Graphs.
Carter et al. Nanosecond indexing of graph data with hash maps and VLists

Legal Events

Date Code Title Description
RD02 Notification of acceptance of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7422

Effective date: 20140908

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20150710

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20160420

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20160426

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20161025