DB Tech Showcaseで発表したスライドを公開しました：MySQL Cluster 7.4で楽しむスケールアウト

表題の通り、MySQL Cluster 7.4で楽しむスケールアウトというタイトルのスライドを公開した。

MySQL Cluster 7.4で楽しむスケールアウト @DB Tech Showcase 2015/06 from Mikiya Okuno

OSC広島と中国地方DB勉強会に参加しました。

かねてから予告していた通り、OSC広島と中国地方DB勉強会（第5回）に参加させて頂いた。両方のイベントがこの土日で連続して行われたので、いずれのイベントにも遠方からの参加者がたくさんいて盛況だったように思う。OSC広島ではデモマシンの展示を、中国地方DB勉強会ではスライド（MySQLのトラブルシューティングについて）の発表をそれぞれやらせて頂いたので、今日はその報告をさせて頂こう。

Dbtech Showcase 2013で使用したスライドを公開しました。

11月は非常に多忙な月であった。セミナーでの発表を3つこなすというのは、私のペースからするとかなり無茶だったかも知れない。反省。

さて、スライドを公開する順序が前後してしまったが、11月に発表したひとつめのセミナーがDbtech Showcase Tokyo 2013だ。発表内容はMySQL Clusterに関するもので、題して「MySQL Cluster 徹底活用術」だ。どのようなシーンで利用できるかというコンセプトのもと、構成や性能、運用といったトピックについて解説している。

MySQL Cluster Casual Talksで使った資料を公開しました。 #mysql_jp

昨夜、MySQL Cluster Casualにおいて、「カジュアルにMySQL Clusterを使おう」というタイトルで発表をした。その資料をスライドシェアにアップロードしたので、カジュアルにMySQL Clusterを使ってみたい人は参考にして頂きたい。

隙がなくなったMySQL Cluster 7.3登場！！これで勝つる。

MySQL Cluster 7.3の正式版がリリースされた。このバージョンで追加された新機能は少ない。だが、これまでにリリースされたMySQL Clusterのバージョンの中で、この7.3こそが最も重要なバージョンである！と私は考えている。新機能は少ないが非常に重要なものが詰まっているからだ。今日はMySQL Cluster 7.3の新機能について見てみよう。

MySQL Clusterに外部キーがやってくる！！

タイトルのまんまなのだが、現在最新のラボ版（アルファ相当）であるMySQL Cluster 7.3で外部キーが追加された。外部キーのサポートがないのはRDBMSにとって割と致命的ではないかと思っていたのだが、これでようやくMySQL Clusterがその汚名を返上できることになる。

MySQL Cluster構築・運用バイブル」発刊のおしらせ。

入魂書籍第二弾であるMySQL Cluster構築・運用バイブルが発売となった。一部書店では先行発売しているが、本日が正式な発売日である。Amazonでも今日から購入可能だ。サブタイトルは「仕組みからわかる基礎と実践のノウハウ」であり、MySQL経験者にとってMySQL Clusterを一から理解して頂けるような内容になっている。今では一端のエンジニア気取りの筆者であるが、MySQL Clusterに手を染めたばかりの当時は結構苦労したものだった。どのような点が分かりづらかったかという経験を活かし、MySQL Clusterのコンセプトや使い方をできるだけわかりやすく説明したつもりである。

告知：MySQL Cluster 7.2の新機能オンラインセミナー

本ブログでは新バージョンのリリースをスルーしてしまったが、先日MySQL Cluster 7.2が正式版になった。強烈な新機能を引っさげての登場だ！！

そこで、明日2月29日15時よりMySQL Cluster 7.2の新機能を紹介するオンラインセミナーを開催する。直前の告知で申し訳ないが、スケジュールの空いている人または空けられる人はぜひ参加して頂きたい。講師は梶山氏。言語は日本語だ。筆者もQ&Aサポート要員として参加する予定である。

エントリーページはこちら

皆さんの登録をお待ちしている！！

追記 2012-02-29: 皆様にご案内したURLが間違っていたようです。原因はシステムトラブルだそうです。忙しい中予定を入れて頂いた皆様には本当に^256申し訳ありません。来週の同じ時間（3月7日(水) 15時）より改めて開催する予定ですので、もしご都合が合えばそちらに出て頂けますでしょうか。誠に申し訳ございません。

MySQL Cluster 7.2については、ベータ版がリリースされていた時期からその機能が明らかになっていたので、以前解説記事を書いた。まだ読んでいない方はぜひ一読して頂きたい。（もし食指が動けばぜひMySQL Cluster 7.2を試して頂きたい。）

漢(オトコ)のコンピュータ道: MySQL Cluster 7.2見参！Webでも使える熱いヤツがやってきた。

MySQL ClusterはMySQLと比べると、かなり難しいソフトウェアではないかと思う。そのためかどうかは分からないが、MySQLと比べるとユーザー数は少ない。長年日本語の解説書は存在しなかったのが大きな要因ではないかと思っている。だが、そんな状況も近日改善される予定だ。

