Cloudの技術的特徴について
Cloud --- Scalability Availability --- Agenda Scalability Availability CAP Theorem Scalability Availability Consistency BASE Transaction Scale-out Scale-out Availability Scalabilty Availability Scalability Availability Availability Replica Replica Eventually Consistency Transaction ACID BASE Scale-up Scale-out $10,0 00 machi ne $10,0 00 machi ne $1000 machi ne $1000 machi ne Scale-up Scale-out $50
クラウドでの新しいACID、そしてBASEトランザクションとCAP定理 - Fight the Future
クラウドではアーキテクチャやプログラミングモデルが今までと変わる。 QConでは複数の人からそういう話が出ていた。 ちょっと自分なりにまとめてみる。間違っているかもしれないので、見つけた人はご指摘ください。 新しいACID 従来のモデルでのACIDは、特にRDBMS関連でよく耳にすると思う。 Atomic(原子性) Consistent(一貫性) Isolated(独立性) Durable(永続性) だ。 QConでGoogleのGregor Hohpe氏は、クラウドにおいてACIDは次のような意味になると言っていた。 資料はここ。https://sites.google.com/site/gcodejp/slides/ProgrammingCloud_QCon.pdf?attredirects=0 Associative(結合の) Commutative(相互の) Idempotent(
How to beat the CAP theorem - thoughts from the red planet - thoughts from the red planet
September 2021 (1) March 2017 (1) January 2017 (1) July 2016 (1) June 2016 (1) September 2015 (1) October 2014 (1) June 2014 (1) May 2014 (1) February 2014 (2) April 2013 (3) March 2013 (1) September 2012 (1) February 2012 (1) January 2012 (1) October 2011 (1) March 2011 (1) January 2011 (3) December 2010 (2) November 2010 (1) October 2010 (2) August 2010 (2) July 2010 (2) June 2010 (1) May 2010 (
NoSQL: おちエンのブログ
Hadoop の一番の問題は、NameNode が SPoF になっているところだと思います。 ただ、構成でなんとか障害に強いシステムにすることはできると思います。例えば、以下のような感じ。 NameNode として、ロードバランサを指定しておき、NameNode は hot stanby の NameNode の disk を NFS マウントさせておき、namespace と transaction log を local の disk と NFS でマウントしている disk に書き込んでおきます。 障害を自動検出し、問題がある場合は、hot stanby に自動的に切り替えます。 namespace と transaction log は stanby の disk にも書き込まれており、NameNode としてロードバランサを指定しているので、問題なくサービス提供ができるはずです
開発メモ
弁護士の先生と協議しつつ、Kyoto Cabinetの商用ライセンスを策定した。英語版の策定はこれからだが、日本語版としては完成したので、ぼちぼち営業活動を始める。価格に関しては契約者毎に決定することになるし、大口の契約者とはライセンス内容自体の調整もすることになるだろう。ただ、その前に、一般論としてのご意見を広く伺いたいと思っているので、ここに最終案を公開してみる。しばらくしたらKCのページにPDFかなんかにして載せることにする。 なお、当初の予定ではGPLv3とそれに対する例外規程として商用ライセンスを構成するつもりだったが、最終的にはGPLv3とは完全に独立したライセンスを策定することとなった。本文にも明記されているが、このライセンスを購入した法人や個人は、GPLv3が規定する権利や義務ではなく、この商用ライセンスで規程する権利や義務を持つことになる。逆も然りで、GPLv3は依然とし
もう1つの、DBのかたち、分散Key-Valueストアとは
分散KVSが苦手なトランザクションの「ACID特性」 RDBのように、テーブルとテーブルを結合（SQLでいうJOIN文）して複雑な条件検索や集計処理を一発でこなすような芸当はできません。また、トランザクションによる「ACID特性」の確保も分散KVSが苦手な分野です。 RDBが不得意な分散／拡張 そのため、これらの不足をアプリケーション側で補うためのさまざまな工夫やフォローが必要となります。その一方で、分散KVSはデータストア全体をいくらでも多くのサーバに分散（スケールアウト）できるのが最大の特徴です。 一方でこれは、RDBが最も不得意とするところです。RDBでは、その長所であるテーブル結合やACIDの確保がボトルネックとなり、複数のサーバにスケールアウトさせることが「原理的」に容易ではありません。そのため、負荷分散や高可用性を低コストで実現することが困難です。 RDBで負荷分散させようとす
Visual Guide to NoSQL Systems - Nathan Hurst's Blog
There are so many NoSQL systems these days that it's hard to get a quick overview of the major trade-offs involved when evaluating relational and non-relational systems in non-single-server environments. I've developed this visual primer with quite a lot of help (see credits at the end), and it's still a work in progress, so let me know if you see anything misplaced or missing, and I'll fix it. Wi
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
