bigdataを迎え撃つ！...

Copyright 2012 Uptime Technologies, LLC. All rights reserved.

BigDataを迎え撃つ！PostgreSQL並列分散ミドルウェア「Stado」の

紹介と検証報告

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

永安悟史

2012/7/25


自己紹介

• 永安悟史（ながやすさとし）

• 略歴– 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データベース

でもない


アーキテクチャ

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

• Stadoプロセス

– 中央のコーディネータ

– データノートのエージェント

• データレポジトリ

– メタデータデータベース

– Stado（ユーザ）データベース

Coordinator

Data Nodes

ETL

Applications


構成

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

• テーブルは、レプリケーションか、パーティショニング– パーティションテーブルは大規模なファクトテーブル

– 単一のファクトテーブルと複数のディメンションテーブル


パーティショニング

• StadoのパーティショニングとPostgreSQLのCE（Constraint Exclusion）パーティショニングを同時に利用可能– （CEの）サブテーブルを使うことによって、大規模なクエリはより小さ

なデータをスキャンする

– 各サブテーブルがノードをまたいで分割されているので、並列にスキャンされる

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

– CEはレンジパーティションを提供

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


スタースキーマ

• ひとつのファクトテーブル（トランザクション情報）と、複数のディメンション（マスター）テーブルで構成されるスキーマ

o_orderkey

o_custkeyo_orderstatuso_totalpriceo_orderdateo_orderpriorityo_clerko_shippriorityo_comment

ordersc_custkey

c_namec_addressc_nationkeyc_phonec_acctbalc_mktsegmentc_comment

customer

l_orderkeyl_linenumber

l_partkeyl_suppkeyl_quantityl_extendedpricel_discountl_taxl_returnflagl_linestatusl_shipdatel_commitdatel_receiptdatel_shipinstructl_shipmodel_comment

lineitem

n_nationkey

n_namen_regionkeyn_comment

nation

p_partkey

p_namep_mfgrp_brandp_typep_sizep_containerp_retailpricep_comment

part

ps_partkeyps_suppkey

ps_availqtyps_supplycostps_comment

partsupp

r_regionkey

r_namer_comment

region

s_suppkey

s_names_addresss_nationkeys_phones_acctbals_comment

supplier


テーブルの作成

• テーブルはレプリケーションかパーティショニングされる– 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

Coordinator

Agent Agent Agent Agent Agent Agent Agent Agent

Postgres Postgres Postgres Postgres Postgres Postgres Postgres Postgres

stado01

stado02 stado03 stado04 stado05 stado06 stado07 stado08

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

testdb1

testdb2

testdb4

tblspc1 tblspc2 tblspc3


DBT-3 Schema

• Scale factor “10”– >25GB, including its indexes.

－17,858,560100,000販売業者マスタsupplier－8,1925地域マスタregion

ps_partkey1,400,143,8728,000,000部品詳細マスタpartsuppp_partkey332,816,3842,000,000部品マスタparto_orderkey2,074,853,37615,000,000注文orders

－8,19225国名マスタnationl_orderkey8,727,838,72059,986,052注文明細lineitemc_custkeyPartition Key

289,046,528Size

1,500,000# of Records

顧客マスタ

PurposecustomerTable Name


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)

0.00

0.50

1.00

1.50

2.00

2.50

3.00

3.50

LoadingTables

BuildingIndexes

Query 1 Query 2 Query 3 Query 4 Query 5

Workload Type

Exe

cution T

ime

(com

pare

d to

sta

nda

lone

)

Standalone

1-node

2-nodes

4-nodes

8-nodes




0.00

0.20

0.40

0.60

0.80

1.00

1.20

LoadingTables

BuildingIndexes

Query 1 Query 2 Query 3 Query 4 Query 5

Workload Type

Exe

cution T

ime

(com

pare

d t

o s

tandalo

ne)

Standalone

1-disk