MySQL Clusterの日本語の解説書がもうすぐやってくる！！筆者は俺！！題して、「MySQL Cluster構築・運用バイブル」。価格、発売日は未定だが、今は絶賛仕上げ作業中である。先日カバー写真がアップされた。

価格、発売日などが決まったらあらためて告知させて頂く。

乞うご期待！！

MySQL Cluster 7.2見参！Webでも使える熱いヤツがやってきた。

前回のエントリではMySQL 5.6の新機能についてレビューを行ったが、MySQL User Conferenceに合わせる形でMySQL Clusterの新しい開発版であるバージョン7.2も発表された。一見すると追加された新機能の数は少なくMySQL 5.6ほどのインパクトはないが（というかMySQL 5.6の新機能がありすぎなわけだが）、実は7.2ではMySQL Clusterにとって非常に重要な改善がなされているのだ！

というわけで、今日はMySQL Cluster 7.2の新機能を紹介しよう。

MySQL Clusterが苦手とするJOINを如何にして克服するべきか。

シェアードナッシング型の負荷分散機能を持ち、なおかつ同期レプリケーションによるHA機能まで備えたMySQL Cluster最大の弱点といえば、JOINの遅さであろう。MySQL ClusterのJOINは偽りなく遅い。JOINを多用するアプリケーションでMySQL Clusterを利用するのはある意味マゾヒスティックな行為であると言えよう。何故MySQL ClusterはJOINが遅いのか？それはMySQL Clusterが分散データベースだからである。

ご存じの通り、MySQLにおけるJOINのアルゴリズムにはNested Loopしかない。他のストレージエンジンを利用していればそれでも十分実用に耐えうるぐらい高速なのだが、MySQL Clusterの場合はそうはいかない。JOINでは自ずとストレージエンジンからデータをフェッチする回数が増えるが、MySQL Clusterの場合レコードのフェッチはネットワークを経由しなければいけないのでここがボトルネックになってしまう。

例えば、2つのNDBストレージエンジン（MySQL Cluster）のテーブルをJOINする場合を考えよう。外部表からM行フェッチし、外部表の一行につき内部表から平均でN行フェッチする必要があるとする。その場合、外部表から1回（1回のスキャンオペレーションでデータをフェッチできる）、内部表からM回のフェッチをしなければならない。1回のフェッチにつき、ネットワーク上をパケットが往復するわけであるから、InnoDBやMyISAMのように同一ホストから（特にメモリ上のキャッシュから）データをフェッチする場合と比べてJOINは不利なのである。

ではMySQL ClusterにおいてJOINを高速化するにはどうすればいいだろうか？

単純に「ネットワーク接続を高速化すればいいじゃないか。10GbEのNICを使えば？」などと思うかも知れない。それはある意味正しいが、正しいアプローチではないと思う。確かにJOINの性能は向上するのだが、10GbEとてレイテンシは無視できないので同一ホスト上のメモリからデータをフェッチする場合より遅いのは明らかである。

少し話はそれるが、何かを処理するユニットを増強して（もしくはたくさん並べて）何とかしてしまおうというのは、いかにもBruteなやり方である。確かにハードウェアの性能向上はBruteなやり方でも良いと思うし、Bruteなやり方で成功した事例もたくさんある。例えばグラフィックスチップにたくさんの演算回路（シェーダ）を組み込んだり、ハイエンドサーバにCPUを満載したり、安価なマシンを並べてスケールアウトしたり。しかし、Bruteなアプローチではシステムの性能の限界はハードウェアの性能の限界によって頭打ちしてしまうことになる。だが一方で、ソフトウェアの性能向上を考える場合には、同じ条件のハードウェアで如何に高速化するかということを検討しなければならないと思う。つまり、もっとSmartなやり方でないといけない。ハードウェアはBruteに。ソフトウェアはSmartに。それがシステムを高速化する際のコツだろう。

そんなわけで話は戻るが、つまり単純にネットワーク接続を高速化するのは、一定の効果は上がるがすぐに限界を迎えてしまう可能性が高いのである。

現時点でも実装可能かつスマートなアプローチは、レプリケーションを利用することである。Kaj Arno氏のエントリでも紹介されているが、MySQL Clusterから通常のMySQL Serverへのレプリケーションを行い、JOINを伴う複雑なSELECTに関してはスレーブで実行することにより、複雑なSELECTを高速化するというテクニックが存在する。（詳細はKaj氏のブログエントリの図を参照して頂きたい。）スレーブへのレプリケーションは非同期なので、厳密な最新のデータに対するクエリは実行出来ないが、厳密な最新のデータが必要ない場合この方法は大抵うまくいく。システムの構築がちょっと面倒臭くなる以外弊害もない。複雑なクエリは集計データなどに利用されることが多いので、適用出来るシーンも多いだろう。

