PGConf.ASIA 2017

PostgreSQLを使って変化に強いシステムへ！

2017/12/4(株)日立製作所 システム＆サービスビジネス統括本部
OSSソリューションセンタ

© Hitachi, Ltd. 2017. All rights reserved.

Contents
1. 日立の取り組み

2. PostgreSQLとIoT
3. 某DBからPostgreSQLへの移行事例
4. 弊社サービス紹介© Hitachi, Ltd. 2017. All rights reserved.

1

自己紹介
●名前
稲垣

毅

(INAGAKI Tsuyoshi)

Facebook：

https://www.facebook.com/tsuyoshi.inagaki.3●所属
・株式会社日立製作所 OSSソリューションセンタ
・PostgreSQL エンタープライズコンソーシアム
・OSSコンソーシアム オープンCOBOLソリューション部会●仕事
・PostgreSQL、MySQLのテクニカルサポート
・データベースの評価、検証・外部団体の活動●PostgreSQLの近況
・hookの面白い活用方法を考えている（←あくまで趣味です。）© Hitachi, Ltd. 2017. All rights reserved.

2

１. 日立の取り組み© Hitachi, Ltd. 2017. All rights reserved.

3

1-1. デジタル化の進展
世界では産業・社会インフラのデジタル化が加速
欧州
Industrie4.0

中国
中国製造2025

日本

アジア
スマートシティSociety5.0

北米
Industrial Internet

パラダイムシフト：人、社会を中心に考えるサービス、技術の進化

モノ

コト

占有

シェア

クローズド

オープン

個別最適

全体最適
© Hitachi, Ltd. 2017. All rights reserved.

4

1-2. 社会イノベーション事業に貢献
高度道路交通システム
スマート・フードチェーンシステム
スマート生産システム

エネルギー
バリューチェーン

新たなものづくりシステム
地域包括
ケアシステム

内閣府 第５期科学技術基本計画

超スマート社会 Society5.0
あらゆる人が活き活きと快適に暮らすことのできる社会

総合型材料開発
システム

地球環境情報プラットフォーム

おもてなし
システム

インフラ
維持管理・更新

自然災害に対する強靭な社会© Hitachi, Ltd. 2017. All rights reserved.

51-3. 日立がめざす姿

ＩｏＴ時代のイノベーションパートナー
進化した社会イノベーション事業でお客さまとの協創を加速
注力４事業分野

電力・エネルギー

産業・流通・水

アーバン

金融・公共
ヘルスケア
© Hitachi, Ltd. 2017. All rights reserved.

6

1-4. IoTプラットフォーム Lumada
お客さまが保有する多様なアセットから生成されるデジタルデータを収集、人工知能等の最新デジタル技術により経営課題の解決を支援する
フレキシブルインテリジェント

OTアセットマシンデータ

コンポーザブルITアセットIoTプラットフォーム Lumada
Edge

Analytics

Studio

機械学習

視覚化

人工知能

API

データ収集

ヒューマンデータ

ビジネスデータCore

デバイス制御アセット情報エッジ
アナリティクス

セキュア

アセットアバターオブジェクトストア(データレイク)

Foundry© Hitachi, Ltd. 2017. All rights reserved.

7

2. PostgreSQLとIoT© Hitachi, Ltd. 2017. All rights reserved.

8

2-1. 概要
 概要
センサーデータ等のIoTデータは、多種多様(Variety)、 かつ大量データ(Volume)が高頻度(Velocity)の「3つのV」で発生するため、RDBではな
くhadoopなどに蓄積されていることが多く、そこから新たな価値が創出されている。
最近では、さらに既存業務システムのデータとIoTデータを組み合わせて新たな価値を創出したいという需要がある。
しかし、企業内のシステムの多くが、目的ごとに独立してシステム設計・構築を行った結果、「他システムのデータを活用するのにコストや手間がかかる」という課題があり、連携するための施策を検討する必要がある。
そこで、この章では、既存システム（RDBはPostgreSQL前提）とhadoopなどIoTシステムとの連携・融合について検証結果を報告する。

© Hitachi, Ltd. 2017. All rights reserved.

92-2. 現行システム
 システムイメージ
今あるシステムは、目的別に独立して構築(サイロ化)されているため、
以下のように分断されていることが多いと思われる。

IoTシステム

業務システムセンサー

HDFS
クライアント

分断
見える化
（簡易版）

分析サーバ

PostgreSQL
業務サーバ

HDFSクラスタ© Hitachi, Ltd. 2017. All rights reserved.

102-3. 手段について
 連携方法業務システムとIoTシステムとの連携する上で、IoTデータの活用方法には以下の方法が考えられる。

既存のまま
連携

各々データに
アクセス

連携型

FDW

システム連携IoTデータをどう扱うか？

FDWで移行
PostgreSQL
へ移行

手動で移行

統合型

ETLツールで移行© Hitachi, Ltd. 2017. All rights reserved.

112-4. FDW FDWについてFDW（Foreign Data Wrapper：外部データラッパー）とは、SQL/MEDの仕様を実装した、外部データにアクセスする仕組み。
PostgreSQLから、他のSQLデータベースやフラットファイルなど様々な
リモートデータストアにアクセスを可能にするFDWが準備されている。
DataStore

FDW

Owner

PostgreSQL

postgres_fdw

PGDG

Oracleoracle_fdw

laurenz

MySQL

mysql_fdw

EnterpriseDB

Hadooppg-file-fdw-gds

wat4doghadoop_fdw

