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

自己紹介 • 永安悟史（ながやすさとし） • 略歴 – 1997年よりインターネットベンチャーにてネットサービス開発・運用に従事。 – 2004年より（株）ＮＴＴデータにて、並列分散データベースの研究開発、技術支援・保守サポート業務を経て、データセンタの新規サービス開発、運用チームの立ち上げ、サービス運用などに従事。 – 2009年、アップタイム・テクノロジーズを創業。 • 専門分野 – データベースシステム、並列分散システム、クラスタシステム – オープンソース・インフラ技術 – ＩＴサービスマネジメント（ITIL）、ITインフラ運用管理（運用設計～運用） • アップタイム・テクノロジーズ＠本業 – オープンソース導入サポートサービス – データベース・コンサルティング – ＩＴサービスマネジメント・コンサルティング Copyright 2012 Uptime Technologies, LLC. All rights reserved.

アップタイム・テクノロジーズについて • オープンソース導入サポートサービスの提供 – 各種OSS（ミドルウェア、ツールなど）についての調査・情報提供 – 設計（基盤～アプリ）、開発の支援 – 機能検証・性能見積もり支援（機能検証、性能検証）、試験設計支援 – OSSコミュニティエスカレーション、等 • セミナ、トレーニングの提供 – 「PostgreSQLパフォーマンスチューニング入門」（7/27） – 「LifeKeeper for Linuxで構築・運用する高可用PostgreSQLシステム」 • コンテンツのオンライン販売 – PostgreSQLアーキテクチャ入門（自習用教材） – OSDL DBT-3によるPostgreSQLの性能評価～SATA HDD＆SATA SSD編（技術検証レポート）詳細は http://www.uptime.jp をご覧ください。 Copyright 2012 Uptime Technologies, LLC. All rights reserved.

“Stado”とは何か? • PostgreSQLで利用できるMPPミドルウェア – MPP: Massive Parallel Processing、超並列処理 • GridSQLの後継であり、長い技術の蓄積 – ExtenDB（2003）、GridSQL@EnterpriseDB（2007） • 「シェアードナッシング」方式の分散データアーキテクチャ – コモディティサーバのパフォーマンスをレバレッジさせる。 – アプリケーションに対して単一のデータベースに見せる。 • 基本事項… – オープンソース – BI/DWHデータベース（Greenplum、NetezzaやTeradataのような） Copyright 2012 Uptime Technologies, LLC. All rights reserved.

“Stado”とは何か? (2) • パラレルクエリを実行するための設計 – 伝統的なスタースキーマを対象とする • 読み取りだけではなく、UPDATEやDELETEも実行可 • パラレルローディングのためのデータローダ – バルクローディング • PostgreSQL互換のコネクタを使って標準的な接続が可能 – JDBC, ODBC, ADO.NET, libpq(psql) Copyright 2012 Uptime Technologies, LLC. All rights reserved.

Stadoは何 “ではない” か？ • SlonyやBucardoのようなレプリケーションではない • PostgreSQL 9.1の同期レプリケーションのような高可用のためのソリューションでもない • Postgres-XCのようなスケーラブルなトランザクションソリューションでもない • “Elastic” で “Eventually consistent” なNoSQLデータベースでもない Copyright 2012 Uptime Technologies, LLC. All rights reserved.

アーキテクチャ • 祖結合なシェアードナッシング Applications アーキテクチャ • Stadoプロセス – 中央のコーディネータ Coordinator – データノートのエージェント • データレポジトリ – メタデータデータベース Data Nodes – Stado（ユーザ）データベース ETL Copyright 2012 Uptime Technologies, LLC. All rights reserved.

パーティショニング • StadoのパーティショニングとPostgreSQLのCE（Constraint Exclusion）パーティショニングを同時に利用可能 – （CEの）サブテーブルを使うことによって、大規模なクエリはより小さなデータをスキャンする – 各サブテーブルがノードをまたいで分割されているので、並列にスキャンされる • パーティションの種類 – Stadoはハッシュパーティションを提供 – CEはレンジパーティションを提供 • “Making things smaller, making things faster.” – テーブルやインデックスを小さく保つことで高速化する Copyright 2012 Uptime Technologies, LLC. All rights reserved.

スタースキーマ • ひとつのファクトテーブル（トランザクション情報）と、複数のディメンション（マスター）テーブルで構成されるスキーマ 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 Copyright 2012 Uptime Technologies, LLC. All rights reserved.

クエリオプティマイザ • コストベースのオプティマイザ – もっともコストが高いのがRow Shipping • レプリケーションテーブルとのJOIN（結合）を探す – レプリケーションテーブルとのJOINはノード内で処理可能 – パーティションキーを使ったJOINを探す – 複数のテーブル（ordersとlineitemなど）を単一のパーティションキー（orderkey）を使って分割すると、同じキーのレコードが同一パーティションにあることが担保される – 異なるキーで複数のテーブルをパーティションすると、JOIN時にRow Shippingが発生する（サイズによっては非常に時間がかかる） Copyright 2012 Uptime Technologies, LLC. All rights reserved.