この方法で気をつけるべきポイントは、replicate[-wild]-do-tableやreplicate[-wild]-ignore-tableオプションを利用して、複製するテーブルを限定することである。そうしないとndb_apply_statusテーブルへの更新が出来ないというエラーに見舞われてしまうことになる。MySQL Clusterテーブルを更新すると、バイナリログは自動的にmysql.ndb_apply_statusテーブルへの更新が含まれてしまう。このテーブルはNDBストレージエンジンで定義されているテーブルでMySQL Cluster同士のレプリケーションに利用されるのだが、MySQL Clusterから通常のMySQL Serverへレプリケーションする場合には不要などころかエラーの元凶になるだけなのできっちりとフィルタリングしておこう。例えば、worldデータベースに存在するテーブルだけを対象にしたい場合は、スレーブのmy.cnfに次のようにreplicate-wild-do-tableを使って記述するといいだろう。

[mysqld]
replicate-wild-do-table=world.%

MySQL ClusterのSQLノード上で新規にテーブルを作成する場合、つまりCREATE TABLE tbl(...) ENGINE NDB;とした場合に、スレーブ側ではデフォルトのストレージエンジンが使用されることになる点にも注意したい。（通常のMySQL ServerにはNDBストレージエンジンは含まれていないからだ。）--storage-engineオプションを好みのもの（InnoDB等）に設定しておこう。

しかし、MySQL Clusterの開発者たちは、JOINが遅いという現状をいつまでも放置しておくつもりはない。

将来的にはMySQL ClusterのJOIN性能は大幅に改善される予定である。まず、近い将来に搭載される機能として挙げられるのがBKA（Batched Key Access）というJOIN最適化手法である。この方法では、これまで1+M回必要だったデータのフェッチが、最も効率的な場合にはたったの2回にまで減少する。2つのNDBテーブルのJOINにおいて外部表からM行フェッチし、外部表の一行につき内部表から平均でN行フェッチする必要がある場合、BKAの動作は次のようになる。

1. 外部表からM行フェッチ（一回のスキャン）
2. JOINに利用するキーの値をリストアップする。
3. リストアップされたキーをNDBストレージエンジンにPush-Downする。
4. 内部表からN行フェッチ（一回のスキャン）

内部表からレコードをフェッチする際、ICT（Index Condition Pushdown）という機能が利用されるのだが、ICTではストレージエンジンに対してフェッチしたい行を含むキーを一気に送信し、レコードを一気にフェッチするのである。その結果、MySQL Clusterではネットワーク上のパケット往復の回数が劇的に減少し、JOINの性能が向上するというわけだ。従って、BKAが実装された暁には、通常のMySQL Serverへレプリケーションするといった面倒な運用は一切不要になるだろう。少なくとも他のストレージエンジンと同等程度までJOINの性能が改善するはずであるから。

BKAブラボー！！と思うかも知れない。
しかし、そんなところで終わるようなMySQL Cluster開発チームではないのである！！

実装されるのはかなり先になるだろうが、MySQL ClusterのJOINを劇的に高速化することが出来ると予想される機能が実装される見込みである。それはDbspjと呼ばれる機能であり、言うなれば「分散JOIN」とでも呼ぶべきシロモノである。かなり貪欲な性能の追求である。MySQL Clusterは分散型のRDBMSであるから、JOINの処理も分散して行えば良いじゃないかと考えるのが人情というもであるが、一方でそのような機能を実装するのは難しいということもまた事実である。（従って現時点ではそのような機能は実装されていない。）しかし難しいというのを理由にして諦めないのが真の漢。MySQL Cluster開発チームはこの難題にチャレンジしており、既に初期段階のテスト結果が開発者Jonas Oreland氏のブログで公表されている。ぶっちゃけ通常のJOINと比べると格段に速い。MySQL Clusterの正式リリースに搭載されるのはずっと先になるだろうが、楽しみな機能の一つである。

MySQL Clusterソースコード探検隊！

これまで「MySQL Clusterの進化とその構造について」および「NDBカーネルブロックの種類」について説明した。今日はその続きとしてMySQL Clusterのソースコードについて紹介しようと思う。シグナルを交換し合うマルチプルステートマシンは間違いなくこれからの時代にフィットするアーキテクチャなので、MySQL Clusterに興味を持たれた方が「膨大なMySQL Clusterのソースコードを探検する場合にどの入り口から入ればいいのか」ということを判断する一助になればと思う。とりとめなく書いてるのであんまりまとまってないかも知れないが、その点は容赦して頂きたい。

まず、ソースコードの入手方法であるが、これは最新のソースツリーをBazaarで入手する方法と、MySQLのWebページからダウンロードする方法の2つがある。Bazaarで入手するには、次のコマンドを実行すれば良い。（Bazaarを事前にインストールしておこう。）

shell> bzr branch lp:~mysql/mysql-server/mysql-cluster-7.0

するとカレントディレクトリ以下にソースコードがコピーされる。結構時間がかかるので注意しよう。

MySQLのWebページからダウンロードするには、次のページをブラウザでアクセスしよう。

http://dev.mysql.com/downloads/cluster.html

するとプラットフォームの選択メニューが出てくるので、ZIP形式のソースコードが欲しければWindowsを、TAR形式のものが欲しければLinuxを選択しよう。一番小さいファイルがソースコードである。ソースコードのファイルはmysql-cluster-gpl-VERSION.tar.gzというような名前になっている。

