本文簡(jiǎn)單介紹了 Cassandra 上時(shí)間序列的存儲(chǔ)，引入了壓縮存儲(chǔ)的概念并將壓縮存儲(chǔ)和非壓縮存儲(chǔ)方式用簡(jiǎn)單的例子進(jìn)行了對(duì)比，得出了非壓縮存儲(chǔ)會(huì)消耗更多的存儲(chǔ)空間的結(jié)論。文章同時(shí)提到不同的需求和條件下應(yīng)該考慮選擇不同的存儲(chǔ)格式。

文章內(nèi)容

在 Librato，我們對(duì)時(shí)間序列的儲(chǔ)存主要是應(yīng)用我們一直在研發(fā)的自定義架構(gòu)所建立的 Apache Cassandra。關(guān)于它我們之前已經(jīng)寫到并呈現(xiàn)過(guò)幾次。在 Cassandra 上我們既存儲(chǔ)真實(shí)的時(shí)間序列也存儲(chǔ)歷史匯總時(shí)間序列。Cassandra 存儲(chǔ)節(jié)點(diǎn)在我們的基礎(chǔ)設(shè)施中占有最大的足跡，因而這些節(jié)點(diǎn)驅(qū)動(dòng)著我們的成本開(kāi)支，所以我們一直在尋找方式來(lái)改進(jìn)我們數(shù)據(jù)的效率。

作為我們正在進(jìn)行的效率改進(jìn)和后臺(tái)功能研發(fā)的部分，我們最近花時(shí)間重新評(píng)估了我們的存儲(chǔ)架構(gòu)。自 Cassandra 0.8.x 版本的早些時(shí)候以來(lái)，我們的架構(gòu)一直被建立在 Thrift APIs 的內(nèi)容之上，并且無(wú)論何時(shí)當(dāng)我們豎起一個(gè)新環(huán)路，我們使用‘節(jié)點(diǎn)工具’命令來(lái)移動(dòng)它。我們一直都在緊密的跟隨 CQL 的發(fā)展并且已經(jīng)將我們的讀取路徑的部分在 2.0.x 版本中移動(dòng)到了新的本地接口。甚至，我們想要更進(jìn)一步關(guān)注使用本地 CQL 接口完全構(gòu)造我們的架構(gòu)轉(zhuǎn)移（創(chuàng)建 CQL 表，或者他們所稱的“列族”）。

CQL 表存儲(chǔ)選項(xiàng)

先前當(dāng)我們關(guān)注 CQL 表結(jié)構(gòu)時(shí)困住我們的事情之一是涉及到一個(gè) COMPACT STORAGE 選項(xiàng)--我將停止吐槽并且從這之后把它稱作為壓縮存儲(chǔ)。其定義文檔如下：

“…主要將對(duì) CQL3 之前創(chuàng)建的定義的反向兼容性為目標(biāo)...在硬盤上提供一個(gè)更壓縮緊湊一些的數(shù)據(jù)分布，但這樣是以減小靈活性和拓展性為代價(jià)的…由于以上原因是不推薦向后兼容性之外使用的?！?

在 CQL 之前當(dāng) Thrift 接口是唯一的 API 時(shí)，所有的表都是以壓縮存儲(chǔ)的方式建立的。和文檔狀態(tài)一樣，它是一個(gè)除了向后兼容性外別無(wú)它用的遺留選項(xiàng)。

在我們的調(diào)研大約進(jìn)行到這個(gè)時(shí)候我們偶然發(fā)現(xiàn)了某團(tuán)隊(duì)研究解析的一篇博客文章。主要是關(guān)于他們對(duì) CQL 表的經(jīng)驗(yàn)認(rèn)識(shí)。這是一篇很棒的文章，我十分推薦它。文章有一段的標(biāo)題是 “我們沒(méi)有使用 COMPACT STORAGE…你敢相信下面發(fā)生了什么嗎”。它記錄了使用壓縮存儲(chǔ)的他們自己的調(diào)研。在這篇文章中，他們提及了當(dāng)沒(méi)有對(duì)表使用壓縮存儲(chǔ)時(shí)他們看到一個(gè)大 30 倍的存儲(chǔ)空間容量。如果知道我們所處理的數(shù)據(jù)庫(kù)的容量大小，這種類型的增大是不可忽視的。

CQL 數(shù)據(jù)分布

