「実現したいことを計算機の問題に置き換えることが『技術力』」、伊藤CTOが“はてな流”大規模データ処理の極意を語る：CodeZineCodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。
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 倍について
GIGAZINEが新サーバに移転完了しました
というわけで、ここが新サーバです。これで平日昼間の発狂したかのような重さが改善されればよいのですが……。次の段階は複数台による負荷分散ですね。 というわけで、やたら重い状況を多少改善してくれた各種設定などは以下から。 あまりにもスロークエリが発生するのでこれを軽減できないかと思い、下記のページを読んでみました。 【MySQLウォッチ】第14回 サーバー設定を見直してMySQLの性能を引き出す：ITpro [ThinkIT] 第4回：ベンチマークツールを使った負荷テスト (2/3) テーブルキャッシュ（table_cache）とスレッドキャッシュ（thread_cache）を設定したところ、飛躍的に負荷が軽くなりました。朝の9時から夜中の0時までひっきりなしに発生し続けていたスロークエリが、アクセスの集中する正午頃以外はほとんどなくなりました。キャッシュってのはうまく使えば非常にお役立ちです
Scaling Twitter: Making Twitter 10000 Percent Faster - High Scalability -
Update 6: Some interesting changes from Twitter's Evan Weaver: everything in RAM now, database is a backup; peaks at 300 tweets/second; every tweet followed by average 126 people; vector cache of tweet IDs; row cache; fragment cache; page cache; keep separate caches; GC makes Ruby optimization resistant so went with Scala; Thrift and HTTP are used internally; 100s internal requests for every exter
はてなブックマークの裏側その後 - naoyaのはてなダイアリー
まるごとPerl! Vol.1 で執筆させていただいたはてなブックマークのシステムに関する記事が ThinkIT で読めるようになりました。記事全体を何回かにわけて掲載していただいています。まるごとPerlの記事なのですが、実は Perl のことはあまり触れていなくてはてなのサーバー運用概論みたいは話が主なところです。 http://www.thinkit.co.jp/free/article/0610/1/1/ http://www.thinkit.co.jp/free/article/0610/1/2/ せっかくなので現状報告も含めて少し補足をしてみようかなと思います。 現在の数字 記事の中での数字は6月のもので ユーザー：45,000人 ブックマーク数：535万件 ページビュー：5,000万/月 サーバー：17台 となってますが、現在 10 月の方はというと ユーザー: 60,000
[Vol.3] RailsとMySQLによる大規模サイト構築実験
MySQL + Railsで大規模サイト構築実験もいよいよ大詰めです。 前回までは、 DB : Active-Active LB : Active-Passive 構成を想定して構築してきました。 また、レプリケーションの遅れによる更新の衝突を避けるための解をいくつか紹介しました。 だがActive-Active構成にするコストが大きい！！ 「そもそもActive-Active構成で組む必要があるのかどうか？」といった疑問が沸いてきました。 調査を進めたところ、DBのActive-Active構成にするコストに対して、メリットが少ないことが判明。 [Active-Active構成を組むメリット] 瞬間的なコネクション増への対応が可能。 コネクションの負荷分散のみ可能。(I/Oの負荷分散はできない) [Active-Active構成を組むデメリット] 更新系クエリの負荷分散は不可。 レプリケ
[Vol.2] RailsとMySQLによる大規模サイト構築実験
vol2でも引き続き、負荷分散・高可用性を備えるDBとWEBアプリケーションフレームワーク(以下AF)のセットアップを目指します。 デュアルマスタ構成に複数台のスレーブがぶら下がっています。 もう少し、詳しく今考えているアーキテクトを見ていきたいと思います。 最小構成: マスタ2台, スレーブ1台 最低3台のDBを用意します。 なぜ3台か？スレーブを追加する際には、マスタのスナップショット取得のためにマスタへの更新を停止する必要があります。データ量が増えると、マスタを停止してスナップショットを取得するには、長時間を要するため、これは現実的な解ではない。 そこで、スレーブをマスタのスナップショットとして考え、スレーブへのレプリケーションを一時停止し、スレーブのスナップショットを新規に用意したスレーブにコピーしレプリケーションを設定する。 スレーブが1台しか存在しない場合でのスレーブ停止時は、
![[Vol.2] RailsとMySQLによる大規模サイト構築実験](https://cdn-ak-scissors.b.st-hatena.com/image/square/b32c7212a71686a423457f26d96cfa0955f315a3/height=288;version=1;width=512/https%3A%2F%2Flh3.googleusercontent.com%2Fblogger_img_proxy%2FAEn0k_txPto9Jq098uA-Y2iq1hriiYhTsUYOaZ_EnnE3uRWq2cwG4HHQ35bO_YnRmt1BOAc7gh6xjYRd9h9WjwEM3OUQi1efJplNOq7I6OAbgf7HNXnG0ZEZOllpBklk0n5aBmNOCr2yAs1StqmGl4A%3Dw1200-h630-p-k-no-nu)
[Vol.1] RailsとMySQLによる大規模サイト構築実験
大規模サイト構築のための土台を作っていきます。 ASP事業に力を注入するとなると、２４H7D動作し続ける安定したサービスのためのインフラがまうます必須になるはずです。 アーキテクト WEBサーバ 何でもいい。 WEBアプリケーションフレームワーク Ruby on Rails DB MYSQL で実験していきます。 とりあえず、必要そうなもの。 1. WEB 負荷分散 ・冗長化 2. DB 負荷分散 3. DB 冗長化 4. Railsの拡張(DBへのコネクション周り) まず1番。 ロードバランサー使えばできるし現在のドリコムでも、DUOBLOG APIやCMS ASPはクリアしてます。DNSラウンドロビンは、障害検知が不可能なのでNGです。 次は、2番。 クエリは、参照系クエリと更新系クエリに分類されます。 今ドリコムでDBへのクエリを負荷分散させているプロジェクトは(僕の知っているところ
![[Vol.1] RailsとMySQLによる大規模サイト構築実験](https://cdn-ak-scissors.b.st-hatena.com/image/square/4eaa2c21ab0ee25aaa9581edc9de7790ee81dcf0/height=288;version=1;width=512/https%3A%2F%2Flh3.googleusercontent.com%2Fblogger_img_proxy%2FAEn0k_s27yaREMaTKhBvb0Bj9DzUtXXaiLzrmgNTLn20ziH3KhNj3LUOBRxBobwdzpp4UG3Wl7WhtzH43n9CiaJCQU5Us54TdCdomqcNr3tWbcA3mWHGmd6hcvhrxICuDQBO40mlx_NHmBjLoeYSe0M%3Dw1200-h630-p-k-no-nu)
[O] Railsで複数DBを使い分けるためのライブラリ magic_multi_connections
「magic_multi_connections」というRailsで複数DBを使い分けるためのラ イブラリについて、まとめている記事がありました。 Twitterのトラブルから見る、DB分割でスケーラブルなRailsサイト構築:TKMR.blog.show 最近、2.0な方々の間でTwitterが話題になってる。で、そのTwitter自体 も面白いんだけど、TwitterについてDHHがブログを書いてRailsでの大規 模サイト構築が話題になってるのが面白い。 基本一つのDBを見るRailsを、複数DBを使えるようにできるようです。 さらに、acts_as_readonlyableという同じように複数DBを使うための ライブラリについても言及されていました。そのうち使うと思うのでメモ。 [2007-04-27]：追記 この話題に対する言及を見かけました。 みかログ: DBの分散方法 2種類
DBの分散方法 - みかログ
Rails って，結構人気があるから，既にそういう機能もあるのではと思っていたけど，無かったらしい． 簡単に実装できるから，誰も公開していなかっただけなのかもしれないけど．(^^; Scaling to multiple databases with Rails (Loud Thinking) Twitterのトラブルから見る、DB分割でスケーラブルなRailsサイト構築 2種類のモジュールがあるようだけど，readonlyable 方式はすぐ問題が出てきそうな気がする． たとえば，ユーザ登録時にIDの重複判定をするような場合，read_only 指定をしていると，masterからslaveへの更新反映が遅延するため，正しく重複判定出来ない可能性が出てしまいそう． かといって，read_only 指定をしないと，アクセスが多そうなユーザ情報のテーブルが分散されない． その辺を考えると，多少
Scaling to multiple databases with Rails (Loud Thinking) - Matzにっき(2007-04-16)
<< 2007/04/ 1 1. エープリルフール 2. [Ruby] オブジェクト指向機能を取り除いた Ruby-- が登場!? 2 1. [教会] セミナリー１日目 2. LMLML 3. [Ruby] 最速配信研究会 - なんだかいろいろ申し訳ない気分になった話 4. [Ruby] Headius: ActiveRecord 100%, Performance Doubling, Java Support Improving 3 1. [Ruby] Bitwise Magazine:: What's Right With Ruby? 2. [OSS] オープンソースソフトウエアがビジネスの成長を加速 3. Passion For The Future: なぜ株式投資はもうからないのか 4 1. [Ruby] Rails 1.2と1.1、速いのはどっち? - Railsbenchによる
Twitterのトラブルから見る、DB分割でスケーラブルなRailsサイト構築:TKMR.blog.show
最近、2.0な方々の間でTwitterが話題になってる。で、そのTwitter自体も面白いんだけど、TwitterについてDHHがブログを書いてRailsでの大規模サイト構築が話題になってるのが面白い。 Twitter trouble (Loud Thinking - DHH) まずTwitterの高負荷について言及、Twitterは11,000リクエスト/秒 の高負荷で問題となっているらしい。 そしてスケーラビリティの鍵はDB分割だ、と言っている。Railsは基本一つのDBを見るのでスケーラビリティの問題になる （確かにWebサーバはロードバランサがあればいくらでもスケールするしね、Sessionの共有だけ気を付ければ） ↓ Dr Nic » Magic Multi-Connections: A “facility in Rails to talk to more than o
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
