20220331_DSSA_MigrationToYugabyteDB

How to assess
your cloud native workloads
for migration to
a Distributed SQL Database
Thu. 31/3/2022
Distributed SQL Summit Asia
#distributedsqlsummit #DSSAsia #distributedsql

About me
1
Masaki Yamakawa
UL Systems, Inc.
Managing Consultant
{
“Sector” ：”Financial（Stock, FX）”
“Skills” ：[“Distributed system”,
“In-memory computing”]
“Note” ：”Apache Geode Committer”
}

本日お伝えしたいテーマ
2
分散SQLデータベースへ
移行する際の考慮点

Agenda
3
1. クラウドネイティブ時代のデータベースの在り方
2. ベンチマーク結果
3. NewSQLチューニングのコツ

クラウドネイティブ時代の
データベースの在り方
4

クラウドネイティブ時代に求められるDBへの要求
5
◼Database on k8s
◼Database per Service
◼Scalability
◼High Availability
Service#1
DataStore#1
MicorService#1
Service#2
DataStore#2
MicorService#2
Service#3
DataStore#3
MicorService#3
Apps
Apps
Apps
Service#1-1
DataStore#1-1
Service#1-n
DataStore#1-n
Database Database Database
Database Database
Database
Service

よくあるアプリケーションのワークロード
6
特定の時間帯は負荷が高い
Ex）昼休みの時間は多くの人が
キャッシュレス決済を使用
通常時の負荷は低い
突発的に通常より高い負荷が発生する
Ex)イベント、キャンペーン開催時、
著名人のSNSでの発信など
Service
DataStore
Service
DataStore
Service
DataStore
Service
DataStore
Service
DataStore
Service
DataStore
Service
DataStore
Service
DataStore
Service
DataStore
Service Service
DataStore
Service Service Service
DataStore
よくある
Apps
App : k8sで柔軟にScale
DataStore: 最大負荷でサイジング
クラウド
ネイティブ時代のApps
App : k8sで柔軟にScale
DataStore: k8sで柔軟にScale
Time
Number
of
accesses

データベースに求められる可用性
7
◼RDBもマルチリージョン、マルチクラウドも視野に入れた
可用性レベルの検討が必要
⚫ マルチAZは当たり前
⚫ 最近はクラウドの障害も目立ち信用が落ちている
当たり前レベル検討レベル検討レベル

NewSQL
8
◼これらの課題を解決する可能性があるのがNewSQL
1. Kubernetes上で稼働
2. マルチAZ、マルチリージョン、マルチクラウドでの高可用性
3. スケールアウトのみならずスケールインも可能
PostgreSQL互換 PostgreSQL互換
MySQL互換

YugabyteDBとは
9
1. NoSQLのように大幅なアプリの変更は不要
⚫ 馴染みのあるSQLが利用可能
⚫ 分散トランザクション
⚫ 自動シャーディング
2. PostgreSQLとの高い互換性
3. DocDBによる強い一貫性
4. Cassandra/Redis互換API

NewSQLの性能は？
10
◼一般的に言われるNewSQLの特性
スケーラビリティ
高可用性
レイテンシー
スループット
トレードオフ
これらは良いところ
Kubernetes対応
SQLが利用可能
ReadのみならずWriteもスケール
分散トランザクション
自動シャーディング

TPC-Cによるベンチマーク（1）
12
◼TPC-Cとは
⚫ TPC によって策定されたベンチマーク仕様の1つ
⚫ 卸売業における注文・支払いなどの業務をモデルにしたトランザ
クションを実行し、システムの性能を測定
ER図と今回測定したデータ件数
Warehouse
倉庫
District
配達区域
Customer
顧客
History
支払履歴
Order
注文
OrderLine
注文明細
Stock
在庫
Item
商品
NewOrder
未配送注文
50件
15万件
5件
15万件
150万件 45000件
15万件
50万件
10万件

TPC-Cによるベンチマーク（2）
13
◼処理内容
処理内容説明
実行
比率
Ware
House
倉庫
District
配達区域
Customer
顧客
History
支払履歴
Item
商品
Stock
在庫
Order
注文
New-
Order
未配送
新規注文
Order-
Line
注文明細
NewOrder 注文処理 45% R RU R R RU C C C
Payment 支払処理 43% RU RU RU C
OrderStatus
注文状況
照会
4% R R R
Delivery 配送処理 4% U RU RD RU
StockLevel
在庫状況
照会
4% R R R

