タグ

分散DBに関するBigFatCatのブックマーク (6)

  • 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の普及とと

    CAP定理を見直す。“CAPの3つから2つを選ぶ”という説明はミスリーディングだった
    BigFatCat
    BigFatCat 2017/12/07
    "一部の研究者が正しく指摘しているように、Pを失うということが正確に何を意味するのか明確ではありません(*11,*12)。設計者は分割が起こらないことを選択できるのでしょうか。CAを選び、分割が発生した場合、CかAの
  • 今更CAP定理で分散データストアの勉強を始めてみた - As a Futurist...

    長くなったので三行でまとめると CAP 定理を素人なりに調べてみた 分散データストアを CAP 定理で俯瞰してみた どのデータストア使うかの決定因子は CAP 定理的な視点の方がインタフェースとかより先 異論は認めるというか、専門知識ゼロなのでもっと正しい理解があればぜひ教えてくださいませ。 はじめに 僕は MySQL 厨なんですが、最近はやれ「MongoDB がいい」だの「HBase 最高」だのとよく聞きます。これら多種多様なデータストアを語る上で、「RDBMS VS NoSQL」みたいに問い合わせ言語の方式やデータ保存形式の違いで語るのは宗教論かなぁと僕は思ってます。単体プロセスのデータストアとしての特徴とか性能とかは正直なんでもいいかなぁと。 思うに、質的に重要なのは MySQL の master-slave&sharding という Web で今までスタンダードに使われてきた分散

    今更CAP定理で分散データストアの勉強を始めてみた - As a Futurist...
  • Cloudera Blog

    Enterprises see embracing AI as a strategic imperative that will enable them to stay relevant in increasingly competitive markets. However, it remains difficult to quickly build these capabilities given the challenges with finding readily available talent and resources to get started rapidly on the AI journey. Cloudera recently signed a strategic collaboration agreement with Amazon […] Read blog p

    Cloudera Blog
    BigFatCat
    BigFatCat 2017/12/07
    "This is often misunderstood: partition tolerance is not something we have a choice about designing into our systems. If you have a partition in your network, you lose either consistency (because you allow updates to both sides of the partition) or you lose availability (because you detect the error
  • A New Concept of Consistency in Distributed Database and Implementation in Riak

    Web+DB forum 技術報告 by Basho

    A New Concept of Consistency in Distributed Database and Implementation in Riak
  • 第4回 memcachedの分散アルゴリズム | gihyo.jp

    株式会社ミクシィの長野です。第2回、第3回と前坂がmemcachedの内部について紹介しました。今回は内部構造から離れて、memcachedの分散についての紹介をいたします。 memcachedの分散 連載の1回目に紹介しましたが、memcachedは「分散」キャッシュサーバと言われていますが、サーバ側には「分散」の機能は備わっていません。サーバ側には当連載の第2回、第3回で前坂が紹介したメモリストレージの機能のみが組み込まれており、非常にシンプルな実装となっています。では、memcachedの分散はどのように実現しているのかと言うと、すべてクライアントライブラリによって実現されます。この分散方法はmemcachedの大きな特徴です。 memcachedの分散とは ここまで数度「分散」という言葉を用いてきましたが、あまり詳しく触れてきませんでした。ここでは各クライアントの実装に共通する大ま

    第4回 memcachedの分散アルゴリズム | gihyo.jp
  • これがWikipediaの裏側、知られざる大規模システムの実態「Wikipedia / MediaWiki におけるシステム運用」

    Wikipediaといえば世界で第5位の訪問者数を誇る巨大サイトですが、システム運営に携わる人間は世界でわずか6人、しかもこれはボランティア込みという恐るべき少人数で、第4位のFacebookのサーバ数が3万台を超えているのに対して、Wikipediaはわずか350台で運用している……などというような感じで、知られざる今のWikipediaの実態が「KOF2010」にて日行われた講演「Wikipedia / MediaWiki におけるシステム運用」で明かされました。 登壇したのはWikipediaを運営するWikimedia財団のエンジニアであるRyan Lane氏で、100席ある座席は満席になり、隣の中継の部屋まで人があふれているほどの盛況っぷりで、語られる内容もなかなか参考になることが多く、今後のGIGAZINEサーバにも活かせそうな内容でした。 というわけで、「Wikipedia

    これがWikipediaの裏側、知られざる大規模システムの実態「Wikipedia / MediaWiki におけるシステム運用」
    BigFatCat
    BigFatCat 2010/11/07
    「SquidをVarnishで置き換える予定」
  • 1