はてなが信頼を回復するためにすべきもうひとつのこと
最近、はてなが提供するはてなブックマークのボタンによってユーザーの行動情報を第三者に販売していたことが問題になっている。問題の詳細については下記のページが詳しい。 ブログパーツやソーシャルボタンの類でアクセスログが残るのは当然だけどトラッキングされるのは当たり前にはなっていない - 最速転職研究会 はてなブックマークボタンのトラッキング問題で高木浩光先生が決別ツイートをするに至った経緯まとめ - NAVER まとめ これに対してはてなはすぐに販売をとりやめ、謝罪するに至った。このことはいくつかのニュースメディアでも取り上げられている。 はてな、「はてブ」ボタンから取得した行動情報の第三者提供取りやめ 近藤社長「間違った情報の使い方」と謝罪 - ITmedia ニュース はてな、ブックマークボタンで周知せず行動情報取得を行なっていたことを謝罪 -INTERNET Watch 「はてなブックマ
サポートエンジニアが経験から語る、論理的文章によるコミュニケーションのススメ
俺はこれまで一貫してIT業界でエンジニアとしてのキャリアを進んできたのだが、これまでのキャリアでもう一つ一貫していることがある。それは、ずっとサポートエンジニアであるということだ。実はサポート職というのはかなり論理的なコミュニケーションを必要とする職種であり、如何に論理的な文章を上手に書くかということが、如何に良い仕事をするか（短い時間で成果＝顧客満足度を得られるか）ということに繋がるという側面がある。（もちろん高い技術力が必要なのは言うまでもないが。）サポートエンジニアはメールや報告書という形で日々論理的な文章を書かなければならないので、サポートの経験を重ねることによって論理的にコミュニケーションをする能力というのは徐々に磨かれよう。しかし、論理的にコミュニケーションをするというのは意外と皆出来ているようで出来ていないし、筋が悪いといつまで経っても身につかないこともあり、上手にお客さんを
"オープンソース"の名を冠したプロプライエタリな人向けのセミナーに参加した件
先月中旬の話になるが、マイコミジャーナルで紹介されていた「事例に学ぶ オープンソース知財セミナー2010」というセミナーに参加してきた。（主催はオージス総研）サブタイトルは「オープンソースに潜む法的リスクとその対策のヒント」という謳い文句であり、オープンソース独特の法的リスクの話が聞けるかも知れないと思い申し込んだ。だが、結果は見事に裏切られた！ ひとことで言うと、今回のセミナーはオープンソースのセミナーではなかった！というのが拙者の正直な感想である。あまりにも酷い内容だったと言って差し支えない。酷かったのは各々のプレゼンの質などではなく、その欺瞞に満ちたメッセージである。そのようなメッセージを放置すると、オープンソースに対する誤った知識が広まる恐れがあるので、本エントリにて批判させて頂こうと思う。 キナ臭い基調講演基調講演は本セミナーを主催したオージス総研の常務が行なった。滑り出しはオー
オトコの近況 - ブログ停滞中のワケ
などという心配はしないで頂きたい。至って快調にマイペースで筆を進める毎日を送っている。ただしブログにではなくMySQL関連の書籍として。ブログは書籍の執筆が完了してから本格的に再開しようと思うので、その際にはまた是非お付き合い頂きたい。書籍も頑張って書いているので是非よろしくお願いしたい。 今書いてるのはこんな内容のものだ。原稿からプチ抜粋。 クエリキャッシュのヒット率はどのように計算すれば良いのでしょうか？ここで改めて説明するために、上の一覧ではクエリキャッシュについては敢えて省略しましたが、クエリキャッシュのヒット率は次の計算式で求めることが可能です。 Qcache_hits / (Qcache_hits + Com_select) Qcache_hitsは文字通り、クエリキャッシュにヒットして、キャッシュからクライアントへ結果が送信された回数です。キャッシュミスが発生すると、MySQ
Good Bye MySQL 6.0
MySQL 6.0.11-alphaがリリースされた。が、アナウンスレターには気になる記述がひとこと。「これはMySQL 6.0の最後のリリースです」と。寝耳に水かも知れないがこの話は本当だ。実はこれが最後のMySQL 6.0のリリースになる。つまり、MySQL 6.0の開発はこれでストップするのだ。 などと心配しないで頂きたい。MySQLの開発はちゃんと継続される。開発の方針が変更されることになったからMySQL 6.0のリリースが見送られただけである。（ちなみに、次期バージョンはMySQL 5.4で、MySQL 6.0はその次のバージョンになる予定だったものである。といっても、MySQL 5.4は後から間に挿入された形なのだが。）理由は、ここのところMySQLの新バージョンのリリーススケジュールが遅れがちだったり色々と問題があったからだ。（何かが変更されるときは大抵その背景には問題があ
Wikipediaのライセンスがクリエイティブコモンズになった。
ITMediaのニュースで報じられているように、WikipediaのライセンスがGFDL - GNU Free Document Licenseからクリエイティブコモンズライセンスに変更された。クリエイティブコモンズライセンスって何？と思う人も多いだろう。実は、以前からオトコのコンピュータ道にはクリエイティブコモンズライセンスを適用している。（ページ右上のCC-BY-NC-SAというのがそれである。）クリエイティブコモンズに関しては、以前の投稿で紹介したので詳しくはそちらを見て欲しい。 ここで概要を簡単に説明すると、クリエイティブコモンズはAll rights reservedではなくSome rights reservedのライセンス、つまり著作権を全て主張するのではなく、著作権の一部を主張するために考案されたライセンスである。著作権で守られたドキュメントや画像、写真、楽曲やその他著作物
限界までMySQLを使い尽くす!!
どこまで出来るか?!やれるところまでやってやるぜ!!と、威勢が良いのは若い間だけの話。オトナのオトコは、攻めるときはとことん攻めるが自らの限界もわきまえて賢く振る舞うのがスマートってものである。というわけで、今日はMySQLのいろいろな限界についてまとめてみる。皆さんも是非MySQLの限界を知り、MySQLをもっとスマートに使って頂きたい。 SQL文の最大長 MySQLサーバーが実行出来るSQL文の最大長は、max_allowed_packetシステム変数で表される。max_allowed_packetの最大値は1GBである。max_allowed_packetの値はセッションごとにも設定可能なので、デフォルトではそこそこの値（16MBなど）に設定しておいて、必要に応じて大きな対を使うと良いだろう。 データベースの個数 データベースオブジェクトの個数に制限はない。データベースオブジェクトは
目覚ましい進化を見せるストレージエンジン - PBXT改善の軌跡
PBXTというストレージエンジンがある。これは、PrimeBase社によるストレージエンジンで、トランザクションをサポートした本格的なものである。（つまり、InnoDBやFalconの代替として使うことを目指したエンジンなのである。）PBXTは次のページからダウンロード可能だ。 http://www.primebase.org/ 上記のページにも書いてあるが、PBXTの特徴は次の通り。 MVCC（Multi Version Concurrency Control）トランザクションのサポートACID準拠行レベルのロックデッドロック検知外部キーのサポートWrite Once（追記型アーキテクチャ）BLOBストリーミング 最後の2つ以外はInnoDBと同じである。Write Onceとは追記型のアーキテクチャで、InnoDBのように独立したログが存在しないという意味である。（PostgreSQL
ALTER TABLEを上手に使いこなそう。
テーブル定義を変更したい。インデックスが壊れてしまったので再作成したい。そんな場合はALTER TABLEを使う。ALTER TABLEはテーブル定義を変更するお馴染みのコマンドであるが、その挙動は意外と知られていない。（エキスパートとおぼしき方々からも度々質問を受ける。）そんなわけで、今日はALTER TABLEについて解説しようと思う。 まず結論から言うと、なんとMySQLのALTER TABLEはテーブルのデータを全てコピーし直すのである。なんて無駄なことを！？と思うかも知れないが、テーブル定義（スキーマ）の変更を動的に行うには、ストレージエンジンによるサポートが必要であり、動的なスキーマ変更をサポートしているストレージエンジンはまだ少ないのである。（動的スキーマ変更をサポートしているのはMySQL Clusterぐらいだ。しかも追加だけ。）デフォルトで利用出来るMyISAMはInn
FOSS License Exception
MySQLにはFOSS License Exceptionという制度がある。そのような制度があることはあまり知られていないし、名前を知っていても内容はよく知らない、または誤解しているという人が結構居る。そこで、FOSS License Exceptionについて改めてここで紹介したい。 MySQL FOSS License Exception http://www.mysql.com/about/legal/licensing/foss-exception/ 知っての通り、MySQLはデュアルライセンスだ。無料で公開されているMySQL Community ServerはGPLv2でライセンスされており、その他に有料のコマーシャル・ライセンス版が存在する。コマーシャル・ライセンス版はソースコードを公開したくないユーザー向けのライセンスで、俗にOEM版とも呼ばれる。 さて、FOSS Lice
LINEAR HASHパーティショニングってなんだ？
MySQL 5.1から利用出来るパーティショニングの種類には、次の4つがある。 RANGEパーティショニング LISTパーティショニング [LINEAR] HASHパーティショニング [LINEAR] KEYパーティショニング RANGEパーティショニングは値の範囲を指定する。次のように日付を用いて範囲を指定するのが代表的な使い方だ。詳細はこちらの記事（パーティショニングの使用例 - http session情報）を見て欲しい。 mysql> CREATE TABLE http_session ( -> session_id VARCHAR(32) NOT NULL, -> last_access TIMESTAMP NOT NULL, -> created TIMESTAMP NOT NULL, -> t_session_data VARCHAR(1024) -> ...(中略)...
SYSDATE()とNOW()の違い。
MySQLには、現在時刻を求める関数としてSYSDATE()とNOW()という2つの関数が実装されている。そして、それらは微妙に動作が違う。SYSDATE()は関数が呼び出された瞬間の時刻を返すのに対して、NOW()はクエリ開始時の時刻を返す。例えば、100秒かかるような長いクエリにおいて両者を利用した場合、SYSDATE()では結果に最大100秒の差が生じるのに対して、NOW()では差が生じない。NOW()では関数が最初に実行された時に結果がキャッシュされ、以降はキャッシュされた値が利用されるからだ。 次のようにSLEEP()を利用するとわかり易いだろう。 mysql> SELECT SYSDATE(), SLEEP(100), SYSDATE(); +---------------------+------------+---------------------+ | SYSDATE(
オトコの生きる道
2008年初頭に、MySQL ABがSunに買収されて非常に驚いた。400人弱の会社を10億ドル（1000億円程度）で買収するという破格の買収劇だった。単純計算でいうと、一人頭2.5億円で移籍したわけである。そして俺もその400人の中に含まれていた。。。 MySQL ABは素晴らしい職場だった。Sunに買収されてから現在に至るまでも、Sun自体の業績が良くなかったために人員の増加が出来ない（超忙しいヨ！）といった問題はあったものの、基本的にはMySQL ABと同じ労働環境を維持することができた。MySQLサポートチームの同僚は世界中に住んでいて、仕事を始めると社内のIRCにログインして挨拶を交わし、電話とPCとインターネットさえあればどこでも仕事をすることが出来た。（だから殆どが在宅勤務である。）そして同僚の技術レベルが素晴らしく高かった。早いときには30分以内にソースコードを確認して回答
パーティショニングの使用例 - カーディナリティが低いカラムを使って検索する場合
MySQL 5.1で追加された機能にパーティショニングがある。これは適切に利用すれば非常に強力な機能であることは間違いないのだが、使いどころが難しい。なぜなら、 インデックスをつけるだけでカバー出来る場合が多い。 パーショニングを使わずに、単にテーブルを分けてしまえばいい。 テーブルが巨大にならないとあまり効果を実感できない。 使い方を間違えると性能が落ちてしまう。 などの問題があるからだろう。 そんなわけで、今日と明日でパーティショニングが役に立つシーンを2つ紹介しようと思う。今日は一つ目、インデックスをつけたいカラムのカーディナリティが低い場合だ。カーディナリティとは日本語に訳すと濃度とか訳されるが、要は値の種類（分散具合）のことである。例えば、YesかNoの2つの値しかとらないカラムは非常にカーディナリティが低く、インデックスをつけるととても効率が悪い。インデックスを使って目的の行を
パーティショニングの使用例 - http session情報
今日もパーティショニングの話の続きである。 パーティショニングが非常にフィットする（たぶん昨日の例よりも）もう一つのケースは、数日間だけ必要なデータを蓄えておくような場合だ。例えば、HTTPセッションやログ情報などが良い例ではないだろうか。そういう場合には、日付を使ってRANGEパーティショニングをするのである。RANGEパーティショニングでももちろんPruningによって性能の向上は出来るのだが、それよりも何よりも高速に不要なパーティションを破棄できるというのが大きい。パーティションの破棄は、内部的にはテーブルのDROPとほぼ同じ扱いなのである。DROPのスピードはストレージエンジンによるが、InnoDBやMyISAM、NDB（MySQL Cluster）ならばいくらデータを含んでいても関係なくDROPは一瞬である。テーブルから大量の行を削除すると、フラグメンテーションが発生したり、イン
圧縮MyISAMテーブルで商品マスターを運用する方法
商品マスターのように参照専門で利用するテーブルならば、圧縮MyISAMが非常に適していることが多い。その方が容量が小さくなるし、ディスクI/Oが減るので高速化が期待出来るからだ。圧縮MyISAMを利用する時の問題点は、MySQLサーバ起動中にテーブルの圧縮を行えない点であろう。（正確には行えなくもないが、操作は慎重を期する必要がある。）また、圧縮MyISAMテーブルはひとたび圧縮してしまった後は、更新を加えることが出来ないのだが、如何に商品マスターといえども、一日に一度程度の頻度で更新をかけないといけないかも知れないので、これまた問題である。圧縮MyISAMテーブルを用いた運用は利点がある一方で、このような問題があるため難しい。そこで、今日は圧縮MyISAMテーブルで商品マスターを運用する方法について紹介しよう。 商品マスター作成用のMySQLサーバを用意する。オンライントランザクションを
やってはいけない!!MySQLに悲鳴をあげさせる10の方法
いつも「MySQLを使うときはこうするべき」という観点から記事を書いているが、今日は逆に犯してはいけない過ちをリストアップしようと思う。 1. 全てのカラムにインデックスをつけるデータベース初心者がもっともやってしまいがちな間違いはコレではないだろうか。インデックスはいい。検索がとても速くなるから。しかし、それと引き替えにインデックスは更新するときにコストがかかるし、その分多くのディスクスペースを消費する。特に更新にかかるコストは時に甚大で、該当するインデックスのページがキャッシュ上にない場合はディスクからいったんそのページを読み込まなければいけない。ディスクアクセスは動作にとても時間がかかるので、インデックスが多数、例えば全てのカラムに付いていたりすると「あれ？固まったか？」というような状態になってしまうことがあるだろう。インデックスは必要なカラムにだけつけるようにテーブルを設計しよう。
バイナリvsテキストに関するオトコの見解
バイナリーとテキストの本当の違い、それは「終わり」にある。 ・「終わり」がはじめにわかるのが、バイナリー。 ・「終わり」が来るまで「終わらない」のが、テキスト。 本質的な違いは、これだけである。 果たしてそうだろうか。 例えばテキストデータとバイナリデータを用いて、データをファイルに記録する場合を考えよう。バイナリデータは予め構造が決まっているのに対して、テキストデータは任意の順番でデータが並んでいる可能性がある。つまり、テキストデータにはコンテキストが存在するのである。 バイナリデータがどのような構造になっているかは、プログラムだけが知っているという場合が多い。もしくは仕様書に書いてあるとか。バイナリデータそのものはデータの構造について、情報を持っていないのである。典型的なバイナリデータとして思い浮かぶのは、IPパケットのヘッダとかSCSIコマンドとか画像ファイルとか動画ファイルとか。こ
GPLに対するオトコの個人的見解
なぜ自分がMySQL関係の仕事をしているのか？もちろんMySQLが技術的に面白いということや、MySQLの優れた性能に惹かれているという部分はあるが、それよりも何よりもライセンスがGPLだということが一番の理由である。なぜGPLがいいのか？それは最も自由なライセンスだからである。 GPLよりBSDライセンスのほうが自由ではないのか？GPLソフトウェアを改変した場合、そのソフトウェアもGPLでリリースいなければいけない。BSDライセンスなら別のオープンソースでないライセンスにするという自由があるではないか。という反論があるかも知れない。 しかし考えて見て欲しい。BSDライセンスのソフトウェアを元に、オープンソースでないライセンスをつけた非常に優れたソフトウェアを開発したとしよう。そのことによって一体どれだけのメリットがプログラマ（またはエンジニア）に還元されるのだろうか。優れたソフトウェアで
MySQLのEXPLAINを徹底解説!!
以前、MySQLを高速化する10の方法という投稿で「EXPLAINの見方についてはいずれ解説しようと思う」と書いてしまったので、今日はその公約？を果たそうと思う。 MySQLのチューニングで最も大切なのは、クエリとスキーマの最適化である。スキーマの設計は一度決めてしまうとそのテーブルを利用する全てのクエリに影響してしまうためなかなか変更することは出来ないが、クエリはそのクエリだけを書き直せば良いので変更の敷居は低い。そして遅いクエリをなくすことは、性能を大幅に向上させるための最も有効な手段である。従って、アプリケーションの性能を向上させたいなら、まず最初にクエリのチューニングを検討するべきなのである。 最適化するべきクエリはスロークエリログやクエリアナライザで見付けられるが、ではそのようなクエリが見つかった場合にはどのように最適化すればいいのか？そのためにはまず現在どのようにクエリが実行さ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
