近期簡單寫了一個基于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

也就是 0011 0000 0011 0000 0011 0010 0011 0001

如果按初始值就是? 0011 0000? 0011 0000? 0011 0000? 0011 0000 按照 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?

關于Cassandra與Thrift在int/text/varint上的曖昧