Facebookが新しいサービス「Messages」の基盤として、NoSQLデータベースの「HBase」を選択したことを、先日の記事「Facebookが新サービスの基盤にしたのは、MySQLでもCassandraでもなく、HBaseだった」で紹介しました。 HBaseは、Facebookによると次のような特徴を備えていると説明されてます。 負荷に対して非常に高いスケーラビリティと性能を発揮 CassandraよりもシンプルなConsistency Model（一貫性モデル）を備えている 自動ロードバランス、フェイルオーバー、圧縮機能 サーバーごとに数十個のシャードを割り当て可能、などなど このHBaseはどのようなデータベースなのでしょうか？ 情報を集めてみました。 HBase入門のプレゼンテーション 最初に紹介するのは「HBaseエバンジェリスト」Tatsuya Kawano氏のプレゼン
Disclaimer: The opinions expressed here are my own and do not necessarily represent those of current or past employers. Recent CommentsJames Hamilton on Reinventing Operational ResiliencyGk on Reinventing Operational ResiliencyKarthick Sudhan on About PerspectivesJames Hamilton on About PerspectivesKarthick Sudhan on About PerspectivesJames Hamilton on David Patterson Retires After 40 YearsRaffael
Not Only NoSQL!! 驚異的なまでにWRITE性能をスケールさせるSPIDERストレージエンジン
Webサービスでは、世界中からのトラフィックを捌く必要があるため、いくらチューニングしようとも一台のRDBMSでは捌ききることが出来ないのが常だ。MySQLは最初からマスター・スレーブ型のレプリケーション機能が搭載されており、スレーブをたくさんぶら下げることによって参照の負荷をスレーブに割り振るというスケールアウトによってその問題に対処してきた。スレーブによるスケールアウトは、参照（＝PV）が多いWebサイトと非常に相性が良く、幾多のWebサイトにおいて実績を作ってきているし、まだまだ利用されている。 しかしながら、サイトのトラフィックが劇的に増加してくるようになると、レプリケーションによる負荷分散では追いつかなくなってきた。そこで人々がとった選択肢は、memcachedを利用することである。memcachedはインメモリ型の高速なKVSであり、参照・更新性能はMySQLより格段に高い。M
先日、分散Key-valueストア kumofs を公開しました。 多く方から反響とフィードバックをいただいています。ありがとうございます。 今回は、kumofs はなぜスケールするのか、なぜスケールすると言えるのかーということについて紹介したいと思います。 ところでスケーラビリティとは何か？ スケーラビリティとは、利用者や仕事の増大に適応できる能力・度合い とされています（端的！）*1 。Scalability を日本語にすると、拡張性 と訳されるようです。 ただ一口でスケーラビリティと言っても、様々な側面があります。ITシステムでは主には処理性能と運用に関することを指す場合が多いと思いますが*2、その中にも様々な側面があります。 なぜスケーラビリティが必要か スケーラビリティは システムなどが持つべき望ましい特性 であって、高いに越したことはありません。しかし、高いスケーラビリティはタ
CAP定理というのは、 Consistency Availability Partitions という状態の2つまでしか達成できない。３つすべてを達成することはできないという定理である。例えばConsistency（一貫性）とAvailability(可用性)を同時に満足させるとPartitions(分散)を達成するのをあきらめるしかない。可用性と分散性を同時に満足させるにはConsistency（一貫性）をあきらめる。すなわちEventually Consistentな状態を受け入れる。 そーゆー状態を受け入れるとスケーラビリティを達成できるようになるので、巨大なデータセンターの中に安いPCサーバーを大量においてCAPのCを若干犠牲にしつつ、高速なデータ処理を行う。そのような計算モデルである。 クラウド時代の計算パラダイムがRDBMSが30年間研究開発していたACIDパラダイムからCAP
I guess most people don't know this, but I'm the only member of the technical team in NorthScale located in Europe. I live just outside Trondheim in Norway, so it's pretty far from everything. So why did I join NorthScale? A lot of my friends in Trondheim have been asking me that question. To them it sounds strange that I want to work from home for a company located 9 timezones away. I've known Du
藤本さんや首藤さんにお誘いいただいて、コラムの執筆を担当させていただきました。 内容はkumofsについて、特に全体のアーキテクチャと耐障害性についての技術解説です。 『クラウドの技術』は、クラウド関連の要素技術について丁寧にまとめられていることが人気を呼んだ末に、今では入手困難となってしまったという噂の UNIX Magazine 2009年 4月号 の特集を再編集し、さらに多くの新しい記事を加えたものになっています。 目次は以下の通りです： [最新・クラウドプレイヤーたちのサービス] ・Windows Azureの世界（丸山不二夫） ・Windows Azure Tableの概要（丸山不二夫） ・Google App Engine（中田秀基） ・Amazon Web Services（浦本直彦） ・Amazon Web Servicesを取り巻く技術とサービス（浦本直彦） ・富士通のト
システム全体で必要な書き込みパフォーマンスが、RDBMSノード１基の IOPS の W% の場合、シングルマスタ+スレーブn台構成のシステム全体のパフォーマンスは、 書き込みパフォーマンス: W 読み込みパフォーマンス: R=(1-w)*(n+1) になる。この n=R/(1-w)-1 って w が増加するとスレーブ増設のメリットが加速度的に失われていく点がイヤ。 例えば、システム全体で要求される書き込みパフォーマンスが W=0.3 で、読み込みパフォーマンスが 3 ならば、シングルマスタ／マルチスレーブ構成で必要なノード数は5台。マルチマスタ構成を採った場合でも理想値は4台なので、そう遜色があるわけではない。 しかし、仮に必要なパフォーマンスが２倍 (W=0.6, R=6) になると、必要ノード数はマルチマスタ構成での8台に対し、シングルマスタ／マルチスレーブ構成では16台と、一気にコス
2009年は、いよいよクラウド時代の幕明けですね。世の中的にも大不況ですから、導入・運用コストを下げることが期待されるクラウドはまさにうってつけではないでしょうか？ しかし、インターネットのあちら側にあるシステムのことは、いまいちピンとこないことが多いですね。最近よく聞く「CAP定理」なんてのもそのひとつだと思います。この定理時代は、前からあったものですが、もっともらしいことを言って煙（いや雲か。）に巻かれている気がしませんか。そんな「CAP定理」をOracleの分散データベースである「Oracle RAC」を例に取り説明してみたいと思います。 1. CAP定理のジレンマ クラウドの特徴のひとつとして、CAP定理が挙げられます。 CAP定理とは、以下の３つを同時には満たせないという定理です。 C：Consistency（データの一貫性） データの更新後、ほかからそのデータを参照した場合、必
※分散Key-Valueストア「kumofs」を公開しました！ 先日開催されたKey Value Store勉強会に行ってきました。私の発表資料は↓ここからダウンロードできます。 kvs-kumofs.pdf 合わせて読むと理解が深まるかもしれない： スマートな分散で快適キャッシュライフ - mixi Engineer's Blog：Consistent Hashについて バイナリシリアライズ形式「MessagePack」：kumofsのプロトコル。高速なストリームバッファとストリームデシリアライザの実装も含まれています。 Protocol Buffersは遅い：MessagePackのベンチマークとProtocol Buffersとの比較。タイトルは釣り。 memstored：IOアーキテクチャのプロトタイピング マルチコア時代の高並列性IOアーキテクチャ Wavy memcached
ここ数年の大規模サービスのシステム運用について調べてみたので参照したページやファイル、本へのリンクをまとめておく。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
Please Note: this was written January 2009 - see the comments for updates and additional information. A lot has changed since I wrote this. Perhaps you’re considering using a dedicated key-value or document store instead of a traditional relational database. Reasons for this might include: You're suffering from Cloud-computing Mania. You need an excuse to 'get your Erlang on' You heard CouchDB was
一昨日から今日まで3日間の日程で開催されていた、MySQL Conference & Expo 2007に行ってきました。日帰り圏内どころか、自転車圏内で、こういうカンファレンスがあるのは、素晴しいです。 詳細は、随時アップされるであろうプレゼン資料と、Planet MySQLに大量の報告があります(全部英語ですけど)。 個人的に注目していたのは、Digg.com、Flickr.comとYoutube.comのDB周りアーキテクチャのセッションでした。あとは、http://www.mysqlperformaceblog.com/の人のセッションは、細かいTipsが多く、具体的にだいぶ役に立ちそうです。 というわけで、簡単に注目したセッションの内容を紹介してみます。ちなみに、内容の正確さは無保証です:P 気が向けば、もっといろいろ考察してみるかもしれません。 Technology at Di
ここしばらく、水面下でBrian Akerを代表とするMySQL/SUNのエンジニアたちや、業界のオープンソースハッカーたちとMySQLをスリムダウンさせたマイクロカーネルRDBMSを開発していたのですが、本日アナウンスされたので、日本語でご紹介させていただきたいと思います。 Drizzleとは？ Drizzleとは必要のないものは一切存在しない、最低限でパフォーマンス重視な「MySQLよりシンプルで、軽く、安定して、高速な」 MySQLのforkです。マイクロカーネルアーキテクチャを採用したので、必要のないものは後付けできる構成です。こういった目標もあり、現在、Drizzleの開発チームはMySQLをドラスティックにリファクタリングしています。 コミュニティベースのプロジェクト Drizzleで大事な事は、Drizzleはコミュニティベースのプロジェクトであるという事です。Montyのブ
今年もMySQL Conference 2008に行ってきました。社内向けの報告資料と雑多なメモですが、よろしければ参考にしてください。 *1 概要 MySQLがSunに買収されて始めてのConference 8セッション並列で、OSCONの規模にだいぶ近い MySQLが扱うトラフィック量・データ量がどんどん大きくなってきており、それにどう追従するか、という観点の話が多い 買収の話とか "MySQL、新機能追加は有償版の「MySQL Enterprise」だけを対象に"というのは、かなりミスリーディングな記事 実体は一部のセキュリティ形の機能やnative storage engine-specific driverをMySQL Enterpriseとして出す、という話 Backup機能や、Falcon, Mariaといったストレージエンジンの開発では、Community ServerとE
repcachedについて repcachedとは、memcachedにデータのレプリケーション機能を追加実装したものです。 memcachedは、以下のようなところによく使われると思います。 一時的なデータの保存場所として キャッシュを保存する場所として RDBMSのデータのキャッシュ 生成したページデータのキャッシュ いずれの場合も消えていいデータなので、万が一memcachedがダウンしても問題はないはずです。 しかし、影響が全くないわけではありません。 例えば、MySQLのデータをmemcachedでキャッシュしている場合、memcachedがダウンしている間は直接MySQLにアクセスがいくことになりDBサーバの負荷が上がります。また、memcachedを再起動してキャッシュが失われた場合は、再びキャッシュが溜まるまではDBサーバに負荷がかかることになってしまいます。 このように
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
