Cassandra 技术选型的问题

Cassandra在国内资料少，用的也不多，大家更多抱观望态度吧。
为了扩大Cassandra队伍帮助自己采坑，决定写一篇文章，就自己对Cassandra的理解范围进行介绍。

选用Cassandra的基本原因

1. 集群，集群意味着存储能力、负载能力的平行扩展，多节点提供快速故障转移，这是主要原因。
2. 写入，Cassandra写入的能力还是不错，读性能正常水平，但是由于原因1，可以使用更多的设备来弥补。
3. 单表海量数据的存储，Cassandra提供分区功能，类似在mysql中分表操作，减少了分表这一层逻辑，但是也带来了一些限制。
4. CQL 类似 SQL，这里是和redis相比，Cassandra的数据操作更加可控，同时自动管理缓存，可以当做mysql + redis用，然而不需要写两套代码，数据可以设置生存时间，相比redis，数据的落地做的更好，更接近mysql这种关系数据库的数据保障。
5. 客户端，Cassandra提供较完整的客户端，包括PHP、JAVA、PYTHON、C 等等，而且近一年来（2015）更新频繁，可以说在技术支持上提供了较好保障。
   值得一提的是，Cassandra在PHP提供了异步编程模式，这使得较少涉及异步编程的PHP可以同时处理许多耗时的查询。
6. 技术单一，你只需要一个Cassandra安装包，就可以完成集群架设，算是非常简单，这一点是相比HBase。

限制和坑

1. Cassandra无法替代MySQL(下面有介绍)，你可能只能在部分业务中使用，可以替换redis 几乎所有的功能，目前发现就是可排序的计数器还是无法实现。
2. 连接过程异常缓慢，即使在没有账号密码验证的情况下可能也需要几十ms，基本无法容忍，需要有连接池、长连接的支持，如果你需要在PHP中使用Cassandra，可能需要自己实现一个中间件来避免每次请求的连接或者连接数量庞大的问题。
3. 不支持跳页，也就是limit 100,100，只能limit 100 再用条件看“下一页”。
4. 读取速度基本和mysql相当，别指望用Cassandra后页面变快了，不过PHP程序员可以期待一下异步编程带来的速度提升。前面提到，节点不断扩展后，整体的集群负载能力是比mysql要高的，新版本mysql7 不算在内，尚未发现有专业人士提供测试对比数据。
5. 无法提供非常精确的备份还原点，Cassandra是基于镜像和增量备份做还原，只能提供有限的还原时间点。
6. CQL 不是 SQL，你会遇到一些操作限制，比如排序的时候不能用主键的第一级排序 primary key (uid,pid)，只能用pid排序。
7. 文档以英文为主，国内有一些翻译，但是不完整，也可能是我没找对地方。许多同行已经在分享Cassandra的宝贵经验了，stackoverflow会是一个解决问题的好去处。
8. 这一点要非常小心 Cassandra保证最终一致性，你会遇到一些并发导致数据短时不一致问题，在计数器的使用的时候，这个问题非常明显，比如你要将计数器清0，但是可能变成负数，因为有2个进程可能并发请求。这一点可以看另一篇专门介绍计数器的文章。http://www.cnblogs.com/didda/p/4789013.html

对比redis

Cassandra 在操作速度上还是和redis有差距，但是它提供更复杂的数据结构和并发的操作方式，比如你可以给一行数据某些字段加上过期时间，某些字段使用Map结构，另外一些字段像mysql一样保存text、int、blob数据。这一切都可以在同一个table实现。而在使用redis的时候，你需要更细的规划和管理所有的key，避免有些key在redis中，其他人不知道~~。另外通过合并多种数据类型操作，Cassandra在操作次数上可以比redis减少较多。最后就是你不需要总是写一个逻辑：
如果一个数据在redis中，就读redis 返回
否则读取db，写入redis，返回

很眼熟吧，Cassandra自己做完这个事了。

PHP开发的一些问题和解决方法

1. 连接特别慢，使用swoole 做中间件，保持所有的Cassandra连接，可以解决。
2. timeuuid bigint map set 等数据类型在入库的时候，你需要像强类型语言一样，指定类型，这个没有办法，你可以为每张表写一个类型映射，进行自动匹配。