TPC-C Benchmark Result
14
◼特に何も考慮せずベンチマークした結果…
102.0
33.4 9.9
130.9
50.4
208.9 175.8
52.3
337.7
199.0
294.0
1464.1
249.2 267.8
829.8
0.0
200.0
400.0
600.0
800.0
1000.0
1200.0
1400.0
NewOrder Payment OrderStatus Deliver StockLevel
ms
Average Latency(ms)
PostgresSQL MySQL YugabyteDB
333.2
314.7
29.3 29.5 29.4
117.7 111.5
10.6 10.7 10.3
24.9 23.8
2.4 2.4 2.3
0.0
50.0
100.0
150.0
200.0
250.0
300.0
350.0
400.0
req/sec
Throughput(req/sec)
Benchmaker BenchBase
VM
PostgresSQL, MySQL: 1node（2 vCPU, Mem 8GiB）
YugabyteDB: 3node[replica=3]（2 vCPU, Mem 8GiB×3）
Warehouses 5 15万顧客、10万商品、50万在庫
Terminals 50 50端末（1倉庫あたり10端末）
YugabyteDBは
HighLatency、Low Throughput

TPC-C Benchmark Result（低負荷時）
15
◼低負荷時は大きな性能劣化はない印象
9.6
3.1 1.2
21.2
1.9
17.5
6.5 1.9
37.0
1.7
39.5
9.9 3.8
89.8
79.8
77.6
29.1
7.6
16.3
0.0
20.0
40.0
60.0
80.0
100.0
120.0
140.0
160.0
180.0
200.0
ms
Average Latency(ms)
PostgresSQL MySQL YugabyteDB TiDB
68.0
65.0
6.2 5.8 6.1
37.0 34.5
3.4 3.2 3.3
15.7 15.4
1.4 1.3 1.3
7.8 7.6
0.7 0.8 0.6
0.0
10.0
20.0
30.0
40.0
50.0
60.0
70.0
80.0
90.0
100.0
req/sec
Throughput(req/sec)
PostgresSQL MySQL YugabyteDB TiDB
Benchmaker BenchBase
VM
PostgresSQL, MySQL: 1node（2 vCPU, Mem 8GiB）
YugabyteDB: 3node[replica=3]（2 vCPU, Mem 8GiB×3）
Warehouses 5 15万顧客、10万商品、50万在庫
Terminals 1 1端末

TPC-C Benchmark Result（Tuned＆Scaleout）
16
◼簡単なチューニングでYugabyteDBのレイテンシー、
スループットは改善出来る
294.0
1464.1
249.2 267.8
829.8
204.8
1104.4
14.7
193.8
441.8
117.3
869.8
9.2
118.5
261.0
0.0
200.0
400.0
600.0
800.0
1000.0
1200.0
1400.0
ms
Average Latency(ms)
YugabyteDB YugabyteDB(tuned) YugabyteDB(tuned+6node)
24.9 23.8
2.4 2.4 2.3
32.5 31.7
3.1 2.9 2.7
45.2
43.0
4.2 3.8 3.8
0.0
5.0
10.0
15.0
20.0
25.0
30.0
35.0
40.0
45.0
50.0
req/sec
Throughput(req/sec)
YugabyteDB YugabyteDB(tuned) YugabyteDB(tuned+6node)

PotgresSQL/MySQL vs YugabyteDB
17
◼この結果であればYugabyteDBの採用も検討に値するのでは？
102.0
33.4 9.9
130.9
50.4
208.9
175.8
52.3
337.7
199.0
117.3
869.8
9.2
118.5
261.0
0.0
100.0
200.0
300.0
400.0
500.0
600.0
700.0
800.0
900.0
ms
Average Latency(ms)
PostgresSQL MySQL YugabyteDB(tuned+6node)
333.2
314.7
29.3 29.5 29.4
117.7 111.5
10.6 10.7 10.3
45.2 43.0
4.2 3.8 3.8
0.0
50.0
100.0
150.0
200.0
250.0
300.0
350.0
req/sec
Throughput(req/sec)
YugabyteDB公式サイトでのTPC-C結果
では、こんなに悪化しないため調査中
おそらくMySQLと遜色ないレベルにな
るはず

YugabyteDBチューニングのコツ
18

YugabyteDBチューニングポイント
19
◼簡単なチューニングでYugabyteDBの性能は改善する
Smart Client Driver
compact_table
自動シャーディングのHashキー指定
1
2
3

1. Smart Client Driver（1）
20
◼JDBCドライバーでクライアントサイドLBを実現
<driver>org.postgresql.Driver</driver>
<url>
jdbc:postgresql://localhost:5433/yugabyte
</url>
<driver>com.yugabyte.Driver</driver>
<url>
jdbc:yugabytedb://localhost:5433/yugabyte?
load-balance=true
</url>
Smart Client Driver使用方法
変更

1. Smart Client Driver（2）
21
◼Smart Client Driverを使用することによりQueryEngine部
分も負荷分散が可能に
Query Engine
DocDB
Query Engine
DocDB
Query Engine
DocDB
tserver
tserver
tserver
SQL
(PostgreDriver)
Query Engine
DocDB
Query Engine
DocDB
Query Engine
DocDB
tserver
tserver
tserver
SQL
(YugabyteDriver)
変更

