JP2018045285A - 情報処理システム、制御装置、処理プログラム、及び処理方法 - Google Patents

Abstract

【課題】データベースの処理性能と利用効率との向上を両立させる。
【解決手段】行指向データベース１１と、前記行指向データベース１１から変換される列指向データベース１５とを記憶する記憶装置と、前記記憶装置を制御する制御装置とをそなえ、前記制御装置は、前記行指向データベース１１に含まれる複数のレコードを複数のグループに分け、前記グループごとに、当該グループを前記列指向データベース１５のフォーマットに従った列グループ１６に変換する。
【選択図】図２

Description

本発明は、情報処理システム、制御装置、処理プログラム、及び処理方法に関する。

リレーショナルデータベース（ＲＤＢＭＳ）では、１件のデータはレコード（record）又はタプル（tuple）と呼ばれる。１件のレコードは「人名」、「生年月日」、「住所」等の複数の属性（attribute）によって構成される。複数のレコードを集めたものがテーブル（table）又はリレーション（relation）である。ＲＤＢＭＳではテーブルに対してレコードの挿入・削除や検索等の操作が実行される。

テーブルは設計上の概念としては「レコードの集合」だが、これは縦と横方向を持った２次元情報として解釈することもできる。レコードの属性はカラム（column）であり各レコードは行（row）となる。ＲＤＢＭＳの実際の実装では、テーブルは計算機上のストレージに格納される。ここで、カラム及び行の並べ方には以下の３種類が存在する。

・ＮＳＭ（N-ary Storage Model）：レコード内の属性を固めて１つのストレージに格納する（行指向）。

・ＤＳＭ（Decomposition Storage Model）：属性ごとに分割してストレージに格納する（列指向）。

・ＰＡＸ（Partition Attributes Across）：一定数のレコードを属性別に並べてストレージに格納する。

比較的古いデータベースでは、ＮＳＭ（行指向）が採用されている。このようなデータベースではレコードの挿入・削除・更新の性能が重要で、ストレージ上にレコード単位でデータが並んでいる方が出し入れがし易いためである。このようなデータベースとしては、例えば、１９７７年にリリースされたＯＲＡＣＬＥ（登録商標）Ｄａｔａｂａｓｅの前身や１９８３年にＩＢＭ（登録商標）からリリースされたＤＢ２（登録商標）等が挙げられる。

一方、Ｓｙｂａｓｅ ＩＱ（登録商標）やＴｅｒａｄａｔａ（登録商標）をはじめとするビジネスインテリジェンスやデータウェアハウスでは、ＤＳＭが採用されることが多い。これはデータの分析ではテーブル内の全てのレコードを読み出す場合が多いが、このときレコード内の全属性のうちの特定の数の属性だけを読み出せればよいためである。ＤＳＭが採用されたデータベースは列指向データベース（column-oriented database）又はカラムナー（columnar）と呼ばれる。またカラム別のデータは圧縮が効き易く（圧縮効率がよく）、高効率の圧縮をかければディスク上のスペースも小さくなり、読み出し時のＩ／Ｏ（Input / Output）が削減され、性能が向上する。このため、カラムナーは一般に圧縮を行なう。

近年、列指向データベースの需要が高まっており、様々な列指向データベースが開発されている。研究レベルではＣ−Ｓｔｏｒｅ、ＭｏｎｅｔＤＢ、Ｘ１００、ＨｙＰｅｒ、商業用ではＨＰ Ｖｅｒｔｉｃａ、Ｖｅｃｔｏｒｗｉｓｅ（Ａｃｔｉｏｎ Ｖｅｃｔｏｒ）等が開発されている。また行指向データベースでも、ＩＢＭ ＤＢ２ ＢＬＵ ＡｃｃｅｌｅｒａｔｉｏｎやＯｒａｃｌｅ １２ｃ等で列指向データベース機能をオプションで追加するようになっている。

一方、従来の行指向データベースに分析用のカラムナーをアドインする場合、行指向データベースのテーブルに対してカラムナーの「インデックス」を用意するという方法が知られている。例えば、Ｍｉｃｒｏｓｏｆｔ（登録商標）のＳＱＬ Ｓｅｒｖｅｒ ２０１２のカラムストア・インデックス（Columnstore Indexes）機能や、富士通研究所のＣＳＩ（Column Store Index）機能である。

但し、上記の「インデックス」は、データベースから見てテーブルスキャンを助ける機構があるという意味であり、通常のインデックスのように指定したキーに対するソートがされているわけではない。以下、カラムナーのインデックスを、「カラムストア・インデックス」又は単に「カラムストア」と表記する。

特表２０１０−５３９６１６号公報 特開２０１４−１３５６２号公報 特開２００１−１４３２９号公報

株式会社富士通研究所、"PostgreSQLをベースとしたカラムストア機構の実現検討"、中村 実、田原 司睦、宇治橋 善史、橋田 拓志、河場 基行、原田 リリアン、DEIM Forum 2015、［online］、平成２７年３月３日、［平成２８年７月５日検索］、インターネット<URL: //db-event.jpn.org/deim2015/paper/195.pdf> Microsoft Corporation、"SQL Server 2014 列ストア インデックスの説明"、［online］、［平成２８年７月５日検索］、インターネット<URL: //msdn.microsoft.com/ja-jp/library/gg492088%28v=sql.120%29.aspx>

カラムナーはINSERT/DELETE/UPDATE等の更新系の処理の性能が低いことが知られている。カラムナーが１つの行をカラムごとに分割して複数のカラム別データに書き込むことや、各カラム別データが圧縮されていることが原因となっている。カラムナーの更新速度を改善するために、カラムストアとは別に行形式のまま格納する少量のキャッシュを設けるのが一般的である。このキャッシュはデルタストア（delta store）或いはＷＯＳ（Write Optimized Store）と呼ばれる。

カラムストア・インデックスを採用した場合、図１５に例示するように、オリジナルテーブル１１００に対するINSERT/DELETE/UPDATEはまずデルタストア１２００に格納される。デルタストア１２００に一定量の挿入・更新・削除行の情報が溜まると、複数行を一括でカラムストア１３００内データへと変換する。変換されたデータは、ＳＱＬ Ｓｅｒｖｅｒでは列セグメント（column segment）、富士通研究所のＣＳＩではエクステント（extent）と呼ばれる。図１５にはカラムストア１３００内に列セグメント１４００−１及び１４００−２が存在する例を示している。デルタストア１２００内に蓄積された行のうち、デルタストアに挿入した行と削除した行のペアがあれば列セグメントへの変換時に対消滅させてカラムストアには書き出さないといった最適化も可能である。

一方、オリジナルのテーブルは行単位で管理されている。例えば、オリジナルテーブルで削除された行はテーブルに空き領域として残り、次に行を挿入するときにテーブルの空き領域として再利用される。図１６に、オリジナルテーブル２１００の行“２”を削除し行“３”を追加する例を示す。

しかし、オリジナルテーブル２１００上から削除された行は、カラムストア２３００内ではＤｅｌｅｔｅ ｖｅｃｔｏｒに削除行であることがマークされた後にそのまま残る。例えば、図１６では、カラムストア２３００の列セグメント２４００−１の行“２”にＤｅｌｅｔｅ ｖｅｃｔｏｒ“１”が設定される。

このため、挿入を行なった順序とディスク上の配置とにズレが生じる。INSERTだけを実施していた場合は、オリジナルテーブル２１００とカラムストア２３００との行の並び方は同じになり得るが、UPDATE・DELETEも含めるとテーブル２１００の並びとカラムストア２３００の並びとはズレることになる。従って、オリジナルテーブル２１００の順序とカラムストア２３００の順序とは一致しない。

これは行指向データベースのオリジナルテーブルに対する、カラムストア・インデックスではない検索用のインデックス（以下、「通常インデックス」と表記する）がカラムストアに適用できないことを意味する。

行指向データベースは通常インデックスを用いることでテーブルの特定の行へのアクセスを高速化している。通常インデックスは一般に指定したカラムをキーにし、オリジナルテーブル上の位置を値に保持している。図１７にオリジナルテーブル３１００と通常インデックス３２００との関係を例示する。

オリジナルテーブル３１００には、“ColA”、“ColB”、“ColC”の３つの列を持つテーブルがあり、その中で“ColA”に対して通常インデックス３２００が張られている。通常インデックス３２００は“ColA”をソートした形でデータを保持している。なお、図１７の例では、通常インデックス３２００は表の形式で示しているが、実際には木構造である場合が多い。オリジナルテーブル３１００において、“0:1”、“0:2”等は、テーブル内の行の位置を示す識別子である。以下、この識別子を「レコードＩＤ（Identifier）」と表記する。

