2014-12-16

Understanding The Cassandra Data Model

Comparing the Cassandra Data Model to a Relational Database

  • Keyspace 是一個應用程式資料的容器,類似關聯式資料庫的 database 或 schema。
  • 在 keyspace 內部有很多的 column family, 類似 table。
  • Column family 包含了很多的 columns,而一個 row key 指定了一個 columns 集合。
  • 每一個 row key 所指定的 column 集合,這些 column 可以不同 (與關聯式資料庫不同)。
  • Cassandra 不強制關聯 column families,而它們之間沒有 foreign keys,在 query 資料的時候也不能 join 起來。
  • 以反正規化資料為設計。

About keyspace

  • 一個 cluster 裡會有一個 keyspace 提供給每個應用程式使用。
  • Replication 的控制是以 keyspace 為基礎,若資料有不同複本需求時,應該以不同的 keyspace 為管理。
  • 使用 Data Definition Language (DDL) 命令(CLI 或 CQL) 來定義 keyspace。

About Column Families

  • 在 Cassandra,你定義了 column family,每個 column family 能夠定義 column 的 metadata,但實際上儲存每一筆 row 的時候,會有哪些 columns 則是應用程式決定的,而且每個 row 可以有不一樣的 columns。
  • 雖然 column family 可以有非常大的彈性,實行上,並不是完全的 "schema-less"。每個 column family 都應該被設計成只包含單一資料型態。
  • Column family 的設計模式有兩種類型:static 和 dynamic column family。
  • Static column family
    • 使用一組靜態的欄位名稱,這很像傳統資料庫的 table。
    • 可以預先定義 每個 column 的 metadata。
    • 例如,一個用來儲存 user 的 column family,可能會有欄位:user name, address, email, phone number. 雖然每一個 row 都有相同的 column 集合,但卻不一定在儲存時都要有值。
  • Dynamic column family
    • 預先計算結果集(result sets),並儲存到資料列中以提供高效的資料檢索。
    • 每一筆資料列都是一筆為了滿足搜尋的資料的快照(snapshot),有點像是具體化視觀表 (materialized view)。
    • Dynamic column family 為每個 column 的名稱(name)和值(value) 定義了型態資訊(comparators,validators),而不是去定義每個 column 的 metadata,每個 column 實際的名稱和值,是應用程式在新增欄位時決定的。
  • Row key 是唯一的,用來識別每一筆資料列,類似關聯式資料庫的 primary key (主鍵)。
  • Column family 靠 row key 來達到資料分割 (partition) 的目的,而 row key 也隱含著索引的意味,它不能是空值。


About Columns

  • 在 Cassandra,column 是最小的資料單位,它是由一個名稱(name)、一個值(value)、一個時間戳記(timestamp),所組成的。
  • 如果排序對你來說很重要,那麼你可以自己維護一個索引表,利用這個索引表達成排序的需求。
  • Column 並不一定要有值(可以是空的),允許只存 column name。
  • Cassandra 的每個 column 都有 timestamp,它是用來判斷誰是最新的資料,並且可以被更新。
  • timestamp 是客戶端應用程式所提供的,當多個客戶端同時儲存同一個欄位時,只有最新的那筆資料會被儲存。


