Planet MySQL

Firebirdユーザコンテキスト変数を使ったdense_rank()

MeijiK — Mon, 23 Nov 2009 03:08:08 +0000

以前MySQLユーザ変数を使ったdense_rank()を紹介しましたが、
下記はそのFirebird版です。

Firebirdではrdb$set_context()が値ではなく、既存の設定あり(1), なし(0)になってしまうので、
Firebirdの組み込み関数に追加されたdecode()(Oracleと同じ)で、値を返すようにしています。

QL> --Like dense_rank()
SQL> select rdb$set_context('USER_SESSION', 'rnk', 0), rdb$set_context('USER_SESSION', 'preval', null) from rdb$database;

RDB$SET_CONTEXT RDB$SET_CONTEXT
=============== ===============
0 0

SQL> select case when cast(rdb$get_context('USER_SESSION', 'preval') as int) <> sal then cast(rdb$get_context('USER_SESSION', 'rnk') as int)
CON> ELSE decode(rdb$set_context('USER_SESSION', 'rnk', cast(rdb$get_context('USER_SESSION', 'rnk') as int) + 1),1,cast(rdb$get_context('USER_SESSION', 'rnk') as int)) END,
CON> decode(cast(rdb$set_context('USER_SESSION', 'preval', sal) as int), 1, sal,sal) from emp order by sal;

CASE CASE
============ ============
1 800
2 950
3 1100
4 1250
5 1250
6 1300
7 1500
8 1600
9 2450
10 2850
11 2975
12 3000
13 3000
14 5000

PlanetMySQL Voting: Vote UP / Vote DOWN

[mysql]MySQL 5.0.88リリース−EoLにちゅうい-

Sakai Kei — Sat, 21 Nov 2009 00:00:00 +0000

　5.0.99 まであと11！　とドキドキしている今日この頃。みなさんいかがお過ごしでしょうか。　MySQL 5.0.88 がリリースされました。さすがに修正項目も少ないですね。　http://www.mysql.gr.jp/frame/modules/news/article.php?storyid=157 　さて、各メジャーバージョンごとにだいたい月１回のペースで新しいバージョンが公開されているのですが、いよいよ、この MySQL 5.0 シリーズも EoL(End of Life) です。 ...
PlanetMySQL Voting: Vote UP / Vote DOWN

MySQL 5.1.41リリース

Sadao Hiratsuka — Fri, 20 Nov 2009 00:00:00 +0000

出ました。今回は機能の追加・変更が4件、バグ修正が62件あります。 MySQL 5.1.38から同梱されるようになったInnoDB Pluginですが、MySQL 5.1.41ではバージョンが1.0.5に上がり、ついにRC(リリース候補版)となりました。再掲になりますがInnoDB PluginはビルトインのInnoDBに比べて以下のような機能強化が施されており、非常に有用性の高いものです。そろそろ利用を検討しても良い時期に入ってきたのではないかと思います。高速なインデックス作成。従来InnoDBのCREATE INDEXはテーブルの再作成を伴っていましたテーブルとインデックスの圧縮 (検証結果その1、その2) INFORMATION_SCHEMAによるロック競合の検出 (検証結果) CPUスケーラビリティの向上 (1.0.3から) バックグラウンドI/Oスレッドの増加 (1.0.4から。検証結果) グループコミットの修正 (1.0.4から。Sun松信氏による検証結果) InnoDB Plugin 1.0.5ではバッファプールの管理アルゴリズムが強化されました。今回はこの点について、他の製品と比較しながら理解していきたいと思います。 InnoDBのバッファプール管理ほとんどのRDBMSは、ディスク上に保存されたテーブルのデータをメモリ上にキャッシュする仕組みを備えています。テーブルのデータをメモリ上にキャッシュする目的は、頻繁にアクセスされるデータについてアクセスのたびにディスクI/Oが発生することを防ぎ、全体の性能を向上させることです。InnoDBではこの領域のことをバッファプールと呼び、通常1GBから、多い場合は8GB程度を割り当てて利用しています。すべてのデータがメモリ上に収まってしまえば悩むことはないのですが、多くの場合メモリのサイズはデータベースサイズよりも小さいため、すべてのデータを収めるわけにはいきません。そのため、よく使われるデータというものをより分けてメモリに蓄える必要があります。これにはLRUアルゴリズムが用いられます。バッファプールのそれぞれのページをリストとして連結し、ページがアクセスされるたびに対象のページをリストの先頭(MRU側、Most Recently Used)に移動させます。しばらくアクセスされなかったページはリストの末尾(LRU側、Least Recently Used)に寄せられていき、バッファプールの容量を超えたものはメモリから破棄されるというアルゴリズムです。 LRUリストは仕組みが明快で有効性も高いのですが、弱点があります。それは、1回しかアクセスされない巨大なデータが来た場合に、本来蓄えておくべきアクセス頻度の高いデータが巨大なデータによって押し流されてしまうという点です。そのため各RDBMS製品はLRUリストに工夫を加えることでこれに対処しています。これはInnoDBのバッファプールをLRUの観点から図示したものです。見てすぐ分かるようにLRUリストが2本あります。1本はYoung LRUリスト、もう1本はOld LRUリストと呼ばれているものです。ディスクから読み込まれたデータは、まずOld LRUリストのMRU側に配置されます。 Old LRUリスト上のデータがもう一度アクセスされると、Young LRUリストの先頭に移動されます。 Young LRUリストからあふれたデータはOld LRUリストのMRU側に戻されます。 Old LRUリストからあふれたデータはメモリ上から破棄されます。ディスクから読み込んだデータがLRUリスト全体に対するMRU側ではなく中間地点に挿入されることから、このアルゴリズムのことをミッドポイント挿入戦略と呼びます。この戦略によって、1回しかアクセスされないデータが他の重要なデータを押し流してしまうことを防ごうとしています。しかし、これまでこのミッドポイント挿入戦略はうまく機能していませんでした。InnoDBのページは16KBあって1ページ内に複数のレコードが格納されているのですが、テーブルのフルスキャンを行う際に例えば1ページに2レコードが格納されていると、それだけでアクセス回数が2回と数えられてしまうためです。そのため結局のところ1回のフルスキャンによって他のデータが押し流されてしまうということが発生してしまっていました。 InnoDB Plugin 1.0.5ではinnodb_old_blocks_timeという新規パラメータによってこの問題に対処できるようになりました。このパラメータを設定すると、Old LRUリストに格納されたページに対して再びアクセスが発生しても、指定した時間が経過するまではYoung LRUリストに移動されないようになります。innodb_old_blocks_timeはミリ秒単位で指定し、デフォルトは0(無効)となっています。 MyISAMのキーキャッシュ管理他の製品ではどうなっているのか、まず近いところでMyISAMのアルゴリズムを見てみましょう。MyISAMの特徴としてテーブルのデータはキャッシュせず、インデックスのデータのみをキーキャッシュという領域に格納するという点があります。テーブルのデータはOSのキャッシュ機構にまかせてしまう、というのがMyISAMの設計思想です。 MyISAMのキーキャッシュも、InnoDBと同様に2本のLRUリストで管理されています。それぞれHot LRUリスト、Warm LRUリストという名前がついていて、役割はInnoDBのYoung LRUリスト、Old LRUリストとまったく同じです。 InnoDBはYoung LRUリストへの昇格を時間で管理していましたが、MyISAMはHot LRUリストへの昇格を回数で管理しています。Warm LRUリストにあるブロックは、Warm LRUリストから脱落するまでに3回アクセスされるとHot LRUリストに移動されるという仕組みになっています。また、Hot LRUリストから脱落したブロックは、Warm LRUリストのMRU側ではなくLRU側に配置されます。Hot LRUリストから脱落した時点で、それはもう不要なデータだと判断されていることになります。 Oracleのデータベースバッファキャッシュ管理続いてOracle Databaseのバッファキャッシュ管理アルゴリズムを確認していきましょう。 OracleのLRUリストは内部的にホットバッファとコールドバッファという二つの領域に分けられています。これはInnoDBにおけるYoung LRUリスト、Old LRUリストとほぼ同じものですが、二つの領域のサイズ比をOracleが自動で調節するようになっているところが異なります。また、OracleはLRUリストを用途別に複数持っています。 Oracleのバッファキャッシュ管理におけるポイントは、データへのアクセスパターンによってLRUリストの挿入位置を変化させているところにあります。まず、インデックスアクセスによりディスクのランダムリードを行った場合は、InnoDBやMyISAMと同様に読み込んだデータブロックをホットバッファとコールドバッファの境目にあるコールドポインタという位置に挿入します。またLRUリスト内のデータブロックはそれぞれがアクセスカウンタを持っており、一定回数アクセスされたデータブロックはコールドバッファからホットバッファに移されます。このあたりの考え方はMyISAMと同じです。一方、テーブルフルスキャンによりディスクのシーケンシャルリードを行った場合は、読み込んだデータブロックはLRUリストのLRU側に挿入されます。そのためフルスキャンによって読み込んだデータは、次の瞬間には破棄されてしまうということになります。これはつまりdb_block_size×db_file_multiblock_read_count分のメモリを本当にただのバッファとして利用しているだけで、データを再利用できるように保持するつもりがまったくないということです。この仕組みによって、アクセス頻度の高いデータがバッファキャッシュから押し流されてしまうことを防いでいます。ただし、いくつかの条件の下ではテーブルフルスキャンを行ったデータでもコールドポインタに挿入することがあります。インスタンス起動直後でバッファキャッシュに未使用領域がある場合アクセス対象のテーブルがバッファキャッシュのサイズに比べて十分小さい場合 SQLにCACHEヒント句をつけた場合(SELECT /*+ CACHE(emp) */ ename FROM emp;) こうした仕組みによって、Oracleではどのデータをメモリ上に保持しておくのかがきめ細かく制御されています。さらに、特定のテーブルがメモリ上から押し出されないようにするために、Oracleはバッファキャッシュを分割して管理する機能を備えています。このようにOracleではデフォルトのバッファプールに加えてKEEPバッファプール、RECYCLEバッファプールという2種類の領域を定義し、それぞれにメモリを割り当てることができるようになっています。KEEPバッファプールにはメモリ上に保持しておきたいデータ、RECYCLEバッファプールにはメモリ上に保持する必要性の薄いデータを配置します。この配置はテーブル単位で行われ、図のようにALTER TABLE文を用いて事前に配置先を指定しておく必要があります。何も指定していないテーブルはデフォルトのバッファプールに配置されることになります。全体として、限られたメモリを有効活用するために手厚いサポートがされていることが分かると思います。 2本目のLRUリストにはLRUWリストという名前がついていますが、これはYoung LRUリスト、Old LRUリストと対比するための一つの例として記載したもので、実際にはOracleのLRUリストはさまざまな用途に応じたものが合計10種類あります。 LRUWリストはメモリ上で更新されたデータブロックが格納されるもので、このLRUWリスト上に存在するデータブロックはDBWRプロセスによってそのうちディスクに書き戻されることが決まっています。このように更新されたデータブロックを通常のLRUリストから分離しておくと、チェックポイント時にDBWRがスキャンしなければならないメモリ量を減らすことができるため、性能が良くなるというわけです。この考え方はLinuxカーネル 2.6.28で導入されたSplit LRUと似ていると思います。性能向上の観点からもう一つ、OracleのLRUリストはこの10種類を1セットとして複数セットが用意されており、バッファキャッシュを内部的に分割して管理しています。なぜ分割されているかというと、LRUリストはその構造上リストを更新するために排他ロックを取らなければならず、リストが一組しかないとCPU数の増加に応じた性能を発揮しにくいためです。このセット数はCPU数やメモリサイズに応じてOracleが内部的に決めるもので、私の手元のPCでも32セットというかなり大量のLRUリストが用意されています。これがすべてではありませんが、Oracleはこうした作りによって高いCPUスケーラビリティを確保しています。 Oracleに近づくInnoDB InnoDB Pluginはバージョンアップごとにかなりアグレッシブな機能強化が行われていて、徐々にではありますがアーキテクチャがOracleに近づいてきているように思います。このエントリだけ読むとまだOracleとの機能差はかなりあると感じるかもしれませんが、実際の利用シーンでは微々たる差になりつつあります。Oracle一筋というエンジニアの方も、そろそろMySQLを触ってみてもよい頃合いかもしれませんね。
PlanetMySQL Voting: Vote UP / Vote DOWN

