跳至內容
主選單
主選單
移至側邊欄
隱藏
導覽
首頁
近期變更
隨機頁面
MediaWiki說明
Taiwan Tongues 台語維基
搜尋
搜尋
外觀
建立帳號
登入
個人工具
建立帳號
登入
檢視 Cassandra 的原始碼
頁面
討論
臺灣正體
閱讀
檢視原始碼
檢視歷史
工具
工具
移至側邊欄
隱藏
操作
閱讀
檢視原始碼
檢視歷史
一般
連結至此的頁面
相關變更
特殊頁面
頁面資訊
外觀
移至側邊欄
隱藏
←
Cassandra
由於以下原因,您無權編輯此頁面:
您請求的操作只有這些群組的使用者能使用:
使用者
、taigi-reviewer、apibot
您可以檢視並複製此頁面的原始碼。
'''Apache Cassandra'''(社群內一般簡稱做 C \ *)是一套開源分散式 NoSQL 資料庫系統。伊上初由 Facebook 開發,用佇改善電子郵件系統的搜揣效能的簡單格式資料,集 Google BigTable 的資料模型佮 Amazon Dynamo 的完全分散式架構佇一身。Facebook 佇咧二千空八將 Cassandra 開源,此後,因為 Cassandra 真好的可能愛延伸性佮效能,予被 Apple , Comcast , Instagram , Spotify , eBay , Rackspace , Netflix 等知名網站所採用,成做一種流行的分散式結構化資料儲存方案。 佇資料庫排行榜「DB-Engines Ranking」中,Cassandra 排佇第十位,是毋是關聯型的資料庫中排名第四懸。 ==歷史== Cassandra 的名稱來源於希臘神話,是特洛伊的一位悲劇性的女先知的名,所以專案的 Logo 是一蕊放光的目睭。 這个案因為就是職於 Facebook 的 Avinash Lakshman(嘛是啦 Amazon Dynamo 的作者之一)和 Prashant Malik 咧為 Facebook 的 Inbox 編寫。二空空八年,Facebook 共專案開源,Cassandra 佇二空空九年就成做 Apache 軟體基金會的 Incubator 專案,並且二空一空年二月行出孵化器,成做是正式的基金會專案。目前這个專案主要是專門咧行 Cassandra 商業化運作的 DataStax 公司來開發,嘛有一寡來自其他的公司抑是獨立的開發者。 ===主要版本佮主要改進=== * 空七六,二空一空年四月發布,支援內起的緊取。 * 空九七,二空一一年一月發佈,支援揤欄建二級索引 ( secondary indexes ) 佮線頂修改表的結構定義 * 空九八,二空一一年六月發布,支援 CQL 語言佮零停機的線頂升級 * 一垺零,二空一一年十月發布,支援資料壓縮,level compaction 佮提高讀取效能 * 一孵一,二空一二年四月發佈,支援 ssd 佮機械硬碟混合使用 * 一孵二,二空一三年一月發布,支援虛擬節點 ( 一个機器佇咧一致性雜鬥環中擁有多個節點 )、原子性的批次來處理 * 二孵空,二空一三年九月發布,支援輕量級事務、建築、改進 compaction 效能,強制使用 Java 七 * 二嬸一,二空一四年九月十號發布 * 二嬸二 , 二空一五年七月二十發布 * 三-c零 , 二空一五年十一月十一日發布 * 三孵一 , 仝款三更一空版本,使用類 tick-tock 發佈模式,逐個月發布一遍,雙數編號版本提供新功能佮錯誤修正,奇數編號版本干焦包括錯誤修正。 * 三孵一一,二空一七年六月二三號發布,成做穩定的三更加一一版本系欄,修復著頂懸一个 tick-tock 功能版本的錯誤。 ==資料模型== Cassandra 使用矣 Google 設計的 BigTable 的資料模型,佮面向列 ( row ) 的傳統的關聯型資料庫抑是加減有的 key-value 資料庫無仝,Cassandra 使用的是闊欄儲存模型 ( Wide Column Stores ),每列的資料由 row key 唯一標識了後,會當有上濟二十億的欄,彼每一个欄有一个 column key 標識,彼每一个 column key 下對應如果干 value。這款模型會當理解為是一个二維的 key-value 儲存,即整個資料模型予定義成一个類似 map < key 一 , map < key 二 , value > > 的類型。 舊版的乎 Cassandra 佮客戶捀互動的方法是通過 thrift,這馬目前新版本的 Cassandra 採用佮 SQL 語言類似的 CQL 語言來實現資料模型的定義佮資料的讀寫。其中 BigTable 中的欄族 ( Column Family ) 佇咧 Cassandra 予人號做類似關聯型資料庫內底的稱呼—— 表 ( table ),而且 Cassandra / BigTable 中的 row key 和 column key 並講是主鍵 ( primary key )。 Cassandra 的 row key 決定矣該列資料儲存佇佗一寡節點內底,所以 row key 需要插雜鬥來儉,袂當順序的掃描抑是讀取,啊若一个 row 內的 column key 是順序儉的,會當進行順序的掃描抑是範圍來走揣。 ==儲存模型== 佮 BigTable 佮其模仿者 HBase 無仝,Cassandra 的資料並無儲存佇分散式檔案系統如 GFS 抑是 HDFS 中,是直接存在本地。佮 BigTable 仝款,Cassandra 嘛是紀錄檔型的資料庫,就共新寫入去的資料儲存佇記持體的 Memtable 中並通過磁碟中的 CommitLog 來做維持久化,記持體填滿了後將資料按照 key 的順序寫入去一个唯讀檔案 SSTable 中,逐改讀資料的時陣將所有 SSTable 佮記憶體內底的資料進行走揣佮合併。這種系統的特點是寫入比讀閣較緊,因為寫入一條資料是順序的計入 commit log 中,毋免隨機讀取吸碟以及搜揣。 ==分散式架構== Cassandra 的系統架構佮 Dynamo 類似,是因為一致性雜鬥的完全 P 二 P 架構,逐列的資料通過雜鬥來決定應該存在佗一个抑是佗一寡節點中。密密無 master 的概念,所有的所在攏是仝款的角色,徹底避免規个系統的單點問題致使的無穩定性,密集間的狀態仝步通過 Gossip 協定來進行 P 二 P 的通批。每一个節點攏共資料儉佇咧本地,每一个節點攏接受來自客戶捀的請求。逐改客戶五隨機選擇密集中的一个節點來請求資料,對應接受請求的截點會對應的 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 設為三,W 和 R 設為 QUORUM,即「過半數」——佇咧 N 為三時 QUORUM 是二。 ==支援的操作== Cassandra 支援對一欄資料進行 insert、update、抑是 delete 操作。其中 insert 和 update 雖然語法略仔區別,毋過語意上等價,即會當針對已經存在的列進行 update 抑是 insert 一个不存在的列。 ===輕量級事務=== 毋知影二鋪空版開始,Cassandra 支援輕量級事務。這款事務予人號做「compare-and-set」,簡稱 CAS。通過 paxos 演算法實現此時滿足某條件了後才修改資料若無修改。目前支援 " insert if not exist "、" update if col=value "、" delete if exist " 等等幾款的操作。 ==資料類型== Cassandra 佇咧 CQL 語言層面支援真濟種資料類型。 ==猶閣有類似開源系統較== ===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。 ==參考文獻== ==相關閱讀== [[分類: 待校正]]
返回到「
Cassandra
」。