About Special Columns (Counter, Expiring, Super)

  • Expiring Columns
    • Column 可以設定過期日 (expiration date),稱為 TTL ( time ot live ),單位是秒。
    • 當有設定 TTL 的 column到期之後,就會被標記為 deleted ( with a tombstone)。
    • 一但欄位被標記為 tombstone, 在 normal compaction (gc_grace_seconds) 以及 repair 的時候就會自動被清除。
    • 可以透過以下兩種方式來設定,
      CLI:
      SET users['bobbyjo'][utf8('coupon_code')] = utf8('SAVE20')
      WITH
      ttl = 864000;
      CQL :
      cqlsh> UPDATE users USING TTL 432000 SET 'password' = 'ch@ngem3a'
      WHERE
      KEY = 'jsmith';
    • 如果你想要重設該 column 的 TTL,那麼就要重新 insert,並指定新的 TTL。
    • 過期日的計算是在主要的 host (接受 insert 操作),但會被其它的 node 所解讀,所以 Server 之間的時間必須要同步,否則會不精準。
  • Counter Columns
    • 用來儲存計數的欄位。
    • Counter column families 必須使用 CounterColumnType 做為 validator,所以 counter 必須被使用在專門的 column family。(目前無法與標準欄位放一起)
    • 它只會做增量 (incrementing) 或減量 (decrementing)的更新。
    • 要更新 counter column,客戶端要指定 counter 名稱和要增加或減少的值。
    • counter 能夠以任何的 consistency level 被讀或寫入。
    • 與一般的欄位不同,當寫入一個 counter 時,會在背景裡有發出一個讀的請求,以確保分散式 counter 的值在複本間保持一致性。
    • Consistency Level ONE 是寫入 counter 最普遍的一致性級別,在這個級別下,所隱含的 read 請求,不會對寫入的延遲造成什麼衝擊。
  • Super Columns
    • Cassandra 的 column family 可以包含 regular columns 或是 super columns。
    • Super column 包含一個 column name 和一個 sub-columns 的 map。
    • Super column 可以指定一個 comparator 給 super column name 和 sub-column names。
    • 類似實例化視圖(materialized view),可以做資料檢索。
  • Data Types (comparators and validators)
    • Column value 或 row key 的 data type,我們稱為 validator。
    • Column name 的 data type,我們稱為 comparator。
    • 在 cassandra 內部,若在建立 column family 的時候沒有指定 data type,預設是以 16 進位的位元陣列 (Bytes type) 來存。
    • Cassandra 提供 validator 和 comparator 使用的 data type 中 CounterColumnType 只能用自在 column value。
    • data type 請查詢:DataStax
  • Validator
    • 使用 key_validation_class property,定義預設的 row key validator 給所有的 column families。
    • CounterColumnType 不能被用在 row key validator。
    • static column family:使用 column_metadata property 來定義 column family 時,你應該要定義每個 column 和它的 data type。
    • dynamic column family:你應該定義一個預設的 validator class:default_validation_class,而不是定義每個 column 的 data type。
    • Key 和 column validators 在之後可以隨意的增加或修改。
  • Comparator
    • Row 和 column 會以 column name 的排序順序來存放。
    • Comparator 指定 column name 的 data type。
    • 當建立 column family 的時候指定了 comparator 後,之後就不能在變更了,這點與 validator 不同。
  • Column Family Compression
    • 每個 column family 都能設定資料壓縮。
    • 壓縮可以讓資料量減少,這樣就可以最大化你的硬碟容量。
    • 壓縮的好處,除了節省磁碟空間,也能減少磁碟的 IO,特別是以讀為主的工作。
    • Cassandra 能夠快速從 SSTable 索引,找到 row 的位置,然後只解壓縮跟那筆 row 有關的資料的 chunk。
    • 壓縮對於寫入的效能而言並沒有負面的影響。事實上,寫到壓縮的 table,效能有 10% 左右的提升。
    • Cassandra 的 SSTable 資料檔案是 immutable 的,所以也就沒有重複壓縮的循環。SSTable 只會被壓縮一次,然後就寫到磁碟了。
    • 壓縮能夠帶來以下的好處,依不同的 column families 的資料特性有所不同:
      • 2X - 4X 資料量的減少。
      • 25% - 35% 讀校能改善。
      • 5% - 10% 寫校能改善。
    • 使用時機:
      • 壓縮最合適的 column family 是,有很多筆 row,每一筆 row 有同樣的 columns。
        舉例來說,一個 column family 包含 user 相關的資料,如 username, email, 等,可以被選為要壓縮的對象。更多更類似的 row 的資料,將得到更大的壓縮率,而在讀取時會有更大的效能提升。
      • 在每筆 row 會有不同的 columns set 的 column family,就不是很適合壓縮,所以 Dynamic column families 不會有太好壓縮率。
    • 設定
      • 透過 compression_options 來設定 column family 的壓縮。
      • 當你在一個 column family 設定壓縮後,那些已經存在磁碟的 SSTable 不會馬上進行壓縮,不過在之後的 compaction 程序會進行壓縮,但新建立的 SSTable 會立即被壓縮。
      • 若有必要,你可以使用 nodetool upgradesstables 或 scrub 強迫重寫並壓縮這些 SSTable。
      • 透過 CLI 設定
        UPDATE COLUMN FAMILY users
        WITH compaction_strategy=LeveledCompactionStrategy
        AND compaction_strategy_options={sstable_size_in_mb: 10};
      • Cassandra 1.1 之後才能透過 CQL 來設定 compression (DataStax)。

