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: Pacific という名前の分散ストレージを作り始めた件
大規模なウェブアプリケーションのボトルネックがデータベースであるという点については、多くの同意が得られるところだと思います。解決策としては、同じ種類のデータを複数の RDBMS に保存する「sharding」 (別名：アプリケーションレベルパーティショニング／レベル２分散注1) が一般的ですが、最近では、分散キーバリューストア (分散 KVS) を使おうとする試みもみられるようになってきています。 分散 KVS が RDBMS sharding に対して優れている要素としては、事前の分割設計が不要で、動的なノード追加（とそれにともなう負荷の再分散）が容易、といった点が挙げられると思います。一方で、Kai や Kumofs のような最近の実装では eventually consistent でこそ無くなってきているものの、ハッシュベースの分散 KVS は、レンジクエリができなかったり (例:
仮想化環境を「DNSで」管理するはてな，分散ストレージを自社開発したライブドア
シンプルでスケーラブルな分散ストレージを自社開発したライブドア 一方ライブドア執行役CTOの池邉智洋氏は，同社のブログや写真投稿サービスなどのインフラで利用中のストレージ仮想化ソフトを自社開発した事例を紹介した。ライブドアのサービス群が求める要件が「いかに安価に容量を追加できるか。過剰な機能と信頼性は不要」（池邉氏）と判断。メーカー製のネットワーク・ストレージの利用を止め，「ファイルのパスがそのままURLになるため，ファイル・システムのパスをURLに変換しなくて済む」HTTPで入出力する分散型仮想ストレージの開発に踏み切ったのだという（写真4）。 設計思想は「複数ノード間の一貫性はCAP定理に基づいて遅延を妥協し，スケーラビリティと読み出しの速さにこだわった。一方で書き込みはそこそこの速度でよく，認証とアクセス制御はアプリケーションで実装するので不要」（池邉氏）というもの。HTTPサーバー
mixi Engineers’ Blog >> Tokyo (Cabinet|Tyrant)の新機能
アロハシャツとショートパンツとビーサンで出勤してスネ毛が美しくないと評判のmikioです。さて今回は、Tokyo Cabinet（TC）とTokyo Tyrant（TT）のそれぞれ最新版でサポートされた新機能についてご紹介します。 固定長データベース 最終ログイン時刻データベースをTTで管理する仕組みについての記事を以前書きましたが、それに対して「各レコードを固定長にすればlseek一発で参照できるよ」という趣旨のご指摘をいただきました。全くその通りで、最終ログイン時刻の値に必要な領域は各ユーザ毎に10バイトもあれば十分ですし、検索キーはユーザID（mixiにおいては1からの連番）なので、それを添字に使えば二次元配列としてデータベースを表現することができます。 ただし、yamazさんも指摘しているように、ログイン時刻データベースのスループット限界はwriteがブロックすることにより訪れるの
レプリケーションを使う - Unlimited Island
レプリケーションとは、あるデータベースから他のデータベースに複製を作ることです。 これは通常、以下のような理由から使われます。 サーバがダウンしたときの対処 複数のデータベースが同じ内容を持つことで、一つのサーバがダウンしても 他のサーバを使うことが可能になります。 負荷分散 複数のデータベースを交互にアクセスすることで、一つのサーバに掛かる負担を減らすことが出来ます。 MySQLでは「一方向レプリケーション」を採用しています。 一つのサーバを「マスタ」として機能させ、残りのサーバが「スレーブ」になります。 データの複製は「マスタ→スレーブ」という方向でのみ行われます。 そのため、データの更新は必ずマスタサーバで実行する必要があります。 マスタサーバで更新を行うと、その更新内容が全てのスレーブサーバに通知され スレーブサーバはマスタサーバと同じ更新処理を行います。これにより、マスタとスレー
Amazon Elastic MapReduceを使ってみた - moratorium
Amazon Elastic MapReduceを使ってみた 2009-04-03 (Fri) 3:06 Amazon EC2 連日のEC2ネタです。本日、AmazonからElastic MapReduceというサービスがリリースされました。大規模データ処理技術が一気に民間の手に下りてくる、まさに革命的なサービスだと思います。 Amazon Elastic MapReduce Amazon ElasticMapReduce 紹介ビデオ With Hadoop, Amazon Adds A Web-Scale Data Processing Engine To Its Cloud Computer by techcrunch.com Elastic MapReduceは、Googleの基盤技術の一つであるMapReduceを時間単位課金で実行できるサービスです。MapReduceについては以
livedoor Blogの中の人が裏側を語る、Winny金子氏の講演も
ライブドアは27日、同社技術部会の主催による技術者向けのセミナー「第1回ライブドアテクニカルセミナー」を開催した。セミナーでは、ライブドアが運営するブログサービスのシステムや、データセンター事業を含むネットワーク運用についての解説などが行われたほか、ゲストとしてファイル共有ソフト「Winny」を開発した金子勇氏と弁護士の壇俊光氏が招かれ、配信技術と法的問題に関する講演が行われた。 ● 新サービス「livedoor Blog ASP」を4月に提供 ライブドアメディア事業部ブログBU開発グループの垣内秀之氏は、ライブドアのブログサービス「livedoor Blog」のシステムの裏側を紹介。livedoor Blogは2003年11月にサービスを開始し、現在では約270万ユーザー、1日約5000万ページビュー、1日の投稿記事数が約10万という巨大なサービスとなっている。 垣内氏はlivedoor
0×0018 till I die » はてなnaoyaさん「はてなを支えるバックエンドシステム」
403 Forbidden nginx
「クックパッド」の裏側にいってきた | Carpe Diem
Web デベロッパーの祭典に行ってきた。今回は、通路沸きに用意された比較的狭いスペースで開催された。 以下、メモと自分の勝手な感想をまとめておく。 クックパッドについて 毎日の料理を楽しみにすることで心からの笑顔を増やす 1998年にオープン 去年のリニューアルのときに Rails で作り直した 使い方 レシピをのせる レシピをさがす 月間ユーザ数 547万人 Rails サイト中世界7位 (from rails 100 wiki)、まさか1位がscribd.comとは 月間 2.8億 PV(PVでは、Rais サイト中世界3位) 登録レシピ数: 47万品 トラフィックは、16-18時くらいがピーク(夕飯を作る前に調べるユーザが多いとのこと) 秋からバレンタインにかけてトラフィックが伸びる(来週はピークだということで、最近はパフォーマンス向上に中心にやっていた) ユーザ数: 547万人(す
mixiの年末年始対策 日記投稿システムの改善 - mixi engineer blog
朝晩冷えてきましたね。風邪など引いていませんでしょうか。さて、年末が近づいてくるこの時期に弊社のエンジニアが最も気になるのは、お正月。それも来年1月1日を迎えた瞬間です。 1日1日0時に何があるのでしょう？そう、mixiのサービスで最も日記が書き込まれるタイミングになるのです。個人的に「あけおめことよろアタック」と呼んでいます。今年は日記だけではなく、エコーでもメッセージが飛び交うことでしょう。この時期は携帯電話のキャリアでもさまざまな対策を行っていますが、ミクシィでも年末年始でもユーザの方に快適にサービス提供ができるように努めています 以下は昨年の年末年始の日記投稿数の推移です。青色が12/31から1/1、赤色が1/1から1/2になります 1/1の方が全体的に多いですが、特に年が変わる前後の投稿数は倍近くなっていることがわかります。この時に負荷により日記の投稿がしづらい状態になっていたの
楽天テクノロジーカンファレンス 2008にいってきました - d.hatena.zeg.la
1000人以上のエンジニア、全国各地に開発拠点をもっている 楽天のテクノロジーカンファレンスにいってきました。 分散並列処理フレームワークfaily,P2PオンメモリストレージROMAが 2009年にOpenSource化されるとのことでした。 楽天ウェブサービス APIの紹介 16種類のAPI 直近だと楽天ランキングAPI 1500万件,2万件の宿泊施設 Affiriateと連動可能 REST,JSON,SOAPのフォーマットをサポート 楽天ダイナミックアド 楽天版アドセンス 記事の内容にマッチした楽天の商品を出す 楽天経済圏 APIを使ったアプリが入り込める マッシュアップブームおちちている ALL 35,000ID Active 5,000ID Webサービス経由の流通金額は7.24% 3,500万request/day ItemSearch,GenreSearch,Itemcode
KOF 2008 の発表資料 - naoyaのはてなダイアリー
KOF 2008 での発表資料「はてな流大規模データ処理」を以下にアップロードしました。 http://bloghackers.net/~naoya/ppt/081108huge_data.ppt 一部参考文献からの引用 (Introduction to Information Retrieval から Vector space model の図、たつをの ChangeLog から転置インデックスの図) があります。この場を借りて感謝。 環境によってはおそらくフォントの表示がいまいちだと思いますが、ご了承ください。 追記 SlideShare にアップロードしました。 081108huge_data.pptView SlideShare presentation or Upload your own. (tags: linux mysql) 追記: メモリはディスクの 150 倍について
「はてな流大規模データ処理」を見てきた - もぎゃろぐ
KOF2008：関西オープンソース2008というイベントに来ています。 はてなの伊藤さんの講演があったので、講演メモを公開。 ＃ボクがメモした内容であって、100%言ったとおりに書いてあるわけじゃないので、参考としてご覧ください。 (続き) アジェンダ 大規模なデータ OSのキャッシュ MySQLの運用 大規模データアプリケーションの開発 データの例 はてなブックマークのデータ量：五千万件くらいのデータ量 このデータに対して何百万人がアクセスしてくる状況でどういう作りにするか レコード数 1073万エントリー 3134万エントリー 4143万タグ データサイズ エントリー2.5GB 何の工夫もなく普通にアクセスすると...200秒待っても結果が帰ってこない 大規模データの難しいところ 開発サーバで開発者が作っている時は快適に動いていても、多数の人間がアク
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
scale out の技術 〜 consistent hashing 編 (cloud 研究会, December 19, 2008)
Hadoop、hBaseで構築する大規模分散データ処理システム
「実現したいことを計算機の問題に置き換えることが『技術力』」、伊藤CTOが“はてな流”大規模データ処理の極意を語る：CodeZine