トランザクションパフォーマンス • 行のINSERT、UPDATE、DELETEは、単体のPostgreSQL と比較すると遅い – データがネットワーク上を余分に行き来する必要があるため – パーティションテーブルの行は、適切なノードに割り振るためにハッシュ化される必要がある – レプリケーションテーブルの行はすべてのノードでコミットされる必要がある • パフォーマンスを上げるためには “gs-loader” を使ってバルクロードする Copyright 2012 Uptime Technologies, LLC. All rights reserved.

高可用性 • ハートビートやフェイルオーバーの制御はコーディネータには無い – 各PostgreSQLノードの高可用性は、それぞれ個別に設定される必要がある – この目的にストリーミングレプリケーションを利用可能 • Stadoデータベース全体の一貫性のあるバックアップの取得は難しい – トランザクションが実行されていないことを担保する必要がある – 各ノードを個別にバックアップする必要がある Copyright 2012 Uptime Technologies, LLC. All rights reserved.

ノードの追加 • ダウンタイムが必要 – データは手動で新しいノードにリロードされる必要がある • 設計によっては、データの再配置を排してより迅速にできる – 最初に多数のパーティションに分割しておく – 最初に複数のインスタンスを物理サーバで動作させておき、必要に応じて新しいハードウェアに移動させる Copyright 2012 Uptime Technologies, LLC. All rights reserved.

ドキュメント類 • Stadoに同梱されているドキュメント類 – Stado Administration Guide （対訳済み） – Stado Import and Export Utilities （一部対訳済み） – Stado Planning Guide – Stado SQL Reference 上記の対訳版ドキュメントは以下のURLで公開しています。 http://www.uptime.jp/go/stado Copyright 2012 Uptime Technologies, LLC. All rights reserved.

導入手順 • ステップ１ – OSアカウントの作成、セットアップ – ネットワーク関連のセットアップ – OSのチューニング – JDK、PostgreSQLのインストールとコンフィグ設定 • ステップ２ – Stadoのインストールとコンフィグ設定 – 各PostgreSQLノード管理ユーザ（stado）の作成 – Stado管理/接続ユーザの作成（admin）とメタデータベース作成 – コーディネータの起動 – エージェントの起動 • ステップ３ – ユーザデータベースの作成 – テーブルの作成 – データのロード Copyright 2012 Uptime Technologies, LLC. All rights reserved.

導入手順 – STEP2 • Stadoのインストールとコンフィグ設定 – コーディネータ設定：stado.config – エージェント設定：stado_agent.config • 各PostgreSQLノード管理ユーザ（stado）の作成 – createuserコマンド • Stado管理/接続ユーザの作成（admin）とメタデータベース作成 – gs-createmdbコマンド • コーディネータの起動 – gs-serverコマンド • エージェントの起動 – gs-agentコマンド Copyright 2012 Uptime Technologies, LLC. All rights reserved.

管理コマンド • 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時代の名残りの模様） Copyright 2012 Uptime Technologies, LLC. All rights reserved.

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 Copyright 2012 Uptime Technologies, LLC. All rights reserved.

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 Copyright 2012 Uptime Technologies, LLC. All rights reserved.

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 Copyright 2012 Uptime Technologies, LLC. All rights reserved.

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 Copyright 2012 Uptime Technologies, LLC. All rights reserved.

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 － Copyright 2012 Uptime Technologies, LLC. All rights reserved.

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) / 結合（ノード間） Copyright 2012 Uptime Technologies, LLC. All rights reserved.

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 Copyright 2012 Uptime Technologies, LLC. All rights reserved.

Summary – Cluster #2 Stado Performance Comparison (Stado Cluster #2) 1.20 1.00 (compared to standalone) 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 Copyright 2012 Uptime Technologies, LLC. All rights reserved.

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 (compared to standalone) (compared to standalone) 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 Copyright 2012 Uptime Technologies, LLC. All rights reserved.

