MysqlClusterCasual. 20130926にいってきました
こんにちは。smallpalaceです。
最近やっと旦那さんの浴衣が完成したけど季節はもう秋です。来年着てもらおうかと。
それはともかく、、
MysqlClusterCasualに行ってきたのでその記録を。すごく面白かったです。
聞いたままメモりました。発表資料が公開されてたら追記すると思います。
ハッシュタグ： #mysql_jp
トゥギャッタ：http://togetter.com/li/569292
行った人のブログ：
http://d.hatena.ne.jp/garage-kid/20130926/mysqlclustercasualtalks
http://b.l0g.jp/mysql/mysql-cluster-casual-talks-memo/
------
梶山さんのお話から(途中から聞きました）
ACIDのKVSとしても使える
データが分散配置と二重化されたりしてく
トランザクションに求められる用件を満たしたNoSQL。
一貫性とかも保障してくれるらしい
ハイパフォーマンスもあきらめなくていいらしい。
まるで夢のような話です。
20Mqps(2000万)update/secいけるらしい。30ノードの構成で。
つかってる会社：米軍、paypal、NEC、CISCO、at&t、艦コレ、zynga等
MySQL、NoSQL
ネットワークは40GbpsのInfiniBandが必要だそう。神々の遊び、というツイートを見かけました。
apacheのmod_ndbというのがある(つかってもらえないので塩漬け状態）
予告：MySQL Connectというののフィードバック情報を得られるMyNA会がある
5.7の情報っぽいです（来週月曜）
10/25 最新情報セミナー ORACLEとして
同じ日にMySQL CasualTalksがあるよ
この先2ヶ月くらいイベント山盛りだそうです。
「MySQL Cluster 運用構築バイブル」の宣伝が。
-----
奥野さんのセミナー
「MysqlClusterをつかってみよう」
http://nippondanji.blogspot.jp/2013/09/mysql-cluster-casual-talks-mysqljp.html
「MySQLClusterをCasualに使えるわけないじゃないか」という突っ込みから。
そうですよね。
MySQLのストレージエンジンとして使える。
ENGINE NDB;
トランザクション対応
並列分散型
HA機能
SQLノードとデータノードがある
SQLの解析のCPUの負荷も分散できる
全ノードあわせて255ノードまで。
1台の性能ではInnoDBのほうが上
ただしNDB APIは爆速
ノードを並べてなんぼ
データノード
負荷分散
データ量の増加
SQLノード
SQL解析の負荷分散
ノードを増やしても性能が伸びない処理もある
少ししかとってこないスキャンとか
できること
高可用性
SPOF排除
HA機能
DR
パフォーマンス
スケールアウト
リアルタイム処理
NoSQL
低価格
GPL版は無償
商用ライセンスもお手ごろ
コモディディなハードウェアでも可能
管理ノード
クラスタの構成情報を管理
各種操作を発行
データノード
データとトランザクションをつかさどる
データノードのなかのデータ配置
シェアードナッシング＝NoSPOF
ノードグループごとにフラグメントが別れ、それぞれデータを分散している
ひとつこけても大丈夫
ノードグループ内でひとつこける文には大丈夫。同じグループ内で両方こけるとダメ。
インストール
パッケージをとってくる
config.ini(管理ノード）とmy.cnf（SQLノード）を書く
プロセスを起動する
管理→SQL→データ
インストールのデモ
そんなにカジュアルではなかった。
パフォーマンスの勘所
単純に言うとInnOBと特性が違う。処理の得手不得手がある。
最新のバージョンをつかいましょう
バージョンが新しいほど高速化している
TC(データノードのトランザクションコーディネータ)の選択ロジックが改善されたり色々あるらしい
7.0からデータノードのオンライン拡張ができる
7.1からndbinfoでパフォーマンス情報がとれるように
7.2からpushdown joinというので早くなった
7.3から外部キーが使えるようになった。NDBAPIのボトルネック解消したらしい。
30データノードで、19.5Mtransactions/sec、
スレッドのチューニングができるようになった
主キーを使った検索はデータノード数に応じてスケールする。
データノードは最大48台まで。
スキャンは弱い。なぜならデータはすべてのノードに分散しているから。
フェッチするレコードが多い場合、並列処理ができるのでスキャンでも悪くない。
どうやって問題を解決するかというと、
ユーザ定義パーティション。だんだんカジュアルではなくなってきた。
user_idをパーティションのキーにするとスキャンがスケールアウトする
特定のデータノードにだけアクセスすればよくなるので高速に。
レプリケーションによるスケールアウト
スキャンの処理はInnDBのスレーブ側でやると少しカジュアルな感じ。
SQLノードにバイナリログを生成させればレプリケーションが可能に。
インメモリデータベースだけれども、早いディスクのほうがいい
データの永続性のためにたくさんのI/Oが発生するため
更新を記録するGCP（REDOログ）
LCP（定期的にメモリのイメージをディスクに書き出す処理）
ディスクテーブル
FusionI/Oの人に貸してもらってベンチしてみてた結果
fioはメモリに近い性能が出てた
BLOBは苦手
内部的にBLOB用のテーブルが作成される
JOINが増えるのと同じ
なるべくつかわず
varcharでがんばる
SQLよりも数段早いNoSQLインターフェース
３．memcachedでアクセスSQLノードの代わりにmemcachedを立てる(InnDBのやつより賢い）
４．なんだっけ
こんなときにおすすめ
更新性能をスケールしたい
HA機能
超絶高速なJOINがほしい
性能の特性の違いに注意
得手、不得手がある
適切なスケールアウト戦略をえらぶべし
・休憩時間に繰り広げられた@kamipoさんと奥野さんのガチンコな質疑応答
Q:SQLノードが接続した時点でデータノードをどうやって見つけるのか？
A:my.cnfのなかに管理ノードに接続するための情報が書いてあり、
管理ノードから情報を引っ張ってきて、起動した時点で接続されてる
Q:管理ノードは単一障害点にみえるが
A:管理ノードは2つにできるし落ちても影響ない
フェイルオーバーはデータノード自身がやる
アービトレータという機能があり、管理ノードしか設定してないときには
SQLノードもアービトレータになれる、ネットワークパーティションやスプリットブレイン起きたときに引き継ぐとか
Q:レプリケーションしてるときにマスタとスレーブのエンジンをかえるのはよくないとかある？
InnDBの性質をかんがえてこういうスキーマにしなきゃいけないとかあるのかな？
A:やってみていければ大丈夫、動くかどうかはテストをしてみましょう。
性能の特性の違いについては、メインをクラスタで弱いところだけInnoDBと考えたほうがいい。
スキャンしたいテーブルだけレプリケーションするとか工夫を色々すると良い。
Q:インデックスちゃんと張られてないつかってないクエリがきたときが恐怖？
A:データベース設計しっかりやればスキャンもそこまで発生しないはず
ちょっと色々メモりきれませんでした。
盛り上がってきたところで休憩時間おわりに。
-----
桜田さんのおはなし
@tsakurada
MySQL Clusterを2009年頃から4年も運用してるそうです。
スライド：http://www.slideshare.net/TakeshiSakurada/mcct20130926-tsakuradac
・選択
なぜMySQLClusterか。更新系が早いのがいい。IAサーバでスケールアウト、ミッションクリティカル。
インメモリDB確かに早い。今となってはIoDrive+innodbでもかなり高い性能でちゃうので優位性が出しづらい
メモリがたくさん載ってるサーバは高いのでそんなにコモディティでもない
スケールアウトでつかいづらいところもある
HA的にはほかにない。F/Oとても高速で数秒で完了する
いくつかポイントを抑えないと意味がないかも
改めて主張したい優位点
GPLで無償。Inndbとの互換性がV7.3からかなり向上した。
NDB単体でもトランザクションが使える、NoSQLとして使える
・導入
最小構成は全部一個ずつあればOK(検証用）
冗長構成だと全部2つずつ必要。実質サーバ4つあればそこそこいけると思われる
データ量が多くなってきたらデータノードを増やすメモリを増やす
スケールアウトのことも考えてデータノードを増やすのがいい
MysqlClusterとして使いたい場合データノードの増やしすぎに注意
SQLノードはいっぱい増やしても大丈夫
実行中のクエリ(トランザクション）がキャンセルされたとき、
エラーをキャッチして後続処理を適切に作りこむ必要があります。
リトライ、中断、一時的な不整合を許容して後から自動的にリカバリするバッチを定期実行するなど
アプリ側で考慮しなければならないことが。
InnDBと同じ感覚でテーブル設計していいのか
そのままもってくるとだめかも
トランザクションの分離レベルも違うので注意が必要
高可用性のレベルがInnDB側に引っ張られることになるのでそれをどう保障するかを考える必要がある
・運用
なにが起きるか？
→GCP stop!
GlobalCheckPoint デフォルトだと2秒ごとにHDDにメモリ上の更新ログを書き出していますが、
コレが何らかの理由でとまるとデータノードがシャットダウンする
UPDATE t set xx where xxx
一度のコミットにかかる時間が一定閾値を超過した場合に発生することがある。
かかる時間と件数を事前にアプリ側で把握してないとだめ
7.3では無制限の閾値にできるがDBが固まるかも。
→ローリングリスタート
NDBのパラメータ変更を反映するためにデータノードの再起動が必要なものがある
再起動が高速であれば問題にならないが、データ量が多くなってくると
100GBoverだと数十分～2時間とかかかることも。
リスタート中はDDL文は発行できない
最新バージョンでは起動時間も高速化しているらしい
多重障害をどこまで考慮するかNDBで一番悩ましいのがこのポイント。
→ボトルネックがみえずらい
vmstatとかiostatとかつかうが、NDBの場合ボトルネックがみえずらい。
一見なにも問題なさそうなのにサチレーションが発生するなど
slowログで通常遅くならないselectがでてきたりする
確認ポイントとしては
データノードで異常が起きていないか、SQLノードで異常が起きていないか、などなど
データのライフサイクルをどうするか
メモリを節約するためには削除したいがDELETE遅い
あいた領域が同じテーブル内でしか再利用されない仕様なので要注意(他でつかうにはローリング再起動必要
→バックアップはいいけどリストアが。。
NDBには専用のオンラインバックアップ機能があります
ロールフォワードリカバリにはbinlogをつかう
しかしバックアップをリストアするには時間がかかる
100GBあるとおそらく半日以上（ndb-restoreみたいなコマンド）
ただ、通常は片方のデータノードが生存していてそこからオンラインで
データを複製・フェイルバックするほうが多いと思われる
相方が死んだほうがrepがとまるので性能アップする
僕達とオラクルさんでだいぶ地雷を撤去したのでそろそろカジュアルに使えると思います
心配な人はライセンスかったほうがいいかな。
------------
山崎さん オラクルのセールスコンサルの人
スライド： http://www.slideshare.net/yoyamasaki/5mysql-cluster
MySQL Cluster Auto installer
のデモ
赤と青のターミナル画面に気をとられましたが、ブラウザで進められるのはいいなと思いました。
奥野さんの本がおススメ
さくらのクラウド2万円分無料券もらいました。ありがとうございました。
GMOのイベントでカジュアルにさくらの無料券が配られるという。
-------
yoku0825さんの高速LT
http://www.slideshare.net/yoku0825/ndbcluster
７．２
10/04にMyNAのやつがある
10/19にOSC
XtraDBXCluster面白いです
マルチマスター
ほとんどメモれなかったです。
------
個人的には、以前からMySQL Clusterは知ってはいました。
きっかけは、某社のオンラインゲームの運用がめんどくさいからやらないかという話が来たこと。
それを受けるかどうかで調べてみて、ライセンス買ってくれないなら問い合わせできないから無理そうですと回答して終わった話です。
無理だと思った理由としては、難しそう、受けても引継ぎ困難になるのが目に浮かんだとかそんな感じです。
その後も高可用性の点でどうなのと社内の人に聞かれたりしましたが、その時点では、JOINが苦手とか
内部ネットワーク10GB必要とか最低3台からとか専任の担当者が必ず必要になるほど運用に手間がかかる、
というような情報があって、それを伝えた時点でじゃあいいやとなるのでした。
その後JOINについては改善されたんだなとわかってよかったです。
Twitterでの反応で、面白く共感したのが、
人類が使いこなすには早すぎるテクノロジーっぽい、
夢の話が胃の痛い話になってる、
40MbpsのInfiniBandとか神々の遊び、
というようなつぶやきでした。
まあそうだよね。そうおもうの私だけじゃなくてよかったです。
このプロダクトが必要とされるのはもっとこう元々オラクルつかってるような
官公庁とかライフラインにかかわるような領域のシステムたちではなかろうか。
そっちからなら破格の値段ですねーという話になるんじゃないのかと思いました。
もうすこしお金持ちで高可用性を必須とするお客様に売れそうな気がします。
では、読んでいただいてありがとうございました。
また機会がありましたら何か書きます。
