Yahooの技術者が書いたブログ techblog.yahoo.co.jp が悪い方向に期待を裏切ってくれたのに対し、 @kuenishi さんがまとまった文章 kuenishi.hatenadiary.jp を書いていたので、僕も2番煎じぐらいでまとまった文章を書く。 始めに断っておくと、分散システムというのはまだまだ事例を集めていくフェーズを抜けきっておらず、体系立った大統一理論的な分類法は確立していない。ここに書くのは、これまでの分散システム事例やこれからの分散システム事例を分類していく際にその性質をカテゴライズする一助となれば良いな、程度の文章なのであまり真に受けないで欲しい。 なぜYahooの記事が期待はずれなのか 人によって意見はあるとは思うが、個人的に感じたのは以下の３つ。 分散システムのデザインパターンと銘打っておきながら並列・並行システムの分野の話からクラウド環境へとこじ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 最近では珍しくもなくなった"Quorum"という言葉。Zookeeper, etcd, Serfといったクラスタ中でデータのレプリケーションを行ってくれるようなツールや、Cassandra, Riakといった分散データベース(NoSQL系)のようなツールにおいても、データの複製に一貫性を持たせる仕組みとしてよく聞かれます。 しかしながら、多くのスライドやWebの記事を読んでも、"Quorum"という語が意味するところは要するに「過半数ノードによる多数決」というような説明が多いように感じていました。 にも関わらず、"Quorum"と呼ばれ
分散システムについては、もう随分と前から学びたいと思っていました。ただ、それは一度首を突っ込んだら最後、ゴールのない迷路に迷い込むようなものなのです。どこまでも続いているウサギの穴のようなものです。分散システムに関する文献は星の数ほど存在します。様々な大学からたくさんの論文が発表されているばかりでなく、膨大な数の書籍もあるのです。私のような全くの初心者には、どの論文を読んだらいいのか、どの書籍を買ったらいいのか、見当もつきません。 そんなとき、一部のブロガーが、 分散システムエンジニア （それがどういう意味であれ）になるなら知っておくべき論文というものを推奨しているのを見つけました。その一部を紹介しましょう。 FLP , Zab , Time, Clocks and the Ordering of Events in a Distributed Systems , Viewstamped
一貫性モデルとして、結果整合性が利用されるデータベースに関して、現状の棚卸しをしているMariaDBプロジェクトの記事である。 各データベースの概要や、評判/成熟度/一貫性/ユースケースに基づいた評価、利点および欠点についてまとめた。 はじめに 結果整合性(eventually consistent) [1] は、多くの大規模分散データベースで使われる一貫性モデルの1つである。このようなデータベースでは、複製されたデータ片に対する全ての変更は 結果的に全ての関連するレプリカに反映される必要がある。 さらに、コンフリクトの解消はこれらのデータベースでは扱われず、更新のコンフリクトが発生した場合、アプリケーションで対処の責任を負う必要がある。 結果整合性は、弱い一貫性の1つの特異形態で、オブジェクトに新規の更新がない場合、ストレージシステムが全てのアクセスが結果的には、最後にアップデートした値
詳細については後述しますが、MapReduceの処理モデルは、上記の通り各区分ごとにそれぞれ単純化（限定）されたモデルであったと言えます。 また、MapReduceの関数プログラミングおよびグラフ的な特徴も合わせて以下に整理してみます。 関数プログラミング的な特徴 MapおよびReduceフェーズは、それぞれ関数型プログラミングのMapおよびReduce処理をモデル化したものです。MapReduceは、参照透過性がある純粋な関数処理と言えます。参照透過性とは入力により出力が一意に決まる性質のことです。言い換えればMapReduceの処理は、大域などの処理に影響する外部の環境は持たず、内部的にも静的な一時変数などの状態も持たないことを意味します。 純粋な関数処理は複数の処理が同時に実行されても他の並列に動作している処理の状態には左右されないため、この参照透過性は並列化に向いている性質がありま
QConTokyo ( http://www.qcontokyo.com/KotaUENISHI_2015.html ) の発表スライド
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog システム統括本部アーキテクト室 今野です。 昨年は、Twitter,Facebookを始めとするクラウド各社で新規の分散システム開発のプロジェクトが相次いで発表された年でした。これらの新しい分散システムを開発する理由や、その背景にあるものは何なのでしょうか？ 今回は、昨年末に開催された高信頼性分散システム系の国際学会であるSRDS 2014[1]の発表内容に関連する論文の話題も踏まえて、昨今のクラウド各社の分散システムの動向について整理してみます。 分散システムにおけるクラウド各社の動向 近年の分散データベースの世界では、AmazonのDynamo[2]やFacebookのCassandra[3]などを代表とする結果整合性（Eve
Principles of Distributed Computing (lecture collection) Distributed computing is essential in modern computing and communications systems. Examples are on the one hand large-scale networks such as the Internet, and on the other hand multiprocessors such as your new multi-core laptop. The lecture notes on this webpage introduce the principles of distributed computing, emphasizing the fundamental i
3. 講義内容 序論 - 並列データベースの前に 並列処理の基礎 並列処理のTerminology 並列計算機アーキテクチャ 並列データベースのアーキテクチャ データベース処理の並列化 結合処理の高速化 並列ハッシュ結合 並列ソート パーティショニング手法 多重結合や計算機間のデータ交換で発生する問題 MapReduceによる関係演算の並列処理 3 4. データベース開発の流れ Coddの論文: 1970年 System RやIngres: 70年代中盤 Oracle, IBM DB2, Ingres: 80年代序盤 並列データベースの隆盛: 80年代後半 A Relational Model of Data for Large Shared Data Banks, Communications of ACM 商用
講師：EMCジャパン 竹内様、宮崎様 日時：2014/06/05 タイトル：Cinder＋Software Defined Storage(SDS)でシンプルなストレージ運用と拡張性・柔軟性が高いクラウドインフラを実現 概要： - Cinder概要及びEMCのOpenStackに対する取り組み（竹内） --- Cinderとは? Cinder動作概要 --- EMCのストレージポートフォリオとSDS戦略 --- EMCのSDS製品ラインナップの紹介 --- OpenStackに対するコミットメント，対応／開発状況の紹介 - OpenStackとViPR（宮崎） --- ViPRのメリット及びOpenStackとの関係について --- OpenStack + ViPR構成及び利用イメージ --- 検証構成及び結果の紹介 --- まとめ
短期間にブラウザのタブがたまってきたのでここいらでひとつまとめておこうと思う。 なにより驚いたのはChaos Monkeyというやつである（via forbes.com）。日本では知名度は低いが、NetflixはインターネットTV（というと分かりやすいかな？）の米国最大手でCassandraやAmazon EC2のビッグユーザーである。最近だと何やらオープンな形でCDN事業に参入しようとしているとか、まあひかりTVなどをやろうとしているNTTからみると協力なライヴァルではいぱーじゃいあんとである。 そのNetflixが、分散システムのテストでCassandraプロセスをわざと強制終了して常に障害耐性をテストしていると言っていたが、ついにそのソースコードが公開された。残念ながらバージャーでGradleという私からは最も遠い世界なのでソースコードは全く目を通せていないが、サービスを運用するため
Join the official community for Google Workspace administrators In the Google Cloud Community, connect with Googlers and other Google Workspace admins like yourself. Participate in product discussions, check out the Community Articles, and learn tips and tricks that will make your work and life easier. Be the first to know what's happening with Google Workspace. ______________ Learn about more Goo
Asakusa supports for the multi-clusterというお話で、多分解説がいるので書いておく。公式に書くものではない、という意見も強いので、ここで書く。先日のSIGMOD日本支部のMtgでも発表した内容ともかぶりますが。 具体的にはここで http://asakusafw.s3.amazonaws.com/documents/0.2/release/ja/html/yaess/multi-dispatch.html いろいろ細かい内容は以下を参照で。 「AsakusaFW0.2.6の見どころ」 http://blog.goo.ne.jp/hishidama/e/2ba82d5ad404000de52d1a4029eb7346 まず、前提として現在のAsakusaは業務処理のバッチ処理、特に非同期処理を対象している。その上で実際に使われているし、SIも行われている。
次世代アーキテクチャについての考えをまとめておく。 まずは、Hbaseの勉強会のお話。 某界隈では割と話題になったので、 細かいブログやサイトは結構、紹介されている。 ので特に詳細は省く。 一応tatsuyaさんのSlideshareは Tokyo HBase Meetup - Realtime Big Data at Facebook with Hadoop and HB… slideを見ているだけでは、よくわからないと思うが Jonathanとの会話では、FBはバックエンドの部分を含めて バッチ処理は別のHadoopクラスターで行っている。 相当バリバリ使っているようだ。 したがって、割と話題になっているHbase上でHadoopMRはどうよ？ っていう話は「分ける」ってのが正解に近く、 フロント処理とバック処理は明快にわけることが基本になるようだ。 その上での印象で、 自分の思ったこ
Facebookは大規模なデータ処理の基盤としてHBaseを利用しています。なぜFacebookはHBaseを用いているのか、どのように利用しているのでしょうか？ 7月1日に都内で行われた勉強会で、Facebookのソフトウェアエンジニアであるジョナサン・グレイ（Jonathan Gray）氏による解説が行われました。 解説はほぼスライドの内容そのままでした。当日使われた日本語訳されたスライドが公開されているので、ポイントとなるページを紹介しましょう。 Realtime Apache Hadoop at Facebook なぜリアルタイムデータの分析に、Hadoop/HBaseを使うのか？ MySQLは安定しているが、分散システムとして設計されておらず、サイズにも上限がある。一方、Hadoopはスケーラブルだがプログラミングが難しく、ランダムな書き込みや読み込みに向いていない。 Faceb
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く