Cassandra数据模型思考

采用NoSQL技术的云存储解决方案渐渐成熟，但SQL数据库思想还是占据主导地位。这可能导致使用SQL的方式来解决NoSQL的数据建模问题。本文根据作者的Cassandra项目开发和项目实施经验，对NoSQL建模做一些概要性的指导。文章没有具体的语法指导数据建模，这些问题请参考apache网站。 Cassandra已经升级为apache组织的顶级项目。目前保持非常快的开发升级速度。Apache已经放出1.0beta版本。不同版本的Cassandra具有不同的特性，因此，在开发的角度也可以采用不同的数据模型。

Cassandra模型可以用一个5维数组表示，相对应keyspace、ColumnFamily（SuperColumns）、Key、Columnes、Value这5个维度。在获取数据采用get语法，以get key为最大获取数据维度，columns为最小获取数据维度。

获取数据可以这样理解：由于Key值索引是缺省索引，只支持精确查找。如果我们希望最快速的找出一个班的学生，最简单的方法是以班级代码为Key建模。如果我们希望最快速的找出一个年级的学生，当然以年级代码为Key建模。

这样的解决方式会带来一个问题。在以关系型数据库为主的各种应用中，我们习惯了使用条件语句查找数据，从整个数据集中获取需要的数据。如：where年级="3"或where班级="302"。SQL可以简洁的建立应用的模型。而Cassandra似乎不能这样。

实际情况也确实如此。在Cassandra 0.6版本时，除非使用代码，否则很难像SQL一样方便解决这个简单的问题。如果仅这样思考问题，同样也说明我们还在使用SQL的经验和方式来思考。关系型数据库应用系统经验如：3个经典范式，甚至PK、FK、字典表、schema等无一不主导思维。所以，我们需要改变这种思维。

Cassandra不是关系型数据库，其CF的设计大约是以一类查询为基础。这个观点有两层理解：1、以应用的角度来考虑数据存储；2、数据模型关键是在第二级，也就是ColumnFamily。例如：查询一个年级的学生，就应该以年级为CF来组织数据；查询一个班级的学生，就应该以班级为CF来组织数据。

看起来这非常的不可思议。对于具备丰富SQL经验的人确实如此（感同身受）。在做系统概要设计时，为什么用NoSql技术而不用SQL数据库？最简单的理由是SQL数据库不能胜任。由于SQL数据库在大数据量时维护复杂的数据约束关系导致性能上的巨大开销，影响了业务。

以上只是一个简单的案例，不需要过于。在使用NoSql数据库前，我们应该好好反省根深蒂固的SQL数据库+OLTP型应用的思维方式。NoSQL领域有一个CAP理论：一个分布式系统不能同时满足一致性，可用性和分区容错性这三个需求，最多只能同时满足两个。

这个理论面临各种猜疑和压力，但在没有更好的理论支持前，暂且用着也无妨。Cassandra在这个理论中被标记为A+P，即可用性和分区容忍性。可用性（Availability）：每一个操作总是能够在确定的时间内返回，也就是系统随时都是可用的。分区容忍性（Partition Tolerance）： 在出现网络分区（比如断网）的情况下，分离的系统也能正常运行（这些思想在SQL中也很难理解）。

不同的应用有不同的侧重点。传统OLTP型应用中，我们必须ACID特性。而在非交易型的分布式系统，我们的点是在系统的可用性上，如系统的部分节点宕机，仍需要保证业务的可用性。这里有个专业的术语描述“BASE”。

随着Cassandra的不断完善和升级，我们在处理数据模型上也就较大的自由度。Cassandra 0.7相比较以前的版本，除了bug修复和性能的提高，还有一个最重要的更新就是2级索引。Key索引为一级索引，column索引为二级索引。同样的问题。采用2级索引可以更方便的解决。

在Cassandra 0.7中，对列值（column values）的索引叫做“二级索引”，它与列簇（ColumnFamilies）中对Key的索引不同。二级索引允许我们对值进行查询，并且在后台自动建立，不会引起读写阻塞。二级索引可以使用范围查询。这样，我们可以改良原始方案。可以使用更直观的、维护和编程一致的解决方案。

在使用二级索引时，需要注意：在所谓的primary（主要描述）数据集中使用一个嵌套循环过滤。意味着在查询语句中不能只使用一个索引条件如：班级>302 ，否则只会得到：No indexed columns present in index clause with operator EQ 。

在使用二级索引时，需要增加一个主要描述索引。如增加一个年级索引，使用条件where 年级= "3" and 班级 > 302；这个案例似乎不大好理解。从另一个角度上来看二级索引其实是取出所有满足等式的数据集，再循环遍历。以前需要写代码解决的事情，现在只需要建立索引就能搞定。

对于Cassandra模型的理解，可以让我们更优雅的解决应用开发的问题。通常，Cassandra只能提供对key的确定值查询。如果需要对key进行范围查询呢？有两个方法：1、修改模型，将key维度下沉到column维度，然后建二级索引查询；2、数据分布策略中，如果采用有序的分布策略如： OrderPreservingPartitioner等，就可以使用Key的范围查询。

数据建模不仅仅受开发工具影响，还需要考虑应用的类型。OLAP型应用比OLTP型应用更多地使用冗余的数据模型。一个原因是描述同一个对象的粒度不同，还有一个原因是以空间代价换取时间代价。所以在Cassandra建模的过程中也应该考虑这些因素。

在不久的将来，云计算一定会彻底走入我们的生活，有兴趣入行未来前沿产业的朋友，可以收藏云计算，及时获取人工智能、大数据、云计算和物联网的前沿资讯和基础知识，让我们一起携手，引领人工智能的未来！

标签： 大数据 代码 数据库 网络 云计算

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点！
本站所提供的图片等素材，版权归原作者所有，如需使用，请与原作者联系。