しかし、上述のように、オリジナルテーブルとカラムストアとで行の並び順の一致が保証されていないため、図１８に例示するように、オリジナルテーブル４１００のために設けた通常インデックス４２００からカラムストア４３００へは直接マッピングできない。換言すれば、カラムストア４３００をスキャンする場合には通常インデックス４２００は使えないことになる。

カラムナーにおいても、検索のために用いるインデックスが存在しない場合には、十分な性能が発揮できない。このため、カラムストア・インデックスの性能を上げるためには、オリジナルテーブルの通常インデックスとは別にカラムストア・インデックスに対するインデックスを設けることが考えられる。しかし、これはデータを二重に持つことを意味し、ディスク容量等を浪費することに繋がる。

以上のように、行指向データベースの処理性能を向上させるために列指向のカラムストアを適用する場合、通常インデックスの他に、カラムストアに対してもインデックスを設けることになり、データ圧縮や更新頻度等の観点で利用効率が低下する場合がある。

１つの側面では、本発明は、データベースの処理性能と利用効率との向上を両立させることを目的とする。

なお、前記目的に限らず、後述する発明を実施するための形態に示す各構成により導かれる作用効果であって、従来の技術によっては得られない作用効果を奏することも本発明の他の目的の１つとして位置付けることができる。

１つの側面では、情報処理システムは、行指向データベースと、前記行指向データベースから変換される列指向データベースとを記憶する記憶装置と、前記記憶装置を制御する制御装置とをそなえてよい。前記制御装置は、前記行指向データベースに含まれる複数のレコードを複数のグループに分け、前記グループごとに、当該グループを前記列指向データベースのフォーマットに従った列グループに変換する変換部、をそなえてよい。

１つの側面では、データベースの処理性能と利用効率との向上を両立できる。

ＶＢＭ（Visibility block map）を有するオリジナルテーブルのデータ構成例を示す図である。 一実施形態に係るデータベースのデータ構成例を示す図である。 一実施形態に係る情報処理システムの構成例を示すブロック図である。 オリジナルテーブルからカラムストアへの変換処理の一例を示す図である。 通常インデックスを利用せずにオリジナルテーブルをスキャンする場合の参照処理の一例を示す図である。 通常インデックスを利用してオリジナルテーブルをスキャンする場合の参照処理の一例を示す図である。 通常インデックスを利用してオリジナルテーブルをスキャンする場合の参照処理の変形例を示す図である。 図３に示す更新部の処理の一例を説明するフローチャートである。 図３に示す変換部の処理の一例を説明するフローチャートである。 図９に示す変換処理の一例を説明するフローチャートである。 図３に示す参照部による通常インデックスを利用しない場合の処理の一例を説明するフローチャートである。 図３に示す参照部による通常インデックスを利用する場合の処理の一例を説明するフローチャートである。 図３に示す参照部による通常インデックスを利用する場合の処理の変形例を説明するフローチャートである。 図３に示すコントローラのハードウェア構成例を示すブロック図である。 オリジナルテーブル、デルタストア、列セグメントの関係の一例を示す図である。 行の挿入及び削除を行なった場合のオリジナルテーブル、カラムストアのデータ変化の一例を示す図である。 オリジナルテーブルと通常インデックスとの関係の一例を示す図である。 オリジナルテーブル、通常インデックス、カラムストアの関係の一例を示す図である。

以下、図面を参照して本発明の実施の形態を説明する。ただし、以下に説明する実施形態は、あくまでも例示であり、以下に明示しない種々の変形や技術の適用を排除する意図はない。例えば、本実施形態を、その趣旨を逸脱しない範囲で種々変形して実施することができる。なお、以下の実施形態で用いる図面において、同一符号を付した部分は、特に断らない限り、同一若しくは同様の部分を表す。

〔１〕一実施形態
〔１−１〕データベース構造について
一実施形態に係るシステムでは、カラムストア・インデックスの並びとオリジナルテーブルの並びとの一貫性を維持し、オリジナルテーブルに対する通常インデックスをカラムストア・インデックスへも適用可能とする。

図１に、比較例としてのオリジナルテーブル１００のデータ構成例を示す。オリジナルテーブル１００は、ＤＢブロック又はＤＢページと呼ばれるデータ単位に分割されているとする（図１でＤＢブロック＃０〜＃２と表記）。１つのＤＢブロックは４ＫＢ（バイト）〜６４ＫＢ程度のサイズであり、ストレージからメモリへのデータロードの単位となる。なお、以下の説明において、ＤＢブロックを、単に「ブロック」と表記する場合がある。

１つのＤＢブロックの中には複数のレコード（行）が格納される。テーブル１００に格納されているレコードはブロック番号とブロック内の相対位置（例えば“0:0”、“0:1”、“1:1”等）で示すことができる。以下、識別子として用いられる当該相対位置をレコードＩＤと表記する。レコードＩＤにおいて、コロン（：）の左側の値はＤＢブロック番号を示し、コロンの右側の値は当該ＤＢブロック内でのレコードの相対位置を示す。

オリジナルテーブル１００はＶＢＭ（Visibility block map）１１０を持つものとする。オリジナルテーブル１００内のレコードが変更を受けた場合、その変更の可視性はトランザクションモデルにより制御され、トランザクションによって見え方が異なる。しかし、当該レコードを変更したトランザクションと同時に存在した他のトランザクションが全てコミット又はアボートした後に可視性は確定する。

ＶＢＭ１１０は、ＤＢブロックの可視性を管理する情報であり、例えば、ＤＢブロックごとに１ビットが割り当てられたビットマップとして管理されてよい。例えば、ＶＢＭ１１０の或るビットの値として、当該ビットに対応するＤＢブロック内の全てのレコードの可視性が確定した状態を“１”、１つでも可視性が確定しないレコードが存在する場合を“０”とする。

ブロック内のレコードが変更を受けた場合、ＶＢＭ１１０の当該ブロックの位置のビットは“０”に落ちる。一方、システムは、非同期にオリジナルテーブル１００のスキャンを行ない、ブロック内の全レコードの可視性が確定していることを確認するとＶＢＭ１１０を“１”に設定する処理を行なう。

通常インデックス１２０は指定されたカラムをソートして記憶する。図１の例では、通常インデックス１２０はオリジナルテーブル１００の一番左のカラム“ColA”をソートした情報を保持する。また、通常インデックス１２０は指定されたカラムのデータと対でレコードＩＤを記録し、オリジナルテーブル１００へのポインタとしている。図１の例では、通常インデックス１２０を表の形式で示しているが、木構造或いはハッシュ構造であってもよい。

図２は、一実施形態の一例としてのデータベース構成例を示す図である。なお、図２の例では、通常インデックスの図示を省略しているが、一実施形態に係るデータベースは通常インデックスも有してよい。一実施形態に係るデータベースは、図２に例示するフレームワークによって実現されてよい。

オリジナルテーブル１１は、行指向データベースの一例である。オリジナルテーブル１１は、図１と同様に、複数のＤＢブロック１２を有してよい。また、オリジナルテーブル１１には、図１と同様のＶＢＭ１３、及び、ＶＧＭ（Visibility group map）１４が設定されてよい。以下、ＶＢＭ１３を「ブロックマップ１３」と表記し、ＶＧＭ１４を「グループマップ１４」と表記する場合がある。

ＶＧＭ１４は、一度に変換されるＤＢブロック１２の可視性を管理する情報である。以下、一度に変換されるＤＢブロック１２をブロックグループと表記する場合がある。システムは、オリジナルテーブル１１のうちの固定数個のＤＢブロック１２をまとめた１つのブロックグループを、１つの列セグメント１６に変換する。

ＶＧＭ１４は、例えば、ブロックグループごとに１ビットが割り当てられたビットマップとして管理されてよい。例えば、ＶＧＭ１４の或るビットの値には、オリジナルテーブル１１のうちの当該ビットに対応するブロックグループ内の全ブロックマップ１３が“１”の場合は“１”、それ以外の場合（１つでもブロックマップ１３が“０”の場合）は“０”が設定される。

ブロックグループ内のＤＢブロック１２内のレコードが変更を受けた場合、ＶＧＭ１４の当該ブロックグループの位置のビットは“０”に落ちる。一方、システムは、オリジナルテーブル１１に対して非同期にＶＧＭ１４に“１”を立てる非同期処理を行なう。また、非同期処理によって同じブロックグループ内のＤＢブロック１２のＶＢＭ１３が全て“１”になる場合（可視性が確定した場合）、システムは、ブロックグループを列セグメント１６へ変換し、ＶＧＭ１４の対応するビットに“１”を設定する。

