Cassandra The Definitive Guide 這本書的一些閱讀筆記…跟其他學習的紀錄

The Definitive Guide

1. Introducing Cassandra

1.1 關聯式資料庫出了什麼問題？

沒有問題…馬、車、飛機在現代都有存在的必要，只是需求的不同而已，所以非關聯資料庫也是為了處理現今大量成長的資料而產生的。

關聯式資料庫在維持一致性時，需要透過「transactions」來鎖定資料表，當負載很重時用戶全都要等待自己的回合…才能讀寫資料，是有很多解決辦法可以用關聯式資料庫解決啦～只是有沒有錢勒。

沒有打算說服你使用非關聯式資料庫，而是考慮你現有專案的需求，是否需要導入大量的資料，來考慮應用進去某部份來改善你的專案，並試著迎向未來資料爆炸的時代。

1.2 回顧關聯式資料庫

為什麼 RDBMS 會如此流行四十年，由許多因素造成，

• 結構化查詢語言(SQL)：易用易學，功能強大；資料查詢(DML)、結構定義(DDL)、權限管理。
• 易於調整，容易應用專案不斷的的變化。
• …

ACID Atomic, Consistent, Isolated, Durable

交易 (Transactions) 造成關聯式資料庫嚴重的負載..

中間快速跳過…=_=歡迎來到第三章

3 The Cassandra Data Model

儲存資料的單位是 name => value 這樣叫做一個 column，

有時我們會想要好幾個 column 為一組，例如一個人就會有姓名、電話、住址等 columns，這樣就稱為 rows，

又可以稱為 column  family，就像關聯式資料庫的一個資料表一樣。

例如：

透過 CloumnFamily + RowKey 形成了類似關聯式資料庫的  Primary key，而有些 ColumnName 則可以 可有可無的方式呈現，

事實上”每一個 column” 還帶有一個時間戳記 (timestamp)，由伺服器暗中紀錄該欄位最後更新時間。

下圖是描述資料模型上最後的一張圖，感覺是代表每個欄位都可以存好幾個欄位，透過這樣階層式的設計，存放資料也可以如關聯式資料一樣有彈性。

我想像這裡的一個 Row 可能是一個帳號，而一個帳號可以分成很多種資訊，聯絡方式、個人資料、就學紀錄等等…這些資訊內都還有很多項次的紀錄。

就如同關聯式資料庫會將這些資訊分為資料表再透過 join 的方式結合，而這裡設計就是希望儘量設計成一個表，不斷的擴充欄位這樣，而分組就是希望能有類似資料表的語意。

所以實際的差距還是在關聯式資料庫 1 to n 、 m to n 的概念在這似乎沒有對應的概念。

keyspaces 在這邊書上描述的比較抽象一點沒實際使用過可能也不曉得在講什麼，似乎類似是名稱空間的一個範圍，

你有一個應用程式要建立，對應會有很多資料要儲存，而非關聯的資料儲存會有一些參數，包含了副本數量、副本放置策略、欄位組 等等的參數，

而 keyspaces 就是一組參數的單位，我這個應用成是有一個 keyspaces 裡面就包含了數個設定好的參數，就像是一組資料群的代號(名字 , database)一般。

Column Families 就比較像是 keyspaces 裡面有很多的 column families(table)，為什麼這樣說呢？因為在這裡欄位是不需要定義的，但是Column Families 可以被定義，所以就像是資料表該被取名字一樣～而他不像 table 的因素則是因為一個 Column Families 會切割存放在不同的檔案裡面(應該是為了分散讀取)，而資料表則不是。

如果你想要儲存巢狀的資料，應該要用 super column family 而不是 Column Families。

一個存放的例子～
Hotel {
key: AZC_043 { name: Cambria Suites Hayden, phone: 480-444-4444,address: 400 N. Hayden Rd., city: Scottsdale, state: AZ, zip: 85255}
key: AZS_011 { name: Clarion Scottsdale Peak, phone: 480-333-3333,address: 3000 N. Scottsdale Rd, city: Scottsdale, state: AZ, zip: 85255}
}
Hotel 是一個 columns families 就像一個 table，而 下面的 AZX_000 是 row key(PK)，內部的欄位則是 columns

查詢的語法是

cassandra> get Hotelier.Hotel[‘NYN_042’]