openscg

hdfs_fdw

EnterpriseDB

hive-fdw-for-postgresql

youngwookim

orc_fdw

gokhankici

出展元：
https://wiki.postgresql.org/wiki/Foreign_data_wrappers© Hitachi, Ltd. 2017. All rights reserved.

122-4. FDW FDWについて
FDWの種類は様々あるが･･･、※ FDWのほとんどは、PGDG（PostgreSQLグローバル開発グループ）
による正式サポートがされていないため、使用するに当たって注意する必要がある（オンラインマニュアルを参照）。
弊社は、EnterpriseDB社とパートナー契約を結んでおり、EnterpriseDB社が開発しているFDWを使うことでサポート等の連携が可能。
DataStore
FDW
Owner
Hadooppg-file-fdw-gds

wat4doghadoop_fdw

openscg

hdfs_fdw

EnterpriseDB

hive-fdw-for-postgresql

youngwookim

orc_fdw

gokhankici⇒本講演のFDWは、hdfs_fdwを使った評価結果を報告する。
出展元：
https://wiki.postgresql.org/wiki/Foreign_data_wrappers© Hitachi, Ltd. 2017. All rights reserved.

132-5. 評価の全体像 評価
評価１：既存のまま連携する場合の各アクセス方式を評価
評価２：PostgreSQLに統合する場合の移行方式を評価

既存のまま
連携

各々データに
アクセス

連携型

FDW

システム連携IoTデータをどう扱うか？

FDWで移行
PostgreSQL
へ移行

手動で移行

統合型

ETLツールで移行© Hitachi, Ltd. 2017. All rights reserved.

14

2-6. 評価環境
 物理構成PostgreSQLサーバ
兼、Hiveサーバ

PostgreSQLサーバ
兼、Hiveサーバ(物理マシン)

1台

CPU

Xeon E5-2470 2.3GHz x 1（8 コア、HT有効）

メモリ

128 GB

ディスク

7.2TB（900GB x 8台）

1Gbps LAN

10Gbps LAN
10Gbps SW

Hiveメタストア

10Gbps LAN

1ノード

HDFSクラスタ 3台(物理マシン)

disk

disk

・・・

disk

3ノード合計

CPU

Xeon E5-2470
48 コア
2.3GHz x 1(8コア、HT有効)

メモリ

128 GB

384 GBディスク

7.2 TB(900GB x 8台)

21.6 TB© Hitachi, Ltd. 2017. All rights reserved.

15

2-6. 評価環境
 論理構成managerCloudera Manager
Hadoopsensor sensor
data
data
Hive
HDFS

PostgreSQL

Hive
MetaStore

sensordata
HiveServer2

バッチPG
JDBC

PostgreSQL
hdfs_fdw

ソフトウェア構成

ソフトウェア構成

RHEL 6.7 (x86_64)

RHEL 6.7 (x86_64)

CDH 5.11.1

PostgreSQL 10.0
hdfs_fdw 2.0.2© Hitachi, Ltd. 2017. All rights reserved.

16

2-7. 評価1の概要
 シナリオ
IoTデータの「見える化」サービスを行うためのバッチ処理作成。
今回は、具体的な例として、月初に前月分の工場内のセンサーデータ(IoT)を取得、時系列分析を行い、業務システムデータ(RDB)と組合せて「見える化」するための統計データ（見える化用データ）を作成する。

 評価観点下記２種類のプログラム（以下、バッチPG）を作成し、以下の内容で比較評価する。
・バッチPGでPostgreSQLとhadoopにアクセスし、PG内で連携する・バッチPGはPostgreSQLにアクセスし、FDWでHadoopに連携する

 評価内容①コスト（設計、開発、構築、テスト、運用・保守等）面や業務変化対応の比較評価②性能面の比較評価© Hitachi, Ltd. 2017. All rights reserved.

172-7. 連携後のシステム
 アプリケーションで連携
アプリケーションで連携する場合のイメージを以下に示す。
（オレンジの部分が評価対象）

IoTシステム

業務システムセンサー

HDFS
クライアント

見える化用
データ

見える化
（詳細版）

バッチ
PG

分析サーバ

Hiveテーブル

PostgreSQL
既存フロー

業務サーバ

HDFSクラスタ

連携フロー
（追加）

© Hitachi, Ltd. 2017. All rights reserved.

18

2-7. 連携後のシステム
 FDWで連携
FDWで連携する場合のイメージを以下に示す。
（オレンジの部分が評価対象）

IoTシステム

業務システムセンサー

HDFS
クライアント

見える化用
データ

見える化
（詳細版）

バッチ
PG

FDW

分析サーバ

Hiveテーブル

PostgreSQL
既存フロー

業務サーバ

HDFSクラスタ

連携フロー
（追加）

© Hitachi, Ltd. 2017. All rights reserved.

192-7. 評価イメージ
 処理概要PostgreSQLHDFSクラスタ(Hiveテーブル)

meter_dataテーブル(センサーデータ)

metersテーブル(対応データ)factoryテーブル(工場データ)ColumnType

ColumnTypefact_idint

fact_idint

meter_id

int

type

char

Column

Type

pref

char

meter_id

int

city

char

date_time

timestamp

weightdoubleusage

doubleyear

smallintmonthsmallintday

smallint

Supportテーブル(「見える化」データ)

データ生成

ColumnTypefact_idint

