[db tech showcase Tokyo 2016] C32: 世界一速いPostgreSQLを目指せ！インメモリカラムナの実現 by 富士通株式会社小林郁弥

2016年7月15日
富士通株式会社
データマネジメントミドルウェア事業部
小林郁弥
世界一速いPostgreSQLを目指せ！
インメモリカラムナの実現
Copyright 2016 FUJITSU LIMITED
db tech showcase Tokyo 2016

略歴
小林郁弥（こばやしふみや）
2010年よりデータベース製品の開発を担当
FUJITSU Software Symfoware Server (PostgreSQL)
FUJITSU Integrated System PRIMEFLEX for HA Database
FUJITSU Software Symfoware Analytics Server
RDBから情報系まで、データベース全般を開発。
最近は、様々なお客様のProof of Conceptがメーン。
データの管理から活用へ軸足が移っていることを日々体感。
PostgreSQLをベースにエンタープライズユースの機能を強化
Symfoware Serverのハードウェアアプライアンス製品
PostgreSQLインターフェースのカラム型データベース
1

本日のアジェンダ
なぜPostgreSQLのインメモリカラムナに取り組んだのか
今回実装したインメモリカラムナ技術のご紹介
本日のまとめ
Copyright 2016 FUJITSU LIMITED2

なぜPostgreSQLの
インメモリカラムナに取り組んだのか
3

富士通のPostgreSQLへの取組み
 OSS技術によりお客様のやりたいことをスピーディに実現していくために、
富士通のデータベースエンジンにPostgreSQLを採用
FUJITSU Software
Symfoware Server (PostgreSQL)
PostgreSQL
富士通のデータベース技術
信頼性性能使いやすさ
富士通のあんしんサポート
4

 に加え、
OLTPのデータをリアルタイムに見て判断に繋げたい
データベースを取り巻く市場の変化
 OLTPのデータをOLAPで分析すること
OLTPとOLAPを共存させる
OnLine miXed workload Processing (OLXP)により実現
OLTP
売上データの管理
OLAP
ビジネスプラン分析
OLXP
売上データの管理
＋
ビジネスプラン分析
ETL
クライアント
3か月間の地域ごとの
売上top 10店舗
定時定型
バッチ処理リアルタイム処理
アドホック処理アドホック処理
この3時間の商品の
売上げ状況は
クライアントクライアント
5

OSS DBは、まだOLXPの領域に入ってきていない
MariaDBはColumnStoreというOLAP向けストレージエンジンを
開発中
データベースを提供するベンダー各社の取組み
近年、データベースベンダー各社は「OLXPの実現」に
取り組んできている
SAP HANA Oracle Database
Microsoft SQL Server IBM DB2
OLXP実現の技術として活用されてきているのが
「インメモリカラムナ」
出典：https://mariadb.com/kb/en/mariadb/mariadb-columnstore-101-alpha-release-notes/
6

富士通のOLXPへの取組み
 富士通はPostgreSQLにインメモリカラムナを実装し、
OSS DBとしては世界で初めてOLXPに取り組んだ
コミュニティ版PostgreSQL比 48倍のスループットを実現
7

インメモリカラムナ技術のご紹介
今回実装したOLXPを実現する
8

PostgreSQLへのOLXP実装構造
エクステンションとしてインメモリカラムナ機構を実装
OSSとしてのオープン性を損なわずに、OLXPを実現
PostgreSQL
（OLTP）
インメモリカラムナ機構
（OLAP）
OLXP
ロー型テーブルカラム型インデックス
9

OLXPを実現するインメモリカラムナ技術とは(1)
OLAPで発展してきたインメモリカラムナ技術は、
大量データに対するクエリ処理の高速化
インメモリカラムナ機構
インメモリカラムナを利用するSQL実行計画の作成
並列処理
ベクトル演算
列圧縮
OLXPの実現にはOLAPのクエリ処理の高速化だけでは不足
OLTPとの共存を可能にする技術が必要
10

OLXPを実現するインメモリカラムナ技術とは(2)
OLTPとOLAPを共存可能にする3つのポイント
OLTP性能に影響を与えない1
OLAPで最新データが分析できる2
OLTPとOLAPのリソースバランスを制御できる3
本日は上記を実現する技術をご紹介します
11

OLXPを実現する3つの技術
12

OLXP実現のための性能課題
 OLTPとOLAPの違い、そしてデータ構造の違いに起因する課題
 システムごとの書込パターンの比較
• OLTP ：少量で断続的な挿入と更新。時間の経過に応じて更新頻度低下。
• OLAP ：大量一括挿入。更新なし。
• OLXP ：OLTPに準じる
 データ構造ごとの書込性能比較
