トランザクション処理可能な分散DB 「YugabyteDB」入門（Open Source Conference 2022 Online/Fukuoka 発表資料）

© 2022 NTT DATA Corporation
Open Source Conference 2022 Online/Fukuoka
トランザクション処理可能な分散DB
「YugabyteDB」入門
2022/11/26
NTTデータ笠原辰仁

© 2022 NTT DATA Corporation 2
00
はじめに

自己紹介
• NTTデータ技術開発本部笠原辰仁
• 長年PostgreSQLの検証や周辺ツールの開発、サポートなどに従事
• 最近はNewSQLや分散データベースに属するOSSプロダクトの調査や検証、
適用領域の見極めなど
• 本日は、まだあまり馴染みのない分散データベースのOSSプロダクトであるYugabyteDBの概
観や利用方法を紹介
• 興味があるので手始めに簡単に触ってみたい、どんな特長のあるプロダクトかをざっくり知りた
い、という方々の一助になれば・・
• 本資料は公開しますので、細かい部分はそちらで確認いただけます

本日のアジェンダ
1.YugabyteDBの概要とアーキテクチャ
2.YugabyteDBの導入と操作
3.YSQLによるDBへの処理
4.YugabyteDBの管理
【注意】
本日紹介するYugabyteDBでは、機能追加や変更が活発に行われているため、本日の講演内容と最新版のプロダクトとの
齟齬が出やすいことが想定されます。参考として公式のオンラインマニュアルのリンクも添えていますので、試行の際に躓く場合は
マニュアルを参考してください。
本資料の説明には2022年11月上旬での最新版であるYugabyteDBのバージョン2.15(2.15.2)を利用しています。

01
YugabyteDBの概要とアーキテクチャ

