JP2014191593A - カラムストア型データベース管理システム - Google Patents

Abstract

【課題】同一の列中に完全に一致するデータの数が少ない場合にはデータの圧縮率を高めることは困難であること。
【解決手段】表領域とスキーマ領域とデータベース管理部とを有する。スキーマ領域は、表に関する管理情報を格納し、管理情報は、表の少なくとも１つの列に関連して、列が分割対象列であることを表す情報と、列中のデータに共通に出現する文字である基準文字の情報と、列を基準文字に一致する文字の箇所で複数の部分列に分割する分割方法に関する情報と、表領域における複数の部分列のデータを保存する領域に関する情報とを有する。データベース管理部は、スキーマ領域に格納された表に関する管理情報を参照して表領域に表の表データを格納し、表領域への表の表データの格納では、表の列単位および部分列単位で重複するデータを排除する。
【選択図】図１

Description

本発明は、カラムストア型データベース管理システム、データ圧縮方法、およびプログラムに関する。

リレーショナルデータベース管理システム（ＲＤＢＭＳ）は、幾つかの列からなる行の集合である表として情報を蓄積する方式のデータベースシステムである。リレーショナルデータベース管理システムには、一般的な行指向のリレーショナルデータベース管理システムと、カラムストア型データベース管理システムと呼ばれる列指向のリレーショナルデータベース管理システムとがある。前者の一般的なリレーショナルデータベース管理システムは、行方向にデータをまとめて扱うため、追加、更新、削除を伴うオンライントランザクション処理に適している。他方、後者のカラムストア型データベース管理システムは、列方向にデータをまとめて扱うため、列を抜き出して操作する集計処理などに適している。本発明は、後者のカラムストア型データベース管理システムの改良に関する。

カラムストア型データベース管理システムは、一般のリレーショナルデータベース管理システムと同様に、表領域とスキーマ領域とを有する。表領域は、表の内容自体を格納する記憶領域であり、スキーマ領域は、表の名前や列のデータ型など、表自体に関する情報を格納する領域である。そして、列方向にデータをまとめて扱うカラムストア型データベース管理システムでは、列方向のデータが同じデータ型であり、同じ値が繰り返し現れることに着目し、列単位で重複するデータを排除することにより、データの圧縮を行っている（例えば特許文献１参照）。

一方、ＧＰＵ等の並列演算器を有するカラムストア型データベース管理システムにおいて、演算器のデータ処理単位に適したフラグメント長（例えば、４、８、１６、３２、６４バイト等）を決定し、可変長データを含むタプルデータ（カラムタプル）を、必要に応じて複数のフラグメントからなるフラグメントセットへ格納することが、本発明に関連する第１の関連技術として提案されている（例えば特許文献２参照）。

また、重複排除により削減されるデータ量を増加させるために、情報記憶部に記憶されている情報が有する付加情報に示された分割単位よりも小さい分割単位でデータ取得部より取得されたデータを分割して重複排除を行うことが、本発明に関連する第２の関連技術として提案されている（例えば特許文献３参照）。

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

上述したように、カラムストア型データベース管理システムでは、列単位で重複するデータを排除することにより、データの圧縮を行っている。従って、同一の列に同じ値が繰り返し現れるほどに、圧縮効果が高まる。しかし、重複により排除されるデータは、完全に一致するデータに限られるため、同一の列中に完全に一致するデータの数が少ない場合にはデータの圧縮率を高めることは困難である。

特許文献２および特許文献３に記載される技術をカラムストア型データベース管理システムに適用し、同一の列のデータを演算器のデータ処理単位に適した固定長の部分データに分割して重複排除することが考えられる。しかし、同一の列中に完全に一致するデータの数が少ない場合に列中のデータを固定長の複数の部分データに分割しても分割後の部分データ同士が同じになるケースは殆どない。そのため、固定長に分割する方法では、データの圧縮率を高めることは困難である。

本発明の目的は、上述した課題、すなわち、同一の列中に完全に一致するデータの数が少ない場合にはデータの圧縮率を高めることは困難である、という課題を解決するカラムストア型データベース管理システムを提供することにある。

本発明の第１の観点に係るカラムストア型データベース管理システムは、
表領域とスキーマ領域とデータベース管理部とを有するカラムストア型データベース管理システムであって、
前記スキーマ領域は、表に関する管理情報を格納し、前記管理情報は、前記表の少なくとも１つの列に関連して、前記列が分割対象列であることを表す情報と、前記列中のデータに共通に出現する文字である基準文字の情報と、前記列を前記基準文字に一致する文字の箇所で複数の部分列に分割する分割方法に関する情報と、前記表領域における前記複数の部分列のデータを保存する領域に関する情報とを有し、
前記データベース管理部は、前記スキーマ領域に格納された前記表に関する前記管理情報を参照して前記表領域に前記表の表データを格納し、前記表領域への前記表の表データの格納では、前記表の列単位および部分列単位で重複するデータを排除する。

本発明は上述した構成を有するため、同一の列中に完全に一致するデータの数が少ない場合であっても、データの圧縮率を高めることが可能になる。

本発明の第１の実施形態のブロック図である。 本発明の第１の実施形態の動作の一例を示すフローチャートである。 本発明の第２の実施形態のブロック図である。 本発明の第２の実施形態においてデータベースに保存するテーブルの一例を示す図である。 既存のカラムストア型データベースの実データ領域とインデックス領域に保存されるデータの一例を示す図である。 本発明の第２の実施形態においてデータベースの実データ領域とインデックス領域に保存されるデータの一例を示す図である。 本発明の第３の実施形態においてデータベースに保存するテーブルの一例を示す図である。 本発明の第３の実施形態においてデータベースの実データ領域とインデックス領域に保存されるデータの一例を示す図である。 本発明の第４の実施形態のブロック図である。

