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

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

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

前へ

  • 1
  • 2

―メモリ上で行形式データと列形式データを、いわば「二重持ち」しているのですね。では、その内容をディスクに保存する際はどうしているのでしょうか?

行形式データも列形式データも、両方ともディスクに保存しています。
実はこの部分の実装方式は、検討を重ねました。二重持ちするとリソースは通常より多く用意しないといけません。
しかし、ディスクに列形式のデータを保持していないと再起動時のメモリ再構築の時間がかかります。両者を天秤にかけ、最終的に「二重持ちする」という選択をしました。

―なぜ「二重持ち」を選択したのですか?

インメモリデータベース製品の中には、ディスク上には行形式でしか保存しないものもあります。
しかし検討を進めるうち、クラッシュからの復旧時に列形式データがディスクに保存されていないと、メモリ上の列形式データの再構築にとても時間がかかることが判明しました。これだけ時間がかかってしまっては、とても実用には耐えないと判断し、列形式データも逐次ディスクに保存する仕様としました。
ただし、二重持ちと言ってもデータは圧縮しているため、ディスク使用量はそれなりに抑えられます。

―具体的にどれくらい圧縮できるのでしょうか。

データの種類によりますが、最大で2分の1くらいは圧縮可能です。
圧縮によりディスク読み込み時のI/O量も減らすことができます。
列形式の共有バッファには、一度データを載せるとデータを維持し続けるステーブルバッファ機能を搭載していますが、それでも急激にデータ量が増えた場合などバッファから溢れることがないとは言いきれません。その場合もディスクに列形式の圧縮データがあるので、安定した性能で使い続けることができます。

―データを二重持ちするリスクを最小限に抑え、メリットへと転換しているのですね。
これまで、インメモリカラムナ機能の仕組みについて伺ってきましたが、本機能はPostgreSQLにどのように実装されているのですか?

インメモリカラムナ機能は、PostgreSQLのエクステンションとして実現しています。PostgreSQLの魅力のひとつはオープン性だと考えています。ですから、多くのPostgreSQLユーザーに、富士通ならではの高性能・高信頼性なデータベース機能を提供できることを目指しています。

―ということは、オープンソースのPostgreSQLとの互換性は意識されましたか?

それはかなり意識しました。インメモリカラムナ機能を実現するために、まったく新たなエンジンを開発・実装すると同時に、既存のPostgreSQLとの互換性も絶対に維持しなくてはいけません。この2つの要件を両立させるために、かなり苦労を重ねました。

―どのような点で苦労されたのですか?

そうですね。例えば、エラーが発生した際にユーザーに表示するメッセージがあります。もともとのPostgreSQLと、新たに開発したエンジンとで異なっていては、ユーザーが混乱してしまいますからね。
特に、苦労したのは、特定のトランザクションから見えていいデータと見えてはいけないデータをきちんと管理する「トランザクションの可視性」の互換性ですね。
PostgreSQLは、テーブル内の各行に追加・削除を識別するトランザクションIDを持っていて、この情報を基に、テーブルをスキャンする際に「可視な行」だけを読みます。インメモリカラムナ機能でも、PostgreSQLと同様の一貫性を保たなければなりません。

―インメモリカラムナではWOS(行形式の追加・削除情報)とROS(列形式のデータ)にデータが分かれていて、データ参照の際にはこの2つを突合せると伺いました。WOSとROSを突合せる時に、どう一貫性を保つかということでしょうか。

はい。WOSは更新トランザクションと同期しているので、更新の際にPostgreSQLのトランザクションIDの情報も記録しておくことで、どれが可視な行なのかがわかります。データ参照の際には、クエリー開始時点のスナップショットから、可視な行のデータを一時的に列形式に変換しておきます。
一方、ROSには、不定期にWOSのデータが反映されます。一貫性を保つには、ROSに反映中のデータは、他のトランザクションから見えないようにしておく必要があります。そこでWOSからROSへの反映は、エクステントという単位で管理するようにしました。
クエリー開始時には、データ反映が完了しているエクステントを判定し、そのスナップショットと、先ほどの一時的に列に変換したデータと突合せることで、一貫性を確保しました。
こうした極めて細かな点までこだわり、互換性の維持に努めました。

―実際にデータベースを使うユーザーの立場に立つと、そうした細かなインターフェース1つ1つの違いがアプリケーション開発の効率を大きく左右しますからね。

そうですね。また、実装する際のアプローチを選ぶ上では、新たに実装する機能と既存機能との相性も考える必要がありました。
同じ機能を実現するにも「性能面で有利なアプローチ」「変更量が少ないアプローチ」などさまざまなアプローチが考えられるのですが、それぞれPostgreSQLとの相性が異なります。
そこで、個々の機能ごとになるべく多くの実装アプローチを挙げ、それらの中からPostgreSQLへ組み込むのに最も適したものを選んでいくという作業をひたすら繰り返しました。

―やはりこれだけ先進的な機能を実現するとなると、一筋縄ではいかいのですね。ちなみに、今後はどのような形でPostgreSQLとかかわっていきたいとお考えですか?

まずは、性能をより一層“尖らせて”いきたいですね。
やはり、ある処理系において世界最速レベルを達成するというのは、技術者の1つの夢ですからね。また今後のデータベース技術の方向性として、データ分析の機能が徐々にデータベース製品に取り込まれていくのではないかと予想しています。
メモリ容量をはじめとしたハードウェア性能が飛躍的に向上したことで、従来のOLTPに加えてOLAPも同じ箱で扱えるようになりました。そして今後もっとハードウェア性能が上がれば、OLAPだけに留まらずさらに広い領域の機能が同じ箱の中で実現できるようになることでしょう。

―その1つが、データ分析機能だということですね。

その通りです。データベースサーバのメモリがさらに増えれば、それまで別のサーバで行われていたデータ分析処理もデータベース上で行えるようになるはずです。
当面は、限られた分析処理だけに限られるでしょうが、将来的には機械学習やAIの処理までPostgreSQLに取り込まれるようになるかもしれません。一技術者としては、そうした技術の研究や実用化にぜひ関わってみたいと考えています。

―AIの処理がPostgreSQLに取り込まれる!それは夢のある話ですね。データベースの先行きが楽しみです。ありがとうございました。

前へ

  • 1
  • 2

技術者からのコメント

株式会社富士通研究所
コンピュータシステム研究所
河場 基行

入社以来、CPUからWebシステムまで様々なシステムの性能分析・解析技術の研究に携わってきました。
性能解析の観点から見ると、データベースは中核に居座りながら、複雑で解析が難しくチューニングがしづらい伝統的な難物システムだと思ってきました。
ところが、ここ数年PostgreSQLをベースとしたデータベース技術の研究開発を通じてわかったことは、データベースは難物などではなくデータ処理の粋が詰まったある意味美しいシステムであること、またコミュニティの力で日々進化し続けている可能性を秘めたシステムであることです。
昨今、ICTシステムの変化に合わせて、様々なデータベースが現れ消えています。その中で、30年近くも進化し続けているPostgreSQLとコミュニティに尊敬の念を感じます。
未来のICTシステムを支えるデータシステムを創り続けるために、PostgreSQLとともに研究開発を行っていきたいと思っています。


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

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

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

Webでのお問い合わせ

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

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

お電話でのお問い合わせ

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

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