• ロー形式データ構造：書込みが速い
• カラム形式データ構造：ロー型に比べ書込みが遅い
 カラム形式データ構造でOLTPクエリをさばく際の書込性能劣化を抑止する
工夫が必要
カラム形式はレコードの挿入、削除、更新処理に時間がかかる
13

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)とは
 データベースへの変更をインメモリカラムナに反映する前に一時的に
貯めこむバッファ領域
WOSを活用してインメモリカラムナへの書込みを
遅延させることによりOLTPの性能劣化を抑止
 富士通は書込み性能に最適化した独自インデックスとして実装
14

インメモリカラムナ機構PostgreSQL
メモリ
ディスク
PostgreSQLとインメモリカラムナの内部構成
カラム型専用共用バッファ
WOS
(index)
・・・
・・・
・・・
・・・
・・・
・・・
・・・
列1 列m
インメモリカラムナ
富士通版PostgreSQLの内部構成
テーブル
データ
WALログ WOS
データ
カラムナ
データ
共用バッファ
テーブル
列
1
TID 列m
・・・0
・・・1
・・・n
・・・
15

インメモリカラムナへの遅延書込み
メモリ
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の行を挿入
➋インデックス同期
➌挿入行を列ごとに分解して、
インメモリカラムナの各列末尾
に追記
同期的に行なう
追加処理は➋のみ
16

インメモリカラムナへのクエリ処理
メモリ
SELECT処理の内部フロー（インメモリカラムナの場合）
列1行ID
・・・0
・・・1
・・・n
・・・
列m
c1
0
c1
1
c1
n
cm
0
cm
0
cm
n
・・・n+1c1
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）
17

まとめ:OLTP性能に影響を与えないためには
 性能測定
 インメモリカラムナあり／なし状態での多重度ごとの更新スループット
既存のOLTP系業務にほぼ影響なしでリアルタイム分析を実施可能
インメモリカラムナ機構にWOSを実装
0
500
1000
1500
2000
2500
10 20 30 40 50
インメモリカラムナなしインメモリカラムナあり
(多重度)
(TPS)
当社測定環境による結果
インメモリカラムナの更新スループット
18

19

OLXP特有の整合性の課題
 OLXP特有の同時実行性要求
 システムごとの書込・参照の同時実行性
• OLTP：書込と参照が同時に行われる
• OLAP：書込と参照の時間帯を区切ることが一般的
例：夜間のみ、12～13時と18～19時と6～7時など限られた時間など
• OLXP：OLTPに準じる
 メリット：楽観的なトランザクション制御なので高い同時実行性が期待できる
 デメリット：トランザクションに対して、どの版(バージョン)の行が有効なのかを
判定する可視性判定処理を行単位に実施。
scan行数が多い場合は可視性判定処理のオーバーヘッドが増加
OLXPシステムでは書込と参照の高い同時実行性が
インメモリカラムナにも求められるのでMVCC方式が最適だが・・・
MVCCによるトランザクション制御にはメリットとデメリットがある
分析クエリはscan行数が多いため、処理のオーバーヘッドの解消が必要
20

OLXPでMVCC制御時の考慮事項
 全トランザクションから見て有効な行は可視性判定処理を省略可能
 PostgreSQLは全トランザクションから見て有効な行を記憶
 その行に対する判定処理を省略しオーバーヘッドを低減 (index only scanの場合)
分析クエリはscan行数が多いため、処理のオーバーヘッドの解消が必要
解決のヒント
 「可視性判定処理の省略」のアイデアをインメモリカラムナにも適用
 判定処理が省略可能な行のみをWOSからインメモリカラムナに移動させる
 インメモリカラムナのみに存在する行は判定処理なしで有効とみなす
21

まとめ:OLAPで最新データを分析するには
 MVCCの考え方を取り入れ、可視性判定処理のオーバーヘッドを解消
することでインメモリカラムナで高い同時実行性を実現
 同時実行性に関する性能測定
 オンライン業務中の順検索性能に対するインメモリカラムナ検索の性能比
MVCCの考え方をインメモリカラムナにも適用
11.3
10.4
9.1
0
5
10
15
300 1000 1500
順検索に対するインメモリカラムナ検索の性能向上比
(TPS)
(倍)
当社測定環境による結果
22

23

OLXP特有のリソース制御の課題
 OLXPシステム特有のアクセスパターンに起因してキャッシュヒット率が
低下する課題
 システムごとの書込パターンの比較(もう一度)
• OLTP ：断続的で少量の挿入・更新・削除。挿入後の時間経過で更新頻度低下
• OLAP ：大量一括挿入、更新なし。必要に応じて一括削除
• OLXP ：OLTPに準じる
 システムごとの参照パターンの特性比較
