中国によるソースコード開示要求・・・変更

中国、ＩＴ情報強制開示制度の導入発表…適用は来年５月
http://www.yomiuri.co.jp/atmoney/news/20090429-OYT1T00633.htm

というわけで、

• ソースコードの開示制度の導入は1年間延期
• 適用範囲は中国市場全体から政府調達へ縮小

となった。これであれば各国企業もそれほど神経質にならないのではななかろうか。特にマイクロソフトなどは既にWindowsのソースコードの開示を一部団体に対して行ってるわけであるし、政府限定でソースコードを開示することへの抵抗は少ないだろう。

開示制度を施行するにあたっては、次の点について明確にしないといけないと思う。

SYSDATE()とNOW()の違い。

MySQLには、現在時刻を求める関数としてSYSDATE()とNOW()という2つの関数が実装されている。そして、それらは微妙に動作が違う。SYSDATE()は関数が呼び出された瞬間の時刻を返すのに対して、NOW()はクエリ開始時の時刻を返す。例えば、100秒かかるような長いクエリにおいて両者を利用した場合、SYSDATE()では結果に最大100秒の差が生じるのに対して、NOW()では差が生じない。NOW()では関数が最初に実行された時に結果がキャッシュされ、以降はキャッシュされた値が利用されるからだ。

中国によるソースコード開示要求についての考察 - その2

中国によるソースコードの開示要求に従ってソースコードを公開しても、「知財」と呼ばれるもの、即ち「著作権」「特許」「商標」のいずれについても失われることはないということは、昨日の記事で書いた通りである。権利という側面だけから見ると、諸外国の企業は失うものがないどころか、逆に中国企業が深刻なダメージを受ける可能性が高い。（こっそりGPLのソースコードを流用している企業はたちまちビジネスを停止する羽目になるだろう。）

中国によるソースコード開示要求についての考察

中国、ＩＴソースコード強制開示強行へ…国際問題化の懸念
http://www.yomiuri.co.jp/atmoney/news/20090424-OYT1T00053.htm

SunがOracleに買収され、草なぎが脱ぎ、驚きのニュースが続くなあと思っていたら、今度は中国からビックリなニュースの到来である。なんと、中国で販売するIT製品はソースコードを開示しなければいけなくなるというのだ。これは一見すると、俺のようなフリーソフトウェア支持者またはオープンソース支持者にとって歓迎のニュースのように思えるだろう。しかし果たしてそうだろうか？

多くのニュースサイトで見られるのが「知財流出」という表現。知財という言葉は、多くの内容を包括しているのでどうしても意味がぼやけてしまう。実は「知財」という観点からすると、ソースコードをオープンにするだけでは何も失わない可能性すらある。なぜか？

AGPLのライセンス互換性の問題について - 解決策はRoR

Webの世界にもGPLと同様の自由や相互運用性をもたらす小粋なAGPLであるが、運用に際しては注意点がある。それは、ライセンスの互換性である。結論から言うと、AGPLはGPLv2と互換性がない。GPLv2を利用したソフトウェアを改変またはリンクして、AGPLとしてリリースすることは出来ない。それが最大の問題である。GPLv3では一部互換で、GPLv3のソフトウェアを改変してAGPLとしてリリースすることは出来ないが、GPLv3のコードをリンクしたソフトウェアをAGPLv3としてリリースすることが可能である。

分散ソリューションを可能にするAGPLのススメ

Webサイトのようにプログラムの頒布を伴わない用途においては、GPLソフトウェアを利用してもそのWebサイトのために開発したプログラムをGPLライセンスで公開する義務はない。そのため、多くのWebサイトはGPLソフトウェアを利用していてもソースコードレベルの互換性は殆ど無く、ソースコードの相互利用もなく、Webプログラマは車輪の再発明をしなければならず、多大な負荷を強いられているのではないだろうか。他人の目に触れていないソースコードは、恐らく欠点（バグやセキュリティホールなど）も多いことだろう。これではGPLライセンスの意味、つまりより多くのプログラムをGPLライセンスで流通させて、プログラマが自由に他人のソースコードを参照・利用できる（それによって車輪の再発明を防ぎ、ソフトウェアの発展を促す）という目的が台無しになってしまう。これは、フリーソフトウェアを支持する人達にとって好ましくない事態である。GPLソフトウェアの利用実績が増えてるのは良い事じゃないのか？と思ってしまうかも知れないが、大事なのは如何に多く利用されるかということではない。プログラマおよびプログラムを利用する全ての人々に自由をもたらすということがGPLの目的だからである。

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の中間的なバージョンというわけである。）

オトコの生きる道

