Riak: 本物の高可用性を実現する仕組みとは？[B31] LOGMinerってレプリケーションソフトで使われているけどどうなってる？ by Toshiya MoritaInsight Technology, Inc.
Netflix: 結果整合性の許容範囲は広がってしかるべき - ワザノバ | wazanova
https://www.youtube.com/watch?v=6R1WhWkh6pg 2 comments | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 Cassandra Day Silicon Valley 2014でのChristos Kalantzis (Cloud DB Engineering Manager, Netflix) の講演。 10年前を思い出してほしい、データの書込みは1台のマスターに、読込みは複数のスレーブで担いスケールさせていた。ウェブサービスでよく使われていた手法だが、レプリが完全に行われないケースはありえた。 Cassandraの場合は、大量のデータ処理でも結果整合性の遅延は極短く、信頼性高く、かつデータ修復機能もある。チューニングできるシステム。 Netflixでの実験: - 二箇
Riak 2.0のCRDTで遊ぶ - kuenishi's blog
今日もRiakアドベントカレンダーの記事だよ！ GLEE見てると"Call Me Maybe"という曲があって、それがなんとなくお気に入りな昨日今日です。今日はWebDB Forum 2013で話してきたCRDTの話。 CRDTって何よ？という人多いと思うので当日僕が話したスライドを見てほしい。 まとめると、絶対にデータをなくしたくないし可用性を下げたくないための可換データ型をRiakにネイティブで実装したよという話です*1。で、ちょっと使ってみようと。 Riak 2.0を落としてきて動かす $ git clone git://github.com/basho/riak $ cd riak $ git checkout riak-2.0.0pre7 -b crdttest $ make rel $ ulimit -n 4096 $ rel/riak/bin/riak start これで多分
筑波大学でデータベースの話をしてきました - kuenishi's blog
筑波大学の川島先生に呼ばれて木、金と情報システム特別講義Dというやつに参加してきた。こんなことになるとは思っていなかったが、あろうことか講師側で呼ばれてしまい、思えば遠くへ来たものだと感慨深い。フリは「RiakとNoSQLの話をしてもらえたら」という非常に自由度の高い内容なので、せっかくなので僕の知っていることを全部詰め込んで話してやろうと思ったら10分延長してさらにスライド10枚分くらいを消化不良で終了という、みっともない感じになってしまった。かなり端折ってポイントだけ説明したので流れが分からず苦労した方も多いと思うが、まあ僕の性格なので許してほしい。データベースの講義をひと通り終えた院生レベルを想定してスライドを作ったので、もしかすると、わりと難しかったり分かりにくかったりするかもしれないので、わからないことがあったら適当に質問してください。 言いたかったことの流れを僕なりにまとめると
ITエンジニアのCAPの定理 - from scratch
CAPの定理というのがある、 「ノード間のデータ複製において、同時に一貫性、可用性、分断耐性の3つの特性を同時に保証することはできない。」というもの。 説明をwikipediaにゆずると、 ・一貫性 (Consistency)： 全てのノードにおいて同時に同じデータが見えなければならない。 ・可用性 (Availability)： ノード障害により生存ノードの機能性は損なわれない。つまり、ダウンしていないノードが常に応答を返す。単一障害点が存在しないことが必要。 ・分断耐性 (Partition-tolerance)： システムは任意の通信障害などによるメッセージ損失に対し、継続して動作を行う。通信可能なサーバーが複数のグループに分断されるケース（ネットワーク分断）を指し、1つのハブに全てのサーバーがつながっている場合は、これは発生しない。ただし、そのような単一障害点のあるネットワーク設計
クラウド事業者がテクノロジーリーダーになる理由～クラウドコンピューティングの雲の中（その1）。NII Open House 2013
クラウドコンピューティング（以下クラウド）とは、コンピュータやストレージを必要なときに必要なだけ使えるシステムです。 クラウドというと未来の技術というイメージが強かったのですが、いまではオンラインゲームや企業の基幹業務などにまで広く使われる時代になっています。 その割にはクラウドの中身はあまり知られていません。例えば皆さんがPCを使うときには、プロセッサやメモリなどの基礎知識があって、それがPCを使うときに間接的に役立つことが多いでしょう。 クラウドがこれから一般的になれば、その基礎知識があることがすごく重要になると思います。今日はそのあたりを中心にお話ししたいと思います。 クラウド事業者がテクノロジーリーダーとなっている これはGoogleのクラウドの中、データセンター内部の写真です。こうした大きなデータセンターを作り、10万台オーダーのサーバとネットワークと冷却装置などをそこに入れる、
HAT, not CAP: Introducing Highly Available Transactions | Peter Bailis
Peter Bailis :: Highly Available, Seldom Consistent Data management, distributed systems, and beyond HAT, not CAP: Introducing Highly Available Transactions 05 Feb 2013 tl;dr: Highly Available Transactions show it’s possible to achieve many of the transactional guarantees of today’s databases without sacrificing high availability and low latency. CAP and ACID Distributed systems designers face har
CAP定理を見直す。“CAPの3つから2つを選ぶ”という説明はミスリーディングだった
分散システムにおいては以下の3つの要素のうち2つしか同時に満たすことができない、というCAP定理を提唱したのは、Eric Brewer氏でした。 C：Consistency（一貫性） A：Availability（可用性） P：Tolerance to network Paritions（ネットワーク分断への耐性） 一般にリレーショナルデータベースでは、一貫性（C）と可用性（A）をできるだけ保証する代わりに、ネットワーク分断への耐性（P）を犠牲にしています。ネットワークが途中で切れたり大きく遅延した場合、動作が保証されなくなってしまうわけです。 一方でNoSQLでは一貫性（C）よりも可用性（A）とネットワーク分断への耐性（P）を優先させるものが多く、分散システムでの動作に向いていると説明されます。このようにNoSQLの説明にこのCAP定理がしばしば引用されることになり、NoSQLの普及とと
クラウドを支える基盤技術の最新動向と今後の方向性
知っているようで知らないNeutron -仮想ルータの冗長と分散- - OpenStack最新情報セミナー 2016年3月 VirtualTech Japan Inc.
NoSQL、CAP定理、BASE、Eventual Consistencyについて深く考えてみた
最近はNoSQLなどといって分散データベースがやたらに流行です。私もDynamoDBを使ってみようと思って色々調べているところですが、学べば学ぶほど奥が深くて恐ろしくなってきます。 まず第一に言っておきますが、現在のところ、いわゆるKey-value store型のNoSQLのメリットは「書き込みのスケーラビリティ」であって、それ以外には大きなメリットはありません。 DynamoDBの場合は「管理不要」「高信頼性」というおまけが付きますので、また話は少し別ですけどね。 他のオープンソース製品を自分のサーバーにインストールするのであれば、RDBMSほどこなれていないNoSQLを運用するのは大変な苦痛と危険が伴うでしょうね。前の記事にも書いたように分散システムを運用するというのは困難かつ苦痛を伴う仕事ですから。 ですから、すさまじい数のアクセスがあるようなシステムでなければ、NoSQLを選択す
12年後のCAP定理: "法則"はどのように変わったか
設計者は分割が発生したとき一貫性と可用性のどちらかを選ぶ必要がありますが、分割の扱い方と分割の復旧には柔軟な対処方法があります。現在のCAPの目的は特定のアプリケーションが必要とする一貫性と可用性を最適化することでしょう。このような方法には分割発生中の計画や分割の復旧計画が組み込まれています。したがって、設計者はこのような方法を採用することで、従来受け取られてきたCAPの限界を超えてCAPについて考えることができます。 なぜ"3つのうち2つ"がミスリーディングなのか CAPを理解する最も簡単な方法は分割の両側にひとつずつノードがある場合を考えることです。片方のノードだけ状態を更新できるようにすると、2つのノードに一貫性がなくなります。つまり、Cが失われます。一貫性を維持しようとすれば、一方のノードは利用できない状態であるかのように動作しなければなりません。この場合、Aが失われます。一貫性と
Errors in Database Systems, Eventual Consistency, and the CAP Theorem | blog@CACM | Communications of the ACM
CACM Web Account Membership in ACM includes a subscription to Communications of the ACM (CACM), the computing industry's most trusted source for staying connected to the world of advanced computing. Sign In Sign Up Recently, there has been considerable renewed interest in the CAP theorem [1] for database management system (DBMS) applications that span multiple processing sites. In brief, this theo
PACELCで理解するCAPの定理(1)
CAPの定理が何故最近話題になっているかについての説明などは他サイトに任せることにして、このエントリではCAP定理の技術的な解説、および、CAP定理をより分かりやすく、かつ（簡単に言えば）より正確にした「PACELC定理」の解説を行います。 PACELCの定理とは、エール大学のAbadi氏が提唱しているもので、CAPの定理のいわば発展形です。CAPの定理の「難しい版」と思われていることがあるようですが、そんな事はありません。むしろ、多くの学生がCAPの定理で苦労するのを見たAbadi氏が、学生に分かりやすく説明するために考えたものなので、CAPの定理をより分かりやすくしたものと言えます。ただ、それだけでなく、CAPの定理には入っていなかったLatency(≒レスポンス時間)の概念も合わせて捉えることで、より正確に分散データベースの特性を考えられるようになっています。 ではまず、第一回目はC
NoSQL Required Reading
I've been trying to follow the fast-moving world of NoSQL lately, and -- like a visit to the carnival funhouse -- it has left me with double vision, queasy stomach, and a staggering gait. (And it's not even Saturday morning...) Yet I find myself coming back for more. If you're new to NoSQL, you'll want to do a bit of background reading. I'll keep this quick and limit my recommendations to just the
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
A New Concept of Consistency in Distributed Database and Implementation in Riak
大規模分散システム ”Amazon Web Services” の使い方
クラウドコンピューティングの雲の中 - クラウドコンピューティングの新潮流 / 佐藤一郎
The CAP FAQ by henryr
FoundationDBの共同創立者Nick Lavezzo氏へのインタビュー