Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Copyright 2017 FUJITSU LIMITED
進化を続けるPostgreSQL
~ Linuxの成功からみるPostgreSQLの将来とカラムナ
ストレージ技術~
2017年9月5日
富士通株式会社
データマネジメントミドルウェ...
自己紹介
富士通株式会社
データマネジメント・ミドルウェア事業部第一開発部
出利葉 健(いでりは たけし)
 経歴
2016 年度に富士通へ入社。
PostgreSQL コミュニティでの活動に従事。Cプログラム用の埋め込み
SQLプリプロセッ...
アジェンダ
エンタープライズ利用拡大に向けた取り組み
インメモリカラムナの技術
Pluggable storageの技術
Copyright 2017 FUJITSU LIMITED2
エンタープライズ利用拡大に向けた
取り組み
Copyright 2017 FUJITSU LIMITED3
PostgreSQLの進化
PostgreSQL 9.0
・レプリケーション
・列/条件付きトリガ
・64bit版Windows対応
2010 2011 2012 2013 2014 2015 2016 [年]
PostgreSQL 9.5
・...
PostgreSQLをもっと広げたい
ビジネス領域でもっと使いやすくすることが必要
*PostgreSQLのEOLは、メジャーバージョンのリリースから最大5年です
構築 運用
PostgreSQLの周辺ツール(OSS)
との組合せの整合性
暗号...
PostgreSQLをもっと広げたい:コミュニティ活動
 自社製品で培った技術をPostgreSQLコミュニティ、周辺コミュニティに
還元して、コミュニティの発展に貢献
 PGCon 2017にて富士通の2名がコントリビューターに認定
綱...
コミュニティに提案した機能の例
 8.x時代から新機能提供(tablespace等), バグ修正多数
 “COPY view FROM”(V10新機能)
 “INSTEAD OF INSERT”トリガーを設定したビューにデータをインポート...
性能向上への取り組み:
インメモリカラムナ
Copyright 2017 FUJITSU LIMITED8
事例「すぐにレポートが見たい」
従来はETLツールを使った集計処理で翌日に売上状況把握
売り上げ状況に応じて次のアクションを行いたい
Copyright 2017 FUJITSU LIMITED
作成
レポート
[売上状況]
集計データ
夜...
もしリアルタイム集計ができると
既存の業務と共にリアルタイム集計ができると…
午前中の各店舗の売上に応じて午後の配送計画
→ 無駄な配送がなくなりコスト削減
→ 戦略的に売り上げを伸ばせる
短時間で分析が終わるので、分析手法の試行錯誤が可...
富士通のOLXPへの取組み
 富士通はPostgreSQLにインメモリカラムナを実装し、
OSS DBとしては世界で初めてOLXPに取り組んだ
 ユーザはデータ構造を選択しなくてよい(自動選択される)
Copyright 2017 FUJI...
OLXP実現のための性能課題
 OLTPとOLAPの違い、そしてデータ構造の違いに起因する課題
システムごとの書込パターンの比較
• OLTP:少量で断続的な挿入と更新。
• OLAP:大量一括挿入。更新なし。
データ構造ごとの書込性能比...
OLTPの性能劣化を抑止する技術
 性能劣化抑止技術の代表は”Write-Optimized Store (WOS)”
 Verticaの前身であるC-StoreをMITで研究していたグループが2005年に発表
 論文名:“C-Store...
インメモリカラムナ機構PostgreSQL
メモリ
ディスク
PostgreSQLとインメモリカラムナの内部構成
Copyright 2017 FUJITSU LIMITED
カラム型専用共用バッファ
WOS
(index)
・・・
・・・
・...
インメモリカラムナへの遅延書込み
Copyright 2017 FUJITSU LIMITED
インメモリカラムナ機構PostgreSQL
メモリ
INSERT処理の内部フロー
テーブル
列1行ID
・・・0
・・・1
・・・n
・・・
列m
...
インメモリカラムナへのクエリ処理
Copyright 2017 FUJITSU LIMITED
インメモリカラムナ機構PostgreSQL
メモリ
SELECT処理の内部フロー(インメモリカラムナの場合)
列1行ID
・・・0
・・・1
・・・...
まとめ:OLTP性能に影響を与えないためには
 性能測定
 インメモリカラムナあり/なし状態での多重度ごとの更新スループット
Copyright 2017 FUJITSU LIMITED
既存のOLTP系業務にほぼ影響なしでリアルタイム分析...
インメモリカラムナをコミュニティにフィードバック
 カラムナ型は多くの商用DBで利用可能。OSSではMariaDBが対応