2008年初頭に、MySQL ABがSunに買収されて非常に驚いた。400人弱の会社を10億ドル（1000億円程度）で買収するという破格の買収劇だった。単純計算でいうと、一人頭2.5億円で移籍したわけである。そして俺もその400人の中に含まれていた。。。

パーティショニングの使用例 - http session情報

今日もパーティショニングの話の続きである。

パーティショニングが非常にフィットする（たぶん昨日の例よりも）もう一つのケースは、数日間だけ必要なデータを蓄えておくような場合だ。例えば、HTTPセッションやログ情報などが良い例ではないだろうか。そういう場合には、日付を使ってRANGEパーティショニングをするのである。RANGEパーティショニングでももちろんPruningによって性能の向上は出来るのだが、それよりも何よりも高速に不要なパーティションを破棄できるというのが大きい。パーティションの破棄は、内部的にはテーブルのDROPとほぼ同じ扱いなのである。DROPのスピードはストレージエンジンによるが、InnoDBやMyISAM、NDB（MySQL Cluster）ならばいくらデータを含んでいても関係なくDROPは一瞬である。テーブルから大量の行を削除すると、フラグメンテーションが発生したり、インデックスの統計情報が乱れてしまったりするのだが、パーティションごと削除してしまえばそのような心配は一切ないのでお勧めである。

パーティショニングの使用例 - カーディナリティが低いカラムを使って検索する場合

MySQL 5.1で追加された機能にパーティショニングがある。これは適切に利用すれば非常に強力な機能であることは間違いないのだが、使いどころが難しい。なぜなら、

• インデックスをつけるだけでカバー出来る場合が多い。
• パーショニングを使わずに、単にテーブルを分けてしまえばいい。
• テーブルが巨大にならないとあまり効果を実感できない。
• 使い方を間違えると性能が落ちてしまう。

などの問題があるからだろう。

そんなわけで、今日と明日でパーティショニングが役に立つシーンを2つ紹介しようと思う。

Macで簡単に英語の発音を調べる方法

知らない英単語に遭遇したとき、意味を調べるのも大切だが、どんな発音なのかということを調べるのも大切である。そんなとき、Macユーザーなら簡単に単語の発音を聴くことができる。ターミナルを起動し、おもむろに

バイナリvsテキストに関するオトコの見解

dankogai氏のブログでバイナリデータとテキストデータの違いについて論じられているので、オトコ的にも少しコメントを加えてみたい。

== 404 Blog Not Found: バイナリとテキストの本当の違いより抜粋 ==

バイナリーとテキストの本当の違い、それは「終わり」にある。
・「終わり」がはじめにわかるのが、バイナリー。
・「終わり」が来るまで「終わらない」のが、テキスト。
本質的な違いは、これだけである。

果たしてそうだろうか。

MySQLサポートにまつわるエトセトラ

写真入りでちょっと恥ずかしいけど、SDC(Sun Developer Connection)のインタビューを受けたので紹介。

SDC SQUARE: MySQLパフォーマンスチューニング TIPS

仕事に関する与太（オタ？）話など。適当に質問に答えてただけなのに、パフォーマンスチューニングの作業フロー図まで作成されてしまった。

圧縮MyISAMテーブルで商品マスターを運用する方法

商品マスターのように参照専門で利用するテーブルならば、圧縮MyISAMが非常に適していることが多い。その方が容量が小さくなるし、ディスクI/Oが減るので高速化が期待出来るからだ。圧縮MyISAMを利用する時の問題点は、MySQLサーバ起動中にテーブルの圧縮を行えない点であろう。（正確には行えなくもないが、操作は慎重を期する必要がある。）また、圧縮MyISAMテーブルはひとたび圧縮してしまった後は、更新を加えることが出来ないのだが、如何に商品マスターといえども、一日に一度程度の頻度で更新をかけないといけないかも知れないので、これまた問題である。圧縮MyISAMテーブルを用いた運用は利点がある一方で、このような問題があるため難しい。そこで、今日は圧縮MyISAMテーブルで商品マスターを運用する方法について紹介しよう。

やってはいけない!!MySQLに悲鳴をあげさせる10の方法

いつも「MySQLを使うときはこうするべき」という観点から記事を書いているが、今日は逆に犯してはいけない過ちをリストアップしようと思う。

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

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

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

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

あのサイトでMySQL Clusterが？！

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

GPLに対するオトコの個人的見解

なぜ自分がMySQL関係の仕事をしているのか？もちろんMySQLが技術的に面白いということや、MySQLの優れた性能に惹かれているという部分はあるが、それよりも何よりもライセンスがGPLだということが一番の理由である。なぜGPLがいいのか？それは最も自由なライセンスだからである。