[misc][mysql]インタビュー記事が okyuu.com に掲載されました

Sakai Kei — Fri, 20 Nov 2009 00:00:00 +0000

　カカクコム社の運営する okyuu.com からインタビューをしていただきました。昨日公開。 http://okyuu.com/ja/special/engineer10-sakai 「すごいITエンジニア」にインタビューしていく企画で、私より前に出てきている方々は誰もが知っているような方たちばかり（もし知らない人がいたら業界的にモグリですよ！情報収集しましょう(笑)）。　直前数人を遡るだけでも、MySQLの第一人者サンの松信さん、drizzleで有名な(っていうかdrizzle自体がまだ有名 ...
PlanetMySQL Voting: Vote UP / Vote DOWN

WebDB Forum 2009 初日のポスターレセプションに参加しました。

MeijiK — Thu, 19 Nov 2009 14:20:16 +0000

一昨年から参加しているWebDB Forum。今年は場所を慶應大学日吉キャンパスに移し開催しています。

WebDB Forum 2009

今回私はFirebird日本ユーザー会の一員として、会員のはやしさんとともにポスターレセプションに参加してきました。まぁポスターレセプションといっても、ポスターを用意して、バイキング形式＆飲み放題の酒を飲みつつ、勝手に二時間過ごすというものです(ざっくりすぎる説明....)

学生の研究、企業のPR、そして我々のようなコミュニティも参加して、まぁバラエティに富んでいます。

サイボウズラボもブースを出していて、MySQL関連で有名な奥さん、LL関連で有名な竹迫さんもいらしていて、しばしご歓談。Q4Mはしっていたけど、mycachedは知らなかったなぁ。

各種研究はまぁ地味なものも多かったけど、留学生の方のひたむきな瞳と、説明はいつ聞いても新鮮です。ええ、私がおじさんになった証拠でもあります。ははは。
PlanetMySQL Voting: Vote UP / Vote DOWN

[mysql]MySQL 5.1.41 リリース

Sakai Kei — Thu, 19 Nov 2009 00:00:00 +0000

　定刻通り、今回もほぼ１ヶ月ぶりに MySQL 5.1 シリーズの最新版が公開されました。本当にここ最近（今年に入ってから？）、各メジャーバージョンのリリーススケジュールのコントロールが素晴らしいですね。　ということで今回出たのは MySQL 5.1.41。　http://www.mysql.gr.jp/frame/modules/news/article.php?storyid=156 　なんと言っても目玉は「InnoDB Plugin が 1.0.5-RC になった！」ということでしょう。 ...
PlanetMySQL Voting: Vote UP / Vote DOWN

[mysql]MySQL 5.1 英語／日本語マニュアル最新差分

Sakai Kei — Tue, 17 Nov 2009 00:00:00 +0000

　MySQL 5.1 マニュアルには日本語版があります。 http://dev.mysql.com/doc/refman/5.1/ja/ しかしこの日本語版、5.1.15-beta の頃 *1 に日本語化したもので、その後多少の修正は加えられ続けているものの、英語版マニュアル(http://dev.mysql.com/doc/refman/5.1/en/)のダイナミックな変更には追随していないものなのです。　ということで、MySQL 5.1 マニュアル。現時点の最新英語版と現在公開されてい ...
PlanetMySQL Voting: Vote UP / Vote DOWN

[Tritonn] Tritonn 1.0.12 - MySQL 5.0.87へのアップデートリリース

Tetsuro Ikeda — Mon, 16 Nov 2009 00:00:00 +0000

早いもので前回のリリースから1年弱が経過してしまいましたが、SourceForgeのダウンロード統計を見ているとリリースが無い間も継続的にダウンロードしてくださる方々がいらっしゃるのが気になっていました。

そこで現在のMySQL 5.0系の最新版である5.0.87向けのソース配布版およびold-styleパッチをリリースしました！

https://sourceforge.jp/projects/tritonn/releases/

今回のリリースはMySQL 5.0系最新版へのアップデートが目的です。Tritonn自体のバージョンは1.0.12のままです。

Tritonnの1.0.13については担当者多忙につき少しお休み中。MySQL 5.1対応についてはGroongaストレージエンジンを開発中です。

バイナリパッケージについては時間が取れ次第、随時リリースして行きます。

PlanetMySQL Voting: Vote UP / Vote DOWN

OSC2009高知

MeijiK — Sat, 14 Nov 2009 14:40:45 +0000

四国で初めての開催になるOSC高知に参加してきました。

私は愛媛出身ですが、高知にくるのは多分二回目(一回目は子供のころなのでまったく覚えていない)本当は前日に移動する予定が、遅れて当日朝の移動になりました。四国の他の三県は比較的、山が少なく平野が多いのですが、高知は山が多くて飛行機から見た景色は圧巻でした。

さすがに四国開催ということで、参加者人数は少なめ、参加者は控えめだったのですが、初回開催としては成功だったと思います。

私は今期のネタMySQL Workbenchをやりましたが、同じネタをやっても地方により受けたり受けなかったりするのが不思議です(いつも)

ライトニングトークとその後の打ち上げで、高知大学の菊池先生(今回の世話役の方)のお人柄に触れて、ほのぼのとした気持ちになったOSC高知でした。

PlanetMySQL Voting: Vote UP / Vote DOWN

四国で初めてのOSC2009高知開催

MeijiK — Thu, 12 Nov 2009 22:13:56 +0000

MySQLのマスコットSakilaも待ちかねた？
四国で初めてのOSCであるOSC2009Kochiが明日(2009-11-14(Sat))開催です。

私はMyNAのブースと、セミナーを一つやりますので、お近くの方は是非ご参加ください。

PlanetMySQL Voting: Vote UP / Vote DOWN

[mysql] 実録、ほぼ無停止なMySQLのフェイルオーバ (動画もあるよ)

ひろせまさあき — Wed, 11 Nov 2009 12:22:48 +0000

レプリケーションしてるMySQLで、マスタやスレーブが障害停止した場合のリカバリプランでも掲げたゴールである、「マスタが落ちてもぐーすか寝ていられるようにしたい」がほぼできたので、ほとんどサービスが停止することなく、フェイルオーバする様をスクリーンキャストに収めました。

埋め込みプレイヤーだと、小さくてわからないと思うので、リンク直接でみてください。

http://www.irori.org/pub/mysql-mm.mov

登場するホスト

登場するホストは2台、db901とdb902です。

最初は、db901が更新系クエリを受けるプライマリでdb900の浮動IPアドレスを持っています。

画面分割

画面は5分割しています。

左上 = 「select sysdate(),@@server_id」をdb900に対して(sleep 1しながら)延々と実行しまくりんぐ
右上 = ping -n db900
右下の2つ = 上のが ping -n db901、下のが ping -n db902
左下 = db901を落とそうと待ち構えているターミナル

動画の解説