次に本発明の実施の形態について図面を参照して詳細に説明する。
[第１の実施形態]
図１を参照すると、本発明の第１の実施形態に係るカラムストア型データベース管理システム１００は、通信Ｉ／Ｆ（インターフェイス）部１１０と、操作入力部１２０と、画面表示部１３０と、記憶部１４０と、プロセッサ１５０とを有する。

通信Ｉ／Ｆ部１１０は、専用のデータ通信回路からなり、通信回線を介して接続されたデータベースクライアントなどの各種装置との間でデータ通信を行う機能を有している。

操作入力部１２０は、キーボードやマウスなどの操作入力装置からなり、オペレータの操作を検出してプロセッサ１５０に出力する機能を有している。

画面表示部１３０は、ＬＣＤ（Liquid Crystal Display）やＰＤＰ（Plasma Display
Panel）などの画面表示装置からなり、プロセッサ１５０からの指示に応じて、操作メニューなどの各種情報を画面表示する機能を有している。

記憶部１４０は、ハードディスクやメモリなどの記憶装置からなり、プロセッサ１５０での各種処理に必要な処理情報を記憶する領域やプログラム１４０Ｐを記憶する領域を有している。プログラム１４０Ｐは、プロセッサ１５０に読み込まれて実行されることにより各種処理部を実現するプログラムであり、通信Ｉ／Ｆ部１１０などのデータ入出力機能を介して外部装置（図示せず）や記憶媒体（図示せず）から予め読み込まれて記憶部１４０に保存される。主な処理情報を記憶する記憶部１４０の領域として、表領域１４０Ａとスキーマ領域１４０Ｂとがある。

表領域１４０Ａは、表の内容自体である表データ１４０Ａ１を格納する機能を有する。表は幾つかの列からなる行の集合である。表領域１４０Ａでは、列方向にデータをまとめて格納する。

スキーマ領域１４０Ｂは、表に関する管理情報１４０Ｂ１を格納する機能を有する。表に関する管理情報１４０Ｂ１は、表の名前、列の数、各々の列に関する各種情報などである。本実施形態では、管理情報１４０Ｂ１は、表の少なくとも１つの列に関連して、分割対象列に関する管理情報１４０Ｂ１１を有している。

分割対象列に関する管理情報１４０Ｂ１１は、情報１４０Ｂ１１１〜１４０Ｂ１１４から構成される。情報１４０Ｂ１１１は、当該列が分割対象列であることを表している。情報１４０Ｂ１１２は、当該列中のデータに共通に出現する文字である基準文字を表している。情報１４０Ｂ１１３は、当該列を上記基準文字に一致する文字の箇所で複数の部分列に分割する分割方法を表している。情報１４０Ｂ１１４は、表領域１４０Ａにおける上記複数の部分列のデータを保存する領域を特定している。

プロセッサ１５０は、ＭＰＵなどのマイクロプロセッサとその周辺回路を有し、記憶部１４０からプログラム１４０Ｐを読み込んで実行することにより、上記ハードウェアとプログラム１４０Ｐとを協働させてデータベース管理部１５０Ａを実現する機能を有している。データベース管理部１５０Ａは、表領域１４０Ａとスキーマ領域１４０Ｂとによって構成されるカラムストア型データベースの全般を管理する機能を有する。データベース管理部１５０Ａの有する主な機能部として、表作成部１５０Ａ１と表データ格納部１５０Ａ２と検索部１５０Ａ３とがある。

表作成部１５０Ａ１は、表定義情報を操作入力部１２０あるいは通信Ｉ／Ｆ部１１０を通じて外部から入力し、この入力した表定義情報に従って、スキーマ領域１４０Ｂ上に、表に関する管理情報１４０Ｂ１を生成する機能を有する。

表データ格納部１５０Ａ２は、表データを操作入力部１２０あるいは通信Ｉ／Ｆ部１１０を通じて外部から入力し、スキーマ領域１４０Ｂに格納されている表に関する管理情報１４０Ｂ１を参照して、上記入力した表データを表領域１４０Ａの表データ１４０Ａ１に格納する機能を有する。表データ格納部１５０Ａ２は、表領域１４０Ａへの表データの格納では、既存のカラムストア型データベースと同様の手法を用いて、表の列単位で重複するデータを排除する。また表データ格納部１５０Ａ２は、分割対象列に関する管理情報１４０Ｂ１１が記載されている列に関しては、その列単位ではなく、その列を構成する部分列単位で重複するデータを排除する。部分列単位で重複するデータを排除する手法は、列単位で重複するデータを排除する手法と同じ手法を使用してもよいし、他の手法を使用してもよい。

検索部１５０Ａ３は、検索要求を操作入力部１２０あるいは通信Ｉ／Ｆ部１１０を通じて外部から入力し、スキーマ領域１４０Ｂに格納された表に関する管理情報１４０Ｂ１を参照して、表領域１４０Ａに格納された表データ１４０Ａ１を検索する。検索部１５０Ａ３は、表データ１４０Ａ１の検索では、分割対象列に関する管理情報１４０Ｂ１１を参照して、検索対象とする列が分割対象列か否かを判定し、分割対象列の場合、複数の部分列のデータを結合して分割前のデータを再構成した上で検索を行う。

