共计 3531 个字符，预计需要花费 9 分钟才能阅读完成。
如何进行 Cassandra 模型以及架构的分析，相信很多没有经验的人对此束手无策，为此本文总结了问题出现的原因和解决方法，通过这篇文章希望你能解决这个问题。
NoSql 的世界纷繁复杂，出去掉 Redis 等内存型的数据库之外，在整个 NoSQl 领域比较认可的是 Cassandra，Hbase，以及 MongoDB。
对于 Mongo，目前本 ID 的系列博文已经有部分，而 Hbase 有关的部分还未补充，待补。
高可靠性 协议
1：Cassandra 采用了 gossip 作为集群中节点的通信协议，该协议整个节点都处于同等的地位，没有主从
之分，这就使得任一节点的推出都不会导致整个集群的失效。
2:Cassandra 和 Hbase 在底层的架构设计都是借鉴了 Google Big Table 的思想来构建自己的系统，而
Cassandra 的创新就是将原本用在文件共享架构的 P2P（Peer to Peer）引入到了 NoSql
P2P 的一大特点就是去中心化，集群之中的所有节点都有着同等的地位，这极大的避免了单个节点退出，
而使整个集群不能工作的可能，与之形成对比的是 Hbase 采用了 Master/Slave 的方式，这就存在了单点失效的可能。
1.2：高扩展性
随着时间的推移，集群中原有的规模不足以存储新增加的数据，目前 NoSql 的数据都已经实现了
级联的扩展，非常容易实现添加新的节点到已有集群，操作简单。
1.3：最终一致性
在这里再次强调一下最终一致性：Cassandra 采用了最终的一致性：
最终的一致性是指分布式系统之中的一个数据对象的多个副本尽管在短时间内可能出现不一致，但是经过
一段时间以后，这些副本最终会达到一致。
Cassandra 是优先保证了 AP，也就是我们经常说到的可用性，和分区容错性。
通常而言，大部分的 NoSQL key-value 的模式都是写入非常的高效，毕竟是为了大量数据的插入所涉及，
可是在数据的读取方面那就依据不同的情况而不同。
1：如果是单个读取指定了的 key，那就回很快的返回结果。-》指定 key 查询。
2 : 如果是范围查询，由于查询的目标可能存储在多个节点之上，这就需要要对多个节点
来进行查询，速度会比较慢。
3：全表扫。毫无疑问，全表扫描数据，会非常的低效。
数据模型
由于 Cassandra 采用了类似与 BigTable 的数据结构组织，Cassandra 和 Hbase 比较类似。所以 Cassandra 和 Hbase 相比也存在着许多相同的概念。
如果抽象来看 Cassandra。整个 Cassandra 都是一个五维的空间
1：column
column：列，在 Cassandra 之中是最小的一个数据单元，它包含了一个三元的数据类型：
1: { // 这是一个 column
2: name: 美丽新世界 ,
3: value: gpcuster@gmali.com ,
4: timestamp: 123456789
5: }
upercolumn：超级列
我们可以将 SuperColumn 想象成 Column 的数组，他包含一个 name。以及一系列的 Column
将一个 SuperColumn 用 JSON 的形式表示如下
{ // 这是一个 SuperColumn
2: name: “美丽的新世界 ,
3: // 包含一系列的 Columns
4: value: { 5: street: {name: street , value: 1234 x street , timestamp: 123456789},
6: city: {name: city , value: san francisco , timestamp: 123456789},
7: zip: {name: zip , value: 94107 , timestamp: 123456789},
8: }
9: }
Columns 和 SuperColumns 都是一个 Key Value，一个 name 和一个 String 的组合，最大的不同在于 Column 的 Value 是一个“String”，而 SuperColumn 的 value 是一个 Cloumns 的 Map
1：Column family
Column family 是一个包含了一个许多行 [Row] 的结构，你可以将它想象成 RDBMS 中的 Table，每一个行都包含有 Clinet 提供的 Key 和该 KEY 关联的的一系列的 Column，我们可以看到如下的结构：
1: UserProfile = { // 这是一个 ColumnFamily
2: phatduckk: { // 这是对应 ColumnFamily 的 key
3: // 这是 Key 下对应的 Column
4: username: gpcuster ,
5: email: gpcuster@gmail.com ,
6: phone: 6666
7: }, // 第一个 row 结束
8: ieure: { // 这是 ColumnFamily 的另一个 key
9: // 这是另一个 Key 对应的 column
10: username: pengguo ,
11: email: pengguo@live.com ,
12: phone: 888
13: age: 66
14: },
15: } 1: UserProfile = { // 这是一个 ColumnFamily
2: phatduckk: { // 这是对应 ColumnFamily 的 key
3: // 这是 Key 下对应的 Column
4: username: gpcuster ,
5: email: gpcuster@gmail.com ,
6: phone: 6666
7: }, // 第一个 row 结束
8: ieure: { // 这是 ColumnFamily 的另一个 key
9: // 这是另一个 Key 对应的 column
10: username: pengguo ,
11: email: pengguo@live.com ,
12: phone: 888
13: age: 66
14: },
15: }ColumnFamily 的类型可以是 Standard，也可以是 Super 的类型，我们刚刚看到的例子是一个 Stand 类型的 ColumnFamily。除此之外，还有另外的一种形式，也就是不每一行不仅仅只是一个列，还可能是一个 CF
如下所示：
1: AddressBook = { // 这是一个 Super 类型的 ColumnFamily
2: phatduckk: { // key
3: friend1: {street: 8th street , zip: 90210 , city: Beverley Hills , state: CA},
4: John: {street: Howard street , zip: 94404 , city: FC , state: CA},
5: Kim: {street: X street , zip: 87876 , city: Balls , state: VA},
6: Tod: {street: Jerry street , zip: 54556 , city: Cartoon , state: CO},
7: Bob: {street: Q Blvd , zip: 24252 , city: Nowhere , state: MN},
8: ...
9: }, // row 结束
10: ieure: { // key
11: joey: {street: A ave , zip: 55485 , city: Hell , state: NV},
12: William: {street: Armpit Dr , zip: 93301 , city: Bakersfield , state: CA},
13: },
14: }注意，在 Hbase 之中也有一个 CL 的概念。
3：keySpace
KeySpace 是我们最外层的数据结构，通常的情况，我们的应用程序只有一个 KeySpace，简单点来讲，keySpace，可以把 keySpace 想象成为 RDBMS 之中的 database。
相对与关系型的数据库的三层结构：
database – table – colum 而言。
cassandra 的结构层次如下：
keyspace- column family【column|super column】
看完上述内容，你们掌握如何进行 Cassandra 模型以及架构的分析的方法了吗？如果还想学到更多技能或想了解更多相关内容，欢迎关注丸趣 TV 行业资讯频道，感谢各位的阅读！