また、ＶＧＭ１４において、ビットが“０”に設定された列セグメント１６は無効化され、次にビットが“１”に設定されるときまでは変換が行なわれない。これにより、ブロックグループ内で１つでも可視性が確定しないＤＢブロック１２が存在する場合、当該ブロックグループに対応する列セグメント１６は無効になる。この場合、当該ブロックグループに対するアクセスは、カラムストア・インデックス（図２では「カラムストア１５」と表記）ではなくオリジナルテーブル１１に対して向けられる。

換言すれば、ＶＧＭ１４は、ブロックグループごとに対応する列セグメント１６が有効か否かを表すグループ情報の一例である。ＶＧＭ１４により、システムは、列セグメント１６が有効か否かを容易に判定でき、また、ブロックグループを列セグメント１６に変換するか否かの判定を容易に行なうことができる。

このように、一実施形態では、ブロックグループ内の全てのＤＢブロック１２の可視性が確定している場合、例えば、同時に存在するトランザクションが全てコミット又はアボートした場合に、列セグメント１６への変換が行なわれる。換言すれば、ＶＧＭ１４に“１”が設定されたブロックグループでは、オリジナルテーブル１１とカラムストア１５との間で、削除・挿入・更新等によるレコードのズレが存在せず、これらの並び順の一致が保証されているといえる。

以上のように、一実施形態では、オリジナルテーブル１１が複数のＤＢブロック１２を含むブロックグループ単位で列セグメント１６に変換される。これにより、列セグメント１６内に、オリジナルテーブル１１との並び順の一致が保証されたブロックグループ単位のデータが存在するため、オリジナルテーブル１１及びカラムストア１５の双方に通常インデックスを用いることができる。

また、ブロックグループは、ある程度大きいほうが１度に変換する行が多くなり圧縮効果が高くなる。また１回の列セグメント１６への変換で定常的にかかるコストがある。従って、１度に多数の行を変換した方が相対的にコストが小さくなる。一例として、ブロックグループは１ＭｉＢ（mebibyte）程度であってよい。例えば、１つのＤＢブロックが４ＫｉＢ（kibibyte）〜６４ＫｉＢの場合、１つのブロックグループには１６３８４個〜２６２１４４個のＤＢブロックが含まれてよい。なお、以下の説明では、図の簡略化のため４つのＤＢブロックをまとめて１ブロックグループとする。

カラムストア１５は、オリジナルテーブル１１から変換される列指向データベースの一例である。カラムストア１５は、ブロックグループごとに列セグメント１６を記憶してよい。列セグメント１６は、オリジナルテーブル１１のブロックグループに対応する列グループの一例である。

図２に例示するように、列セグメント１６には、列セグメントのデータ１６ｂに加えて、列セグメント内オフセット番号１６ａ、変換表１６ｃ、及び、変換ツリー１６ｄが対応付けられてよい。

列セグメント内オフセット番号１６ａは、データ１６ｂのオフセット番号を示す情報である。

変換表１６ｃは、列セグメント内オフセット番号１６ａからオリジナルテーブル１１のレコードＩＤへの変換を行なうための情報である。変換表１６ｃは、カラムストア１５内のデータ１６ｂがオリジナルテーブル１１のどのレコードに対応するかを特定するレコードＩＤを記録してよい。

換言すれば、変換表１６ｃは、変換により生成された列グループ内のデータごとに、変換を行なったグループ内の対応するレコードの識別情報との関係を表す情報の一例である。

変換ツリー１６ｄは、レコードＩＤから列セグメント内オフセット番号１６ａへの変換を行なうための情報であり、レコードＩＤ→カラムストア１５内の位置を記録するデータを有してよい。

変換ツリー１６ｄは、レコードＩＤのうちのＤＢブロック番号の検索のための１段目のテーブル１６ｄ−１と、特定のブロック番号下の相対位置でレコードＩＤを引く２段目のテーブル１６ｄ−２とを組み合わせた階層構造であってよい。なお、変換ツリー１６ｄのデータ構造としては木構造以外にハッシュテーブル等が用いられてもよい。

換言すれば、変換ツリー１６ｄは、変換を行なったグループ内の各レコードの識別情報と、変換で生成された列グループ内の当該レコードに対応するデータの相対位置との関係を表す関係情報の一例である。

図２の例において、テーブル１６ｄ−１には、レコードＩＤのうちのＤＢブロック番号（図２では“０”〜“３”で示す）と、テーブル１６ｄ−２へのポインタ（図２では、テーブル１６ｄ−２への矢印が出ている四角枠で示す）とが設定されてよい。

また、図２の例において、テーブル１６ｄ−２には、レコードＩＤのうちの相対位置（コロンの右側の値、図２ではレコードＩＤ全体を示す）と、列セグメント内オフセット番号１６ａ（図２では四角枠内の数字で示す）とが設定されてよい。

〔１−２〕情報処理システムの構成例
次に、一実施形態に係る情報処理システム１の構成例について説明する。図３は一実施形態に係る情報処理システム１の機能構成例を示す図である。

図３に示すように、情報処理システム１は、例示的に、データベース１０及びコントローラ２０をそなえてよい。

データベース１０は、行指向データベース及び列指向データベースを記憶する記憶装置の一例である。データベース１０は、図２に例示するデータ構造であってよい。例えば、データベース１０は、オリジナルテーブル１１、ブロックマップ（ＶＢＭ）１３、グループマップ（ＶＧＭ）１４、カラムストア１５、及び、通常インデックス１７を記憶する。

なお、カラムストア１５には、図２を用いて説明したように、列セグメント内オフセット番号１６ａ及びデータ１６ｂを含む列セグメント１６、変換表１６ｃ、並びに、変換ツリー１６ｄを含んでよい。

データベース１０は、１以上の記憶部によって実現されてよく、複数の記憶部によってＲＡＩＤ（Redundant Arrays of Inexpensive Disks）等のディスクアレイが構成されてもよい。記憶部としては、例えばＨＤＤ（Hard Disk Drive）等の磁気ディスク装置、ＳＳＤ（Solid State Drive）等の半導体ドライブ装置、不揮発性メモリ等が挙げられる。不揮発性メモリとしては、例えば、フラッシュメモリ、ＳＣＭ（Storage Class Memory）、ＲＯＭ（Read Only Memory）等が挙げられる。

コントローラ２０は、データベース１０に対する種々の制御を行なう制御装置又はコンピュータの一例である。例えば、ホスト３０からネットワーク４０を介してデータベースへの参照や更新等の操作要求があった場合、コントローラ２０は、データベース１０に対して参照や更新等の操作を行ない、ホスト３０に応答を返す。

このように、情報処理システム１は、ホスト３０に対して、データベース管理システムとしての機能・サービスを提供してよい。

なお、ホスト３０としては、例えば業務サーバや基幹サーバ、或いはクライアントマシン等のコンピュータが挙げられる。図３には２台のホスト３０が示されているが、ホスト３０は１台又は３台以上でもよい。

ネットワーク４０としては、例えばインターネット、又は、ＬＡＮ（Local Area Network）若しくはＷＡＮ（Wide Area Network）等が挙げられる。

コントローラ２０は、例示的に、通信部２１、変換部２２、更新部２３、及び、参照部２４をそなえてよい。

通信部２１は、ホスト３０との間の通信を行なう。例えば、通信部２１は、ホスト３０からの操作要求を受け付け、当該操作要求を更新部２３又は参照部２４に渡すとともに、更新部２３又は参照部２４からの操作結果をホスト３０に送信する。

変換部２２は、オリジナルテーブル１１に含まれる複数のレコードを複数のブロックグループに分け、ブロックグループごとに、当該ブロックグループをカラムストア１５のフォーマットに従った列セグメント１６に変換する。

また、変換部２２は、列セグメント１６が無効であるグループ内の複数のレコードに対する全ての更新が確定している、換言すれば、全てのレコードの可視性が確定している場合に、当該更新が確定しているグループを列セグメント１６に変換する。そして、変換部２２は、変換した列セグメント１６が有効であることをグループマップ１４に設定する処理を行なう。変換部２２による処理は、更新部２３及び参照部２４によるデータベース１０への処理とは非同期に行なわれてよい。

変換部２２による処理は、例えば以下の手順で行なわれてよい。

（Ａ）グループマップ１４に“０”が設定されたブロックグループにおいて、“０”が設定されたＤＢブロック１２（図２参照）内の全てのレコードの可視化が確定しているかを判定する。

（Ｂ）上記（Ａ）で全てのレコードの可視化が確定している場合、当該ＤＢブロック１２の位置のブロックマップ１３に“１”をセットする。