次に本実施形態に係るカラムストア型データベース管理システム１００の動作を図２のフローチャートを参照して説明する。

プロセッサ１５０上のデータベース管理部１５０Ａは、起動されると、操作入力部１２０または通信Ｉ／Ｆ部１１０からの要求の入力を待ち合わせる（ステップＳ１０１）。何らかの要求の入力があると、データベース管理部１５０Ａは、要求種別に応じた処理を実行する（ステップＳ１０２）。

要求が表作成の場合、データベース管理部１５０Ａは、表作成部１５０Ａ１を起動する。表作成部１５０Ａ１は、要求に付加されている表定義情報に従って、スキーマ領域１４０Ｂ上に、表に関する管理情報１４０Ｂ１を生成する（ステップＳ１０３）。

通常、表定義情報には、表の名前、各列の名前やデータ型といった情報が含まれる。表作成部１５０Ａ１は、ステップＳ１０３では、これらの情報を表定義情報から抽出して、スキーマ領域１４０Ｂの表に関する管理情報１４０Ｂ１に格納する。

また、或る列は、列全体としてはデータが重複することは皆無であるが、或る文字の箇所で複数の部分列に分割すると、部分列としては重複するデータが少なからず発生することが予想される場合、入力の表定義情報において、当該列を分割対象列として記述しておく。加えて、入力の表定義情報に、分割する際の基準となる文字とその分割方法とを記述しておく。例えば、メールアドレスを記憶する列は、列全体としてはデータが重複する可能性は存在しないが、＠の箇所でユーザ名とドメイン名とに分割すると、ドメイン名の部分について重複するデータが発生する。この場合、＠を基準文字に指定し、＠より前半部分と、＠を含む後半部分との２つの部分に分割することを入力の表定義情報に記述しておく。表作成部１５０Ａ１は、ステップＳ１０３では、そのような入力情報に従って、分割対象列として記述された列に関連して、当該列が分割対象列であることを表す情報１４０Ｂ１１１と、当該列中の基準文字（今の例では＠）の情報１４０Ｂ１１２と、当該列を上記基準文字に一致する文字の箇所で複数の部分列に分割する分割方法に関する情報１４０Ｂ１１３と、表領域１４０Ａにおける上記複数の部分列のデータを保存する領域に関する情報１４０Ｂ１１４とを生成し、これらの情報を有する分割対象列に関する管理情報１４０Ｂ１１を管理情報１４０Ｂ１に格納する。

また、要求が表データの格納であった場合、データベース管理部１５０Ａは、表データ格納部１５０Ａ２を起動する。表データ格納部１５０Ａ２は、要求に付加されている表データを、スキーマ領域１４０Ｂに格納されている表に関する管理情報１４０Ｂ１を参照して、表領域１４０Ａの表データ１４０Ａ１に格納する（ステップＳ１０４）。このとき、表データ格納部１５０Ａ２は、表の列単位および部分列単位で重複するデータを排除する。例えば、格納する表データに前述したメールアドレスの列が存在する場合、メールアドレスを＠の箇所で複数の部分列のデータに分割して保存するが、既に同じ部分列のデータが表データ１４０Ａ１に存在する場合には、同じ部分列のデータが重複して保存されないようにする。

また、要求が検索であった場合、データベース管理部１５０Ａは、検索部１５０Ａ３を起動する。検索部１５０Ａ３は、検索要求に付随する検索条件に従って、スキーマ領域１４０Ｂに格納された表に関する管理情報１４０Ｂ１を参照して、表領域１４０Ａに格納された表データ１４０Ａ１を検索し、検索結果を画面表示部１３０に出力し、或いは通信Ｉ／Ｆ部１１０から外部へ送信する（ステップＳ１０５）。検索部１５０Ａ３は、ステップＳ１０５における表データ１４０Ａ１の検索では、分割対象列に関する管理情報１４０Ｂ１１を参照し、検索対象とする列が分割対象列の場合、分割とは逆の方法により複数の部分列のデータを結合して分割前のデータを再構成した上で検索を行う。

このように本実施形態によれば、同一の列中に完全に一致するデータの数が少ない場合であっても、データの圧縮率を高めることが可能になる。その理由は、同一の列中のデータに或る文字が共通に出現する場合にはその列中のデータを当該文字の箇所で複数の部分列に分割すると部分列単位で重複するデータが発生する、という経験則を利用し、同一の列中のデータに共通に出現する文字を基準文字とし、その列中のデータを上記基準文字に一致する文字の箇所で複数の部分列に分割し、部分列単位で重複するデータを排除するためである。

[第２の実施形態]
次に、本発明の第２の実施形態について、その背景、解決しようとする課題、概要、構成、動作、および効果の順に説明する。

[背景]
近年のデータ量の増加に伴い、大量データを一括で処理するバッチ処理や、大量のデータからデータマートを作成するようなシステムにおいて、カラム単位でデータを格納するカラムストア型データベースを用いることで集計や結合処理を高速化することにより、高速な処理を実現することを可能としているシステムがある。特にデータベースのデータを全てメモリ上に展開した上で計算処理を行い、高い処理性能を実現しているメモリデータベース管理システムが登場している。

例えばデータ量がシステムの想定以上に増加し、夜間バッチ中に数千万〜数億件に渡るようなデータを複雑な結合や集計が必要な場合に、ディスクベースのデータベースではバッチ処理がシステムの停止時間に間に合わず、業務開始を超えてしまうような危険性がある。このような大規模な処理にメモリデータベース管理システムを利用して処理時間を短縮し、安定的なシステムの構築が可能となっている。

