タグ

2013年6月4日のブックマーク (6件)

  • ZooKeeper の Java での使用例

    ZooKeeper Java API を利用するための手引きとして、ここでは非常に簡単なウォッチクライアントを作成します。作成する ZooKeeper クライアントは、ZooKeeper ノードに変更があったかどうかをウォッチし、プログラムを起動または停止して応答します。 要件 クライアントの要件は次の 4 項目です。 以下の引数を取ります。 ZooKeeper サービスのアドレス ウォッチする znode の名前 プログラムとその引数 znode に関連付けられたデータを取得し、プログラムを起動します。 znode が変更されたら、クライアントはその内容を取得し、プログラムを再起動します。 znode が消滅したら、クライアントはプログラムを kill します。 プログラムの設計 慣習として、ZooKeeper アプリケーションは 2 のユニットに分けます。一方は接続を維持します。もう一

    mano-junki
    mano-junki 2013/06/04
    java zookeeper
  • フラットデザインについて130603_CRsalon

    mano-junki
    mano-junki 2013/06/04
    desighn flat css html front ui
  • シェアード・ナッシング・アーキテクチャ - Wikipedia

    シェアード・ナッシング・アーキテクチャ(英語: shared nothing architecture、SN)とは、分散コンピューティングにおいて、各ノード(コンピュータ)がネットワークを除いてリソースを共有しておらず、それぞれが独立しており、自律的であり、システムにおいて単一競合箇所が無い物を指す。 シェアード・ナッシング・モデルは通常は、大規模な状態(state)データを中央に集中的に格納するシステムと対比されるが、これはデータベースやアプリケーションサーバなど、その他の単一競合箇所のいずれについても適用される。 例えばDBMSの場合は、Oracle Databaseはシェアード・ディスク・モデル(DISK共有モデル)であり、DB2の分散系におけるPE、EEE、DPFなどはシェアード・ナッシング・モデルである。 シェアード・ナッシング・モデルは現在では、Webのシステムにおいて頻繁に議

    mano-junki
    mano-junki 2013/06/04
    oracle architecture nosql database
  • 12年後のCAP定理: "法則"はどのように変わったか

    設計者は分割が発生したとき一貫性と可用性のどちらかを選ぶ必要がありますが、分割の扱い方と分割の復旧には柔軟な対処方法があります。現在のCAPの目的は特定のアプリケーションが必要とする一貫性と可用性を最適化することでしょう。このような方法には分割発生中の計画や分割の復旧計画が組み込まれています。したがって、設計者はこのような方法を採用することで、従来受け取られてきたCAPの限界を超えてCAPについて考えることができます。 なぜ"3つのうち2つ"がミスリーディングなのか CAPを理解する最も簡単な方法は分割の両側にひとつずつノードがある場合を考えることです。片方のノードだけ状態を更新できるようにすると、2つのノードに一貫性がなくなります。つまり、Cが失われます。一貫性を維持しようとすれば、一方のノードは利用できない状態であるかのように動作しなければなりません。この場合、Aが失われます。一貫性と

    12年後のCAP定理: "法則"はどのように変わったか
    mano-junki
    mano-junki 2013/06/04
    cap定理 nosql database CAP定理 acid
  • 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つを選ぶ”という説明はミスリーディングだった
    mano-junki
    mano-junki 2013/06/04
    CAP定理 nosql db architecture
  • InfoQ: グラフデータベース、NOSQL、Neo4j

    VoldemortやTokyo Cabinetといったキー/バリューシステムにおけるモデリングの最小単位はキー/バリューペアになる。そして、BigTableやそのクローンでは可変数の属性をもつタプルに、CouchDBやMongoDBといったドキュメントデータベースではドキュメントになる。これに対しグラフデータベースでは、データセット全体をひとつの巨大な高密度ネットワーク構造としてモデル化する。 ここではNOSQLデータベースにおける2つの興味深いポイント、スケーラビリティと複雑さについて詳しく説明する。 1. スケーラビリティ CAP: ACID 対 BASE 従来のデータベースシステムのほとんどは、トランザクションに基づいてデータの完全性を保証する。トランザクションを使うことで、データ管理のあらゆる状況において、データの一貫性を確保している。こうしたトランザクションの性質は、ACID(A

    InfoQ: グラフデータベース、NOSQL、Neo4j
    mano-junki
    mano-junki 2013/06/04
    nosql traph kvs neo4j infoq database