• OLTP ：断続的で定形、かつ少量の抽出
• OLAP ：不定期で不定形な大量集計(分析クエリ)
• OLXP ：OLTP的な参照とOLAP的な参照の両方
 OLXPシステムでは挿入から時間の経ったデータがDBバッファから追い出されるた
め、分析クエリのキャッシュヒット率が下がる
 分析クエリに対するキャッシュヒット率を維持する工夫が必要

OLXPにおける分析クエリのキャッシュヒット率の低下
時間
カラムナ
テーブル
インデックス
バ
ッ
フ
ァ
制
御
な
し
キャッシュミス量
ここで分析クエリ発生
データをバッファに維持し続ける機能がないと
分析クエリのキャッシュヒット率が低下
25

OLTPとOLAPのDBバッファを制御する技術
 富士通では”ステーブルバッファ機能”を実装することでこの課題を克服
 ステーブルバッファ機能とは
 インメモリカラムナ専用のDBバッファを用意できるようにする機能
ステーブルバッファ機能があるとカラムナデータが
キャッシュに残り分析クエリのキャッシュヒット率が安定
カラムナ
テーブル
インデックス
バ
ッ
フ
ァ
制
御
あ
り
カラムナ専用バッファ量
時間
カラムナ
テーブル
インデックス
バ
ッ
フ
ァ
制
御
な
し
キャッシュミス量
ここで分析クエリ発生
26

まとめ:OLTPとOLAPのリソースバランスを制御するには
 OLTPとOLAPが使用するDBバッファ量を調整することで、必要最低限
のメモリ増設で安定したレスポンスを実現可能
 既存のOLTP性能を確保しながらリアルタイムな分析を行なうには、
OLAP分の追加メモリが必要
インメモリカラムナ専有のDBバッファ領域を用意
27

本日のまとめ
PostgreSQLのエクステンションとしてインメモリカラムナを実装
PostgreSQL
（OLTP）
インメモリカラムナ機構
（OLAP）
OLXP
ロー型テーブルカラム型インデックス
OLXPの実現によりPostgreSQLのビジネス活用領域を拡大
WOSを活用しOLAPへの遅延書込みを実装。
データを同期させながらOLTPの性能を維持
MVCCをインメモリカラムナに実装。
OLAPで最新データをリアルタイムに参照可能
OLTPとOLAPのリソースバランスを制御。
必要最低限の追加リソースでOLXPを安定的に利用可能
28

ご参考
 PostgreSQL をベースとしたカラムストア機構の実現検討
 PostgreSQL ベースの並列処理向けの共有メモリ機構の設計
 PostgreSQLベースのカラムナ機構へのトランザクション実現検討
本日、紹介できなかったインメモリカラムナ実装やトランザクション制御の
情報に関する情報を以下で公開しています。是非ご参照ください。
DEIM2015発表資料
情報処理学会第77回全国大会発表資料
富士通研究所 PostgreSQL [イベント名]
29

登録商標
 Symfowareは富士通株式会社の登録商標です。
 Oracle、MySQL、Javaは、Oracle Corporation およびその子会社、関連会社の米国およ
びその他の国における登録商標です。文中の社名、商品名等は各社の商標または登録商標で
ある場合があります。
 SAP及びSAPロゴ、SAP HANA、その他のSAP製品は、ドイツ及びその他の国におけるSAP
AGの商標または登録商標です。
 MicrosoftおよびSQL Serverは、米国 Microsoft Corporation の、米国およびその他の
国における登録商標または商標です。
 IBM、IBM ロゴ、DB2は、International Business Machines Corporation の米国およ
びその他の国における商標または登録商標です。
 PostgreSQLは、PostgreSQLの米国およびその他の国における商標です。
 記載されている製品名、会社名などの固有名詞は、各社の登録商標または商標です。
 その他、本資料に記載されているシステム名、製品名などは、必ずしも商標表示を付記していま
せん｡

[db tech showcase Tokyo 2016] C32: 世界一速いPostgreSQLを目指せ！インメモリカラムナの実現 by 富士通株式会社小林郁弥

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to [db tech showcase Tokyo 2016] C32: 世界一速いPostgreSQLを目指せ！インメモリカラムナの実現 by 富士通株式会社小林郁弥

Similar to [db tech showcase Tokyo 2016] C32: 世界一速いPostgreSQLを目指せ！インメモリカラムナの実現 by 富士通株式会社小林郁弥 (20)

More from Insight Technology, Inc.

More from Insight Technology, Inc. (20)

Recently uploaded

Recently uploaded (9)