(57)【要約】      （修正有）【課題】ＯＬＴＰ（Ｏｎｌｉｎｅ  Ｔｒａｎｓａｃｔｉｏｎ  Ｐｒｏｃｅｓｓ）とＯＬＡＰ（Ｏｎｌｉｎｅ  Ａｎａｌｙｔｉｃａｌ  Ｐｒｏｃｅｓｓｉｎｇ）が同時に実行されるＨＴＡＰ性能の向上が可能なデータベース管理システム、メモリ管理装置、データベース管理方法およびプログラムを提供する。【解決手段】データベース管理システム（ＤＢＭＳ）１００は、ＯＬＴＰ処理部２０と、ＯＬＡＰ処理部３０と、ＯＬＴＰのための行指向データを格納するＳＣＭ１１０と、ＳＣＭ１１０上で、ＯＬＴＰがデータを更新して行指向に保持し、行指向に保持したデータを所定量蓄積した後、所定量蓄積したデータをＤＲＡＭ１２０に列単位のブロックで格納するとともに、当該列単位のブロックをＯＬＡＰのためにＤＩＳＫ１３０に格納するメモリ管理部４０と、を備える。【選択図】図１
2020013318.tif 000002
【特許請求の範囲】
【請求項１】
データベースの更新処理を行うＯＬＴＰ（Online Transaction Process）と、前記データベースに蓄積したデータの集計処理を行うＯＬＡＰ（Online Analytical Processing）と、を備えるデータベース管理システムであって、
前記ＯＬＴＰのための行指向データを格納する不揮発性メモリと、
前記不揮発性メモリ上で、前記ＯＬＴＰがデータを更新して行指向に保持し、行指向に保持したデータを所定量蓄積した後、所定量蓄積したデータを揮発性メモリに列単位のブロックで格納するとともに、当該列単位のブロックを前記ＯＬＡＰのために前記不揮発性メモリとは異なる二次記憶装置に格納するメモリ管理手段と、を備える
ことを特徴とするデータベース管理システム。
【請求項２】
前記メモリ管理手段は、
前記不揮発性メモリ上で、行単位で管理されているデータを、前記二次記憶装置上の列単位で管理されたデータと対応させて移動させる
ことを特徴とする請求項１に記載のデータベース管理システム。
【請求項３】
前記メモリ管理手段は、
前記二次記憶装置上に列指向で格納されているデータに対して、前記揮発性メモリでは列指向で保持する一方、前記不揮発性メモリでは行指向で保持し、当該不揮発性メモリでの行指向のデータを列指向の前記二次記憶装置上のデータに反映する
ことを特徴とする請求項１に記載のデータベース管理システム。
【請求項４】
前記メモリ管理手段は、
前記列単位のブロック内に含まれる更新されたデータ数が所定以上のブロックを前記二次記憶装置に書き込む
ことを特徴とする請求項１に記載のデータベース管理システム。
【請求項５】
前記二次記憶装置は、列指向データをブロック単位で保持し、
前記メモリ管理手段は、
前記不揮発性メモリ上での行指向データの更新を前記二次記憶装置上の列指向のブロックへ反映させる場合、列指向の前記ブロックの中で更新が所定時間以上されないデータを所定量以上含むブロックを反映の対象として選択する
ことを特徴とする請求項１に記載のデータベース管理システム。
【請求項６】
前記メモリ管理手段は、
列指向のブロック単位で、更新された行指向のデータ数と更新の新旧の情報を用いて、データの反映を管理する
ことを特徴とする請求項１に記載のデータベース管理システム。
【請求項７】
前記メモリ管理手段は、
所定の閾値に基づいて、行指向のデータが前記不揮発性メモリの中に入りきらなくなったことを判定する
ことを特徴とする請求項１に記載のデータベース管理システム。
【請求項８】
ＬＰＵ（Least Recently Used）カウントを備え、
前記メモリ管理手段は、
前記不揮発性メモリ上の更新済みデータから、更新された行データとその行データが属する前記列単位のブロックに対する更新時の前記ＬＲＵカウントと前記列単位のブロック内の更新された行数の情報をもとに、前記二次記憶装置上の前記列単位のブロックを更新する
ことを特徴とする請求項１に記載のデータベース管理システム。
【請求項９】
前記メモリ管理手段は、
更新されたブロック内の行数が多いほど優先度が高くなるように計算した値とブロック単位で前記ＬＲＵカウントを適用した値の合計が高い前記ブロックを前記不揮発性メモリから書き出す
ことを特徴とする請求項８に記載のデータベース管理システム。
【請求項１０】
前記メモリ管理手段は、
下記式で示される計算時間Ｐ６をもとに、更新されたブロック内の行数が多いほど優先度が高くなるように計算した値とブロック単位でＬＲＵを適用した値の合計が高いブロックを書き出す
【数７】
2020013318.tif 000011
ただし、
HTfs_RID：ＲＩＤハッシュテーブルのフルスキャンに掛かる時間
HTfs_LBID：ＬＢＩＤハッシュテーブルをフルスキャンする時間
HSLBID：キー値ＬＢＩＤからＬＢＩＤハッシュテーブルに一意にアクセスする時間
x：ＬＢＩＤハッシュテーブル内で各ブロックが持つＬＲＵの合計値
max(LRUrow)：ＳＣＭ内の各行データが持つＬＲＵの値の最大値
y：ＬＢＩＤハッシュテーブルが持つ更新された行数
max（size）：そのブロックに格納できる最大行数
BLOCKdatatype：そのブロックに格納されるデータのデータ型のサイズ
N：ブロック内更新行数の比率に対する重みの固定値
BLOCKsize：計算機によって定められた固定値
ことを特徴とする請求項１に記載のデータベース管理システム。
【請求項１１】
前記不揮発性メモリ上に、ＲＩＤ（Row Identifier）を管理するＲＩＤテーブルと、ＬＢＩＤ（Logical Block Identifier）を管理するＬＢＩＤテーブルとを備え、
前記メモリ管理手段は、
前記ＲＩＤテーブルをもとに、前記ＯＬＴＰによって更新された行単位のデータを指定し、
前記ＲＩＤテーブルのＲＩＤをキーをもとに、該当行の前記ＬＲＵカウントおよびその行に対応する前記二次記憶装置上のブロックＬＢＩＤを指定する
ことを特徴とする請求項９に記載のデータベース管理システム。
【請求項１２】
前記ＲＩＤテーブルおよび前記ＬＢＩＤテーブルは、ハッシュテーブルである
ことを特徴とする請求項１１に記載のデータベース管理システム。
【請求項１３】
前記不揮発性メモリは、
ＳＣＭ（Storage Class Memory）、電源バックアップＤＲＡＭ（Dynamic Random Access Memory）、ＭＲＡＭ（Magnetoresistive Random Access Memory）、ＳＴＴ（Spin Transfer Technologies）−ＭＲＡＭ、ＰＣＭ（Phase-change Memory）、およびＲｅＲＡＭ（Resistive Random Access memory）から選択される少なくとも一つである
ことを特徴とする請求項１に記載のデータベース管理システム。
【請求項１４】
前記データベースは、前記二次記憶装置に配置される
ことを特徴とする請求項１に記載のデータベース管理システム。
【請求項１５】
ＯＬＴＰ（Online Transaction Process）のための行指向データを格納する不揮発性メモリと、
前記不揮発性メモリ上で、前記ＯＬＴＰがデータを更新して行指向に保持し、行指向に保持したデータを所定量蓄積した後、所定量蓄積したデータを列単位のブロックで前記不揮発性メモリとは異なる二次記憶装置に格納するメモリ管理手段と、を備える
ことを特徴とするメモリ管理装置。
【請求項１６】
データベースの更新処理を行うＯＬＴＰ（Online Transaction Process）と、前記データベースに蓄積したデータの集計処理を行うＯＬＡＰ（Online Analytical Processing）と、を有するデータベース管理システムのデータベース管理方法であって、
前記データベース管理システムは、
前記ＯＬＴＰのための行指向データを格納する不揮発性メモリ上で、前記ＯＬＴＰがデータを更新して行指向に保持し、行指向に保持したデータを所定量蓄積するステップと、
所定量蓄積したデータを揮発性メモリに列単位のブロックで格納するステップと、
当該列単位のブロックを前記ＯＬＡＰのために前記不揮発性メモリとは異なる二次記憶装置に格納するステップと、を実行する
ことを特徴とするデータベース管理方法。
【請求項１７】
データベースの更新処理を行うＯＬＴＰ（Online Transaction Process）と、前記データベースに蓄積したデータの集計処理を行うＯＬＡＰ（Online Analytical Processing）と、を有するデータベース管理システムとしてのコンピュータを、
前記ＯＬＴＰのための行指向データを格納する不揮発性メモリ上で、前記ＯＬＴＰがデータを更新して行指向に保持し、行指向に保持したデータを所定量蓄積する手段、
所定量蓄積したデータを揮発性メモリに列単位のブロックで格納する手段、
当該列単位のブロックを前記ＯＬＡＰのために前記不揮発性メモリとは異なる二次記憶装置に格納する手段、として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データベース管理システム、メモリ管理装置、データベース管理方法およびプログラムに関する。
【背景技術】
【０００２】
ＯＬＴＰ（Online Transaction Process）は、ＡＴＭ（Automatic Teller Machine）、ＰＯＳ（Point Of Sale）などで処理が発生したケースにおいてデータベースの更新を行う場合に使われる。ＯＬＴＰは、行形式のデータを扱うことに適した方式をとる。
一方、ＯＬＡＰ（Online Analytical Processing）は、データベースに蓄積された大量のデータに対し複雑な集計、分析を行い、素早く結果を提示する。ＯＬＡＰは、データベースの解析を行う場合に使われる処理であり、列形式のデータを扱うことに適した方式をとる。
システム全体としては、データ入力／更新とデータ解析の処理速度を高くすることが求められる。そのために、データ更新処理のＯＬＴＰとデータ集計処理のＯＬＡＰを同時に効率よく実行するＨＴＡＰ（Hybrid Transactional/Analytical Processing）が注目されている。
【０００３】
従来のデータベース管理システム（ＤＢＭＳ：Database Management System）では、ＯＬＴＰを効率よく実行できる行指向型ストレージモデルが採用されてきた。しかし、ＯＬＡＰを効率よく実行するためには列指向型ストレージモデルの方が適しており、ＨＴＡＰを実現するためには２種類のストレージモデルを採用して効率よく運用する必要がある。
【０００４】
ＤＢＭＳでは、ＤＢＭＳに格納された大量データを集計するＯＬＡＰを高速化するために、表形式のデータを各列単位で格納する列指向型ストレージモデルが採用されている。列指向型ストレージモデルは、行指向型ストレージモデルと比べてＯＬＡＰで集計する列が限られるためＩ／Ｏ（Input/Output）効率がよい。
一方、一行単位で実行するデータ更新処理のＯＬＴＰに対しては、各列単位でディスク（二次記憶装置）へのＩ／Ｏが発生するためＯＬＴＰは非効率である。
【０００５】
非特許文献１には、列指向型ストレージモデルを採用するディスクベースＤＢＭＳの代表例が記載されている。
【先行技術文献】
【特許文献】
【０００６】
【非特許文献１】A. Lamb, M. Fuller, R. Varadarajan, N. Tran, B. Vandiver, L. Doshi, and C. Bear. The vertica analytic database: C-store 7 years later. Proceedings of the VLDB Endowment, 5(12):1790--1801, 2012.
【非特許文献２】Amazon Elastic Compute Cloud (Amazon EC2) のr3.4xlarge （Red Hat Enterprise Linux Server release 7.1 (Maipo), Intel(R) Xeon(R) CPU E5-2670 v2 at 2.50 GHz processor, HDD [EBSマグネティック]
【非特許文献３】Amazon Elastic Compute Cloud (Amazon EC2) のr3.4xlarge （Red Hat Enterprise Linux Server release 7.1 (Maipo), Intel(R) Xeon(R) CPU E5-2670 v2 at 2.50 GHz processor, EBS (gp2) 500 GB SSD）
【発明の概要】
【発明が解決しようとする課題】
【０００７】
列指向型ストレージを採用するＤＢＭＳでは、ＯＬＴＰ効率のために揮発性メモリ（ＤＲＡＭ）上で一時的に行指向に格納し、ＯＬＡＰ最適化のために列指向データをディスクに格納する。ＤＲＡＭ内に数十万行単位で修正された行形式のデータを蓄積させた後にディスク（例えばＨＤＤ，ＳＳＤ）上へまとめて更新を反映している。
ＤＲＡＭ内のデータは、サーバ障害等で揮発する。このため、ディスク上のデータへ更新を反映させるまでは、トランザクション毎に行データ（トランザクション情報）をログとしてディスクへ書き込む必要がある。
そのため、ディスクへのアクセス回数（トランザクション単位のディスクへの書き込み処理回数）が膨大となり、Ｉ／Ｏが増加するという課題がある。
【０００８】
非特許文献１に記載の技術は、ＤＲＡＭ（揮発性メモリ）上でデータを修正した行を蓄積させ、数十万行単位でディスクへまとめて書き込むため、その間にディスクへの書き込み回数が非常に多い。実際に、TPC-CベンチマークのようなＤＢＭＳに大量のデータ更新を行う評価を行った場合、性能が悪く、ディスクへの書き込み回数が考慮されていない。
【０００９】
本発明は、このような事情に鑑みてなされたものであり、ＯＬＴＰとＯＬＡＰが同時に実行されるＨＴＡＰ性能の向上が可能なデータベース管理システム、メモリ管理装置、データベース管理方法およびプログラムを提供することを課題とする。
【課題を解決するための手段】
【００１０】
前記した課題を解決するため、本発明に係るデータベース管理システムは、データベースの更新処理を行うＯＬＴＰと、前記データベースに蓄積したデータの集計処理を行うＯＬＡＰと、を備えるデータベース管理システムであって、前記ＯＬＴＰのための行指向データを格納する不揮発性メモリと、前記不揮発性メモリ上で、前記ＯＬＴＰがデータを更新して行指向に保持し、行指向に保持したデータを所定量蓄積した後、所定量蓄積したデータを揮発性メモリに列単位のブロックで格納するとともに、当該列単位のブロックを前記ＯＬＡＰのために前記不揮発性メモリとは異なる二次記憶装置に格納するメモリ管理手段と、を備えることを特徴とする。
その他の手段については、発明を実施するための形態のなかで説明する。
【発明の効果】
【００１１】
本発明によれば、ＯＬＴＰとＯＬＡＰが同時に実行されるＨＴＡＰ性能の向上が可能なデータベース管理システム、データベース管理装置、データベース管理方法およびプログラムを提供することができる。
【図面の簡単な説明】
【００１２】
【図１】本発明の実施形態に係るデータベース管理システムの構成を示すブロック図である。
【図２】上記実施形態に係るデータベース管理システムの動作の概要を示す図である。
【図３】上記実施形態に係るデータベース管理システムのＳＣＭ上Tierの行データの更新を説明する図である。
【図４】図３のＳＣＭ上のＲＩＤハッシュテーブルを示す図である。
【図５】上記実施形態に係るデータベース管理システムの書き出しブロック特定のための更新情報の管理構造を示す図である。
【図６】上記実施形態に係るデータベース管理システムのＤＩＳＫへの列データブロックwriteを説明する図である。
【図７】上記実施形態に係るデータベース管理システムのデータ更新処理のフローチャートである。
【図８】上記実施形態に係るデータベース管理システムのTPC-Cベンチマーク３００秒間の５回の平均を各トランザクションタイプ毎に表（表１）にして示す図である。
【図９】上記実施形態に係るデータベース管理システムのMariaDB Columnstore （InfiniDB)のTPC-Cベンチマーク３００秒間の５回の平均を各トランザクションタイプ毎に表（表２）にして示す図である。
【図１０】上記実施形態に係るデータベース管理システムのスケールファクター（ＳＦ）「４」として、各手法（Ｐ１〜Ｐ７）毎にTPC-Cベンチマークを１２０秒間実行し、その間のＤＢＭＳ１００のスワップアウト回数（Ｓ）、スワップアウトされたブロック数（S_block）、キャッシュミスした行数（C_Row）、スワップアウト毎の平均行数（S_aveRow）を示す図である。
【図１１】図１０のデータを表（表３）にして示す図である。
【図１２】上記実施形態に係るデータベース管理システムのスケールファクター（ＳＦ）「８」として、各手法（Ｐ１〜Ｐ７）毎にTPC-Cベンチマークを１２０秒間実行し、その間のＤＢＭＳ１００のスワップアウト回数（Ｓ）、スワップアウトされたブロック数（S_block）、キャッシュミスした行数（C_Row）、スワップアウト毎の平均行数（S_aveRow）を示す図である。
【図１３】図１２のデータを表（表４）にして示す図である。
【図１４】上記実施形態に係るデータベース管理システムのスケールファクター（ＳＦ）「１４」として、各手法（Ｐ１〜Ｐ７）毎にTPC-Cベンチマークを１２０秒間実行し、その間のＤＢＭＳ１００のスワップアウト回数（Ｓ）、スワップアウトされたブロック数（S_block）、キャッシュミスした行数（C_Row）、スワップアウト毎の平均行数（S_aveRow）を示す図である。
【図１５】図１４のデータを表（表５）にして示す図である。
【発明を実施するための形態】
【００１３】
以下、図面を参照して本発明を実施するための形態（以下、「本実施形態」という）におけるデータベース管理システム等について説明する。
（原理説明）
ＤＢＭＳは、ハードウェアの特性を活用した効率化が行われている。また、近年、ディスクよりも高速にアクセス可能な不揮発性メモリＳＣＭ（Storage Class Memory）が実用化されている。
ＳＣＭ上にストアされたデータは、揮発しないため、ＳＣＭ上で更新したデータを保持しておくことができる。例えば、ＳＣＭ上で更新したデータを保持しておくことで、ディスクへのログ書き込み処理が無い更新処理を実現できるようになる。
ただし、高速にアクセス可能なＳＣＭは、容量が小さい。このため、大規模化が進むデータセットを扱うＤＢＭＳにおいては、ＳＣＭ上に書き込まれたデータをディスク（二次記憶）上のブロックへ反映する必要がある。
【００１４】
従来のＤＢＭＳのメモリ管理は、行指向の場合にはメモリ中も二次記憶中も行単位で管理されたデータを移動させ、列指向の場合にはメモリ中も二次記憶中も列単位で管理されたデータを移動させるものであった。
【００１５】
本発明は、メモリ中は行単位で管理されているデータを、二次記憶中の列単位で管理されたデータと対応させて移動させる。すなわち、本発明は、二次記憶中に列指向で格納されているデータに対して、ＯＬＡＰ用のメモリではそのまま列指向で保持する一方、ＯＬＴＰ用の不揮発性メモリでは行指向で保持し、不揮発性メモリでの行指向のデータを列指向の二次記憶中のデータに反映することを特徴とする。
【００１６】
二次記憶中の列指向データのデータは、ブロック単位で保持されることから、不揮発メモリ上での行指向データの更新を二次記憶中の列指向のブロックへ反映させる際に、ＩＯ回数を減らすために、列指向のブロックの中で更新が新しくないデータをできるだけ多く含むブロックを反映の対象として選ぶ工夫をする。本発明は、列指向のブロック単位で、更新された行指向のデータ数と更新の新旧の情報を用いて管理することを特徴とする。
【００１７】
更新の新旧を管理する手段の一つとして、ＬＲＵ（Least Recently Used）カウントを利用することも可能である。ブロック選択の際のデータ数とＬＲＵカウントを組み合わせる基準についても記載する。
【００１８】
本発明は、ＤＢＭＳの行単位更新を列指向型ストレージのブロックへ更新する際のブロックを、ブロック内のデータ数と従来ブロック更新のために利用されてきたＬＲＵの双方を組み合わせた基準によって決定する手法を提案する。
本発明におけるブロック内の更新されたデータ数という観点は、列指向型ストレージにおける１ブロック内に含まれるデータの行数が多くなることに基づいて、行単位の更新されたデータ数が多いブロックを書き込む方が一度のディスクへの書き込み処理で多くのデータ更新を反映させることができる。
また、ＳＣＭによってデータが揮発しないことを利用して行単位の更新処理のログデータをディスクへ書き込み、更新処理を確定するディスクへの書き込み回数を減らし、ＳＣＭ上でデータ更新を確定することができるためデータを蓄積させることが可能となる。
【００１９】
（実施形態）
図１は、本発明の実施形態に係るデータベース管理システムの構成を示すブロック図である。
図１に示すように、データベース管理システム（ＤＢＭＳ）１００は、問い合わせ受付部１０と、ＯＬＴＰ処理部２０と、ＯＬＡＰ処理部３０と、不揮発性メモリ１１０と、ＤＲＡＭ１２０（揮発性メモリ）と、メモリ管理部４０（メモリ管理手段）と、二次記憶装置１３０と、を備える。
【００２０】
ＤＢＭＳ１００は、データベース（図示省略）を管理する機能を有する。ＤＢＭＳ１００は、データベース管理ソフトウェアをＰＣ等のサーバ装置にインストールし、このサーバ装置のＣＰＵがプロセスを起動することで実現されてもよい。
【００２１】
上記データベースは、ＤＢＭＳ１００により記録されたデータを保持するデータセットであり、ＨＤＤ（Hard Disk Drive）その他の記録媒体に設置される。このデータベースは、ＤＢＭＳ１００を介してデータを記録し、ＤＢＭＳ１００を介してデータを出力する。
なお、このデータベースは、ＤＩＳＫ１３０（後記）に配置されるものでもよい。
【００２２】
<問い合わせ受付部１０>
問い合わせ受付部１０は、利用者からデータベースの更新処理（ＯＬＴＰ）や、データベースに蓄積したデータの集計処理（ＯＬＡＰ）の実行要求（問い合わせ）を受付ける。
【００２３】
<ＯＬＴＰ処理部２０>
ＯＬＴＰ処理部２０は、行指向型データ格納方式（行指向型ストレージモデル）であり、ＤＢＭＳ１００が管理するデータベースにデータを格納・更新するＯＬＴＰ処理を実行する。
【００２４】
<ＯＬＡＰ処理部３０>
ＯＬＡＰ処理部３０は、列指向型データ格納方式（列指向型ストレージモデル）であり、ＤＢＭＳ１００が管理するデータベースに蓄積したデータを集計するＯＬＡＰ処理を実行する。
【００２５】
<メモリ管理部４０>
メモリ管理部４０は、不揮発性メモリ１１０上で、ＯＬＴＰ処理部２０がデータを更新して行指向に保持し、行指向に保持したデータを所定量蓄積した後、蓄積したデータをＯＬＡＰ用のＤＲＡＭ１２０に列単位のブロック（後記）で格納するとともに、当該列単位のブロックをＯＬＡＰ処理部３０のためにＤＲＡＭ１２０とは異なるＤＩＳＫ１３０に格納する。
【００２６】
メモリ管理部４０は、不揮発性メモリ１１０上で、行単位で管理されているデータを、ＤＩＳＫ１３０上の列単位で管理されたデータと対応させて移動させる。
【００２７】
メモリ管理部４０は、ＤＩＳＫ１３０上に列指向で格納されているデータに対して、ＤＲＡＭ１２０では列指向で保持する一方、不揮発性メモリ１１０では行指向で保持し、不揮発性メモリ１１０での行指向のデータを列指向のＤＲＡＭ１２０上のデータに反映する。
【００２８】
メモリ管理部４０は、列単位のブロック内に含まれる更新されたデータ数が所定以上のブロックをＤＩＳＫ１３０に書き込む。
【００２９】
メモリ管理部４０は、不揮発性メモリ１１０上での行指向データの更新をＤＩＳＫ１３０上の列指向のブロックへ反映させる場合、列指向のブロックの中で更新が所定時間以上されないデータを所定量以上含むブロックを反映の対象として選択する。
【００３０】
メモリ管理部４０は、列指向のブロック単位で、更新された行指向のデータ数と更新の新旧の情報を用いて、データの反映を管理する。
【００３１】
メモリ管理部４０は、所定の閾値に基づいて、行指向のデータが不揮発性メモリ１１０の中に入りきらなくなったことを判定する。
【００３２】
メモリ管理部４０は、不揮発性メモリ１１０上の更新済みデータから、更新された行データとその行データが属する列単位のブロックに対する更新時のＬＲＵ（Least Recently Used）カウント（後記）と列単位のブロック内の更新された行数の情報をもとに、ＤＩＳＫ１３０上の列単位のブロックを更新する。
【００３３】
メモリ管理部４０は、不揮発性メモリ１１０上に、ＯＬＴＰによって更新された行単位のデータを特定するための行ＩＤ（ＲＩＤ、Row Identifier）ハッシュテーブル１１１と、ＲＩＤをキーとしてその行のＬＲＵカウントおよびその行に対応するＤＩＳＫ１３０上の論理ブロックＩＤ（ＬＢＩＤ、Logical block Identifier）を特定するＬＢＩＤハッシュテーブル１１２と、を作成する。メモリ管理部４０は、ＯＬＴＰによって更新された行の行ＩＤ（ＲＩＤ）をキーとしてその行のＬＲＵカウントを特定するＲＩＤハッシュテーブル１１１およびＬＢＩＤハッシュテーブル１１２とを作成することで、ＳＣＭ１１０上で更新された行のＬＲＵを更新する。
【００３４】
メモリ管理部４０は、更新された列データの論理ブロックＩＤ（ＬＢＩＤ）によってその行のＬＲＵカウントを、ブロック内の合計ＬＲＵカウントに加算することで、列データのブロック単位でＬＲＵを適用する。また、メモリ管理部４０は、ＲＩＤハッシュテーブル１１１を利用する際の衝突を判定する処理によってブロック内の更新された行数を加算する。
これらのハッシュテーブルによって、不揮発性メモリ１１０上で更新されたデータの行はＲＩＤから特定できる。メモリ管理部４０は、ＬＢＩＤからブロック単位のＬＲＵカウントとブロック内で更新した行数を用いて、ＤＩＳＫ１３０上に書き戻すブロックを決定する。
【００３５】
<ＬＲＵカウント>
本実施形態では、ＬＲＵカウントを、説明の便宜上ＬＲＵと呼んでいる。ＬＲＵカウントは、厳密にはＬＲＵとは別のものである。ＬＲＵは、リストの形で管理され、最新にアクセスされたものがトップに、一番古くアクセスされたものがテールに来るように管理される。つまり、リストの途中のデータにアクセスがあると、リストの中身がずれる。一方、本実施形態のＬＲＵカウントは、単純なカウンタの数でリストを模倣するものであり、新たにアクセスされた場合にカウントアップされた数を割り当てていく。このため、カウントが次第に大きくなる。そのため、どこかでカウントのリセットが必要になる。本実施形態では、簡単に管理できるＬＲＵカウントを用いている。
【００３６】
本実施形態では、ＬＲＵカウントを用いているが、ＬＲＵカウントはあくまでも実現手法の一つに過ぎない。メモリ管理部４０が、ブロック単位で、更新されたデータ数と更新の新旧の情報を用いて管理するものであればよい。
【００３７】
<ＬＲＵカウント>
不揮発性メモリ１１０上に、ＲＩＤを管理するＲＩＤテーブルと、ＬＢＩＤを管理するＬＢＩＤテーブルとを備える。本実施形態では、テーブルの実現手法の一つとしてハッシュを用い、ＲＩＤハッシュテーブル１１１およびＬＢＩＤハッシュテーブル１１２とする。テーブルは、ハッシュで実現することが一般的であるが、ハッシュではない他のテーブルを用いてもよい。
【００３８】
<不揮発性メモリ１１０>
不揮発性メモリ１１０は、不揮発性を有する記録媒体であり、例えばＳＣＭ（Storage Class Memory）、電源バックアップＤＲＡＭ（Dynamic Random Access Memory）、ＭＲＡＭ（Magnetoresistive Random Access Memory）、ＳＴＴ（Spin Transfer Technologies）−ＭＲＡＭ、ＰＣＭ（Phase-Change Memory）、およびＲｅＲＡＭ（Resistive Random Access Memory）から選択される少なくとも一つである。
本実施形態では、アクセスが高速に可能なＳＣＭ、電源バックアップＤＲＡＭ、ＭＲＡＭ、ＳＴＴ−ＭＲＡＭを利用する際の効果が大きい。以下、ＳＣＭ１１０として説明する。
【００３９】
ＳＣＭ１１０は、装置が障害等により電源オフ状態となっても、更新データを継続して保存する。詳細な動作については後述する。
ＳＣＭ１１０は、高速な不揮発性メモリであり、高速であることがＯＬＴＰ処理条件の一つである。例えば、フラッシュメモリ（Flash Memory）は、不揮発性メモリであっても書き込みが遅いのでＯＬＴＰ処理には向かない。また、フラッシュメモリは、書き込み回数に制限がありそれを超えると劣化する。本実施形態で用いるＳＣＭ１１０は、ＤＲＡＭの書き込み速度より数倍程度遅いものからＤＲＡＭ以上の高速性のものを用いる。
【００４０】
ＳＣＭ１１０は、行単位の更新データ（トランザクション）を格納する。
ＳＣＭ１１０は、ＯＬＴＰによって更新された行単位のデータを特定するための行ＩＤ（ＲＩＤ）ハッシュテーブル１１１と、ＲＩＤをキーとしてその行のＬＲＵカウントおよびその行に対応するＤＩＳＫ１３０上のブロックＩＤ（ＬＢＩＤ）を特定するＬＢＩＤハッシュテーブル１１２と、を有する。
【００４１】
<ＤＲＡＭ１２０>
ＤＲＡＭ１２０は、揮発性メモリである。ＤＲＡＭ１２０は、ＳＣＭ１１０からの更新情報を列情報の形で格納する。ＤＲＡＭ１２０は、列情報の形で格納した更新情報がある程度まとまった状態になった時点でＤＩＳＫ１３０へ格納する。
【００４２】
<二次記憶装置１３０>
二次記憶装置１３０は、ＨＤＤ，ＳＳＤ（Solid State Drive）等の記憶手段である。以下、ＤＩＳＫ１３０として説明する。
ＤＩＳＫ１３０は、ＯＬＡＰに適した列指向型ストレージである。
【００４３】
以下、上述のように構成されたＤＢＭＳ１００の動作について説明する。
<概要>
ＤＢＭＳ１００のデータ更新のブロックへの反映について述べる。
図２は、ＤＢＭＳ１００の動作の概要を示す図である。
図２中のハッチングに示す□印は、更新されたデータであることを表す（以下同様の表記）。
図２の符号ａに示すように、ＤＢＭＳ１００は、ＳＣＭ１１０上で、ＯＬＴＰ処理部２０によりデータを更新する。図２の符号ｂに示すように、ＳＣＭ１１０上では、行単位の更新データを行指向に保持する。そして、図２の符号ｃに示すように、行指向に保持したデータを所定量蓄積させる。
行指向に保持したデータを所定量蓄積させた後、ＳＣＭ１１０上に蓄積したデータをＤＲＡＭ１２０に列単位のブロックで格納する（図２の符号ｄ参照）。例えば、数十万行単位のデータを列単位（列指向）に変換する。
そして、図２の符号ｅに示すように、列単位のブロックをＤＩＳＫ１３０に格納する。ＤＩＳＫ１３０上では、ＯＬＡＰに適した列指向型ストレージを採用している。ＤＩＳＫ１３０への書き込みは、ブロック単位で行われる。ＤＢＭＳ１００は、同じブロック内に含まれる更新されたデータ数が多いブロックをＤＩＳＫ１３０へ書き込む。
【００４４】
行指向に保持したデータを所定量蓄積させるのは下記の理由からである。
例えば、図２の符号ｃの破線枠囲みに示す例では、１つの列の中に更新されたデータが４行入っている。ＤＩＳＫ１３０へ書き込むブロックは、列形式であるので、行単位で更新はくるものの、６回の更新の中でこの列は、４回である。すなわち、ブロックの中に４行分のデータ更新を反映できる。このブロックをＤＩＳＫ１３０へ反映してしまえば、更新されなかった２行分をＳＣＭ１１０から消す（書き出す）ことができる。一方、図２の符号ｃの左側の列では、ブロックのなかで１行しか更新されていないにもかかわらず、ＤＩＳＫ１３０へ書き込んでしまうので効率が悪い。
このように、ＳＣＭ１１０のデータ不揮発性を利用して行形式のデータを溜めておくことで、１つの列の中の更新が多いブロックを選択することができる。更新が多く行われているブロックをＤＩＳＫ１３０へ書き込むようにする。
【００４５】
また、ＤＢＭＳ１００は、ＳＣＭ１１０上では、ＤＩＳＫ１３０上の行単位のデータ、論理ブロックＩＤ（ＬＢＩＤ）を取得して行データを構成する。これにより、ＳＣＭ１１０上で更新したデータから同じブロックに属するデータを特定できるようにしている。
【００４６】
上記のように、ＤＢＭＳ１００は、行指向に保持したデータを所定量蓄積させた後、ＤＲＡＭ１２０に列単位のブロックで格納する。この時点で、例えばトランザクションによる更新内容は、ＳＣＭ１１０上とＤＲＡＭ１２０に二重化して保持しており、装置の電源断ではデータは失われない。そのため、ＤＢＭＳ１００は、トランザクションをコミットすることができる。
【００４７】
<ＯＬＴＰ／ＯＬＡＰそれぞれのためのキャッシュ領域>
ＯＬＴＰ／ＯＬＡＰそれぞれのためのキャッシュ領域について説明する。
本実施形態は、下記特徴（１）−（３）を有する。
（１）ＤＢＭＳ１００は、ＣＰＵが直接ロード／ストア可能なＳＣＭ１１０上で、行指向のデータをキャッシュしておく。そして、行指向のデータを用いてＯＬＴＰを実行（ＯＬＴＰ処理部２０がＯＬＴＰ処理を実行）した後に、行単位の更新をＬＲＵカウント（後述）等をもとに、ページ単位でＤＩＳＫ１３０に書き込む。これにより、ＤＩＳＫ１３０のＩ／Ｏの削減を図る。
（２）ＤＢＭＳ１００は、ＯＬＴＰ実行毎のログ処理をＳＣＭ１１０上で行う。これにより、ＤＲＡＭ上でログをまとめて書き出す場合に比べてＤＩＳＫ１３０のＩ／Ｏの削減を図る。
（３）ＤＢＭＳ１００は、ＯＬＡＰを効率良く実行するために、ＳＣＭ１１０上に蓄積したデータをＤＩＳＫ１３０上では列指向に格納することで、ＤＲＡＭ１２０上には必要な列データのみをロードできるようする。ＤＩＳＫ１３０上では、一般的な列指向型ＤＢＭＳがメモリ上に蓄積するデータの単位である数十万行単位等のデータがセグメント毎に格納される。
【００４８】
上記（１）−（３）で述べた、ＳＣＭ１１０上のデータ配置により、一般的な列指向型ＤＢＭＳに比べ、ＯＬＴＰを効率良く実行しつつ、更新したデータを即座に反映することで、一度キャッシュしたデータ有効活用したＯＬＡＰを実行可能とすることができる。
なお、ＤＲＡＭ１２０上に、列指向で圧縮したデータを格納することも可能である。
【００４９】
<ＳＣＭ１１０上Tierの行データの更新>
ＤＢＭＳ１００のＳＣＭ１１０上Tier（物理階層）の行データの更新について説明する。
【００５０】
図３は、ＤＢＭＳ１００のＳＣＭ１１０上Tierの行データの更新を説明する図である。図４は、図３のＳＣＭ１１０上のＲＩＤハッシュテーブル１１１を示す図である。
図３および図４に示すように、ＳＣＭ１１０上にＲＩＤハッシュテーブル１１１を設ける。
本実施形態では、ＳＣＭ１１０とＤＩＳＫ１３０を仮想的なTierとみなし、ＤＲＡＭ１２０は双方のTierのキャッシュ領域として扱う。実際には、ＤＩＳＫ１３０上Tierのデータに対する更新をＳＣＭ１１０上Tierの削除フラグとして利用し、ライトバックキャッシュのようにＤＩＳＫ１３０に反映を行う。
【００５１】
また、図３の符号ｆに示すように、ＳＣＭ１１０上にINSERTされるデータに対する更新は、そのままＳＣＭ１１０上の行指向データに更新する。そして、図３の符号ｇに示すように、ＳＣＭ１１０上Tierの１行のデータには各カラム毎にＤＩＳＫ１３０上の論理ブロックＩＤ（ＬＢＩＤ）を持たせる。ＬＢＩＤを行データに持たせることで、ＤＩＳＫ１３０上ブロックへのWrite（書き込み）の前に行ＩＤ（ＲＩＤ）からブロックＩＤを取得する処理を減らし、同じブロック内に属するＳＣＭ１１０上行データの更新をまとめる処理に利用することができる。
【００５２】
図３に示すように、ＳＣＭ１１０上Tierのデータに対する更新は、そのままＳＣＭ１１０上で行指向データを用いて実行する。ただし、図３の符号ｈに示すように、コミット時にＳＣＭ１１０上のＲＩＤをもとに、ＳＣＭ１１０上のＲＩＤハッシュテーブル１１１（図３および図４参照）からＤＲＡＭ１２０上のカラムページの行を特定して行単位に新たなバージョンのデータをトランザクションＩＤタイムスタンプ（TxnID）と共にインプレイスに更新する。この時、前バージョンのデータをVersioned flagに前バージョンデータへのポインタを登録する（図４の符号ｉ，ｊ参照）。その後、ＳＣＭ１１０上のＬＢＩＤハッシュテーブル１１２（後記図５および図６参照）に更新した行のカラム番号とＬＢＩＤをＤＩＳＫ１３０上のブロックへのライトバック用に登録する（図４の符号ｋ参照）。ＤＲＡＭ１２０上でキャッシュした際のページバッファは、図示しない所定アルゴリズムに従って更新する（図４の符号ｌ参照）。
【００５３】
図３の符号ｍに示すように、ＤＩＳＫ１３０上Tierのデータが更新される場合には、ＤＩＳＫ１３０から列指向のブロック単位で読み出し、ＳＣＭ１１０上に行指向のデータをＬＢＩＤと共に再構成して行のバージョン管理を行う。読み出された列指向のブロックは、ハッシュテーブル１１２のＬＲＵによって、更新頻度の低いブロックがＤＩＳＫ１３０上に新たなバージョンのブロックとして書き出される。これにより、ＤＩＳＫ１３０上の列指向データの更新を行う。
図３に示すように、ＤＲＡＭ１２０上では、ＯＬＡＰに対して列単位でＤＩＳＫ１３０からデータをキャッシュする。読み出された列指向データに対して更新があった場合には、ＳＣＭ１１０上で更新された行のＲＩＤ（図４の符号ｎ参照）をもとに、ＯＬＴＰの更新を反映する（図４の符号ｏ参照）。そのために、ＳＣＭ１１０上では、行単位で更新したコミット時にＬＢＩＤハッシュテーブル１１２（図５および図６参照）を更新する。
【００５４】
<書き出しブロック特定の具体例>
図３に示すＳＣＭ１１０上Tierの行データの更新について、図５を参照してより詳細に説明する。
図５は、書き出しブロック特定のための更新情報の管理構造を示す図である。図３と同一動作には、同一符号を付している。
図５に示すように、ＳＣＭ１１０上の更新済みデータから、ＲＩＤハッシュテーブル１１１を用いて、図５の符号ｐに示すように更新された行データとその行データが属するブロックに対する更新時のＬＲＵカウント（ここでは「２」「３」「１」）を読み出す。このＬＲＵカウント「２」「３」「１」から、ＬＢＩＤハッシュテーブル１１２を用いて、合計ＬＲＵ（ここでは「１」「５」）と更新行数（ここでは「１」「２」）を読み出す。そして、更新された行データとその行データが属するブロックに対する更新時のＬＲＵカウントとブロック内の更新された行数の情報を用いて、ＤＩＳＫ１３０上のブロックを更新するか否かを決定する。これにより、ＤＢＭＳ１００の行単位のデータ更新処理におけるＤＢＭＳ１００への書き込み回数を削減する。
【００５５】
より詳細に説明する。
ＤＩＳＫ１３０は、行単位のデータを特定するために行ＩＤ（ＲＩＤ）を有する。本実施形態では、ＳＣＭ１１０上で更新されたデータの行ＩＤ（ＲＩＤ）（図５の符号ｈ参照）と、その行に対応するＤＩＳＫ１３０上のブロックＩＤ（ＬＢＩＤ）を利用して行単位にＬＲＵを適用する（図５の符号ｐ参照）。
ＯＬＴＰによって更新された行の行ＩＤ（ＲＩＤ）をキーとしてその行のＬＲＵカウントを特定するＲＩＤハッシュテーブル１１１を作成する。これにより、ＳＣＭ１１０上で更新された行のＬＲＵを更新する。
また、更新された列データの論理ブロックＩＤ（ＬＢＩＤ）によってその行のＬＲＵカウントを、ブロック内の合計ＬＲＵカウントに加算する。すなわち、列データのブロック単位でＬＲＵカウントを適用し、ＬＢＩＤハッシュテーブル１１２を利用する際の衝突を判定する処理によってブロック内の更新された行数を加算する。
【００５６】
ＲＩＤハッシュテーブル１１１およびＬＢＩＤハッシュテーブル１１２によって、ＳＣＭ１１０上で更新されたデータの行は、ＲＩＤから特定できる。ＬＢＩＤからブロック単位のＬＲＵとブロック内で更新した行数を用いて、ＤＩＳＫ１３０上に書き戻すブロックを決定する。
書き戻すブロックは、行単位のＬＲＵ、ブロック単位のＬＲＵそれぞれの値が低い方を優先するようにする。この優先度の設定は、これに限定されない。例えば、ブロック内で更新された行数が少ない場合にはあえて書き戻す優先度を下げた方が、後にそのブロックを書き戻す際に多くのＯＬＴＰの更新処理を含むことが可能となる。このように書き戻すブロックの決定パタンは、様々なパタンがある。書き戻すブロックを決定する具体例については、図１０〜図１５で後記する。
【００５７】
<ＤＩＳＫ１３０へのページ更新反映>
ＤＩＳＫ１３０へのページ更新反映について、図６を参照して説明する。
図６は、図２のＤＢＭＳ１００のＤＩＳＫ１３０への列データブロックwriteを説明する図である。図３〜図５と同一動作には、同一符号を付している。
図６に示すように、ＤＩＳＫ１３０へのページ更新を反映するために、ＳＣＭ１１０上で更新された中で使われていない論理ブロックＩＤ（ＬＢＩＤ）を登録したＬＢＩＤとＬＲＵカウントのアレイをＳＣＭ１１０上に作成する（図６の符号ｑ参照）。
ＤＩＳＫ１３０に格納するページにはなるべくまとめて更新後の行データを含める。このために、ＬＢＩＤアレイにはＳＣＭ１１０上で、行単位でＯＬＴＰが実行された際のＲＩＤハッシュテーブル１１１の更新時にＬＲＵカウントを加算する（図６の符号ｑ参照）。
【００５８】
ＬＢＩＤからＤＩＳＫ１３０上のブロックを読み出し、ＲＩＤからＲＩＤハッシュテーブル１１１によって目的の行のカラムデータを取得する（図６の符号ｒ参照）。これにより、更新があったデータのみを反映したブロックをＤＩＳＫ１３０へ書き出すことができる（図６の符号ｓ参照）。
ページを書き込む際のアップデート時には（図６の符号ｔ参照）、ＳＣＭ１１０にロードされていない行データが存在する可能性があるため、本実施形態ではＬＢＩＤブロックをread後にブロック内ＲＩＤからデータを取得し、修正した後にＤＩＳＫ１３０へWriteしている。
ＤＩＳＫ１３０内ブロック更新時の処理速度は、カラム単位のブロックに含まれる行データの数が、通常の行指向ブロックに比べて多い。このため、少数行の更新に関わらず多数のページに反映してしまうことで、ＳＣＭ１１０のスペース効率と処理速度が低下することに留意する必要がある。
【００５９】
［データ更新処理のフローチャート］
図７は、データ更新処理のフローチャートであり、ＯＬＴＰデータ更新処理を例に採る。本フローは、ＤＢＭＳ１００のＣＰＵ（図示省略）により実行される。
まず、ステップＳ１でＳＣＭ１１０に更新対象の行データがキャッシュされているか否かを判別する。
ＳＣＭ１１０に更新対象の行データがキャッシュされていない場合（ステップＳ１：Ｎｏ）、ステップＳ２でＤＩＳＫ１３０上の列指向データから更新対象の行をＳＣＭ１１０に読み出してステップＳ３に進む。ＳＣＭ１１０に更新対象の行データがキャッシュされている場合（ステップＳ１：Ｙｅｓ）、そのままステップＳ３に進む。
【００６０】
ステップＳ３でＳＣＭ１１０上でデータを更新して行指向に保持する。
ステップＳ４でＲＩＤハッシュテーブル１１１のＬＲＵカウントを更新する。
ステップＳ５でＤＲＡＭ１２０上にＯＬＡＰ用データがキャッシュされているか否かを判別する。
ＤＲＡＭ１２０上にＯＬＡＰ用データがキャッシュされていない場合（ステップＳ５：Ｎｏ）、ステップＳ６でＤＲＡＭ１２０上のデータをＲＩＤハッシュテーブル１１２のポインタから更新してステップＳ７に進む。ＤＲＡＭ１２０上にＯＬＡＰ用データがキャッシュされている場合（ステップＳ５：Ｙｅｓ）、そのままステップＳ７に進む。
なお、上記ステップＳ４〜ステップＳ６は、ＯＬＡＰ用データの更新であり、従来技術と同様の処理である。
【００６１】
ステップＳ７でＬＢＩＤハッシュテーブル１１２のＬＲＵカウントと行数を更新する。
ステップＳ８でＳＣＭ１１０上のスペースは十分か否かを判別する。ＳＣＭ１１０上のスペースの判別は、下記の通りである。すなわち、各テーブルのスキーマから１行分のデータサイズが分かる。この１行分のデータサイズを用いて、ＳＣＭ１１０上で予めＳＣＭ１１０に、例えば「１万桁まで保持する」基準を決めて、「その行数以下」か否かを判別するようにする。ＳＣＭ１１０上のスペースが十分か否かの判断は、メモリ管理部４０が、例えば所定の閾値に基づいて、行指向のデータが前記不揮発性メモリの中に入りきらなくなったことを判定する。
【００６２】
ＳＣＭ１１０上のスペースが十分である場合（ステップＳ８：Ｙｅｓ）、本フローの処理を終了する。
ＳＣＭ１１０上のスペースが十分でない場合（ステップＳ８：Ｎｏ）、ステップＳ９でＳＣＭ１１０上のデータを一時的にＤＩＳＫ１３０に退避（退避はページと呼ばれる分割された単位で行う）させるスワップアウト処理（後記手法６等参照）を行ってステップＳ８に戻る。
【００６３】
［ＤＢＭＳのデータ更新性能の評価］
ＤＢＭＳ１００のデータ更新性能の評価について説明する。
ＤＢＭＳのデータ更新性能の評価として一般的に使用されているTPC-Cベンチマークを用いて本実施形態に係るＤＢＭＳ１００を評価した。
TPC-Cベンチマークは、米国トランザクション処理性能協議会 （Transaction Processing Performance Council: TPC） によって策定されたテストコレクションである。本評価の実験環境では、非特許文献２を用いた。TPC-Cのデータ量は、スケールファクター（ＳＦ）によって決められ、ここではＳＦ＝４で評価を行った。
【００６４】
TPC-Cを３００秒間実行した本実施形態に係るＤＢＭＳ１００の結果を図８の表１に、列指向型ＤＢＭＳのオープンソース版であるMariaDB Columnstore （InfinIDB）の結果を図９の表２に示す。
図８は、ＤＢＭＳ１００のTPC-Cベンチマーク３００秒間の５回の平均を各トランザクションタイプ毎に表（表１）にして示す図である。
図９は、MariaDB Columnstore （InfiniDB)のTPC-Cベンチマーク３００秒間の５回の平均を各トランザクションタイプ毎に表（表２）にして示す図である。
３００秒で各トランザクションが何回実行されたか、各トランザクションの１秒当たりの回数を示している。
【００６５】
図８および図９の対比から分かるように、本実施形態に係るＤＢＭＳ１００は、各トランザクションタイプのすべてにおいて、１．５〜２倍程度の性能が向上している結果を得た。
なお、TPC-Cベンチマークは、ＯＬＴＰ用のベンチマークである。また、ORDER_STATUSとSTOCK_LEVELトランザクションは集計のみのトランザクションである。このため、更新の伴うＯＬＴＰの中でもＯＬＡＰのような集計系の問合せ処理の性能向上が見込むことができる。このことから本実施形態に係るＤＢＭＳ１００は、ＨＴＡＰ性能向上に貢献できる。
【００６６】
［実施例］
本発明は、様々な手法の適用が考えられる。その中でも最も効果が高い方法を調査した。
具体的には、７つの手法（Ｐ１〜Ｐ７）を評価し、最も効果が高い手法６（Ｐ６）を適用して実験を行った。
【００６７】
Ｐ１：ブロック単位でＬＲＵを適用し、そのブロックを書き出す。
Ｐ２：行単位でＬＲＵを適用し、その行を含むブロックを書き出す。
Ｐ３：行単位でＬＲＵを適用し、ＬＲＵカウントが高い上位１０％の値とブロック内の更新比率（更新された行数÷（ブロックサイズ÷そのブロックのデータ型のサイズ））を足して高い値のブロックから書き出す。
Ｐ４：ブロック単位でＬＲＵを適用し、（ブロックサイズ÷そのブロックのデータ型のサイズ）÷（全ブロックの中で最大のＬＲＵカウント）の値が高いブロックを書き出す。
Ｐ５：更新されたブロック内の行数が多いほど優先度が高くなるように計算した値とブロック単位でＬＲＵを適用した値の合計が高いブロックを書き出す。
Ｐ６：更新されたブロック内の行数が多いほど優先度が高くなるように計算した値とブロック単位でＬＲＵを適用した値の合計が高いブロックを書き出す。
Ｐ７：更新されたブロック内の行数が多いほど優先度が高くなるように計算した値が高いブロックを書き出す。
【００６８】
それぞれの手法（Ｐ１〜Ｐ７）の実行時間は、式（１）〜（８）で表すことができる。
実行時間は、Ｓ（スワップアウト回数）に、式（２）〜（８）に示す計算時間を掛けたものである。それぞれの手法（Ｐ１〜Ｐ７）の中でスワップアウト回数とスワップアウトブロック数の結果のバランスが最も良い手法６を適用し、図８に示す表１で評価した。
【００６９】
式（１）に示すＰｉは、手法（Ｐ１〜Ｐ７）によって計算される書き出し対象のブロックを決定する方法である。式（１）に示すＰｉは、式（２）〜（８）に示すＰ１〜Ｐ７で表すことができる。
【００７０】
【数１】
2020013318.tif 000003
【００７１】
ただし、
Stotal：ＤＢＭＳのデータ更新時のディスクへの反映時間
Pi：ＳＣＭの情報から書き出し対象のブロックを決定する計算時間（Ｐ１〜Ｐ７）
S：Piの計算によってブロック群が書き出される回数（スワップアウト）
S_block：スワップアウト時の書き出されるブロック数
Drr：ディスクから１ブロックを読み出すランダムリード時間
S_aveRow：スワップアウトによってＳＣＭから削除されるスワップアウト毎の平均行数
HTfs_RID：ＲＩＤハッシュテーブルのフルスキャンに掛かる時間
Urow：書き出し対象ブロック内のデータをメモリ上で修正する時間
Drw：ディスクから１ブロックを書き出すランダムライト時間
HTfs_LBID：ＬＢＩＤハッシュテーブルをフルスキャンする時間
HSLBID：キー値ＬＢＩＤからＬＢＩＤハッシュテーブルに一意にアクセスする時間
x：ＬＢＩＤハッシュテーブル内で各ブロックが持つＬＲＵの合計値
max(LRUrow)：ＳＣＭ内の各行データが持つＬＲＵの値の最大値
y：ＬＢＩＤハッシュテーブルが持つ更新された行数
max（size）：そのブロックに格納できる最大行数
BLOCKdatatype：そのブロックに格納されるデータのデータ型のサイズ
N：ブロック内更新行数の比率に対する重みの固定値(n=2000)
BLOCKsize：計算機によって定められた固定値（4096）
【００７２】
手法１（Ｐ１）のＳＣＭの情報から書き出し対象のブロックを決定する計算時間（以下、「計算時間」という）Ｐ１は、式（２）で示される。
【００７３】
【数２】
2020013318.tif 000004
【００７４】
手法２（Ｐ２）の計算時間Ｐ２は、式（３）で示される。
【００７５】
【数３】
2020013318.tif 000005
【００７６】
手法３（Ｐ３）の計算時間Ｐ３は、式（４）で示される。
【００７７】
【数４】
2020013318.tif 000006
【００７８】
手法４（Ｐ４）の計算時間Ｐ４は、式（５）で示される。
【００７９】
【数５】
2020013318.tif 000007
【００８０】
手法５（Ｐ５）の計算時間Ｐ５は、式（６）で示される。
【００８１】
【数６】
2020013318.tif 000008
【００８２】
手法６（Ｐ６）の計算時間Ｐ６は、式（７）で示される。
【００８３】
【数７】
2020013318.tif 000009
【００８４】
手法７（Ｐ７）の計算時間Ｐ７は、式（８）で示される。
【００８５】
【数８】
2020013318.tif 000010
【００８６】
［実験結果］
本評価の実験環境では、非特許文献３を用いた。TPC-Cのデータ量は、スケールファクター（ＳＦ）によって決められ、ここではＳＦ＝４、８、１４で評価を行った。
図１０は、スケールファクター（ＳＦ）「４」として、各手法（Ｐ１〜Ｐ７）毎にTPC-Cベンチマークを１２０秒間実行し、その間のＤＢＭＳ１００のスワップアウト回数（Ｓ）、スワップアウトされたブロック数（S_block）、キャッシュミスした行数（C_Row）、スワップアウト毎の平均行数（S_aveRow）を示す図、図１１は図１０のデータを表（表３）にして示す図である。
【００８７】
図１２は、スケールファクター（ＳＦ）「８」として、図１０と同様の評価を行った図、図１３は図１２のデータを表（表４）にして示す図である。
【００８８】
図１４は、スケールファクター（ＳＦ）「１４」として、図１０と同様の評価を行った図、図１５は図１４のデータを表（表５）にして示す図である。
【００８９】
例えば、図１０〜図１５のうち、図１４および図１５の手法６（スワップアウト回数とスワップアウトブロック数の結果のバランスが最も良い手法）を例に採る。図１５の手法６に示すように、ブロック群が書き出される回数（スワップアウト）Ｓが「１２７」回あった場合に、ＳＣＭ１１０から平均して行を削除することができたスワップアウト毎の平均行数S_aveRowが「４６１４」であった。
【００９０】
以上説明したように、ＤＢＭＳ１００は、ＯＬＴＰ処理部２０と、ＯＬＡＰ処理部３０と、ＯＬＴＰのための行指向データを格納するＳＣＭ１１０と、ＳＣＭ１１０上で、ＯＬＴＰがデータを更新して行指向に保持し、行指向に保持したデータを所定量蓄積した後、所定量蓄積したデータをＯＬＡＰ用のＤＲＡＭ１２０に列単位のブロックで格納するとともに、当該列単位のブロックをＯＬＡＰのためにＤＩＳＫ１３０に格納するメモリ管理部４０と、を備える。
【００９１】
従来のＤＢＭＳのメモリ管理は、行指向の場合にはメモリ中も二次記憶中も行単位で管理されたデータを移動させ、列指向の場合にはメモリ中も二次記憶中も列単位で管理されたデータを移動させるものであった。換言すれば、従来のＤＢＭＳでは、二次記憶中に行指向で格納されている場合にはメモリ中も行指向で、二次記憶中に列指向で格納されている場合にはメモリ中も列指向で保持されてきた。
【００９２】
これに対して、本実施形態に係るＤＢＭＳ１００は、メモリ中は行単位で管理されているデータを、ＤＩＳＫ１３０上の列単位で管理されたデータと対応させて移動させる。すなわち、本ＤＢＭＳ１００は、ＤＩＳＫ１３０上に列指向で格納されているデータに対して、ＯＬＡＰ用のＤＲＡＭ１２０ではそのまま列指向で保持する一方、ＯＬＴＰ用のＳＣＭ１１０では行指向で保持し、ＳＣＭ１１０での行指向のデータを列指向のＤＩＳＫ１３０上のデータに反映する。
【００９３】
メモリ管理部４０は、ＳＣＭ１１０上での行指向データの更新をＤＩＳＫ１３０上の列指向のブロックへ反映させる場合、列指向のブロックの中で更新が所定時間以上されないデータを所定量以上含むブロックを反映の対象として選択する。これにより、列指向のブロックの中で更新が新しくないデータをできるだけ多く含むブロックを反映の対象として選択することができる。ＤＩＳＫ１３０上の列指向データのデータは、ブロック単位で保持されることから、ＳＣＭ１１０上での行指向データの更新をＤＩＳＫ１３０中の列指向のブロックへ反映させる際に、Ｉ／Ｏ回数を減らすことができる。
【００９４】
このように、ＳＣＭ１１０上でデータが揮発しないことを利用して、行単位の更新処理のログデータをＤＩＳＫ１３０へ書き込み、更新処理を確定するＤＩＳＫ１３０への書き込み回数を減らし、ＳＣＭ１１０上でデータ更新を確定することができる。これにより、ＯＬＴＰを効率良く実行しつつ、更新したデータを即座に反映することで、一度キャッシュしたデータ有効活用したＯＬＡＰを実行可能とすることができる。
ＯＬＴＰとＯＬＡＰが同時に実行されるＨＴＡＰ性能の向上を図ることができる。特に、更新の伴うＯＬＴＰの中でもＯＬＡＰのような集計系の問合せ処理の性能向上が見込むことができる。
【００９５】
本発明は上記の実施形態例に限定されるものではなく、特許請求の範囲に記載した本発明の要旨を逸脱しない限りにおいて、他の変形例、応用例を含む。
例えば、メモリ管理手段は、ＦＰＧＡ（Field-Programmable Gate Array）やＡＳＩＣ（Application Specific Integrated Circuit）を用いて実現可能である。ＦＰＧＡを用いる場合、一例としてＦＰＧＡベンダのツールを用いて、実現したい論理回路をハードウェア記述言語を用いて記述し、提供されたツールでビットストリームに合成する。そして、ＦＰＧＡにこのビットストリームを送信するとＦＰＧＡに回路が実現する。
【００９６】
また、上記した実施形態例は本発明をわかりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施形態例の構成の一部を他の実施形態例の構成に置き換えることが可能であり、また、ある実施形態例の構成に他の実施形態例の構成を加えることも可能である。また、実施形態例は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形例は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【００９７】
また、上記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上述文書中や図面中に示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。
【００９８】
また、上記の各構成、機能、処理部、処理手段等は、それらの一部または全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行するためのソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、または、ＩＣ（Integrated Circuit）カード、ＳＤ（Secure Digital）カード、光ディスク等の記録媒体に保持することができる。
【００９９】
また、上記実施の形態では、装置は、データベース管理システムおよびメモリ管理装置という名称を用いたが、これは説明の便宜上であり、名称はデータベース管理装置等であってもよい。また、方法およびプログラムは、データベース管理方法という名称を用いたが、ＯＬＴＰ管理方法、ＯＬＡＰ最適化方法、データベース管理プログラム等であってもよい。
【符号の説明】
【０１００】
１０  問い合わせ受付部
２０  ＯＬＴＰ処理部
３０  ＯＬＡＰ処理部
４０  メモリ管理部（メモリ管理手段）
１００  データベース管理システム（ＤＢＭＳ）
１１０  （不揮発性メモリ）
１１１  ＲＩＤハッシュテーブル
１１２  ＬＢＩＤハッシュテーブル
１２０  ＤＲＡＭ（揮発性メモリ）
１３０  ＤＩＳＫ（二次記憶装置）
【図１】
2020013318.tif 000012
【図２】
2020013318.tif 000013
【図３】
2020013318.tif 000014
【図４】
2020013318.tif 000015
【図５】
2020013318.tif 000016
【図６】
2020013318.tif 000017
【図７】
2020013318.tif 000018
【図８】
2020013318.tif 000019
【図９】
2020013318.tif 000020
【図１０】
2020013318.tif 000021
【図１１】
2020013318.tif 000022
【図１２】
2020013318.tif 000023
【図１３】
2020013318.tif 000024
【図１４】
2020013318.tif 000025
【図１５】
2020013318.tif 000026