2-disks

4-disks


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.


0.00

0.20

0.40

0.60

0.80

1.00

1.20

Loading Tables

Workload Type

Exe

cution

Tim

e(c

om

pare

d t

o s

tandalo

ne)

Standalone

1-disk

2-disks

4-disks


0.00

0.50

1.00

1.50

2.00

2.50

3.00

3.50

Loading Tables

Workload Type

Exe

cution T

ime

(com

pare

d t

o s

tandalo

ne)

Standalone

1-node

2-nodes

4-nodes

8-nodes


Building Indexes

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


0.00

0.20

0.40

0.60

0.80

1.00

1.20

Building Indexes

Workload Type

Exe

cution

Tim

e(c

om

pare

d t

o s

tandalo

ne)

Standalone

1-disk

2-disks

4-disks


0.00

0.20

0.40

0.60

0.80

1.00

1.20

Building Indexes

Workload Type

Exe

cution T

ime

(com

pare

d to

sta

nda

lone)

Standalone

1-node

2-nodes

4-nodes

8-nodes


Aggregation (Query 1, 2)

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


0.00

0.20

0.40

0.60

0.80

1.00

1.20

Query 1

Workload Type

Exe

cution

Tim

e(c

om

pare

d t

o s

tandalo

ne)

Standalone

1-disk

2-disks

4-disks


0.00

0.20

0.40

0.60

0.80

1.00

1.20

Query 1

Workload Type

Exe

cution T

ime

(com

pare

d to

sta

nda

lone)

Standalone

1-node

2-nodes

4-nodes

8-nodes


Aggregation + GROUP BY (Query 3)

• “Aggregation + GROUP BY” as well.


0.00

0.20

0.40

0.60

0.80

1.00

1.20

Query 3

Workload Type

Exe

cution

Tim

e(c

om

pare

d t

o s

tandalo

ne)

Standalone

1-disk

2-disks

4-disks


0.00

0.20

0.40

0.60

0.80

1.00

1.20

Query 3

Workload Type

Exe

cution T

ime

(com

pare

d to

sta

nda

lone)

Standalone

1-node

2-nodes

4-nodes

8-nodes


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.


0.00

0.20

0.40

0.60

0.80

1.00

1.20

Query 4

Workload Type

Exe

cution

Tim

e(c

om

pare

d t

o s

tandalo

ne)

Standalone

1-disk

2-disks

4-disks


0.00

0.50

1.00

1.50

2.00

2.50

Query 4

Workload Type

Exe

cution T

ime

(com

pare

d t

o s

tandalo

ne)

Standalone

1-node

2-nodes

4-nodes

8-nodes


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.


0.00

0.20

0.40

0.60

0.80

1.00

1.20

Query 5

Workload Type

Exe

cution

Tim

e(c

om

pare

d t

o s

tandalo

ne)

Standalone

1-disk

2-disks

4-disks


0.00

0.50

1.00

1.50

2.00

2.50

Query 5

Workload Type

Exe

cution T

ime

(com

pare

d t

o s

tanda

lone)

Standalone

1-node

2-nodes

4-nodes

8-nodes


Behind the scene: “cross-node” join

• Collect all rows (Row Shipping) from the entire cluster into temp table.

• Process a JOIN which can be done within the node.

• Process a JOIN against the temp table.

• Row Shipping is very expensive!

customer (2)

orders (2)

lineitem (2)

customer (3)

orders (3)

lineitem (3)

customer (4)

orders (4)

lineitem (4)

customer (1)

orders (1)

lineitem (1)

temp

JOIN (1)

JOIN (2)

Row Shipping

Node #1

Node #2 Node #3 Node #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.




0

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

1.8

2

Q1 Q2 Q4 Q6 Q11 Q12 Q16

Workload Type

Exe

cution T

ime

(com

pare

d t

o s

tandalo

ne)

Standalone

1-node

2-nodes