About Primary Indexes

  • Column family 的 primary index 就是 row key 的索引。
  • Row 的分配是藉由 cluster-configured partitioner 和 key-configured replia placement strategy
  • Primary index 能讓 Cassandra 透過 row key 找出 row。
  • 每一個節點都知道任何一個節點所管理的 row key 的範圍。
  • 每個 row 請求都能夠透過 row indexes 並只在相關的複本節點上,地找到 row 的位置。

About Secondary Indexes

  • Secondary indexes 是用來參考 column value。
  • Cassandra 支援 type KEYS 的 secondary index (hash index)。
  • 使用 secondary indexes 來查找資料時,透過指定的值和使用對應的欄位名稱(predicate)。
    WHERE column x = value y
  • 何時使用
    • 當資料列包含了索引値。
    • 在一個特定的 column 其中的值都是唯一的。(ex, mail)
    • 當你查詢或維護一個 index 表花了很多時間時。
    • 舉例,若你想要 透過 mail address 來查找一個 user,這會比維護一個做為 index 表格的 dynamic column family 還要有效率。
  • 如何使用
    • 當你在 column 建立 secondary index時,這會在背景裡建立資料的索引。
    • 建立的方式
      • 建立 column family時
        CREATE COLUMN FAMILY users WITH comparator=UTF8Type
        AND column_metadata=[
        {column_name: full_name, validation_class: UTF8Type},

        {column_name: email, validation_class: UTF8Type},
        {column_name: birth_year, validation_class: LongType, index_type: KEYS},
        {column_name: state, validation_class:  UTF8Type, index_type: KEYS}];
      • 用 UPDATE 來建立已經存在的 column
        UPDATE COLUMN FAMILY users WITH comparator=UTF8Type
        AND column_metadata=[
        {column_name: full_name, validation_class: UTF8Type},

        {column_name: email, validation_class: UTF8Type},
        {column_name: birth_year, validation_class: LongType, index_type: KEYS},
        {column_name: state, validation_class:  UTF8Type, index_type: KEYS}];
    • 使用 secondary index
      • CLI
        GET users WHERE state = 'TX';
      • CQL
        SELECT * FROM users WHERE state = 'TX';


2014-12-04

Understanding Cassandra Architecture

Reading Document : http://www.datastax.com/docs/1.0/cluster_architecture/index


Gossip

  • Cassandra 使用 gossip 協定來找出其它參與 Cassandra 叢集的節點位置和狀態資訊。
  • Gossip 訊息有版本號,比較老舊的訊息,不能覆寫較新的訊息。
  • 為了預防 gossip 溝通上的隔閡,在一個叢集內的所有節點都應該擁有相同的種子節點(seed nodes)清單。
  • Seed node 的目的只有在新的節點加入時啟動 gossip 程序,它也不是單點失敗 (Single point of failure) 的設定。
  • 每個節點都必須知道它自己的 token 值。當一個叢集被初始化時,應該要建立整個叢集的 tokens,並且為每個節點分配一個 token。之後,每個節點都會把它的 token 拿來跟其他節點溝通。
  • 錯誤偵測 (Failure detection) 是一個採取 gossip state 來決定的方法。錯誤偵測也被來避免客戶端請求被繞送到到不了的節點 (unreachable node)。
  • 透過 dynamic snitch,Cassandra 也能夠避免把客戶的請求,繞送到活著但效能不佳的節點。
  • Cassandra 使用一個累積(accrual)偵測機制,用來計算每一個節點的門檻值,這個門檻值必須考量到網路情況、工作量、或其它跟影響心跳感應率有關的條件。
  • 透過設定 phi_convict_threshold 屬性,來調整錯誤偵測的敏感度。目前的預設值已經是大部分情況下的最佳值。
  • 個節點的中斷不表示,這個節點從叢集中永遠離開,節點不會自動從 ring 中離開,其它的節點會定期的透過 gossip 和它聯繫,去看看它是否回來了。(如果要將一個節點,加入一個 ring 或從一個 ring 移掉,那麼就要使用 nodetool。)


