postgresqlを活用するための基礎知識 - obci.jp · • postgresql...

Copyright © 2016 TIS Inc. All rights reserved.

PostgreSQLを活用するための基礎知識

　～ PostgreSQLでできること／できないことを知ろう～

TIS株式会社中西剛紀

Copyright © 2016 TIS Inc. All rights reserved. 2

はじめに


最近のOSS事情

•  5,6年年前：OSSは⼀一般的でない – コスト削減要望を受けてやむを得ず – プロダクト品質への不不安を払拭するのに必死

• 現在：OSSを使うのは当たり前 – ユーザ側がOSSに抵抗感を持たなくなっている – むしろOSSでの提案を希望されるケースが増加 – データベースにもOSSを求める⾵風潮が


知ってほしいこと

• 全てOSSに置き換わるわけじゃない – 商⽤用製品にしかできないこともある – 製品の特徴を理理解して選択するのが⼤大切切

• 技術者の⽴立立場 –  PostgreSQL案件で慌てないよう先に知っておく – 特徴を知れば他製品の知識識でキャッチアップ可能


自己紹介 • ⽒氏名: 中⻄西剛紀(なかにしよしのり)• 所属: TIS株式会社 OSS推進室• 仕事: OSSのサポート、技術⽀支援 •  PostgreSQL歴：6年年くらい •  DB歴：たぶん10年年以上


PostgreSQLへの取り組み • コミュニティでの活動

–  PostgreSQLエンタープライズコンソーシアム•  成果報告セミナーでWG検証成果を講演したり •  http://itpro.nikkeibp.co.jp/atcl/column/15/052800134/052900004/?ST=oss&a

– ⽇日本PostgreSQLユーザ会 •  PostgreSQLカンファレンス2015で講演したり•  http://www.slideshare.net/naka24nori/postgre-sql-55593111

• 周辺ツールの公開 –  pg_monz: ZabbixでPostgreSQLを監視するツール

•  http://pg-monz.github.io/pg_monz/


PostgreSQLの基礎知識


歴史

1997

6.0

2003

20052006

20072008

2009

2011

20122013

20142015

7.4

8.0 Windows対応 PITR テーブルスペース PITR

8.1 パーティショニング 2相コミットバッファ管理理改良良ロール

8.2 CPUスケールオンライン索索引作成 GINインデックスウォームスタンバイ

8.3 HOT:更更新性能向上 VACUUM⾃自動化全⽂文検索索 XMLデータ型

8.4 Window関数再帰SQL

9.0 レプリケーションホットスタンバイ Windows 64bit対応

9.1 同期レプリケーションパーティショニング強化⼀一時テーブル強化

9.2 カスケードレプリケーションスケーラビリティ向上インデックス検索索強化

9.3 障害切切替時間短縮ビューの改良良 DB間連携強化

9.4 レプリケーション運⽤用性向上 JSON強化⼤大容量量メモリ対応

9.5 BRINインデックス WAL圧縮⾏行行レベルセキュリティ UPSERT

2010


対応するプラットフォーム • いろんなOSで動作

–  Linux (最近のディストリビューションすべて) –  Windows (Win2000 SP4以降降) –  FreeBSD, OpenBSD, NetBSD –  OS X, AIX, HP/UX, Solaris, UnixWare – ビルドファームで何がテスト済かを確認可能

http://buildfarm.postgresql.org/cgi-bin/show_status.pl

•  Windowsでちょっと困ること –  Windowsでは動かない周辺ツール達

•  pg_rman, pg_statsinfo, pgpool-II 等 –  Windowsで使えないノウハウ

•  メモリ関連のチューニング


ライセンス

•  The PostgreSQL Licence –  BSDやMITに似た緩いライセンス – プロダクトのダウンロード、利利⽤用は無償 – 商⽤用利利⽤用も制限なし – ソースコードを改変した有償製品を売ってもいい – 改変したソースコードの公開は不不要 –  PostgreSQLベースの商⽤用製品、サービス

•  PowerGres/PowerGres Plus (SRA OSS) •  EDB Postgres (旧：Postgres Plus)（EnterpriseDB） •  Amazon Redshift（AWS）：PostgreSQL 8.0.2 ベース •  Greenplum（Pivotal）


サポート • 保守サポートベンダは国内に多数

–  SRA OSS, Inc, ⽇日本⽀支社 – アシスト – サイオステクノロジー –  NEC – ⽇日本HP – ⽇日⽴立立製作所 –  TIS

• サポートは⼊入っておきましょう – ソース読めばなんでもできますが、誰がやる？