（Ｃ）上記（Ａ）及び（Ｂ）の結果、ブロックグループ内の全てのブロックマップ１３に“１”がセットされた場合、当該ブロックグループを列セグメント１６に変換する。

（Ｄ）当該ブロックグループ番号の位置のグループマップ１４に“１”をセットする。

（Ｅ）グループマップ１４に“０”が設定された他のブロックグループについて、上記（Ａ）〜（Ｄ）を実施する。

上記（Ｃ）における変換処理は、図４に例示するように、以下の手順で行なわれてよい。なお、図４には、以下の（ａ）〜（ｄ）に対応する処理を符号付きの矢印で示す。

（ａ）変換を行なうブロックグループから１つのＤＢブロック１２を読み込み、当該ＤＢブロック１２からレコードをスキャンする。

（ｂ）１つのレコードの各カラムのデータを、列セグメント１６における所定の列セグメント内オフセット番号１６ａ位置のデータ１６ｂに追加する。

（ｃ）当該１つのレコードのレコードＩＤを変換表１６ｃに追加する。

（ｄ）当該１つのレコードのレコードＩＤと、列セグメント内オフセット番号１６ａとの対応関係を変換ツリー１６ｄに追加する。この処理では、レコードＩＤのうちのＤＢブロック番号にテーブル１６ｄ−２へのポインタを対応付けてテーブル１６ｄ−１に設定する処理、及び、レコードＩＤに列セグメント内オフセット番号１６ａを対応付けてテーブル１６ｄ−２に設定する処理が行なわれる。

（ｅ）列セグメント内オフセット番号１６ａをインクリメントし、他のレコードについて上記（ｂ）〜（ｄ）を実施する。

（ｆ）変換を行なうブロックグループ内の他のＤＢブロック１２について、上記（ａ）〜（ｅ）を実施する。

以上の手順により、変換部２２によってオリジナルテーブル１１が複数のＤＢブロック１２を含むブロックグループ単位で列セグメント１６に変換され、カラムストア１５に設定される。これにより、列セグメント１６内に、オリジナルテーブル１１との並び順の一致が保証されたブロックグループ単位のデータが存在するため、オリジナルテーブル１１及びカラムストア１５の双方に同じ通常インデックスを用いることができる。また、ブロックグループ単位での変換により、圧縮効率を高めつつ変換コストを下げることができる。従って、データベースの処理性能と利用効率との向上を両立できる。

更新部２３は、通信部２１から受け取った更新系の操作要求に応じて、オリジナルテーブル１１に対するINSERT/DELETE/UPDATE等の種々の更新系の処理を行なう。このため、更新部２３は、更新系の操作を行なう実行エンジンを含んでよい。或いは、更新部２３は実行エンジンを含まず、代わりに実行エンジンに対して操作要求を行なう機能を有してもよい。

また、更新部２３は、オリジナルテーブル１１に対して更新操作が行なわれるタイミングで、ブロックマップ１３及びグループマップ１４における更新操作に係るビット位置の値を“０”にクリアする処理を行なう。これにより、オリジナルテーブル１１で更新された箇所に対応する列セグメント１６は無効化される。当該ＤＢブロック１２は更新されたため、ＤＢブロック１２と列セグメント１６との間で並び順の一致が保証できないためである。

このように、更新部２３が列セグメント１６を無効にすることで、変換部２２は、更新に係るレコードの更新確定後に、最新のレコードを列セグメント１６に変換でき、カラムストア１５を最新の状態に更新することができる。

換言すれば、更新部２３は、行指向データベースにおいて更新されるレコードを含むグループの列グループが無効であることを前記グループ情報に設定する無効化部の一例である。

参照部２４は、読出部の一例である。参照部２４は、通信部２１から受け取ったオリジナルテーブル１１に対する参照系の操作要求（クエリ；参照要求）に応じて、オリジナルテーブル１１又はカラムストア１５に対するSELECT等の種々の参照系の処理を行なう。このため、参照部２４は、参照系の操作を行なうクエリ実行エンジンを含んでよい。或いは、参照部２４はクエリ実行エンジンを含まず、代わりにクエリ実行エンジンに対して操作要求を行なう機能を有してもよい。

このとき、参照部２４は、参照対象のレコードの読出ターゲットを、当該レコードが存在するブロックグループ単位で、オリジナルテーブル１１及びカラムストア１５のいずれかからグループマップ１４に基づき判定する。そして、参照部２４は、判定した読出ターゲットから操作要求で指定されたレコードを読み出す。

例えば、参照部２４は、クエリを行なうブロックグループに対応するグループマップ１４の値が“０”の場合はオリジナルテーブル１１を走査（スキャン）すると判定する。一方、参照部２４は、当該グループマップ１４の値が“１”の場合はオリジナルテーブル１１ではなくカラムストア１５からデータ供給を受けると判定する。

なお、参照部２４は、クエリ実行の際に通常インデックス１７を利用する場合と利用しない場合とがある。

クエリ実行の際にオリジナルテーブル１１を通常インデックス１７無しで直接走査する場合、参照部２４は、図５に例示するように、以下の（Ｉ）又は（II）の処理を行なう。なお、図５ではブロックマップ１３の図示を省略している。

（Ｉ）参照対象のブロックグループのグループマップ１４が“０”の場合：オリジナルテーブル１１から参照対象のＤＢブロック１２を走査して、レコードのデータを読み出す（図５のＤＢブロック＃４〜＃７のブロックグループ参照）。読み出したデータはクエリ実行エンジンへ供給される。

（II）参照対象のブロックグループのグループマップ１４が“１”の場合：カラムストア１５から参照対象のＤＢブロック１２を走査して、レコードのデータを読み出す（図５のＤＢブロック＃０〜＃３、ＤＢブロック＃８〜＃１１の各ブロックグループ参照）。読み出したデータはクエリ実行エンジンへ供給される。なお、カラムストア１５の走査において、変換表１６ｃ及び変換ツリー１６ｄの参照は不要としてもよい。

次に、クエリ実行の際にオリジナルテーブル１１に対する通常インデックス１７を利用して検索する場合を考える。例えば、オリジナルテーブル１１が“ColA”、“ColB”、“ColC”の３つのカラムを持っており、“ColA”の通常インデックス１７が作成されているとする。そこに、「SELECT ColB FROM オリジナルテーブル WHERE ColA BETWEEN 4 AND 6」というクエリが実行されたとすると、参照部２４は、図６に例示するように、以下の（ｉ）〜（iv）の処理を行なう。

（ｉ）通常インデックス１７を「WHERE」句で指定される「ColA BETWEEN 4 AND 6」という条件でスキャンして、条件に合致する行のレコードＩＤを取り出す。

（ii）レコードＩＤはＤＢブロック番号を含んでいるので、ＤＢブロック番号からブロックグループを特定し、グループマップ１４を参照して、当該レコードのデータがカラムストア１５内に存在するか否かを判定する。

（iii）上記（ii）で当該レコードのデータがカラムストア１５内に存在する場合（図６のグループマップ１４の値“１”のブロックグループ参照）、列セグメント１６を参照する。そして、列セグメント１６内の「レコードＩＤから列セグメント内オフセット番号１６ａへの」変換ツリー１６ｄを参照し、通常インデックス１７のキーに対応するレコードのデータを特定して、クエリ実行エンジンへデータを供給する。

（iv）上記（ii）で当該レコードのデータがカラムストア１５内に存在しない場合（図６のＤＢブロック＃４〜＃７のブロックグループ参照）、オリジナルテーブル１１を参照する。そして、オリジナルテーブル１１から通常インデックス１７のキーに対応するレコードのデータを特定して、クエリ実行エンジンへデータを供給する。

このように、参照部２４は、オリジナルテーブル１１に対して設定された通常インデックス１７を用いて参照要求で指定されたレコードを特定してよい。そして、参照部２４は、読出ターゲットがカラムストア１５である場合、変換ツリー１６ｄに基づいて、通常インデックス１７を用いて特定したレコードに対応する列セグメント１６内のデータの相対位置を特定してよい。

なお、参照部２４は、例えば、クエリで要求された情報にレコードＩＤが含まれる場合、変換表１６ｃを参照して、列セグメント内オフセット番号１６ａに対応するレコードＩＤを取得してよい。これにより、列セグメント１６を用いたレコードＩＤの応答が可能となる。