しかし、次のような問題点があった。

第１の問題点は、同一列の複数の件数のデータの中の一部で重複している部分があっても、少しでもデータが異なると列内で重複を排除してデータを圧縮し高速に処理ができるというカラムストア型データベースの特性が利用できないことである。例えば、格納するデータがＵＲＬやメールアドレスなどの場合、ドメイン部分のデータは重複しやすい特性を持っているが、データ全体としてそれぞれは重複のないデータとなりやすい。このようなデータを扱う際にアプリケーション開発者がデータの特性を意識し、重複度合いが高い部分と重複が低い部分とで列自身を分割する方法もあるが、該当の列は不自然なデータとなる可能性があり、データを分割していることを強く意識してアプリケーションを開発する必要がある。また、カラムストア型データベースの性能特性を活かそうと、既存のリレーショナルデータベースのアプリケーションからカラムストアのデータベースに移行する場合などで、すでに保有しているアプリケーション資産を活用する場合はデータ移行およびアプリケーション側の設計変更を行うことが必要となり、この手法を採用することは難しい。

第２の問題点は、データ量の削減方法として、データベースに格納する際に、データ自身を一般的な圧縮アルゴリズムを利用して圧縮する方法が考えられる。これは、ＣＰＵとメモリの性能が格段に向上しているため、ディスクのＩ／Ｏ負荷が全体の性能に大きな影響を与えるケースが多いディスクを格納先としたデータベースであれば、ＣＰＵやメモリ性能が余剰な状態になっているケースが多く、非常に有効な手法である。しかしながら、データの格納先をメモリにしているメモリデータベースシステムであれば、ディスクベースのＩ／Ｏがない分だけ、圧縮アルゴリズムによる圧縮および伸長の計算処理コストが相対的に負荷の高い処理になってしまう。これにより全体のデータベースの処理性能に影響を与える可能性が高いことから、出来るだけＣＰＵ性能に影響を与えにくいシンプルな圧縮方式が求められる。

本実施形態は、以上の問題点を解決するカラムストア型データベース管理システムにおけるデータ圧縮方式を提供する。

[解決しようとする課題]
カラムストア型のデータベースでは、同一列内に同じデータが複数の件数が格納されている場合は重複を排除することでデータを圧縮し、検索やデータ格納に必要なデータ量を削減することで参照処理性能が向上させている。しかし、この同一の列のデータは完全に一致している必要があり、データ内の一部が重複している場合でも、全体としてデータが異なればデータの圧縮効果を出すことはできなかった。この問題に対して、２つの解決のアプローチがある。

１つ目は、データベースの利用者側がある一つの列を２つ以上の列に定義し、データを分割して格納し、一部の重複を有効活用する方法がある。しかしながら、この手法では、アプリケーション側に大きく影響があり、たとえばリレーショナルデータベースからカラムストア型データベース移行した場合などでは列定義を変更するといった場合に、アプリケーション改修のコストの問題から採用が難しい場合がある。

２つ目は、列の格納データ自体を圧縮する手法である。この手法はディスクのＩ／Ｏがネックになりやすいディスクベースのデータ管理システムでは特に有効だが、Ｉ／Ｏ性能が高いメモリ上にデータを構築するメモリデータベース管理システムでは、相対的にＣＰＵに十分負荷がかかりやすく、通常の圧縮アルゴリズムにてデータ圧縮や伸長を行うと全体のデータベース管理システムへの性能の影響を与えやすいという問題点がある。

[概要]
本実施形態では、カラムストア型のデータベース管理システムにおいて、ある列を内部的に複数の列に分割して格納することの表定義を保有し、また列データをどのように分割するかのルールを別に格納している。この表定義と分割するルールにより、論理的に１つの列のデータを複数の物理的な列データに分割してデータベースに格納する。なお、検索などのデータ操作が発生した場合には、論理的な列がどのように物理的な列に分割しているのかを判断して、必要に応じてデータを結合したうえでデータ処理を行い、データの更新や検索などを行う。

このことにより同一列内のデータの中で部分的にデータが異なっているため重複を排除できずデータの圧縮効果が出ない列のデータを、物理上にデータ格納する際に内部的に複数の列に分割することで、部分的なデータの重複を活用して格納データ量の削減を行うことが可能になる。

データ分割は処理内容が容易であるため、通常の圧縮アルゴリズムを用いるより、ＣＰＵへの負荷を抑えたうえでデータ圧縮を実現できる。このことはＩ／Ｏの負荷よりもＣＰＵの負荷が性能に大きく影響するインメモリデータベースでは非常に性能面で有効である。

また、データ操作条件によっては、この列データの分割を行い重複排除したテーブルにおいて、分割した列に対してのみ前方一致、中間一致、後方一致の検索をすることで、検索対象範囲を大幅に減らせ、高速な検索を実現できる。

なお、物理的に分割していることは隠ぺいをしているため、アプリケーションからは内部的に分割することを意識する必要はない。

[構成]
図３を参照すると、本実施形態は、データベースクライアント１と、データベースクライアント１が接続するカラムストア型データベース管理システム２とを含む。本実施形態ではカラムストア型データベース管理システムは１台のマシンを例にしているが、分散データベース管理システムのように複数のマシン台数のデータベース管理システムでもよい。また、データベースクライアント１とカラムストア型データベース管理システム２はネットワークによって接続されていても、同一マシン内でも構わない。

