关于Cassandra与Thrift在int/text/varint上的暧昧

近期简单写了一个基于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