ようこそ!浜村拓夫の世界へ

    ブログ内検索

    最近の記事

    ブックマーク数の多い記事

    Blog Translation

    Powered By FC2ブログ

    Powered By FC2ブログ
    ブログやるならFC2ブログ


    FC2ブログ LOGIN

    with Ajax Amazon

    スポンサーサイト

    このエントリーを含むはてなブックマーク はてなブックマーク - スポンサーサイト あとで読む
    上記の広告は1ヶ月以上更新のないブログに表示されています。
    新しい記事を書く事で広告が消せます。

    ブリュワーのCAP定理~データストレージの選定基準

    このエントリーを含むはてなブックマーク はてなブックマーク - ブリュワーのCAP定理~データストレージの選定基準 あとで読む
    大規模なデータを保存するとき、どんな方法で保存するかが問題になる。
    問題の切り分けとして、「CAP定理」という考え方があった。

    CAP定理
    (via Cassandra実践入門―Twitter,Facebookが採用するNoSQLシステム

    ボツ CAP定理 - たかはしの日記

    分散データベースを考える上でCAP定理というものがある。
    一貫性、可用性、分散性のうちどれか2つは同時に実現できるが3つ同時は不可能であるというものである。

    例として
    ・RDBMSは分散性を抜いた一貫性、可用性である。
    ・これまで見てきたコンシステントハッシュ法を利用したpureP2Pなシステムであるcassadraは可用性+分散性である
    ・hadoopを利用したHBaseというデータベースは単一障害点やネットワーク分断に対して弱いので一貫性+分散性である。



    データストレージとして、基本的にMySQLを使っている。
    RDBは、一貫性と可用性を重視しており、分散性=スケールはあんま考慮されていない。
    まあ、スケールが必要になるようなWebサービスを作れてないから、今のところ問題ないけど(笑)

    MySQLでも頑張れば、ある程度分散できるだろうし、Oracleとか商用RDBならかなりスケールできるだろう。
    自分としては、一貫性は落としたくない項目かな?

    一貫性はなくても構わないWebサービスって、どんなサービスだろ?
    Cassandra → Facebook → 自分の書き込みは正確に表示されなきゃすぐ分かるけど、他人の書き込みは多少タイムラグがあっても気にならないかな?

    7つのデータベース 7つの世界
    Eric Redmond / Jim R. Wilson
    オーム社
    2013-02-26
    ¥ 3,024


    CAP定理 - Wikipedia

    CAP定理はブリュワーの定理とも呼ばれ、分散コンピュータシステムのマシン間の情報複製に関する定理。
    ウェブサービスを想定して作られた定理。

    ノード間のデータ複製において、同時に次の3つの保証を提供することはできない。

    ●一貫性 (Consistency)
    全てのノードにおいて同時に同じデータが見えなければならない。

    ●可用性 (Availability)
    ノード障害により生存ノードの機能性は損なわれない。
    つまり、ダウンしていないノードが常に応答を返す。
    単一障害点が存在しないことが必要。

    ●分断耐性 (Partition-tolerance)
    システムは任意の通信障害などによるメッセージ損失に対し、継続して動作を行う。
    通信可能なサーバーが複数のグループに分断されるケース(ネットワーク分断)を指し、1つのハブに全てのサーバーがつながっている場合は、これは発生しない。
    ただし、そのような単一障害点のあるネットワーク設計は可用性が成立しない。

    この定理によると、分散システムはこの3つの保証のうち、同時に2つの保証を満たすことはできるが、同時に全てを満たすことはできない。



    CAP定理を見直す。“CAPの3つから2つを選ぶ”という説明はミスリーディングだった - Publickey

    クラウド上のリレーショナルデータベースはなぜ難しいのか? BASEとCAP定理について - Publickey

    12年後のCAP定理: "法則"はどのように変わったか - InfoQ

    BrewersCapTheorem - ブリュワーの CAP 定理


    ●BASE

    WebSphereソフトウェアで構築するプライベート・クラウド - IBM

    パフォーマンスやアクセス平準化が得られるとしても、分散キャッシュではいかにしてデータの整合性を保つのでしょうか。
    分散キャッシュ上でACIDトランザクションを実現するのでしょうか。
    このような問いにヒントを与えてくれるのが、CAP定理(図3)とBASE(図4)に基づいたEventual Consistency(結果整合性)の考え方です。



    BASE

    結果整合性 - Wikipedia

    結果整合性(英: eventual consistency)は、並列プログラミングの分野、例えば、分散共有メモリ、分散トランザクション、楽観的レプリケーション、において用いられるデータの一貫性に関するモデルのひとつ。

    これは厳密な一貫性を要求する考え方ではなく、結果的に一貫性が保たれればよいという考え方。
    長い間、データの更新がなければ、結果的に、全ての更新処理が反映され、全てのレプリケーションを含めたデータの一貫性が保たれる、とする。



    結果整合性(Eventual Consistency)についての分かりやすいプレゼン資料 - Publickey

    コンバージェンスとは - IT用語辞典 e-Words

    ルーティングコンバージェンス / routing convergence
    収束、収斂、集中という意味の英単語。
    ネットワークの分野で、ルータ間で経路情報が十分に行き渡り、すべてのルータが最新の経路をすべて認識している状態のことをルーティングコンバージェンス、あるいは単にコンバージェンスという。
    ネットワークやルータ、経路が増えてから、すべてのルータがそのことを認識するまでに要する時間をコンバージェンス時間(convergence time)という。



    ・データの一貫性は、ノード間の差異が収束するまでの時間が十分に短ければOK
    ・一貫性が絶対に必要なときだけ、トランザクションでロックしとけばOK
    関連記事

    コメント

    コメントの投稿


    管理者にだけ表示を許可する

    トラックバック

    トラックバックURL:
    http://hamamuratakuo.blog61.fc2.com/tb.php/1089-f2acc5ba

    FC2Ad

    上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。