〔１−２−１〕参照部の変形例
なお、参照部２４は、クエリ実行の際に、より効率的に通常インデックス１７を用いるために、ビットマップ走査を使用したクエリへのビットマップフィルタを適用してもよい。このようなビットマップフィルタとしては、例えば、Ｍｉｃｒｏｓｏｆｔ（登録商標）のＳＱＬ Ｓｅｒｖｅｒに搭載されたビットマップフィルタや、ＰｏｓｔｇｒｅＳＱＬのビットマップヒープスキャン（Bitmap Heap Scan）等が挙げられる。

例えば、参照部２４は、図７に示すように、上記（ii）の処理に代えて、以下の（ii′−１）及び（ii′−２）の処理を行なってもよい。参照部２４は、（ii′−２）の判定の後、上記（iii）又は（iv）の処理を行なえばよい。

（ii′−１）通常インデックス１７の検索に合致した行をレコードＩＤ順に並んだビットマップ（図７では「ビットマップフィルタ１８」と表記）に記録する。例えば、検索に合致した行のビットに“１”をセットし、それ以外のビットに“０”をセットする。

（ii′−２）ビットマップフィルタ１８をレコードＩＤ順に検索し、“１”がセットされた位置に対応するレコードＩＤについて、当該レコードのデータがカラムストア１５内に存在するか否かを判定する。

このように、参照部２４は、通常インデックス１７を用いて特定したレコードを、レコードの識別情報の順に並んだビットマップフィルタ１８に設定してよい。そして、参照部２４は、ビットマップフィルタ１８に設定されたレコードについて、レコードの識別情報の順に読出ターゲットの判定を行なってよい。

ビットマップフィルタ１８を用いることで、ビットマップがレコードＩＤ順に並ぶため、参照部２４は同じブロックグループに属する行が選択されたか否かを一括で取得することができる。上記（ii′−２）及び（iii）の処理により、参照部２４は、列セグメント１６をシーケンシャルにアクセスできるため、効率よくクエリを実行でき、スループットを向上できる。以下、ビットマップフィルタ１８を単に「ビットマップ１８」と表記する場合がある。

〔１−３〕動作例
次に、図８〜図１３を参照して、上述の如く構成された情報処理システム１の動作例を説明する。

〔１−３−１〕更新部の動作例
更新部２３は、通信部２１がホスト３０から受信した更新系の操作要求を通信部２１から受け取る。

更新部２３は、操作要求を受け取ると、更新系の操作を行なう実行エンジンによってオリジナルテーブル１１に対して当該要求に係る操作を行なってよい。また、更新の操作が完了すると、更新部２３は、図８に例示するブロックマップ１３及びグループマップ１４の更新処理を行なってよい。なお、当該更新処理は、更新の操作と並行して、又は、更新の操作前に行なわれてもよい。

図８に示すように、更新部２３は、操作要求から操作対象のテーブル１１のレコードＩＤを特定し、当該レコードＩＤからブロック番号Ｍ（Ｍは整数）を取り出す（ステップＡ１）。

次いで、更新部２３は、ブロック番号Ｍをブロックグループ内のブロック数（ブロックグループの構成ブロック数）Ｘ（Ｘは２以上の整数）で割り、ブロックグループ番号Ｎ（Ｎは整数）を求める（ステップＡ２）。なお、ブロックグループ内のローカルなブロック番号を求める場合には、ブロック番号Ｍをブロックグループの構成ブロック数Ｘで剰余をとればよい。

更新部２３は、ブロックグループＮにおけるＭの位置のブロックマップ１３が“１”か否かを判定する（ステップＡ３）。判定の結果、ブロックマップ１３が“１”の場合（ステップＡ３でＹｅｓ）、更新部２３は、当該Ｍの位置のブロックマップ１３を“０”にクリアし（ステップＡ４）、処理がステップＡ５に移行する。一方、判定の結果、ブロックマップ１３が“１”ではない場合（ステップＡ３でＮｏ）、処理がステップＡ５に移行する。

ステップＡ５では、更新部２３は、ブロックグループＮの位置のグループマップ１４が“１”か否かを判定する。判定の結果、グループマップ１４が“１”の場合（ステップＡ５でＹｅｓ）、更新部２３は、当該Ｎの位置のグループマップ１４を“０”にクリアし（ステップＡ６）、処理が終了する。一方、判定の結果、グループマップ１４が“１”ではない場合（ステップＡ５でＮｏ）、処理が終了する。

〔１−３−２〕変換部の動作例
変換部２２は、更新部２３及び参照部２４の処理とは非同期に、図９及び図１０に例示するブロックマップ１３及びグループマップ１４の更新、並びに、オリジナルテーブル１１からカラムストア１５への変換の処理を行なってよい。

図９に例示するように、変換部２２は、ブロックグループ番号Ｎに“０”をセットする（ステップＢ１）。また、変換部２２は、変換実施のフラグＦを“１”にセットする（ステップＢ２）。

変換部２２は、ブロックグループＮに対応するグループマップ１４が“１”か否かを判定する（ステップＢ３）。判定の結果、グループマップ１４が“１”ではない場合（ステップＢ３でＮｏ）、変換部２２は、ブロックグループＮ内のブロック番号Ｍに“０”をセットする（ステップＢ４）。

そして、変換部２２は、ブロック番号Ｍに対応するブロックマップ１３が“１”か否かを判定する（ステップＢ５）。判定の結果、ブロックマップ１３が“１”ではない場合（ステップＢ５でＮｏ）、変換部２２は、当該ブロックＭ内の全てのレコードの可視性が確定しているか否かを判定する（ステップＢ６）。

全てのレコードの可視性が確定している場合（ステップＢ６でＹｅｓ）、変換部２２は、ブロック番号Ｍの位置のブロックマップ１３を“１”にセットし（ステップＢ７）、処理がステップＢ９に移行する。

一方、少なくとも１つのレコードの可視性が確定していない場合（ステップＢ６でＮｏ）、変換部２２は、フラグＦを“０”にクリアし（ステップＢ８）、処理がステップＢ９に移行する。なお、ステップＢ５において、判定の結果、ブロック番号Ｍに対応するブロックマップ１３が“１”の場合も（ステップＢ５でＹｅｓ）、処理がステップＢ９に移行する。

ステップＢ９では、変換部２２は、Ｍに１を加算する。そして、変換部２２は、Ｍが最大のブロック番号を超えたか否かを判定する（ステップＢ１０）。Ｍが最大のブロック番号を超えていない場合（ステップＢ１０でＮｏ）、処理がステップＢ５に移行し、変換部２２は、次のブロック番号Ｍについて判定を行なう。一方、Ｍが最大のブロック番号を超えた場合（ステップＢ１０でＹｅｓ）、変換部２２は、フラグＦが“１”か否かを判定する（ステップＢ１１）。

判定の結果、フラグＦが“１”ではない場合（ステップＢ１１でＮｏ）、処理がステップＢ１４に移行する。一方、判定の結果、フラグＦが“１”の場合（ステップＢ１１でＹｅｓ）、変換部２２は、ブロックグループＮを列セグメント１６に変換する（ステップＢ１２）。当該ブロックグループＮ内の全てのブロック１２における全てのレコードの可視性が確定しているためである。

そして、変換部２２は、ブロックグループ番号Ｎの位置のグループマップ１４に“１”をセットし（ステップＢ１３）、Ｎに１を加算する（ステップＢ１４）。また、変換部２２は、Ｎが最大のブロックグループ番号を超えたか否かを判定する（ステップＢ１５）。

判定の結果、Ｎが最大のブロックグループ番号を超えていない場合（ステップＢ１５でＮｏ）、処理がステップＢ２に移行し、変換部２２は、次のブロックグループ番号Ｎについて判定を行なう。

一方、Ｎが最大のブロックグループ番号を超えた場合（ステップＢ１５でＹｅｓ）、処理が終了する。

なお、ステップＢ３において、判定の結果、ブロックグループ番号Ｎに対応するグループマップ１４が“１”の場合（ステップＢ３でＹｅｓ）、処理がステップＢ１４に移行する。つまり、既に列セグメント１６が作成されているため、変換部２２は、当該ブロックグループＮについてこれ以上の処理を行なわず、次のブロックグループ番号について判定を行なう。

次に、図１０を参照して、変換部２２によるステップＢ１２の変換処理の動作例を説明する。

変換部２２は、列セグメント内オフセット番号Ｏ（Ｏは整数）に“０”をセットし（ステップＢ２１）、ブロックグループＮ内のブロック番号Ｍに“０”をセットする（ステップＢ２２）。なお、Ｎは、図９でステップＢ１２に移行する際にセットされている値である。

変換部２２は、ブロックＭを読み込む（ステップＢ２３）。そして、ブロックＭ内のレコードをスキャンし（ステップＢ２４）、当該レコードのレコードＩＤ Ｒを取り出す（ステップＢ２５）。

