cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Cassandra Wiki] Update of "ArchitectureOverview_JP" by Kazuki Aranami
Date Thu, 01 Apr 2010 07:44:26 GMT
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=10&rev2=11

--------------------------------------------------

  
  開発者の方は、Wikiの[[../|フロントページ]]から開発者向けのリンクをご覧ください。
  
- このページの情報は、オライリー主催の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)]]のプレゼンテーション資料に基づいています。
+ このページの情報は、オライリー主催の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)]]のプレゼンテーション資料に基づいています。
  
  
- なぜCassandraなのか?
+ なぜCassandraなのでしょうか?
-  * MySQLでは、あまりにも多くのランダムI / Oが発生する
+  * MySQLでは、あまりにも多くのランダムI/Oが発生する
   * ファイルベースのソリューションでは、あまりにも多くのロックが必要とされる
  
  新たなデータの出現
@@ -25, +25 @@

  === CAP定理 ===
  
  
- Eric Brewer(エリック・ブルーワー)の'''([[http://www.cs.berkeley.edu/~brewer/cs262b-2004/PODC-keynote.pdf|CAP定理]])'''に支配された状況では、'''Consistency(一貫性、コンシステンシー)'''、'''Availability(可用性、アベイラビリティー)'''、'''Partition-tolerance(分割耐性、パーティショントレランス)'''のうち2つを選択する必要があります。同時に3つの性質を得ることはできないため、これらを得るにはレイテンシー(遅延)を許容する必要があります。
+ 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つの有名な論文
  
-  * Bigtable: A distributed storage system for structured data, 2006 
-  * Dynamo: amazon's highly available keyvalue store, 2007
+  * [[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つの有名な論文
+ 2つのアプローチ
  
+  * BigTable:”どのようにしてGFS上に分散データベースを構築できるか?”

+  * Dynamo:”どのようにして、分散ハッシュテーブルをデータセンターに相応しいように構築できるか?”
  
-  * Bigtable: "How can we build a distributed db on top of GFS?" 
-  * Dynamo: "How can we build a distributed hash table appropriate for the data center?"
  
  
+ === 10,000フィートからのCassandra要約 ===
  
- === Cassandra 10,000 ft summary ===
  
+  * Dynamoのパーティション分割およびレプリケーション
+  * BigTableに類似したログ構造のColumnFamilyデータモデル
  
-  * Dynamo partitioning and replication 
-  * Log-structured ColumnFamily data model similar to Bigtable's
  
  
+ === Cassandraハイライト ===
  
- === Cassandra highlights ===
  
+  * 高可用性 
+  * 可用性の増分 
+  * イベンチュアルコンシステント(Eventually consistent)
+  * 一貫性と遅延というトレードオフの関係が調整可能 
+  * 最小限の管理
- 
-  * High availability 
-  * Incremental scalability 
-  * Eventually consistent 
-  * Tunable tradeoffs between consistency and latency 
-  * Minimal administration 
-  * No SPF (Single Point of Failure)
+  * SPOF(Single Point of Failure、単一障害点)がない
  
  
- p2p distribution model -- which drives the consistency model -- means there is no single
point of failure. 
+ P2P流通モデル:SPOF(単一障害点)のないことを意味する整合性モデルで動作します。
  
  
  
@@ -74, +73 @@

  
  
  
- == Keys distribution and Partition ==
- Dynamo architecture & Lookup
+ == キーの流通と分割 ==
+ Dynamoアーキテクチャー&ルックアップ
  
  
  In a ring of nodes A, B, C, D, E, F and G
  Nodes B, C and D store keys in the range (''a'',''b'') including key ''k''
  
  
- You can decide where the key should go in Cassandra using the {{{IntitialToken}}} parameter
for your {{{Partitioner}}}, see [[StorageConfiguration|Storage Configuration]]
+ {{{パーティション分割}}}のために{{{IntitialToken}}}パラメーターを使用して、Cassandraのどこにキーがあるのか、その方向性を決定することができます。[[StorageConfiguration|ストレージの構成]]を参照してください。
  
- Architecture details
+ アーキテクチャーの詳細
  
  
-  * O(1) node lookup 
-  * Explicit replication 
+  * O(1)ノードのルックアップ 
+  * 明示的なレプリケーション
-  * Eventually consistent
+  * イベンチュアルコンシステント(Eventually consistent)
  
  
  
  
  
- === Architecture layers ===
+ === アーキテクチャーレイヤー ===
  
- ||Core Layer || Middle Layer || Top Layer||
- || 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 ==
  
@@ -185, +184 @@

   * Scales to billions of rows
  
  
- == Consistency ==
- See also the [[API|API]] documentation.
+ == 一貫性 ==
+ [[API|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.
+ 何か操作を行った後に、システムが一貫性を保持した状態を、どのようにして実現するのか、整合性について詳しく説明していきます。Cassandraのような分散システムのデータは、通常一度ライターが書き込みを試行し、すべて読み込みができることを確認した後に、実際に書き込みを行うことをまず理解してください。
  
- 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.
+ ほとんどのACIDなリレーショナルデータベースで使用されている、強い一貫性(strong
consistency)とは違い、CassandraはBASEスペクトラム(連続体)の片隅に位置します。(訳注:Cassandraは、NoSQLの文脈で語られるBASEの概念を適用した分散データベースのひとつとして位置づけられます)
+ 
+ Cassandraの弱い一貫性(weak consistency)は、データベースが一貫性のある状態にいつか到達するという、イベンチュアルコンシステンシー(eventual
consistency)の考えに基づいています。
+ 
+ データがレプリケート(複製)されるにつれて、クラスタ上のいくつかのノードに最新バージョンが存在することになります。しかし古いバージョンの複製も他のノード上に、まだ存在することになります。しかし、いつかすべてのノードが最新バージョンとなることを理解してください。
+ 
  
  
  More specifically:

Mime
View raw message