meter_idint[データ量]
10万センサ
month
int
1分毎送信
is_holiday
boolean←テストを実施した結果、メモリ肥大化により、1年間分蓄積合計：525.6億件
hourint
OOM-Killer発生！全てPostgreSQLで処理するのは現実的ではない

usagesdouble© Hitachi, Ltd. 2017. All rights reserved.

20

2-8. 評価1改の概要
 シナリオ
IoTデータの「見える化」サービスを行うためのバッチ処理作成。
今回は、具体的な例として、月初に前月分の工場内のセンサーデータ(IoT)を取得、時系列分析を行い、業務システムデータ(RDB)と組合せて「見える化」するための統計データ（見える化用データ）を作成する。

 評価観点①Hadoop側で時系列分析を行ったデータを生成し、下記２種類のプログ
ラム（以下、バッチPG）を作成し、以下の内容で比較評価する。
・バッチPGでPostgreSQLとhadoopにアクセスし、PG内で連携する・バッチPGはPostgreSQLにアクセスし、FDWでHadoopに連携する②Hadoop側で時系列分析を行ったデータを出力し、PostgreSQLにロードした上で、バッチPG内で連携する

 評価内容①コスト（設計、開発、構築、テスト、運用・保守等）面や業務変化対応の比較評価
21© Hitachi, Ltd. 2017. All rights reserved.
②性能面の比較評価（分析データの1か月分）

2-8. 連携後のシステム
 アプリケーションで連携
分析データをHadoop側で作成し、アプリケーションで連携する場合のイメージを以下に示す。（オレンジの部分が評価対象）

IoTシステム

業務システムセンサー

HDFS
クライアント

見える化用
データ

見える化
（詳細版）

分析サーバ

Hiveテーブルバッチ
PG

PostgreSQL

Hiveテーブル（分析結果）
既存フロー

業務サーバ

HDFSクラスタ

連携フロー
（追加）

© Hitachi, Ltd. 2017. All rights reserved.

22

2-8. 連携後のシステム
 FDWで連携
分析データをHadoop側で作成し、 FDWで連携する場合のイメージを以下に示す。（オレンジの部分が評価対象）

IoTシステム

業務システムセンサー

HDFS
クライアント

見える化用
データ

見える化
（詳細版）

分析サーバ

Hiveテーブル

バッチ
PG

FDW

PostgreSQL

Hiveテーブル（分析結果）
既存フロー

業務サーバ

HDFSクラスタ

連携フロー
（追加）

© Hitachi, Ltd. 2017. All rights reserved.

23

2-8. 連携後のシステム
 PostgreSQLにロードして連携
Hadoop側で作成した分析データをファイル出力し、PostgreSQLにロード、PostgreSQLで連携する場合のイメージを以下に示す。（オレンジの部分が評価対象）

IoTシステム

業務システムセンサー

HDFS
クライアント

見える化用
データ

見える化
（詳細版）

分析サーバ

Hiveテーブルバッチ
PG

PostgreSQL

業務サーバ

Hiveテーブル（分析結果）
ファイル

既存フロー

HDFSクラスタ

連携フロー
（追加）

© Hitachi, Ltd. 2017. All rights reserved.

24

2-8. 評価イメージ
 処理概要PostgreSQLHDFSクラスタ(Hiveテーブル)
meter_dataテーブル

metersテーブル(対応データ)factoryテーブル(工場データ)ColumnType

ColumnTypefact_idint

fact_idint

meter_id

int

type

char

pref

char

ColumnTypemeter_id

int

date_time

timestamp

usage

double

city

char

year

smallint

weightdoublemonthsmallintday

smallint

meter_analyzeテーブル（集計結果テーブル）
ColumnTypemeter_id

int

month

int

is_holiday

boolean

hour

int

usage

double

データ生成

Supportテーブル(「見える化」データ)
ColumnTypefact_idint

meter_id

int

month

int

is_holiday

booleanhour

intusagesdouble© Hitachi, Ltd. 2017. All rights reserved.

25

2-8. 評価設計

 PostgreSQLパラメータ
PostgreSQLが運用中であることを想定したパラメータにしている。
パラメータ

値

目的

shared_buffers

8GB

DBリソースにあわせる

maintenance_work_mem

2GB

VACUUMの高速化

wal_level

replica

運用中を想定checkpoint_timeout

30min

運用中を想定checkpoint_completion_target

0.9

CHECKPOINT処理の平準化

archive_mode

on

運用中を想定max_wal_senders

2

HA構成を想定

hot_standbyon

運用中を想定effective_cache_size

16GB

DBリソースにあわせる

logging_collector

on

ログ出力

autovacuumon

運用中を想定hdfs_fdw.jvmpath（環境依存のため省略）

hdfs_fdwの設定

hdfs_fdw.classpath（環境依存のため省略）© Hitachi, Ltd. 2017. All rights reserved.

26

2-8. 評価結果①
まず初めに、気になる設計・開発、運用・保守におけるコスト面、業務変化への対応の難易度について、机上評価を行った。
方式
フェーズ

アプリ連携

FDW連携

設計・開発

• やりたいことを細かいレベルで実現 • 開発コストが少ない
しやすい• FDWを使うに当たっての選定や構• 開発コスト、テストコストが大きく
築コストがかかるなる（アプリで連携やSQLでできるような結合処理の実装が必要）

運用・保守• 障害発生時の切り分けが容易、内部 • 活発なコミュニティであれば品質だけで対応可能向上が図れる• RDBやhadoopの接続はトラブルに • 障害時の切り分けコストが大きい
陥りやすく、保守改修コストが大き（DBAとの連携が必要）
い