カラムストア型データベース管理システム２は、クエリ解析部２１と実行計画部２２とクエリ実行部２３とテーブルデータ保存領域２４とスキーマ管理データ保存領域２５とを備えており、データベースクライアント１からの問い合わせを受け付け、データの挿入や検索、更新結果をデータベースクライアントに返却をするシステムである。図１に示した第１の実施形態との関係では、テーブルデータ保存領域２４が表領域１４０Ａに相当し、スキーマ管理データ保存領域２５がスキーマ領域１４０Ｂに相当し、クエリ解析部２１と実行計画部２２とクエリ実行部２３とがデータベース管理部１５０Ａに相当する。

クエリ解析部２１は、データベースクライアントから発行されたＳＱＬといった問い合わせ言語の内容を確認し、構文解析を実行する。

実行計画部２２は、クエリ解析部２１で解析した問合せをどのような順番や方法で行えば最も効率的であるかを判定し、その実行計画を作成する。なお、クエリがＳＱＬ言語ではなく、データベースクライアント１からの操作をＡＰＩ等で直接クエリ実行部の動作を指定する場合は、クエリ解析部２１や実行計画部２２は通過しない。

クエリ実行部２３は、実行計画部２２で解析した実行計画によるデータ操作命令、またはデータベースクライアント１から直接受けたデータ操作命令を受けて、テーブルデータ保存領域２４やスキーマ管理データ保存領域２５に向けてクエリを実行する。いわゆるデータベースのエグゼキュータと呼ばれる部分に相当する。

テーブルデータ保存領域２４は、スキーマ管理データ保存領域２５に格納された定義に基づいたデータベースの実データやインデックスデータなどを格納している。このデータ保存領域は、メモリまたはディスク、その他のストレージであるかについては問わない。

スキーマ管理データ保存領域２５は、データベースのスキーマの定義情報を記憶・管理している。スキーマ情報には一般的に保持されるリレーショナルデータモデルでの表やインデックスなどの定義やそれらのデータがどのデバイスのどの位置に格納されているかといった情報が表定義領域２５１に格納されている。またこの表定義の中に、本実施形態で特徴的である論理的な表の中のどの列に対して分割したデータがテーブルデータ保存領域２４のどの列に対応するかの情報も格納されているものとする。列分割文字テーブル２５２は、実際に列データを分割をする基準の文字と分割する最大の列数などの簡単なルールを格納している。

[動作]
次に、図３乃至図６を参照して本実施形態の動作について詳細に説明する。

まず、データベース管理者やユーザなどがデータベースクライアント１からデータベース管理システム２に、ユーザの必要なデータベースのスキーマ定義作成と実データの格納を実施する。なお、本実施形態ではテーブル定義上の１つの列を複数の列に分割して格納する方式を用いるが、その列を「分割圧縮列」と定義する。

スキーマ定義について述べる。データベースクライアント１からコマンド等により、通常のカラムストア型データベースと同様にリレーショナルデータモデルの表定義やインデックス定義を行う。定義方法については一般的に、ＳＱＬ言語によって行われる場合が多いが、その手法を限定するものではない。ＳＱＬ言語を用いる場合はクエリ解析部２１、実行計画部２２を通じてクエリ実行部２３で定義データを生成し、その結果をスキーマ管理データ保存領域２５にある表定義領域２５１に格納する。なお、ＡＰＩ等でデータベース管理システム独自の方法をとる場合は直接クエリ実行部２３に命令し同様にデータを格納する。この時、表定義領域２５１の表定義には本実施形態の特徴である、各列に対して「分割圧縮列」であるか「通常」の列であるかを格納している。また、列分割文字テーブル２５２に格納されたどの分割ルールを使用するかの対応関係と分割後の複数の列データの対応関係も同様に各列に格納する領域を確保しており、これらの情報が表定義領域２５１に格納されている。

列分割文字テーブル２５２には、分割する際の識別子や分割を行う列数などのルールが格納されている。これらの定義についても同様にデータベースクライアント１からＳＱＬ等を用いて定義をする。この時、分割された列のデータで完全一致する重複データができるように分割の列の定義を行うことが本実施形態を効果的に利用する方法である。アプリケーション開発者やデータベース管理者はデータの特性を理解し、分割列の実施有無とルールを判断する必要がある。

これ以降、今回の説明のためのカラムストアデータモデルの例として、同じ列の中で実データの重複を排除してソートした形で格納する「実データ領域」をその列単位に作成・格納した上で、該当のデータ列を参照するインデックスを並べた「インデックス領域」に格納することで、カラム単位の列データを表現させている方式で説明する。「実データ領域」と「インデックス領域」はテーブルデータ保存領域２４の内部に格納されている。具体的な例については後程図４以降の例で述べる。

このデータ領域で重複を排除している機構については、一般的なカラムストア型データベースの特徴になり、それ以外のカラムストア型のデータモデルを利用している場合でも、同様に重複排除の効果を利用している。この重複排除の効果があれば本実施形態の「分割圧縮列」の手法は採用可能である。

次に分割圧縮列を含めた表定義が完了したらデータベースクライアント１から表定義に対応した表データをカラムストア型データベース２にロードする。クエリ実行部２３は、クライアント１から渡されたデータをテーブルデータ保存領域２４に格納する。「分割圧縮列」以外の列については、通常の通り重複を排除した形でデータを格納する。また、本実施形態での特徴である「分割圧縮列」に指定されている列については、列のデータを列分割文字テーブル２５２にある指定された分割文字によって複数の列に分割したうえで、通常の列と同様に重複を排除した形で「実データ領域」にデータを作成する。「分割圧縮列」の「インデックス領域」については分割された実データ領域を分割した列分インデックスが配列と同様の形で保有しており、その配列に書かれているインデックスと対応している実データ領域のデータを順番に結合することで元データを復元することを可能としている。

