Cassandra或许不会因为是NoSQL而得到关注，但是它在完成某些特定工作上，有迷人的魅力，这Netflix和Instagram两家公司一定知道。
过去的这些年，NoSQL的参与者，例如MongoDB已经得到了快速发展，受到了非常多的关注，但是 Apache Cassandra的光环褪去，作为创造了Cassandra的Facebook已经放弃了它，Cassandra的社区也好像过时了快。但
是Cassandra的命运迎来的转机，Netflix近来决心把他们自己的数据中心的oracle改成Cassandra Amazon云。不久
以后,Facebook也再次开始使用Cassandra,而Twitter和WebEx都不同程度的使用着Cassandra.
Cassandra的一个大问题在于它太个性，好像不好把它进行分类，虽然类似HBase，它是一个Column-family数据库，但是它却有很大的独得性。它跟文档NoSQL数据库也是不同的类别例如MongoDB或Couchbase,或key-value-pair数据库DynamoDB,Redis,Riak,等等都不一样，它自成一类。
什么是cloumn-family数据库？
一个column-family数据库它按行关键字来存储数据，它非常类似一张表，跟人们熟悉的关系数据库的表很容易混淆，尤其是自从google著名的column-family应用被称为BigTable以后，人们更容易把column的存储结构与关系数据库下的表相混淆了，但是一定要注意此表非彼表。
首先，他们基本上缺少架构schema，架构可以让你很容易的添加你想添加的列（但是你需要考虑存储优化，数据分布等问题），在Cassandra里，表的关键字不紧紧围了方便查找，它可以允许系统有效的在集群上对数据分片，看下面标准的column family结构吧，它看起来非常类似JSON.
ColumnFamilyName { rowkey1 = {column1:"value1", column2:"value2"}, rowkey2 = {column1:"value2.1", column2:"value2.2", column3:"value2.3"}, rowkey3 = {column2:"value3.2", column3:"value3.3"}, rowkey4 = {column1:"value4.1", column3:"value4.3"} }
上面是标准的column family数据库数据存储结构，看起来有一定的局限性，但是作为补充，它还包括一个超级列的概念，类似下面的结构：
SuperColumnFamily { ColumnFamily1 { cf1rowkey1 = {column1:"value1", column2:"value2"}, cf1rowkey2 = {column1:"value2.1", column2:"value2.2", column3:"value2.3"}, cf1rowkey3 = {column2:"value3.2", column3:"value3.3"}, cf1rowkey4 = {column1:"value4.1", column3:"value4.3"} }, ColumnFamily2 { cf2rowkey1 = {column1:"value1", column2:"value2"}, cf2rowkey2 = {column1:"value2.1", column2:"value2.2", column3:"value2.3"}, cf2rowkey3 = {column2:"value3.2", column3:"value3.3"}, cf2rowkey4 = {column1:"value4.1", column3:"value4.3"} } }
另外你还可以找到另外几种结构，例如composite columns和其他类型的列，包括静态和动态列等等。还有些特殊的列类型包括计数列，时间戳列等。
什么情况下使用Cassandra?
一，时间类型的数据
时间类型的数据包括任何温度传感器，工作日志，或股票价格数据等，也包括博客数据，电影片段数据等等，这些数据被证明如果使用文档数据库例如MongoDB会导致失败。
二，产品目录
三，信息过滤系统的子系统信息推荐系统－Recommendations
四，诈骗与垃圾信息侦听系统
五，后端的大数据存储系统
应该说后台数据库存储系统，用Cassandra的地方不是太多，主要是应用它的缓存功能全局网数据复制
的能力，如果你需要异地备份双活数据库的话，你可以使用下Cassandra.
Cassandra与Hbase
Cassandra有自己的优点和缺点，正如Hbase一样，它们都有各自的使用场合两者都在Hadoop生态下，Cassandra用来对读写进行高复合工作，而对毫秒级的数据一致性不是太擅长，而HBase则可以弥补这些，从更大的范围讲，Cassandra适合业务系统，而HBase则更多的用在数据仓库和事务场景的系统上。
说说事务......
开发人员经常困惑什么时候才真正的需要原子级别的一致性，同样如果你开始使用RDBMS,你也会困惑，因为关系型数据库经常需要跨越多个地点收集相同的一组数据。这样一个人的信息可能被打乱放到了多个表中，因为它们有不同的电话好吗，有不同的地址等等，这样就引出－好的数据库架构到底是什么样的？
在现在的任何系统之下，你都需要对数据一致性进行妥协，因为无论你使用什么类型的数据库，都不可能提供长时间运行的事务（足够轻量级的可以满足互联网应用级的要求），因为没有人可以在信息持久话的模式下做操作，而且每个用户对应一个连接，而事务则经常打断用户的操作，影响用户的体验，这就是进行原子级的数据一致性的代价。
但是在很多情况下，一毫秒甚至500毫秒不会有太多的不同，如果我修改了一些行关键字，最终Cassandra会进行持久话，那么我就可以进行读操作，可能这读操作是虚拟读。这里的问题在于，你不会关注一个短暂的错误，例如你正在看电影，发现里面的片段少了，没有数据加载，但是紧紧一会后，你再次单击那部电影，恢复正常了，可以正常观看了，这里你不太会太在意，你在意的是，每当电影目录被更新，你的操作都会被奇怪的中断，所以当前在互联网级的应用上，你需要在性能和系统规模及数据一致性之间做出妥协，有的时候，一致性跟性能及规模来说并不是过于重要。
翻译文章