Building Indexes • Building indexes could benefit by adding servers and/or spindles. – Elapsed time shows linear scalability as adding nodes. Stado Performance Comparison Stado Performance Comparison (Stado Cluster #1) (Stado Cluster #2) 1.20 1.20 1.00 1.00 (compared to standalone) (compared to standalone) 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 Workload Type Workload Type Copyright 2012 Uptime Technologies, LLC. All rights reserved.

Aggregation (Query 1, 2) • Simple scan and aggregation can take advantage of the cluster. – Executing SUM() and COUNT() on “orders” table. Stado Performance Comparison Stado Performance Comparison (Stado Cluster #1) (Stado Cluster #2) 1.20 1.20 1.00 1.00 (compared to standalone) (compared to standalone) 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 Query 1 Query 1 Workload Type Workload Type Copyright 2012 Uptime Technologies, LLC. All rights reserved.

Aggregation + GROUP BY (Query 3) • “Aggregation + GROUP BY” as well. Stado Performance Comparison Stado Performance Comparison (Stado Cluster #1) (Stado Cluster #2) 1.20 1.20 1.00 1.00 (compared to standalone) (compared to standalone) 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 Query 3 Query 3 Workload Type Workload Type Copyright 2012 Uptime Technologies, LLC. All rights reserved.

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. Stado Performance Comparison Stado Performance Comparison (Stado Cluster #1) (Stado Cluster #2) 2.50 1.20 1.00 2.00 (compared to standalone) (compared to standalone) 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 Workload Type Workload Type Copyright 2012 Uptime Technologies, LLC. All rights reserved.

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. Stado Performance Comparison Stado Performance Comparison (Stado Cluster #1) (Stado Cluster #2) 2.50 1.20 1.00 2.00 (compared to standalone) (compared to standalone) 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 Workload Type Workload Type Copyright 2012 Uptime Technologies, LLC. All rights reserved.

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) Copyright 2012 Uptime Technologies, LLC. All rights reserved.

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. Copyright 2012 Uptime Technologies, LLC. All rights reserved.

Summary – Cluster #1 Stado Performance Comparison (Stado Cluster #1) 2 1.8 1.6 1.4 (compared to standalone) 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 Copyright 2012 Uptime Technologies, LLC. All rights reserved.

Summary – Cluster #2 Stado Performance Comparison (Stado Cluster #2) 1.40 1.20 1.00 (compared to standalone) 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 Copyright 2012 Uptime Technologies, LLC. All rights reserved.

Q1 • Simple aggregation with conditional scan on a partitioned table, “lineitem”. Stado Performance Comparison Stado Performance Comparison (Stado Cluster #1) (Stado Cluster #2) 1.20 1.20 1.00 1.00 (compared to standalone) (compared to standalone) 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 Q1 Q1 Workload Type Workload Type Copyright 2012 Uptime Technologies, LLC. All rights reserved.

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. Stado Performance Comparison Stado Performance Comparison (Stado Cluster #1) (Stado Cluster #2) 3.00 1.20 2.50 1.00 (compared to standalone) (compared to standalone) 2.00 Standalone 0.80 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 Workload Type Workload Type Copyright 2012 Uptime Technologies, LLC. All rights reserved.

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. Stado Performance Comparison Stado Performance Comparison (Stado Cluster #1) (Stado Cluster #2) 1.00 1.20 0.90 1.00 0.80 (compared to standalone) (compared to standalone) 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 Workload Type Workload Type Copyright 2012 Uptime Technologies, LLC. All rights reserved.

Q6 • Simple conditional scan on a partitioned table,“lineitem”. Stado Performance Comparison Stado Performance Comparison (Stado Cluster #1) (Stado Cluster #2) 1.20 1.20 1.00 1.00 (compared to standalone) (compared to standalone) 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 Q6 Q6 Workload Type Workload Type Copyright 2012 Uptime Technologies, LLC. All rights reserved.

Q11 • Joining a partitioned table and dimension tables, “partsupp”, “supplier” and “nation”, with aggregation and sort. Stado Performance Comparison Stado Performance Comparison (Stado Cluster #1) (Stado Cluster #2) 1.20 1.20 1.00 1.00 (compared to standalone) (compared to standalone) 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 Q11 Q11 Workload Type Workload Type Copyright 2012 Uptime Technologies, LLC. All rights reserved.

Q12 • Joining two partitioned tables, “orders” and “lineitem”, with aggregation and sort. Stado Performance Comparison Stado Performance Comparison (Stado Cluster #1) (Stado Cluster #2) 1.20 1.20 1.00 1.00 (compared to standalone) (compared to standalone) 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 Q12 Q12 Workload Type Workload Type Copyright 2012 Uptime Technologies, LLC. All rights reserved.

Q16 • Joining another two partitioned tables, “part” and “partsupp”, with aggregation and sort. Stado Performance Comparison Stado Performance Comparison (Stado Cluster #1) (Stado Cluster #2) 1.40 1.20 1.20 1.00 (compared to standalone) (compared to standalone) 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 Workload Type Workload Type Copyright 2012 Uptime Technologies, LLC. All rights reserved.

その他 • 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.” • 今後の課題 – ログ出力の強化、改善 – 管理コマンドの強化（パーティションの再配置等） – ドキュメントの強化 Copyright 2012 Uptime Technologies, LLC. All rights reserved.

まとめ • Stadoはクエリのパフォーマンスを大きくに向上させます – リーズナブルな手段、リーズナブルな方法で • Stadoはノードの追加に応じてスケールします – サーバだけではなく、複数ディスク＋マルチコアCPUもアリ • Stadoはオープンソースなので、制限が問題になるようであれば、レポートやパッチを送りましょう – 開発メンバーはとてもフランクで、bug fixも迅速です • Stadoを使ってみたいと思った方、ぜひ情報交換しましょう！ Copyright 2012 Uptime Technologies, LLC. All rights reserved.

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

More Related Content

What's hot

Viewers also liked

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

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