Data Partitioning in Cassandra

  • Data Partitioning 決定資料如何分佈在叢集內的節點。
  • 與資料分散有關的三個要素:
    • Partitioner:決定哪個節點來存資料。
    • 資料副本數量:透過副本放置策略 (replica placement strategy) 來決定。
    • 叢集拓撲:節點數量,節點在機櫃 (rack) 的分佈和資料中心 (data center) 的數量。
  • 要決定一個 row 的第一個副本 (replica) 要存到哪一個節點,便要順時針方向走訪這個 ring 的每個節點,直到遇到一個節點的 token 值大於 row key 值。
  • 一個節點的責任區在於他自己和前面節點的那一段區域。
  • Cassandra 1.0 提供兩個 Partitioner。
    • RandomPartitioner
    • ByteOrderedPartitioner
  • RandomPartitioner 是預設的 partitioning strategy,在大部份的情況下是最佳選擇。
    • 把資料均勻的分佈在數個節點,row key 是用一個雜湊演算法所建立一個 MD5 的雜湊值。(雜湊值的範圍為 0 ~ 2127 - 1)
    • 另一個使用 RandomPartitioner 的好處是,簡單化了叢集負載平衡,因為每一個區塊的雜湊範圍平均接受了等量的資料。
  • ByteOrderedPartitioner 從字面上來看,這個 Partitioner 的 row key 是 bytes。
    • Datastax 強烈建議不要使用這個 Partitioner,原因如下:
      1) Sequential writes can cause hot spots
      如果你的應用程式傾向一次寫入或更新一批連續資料列,這些寫入的資料並不分散在整個叢集裡,也就是都存到單一個節點,這經常會是一個應用程式會有 處理與timestamped 資料有關的問題。

      2) More administrative overhead to load balance the cluster
      Ordered Partitioner 需要管理者去計算出 token 的範圍,以估算出 row key 的分散。

      3) Uneven load balancing for multiple column families
      若你的應用程式有很多列族,有個可能性是這些列族們有不同的 row key 並且有不同的資料分佈。
  • 佈署在多個 data center 的副本放置策略(replication placement strategy) 比較推薦的是 NetworkTopologyStrategy,這個策略對每個 data center 計算副本的放置。
    • 這個策略,為每一個列,藉由 token 值來分配節點以放置第一個副本,之後,要在同一個 data center 裡放置額外的副本,就必須以順時鐘方向走訪 ring 的節點,直到遇到在另一個 rack 的第一個節點。
    • 在 data center 內不均勻的資料分佈,會導致不均勻的資料分佈。
    • 要先確保每一個 data center 裡的每一個節點所獲得的 token 可以讓它們均勻分布在 ring 裡,這樣可以避免 row key 不均勻的分配在每一個 data center 裡。
    • 無論如何,你必須避免節點有相同的 token 值,而造成衝突,即使不在同一個叢集的節點。必須要確認每一個節點都有一個唯一值的 token。


Replication in Cassandra

  • Replication 是一個把資料複本儲存到多個節點的程序,用來確保可靠度和容錯。
  • Cassandra 的儲存複本稱為 replica (複製品;複寫),針對 row key 的每個 row 來存。
  • 這個策略將複本分散儲存到叢集內的一些節點,取決於叢集的拓撲 (topology)。
  • 叢集內複本的總數參考到複本因子(replication factor)。
  • 複本因子為 1 的意思是,針對每一筆資料列只會有1 筆複本在一個節點裡。複本因子為 2 的意思是,每一筆資料列有 2 筆複本,分別存到不同節點裡。
  • 所有複本一樣重要,沒有主要或次要複本的差別。
  • 個通則是,副本因子的數量不能超過叢集內節點的總數,當然你可以增加副本因子的數量,在之後增加節點。如果副本因子超過節點數,就無法寫成功,但讀取只要可以符合一致性等級(consistency level) 仍然可以成功。
  • 複本策略仰賴叢集設定 snitch
  • Replication Strategy 可用設定有:SimpleStrategy、NetworkTopologyStrategy
  • SimpleStrategy
    • 針對單一 data center 的話,就使用這個策略。
    • 若你透過 CLI 建立 keyspace 時,這是預設的複本放置策略。
      CREATE KEYSPACE myspace WITH placement_strategy = 'org.apache.cassandra.locator.SimpleStrategy'
                              AND strategy_options = {replication_factor:3};
    • 這個策略放置第一個複本的依據是來自 partitioner,剩下的複本則是依序走訪 ring 中的節點,而不需要考慮機櫃 (rack) 或資料中心 (data center)。
    • 下圖顯示 3 個資料列的 3 個複本被放置在 4 個節點的叢集中。


















  • NetworkTopologyStrategy
    • 當你已經或想要佈署你的 Cassandra 叢集橫跨多個 data center。這個策略可以指定有你想要放置多少複本在每個 data center。
    • 當你想決定要將多少複本設置到每一個 data center 時,底下兩件事情是需要考慮的:
      1) 能夠滿足本地端的讀取,而不需要跨 data center
      2) 錯誤的情形
    • Two replicas in each data center
      這個設定能夠容忍一個複本群組的單點失效狀態,並允許在 consistency level 設為 1 時的本地端讀取。
    • Three replicas in each data center
      這個設定能夠在 consistency level 為 LOCAL_QUORUM 的情況下,容忍一個複本群組的單點失效狀態。或者,在 consistency level 設為 1 的情況下,容忍 data center 有多個失敗節點。
    • 每個 data center 都是獨立決定資料複本的放置,規則如下:
      1) 
      第一個複本,會根據 partitioner 來放置 (與 SimpleStrategy 一樣)
      2) 剩餘的複本會順時針走訪 ring 的每個節點,直到發現有不同的 rack 的節點。如果沒有這樣的節點,那麼就會放在同一個 rack 裡的其它節點。
    • 這個策略會嘗試將複本放到不同的 rack,因為在同一個 rack 的節點,有可能會同時失效 (斷電, 網路中斷)。
    • NetworkTopologyStrategy 仰賴 snitch 的設定,以正確地放置複本到 rack 和 data center。慎重的為你的叢集選擇 snitch 的類型,這個重要性可以讓你的叢集能夠正確地決定節點在你網路的位置。
    • OldNetworkTopologyStrategy 設定上的限制,只能夠指定多少複本要存到分別存到不同的 data center,不能夠像 NetworkTopologyStrategy 那樣可以個別設定哪一個 data center 可以存多少複本。
  • Snitch
    • Snitch 將 IP 對應到 rack 和 data center。
    • 它定義了,節點如何在整個網路拓撲裡,被群集在一起。
    • Cassandra 使用了這個資訊,盡可能以高效的方式,繞送 (route) 節點間的請求。
    • 在同一個叢集內的節點應該都要使用相同的 snitch 設定。
    • Snitch 的類型:
      1) SimpleSnitch不去識別 data center 或 rack 資訊,用在 single-data center 佈署。

      2) RackInferringSnitch
      RackInferringSnitch 猜測網路拓撲是依據八進位的節點 IP 位址。

       
      當定義你的 keyspace 的 strategy_options 時,使用第二個八進位的 IP 當做你 data center 的名稱。
      左圖表示,data center 的名稱是 100。
















      3) PropertyFileSnitch
      透過 rack 和 data center 決定節點的位置。透過 cassandra-topology.properties  來設定。
      使用這個 snitch 的原因有:節點 IP 會改變、有複雜的複本群組需求。

      4) EC2Snitch
      提供 Amazon EC2 佈署(single region)

      5) ECMRegionSnitch
      提供 Amazon EC2 佈署(multiple region)。
  • Dynamic Snitching
    • 預設上是啟用的,所有的 snitch 都使用一個動態 snitch 層,這個 snitch 監控讀的延遲 (read latency)以及試著不要將請求送到效能低下的節點。
    • 可以在 cassandra.yaml 針對每個節點,設定 dynamic snitch threshold 。

Cient Requests in Cassandra

  • 所有 Cassandra 節點的地位都是相同的,同一個 Client 的讀或寫的請求可以送到任何一個節點處理,當一個 Client 連到一個節點並且發起一個讀或寫的請求,這個節點就成為協調者 (coordinator) 用來處理特定客戶端操作。
  • 協調者的工作是:
    • 扮演代理 (proxy) 的角色,做為 Client 與複本節點 (replicas) 之間的代理人。
    • 決定 ring 裡的哪些節點應該取得請求,這必須依據 partitioner 和 replica placement strategy。
  • Write Requests:
    • Coordinator 將寫的請求發送給所有的 replicas,只要所有的複本節點是正常運作的,它們就會收到寫的請求,不論 Client 是否有指定的一致性等級 (consistency level)。
    • 在一個單一 data center 裡有一個帶有複本因子為 3 並擁有 10 個節點的 Cassandra 叢集,一個在進行的寫的請求將會跑到 3 個節點,以讓它們擁有那筆資料列的請求。
    • 如果 Client 指定這個寫入的 consistency level 是 ONE,第一個節點完成寫入後,回應了 coodinator,那麼隨後就會把成功訊息送回 Client。
    • 如果一個複本節點錯過了一個寫入的請求,那麼這筆資料列將會在後續,以 Cassandra 所提供的修復方式:hinted handoff、read repair、anti-entropy node repair,來修復。
  • Multi-Data Center Write Requests
    • 多 data center 佈署上,Cassandra 最佳化寫的效能上,在每個 data center 各選擇了一個 coordinator,透過它來處理寫入複本的請求,這樣的話,只要把寫入的請求送給每一個 data center 的 coordinator 就行了。.
    • 使用的 consistency level 是 ONE 或是 LOCAL_QUORUM,只有在同一個 data center 作為 coordinator 的節點必須要回應 client 的請求,以表示成功。這個方法,可以壁開地理性延遲的衝擊,影響回應 client 的時間。










  •  Read Requests
    • 有兩種讀的類型:直接讀的請求、背景 read repair 請求。
    • 要聯繫多個 replicas,由 Client 指定 consistency level 直接請求。而背景 read repair 請求則不需要一個直接的請求。
    • Read repair 請求確保所請求的資料列必須一致性的存在於所有的複本。
    • 如果 replicas 的節點都聯繫到了,從每個 replica 來的資料列就會在記憶體內做一致性的比較。若有 replica 是不一致的,接著就會發生一些事情:
      1) 
      不管 read_repair_chance 是否有設定,一個在前景的 read repair 會發生在資料上。
      2) Coordinator 使用擁最新資料的 replica (基於 timestamp) 並把結果傳遞到 client。
      3) 背景裡,coordinator 會比較剩下擁有那筆資料列的 replicas。
      4) 如果有不一致的 replica,會更新那筆資料列以反映最新寫入的資料值 (coordinator 會負責發起 "更新過期的 replica" 的操作)。
    • 這個程序就是 read repair。我們能夠針對每個列族設定 read repair (使用 read_repair_chance 預設上是開啟的)。