2. compact_table
22
◼Size-Tier CompactionによるディスクI/Oの最適化
◼通常、Compactionは自動的にトリガーされるため、
ベンチマーク前にCLIより実行
yb-admin ¥
--master_addresses localhost:7100 ¥
compact_table ysql.yugabyte new_order
yb-admin CLIによるcompact_table実行

3. 自動シャーディングのHashキー指定
23
◼更なる性能向上を求める場合はHashキーを明示的に指定
CREATE TABLE new_order (
no_w_id int NOT NULL,
no_d_id int NOT NULL,
no_o_id int NOT NULL,
PRIMARY KEY (no_w_id, no_d_id, no_o_id)
);
PRIMARY KEY (no_w_id HASH, no_d_id, no_o_id)
);
PRIMARY KEY ((no_w_id, no_d_id) HASH, no_o_id)
);
Hashを指定していない場合、PRIMARYキーの１番目がHashキーになる
倉庫IDと配達区域で別のシャード（tablet）にデータが配置されると
効率が悪いため、明示的にHashキーを指定する
PostgreSQLの
DDLを
そのまま使用
Hashキー
指定

YugabyteDBの優位性
24
◼簡単なチューニングをすることで、通常のDBと同じ感覚で
SQLを使用しつつ、スケーラビリティと高可用性も満たす
102.0
33.4 9.9
130.9
50.4
208.9
175.8
52.3
337.7
199.0
117.3
869.8
9.2
118.5
261.0
0.0
100.0
200.0
300.0
400.0
500.0
600.0
700.0
800.0
900.0
ms
Average Latency(ms)
333.2
314.7
29.3 29.5 29.4
117.7 111.5
10.6 10.7 10.3
45.2 43.0
4.2 3.8 3.8
0.0
50.0
100.0
150.0
200.0
250.0
300.0
350.0
req/sec
Throughput(req/sec)
YugabyteDB公式サイトでのTPC-C結果
では、こんなに悪化しないため調査中
おそらくMySQLと遜色ないレベルにな
るはず

スケーラビリティ/高可用性
に対する追加ベンチマーク
25

YugabyteDBのスケーラビリティ
26
◼PostgreSQL/MySQLはスケーラビリティがないため、データ量、同時
アクセス数を増やすと性能劣化する
◼YugabyteDBは期待する性能に応じてノードを増減することで性能維持
225.6
75.8
25.8
300.2
153.9
452.6
930.5
106.1
944.1
563.8
215.2
1180.9
15.9
200.9
461.1
0.0
200.0
400.0
600.0
800.0
1000.0
1200.0
1400.0
ms
Average Latency(ms)
294.2
281.7
25.7 26.0 25.9
68.9 63.3
5.9 5.8 6.0
62.0 60.1
5.7 5.6 5.4
0.0
50.0
100.0
150.0
200.0
250.0
300.0
req/sec
Throughput(req/sec)
10Warehouse、100Terminalsの場合の性能比較

マルチAZ、マルチリージョン/マルチクラウドの性能
27
◼AZ冗長は現実的
◼マルチリージョン/マルチクラウドは、このレイテンシー/
スループットが許容できない場合は時期尚早。今後に期待
204.8
1104.4
14.7
193.8
441.8
430.3
1597.5
30.1
361.9
971.6
3035.1
4151.2
148.4
2095.2
6906.6
0.0
1000.0
2000.0
3000.0
4000.0
5000.0
6000.0
7000.0
ms
Average Latency(ms)
YugabyteDB YugabyteDB(AZ冗長) YugabyteDB(Region冗長)
32.5 31.7
3.1 2.9 2.7
21.6 20.7
1.9 1.9 1.8
5.8 5.6
0.6 0.6 0.6
0.0
5.0
10.0
15.0
20.0
25.0
30.0
35.0
40.0
req/sec
Throughput(req/sec)
YugabyteDB(tuned) YugabyteDB(AZ冗長) YugabyteDB(Region冗長)
5Warehouse、50Terminalsの場合の性能比較
Min
529.8ms
Min
90.6ms
Min
29.3ms
Min
96.0ms
Min
148.5ms

今後のロードマップで期待する機能
28

今後のロードマップで期待する機能
29
1. Upgrade to PostgreSQL v13
2. Automatic tablet splitting enabled by default
3. YSQL-table statistics and cost based optimizer(CBO)
4. Pessimistic locking Design
5. Make COLOCATED tables default for YSQL
6. Support for GiST indexes

まとめ
31
NewSQLはクラウドネイティブ時代のデータベース
ReadのみならずWriteもスケールしたいユースケースに
最適
データベースの高可用性は絶対

32
お問合せ先
mailto: info@ulsystems.co.jp
http://www.ulsystems.co.jp

20220331_DSSA_MigrationToYugabyteDB

More Related Content

What's hot

Similar to 20220331_DSSA_MigrationToYugabyteDB

More from Masaki Yamakawa

20220331_DSSA_MigrationToYugabyteDB