00:00: はじまりはじまり。db900に対するselect、db900,db901,db902に対するping、すべて正常に流れている。selectのserver_idは、db901のものである「901」が返ってきているのを覚えておいてください。
00:11: この時点でのプライマリでもあるdb901を強制終了する。強制終了には SysRq を使ってバルスっと落とす (# echo b > /proc/sysrq-trigger)
00:12: db901が停止したので、db901に対するpingがとまる。db901はdb900でもあったので、db900に対するpingとdb900に対するselectも止まる。
00:17: 首尾よくフェイルオーバが完了し、db902がdb900となったので、db900に対するpingとdb900に対するselectが回復(server_idが「901」から「902」に変わっている点に注目！)した。yay!

フェイルオーバのメカニズム

今回のケースでは、停止から 5 秒後には、

異常の検知
プライマリのフェイルオーバ

が完了しています。

フェイルオーバのメカニズムは、レプリケーションしてるMySQLで、マスタやスレーブが障害停止した場合のリカバリプランの「<セカンダリをプライマリに昇格>」に書いた通りなんですが、監視とこのフェイルオーバ処理の実装は、

keepalived --vrrp
MySQLのL7レベルの監視をするスクリプト (check-service.db)
状態変更時にもろもろの処理をするスクリプト (trigger-vrrp.db)
- keepalived.confのnotifyや、check-service.db から実行される

で行ってます。

あとがき

これでお正月は安心しておもちがたべられそうです＾ρ＾

PlanetMySQL Voting: Vote UP / Vote DOWN

Strawberry PerlにDBD::mysqlインストール

Kazuho Oku — Wed, 11 Nov 2009 06:28:22 +0000

dev.mysql.com から MSI 形式のインストーラをダウンロード
開発用ヘッダやライブラリも含めて、mysql をインストール
mysql の scripts\mysql_config.pl を bin\ にコピー
管理者権限で cmd.exe を起動して cpan, force install DBD::mysql

PlanetMySQL Voting: Vote UP / Vote DOWN

[MySQL]相互情報量(mutual information)についてのメモ3

Yuki Anai — Tue, 10 Nov 2009 03:13:18 +0000

色々試してみてたら，

共起語の各共起回数が少ない場合に相互情報量を使うのは

一つの手段としてアリなのかもとか思った．

例1:相互情報量のが意味がありそうな結果

例2：どっちもまぁまぁ

例3:共起語のが良い結果

PlanetMySQL Voting: Vote UP / Vote DOWN

[MySQL]相互情報量(mutual information)についてのメモ2

Yuki Anai — Mon, 09 Nov 2009 14:39:42 +0000

テスト結果をつらつら書いてると長くなりそうなので記事を分けた．

情報量にidf値を用いてやってみた．

単語Aが出たら単語Bも出るっていう確率は分子で行っているので，

分母はidfってゆー，対極的重み付けのスコアを使ってみる．

相互情報量 = log(
  (全文書に出現した単語の総数 * 単語Aと単語Bの共起頻度)
   / 
  (単語Aのidf値 * 単語Bのidf値)
)

発行したSQLは以下の通り．

select
  t1.id,
  t1.name,
  t2.id,
  t2.name,
  log(
    -- T1
    (
      -- 語の総数
      (select count(id) from terms as t_cnt)
      *
      -- AとBの共起回数
      (
        select
          count(term_id) as co_cnt
        from document_terms a
        join terms b
          on a.term_id = b.id
        where
          document_id in (
            select document_id from document_terms where term_id = t1.id
          ) 
          and term_id != t1.id
          and term_id = t2.id
        group by term_id
        order by co_cnt desc
        limit 1
      )
    )
    /
    -- T2
    (
      -- Aの情報量(idf)
      t1.idf
      *
      -- Bの情報量(idf)
      t2.idf
    )
  ) as mutual_information
from
  terms t1
join
  terms t2
  on t2.id != t1.id
where
  t1.id = 12198
  and
  t1.idf > 2
  and
  t2.idf > 2
-- group by
--  t1.id
having
  mutual_information is not null
order by
  mutual_information desc
limit
  30
;

試してみたら微妙な結果に！

(海女さん...)

因みによかったケース：

「ACIDMAN」というバンド名を対象にテスト

共起情報の場合．

まあ割と納得．

「アーティスト」や「ライブ」という共起情報のテーブルには無かったのが出てる！！

「アーティスト」「ライブ」「ACIDMAN」は一つのグループにしても納得は得られると思う．

ただ，これの欠点はノイズが多い．

非常に多い．

これを解決するにはノイズになりそうな単語を除くとか必要になりそうですね．

メモ１：

ストップワードを反映した後にまた試してみる(多分)

PlanetMySQL Voting: Vote UP / Vote DOWN

[MySQL]相互情報量(mutual information)についてのメモ

Yuki Anai — Mon, 09 Nov 2009 05:46:30 +0000

推薦の勉強の一環のメモです。

相互情報量とは、単語Aが出たら単語Bも文書Xに出るという

情報量の計算に使えそうな理論。

これをクラスタリングする際の指標に使えないかと模索中です。

数式は下記の通り。

数Aとか数Bが超苦手だったので、

解釈があっているのかアレなのですが、

この式をこんな風に解釈できるんじゃないかと考えてみました。

(正しい数式じゃないのでご注意ください)

相互情報量 = log(
  (全文書に出現した単語の総数 * 単語Aと単語Bの共起頻度) / (単語Aの出現頻度 * 単語Bの出現頻度)
)

多分色々間違ってるような気もするけど。

で、作ったのが以下のSQL。

insert into term_matual_infos(
select
  t1.id,
  t2.id,
  log(
    -- T1
    (
      -- 語の総数
      (select count(id) from terms)
      *
      -- AとBの共起頻度
      (
        select
          -- term_id,
          -- b.name,
          count(term_id) / (select count(id) from documents) as co_cnt
        from document_terms a
        join terms b
          on a.term_id = b.id
        where
          document_id in (
            select document_id from document_terms where term_id = t1.id
          )   
          and term_id != t1.id
          and term_id = t2.id
        group by term_id order by co_cnt desc
        limit 1
      )   
    )   
    /   
    -- T2
    (   
      -- Aの出現頻度
      (   
        select
          (select count(term_id) from document_terms where term_id = t1.id)
          /
          (select count(id) from documents)
      )       
      *   
      -- Bの出現頻度
      (
        select
          (select count(term_id) from document_terms where term_id = t2.id)
          /
          (select count(id) from documents)
      )
    )
  ) as mutual_information
from
  terms t1
join
  terms t2
  on t2.id != t1.id
where
  t1.idf > 2
  and
  t2.idf > 2
);

テーブルの定義は以下の通り。

-- 文書テーブル
CREATE TABLE `documents` (
  `id` int(11) NOT NULL auto_increment,
  `title` text,
  `document` longtext,
  `n` float default NULL COMMENT '文書正規化用(コサイン正規化)',
  PRIMARY KEY  (`id`)
);


-- 文書中に出現した単語を保存するテーブル
CREATE TABLE `document_terms` (
  `document_id` int(11) NOT NULL,
  `term_id` int(11) NOT NULL,
  `frequency` int(11) default NULL COMMENT '出現回数',
  `tf` float default NULL,
  `score` float default NULL COMMENT 'TF-IDFのスコア',
  PRIMARY KEY  (`document_id`,`term_id`)
);


-- 単語テーブル
CREATE TABLE `terms` (
  `id` int(11) NOT NULL auto_increment,
  `name` varchar(50) NOT NULL,
  `idf` float default NULL,
  PRIMARY KEY  (`id`),
  UNIQUE KEY `name` (`name`)
);


-- 単語同士の情報量保存テーブル
create table term_matual_infos(
  term_id int not null,
  tar_term_id int not null,
  score float not null
);

こんな感じ。

「海女」が対象の単語で，

1段落目が共起情報から抽出した単語リストで，

2段目が相互情報量を用いて抽出した単語リスト．

「海女」に「就職」が出てるのは，

最近美女が海女さんになった(就職)ってニュースから来てる様子．

(参考URL：http://www.youtube.com/watch?v=nlbSpQqCV9E)

メモ１：

このリストは気付きには使えるかもしれないけど，

似ている単語としてクラスタリングするのには使えないと思った．

メモ２：

情報量の定義を色々変えてみて後でまた試したい．

出現頻度の値域を0〜1にするとまた変わるのかなー．

PlanetMySQL Voting: Vote UP / Vote DOWN

KOF2009 一日目

MeijiK — Fri, 06 Nov 2009 14:10:28 +0000

関西オープンソース2009
関西コミュニティ大決戦

開始しました。今年は参加者も少し少なめかな？セミナー数も例年より少なく感じました。Zen Cartでお世話になっているオビタスターさんに、Openbravo POSを教えてもらう。オープンソースのPOS!かっこいい。

木村自身は先日告知したとおり、東京と同じMySQL Workbenchネタをやりました。MyQueryのオチがあまりうけなくて残念。

私の前のコマでは、以前CLUB DB2でRoRについて語ってもらった大場さんがここでもRoRについて語ってらっしゃいました。
PlanetMySQL Voting: Vote UP / Vote DOWN

XtraBackup Windows版

Yasufumi Kinoshita — Fri, 06 Nov 2009 08:34:00 +0000

今回は、速報なので短いです。

「Linuxだけでたまたま動いていた感」のあるXtraBackupですが、私がいろいろ直しているうちに、最新revisionはWindowsでも動くようになったそうです！次のリリースではWindows版も出てくると思います。乞うご期待！！

「そうです」というのは、私はWindowsの開発環境を持っていないし良く分からないので、寄せられたスタックトレースだけを頼りに気合いで直しています。しかし、それで良く動いたものです。。。。

PlanetMySQL Voting: Vote UP / Vote DOWN

[ohamari][mysql] あるあるおハマり大事典 - InnoDBなのに行ロックしないの

ひろせまさあき — Fri, 06 Nov 2009 07:47:32 +0000

drop table if exists t;

create table t (
  iid int
 ,nid int
 ,bid binary(3)
 ,msg varchar(69)
 ,key (iid)
 ,key (bid)
) ENGINE=InnoDB;

insert into t values
 (1,1,1,"ichi"),(2,2,2,"ni"),(3,3,3,"san")
,(4,4,4,"si"),(5,5,5,"go"),(6,6,6,"roku")
;

なテーブルとデータで、2つ端末を用意して update しあいっこしてみます。

まず、これ↓は両方ともupdateが完了してスコっと返ってきます。行レベルロック++

begin;
update t set msg = "t1" where iid = 1;
と
begin;
update t set msg = "t2" where iid = 2;

これ↓は、where句で使っているのが、インデックスがはられていないカラムなので、後発のクエリはすぐ返らず(先発のがcommit or rollback or タイムアウトするまで)待たされます。これも期待通り。

begin;
update t set msg = "t1" where nid = 1;
と
begin;
update t set msg = "t2" where nid = 2;

で、おハマりしたのがこれ↓。intじゃなくてbinary型なんだけどちゃんとインデックスははってあるのになんでか後発のが待たされてしまいます。

begin;
update t set msg = "t1" where bid = 1;
と
begin;
update t set msg = "t2" where bid = 2;

さて、どうして行レベルロックにならずに後発のクエリが待たされるのでしょうか？

答えはこのあとすぐ！！

まだだよー

そろそろいくよー

explain select * from t where bid = 1\G

とかするとわかるんですが、なんと「type: ALL」でフルテーブルスキャンになってます。なのでテーブル全体にロックがかかってると。

フルスキャンになる理由は、数値型→binary型への型変換がかかるせいかなと思います。

なので、

begin;
update t set msg = "zero" where bid = '1\0\0';
と
begin;
update t set msg = "zero" where bid = '2\0\0';

とすると、後発のもすぐに返ってきます。

bid = 1 でもちゃんとマッチするので、型変換のことをずっぽし見落としてました＞＜

今回も id:kazuhooku さんに多大なるご支援、ご協力を賜りましてほんとうにありがとうございました。

PlanetMySQL Voting: Vote UP / Vote DOWN

Opensource Conference 2009 Tokyo/Fallに参加しました!

TeamApac — Wed, 04 Nov 2009 09:41:04 +0000

サン・マイクロシステムズは年間スポンサーとしてOSCを応援しています。去る10月30、31日に蒲田にて開催されたOpensource Conference 2009 Tokyo/Fall にサン・マイクロシステムズも参加しました。
この度のOSCは、2日間で約1,600名の参加者を迎え、大盛況のうちに幕を閉じました。

今回、サン・マイクロシステムズ企業セッション枠にはMySQLシニアエバンジェリストの梶山によるセッションが、また、MyNAコミュニティ枠でMySQLシニアサポートエンジニアの木村によるセッションがありました。
また、サン･マイクロシステムズの企業ブースでは、MySQLチームのメンバーが皆様をお迎えしました!ブースでは、MyQL 製品をはじめ、GlassFishやSun Open SSO製品をご紹介しました。システム運用管理、最適化、パフォーマンスチューニングを迅速に、かつ簡単に可能にする監視ツールであるMySQL Enterprise Monitor のデモもご覧いただきました。木村のセッションでも少しご案内しましたが、これは、MySQL コミュニティ版には含まれないEnterprise ツールです。この機会にぜひ、MySQL監視ツールについてももっと知っていただければ幸いです。

ブースにお立ちよりいただいた皆様、どうもありがとうございました!
MySQLマスコットのイルカ(Sakila)は相変わらず、OSCでも大人気でした。

今後ともどうぞよろしくお願いたします。

三橋

PlanetMySQL Voting: Vote UP / Vote DOWN

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

Mikiya Okuno — Wed, 04 Nov 2009 03:27:00 +0000

シェアードナッシング型の負荷分散機能を持ち、なおかつ同期レプリケーションによる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の動作は次のようになる。

外部表からM行フェッチ（一回のスキャン）
JOINに利用するキーの値をリストアップする。
リストアップされたキーをNDBストレージエンジンにPush-Downする。
内部表から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の正式リリースに搭載されるのはずっと先になるだろうが、楽しみな機能の一つである。

PlanetMySQL Voting: Vote UP / Vote DOWN

[MySQL][Spider]Spider-2.8リリース

斯波健徳 — Tue, 03 Nov 2009 22:11:00 +0000

Spiderストレージエンジンのバージョン 2.8(beta)をリリースしました。
Spiderストレージエンジンは、database sharding用のストレージエンジンです。
http://spiderformysql.com/

今回の主な変更は以下です。
・テーブルパラメータに「link_status」を追加しました。
　このパラメータにより、alter table文を利用してリンクの障害状況を変更することができます。
　なお、Spiderのリンク障害状況管理は、テーブル単位で行われます。

それ以外の変更については、ダウンロードドキュメント中の「99_change_logs.txt」をご確認下さい。

PlanetMySQL Voting: Vote UP / Vote DOWN

今週末はKOF(関西オープンソース決戦)2009

MeijiK — Mon, 02 Nov 2009 14:51:26 +0000

先週末はOSC2009Tokyo/Fallでしたが、今週末は場所を大阪に移し、関西オープンソース決戦(KOF)2009が11/6(Fri), 11/7(Sat)に行われます。

まずは11/6(Fri)にOSC2009Tokyo/Fallで行ったものと同じセミナーを行いますので、ご興味のある方は是非ご参加ください。

MySQL Workbenchを使ってみよう！〜MySQL GUI Toolsのご紹介〜
PlanetMySQL Voting: Vote UP / Vote DOWN

GPLソフトウェアのパッチをBSDライセンスで提供することの意義

Mikiya Okuno — Sun, 01 Nov 2009 23:54:00 +0000

先日の投稿「GPLが適用されているソフトウェア＝MySQLのパッチをBSDライセンスでリリースする。」では、GPLが適用されているソフトウェアにBSDライセンスのパッチを提供することが出来るということを書いた。ただし、それが出来ることによってどのような意義があるのかということについては触れていなかった。その結果、

単独で動かないパッチに元のと違うライセンスをつける感覚がよくわからない。

という疑問が生じたらしい（ブコメ参照）ので、パッチをBSDライセンスで提供するということはどういうことなのかを説明しようと思う。

まず第一に、パッチ自身はBSDライセンスなので、BSDライセンスに従う限り他のプログラムへ流用することが出来る。パッチといえども、それが何かの機能を追加する類のものであれば巨大なプログラムになり得るだろう。事実、Googleが提供するMySQLのパッチもかなりデカイ。パッチの規模がでかくなれば、独立して機能する有益なロジックが多々含まれることになるだろう。パッチのライセンスがBSDライセンスであれば、その機能をGPL以外のライセンスのソフトウェア、例えばBSDライセンスのPostgreSQLなどに追加するということも可能である。つまり、パッチをBSDライセンスにすることで、MySQLとPostgreSQLに同じ機能を追加するということが出来るわけだ。

第二に、MySQLはデュアルライセンスなので、BSDライセンスで提供されたパッチであればGPL版とコマーシャルライセンス版の両方に機能を追加することが出来る。従って、BSDライセンスのパッチはMySQLにとっては都合が良いのである。（MySQLがデュアルライセンスを貫く以上、GPLで提供されたパッチは適用出来ないのである。）

ちなみに、GPLソフトウェアであるMySQL 6.0からforkしたDrizzleも、全てのContributionはBSDライセンスのもとに行われている。（Drizzleに提供された全てのソースコードはBSDライセンスが適用されている。）従って、Drizzleに追加された全ての機能は、GPL版、コマーシャルライセンス版のいずれのMySQLにも取り込むことが出来るのである。また、DrizzleにContributeされたコードは、PostgreSQLなどの他のライセンスのRDBMSソフトウェアにも取り込むことが出来るので、PostgreSQLerの人は是非Drizzleのソースコードを覗いて見ると良いのではないだろうか。ただし、Drizzleでは積極的に外部のライブラリを取り込んで利用しようという方針があるので、外部のGPLが適用されたライブラリに依存した機能については、BSDライセンスによる利用は出来ない点には注意が必要である。（もちろん元のMySQL 6.0から残っているコードはPostgreSQLに取り込むことは出来ないので注意しよう。）

さて、ここまで書くと「GPLよりBSDライセンスの方が優れている」ということを言い出す人が居るかも知れないので、この点について少し捕捉しておく。GPLとBSDライセンスを比較するのはハッキリ言って無意味である。確かにBSDライセンスの方が再利用出来るソフトウェアの範囲が広い。（商用、無償、プロプラエタリ、OSSを問わず利用可能である。）しかし一方で、GPLはソフトウェアの利用者に（それをカスタマイズすることを含めて）未来永劫最大限の自由を約束するライセンスであり、GPLを継承することによって再利用可能な場面が限定されることは、その自由を約束するために必要な措置なのである。つまり、GPLとBSDライセンスはそれぞれ異なる属性を持ったライセンス（かたやCopyleft、かたやPermissive）であり、それぞれのライセンスを適切に使い分けるのが重要だということである。ライセンスに対する理解とそれらの使い分けは、オープンソースに生きる人々にとっては最も重要な嗜みと言えるだろう。

PlanetMySQL Voting: Vote UP / Vote DOWN

OSC2009Tokyo/Fall 二日目

MeijiK — Sat, 31 Oct 2009 12:58:50 +0000

今回の会場となった日本工学院専門学校　蒲田キャンパス12号館は、各部屋がガラス張りで明るい感じです。校舎も綺麗。

展示はスポンサー展示も含めて2F, セミナーは3F. 廊下も広く導線もこんがらがず、会場提供感謝です。木村はサンのブースとMyNA/Firebirdのブース運営が主で、今回はあまりセミナー見学ができなかったのが少し残念でした。夕方にブースを全部みてまわりました。Sugar CRMからforkしたというvTigerは興味深かったですね。日本語化プロジェクトもすすんでいるということで、無償で使いたい方は是非！

OS自作ということでは、本と本人のユニークさが際だつ川合さんが有名ですが、安価なハードに、個人で読み切れるソースコードで実装されたKOZOSが気になりました。私も一時期、組み込み関連の仕事をしていたことがあるのですが、なかなかよいレファレンスがないんですよね。組み込みOS. すぐにでもやりたいですが、諸般の事情により、とりあえずメモ。

PlanetMySQL Voting: Vote UP / Vote DOWN

OSC2009Tokyo/Fall 一日目

MeijiK — Fri, 30 Oct 2009 12:28:27 +0000

一日目はセミナーを行わせていただきました。ざっくりWorkbenchは上記Flashでお楽しみください。
PlanetMySQL Voting: Vote UP / Vote DOWN

[MySQL][Spider]Spider-2.7リリース

斯波健徳 — Thu, 29 Oct 2009 18:28:00 +0000

Spiderストレージエンジンのバージョン 2.7(beta)をリリースしました。
Spiderストレージエンジンは、database sharding用のストレージエンジンです。
http://spiderformysql.com/

今回の主な変更は以下です。
・１Spiderテーブルに付き、複数リンクを生成し、ロックなし参照時にロードバランスするようになりました。ロードバランスのルールは((サーバID + スレッドID) % リンク数)で決定されます。
　複数リンクを生成するには、「host」「user」「table」「server」「socket」「wrapper」「database」「password」のテーブルパラメータを記述する際に、半角スペース区切りで複数記述してください。
　例：「host 'h1 h2 h3'」

今後、SpiderでActive-Activeのクラスタ構成ができるようにするための、機能追加を行っていく予定です。

それ以外の変更については、ダウンロードドキュメント中の「99_change_logs.txt」をご確認下さい。

PlanetMySQL Voting: Vote UP / Vote DOWN

GPLが適用されているソフトウェア＝MySQLのパッチをBSDライセンスでリリースする。

Mikiya Okuno — Thu, 29 Oct 2009 17:21:00 +0000

Googleがリリースしている有名なMySQL 5.0用パッチは、なんとBSDライセンスで提供されている。MySQLは周知の通りGPLでリリースされているが、GPLソフトウェアはその性質上、改変するとそのソフトウェアもGPLでリリースしなければいけない。だったら何故そのパッチをBSDライセンスで提供することが出来るのか？！ホントにそんなこと出来るのか？！Googleは何か間違ってるんじゃないか？！などと疑問に思われることだろう。

結論から言うと、Googleは何らライセンスの間違いを犯しているわけではなく、GPLソフトウェアにGPL互換のライセンスでパッチを書くことが出来るのは、GPLの条文そのものにしっかりと書いてあるのである。

以下、GPLv2の日本語訳より抜粋。

http://sourceforge.jp/projects/opensource/wiki/licenses/GNU_General_Public_License

以上の必要条件は全体としての改変された著作物に適用される。著作物の一部が『プログラム』から派生したものではないと確認でき、それら自身別の独立した著作物であると合理的に考えられるならば、あなたがそれらを別の著作物として分けて頒布する場合、そういった部分にはこの契約書とその条件は適用されない。しかし、あなたが同じ部分を『プログラム』を基にした著作物全体の一部として頒布するならば、全体としての頒布物は、この契約書が課す条件に従わなければならない。というのは、この契約書が他の契約者に与える許可は『プログラム』丸ごと全体に及び、誰が書いたかは関係なく各部分のすべてを保護するからである。よって、すべてあなたによって書かれた著作物に対し、権利を主張したりあなたの権利に異議を申し立てることはこの節の意図するところではない。むしろ、その趣旨は『プログラム』を基にした派生物ないし集合著作物の頒布を管理する権利を行使するということにある。

つまり、パッチとしてオリジナルのGPLソフトウェアから完全に切り離された部分に関しては、GPLが適用されないわけである。ただし、そのパッチをGPLソフトウェアに適用するためには、そのパッチはGPL互換のライセンス（例えばBSDライセンスなど）でリリースしなければならない。そして、それをオリジナルのGPLソフトウェアと合体した時点でGPLが適用される。つまり、

GPLソフトウェア＋ BSDLパッチ＝改変されたGPLソフトウェア

という関係が成り立つわけである。従って、件のGoogleパッチがBSDLでリリースされているのは、一切問題はないというわけであり、Googleパッチに含まれるソースコードはBSDライセンスで利用することが可能である。

なぜ上記のような条項がGPLに盛り込まれているのか？と疑問を持たれることだろう。もし上記の条項がなければ、全ての変更はGPLを適用したソフトウェアで行わなければならず、従って他のライセンスでリリースされた優秀なソフトウェアやライブラリをGPLソフトウェアと組み合わせて利用することが出来ないという事態になってしまう。例えそれがFSFが作成した他のライセンス、例えばLGPLなどを適用したソフトウェアであっても！である。上記の条項があれば、ライセンス上は安全に他のGPL互換のライセンス（BSDライセンスなど）のソフトウェアとGPLライセンスのソフトウェアを組み合わせて別のソフトウェアを開発することが可能になる。

まったくもってややこしい話であるが、オープンソースソフトウェアに携わる人間としてライセンスの組み合わせは避けて通ることが出来ない問題であり、数あるオープンソースライセンスの中でも最もシェアが多いのはGPLなので、GPLの互換性に関する知識は身につけておく必要があるだろう。GPLが嫌いな人は「GPL汚染」などと揶揄してとかくGPLソフトウェアに対して脊髄反射的な嫌悪を示すことが多いのだが、それはきっと未知なるものに畏怖の念を抱くのは人間の性だからであり、しっかりライセンスを読んでよく理解すれば何も恐れる必要はないのである。

PlanetMySQL Voting: Vote UP / Vote DOWN

(特にMyISAMを使っていた)ウェブ屋さんがInnoDBを使う場合の設定項目

Kazuho Oku — Thu, 29 Oct 2009 00:23:11 +0000

InnoDBはMyISAMと比較して安全(OSクラッシュや電源断が発生してもテーブルが壊れない)分、書き込みが遅い。データベース屋さんからすると、それは当然のことでMyISAMがおかしいんだ、ということになり、だからバッテリバックアップ機能のついたRAIDカードを使うんだ、という話になる。でも、MyISAMを使っているウェブ屋さんの現場では、場合によって多少データが消えてもかまわないから、安いハードウェアで大量のアクセスを捌きたい... って乖離があるんじゃないかなーと思ってる。

そのような場合には、my.cnf の innodb_flush_log_at_trx_commit パラメータを調整することで、MyISAMに比肩する書き込み速度を得ることができる(そのかわり、クラッシュや電源断の場合は、設定によって直近１秒以内の変更が失われる)。

他のパラメータも含めて書いておくと、データベース専用サーバ (on linux) の場合は、

[mysqld]
...
innodb_buffer_pool_size=3072M     # innodbに割り振るメモリ。実メモリの75%程度
innodb_log_buffer_size=256M       # あまり大きくしても意味がないような気がする...
innodb_flush_log_at_trx_commit=0  # 毎秒１回データをディスクに書き出し
innodb_flush_method=O_DIRECT
innodb_file_per_table
...

あたりが自分の好み。/etc/sysctl.conf も編集して、

vm.swappiness = 5

とか書いておくと、InnoDBのバッファプールがスワップアウトされる可能性が減って幸せになれる（ことがあるかも）。

linux 以外、あるいは Apache と同居させるような小規模な運用では、O_DIRECT せずに

innodb_buffer_pool_size=512M      # 実メモリの10-20%?
innodb_log_buffer_size=128M
innodb_flush_log_at_trx_commit=0
innodb_file_per_table

として、OSのバッファキャッシュを使うという手もあると思う。そんなにいっぱいデータベース立てた経験ないけど、ベストプラクティスがどのあたりなのか興味があるので、あえて書いてみた。

なお、SATA HDDを使ってるようなケースでは、

% sudo hdparm -W 0 /dev/sda  # 必要なら sdb や sdc も。

して、ディスクの書き込みバッファを無効化しておく必要がある（そうでないと電源断時にデータが壊れる）。これはデータベースソフトウェアに限らない話だけど。

参考:

Open database life: MyISAMとInnoDBのどちらを使うべきか

MySQL :: MySQL 5.1 リファレンスマニュアル :: 13.5.4 InnoDB 起動オプションとシステム変数

MySQL5開拓団 - ストレージエンジンの吟味 (2) / KLab株式会社

Red Hat Knowledgebase: システムがメモリのキャッシュやバッファを解放せずにデータをスワップするのはなぜですか？

PlanetMySQL Voting: Vote UP / Vote DOWN

MySQLerのTwitterアカウントまとめ。

Mikiya Okuno — Wed, 28 Oct 2009 14:29:00 +0000

松信氏の、

MyISAMとInnoDBのどちらを使うべきか
Twitterで話題になってたので簡単にまとめました。

というエントリが人気を博しているが、松信氏が言うように最近はTwitterでMySQL関連の話題も結構増えてきているように思う。Twitterの流行の勢いは凄まじく、今は右を向いても左を向いてもTwitter、寝ても覚めてもTwitter、猫も杓子もTwitterという雰囲気である。従ってMySQLもTwitterで盛り上がるのは当然の成り行きというもであるし、Twitterを活用しない手はない。

しかしMySQL関連の話で盛り上がると言っても「じゃあ誰をフォローすれば話に入れるんだよ？！」と多くの皆さんは疑問に思われることだろう。そこで、今日はMySQL関連のTwitterアカウントを独断と偏見と愛と勇気と努力をもって紹介する。MySQLの情報が欲しい人、もしくは話題の輪に入ってみたい人はぜひフォローして頂きたい。

まずはオフィシャルなアカウント関係から。オフィシャルなアカウントメッセージを一方的に発信するだけなので、話題に入るのではなく、情報源として、つまりRT（Re−Tweet）の対象として活用して頂きたい。

@mysql

基本中の基本。新しいリリースやWebinarの告知などが行われる。特にバージョンアップによる新機能の追加は、話のネタには持ってこいなのでMySQLerは必ずフォローしよう。

@mysql_jp

MySQL公式日本語アカウント。国内で行われるイベントやセミナーの告知とかがされる模様。2009年11月13日オープン！

@planetmysql_jp

こちらもMySQLerフォロー必須のアカウントである。コレはPlanet MySQL日本語版のフィードを呟くボットアカウントで、Planet MySQL日本語版に登録されているブログに記事が投稿される度にフィードを読み取って呟いてくれる。ブログ記事にツッコミを入れたりコメントしたり友人に広めたりするのに持ってこいだろう。

なお、MySQL関連のブログを書いている人は是非Planet MySQLに登録しよう。ブログは見る人が居てナンボであるが、Planet MySQLに登録することでより多くの人に見て貰える機会が増えるからである。MySQLブロガーがPlanet MySQLに登録し、MySQLer全員がそのRSSを購読したり@planetmysql_jpをフォローすれば品質の高い情報交換が出来るようになるだろう。

関連リンク

Planet MySQL日本語版 http://jp.planet.mysql.com/

@planetmysql

こちらはPlanet MySQL英語版のボットアカウントである。英語が堪能なら是非こちらのアカウントもフォローしよう。英語圏におけるMySQLブログ記事の投稿数は相当なものであり、非常に質の高い情報が飛び交っている。英語の練習にもどうぞ。

関連リンク

Planet MySQL英語版 http://planet.mysql.com/

では続いて日本人MySQLerのアカウントを紹介しよう。友好的な人が多いので、気軽にフォローして突っ込んでみて頂きたい。

@tmtms

言わずと知れたとみたまさひろ氏。MyNAの会長にして日本最古参MySQLerのひとり。MySQL徹底入門の著者、MySQLにおける日本語文字コードの初期実装、なおかつ超^128重要なモジュールであるMySQL/Rubyの開発者としても知られる偉人である。（しかし本人は奇策・・・もとい気さくなひと）Rubykaigi 2009では「MySQL/Ruby終了のお知らせ」という楽しいプレゼンをして話題を呼んだ。これからはPure-Ruby実装であるRuby/MySQLを継続されるそうなので頑張って頂きたい。

関連リンク

MySQL/Ruby http://www.tmtm.org/en/mysql/ruby/README_ja.html
Ruby/MySQL http://www.tmtm.org/ja/ruby/mysql/README.html
MySQL/Ruby終了のお知らせ http://www.slideshare.net/tmtm/mysqlruby
しあわせプログラマ http://d.hatena.ne.jp/tmtms/

@sakaik

MyNAのMLでおなじみの坂井氏。MySQL 徹底入門第2版や、その他数多くのMySQL関連書籍の共著者として知られる。

関連リンク

sakaikの日々雑感～(C)編 http://d.hatena.ne.jp/sakaik/

@ikdttr

MySQLにおいて日本語フルテキストインデックスを使った検索を可能とする「Sennaストレージエンジン」の開発者である池田氏。最近はMySQL 5.1対応版の開発に忙しいらしい。早くでないかと心待ちにする毎日である。池田氏をフォローしたら「リリースマダー？」と呟くのを忘れてはならない。

関連リンク

Tritonnプロジェクト http://qwik.jp/tritonn/
mir the developer http://d.hatena.ne.jp/mir/

@hirohama

日本におけるMySQL Clusterの第一人者にして実力者の廣濱氏。カメラ好き、ガジェット好き、女好き^H^H^H^H。MySQL Clusterについて語ることの出来る貴重な人材である。

関連リンク

hirohama.mysql http://www.hirohama.biz/mysql/

@kazuho

天才エンジニアとして国際的な評価も高いサイボウズ・ラボの奥一穂氏。Q4Mストレージエンジン、Pacificドライバなど秀逸なソフトウェアを世に送り出している。ツッコミも的確で示唆的である。しかしそれでいて茶目っ気を忘れないというのが心憎い。

関連リンク

Kazuho@Cybozu Labs http://developer.cybozu.co.jp/kazuho/
コンピュータは想像力を刺激する奥一穂さんのエンジニアライフ http://okyuu.com/ja/special/engineer07-kazuho
彼氏がMyISAMを使ってた。別れたい... http://d.hatena.ne.jp/kazuhooku/20091027
Q4M http://q4m.31tools.com/
Pacificという名前の分散ストレージを作り始めた件 http://developer.cybozu.co.jp/kazuho/2009/06/pacific-18c7.html

@yonekawa

サイボウズ株式会社の米川氏。サイボウズはMySQLを利用するプロプラエタリソフトウェアの代表格である。

関連リンク

Happy Software Development http://yonekawa.livejournal.com/
サイボウズ職種別社員インタビュー開発本部開発部米川健一 http://cybozu.co.jp/company/job/recruitment/voice/11yonekawa.html

@sh2nd

OracleおよびInnoDBのエキスパート平塚氏。ブログでは度々気合いの入ったベンチマークなどをしてくれるのでwktk度高し。Rethink DBを真っ先に試すなど、人柱としても秀逸である。

関連リンク

SH2の日記 http://d.hatena.ne.jp/sh2/
MySQL RethinkDB 0.1 試してみました http://d.hatena.ne.jp/sh2/20090916

@kentokushiba

スパイダーマンこと斯波氏。SPIDERストレージエンジンの開発者として有名である。最近はVertical Partitioningエンジン（カラムごとにパーティショニングをするタイプのストレージエンジン）の開発も精力的に行っている。

関連リンク

Wild Growth日本語版 http://wild-growth-ja.blogspot.com/
SPIDER for MySQL http://spiderformysql.com/
Vertical Partitioning for MySQL http://launchpad.net/vpformysql

@kazeburo

大規模分散野郎Aチーム。Mixiの長野氏。Mixiのインフラを支える職人的DBAである。

関連リンク

横浜から渋谷方面に通勤するWeb EngineerのBlog http://blog.nomadscafe.jp/
インフラエンジニア検討会2008 mixiや楽天の「中の人」、インフラエンジニアを語る http://www.atmarkit.co.jp/news/200812/08/infla.html
mixi Engineer's Blog http://alpha.mixi.co.jp/blog/

@tmaesaka

Mixiの前坂氏。Drizzleやmemcachedなどのプロジェクトにおいて精力的に活動している。長きにわたりニュージーランドに在住しているため英語はペラペラである。最近はTokyo Cabinetにデータを格納するDrizzle用ストレージエンジンであるBlitzDBの開発に勤しんでいる。

関連リンク

オープンソースの活動「すごく、いい」前坂徹さんのエンジニアライフ http://okyuu.com/ja/special/engineer08-tmaesaka
前坂氏のブログ（英語） http://torum.net/
バイリンガルの独り言 http://ja.torum.net/
BlitzDB https://launchpad.net/blitzdb
Drizzle https://launchpad.net/drizzle
memcached http://www.danga.com/memcached

@stanaka

とあるはてな社員こと田中氏。はてなを果てしなくスケーリング（注：ダジャレではありません。）

関連リンク

とあるはてな社員の日記 http://d.hatena.ne.jp/stanaka/

@tokuhirom

えとらぼ松野氏。だまってコードを書く人。

関連リンク

TokuLog 改めB日記 http://d.hatena.ne.jp/tokuhirom/
広がれエンジニアの輪第2回松野徳大 -- 「だまってコードを書けよ」 http://jibun.atmarkit.co.jp/lcom01/rensai/comrade02/comrade01.html

@hirose31

えとらぼのひろせまさあき氏。ブログのネタはいつも秀逸。

関連リンク

(ひ)メモ http://d.hatena.ne.jp/hirose31/
「ブラックボックスは不安でしょ」　ひろせまさあきさんのエンジニアライフ http://okyuu.com/ja/special/特集_No_okyuu_No_Life_第3回

@ichii386

GREEの一井氏。InnoDBラブなMySQLerが多い中で異色のMyISAMラヴ!!な逸材。一井氏曰く、分析計の処理にはMyISAMの取り回しの手軽さが便利とのこと。

関連リンク

いちいの日記 http://d.hatena.ne.jp/ichii386/
Ethna×PHP (LLフレームワークBOOKS)

お次はMySQLの中の人。まずは日本人から。

@matsunobu

言わずと知れたMySQLのコンサルタント松信氏。数多くの書籍を執筆し、~~印税でウハウハしている~~MySQLの普及に大きく貢献している。最近受けたOkyuu.comのインタビュー記事では、「夢はエンジニアに強い影響を与える本を書くこと」と述べているのは感心する志である。この調子でこれからも頑張って頂きたい。

関連リンク

夢はエンジニアに強い影響を与える本を書くこと　松信嘉範さんのエンジニアライフ http://okyuu.com/ja/special/engineer09-matsunobu
Open Database Life http://opendatabaselife.blogspot.com/

@rkajiyama

トレーナーから技術支援まで幅広くこなすタフガイ梶山氏。日本語の（Webを含む）セミナーやイベントではまず梶山氏が登場するので、ご存じの方も多いのではないだろうか。APAC地域担当であるため、かなりの期間を海外で過ごしている。

@meijik

同じMySQLサポートエンジニアにしてキムラデービー代表の木村氏。カレーが大好きで、ランチはカレー率が非常に高い。ブログにもカレーの記事が満載である。たまにDB Magazine等の雑誌に記事を投稿している。また、OSS RDBMSとしてはMySQLだけでなくFirebird関連の活動も活発に行っている。現在Firebird（徹底）入門書籍執筆中。

関連リンク

キムラデービーブログ http://blog.kimuradb.com
適材適所のデータベース選択が重要--Firebird日本ユーザー会 http://japan.zdnet.com/sp/interview/story/0,2000056426,20354736,00.htm

@nippondanji

いわゆる俺。フォロー歓迎。

続いて英語圏の中の人たち。英語が堪能ならぜひフォローを。

@brianaker

OSSの申し子Brian Aker氏。MySQLの各種ストレージエンジン（FEDERATED、ARCHIVE、Blackhole）、memcached、Drizzle、Gearmanなど、様々な実績を残している天才プログラマである。使用しているエディタはvim。MySQLに入社する条件として「絶対にノベルティのTシャツは着ない」というものを提示した頑固者。彼の語り口は非常にマイルドで、それでいて常に論理的である。Aker氏は尊子Richard Stallmanとディベートを行ったのだが、尊子よりも主張が論理的ですらあるように感じてしまうから驚きである。俺は二人とも大好きだ！

関連リンク

BRIAN AKER DEBATES WITH RICHARD STALLMAN http://www.bytebot.net/blog/archives/2009/10/25/brian-aker-debates-with-richard-stallman
Brian "Krow" Aker's Idle Thoughts http://krow.livejournal.com/

@stewartsmith

元MySQL Clusterの開発者にして、Drizzleの開発者Stewart Smith氏。写真ではオッサンっぽく見える場合もあるが実は結構若い。もちろん技術的にはエキスパートであり、彼のブログでは度々参考になる情報が掲載されているから見逃せない。

関連リンク

Ramblings http://www.flamingspork.com/blog/

@kajarno

MySQLコミュニティ担当副社長のKaj Arno氏。MySQLのスポークスパーソン的存在。MySQL ABがコミュニティと良好な関係を保ってこられたのは彼の功績によるところが大きい。Bad Newsを魔法のようにGood Newsに変えるともっぱらの噂である。

関連リンク

ブログ http://blogs.mysql.com/kaj/

@datacharmer

MySQLコミュニティ担当のGiuseppe Maxia氏。Datacharmerというのは彼のニックネーム。ジュゼッペ氏はMySQL::Sandboxの作者としても知られる。MySQL::Sandboxは相当便利なので使うべし！

関連リンク

ブログ http://datacharmer.blogspot.com/
MySQL::Sandbox http://mysqlsandbox.net/

@LenzGr

同じくMySQLコミュニティ担当のLenz Grimmer氏。Planet MySQLを管理しているのは彼である。

さらに中の人を紹介するが、以下はサポートチームの面々である。詳しい説明は省略する。

@maximuscub

俺の上司のLachlan。若くてマッチョなオーストラリア人。

@adamtdixon

APAC地区でMySQL Clusterを担当しているAdam。

@geertjanvdk

EMEA地区でMySQL Clusterを担当しているGeert。

@lathiat

見たまんまギークなTrent。かなりの早口なので、脳をオーバークロックしている疑いが持たれている。

@garypendergast

長期休暇取得中のGary。今はイタリアを放浪しているらしい。しかし仕事はチョッパ。

以下はその他の英語圏のMySQL関連アカウント。

@jzawodn

誉れ高き名著「High Performance MySQL」の著者、Jeremy Zawodny氏。元米Yahoo!のDBA。MySQLのレプリケーションで参照系の負荷を分散できる！ということを、実際のシステムで証明して見せたのは彼が最初ではないだろうか。

関連リンク

ブログ http://jeremy.zawodny.com/blog/

@martenmickos

元MySQL ABのCEO、Marten Mickos氏。MySQLは技術者集団だが、Mickos氏は経営のプロ。惜しい人物を放出したものである。

@launchpad_net

MySQLの公開リポジトリをホスティングしているLaunchpadの公式アカウント。

関連リンク

Launchpad http://launchpad.net/

@Kickfire

MySQLを用いたDWHアプライアンスを販売している米Kickfire社の公式アカウント。KickfireはDWH用のストレージエンジンであるが、興味深いのは「SQLチップ」なるものを用いた専用のハードウェアで動作するるところ。汎用CPUでは達成できない性能を叩き出す。

関連リンク

Kickfire http://www.kickfire.com/

@webyog

MySQLのGUIを販売するWebyog社のアカウント。

関連リンク

Webyog http://www.webyog.com/

@Percona

MySQL Performance Blogでお馴染みのPercona社のアカウント。InnoDBの達人である木下氏が所属する会社でもある。（木下氏はPercona社にてXtraDBやXtraBackupの開発に勤しんでいる。オトコ的には木下氏にも呟いて貰いたいところである。）

関連リンク

Percona http://www.percona.com/
MySQL Performance Blog http://www.mysqlperformanceblog.com/
DB改造屋雑記 http://buildup-db.blogspot.com/

というわけで、思いつくままにMySQLerなTwitterアカウントを並べてみたが、是非皆さんも彼らをフォローしてみて頂きたい。データベースを開発や運用でどう上手に使いこなすかということは、システム屋ないしはWeb系のエンジニアにとって非常に重要な課題である。Twitterを活用して情報を仕入れたりディスカッションに参加したりして、ぜひスキルアップに役立てて貰いたいものである。ここに挙げたアカウントはほんの一部であることを断っておく。実際にはまだまだこんなものではなくもっと大勢の優秀なMySQLerが存在する。もし、「この人が抜けてるだろ！」とか「俺も載せろ！」という方がいらっしゃったら、Twitterで@nippondanjiへこっそりとダイレクトメッセージを送って頂きたい。

PlanetMySQL Voting: Vote UP / Vote DOWN

一家に一冊。あのオプションなんだっけ？と思った時のために備えて。- #書評_ - MySQL全機能バイブル

Mikiya Okuno — Tue, 27 Oct 2009 18:18:00 +0000

著者鈴木啓修様より献本御礼。（←一度言ってみたかったｗ）

本書は鈴木氏の前著である「MySQL全機能リファレンス」からのアップデートであるが、この度は最新バージョンであるMySQL 5.1対応になっての登場である。

今の時代、一家に一台テレビがあるように、はたまたパソコンがあるように、いやいや冷蔵庫があるように、一家に一冊本書があってもいいのではなかろうか。MySQLがオフィシャルに提供しているリファレンスマニュアルを除いて、MySQLをここまで網羅的に解説している書籍を私は知らない。その網羅性は目次だけで13ページも費やしていることからも、容易に想像出来ることだろう。

もくじを見ただけでもその網羅性がよく分かるだろう。このもくじを書いただけで既に腕がつりそうである。

Chapter 01 イントロダクション
■■　概要
1-01 MySQL™とは
1-02 MySQLの概要
1-03 データベースシステムの構造
1-04 ストレージエンジン
Chapter 02 MySQLの内部構造
■■　プロセスとメモリ構造
2-01 プロセス構造
2-02 メモリ構造
■■　問い合わせ処理
2-03 問い合わせ処理
2-04 プランナ
2-05 MyISAMのエクゼキュータ処理
■■　データベースディレクトリの構造
2-06 データベースディレクトリの構造
■■　テーブルの構造
2-07 MyISAM型
2-08 InnoDB型
■■　トランザクションの隔離レベル
2-09 トランザクションの隔離レベル
■■　INSERT DELAYED文
2-10 INSERT DELAYED文
■■　クエリキャッシュ（Query Cache）
2-11 クエリキャッシュ（Query Cache）
Chapter 03 MySQLのインストール
3-01 インストール準備
3-02 インストール
Chapter 04 MySQLサーバ管理
■■　イントロダクション
4-01 MySQLサーバ管理
■■　初期設定
4-02 初期設定
■■　サーバの起動/停止
4-03 MySQLサーバの起動と停止
4-04 MySQLサーバの起動
4-05 MySQLサーバの停止
4-06 MySQLサーバをデーモンとして起動する
■■　データベースユーザ管理
4-07 MySQLにおけるデータベースユーザの概念
4-08 データベースユーザの管理
■■　システム変数の設定
4-09 システム変数の設定
4-10 サーバの動作に関するシステム変数
4-11 通信関連のシステム変数
4-12 問い合わせ処理に関するシステム変数
4-13 ストレージエンジン関連のシステム変数
4-14 ログ関連のシステム変数
4-15 表示や文字コードに関連するシステム変数
4-16 SQL_MODE
4-17 レプリケーション関連のシステム変数
4-18 その他のシステム変数
■■　ストレージエンジン
4-19 MyISAM型
4-20 InnoDB型
4-21 MEMORY型（旧 HEAP型）
4-22 パーティション
■■　ログ
4-23 ログファイル
4-24 バイナリログ（binary log）
4-25 スロークエリのログ（slow query log）
4-26 一般クエリログ（general query log）
■■　データベースのダンプ/リストア
4-27 データベースのダンプ/リストア（再構築）
4-28 ファイル群のコピーによるダンプ/リストア
4-29 mysqldumpによるダンプ/リストア
■■　管理ツール
4-30 mysqladminとは
4-31 データベースの作成/削除
4-32 サーバの情報表示
4-33 FLOSH/RELOAD
4-34 パスワードの変更
4-35 スレーブ機能の開始/停止
4-36 mysqlcheck
■■　文字コード
4-37 MySQLのサポートする文字コード
4-38 文字コードの設定と確認
■■　レプリケーション
4-39 レプリケーションとは
4-40 MySQLにおけるレプリケーションの仕組み
4-41 レプリケーションの設定
4-42 運用/管理
■■　クエリキャッシュ
4-43 クエリキャッシュ（Query Cache）
Chapter 05 mysqlの使い方
■■　mysqlの使い方
5-01 mysqlの使い方
■■　mysqlの起動オプション
5-02 MySQLサーバとの接続と切断
5-03 表示と結果出力
5-04 バッチ処理とSQL文の実行
5-05 実行制御
■■　mysqlのメタコマンド
5-06 再接続と切断
5-07 表示の制御
5-08 バッチファイルの処理,および結果のファイル出力
5-09 SQL文の編集と表示
5-10 プロンプト
5-11 接続中のセッション情報を表示
Chapter 06 SQL
■■　SQL
6-01 SQL文一覧
6-02 語彙
■■　データベースの作成/削除/接続
6-03 データベースの作成 CREATE DATABASE
6-04 データベースの削除 DROP DATABASE
6-05 データベースの属性変更 ALTER DATABASE
6-06 データベースの一覧表示 SHOW DATABASES
6-07 データベースへの接続 USE
■■　テーブルの作成/削除
6-08 テーブルの作成 CREATE TABLE
6-09 テーブルの削除 DROP TABLE
■■　テーブルの情報表示
6-10 テーブル定義（テーブルスキーマ）の表示 SHOW CREATE TABLE
6-11 列の属性を表示 SHOW COLUMNS FROM/SHOW FIELDS FROM/DESCRIBE/DESC
6-12 テーブルの一覧表示 SHOW TABLES
6-13 テーブルの情報表示 SHOW TALBE STATUS
■■　テーブルの属性変更
6-14 テーブル属性の変更 ALTER TABLE
6-15 列の追加と削除 ALTER TABLE ADD COLUMN/ALTER TABLE DROP COLUMN
6-16 インデックスの追加と削除 ALTER TABLE ADD INDEX|CREATE INDEX/ALTER TABLE DROP INDEX|DROP INDEX
6-17 主キーの追加と削除 ALTER TABLE ADD PRIMARY KEY/ALTER TABLE DROP PRIMARY KEY
6-18 一意性制約の追加 ALTER TABLE ADD UNIQUE
6-19 外部キー制約の追加と削除 ALTER TABLE ADD FOREIGN KEY/ALTER TABLE DROP FOREIGN KEY
6-20 デフォルト値の設定と削除 ALTER TABLE ALTER SET DEFAULT/ALTER TABLE ALTER DROP DEFAULT
6-21 列定義、列名の変更 ALTER TABLE MODIFY COLUMN/ALTER TABLE CHANGE COLUMN
6-22 テーブル名の変更 ALTER TABLE RENAME
6-23 テーブル名の変更 RENAME TABLE
■■　データベースユーザの作成と削除
6-24 データベースユーザの作成と削除 CREATE USER/DROP USER
■■　データベースユーザの管理
6-25 データベースユーザの権限設定と削除 GRANT/REVOKE
6-26 データベースユーザの権限表示 SHOW GRANTS
■■　データの挿入
6-27 データの挿入 INSERT
6-28 データの挿入 REPLACE
■■　SELECT
6-29 データの検索 SELECT
6-30 重複する行を削除 DISTINCT
6-31 FROM句
6-32 テーブル結合 CROSS JOIN/INNER JOIN/OUTER JOIN
6-33 WHERE句
6-34 グループ化 GROUP BY, HAVING
6-35 検索結果の並び替え ORDER BY
6-36 検索結果の出力範囲を指定 LIMIT, OFFSET
6-37 排他的六句と共有ロック FOR UPDATE/LOCK IN SHARE MODE
6-38 問い合わせの結合 UNION
6-39 副問い合わせ
■■　データの更新
6-40 データの更新 UPDATE
■■　データの削除
6-41 データの削除 DELETE
6-42 全データの削除 TRUNCATE
■■　式や関数の実行
6-43 式や関数の実行 DO
■■　プリペアードステートメント
6-44 プリペアードステートメントの準備、実行、削除 PREPARE/EXECUTE/DEALLOCATE PREPARE
■■　問い合わせ計画の表示
6-45 問い合わせ計画の表示 EXPLAIN
■■　ストアドプロシージャ・ストアドファンクション
6-46 ストアドプロシージャ・ストアドファンクションの定義表示 SHOW CREATE PROCEDURE/SHOW CREATE FUNCTION
6-47 ストアドプロシージャ・ストアドファンクションの状態表示 SHOW PROCEDURE STATUS/SHOW FUNCTION STATUS
■■　インデックスの表示
6-48 インデックスの表示 SHOW INDEX/SHOW KEYS
■■　インデックス情報の更新
6-49 インデックス情報の更新 ANALYZE TABLE
■■　ビュー
6-50 ビューの作成、変更、削除 CREATE VIEW/ALTER VIEW/DROP VIEW
6-51 ビューの定義表示 SHOW CREATE VIEW
■■　トリガ
6-52 トリガの定義、変更、削除 CREATE TRIGGER/ALTER TRIGGER/DROP TRIGGER
6-53 トリガの定義表示 SHOW TRIGGERS
■■　テーブルの最適化
6-54 テーブルの最適化 OPTIMIZE TABLE
■■　テーブルの検査と修復
6-55 テーブルの検査 CHECK TABLE
6-56 テーブルの修復 REPAIR TABLE
■■　トランザクション
6-57 トランザクション BEGIN|START TRANSACTION/COMMIT/ROLLBACK
6-58 セーブポイントの設定とロールバック SAVEPOINT/ROLLBACK TO SAVEPOINT
6-59 トランザクションの分離レベル設定 SET TRANSACTION ISOLATION LEVEL
■■　ロック
6-60 テーブルのロックと解除 LOCK TABLES/UNLOCK TABLES
■■　テーブルデータのインポートとエクスポート
6-61 テーブルデータのインポート LOAD DATA INFILE
6-62 テーブルデータのエクスポート SELECT INTO OUTFILE/SELECT INTO DUMPFILE
■■　テーブルのバックアップとリストア
6-63 テーブルのバックアップ BACKUP TABLE
6-64 テーブルのリストア RESTORE TABLE
■■　ログの管理
6-65 ログの切り換え FLUSH LOGS
6-66 バイナリログ一覧表示 SHOW BINARY LOGS/SHOW MASTER LOGS
6-67 バイナリログの内容表示 SHOW BINLOG EVENTS
6-68 バイナリログの全削除 RESET MASTER
6-69 バイナリログの削除 PURGE MASTER LOGS
■■　サーバの制御と状態表示
6-70 スレッドの情報表示とKILL SHOW PROCESSLIST/KILL
6-71 システム変数の変更 SET|SET OPTION
6-72 システム変数の表示 SHOW VARIABLES
6-73 データベースサーバの状態表示 SHOW STATUS
6-74 各種情報やログのリセット FLUSH
6-75 権限テーブルの再読込み FLUSH PRIVILEGES
6-76 クエリキャッシュの出フラグメント FLUSH QUERY CACHE
6-77 テーブルのクローズ FLUSH TABLES|FLUSH TABLE/FLUSH TABLES WITH READ LOCK
6-78 ステータス情報のリセット FLUSH STATUS
6-79 問い合わせ実行回数のリセット FLUSH USER_RESOURCES
■■　レプリケーション
6-80 レプリケーションに関するスレッドの状態表示 SHOW PROCESSLIST
6-81 マスターサーバの状態表示 SHOW MASTER STATUS
6-82 接続しているスレーブの一覧表示 SHOW SLAVE HOSTS
6-83 スレーブ機能の起動と停止 START SLAVE (SLAVE START) / STOP SLAVE (SLAVE STOP)
6-84 スレーブの状態表示 SHOW SLAVE STATUS
6-85 スレーブ機能のリセット RESET SLAVE
6-86 マスターサーバの変更 CHANGE MASTER
Chapter 07 データ型、演算子と関数
■■　データ型
7-01 MySQLがサポートするデータ型
7-02 数値データ型
7-03 文字データ型
7-04 ENUM型、SET型
7-05 BLOB（BINARY LARGE OBJECT）型
7-06 日付/時刻データ型
7-07 ビット型
■■　演算子
7-08 MySQLのサポートする演算子
7-09 論理演算子
7-10 比較演算子
7-11 算術演算子
7-12 日付/時刻演算子
7-13 COLUMNパターンマッチング
■■　関数
7-14 MySQLがサポートする関数
7-15 算術関数
7-16 集約関数
7-17 文字列関数
7-18 日付/時刻関数
7-19 型変換関数
7-20 その他の関数
Chapter 08 ストアドプロシージャ・ストアドファンクション
■■　概要
8-01 ストアドプロシージャ・ストアドファンクションとは
8-02 ストアドプロシージャ・ストアドファンクションの定義と実行、削除
■■　プログラミングの基本
8-03 ローカル変数宣言と値の代入
8-04 SELECT INTO文
■■　制御構造
8-05 条件分岐と場合分け
8-06 ループ処理
8-07 ハンドラー
■■　カーソル
8-08 カーソル
8-09 カーソル変数の宣言とオープン、クローズ DECLARE CURSOR FOR/OPEN/CLOSE
8-10 FETCH文によるカーソル行の取得 FETCH
8-11 カーソルを使った例

この本は、とても簡潔な（悪い言い方をすると淡々とした）文体で書き進められている。リファレンスなので淡々としているのは当然と言えば当然なのであるが、それでいて説明が明快なのは感心するところである。しかし本書の真の価値は文章ではないと断言する！本書を手にとって少しめくればすぐに気付くであろう。その図表の多さに。

そう、この本の真の価値は図表にある。文章による説明は必要最低限であるのだが、その代わり豊富な図表が補って余りあるぐらい雄弁にMySQLの各種機能を説明してくれるのである。文章をいちいち読むのではなく、図表で素早く内容を理解できるというのは、リファレンス本にとって至上命題の一つであろう。また、図表以外に目をひくのがコマンドやSQL文の実行例の多さである。各種機能の説明には必ずと言って良いほどSQLやコマンドの実行結果が掲載されている。説明を読んだだけではちょっとピンと来ないな・・・と思うような機能であっても、実行例を見れば一目瞭然という寸法である。

本書の内容を改めて見てみると、MySQLには膨大な機能があるんだなということに気付く。もちろん本書ではカバーされていない機能もあるが、それにしても膨大な機能である。（MySQLは高速だが機能が少ないと言う定説を疑いたくなるぐらいである。）その膨大な機能の説明を成し遂げた鈴木氏の努力は、並大抵のものではないと言えよう。

ちなみに、本書の最後には「参考書籍」が紹介されているのだが、その中には私（つまりこのブログの筆者）が執筆した出版予定の書籍（仮題：MySQLエキスパートトラブルシューティングガイド）が紹介されている。まだ出版されていない（鈴木氏に原稿を見せたということもない）書籍を「参考書籍」として紹介するというのは前代未聞の所業ではないだろうかと思うのだが、鈴木氏曰く「参考にした書籍ではなく、参考になる書籍という意味で掲載するからOK!」ということらしい。

※この点については鈴木氏本人より「誤解を招く表現」との指摘があったので修正させて頂く。この文面からすると鈴木氏は架空の内容を参考にしたように読み取れるがそうではない。鈴木氏は次の2点を見て「この書籍なら参考にするに値する」と判断して下さったそう。
ブログに掲載した原稿のプチ抜粋
個人的に見せた書籍の「もくじ」（内容は送っていない）
オモシロおかしく書いたつもりが、思わぬ茶々になってしまって面目ないです＞鈴木氏

MySQLエキスパートトラブルシューティングガイド（仮題）では、本書で取り上げられていない機能、例えばSHOW INNODB STATUSの見方やINFORMATION_SCHEMA、プロファイリング、トレースファイル、DTraceプローブなども解説するので乞うご期待。

そんなわけで、本書は網羅的で図表や実行例を駆使してとても分かり易いMySQLのリファレンスであり、初心者から上級者まで幅広い方々におすすめである。

PlanetMySQL Voting: Vote UP / Vote DOWN

MyISAMとInnoDBのどちらを使うべきか

Yoshinori Matsunobu — Tue, 27 Oct 2009 10:32:00 +0000

Twitterで話題になってたので簡単にまとめました。

●MyISAMにしか無い機能を使いたい場合はMyISAMを使うしかない
・全文検索 (TritonnやSphinx)
・GIS

●InnoDBの利点(MyISAMの欠点)
▲障害対応系
・クラッシュしても再起動するだけでリカバリができる
・クラッシュリカバリにかかる時間はテーブルサイズに比例するようなことはなく、コミット済みのデータは修復できる (巨大なMyISAMテーブルのREPAIRには数日単位で時間がかかることがある)
・オンラインバックアップができる
・INSERTやLOAD DATAなどを実行している途中でCtrl+Cでその更新系SQL文を止めても、テーブルは壊れないし、中途半端な状態で更新されることも無いし、スレーブが止まることも無い

▲性能系
・行レベルロックなので並列性が高い(MyISAMはテーブルロック)。またSELECTと更新系SQL文が競合しない。
・主キー検索が高速 (クラスタ索引のため)
・ダイレクトI/O(innodb_flush_method=O_DIRECT)を使えるためキャッシュ効率が高い
・インデックスの追加/削除をするにあたってテーブルを再編成する必要がなく、そのインデックスだけを再構築するので効率が良い(InnoDB Plugin)
・Insert Bufferという仕組みにより、セカンダリインデックスへのINSERT処理の効率がMyISAMよりも良い

▲従来は欠点だったが、InnoDB Pluginによって改善されたもの
・グループコミットが無効化されるため同時更新性能が著しく低下していた
・I/Oスレッドが事実上読み書き1本ずつしか無かったため並列性が低く、RAIDやSSDを有効活用できなかった
・CPUスケーラビリティが悪く、4CPUコアくらいまでしかスケールしなかった
・同じ量のデータを投入してもテーブルサイズがMyISAMよりも倍以上大きくなることがある(InnoDB Pluginの圧縮機能を使うことで緩和する手がある)

▲ほか
・InnoDBでは外部キーが使える

●MyISAMの利点
・WHERE条件無しのSELECT COUNT(*)が一瞬で返る
(InnoDBの場合はテーブルをなめる必要がある)
・メモリにおさまらないほど巨大なテーブルのフルテーブルスキャン系の処理効率が良い
(InnoDBではこうしたバッチ処理でバッファプールの中身が追い出されてしまうし、バッファプールの管理オーバーヘッドもあるが、MyISAMは専用のバッファプールを持たないので効率が良い)
・OSコピーによってテーブルの移動が極めて簡単にできる
・MERGEテーブルを使うことができる (InnoDBでも5.1のレンジパーティショニングを使えば十分なことは多い)
・リードオンリーのテーブルであれば圧縮できる
・ALTER TABLE ENABLE/DISABLE KEYSを使える。例えばインデックスなしの状態で高速にロードして、後からインデックスを有効化とかができる (InnoDB Pluginではインデックス単位の再構築ができるのでかなり緩和できる)
・InnoDBはテーブルのオープン処理がシリアライズされるため、大量の数のテーブルを初回オープンするような処理がきつい

▲ソリューションによって緩和できるもの
・クラッシュ時に壊れる問題やリカバリ(REPAIR TABLE)の遅さは、生きているスレーブを使って復旧すれば解決できる
・テーブルが巨大になることで引き起こされる性能問題は、小さなテーブルに分割することで解決できる

　自分は、特別な事情が無い限り、5.1最新版に含まれるInnoDB Pluginを勧めています(*注)。ログ蓄積系のテーブルではMyISAMが良いと考えている方が結構多いのですが、MyISAMでは複数のクライアントから同じテーブルに対してINSERTをすれば競合してしまいますし、InnoDBのInsert BufferのようなI/O最適化の仕組みが無い(詳しくは「Linux-DBシステム構築/運用入門」の9章あたりを参考にしてください)ので、InnoDBに比べても処理効率が悪いです。MyISAMを活用する場合は、上に挙げたようなテクニックを使って問題を緩和するのが効果的です。
　ちなみに、マスターをInnoDBにして、スレーブをMyISAMにするのは以前Postしたように特別な注意が必要です。

(*注追加) InnoDB Pluginの現時点での位置づけはベータです。ただし、Dynamic/Compressedという特別なテーブルフォーマットを使わない限り、既存のInnoDBテーブルと互換性があるので、InnoDB Pluginを使いつつ、不安定な現象に遭遇したらパラメータを変えて通常のInnoDBに戻すことが可能です。追加インストールやインストールし直し等が必要ないという手軽さが魅力です。

PlanetMySQL Voting: Vote UP / Vote DOWN

彼氏がMyISAM使ってた。別れたい…

Kazuho Oku — Tue, 27 Oct 2009 10:20:05 +0000

追記: マジメな比較はこちら：Open database life: MyISAMとInnoDBのどちらを使うべきか

MyISAMだとPostgreSQLと並べられた時なんか恥ずかしいｗｗ

下向いちゃうしｗｗ

ウェブサイトにはせめてInnoDB使って欲しい・・・

勉強会とかで発表されたら・・・・もう最悪ｗｗ

せめて普通にトランザクションやMVCCぐらいは対応して欲しい。

常識的に考えて欲しいだけなんです！

MyISAMでテーブルロックしちゃった時の遅さとか分かる？

あのね？たとえばピーク時10〜20並行ぐらいで書込みとか行くでしょ？

それぞれ別の接続で来るわけじゃない？

みんな普通にグループコミットやアシッドネス期待してるわけでしょ？

MyISAMでテーブル壊れてリペアしてたら大恥かくでしょうがｗｗ

じゃあ MyISAM はどういう用途に適しているのか。~~待て！　次号！~~*1

参考: 彼氏が軽自動車に乗ってた。別れたい…

*1：詳しい人が解説してくれるらしいぉ ^o^

PlanetMySQL Voting: Vote UP / Vote DOWN

[mysql]MySQL 5.1.40 と MySQL 5.0.87 リリース

Sakai Kei — Tue, 27 Oct 2009 00:00:00 +0000

　一週間ほど前に MySQL 5.1.40 が、そして今週はMySQL 5.0.87 がリリースされました。　 ○MySQL 5.1.40 リリース http://www.mysql.gr.jp/frame/modules/news/article.php?storyid=153 ○MySQL 5.0.87 リリース http://www.mysql.gr.jp/frame/modules/news/article.php?storyid=154 　MySQL 5.0.87 は修正数も少なくな ...
PlanetMySQL Voting: Vote UP / Vote DOWN

[mysql]松信さんの奥さんのエントリがすごい

Sakai Kei — Tue, 27 Oct 2009 00:00:00 +0000

　気づいたら twitter で MyISAM vs InnoDB の話題が盛り上がっていました。その流れで、奥さんの愛のある MyISAM 礼賛(?)の記事： ○彼氏がMyISAM使ってた。別れたい… http://d.hatena.ne.jp/kazuhooku/20091027/1256638805 　勢いがあります。こういう文章をさくっと数分で書いてしまうセンスが羨ましい。　末尾に「待て！　次号」とあり、その「次号」を松信さんがこれまた数分でさくっと。　すごい。 ○彼女が・・・　 ...
PlanetMySQL Voting: Vote UP / Vote DOWN

Okyuu.comからインタビューを受けました

Yoshinori Matsunobu — Mon, 26 Oct 2009 11:17:00 +0000

　先日カカクコムさんが運営しているサイト「Okyuu.com」からインタビューを受け、その記事が公開されました。
　私は幼少の頃から技術者魂全開、というキャラとは程遠く、気づいたらこの業界でDB技術系の仕事をしていた、という程度なのですが、趣味と仕事が完全に一致したという恵まれた方はむしろ少数派で、多くの方は生活のために(それと多少の興味と一致して)この業界で仕事をしているのだと思います。この業界はコードを書くのが趣味でなければ生きていけない、というプレッシャーをひしひしと感じさせますが、そうでない人にとっても活躍の場はあるのだ、という安心感を持っていただけると幸いです。
　インタビュー記事について、少しだけ補足をしたいと思います。

・お金を払うユーザーを大切にするのは当然ですが、無償で使うユーザーを無視しているわけではありません。そもそも無償で使うユーザーを無視するようではOSSビジネスは成立しません。多くの利用者が試し、時に地雷を踏みそれを修復するサイクルを繰り返すことで、ようやくお金を払っても良いかなという品質に達すると考えています。誰も使っていないプロダクト(地雷を踏むリスクが高い)にお金を払うユーザーは、昨今では非常に少ないのではないでしょうか。

・第3者企業がOSS製品をさんざん利用した挙句、ちょっと機能を追加してクローズドソースにして「自社製品です」と言い張って販売するのは、私は「邪道」のビジネスだと考えています。もちろん程度問題で、ユーティリティライブラリ程度なら全然いいと思いますが、コアの機能がもろにOSSを使っているのなら、それを拡張してクローズドソースにして販売するくらいなら本家にフィードバックしろよ、と思うわけです。

・OSSに貢献する道は、パッチを書くだけではありません。たとえば新バージョンのバグを見つけてバグレポート上で再現手順を報告するというのも立派な貢献です。こうしたバグ報告によって製品の品質は徐々に上がっていきます。その意味では、会社としてはお金を出せないしパッチを書くほどのスキルは無いけどOSSに貢献したい、というような方は、できるだけ新しいバージョンを積極的に使って、バグを見つけて報告するのが良いのではないかと思います。ただし、セキュリティ上の脆弱性に関しては、バグフィックスよりも先にBlog等で発信して一般に認知されたりすると、攻撃の対象になりかねないので気をつけて頂きたいと思います(MySQLのバグレポートでは、脆弱性の問題については、報告を受けた後に一般ユーザーが閲覧できないように権限設定されます)。

PlanetMySQL Voting: Vote UP / Vote DOWN

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

Mikiya Okuno — Mon, 26 Oct 2009 00:32:00 +0000

これまで「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のソースコードのレイアウトについてとりとめもなく紹介してみた。「よし、ソースコードを見るか！」と思った時に参考にして頂けると幸いである。

PlanetMySQL Voting: Vote UP / Vote DOWN