コミュニティ • ボランティアベースの組織運営

–  PostgreSQL Global Development Group –  PostgreSQLへ貢献する個⼈人/企業の⾮非法⼈人組織 – 特定の会社が開発をコントロールしない – プロダクトの進化を⽌止めずに運営し続ける苦労

• 他の製品は？ –  Oracle –  MySQL


PostgreSQLができること／ PostgreSQLが苦手なこと


データベースに何を求める？ •  ACID特性

–  Atomicity: 原⼦子性 •  トランザクション全体が実⾏行行される or 全く実⾏行行されない

–  Consistency: ⼀一貫性 •  整合性条件を満たさない状態を起こす処理理は実⾏行行しない

–  Isolation: 独⽴立立性 •  トランザクション途中のデータを他から参照出来ない •  隔離離性があるということ

–  Durability: 永続性 •  トランザクション完了了後のデータを失わない •  耐障害性があるということ

•  PostgreSQLはACIDを満たす


MVCC • 同時並⾏行行性とデータ⼀一貫性を両⽴立立

– 変更更中データをロックすると同時並⾏行行性を損なう – 変更更前後のデータを持つことで同時並⾏行行性を保つ

•  PostgreSQLは追記型で実現 – 書き込み中でも読み込みをブロックしない

ID 商品名在庫数001 A 10

002 B 8

003 C 20

004 D 12


002 B 8

003 C 20

004 D 12 002 B 6

UPDATE 在庫 SET 在庫数 = 6 WHERE ID = 002；

SELECT 在庫数 FROM 在庫WHERE ID = 002；


VACUUM •  PostgreSQLは追記型

– 不不要になったデータはVACUUMで回収 – 運⽤用時にノウハウが必要になることも

•  Oracle, MySQLもMVCCを実現 –  UNDOセグメントに変更更前データを退避


002 B 8

003 C 20

004 D 12 002 B 6

VACUUM

不不要領領域を回収せよ

再利用可能レコード

INSERT INTO 在庫 VALUES (005, 'E', 50);


SQLで柔軟にデータを操作 • 標準SQLへの準拠度度が⾼高い

–  ISO/IEC 9075「Database Language SQL」 –  ISO/IEC 9075:2011(SQL:2011) のほとんどの機能をサポート

• 多様なSQLをサポート –  MySQLにはない標準SQLの例例 –  Window関数 : 複雑な集計を効率率率よく処理理する構⽂文 – 再帰SQL : 親⼦子関係を持つ⽊木構造のテーブルに

対して繰り返し⾃自⼰己結合を⾏行行う


性能 •  PostgreSQLは性能が悪い？

– 昔から「PostgreSQLは遅い」と思われている。。。 – 古いバージョンのイメージが根強い


PostgreSQLの性能は悪いのか •  CPU数に応じたスケールアップ

–  9.4 ⇒ 9.5 でさらに 22％性能向上

0

5000

10000

15000

20000

25000

30000

0 20 40 60 80 100 120 140

TPS

クライアント数

9.5

9.4

PGECons 2015年年度度WG1活動報告より抜粋


PostgreSQLの性能は悪いのか • パーティショニング

– テーブルを分割して検索索、更更新性能を向上 – 約36億件を180分割した時の検索索性能

PGECons 2013年年度度WG1活動報告より抜粋

いずれの検索索⽅方法においても、パーティションを使⽤用した⽅方が⾼高速


性能 • プロセスモデルの違い

– 接続要求毎にプロセス or スレッドを⽣生成 – マルチプロセス：PostgreSQL, Oracle – マルチスレッド：MySQL – 同時実⾏行行数が多いケースは MySQL が有利利

• ディスクI/Oの違い –  MySQLはランダム指向でSSDと相性良良 –  Fusion-ioで性能が数⼗十倍になる事例例も –  PostgreSQLはHDD向けのシーケンシャル指向 – 並べ替えて書き込むのでSSDでも速くならない


性能 • 複雑なSQLはPostgreSQL優位？

– 多様な結合⽅方式をサポート •  Nested Loop, Merge Join, Hash Join •  MySQL は Nested Loop のみ •  ⼤大きなテーブル同⼠士を結合する分析⽤用途で差が出る

– サブクエリ（副問い合わせ） •  PostgreSQL は⾮非相関サブクエリを 1 回だけ実⾏行行 •  MySQL は⾮非相関サブクエリも N 回実⾏行行してしまう •  PostgreSQL では結合するより⾼高速なことが多い

–  MySQL はSQLをシンプルに。アプリで頑張る。