那么讓我們研究一下一個(gè) CQL 表的數(shù)據(jù)分布是什么樣的。我們將以一個(gè)簡(jiǎn)化過(guò)的例子開(kāi)始，它來(lái)自用 Cassandra 建立一項(xiàng)音樂(lè)服務(wù)的教程指南。我們已經(jīng)用一個(gè)（id，song_id）的指針把表減少到只有一個(gè) id，音樂(lè) 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');

現(xiàn)在讓我們來(lái)看一下它的數(shù)據(jù)分布是什么樣的。我們將使用 sstable2json 來(lái)把原始 sstable 轉(zhuǎn)儲(chǔ)成一個(gè)我們可以分析的格式：

$ 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"
    }
]

你可以看到，每一排都存在有兩個(gè)列插入，一個(gè)列給主關(guān)鍵字的元素，第二個(gè)列給表中剩下的“title”列。同樣注意到名稱列的名字被加入到每一排的列關(guān)鍵字中。這一切說(shuō)明，列關(guān)鍵字賦予的重復(fù)副本的數(shù)量是合適的，和一個(gè) 64 位的列時(shí)間標(biāo)記。

使用壓縮存儲(chǔ)的同一個(gè)表分布

讓我們來(lái)比較一下使用壓縮存儲(chǔ)選項(xiàng)的同一個(gè)表，再看看同一排的存儲(chǔ)格式看起來(lái)是什么樣。

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"
    }
]

和名字所代表的一樣，存儲(chǔ)格式確實(shí)更加緊湊了。對(duì)同一排現(xiàn)在只有單獨(dú)一個(gè)列同時(shí)這一列并不包括列的字符串名。如果你只看原始表數(shù)據(jù)這樣會(huì)描述不充分，但是你可以結(jié)合架構(gòu)一起來(lái)定義余下列的名字。

從長(zhǎng)遠(yuǎn)看這會(huì)是什么樣的？

正如你從原始輸出所看到的一樣，默認(rèn)的 CQL 格式是更加冗長(zhǎng)的。然而，硬盤上的 sstables 是被壓縮過(guò)的，所以這個(gè)重復(fù)列名稱的極端冗長(zhǎng)性起什么作用？

為了比較這兩種方式我們建立了兩個(gè)表：一個(gè)使用默認(rèn)存儲(chǔ)格式而另一個(gè)使用了壓縮存儲(chǔ)。我們的架構(gòu)和上面的播放列表相似：一個(gè)行關(guān)鍵字，在列關(guān)鍵字中有 2-3 個(gè)列，和單獨(dú)一個(gè)值列。在幾天時(shí)間內(nèi)我們推入分段工作負(fù)載通過(guò)它--每次對(duì)兩個(gè)表寫入相同的行。下面是兩個(gè) sstables 中每一個(gè)的存儲(chǔ)載入圖表：

http://wiki.jikexueyuan.com/project/wiki-journal-201507-1/images/cassandra-compact-storage02.png" alt="02" />

結(jié)果告訴我們，對(duì)我們的測(cè)試用例，無(wú)壓縮存儲(chǔ)將多需要大約 35% 的存儲(chǔ)空間（并且任何額外的處理都需要如此）。這樣就清楚地知道了在我們寫入的數(shù)據(jù)卷當(dāng)中，非壓縮存儲(chǔ)中 35% 的存儲(chǔ)是沒(méi)有被有效利用正常工作的。那么那里為什么會(huì)有一個(gè)選項(xiàng)？

一件需要注意的事情是我們沒(méi)有將數(shù)據(jù)列壓成行。我們的數(shù)據(jù)模式始終在用一個(gè)整體作為存儲(chǔ)物（最初是 JSON，現(xiàn)在是 ProtoBuf），支持在不調(diào)整 Cassandra 架構(gòu)的條件下增加/移除列的操作。如果我們向 Cassandra 架構(gòu)中擴(kuò)展列，存儲(chǔ)空間的增加將會(huì)變的非常大，因?yàn)槊總€(gè)增加的列將會(huì)重復(fù)列關(guān)鍵字和時(shí)間標(biāo)記字段。

為什么不一直用壓縮存儲(chǔ)呢？

自然而然有人會(huì)問(wèn)既然和無(wú)壓縮存儲(chǔ)方式相比如此節(jié)約成本，為什么不一直使用壓縮存儲(chǔ)?；卮鹗怯幸恍┣闆r下并不能使用壓縮存儲(chǔ)。

