ぱろっと・すたじを

この２ヶ月ほど、仕事でさんざん
「MySQL Cluster」について評価を続けていたので、
ディスクベースのクラスタについて、だいぶノウハウがたまりました(｀･ω･´) ｂ

で、評価の結果、実運用レベルでＧＯサインが出たので、
本番に近いレベルのテストをしていたのですが、
いろいろ問題が発生したり(´･ω･`)

まあ、予想よりも多くのサーバリソースを使うことがわかったからなのですが、
Clusterの評価をする時につまづきやすいポイントを３つほどメモしておきます


　１．日本語ドキュメントは足りてない

今年初頭にSunに買収されたため、日本語のマニュアルが公式に出ているのですが、
このマニュアル、英語のマニュアルと比較して、
情報量が足りてません(´･ω･`)

（まあ、よくある話なんですがね・・・
　最近オープンソースを使ったソリューションを発表した会社も、
　独自の日本語マニュアルがＵＳＯ８００だったし）

例えば、日本語マニュアルでClusterは14章なのですが、
英語のマニュアルでは20章です
ついでに、Clusterの章の中身も少なめです

「動かしてみる」レベルなら日本語マニュアルで十分なのですが、
「実運用レベル」になるとちょっと足りてないので、
英語のマニュアルも読んでみることをお勧めします


　２．MySQL5.1とMySQL Clusterは違う

以前もちょこっと書いた話だったのですが、
もっと詳しくわかったので補足

当初、ディスクベースのクラスタは、
MySQL5.1の新機能としてアナウンスされていました
なので、情報系のサイトでもそのように説明されています

しかし、５月末の時点で、MySQL本体とClusterは分離され、
別ブランチになった・・・のいうのが以前のお話

にもかかわらず、最新のMySQL5.1.26でも、
Clusterを含んだソースになっていたために、
「分離された」という感じがしてなかったのですが・・・

実は、5.1.23以降、MySQL本体に含まれるClusterのソースは、
6.2.15から更新されていないのですΣ(・ω・ノ)ノ

しかも、英語のマニュアルの頭に、
「5.1に含まれるClusterのソースはもうメンテしないからね(`･ω･´)」
と書かれているのです

こういった情報こそ、まさに日本語に訳すべきだと思うのですが・・・
まあ、仕方ないとして・・・

じゃあ、今のClusterのバージョンはいくつなのかというと、
実は6.3.16まで進んでいます

しかも、6.3系では、複数のデータノードを
同時にリカバリする機能が追加されています
・・・ということは、以前はできなかったのね(´･ω･`)

（もっとも、Clusterにおける「リカバリ」とは、
　ただノードプロセスを起動するだけのことなんですがね
　ファイルが壊れてようがなくなってようが、自動で復旧します）

さらにややこしいのが、Clusterはあくまで「ストレージエンジン」であり、
「MyISAM」や「InnoDB」と同じ位置づけってことです
つまり、SQLを解釈するフロントエンジンが必要である、と

結果、Clusterのソースには、MySQL5.1のソースが同梱されており、
これが余計に混乱を招いているような気が
（6.3.16には5.1.24が付属）

せっかくとても（・∀・）ｲｲ!!機能なので、
もうちょっとわかりやすくアピールすべきだと思いますが・・・

MySQL5.1はRCでも、Clusterはすでに安定版なので、
評価の際にはClusterの最新版を使うことをお勧めします


　３．ディスククラスタはディスクに格納するクラスタではない

これを勘違いしていたのは、
私（と周辺の人々）だけなのかもしれませんが・・・

そもそも、Clusterは4.1の時代からメモリベースで実装されています
これがMySQL5.1からディスクにも格納できるって話になったわけです

しかし、ディスクへの格納は、メモリクラスタの補助と考えた方がよさそうです
Indexとそれを適用したColumnは、従来同様メモリに格納されるからです

これをきちっと把握していなかったために、
前述の本番レベルテストで問題が出たのです