YugabyteDBの概要
Yugabyte社が中心に開発しているOSSプロダクト。PostgreSQL/Cassandraとの互換性があり、
高い可用性とスケーラビリティを持つ分散データベース。
YugabyteDB
開発主体 Yugabyte 社 ( https://www.yugabyte.com/ )
開発体制 Github上での開発。JIRAも併用。 ( https://github.com/yugabyte/yugabyte-db )
開発言語 DB本体は主に C/C++ (PostgreSQLのコードを流用している部分はC)
ユーティリティやCLIはPython
製品形態 YugabyteDB Core ：YugabyteDB本体
YugabyteDB Anyware ：YugabyteDBのセルフマネージド用のユーティリティ群
YugabyteDB Managed ： YugabyteDBのマネージドサービス
ライセンス Apache License 2.0とPolyform Free Trial License 1.0.0の2つのライセンス形態がある。
Polyformライセンスは主にYugabyteDB Anywareに関するコード部分となる。(ソースツリーの managed
ディレクトリ以下の部分。バイナリには-managedのサフィックスを含む)
( https://docs.yugabyte.com/preview/legal/#licenses )

YugabyteDBの概要
非常に高いPostgreSQLとの互換性を持つ。
• ほとんどのDDL/DML/DCLのシンタックスをサポート
• PostgreSQLが持っているデータ型や組み込み関数もOK
• Extensionも主要なものはカバー
• NewSQLとしては珍しく外部キーやトリガ、ユーザ定義関数、ストアドプロシージャもサポート
• TiDBやCockroachDBなども追随しているが一歩リード、な感じ
• トランザクション分離レベルとしてもRead Committedもサポートし、PostgreSQLと同じよう
な振る舞いが可能
• JDBCなどPostgreSQL用のドライバも広く利用可能

YugabyteDBのアーキテクチャ
ユーザデータの配置先・ユーザ・権限などのメタデータを管理する「YB-Master」と、
ユーザデータを保持するとともに、ユーザリクエストを処理する「YB-Tserver」の2つのコンポーネントから構成される。
複数のYB-MasterとYB-Tserverで構成されるクラスタをYugabyteDBクラスタ(Universe)と呼ぶ。
YugabyteDBクラスタ (Universe)
YugabyteDBノード#1
YB-Master
YB-Tserver
YB-Master
YB-Tserver
YB-Master
YB-Tserver
YB-Masterはクラスタ全体の
メタデータ管理を担当
YB-Tserverはクエリ処理や
ユーザデータの保管を担当

YB-Masterサーバ
YB-Masterサーバ(以降Masterと呼称)はDDLの実行やデータ配置などの管理を行う。
Masterは複数ノードで構成され、１台のLeaderと複数のFollowerから成る。
メタデータはDocDB(RocksDBの改良版となるKVS)に格納され、Raftを用いてLeaderの選出や冗長化を実施。
Leader役のノードダウン時にはFollowerがLeaderに昇格し処理を継続する。
YB-Master
(Follower)
YB-Tserver
YB-Master
(Leader)
YB-Tserver
YB-Master
(Follower)
YB-Tserver
DocDB DocDB DocDB
クラスタのメタデータの変更を
伴う処理(テーブル作成や
データ配置の変更など)は
Leaderで実施され、
その結果がFollowerに
伝搬される。

YB-Tserverサーバ
YB-Tserverサーバ(以降Tserverと呼称)はユーザからのYSQL(PostgreSQL互換のIF)と
YCQL(Cassandra互換のIF)を受け付け処理を行う。また、Masterのメタデータを元に
ユーザーデータの読み書きを実施。データはTablet(後述)という単位で分割され複数のTserverに
均等に分散される。これによりTserverのノード増減に伴うスケーラビリティを実現している。
YB-Master
YB-Tserver
YB-Master
YB-Master
YSQL YCQL
DocDB
YB-Tserver
YSQL YCQL
DocDB
YB-Tserver
YSQL YCQL
DocDB
クエリ処理やそれに伴うデータ
の読み書きを行う。
ユーザはすべてのTserverへ
処理を行うことができる。

Tablet
ユーザデータ(テーブルとインデックス)はTabletと呼ばれる単位で分割され、
各TserverのDocDBへ分散配置(シャーディング)される。Tabletは１台のLeaderと
複数(replication factorで変動)のFollowerから成る。
基本的にユーザからの読み書きリクエストはLeaderのTabletに対して実行される。
Masterと同じく、ユーザデータもRaftによりLeader選出と冗長化が行われている。
Tablet1
(Leader)
Tablet1 Tablet1
Tablet2
(Leader)
Tablet2 Tablet2
Tablet3
Tablet3 Tablet3
(Leader)
YB-Tserver YB-Tserver YB-Tserver ユーザからは一つのテーブル
に見えるが内部的に複数の
Tabletに分割される。
分割はHash or Rangeが
選択可能。
分割数や配置は基本的に
自動で決定・実施。

02
YugabyteDBの導入と操作

YugabyteDBの動作環境とインストール
YugabyteDBは以下の環境で利用可能。
詳しくは https://docs.yugabyte.com/preview/quick-start/
OSのバージョンバイナリ Docker 備考
CentOS 7以降 ○ ○ RockyLinux8でもとりあえ動作
Ubuntu 16.04以降 ○ ○
Mac 10.12以降 ○ ○
Windows -- - ○
必要なハードスペック
• https://docs.yugabyte.com/preview/deploy/checklist/
• CPUは最低2core, 推奨は16core以上
• メモリは最低2GB, 推奨は32GB以上
• CPUとメモリはあるだけ良い・・
• ストレージはSSD等の高速なもの推奨
• YugabyteDBではJBODのような複数ディスク構成も扱いやすい (RAIDやLLVMでまとめなくても良い)
• サイズ要求は明示的にないが、触ってみる程度ならば最低限1GB程度あれば動く (できれば20GBくらいあると良い)

YugabyteDBの動作環境とインストール
インストールに際しては、以下のソフトウェアを事前に導入しておく。
• Python3
• 後にも出てくるYugbyteDBのCLIやユーティリティの多くがPythonを利用しているため
• wget もしくは curl
• これはバイナリのダウンロードのため
その他のポイント
• 複数ノードでクラスタを構成する場合は、NTP/Chronyでノード間の時刻同期をしておく
• デフォルトの設定では250 msec以上の時刻差があるとWARNING、6秒以上でFATALのエラーとなる
• システム設定でいくつかの設定を引き上げておくと良い
• 簡易動作確認程度ならば問題ないが、比較的多めのファイルやスレッドを扱うためnofile (ulimit –n)、
nproc (ulimit –u)は公式ドキュメントの推奨程度にしておく
• https://docs.yugabyte.com/preview/deploy/manual-deployment/system-config/

YugabyteDBのインストール
YugabyteDBのインストール方法にはいくつかあるが、
ここでは公式に公開しているバイナリを入手する方法を紹介。
最新版の資材は https://docs.yugabyte.com/preview/quick-start/linux/#download-yugabytedb を参照。
以下はyugabyteユーザを追加し、python3を入手後、alternativesコマンドでpythonコマンドがpython3を向くように設定
した後、実際のインストールへ移るコマンド例。
(yugabyteユーザの作成は任意で、別のユーザ名でも可。python3もインストール済みならスキップ可)
# useradd yugabyte
# yum install -y python3
# alternatives --set python /usr/bin/python3
# yum install -y wget
# su - yugabyte
$ wget https://downloads.yugabyte.com/releases/2.15.2.1/yugabyte-2.15.2.1-b1-linux-x86_64.tar.gz
$ tar zxvf yugabyte-2.15.2.1-b1-linux-x86_64.tar.gz
$ cd yugabyte-2.15.1.0
$ ./bin/post_install.sh
以上で終わり。資材の格納先は任意なのでダウンロード/解凍後に好きなディレクトへ移しても問題ない。
なお yugabyte-xxx.tar.gzは約300MB、展開後は約1.1GB程度のサイズとなる。

YugabyteDBのインストール
前述のコマンドにより $HOME/yugabyte-2.15.2.1 に必要資材が格納される。
操作に必要な実行ファイルは
$HOME/yugabyte-2.15.2.1/bin
と
$HOME/yugabyte-2.15.2.1/postgres/bin
にあるため、PATH に上記を通しておくと良い。
$ cat .bashrc
YUGA_INSTALL=/home/yugabyte/yugabyte-2.15.2.1
export PATH=$PATH:$YUGA_INSTALL/bin:$YUGA_INSTALL/postgres/bin

YugabyteDBの起動と停止
YugabyteDBの起動は基本的にMasterサーバ(YB-Master)の起動を行い、
それからTabletサーバ(YB-Tserver)を起動する手順となる。
起動と停止(初期化含む)には以下のコマンドを利用可能。
説明備考/注意
yb-master YB-Masterの起動用コマンド。
yb-tserver YB-Tserverの起動用コマンド。
yugabyted yb-masterとyb-tserverをラップし、簡易的にクラ
スタの設定や起動/停止を行うコマンド。動作確
認や開発、試験時の利用を想定。
商用利用は非推奨。複数ノードでのクラスタ
構成などをサポート。
yb-ctl yb-masterとyb-tserverをラップし、簡易的にクラ
スタの設定や起動/停止を行うコマンド。動作確
認や開発、試験時の利用を想定。
商用利用は非推奨。シングルノードのみでの
クラスタ構成などをサポート。yb-ctlコマンドで
生成したデータディレクトリはyb-ctlでのみ再
利用可。
クラスタ構成を組んでの起動などはやや煩雑なコマンドとなるため、利便用のコマンドとしてyugabytedとyb-ctlが用意されている。
従来はyb-ctlが主に用いられてきたようだが、最近はyugabytedの機能拡充が目立つ。
簡易的な動作確認であれば、構築されるクラスタの機能としては変わらないためどちらを選んでも良い。
本資料ではyugabytedコマンドを利用した実例で解説を進める。

YugabyteDBの起動
yugabytedコマンドを利用する場合、以下のように「yugabyted start」とするだけで起動できる。
$ yugabyted start
Starting yugabyted...
? System checks
? YugabyteDB Started
? WARNING: Cluster started in an insecure mode without authentication and encryption enabled. For non-
production use only, not to be used without firewalls blocking the internet traffic.
+----------------------------------------------------------------------------------------------------------+
| yugabyted |
+----------------------------------------------------------------------------------------------------------+
| Status : Running. |
| Replication Factor : 1 |
| Web console : http://127.0.0.1:7000 |
| JDBC : jdbc:postgresql://127.0.0.1:5433/yugabyte?user=yugabyte&password=yugabyte |
| YSQL : bin/ysqlsh -U yugabyte -d yugabyte |
| YCQL : bin/ycqlsh -u cassandra |
| Data Dir : /home/yugabyte/var/data |
| Log Dir : /home/yugabyte/var/logs |
| Universe UUID : e8bffde5-b7e1-4837-83b8-15c0d6008d0b |
+----------------------------------------------------------------------------------------------------------+
? YugabyteDB started successfully! To load a sample dataset, try 'yugabyted demo'.
? Join us on Slack at https://www.yugabyte.com/slack
? Claim your free t-shirt at https://www.yugabyte.com/community-rewards/

YugabyteDBの起動
YugabyteDBを起動すると以下のプロセスが立ち上がる。
yugabyte 6411 0.0 0.0 470544 17560 ? Sl 10:27 0:00 python /home/yugabyte/yugabyte-2.15.2.1/bin/yugabyted start
yugabyte 6423 1.7 0.3 649900 127504 ? Sl 10:27 0:04 /home/yugabyte/yugabyte-2.15.2.1/bin/yb-master (略
yugabyte 6504 0.3 0.1 1055384 57748 ? Sl 10:27 0:00 /home/yugabyte/yugabyte-2.15.2.1/bin/yb-tserver (略
yugabyte 6672 0.0 0.2 291664 64508 ? S 10:27 0:00 /home/yugabyte/yugabyte-2.15.2.1/postgres/bin/postgres (略
yugabyte 6696 0.0 0.0 133392 17548 ? Ss 10:27 0:00 postgres: logger
yugabyte 6698 0.0 0.0 308056 26272 ? Ssl 10:27 0:00 postgres: YSQL webserver
yugabyte 6700 0.0 0.0 291664 18452 ? Ss 10:27 0:00 postgres: checkpointer
yugabyte 6701 0.0 0.0 135512 17508 ? Ss 10:27 0:00 postgres: stats collector
yugabytedとyb-master、yb-tserverの他、PostgreSQL(とPostgreSQLのバックグラウンドプロセス)が稼働する。
PostgreSQLはTserverが内部的に起動/停止するためユーザが直接管理する必要はない。

YugabyteDBのデータディレクトリ
YugabyteDBを起動する際、指定されたデータディレクトリ(yb-master、yb-tserverコマンドの--fs_data_dirsオプションで指
定)が空もしくは存在しない場合、自動でディレクトリが作成され各種の初期データが作成される。
yugabytedコマンドを利用する場合、デフォルトでは実施ユーザのHOMEディレクトリ配下に「var」ディレクトリが生成され、その配下
に各種データが生成・格納される。以下はyugabytedコマンドで生成されるデータディレクトリ。
var/
|-- conf < -- yugabytedコマンドの起動オプション(デフォルト含む)として使用されたパラメータの設定ファイル
|-- data
| |-- pg_data < -- Tserverで稼働するPostgreSQLのデータファイル
| `-- yb-data < -- Master、およびTserverのデータファイル
`-- logs
|-- master < -- Masterのログディレクトリへのリンク
`-- tserver < -- Tserverのログディレクトリへのリンク
ログディレクトリ配下にはいくつかログが生成される。直下にあるmaster.errやtserver.errは各サービスの起動ログ。
yugabyted.logはyugabytedが発行しているコマンドログ。起動が上手くいかない場合はこれらを見ると良い。

yugabytedが利用するポート
YugabyteDBは処理の受付や後述するメトリクス情報のエンドポイント用に以下のポートを利用する。
ユーザはこれらにアクセスして処理をリクエストしたり情報を参照したりできる。
(なお他にYEDIS用のポートもあるが、YEDISは廃止予定のため省いている)
ポート番号用途備考
5433 TserverでのYSQLのリクエスト
9042 TserverでのYCQLのリクエスト
7000 MasterのWeb UIとメトリクス用 Web UIはブラウザでアクセスする。
メトリクスはPrometheusで収集するためのもの
だが、jsonフォーマット出力を行うエンドポイント
も備えている。
9000 TserverのWeb UIとメトリクス用
13000 TserverでのYSQLのメトリクス用
12000 TserverでのYCQLのメトリクス用
7100 MasterのRPC処理用ユーザは直接利用しない。
9100 TserverのRPC処理用
https://docs.yugabyte.com/preview/reference/configuration/default-ports/

YugabyteDBの停止
yugabytedコマンドを利用する場合、以下のように「yugabyted stop」とするだけで起動できる。
$ yugabyted stop
Stopped yugabyted using config /home/yugabyte/var/conf/yugabyted.conf.
もし、同じデータディレクトリで再度起動したい場合は「yugabyted start」とすれば良い。
なお、使い捨てのデータディレクトリである場合(停止後にデータなどを破棄しても良い)、
「yugabyted destroy」とすることで停止と共にデータディレクトリの破棄も行う。ただし「var/conf」のみ残る。
$ yugabyted destroy
Stopped yugabyted using config /home/yugabyte/var/conf/yugabyted.conf.
Deleted logs at /home/yugabyte/var/logs.
Deleted data at /home/yugabyte/var/data.
Deleted conf file at /home/yugabyte/var/conf/yugabyted.conf..

yugabytedによる起動時のオプションについて
yugabytedコマンドはいくつかのオプションを取ることができる。
以下は多用するため抑えておくと良い。特に複数のYugabyteDBを起動してクラスタを組む場合には必須となる。
オプション用途
--listen 起動するMasterとTserverのListenアドレスの指定。複数のMasterとTserverでクラスタを組む場合は
明示しておくと良い。
--base_dir 起動するMasterとTserverのデータディレクトリの指定。
--join 複数のMasterとTserverでクラスタ構成を組む際のジョインする既存Masterのアドレス
--master_flags Master用のパラメータ指定。カンマ区切りでname=valueを複数指定可能。
--tserver_flags Tserver用のパラメータ指定。カンマ区切りでname=valueを複数指定可能。
-- 以下は1台のローカルマシン上で3つのMasterとTserverを起動しクラスタを組む例
$ yugabyted start --base_dir=/home/yugabyte/ydata/node1 --listen=127.0.0.1
$ yugabyted start --base_dir=/home/yugabyte/ydata/node2 --listen=127.0.0.2 --join=127.0.0.1
https://docs.yugabyte.com/preview/reference/configuration/yugabyted/

03
YSQLによるDBへの処理

ysqlshによる接続と操作
YugabyteDBのYSQLでの接続はysqlshコマンド、もしくはPostgreSQL用のドライバや
コマンド(psqlなど)を利用可能。
$ ysqlsh
ysqlsh (11.2-YB-2.15.2.1-b0)
Type "help" for help.
yugabyte=# CREATE TABLE test (c1 int primary key, c2 text);
CREATE TABLE
yugabyte=# ¥d+ test
Table "public.test"
Column | Type | Collation | Nullable | Default | Storage | Stats target | Description
--------+---------+-----------+----------+---------+----------+--------------+-------------
c1 | integer | | not null | | plain | |
c2 | text | | | | extended | |
Indexes:
"test_pkey" PRIMARY KEY, lsm (c1 HASH)
yugabyte=# INSERT INTO test SELECT generate_series(1,10000), md5(clock_timestamp()::text);
INSERT 0 10000
基本的にPostgreSQLと同じ
シンタックスであればほとんど実行可能。
メタコマンド(¥～)もおおよそ
カバーされている

【参考】非サポートのシンタックス対応
YugabyteDBではPostgreSQLで実施可能なVACUUMやCHECKPOINTなどの処理、
およびDDLのオプションの一部などはサポートしていない。
ただしそれらの多くはERRORとせずにWARNING扱い(無視)とすることで処理のアボートを回避している。
下記はPostgreSQLのソースに同梱されているpgbenchというベンチマークツールによる初期化の様子を
抜粋したもの。
$ pgbench -i -s 1 -h 127.0.0.1 -p5433
dropping old tables...
NOTICE: table "pgbench_accounts" does not exist, skipping
NOTICE: table "pgbench_branches" does not exist, skipping
NOTICE: table "pgbench_history" does not exist, skipping
NOTICE: table "pgbench_tellers" does not exist, skipping
creating tables...
WARNING: storage parameter fillfactor is unsupported, ignoring
(中略)
HINT: Set 'ysql_beta_features' yb-tserver gflag to true to suppress the warning for all beta features.
WARNING: VACUUM will be ignored
creating primary keys...
done in 17.98 s (drop tables 0.03 s, create tables 1.07 s, client-side generate 5.69 s, vacuum 2.79 s, primary keys 8.40 s).

PostgreSQLとの差異/注意点
PostgreSQLとの高い互換性を持つYugabyteDBだが、当然ながら非互換なものもある。
一般的な使い方をするうえで注意した方が良いポイントをいくつかピックアップする。
• トランザクション分離レベルの設定
• DDLはトランザクショナルではないこと
• CREATE INDEXはデフォルトでCONCURRENTLYであること
なお、非互換に関しては以下のマニュアルにまとまっている。
https://docs.yugabyte.com/preview/explore/ysql-language-features/postgresql-compatibility/
https://docs.yugabyte.com/preview/faq/compatibility/#ycql-compatibility-with-apache-cassandra-ql

DLはトランザクショナルではないこと
YugabyteDBではテーブル作成やインデックス作成、TRUNCATEといった処理は
トランザクションとして実行できない(※)
PostgreSQLではROLLBACKできるが、それができないので注意。
yugabyte=# BEGIN;
BEGIN
yugabyte=# CREATE TABLE t1 (c1 int primary key, c2 text);
CREATE TABLE
yugabyte=# ROLLBACK ;
ROLLBACK
yugabyte=# SELECT * FROM t1;
c1 | c2
----+----
(0 rows)
yugabyte=# INSERT INTO t1 SELECT generate_series(1,10000), 'AAA';
INSERT 0 10000
yugabyte=# BEGIN;
BEGIN
yugabyte=# TRUNCATE t1;
TRUNCATE TABLE
yugabyte=# ROLLBACK ;
ROLLBACK
yugabyte=# SELECT count(*) FROM t1;
count
-------
0
(1 row)
CREATE TABLEの例 TRUNCATEの例
※HEADにはDDLをAtomicに行うための改善パッチが段階的に導入されている。
https://github.com/yugabyte/yugabyte-db/commit/6e604ba9a00842d4e114ef70708c99b6d2fac2af

トランザクション分離レベルの設定
YugabyteDBでは複数のトランザクション分離レベルをサポートしており、Beta機能では
あるがRead Committedでの動作(PostgreSQLのデフォルトと同じ振る舞い)も可能。
ただし、それを利用するにはTserverの「yb_enable_read_committed_isolation」パラメータを有効にする必要がある。
-- PostgreSQLにもある以下のパラメータでも確認できるが、実際には作用しない
yugabyte=# SHOW default_transaction_isolation ;
default_transaction_isolation
-------------------------------
read committed
-- 実際に分離レベルとして作用するのは以下のパラメータ
yugabyte=# SHOW yb_effective_transaction_isolation_level ;
yb_effective_transaction_isolation_level
------------------------------------------
repeatable read
-- 「default_transaction_isolation」を設定しても実際には変更されていない・・
yugabyte=# SET default_transaction_isolation TO "read committed";
SET
------------------------------------------
repeatable read

トランザクション分離レベルの設定
YugabyteDBでは複数のトランザクション分離レベルをサポートしており、Beta機能では
あるがRead Committedでの動作(PostgreSQLのデフォルトと同じ振る舞い)も可能。
ただし、それを利用するにはTserverの「yb_enable_read_committed_isolation」パラメータを
有効にする必要がある。
-- 以下のようにパラメータを指定してTserverを起動する必要がある。
$ yugabyted start --tserver_flags="yb_enable_read_committed_isolation=true"
-- 適切にTserverのパラメータを有効にすることでRead Committedになる
yugabyte=# SHOW default_transaction_isolation ;
default_transaction_isolation
-------------------------------
read committed
------------------------------------------
read committed

CREATE INDEXはデフォルトでCONCURRENTLYであること
YugabyteDBではインデックスの作成をデフォルトでCONCURRENTLYに行う。
(YugabyteDBではindex backfillと呼ぶ)
これはインデックス作成対象のテーブルへの更新処理をブロックしない一方、作成時間が長くなる。
NONCONCURRENTLYを付与すると対象テーブルへの排他ロックを取る一方、作成時間は短縮する。
大量の空のテーブルとインデックスを作成する場合にはNONCONCURRENTLYを付与すると良い。
yugabyte=# CREATE TABLE cic (c1 int);
CREATE TABLE
yugabyte=# ¥timing
Timing is on.
yugabyte=# CREATE INDEX cic_idx1 On cic (c1);
CREATE INDEX
Time: 3067.489 ms (00:03.067)
yugabyte=# CREATE INDEX NONCONCURRENTLY cic_idx2 On cic (c1);
CREATE INDEX
Time: 268.417 ms

CREATE INDEXはデフォルトでCONCURRENTLYであること
CONCURRENTLYでのインデックス作成が失敗するとインデックスの定義だけが
残存する。(これはPostgreSQLと同じ仕様)
作成に失敗したインデックスの再作成前に削除が必要なことに注意。
yugabyte=# INSERT INTO cic VALUES(1), (1);
INSERT 0 2
yugabyte=# CREATE UNIQUE INDEX cic_u_idx1 On cic (c1);
ERROR: Aborted: ERROR: duplicate key value violates unique constraint "cic_u_idx1"
yugabyte=# TRUNCATE cic;
TRUNCATE TABLE
yugabyte=# CREATE UNIQUE INDEX cic_u_idx1 On cic (c1);
ERROR: relation "cic_u_idx1" already exists
yugabyte=# SELECT indexrelid::regclass, indisvalid FROM pg_index WHERE NOT indisvalid;
indexrelid | indisvalid
------------+------------
cic_u_idx1 | f

04
YugabyteDBの管理

YugabyteDBの管理
DBの管理には様々あるが、本資料では以下の項目について紹介する。
• クラスタの状態/情報を確認する
• yb-adminコマンドで確認する
• ノード追加と削除
• MasterとTserverを追加/削除しスケールさせる
• Web UIを使う
• Web UIで各種情報を確認する
• 監視(メトリクス監視)
• PrometheusとGrafanaと連携しメトリクスを可視化する

クラスタの状態/情報を確認する
YugabyteDBではクラスタ管理用にyb-adminコマンドが用意されている。
yb-adminではおよそ以下のことができる。DBAの作業に該当することはほぼカバーする。
• クラスタ状態の確認
• MasterやTserverの数や状態、Tabletの配置状況など
• クラスタ構成の変更
• Masterの追加やレプリケーション数の変更、Master/TserverのDecommissionなど
• テーブルやTabletの構成変更
• テーブルのレプリケーション数変更やTabletの分割、再配置など
• バックアップ/リストア
• 手動でのスナップショット取得や自動バックアップのスケジュール設定など
その他いろいろ
詳細はマニュアルを参照 -> https://docs.yugabyte.com/preview/admin/yb-admin

クラスタの状態/情報を確認する
YugabyteDB試用に際してyb-adminで多用するのは以下のコマンドとなる。
-master_addressesはMasterが複数いれば全MasterのIP:portの組を指定するのが
一般的だが、LEADERのMasterが含まれていれば良い。
-- Masterの状態を確認
$ yb-admin -master_addresses "127.0.0.1:7100" list_all_masters
Master UUID RPC Host/Port State Role
de21a4e44387425abbe4493631dbc49b 127.0.0.1:7100 ALIVE LEADER
f3514d982165448da71199cc4242bf90 127.0.0.2:7100 ALIVE FOLLOWER
bb46c71afd0242d3a8e60cd103750e9c 127.0.0.3:7100 ALIVE FOLLOWER
-- Tserverの状態を確認
$ yb-admin -master_addresses "127.0.0.1:7100" list_all_tablet_servers
Tablet Server UUID RPC Host/Port Heartbeat delay Status Reads/s Writes/s Uptime SST total size SST uncomp size SST #files Memory
3ba6f5f1545c4052ae69403d253c0328 127.0.0.3:9100 0.76s ALIVE 0.00 0.00 1132 80.83 KB 190.31 KB 1 64.65 MB
1e22539c24f548f6b63d232391eb9476 127.0.0.2:9100 0.76s ALIVE 0.00 0.00 1142 80.83 KB 190.31 KB 1 82.25 MB
4b2534e0864142b2a0706bd388e40896 127.0.0.1:9100 0.76s ALIVE 0.00 0.00 1162 80.83 KB 190.31 KB 1 77.32 MB
-- Tabletの状態を確認
$ yb-admin -master_addresses "127.0.0.1:7100" list_tablets ysql.test1 t1
Tablet-UUID Range Leader-IP Leader-UUID
3e7bf5ea759147859dc7f5a2292521c0 partition_key_start: "" partition_key_end: "H¥200¥000¥003¥350!" 127.0.0.2:9100 1e22539c24f548f6b63d232391eb9476
9559e27874824a39b2f301223ff00fbf partition_key_start: "H¥200¥000¥003¥350!" partition_key_end: "H¥200¥000¥013¥270!" 127.0.0.3:9100 3ba6f5f1545c4052ae69403d253c0328
2ee47bf19fb04858b09a17ed71463a35 partition_key_start: "H¥200¥000¥013¥270!" partition_key_end: "" 127.0.0.1:9100 4b2534e0864142b2a0706bd388e40896
テーブルやTabletの状態確認、変更を行う場合、DB(Keyspace)を指定するが、
ysql.dbname or ycql.keyspacenameのように修飾が必要になるので注意

ノード追加と削除
YugabyteDBではMasterとTserverを適宜クラスタへ追加することで冗長性や性能の向上を
実施できる。以下、テーブルを明示的に4つのTabletで作成し、ノード追加によるそれらTabletの
Leaderが均等にリバランスしている様子をコマンド結果で示す。
-- 以下は1台のローカルマシン上で3つのMasterとTserverを起動しクラスタを構成
$ yugabyted start --base_dir=/home/yugabyte/ydata/node1 --listen=127.0.0.1
yugabyte=# CREATE TABLE t1 (c1 int primary key, c2 text) SPLIT INTO 4 TABLETS;
CREATE TABLE
yugabyte=# INSERT INTO t1 SELECT generate_series(1,10000), 'AAA';
INSERT 0 10000
yugabyte=# ¥q
$ yb-admin list_tablets ysql.yugabyte t1
dc7ad7e2988742a8861b4c224e66b05a partition_key_start: "" partition_key_end: "?¥377" 127.0.0.2:9100 68c0f30f937140a9a0d1449e9c5cc01d
3739b68f0035419eb2b8d2e57937cef3 partition_key_start: "?¥377" partition_key_end: "¥177¥376" 127.0.0.1:9100 44ea2d19ea0b469184a0640713796f3b
82b1ef5f90604bc6a7a204953247b52e partition_key_start: "¥177¥376" partition_key_end: "¥277¥375" 127.0.0.2:9100 68c0f30f937140a9a0d1449e9c5cc01d
69b32c5c0ae441e8ade3bd46f923732c partition_key_start: "¥277¥375" partition_key_end: "" 127.0.0.3:9100 a8f45172236f451190cc55a74c41ceba
4つのTabletが3つのノードに配置されている

-- もう1台のTserverを起動しクラスタに追加
82b1ef5f90604bc6a7a204953247b52e partition_key_start: "¥177¥376" partition_key_end: "¥277¥375" 127.0.0.4:9100 767b16ee4ac84184a27e08fef1cd0d01
69b32c5c0ae441e8ade3bd46f923732c partition_key_start: "¥277¥375" partition_key_end: "" 127.0.0.3:9100 a8f45172236f451190cc55a74c41ceba
4つのTabletが新規に追加されたノード(127.0.0.4)を
含めた4ノードにリバランスされた

次に、ノード削除を行い削除対象のTserverノードにいたLeaderが別のノードに移る様子を見る。
-- yugabyted destoryでNode3を停止しデータディレクトリを破棄する
$ yugabyted destroy --base_dir=/home/yugabyte/ydata/node3
Stopped yugabyted using config /home/yugabyte/ydata/node3/conf/yugabyted.conf.
Deleted logs at /home/yugabyte/ydata/node3/logs.
Deleted data at /home/yugabyte/ydata/node3/data.
Deleted conf file at /home/yugabyte/ydata/node3/conf/yugabyted.conf.
82b1ef5f90604bc6a7a204953247b52e partition_key_start: "¥177¥376" partition_key_end: "¥277¥375" 127.0.0.4:9100 767b16ee4ac84184a27e08fef1cd0d01
69b32c5c0ae441e8ade3bd46f923732c partition_key_start: "¥277¥375" partition_key_end: "" 127.0.0.1:9100 44ea2d19ea0b469184a0640713796f3b
削除されたノード(127.0.0.3)がLeaderだったTabletが
別のノードに変更された

ノード全体の停止について
注意点として、クラスタ全体を綺麗にシャットダウンする機能は今のところない(ように見受けられる)。
これはTODOとなっている。従って大規模データでクラスタを組んでいる場合にYugabyteDBのクラスタ全体の起動と停止を行う
場合は注意が必要。
https://github.com/yugabyte/yugabyte-db/issues/10664

Web UIを使う
YugabyteDBではMasterとTserverのぞれぞれにWeb UIを備えている。
Web UIへはMasterやTserverが稼働しているホストの7000 or 9000ポートにブラウザでアクセスする。
操作はできないが、MasterやTserverのノード数や状態、テーブルやTabletの状態を確認することができる。

Web UIを使う (テーブルとインデックスの情報)

Web UIを使う (Tablet Serverの情報)

Web UIを使う (Debug情報)
メモリ使用量やスレッドの稼働状況などがかなり細かく分かる。GFlagsで現状のパラメータ設定が確認可能。

PrometheusとGrafanaとの連携
YugabyteDBではMasterとTserverがPrometheus用のフォーマットでメトリクスを出力する
エンドポイントを備えている。またGrafana用のサンプルダッシュボードも提供している。
そのためPrometheusでそれらを対象にスクレイピングを行い、主要なメトリクスをGrafanaで可視化することが容易である。
この資料ではPrometheusとGrafanaをそれぞれ入手して最もシンプルな利用方法を説明する。
ポート番号エンドポイント説明
7000 (Master)
9000 (Tserver)
13000 (YSQL)
12000 (YCQL)
/metrics Master、Tserver、YSQL、YCQLそれぞれのメトリクスをJSONの形
で出力するエンドポイント
/prometheus-metrics 同上のデータをPrometheusフォーマットで出力するエンドポイント
13000 (YSQL) /statements PostgreSQLのpg_stat_statementsと同様のデータをJSONの形
式で出力するエンドポイント

以下のように最新版のPrometheusとGrafanaを入手し、
提供されているサンプルの設定を利用する。
$ cd download
$ wget https://dl.grafana.com/enterprise/release/grafana-enterprise-9.2.2.linux-amd64.tar.gz
$ tar zxvf grafana-enterprise-9.2.2.linux-amd64.tar.gz
$ wget https://github.com/prometheus/prometheus/releases/download/v2.39.1/prometheus-2.39.1.linux-amd64.tar.gz
$ tar zxvf prometheus-2.39.1.linux-amd64.tar.gz
$ cd prometheus-2.39.1.linux-amd64
$ ./prometheus --config.file=prometheus-yugabyte.yml &
$ cd ../grafana-9.2.2
$ ./bin/grafana-server web &
https://docs.yugabyte.com/preview/explore/observability/prometheus-integration/linux/ の
prometheus用のymlファイルを改変(スクレイプ対象のIPなどを変更)して利用すると良い。
本資料では「prometheus-yugabyte.yml」としている。

Prometheusが無事稼働していれば、稼働させたノードのポート:9090にブラウザで
アクセスすると以下のようなページが表示される。(PromQLで問い合わせは可能)

Grafanaの設定に関しては通常の(他の製品と同様の)手順となる。
ここではGrafanaを起動してブラウザでアクセスするところから解説する。
ブラウザでGrafanaの起動しているサー
バのポート(デフォルト3000)にアクセス。
ID/passはadmin/adminが初期値。
赤枠のメニューから「Data Source」を選択

Data SourceにPrometheusを選択し、
URLでPrometheusの稼働している
サーバとポート(デフォルト9090)を指定
下部の「Save & Test」を押下。
(上記のようになる)

Dashboardsを選択し、Grafana.com
にアップロードされているYugabyteDB
用のひな型(12620)を指定しLoadする
下部でPrometehusを指定しImportを押下する

ここまでの手順でDashboardが利用可
能になっている(はず)

pgbenchで負荷をかけてメトリクスを眺めてみる
-- 初期化(ベンチマーク用のテーブルとインデックス作成、およびデータロード)
$ pgbench -i -s 1 -h 127.0.0.1 -p 5433
-- ベンチマーク実施(-n: VACUUM不要、-T: 実施時間、-c: 同時実行数、-P: 指定間隔での性能レポート出力)
-- Read Committed以外のトランザクション分離レベルの場合、開始時にエラーが出る
$ pgbench -n -T 1200 -c 4 -P 10 -h 127.0.0.1 -p 5433
progress: 10.0 s, 364.4 tps, lat 2.730 ms stddev 0.783
(中略)
(中略)
(中略)
number of transactions actually processed: 426127
latency average = 2.816 ms
latency stddev = 0.356 ms
tps = 355.105677 (including connections establishing)
tps = 355.109373 (excluding connections establishing)

以下のようにpgbench実行中のクエリ種別ごとのレイテンシやスループットが可視化される。

注意点として、YugabyteDBが出力するメトリクスがYugabyteDB内のレイテンシとなる。
そのためクライアントとの通信や結果送信などのNWレイテンシは加味されない。性能試験などの際はメトリクスだけでなくクライアン
ト側でのレイテンシなども確認しておくと良い

05
おわりに

まとめ
本講演ではYugabyteDBの概要とアーキテクチャの簡単な説明、
および利用と管理の基本的な一連の流れを解説しました。
分散データベースは非常に取っつきにくい、扱いにくそう、というイメージがあるかもしれませんが
利用してみるだけならばとても簡単です。
YugabyteDBに限らず、昨今の類似プロダクト(TiDBやCockroachDBなど)は使い勝手を考
慮した便利なユーティリティやコマンドの充実にも力を入れています。
ぜひ、気になっている方々がいれば、実際に使ってみてください。

06
付録など

【参考】 Tabletの分割方法の指定
Tabletの分割は自動で行われるほか、テーブル作成時に予め分割しておくことも可能。
分割はHashかRangeとなるが、主キーやインデックスの定義方法で決まることになる。
Range SplitのテーブルにHash Splitのインデックス定義なども可能。
-- 主キーをASC/DESC付きでソートしたものを定義した場合はRange Splitとなる
yugabyte=# CREATE TABLE r_t1 (c1 int, c2 text, primary key (c1 ASC));
CREATE TABLE
-- 主キーのデフォルト(ASCなどを付与しない)定義ではHash Splitとなる
yugabyte=# CREATE TABLE h_t1 (c1 int, c2 text, primary key (c1));
CREATE TABLE
-- インデックスも同様のルール。なおRange Splitの場合は作成時にSplitの境界値を指定できる
yugabyte=# CREATE INDEX r_t1_idx ON r_t1 (c2 ASC) SPLIT AT VALUES((1000),(2000));
CREATE INDEX
-- Hash Splitの場合は作成時に分割数を指定できる
yugabyte=# CREATE INDEX h_t1_idx ON h_t1 (c2) SPLIT INTO 4 TABLETS;
CREATE INDEX

【参考】 YugabyteDBのデータディレクトリ (yb-data)
YugabyteDBのMasterとTserverそれぞれで扱う実データは基本的にDocDBに格納される。DocDBはTabletの単位でイン
スタンスが作成されるため、Tabletの数だけDocDB用のディレクトリが存在する。
また、内部的にノード間はProtocol Bufferを利用してデータのやり取り(read/write, replication, consensusなど)がされ
るため、そのデータのメタデータもデータディレクトリに格納される。
var/data/yb-data/
|-- master
| |-- consensus-meta < -- Tablet毎のRaftコンセンサスのメタデータ
| |-- data < -- Tablet毎のDocDB(RocksDB)の実データ
| |-- logs < -- ログファイル
| |-- tablet-meta < -- Tablet毎のメタデータ
| `-- wals < -- Tablet毎のWAL(Write Ahead Log)
`-- tserver < -- 以下はTservertのデータだが区分けはMasterと同様
|-- consensus-meta
|-- data
|-- logs
|-- tablet-meta
`-- wals

【参考】 YugabyteDBのデータディレクトリ (rocksdb)
「var/data/yb-data/tserver/data/」配下には、YugabyteDBのTserverのユーザデータ(ユーザが作成したテーブルなど)
が格納される。以下のように「rocksdb」ディレクトリの下に「table-<UUID>」ディレクトリがテーブルとインデックス(主キーは除く)
の数だけ作成され、その下に「tablet-<UUID>」のディレクトリが作成される。
var/data/yb-data/tserver/data/
`-- rocksdb
|-- table-000033e8000030008000000000004008 < -- Table(3つのTabletを持つ)のディレクトリ
| |-- tablet-39ae7e99082e4e2483d9909131a67155 < -- Tabletのデータ
| |-- tablet-39ae7e99082e4e2483d9909131a67155.intents < -- 同名Tabletのロックなどのデータ
| |-- tablet-39ae7e99082e4e2483d9909131a67155.snapshots < -- 同名Tabletのスナップショットデータ
| |-- tablet-3c47e9b44d25408f9765231ba6fedbc7
| |-- tablet-3c47e9b44d25408f9765231ba6fedbc7.intents
| |-- tablet-3c47e9b44d25408f9765231ba6fedbc7.snapshots
| |-- tablet-ce93f09488d94b109f09f05e434470ff
| |-- tablet-ce93f09488d94b109f09f05e434470ff.intents
| `-- tablet-ce93f09488d94b109f09f05e434470ff.snapshots
|-- table-000033e8000030008000000000004003
(略)

【参考】メタデータのダンプ
YugabyteDBではメタデータのダンプを行う yb-pbc-dumpコマンドを提供している。以下のようにメタデータファイルを引数として
渡すことで、中身をJSON形式で確認することができる。
$ yb-pbc-dump var/data/yb-data/tserver/tablet-meta/39ae7e99082e4e2483d9909131a67155
yb.tablet.RaftGroupReplicaSuperBlockPB 0
-------
primary_table_id: "000033e8000030008000000000004008"
raft_group_id: "39ae7e99082e4e2483d9909131a67155"
tablet_data_state: TABLET_DATA_READY
partition {
partition_key_start: "¥252¥252"
partition_key_end: ""
}
wal_dir: "/home/yugabyte/var/data/yb-data/tserver/wals/table-000033e8000030008000000000004008/tablet-
39ae7e99082e4e2483d9909131a67155"
kv_store {
kv_store_id: "39ae7e99082e4e2483d9909131a67155"
rocksdb_dir: "/home/ yugabyte/var/data/yb-data/tserver/data/rocksdb/table-000033e8000030008000000000004008/tablet-
39ae7e99082e4e2483d9909131a67155"
tables {
table_id: "000033e8000030008000000000004008"
table_name: “t1"
table_type: PGSQL_TABLE_TYPE
(略)

【参考】 WALデータのダンプ
YugabyteDBではWALデータのダンプを行う log-dumpコマンドを提供している。以下のようにwalファイルを引数として渡すこと
で、中身をJSON形式で確認することができる。
$ log-dump var/data/yb-data/master/wals/table-sys.catalog.uuid/tablet-00000000000000000000000000000000/wal-000000001
Header:
major_version: 1
minor_version: 0
unused_tablet_id: "00000000000000000000000000000000"
sequence_number: 1
(中略)
1.753@6836335657396293632 REPLICATE WRITE_OP, SIZE: 211
1.754@6836335657458892800 REPLICATE UPDATE_TRANSACTION_OP, SIZE: 96
id { term: 1 index: 754 } hybrid_time: 6836335657458892800 op_type: UPDATE_TRANSACTION_OP committed_op_id
{ term: 1 index: 753 } monotonic_counter: 0 transaction_state { transaction_id:
"¥313I¥217¥266¥333¥340M¥213¥252¥311¥2003¥275¥213¥r¥337" status: APPLYING tablets:
"722f625cf0224b69b4a2082d68880329" commit_hybrid_time: 6836335657455751168 sealed: false aborted { } }

【参考】パラメータについて
YugabyteDBではMaster、Tserverそれぞれで非常に多くのパラメータが設定できる。
パラメータの中には動的に変更できるものなどもあるが、マニュアル上から読み解くことが難しい。
パラメータについてはXMLの形式だが資材ディレクトリ(インストール時に入手したtar.gzを解凍した配下)に配置される
master_flags.xmlとtserver_flags.xmlに詳細情報がある
以下のようにXMLをパースしてmodeを確認し、「runtime」とラベル付けされていれば動的変更が可能。
$ cat yuga-param.pyc
################################
import sys
import xml.etree.ElementTree as ET
for param in ET.parse(sys.stdin).getroot().findall('flag'):
name = param.find('name').text
mode = param.find('tags').text
print ("name:[", name, "] mode:[", mode, "]")
################################
$ python yuga-param.pyc < yugadb/yugabyte-2.15.2.1/master_flags.xml | grep runtime
(略)
name:[ ysql_index_backfill_rpc_timeout_ms ] mode:[ runtime,advanced ]
name:[ ysql_num_tablets ] mode:[ runtime ]
name:[ ysql_tablespace_info_refresh_secs ] mode:[ runtime ]

【参考】 yugabytedコマンドのその他ポイント
• yugabytedで3つ以上のMaster/Tserverを起動し—joinオプションでクラスタを構成すると、
自動的にreplication factorを3に設定し、冗長構成としてくれる
• ただしMasterは4つ以上の構成にしない(Tserverは4台上の追加がされる)
• Masterを4つ以上とするクラスタを構成する場合は手動でyb-masterを起動しクラスタに参加させる必要がある
• Tserverを4つ以上に増やしていってもreplication factorは3から変更されない
• replication factorを変更する場合は別途tserver_flagsオプションで変更する必要がある
• master_flagsやtserver_flagsオプションの指定は非常に長くなりやすく、かつクォート/ダブルクォートの指定が(正しい文法で
あっても)一部のケースでエラーで弾かれることがある。
• 以下のようにconfファイルを作成し、--tserver_flags=flagfile=/path/to/conf_fileという方法を取ると良い。
$ cat /tmp/tserver_flg.conf
--yb_enable_read_committed_isolation=true
--ysql_beta_features=true
--ysql_pg_conf_csv=password_encryption=scram-sha-256
--ysql_hba_conf_csv=host all kasa 127.0.0.1/32 scram-sha-256,host all all 0.0.0.0/0 trust,host all all ::0/0 trust
$ yugabyted start --tserver_flags=flagfile=/tmp/tserver_flg.conf

【参考】 ycqlshによる接続と操作
YugabyteDBのYCQLでの接続はycqlshコマンド、もしくはCassandra用のドライバや
コマンド(cqlshなど)を利用可能。
$ ycqlsh
Connected to local cluster at 127.0.0.1:9042.
[ycqlsh 5.0.1 | Cassandra 3.9-SNAPSHOT | CQL spec 3.4.2 | Native protocol v4]
Use HELP for help.
ycqlsh> DESCRIBE KEYSPACES;
system_auth system_schema system
ycqlsh> CREATE KEYSPACE test;
ycqlsh> USE test;
ycqlsh:test> CREATE TABLE t1 (c1 int primary key, c2 text);
ycqlsh:test> INSERT INTO t1(c1, c2) VALUES (1, 'AAA');
ycqlsh:test> SELECT * FROM t1;
c1 | c2
----+-----
1 | AAA
(1 rows)
基本的にCassandraと同じ
シンタックスであればほとんど実行可能。

トランザクション処理可能な分散DB 「YugabyteDB」入門（Open Source Conference 2022 Online/Fukuoka 発表資料）

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a トランザクション処理可能な分散DB 「YugabyteDB」入門（Open Source Conference 2022 Online/Fukuoka 発表資料）

Similar a トランザクション処理可能な分散DB 「YugabyteDB」入門（Open Source Conference 2022 Online/Fukuoka 発表資料） (20)

Más de NTT DATA Technology & Innovation

Más de NTT DATA Technology & Innovation (20)

Último

Último (8)

トランザクション処理可能な分散DB 「YugabyteDB」入門（Open Source Conference 2022 Online/Fukuoka 発表資料）