select id, name, description from departmentswhere id in ( select dept_id from employees where gender = 'F' )


可用性 •  DBサーバ停⽌止 = サービス停⽌止

• 冗⻑⾧長化による可⽤用性確保が⼀一般的

•  PostgreSQLでの冗⻑⾧長化構成 –  HAクラスタ構成（共有ストレージ） –  HAクラスタ構成（シェアードナッシング） – ストリーミングレプリケーション


HAクラスタ（共有ストレージ） • アクティブ/スタンバイ • 旧来からある⽅方式

• シンプルで運⽤用が楽

• ストレージが⾼高い


HAクラスタ（シェアードナッシング） • アクティブ/スタンバイ • ストレージでデータ同期

– ストレージの機能を利利⽤用 – ソフトウェアの機能を利利⽤用

• 低コストで実現可能 – クラスタソフト：

Heartbeat, Pacemaker – レプリケーション：DRBD


ストリーミングレプリケーション • アクティブ/アクティブ

– 待機系サーバでも参照SQLを実⾏行行可能 – 待機系サーバを増やして参照処理理をスケールアウト

• 低コストで実現可能 – 標準機能でデータ同期


より高い可用性を求めるケース •  Oracle RAC

– キャッシュ機構で⼀一貫性を保ちつつ、⾼高可⽤用性と⾼高拡張性を実現

•  MySQL Cluster – 単⼀一障害点がなく障害時の切切替も⾼高速 – 99.999％の⾼高い可⽤用性 – 単純なクエリを⼤大量量に捌きたいニーズ向け

•  PostgreSQLでここまでは満たせない – 更更新可能なマスタは1台という制約


セキュリティ •  PCI DSSをどこまで満たせる？

– クレジットカード業界のセキュリティ基準 –  PostgreSQLエンタープライズコンソーシアムのWG活動で調査

–  https://www.pgecons.org/wp-content/uploads/PGECons/2014/WG3/PGECons_2014_WG3_Security.pdf

• アクセス制御はだいたい可能 – クライアント認証 – テーブル、列列、⾏行行単位に参照可能データを制限 –  OSや外部ツールの助けが必要なこともある

•  アカウントポリシー •  不不正アクセスへの対処


セキュリティ • 監査

– 標準機能で実⾏行行したSQLをログ出⼒力力可能 – 課題：出⼒力力対象を細かく指定できない

•  テーブル単位、列列単位での指定•  SQL種別(READ,FUNCTIONのみ)を指定 •  拡張モジュール pgaudit で若若⼲干改善

– 課題：サーバログと監査ログを分けられない •  監査ログを分析する際の煩わしさ •  商⽤用製品 EDB Postgres は監査ログを別にできる


セキュリティ • 暗号化

– 格納データを透過的に暗号化するニーズ •  カード番号、マイナンバー •  アプリ側で暗号化するのは煩わしい

– 課題：格納データを暗号化する機能がない –  PostgreSQLでデータを暗号化する⽅方法

•  ファイルシステムの透過的暗号化機能•  拡張モジュール pgcrypto •  Transparent Data Encryption for PostgreSQL(TDE) •  商⽤用製品(PowerGres Plus)


運用機能 • リッチなGUIは期待しない

– 基本的に⿊黒い画⾯面とシェルスクリプトで対応！

• 性能チューニング – ⾃自動チューニング？なんすかそれ？ –  OracleはSQLトレースでいろんなことがわかる –  PostgreSQLはSQL単位のトレースは取れない

• バックアップ等のツール – 標準機能を補うツールがOSSで公開されている – ドキュメントやノウハウ情報は少なく、使えるものを選定して、使いこなすのは⾯面倒


PostgreSQLで高可用性クラスタを実現した事例


案件概要

• 通信事業者のコンシューマ向けサービスの状況確認・変更受付の窓口となるポータルサイトの再構築

• コスト、ベンダーロックイン回避の観点からOSS採用には積極的

• ただし、データベースは可用性要件を考慮して当初はOracle RACを想定

• 最終的にデータベースはPostgreSQLを選択し、基盤ミドルウェアを全てOSS化


PostgreSQL選択のポイント • 要求事項の絞込み

– 非機能要件がシビアでないことが判明 – 可用性：秒単位の切替は求めない – 性能拡張性：求めない – Oracle RACではオーバースペック

• 事前検証済の推奨構成パッケージを保有 – PostgreSQLクラスタは技術検証し、達成可能な可用性要件を確認済

– 基盤ミドルウェアをOSSで構築する際の推奨構成をパッケージング


ISHIGAKI Template