MySQL Clusterのソースコードが含まれる場所は次の2つである。

• src-top-dir/storage/ndb
• src-top-dir/sql

src-top-dirはソースコードのトップディレクトリ、つまりZIPまたはTARファイルを展開したときに作成されるディレクトリ（mysql-cluster-gpl-VERSIONというような名前のディレクトリ）のことである。

storage/ndbにはndbdやndb_mgmdといったコマンドのソースコードが収められている。つまりSQLノードを除く全てのコマンドのソースコードはここにある。一方、sqlディレクトリにはSQLノードのソースコードが格納されている。ファイル名はha_ndbcluster*。（*はワイルドカード。）ここは元々mysqldのソースコードが収められているディレクトリなので、そこに居候しているのである。（将来的にはstorage/ndbへ移動したいらしいが、タスクの優先順位は低くなかなかそうならない。）肝心のNDBカーネルのソースコードはstorage/ndb以下にあるのでこちらを中心に説明する。ha_ndbcluster*には、ストレージエンジンとしてMySQL Clusterへアクセスする際に必要なソースコード、つまりmysqldがNDB APIを通じてNDBにアクセスするためのロジックが記述されているので、ストレージエンジンAPIおよびNDB API興味のある人は覗いて見るといいだろう。

ここからは、NDBカーネルのソースコードを見る際のポイントについて列挙しよう。

• NDBカーネルのソースコードの位置は、storage/ndb/src/kernelである。main()関数を含むmain.cppはこのディレクトリである。ndbdの初期化プロセスについて知りたい場合には、main.cppを見よう。
• ヘッダファイル類はstorage/ndb/include/kernel配下に収められている。C++のヘッダファイルはstorage/ndb/src/kernel以下にも含まれているが、共通のヘッダファイルはこちらのディレクトリに含まれているので注意しよう。
• storage/ndb/src/kernel/vmには、PLEX仮想実行環境のソースコードが含まれている。最も重要なのはSimulatedBlock.[c|h]ppで、ここで定義されているSimulatedBLockクラスはこれらは全てのブロックの親クラスとなる。つまり、NDBDカーネル内の各ブロックは、SimulatedBlockクラスを継承しているのである。また、SimulatedBlockが交換するメッセージは、VMSignal.[c|h]ppで定義されている。（シグナルを表すクラスはSignalである。）面白いことに、SimulatedBlockは他のあらゆるカーネルブロックへ、sendSignal()関数を通じてシグナルを送信することが出来る。同じプロセス内のブロックであろうが、他のホストで動作しているブロックであろうが、同じ方法（関数）でシグナルを送信することが出来るのである。
• storage/ndb/src/kernel/blocksには各ブロックのソースコードが含まれている。ブロックごとにサブディレクトリに分かれているので見易いだろう。ここで定義されている各カーネルブロックは、上記の通りSimulatedBlockクラスを継承している。各カーネルブロックの動作を定義しているこのディレクトリは、NDBのソースコードの心臓部と言っていいだろう。
• storage/ndb/include/kernel/BlockNumbers.hには、各カーネルブロックのIDが定義されている。ブロック番号は16ビット符号無し整数なのだが、同じく16ビット符号無し整数であるノードIDと組み合わせることで、32ビットの符号無し整数としてクラスタ全体を通じたID（BlockReference）を合成することが出来る。storage/ndb/include/kernel/RefConvert.hppにはノードIDとブロック番号からBlockReferenceへ変換するロジックおよびその逆が定義されている。（ただのビット演算だけどね！）
• storage/ndb/src/kernel/SimBlockList.cppには、作成したカーネルブロックのインスタンス化と、そのインスタンスへのポインタをリストにして保管しておくためのロジックが記述されている。ただし、NDBカーネルの各ブロックはインスタンス化された段階ではまだ初期化されず、その後STTORシグナルを受け取った時点で初期化が始まる点には注意したい。
• storage/ndb/include/kernel/GlobalSignalNumbers.hでは、各シグナルにつけられた番号が記述されている。実に700種類以上のシグナルが定義されている！（2009年10月現在）
• storage/ndb/include/kernel/signaldataディレクトリには、シグナルにおいて送信されるデータ（ペイロード）を定義するクラスのソースコードが格納されている。シグナルが送信するデータはフリーフォーマット（単なるワード列）なので、頻繁に利用されるデータについてはその構造が定義されているのである。
• storage/ndb/src/common/transporterディレクトリには、トランスポーターに関するソースコードが格納されている。トランスポーターとは、MySQL Clusterの各ノード同士が通信し合うための仮想的なインターフェイスである。これにより、通信する実際のプロトコル（TCP/IPなのかSCIなのか）に因らないロジックの記述が可能になる。
• storage/ndb/src/mgmsrvディレクトリには、管理ノードのソースコードが格納されている。特に重要なのはstorage/ndb/src/mgmsrv/ConfigInfo.cppで、このファイルには各種設定パラメーターとそのデフォルト値に関する記述がなされている。また、storage/ndb/src/mgmclientにはndb_mgmコマンドのソースコードが、storage/ndb/src/mgmapiにはNDB MGM API（設定情報をやり取りするためのAPI）のソースコードが格納されている。
• storage/ndb/src/ndbapiディレクトリには、NDB APIに関するソースコードが格納されている。