PostgreSQLの更なる利用拡大のためコミュニティにフィードバック
 PGCon2016で発表。パッチも投稿済み
...
コミュニティでの取り組み:
Pluggable storage
Copyright 2017 FUJITSU LIMITED19
インメモリカラムナからPluggable storageへ
Copyright 2017 FUJITSU LIMITED
 インメモリカラムナの実装
独自インデックス作成用のAPIを活用。エクステンションとして実装
 コミュニティでの議論...
Pluggable storageのコミュニティでの動向
 富士通中心でコミュニティ内で開発中
PGCon 2017でのHaribabuさんの発表をきっかけにV11(来年
秋)への開発が加速
 PostgreSQLコミュニティ全体として盛...
Pluggable Storageとは(開発中)
 複数のストレージ構造を利用可能にするAPI
 業務に応じてテーブル毎に最適なストレージを選択可能
Copyright 2017 FUJITSU LIMITED
ヒープストレージ
(既存)
...
既存のPostgreSQLのアクセスメソッド(AM)
 物理的なデータの操作はアクセスメソッド(AM)を通して実行
 AMはデータがロー型(ヒープタプル)であることが前提=ヒープAM
Copyright 2017 FUJITSU LIMIT...
Pluggable Storage API
 Pluggable storageがストレージ構造の違いを吸収
Copyright 2017 FUJITSU LIMITED
プランナ
/ エグゼキュータ
問い合わせ
ヒープAM
(既存)
・・
...
APIの例
Copyright 2017 FUJITSU LIMITED
プランナ
/ エグゼキュータ
問い合わせ
Pluggable
Storage
XXX AM
XXX ストレージ
 プランナ・エグゼキュータ内部でのデータを操作
 sl...
開発者募集!
 まだ作り込みは必要
 ストレージ構造の変化に対応したプランナ
 各ストレージ構造とAM
Copyright 2017 FUJITSU LIMITED
ぜひ、一緒に開発しませんか?
プランナ
/ エグゼキュータ
ヒープAM
...
まとめ
 PostgreSQLのエクステンションとしてインメモリカラムナを実装
 コミュニティ内でPluggable storageを開発中
 日進月歩でPostgreSQLは進化している
上記以外にも
FDWやJSONBなどによるNo...
[db tech showcase Tokyo 2017] E14: 進化を続けるPostgreSQL ~Linuxの成功からみるPostgreSQLの将来とカラムナストレージ技術~ by 富士通株式会社 出利葉健 & 特定非営利活動法人LPI...
Upcoming SlideShare
Loading in …5
×

[db tech showcase Tokyo 2017] E14: 進化を続けるPostgreSQL ~Linuxの成功からみるPostgreSQLの将来とカラムナストレージ技術~ by 富士通株式会社 出利葉健 & 特定非営利活動法人LPI-Japan 成井弦

340 views

Published on

PostgreSQLは、エンタープライズ領域での適用を考慮した安定性や信頼性の強化と、NoSQLやクラウドなど新しい技術との連携性強化といった2つの方向へ成長しています。
そのような動きの中、富士通はカラム型インデックス(VCI)を開発し、この技術をコミュニティに提案、オープンソース化を進めています。
VCIや、PostgreSQL11に向けてコミュニティで開発を進めているPluggable Storage技術を活用して何ができるのか、適用例を交えて、それぞれの技術をご紹介します。
また、「富士通ミドルウェアマスター」と「OSS-DB技術者認定資格」を活用した技術者育成の取組みもご紹介します。

Published in: Technology
  • Be the first to comment

  • Be the first to like this