• エンタープライズ領域で推奨する OSSをパッケージ化したもの

• OSSを利用する際に投げかけられる不安 •  非機能要求への適合性 = 「OSSを本番業務に使って大丈夫？」 •  非機能要求なんて気にしない、本番業務はない •  性能や可用性は調査だけでは（やってみないと）わからない

検証ケースを積み上げて洗練した推奨構成を提供


HA Edition

• 障害時の業務停止を回避するHAクラスタ

Standbyサーバ

運⽤用設定

情報収集

Apache

Tomcat

Activeサーバ

死活監視データ同期

Tomcat

Apache

リソース監視リソース監視

運⽤用監視サーバ

•  Active/Standby型で冗長化し可用性を向上 •  DRBDでデータ同期を行い安価なディスクで実現


Cluster Edition •  Web/AP/DBサーバが複数台分散して処理を行う高性能クラスタ構成

•  Active/Active 型で冗長化し可用性を向上 •  スケールアウト型での性能向上を実現

マスター

スレーブ

スレーブ

Tomcatpgpool-Ⅱ

セッションレプリケーション参照負荷分散 DBレプリケーション

Tomcatpgpool-Ⅱmod_jk

mod_jk

mod_jkTomcat

pgpool-Ⅱ

負荷分散

情報収集

運⽤用監視サーバ

運⽤用設定


標準構成のための“参照モデル” • ベースとなる参照モデル(左)を定義 • 参照モデルを推奨構成(右)として具体化

業務アプリケーション

アプリケーションフレームワーク

ミドルウェア (AP基盤・ID管理)

ミドルウェア (運用)自動化

OS

仮想化基盤

サーバ／ストレージ

ネットワーク

クラウド基盤(IaaS)

クラウドサービス(SaaS，PaaS)

Oracle, (DB2),(WebSphere), JBoss,

Apache

PostgreSQL,JBoss, Tomcat, Apache,OpenAM, OpenLDAP

個別要件対応型(高信頼性要件指向)

標準パターン型(オープンスタンダード指向)

JP1, (Zabbix), (Hinemos),(バックアップ,構成管理,他)

Zabbix, Hinemos, JobScheduler,

(バックアップ,構成管理,他)

Linux, （AIX, 他UNIX) Linux, Windows srv.

AWS, TEOS,(Azure), (Softlayer)

VMwareVMware, (Hyper-V),

(OpenStack), (Docker)

主要ハードウェアメーカ製品, (SDS)

主要ネットワーク機器メーカ製品, (SDN)

ミドルウェア(AP基盤・ID管理)

ミドルウェア(運用)

OS

クラウド基盤

仮想化基盤

サーバ／ストレージ

ネットワーク

Ansible, Chef, Serverspec　　　　

(PaaS基盤)


PostgreSQLの最新動向


外部データラッパ •  PostgreSQLのテーブルの様に外部データへアクセス可能 – 外部データに応じた拡張機能を組み込んで使⽤用 – データ更更新(9.3)、外部データの継承(9.5) –  9.6 でリモートでのソート/結合も可能に

PostgreSQL 外部データ

通常のテーブル

postgres_fdw

mysql_fdw

redis_fdw

twitter_fdw

file_fdw

サーバプロセス

PostgreSQL

MySQL

NoSQL(Redis)

Twitter

CSVファイル

外部データラッパ


ログを外部テーブル化 •  file_fdwでPostgreSQLログを外部テーブル化 testdb=# CREATE EXTENSION file_fdw;

testdb=# CREATE SERVER pglog FOREIGN DATA WRAPPER file_fdw;

testdb=# CREATE FOREIGN TABLE pglog (log_time timestamp(3) with time zone,