4-nodes

8-nodes




0.00

0.20

0.40

0.60

0.80

1.00

1.20

1.40

Q1 Q2 Q4 Q6 Q11 Q12 Q16

Workload Type

Exe

cution T

ime

(com

pare

d t

o s

tandalo

ne)

Standalone

1-disk

2-disks

4-disks


Q1

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


0.00

0.20

0.40

0.60

0.80

1.00

1.20

Q1

Workload Type

Exe

cution

Tim

e(c

om

pare

d t

o s

tandalo

ne)

Standalone

1-disk

2-disks

4-disks


0.00

0.20

0.40

0.60

0.80

1.00

1.20

Q1

Workload Type

Exe

cution T

ime

(com

pare

d t

o s

tanda

lone)

Standalone

1-node

2-nodes

4-nodes

8-nodes


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.


0.00

0.20

0.40

0.60

0.80

1.00

1.20

Q2

Workload Type

Exe

cution

Tim

e(c

om

pare

d t

o s

tandalo

ne)

Standalone

1-disk

2-disks

4-disks


0.00

0.50

1.00

1.50

2.00

2.50

3.00

Q2

Workload Type

Exe

cution T

ime

(com

pare

d t

o s

tandalo

ne)

Standalone

1-node

2-nodes

4-nodes

8-nodes


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.


0.00

0.20

0.40

0.60

0.80

1.00

1.20

Q4

Workload Type

Exe

cution

Tim

e(c

om

pare

d t

o s

tandalo

ne)

Standalone

1-disk

2-disks

4-disks


0.00

0.10

0.20

0.30

0.40

0.50

0.60

0.70

0.80

0.90

1.00

Q4

Workload Type

Exe

cution T

ime

(com

pare

d t

o s

tanda

lone)

Standalone

1-node

2-nodes

4-nodes

8-nodes


Q6

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


0.00

0.20

0.40

0.60

0.80

1.00

1.20

Q6

Workload Type

Exe

cution

Tim

e(c

om

pare

d t

o s

tandalo

ne)

Standalone

1-disk

2-disks

4-disks


0.00

0.20

0.40

0.60

0.80

1.00

1.20

Q6

Workload Type

Exe

cution T

ime

(com

pare

d t

o s

tanda

lone)

Standalone

1-node

2-nodes

4-nodes

8-nodes


Q11

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


0.00

0.20

0.40

0.60

0.80

1.00

1.20

Q11

Workload Type

Exe

cution T

ime

(com

pare

d t

o s

tandalo

ne)

Standalone

1-disk

2-disks

4-disks


0.00

0.20

0.40

0.60

0.80

1.00

1.20

Q11

Workload Type

Exe

cution T

ime

(com

pare

d to

sta

nda

lone)

Standalone

1-node

2-nodes

4-nodes

8-nodes


Q12

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


0.00

0.20

0.40

0.60

0.80

1.00

1.20

Q12

Workload Type

Exe

cution T

ime

(com

pare

d t

o s

tandalo

ne)

Standalone

1-disk

2-disks

4-disks


0.00

0.20

0.40

0.60

0.80

1.00

1.20

Q12

Workload Type

Exe

cution T

ime

(com

pare

d t

o s

tandalo

ne)

Standalone

1-node

2-nodes

4-nodes

8-nodes


Q16

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


0.00

0.20

0.40

0.60

0.80

1.00

1.20

Q16

Workload Type

Exe

cution

Tim

e(c

om

pare

d t

o s

tandalo

ne)

Standalone

1-disk

2-disks

4-disks


0.00

0.20

0.40

0.60

0.80

1.00

1.20

1.40

Q16

Workload Type

Exe

cution T

ime

(com

pare

d to

sta

nda

lone)

Standalone

1-node

2-nodes

4-nodes

8-nodes


その他

• 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 [email protected]


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

bigdataを迎え撃つ！...

Technology