近期简单写了一个基于Cassandra/C++的日志缓存，虽然是Nosql，但是在实际应用中，还是期望能有部分的临时CQL统计 或+-*/可以支持
所以在针对部分字段入库时，选择了作为整形录入，于是麻烦就来了。
1，第一个碰到的是 Not enough bytes to read value of component 0
经过百般测试发现在建表时的WITH COMPACT STORAGE干扰最大。当去掉该语句时，Thrift程序写入会报错，cql执行会通过。翻阅官网HANDBOOK后发现，
也许是出于节省磁盘空间的出发点，在2.0以后cql界面建表不再自带该参数，cli界面建表自动带上该参数。
根据官网解释，如果是复合主键的Column记录一起存储（或者说是打包存储），独立在外的Column记录单独存储（或者说是散列存储）。
话说回来，不管哪种DB，复合KEY用多了性能都会下降，同时有违P2P精神，也无法体现出cas强大的随机写。
2，第二个碰到的是 Exception: Default TException. [Expected 4 or 0 byte int (1)]
恶心的事情来了：
正常建表全Column都是text，程序负责外部擦屁股，Thrift和cas之间相安无事。
某Column设定为int，cas的cql正常使用，但Thrift开始跟你搞了，报这个错给你看。
按cas源码column定义为：
97 std::string name;
98 std::string value;
99 int64_t timestamp;
100 int32_t ttl;
按thrift源码column定义为：
71 struct Column {
72 1: required binary name,
73 2: optional binary value,
74 3: optional i64 timestamp,
75 4: optional i32 ttl,
76 }
也就是string 转 binary有thrift完成，这一转转出一些道道：
但我们这样去写时会报错
sstemp.clear();
sstemp<<i;
sstemp>>key;
c.name="age";
c.value=i;
cass.insert(key,cparent,c,ConsistencyLevel::ONE);
改成这样去写
sstemp.clear();
sstemp<<i;
sstemp>>key;
c.name="age";
c.value="0021"; //必须4个字符
cass.insert(key,cparent,c,ConsistencyLevel::ONE);
虽然写进去了，但是新问题出现了，转就老老实实转，偏偏对字节进行了拆分补位。。。。
这就没法看了，那为什么会这样？将808464945放到calc中看一下，发现高位4bit被补了0011
也就是 00110000 00110000 00110010 00110001
如果按初始值就是 00110000 00110000 00110000 00110000 按照 2^N SUM，初始值变为了808464432。
继续翻了thrift源码【/root/soft/thrift-0.9.1/lib/cpp/src/thrift/transport】好久，无果，放弃。
这样做意味着写的时候被搞了一把，读的时候，还的再搞一把，而且只能4个字节或者0字节，也就是程序只能写0~9999的整数。这样做显然不合适。
由于insert的源码写的很清楚了，都是封装的对象，不再会有第二种insert 所以，尝试了cas的另外一个datatype:varint
官网解释：精度整形 varint。
依旧是这套写代码，但是value我们不做string ，直接改int赋给string，于是，果然各种强。
至此，搞定了两大数据类型text和int，虽然还是有不少问题有待查证，但是应付一个TASK也算马马虎虎了。
PS：环境 cqlsh 4.1.0 | Cassandra 2.0.2 | CQL spec 3.1.1 | Thrift protocol 19.38.0