要件追加・変更• 柔軟な対応ができる• 容易に対応できる（SQLの修正の• 小さな変更レベルでもアプリの改修
み...等）
が必要となるため、コストがかかる • FDWとしての制約がある（例、
HadoopアクセスにはHiveが必要）© Hitachi, Ltd. 2017. All rights reserved.

27

2-8. 評価結果①
バッチPGの処理概要から、IoT分析データ取得部分のコストを比較する。

 FDW連携のバッチPG処理概要
PostgreSQL接続
IoT分析データ取得(FDW)
業務データ取得
格納

pstmt = con.prepareStatement(“select b.fact_id, a.meter_id,a.month, a.is_holiday, a.hour, a.usage frommeter_data_custom a, meters b where ((a.meter_id= b.id) and (a.year_month = ?))");
pstmt.setInt(1, year_month);res = pstmt.executeQuery();
while (res.next()) {// 1件ずつ取得}

PostgreSQL切断© Hitachi, Ltd. 2017. All rights reserved.

28

2-8. 評価結果①
バッチPGの処理概要から、IoT分析データ取得部分のコストを比較する。

 アプリ連携のバッチPG処理概要
Hive接続IoT分析データ取得
Hive切断業務データ取得
結合・演算処理格納･･･

PostgreSQL接続

Class.forName(driverHive);
Connection con = null;
con = DriverManager.getConnection(urlHive, userHive,passwordHive);
pstmt = con.prepareStatement("select * frommeter_data_avg_2017 where year_month = ?");
pstmt.setInt(1, year_month);res = pstmt.executeQuery();
while (res.next()) {// 1件ずつ取得}･･

for (MeterObject meter:meterMap){
pstmt.setInt(1, meter_fact_map.get(meter.getMeter_id()));
pstmt.setInt(2, meter.getMeter_id());
pstmt.setInt(3, meter.getYear_month());
pstmt.setBoolean(4, meter.getIs_holiday());
pstmt.setInt(5, meter.getHour());
pstmt.setDouble(6, meter.getUsage());
pstmt.addBatch();}PostgreSQL切断

アプリ連携では、接続処理やSQLレベルの結合演算処理も独自で開発する必要があり、複雑さの高い業務システムではコストが高い。
運用・保守においても継続メンテが必要。© Hitachi, Ltd. 2017. All rights reserved. 29

2-8. 評価結果②
次に、性能面の比較評価を行った。

 性能面の比較評価①アプリケーション実行時間の比較評価
アプリケーションで連携
FDWで連携PostgreSQLにロードして連携

0

Hadoop側の処理

Hive読込み

FDW読込み500

Postgresロード

Postgres読込み

1000

(sec)

データ作成

連携方式による顕著な差異は見られなかったので、性能以外の面に着目すると良い。
※hadoop, PostgreSQLのキャッシュは初期起動時に削除© Hitachi, Ltd. 2017. All rights reserved.

30

2-8. 評価結果②
 性能面の比較評価②システムへの影響の比較評価
 FDW連携

IoTデータ取得

80
70
60
50
40
30
20
10
0
21:37:04

21:38:04

21:39:04

21:40:04

 アプリ連携 IoTデータ取得
70

60
50
40
30
20
10

21:48:26

21:42:04

CPU利用率FDW連携時はCPU資料率が高騰す
る頻度が高かった。マスターデータ
は業務DBにあり、業務に影響が出る可能性があるため、事前の負荷検証は必ず必要と考える。負荷状況によってはCPU増設等ハード強化も検
討要。

80

0
21:47:26

21:41:04

21:49:26

21:50:26※hadoop, PostgreSQLのキャッシュは初期起動時に削除※なお、メモリの利用率については
連携方式による差がなかったため、表記は省く。
© Hitachi, Ltd. 2017. All rights reserved.

31

2-8. 評価結果②
 性能面の比較評価③hdfs_fdwのクエリプランの評価

 PostgreSQL

hdfsfdw=# explain analyze select count(*) from meter_data_custom where year_month ='201701';
QUERY PLAN-----------------------------------------------------------------------------------------Aggregate (cost=1100002.50..1100002.51 rows=1 width=8) (actual
time=39792.123..39792.124
rows=1 loops=1)-> Foreign Scan on meter_data_custom (cost=100000.00..1100000.00 rows=1000
width=0) (actual time=306.846..38433.607 rows=4800000 loops=1)
Planning time: 112.417 ms
Execution time: 40187.927 ms(4 rows)

 Hiveログ

Compiling command(queryId=hive_id): SELECT * FROM default.meter_data_avg_2017
WHERE ((year_month = '201701'))
Executing command(queryId=hive_id): SELECT * FROM default.meter_data_avg_2017
WHERE ((year_month = '201701'))
ORC pushdown predicate: leaf-0 = (EQUALS year_month 201701)
Reading ORC rows from
hdfs://pgmaster:8020/user/hive/warehouse/meter_data_avg_2017/year_month=201701/
000000_0 with {include: [true, true, true, true, true], offset: 0, length:9223372036854775807, sarg: leaf-0 = (EQUALS year_month 201701)
expr = leaf-0, columns: ['null', 'meter_id', 'is_holiday', 'hour', 'usage']}→ Hadoop側での分析データは月単位で作成しているが、対象ファイルのみアクセス© Hitachi, Ltd. 2017. All rights reserved.
(pushdown)することでI/O削減による高速化ができていることがわかる。

32

2-9. 評価2の概要
 シナリオ
次に、hadoopに格納されているIoTデータをPostgreSQLに統合する場合のデータ移行を検討する。
今回は、各システムの業務特性が異なることからデータベースクラスタを新たに作成し、IoTデータは月ごとのパーティショニング構成を想定して、1か月分を子テーブルにデータを挿入した。

 評価観点下記3つの方法で、移行の比較評価をする。
① FDWを使ってIoTデータをhadoopからPostgreSQLに移行する(1) SQL(INSERT-SELECT文)で直接移行する方法 ･･･(a)(2) SQL(COPY文)で一度ファイルに出力し、そのファイルを使って移行する方法 ･･･(b)② hadoopからIoTデータをファイルで出力し、PostgreSQLに移行する（以降、「手動で移行」と略します。） ･･･(c) 評価内容各評価観点の1か月分のデータの移行時間を評価する© Hitachi, Ltd. 2017. All rights reserved.

33

2-9. 移行後のシステム
 FDWで移行
FDWで移行した場合のイメージを以下に示す。（赤の部分が評価対象）

業務システムIoTシステム
センサー

見える化
（詳細版）

HDFS
クライアント

分析サーバ

PostgreSQL

業務サーバ

FDW

IoT用DB

HDFSクラスタ

既存フロー
連携フロー
（追加）

© Hitachi, Ltd. 2017. All rights reserved.

34

2-9. 移行後のシステム
 手動で移行
手動で移行した場合のイメージを以下に示す。（赤の部分が評価対象）

業務システムIoTシステム
センサー

見える化
（詳細版）

HDFS
クライアント

分析サーバ

PostgreSQL

業務サーバ
importHDFSクラスタ

IoT用DB

export
移行

既存フロー
連携フロー
（追加）

© Hitachi, Ltd. 2017. All rights reserved.

35

2-9. 評価設計
 PostgreSQLパラメータ
新しくPostgreSQLを立てるため、データ移行に適した設定にした。
パラメータ

値

目的

shared_buffers

8GB

DBリソースにあわせる

maintenance_work_mem

2GB

VACUUMの高速化

wal_levelminimal

WAL書込みを極力減らす

synchronous_commit

off

高速化（失敗すれば再実行すればよい）

checkpoint_timeout

1d

CHECKPOINT実行抑止

max_wal_size

200GB

CHECKPOINT実行抑止

checkpoint_completion_target

0.9

CHECKPOINT処理の平準化

archive_mode

off

移行のためアーカイブ不要

effective_cache_size

16GB

DBリソースにあわせる

logging_collector

on

ログ出力

autovacuumoff

移行中のVACUUM実行を防ぐ

hdfs_fdw.jvmpath（環境依存のため省略）

hdfs_fdwの設定

hdfs_fdw.classpath（環境依存のため省略）© Hitachi, Ltd. 2017. All rights reserved.

36

2-9. 評価イメージ
 処理概要HDFSクラスタ(hiveテーブル)

metersテーブル(対応データ)meter_dataテーブル(センサーデータ)

PostgreSQL
factoryテーブル(工場データ)ColumnType

ColumnTypefact_idint

fact_idint

meter_id

int

type

char

Column

Type

pref

char

meter_id

int

city

char

date_time

timestamp

weightdoubleusage

doubleyear

smallintmonthsmallintday

smallint[データ量]
10万センサ
1分毎送信
1年間分蓄積合計：525.6億件

データ移行

PostgreSQL

meter_dataテーブル(センサーデータ)
ColumnTypemeter_id

int

date_time

timestamp

usage

double© Hitachi, Ltd. 2017. All rights reserved.

37

2-9. 評価結果
1か月分のデータを移行する場合のFDWを使った移行と、全て手動での移行との移行時間の比較評価を行った。

 移行時間の比較評価
FDWで移行(INSERT-SELECT)OOM-Killer発動→メモリに格納できるサイズに変更して再度評価する
FDWで移行(COPY)･･･(a)･･･(b)

手動で移行･･･(c)

0
データ出力

1000

2000

3000

4000

データ入力
(min)

※hadoop, PostgreSQLのキャッシュは初期起動時に削除© Hitachi, Ltd. 2017. All rights reserved.

38

2-9. 評価結果
1か月分のデータを移行する場合のFDWを使った移行と、全て手動での移行との移行時間の比較評価を行った。

 移行時間の比較評価
FDWで移行(INSERT-SELECT)･･･(a)

FDWで移行(COPY)･･･(b)

手動で移行･･･(c)

圧倒的に高速
0

3000

4000

(a),(b)は1日分ごとに移行を行なうSQLを1か月分処理した総計

(min)

データ出力

1000

2000

データ入力

※hadoop, PostgreSQLのキャッシュは初期起動時に削除© Hitachi, Ltd. 2017. All rights reserved.

39

2-10. まとめ

IoT時代において、データから価値創出するにあたりシス
テム連携は必須であり、連携を実現するFDWは他の方法に比べて遜色なく有効であると感じた。

今回の検証でわかったように、何でもFDWに頼るのではなく、様々なコストに応じた対応を検討すべきである。
大量データ分析はHadoop側で行い、データ量を減らす。
移行は、既存の方法（手動で移行）のほうがコストが小さい。

© Hitachi, Ltd. 2017. All rights reserved.

40

3. 某DBからPostgreSQLへの移行事例～TWX-21における移行事例～© Hitachi, Ltd. 2017. All rights reserved.

41

3-1. 自己紹介
傳法谷 智 （でんぽうや さとし）
・現職
株式会社日立製作所
IoT・クラウドサービス事業部
アプリケーション第２部 統括主任技師
・職歴
1993 年株式会社日立製作所入社。
分散トランザクションマネージャ「uCosminexus OpenTP1」の開発に従事。
1996 年から業務システムクラウドサービス「TWX-21」の開発及び運用業務を担当している。

© Hitachi, Ltd. 2017. All rights reserved.

42

3-2. TWX-21とは・企業向けの業務システムをＳａａＳ型で提供
・TWX-21会員約64,000社、約30カ国・地域、約31万ID

業務システムクラウド
国内最大規模
ご利用
企業

お得意先

TWX-21

サプライヤー

設計･生産
委託先

販売会社

保守会社

業務アプリケーション
品質・設計系

SCM系

購買系
MRO集中購買見積評価
TWX-21 （リバースオークション）
提供ｻｰﾋﾞｽ
サプライヤー情報共有

EDI、Web-EDI（購買･物流機能）

大容量データ交換

需給調整

販売・保守系

Salesforce.com

カスタマイザブルデータ交換

PSI見える化

GXS

クラウド型購買ｼｽﾃﾑ
生産計画

プロジェクト管理（SCPLAN）（OnSchedule on TWX-21）

倉庫管理（WMS）

ONEsLOGI on TWX-21

機器ライフサイクル支援（Global e-Service onTWX-21）･･･

ﾊﾟｰﾄﾅｰ
ｻｰﾋﾞｽ

活文MIE

画面表示制御・アクセス制御・データ形式・データチェック・言語対応など（順次拡大）

SaaSビジネス基盤（ﾕｰｻﾞ管理、ｱﾌﾟﾘｹｰｼｮﾝ運用ﾅﾋﾞ、課金管理、BPO）
クラウド基盤
MRO：Maintenance, Repair and Operations PSI：Production Sales Inventory
WMS：Warehouse Management System BPO：Business Process Outsourcing SCM：Supply Chain Management© Hitachi, Ltd. 2017. All rights reserved.

43

3-3. TWX-21のグローバル展開
海外での主な利用地域
China：North-East Area
China：North Area
China：South Area
EuropeGermany
India
Franceグローバル
Belgium ヘルプデスク
SwissThailand
Netherlands
Malaysia
Spain, et al
Singapore

中国
TWX-21センター

Korea

日本
ヘルプデスクTaiwan Area

CanadaAmerica:West Coast
America:Inland Area
America:East
Coast

日本
TWX-21センター

China：
Central Area

MexicoPhilippines
Vietnam
Australia

Indonesia

データセンターヘルプデスク対応言語

現地契約可能な国

日本・中国

日本語・英語・中国語・
タイ語・インドネシア語・マレーシア語

日本、中国、タイ、
インドネシア© Hitachi, Ltd. 2017. All rights reserved.

44

3-4. プロジェクト概要●サプライヤーが利用する形態に合わせて、TWX-21が伝送方式を変換することで
EDIサービス
バイヤー側のEDIを実現、建設業法の取引を含めてペーパーレス化を推進●注文書などの伝票データとともに、図面や仕様書などのデータも交換できるため業務効率が向上
●EDIシステムの管理コスト・運用負担を軽減でき、IT部門の要員を自社のコア業務にシフト可能
TWX-21センター

バイヤー

サプライヤー

Web-EDI参照

設計部門

基幹システム

コ
マ
ン
ド

I/F

イ
ン
タ
ー
ネ
ッ
ト

Web-EDIEDIファイル連携(各種フォーマット)

ファイル転送 EDI

購買・調達部門・販売終了製品のOS/ミドルウェア
バージョンアップ対応不可
・機能エンハンス不可・保守体制維持困難

FAX-EDI

営業部門

FAX送信
出荷部門

アーキテクチャ含め

リニューアルを実施することにした。
© Hitachi, Ltd. 2017. All rights reserved.

45

3-5. DBの選定
DBを選定するに当たり、8項目を得点制で比較検討実施。

重点比較項目

評価
結果

比較項目

A B C D E F

G H

区分

コスト

製品A
2
製品B
3
製品C
4 PostgreSQL
1

イベント制
御DBと業
サポート
務DBを分
離

重点比較評
価点小計

性能

信頼性/
拡張性

永続性

保守性

制限事項

評価点計

評価点
合計

27

16

-15

18

14

18

78

14

10

24

102

12

12

0

20

20

20

84

20

12

32

116

32

12

0

12

12

12

80

20

4

24

104

40

20

0

12

12

12

96

20

4

24

120

順
位
4
2
3
1

• PostgreSQLはコスト、サポート(弊社サポート部門)、実績、コミュニ
ティ等で高得点• 製品Aは、保守が困難。
• 製品Bは、仮想化上でのライセンスの懸案があり、極端なコスト増のため不可。
• 製品Cは、サポート、信頼性が低い。
• 他OSSでも実績多いものあるが、製品Bのベンダが所有していることから、将来性を鑑みて対象外とした。

© Hitachi, Ltd. 2017. All rights reserved.

46

3-6. 信頼性確保について
現行システム・・・クラスタソフトと共有Diskにより信頼性を確保
仮想IPアドレスDBサーバ１
クラスタソフト
ActiveHeartBeat

DBMS

DBサーバ２※サーバダウン、DBMSダウン
した際クラスタソフトにより、
HotStandbyで切替可能

クラスタソフトDBMSStandby

一般的なクラウド環境では、共有Diskは利用不可
共有Disk現行システムから信頼性を落とさない方式検討が課題© Hitachi, Ltd. 2017. All rights reserved.

47

3-6. 信頼性確保について
新システム

・・・pgpool-Ⅱ(OSS)とストリーミングレプリケーションにより信頼性を確保
仮想IPアドレスpgpool-Ⅱサーバ１

PostgreSQL管理

HeartBeat

pgpool-Ⅱサーバ２••

PostgreSQL管理•

ActiveStandbyPostgreSQLサーバ１

PostgreSQLサーバ２•

レプリケーション

Activemaster
更新可

•

slave
更新不可
参照のみ可

Active••

複数のPostgreSQLを管理
master/slave環境で更新系
SQLはmasterにのみ振分
masterダウン時にはslave側
をmasterへ昇格させる

レプリケーション機能により、同一データを２台で保持
masterは更新可、slaveは参照のみ
masterダウン時のデータ欠
損ないように、同期レプリ
ケーションを選択
同期レプリケーションは性能検証が必要© Hitachi, Ltd. 2017. All rights reserved.

48

3-7. 課題・懸案対応

インシデントへの対応事例■slave側への参照クエリーで検索できないことがある①現象
masterに対して更新されたレコードを、その直後にslave側で参照した場合に、対象のレコードが検索できない場合がある。
②調査方法、調査結果
master、slaveのPostgreSQLのログより、対象のレコードが正しく検索できる場合とできない場合を整理し、正しく検索できない場合はslave側で参照クエリーが処理されていた。
同期モード時の負荷分散の仕様を再確認した結果、更新のクエリーはslaveへ送信されたWALが同期した時点でコミットが返る仕様であり（PostgreSQL 9.6 ではエンハンスされている）、
slave側のテーブルに該当のレコードが書込まれた後ではなかった。
③対策
クライアントが発行するSELECT文の前に/*NO LOAD BALANCE*/コメントを付与することでクエリー毎に負荷分散しないまたは、するを宣言することができるがクライアントプログラムへの改修
範囲が大きくなる。このためクライアントプログラム毎（サーバのJDBC/ODBCのドライバー単位）に識別できる特定の名称(アプリケーション名)を付与し、この名称毎に参照クエリーを負荷分散するまたは、しないかを区別する対策とした。
これにより、更新した後にすぐに参照が発行されるようなケースにおいても正しい結果が得られるようになった。

© Hitachi, Ltd. 2017. All rights reserved.

49

3-7. 課題・懸案対応
仮想IPアドレスpgpool-Ⅱサーバ１

HeartBeat

PostgreSQLサーバ１

pgpool-Ⅱサーバ２

PostgreSQLサーバ２⑤ startup

①
メモリ

WAL
②

ディスク

WAL

master Active

③

共有
ﾊﾞｯﾌｧ

WAL
メモリ

⑤startupプロセスは非同期に処理するため、テーブル参照時には更新されていな
かった。

④
ディスク

WAL

同期モードでもコミット時にここまでしか同期されない。

slave Active※9.6ではエンハンスされており、問題は発生しない。

© Hitachi, Ltd. 2017. All rights reserved.

50

3-7. 課題・懸案対応
現象

原因

対策

1 検索結果が不特定に不正になる JDBCにてPreparedStatement
JDBCにprepareThreshold=0をキャッシュが行われており、SQL 設定した。
が実行されなかったため。
2 検索結果が不特定に不正になる ODBCの設定で、カーソルを利用 ODBCの設定で、Declare-Fetch
しないようになっていたため。
をONにする。
3 SQLがエラーになる場合がある autovacuum中にslave側に対して master側を検索するようにした。
検索したため。
4 検索が遅い時がある。

テーブルの状態によって、シーケ set enable_seqscan = off;を追ンススキャンされる場合があるた 加した。
め。

5 SQLが接続エラーになる場合が コネクションプールを利用時に、 切断のタイムアウト値を見直しある。
FWで無通信タイムアウトにより、 た。
切断してしまっていたため。
：

：

：

：

インターネットで調査
弊社サポート部門と協力して調査・対策© Hitachi, Ltd. 2017. All rights reserved.

51

3-8. まとめ

高信頼性のシステムを構築できた。

実績が豊富のため、インターネットで検索可能。
弊社サポート部門の協力により、5月本番稼働からトラブルなし。

© Hitachi, Ltd. 2017. All rights reserved.

52

4. 弊社サービス紹介© Hitachi, Ltd. 2017. All rights reserved.

53

4-1. カスタマイザブルデータ交換サービス
ビジネスパートナーとの多様なデータ交換を国・業界にかかわらず容易に実現し、ビジネスの可能性を拡張

A社FMT

C社FMT

発注者A

ﾃﾞｰﾀ通信

ﾃﾞｰﾀ変換効果①従来業務方式に合わせてカスタマイズ可能

B社FMT

受注者C
(A社取引先)

D社
海外標準
FMT
B社
カスタマイズ(海外)発注者D
A社新規取引先業界標準規格テンプレート

新規発注者B

効果②他業界・海外取引先を意識することなくデータ交換可能

効果③データ交換業務の可視化とリカバリ機能により運用工数軽減

効果④取引先からの問合せは、
ヘルプデスクで一元的に受付・管理煩雑なシステム運用を代行

ヘルプデスクWebモニター
サービス導入による効果
１．お客さまが管理する資産を増やさずにデータ交換が実現可能

２．お客さまの業務内容に合わせてスピーディーな導入を実現
３．Webモニターやヘルプデスクにより運用・保守工数を軽減© Hitachi, Ltd. 2017. All rights reserved.

54

4-2. 日立のEDB Postgresサポートサービス
 日立が提供するEDB Postgresサポートサービスの特長
 日立サポート360によるワンストップサポート
 日立およびEnterprise DB社の技術者の連携による問合せ対応
日立サポート360ご利用のメリット
日立の総合力によりシステム一体のサポートを提供します。障害発生時もお客さまは問題を切り分けることなくお問い合わせいただけます。
また、原因究明が難しい問題も各製品技術者、導入元ベンダとの連携により、多角的に問題解決にあたります。

お客様
障害
発生

お客様での
切り分け不要EnterpriseDB社

日立
各製品担当技術者間で連携

お問合せ
サーバ

連携

早期解決！
ストレージ

迅速回答

ミドルウェアOSSLinux/Windows

http://www.hitachi.co.jp/Prod/comp/soft1/support360/

自社DB開発経験者が対応© Hitachi, Ltd. 2017. All rights reserved.

55

4-2. 日立のEDB Postgresプロフェッショナルサービス
安定稼働の実現を支援する、システムの設計から運用フェーズまでをサポートするサービスです。
技術支援

概要

コンサルティング

お客さまの困りごとに対して、コンサルティング支援を行います。
下記の支援内容以外にも、例えば、テストや本番運用時に性能が出ない際の問題解決のためのノウハウ提供や支援を行います。

設計・構築支援要件に応じた構築を行うために、構成検討やインストール設計、
パラメタ設計、運用設計などのノウハウ支援、問題解決、作業支援を行います。また、立ち会いによる構築支援を行います。

クラスタ構築支援

高可用性、高信頼性を確保しなければならない基幹システムには、クラスタソフトウェアと組み合わせた構成で設計・構築を支援します。

マイグレーション支援

他の商用データベースからEDB Postgresに移行する際の先行調査、影響範囲を見極め、マイグレーションを支援します。移行の際の留意点やノウハウを提供します。

製品トレーニング

製品を初めてご利用になる開発技術者に向けたサービスメニューです。
製品の概要説明や基本機能の使い方を習得できます。
© Hitachi, Ltd. 2017. All rights reserved.

56

4-3. 日立のサポート対象OSS※下記以外のOSSにつきましては、個別にご相談ください。
クラウド
ビッグデータビジネスルール
Web・
アプリケーションサー
バ

データベース
クラスタソフト※PostgreSQLとの組み
合わせのみ

ネットワークメール
ファイル同期運用管理
認証・セキュリティ
開発管理
開発言語・
フレームワーク

•
•
•
•
•
•
•

OpenStack
Cloudera Enterprise
Hadoop(コミュニティ版)
Spark(コミュニティ版)
Kafka(コミュニティ版)
JBoss BPM Suite
JBoss Enterprise Application
Platform
JBoss Web Server
JBoss Fuse
Apache HTTP Server
EDB Postgres
商用版MySQL
PostgreSQL
pgpool-II

•
•
•
•
•
•
•

BIND
Postfix
rsync
AnsibleOpenLDAP
Spring Security OAuth
Redmine• Samba• dovecot

Ruby on Rails
Apache Struts
jQueryjQuery UI
Log4j 2
Red Hat Enterprise Linux

•
•
•
•

•
•
•
•
•
•
•

•
•
•
ライブラリ・API••
OS・プラットフォーム •• Hive(コミュニティ版)• HBase(コミュニティ版)• ZooKeeper(コミュニティ版)
•
•
•
•
•
•
•
•
•
•

JBoss BRMS
Nginx
TomcatPHP
mod_jkNginx
MySQL
MongoDB
PostGISpacemaker• MIRACLE ZBX• OpenSSL

Spring Framework
JBoss Developer Studio
SLF4J
Logback• MIRACLE LINUX• Hadoop(Cloudera版)• Talend• Asakusa• Apache Commons Lang
• Apache Commons
Collection• Apache Commons IO• Apache Commons Net• JBoss Data Grid
• JBoss Data Virtualization• corosync• JBoss Operations Network• GnuPG• MyBatis• JasperReports Library• ApachePOI© Hitachi, Ltd. 2017. All rights reserved.

57

END
PostgreSQLを使って変化に強いシステムへ！

2017/12/04
株式会社 日立製作所
OSSソリューションセンタ

© Hitachi, Ltd. 2017. All rights reserved.

58

付録．他社商品名，商標等の引用に関する表示
・HITACHIは、株式会社 日立製作所の商標または登録商標です。
・PostgreSQLは、PostgreSQL Community Association of Canadaのカナダにおける登録商標およびその他の国における商標です。
・EnterpriseDBは、EnterpriseDB Corporationの登録商標です。 EDBおよびEDB Postgresは、EnterpriseDB Corporationの商標です。
・MySQLは，Oracle Corporation 及びその子会社，関連会社の米国及びその他の国における登録商標です。
・Linuxは，Linus Torvalds氏の日本およびその他の国における登録商標または商標です。
・Red Hatは，米国およびその他の国でRed Hat, Inc. の登録商標若しくは商標です。
・Apache は、Apache Software Foundation の米国およびその他の国における登録商標または商標です。
その他記載の会社名，製品名は，それぞれの会社の商標もしくは登録商標です。

© Hitachi, Ltd. 2017. All rights reserved.

59