Created
December 4, 2018 12:32
-
-
Save chokkoyamada/a940e1087b9802d48e72ac467ff1cbf0 to your computer and use it in GitHub Desktop.
2018/12/04 Japan Container Days でのVitessについてメモ
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
関連Tweet | |
https://twitter.com/search?f=tweets&q=%23containerdaysjp%20vitess&src=typd | |
資料はあとでアップされると思いますが、7割ぐらい下記と同じです。Vitess のパフォーマンスと運用性を検証してみた - Speaker Deck | |
https://speakerdeck.com/cotoc/vitess-falsepahuomansutoyun-yong-xing-wojian-zheng-sitemita | |
この方が作者なのでフォローしてると追えるかと https://twitter.com/Cotoc88 | |
# 以下、山田のメモ | |
早川さん 茂さん | |
日本オラクルソリューションエンジニア | |
日本オラクルの人間ではるが会社と関係なく発表する | |
CNDJP | |
CloudNativeDevelopersJpのコミュニティとして活動した成果の発表 | |
*目次 | |
Vitessとは | |
Vitessのアーキテクチャ | |
シャーディングの仕組み | |
検証してみた | |
#Vitessとは | |
MySQLをシャーディングして複数に分散するためのソフトウェア | |
YouTubeがProductionで使っていたがOSSになった | |
Slackも使っている | |
CNCFでIncubating | |
VitessはK8sに完全依存はしていないが、今回はK8s上で使う想定で検証 | |
##特徴 | |
パフォーマンスがすごくよい | |
潜在的に問題のあるクエリからの保護を行う | |
MySQLのクエリとのコマンドあってMySQLクライアントから普通にアクセスできる | |
検証ではSysbenchをそのまま使えた | |
#アーキテクチャ | |
VTGateが書くVTTabletをすべて統括している | |
VTGateが一番偉い | |
Tablet=MySQLDとVTTabletをセットでこう呼ぶ | |
#サポートされているクライアント | |
grpcのコネクタと、従来のMYSQLクライアントをサポートとうたわれているが | |
中の人によるとMySQLクライアントを推奨(これからドキュメント直す) | |
#シャーディング | |
Vitessは2種類のシャーディングをサポート | |
テーブルごとに複数のデータベースに分ける(垂直) | |
1つのテーブルを複数のShardに分ける(水平) | |
Vitessの肝は水平シャーディングがきちんとできること | |
では実際にVitess上でシャーディングがどう行われるか | |
VTWorker(Pod)がシャーディングを担当 VSchemaがデータをどう分割するかルールを決めている部分 | |
Keyspace=分割されているが一個の論理的なデータベースとしてみえるもの | |
##シャーディングのロジック | |
VIndexを付与した列からKeySpaceIDを算出(Hashなど複数値のサポート Hash・ Range・ Functional・ Lookup Unique ・Lookup Nonunique) | |
KeyspaceIDとShardとのマッピングに従ってデータを配置 | |
Vindexにはプライマリ・セカンダリがあるプライマリはシャーディングに使われるセカンダリはWHERE句の最適化を提供 | |
#検証してみた | |
1負荷分散による性能向上 | |
2スケーラビリティ | |
#負荷分散による性能向上 | |
100万件のテーブルデータ | |
そこに対してフルスキャンクエリーを投げてみた | |
複数Tablet(Shard)をまたがるクエリを実行 (25万件x4) | |
テーブル定義・VSchema定義は表示の通り | |
##分散クエリが帰ってくるまでの流れ | |
VTGateがすべてのVTTableをヒットする必要があると判断すると分散クエリとして認識 | |
VTGateが帰ってきたクエリをマージしてクライアントに結果を返す | |
##結果 | |
3.6倍程度には高速化している | |
#スケーラビリティ | |
OLTPクエリを実行 | |
Tabletを追加することで処理できるトランザクションが増えるかどうか | |
##ベンチマークツール | |
Sysbench | |
mysqlプロトコルでアクセス可能。中の人のお墨付き | |
テーブルは1表のみ9680件ID列がPrimary INDEX | |
クエリーは2パターン用意 | |
シンプルなものとBetweenを含むもの | |
準備として、CPUにリミットをかけた | |
##結果 | |
SimpleなクエリはShardの数を増やすことでTPSがスケールすることを確認 | |
Betweenで複数シャードに分かれるようなクエリはShardを増やしてもスケールしない | |
##エラーとの戦い・・・ | |
VitessのSlackに相談に乗ってもらって無事検証を終えられた | |
Vitess.slack.com | |
##Vitessと触れ合った感想 | |
スキーマ設計 シャーディング設計 | |
MySQLの管理チューニング | |
Kubernetesの知識 | |
Goのコードよめるとよい | |
諦めない心 Vitessコマンドは独特なため慣れが必要 | |
##Q&A | |
QPrestoと似てる? Vitessのほうが将来性がありそう? | |
Aきちんと比較できない。似たようなソリューションといえるかもしれない | |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment