对Cassandra的一些思考

Keyspace

Cassandra中的最大组织单元，里面包含了一系列Column family，Keyspace一般是应用程序的名称。可以把它理解为Oracle里面的一个schema，包含了一系列的对象。

Column family（CF）

CF是某个特定Key的数据集合，每个CF物理上被存放在单独的文件中。从概念上看，CF有点象数据库中的Table.

Key

数据必须通过Key来访问，Cassandra允许范围查询，例如：start => '10050', :finish => '10070'

Column

在Cassandra中字段是最小的数据单元，column和value构成一个对，比如：name:“age”，column是name，value是age，每个column:value后都有一个时间戳：timestamp。

和数据库不同的是，Cassandra的一行中可以有任意多个column，而且每行的column可以是不同的。从数据库设计的角度，你可以理解 为表上有两个字段，第一个是Key，第二个是长文本类型，而这个长文件类型是又进行了一次结构化设置 ，用来存放很多的(name,value)对，而每个(name,value)可以认为是一个column。这也是为什么说Cassandra具备非常灵活schema的原 因。

Super column

Super column是一种特殊的column，里面可以存放任意多个普通的column。而且一个CF中同样可以有任意多个Super column，一个CF只能定义使用Column或者Super column，不能混用。这有点象数据库中的嵌套表。

从这个数据模型看，Canssandra的数据模型比关系型数据库模型复杂，而关系型数据库基本上就是一个简单的二维表格。同时Canssandra是基本key-value系统，如果不考虑value内部的复杂设计，基本上可以认为是关系型表简化为两列的情况，一列为key，另一列是一个长文件型的有内部结构的value型的列。

所以从本质上说，Canssandra基本上等于把两列的关系型表+数据水平分割的数据访问路由功能的cluster结合在一起的一个系统 。

传统数据库都是通过SQL来访问数据库的，而SQL已早就成为一个标准，而Canssandra是自成一个体系，所以说对于基于数据库的开发人员来说，传统数据库的开发成本更低。而对于维护人员来说，传统数据库有丰富的资料，各种完善的解决方案以及丰富的维护工具，而Canssandra这类NoSQL的数据库来说，资料比较少，维护成本比较高。

从digg的使用情况看，Canssandra还很不成熟 （见文章：

Digg在挣扎,技术副总裁已卷铺盖走人）,所以我个人觉得，使用成熟的关系数据库＋数据水平拆分的数据访问层，要比使用Canssandra稳定很多，如现在阿里巴巴公司使用的corbar+mysql的方案，corbar是一套做数据水平拆分的集群软件，把前端的请求分发到后面的多台mysql服务器上。另也可以使用plproxy+PostgreSQL的方案。corbar和plproxy只关心数据的路由，而数据的存储、可靠性仍然由传统的关系型数据库保障，由于corbar和plproxy只关心数据的路由部分，所以这部分的代码比较少，也不复杂，这样corbar和plproxy这一块的代码就很稳定，而后面的传统数据库也是久经考验的，所以整个系统 的可靠性比Canssandra稳定的多。

所以，处于科技前沿的新技术总是让开发人员激动不以的，但做为一个公司来说，网站的稳定性是极其重要的，对于运维人员来说，保证系统的可用性也是第一位的。所以在架构选型时，一个定非常谨慎.不要在新技术上面迷失了我们的根本。

对于，新技术，我们一定要问，这个新技术给我们解决了哪些问题？除了提供的一些闪光点外，有哪些不足，是否有更成熟的传统方案可以选择？而不能为了新技术而上新技术。