BigDataを迎え撃つ！ PostgreSQL並列分散ミドルウェア「Stado」の紹介と検証報告

BigDataを迎え撃つ！
PostgreSQL並列分散ミドルウェア「Stado」の
紹介と検証報告

アップタイム・テクノロジーズ

永安悟史

2012/7/25

Copyright 2012 Uptime Technologies, LLC. All rights reserved.

自己紹介
• 永安悟史（ながやすさとし）

• 略歴
– 1997年よりインターネットベンチャーにてネットサービス開発・運用に従事。
– 2004年より（株）ＮＴＴデータにて、並列分散データベースの研究開発、技術支援・保守
サポート業務を経て、データセンタの新規サービス開発、運用チームの立ち上げ、
サービス運用などに従事。
– 2009年、アップタイム・テクノロジーズを創業。

• 専門分野
– データベースシステム、並列分散システム、クラスタシステム
– オープンソース・インフラ技術
– ＩＴサービスマネジメント（ITIL）、ITインフラ運用管理（運用設計～運用）

• アップタイム・テクノロジーズ＠本業
– オープンソース導入サポートサービス
– データベース・コンサルティング
– ＩＴサービスマネジメント・コンサルティング


アップタイム・テクノロジーズについて
• オープンソース導入サポートサービスの提供
– 各種OSS（ミドルウェア、ツールなど）についての調査・情報提供
– 設計（基盤～アプリ）、開発の支援
– 機能検証・性能見積もり支援（機能検証、性能検証）、試験設計支援
– OSSコミュニティエスカレーション、等

• セミナ、トレーニングの提供
– 「PostgreSQLパフォーマンスチューニング入門」（7/27）
– 「LifeKeeper for Linuxで構築・運用する高可用PostgreSQLシステム」

• コンテンツのオンライン販売
– PostgreSQLアーキテクチャ入門（自習用教材）
– OSDL DBT-3によるPostgreSQLの性能評価～SATA HDD＆SATA SSD編（技術検
証レポート）

詳細は http://www.uptime.jp をご覧ください。


アジェンダ
1. Stado概要

2. Stado導入方法

3. Stado検証結果
“stado” はポーランド語で「群れ」を意味しています


1. Stado概要


Stado

https://launchpad.net/stado

“Stado”とは何か?
• PostgreSQLで利用できるMPPミドルウェア
– MPP: Massive Parallel Processing、超並列処理

• GridSQLの後継であり、長い技術の蓄積
– ExtenDB（2003）、GridSQL@EnterpriseDB（2007）

• 「シェアードナッシング」方式の分散データアーキテクチャ
– コモディティサーバのパフォーマンスをレバレッジさせる。
– アプリケーションに対して単一のデータベースに見せる。

• 基本事項…
– オープンソース
– BI/DWHデータベース（Greenplum、NetezzaやTeradataのような）


“Stado”とは何か? (2)
• パラレルクエリを実行するための設計
– 伝統的なスタースキーマを対象とする

• 読み取りだけではなく、UPDATEやDELETEも実行可

• パラレルローディングのためのデータローダ
– バルクローディング

• PostgreSQL互換のコネクタを使って標準的な接続が可能
– JDBC, ODBC, ADO.NET, libpq(psql)


Stadoは何 “ではない” か？
• SlonyやBucardoのようなレプリケーションではない

• PostgreSQL 9.1の同期レプリケーションのような高可用の
ためのソリューションでもない

• Postgres-XCのようなスケーラブルなトランザクションソ
リューションでもない

• “Elastic” で “Eventually consistent” なNoSQLデータベース
でもない


アーキテクチャ
• 祖結合なシェアードナッシング Applications
アーキテクチャ

• Stadoプロセス
– 中央のコーディネータ Coordinator
– データノートのエージェント

• データレポジトリ
– メタデータデータベース Data Nodes
– Stado（ユーザ）データベース

ETL


構成
• 単一の物理サーバに対して、複数の論理ノードを設定可能
– マルチコアプロセッサの性能を活用する

