MySQL Clusterについて ― 2009/12/08 00:14
MySQL Cluster 7.0.8aの時点での現状について、僕の認識をメモ。
（使えるかどうかの観点）
（使えるかどうかの観点）
・地雷を踏みまくることを覚悟するのであれば使える。7.x系列はまだ枯れていない。最近でも、どんどんバージョンが上がっている。
・したがって、急いでいるときに早いレスポンスで応答してくれる、有償のテクニカルサポートは必須（でも、メールベースなので、やりとりを重ねると解決には結局、半日くらいはかかる。それ以上を求めるのであれば、コンサルティング契約を購入するか、あるいは自分でソースコードをデバッガで追うかが必要）。
・本当にMySQL Clusterでなければならないのか？バッチ処理や、大きなテーブル操作が中心になるのであればInnoDBの方が断然パフォーマンスが出る（特にテーブルがinnodb_buffer_pool_size以内で収まる場合）。
・件の可用性の話で、99.999%の稼働率を実現したいのであれば、SPOFを持たないシステムを構築できる点で、MySQL Cluster（というか、ベースとなっているNDB Cluster）を使う意味がある。
・しかし、構成要素が多くなるため(データノード、SQLノード、MGMノードの３種類）、それらをちゃんと組み合わせて、システムとして高い信頼性を確保するには監視機能とか、結構作り込みが必要になり大変だ。
・ちょっとしたこと（操作、条件）で、データノード全体が落ちてしまったりとか、要するにバグ的な不具合（まさに地雷）がある。
・パフォーマンスの点で、InnoDBと比べて、常に、圧倒的に高速であるとは言えないのが現状（逆に言えば、InnoDBの完成度が非常に高いレベルにあるということである）。
・OracleのSun買収が完了してしまうと、MySQL Clusterの立場はどうなる？というところが不透明である。
（ありえないと思うひどい点）
・特定の危険なクエリが原因で、データノード自体が落ちることが、まま有る（安全側に倒してキャンセルしてくれない。。）
・SQL文の最適化が、まだまだである（インデックスを使ってほしいところで使ってくれない、とか、特定のクエリでは何故かフルテーブルスキャンが走ってしまい激重であることなど）
・そもそも、Primary Key（主キー）に帰着できない、インデックスを使うSQL文を発行すると、すべてのデータノードに対してアクセスが行ってしまうという仕様（同様の理由でJOINも原則使えない）。
・したがって、データノードの性能向上について、スケールアウトできない（主キーで完結するクエリだけ投げるならばスケールアウトすると思われるが、そうであるならば、無理にMySQLとして使う必要はなく、NDB Clusterとして使うのが普通）。
・MySQLのテクニカルサポートを受けるためには、Commercial版のバイナリを使う必要があるのだが、これにはInnoDBのコードが入っていない（なので、NDBを使わない他のテーブルはMyISAMを使うことになる、あるいは、別個にMySQL Enterpriseを入れるか）。
（その他豆知識）
・InnoDBは元々GPLであり、フリーで公開されているGPL版のMySQL Clusterには入っているのだが、こちらのバイナリではサポートが受けられない。
・その一方で、通常の商用版のMySQL EnterpriseはGPLライセンスであり、こちらはそのバイナリでサポートが受けられる、という変則的なルールである。
・Carrier Grade Edtion(CGE)とStandard Editionの区別はversion 6.2から無くなった(CGEに統一された）。
・よく知られていることだけれど、元々はNDBと呼ばれていて、Ericssonの中で開発されていたものが、Alzato社という会社にスピンアウトして、それがMySQL ABに買収されたものである。だから、元々全く別に作られたデータベースエンジンにMySQLのレイヤーをかぶせた実装になっているので、MySQL的な機能に一部対応していないことも結構ある。
・したがって、急いでいるときに早いレスポンスで応答してくれる、有償のテクニカルサポートは必須（でも、メールベースなので、やりとりを重ねると解決には結局、半日くらいはかかる。それ以上を求めるのであれば、コンサルティング契約を購入するか、あるいは自分でソースコードをデバッガで追うかが必要）。
・本当にMySQL Clusterでなければならないのか？バッチ処理や、大きなテーブル操作が中心になるのであればInnoDBの方が断然パフォーマンスが出る（特にテーブルがinnodb_buffer_pool_size以内で収まる場合）。
・件の可用性の話で、99.999%の稼働率を実現したいのであれば、SPOFを持たないシステムを構築できる点で、MySQL Cluster（というか、ベースとなっているNDB Cluster）を使う意味がある。
・しかし、構成要素が多くなるため(データノード、SQLノード、MGMノードの３種類）、それらをちゃんと組み合わせて、システムとして高い信頼性を確保するには監視機能とか、結構作り込みが必要になり大変だ。
・ちょっとしたこと（操作、条件）で、データノード全体が落ちてしまったりとか、要するにバグ的な不具合（まさに地雷）がある。
・パフォーマンスの点で、InnoDBと比べて、常に、圧倒的に高速であるとは言えないのが現状（逆に言えば、InnoDBの完成度が非常に高いレベルにあるということである）。
・OracleのSun買収が完了してしまうと、MySQL Clusterの立場はどうなる？というところが不透明である。
（ありえないと思うひどい点）
・特定の危険なクエリが原因で、データノード自体が落ちることが、まま有る（安全側に倒してキャンセルしてくれない。。）
・SQL文の最適化が、まだまだである（インデックスを使ってほしいところで使ってくれない、とか、特定のクエリでは何故かフルテーブルスキャンが走ってしまい激重であることなど）
・そもそも、Primary Key（主キー）に帰着できない、インデックスを使うSQL文を発行すると、すべてのデータノードに対してアクセスが行ってしまうという仕様（同様の理由でJOINも原則使えない）。
・したがって、データノードの性能向上について、スケールアウトできない（主キーで完結するクエリだけ投げるならばスケールアウトすると思われるが、そうであるならば、無理にMySQLとして使う必要はなく、NDB Clusterとして使うのが普通）。
・MySQLのテクニカルサポートを受けるためには、Commercial版のバイナリを使う必要があるのだが、これにはInnoDBのコードが入っていない（なので、NDBを使わない他のテーブルはMyISAMを使うことになる、あるいは、別個にMySQL Enterpriseを入れるか）。
（その他豆知識）
・InnoDBは元々GPLであり、フリーで公開されているGPL版のMySQL Clusterには入っているのだが、こちらのバイナリではサポートが受けられない。
・その一方で、通常の商用版のMySQL EnterpriseはGPLライセンスであり、こちらはそのバイナリでサポートが受けられる、という変則的なルールである。
・Carrier Grade Edtion(CGE)とStandard Editionの区別はversion 6.2から無くなった(CGEに統一された）。
・よく知られていることだけれど、元々はNDBと呼ばれていて、Ericssonの中で開発されていたものが、Alzato社という会社にスピンアウトして、それがMySQL ABに買収されたものである。だから、元々全く別に作られたデータベースエンジンにMySQLのレイヤーをかぶせた実装になっているので、MySQL的な機能に一部対応していないことも結構ある。
