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=9&rev2=10

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

  ## page was copied from ArchitectureOverview
- This is an overview of Cassandra architecture aimed at Cassandra users.
+ #language ja
+ これはCassandra(カサンドラ)ユーザー向けのCassandraアーキテクチャーの概略です。
  
- Developers should probably look at the Developers links on the wiki's 
[[../|front page]]
+ 開発者の方は、Wikiの[[../|フロントページ]]から開発者向けのリンクをご覧ください。
  
- Information is mainly based on 
[[http://assets.en.oreilly.com/1/event/27/Cassandra_%20Open%20Source%20Bigtable%20+%20Dynamo%20Presentation.pdf|J
 Ellis OSCON 09 presentation ]]
+ このページの情報は、オライリー主催の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)]]のプレゼンテーション資料に基づいています。
  
  
+ なぜCassandraなのか?
+  * MySQLでは、あまりにも多くのランダムI / Oが発生する
+  * ファイルベースのソリューションでは、あまりにも多くのロックが必要とされる
  
+ 新たなデータの出現
  
+  * スケールアップではなく、スケールアウト
+  * オンライン状態でのロードバランシングとクラスタの増加の実現
+  * 柔軟なスキーマ
+  * キー指向のクエリー
+  * CAP定理を認識すること
  
  
+ === CAP定理 ===
- Why Cassandra
-  * MySQL drives too many random I/Os
-  * File-based solutions require far too many locks
  
- The new face of data
  
+ Eric 
Brewer(エリック・ブルーワー)の'''([[http://www.cs.berkeley.edu/~brewer/cs262b-2004/PODC-keynote.pdf|CAP定理]])'''に支配された状況では、'''Consistency(一貫性、コンシステンシー)'''、'''Availability(可用性、アベイラビリティー)'''、'''Partition-tolerance(分割耐性、パーティショントレランス)'''のうち2つを選択する必要があります。同時に3つの性質を得ることはできないため、これらを得るにはレイテンシー(遅延)を許容する必要があります。
  
+ 
Cassandraは、可用性と分割耐性('''AP''')を重視しています。一貫性と遅延はトレードオフの関係にあり、Cassandraでは調整可能(tunable)です。遅延を伴えばCassandraでは強い一貫性(strong
 consistency)を得ることができます。しかし、行ロックを取得することはできません。その点は、HBaseの方が優れています。
-  * Scale out, not up 
-  * Online load balancing, cluster growth 
-  * Flexible schema 
-  * Key-oriented queries 
-  * CAP-aware
  
+ メモ: HBaseは、一貫性と分割耐性('''CP''')を重視しています
  
+ === 歴史とアプローチ ===
+ 2つの有名な論文
- === CAP theorem ===
- 
- 
- The '''CAP''' theorem 
([[http://www.cs.berkeley.edu/~brewer/cs262b-2004/PODC-keynote.pdf|Brewer]]) 
states that you have to pick two of '''Consistency''', '''Availability''', 
'''Partition tolerance''': You can't have the three at the same time and get an 
acceptable latency.
- 
- Cassandra values Availability and Partitioning tolerance ('''AP'''). 
Tradeoffs between consistency and latency are tunable in Cassandra.  You can 
get strong consistency with Cassandra (with an increased latency). But, you 
can't get row locking: that is a definite win for HBase.
- 
- Note: Hbase values Consistency and Partitioning tolerance ('''CP''')
- 
- === History and approaches ===
- Two famous papers
  
   * Bigtable: A distributed storage system for structured data, 2006 
   * Dynamo: amazon's highly available keyvalue store, 2007
  
  
  
- Two approaches
+ 2つの有名な論文
  
  
   * Bigtable: "How can we build a distributed db on top of GFS?" 

Reply via email to