ビザンチン将軍問題 - Wikipedia
ビザンチン将軍問題（ビザンチンしょうぐんもんだい、英語: Byzantine Generals Problem）とは、相互に通信しあう何らかのオブジェクト群において、通信および個々のオブジェクトが故障または故意によって偽の情報を伝達する可能性がある場合に、全体として正しい合意を形成できるかを問う問題である[1]。フォールトトレラントシステムでの多数決の妥当性や分散コンピューティングの処理の妥当性に関わる問題と言え、二人の将軍問題を一般化したものと言える。 ビザンチン将軍問題に帰結される故障や障害をビザンチン故障（Byzantine Failure、あるいはビザンチン障害）と呼ぶ。また、ビザンチン将軍問題が発生しても全体として正しく動作するシステムをビザンチン・フォールトトレラント性（Byzantine Fault Tolerance）があるという。 ビザンチン将軍問題は、東ローマ帝国（ビザ
Amazon Auroraの先進性を誰も解説してくれないから解説する - Qiita
TL;DR; Amazon AuroraはIn-Memory DBでもなくDisk-Oriented DBでもなく、In-KVS DBとでも呼ぶべき新地平に立っている。 その斬新さたるやマスターのメインメモリはキャッシュでありながらWrite-BackでもなくWrite-Throughでもないという驚天動地。 ついでに従来のチェックポイント処理も不要になったのでスループットも向上した。 詳細が気になる人はこの記事をチェキ！ Amazon Aurora Amazon AuroraはAWSの中で利用可能なマネージド(＝運用をAWSが面倒見てくれる)なデータベースサービス。 ユーザーからはただのMySQL、もしくはPostgreSQLとして扱う事ができるのでそれらに依存する既存のアプリケーション資産をそのまま利用する事ができて、落ちたら再起動したりセキュリティパッチをダウンタイムなしで(!?)適
今度こそ絶対あなたに理解させるPaxos - Qiita
Paxosとは何か 分散システムの金字塔とも呼ばれ、Leslie Lamport大先生の輝かしい成果の一つとして知られる分散合意アルゴリズムPaxos。 既存の解説 実はすでに存在するPaxosの解説は充分に質が高い Wikipediaの項目にも結構長々と書かれていて、これを読んで理解できた人はもう僕の記事を読む必要はない。 同様にPFIの久保田さんによる解説スライドもあり、これも良く書けているし、これを読んで理解できた人もこれ以上記事を読む必要はない。 minghai氏によるブログ記事のこれとか特にこっちなんかはかなり納得感があり、これらを読んで理解できた人も（中略） tyonekura氏によるスライドも良くかけていて(中略) この記事はこれらの説明に目を通してもなお理解できなかった人、もしくはこれらの説明をこれから読もうと思っている人に向けて書き、Paxosアルゴリズムの詳細な説明自体
Akka vs Erlang【スケジューラ編】
まっちゃら @ FOLIO @matsu_chara なるほど？akka内部でブロックしたい場合はアクター単位でブロックするのは無理だけど、dispatcherを工夫すればブロックしてもExecutionContext的な物がことなるからThread.sleepをよんでも大丈夫そうという知見を得た 2016-02-27 16:57:40 まっちゃら @ FOLIO @matsu_chara 普通のdispatcherでやると同じdispatcherを共有してる奴も（当たり前だけど）止まってしまうけどPinnedDispatcherを使えば1actor1threadになるから影響を受けなくはなる。 gist.github.com/matsu-chara/33… 2016-02-27 17:00:57
分散システムの一貫性に関する動向について
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog システム統括本部アーキテクト室 今野です。 昨年は、Twitter,Facebookを始めとするクラウド各社で新規の分散システム開発のプロジェクトが相次いで発表された年でした。これらの新しい分散システムを開発する理由や、その背景にあるものは何なのでしょうか？ 今回は、昨年末に開催された高信頼性分散システム系の国際学会であるSRDS 2014[1]の発表内容に関連する論文の話題も踏まえて、昨今のクラウド各社の分散システムの動向について整理してみます。 分散システムにおけるクラウド各社の動向 近年の分散データベースの世界では、AmazonのDynamo[2]やFacebookのCassandra[3]などを代表とする結果整合性（Eve
出版-購読型モデル - Wikipedia
出版-購読型モデル（しゅっぱん-こうどくがたモデル、英: Publish/subscribe）は、非同期メッセージングパラダイムの一種である。メッセージの送信者（出版側）が、特定の受信者（購読側）に直接メッセージを発行するプログラムではなく、発行（出版）されたメッセージはクラス分けされ、どんな受信者が居るのかは知らない。受信者は興味のあるクラスを指定しておき、そのクラスに届くメッセージだけを受け取り、どんな送信者が居るのかは知らない。送信者と受信者の結合度が低いため、スケーラビリティがよく、動的なネットワーク構成に対応可能である。 出版-購読型モデルはメッセージキューパラダイムと対比され、一般に大きなメッセージ指向ミドルウェアの一部として使われる。一部のメッセージシステム（Java Message Serviceなど）は、出版-購読型とメッセージキューの両モデルをサポートしている。 出版-
対宇宙人用フレームワーク
対宇宙人用フレームワーク Presentation Transcript 対宇宙人フレームワーク 宇宙人っているのか？ 僕は見たことがない でもたぶんいるっぽい ちきゅうがいせいめいたいたんさ地球外生命体探査Search for Extra-Terrestrial Intelligence 地球人類の文明は、● 宇宙の中でも非常に例外的な存在なのか● それとも必然的に発生した物なのか 哲学的命題へに回答するための人類の試み Search for Extra-Terrestrial Intelligence -> SETI・Active SETI・Passive SETI Active SETI Active SETI異星人が受信することを期待して、 地球からメッセージを送る試み アレシボ・メッセージ 1679個の2進数(23と73という二つの素数の積) ● 1から10までの数字 ● 水素・
管理が困難―分散処理の常識はZooKeeperで変わる
管理が困難―分散処理の常識はZooKeeperで変わる：ビッグデータ処理の常識をJavaで身につける（8）（1/3 ページ） Hadoopをはじめ、Java言語を使って構築されることが多い「ビッグデータ」処理のためのフレームワーク／ライブラリを紹介しながら、大量データを活用するための技術の常識を身に付けていく連載 分散処理の課題が「管理」なのは常識 複数の計算機上で動作（分散）するアプリケーション、ソフトウェアが多く存在します。分散ソフトウェアは複数の計算機で動作することで大量のデータを扱えたり、高負荷な状況に対処します。本稿では、複数の計算機（クラスタ）で動作する各サーバを「インスタンス」と呼びます。 本連載で紹介した分散Key-Valueデータベースである「HBase」は複数の計算機で動作する代表的なソフトウェアです。両ソフトウェアはともに「Apache ZooKeeper」（以下、Z
Jubatus : Distributed Online Machine Learning Framework¶
Jubatus English Japanese
FacebookがHBaseを大規模リアルタイム処理に利用している理由（前編）
Facebookは大規模なデータ処理の基盤としてHBaseを利用しています。なぜFacebookはHBaseを用いているのか、どのように利用しているのでしょうか？ 7月1日に都内で行われた勉強会で、Facebookのソフトウェアエンジニアであるジョナサン・グレイ（Jonathan Gray）氏による解説が行われました。 解説はほぼスライドの内容そのままでした。当日使われた日本語訳されたスライドが公開されているので、ポイントとなるページを紹介しましょう。 Realtime Apache Hadoop at Facebook なぜリアルタイムデータの分析に、Hadoop/HBaseを使うのか？ MySQLは安定しているが、分散システムとして設計されておらず、サイズにも上限がある。一方、Hadoopはスケーラブルだがプログラミングが難しく、ランダムな書き込みや読み込みに向いていない。 Faceb
NTTデータのHadoop報告書がすごかった - 科学と非科学の迷宮
業界トップ のエンタープライズ Hadoop 企業 Cloudera に入社しました http://www.cloudera.co.jp/ 今年の6月に、「平成２１年度 産学連携ソフトウェア工学実践事業報告書」というドキュメント群が経産省から公表されました。 そのうちの一つに、NTTデータに委託されたHadoopに関する実証実験の報告書がありましたので、今更ながら読んでみることにしました。 Hadoop界隈の人はもうみんなとっくに読んでるのかもしれませんけど。 http://www.meti.go.jp/policy/mono_info_service/joho/downloadfiles/2010software_research/clou_dist_software.pdf 「高信頼クラウド実現用ソフトウェア開発（分散制御処理技術等に係るデータセンター高信頼化に向けた実証事業）」という
MySQLデータベース分散処理 - 憂鬱なプログラマの形而上学
MySQL今まで、携帯の大規模サイトをいくつか運用してきて、過去には会員数300万人を超える携帯SNSをほぼ一人で作ったりしてきたわけだが、今回はその過程で得たMySQLの分散処理についてまとめたい。パラメータ系の設定はまた今度にして、とりあえず今回は設計のお話。まず、基本的にはどんなプログラムでも負荷に関して何らかの対策は必要で、常に意識すべきことではあるのですが、特にWEBアプリの場合、データベースの負荷対策が中心的な課題となります。その中でも、confファイルの編集やINDEX、個々のテーブル設計などで個々のデータベースのパフォーマンスチューニングを、テーブル全体の設計やレプリケーションなどの設計で冗長化による負荷の分散を行うわけですが、今回は後者に重点を置いてお話をしたいと思います。私の場合、行っている分散処理は実は非常に単純でして、主に下記の内容となります。レプリケーションスキー
Solr/SolrJ1.3のCoreAdmin(マルチコア)機能を用いて動的にCoreを追加する方法(SolrJのバグの対処方法) | イージーネット Tech Blog
こんにちは。 株式会社イージーネット プロダクト&サービス事業部 リーダーの久保です。 前回書いたSolrの記事 全文検索サーバ: これからSolrを始める人のためのApache Solr概要と便利なリンク集 は沢山のアクセス/ブックマークをいただきました。 来週月曜日の7/21には、Lucene/Solrで有名なロンウイットの関口さん(参考: 関口宏司のLuceneブログ)などが参加されるSolr勉強会も開催されるようですので、Solr人気は高まっているのかもしれません。 今回は前回から変わって小さなネタになりますが、 Solr/SolrJ1.3のCoreAdmin(マルチコア)機能を用いて動的にCoreを追加する際にはまるSolrJのバグと、その対処方法について書きます。 Solr1.3のマルチコア機能とは 単純に言うと、1つのSolrアプリケーション(サーブレットアプリケーショ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - contribsys/faktory: Language-agnostic persistent background job server
分散システムについて語らせてくれ
No.4 BigDataの次のSTEP リアルタイム分散処理のイマドキ - Advanced Tech Night
としの今日でき