そして、変換部２２は、オリジナルテーブル１１内の当該レコードにおけるカラムＣを１つ選択し（ステップＢ２６）、列セグメント１６のカラムＣのデータの末尾にレコードＩＤ Ｒのレコード内のカラムＣの値を追加する（ステップＢ２７）。

変換部２２は、当該レコード内の全てのカラムを選択したか否かを判定し（ステップＢ２８）、全てのカラムを選択していない場合（ステップＢ２８でＮｏ）、処理がステップＢ２６に移行し、変換部２２は未選択のカラムＣを選択する。

一方、判定の結果、全てのカラムを選択した場合（ステップＢ２８でＹｅｓ）、変換部２２は、列セグメント内オフセット番号１６ａからレコードＩＤへの変換表１６ｃの末尾にレコードＩＤ Ｒを追加する（ステップＢ２９）。また、変換部２２は、レコードＩＤから列セグメント内オフセット番号１６ａへの変換ツリー１６ｄに、レコードＩＤ Ｒから列セグメント内オフセット番号Ｏへの対応関係を追加する（ステップＢ３０）。

そして、変換部２２は、Ｏに１を加算し（ステップＢ３１）、ブロックＭ内の全てのレコードをスキャンしたか否かを判定する（ステップＢ３２）。全てのレコードをスキャンしていない場合（ステップＢ３２でＮｏ）、処理がステップＢ２４に移行し、変換部２２は未スキャンのレコードをスキャンする。

一方、全てのレコードをスキャンした場合（ステップＢ３２でＹｅｓ）、変換部２２は、Ｍに１を加算し（ステップＢ３３）、ＭがブロックグループＮ内の最大のブロック番号を超えたか否かを判定する（ステップＢ３４）。

判定の結果、Ｍが最大のブロック番号を超えていない場合（ステップＢ３４でＮｏ）、処理がステップＢ２３に移行し、変換部２２は、次のブロック１２について判定を行なう。一方、Ｍが最大のブロック番号を超えた場合（ステップＢ３４でＹｅｓ）、処理が終了する。

〔１−３−３〕参照部の動作例
参照部２４は、通信部２１がホスト３０から受信した参照系の操作要求（例えばクエリ）を通信部２１から受け取る。

参照部２４は、クエリを受け取ると、図１１〜図１３のいずれかの手法によって、クエリ実行エンジンによりオリジナルテーブル１１又はカラムストア１５からクエリに係るデータを読み出してよい。

（通常インデックス無しの問い合わせ（クエリ）の場合）
通常インデックス無しの問い合わせ（クエリ）の場合、図１１に示すように、参照部２４は、ブロックグループ番号Ｎに“０”をセットし（ステップＣ１）、ブロックグループＮに対応するグループマップ１４が“１”か否かを判定する（ステップＣ２）。

判定の結果、グループマップ１４が“１”ではない場合（ステップＣ２でＮｏ）、参照部２４は、ブロックグループＮ内のブロック番号Ｍに“０”をセットし（ステップＣ３）、オリジナルテーブル１１からブロックＭを読み込む（ステップＣ４）。

そして、参照部２４は、ブロックＭから１つレコードを読み出し（ステップＣ５）、ブロックＭから全てのレコードを読み出したか否かを判定する（ステップＣ６）。全てのレコードを読み出していない場合（ステップＣ６でＮｏ）、処理がステップＣ５に移行し、未読出のレコードを読み出す。一方、全てのレコードを読み出した場合（ステップＣ６でＹｅｓ）、参照部２４は、Ｍに１を加算し（ステップＣ７）、Ｍが最大のブロック番号を超えたか否かを判定する（ステップＣ８）。

ＭがブロックグループＮ内の最大のブロック番号を超えていない場合（ステップＣ８でＮｏ）、処理がステップＣ４に移行し、オリジナルテーブル１１から次のブロックＭを読み出す。一方、Ｍが最大のブロック番号を超えた場合（ステップＣ８でＹｅｓ）、処理がステップＣ１１に移行する。

ステップＣ２において、ブロックグループＮに対応するグループマップ１４が“１”の場合（ステップＣ２でＹｅｓ）、参照部２４は、ブロックグループＮに対応するカラムストア１５の列セグメント１６から１つレコードを読み出す（ステップＣ９）。そして、参照部２４は、当該列セグメント１６から全てのレコードを読み出したか否かを判定する（ステップＣ１０）。全てのレコードを読み出していない場合（ステップＣ１０でＮｏ）、処理がステップＣ９に移行し、未読出のレコードを読み出す。一方、全てのレコードを読み出した場合（ステップＣ１０でＹｅｓ）、処理がステップＣ１１に移行する。

ステップＣ１１では、参照部２４は、Ｎに１を加算する。そして、参照部２４は、Ｎが最大のブロックグループ番号を超えたか否かを判定する（ステップＣ１２）。

Ｎが最大のブロックグループ番号を超えていない場合（ステップＣ１２でＮｏ）、処理がステップＣ２に移行し、参照部２４は、次のブロックグループＮについて判定を行なう。一方、Ｎが最大のブロックグループ番号を超えた場合（ステップＣ１２でＹｅｓ）、処理が終了する。

このように、ステップＣ２におけるグループマップ１４が“１”か否かの判定結果、換言すれば列セグメント１６が有効か否かの判定結果に応じて、レコードを読み出すターゲットが列セグメント１６及びオリジナルテーブル１１から選択される（図５参照）。

なお、ステップＣ５及びＣ９において読み出されたレコードは、例えばメモリに格納・蓄積され、クエリの全てのレコードが読み出されたときにメモリから読み出され、通信部２１を介してホスト３０に送信されてよい。

（通常インデックス有りの問い合わせ（クエリ）の場合）
通常インデックス１７を用いて検索する場合、図１２に示すように、参照部２４は、条件（例えば、“ColA BETWEEN 4 AND 6”）に従う通常インデックス１７内のレコードＩＤ Ｒを１つ取り出す（ステップＣ２１）。

そして、参照部２４は、当該レコードＩＤ Ｒに対応するグループマップ１４が“１”か否かを判定する（ステップＣ２２）。

グループマップ１４が“１”ではない場合（ステップＣ２２でＮｏ）、参照部２４は、オリジナルテーブル１１からレコードＩＤ Ｒのレコードを読み出し（ステップＣ２３）、処理がステップＣ２５に移行する。一方、グループマップ１４が“１”の場合（ステップＣ２２でＹｅｓ）、参照部２４は、カラムストア１５の列セグメント１６からレコードＩＤ Ｒのレコードを読み出し（ステップＣ２４）、処理がステップＣ２５に移行する。

ステップＣ２５では、参照部２４は、条件に従う全てのレコードを通常インデックス１７から読み出したか否かを判定する。全てのレコードを通常インデックス１７から読み出していない場合（ステップＣ２５でＮｏ）、処理がステップＣ２１に移行し、未取出のレコードＩＤ Ｒを１つ取り出す。一方、全てのレコードを通常インデックス１７から読み出した場合（ステップＣ２５でＹｅｓ）、処理が終了する。

このように、通常インデックス１７から読み出したレコードごとに列セグメント１６が有効か否かを判定することで、レコードを読み出すターゲットが列セグメント１６及びオリジナルテーブル１１から選択される（図６参照）。

（通常インデックス有りの問い合わせ（クエリ）の場合の変形例）
次に、図１３を参照して、通常インデックス１７を用いて検索する場合の変形例として、図７に例示するビットマップフィルタ１８を用いる場合を説明する。図１３は、図１２のステップＣ２１をステップＣ３１〜Ｃ３４に置き換えるとともに、図１２のステップＣ２５をステップＣ３５に置き換えたものである。

図１３に示すように、参照部２４は、条件（例えば、“ColA BETWEEN 4 AND 6”）に従う通常インデックス１７内の行を１つ読み出す（ステップＣ３１）。そして、参照部２４は、通常インデックス１７から読み出した行のレコードＩＤに対応する位置のビットマップ１８に“１”をセットする（ステップＣ３２）。

参照部２４は、条件に従う全てのレコードを通常インデックス１７から読み出したか否かを判定する（ステップＣ３３）。全てのレコードを通常インデックス１７から読み出していない場合（ステップＣ３３でＮｏ）、処理がステップＣ３１に移行し、参照部２４は、条件に従う通常インデックス１７内の未読出の行を１つ読み出す。

一方、全てのレコードを通常インデックス１７から読み出した場合（ステップＣ３３でＹｅｓ）、参照部２４は、ビットマップ１８内の“１”がセットされたレコードＩＤ Ｒを１つ取り出す（ステップＣ３４）。