なお、すでに表にデータが存在している場合には、データベースクライアント１からのデータ定義操作によって分割圧縮列と分割ルールの関係性を該当する列に定義することで、クエリ実行部２５は同様に内部的な列データの分割を行えるものとし、反対に内部列分割を解除して１つの列としてデータを再構成する機能も保有している。

ここで具体的に図４のように顧客テーブルというテーブルを定義し、一般的なカラムストア型データモデルの場合と、本実施形態の場合の違いを述べる。

顧客テーブルは、”顧客id“、”性”、”名”、”メールアドレス”、”性別”という列を持っている。この顧客テーブルを既存のカラムストア型データベースモデルにロードした例が図５のようになる。テーブルデータ保存領域２４にある「実データ領域」には実データの重複が排除されて配置されており、インデックス領域には列の位置に該当する実データと対応した「実データ領域」へのインデックス番号が記載されている。このことにより論理的な顧客テーブルを格納している。例えば、顧客テーブルの２列目の“姓”を参照する時は、顧客テーブルのインデックス列の２列目の姓を確認する。この“１”をもとに実データ列の姓の１番目にある値を確認すれば「鈴木」であることがわかる。

図５の方式では、”姓”、”名”、”性別”などは完全一致しているデータが複数存在するため、重複を排除できているが”メールアドレス”については完全に重複しているデータが１件もないため、すべて顧客データの実データが「実データ領域」に格納されており、データの圧縮効果が全く出ていない。

次に本実施形態を用いてデータをロードした場合について述べる。本実施形態では、データベースクライアント１からＳＱＬ文やＡＰＩなどを利用して、顧客テーブルの“メールアドレス”列のデータの中で最初に出てくる”＠”の文字によって、内部的に前後２つに分割するというルールを列分割文字テーブル２５２に格納する。また表定義領域２５１に格納されている顧客テーブルの“メールアドレス”列の定義には列分割文字テーブル２５２に格納された分割文字のルールに従い、メールアドレスＡ列とメールアドレスＢ列として２つの列に分けて格納することが記載されている。この定義によって、顧客テーブルにデータをロードした場合、テーブルデータ保存領域２４には、メールアドレスＡ列とメールアドレスＢ列の２つの列が、カラムストア型のデータモデルにより格納されるように処理を行う。これらの手法を用いて、実データをロードさせた例が図６のようになる。今回の例では、＠以降の文字列については「＠company-a.ne.jp」と「＠company-b.co.jp」でデータが重複している部分があり、この重複を排除することでデータを圧縮することが可能となる。なお、この時に＠がないデータがあった場合は全てのデータがメールアドレスＡに格納されるものとする。

このように列を分割して格納して作成されたデータベースシステムに対して、データベースクライアント１から検索問い合わせがあった場合は、クエリ実行部２３がスキーマ定義情報をスキーマ管理データ保存領域２５に問い合わせる。該当の列が「分割圧縮列」でなかった場合は、通常通り検索を行うが、「分割圧縮列」である場合は、分割されているそれぞれのデータを検索して結合したうえで処理結果を生成し、データベースクライアント１に返却する。今回の例では、メールアドレスＡの列とメールアドレスＢの列を結合し、メールアドレス列のデータに戻したうえで検索処理を行い、結果を返却する。

また、この格納方式によってデータ自体の圧縮が行われることで、操作対象のデータが削減されることで高速化につながる。特に、前方一致検索、後方一致検索の場合など分割した後の一部の列にとどまる処理で処理が可能な場合である。

例えば、前方一致検索であれば、前方の列データであるメールアドレスＡの実データ領域と比較することで、検索対象のデータの前方一致で一致するもののインデックス列だけが検索対象となり、データの絞り込みが可能となる。これによりメールアドレスＢ列の不必要なデータを読み込む必要がなくなる。

後方一致検索についても同様である。分割した後の列をユーザが意識して検索するＡＰＩなどを提供することでも、データ処理の高速化が可能である。

なお、本実施形態でのデータベースシステムは検索演算を中心に利用するシステムに対して活用し、更新やデータの追記処理については重複排除の処理など該当するカラムストア型のデータモデルに整形が必要であることを考慮し、逐次更新を行うのではなく、一括でデータを作成・更新・挿入することが望ましい。

[効果]
第１の効果は、格納するデータの重複を排除する圧縮機能により、通常の圧縮アルゴリズムを用いるより、ＣＰＵへの負荷を抑えたうえで格納に必要なデータ量が削減されることである。

その理由は、同一列内のデータを分割する処理で行うためＣＰＵの負荷は低く、また重複しやすい列で内部のデータを複数の列と同様に分割して格納することにより、重複が排除されるためである。特に、列に格納する文字列などのサイズが大きければ大きいほど、部分的な重複にとどまる可能性が高いため、このようなケースでは１つ１つのデータ量が大きいため一部分の重複を排除することで大きなデータの圧縮効果が見込める。なお、この該当列のデータについては文字列やバイト列といった数十バイト以上の列を想定している。これは、対象のデータが数バイト程度と小さい場合は、分割して重複を排除することにより削減されるデータ量より分割することで発生するデータ量が上回ってしまうためである。