testdb(# user_name text, database_name text, process_id integer,

testdb(# connection_from text, session_id text, session_line_num bigint,

testdb(# command_tag text, session_start_time timestamp with time zone,

testdb(# virtual_transaction_id text, transaction_id bigint, error_severity text, testdb(# sql_state_code text, message text,detail text, hint text,

testdb(# internal_query text, internal_query_pos integer, context text,

testdb(# query text,query_pos integer, location text,application_name text

testdb(# ) SERVER pglog

testdb-# OPTIONS (filename '/var/lib/pgsql/9.4/data/pg_log/postgresql-Fri.csv', format 'csv');

testdb=# select log_time,user_name,database_name,process_id,error_severity,

message,application_name from pglog where message like 'duration%';

-[ RECORD 1 ]-------+------------------------------------------------------

log_time

| 2015-11-06 08:33:31.528+00

user_name

| postgres

database_name

| testdb

process_id

| 8962

error_severity

| LOG

message

| duration: 5006.931 ms statement: select pg_sleep(5);

application_name

| psql


JSON •  JSON形式のデータを投⼊入可能

– スキーマ定義が難しい⾮非構造化データを扱う – 組み込みデータ型として JSON, JSONB を⽤用意

•  PostgreSQLでJSONを扱うメリット – 構造化データと同様にSQLで操作可能

•  既存のテーブルとのJOINもOK – 転置インデックスが使える

•  「この要素を含むもの」を問い合せる検索索が⾼高速 – トランザクションに対応

•  JSONを扱うDB：MongoDB, Couchbase 等 •  NoSQLデータベースとは重視することが違う


BRIN (Block Range INdex) • ブロック毎の最大値と最小値のみを保有

– B-Treeは対象列の全てのデータを保有

• インデックスのサイズが小さくすむ • 順序よく並んだデータの範囲検索用途

– DWHのファクトテーブル

id = 1

id = 1000

id = 2000

id = 3000

・・・

１ 1000 3000 5000

テーブルインデックス(B-Tree)ヒープブロック 0-127 最小：1, 最大: 900

ヒープブロック 128-255 最小: 1000, 最大: 3000

・・・

インデックス(BRIN)

欲しいレコードを特定してアクセス欲しいレコードを含むブロックまで特定してアクセス


パラレルクエリ •  SQL1つに割当るプロセスは1つ

–  CPUが余っててもSQL実⾏行行は速くならない

•  1つのSQLを複数プロセスで並列列処理理することが可能に(9.6〜～) – 分析系の重たいSQLを速くできる可能性

Big Table


従来(〜～9.5) 9.6 以降降


Big Table

CPUは１つしか使えない

ワーカプロセス

ワーカプロセス

ワーカプロセスCPUを

複数使う


レプリケーション •  PostgreSQLの標準機能

–  2010年年リリースの 9.0 より実装 – 更更新可能なマスタは1台。スレーブは複数台OK – 多段のレプリケーションも可能

•  カスケードレプリケーション –  MySQLの⽅方が先輩。ツールやノウハウで負ける。

災対サイトメインサイト

スレーブDB

PostgreSQL

スレーブDB

PostgreSQLスレーブDB

PostgreSQL

マスタDB

PostgreSQL

WALレコード

WALレコード


レプリケーション 9.6新機能 • 同期レプリケーション

– マスタでCOMMITしたデータの損失を防⽌止 –  WALがスレーブに届くまでCOMMITを待機


レプリケーション 9.6新機能 • 複数同期レプリケーション

– 同期レプリケーションスレーブを複数稼働可能に (9.6〜～)

–  9.5までは同時にスレーブは1台のみ

• 完全同期レプリケーション – スレーブのWAL適⽤用完了了するまでCOMMITを待機 – どのスレーブを参照しても最新データが⾒見見える – 更更新性能は犠牲にする覚悟が必要


まとめ


PostgreSQLで何ができる？ •  ACID、MVCC • 標準SQLに準拠。多様なSQLに対応 • 性能拡張性

–  CPU数に応じたスケールアップ – 巨⼤大テーブルを分割するパーティショニング

• 冗⻑⾧長化による可⽤用性確保 – 周辺ツールもOSS利利⽤用で低コストに実現可能

• 制約の少ないライセンス • 利利⽤用は無償。保守サポートは有償


PostgreSQLは何が苦手？ • ⾼高可⽤用性と⾼高拡張性の両⽴立立

– 稼働率率率 99.999％と更更新処理理のスケールアウト

• 運⽤用機能 – 必要最低限の機能は⽤用意されている – 運⽤用者にそれなりの知識識を要求する

• セキュリティ – 監査 – 暗号化


Oracleはいろいろできる

• お⾦金金をかければ –  Enterprise Edition なら、、、 –  RAC なら、、、

•  RACレベルが要求される場⾯面はある – でも今回のシステムで本当に必要？


パーフェクトを求めない • 機能の ◯✕ 表を作らない

– 不不要な機能までフラットに⽐比較してない？

• シンプルな要件に落落としこむ –  Oracle RAC は本当に必要？という検討から

• 最近はRDBMS以外の選択肢も – クラウド、分散、⼤大規模分析 ⇒ NoSQL –  ACIDは満たさなくてもスケールさせたい – 特徴を理理解し最適なものを選ぶ時代が来ている

postgresqlを 活用するための基礎知識 - obci.jp · • postgresql...

Documents

postgresqlを活用するための基礎知識 - obci.jp · • postgresql...