Planning a Cassandra Cluster Deployment

  • Hardware recommendations
    • Memory
      1) 最少要 8GB (最普遍)
      2) DataStax 建議大約要 16GB ~ 32GB
      3) Java heap size 最大值應該設定 8GB 或是你記憶體的一半 (要注意GC的衝擊)
      4) 若是再虛擬環境,至少設定 4GB
    • Disk
      1) 要考慮兩部份: 容量 (capacity) ─ 足夠的空間 和 I/O ─ 讀和寫的吞吐量。2) 大部份工作量,使用不昂貴的 SATA 硬碟以擴充容量,並且透過增加節點的方式,來擴充更多 I/O 的能力 (更多的 RAM)3) Solid-state drives (SSDs) 也是一個有效的替代品。4) 理想上,Cassandra 需要兩顆硬碟,一個提供 commit log,另一個提供 data directories。最低限度,commit log 應該在自己的 partition。5) Commit log disk ─ 這個硬碟不需要太大,但至少可以快到足以接收所有的寫入 (appends; sequential I/O)6) Data disks ─ 使用一個以上的硬碟以確保足夠大到能夠儲存 data volume,而且夠快以滿足資料不在記憶體快取的讀取,並且可以跟上 compaction。
      7) RAID ─ 在單一 data directory volume,compaction 會暫時的需要 100% 的硬碟剩餘空間。這意味,當將達到硬碟的 50% 容量時,你應該使用 RAID 或 RAID 10 提供給 data directory volumes 使用。RAID 也能在 I/O 熱點情況下,對使用單一 SSTable 有所幫助
      8) 擴充檔案系統 ─ 到 ext2 或 ext3, 最小的檔案大小是 2TB ( 64-bit kernel 情況下也是)。ext4 可達 16TB
    • Number of Nodes
      使用大量但資料少的節點比起使用少量但資料量大的節點好,這是因為在 compaction 期間,資料量大的節點會有潛在的瓶頸。
    • Network
      1) 
      Cassandra 是一個分散式的儲存體,在網路上的負載就是 read/write 請求的處理和複本資料分散的處理。
      2) 網路必須要能夠容納你需要的流量。
      3) 頻寬至少要 1Gbits。
      4) 將以下兩個介面分開設給不同 NIC
              - Thrift interface (listen_address )
              - RPC server interface (rpc_address)
      5) Cassandra 盡可能的會向同一個 rack 的節點抓 replica,選擇同一個 rack 的節點,勝過於遠端的 data center 的節點。
  • Node Configuration Options
    • Storage Settings
      在 Production 環境必須讓 commitlog_directory 與 data_file_directories 不同硬碟。
    • Gossip Settings
      控制節點如何參與叢集,以及節點如何被其它節點知道,設定有
      cluster_name:要加入這個叢集的節點都要設定一樣。listen_address:Cassandra 的 IP 位址。
      seeds:這個設定用來啟動 gossip 程序,每個節點都要有同樣的 IP 位址列表。
      storage_port:預設是 7000,在叢集內每一個節點都要一樣,這是用來做內部溝通的 port。
      initial_token:用來決定這個節點所負責的資料範圍。
    • Purging Gosssip State On a Node
      Gossip 資訊會被 persisted 在本地端用來立即重啟,而不用等待 gossip。
    • Partitioner Setting
      1) 你必須要確保每一個節點能夠大約有相同量的資料 (負載平衡)。2) 為每個節點,設定 partitioner ,並且設定一個 initial_token 值。3) Datastax 建議對所有叢集的佈署,使用 RandomPartitioner (default)。4) 在單一 data center,你可以分別為叢集內的每個節點計算 token。5) 
      再多個 data center,token 應該被分開計算,如同每個 data center 的負載平衡都是獨立的。
    • Snitch Settings1) Snitch 的責任,是在了解在你的網路拓撲裡的所有節點的位置。
      2) 他的影響是複本要放在哪裡,以及請求要怎麼在 replicas 之間繞送。
      3) endpoint_snitch 用來設定節點的 snitch,每個節點都應該要有確切的 snitch 設定。
      4) 在單一個 data center,使用 SimpleSnitch 通常就夠用。
      5) 
      如果之後你想要延伸到多個 rack 和多個 data center,也是很簡單的,只要在一開始的時候就選一個可以感知 rack 和 data center 的 snitch 就行。
    • Configuring the PropertyFileSnitch
      1) 
      PropertyFileSnitch 允許你去定義自己想要的 data center 和 rack 名稱。
      2) 
      在 cassandra-topology.properties 檔裡,可以定義網路細節,叢集內的每一個節點應該都要被描述在這個檔案裡,而且這個檔案在每個節點應該都要一樣。
  • Choosing Keyspace Replication Options
    • DataStax 建議,不管是單一 data center 或是多個 data center,選擇 NetworkTopologyStrategy 就好。它跟 SimpleStrategy 一樣容易使用,而且在未來也可以擴充到多個 data center。
    • 設定 NetworkTopologyStrategy 有一些選項,如在每個資料中心的複本數。
      即使是單一 data center 仍可使用。
    • UPDATE KEYSPACE gamecloud WITH placement_strategy =
                   'org.apache.cassandra.locator.NetworkTopologyStrategy'
      AND strategy_options={DC1:3};
    • Data center 的名稱應該要參考 snitch 的設定。
    • 一般的規則是,複本數不應該超過在複本群組內的節點數。然而,增加複本數,之後再增加節點數也是有可能的。當複本因子超過節點數,寫就會被拒絕,但是,讀取只要符合 consistency level 仍然沒有問題。當複本因子超過節點數,寫就會被拒絕,但是,讀取只要符合 consistency level 仍然沒有問題的。