文章翻譯：朱瀚杰
發(fā)表時間：2015 年 7 月 23 日
原文作者：mheffner
文章分類：大數據及商務智能
本文簡單介紹了 Cassandra 上時間序列的存儲，引入了壓縮存儲的概念并將壓縮存儲和非壓縮存儲方式用簡單的例子進行了對比，得出了非壓縮存儲會消耗更多的存儲空間的結論。文章同時提到不同的需求和條件下應該考慮選擇不同的存儲格式。
在 Librato，我們對時間序列的儲存主要是應用我們一直在研發(fā)的自定義架構所建立的 Apache Cassandra。關于它我們之前已經寫到并呈現過幾次。在 Cassandra 上我們既存儲真實的時間序列也存儲歷史匯總時間序列。Cassandra 存儲節(jié)點在我們的基礎設施中占有最大的足跡，因而這些節(jié)點驅動著我們的成本開支，所以我們一直在尋找方式來改進我們數據的效率。
作為我們正在進行的效率改進和后臺功能研發(fā)的部分，我們最近花時間重新評估了我們的存儲架構。自 Cassandra 0.8.x 版本的早些時候以來，我們的架構一直被建立在 Thrift APIs 的內容之上，并且無論何時當我們豎起一個新環(huán)路，我們使用‘節(jié)點工具’命令來移動它。我們一直都在緊密的跟隨 CQL 的發(fā)展并且已經將我們的讀取路徑的部分在 2.0.x 版本中移動到了新的本地接口。甚至，我們想要更進一步關注使用本地 CQL 接口完全構造我們的架構轉移（創(chuàng)建 CQL 表，或者他們所稱的“列族”）。
先前當我們關注 CQL 表結構時困住我們的事情之一是涉及到一個 COMPACT STORAGE 選項--我將停止吐槽并且從這之后把它稱作為壓縮存儲。其定義文檔如下：
“…主要將對 CQL3 之前創(chuàng)建的定義的反向兼容性為目標...在硬盤上提供一個更壓縮緊湊一些的數據分布，但這樣是以減小靈活性和拓展性為代價的…由于以上原因是不推薦向后兼容性之外使用的?！?
在 CQL 之前當 Thrift 接口是唯一的 API 時，所有的表都是以壓縮存儲的方式建立的。和文檔狀態(tài)一樣，它是一個除了向后兼容性外別無它用的遺留選項。
在我們的調研大約進行到這個時候我們偶然發(fā)現了某團隊研究解析的一篇博客文章。主要是關于他們對 CQL 表的經驗認識。這是一篇很棒的文章，我十分推薦它。文章有一段的標題是 “我們沒有使用 COMPACT STORAGE…你敢相信下面發(fā)生了什么嗎”。它記錄了使用壓縮存儲的他們自己的調研。在這篇文章中，他們提及了當沒有對表使用壓縮存儲時他們看到一個大 30 倍的存儲空間容量。如果知道我們所處理的數據庫的容量大小，這種類型的增大是不可忽視的。
那么讓我們研究一下一個 CQL 表的數據分布是什么樣的。我們將以一個簡化過的例子開始，它來自用 Cassandra 建立一項音樂服務的教程指南。我們已經用一個（id，song_id）的指針把表減少到只有一個 id，音樂 id 和歌曲名稱。
CREATE TABLE playlists_1 ( id uuid, song_id uuid, title text,
PRIMARY KEY (id, song_id )
);
INSERT INTO playlists_1 (id, song_id, title)
VALUES (62c36092-82a1-3a00-93d1-46196ee77204,
7db1a490-5878-11e2-bcfd-0800200c9a66,
'Ojo Rojo');
INSERT INTO playlists_1 (id, song_id, title)
VALUES (444c3a8a-25fd-431c-b73e-14ef8a9e22fc,
aadb822c-142e-4b01-8baa-d5d5bdb8e8c5,
'Guardrail');現在讓我們來看一下它的數據分布是什么樣的。我們將使用 sstable2json 來把原始 sstable 轉儲成一個我們可以分析的格式：
$ sstable2json Metrics/playlists_1/*Data*
[
{
"columns": [
[
"7db1a490-5878-11e2-bcfd-0800200c9a66:",
"",
1436971955597000
],
[
"7db1a490-5878-11e2-bcfd-0800200c9a66:title",
"Ojo Rojo",
1436971955597000
]
],
"key": "62c3609282a13a0093d146196ee77204"
},
{
"columns": [
[
"aadb822c-142e-4b01-8baa-d5d5bdb8e8c5:",
"",
1436971955602000
],
[
"aadb822c-142e-4b01-8baa-d5d5bdb8e8c5:title",
"Guardrail",
1436971955602000
]
],
"key": "444c3a8a25fd431cb73e14ef8a9e22fc"
}
]你可以看到，每一排都存在有兩個列插入，一個列給主關鍵字的元素，第二個列給表中剩下的“title”列。同樣注意到名稱列的名字被加入到每一排的列關鍵字中。這一切說明，列關鍵字賦予的重復副本的數量是合適的，和一個 64 位的列時間標記。
讓我們來比較一下使用壓縮存儲選項的同一個表，再看看同一排的存儲格式看起來是什么樣。
CREATE TABLE playlists_2 ( id uuid, song_id uuid, title text,
PRIMARY KEY (id, song_id )
) WITH COMPACT STORAGE;
INSERT INTO playlists_2 (id, song_id, title)
VALUES (62c36092-82a1-3a00-93d1-46196ee77204,
7db1a490-5878-11e2-bcfd-0800200c9a66,
'Ojo Rojo');
INSERT INTO playlists_2 (id, song_id, title)
VALUES (444c3a8a-25fd-431c-b73e-14ef8a9e22fc,
aadb822c-142e-4b01-8baa-d5d5bdb8e8c5,
'Guardrail');
[
{
"columns": [
[
"7db1a490-5878-11e2-bcfd-0800200c9a66",
"Ojo Rojo",
1436972070334000
]
],
"key": "62c3609282a13a0093d146196ee77204"
},
{
"columns": [
[
"aadb822c-142e-4b01-8baa-d5d5bdb8e8c5",
"Guardrail",
1436972071215000
]
],
"key": "444c3a8a25fd431cb73e14ef8a9e22fc"
}
]和名字所代表的一樣，存儲格式確實更加緊湊了。對同一排現在只有單獨一個列同時這一列并不包括列的字符串名。如果你只看原始表數據這樣會描述不充分，但是你可以結合架構一起來定義余下列的名字。
正如你從原始輸出所看到的一樣，默認的 CQL 格式是更加冗長的。然而，硬盤上的 sstables 是被壓縮過的，所以這個重復列名稱的極端冗長性起什么作用？
為了比較這兩種方式我們建立了兩個表：一個使用默認存儲格式而另一個使用了壓縮存儲。我們的架構和上面的播放列表相似：一個行關鍵字，在列關鍵字中有 2-3 個列，和單獨一個值列。在幾天時間內我們推入分段工作負載通過它--每次對兩個表寫入相同的行。下面是兩個 sstables 中每一個的存儲載入圖表：
http://wiki.jikexueyuan.com/project/wiki-journal-201507-1/images/cassandra-compact-storage02.png" alt="02" />
結果告訴我們，對我們的測試用例，無壓縮存儲將多需要大約 35% 的存儲空間（并且任何額外的處理都需要如此）。這樣就清楚地知道了在我們寫入的數據卷當中，非壓縮存儲中 35% 的存儲是沒有被有效利用正常工作的。那么那里為什么會有一個選項？
一件需要注意的事情是我們沒有將數據列壓成行。我們的數據模式始終在用一個整體作為存儲物（最初是 JSON，現在是 ProtoBuf），支持在不調整 Cassandra 架構的條件下增加/移除列的操作。如果我們向 Cassandra 架構中擴展列，存儲空間的增加將會變的非常大，因為每個增加的列將會重復列關鍵字和時間標記字段。
自然而然有人會問既然和無壓縮存儲方式相比如此節(jié)約成本，為什么不一直使用壓縮存儲。回答是有一些情況下并不能使用壓縮存儲。
如下所示，您不可以越過主關鍵字創(chuàng)建一個以上的列。因為我們看到壓縮存儲在存儲模式中生成了一個列，您被單一行關鍵字，單一列關鍵字（作為多列組成部分）和單一列數據值的限制所攔住了。
cqlsh:Metrics> CREATE TABLE playlists_3 ( id uuid, song_id uuid,
... title text, artist text,
... PRIMARY KEY (id, song_id )
... ) WITH COMPACT STORAGE;
Bad Request: COMPACT STORAGE with composite PRIMARY KEY allows no more than one column not part of the PRIMARY KEY (got: title, artist)如果在你的數據模式中需要更多的列值，你有兩個選擇：不使用壓縮存儲，或者將他們序列化成單一列數據值，比如 Json，ProtoBuf，Avro 等。在那樣的數據模式下更新列將不得不從一側采取操作并必須在你的操作中不可分?？紤]到你將不能利用 Cassandra 的輕量級交易進行更新這一點是非常重要的。對我們自己的測試用例來說，我們使用了 Json 和 ProtoBuf 數據團，因為我們的數據模式是只添加的。
和之前那一點類似，一個由壓縮存儲構建的表在它被創(chuàng)建之后不能變動。舉個例子，使用壓縮存儲時你不能對一個表增加或者移除列：
cqlsh:Metrics> alter table playlists_1 DROP title;
cqlsh:Metrics> alter table playlists_2 DROP title;
Bad Request: Cannot drop columns from a COMPACT STORAGE table
cqlsh:Metrics> alter table playlists_1 ADD artist text;
cqlsh:Metrics> alter table playlists_2 ADD artist text;
Bad Request: Cannot add new column to a COMPACT STORAGE table這意味著，你同樣不能為新增列創(chuàng)建索引。比如，我們不能新增一個藝術家列，也不能以藝術家名字索引歌曲。
我們的 Cassandra 主要用例是打的時間序列數據集存儲。我們必須為了最大硬盤效率作優(yōu)化，因為我們的存數載入和成本是和設備服務的使用直接成比例的。額外多出的 35% 存儲的意義是重大的。
時間序列數據是只添加的并且在一些識別的 TTL 后頻繁地取出系統(tǒng)的。通常在時間序列數據被寫入后再修改它是不現實的，所以對數據格式的任何改變都必須以對新數據的新增補丁形式完成。我們使用描述性的序列化格式例如 JSON 或者 ProtoBufs 來定義數據列支持隨時對它們修改。一個架構改變只能被應用到新數據點，而我們可以繼續(xù)支持老的架構格式直到原來的數據完全被取出。
如果存儲效率并不是你的首要考慮因素，那么架構靈活性和非壓縮表提供的交易處理的升級可以讓應用發(fā)展更容易，考慮下你如何構架可以隨時改變和你是否以后想要添加移除列或者建立額外索引的靈活性。
感謝 Opsmatic 的 Mikhail Panchenko 審閱文章早期版本。
如果你喜歡這篇文章想要加入 Cassandra， 來和我們工作！
更多IT技術干貨: wiki.jikexueyuan.com
加入極客星球翻譯團隊: http://wiki.jikexueyuan.com/project/wiki-editors-guidelines/translators.html版權聲明：
本譯文僅用于學習和交流目的。非商業(yè)轉載請注明譯者、出處，并保留文章在極客學院的完整鏈接
商業(yè)合作請聯系 wiki@jikexueyuan.com
原文地址：http://blog.librato.com/posts/cassandra-compact-storage?utm_campaign=social-blog-posts&utm_content=cassandra-compact-storage&utm_medium=social&utm_source=hackernews
掃碼關注鍍金池微信號
手機訂課，優(yōu)惠多多