TwitterとDiggがNoSQLの「Cassandra」を選ぶ理由
スケーラブルなデータベースを実現する手段として「Sharding MySQL plus memcached」がよく知られる方法だとは、1つ前の記事「MySQL+Memcachedの時代は過ぎ、これからはNoSQLなのか、についての議論」で紹介しました。 ちなみに「Sharding」（シャーディング）とは複数のデータベースにデータを分散して運用することで、ざっくりいえばShared Nothing的な分散データベース構成のことです（この記事で紹介する英文中には「Shared MySQL」（共有MySQL）との記述がありますが、これは恐らく「Sharded MySQL」（ShardされたMySQL）のミススペルではないと推測します）。 日本で（たぶん）もっともMySQLについて詳しく解説してあるブログ「漢(オトコ)のコンピュータ道」のエントリ「さらにMySQLを高速化する7つの方法」では、Sh
画像配信の負荷分散も比較的簡単？（その1） - 最速配信研究会(@yamaz)
30万個ぐらいの静的ファイルを配信するサーバーの選び方 で静的な配信サーバに関することが述べられている. naoyaさんが公開されてるInside Hatena Bookmark's Backend の資料などを読むと、mod_perlなサーバーやMySQLサーバーの選び方の参考になったりするわけですが、世の中を見渡してみても、静的コンテンツ（画像とか）を配信するサーバーの指南書らしきものはなかなか見あたりませんでした。 なので、経験を元に書いてみることにします。 ということらしい.書いてあることはすべて同意だけど, つい3ヶ月くらい前まで 平均15k×1万URL×50億httpアクセス/day 平均4KByte×100万URL×3億HTTPアクセス/day な画像サーバと某所で向き合ってたため,ちょっとは役に立てるかもしれないと思ったので,私の経験を書いてみようと思う. 動画配信の負荷分
クラウドの一貫性って - noopな日々
CAP定理というのは、 Consistency Availability Partitions という状態の2つまでしか達成できない。３つすべてを達成することはできないという定理である。例えばConsistency（一貫性）とAvailability(可用性)を同時に満足させるとPartitions(分散)を達成するのをあきらめるしかない。可用性と分散性を同時に満足させるにはConsistency（一貫性）をあきらめる。すなわちEventually Consistentな状態を受け入れる。 そーゆー状態を受け入れるとスケーラビリティを達成できるようになるので、巨大なデータセンターの中に安いPCサーバーを大量においてCAPのCを若干犠牲にしつつ、高速なデータ処理を行う。そのような計算モデルである。 クラウド時代の計算パラダイムがRDBMSが30年間研究開発していたACIDパラダイムからCAP
KOF2009「ウェブサービスのパフォーマンスとスケーラビリティ」 - stanaka's blog
KOF2009にて、「ウェブサービスのパフォーマンスとスケーラビリティ」と題して発表してきました。発表資料を以下に置いておきます。 Performance and Scalability of Web ServiceView more presentations from Shinji Tanaka. 概要は、「ウェブサービスのパフォーマンスを向上させスケーラビリティを高めるために、はてなでは様々な取組みを行っています。本セッションでは、はてなで採用している具体的な技術、ノウハウ、可視化手法と、それらの効果について紹介します。」というものです。 最近の、Interopやカーネル読書会あたりで話した内容をまとめつつ、レスポンスタイムの可視化という最近の取り組みについて話しました。 最近、レスポンスタイムについては、以下のようなグラフを使っています。 x軸がレスポンス時間、y軸がその時間内に収
Migration to a Better Datastore
News, notes, tips and tricks from the Google App Engine Team At Google, we've learned through experience to treat everything with healthy skepticism. We expect that servers, racks, shared GFS cells, and even entire datacenters will occasionally go down, sometimes with little or no warning. This has led us to try as hard as possible to design our products to run on multiple servers, multiple cells,
Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services Seth Gilbert∗ Nancy Lynch∗ Abstract When designing distributed web services, there are three properties that are commonly desired: consistency, avail-
Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services Seth Gilbert∗ Nancy Lynch∗ Abstract When designing distributed web services, there are three properties that are commonly desired: consistency, avail- ability, and partition tolerance. It is impossible to achieve all three. In this note, we prove this conjecture in the asyn- chronous network model, a
満足せる豚。眠たげなポチ。:大規模サービスの運用事例まとめ
ここ数年の大規模サービスのシステム運用について調べてみたので参照したページやファイル、本へのリンクをまとめておく。PDF へのリンクも多数含まれているのでご注意を。 時代が時代なら企業のノウハウとして隠されていたような情報がこれだけ公開してもらえているというのが非常にありがたい。公開してくれている各企業や公開してくれている人に感謝。 あとで気付いたが、Google や Facebook の事例も探しておけばよかった。Thrift とかあったのに。「こんな情報もあったよ」などあればぜひ教えてください。追記していきます。 youtube http://d.hatena.ne.jp/stanaka/20070427/1177651323 digg http://d.hatena.ne.jp/stanaka/20070427/1177651323 livedoor http://labs.cybo
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Elevated Datastore latency, error-rates, serving errors