アーキテクチャーオーバービューは、Cassandra(カサンドラ)ユーザー向けのCassandraアーキテクチャーの概略です。

開発者の方は、Wikiのフロントページから開発者向けのリンクをご覧ください。

このページの情報は、オライリー主催のOSCON 2009Cassandra: Open Source Bigtable + Dynamo、Jonathan Ellis (Rackspace Hosting) (PDF)のプレゼンテーション資料に基づいています。

なぜCassandraなのでしょうか?

新たなデータの出現

CAP定理(経験則)

Eric Brewer(エリック・ブルーワー)のCAP定理 (PDF)に支配された状況では、Consistency(一貫性、コンシステンシー)Availability(可用性、アベイラビリティー)Partition-tolerance(分断耐性、パーティショントレランス)のうち2つを選択する必要があります。同時に3つの性質を満たすことはできないため、それらを得るにはレイテンシー(遅延)を許容する必要があります。

Cassandraは、可用性と分断耐性(AP)を重視しています。一貫性と遅延はトレードオフの関係にあり、Cassandraでは整合性レベルが調整可能(tunable)です。遅延を許容すればCassandraでは強い一貫性(Strong Consistency)を得ることができます。しかし、行ロックを取得することはできません。その点は、HBaseの方が優れています。

メモ: HBaseは、一貫性と分断耐性(CP)を重視しています

歴史とアプローチ

2つの有名な論文

2つのアプローチ

10,000フィートからのCassandra要約

Cassandraハイライト

P2P流通モデル:SPOF(単一障害点)のないことを意味する整合性モデルで動作します。

キーの流通と分割

Dynamoアーキテクチャー&ルックアップ

ノードA、B、C、D、E、F、そしてGのリングでは、ノードB、C、とDは、キーを重要なkを含む(a,b)の範囲の中でキーを格納します。

パーティショナーのためにIntitialTokenパラメーターを使用して、Cassandraのどこにキーがあるのか、その方向性を決定することができます。ストレージの構成を参照してください。

アーキテクチャーの詳細

アーキテクチャーレイヤー

コアレイヤー

ミドルレイヤー

トップレイヤー

メッセージサービス(Messaging service)
ゴシップ障害検出(Gossip Failure detection)
クラスタの状態(Cluster state)
パーティショナー(Partitioner)
レプリケーション(Replication)

コミットログ(Commit log)
Memtable
SSTable
インデックス(Indexes)
コンパクション(Compaction)

廃棄(Tombstones)の有効期間
ハンドオフのヒント(Hinted handoff)
読み込みの修復(Read repair)
ブートストラップ(Bootstrap)
監視(Monitoring)
管理ツール(Admin tools)

書き込み

任意のノードにおけるパーティショナー、コミットログ(Commit log)、Memtable、SSTable、コンパクションは、Wの応答を待ちます。

書き込みモデル:

2つの書き込みモード:

仮にノードがダウンした場合、別のノードへヒント(訳注:ダウンしたノードの情報)と共に書き込みます。このヒントは2つ書き込まれる必要があります。ハーベスターが、15分毎に通過し、ヒントを見つけ、データを適切なノードへ移動します。

Write path

At write time,

書き込みのプロパティ

削除

Deletion marker (tombstone) necessary to suppress data in older SSTables, until compaction Read repair complicates things a little Eventually consistent complicates things more Solution: configurable delay before tombstone GC, after which tombstones are not repaired

読み込み

パスの読み込み

Cassandraはプロパティを読み込む

一貫性

Thrift APIドキュメントも参照してください。

Consistency describes how and whether a system is left in a consistent state after an operation. In distributed data systems like Cassandra, this usually means that once a writer has written, all readers will see that write.

On the contrary to the strong consistency used in most relational databases (ACID for Atomicity Consistency Isolation Durability) Cassandra is at the other end of the spectrum (BASE for Basically Available Soft-state Eventual consistency). Cassandra weak consistency comes in the form of eventual consistency which means the database eventually reaches a consistent state. As the data is replicated, the latest version of something is sitting on some node in the cluster, but older versions are still out there on other nodes, but eventually all nodes will see the latest version.

More specifically: R=read replica count W=write replica count N=replication factor Q=QUORUM (Q = N / 2 + 1)

Cassandra provides consistency when R + W > N (read replica count + write replica count > replication factor).

You get consistency if R + W > N, where R is the number of records to read, W is the number of records to write, and N is the replication factor. A ConsistencyLevel of ONE means R or W is 1. A ConsistencyLevel of QUORUM means R or W is ceiling((N+1)/2). A ConsistencyLevel of ALL means R or W is N. So if you want to write with a ConsistencyLevel of ONE and then get the same data when you read, you need to read with ConsistencyLevel ALL.

stats

ArchitectureOverview_JP (last edited 2013-11-13 00:21:56 by GehrigKunz)