そんなわけでMySQL Clusterのソースコードのレイアウトについてとりとめもなく紹介してみた。「よし、ソースコードを見るか！」と思った時に参考にして頂けると幸いである。

MySQL Clusterカーネルの中身を覗いてみよう。

MySQL Clusterのデータノードであるndbd（もしくはndbmtd）プロセスは、内部的にはマルチプルステートマシン（ブロック）がシグナル（もしくはメッセージ）を交換するという構造になっており、高い同時実行性を実現しているということについては前回述べた通りである。今日は、ndbd内部にどのようなカーネルブロックが存在するかということについて大まかに説明しよう。前回の話を踏まえて読んで頂ければ、何となくイメージだけでも掴めるのではないかと思う。まずは次の絵を見て頂きたい。これは俺の脳内から引っ張り出したndbdの構造のイメージ図である。

矢印はブロック同士の相関関係（シグナルの送受信など）を示すのだが、この絵に描かれているものは非常に省略されたものであり、実際にはもっと複雑に絡み合っているのだということを覚えておいて欲しい。例えばQMGRやDBDICTといったブロックは、他のブロック全てとシグナル交換をするのだが、それを全て描くと何が何だか分からなくなるので省いているわけである。もし全てを描いたなら、思わず「それ何てスパゲティ？」と叫んでしまうこと請け合いである。

というわけで、以下淡々と各ブロックについて簡単に説明しよう。MySQL Clusterの各ブロックは、いくつかのカテゴリに分類することが出来るので、以下ではそのカテゴリごとに説明している。

NDBカーネルを管理するブロック

• CMVMI・・・Cluster Manager Virtual Machine Interfaceの略。OSへのリクエストを処理したり、ndb_mgmd（管理ノード）と通信をしてndbdの構成を決定する。
• NDBCNTR・・・NDB CordiNaToRの略。NDBコントローラーか？と思ってしまいがちだが、コーディネーターの意味。役割はndbd起動時の初期化とシャットダウン。
• QMGR・・・クラスタマネージャブロック。ハートビートを通じて各ブロックの状態を管理している。NDBカーネルの親玉的存在。
• NDBFS・・・ファイルシステムへのI/Oを一手に引き受けるブロック。このブロックのおかげでファイルへの非同期I/Oが容易に実装できている。

ローカルノード（自ノード）のデータを管理するブロック。

• DBLQH・・・ローカル・クエリ・ハンドラ。自ノードに対するトランザクションを処理する。MySQL Clusterのndbmtdでマルチスレッド化されたのはこのブロック。図を見れば分かると思うが、このブロックの負荷はかなり高い。（次いで負荷が高いのはDBTC）
• DBACC・・・自ノードの主キーを管理するブロック。ACCはアクセスの意味。
• DBTUP・・・データを管理するブロック。TUPはタプルの意味。
• DBTUX・・・TUple indeXの略。OrderedIndexを管理する。
• DBUTIL・・・トランザクション管理やデータ管理のための便利な機能が詰まったユーティリティブロック。

並列分散処理のためのブロック

• DBDICT・・・ディクショナリブロック。テーブルやテーブルスペース、ログファイルのメタデータの管理を一手に引き受ける。SQLノードが直接アクセス出来るブロックである。
• DBTC・・・Transaction Cordinatorの略。SQLノードからリクエストされたトランザクションの面倒を始まりから終わりまで面倒を見るブロックである。該当するデータが自ノードの担当でなければ、別のデータノードへ要求を送ったりする。
• DBDIH・・・DIstribution Handlerの略。レプリカを管理し、どのフラグメント（パーティション）がどのノードに格納されているかについて責任を持つ。また、LCPやGCPといった処理を行うのもこのノードである。
• TRIX・・・TRansactions and IndeXesの略。このブロックは内部的なトリガとユニークインデックスを管理する。MySQL Clusterはデータが複数のノードに分散しているので、行の一意性を保証するのにはどうしても分割の対象となる主キーが必要となるため、サポートテーブルという別の内部テーブルが作成される。実テーブルと内部テーブルは、トリガによって同期されるというわけである。

ディスク型テーブル用のブロック

• PGMAN・・・バッファページを管理するブロック。名前の由来はPaGe MANagerである。
• TSMAN・・・テーブルスペースを管理するブロック。名前の由来はTableSpace MANagerである。
• LGMAN・・・ログファイルグループを管理するブロック。名前の由来はLogfile Group MANagerである。

バックアップ関係

• BACKUP・・・オンラインバックアップの実行。
• RESTORE・・・取得したバックアップのリストア。ndb_restoreコマンドからデータを受け取ってリストアする。ndb_restoreコマンドは、一種のSQLノードとして動作する。
• SUMA・・・SUbscription MAnager。MySQL Server（mysqld）へバイナリログの元になるデータを送信する。