ひたすらINSERTのテストを繰り返して必要なHDD容量を割り出し、
仮環境に本番データを投入してみたところ、
メモリがフローしたという・・・(´･ω･`)

（参考までに、数千万行のデータを投入してさらにIndexを定義すると、
　メモリ領域は十数GB使います）

HDDの容量は簡単に拡張できますが、メモリはそうはいきません
しかも、今のClusterの仕様では、ノード構成を簡単に変更できないので、
あらかじめ必要な領域を計算しておかないと、本番で足りないって事態に

この領域計算に役立つツールも同梱されてはいますが、
計算値と実測値に結構ずれがあるので、
実測して容量計算することをお勧めします


というわけで、今回はClusterで引っかかるポイントを紹介しましたが、
実際に運用するとなると、いろいろなノウハウが必要になります

このあたりは機会があればまた・・・

週末に病院送りになった都合で、
Groovy/Grailsネタを書く機会を逸していたのですが、
先週の時点でGrailsを動かすところまではできてます

ただ、良くも悪くも時間が空いたことで、
Groovyそのものについて、さらに調べを進めていたわけですが、
そこでよく出てきたのがJRubyとGroovyの比較

　・JVM上で動く
　・スクリプト言語である
　・Rubyと互換性がある、あるいは参考にしている

このような点で非常に似ていることもあり、
そういった論争が起こることもわかるのですが・・・

結局のところ、JRubyとGroovyは設計思想の違う言語であり、
これを比較して優劣を決めることは、
言語の優劣を決めることと同格な気がします
（比較するならRubyとJRubyの実行速度とか・・・）

JRubyはRubyをJVM上で動かすための仕組みであり、
GroovyはJavaを簡潔に書くための記法ですから、
いろいろ似ていても根本的には違うもののはずです

おそらく、問題を面倒にしているのが、
「JRubyはJavaのコードを呼べる」ってところでしょう

（GroovyもJavaのコードを呼べる・・・という表現は間違いで、
　むしろGroovyはJavaそのものなのですが、
　このあたりが混同されている気がします）

確かにJRubyはJavaのコードを呼び出して書けます

しかし、それで書かれたコードはRuby特有の簡潔な書式ではなく、
かといってJavaほど厳格でもないという、
非常に「ごちゃっと」した印象を受けます

無理矢理RubyとJavaのコードを混在させるくらいなら、
PureRubyかPureJavaで統一した方が、
生産性もメンテナンス性もいいと思うのですが

一方で、「GroovyがあればJavaはいらない」的な論調も見かけましたが、
これも違うよね・・・と思います

確かに、Groovyの「威力」はすさまじいのですが・・・と、
本論からずれるので、この話はまた次回にでも

あまり知られてないことですが、
私は「ファイアーエンブレム」が好きだ

・・・ただし、ＳＦＣ版まで(´･ω･`)

（ＧＢＡの２作目もやった感じつまらなくはなかったのですが、
　ＳＦＣほどの面白さは・・・）

で、今度ＤＳで初代がリメイクされると聞いたので、
情報を軽く集めてみたのですが・・・

・・・何、この手抜きゲーム（ﾉﾟДﾟ)ノ彡┻━┻

どう見てもＳＦＣ版の方がキャラも戦闘もグラフィックがいいような・・・
ＳＦＣ版のキャラグラフィックは、今考えてもいい感じのバランスでしたね

ただまあ、リフが復活している・・・のはどっちでもいいとして、
何かしら追加要素があるならば、価格も安いし考えなくは・・・と思っていたら、
致命的な問題発覚

ＤＳ版は「暗黒竜と光の剣」のリメイクであって、
「紋章の謎」のリメイクではないらしい

つまり、肝心の第２部を無視ぶっちぎって、
第１部だけだという・・・Σ(・ω・ノ)ノ

あのゲームは１部と２部での、
ドロドロした人間関係の変化が面白いんじゃなかったのか・・・

こんな駄作なぞいらんわぁぁぁっ！！щ(ﾟДﾟщ)

「Ruby on Rails」は手早く動くものが作れる

これは事実なのですが、いざ本番に持っていこうとすると、
非常に面倒だったりします

開発中に気楽に動かせるのは「WEBrick」のおかげなのですが、
本番環境でこれを動かすわけにはいかないわけで

かといって、そのままApacheのCGIとして動かした日には、
リクエストの度にRailsの初期化処理が走ってしまい、
恐ろしいほど遅くなってしまう(´･ω･`)

仕方なく、Railsを動かすことに特化されたサーバを使うわけですが、
これをApacheと連動させるさせるのは、
難しいとは言いませんが面倒です

正直、私は作ったRailsのアプリを、XML出力だけに使って、
XMLはバッチで定期的にキャッシュしておき、
フロントエンドはFlexあたりにしようか、とか考えていました

しかし、当然ながらそのバッチを作る方が面倒なわけで、
こりゃ困ったね、と(´･ω･`)

で、考えたのが「JRubyならTomcatで動くんじゃない？」ってことでして

「JRuby」はJavaで書かれたRubyの実装なので、
コード的にはRubyですが、実際はJavaのVMで動きます

しかも、JRubyならJavaのクラスが呼べるので、
自分のフレームワークに詰め込んだ、
使い慣れたライブラリを使えるのもいい感じです(｀･ω･´) ｂ

これは非常に理想的ですし、
「JRuby on Rails」で開発された事例もあるということで、、
いろいろ調べていたわけですが・・・

JRubyを基点に情報をたどったところ、
目に付いたのが「Groovy」という言語

最近のJavaは、JRubyやJython（Javaで実装したPython）のように、
他の言語をJavaで実装するのが流行になっています
（たぶん、Java6の目玉がこれだった気が）

それと同時に出てきたのが「Groovy」だったと思いますが、
名前を知ってはいても、あまり興味はなかったのです

ただ、知っていて損はないだろうと、
Wikipediaの記述を読んでみたのですが・・・

　・・・これ、すごすぎない(´･ω･)？

一言で言って、「Groovy」とは、
「Javaをスクリプト言語風に書くための言語」なのです

Javaは確かにガチガチに固められた言語であり、
それゆえに堅牢性抜群なのですが、
一方で堅苦しくて、開発が（スクリプト言語に比べて）面倒です