なお、分割圧縮列に対する分割後のデータ格納方式はカラムストア型データベースに実装されている物理データモデルを拡張して適用すればよいため、本実施形態の技術を用いることは比較的容易である。また、データ格納領域をメモリやＳＳＤにした場合には、ディスクベースでランダムアクセスに強い特性から、分割された列データのイメージを復元するためのデータ結合については処理性能が早く、本実施形態のデータ分割による性能劣化を小さくすることが可能となり、より効果的である。

第２の効果は、クエリの条件によってはクエリ処理性能が向上することにある。その理由は、データ分割と圧縮によって、操作や検索対象が分割した後の列に閉じる場合は処理対象のデータ量が削減されるためである。特に通常では全件のデータのシーケンシャルスキャンを行わなければならない場合などでは、対象データを削減することでの効果が大きくなる。例えば、先ほど説明したメールアドレスの＠以降のあるドメインについて変更がかかった場合、通常はソートされていたとしても後方一致検索での更新条件となり、全件スキャンが必要だが、本実施形態ではメールアドレスＢのみを対象とすることで、対象データの重複が排除および列の分割により処理対象のデータが大幅に削減される。

ただし、中間一致検索などですべての列を結合してから検索をしなければならない場合には、本実施形態の効果として性能が向上することを見込むことは難しい。

[第３の実施形態]
次に、本発明の第３の実施形態の構成について図面を参照して詳細に説明する。

本実施形態の構成は、第２の実施形態の図３を参照した構成と同じである。異なる点は、以下の点である。
第２の実施形態では列分割を行って分割後の列を独立に格納していた「実データ領域」を本実施形態では１つにまとめて格納し、インデックス領域側はそのアドレスの値を張る点。

具体例として図７、図８を例にして具体的に説明する。図７に定義されている製品テーブルは、”製品id“、”商品名”、”出版社”、”定価”という列を持っている。この製品テーブルのデータをロードした場合、本実施形態では、データベースクライアント１から列分割文字テーブル２５２に” ”（半角スペース）の文字によって、内部的に２つに分割し、” ”（半角スペース）は格納時には取り除くというルールの定義をし、表定義領域２５１には製品テーブルの“商品名”列を「分割圧縮列」として定義し、上記ルールにて列分割を行うという定義を格納する。分割されたデータは、データ保存領域２３の内部での「実データ領域」の“商品名”に、分割されたデータの前後の位置に関係なく格納する。この方法を用いて、実データをロードさせた例が図８のようになる。

インデックス列については、同様に格納した「実データ領域」のアドレスを保有しており、参照先のデータを結合・復元することで検索結果の返却が可能となることは同じである。ただし、今回の場合は” ”（半角スペース）を取り除いているため、クエリ実行部２３は、復元の為結合する際に、”
”（半角スペース）を間に追加するものとする。

[効果]
本実施形態では、第２の実施形態で説明した第１の効果をさらに強化した内容となる。すなわち、データを分割した位置で区別せずに同一の「実データ領域」に重複を排除した形で格納するため、どの位置かに依存せず部分的に重複が発生するような特性を持つデータであれば、重複排除の効果がさらに高まりデータの圧縮精度が高まる効果を持っている。

ただし、第２の実施形態の第２の効果については、分割した順番の情報が失われ、前方一致検索や後方一致検索といった検索対象データの絞り込み効果が薄れるため、検索性能の向上は第２の実施形態ほどは見込めない可能性がある。

[第４の実施形態]
次に、本発明の第４の実施形態について図面を参照して詳細に説明する。

本実施形態の構成は、図９となり、第２の実施形態の図３を参照した構成とほぼ同じであるが、ユーザ定義列分割ルール関数２６が存在することである。動作について異なる点は、以下の点である。

第２の実施形態では列分割を、列分割文字テーブルに分割する文字と、分割する列数の関係を定義することで、カラム内のデータを複数の列に分割するが、本実施形態では、ユーザによって独自の列分割定義ルールを関数などで定義することによって内部の列分割を行う。

具体的には、データベースクライアント１がカラムストア型データベース管理システム２に列分割文字テーブル２５２に分割する文字とルールを定義するが、その代わりに、いわゆるデータベース管理システムのストアドプロシージャや組み込み関数などで作成した分割するルールおよび列数などの関係を、クエリ実行部２３を通じて、ユーザ定義列分割ルール関数２６に定義する。また同様に、ＳＱＬの表定義コマンド等でこのルールを利用する列の定義を表定義領域２５１に格納する。これにより実際に物理的に格納する列定義も行われる。

データベースクライアント１からデータを投入、または更新をする場合には、格納表定義領域２５１にユーザ定義列分割ルール関数を用いてデータを分割する定義がある列に対しては、そのルールを利用してデータを分割し、分割した物理的なデータを格納する。

データ操作については、表定義領域２５１の分割ルールに従い、結合結果を生成したうえで返却する。これは第２の実施形態と同様である。

[効果]
本実施形態の効果は、第２の実施形態で説明した第１の効果と同様である。ただし、第２の実施形態のように、重複排除のための分割方法が通常の分割文字を定義するような場合でなく、ユーザがデータの特性を意識して、特別なルールを設定したい場合には、データベースのストアドプロシージャと同様の形で、ユーザ定義列分割ルール関数２６によって分割手法を定義することを可能とする。これにより、ある程度複雑なルールにも柔軟に分割による重複排除のデータ量削減などを実現することが可能となる。ただし、複雑なルールになると、性能に影響が出やすいため、あまり複雑なルールでないほうが好ましい。