以上がNDBカーネルブロックの概要である。

ブロック同士がシグナルを交換して実現しているのは「データベース管理システム」である。各カーネルブロックは、データベース管理システムに必要な機能の要素ひとつひとつを具現化したものであると考えられるので、どのようなブロックが存在するかということはデータベースエンジニアにとって興味深いものとなっているのではないだろうか。また、MySQL Clusterのログにはブロック名がたくさん登場するので、ブロックの役割について知っていればログを見る際に役立つはずである。次回は、MySQL Clusterのソースコードのレイアウトについて説明する予定である。

MySQL Cluster進化の歴史

MySQL Cluster開発者の一人であるFrazer Clement氏がその歴史についてとても興味深いエントリを自身のブログで綴っているのだが、いかんせん英語の長文で日本人には辛いかも知れないので今日はその日本語訳を皆さんにも紹介しようと思う。進化の歴史とその結果生じた構造を知ることにより、MySQL Clusterの仕組みに興味を持って頂けると幸いである。（わかり辛いところにはところどころ訳者による注釈を入れてある。ただし翻訳は結構大ざっぱなので、英語が達者であれば細かいニュアンスなどはオリジナルのエントリを参照して頂きたい。なお、日本語訳をすることに関してはFrazer氏の了解を得ているのであしからず。）

NDB（MySQL Clusterの略称。元々はNetwork DBという名称であった。）の開発の正確な歴史について、きっと他の誰かのほうが上手く解説できると思うのだが、限られて曖昧かも知れないが私の見解を以下に述べようと思う。

• NDBは元々、EricssonのPLEXというプログラム言語が使われている環境で（EricssonのAXE交換機用に）開発された。PLEXはマルチプルステートマシン（ブロックと呼ばれる）がメッセージ（シグナルと呼ばれる）を互いに交換し合うことによって、いくつかのシステムレベルの起動、再起動、およびメッセージクラスなどのタスクを実行する構造になっている。各ブロックは内部に状態を持っており、シグナルごとにそれを処理するルーチンが定義されているという具合である。ただしブロックがサブルーチンに対してサポートしている抽象化（訳者注：定義出来る機能の実装）はごく限られたものであった。（私＝FrazerはPLEXについて、それがどのように進化したかをもっと詳しく聞きたいと思っている。）このことは、AXEのプロセッサのデザインにそのまま反映されている。AXEは常識とは異なり、シグナルバッファがソフトウェアではなくハードウェアとしてシリコン上に実装されているのである。このような「ハードコーディング」がされているため、当初NDBは最長で25 x 32ビット長のシグナルしかサポート出来なかった。
• PLEXの仮想実行環境（VM）がUNIX上のプロセスとして実行された。ブロック上で実行されるPLEXのコードはVM用のコードに逐次解釈（interpret）され、シグナルはVMによってブロックへ転送された。これにより、PLEXベースのシステムのUNIX上での開発が始まったのである。その結果、PLEXベースのシステムが容易にUNIXソフトウェアと通信することが可能になった。それぞれのVMのインスタンスはシングルスレッドのプロセスで、送られて来たシグナルをブロック内に定義されている処理シグナル処理ルーチンへ振り分けるという仕組みになっていた。 
• PLEXからC++への変換システムが設計された。ブロックが巨大なC++のクラスに変換され、シグナル処理用のメンバ関数とブロックごとのグローバルな状態がメンバ変数が定義された。PLEX環境における限られた命名規則と抽象化された機能が、C++クラス内にC言語スタイルの機能として実装された。
• VM環境は元々のPLEX/AXE環境から分岐し、NDBのベースとして独自の進化路線をとった。その結果、NDBはOSの各種サービス（通信、ディスクI/Oなど）へアクセスすることが可能となった。PLEXコードの逐次解釈（インタプリタ）機能は取り除かれ、PLEXのコードはすべてC++のコードに書き直された。VMインスタンスは各種通信経路を用いて相互に通信出来るようになり、分散システムを形成するようになった。
• このぐらいの時期にNDBとその開発チームがEricssonを去ることになった。（訳者注：Ericossonはベンチャー企業であるAlzato社を作ってNDBを独立した製品にし、さらにその後Alzato社がMySQL ABに買収されることになる。）
• ブロックの共通した機能がベースまたはユーティリティクラスへと抽象化された。これにより、ハードウェアやシステムに起因した制限が緩和され、抽象化の度合いが上昇することになる。現在では、ブロックはPLEXの（負の）遺産に悩まされることなく、C++の抽象化機能を活用して実装されている。元々存在していたブロックは全て作り直された。
• マルチスレッドのNDBデーモン（ndbmtd）が開発された。ブロックの各インスタンスが異なるスレッドで実行されるようになった。といってもこれは急激な変更ではなく、PLEX実行環境で元々採用されていた「1つのブロックを1つのプロセッサとして実装する」という設計への回帰である。（訳者注：ndbmtd内にはおよそ20種のブロックが存在し、それらが予め定められた数のスレッドで実行されている。）

