本頁使用了標題或全文手工轉換

Cassandra

維基百科,自由的百科全書
前往: 導覽搜尋
Cassandra
Cassandra logo.svg
開發者 Apache軟體基金會
初始版本 2008
穩定版本 3.10(2017年2月3日 (2017-02-03)
開發狀態 Active
程式語言 Java
作業系統 跨平台
類型 資料庫
許可協定 Apache許可證 2.0
網站 cassandra.apache.org

Apache Cassandra(社群內一般簡稱為C*)是一套開源分散式NoSQL資料庫系統。它最初由Facebook開發,用於儲存收件箱等簡單格式資料,集Google BigTable的資料模型與Amazon Dynamo的完全分散式架構於一身。Facebook於2008將 Cassandra 開源,此後,由於Cassandra良好的可延伸性和效能,被 Apple[1], Comcast[2],Instagram[3], Spotify[4], eBay[5], Rackspace[6], Netflix[7]等知名網站所採用,成為了一種流行的分散式結構化資料儲存方案。

在資料庫排行榜「DB-Engines Ranking」中,Cassandra排在第七位,是非關聯型資料庫中排名第二高的(僅次於MongoDB[8]

歷史[編輯]

Cassandra 的名稱來源於希臘神話,是特洛伊的一位悲劇性的女先知的名字,因此專案的Logo是一隻放光的眼睛。

這個專案由就職於Facebook的Avinash Lakshman(也是Amazon Dynamo英語Amazon_DynamoDB的作者之一)和Prashant Malik在為Facebook的Inbox編寫。2008年,Facebook將專案開源,Cassandra在2009年成為了Apache軟體基金會的Incubator專案,並在2010年2月走出孵化器,成為正式的基金會專案。目前這個專案主要由專門進行Cassandra商業化運作的DataStax公司來開發,也有一些來自其他公司或獨立的開發者[9]

主要版本和主要改進[10][編輯]

  • 0.6,2010年4月發布,支援內建的快取。
  • 0.7,2011年1月發布,支援按列建二級索引(secondary indexes)及線上修改表的結構定義
  • 0.8,2011年6月發布,支援CQL語言和零停機的線上升級
  • 1.0,2011年10月發布,支援資料壓縮,level compaction和提高讀取效能
  • 1.1,2012年4月發布,支援ssd和機械硬碟混合使用
  • 1.2,2013年1月發布,支援虛擬節點(一個機器在一致性雜湊環中擁有多個節點)、原子性的批次處理
  • 2.0,2013年9月發布,支援輕量級事務、觸發器、改進compaction效能,強制使用Java7
  • 2.1,即將發布,顯著提高讀寫效能
  • 3.0,未來發布,支援在集群中執行用戶定義的函式,支援所有能在JVM上執行的語言

資料模型[編輯]

Cassandra使用了Google 設計的 BigTable的資料模型,與面向行(row)的傳統的關聯型資料庫鍵值儲存的key-value資料庫不同,Cassandra使用的是寬列儲存模型(Wide Column Stores)[8],每行資料由row key唯一標識之後,可以有最多20億個列[11],每個列由一個column key標識,每個column key下對應若干value。這種模型可以理解為是一個二維的key-value儲存,即整個資料模型被定義成一個類似map<key1, map<key2,value>>的類型。

舊版的Cassandra與用戶端互動的方法是通過thrift,而目前新版本的Cassandra採用與SQL語言類似的CQL語言[12]來實現資料模型的定義和資料的讀寫。其中BigTable中的列族(Column Family)在Cassandra中被稱作類似關聯型資料庫中的稱呼——表(table),而Cassandra/BigTable中的row key和column key並稱為主鍵(primary key)。[13]

Cassandra的row key決定了該行資料儲存在哪些節點中,因此row key需要按雜湊來儲存,不能順序的掃描或讀取,而一個row內的column key是順序儲存的,可以進行有序的掃描或範圍尋找[13]

儲存模型[編輯]

與BigTable和其模仿者HBase不同,Cassandra的資料並不儲存在分散式檔案系統如GFSHDFS中,而是直接存於本地。與BigTable一樣,Cassandra也是記錄檔型資料庫,即把新寫入的資料儲存在記憶體的Memtable中並通過磁碟中的CommitLog來做持久化,記憶體填滿後將資料按照key的順序寫進一個唯讀檔案SSTable中,每次讀取資料時將所有SSTable和記憶體中的資料進行尋找和合併[14][15]。這種系統的特點是寫入比讀取更快[16],因為寫入一條資料是順序計入commit log中,不需要隨機讀取磁碟以及搜尋。

分散式架構[編輯]

Cassandra的系統架構與Dynamo類似,是基於一致性雜湊的完全P2P架構,每行資料通過雜湊來決定應該存在哪個或哪些節點中[17]。集群沒有master的概念,所有節點都是同樣的角色,徹底避免了整個系統的單點問題導致的不穩定性,集群間的狀態同步通過Gossip協定來進行P2P的通訊。每個節點都把資料儲存在本地,每個節點都接受來自用戶端的請求。每次用戶端隨機選擇集群中的一個節點來請求資料,對應接受請求的節點將對應的key在一致性雜湊的環上定位是哪些節點應該儲存這個資料,將請求轉發到對應的節點上,並將對應若干節點的查詢反饋返回給用戶端。

在一致性、可用性和分割耐受能力(CAP)的折衷問題上,Cassandra和Dynamo一樣比較靈活。Cassandra的每個keyspace可配置一行資料會寫入多少個節點(設這個數為N),來保證資料不因為機器宕機或磁碟損壞而遺失資料,即保證了CAP中的P。用戶在讀寫資料時可以指定要求成功寫到多少個節點才算寫入成功(設為W),以及成功從多少個節點讀取到了資料才算成功(設為R)。可推理得出,當W+R>N時,讀到的資料一定是上一次寫入的,即維護了強一致性,確保了CAP中的C。當W+R<=N時,資料是最終一致性因為存在一段時間可能讀到的並不是最新版的資料。當W=N或R=N時,意味著系統只要有一個節點無回應或宕機,就有一部分資料無法成功寫或者讀,即失去了CAP中的可用性A。因此,大多數系統中,都將N設為3,W和R設為QUORUM,即「過半數」——在N為3時QUORUM是2。

支援的操作[編輯]

Cassandra支援對一列資料進行insert、update、或delete操作。其中insert和update雖然語法略有區別,但語意上等價,即可以針對已經存在的行進行update或insert一個不存在的行。

輕量級事務[編輯]

從2.0版開始,Cassandra支援輕量級事務。這種事務被稱為「compare-and-set」,簡稱CAS。通過paxos演算法實現在滿足某條件後才修改資料否則不修改。目前支援"insert if not exist"、"update if col=value"、"delete if exist"等幾種操作。

資料類型[編輯]

Cassandra在CQL語言層面支援多種資料類型[18]

CQL類型 對應Java類別型 描述
ascii String ascii字串
bigint long 64位元整數
blob ByteBuffer/byte[] 二進位陣列
boolean boolean 布林
counter long 計數器,支援原子性的增減,不支援直接賦值
decimal BigDecimal 高精度小數
double double 64位元浮點數
float float 32位元浮點數
inet InetAddress ipv4ipv6協定的ip位址
int int 32位元整數
list List 有序的列表
map Map 鍵值對
set Set 集合
text String utf-8編碼的字串
timestamp Date 日期
uuid UUID UUID類型
timeuuid UUID 時間相關的UUID
varchar string text的別名
varint BigInteger 高精度整型

與類似開源系統的比較[編輯]

Apache HBase[編輯]

HBase是Apache Hadoop專案的一個子專案,是Google BigTable的一個克隆,與Cassandra一樣,它們都使用了BigTable的列族式的資料模型,但是:

  • Cassandra只有一種節點,而HBase有多種不同角色,除了處理讀寫請求的region server之外,其架構在一套完整的HDFS分散式檔案系統之上,並需要ZooKeeper來同步集群狀態,部署上Cassandra更簡單。
  • Cassandra的資料一致性策略是可配置的,可選擇是強一致性還是效能更高的最終一致性;而HBase總是強一致性的。
  • Cassandra通過一致性雜湊來決定一行資料儲存在哪些節點,靠機率上的平均來實現負載均衡;而HBase每段資料(region)只有一個節點負責處理,由master來動態分配一個region是否大到需要拆分成兩個,同時會將過熱的節點上的一些region動態的分配給負載較低的節點,因此實現動態的負載均衡。
  • 因為每個region同時只能有一個節點處理,一旦這個節點無回應,在系統將這個節點的所有region轉移到其他節點之前這些資料便無法讀寫,加上master也只有一個節點,備用master的取消復原也需要時間,因此HBase在一定程度上有單點問題;而Cassandra無單點問題。
  • Cassandra的讀寫效能優於HBase[16]

參考文獻[編輯]

相關閱讀[編輯]