這邊看起來 Hotelier 是 keyspaces ，只是這樣看起來是不是蠻像 關聯式資料庫查一列資料的樣子呢，因為會傳回一列的數個欄位～

其實這樣的查詢模式蠻符合我近期在寫 PHP 的一個固定模式，將資料查回放至 hash table，如果搭配關聯式資料庫先把清單查出來，再查詢列的資料可能會有更佳的效率。

如果要篩選某種條件，例如地區，可能要另外建一個地區與 Hotel 的關聯表會比較快喔～類似 hash table …的概念。

另外一個 super column 的例子，主要功能就是一個可以存放很多筆資料的 column。

User {
key: mlwmlw {
name : 喵喵,phone : { home : 12345678 , company : 22345678 }
}}

這樣就能透過以下來取得 super column 的資料

cassandra > getHotelier.User[‘mlwmlw’][phone][home]

Chapter 5 architecture：

Systm KeySpace

系統內含有一個稱為 System 的 Keyspace ，用來存放系統結構，節點資訊等資料，就類似 mysql 的 information_schema 資料表類似

Peer to Peer

不像 HBase 一樣有一個主節點，Cassandra 是採用非集中式的分散式系統，每一台節點的重要性都一致，且採用 p2p 實作並採用 gossip 自動偵測與確認其他節點的存活與資訊，讓他加入一個節點，採用這種架構讓 新節點的加入格外容易。

Bloom Filter

查詢資料的方式透過 hash table 與二進位比較來實作資料是否位於集合內，從wiki[8]內的圖來看，似乎會先經過 hash filter 過濾器確定資料是否存在記憶體，不存在的話在去 硬碟 裡面要，來加快速度～

Anti-Entropy and Read Repair

Memtables, SSTables, Compaction

一開始資料都會寫存取至記憶體，直到記憶體容納不下就會寫到檔案，分別對應到兩個資料格式Memtables 與 SSTables ，而當 SSTables 過多時 ，則會透過壓縮將數個 SSTable 壓縮成一個，來提高存取資料的速度。

Tombstones

Staged Event-Driven Architecture (SEDA)

每種操作都分成不同的 stage ，每個 stage 都分不同的 thread 來執行，並透過事件導向的機制運作，每個階段與階段間透過事件的方式進行通訊，所以每個階段分別實作他的 handler 可以讓設計變得較簡單，且各階段的運作透過 thread pool 來避免執行緒在伺服器壓力成長時較不會炸掉。達到控伺服器上各種有限的資源儘可能利用。[9]

其他：

限制(http://wiki.apache.org/cassandra/CassandraLimitations)：

• 由於採用 Thrift 作為公開的存取介面 而  Thrift 上無支援串流傳輸，所以對大檔案的傳輸十分有限。
• 一個欄位最多不能超過 2G 的空間
• Cassandra  資料模型有分成 Column Family , Super Column ，而原先無支援 SuperColumn 層級的索引，而這個問題似乎已經在新版被處理了 (https://issues.apache.org/jira/browse/CASSANDRA-674)

節點同步策略(Goosip)

節點新增刪除修改恢復，如果有節點當機，短時間內恢復則可與其他節點重新同步資料，如節點當機過久，則要當成新增節點。。。這樣假設資料很大的話不就炸掉了嗎…重傳一次？

參考資料：

1. cassandra 維運之道 http://www.slideshare.net/NinGoo/cassandra-v02
2. cassandra 論文 http://www.cs.cornell.edu/projects/ladis2009/papers/lakshman-ladis2009.pdf
3. bigtable 論文 http://www.eecs.harvard.edu/~mdw/papers/seda-sosp01.pdf
4. Amazon Dynamo 論文 http://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf
5. SEDA 架構 http://www.eecs.harvard.edu/~mdw/papers/seda-sosp01.pdf
6. play with cassandra http://blog.octo.com/en/nosql-lets-play-with-cassandra-part-13/
7. DataStax 的文件 http://www.datastax.com/dev/tutorials/getting_started_0_7/index
8. http://en.wikipedia.org/wiki/Bloom_filter
9. seda 簡介 http://speed847.javaeye.com/blog/459040 http://blog.csdn.net/pennyliang/archive/2010/10/15/5943534.aspx
10. 整理的不錯的 wiki 瘋人院