というわけで、現在NDBはシグナルモデルを利用してブロックがお互いに通信するような仕組みになっているのである。シグナルはもはや25ワード長に制限されていない。シングルスレッド版のNDBデーモン（ndbd）もあり、それは全てのブロックが一つのスレッドを共有しているが、VM同士の通信やディスクI/Oなどのための専用のスレッドが実装されている。（訳者注：I/Oなどのスレッドが別途あるという意味では厳密にシングルスレッドプロセスであるわけではない。）いずれの場合にしても、ひとつひとつのブロックはシングルスレッドのままであり、スレッドは複数のブロックによって共有されている。（訳者注：スレッド対ブロックは1対Nの関係である。）

このようなブロック-シグナルモデルは、ErlangやHoareのCSPを思い起こさせる。つまり、同時実行性がシーケンシャルなプロセスがお互いに明示的なメッセージを交換し合うことによってモデル化されているようなシステムである。これは共有メモリモデル、つまりメモリへのアクセス整合性をロックやメモリ保護機能、アトミック命令などで保証するというモデルとは対照的である。もしくは、ブロック-シグナルモデルはMPIやActiveオブジェクト/Actorモデルに似ているとも言える。

明確なメッセージ交換によって同期または通信を行うのはコストが掛かる。つまり、実行時により多くのメモリコピーが発生するということである。プログラム設計時には、潜在的な同時実行制御はメッセージ交換および状態遷移というモデルで明示的に表現されていなければならず、マルチスレッドセーフな共有メモリとロックを用いたモデルよりも多くのソースコードを改変または記述する必要が生じてしまう。

しかしながら、これらのデメリットはコードの見通しがよくなるという利点によって十分に報われると思う。ステートマシン間の同期はとても見通しが良く、同期のためのコストを容易に理解することができる。明確なメッセージ交換をスレッドまたはプロセスの通信手段として利用すれば、ごく僅かな部分だけをマルチスレッドの（スレッドセーフな）カーネルとして実装するだけで済み、そのカーネルは正しく最適化されているということが保証されるであろう。そして多くのコードがシングルスレッドのスタイルで（マルチスレッドを意識する必要なく）記述することが出来る。マルチスレッドのためにライブラリを作り直す必要もない。（訳者注：ブロックがシグナルに応答する各種ロジックは全てシングルスレッドで実行されるからである。）その結果、プロセッサとシステムアーキテクチャに依存したコードおよびトレードオフが最小化されるのである。

内部的には、NDBのVMはブロック同士の通信は非同期のものだけをサポートしているが、そのような非同期のメッセージ交換を用いることは多くのメリットがある。第一に、メッセージを送信したスレッドは、そのメッセージの処理が送信先のブロックにおいて完了するのを待たなくても良いので、他に多くの作業ができる。同じスレッドを共有している他のブロックにメッセージを送った場合は自らが送信したメッセージを即座に処理するということもあるだろう。これにより、CPU内のデータおよび命令キャッシュが最大限に活用され、コンテキストスイッチが減少し、デッドロックの可能性が低減することになる。ブロッキングI/O（ネットワークおよびディスク）は専用のスレッドプールへ処理が割り振られるため、シグナルを処理するスレッドがブロックすることは絶対にない。（ただし保留中のシグナルがなくなった場合にはスレッドが停止する）システムの応答性は、優先付けされたジョブキューを使い、どのジョブを先に処理するべきかということを決定して各種ジョブに掛かる時間を最小化することによって実現している。形式的な見方をすれば、スレッド同士が相互作用する必要のある状況は、スレッドが同時に実行されている状態とほぼ同等まで減少することが可能となる。つまり、スレッド同士の同期はシグナル処理の境界だけで必要なのである。このように、前述のような制限は、（シングルスレッド処理に起因する）システムの正しさやタイミング特性（応答性の向上）を容易にするのである。

しかしながら、このような非同期で、イベントドリブンなスタイルの開発はとても難しいというのもまた事実である。全てのブロッキング操作（ディスクアクセス、ブロックされる通信、他のスレッドやプロセスへの要求など）をリクエストとレスポンスのペアとして実装しなければならないからである。また、広く一般的に使われる数多くのデータ構造やアルゴリズムは単一の（その処理を開始したスレッドの）スタックを（データを格納したり関数の引数を渡したりするために）利用するという前提に立っているが、このようなメッセージ交換によりシステムを実装するとそれらのデータ構造やアルゴリズムを活用することが出来ない。また、非同期のスタイルで開発されたソフトウェアはこまごまとした詳細が分からず、つかみ所がないため新しい機能を設計するのは時として難しい場合がある。その上、抽象化の深いレイヤーでのコードであっても、並列化が可能なものであれば常に最もレベルの浅い呼び出し元（コールポイント）までリターンしなければならないため、非同期のシステムは構造が平坦になってしまいがちである。（訳者注：つまりスタックが深くなることはない。）このような構造をとることによる副作用は、エラー処理のコードがエラーの発生源になっているブロックに固有のものではないという点である。しかし、まあそれもこのような非同期（の並列）システムをいじる楽しみの一つだと言える。C++環境はそのような抽象化された要素を設計するために、非常に幅広いツールを提供してくれる。そして、個々の改善が将来の作業を易しくしてくれるのである。