しかし、例えば以下のようなコードがあったとします


class HelloTest {
　public HelloTest() {
　　println "Hello, World!"
　}
　public static void main(String[] args) {
　　new HelloTest()
　}
}
（出典：Wikipedia）


「Hello World!」を出力するだけのコードですが、
これをGroovyで書くと・・・


println "Hello, World!"
（出典：Wikipedia）


・・・これだけΣ(・ω・ノ)ノ

GroovyはRubyに影響されて作っただけあり、
Rubyに非常に良く似た記法を使うのですが、
実体は紛れもなくJavaであり、Javaのクラスは全て使えます

しかも一番恐ろしいのは、実体がJavaでありながら、
「動的型付け」を実現しているところなのです(lllﾟДﾟ)

たぶん、リフレクションを駆使しているのだと思いますが、
それゆえに実行速度は犠牲になっているはず

でも、Javaのコードをここまで簡潔に書けるなんて、
想像したこともありませんでした
（他のサンプルコードをぜひWikipediaで）

このありがたみは、Rubyの簡潔さに触れたからわかるもので、
出た当時にこの記述を見ても何とも思わなかったと思うのですが、
これはものすごい言語ですよ・・・本当に

で、Rubyを意識して作った言語であるならば、
当然「Rails」が出てくるわけですが・・・


・・・「Grails」については調査中！Σ(ﾟДﾟ)ｶﾞｰﾝ

ない！

以上(`･ω･´)


これだけじゃ何なので・・・

だいたいRubyの仕様は把握したので、
よく似たPythonとかはどうなのかな・・・とか調べていたのですが、
まあ、なんというか・・・ありがちな論争に出くわしました

404 Blog Not Found:「PHPなめんな」と「(Perl|Python|Ruby)をなめんな」の違い

この手の「どっちが優れているか」論争は、
個人的に見ている分には面白いのですが、
ぶっちゃけ「どっちでもいい」ですよね

（一応フォローしておくと、さっきの記事に書かれているのは、
　PHPが他の言語に劣っている、という話ではないので注意）

だいたい、後発の言語が先発の言語の問題を解決しているのは当然で、
同時に先発の言語の方が実績があるのも当然
どっちが優れているというのは要求仕様による話でしょう

結局のところ、「プロ」に求められるのは、
「要求仕様を、指定された工期で、正しく作ること」であり、
それがどの言語での実装かはどっちでもいいと思うのです

そもそも、私は社会人になって最初にJavaを学び、
今でも一番得意な言語ですが、
転職してからJavaを使っていたところはあまりありません

PHPだったりVBだったりPerlだったりしたわけですが、
「プロ」である以上、「私はJavaしかできません」なんて、
口が裂けても言いませんでしたし、今後も言うつもりもないです

（「停滞」は「退化」と同義です
　・・・時間が一つの方向に流れ続ける限りは）

とはいえ、私が自由に実装言語を選ぶとすれば、
やっぱりJavaを選びます
それは一番「中身を理解しているから」です

Flex/Javaのシステムで実装した、独自セッション機構は、
Javaのメモリ管理の仕組みを知っていたから書けたもので、
他の言語・・・例えばPerlやPHPで書けといわれても無理です

（RailsにはDBを使ったセッションの仕組みがありますが、
　リクエストを投げるたびにDBアクセスが発生する仕組みは、
　パフォーマンス的に避けたい(´･ω･`)）

だからといって、PerlやPHPで書けといわれれば、
全く同じとはいかなくても、別な方法で何とかすると思いますし、
それができるから対価をもらえるわけですよね

要は、応用できるか否か、ですかね・・・

---

余談ですが・・・

「RubyはJavaの10倍の生産性」なんて売り文句は、
正直どうかなと思います
これって正しい表現ではないですよね？

正確には・・・

　「RailsのコードはStrutsのコードの10分の1」

・・・ということでしかなく、
JavaとRubyの比較ではないのです

そもそも、「コードが10分の1」ということと、
「生産性が10倍」ってのはイコールではないわけで

（でも、こういう売り文句を鵜呑みにして、
　マネージャーとか営業が勝手に「RoRで」とか言い出して、
　現場が泣きを見るんですよね(´･ω･`)）

ついでに言えば、「余計なコードを書かない」というRailsと、
「汎用的に何でもできる」Strutsでは、
設計思想が違うわけでして、それを直接比較するのはどうなのよ、と

ぶっちゃけ、私はStrutsの冗長なコードが嫌いで、
Ｇｖ出欠管理も最初はStrutsで書こうと勉強を始めたものの、
あまりに面倒で自前のフレームワークを書いた、という経緯が

ついでに「O/Rマッピング」も嫌いです
SQLを直にいじってパフォーマンスチューニングしてきた側からすると、
見えないところでごちゃごちゃやられるのは気持ち悪いのです

ちょっと話がそれましたが、要するに、
Railsは速攻で動くものが作れるという利点があり、
Strutsは大規模なシステムにも耐えてきた実績があります

何度も繰り返してますが、「適材適所」ですね