Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification.
The "ArchitectureOverview_JP" page has been changed by Kazuki Aranami. http://wiki.apache.org/cassandra/ArchitectureOverview_JP?action=diff&rev1=11&rev2=12 -------------------------------------------------- ## page was copied from ArchitectureOverview #language ja - これはCassandra（カサンドラ）ユーザー向けのCassandraアーキテクチャーの概略です。 + + アーキテクチャーオーバービューは、Cassandra（カサンドラ）ユーザー向けのCassandraアーキテクチャーの概略です。 + + - 開発者の方は、Wikiの[[../|フロントページ]]から開発者向けのリンクをご覧ください。 + 開発者の方は、Wikiの[[FrontPage_JP|フロントページ]]から開発者向けのリンクをご覧ください。 + このページの情報は、オライリー主催のOSCON 2009[[http://assets.en.oreilly.com/1/event/27/Cassandra_%20Open%20Source%20Bigtable%20+%20Dynamo%20Presentation.pdf|Cassandra: Open Source Bigtable + Dynamo、Jonathan Ellis (Rackspace Hosting) (PDF)]]のプレゼンテーション資料に基づいています。 @@ -13, +17 @@ * MySQLでは、あまりにも多くのランダムI/Oが発生する * ファイルベースのソリューションでは、あまりにも多くのロックが必要とされる + 新たなデータの出現 - * スケールアップではなく、スケールアウト * オンライン状態でのロードバランシングとクラスタの増加の実現 * 柔軟なスキーマ @@ -23, +27 @@ === CAP定理 === + Eric Brewer（エリック・ブルーワー）の'''[[http://www.cs.berkeley.edu/~brewer/cs262b-2004/PODC-keynote.pdf|CAP定理 (PDF)]]'''に支配された状況では、'''Consistency（一貫性、コンシステンシー）'''、'''Availability（可用性、アベイラビリティー）'''、'''Partition-tolerance（分割耐性、パーティショントレランス）'''のうち2つを選択する必要があります。同時に3つの性質を満たすことはできないため、それらを得るにはレイテンシー（遅延）を許容する必要があります。（訳注：BASEの考えを適用する必要があります） - Eric Brewer（エリック・ブルーワー）の'''[[http://www.cs.berkeley.edu/~brewer/cs262b-2004/PODC-keynote.pdf|CAP定理 (PDF)]]'''に支配された状況では、'''Consistency（一貫性、コンシステンシー）'''、'''Availability（可用性、アベイラビリティー）'''、'''Partition-tolerance（分割耐性、パーティショントレランス）'''のうち2つを選択する必要があります。同時に3つの性質を満たすことはできないため、それらを得るにはレイテンシー（遅延）を許容する必要があります。（訳注：BASEの考えを適用する必要があります） + Cassandraは、可用性と分割耐性（'''AP'''）を重視しています。一貫性と遅延はトレードオフの関係にあり、Cassandraでは整合性レベルが調整可能（tunable）です。遅延を許容すればCassandraでは強い一貫性（Strong Consistency）を得ることができます。しかし、行ロックを取得することはできません。その点は、HBaseの方が優れています。 - Cassandraは、可用性と分割耐性（'''AP'''）を重視しています。一貫性と遅延はトレードオフの関係にあり、Cassandraでは調整可能（tunable）です。遅延を許容すればCassandraでは強い一貫性（strong consistency）を得ることができます。しかし、行ロックを取得することはできません。その点は、HBaseの方が優れています。 メモ: HBaseは、一貫性と分割耐性（'''CP'''）を重視しています + === 歴史とアプローチ === 2つの有名な論文 - * [[http://labs.google.com/papers/bigtable-osdi06.pdf|Bigtable: A Distributed Storage System for Structured Data, 2006 (PDF)]] * [[http://s3.amazonaws.com/AllThingsDistributed/sosp/amazon-dynamo-sosp2007.pdf|Dynamo: amazon's highly available keyvalue store, 2007 (PDF)]] - 2つのアプローチ - * BigTable：”どのようにしてGFS上に分散データベースを構築できるか？” * Dynamo：”どのようにして、分散ハッシュテーブルをデータセンターに相応しいように構築できるか？” - === 10,000フィートからのCassandra要約 === - - - * Dynamoのパーティション分割およびレプリケーション + * Dynamoのパーティショナーおよびレプリケーション * BigTableに類似したログ構造のColumnFamilyデータモデル - === Cassandraハイライト === - - * 高可用性 * 可用性の増分 - * イベンチュアルコンシステント（Eventually consistent） + * イベンチュアルコンシステント（Eventually Consistent） - * 一貫性と遅延というトレードオフの関係が調整可能 + * 一貫性と遅延というトレードオフの関係が調整可能 * 最小限の管理 * SPOF（Single Point of Failure、単一障害点）がない P2P流通モデル：SPOF（単一障害点）のないことを意味する整合性モデルで動作します。 - - - - - == キーの流通と分割 == @@ -81, +72 @@ Nodes B, C and D store keys in the range (''a'',''b'') including key ''k'' - {{{パーティション分割}}}のために{{{IntitialToken}}}パラメーターを使用して、Cassandraのどこにキーがあるのか、その方向性を決定することができます。[[StorageConfiguration|ストレージの構成]]を参照してください。 + {{{パーティショナー}}}のために{{{IntitialToken}}}パラメーターを使用して、Cassandraのどこにキーがあるのか、その方向性を決定することができます。[[StorageConfiguration|ストレージの構成]]を参照してください。 + アーキテクチャーの詳細 - - * O（1）ノードのルックアップ * 明示的なレプリケーション - * イベンチュアルコンシステント（Eventually consistent） + * イベンチュアルコンシステント（Eventually Consistent） - - - === アーキテクチャーレイヤー === - ||コアレイヤー || ミドルレイヤー || トップレイヤー|| - || メッセージサービス（Messaging service） <<BR>> ゴシップ障害検出（Gossip Failure detection） <<BR>>クラスタの状態（Cluster state） <<BR>>パーティション分割（Partitioner） <<BR>>レプリケーション（Replication） <<BR>>||コミットログ（Commit log） <<BR>>Memtable <<BR>>SSTable <<BR>>インデックス（Indexes） <<BR>>圧縮（Compaction） <<BR>>|| 廃棄（Tombstones）の有効期間 <<BR>> ハンドオフのヒント（Hinted handoff） <<BR>> 読み込みの修復（Read repair） <<BR>> ブートストラップ（Bootstrap） <<BR>> 監視（Monitoring） <<BR>> 管理ツール（Admin tools） || + || メッセージサービス（Messaging service） <<BR>> ゴシップ障害検出（Gossip Failure detection） <<BR>>クラスタの状態（Cluster state） <<BR>>パーティショナー（Partitioner） <<BR>>レプリケーション（Replication） <<BR>>||コミットログ（Commit log） <<BR>>Memtable <<BR>>SSTable <<BR>>インデックス（Indexes） <<BR>>コンパクション（Compaction） <<BR>>|| 廃棄（Tombstones）の有効期間 <<BR>> ハンドオフのヒント（Hinted handoff） <<BR>> 読み込みの修復（Read repair） <<BR>> ブートストラップ（Bootstrap） <<BR>> 監視（Monitoring） <<BR>> 管理ツール（Admin tools） || - - == Writes == - Any node Partitioner Commitlog, memtable SSTable Compaction Wait for W responses + == 書き込み == + 任意のノードにおけるパーティショナー、コミットログ（Commit log）、Memtable、SSTable、コンパクションは、Wの応答を待ちます。 + 書き込みモデル： - Write model: - - There are two write modes: - * ''Quorum write'': blocks until quorum is reached - * ''Async write'': sends request to any node. That node will push the data to appropriate nodes but return to client immediately - If node down, then write to another node with a hint saying where it should be written two. Harvester every 15 min goes through and find hints and moves the data to the appropriate node + 2つの書き込みモード： + * ''クォーラム書き込み（Quorum write）'': ブロッククォーラムに達するまで + * ''非同期書き込み（Async write）'': 任意のノードに要求を送信します。そのノードから適切なノードにデータを送信し、ただちにクライアントへ返信します。 + + + 仮にノードがダウンした場合、別のノードへヒント（訳注：ダウンしたノードの情報）と共に書き込みます。このヒントは2つ書き込まれる必要があります。ハーベスターが、15分毎に通過し、ヒントを見つけ、データを適切なノードへ移動します。 + === Write path === At write time, @@ -138, +125 @@ * Discard tombstones + === 書き込みのプロパティ === + * 読み込みをしない + * シークを行わない + * ''高速'' + * ColumnFamilyの範囲内がアトミックである + * 常に書き込み可能 - === Write properties === - - * No reads - * No seeks - * ''Fast'' - * Atomic within ColumnFamily - * Always writable + == 削除 == - - - == Remove == 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 + == 読み込み == + === パスの読み込み === + * 任意のノード + * パーティショナー + * Rの応答を待つ + * Nの待機 - Rの応答をバッググラウンドで処理中に、読み込みの修復を実行 + === Cassandraはプロパティを読み込む === + * 複数のSSTableを読み込む + * （まだ高速ですが）遅延書き込み + * シークはより多くのメモリー消費を軽減することが可能 + * 数十億の行にわたりスケール - - - - - - - - == Read == - - === Read path === - - - * Any node - * Partitioner - * Wait for R responses - * Wait for N - R responses in the background and perform read repair - - === Cassandra read properties === - - * Read multiple SSTables - * Slower than writes (but still fast) - * Seeks can be mitigated with more RAM - * Scales to billions of rows == 一貫性 == - [[API|API]]ドキュメントも参照してください。 + [[API|Thrift API]]ドキュメントも参照してください。 + 何か操作を行った後に、システムが一貫性を保持した状態を、どのようにして実現するのか、整合性について詳しく説明していきます。Cassandraのような分散システムのデータは、通常一度ライターが書き込みを試行し、すべて読み込みができることを確認した後に、実際に書き込みを行うことをまず理解してください。 - ほとんどのACIDなリレーショナルデータベースで使用されている、強い一貫性（strong consistency）とは違い、CassandraはBASEスペクトラム（連続体）の片隅に位置します。（訳注：Cassandraは、NoSQLの文脈で語られるBASEの概念を適用した分散データベースのひとつとして位置づけられます） + ほとんどのACIDなリレーショナルデータベースで使用されている、強い一貫性（Strong Consistency）とは違い、CassandraはBASEスペクトラム（連続体）の片隅に位置します。（訳注：Cassandraは、NoSQLの文脈で語られるBASEの概念を適用した分散データベースのひとつとして位置づけられます） + + - Cassandraの弱い一貫性（weak consistency）は、データベースが一貫性のある状態にいつか到達するという、イベンチュアルコンシステンシー（eventual consistency）の考えに基づいています。 + Cassandraの弱い一貫性（Weak Consistency）は、データベースが一貫性のある状態にいつか到達するという、イベンチュアルコンシステンシー（Eventual Consistency）の考えに基づいています。 + データがレプリケート（複製）されるにつれて、クラスタ上のいくつかのノードに最新バージョンが存在することになります。しかし古いバージョンの複製も他のノード上に、まだ存在することになります。しかし、いつかすべてのノードが最新バージョンとなることを理解してください。 - More specifically: @@ -214, +189 @@ 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. + Cassandra vs MySQL with 50GB of data
