Kazuho@Cybozu Labs: MySQL のボトルネックを統計的に監視・解析する方法
MySQL のチューニング、と言った場合には、サーバーパラメータの調整や EXPLAIN コマンドを利用したクエリ実行計画の最適化が話題に上ることが多いです。しかし、発行する全ての SQL について、いちいち EXPLAIN コマンドを使って確認していては、いくら時間があってもたりません。チューニングを効率的に進めるには、まず、ボトルネックとなっている SQL クエリを特定し、次にその最適化を行うべきです。 ではどのようにして、ボトルネックを特定するのか。MySQL Conference & Expo 2009 のキーノートにおいて Mark Callaghan 氏は、Google では SHOW PROCESSLIST コマンドを使った統計的アプローチを使っていると述べていらっしゃいます (参照: MySQLConf 09: Mark Callaghan, "This is Not a
Kazuho@Cybozu Labs: MySQL のトリガーの実用性を確認するために InnoDB の SELECT COUNT(*) を高速化してみる
最近 RDBMS のトリガーを色々書いているのですが、知らない人にトリガーが何かいちいち説明するのに簡単な例はないかな、というのと、MySQL の処理速度はトリガーによってどの程度変化するか、ということを確認するために、以下のような実験を行ってみました。 InnoDB はしばしば、「SELECT COUNT(*) が遅い！」と批判されます。では、トリガーを使って行数を別のテーブルにキャッシュすればいいのではないでしょうか？ 以下のように、極めて小さなテーブル t1 を作り、その行数を t1_cnt にキャッシュしてみることにします。 mysql> create table t1 ( -> id int unsigned not null primary key auto_increment, -> v int unsigned not null -> ) engine=innodb
Kazuho@Cybozu Labs: Pacific という名前の分散ストレージを作り始めた件
大規模なウェブアプリケーションのボトルネックがデータベースであるという点については、多くの同意が得られるところだと思います。解決策としては、同じ種類のデータを複数の RDBMS に保存する「sharding」 (別名：アプリケーションレベルパーティショニング／レベル２分散注1) が一般的ですが、最近では、分散キーバリューストア (分散 KVS) を使おうとする試みもみられるようになってきています。 分散 KVS が RDBMS sharding に対して優れている要素としては、事前の分割設計が不要で、動的なノード追加（とそれにともなう負荷の再分散）が容易、といった点が挙げられると思います。一方で、Kai や Kumofs のような最近の実装では eventually consistent でこそ無くなってきているものの、ハッシュベースの分散 KVS は、レンジクエリができなかったり (例:
twitterでつぶやく便器が登場 | 秋元@サイボウズラボ・プログラマー・ブログ
twitter.com/hacklabTOiletは、とあるトイレが流されるたびにつぶやくという新登場のbotだ。 このtwitterアカウント、使われるたびに、「流しまーーーーす」「青? いったい何食べたんです?」「いい配管工知らない?」「そのうちRFIDがついたら、あなたの名前も一緒につぶやきますよ」といったメッセージをランダムにつぶやいている。 これは、イタリア製のマイコンボード開発環境arduinoを使って、トイレの排水のオンオフを入力として、イーサネットケーブルでHTTPを投げることで、実現している。 arduinoからtwitterにポストするコードは、フォーラムにあるものをベースに流用しているという。 実際には、トイレを流してもtwitterのメッセージが行ったり行かなかったりするので、トイレにPCを持ち込んで、パケットをキャプチャしてトラブルシュートを行なったらしい。コネク
Ajax を使うべき 10 個のポイント | 秋元@サイボウズラボ・プログラマー・ブログ
10 個ないじゃん。とりあえず数を書いとけ、ってのが最近の流行だろうか。 Ajax を使って意味があるのはどんなところか、Ajax によって事態が悪化するようなところはどこか、というのを考えて列挙しているエントリ。Ajax の適用箇所を悩んでいる人にはいい参考になると思うのでおおまかに紹介。 Ajax を使うといいところ フォームによる多量の入力 深い階層の木構造をたどらせるところ ユーザ間のコミュニケーションを行わせるところ 投票、「はい/いいえ」、評価ボタン フィルタやソートなどのデータ表示操作 テキスト文入力時のヒントやオートコンプリート Ajax を使うべきでないところ 非常に単純で、失敗が許されないフォーム ライブサーチなどの検索 基本的なサイトナビゲーション 大量のテキストの置換 大々的な表示の変化 無意味な Widgets (UI 部品)の利用 個々の「べき・べからず」を主張
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