そして、参照部２４は、当該レコードＩＤ Ｒに対応するグループマップ１４が“１”か否かを判定し、当該グループマップ１４の値に応じて、オリジナルテーブル１１又は列セグメント１６からレコードＩＤ Ｒのレコードを読み出す。これらの処理は、図１２のステップＣ２２〜Ｃ２４と同様である。

オリジナルテーブル１１又は列セグメント１６からレコードを読み出すと、参照部２４は、ビットマップ１８内の“１”がセットされた全てのレコードを読み出したか否かを判定する（ステップＣ３５）。

全てのレコードを読み出していない場合（ステップＣ３５でＮｏ）、処理がステップＣ３４に移行し、参照部２４は、ビットマップ１８内の“１”がセットされた未取出のレコードＩＤ Ｒを１つ取り出す。一方、全てのレコードを読み出した場合（ステップＣ３５でＹｅｓ）、処理が終了する。

〔１−４〕ハードウェア構成例
次に、情報処理システム１のハードウェア構成例について説明する。図１４に示すように、コントローラ２０は、例示的に、ＣＰＵ２０ａ、メモリ２０ｂ、記憶部２０ｃ、ＩＦ（Interface）部２０ｄ、Ｉ／Ｏ部２０ｅ、及び読取部２０ｆをそなえてよい。

ＣＰＵ２０ａは、種々の制御や演算を行なうプロセッサ又は演算処理装置の一例である。ＣＰＵ２０ａは、コントローラ２０内の各ブロックとバスで相互に通信可能に接続されてよい。プロセッサとしては、ＣＰＵ２０ａに代えて、例えば、ＭＰＵ、ＤＳＰ、ＡＳＩＣ、ＦＰＧＡ等の集積回路が用いられてもよい。なお、ＭＰＵはMicro Processing Unitの略称であり、ＤＳＰはDigital Signal Processorの略称であり、ＡＳＩＣはApplication Specific Integrated Circuitの略称であり、ＦＰＧＡはField-Programmable Gate Arrayの略称である。

メモリ２０ｂは、種々のデータやプログラム等の情報を格納するハードウェアの一例である。メモリ２０ｂとしては、例えばＲＡＭ（Random Access Memory）等の揮発性メモリが挙げられる。

記憶部２０ｃは、種々のデータやプログラム等の情報を格納するハードウェアの一例である。記憶部２０ｃとしては、例えばＨＤＤ等の磁気ディスク装置、ＳＳＤ等の半導体ドライブ装置、不揮発性メモリ等の各種記憶装置が挙げられる。不揮発性メモリとしては、例えば、フラッシュメモリ、ＳＣＭ、ＲＯＭ等が挙げられる。

例えば記憶部２０ｃは、コントローラ２０の各種機能の全部若しくは一部を実現するプログラム２０ｈを格納してよい。ＣＰＵ２０ａは、例えば記憶部２０ｃに格納されたプログラム２０ｈをメモリ２０ｂに展開して実行することにより、図３に示すコントローラ２０の通信部２１、変換部２２、更新部２３、及び参照部２４としての機能を実現できる。

なお、図３に示す例では、コントローラ２０とは別にデータベース１０が存在するが、これに限定されるものではなく、コントローラ２０の例えばメモリ２０ｂ又は記憶部２０ｃによりデータベース１０が実現されてもよい。この場合、メモリ２０ｂ又は記憶部２０ｃは、図３に示すオリジナルテーブル１１、ブロックマップ１３、グループマップ１４、カラムストア１５、通常インデックス１７、及びビットマップフィルタ１８等の情報を記憶してよい。また、コントローラ２０とは別にデータベース１０が存在する場合であっても、メモリ２０ｂ又は記憶部２０ｃは、データベース１０を実現する記憶部との間で、これらの情報を分散して記憶してもよい。

ＩＦ部２０ｄは、ネットワーク４０又はデータベース１０との間の接続及び通信の制御等を行なう通信インタフェースの一例である。例えばＩＦ部２０ｄは、ＬＡＮ、インフィニバンド（Infiniband）、ＦＣ（Fibre Channel；ファイバチャネル）等の光通信、ＵＳＢ（Universal Serial Bus）、又はＢｌｕｅｔｏｏｔｈ（登録商標）等に準拠したアダプタが挙げられる。

なお、プログラム２０ｈは、ネットワーク４０等からＩＦ部２０ｄを介してコントローラ２０にダウンロードされてもよい。

Ｉ／Ｏ部２０ｅは、マウス、キーボード、又は操作ボタン等の入力部、並びに、ディスプレイ又はプリンタ等の出力部、の一方又は双方を含んでよい。

読取部２０ｆは、記録媒体２０ｇに記録されたデータやプログラムの情報を読み出すリーダの一例である。読取部２０ｆは、記録媒体２０ｇを接続可能又は挿入可能な接続端子又は装置を含んでよい。読取部２０ｆとしては、例えばＵＳＢ等に準拠したアダプタ、記録ディスクへのアクセスを行なうドライブ装置、ＳＤカード等のフラッシュメモリへのアクセスを行なうカードリーダ等が挙げられる。なお、記録媒体２０ｇにはプログラム２０ｈが格納されてもよい。

記録媒体２０ｇとしては、例示的に、磁気／光ディスクやフラッシュメモリ等の非一時的な記録媒体が挙げられる。磁気／光ディスクとしては、例示的に、フレキシブルディスク、ＣＤ（Compact Disc）、ＤＶＤ（Digital Versatile Disc）、ブルーレイディスク、ＨＶＤ（Holographic Versatile Disc）等が挙げられる。フラッシュメモリとしては、例示的に、ＵＳＢメモリやＳＤカード等が挙げられる。なお、ＣＤとしては、例示的に、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ等が挙げられる。また、ＤＶＤとしては、例示的に、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＤＶＤ−Ｒ、ＤＶＤ−ＲＷ、ＤＶＤ＋Ｒ、ＤＶＤ＋ＲＷ等が挙げられる。

上述したコントローラ２０のハードウェア構成は例示である。従って、コントローラ２０内でのハードウェアの増減（例えば任意のブロックの追加や削除）、分割、任意の組み合わせでの統合、又は、バスの追加若しくは削除等は適宜行なわれてもよい。

〔２〕その他
上述した一実施形態に係る技術は、以下のように変形、変更して実施することができる。

例えば、図３に示すコントローラ２０の各機能ブロックは、それぞれ任意の組み合わせで併合してもよく、分割してもよい。

また、コントローラ２０の機能は、マルチプロセッサやマルチコアのＣＰＵ２０ａによって実現されてもよい。さらに、コントローラ２０及びデータベース１０の機能は、例えばクラウド環境のように、複数のコンピュータに分散又は冗長化して配置されてもよい。

また、情報処理システム１において、コントローラ２０及びデータベース１０が１つのコンピュータとして併合されてもよい。

一実施形態では、列セグメント１６がブロックグループごとに生成されるものとしたが、これに限定されるものではない。例えば、ＤＢブロック１２ごとに列セグメント１６が生成されてもよい。この場合、ＤＢブロック１２が、複数のレコードのグループの一例となり、ブロックマップ１３が、グループごとに対応する列セグメント１６が有効か否かを表すグループ情報の一例となる。

〔３〕付記
以上の実施形態に関し、さらに以下の付記を開示する。

（付記１）
行指向データベースと、前記行指向データベースから変換される列指向データベースとを記憶する記憶装置と、
前記記憶装置を制御する制御装置とをそなえ、
前記制御装置は、
前記行指向データベースに含まれる複数のレコードを複数のグループに分け、前記グループごとに、当該グループを前記列指向データベースのフォーマットに従った列グループに変換する変換部、をそなえる
ことを特徴とする、情報処理システム。

（付記２）
前記変換部は、前記グループごとに対応する列グループが有効か否かを表すグループ情報に基づいて、前記変換を行なう、
ことを特徴とする、付記１記載の情報処理システム。

（付記３）
前記変換部は、列グループが無効であるグループ内の複数のレコードに対する全ての更新が確定している場合に、当該更新が確定しているグループを列グループに変換し、変換した前記列グループが有効であることを前記グループ情報に設定する、
ことを特徴とする、付記２記載の情報処理システム。

（付記４）
前記制御装置は、
前記行指向データベースにおいて更新されるレコードを含むグループの列グループが無効であることを前記グループ情報に設定する無効化部、をさらにそなえる
ことを特徴とする、付記２又は付記３記載の情報処理システム。