• テーブルは、レプリケーションか、パーティショニング
– パーティションテーブルは大規模なファクトテーブル
– 単一のファクトテーブルと複数のディメンションテーブル


パーティショニング
• StadoのパーティショニングとPostgreSQLのCE（Constraint
Exclusion）パーティショニングを同時に利用可能
– （CEの）サブテーブルを使うことによって、大規模なクエリはより小さ
なデータをスキャンする
– 各サブテーブルがノードをまたいで分割されているので、並列にス
キャンされる

• パーティションの種類
– Stadoはハッシュパーティションを提供
– CEはレンジパーティションを提供

• “Making things smaller, making things faster.”
– テーブルやインデックスを小さく保つことで高速化する


スタースキーマ
• ひとつのファクトテーブル（トランザクション情報）と、複数の
ディメンション（マスター）テーブルで構成されるスキーマ
customer part
orders
c_custkey p_partkey
o_orderkey
c_name p_name
c_address o_custkey p_mfgr
c_nationkey o_orderstatus lineitem p_brand
c_phone o_totalprice p_type
l_orderkey partsupp
c_acctbal o_orderdate p_size
o_orderpriority l_linenumber p_container ps_partkey
c_mktsegment
c_comment o_clerk l_partkey p_retailprice ps_suppkey
o_shippriority l_suppkey p_comment ps_availqty
nation o_comment l_quantity ps_supplycost
l_extendedprice ps_comment
n_nationkey supplier
l_discount
n_name l_tax s_suppkey
n_regionkey l_returnflag
n_comment l_linestatus s_name
l_shipdate s_address
l_commitdate s_nationkey
region
l_receiptdate s_phone
r_regionkey l_shipinstruct s_acctbal
l_shipmode s_comment
r_name
r_comment l_comment


テーブルの作成
• テーブルはレプリケーションかパーティショニングされる
– DDLで何も指定しないと、主キーで分割されるパーティションテーブ
ルになる


クエリオプティマイザ
• コストベースのオプティマイザ
– もっともコストが高いのがRow Shipping

• レプリケーションテーブルとのJOIN（結合）を探す
– レプリケーションテーブルとのJOINはノード内で処理可能
– パーティションキーを使ったJOINを探す
– 複数のテーブル（ordersとlineitemなど）を単一のパーティションキー
（orderkey）を使って分割すると、同じキーのレコードが同一パーティ
ションにあることが担保される
– 異なるキーで複数のテーブルをパーティションすると、JOIN時にRow
Shippingが発生する（サイズによっては非常に時間がかかる）


2段階の集約処理
• SUM
– SUM(stat1)
– SUM2(SUM(stat1))

• AVG
– SUM(stat1)/COUNT(stat1)
– SUM2(SUM(stat1))/SUM2(COUNT(stat1))


SQL上の制約
• 独自のパーサおよびオプティマイザを使用しているため
– ウィンドウ関数が使えない
– ストアドプロシージャが使えない
– 全文検索が使えない
– Geo-Spatialサポートが使えない


トランザクションパフォーマンス
• 行のINSERT、UPDATE、DELETEは、単体のPostgreSQL
と比較すると遅い
– データがネットワーク上を余分に行き来する必要があるため
– パーティションテーブルの行は、適切なノードに割り振るためにハッ
シュ化される必要がある
– レプリケーションテーブルの行はすべてのノードでコミットされる必要
がある

• パフォーマンスを上げるためには “gs-loader” を使ってバル
クロードする


高可用性
• ハートビートやフェイルオーバーの制御はコーディネータに
は無い
– 各PostgreSQLノードの高可用性は、それぞれ個別に設定される必
要がある
– この目的にストリーミングレプリケーションを利用可能

• Stadoデータベース全体の一貫性のあるバックアップの取得
は難しい
– トランザクションが実行されていないことを担保する必要がある
– 各ノードを個別にバックアップする必要がある


ノードの追加
• ダウンタイムが必要
– データは手動で新しいノードにリロードされる必要がある

• 設計によっては、データの再配置を排してより迅速にできる
– 最初に多数のパーティションに分割しておく
– 最初に複数のインスタンスを物理サーバで動作させておき、必要に
応じて新しいハードウェアに移動させる


