あの超オスもセパレート式キーボードを使ってるらしい（ErgoDoxじゃないけど）
超オス。それは漫画、バキシリーズで登場する単語であり、常人離れした、規格外の体格を持った格闘家を指すときに使われる。そんな超オスがIT業界にも存在する。いや、あまりにも有名なので、恐らく業界人であればその名を知らぬ人は居ないだろう。そう、ウェブ魚拓の開発者、新沼大樹氏である。はっきり言って、IT業界で新沼氏を知らなかったらモグリだと言って差し支えない。それどころか、その名はIT業界だけで収まらず、アスリートたちの間でも広まっている。なんせ、握力日本一である。CoCのNo.4（166kg相当）をコンスタントに閉じられるということなので、もしかすると世界一かも知れない。（参考：IRONMAN BLOG:新沼大樹氏、未公開写真、握力王 新沼大樹氏 テレビ出演 - YouTube） 実は、そんな新沼氏から衝撃の発言を聞いた。 「私もセパレート式のキーボードを使っています。」 ・・・ 〜〜〜〜〜〜〜
知って得するInnoDBセカンダリインデックス活用術！
InnoDBはクラスタインデックスという構造になっている。今日はクラスタインデックスがどういうことかということを、皆さんに理解して頂きたい。もっとも理解して頂きたいポイントは「セカンダリインデックスのリーフノードには主キーの値が含まれている」ということだ。 主キーの構造InnoDBの主キーは次の図のように「データが主キーのリーフノードに含まれる」という構造になっている。このような構造をクラスタインデックスという。 このような構造になっていることには利点と欠点があるが、大きな利点は主キーの値で検索をすると非常に高速だということだ。主キーのリーフノードにたどり着いたときには、既にデータのフェッチも完了している。データとインデックスが別々に格納されているタイプのストレージエンジンでは、インデックスからデータの位置を読み取って、その後データファイルからデータをフェッチする。このように二段階の操作が
ラップトップ購入！OSは・・・
実は最近、プライベートで利用するノートPCを新調した。用途はブログを書いたり趣味のプログラムを書いたり音楽を聴いたり写真を管理したりと、ごく一般的なものである。だが、プライベートで利用するからこそ徹底して使い心地にはこだわりたい。 ほう、今日はMacのエントリか。 と思ったそこのアナタ！早合点してはいけない。確かにMacは素晴らしい。だが、今回俺がチョイスしたのはMacではない。Linuxだ！そんなわけで、本エントリではノートPC購入からインストールしたアプリについて紹介しようと思う。 なぜMacを買わなかったのか？この点について疑問に感じる方も多いことだろう。最近、ギークの間ではMacが流行しているように思う。しかるに、iPhoneの開発プラットフォームとしての需要があるせいだろう。 いや、確かにMacのUIは洗練されてるしアプリケーションも充実しているので、プライベートで使うにはもって
残暑なんて吹き飛ばすぐらい熱いベンチマークをやろうぜ！！
なんて幸運なことなんだろう。 実は最近、個人的にサーバーマシンを借りるという機会があった。そのマシンに搭載されているCPUコア数は合計48である！大事なのでもう一度いう。日本語でいう。48CPUコアだ！一昔前なら数千万円もしたスペックだろうが、最近は実にリーズナブルにお求めいただけるようである。（価格についてはふせておく。）このマシンには2.2GHzのOpteron 6174が4つ搭載されている。つまり、ひとつのパッケージに12個のコアが格納されているのだ。これはすごい。いや、むしろどうしてこうなった？！というべきか。そのようなマシンを目の前にすると時代はメニイコアに向かっているんだなあと実感せざるを得ない。 今後、CPUがどんどんメニイコアに向かう流れはさけれない。コアを増やさなければCPUの性能が（システム全体としての性能が）向上しないからだ。CPUの演算回路に対して半導体素子をたくさ
InnoDB Pluginことはじめ。快適ストレージエンジン生活はじまる！
MySQL 5.1.38からMySQL本体にInnoDB Pluginバンドルされている。一部の先駆的なユーザー以外に、「InnoDB使ってますよ！」もしくは「検証してるよ！」という話をあまり聞かない。そもそもであるが、InnoDB Pluginってなんぞ？！という人が多いんではないかと思うのだが、実際はどうなのだろう？現在はRC版（リリース候補版）という位置づけのInnoDB Pluginであるが、一部影響度の高いバグが残っていたりしてGA版ほどの安定性は求められないものの、ほとんど実用に耐えうる品質になっているといえる。そんなわけで、今日は改めてInnoDB Pluginの使い方・使いどころについて説明するので、ぜひ皆さんの手でInnoDB Pluginを評価してみて頂きたい。 なお、以下の解説は現在の最新バージョンである、InnoDB Plugin 1.0.6を前提にしているので、将
スライド公開（Dena Technology Seminar #2、ClubDB2）＋告知
最近ブログの更新が滞り気味である。とはいえ、何もしていなかったわけではない。勉強会で話すことになり、スライドの作成に邁進していたのである。で、そのスライドがこれだ！ まずはひとつめ。DeNA Technology Seminar #2に招いて頂いたときのもの。内容はMySQL 5.5の新機能に関するものだ。プラスアルファとして、トラブルシューティング本が出版された直後のスライドであったため、「トラブルシューティングの心得」を末尾に収録している。 http://www.slideshare.net/nippondanji/denatech2-mysql55 セミナーの様子はustにて録画が残っているので興味のある方はご覧頂きたい。 http://www.ustream.tv/channel/dena-technology-seminar そして、以下はClubDB2にお邪魔したときのものであ
受託開発とGPL ー 補足事項
前回は受託開発をする際にGPLライブラリを用いた場合のライセンスの扱い、主にソースコードの開示義務について説明した。今日はさらにもっと掘り下げて、受託開発でGPLが使える場合、使えない場合、使いたい場合などについて考察してみたい。なお、今回のエントリは前回の続きであるため、まだ前回のエントリを読まれていない方は先にそちらを読んで頂きたい。 おさらい: ライセンシーへソースコードを開示する前回のエントリにおいて解説したことまとめると次の2点となる。 受託開発でGPLを使うときは、発注者＝ライセンシーに対してGPLに基づいてソースコードを開示する必要がある。 ライセンシーがソフトウェアを再配布するかはあくまでもライセンシーの自由。 後者について補足すると、GPLではライセンシーに対してNDAなどでソフトウェアの再配布を禁止することを認めていない。発注者側が「GPLソフトウェアとして一般公開しよ
受託開発とGPL
GPLに対する代表的な誤解・・・というかむしろ謎のひとつに、受託開発（SI）におけるライセンスの扱いがある。この点が明確になっていないため、受託開発において無意味にGPLを回避しようとしたり、GPLに対するFUDを流布することに対する原因になっていたりするように思う。フリーソフトウェアおよびオープンソースソフトウェアを愛する者として、そのような状況は断じて見過ごすことができない！！というわけで、今日はGPLを受託開発（SI）において用いる場合の注意事項を説明しよう。 GPLの使いどころ受託開発においてGPL（とその仲間たち＝LGPL、AGPL）が登場するのは、第三者、つまり発注側でも受託側でもない者が作成したGPLのソフトウェアを利用する場合である。例えばGPLが適用されたライブラリなどだ。周知の通り、GPLのソフトウェアをリンクしたソフトウェアを再配布する場合は、そのソフトウェア全体に対
パーティショニングの使用例 - http session情報
今日もパーティショニングの話の続きである。 パーティショニングが非常にフィットする（たぶん昨日の例よりも）もう一つのケースは、数日間だけ必要なデータを蓄えておくような場合だ。例えば、HTTPセッションやログ情報などが良い例ではないだろうか。そういう場合には、日付を使ってRANGEパーティショニングをするのである。RANGEパーティショニングでももちろんPruningによって性能の向上は出来るのだが、それよりも何よりも高速に不要なパーティションを破棄できるというのが大きい。パーティションの破棄は、内部的にはテーブルのDROPとほぼ同じ扱いなのである。DROPのスピードはストレージエンジンによるが、InnoDBやMyISAM、NDB（MySQL Cluster）ならばいくらデータを含んでいても関係なくDROPは一瞬である。テーブルから大量の行を削除すると、フラグメンテーションが発生したり、イン
たった3秒でInnoDBのデータローディングが快適になるライフハック
MySQLに限った話ではないが、データベース管理システムに大量のデータを投入するのは時間が掛かり大変苦痛を伴う作業である。劇的に効能があるわけではないが、MySQLを利用しているとき、特にInnoDBを使っている場合にはデータの投入を高速化するためにいくつかテクニックがあるので紹介しよう。皆さんの作業時間が短縮され、少しでも早く帰路に着いたりサービスインさせたりという形でお役に立てれば幸いである。ちなみに、タイトルはネタであるのだが、もし本当に3秒で以下の全ての設定を行えた人が居たら教えて頂きたい！ ログファイルサイズの調整データ投入時に限った話ではないが、ログファイルサイズを調整するのは更新性能にとって非常に重要なファクターである。バッファプールのサイズが重要なことに代わりはないが、同じぐらいログファイルのサイズも重要である。InnoDBはログファイルを使い切ってしまうと、バッファプール
MySQLerのTwitterアカウントまとめ。
松信氏の、 MyISAMとInnoDBのどちらを使うべきか Twitterで話題になってたので簡単にまとめました。 というエントリが人気を博しているが、松信氏が言うように最近はTwitterでMySQL関連の話題も結構増えてきているように思う。Twitterの流行の勢いは凄まじく、今は右を向いても左を向いてもTwitter、寝ても覚めてもTwitter、猫も杓子もTwitterという雰囲気である。従ってMySQLもTwitterで盛り上がるのは当然の成り行きというもであるし、Twitterを活用しない手はない。 しかしMySQL関連の話で盛り上がると言っても「じゃあ誰をフォローすれば話に入れるんだよ？！」と多くの皆さんは疑問に思われることだろう。そこで、今日はMySQL関連のTwitterアカウントを独断と偏見と愛と勇気と努力をもって紹介する。MySQLの情報が欲しい人、もしくは話題の輪に
MySQLのEXPLAINを徹底解説!!
以前、MySQLを高速化する10の方法という投稿で「EXPLAINの見方についてはいずれ解説しようと思う」と書いてしまったので、今日はその公約？を果たそうと思う。 MySQLのチューニングで最も大切なのは、クエリとスキーマの最適化である。スキーマの設計は一度決めてしまうとそのテーブルを利用する全てのクエリに影響してしまうためなかなか変更することは出来ないが、クエリはそのクエリだけを書き直せば良いので変更の敷居は低い。そして遅いクエリをなくすことは、性能を大幅に向上させるための最も有効な手段である。従って、アプリケーションの性能を向上させたいなら、まず最初にクエリのチューニングを検討するべきなのである。 最適化するべきクエリはスロークエリログやクエリアナライザで見付けられるが、ではそのようなクエリが見つかった場合にはどのように最適化すればいいのか？そのためにはまず現在どのようにクエリが実行さ
なぜMySQLのサブクエリは遅いのか。
よくMySQLはサブクエリが弱いと言われるが、これは本当だろうか？半分は本当で半分は嘘である。MySQLのサブクエリだってなんでもかんでも遅いわけではない。落とし穴をしっかり避け、使いどころを間違えなければサブクエリも高速に実行できるのである。今日はMySQLがどんな風にサブクエリを実行し、どのような場合に遅いのかということについて説明しよう。 EXPLAINで実行計画を調べた際に、select_typeにはクエリの種類が表示されるのだが、代表的なサブクエリには次の3つのパターンがある。 SUBQUERY DEPENDENT SUBQUERY DERIVED 結論から言おう。遅いのは2番目、DEPENDENT SUBQUERYである。DEPENDENT SUBQUERYとはいわゆる相関サブクエリに相当するもので、サブクエリにおいて外部クエリのカラムを参照しているサブクエリのことである。そし
MySQLのプロンプトを変更する。
MySQLのCLI（コマンドラインインターフェイス）を利用しているとおなじみの mysql> というプロンプトがあるが、実はこれは変更が可能である。MySQL CLIを利用している最中なら、promptコマンドを実行すれば良い。例えば次のように。 mysql> prompt \U [\d] >\_ PROMPT set to '\U [\d] >\_' mikiya@localhost [test] > \Uや\dはそれぞれ意味が決まっていて、それらを組み合わせることで任意の情報をプロンプトに表示できるわけである。見易いように > やスペース、括弧などを組み合わせるといいだろう。例えば何かの作業をするときには mysql> prompt 作業1 [\D]>\_ PROMPT set to '作業1 [\D]>\_' 作業1 [Tue Mar 17 07:39:28 2009]> などとする
MySQLレプリケーションを安全に利用するための10のテクニック
MySQLのレプリケーションは非常に簡単に使える割には応用の幅が広いので非常に人気のある機能の一つである。レプリケーションの応用分野は例えば、 バックアップ 参照系の負荷分散 HA（高可用性） ディザスタリカバリ（サイト間レプリケーション） BI（レポーティングetc） という風にとても多くのバリエーションがある。このブログを読んで頂いている皆さんの中にもレプリケーションを使っている方は多いのではないだろうか。ご覧の通りMySQLのレプリケーション機能はミッションクリティカル分野でも利用されているが、レプリケーションの使い方が適切でないとシステムの安定稼働に支障を来してしまってDBAやシステム管理者の肉体的、精神的負担が増大してしまう。逆にレプリケーションを堅牢に運用することが出来ればマクラを高くして眠れるというものだ。レプリケーションはMySQLの代表的な機能であるので、レプリケーション
さらにMySQLを高速化する7つの方法
MySQLを高速化する10の方法という記事がとても好評だったようである。記事を読んで頂いた皆さん、ありがとう。 この記事に対する便乗（？）でWeb屋のネタ帳: PostgreSQLを高速化する16のポイントという記事を書いて頂いたようだが、そちらの方もかなり人気だったようである。他人が作ったソフトウェアに改良を加えるというフリーソフトウェアやオープンソースソフトウェアの精神も基本は便乗であるので、便乗については大いに賛成したいというかむしろ取り上げてくれてありがとう！！と思うわけであるが、ここでさらに俺はこう考える。 と。 Web屋のネタ帳さんの記事では16のポイントが紹介されているが、漢（オトコ）のコンピュータ道の記事は10の方法だったのであと6つ足りない。オトコは数で勝負！！というわけで今日はネタを振り絞ってさらに7つのMySQL高速化テクニックを紹介しよう。 1. インテルコンパイラ
漢(オトコ)のコンピュータ道: MySQLを高速化する10の方法
ちょっとキャッチ−なタイトルをつけてしまったが、今日は独断と偏見でMySQLを高速化する方法を10個紹介しよう。MySQLサーバをチューニングするときや初期導入する場合などに参考にしてもらいたい。 1. バッファを増やす、または減らす チューニングの基本中の基本であるが、適切なバッファサイズを設定することはパフォーマンスチューニングの要である。主なバッファは次の通り。 innodb_buffer_pool_size・・・InnoDBだけを利用する場合は空きメモリの7〜8割程度を割り当てる最も重要なバッファである。余談だが、実際にはここで割り当てた値の5〜10%ぐらいを多めにメモリを使うので注意が必要だ。 key_buffer_size・・・MyISAMだけを利用する場合は、空きメモリの3割程度を割り当てるといい。残りはファイルシステムのキャッシュ用に残しておこう。 sort_buffer_
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
