GTM-MML4VXJ
Skip to main content
  1. ホーム >
  2. 製品 >
  3. ソフトウェア >
  4. ライブラリー >
  5. 特集>
  6. 一日前のデータはもう古い!?大量データもリアルタイムに意思決定(1/2)

富士通の技術者に聞く!PostgreSQL最新技術
一日前のデータはもう古い!?大量データもリアルタイムに意思決定(1/2)
PostgreSQLインサイド

一日前のデータはもう古い!?大量データもリアルタイムに意思決定

「インメモリ」「列指向(カラムナ)」などのデータベース技術が実用化され、OLAPの世界に数々のブレイクスルーをもたらしている。
富士通では、「世界一高速なPostgreSQLをいち早く世に提供すること」をコンセプトに、独自の「インメモリカラムナ」技術を開発し、トランザクション処理の一貫性を保ちながら、分析処理の高速性を透過的なインターフェースで実現した。その真相に迫る。

  • 1
  • 2

次へarrow-double

[2016年6月24日掲載]

―「インメモリカラムナ」というキーワードは、近年データベースでよく耳にします。PostgreSQLにインメモリカラムナを開発された目的についてお聞かせください。

ビッグデータ活用が本格化し、IoTデータや、オープンデータ、SNSなど、これまでの業務システムで使用していなかった新しいデータの活用が注目されていますが、従来から情報分析に使われていた基幹システムの業務データは、現在も情報分析に無くてはならない存在です。
基幹システムの業務データは、よりリアルタイムに参照・活用できるスピードが求められています。
たとえば「午前の売上データの速報値を見て午後の対策を決定する」など、意思決定のスピードが急速に変化してきています。

―それは、これまで夜間のバッチ処理や、データウェアハウスで行ってきた大量データ集計のスピードが変わってきたということですか。

はい。従来はオンライントランザクション処理(OLTP)の性能に影響を与えないよう、時間帯を変え夜間に集計したり、データウェアハウスなど別システムで集計したりしていました。そのため、参照できる最新データは前日のデータということが殆どでした。
しかし、先ほどお話したとおり、もはやそれではビジネスニーズを満たせないケースが出てきているのです。このニーズに対応するには、OLTPと大量データ検索・集計処理、つまりオンライン分析処理(OLAP)が同時にできる、というデータベース自体の進化が重要になってきます。
既に数年前から、商用データベース各社がOLTPとOLAPの共存に向けた機能を提供してきています。そして、この共存の流れは今後のPostgreSQLにも重要な要素になると考え取り組んだのが、今回のインメモリカラムナです。

―PostgreSQLにインメモリカラムナ機能を新たに加えたのは、こうした背景があったからなのですね。富士通のインメモリカラムナ機能の具体的な仕組みについて、簡単に教えていただけますか?

この機能の中核技術の1つが「カラムナ」、つまり「列形式」でデータを格納する技術です。
一般的なRDBMSは「行形式」でデータを格納しますが、これはデータの更新・削除には強いものの、大量データの検索処理の効率は決してよくありません。逆に、データ更新・削除はあまり得意ではないものの、大量データの検索処理にめっぽう強いのが列形式です。
そこで、OLAP用途を前提としたデータベースの製品の多くは、列形式でデータを格納する方式をとっています。
私たちが開発したインメモリカラムナ機能でも、従来の行形式のデータに加えて列形式のデータもPostgreSQLで扱えるようにしたのです。具体的には、行形式のテーブルに対応するインデックスとして、列形式のテーブルを持つようにしています。

―列形式のインデックスですか?

はい。行形式と列形式のデータを共存させるといっても、実際の検索・集計処理で、すべてのデータが必要というわけではありません。
列形式のインデックスは、行形式のインデックスと異なり、検索する可能性のある列を指定しておけば、列の組み合わせによらず高速に検索することができます。
ですから、検索する可能性のある列データをインデックスとして保持できるようにしました。

―「インメモリ」とついているので、列形式のインデックスはメモリ上にあるのでしょうか。

はい。PostgreSQLの行形式のデータで利用する共有バッファとは別に、列形式専用の共有バッファを用意しました。
共有バッファを独立させることで、OLTPに影響を与えることなく大量データ集計ができるようにしています。

―メモリ上の行形式と列形式のデータの内容は、同期しているのでしょうか。

厳密にいうと、同期はしていませんが、同期しているのと同じ状態を保持しています。
例えば、PostgreSQLに対して、データレコードを更新する命令が飛んで来たとしましょう。PostgreSQLはまず従来通り、メモリ上の行形式のテーブルに対して更新処理を行います。通常ならここで終わりなのですが、インメモリカラムナ機能を使った場合はこれと同時に、やはりメモリ上に保持した列形式のデータに対しても同様の更新処理を行うよう、命令を発行するのです。
この時、実際には専用の共有バッファ上に設けたWrite-Optimized-Store(以降、WOS)という追加・削除情報を記録しておく領域に、そのトランザクション情報を一時的に溜めておくのです。
そしてシステムが適切なタイミングを見計らって、その内容を同じく専用共有バッファ上にあるRead-Optimized-Store(以降、ROS)という領域に列形式のデータとして反映します。

―列形式のデータの反映は非同期なのですね。実際には非同期なのに、どのようにして同期状態を保持するのですか。

データを参照する際には、ROSの列形式のデータとWOSにある差分情報を突き合わせて処理することで、結果は行形式のデータを参照した場合と同じ内容になります。

―結果が同じであれば、リアルタイムに同期させなくてもよいということですね。なぜ直接同期せずにWOSに一時的にデータを溜めるのですか。

行形式のデータを列形式で格納するには、データの形式を変換する必要があります。
行形式のデータ更新のたびにデータを変換すると、その分オーバーヘッドが大きくなり、レスポンスに影響します。ですから、一旦行形式のままWOSに格納することで、レスポンスへの影響を抑えているのです。
また、WOSに一時的に溜めるデータも、PostgreSQLのテーブル内の行(タプル)の位置を記録するタプルID(TID)だけを記録し、データそのものは記録しないことで、トランザクションのオーバーヘッドを最小限にしています。

―処理の分離と最小限の記録で、OLTPの性能を維持されたのですね。ところで、アプリケーションからは明示的に行形式と列形式のデータの使い分けが必要なのでしょうか。

アプリケーション側は、行形式データと列形式データのどちらにアクセスするかは、一切気にする必要はありません。
従来通りにSQL文を発行すれば、後はデータベースが「どちらを使った方が効率的に処理できるか」自動的に判別し、適した方のデータに自動的にアクセスを振り分けてくれます。

次ページ:「リスクを最小限に抑えた富士通ならではのしくみやこだわり」とは?

  • 1
  • 2

次へarrow-double


本ページに記載された内容は、掲載日現在のものです。その後予告なしに変更されることがあります。あらかじめご了承ください。

富士通のPostgreSQLに関する情報がここに「PostgreSQL インサイド」

本コンテンツに関するお問い合わせ

Webでのお問い合わせ

入力フォームはこちらから

当社はセキュリティ保護の観点からSSL技術を使用しております。

お電話でのお問い合わせ

富士通コンタクトライン(総合窓口)0120-933-200

受付時間 9時~17時30分
(土曜・日曜・祝日・当社指定の休業日を除く)