[db tech showcase Tokyo 2017] E14: 進化を続けるPostgreSQL ~Linuxの成功からみるPostgreSQLの将来とカラムナストレージ技術~ by 富士通株式会社 出利葉健 & 特定非営利活動法人LPI-Japan 成井弦

  1. 1. Copyright 2017 FUJITSU LIMITED 進化を続けるPostgreSQL ~ Linuxの成功からみるPostgreSQLの将来とカラムナ ストレージ技術~ 2017年9月5日 富士通株式会社 データマネジメントミドルウェア事業部 出利葉 健 0 db tech showcase 2017 Tokyo
  2. 2. 自己紹介 富士通株式会社 データマネジメント・ミドルウェア事業部第一開発部 出利葉 健(いでりは たけし)  経歴 2016 年度に富士通へ入社。 PostgreSQL コミュニティでの活動に従事。Cプログラム用の埋め込み SQLプリプロセッサの拡張に取り組む。 また、PostgreSQL をベースにした富士通のデータベース製品 「FUJITSU Software Enterprise Postgres」の開発にも携わる。 Copyright 2017 FUJITSU LIMITED1
  3. 3. アジェンダ エンタープライズ利用拡大に向けた取り組み インメモリカラムナの技術 Pluggable storageの技術 Copyright 2017 FUJITSU LIMITED2
  4. 4. エンタープライズ利用拡大に向けた 取り組み Copyright 2017 FUJITSU LIMITED3
  5. 5. PostgreSQLの進化 PostgreSQL 9.0 ・レプリケーション ・列/条件付きトリガ ・64bit版Windows対応 2010 2011 2012 2013 2014 2015 2016 [年] PostgreSQL 9.5 ・差分バックアップ転送 ・BRIN INDEX ・WAL圧縮 ・FDWの強化 ・UPSERT PostgreSQL 9.1 ・同期レプリケーション ・パーティショニング強化 ・拡張モジュールのサポート PostgreSQL 9.3 ・切替え時間短縮 ・マテリアライズドビュー、 更新可能ビューの追加 ・外部テーブル機能の拡張 PostgreSQL 9.2 ・カスケードレプリケーション ・Index検索の強化 ・運用、メンテナンス機能の強化 PostgreSQL 9.4 ・レプリケーションの運用性向上 ・ビューの改善 ・大容量メモリ対応 ・NoSQL対応強化 大規模システムへの適用を意識した機能と性能を中心に改善、 エンタープライズ利用も可能なデータベースへと進化している PostgreSQL 9.6 ・複数同期スレーブ ・Parallel Seq Scan ・postgres_fdw改善 Copyright 2017 FUJITSU LIMITED PostgreSQL 10β ・ロジカルレプリケーション ・パーティショニング ・Parallel クエリ拡張 4
  6. 6. PostgreSQLをもっと広げたい ビジネス領域でもっと使いやすくすることが必要 *PostgreSQLのEOLは、メジャーバージョンのリリースから最大5年です 構築 運用 PostgreSQLの周辺ツール(OSS) との組合せの整合性 暗号化・監査などの セキュリティ対策 業務継続対応 (冗長化構成の構築・運用) チューニング 障害の切り分けや 各コミュニティへの問合せを 自ら実施 EOL* 以降の保守 我々の培った経験・ノウハウでパワーアップ ~性能・信頼性・セキュリティを強化~ Fujitsu Software Enterprise Postgres Copyright 2017 FUJITSU LIMITED5
  7. 7. PostgreSQLをもっと広げたい:コミュニティ活動  自社製品で培った技術をPostgreSQLコミュニティ、周辺コミュニティに 還元して、コミュニティの発展に貢献  PGCon 2017にて富士通の2名がコントリビューターに認定 綱川さん、Haribabuさん  PGConなどのカンファレンスに参加・発表 Copyright 2017 FUJITSU LIMITED6
  8. 8. コミュニティに提案した機能の例  8.x時代から新機能提供(tablespace等), バグ修正多数  “COPY view FROM”(V10新機能)  “INSTEAD OF INSERT”トリガーを設定したビューにデータをインポート可能  インポートデータのテーブル形式への変更が不要  pg_hba_file_rule view (V10新機能)  クライアント認証設定ファイルpg_hba.confを表示するビュー  設定ファイルを変更する前に、ビューを変更することで設定が妥当か判断可能  インメモリカラムナ・Pluggable Storage(V11に向けて開発中)  既存のロー(行)型ストレージ以外のカラム型やインメモリ形式への対応  業務体系に応じてストレージ構造を選ぶことが可能 Copyright 2017 FUJITSU LIMITED7
  9. 9. 性能向上への取り組み: インメモリカラムナ Copyright 2017 FUJITSU LIMITED8
  10. 10. 事例「すぐにレポートが見たい」 従来はETLツールを使った集計処理で翌日に売上状況把握 売り上げ状況に応じて次のアクションを行いたい Copyright 2017 FUJITSU LIMITED 作成 レポート [売上状況] 集計データ 夜間バッチ ETLツール 要望に応えられない・・ 今は出せない・・ 今レポート見たい DB利用者経営陣 日中にできないのかな・・ 9
  11. 11. もしリアルタイム集計ができると 既存の業務と共にリアルタイム集計ができると… 午前中の各店舗の売上に応じて午後の配送計画 → 無駄な配送がなくなりコスト削減 → 戦略的に売り上げを伸ばせる 短時間で分析が終わるので、分析手法の試行錯誤が可能 クラウド上ならば夜間のランニングコストを削減 Copyright 2017 FUJITSU LIMITED OLTPとOLAPを共存させる OnLine miXed workload Processing (OLXP)により実現 レポート [売上状況] 集計データ OLAP OLTP 10
  12. 12. 富士通のOLXPへの取組み  富士通はPostgreSQLにインメモリカラムナを実装し、 OSS DBとしては世界で初めてOLXPに取り組んだ  ユーザはデータ構造を選択しなくてよい(自動選択される) Copyright 2017 FUJITSU LIMITED11
  13. 13. OLXP実現のための性能課題  OLTPとOLAPの違い、そしてデータ構造の違いに起因する課題 システムごとの書込パターンの比較 • OLTP:少量で断続的な挿入と更新。 • OLAP:大量一括挿入。更新なし。 データ構造ごとの書込性能比較 • ロー形式データ構造 (OLTP) :書込みが速い • カラム形式データ構造 (OLAP):ロー型に比べ書込みが遅い カラム形式データ構造でOLTPクエリをさばく際の書込性能劣化を抑止する 工夫が必要 Copyright 2017 FUJITSU LIMITED カラム形式はレコードの挿入、削除、更新処理に時間がかかる 12
  14. 14. OLTPの性能劣化を抑止する技術  性能劣化抑止技術の代表は”Write-Optimized Store (WOS)”  Verticaの前身であるC-StoreをMITで研究していたグループが2005年に発表  論文名:“C-Store: A Column Oriented DBMS” •http://db.csail.mit.edu/projects/cstore/vldb.pdf  Write-Optimized Store(WOS)とは データベースへの変更をインメモリカラムナに反映する前に一時的に 貯めこむバッファ領域 Copyright 2017 FUJITSU LIMITED WOSを活用してインメモリカラムナへの書込みを 遅延させることによりOLTPの性能劣化を抑止 富士通は変更した行(行ID)を示す独自インデックスとして実装 13
  15. 15. インメモリカラムナ機構PostgreSQL メモリ ディスク PostgreSQLとインメモリカラムナの内部構成 Copyright 2017 FUJITSU LIMITED カラム型専用共用バッファ WOS (index) ・・・ ・・・ ・・・ ・・・ ・・・ ・・・ ・・・ 列1 列m インメモリカラムナ 富士通版PostgreSQLの内部構成 テーブル データ WALログ WOS データ カラムナ データ 共用バッファ テーブル 列 1 行ID 列m ・・・0 ・・・1 ・・・n ・・・ 14
  16. 16. インメモリカラムナへの遅延書込み Copyright 2017 FUJITSU LIMITED インメモリカラムナ機構PostgreSQL メモリ INSERT処理の内部フロー テーブル 列1行ID ・・・0 ・・・1 ・・・n ・・・ 列m c1 0 c1 1 c1 n cm 0 cm 0 cm n ・・・n+1 c1 n+1 cm n+1 行ID n+1 WOS (index) ・・・ ・・・ ・・・ 列1 列m c1 0 c1 1 c1 n cm 0 cm 1 cm n c1 n+1 cm n+1 インメモリカラムナ ➊行ID:n+1の行を挿入 ➋インデックス同期 ➌挿入行を列ごとに分解して、 インメモリカラムナの各列末尾 に追記 同期的に行なう 追加処理は➋のみ 15
  17. 17. インメモリカラムナへのクエリ処理 Copyright 2017 FUJITSU LIMITED インメモリカラムナ機構PostgreSQL メモリ SELECT処理の内部フロー(インメモリカラムナの場合) 列1行ID ・・・0 ・・・1 ・・・n ・・・ 列m c1 0 c1 1 c1 n cm 0 cm 0 cm n ・・・n+1 c1 n+1 cm n+1 行ID n+1 ・・・ ・・・ ・・・ 列1 列m c1 0 c1 1 c1 n cm 0 cm 1 cm n c1 n+1 cm n+1 ワーク 領域 ➌行ID:n+1の 行の列1をコピー ➍返却 ➋インメモリ カラムナから 列1をコピー テーブル WOS (index) インメモリカラムナ ➊列1の抽出要求 (select 列1 from TBL) 16
  18. 18. まとめ:OLTP性能に影響を与えないためには  性能測定  インメモリカラムナあり/なし状態での多重度ごとの更新スループット Copyright 2017 FUJITSU LIMITED 既存のOLTP系業務にほぼ影響なしでリアルタイム分析を実施可能 インメモリカラムナ機構にWOSを実装 0 500 1000 1500 2000 2500 10 20 30 40 50 インメモリカラムナなし インメモリカラムナあり (多重度) (TPS) 当社測定環境による結果 インメモリカラムナの更新スループット 17
  19. 19. インメモリカラムナをコミュニティにフィードバック  カラムナ型は多くの商用DBで利用可能。OSSではMariaDBが対応 PostgreSQLの更なる利用拡大のためコミュニティにフィードバック  PGCon2016で発表。パッチも投稿済み 昨年末メーリングリストにもパッチを投稿 Copyright 2017 FUJITSU LIMITED SAP HANA Oracle Database Microsoft SQL Server IBM Db2 18
  20. 20. コミュニティでの取り組み: Pluggable storage Copyright 2017 FUJITSU LIMITED19
  21. 21. インメモリカラムナからPluggable storageへ Copyright 2017 FUJITSU LIMITED  インメモリカラムナの実装 独自インデックス作成用のAPIを活用。エクステンションとして実装  コミュニティでの議論: 独自ストレージ機構のためのAPIを開発した方がよいのでは? 開発者に対して:保守性・拡張性が向上 ユーザに対して :業務に応じて適切なストレージ構造を選べる インデックスアクセスメソッドAPI インメモリカラムナ エクステンション PostgreSQL コア 20
  22. 22. Pluggable storageのコミュニティでの動向  富士通中心でコミュニティ内で開発中 PGCon 2017でのHaribabuさんの発表をきっかけにV11(来年 秋)への開発が加速  PostgreSQLコミュニティ全体として盛り上がっている 2ndQuadrantのAlvaro Herrera Postgres ProfessionalのAlexander Korotkov EnterpriseDBのRobert Haas などの有力開発者が議論に参加 Copyright 2017 FUJITSU LIMITED21
  23. 23. Pluggable Storageとは(開発中)  複数のストレージ構造を利用可能にするAPI  業務に応じてテーブル毎に最適なストレージを選択可能 Copyright 2017 FUJITSU LIMITED ヒープストレージ (既存) ・・・ ・・・ ・・・ ・・ Pluggable Storage API カラムナ ストレージ インメモリ ・・・ ・ ・ ・・ ・・ ・・・ ・・・ ・・・ ・・・*上記以外にも更新型ストレージ(既存は追記型)の実装も見据えている OLTP OLAP 超高速 22
  24. 24. 既存のPostgreSQLのアクセスメソッド(AM)  物理的なデータの操作はアクセスメソッド(AM)を通して実行  AMはデータがロー型(ヒープタプル)であることが前提=ヒープAM Copyright 2017 FUJITSU LIMITED プランナ / エグゼキュータ 問い合わせ アクセスメソッド バッファ マネージャ ストレージ マネージャ 共用バッファ ・・・ ・・・ ・・・ ・・・ ヒープタプル ・・・ ・・・ ・・・ ・・・ Page(Block)ID=5の 3番目のタプルをフェッチ! tbを シーケンシャルスキャン SELECT * from tb; 23
  25. 25. Pluggable Storage API  Pluggable storageがストレージ構造の違いを吸収 Copyright 2017 FUJITSU LIMITED プランナ / エグゼキュータ 問い合わせ ヒープAM (既存) ・・ ・・ ・・ ・・ Pluggable Storage API カラムナAM インメモリAM ・・・ ・ ・ ・・ ・・ ・・・ ・・・ ・・・ ・・・ 24
  26. 26. APIの例 Copyright 2017 FUJITSU LIMITED プランナ / エグゼキュータ 問い合わせ Pluggable Storage XXX AM XXX ストレージ  プランナ・エグゼキュータ内部でのデータを操作  slot_store_tuple_function()  slot_getattr_function()  スキャン操作  scan_begin_function()  scan_getnext_function()  物理データ操作  tuple_insert_function()  tuple_update_function()  tuple_delete_function() 上記のAPIに従って独自関数を定義 25
  27. 27. 開発者募集!  まだ作り込みは必要  ストレージ構造の変化に対応したプランナ  各ストレージ構造とAM Copyright 2017 FUJITSU LIMITED ぜひ、一緒に開発しませんか? プランナ / エグゼキュータ ヒープAM (既存) Pluggable Storage API カラムナAM インメモリAM ヒープ ストレージ カラムナ ストレージ インメモリ データ構造 pgsql-hackers@postgresql.org スレッド名“Pluggable storage” 26
  28. 28. まとめ  PostgreSQLのエクステンションとしてインメモリカラムナを実装  コミュニティ内でPluggable storageを開発中  日進月歩でPostgreSQLは進化している 上記以外にも FDWやJSONBなどによるNoSQL対応 レプリケーション機能の強化などによる信頼性向上 パラレルクエリなどによる性能向上 Copyright 2017 FUJITSU LIMITED 今までにないビジネス領域でのPostgreSQLの活用を広めていく 27

×