Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification.
The "ArchitectureOverview" page has been changed by tuxracer69. http://wiki.apache.org/cassandra/ArchitectureOverview?action=diff&rev1=3&rev2=4 -------------------------------------------------- ... and when you do, it usually isn't relational anymore + Why Cassandra + * MySQL drives too many random I/Os + * File-based solutions require far too many locks + - * The new face of data + The new face of data - Scale out, not up Online load balancing, cluster growth Flexible schema Key-oriented queries CAP-aware + * Scale out, not up + * Online load balancing, cluster growth + * Flexible schema + * Key-oriented queries + * CAP-aware - * CAP theorem + === CAP theorem === - Pick two of Consistency, Availability, Partition tolerance + The '''CAP''' theorem (Brewer00) states that you have to pick two of '''Consistency''', '''Availability''', '''Partition tolerance'''. (You can't have the three at the same time). + 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 @@ -43, +56 @@ - 10,000 ft summary + === Cassandra 10,000 ft summary === * Dynamo partitioning and replication @@ -51, +64 @@ - Cassandra highlights + === Cassandra highlights === * High availability @@ -62, +75 @@ * No SPF (Single Point of Failure) - + p2p distribution model -- which drives the consistency model -- means there is no single point of failure. @@ -84, +97 @@ - Architecture layers + === 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 - * Gossip - * Failure detection - * Cluster state - * Partitioner - * Replication - - * Commit log - * Memtable - * SSTable - * Indexes - * Compaction - - * Tombstones - * Hinted handoff - * Read repair - * Bootstrap - * Monitoring - * Admin tools == Writes == @@ -190, +185 @@ === Consistency in a BASE world === - - Specify W, number of nodes to wait for - + If + R=read replica count + W=write replica count + N=replication factor + Q='''QUORUM''' (Q = N / 2 + 1) * If W + R > N, you will have consistency * W=1, R=N * W=N, R=1 * W=Q, R=Q where Q = N / 2 + 1 - + Cassandra provides consistency when R + W > N (read replica count + + write replica count > replication factor).