2. Stado導入手順


前提条件
• Stadoは以下の環境で動作します
– PostgreSQL 9.1以降
– JDK 6以降

• リリース版ではなくリポジトリの最新版を使うことを推奨
– 現在、頻繁にバグfix等が行われているため


ドキュメント類
• Stadoに同梱されているドキュメント類
– Stado Administration Guide （対訳済み）
– Stado Import and Export Utilities （一部対訳済み）
– Stado Planning Guide
– Stado SQL Reference

上記の対訳版ドキュメントは以下のURLで公開しています。
http://www.uptime.jp/go/stado


導入手順
• ステップ１
– OSアカウントの作成、セットアップ
– ネットワーク関連のセットアップ
– OSのチューニング
– JDK、PostgreSQLのインストールとコンフィグ設定

• ステップ２
– Stadoのインストールとコンフィグ設定
– 各PostgreSQLノード管理ユーザ（stado）の作成
– Stado管理/接続ユーザの作成（admin）とメタデータベース作成
– コーディネータの起動
– エージェントの起動

• ステップ３
– ユーザデータベースの作成
– テーブルの作成
– データのロード

導入手順 – STEP2
• Stadoのインストールとコンフィグ設定
– コーディネータ設定：stado.config
– エージェント設定：stado_agent.config

• 各PostgreSQLノード管理ユーザ（stado）の作成
– createuserコマンド

• Stado管理/接続ユーザの作成（admin）とメタデータベース作成
– gs-createmdbコマンド

• コーディネータの起動
– gs-serverコマンド

• エージェントの起動
– gs-agentコマンド


stado.config
• 全ノードおよびコーディネータの設定を行う設定ファイル


stado_agent.config
• コーディネータへの接続とロギングの設定を行う設定ファイル


XDBSYSメタデータベース
• ノードやスキーマ、ユーザ情報等を保持するメタデータベース


導入手順 – STEP3
• ユーザデータベースの作成
– gs-createdbコマンド

• テーブルの作成
– psqlコマンド、またはgs-cmdlineコマンド

• データのロード
– psql、アプリケーション、またはgs-loaderコマンド


ユーザデータベース
• gs-createdbコマンドで作成し、gs-cmdlineコマンドで状態を参照
– 通常のクエリ実行はpsqlコマンドから実行可能


ユーザデータベース (2)
• 物理的なデータベースは “__(DB名)__N(パーティション番号)” という
データベース名で作成される


ユーザテーブル
• gs-cmdlineコマンドでパーティション情報を確認
– パーティションカラムがあるテーブルはパーティションテーブル


データローディング
• gs-loaderコマンドを使って、フラットファイル（CSV、タブ区切りなど）から
パラレルロードする


実行プランの取得
• EXPLAINコマンドで取得可能
– 出力は通常のPostgreSQLのものと異なる。


管理コマンド
• gs-agent.sh エージェント起動コマンド
• gs-cmdline.sh Stado管理用コマンドラインツール
• gs-createdb.sh ユーザデータベースを作成
• gs-createmddb.sh メタデータベースを作成
• gs-dbstart.sh ユーザデータベースをオンラインに変更
• gs-dbstop.sh ユーザデータベースをオフラインに変更
• gs-dropdb.sh ユーザデータベースを削除
• gs-execdb.sh
• gs-impex.sh
• gs-loader.sh ユーザデータベースにデータをロード
• gs-server.sh コーディネータを起動
• gs-shutdown.sh コーディネータを停止

（“gs-” と付いているのはGridSQL時代の名残りの模様）


3. Stado検証結果


Stado Cluster #1
• Amazon EC2 Small Instances（m1.small）
– APAC/Tokyo Region
– 1.7 GB Memory
– 1 ECU（1 ECU × 1 Virtual Core）
– 160 GB Instance Storage
– 32-bit platform
– I/O Performance: Moderate

• Additional EBS Storages for PostgreSQL database
cluster
• Up to 8 instances


Stado Cluster #1

stado01