以上が翻訳である。このように、MySQL Clusterはシグナル（メッセージ）交換を基礎として実装されており、通常の共有メモリ方式の並列ソフトウェアとは大きく構造が異なっている。その結果として、MySQL Clusterは高い同時実行性と素早い応答性を実現しているのである。排他ロックを使わずに同時実行制御をする構造はロックがボトルネックにならないためCPU数に応じてスケールし易く、CPUコア数が増加すると予想されるこれからの時代にはとても有利に働く可能性があり、これからMySQL Clusterがどこまで性能を向上させられるかとても楽しみである。

しかし、はっきり言ってMySQL Clusterの構造を理解するのは少し敷居が高い。動作不良を起こした場合に原因を特定するためには、各ブロックのソースコードを行ったり来たりしなければならないので必然的に解析には時間が掛かってしまうし、各ブロックの状態は刻々と変化するので問題の発生条件の特定も難しい。なので慣れるまでは結構大変かも知れない。その内部構造を詳しく知るようになればFrazer氏が言うようにそれもまた魅力になるかも知れないが、構造が分からないうちは単なる苦痛である可能性が高い。というわけで、次回はNDBデーモンの各カーネルブロックについて紹介しようと思う。

MySQL 5.4!! MySQL Cluster 7.0!!

Oracleによる買収の報道とちょうど時期が重なってしまったのだが、実は今MySQL Conference & Expoの真っ最中なのである。買収のニュースのインパクトが大きすぎて霞んでしまいそうになるが、MySQL Conference & Expoにおいてなんと新しいバージョンのMySQLが発表された。MySQL 5.4である。次期バージョンは6.0とされていただけに驚いた人も多いだろうが、5.4は5.1から性能を改善し、6.0の機能をちょっとだけ先取りしたバージョンなのである。（そのバージョン番号の通り、5.1と6.0の中間的なバージョンというわけである。）

Distribution Awareness - MySQL Clusterにおけるスキーマチューニングの定石

MySQL Clusterはデータノードが増えると性能が低下する？？？

そのような噂を聞いたことがないだろうか。この噂は事実を含んでいる面もあるが、殆どの場合は適切にスキーマを設計していないことが原因で起きる。実はMySQL Clusterはその性能を遺憾なく発揮するためにはスキーマの設計が非常に大事なのである。

MySQL Clusterは複数のデータノード（ノードグループ）に対して主キーの値に基づいて行単位で分散されている。主キーに偏りがなければ各データノードに格納される行数は均等になる。つまり、MySQL ClusterはSharding（アプリケーションパーティショニング/Level2分散）を自ら行っていると言えるだろう。

あのサイトでMySQL Clusterが？！

MySQL Clusterの導入事例資料が出来た。資料は下記のキャンペーンサイトから入手可能で、要登録だがささやかではあるがプレゼントもあるようなのでぜひ登録してみて欲しい。

MySQL Cluster 7.0.4 beta has been released

ナニッ！！7.0？？そんなの聞いてないよっ！まじかよっっっ！！！

と思った方ごめんなさい。実はMySQL Cluster 6.4はMySQL Cluster 7.0にバージョンが変更されたのである。従って7.0.4は6.4.4の代わりにリリースされたということになる。MySQL Cluster 7.0.4のリリースノートはこちら。

http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-news-5-1-32-ndb-7-0-4.html

MySQL ClusterのRPMパッケージ

MyNAのメーリングリストで迷ってる人を見かけたのだが、意外と同じことで悩んでいる人が多いのではないかと思って書いておく。

MySQL Clusterのダウンロードページに行くと、Linux用のRPMが細かく分かれていて、どのパッケージをどのホストにインストールすればいいのか迷ってしまうんじゃないだろうか。MySQL Clusterには管理ノード、データノード、SQLノードの3種類が存在するが、それぞれにインストールしなければいけないRPMは次の通り。

MySQL Clusterへの接続方法

MySQL Clusterを使うにあたって直感的に理解しにくいことを一つ挙げると

どうやってたくさんあるSQLノードに接続すればいいんだ？
ロードバランスは？
フェイルオーバーは？

ということがあると思う。このテーマを扱ったドキュメントはありそうだちょうど良いものが見あたらない。おそらくこの点が明確でないために「よし、最近サイトのトラフィックも増えてきたことだし、いっちょMySQL Clusterを試してみようか！」という気にならず、多くの人が利用を躊躇ってしまっているのではないだろうか？なので今日はこの点について5パターンのソリューションを紹介したいと思う。

MySQL6.0における新しいJOIN最適化手法 - BKA

MySQL 6.0では新たなJOIN最適化手法であるBKA - Batched Key Accessの実装が進んでいる。BKAとは、読んで字のごとくキーを用いたアクセスをバッチ（ひとまとまりの）処理にすることである。