大量のデータベースからデータマートを作成する場合や、データウェアハウスなどの分野に適する。とくにこの集計処理を既存のシステムをリレーショナルデータベースで実現しており、集計処理の高速化のために既存のリレーショナルデータベースからカラムストアデータベースに移行させたケースなどが考えられる。この場合、アプリケーション側を変更せずに、カラムストア型のデータベースの重複排除の効果が有効に使うことが可能となる。

１００…カラムストア型データベース管理システム
１１０…通信Ｉ／Ｆ部
１２０…操作入力部
１３０…画面表示部
１４０…記憶部
１４０Ａ…表領域
１４０Ａ１…表データ
１４０Ｂ…スキーマ領域
１４０Ｂ１…表に関する管理情報
１４０Ｂ１１…分割対象列に関する管理情報
１４０Ｐ…プログラム
１５０…プロセッサ
１５０Ａ…データベース管理部
１５０Ａ１…表作成部
１５０Ａ２…表データ格納部
１５０Ａ３…検索部

Claims (7)

1. 表領域とスキーマ領域とデータベース管理部とを有するカラムストア型データベース管理システムであって、
   前記スキーマ領域は、表に関する管理情報を格納し、前記管理情報は、前記表の少なくとも１つの列に関連して、前記列が分割対象列であることを表す情報と、前記列中のデータに共通に出現する文字である基準文字の情報と、前記列を前記基準文字に一致する文字の箇所で複数の部分列に分割する分割方法に関する情報と、前記表領域における前記複数の部分列のデータを保存する領域に関する情報とを有し、
   前記データベース管理部は、前記スキーマ領域に格納された前記表に関する前記管理情報を参照して前記表領域に前記表の表データを格納し、前記表領域への前記表の表データの格納では、前記表の列単位および部分列単位で重複するデータを排除する
   カラムストア型データベース管理システム。
2. 前記管理情報中の、前記表領域における前記複数の部分列のデータを保存する領域に関する情報は、前記複数の部分列に１対１に対応する前記表領域中の物理的な列に関する情報を有し、
   前記データベース管理部は、前記分割対象列に格納するデータを前記分割方法に関する情報に従って複数の部分列のデータに分割し、各々の部分列のデータを対応する前記表領域中の物理的な列に格納し、前記物理的な列単位で重複するデータを排除する
   請求項１に記載のカラムストア型データベース管理システム。
3. 前記管理情報中の、前記表領域における前記複数の部分列のデータを保存する領域に関する情報は、前記複数の部分列に共通な前記表領域中の物理的な列に関する情報を有し、
   前記データベース管理部は、前記分割対象列に格納するデータを前記分割方法に関する情報に従って複数の部分列のデータに分割し、該分割して生成された複数の部分列のデータから重複するデータを排除して前記表領域中の物理的な列に格納し、前記物理的な列における位置情報の組み合わせによって分割前のデータの構成を特定する情報を前記表領域に別途格納する
   請求項１に記載のカラムストア型データベース管理システム。
4. 前記データベース管理部は、前記スキーマ領域に格納された前記表に関する前記管理情報を参照して前記表領域に格納された前記表の表データを検索し、前記表の表データの検索では、検索対象とする列が前記分割対象列の場合、前記複数の部分列のデータを結合して分割前のデータを再構成した上で検索を行う
   請求項１乃至３の何れかに記載のカラムストア型データベース管理システム。
5. 前記データベース管理部は、前記スキーマ領域に格納された前記表に関する前記管理情報を参照して前記表領域に格納された前記表の表データを検索し、前記表の表データの検索では、検索対象とする列が前記分割対象列であって且つ前方一致検索あるいは後方一致検索を行う場合、前記複数の部分列のうちの一部の部分列のデータに対して検索を行う
   請求項１または２に記載のカラムストア型データベース管理システム。
6. 表領域とスキーマ領域とデータベース管理部とを有するカラムストア型データベース管理システムにおけるデータ圧縮方法であって、
   前記スキーマ領域は、表に関する管理情報を格納し、前記管理情報は、前記表の少なくとも１つの列に関連して、前記列が分割対象列であることを表す情報と、前記列中のデータに共通に出現する文字である基準文字の情報と、前記列を前記基準文字に一致する文字の箇所で複数の部分列に分割する分割方法に関する情報と、前記表領域における前記複数の部分列のデータを保存する領域に関する情報とを有し、
   前記データベース管理部は、前記スキーマ領域に格納された前記表に関する前記管理情報を参照して前記表領域に前記表の表データを格納し、前記表領域への前記表の表データの格納では、前記表の列単位および部分列単位で重複するデータを排除する
   カラムストア型データベース管理システムにおけるデータ圧縮方法。
7. 表領域とスキーマ領域とを有し、前記スキーマ領域は、表に関する管理情報を格納し、前記管理情報は、前記表の少なくとも１つの列に関連して、前記列が分割対象列であることを表す情報と、前記列中のデータに共通に出現する文字である基準文字の情報と、前記列を前記基準文字に一致する文字の箇所で複数の部分列に分割する分割方法に関する情報と、前記表領域における前記複数の部分列のデータを保存する領域に関する情報とを有するカラムストア型データベース管理システムを構成するコンピュータを、
   前記スキーマ領域に格納された前記表に関する前記管理情報を参照して前記表領域に前記表の表データを格納し、前記表領域への前記表の表データの格納では、前記表の列単位および部分列単位で重複するデータを排除するデータベース管理部
   として機能させるためのプログラム。

Images