stado02 stado03 stado04 stado05 stado06 stado07 stado08

Coordinator

Agent Agent Agent Agent Agent Agent Agent Agent

Postgres Postgres Postgres Postgres Postgres Postgres Postgres Postgres

testdb1

testdb2

testdb4

testdb8


Stado Cluster #1


Stado Cluster #2
• NEC Express5800/GT110b
– Intel Xeon X3440 2.53GHz （Quad Core / 8 threads）
– Unbeffered ECC 16GB RAM
– HGST Deskstar 1TB 7200rpm (SATA 3Gbps) * 4


Stado Cluster #2
• Multiple spindles to take advantage of multi-core
processor even within a single server.
– Multiple tablespaces are assigned to each dedicated disk.

Coordinator

Agent

Postgres

tblspc1 tblspc2 tblspc3
testdb1

testdb2

testdb4


DBT-3 Schema
• Scale factor “10”
– >25GB, including its indexes.

Table Name Purpose # of Records Size Partition Key
customer 顧客マスタ 1,500,000 289,046,528 c_custkey
lineitem 注文明細 59,986,052 8,727,838,720 l_orderkey
nation 国名マスタ 25 8,192 －
orders 注文 15,000,000 2,074,853,376 o_orderkey
part 部品マスタ 2,000,000 332,816,384 p_partkey
partsupp 部品詳細マスタ 8,000,000 1,400,143,872 ps_partkey
region 地域マスタ 5 8,192 －
supplier 販売業者マスタ 100,000 17,858,560 －


Stado Test #1
• Data Loading / データロード

• Creating indexes / インデックス作成

• Aggregation (count, sum) / 集約（count, sum）

• Aggregation + GROUP BY （daily basis, country basis） /
集約+GROUP BY （日別売上、国別売上）

• JOIN (local) / 結合（ノード内）

• JOIN (cross-node) / 結合（ノード間）

Summary – Cluster #1

