Cassandra中实现SQL操作图文介绍。NoSQL数据库是为高扩展性系统设计的。它采用了key/value模型，它的缺点，正如NoSQL名字表明地那样，不支持SQL操作。这听起来像是一个很严重的缺陷—我们怎样对NoSQL上的数据进行“select”，“join”，“group”和“sort”操作？本文介绍了这些操作怎样在cassandra中自然而又有效的实现。
为了能够较清楚的阅读本文，读者需要先明白Cassandra的数据模型，可阅读这篇文章：“Cassandra数据模型”。Cassandra数据模型的优势在于，它通过一个高效的迭代框架（通过column和super column）扩展了基本的key/value存储系统，这意味着，你可以在不检索整条记录的前提下，只对一个column进行读写。下面将介绍怎样利用数据迭代支持各种SQL查询操作。
让我们考虑一个基本的例子：存在一对多关系的department和employee。我们需要两个Column Family（简称“CF”）：Emps和Deps。在Emps中，employee ID作为key，employee的name，birthday和city作为column；在Deps中，department ID作为key，department name作为column。
（1） select
如查询：select * from Emps where Birthdate = ’25/04/1975′
为了支持该查询，我们需要添加一个叫Birthdate_Emps的CF，其中date为key， name为出生在该天的employee的ID，value可以是一个空的byte数组（用“-”代替）。每当从/向 Emps中插入 /删除employee信息时，我们需要同时更新Birthdate_Emps。为了执行该查询，我们只需从Birthdate_Emps中检索出key ’25/04/1975′对应的所有column。
注意，Birthdate_Emps实际上是一个帮助我们快速执行查询的索引，且这个索引有很强的可扩展性，因为它是分布到各个cassandra节点上的。你可以通过在Birthdate_Emps中添加employee冗余信息的方法进一步加速查询速度，这时，employee的ID变成了super column的名字，employee的所有column变成了该super column的column。
（2） Join
例如查询：select * from Emps e, Deps d where e.dep_id = d.dep_id
join实际上是要建立不同实体之间的联系。这种联系可以很容易地通过迭代表示出来。为了实现该查询，可以添加一个叫Dep_Emps的CF，其中department ID作为key，与之对应的employee的ID为name。
（3） Group By
例如查询：select count(*) from Emps group by City
从实现角度看，Group By类似于上面描述的select/indexing，你只需要添加一个叫City_Emps的CF，其中，city作为key，employee的ID作为column name。当执行查询的时候，你只需计算需检索的city对应的employee数目或者专门添加一个column记录该数目。
（4） Order by
为了支持排序操作，你可以使用OrderPreservingPartitioner对数据按照key进行排序。具体可参见：http://ria101.wordpress.com/2010/02/22/cassandra-randompartitioner-vs-orderpreservingpartitioner/
为了支持这些操作，我们 针对查询存储了冗余数据，这样做意味着：
（1） 你必须事先知道系统中需要哪些query（不支持即时查询）。而然，典型的web应用和企业OLTP应用的查询均是事先知道的，且数目不多，不经常改动，具体可阅读这篇论文：The End of an Architectural Era。
（2） 我们将压力从查询转移到更新，这是为了支持物化视图（提前计算出查询结果）。这样做，对于Cassandra是非常有意义的，因为Cassandra的更新操作是经过优化的（多亏了最终一致性和从google的BigTable借鉴的“log-structured”存储理念），并且相比于pull-on-demand模型，cassandra的使用场景更适合push-on-change 模型。关于pull-on-demand和push-on-change模型，可参考文章“Why are Facebook, Digg, and Twitter so hard to scale?”