（付記５）
前記制御装置は、
前記行指向データベースに対する参照要求で指定されたレコードの読出ターゲットを、前記行指向データベース及び前記列指向データベースのうちのいずれかから前記グループ情報に基づき判定し、判定した読出ターゲットから前記参照要求で指定されたレコードを読み出す読出部、をさらにそなえる
ことを特徴とする、付記２〜４のいずれか１項記載の情報処理システム。

（付記６）
前記変換部は、前記変換を行なったグループ内の各レコードの識別情報と、前記変換で生成された列グループ内の当該レコードに対応するデータの相対位置との関係を表す関係情報を生成し、
前記読出部は、
前記行指向データベースに対して設定されたインデックスを用いて前記参照要求で指定されたレコードを特定し、
前記読出ターゲットが前記列指向データベースである場合、前記関係情報に基づいて、前記インデックスを用いて特定したレコードに対応する前記列グループ内のデータの相対位置を特定する、
ことを特徴とする、付記５記載の情報処理システム。

（付記７）
前記読出部は、前記インデックスを用いて特定したレコードを、レコードの識別情報の順に並んだビットマップに設定し、前記ビットマップに設定されたレコードについて、前記レコードの識別情報の順に前記読出ターゲットの判定を行なう、
ことを特徴とする、付記６記載の情報処理システム。

（付記８）
前記読出部は、前記参照要求で指定されたレコードを含むグループの列グループが無効である場合に前記行指向データベースを選択し、前記参照要求で指定されたレコードを含むグループの列グループが有効である場合に前記列指向データベースを選択する、
ことを特徴とする、付記５〜７のいずれか１項記載の情報処理システム。

（付記９）
前記変換部は、前記変換により生成された列グループ内のデータごとに、前記変換を行なったグループ内の対応するレコードの識別情報との関係を表す情報を生成する、
ことを特徴とする、付記１〜８のいずれか１項記載の情報処理システム。

（付記１０）
行指向データベースに含まれる複数のレコードを複数のグループに分け、前記グループごとに、当該グループを列指向データベースのフォーマットに従った列グループに変換する変換部、をそなえる
ことを特徴とする、制御装置。

（付記１１）
前記変換部は、前記グループごとに対応する列グループが有効か否かを表すグループ情報に基づいて、前記変換を行なう、
ことを特徴とする、付記１０記載の制御装置。

（付記１２）
前記変換部は、列グループが無効であるグループ内の複数のレコードに対する全ての更新が確定している場合に、当該更新が確定しているグループを列グループに変換し、変換した前記列グループが有効であることを前記グループ情報に設定する、
ことを特徴とする、付記１１記載の制御装置。

（付記１３）
前記行指向データベースにおいて更新されるレコードを含むグループの列グループが無効であることを前記グループ情報に設定する無効化部、をさらにそなえる
ことを特徴とする、付記１１又は付記１２記載の制御装置。

（付記１４）
前記行指向データベースに対する参照要求で指定されたレコードの読出ターゲットを、前記行指向データベース及び前記列指向データベースのうちのいずれかから前記グループ情報に基づき判定し、判定した読出ターゲットから前記参照要求で指定されたレコードを読み出す読出部、をさらにそなえる
ことを特徴とする、付記１１〜１３のいずれか１項記載の制御装置。

（付記１５）
コンピュータに、
行指向データベースに含まれる複数のレコードを複数のグループに分け、前記グループごとに、当該グループを列指向データベースのフォーマットに従った列グループに変換する
処理を実行させることを特徴とする、処理プログラム。

（付記１６）
前記コンピュータに、
前記グループごとに対応する列グループが有効か否かを表すグループ情報に基づいて、前記変換を行なう、
処理を実行させることを特徴とする、付記１５記載の処理プログラム。

（付記１７）
前記コンピュータに、
列グループが無効であるグループ内の複数のレコードに対する全ての更新が確定している場合に、当該更新が確定しているグループを列グループに変換し、変換した前記列グループが有効であることを前記グループ情報に設定する、
処理を実行させることを特徴とする、付記１６記載の処理プログラム。

（付記１８）
制御装置が、行指向データベースに含まれる複数のレコードを複数のグループに分け、前記グループごとに、当該グループを列指向データベースのフォーマットに従った列グループに変換する
ことを特徴とする、処理方法。

（付記１９）
前記制御装置が、前記グループごとに対応する列グループが有効か否かを表すグループ情報に基づいて、前記変換を行なう、
ことを特徴とする、付記１８記載の処理方法。

（付記２０）
前記制御装置が、列グループが無効であるグループ内の複数のレコードに対する全ての更新が確定している場合に、当該更新が確定しているグループを列グループに変換し、変換した前記列グループが有効であることを前記グループ情報に設定する、
ことを特徴とする、付記１９記載の処理方法。

１ 情報処理システム
１０ データベース
１１ オリジナルテーブル
１２ ＤＢブロック
１３ ブロックマップ
１４ グループマップ
１５ カラムストア・インデックス
１６ 列セグメント
１６ａ 列セグメント内オフセット番号
１６ｂ データ
１６ｃ 変換表
１６ｄ 変換ツリー
１７ 通常インデックス
１８ ビットマップフィルタ
２０ コントローラ
２１ 通信部
２２ 変換部
２３ 更新部
２４ 参照部
３０ ホスト
４０ ネットワーク

Claims (11)

1. 行指向データベースと、前記行指向データベースから変換される列指向データベースとを記憶する記憶装置と、
   前記記憶装置を制御する制御装置とをそなえ、
   前記制御装置は、
   前記行指向データベースに含まれる複数のレコードを複数のグループに分け、前記グループごとに、当該グループを前記列指向データベースのフォーマットに従った列グループに変換する変換部、をそなえる
   ことを特徴とする、情報処理システム。
2. 前記変換部は、前記グループごとに対応する列グループが有効か否かを表すグループ情報に基づいて、前記変換を行なう、
   ことを特徴とする、請求項１記載の情報処理システム。
3. 前記変換部は、列グループが無効であるグループ内の複数のレコードに対する全ての更新が確定している場合に、当該更新が確定しているグループを列グループに変換し、変換した前記列グループが有効であることを前記グループ情報に設定する、
   ことを特徴とする、請求項２記載の情報処理システム。
4. 前記制御装置は、
   前記行指向データベースにおいて更新されるレコードを含むグループの列グループが無効であることを前記グループ情報に設定する無効化部、をさらにそなえる
   ことを特徴とする、請求項２又は請求項３記載の情報処理システム。
5. 前記制御装置は、
   前記行指向データベースに対する参照要求で指定されたレコードの読出ターゲットを、前記行指向データベース及び前記列指向データベースのうちのいずれかから前記グループ情報に基づき判定し、判定した読出ターゲットから前記参照要求で指定されたレコードを読み出す読出部、をさらにそなえる
   ことを特徴とする、請求項２〜４のいずれか１項記載の情報処理システム。
6. 前記変換部は、前記変換を行なったグループ内の各レコードの識別情報と、前記変換で生成された列グループ内の当該レコードに対応するデータの相対位置との関係を表す関係情報を生成し、
   前記読出部は、
   前記行指向データベースに対して設定されたインデックスを用いて前記参照要求で指定されたレコードを特定し、
   前記読出ターゲットが前記列指向データベースである場合、前記関係情報に基づいて、前記インデックスを用いて特定したレコードに対応する前記列グループ内のデータの相対位置を特定する、
   ことを特徴とする、請求項５記載の情報処理システム。
7. 前記読出部は、前記インデックスを用いて特定したレコードを、レコードの識別情報の順に並んだビットマップに設定し、前記ビットマップに設定されたレコードについて、前記レコードの識別情報の順に前記読出ターゲットの判定を行なう、
   ことを特徴とする、請求項６記載の情報処理システム。
8. 前記変換部は、前記変換により生成された列グループ内のデータごとに、前記変換を行なったグループ内の対応するレコードの識別情報との関係を表す情報を生成する、
   ことを特徴とする、請求項１〜７のいずれか１項記載の情報処理システム。
9. 行指向データベースに含まれる複数のレコードを複数のグループに分け、前記グループごとに、当該グループを列指向データベースのフォーマットに従った列グループに変換する変換部、をそなえる
   ことを特徴とする、制御装置。
10. コンピュータに、
    行指向データベースに含まれる複数のレコードを複数のグループに分け、前記グループごとに、当該グループを列指向データベースのフォーマットに従った列グループに変換する
    処理を実行させることを特徴とする、処理プログラム。
11. 制御装置が、行指向データベースに含まれる複数のレコードを複数のグループに分け、前記グループごとに、当該グループを列指向データベースのフォーマットに従った列グループに変換する
    ことを特徴とする、処理方法。

Images