額外增加的行列

如下所示，您不可以越過(guò)主關(guān)鍵字創(chuàng)建一個(gè)以上的列。因?yàn)槲覀兛吹綁嚎s存儲(chǔ)在存儲(chǔ)模式中生成了一個(gè)列，您被單一行關(guān)鍵字，單一列關(guān)鍵字（作為多列組成部分）和單一列數(shù)據(jù)值的限制所攔住了。

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)

如果在你的數(shù)據(jù)模式中需要更多的列值，你有兩個(gè)選擇：不使用壓縮存儲(chǔ)，或者將他們序列化成單一列數(shù)據(jù)值，比如 Json，ProtoBuf，Avro 等。在那樣的數(shù)據(jù)模式下更新列將不得不從一側(cè)采取操作并必須在你的操作中不可分?？紤]到你將不能利用 Cassandra 的輕量級(jí)交易進(jìn)行更新這一點(diǎn)是非常重要的。對(duì)我們自己的測(cè)試用例來(lái)說(shuō)，我們使用了 Json 和 ProtoBuf 數(shù)據(jù)團(tuán)，因?yàn)槲覀兊臄?shù)據(jù)模式是只添加的。

架構(gòu)靈活性

和之前那一點(diǎn)類似，一個(gè)由壓縮存儲(chǔ)構(gòu)建的表在它被創(chuàng)建之后不能變動(dòng)。舉個(gè)例子，使用壓縮存儲(chǔ)時(shí)你不能對(duì)一個(gè)表增加或者移除列：

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)建索引。比如，我們不能新增一個(gè)藝術(shù)家列，也不能以藝術(shù)家名字索引歌曲。

結(jié)論

我們的 Cassandra 主要用例是打的時(shí)間序列數(shù)據(jù)集存儲(chǔ)。我們必須為了最大硬盤效率作優(yōu)化，因?yàn)槲覀兊拇鏀?shù)載入和成本是和設(shè)備服務(wù)的使用直接成比例的。額外多出的 35% 存儲(chǔ)的意義是重大的。

時(shí)間序列數(shù)據(jù)是只添加的并且在一些識(shí)別的 TTL 后頻繁地取出系統(tǒng)的。通常在時(shí)間序列數(shù)據(jù)被寫入后再修改它是不現(xiàn)實(shí)的，所以對(duì)數(shù)據(jù)格式的任何改變都必須以對(duì)新數(shù)據(jù)的新增補(bǔ)丁形式完成。我們使用描述性的序列化格式例如 JSON 或者 ProtoBufs 來(lái)定義數(shù)據(jù)列支持隨時(shí)對(duì)它們修改。一個(gè)架構(gòu)改變只能被應(yīng)用到新數(shù)據(jù)點(diǎn)，而我們可以繼續(xù)支持老的架構(gòu)格式直到原來(lái)的數(shù)據(jù)完全被取出。

如果存儲(chǔ)效率并不是你的首要考慮因素，那么架構(gòu)靈活性和非壓縮表提供的交易處理的升級(jí)可以讓應(yīng)用發(fā)展更容易，考慮下你如何構(gòu)架可以隨時(shí)改變和你是否以后想要添加移除列或者建立額外索引的靈活性。

感謝 Opsmatic 的 Mikhail Panchenko 審閱文章早期版本。

如果你喜歡這篇文章想要加入 Cassandra，來(lái)和我們工作！

更多IT技術(shù)干貨: wiki.jikexueyuan.com
加入極客星球翻譯團(tuán)隊(duì): http://wiki.jikexueyuan.com/project/wiki-editors-guidelines/translators.html

版權(quán)聲明：
本譯文僅用于學(xué)習(xí)和交流目的。非商業(yè)轉(zhuǎn)載請(qǐng)注明譯者、出處，并保留文章在極客學(xué)院的完整鏈接
商業(yè)合作請(qǐng)聯(lián)系 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

上一篇：為什么是 Node.js ? 什么時(shí)候使用 Node.js ?下一篇：20 個(gè)有用的 Angular.js 工具

在线观看不卡亚洲电影_亚洲妓女99综合网_91青青青亚洲娱乐在线观看_日韩无码高清综合久久

理解 Cassandra 壓縮儲(chǔ)存的作用

關(guān)于本文