Stado Performance Comparison
(Stado Cluster #1)

3.50

3.00
(compared to standalone)

2.50
Execution Time

Standalone
2.00 1-node
2-nodes
1.50 4-nodes
8-nodes

1.00

0.50

0.00
Loading Building Query 1 Query 2 Query 3 Query 4 Query 5
Tables Indexes
Workload Type



(Stado Cluster #2)

1.20

1.00

0.80
Execution Time

Standalone
1-disk
0.60
2-disks
4-disks
0.40

0.20

0.00
Loading Building Query 1 Query 2 Query 3 Query 4 Query 5
Tables Indexes
Workload Type


Loading Tables
• Loading tables did not take advantage of the cluster.
– Loading 8 tables using gs-loader (for Stado) or psql (for
Standalone)
– Parallel loading seems like highly CPU intensive task.
Stado Performance Comparison Stado Performance Comparison
(Stado Cluster #1) (Stado Cluster #2)

3.50 1.20

3.00 1.00

2.50
Standalone 0.80

Execution Time
Execution Time

Standalone
2.00 1-node
1-disk
2-nodes 0.60
2-disks
1.50 4-nodes
4-disks
8-nodes 0.40
1.00

0.20
0.50

0.00 0.00
Loading Tables Loading Tables
Workload Type Workload Type


Building Indexes
• Building indexes could benefit by adding servers and/or
spindles.
– Elapsed time shows linear scalability as adding nodes.


1.20 1.20

1.00 1.00

0.80 Standalone 0.80
Execution Time

Execution Time
Standalone
1-node
1-disk
0.60 2-nodes 0.60
2-disks
4-nodes
4-disks
0.40 8-nodes 0.40

0.20 0.20

0.00 0.00
Building Indexes Building Indexes


Aggregation (Query 1, 2)
• Simple scan and aggregation can take advantage of the
cluster.
– Executing SUM() and COUNT() on “orders” table.


1.20 1.20

1.00 1.00

Execution Time

Execution Time
Standalone
1-node
1-disk
0.60 2-nodes 0.60
2-disks
4-nodes
4-disks
0.40 8-nodes 0.40

0.20 0.20

0.00 0.00
Query 1 Query 1


Aggregation + GROUP BY (Query 3)
• “Aggregation + GROUP BY” as well.


1.20 1.20

1.00 1.00

Execution Time

Execution Time
Standalone
1-node
1-disk
0.60 2-nodes 0.60
2-disks
4-nodes
4-disks
0.40 8-nodes 0.40

0.20 0.20

0.00 0.00
Query 3 Query 3


JOIN (local) (Query 4)
• “Local Join” between partitioned tables with using a
partition key could scale.
– “orders” and “lineitem” are joined with “orderkey”.
– More CPU power needed.

2.50 1.20

1.00
2.00

Standalone 0.80
Execution Time

Execution Time
1.50 Standalone
1-node
1-disk
2-nodes 0.60
2-disks
4-nodes
1.00 4-disks
8-nodes 0.40

0.50
0.20

0.00 0.00
Query 4 Query 4


JOIN (cross-node) (Query 5)
• “Cross-node Join” may not be able to scale.
– Particularly, large “Cross-node Join” must be critical for SQL
performance.


2.50 1.20

1.00
2.00

Standalone 0.80
Execution Time

Execution Time
1.50 Standalone
1-node
1-disk
2-nodes 0.60
2-disks
1.00 4-nodes
4-disks
8-nodes 0.40

0.50
0.20

0.00 0.00
Query 5 Query 5


Behind the scene: “cross-node” join
• Collect all rows (Row Shipping) from the entire
cluster into temp table. Node #1
• Process a JOIN which can be done within the
node. customer (1)
• Process a JOIN against the temp table. JOIN (1) orders (1)

lineitem (1)
• Row Shipping is very expensive!
JOIN (2) temp

Row Shipping

Node #2 Node #3 Node #4

customer (2) customer (3) customer (4)

orders (2) orders (3) orders (4)

lineitem (2) lineitem (3) lineitem (4)


Resource usage: “cross-node” join

http://www2.uptimeforce.com/pgstatview2/20b267567a8f134b970070cc1a212a05/

Stado Test #2
• DBT-3 Queries
– Q1 - Aggregations on a single partitioned table.
– Q2 - Joining two partitioned tables with a partition key, and also
joining dimension tables.
– Q4 - Joining two partitioned tables with a partition key, and
aggregation.
– Q6 - Aggregations on a single partitioned table, and aggregation.
– Q11 - Joining a partitioned table and dimension tables, and
aggregation.
– Q12 - Joining two partitioned table, and aggregation.
– Q16 - Joining two partitioned tables with a partition key, also
joining dimension tables, and aggregation.


(Stado Cluster #1)

2

1.8

1.6

1.4
Execution Time

1.2 Standalone
1-node
1 2-nodes
4-nodes
0.8 8-nodes

0.6

0.4

0.2

0
Q1 Q2 Q4 Q6 Q11 Q12 Q16
Workload Type


(Stado Cluster #2)

1.40

1.20

1.00
Execution Time

0.80 Standalone
1-disk
2-disks
0.60 4-disks

0.40

0.20

0.00
Q1 Q2 Q4 Q6 Q11 Q12 Q16
Workload Type


Q1
• Simple aggregation with conditional scan on a
partitioned table, “lineitem”.


1.20 1.20

1.00 1.00

Execution Time

Execution Time
Standalone
1-node
1-disk
0.60 2-nodes 0.60
2-disks
4-nodes
4-disks
0.40 8-nodes 0.40

0.20 0.20

0.00 0.00
Q1 Q1


Q2
• Joining partitioned talbes, “partsupp” and “partsupp”,
with a partition key, and dimension tables.
– But, the 1-node and 8-node AWS clusters shown some strange
behaviors.

3.00 1.20

2.50 1.00

Execution Time

Execution Time
Standalone
1-node
1-disk
1.50 2-nodes 0.60
2-disks
4-nodes
4-disks
1.00 8-nodes 0.40

0.50 0.20

0.00 0.00
Q2 Q2


Q4
• Joining two partitioned tables, “orders” and “lineitem”,
with a partition key “orderkey”.
– Q4 failed to complete on the AWS cluster.
– Q4 was much faster even with 1-disk on the single server.

1.00 1.20
0.90
1.00
0.80

0.70
Standalone 0.80
Execution Time

Execution Time
0.60 Standalone
1-node
1-disk
0.50 2-nodes 0.60
2-disks
0.40 4-nodes
4-disks
8-nodes 0.40
0.30
0.20
0.20
0.10
0.00 0.00
Q4 Q4


Q6
• Simple conditional scan on a partitioned table,“lineitem”.


1.20 1.20

1.00 1.00

Execution Time

Execution Time
Standalone
1-node
1-disk
0.60 2-nodes 0.60
2-disks
4-nodes
4-disks
0.40 8-nodes 0.40

0.20 0.20

0.00 0.00
Q6 Q6


Q11
• Joining a partitioned table and dimension tables,
“partsupp”, “supplier” and “nation”, with aggregation and
sort.


1.20 1.20

1.00 1.00

Execution Time

Execution Time
Standalone
1-node
1-disk
0.60 2-nodes 0.60
2-disks
4-nodes
4-disks
0.40 8-nodes 0.40

0.20 0.20

0.00 0.00
Q11 Q11


Q12
• Joining two partitioned tables, “orders” and “lineitem”,
with aggregation and sort.


1.20 1.20

1.00 1.00

Execution Time

Execution Time
Standalone
1-node
1-disk
0.60 2-nodes 0.60
2-disks
4-nodes
4-disks
0.40 8-nodes 0.40

0.20 0.20

0.00 0.00
Q12 Q12


Q16
• Joining another two partitioned tables, “part” and
“partsupp”, with aggregation and sort.


1.40 1.20

1.20 1.00

1.00
Standalone 0.80
Execution Time

Execution Time
Standalone
0.80 1-node
1-disk
2-nodes 0.60
2-disks
0.60 4-nodes
4-disks
8-nodes 0.40
0.40

0.20 0.20

0.00 0.00
Q16 Q16


その他
• SQLの互換性はほぼ問題なし
– DBT-3のクエリ22本はほとんどそのままの形で実行可能
– 一部、明示的な型キャストや優先度の指定が必要（parse errorなどが発生）

• statement_timeout相当の処理がStadoには無いので注意
– SET statement_timeout コマンドを送れない
– Row Shipping中（COPYコマンド中）にはpostgresql.confの
statement_timeoutも効かなかった（調査中）

• EXPLAINは、Row Shippingの発生および量を明確には教えてくれない
ので、頭の中で理解しておく
– “Even though, EXPLAIN is still your friend.”

• 今後の課題
– ログ出力の強化、改善
– 管理コマンドの強化（パーティションの再配置等）
– ドキュメントの強化


まとめ
• Stadoはクエリのパフォーマンスを大きくに向上させます
– リーズナブルな手段、リーズナブルな方法で

• Stadoはノードの追加に応じてスケールします
– サーバだけではなく、複数ディスク＋マルチコアCPUもアリ

• Stadoはオープンソースなので、制限が問題になるようであ
れば、レポートやパッチを送りましょう
– 開発メンバーはとてもフランクで、bug fixも迅速です

• Stadoを使ってみたいと思った方、ぜひ情報交換しましょう！


Special Thanks

Mason Sharp

Jim Mlodgenski

Andrei Martsinchyk


Questions?

Satoshi Nagayasu
snaga@uptime.jp


【お問い合わせ先】
アップタイム・テクノロジーズ合同会社
永安悟史
E-mail： snaga@uptime.jp
Web: http://www.uptime.jp/


BigDataを迎え撃つ！ PostgreSQL並列分散ミドルウェア「Stado」の紹介と検証報告

More Related Content

What's hot (20)

Viewers also liked (17)

Similar to BigDataを迎え撃つ！ PostgreSQL並列分散ミドルウェア「Stado」の紹介と検証報告 (20)

BigDataを迎え撃つ！ PostgreSQL並列分散ミドルウェア「Stado」の紹介と検証報告