如何进行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都是一个五维的空间
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
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模型以及架构的分析的方法了吗？如果还想学到更多技能或想了解更多相关内容，欢迎关注亿速云行业资讯频道，感谢各位的阅读！
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
