Cassandra 3.x官方文件_理解結構
結構簡介
Cassandra 被設計成可以處理跨多個節點的大資料量工作負載，沒有單點故障。它的體系結構是基於這樣的理解，系統和硬體故障可以和確實發生。Cassandra解決這種故障的方式是，採用點對點的分散式系統，把資料均勻的分佈在叢集的所有節點之中。每一個節點通過點對點的通訊協議gossip，來頻繁的和叢集中的其他節點交換自己的狀態資訊。一個順序寫的檔案commit log在每個節點上捕獲寫操作，以保證資料的永續性。同時資料會被索引，然後寫入到一個叫做memtable記憶體結構裡，這類似於寫回快取。每當這個記憶體結構滿了，資料就會被寫進磁碟一個叫做SSTables的資料檔案裡。所有的寫入都會自動分割槽並在整個叢集中複製。
Cassandra是一個分割槽行儲存資料庫，行通過主鍵被組織成表格。Cassandra的架構允許任何被授權的使用者連線任何資料中心的任何節點，並使用CQL語言訪問資料。為方便使用，CQL使用了和SQL類似的語法和操作表格資料的方法。開發者可以通過cqlsh,DevCenter,和應用語言的驅動程式來訪問CQL。通常，一個叢集的每個應用有一個由很多table組成的keyspace。
客戶端的讀或寫請求可以傳送到叢集中的任何節點。當一個客戶端傳送請求連線到一個節點時，該節點作為該特定客戶端的協調者
主要的結構
• 節點
你儲存資料的地方。這是Cassandr的基礎元件。
• 資料中心
相關節點的集合。一個數據中心可以是一個物理的資料中心，或者是虛擬的資料中心。不同的工作負載應該使用獨立的資料中心，無論是物理的或虛擬的。複製是由資料中心設定的。使用獨立的資料中心，可以防止Cassandra的事務受到其他工作負載的影響，保持互相之間請求有更低的延時。取決於複製因子，資料可以寫入多個數據中心。資料中心必須永遠不會跨越物理位置。
• 叢集
一個叢集包含一個或多個數據中心。它可以跨越物理位置。
• Commit log
為了持久化，所有資料首先寫入commit log裡。當它所有的資料都被重新整理到SSTables以後，它可以存檔，刪除或回收。
• SSTable
排序字串表(SSTable)是一個不可變的資料檔案，Cassandra會定期的把memtables寫入進來。SSTables只能追加，在磁碟上順序儲存的，而且由每個Cassandra表格保持著。
• CQL 表
錶行獲取的有序列的集合。一個表由列組成，並有一個主鍵。
Cassandra配置的主要元件
• Gossip(流言協議)
一個點對點通訊協議，用來發現和共享Cassandra叢集中其他節點位置和狀態資訊。Gossip的資訊也在每個節點上持久化在本地，這樣當一個節點重啟的時候就能馬上使用。
• 分割槽器
一個分割槽器決定哪個節點接收資料的第一份副本，以及如何把其他的副本分配到叢集的其他節點上。每一行資料通過一個主鍵唯一標識，可能有相同的分割槽鍵(partition key)，但是會包含不同的聚集列(clustering columns)。分割槽器利用雜湊函式從每一行的主鍵中提取token值。分割槽器使用這個token值，決定叢集中的哪些節點接收這些行的副本。Murmur3Partitioner是新的Cassandra叢集預設的分割槽策略，幾乎在新叢集所有的案例中都是正確的選擇。
你必須為每個節點設定分割槽器和分配虛擬節點的值。你分配的這個token的數量是由系統的硬體能力決定的。如果你不使用虛擬節點，那就需要配置initial_token。
• 複製因子
叢集的整個副本的總數。副本因子為1，意思是每一行只有一個副本，只存在於一個節點上。副本因子為2，意思是每一行有兩個副本，每一個副本存在於不同節點上面。所有的副本是同等重要的，沒有主副本和從副本。每一個數據中心都需要定義一個副本因子。一般來講，你應該把複製策略設定成大於1，但不超過叢集的節點數量。
• 副本放置策略
Cassandra的副本資料儲存在多個節點上確保可靠性和容錯性。複製策略決定要將副本放置在哪個節點上。資料的第一個副本是僅僅就是第一份備份，它在任何意義上都不是唯一的。在大部分部署中，強烈推薦NetworkTopologyStrategy策略，因為當未來需要擴充套件時，它更容易擴充套件到多個數據中心。當建立一個keyspace時，你必須指定副本放置策略和副本的數量。
• Snitch(告密者) snitch 把一組機器分為了資料中心和機架(拓撲結構)，複製策略用於放置副本。
當你建立叢集的時候，必須配置snitch。所有的snitch使用一個動態的snitch層，用來監控效能和選擇最好的副本來讀。它是預設啟用，建議在大多數部署中使用。在cassandra.yaml配置檔案中為每一個節點配置動態snitch的閥指。
預設的SimpleSnitch並不識別資料中心或者機架的資訊。只有在部署單資料中心或者在公共雲的單個區域的時候才使用它。建議生產中使用GossipingPropertyFileSnitch。它定義了一個節點的資料中心和機架，並使用流言協議(gossip)傳播這些資訊到其他節點。
• cassandra.yaml配置檔案
設定叢集的初始化屬性，快取表的引數，效能調優和資源利用，超時設定，客戶端連線，備份和安全的主要配置檔案。
預設情況下，一個節點在cassandra.yaml檔案裡配置資料儲存的檔案路徑。
在生產環境中叢集部署，你可以把commitlog-directory的路徑修改成和data_file_directories.不同磁碟下面。
• 系統keyspace和table屬性
你在每一個keyspace或者每一個table上的配置屬性都會儲存起來，基礎程式設計或使用
一個客戶端應用程式，如CQL。
相關參考
在71頁cassandra.yaml配置檔案
相關資訊
在68頁安裝位置
節點間通訊(gossip)
Gossip是一個點對點通訊協議，在該協議中，節點定期交換他們自己的和他們所知道的其他節點的狀態資訊。Gossip程序每秒執行一次，和叢集中多達三個以上的節點交換狀態資訊。這些節點交換關於自己的和通過流言獲取到的其他節點的資訊，所以所有的節點很快了解到叢集中所有其他節點的資訊。一個gossip有一個關聯的版本，所以當他在gossip交換資訊期間，舊的資訊在一個特定的節點上會被最新的狀態覆蓋掉。
為了防止在gossip通訊期間出現問題，在一個叢集所有節點上使用相同的種子節點，在節點第一次啟動的時候尤其重要。預設情況下，一個節點會記住它已經通過gossiped協議通訊過的其他節點。種子節點的指定沒有其他目的，絕不是因為新節點加入叢集而自啟動gossip程序。種子節點沒有單點故障，在叢集的操作中沒有其他特殊的目的，除了引導節點。
注意：在有多個數據中心的叢集中，最好從每個資料中心中選出至少一個節點作為種子節點的一員。
為了容錯性，建議每個資料中心指定一個以上的種子節點。否則，在引導一個節點啟動的時候，gossip需要和其他資料中心通訊。不建議把每個節點都當成種子節點，因為增加了維護的難度和降低了gossip的效能。Gossip優化並不是很關鍵，建議不要使用太多種子節點(一個數據中心大概3個左右)。
故障檢測和恢復
故障檢測是一種通過gossip的狀態和歷史在本地確定系統中的其他節點是否已經關閉或已恢復的方法。Cassandra利用這個資訊來避免路由客戶端的請求在任何時候到達不可達節點(Cassandra也可以通過動態告密者snitch來避免路由客戶端到達那些雖然線上，但是效能差的節點)。
Gossip的過程跟蹤其他節點的狀態，既有直接的(節點直接的Gossip過程)也有間接地(節點通過二手的、三手的或者更多手來通訊)。標記一個節點是失敗的沒有一個固定臨界值，Cassandra使用了一個動態增長機制來計算一個節點的臨界值，而且還要考慮網路效能，工作負載和歷史狀況。在gossip協議在交換資訊的過程中，每個節點保持著一個滑動視窗，記錄叢集中其他節點的gossip訊息到達的時間。通過配置phi_convict_threshold屬性，調整故障探測器的靈敏度。值越小，反應遲鈍的節點就越可能被標記為宕機，值越大，導致節點故障的短暫故障的可能性越小。大多數情況下使用預設值，當使用亞馬遜的EC2的時候，把它增大到10或者12(由於經常遇到網路阻塞)。在不穩定的網路環境中(比如說EC2有時候)，把值增大到10或者12可以防止假失敗。不建議設定成大於12和小於5.
節點故障可能由多種原因導致的，比如硬體故障和網路中斷。節點中斷往往是短暫的，但是可以持續較長時間。因為一個節點中斷很少意味著永久離開叢集，它不會自動的從環中永久刪除。其他節點將定期嘗試重新建立與失敗的節點的聯絡，看看他們是否恢復。要永久性地更改叢集中的節點的成員身份，管理員必須明確的使用nodetool工具來把節點從Cassandra叢集中新增或刪除。
當一個節點在中斷後返回聯機時，它可能錯過了本應寫到它上面的副本資料。修復機制的存在會恢復丟失資料，如暗示切換和nodetool repair手動修復。中斷的長度將決定使用哪種修復機制來保持資料的一致性。
資料分佈和複製
在Cassandra裡，資料的分佈和複製是一起的。資料是由表組織的，並且通過主鍵來決定將資料儲存在哪個節點上。副本是行的備份。當資料第一次寫的時候，它也被稱為第一個副本。
Factorsinfluencing replication include:
影響複製的因素包括：
• 虛擬節點:將資料所有權分配給物理機器
• 分割槽器:分割槽整個叢集的資料
• 複製策略:決定每行資料的副本數量
• 嗅探器:定義複製策略用來放置副本的拓撲資訊
一致性雜湊
一致性雜湊允許資料在叢集中分佈，當新增或刪除節點時，儘量減少重組。一致性雜湊是基於分割槽鍵來把資料分割槽的。(想看分割槽鍵和主鍵的解釋，請看Cassandra 2.2和以後版本的CQL資料模型的例子)
例如，如果你有以下資料：
|
name |
age |
car |
gender |
|
jim |
36 |
camaro |
M |
|
carol |
37 |
bmw |
F |
|
johnny |
12 |
M |
|
|
suzy |
10 |
F |
Cassandra為每一個分割槽鍵分配一個雜湊值：
|
Partition key |
Murmur3 hash value |
|
jim |
-2245462676723223822 |
|
carol |
7723358927203680754 |
|
johnny |
6723372854036780875 |
|
suzy |
1168604627387940318 |
叢集中的每一個節點負責一個雜湊值的範圍。
圖：叢集中四個節點的雜湊值
Cassandra根據分割槽鍵的雜湊值和節點負責的雜湊值範圍，把資料分配到不同的節點上。例如，在一個四個節點的叢集中，資料的分佈如下所示：
|
Node Partition |
Start range |
End range |
Partitionkey |
Hash value |
|
A |
9223372036854775808 |
-4611686018427387904 |
johnny |
-6723372854036780875 |
|
B |
-4611686018427387903 |
-1 |
jim |
-2245462676723223822 |
|
C |
0 |
4611686018427387903 |
suzy |
1168604627387940318 |
|
D |
4611686018427387904 |
9223372036854775807 |
carol |
7723358927203680754 |
虛擬節點
虛擬節點，也稱作Vnodes，可以更容易的實現在更細的粒度下分發資料，如果計算出token值。在Cassandra裡，虛擬節點簡化了很多的任務：
•token值是自動算出來的，然後分配到每一個節點上
•當新增和刪除節點時，重新平衡一個叢集是自動完成的。當一個節點加入叢集，它承擔叢集中其他節點的一部分資料的責任。如果一個節點出現故障時，負載均勻的分散到叢集中的其他節點。
•重建一個死亡節點速度更快，因為它涉及到叢集中其他的每一個節點。
•叢集中的每一個機器的虛擬節點的比例可以被指定，那麼不管是比較小的還是比較大的計算機都可以用來組建叢集。
有關更多資訊，請參考文章Virtual nodes in Cassandra 1.2。在已存在的叢集上面配置虛擬節點，請參考Enabling virtual nodes on anexisting production cluster的102頁。
資料是如何分佈在叢集中(使用虛擬節點)
Cassandra1.2之前，你必須計算，然後為叢集中每一個節點分配一個token值。每個節點通過他的雜湊值來確定在環中的節點位置，和它的部分資料。在Cassandra 1.2和後來的版本中，每個節點允許有多個token值。最新的範例叫做虛擬節點(vnodes)。虛擬節點允許每個節點在叢集中擁有大量的小的token分佈範圍。虛擬節點也是用一致性雜湊演算法來分發資料，但是不需要token生成和分配。
圖：虛擬和單token的架構
最上面的一幅圖表示沒有虛擬節點的叢集。在這個範例中，每個節點分配了一個代表了在環中的位置的token值。每個節點儲存的資料是由範圍在上個節點和指定值之間的分割槽鍵的token值決定的。
每個節點也可以包含叢集中其他節點的每一行的副本。舉個例子，如果副本因子是3，那麼E的副本會分佈到5號和6號和1號節點上。注意，一個節點擁有在環空間上一個連續的分割槽範圍。
最下面一幅圖顯示了有虛擬節點的環。在一個叢集裡，虛擬節點是隨機選取的，而且是不連續的。行的位置是由分割槽鍵的雜湊值決定的，在每個節點的很多較小的分割槽範圍內。
資料副本
Cassandra在多個節點上面儲存副本來保證可靠性和容錯性。一個副本策略決定了副本放在哪些節點上。在節點上面的副本的總數稱作複製因子。複製因子為1，意味著叢集上的每行資料只有一份備份。如果包含了這一行資料的節點宕機了，這行資料就無法恢復。複製因子為2，意味著每行資料有兩份備份，而且每個備份在不同節點上。所有副本是同等重要的，沒有主鍵或主副本。作為一個通用規則，副本因子不應該超過叢集中的節點數。然而，你可以增加複製因子的數量，然後新增所需的節點。
兩種複製策略：
• SimpleStrategy:只用於單資料中心和單機架。如果你打算使用不止一個數據中心，那麼使用
NetworkTopologyStrategy
• NetworkTopologyStrategy:高度推薦使用於大多數的部署，因為當未來需要擴充套件時，它更容易擴充套件到
多個數據中心。
SimpleStrategy
只用於單資料中心和單機架。SimpleStrategy把第一份備份放在由分割槽器決定的節點上。餘下的備份被放在環的順時針方向的下面的節點上，而不考慮拓撲結構(機架或資料中心的位置)。
NetworkTopologyStrategy
當你已經(或者計劃)將你的叢集部署成多資料中心的時候，使用NetworkTopologyStrategy策略。這個策略需要指定在每個資料中心有多少個副本數量。
NetworkTopologyStrategy通過走環的順時針方向把副本放置在同一個資料中心上，直到另一個機架的第一個節點。NetworkTopologyStrategy試圖把副本放置在不同的機架，因為在同一個機架上的節點(或者類似物理分組)經常在同一時間發生故障，因為壓力，冷卻或者網路問題。
當決定在每個資料中心配置多少個副本的時候，兩個主要考慮的因素：（1）能夠滿足本地讀取，而不會產生跨資料中心的延遲（2）失敗的情況。兩種最常用的配置多資料中心叢集的方法是：
•每個資料中心兩份副本：這種配置允許其中一個節點的副本組失效，並在一致性級別為1的情況下
仍然允許本地的讀取。
•每個資料中心三份副本：這種配置允許其中一個節點的副本組失效，仍然有著強一致性級別LOCAL_QUORUM，或者每個資料中心多個節點失效，仍然可使用一致性級別1。
不對稱複製分組也是可行的。比如說，在一個數據中心有3個副本來服務實時應用程式請求，在其
他地方使用1個副本來執行分析程式。
每一個keyspace都有一個複製策略，是在keyspace建立的時候設定的。如何建立keyspace，詳見
creating akeyspace。
更多複製策略選項資訊，請看126頁的Changing keyspace replication strategy。
分割槽器
分割槽器決定了資料是如何分佈在叢集的節點上的(包括副本)。基本上，分割槽器通過一個行的分割槽鍵
提取出token值來，通常是通過雜湊函式。然後每行資料通過這個token值來分佈在叢集上面的。
無論是Murmur3Partitioner還是RandomPartitioner都是用token值來幫助把資料均勻的分配到每個
節點上面，均勻的分配資料從整個環中的所有的表和其他的組例如keyspace。這個分佈真的很均勻，
即使表使用不同的分割槽鍵，比如使用者名稱或者時間戳。此外，對於叢集的讀和寫請求分佈的也很均勻，
負載平衡被簡化，因為雜湊值的範圍的每個部分平均接收相同的行數。有關更詳細的資訊，請參見
第14頁的Consistenthashing。
兩種不同分割槽器的主要差別是生成雜湊值的方式。RandomPartitioner使用了加密雜湊的方式，這需
要比Murmur3Partitioner花費更多的時間生成。Cassandra並不真的需要一個加密雜湊，所以使用
Murmur3Partitioner導致效能提高3-5倍。
Cassandra提供了以下的分割槽器，都可以在cassandra.yaml檔案裡設定：
• Murmur3Partitioner(預設的)：基於MurmurHash的雜湊值，資料均勻的分佈在叢集裡。
• RandomPartitioner:基於MD5的雜湊值，資料均勻的分佈在及群裡
• ByteOrderedPartitioner:基於詞彙的關鍵位元組，保持資料的有序分佈。
Murmur3Partitioner在Cassandra 1.2和後來的版本中是預設的分割槽策略，幾乎在所有的情
況下對於新叢集都是正確的選擇。然而，分割槽器是不相容的，用一個分割槽器分割槽的資料不能簡單的
轉換成另一個分割槽器。
注：如果你使用虛擬節點(vnodes)，你就不需要計算token值。如果你不使用虛擬節點，你必須計
算token值分配給cassandra.yaml檔案裡的initial_token引數。見108頁的生成token方法和你使
用的分割槽器型別。
Relatedinformation相關資訊
安裝位置在68頁
Murmur3Partitioner
Murmur3Partitioner是預設的分割槽器。Murmur3Partitioner提供了更快的雜湊演算法和比
RandomPartitioner更好的效能。Murmur3Partitioner可以使用虛擬節點。然而，如果你不使用虛擬
節點，你就必須用生成token的方法計算token值。
在新的叢集中使用Murmur3Partitioner分割槽器，你就不能改變現有叢集的分割槽器。
Murmur3Partitioner使用了MurmurHash方法。這種雜湊演算法建立了分割槽鍵的64位雜湊值。
雜湊值的可能範圍在-2∧63和+2∧63-1.之間。
使用Murmur3Partitioner的時候，你可以用CQL的token方法瀏覽所有行。
RandomPartitioner
RandomPartitioner是Cassandra1.2之前版本的預設分割槽器。它是向後相容的。
RandomPartitioner可以使用虛擬節點(vnodes)。然而，如果你不使用虛擬節點，你必須用Generating
tokens.描述的方法來計算token值。RandomPartitioner把資料均勻分佈在各個節點上面，使用
的是行健的MD5雜湊值。雜湊值的可能範圍在0到2∧127-1之間。
使用RandomPartitioner的時候，你可以用CQL的token方法瀏覽所有行。
ByteOrderedPartitioner
Cassandra為有序分割槽提供了ByteOrderedPartitioner。它是向後相容的。這個分割槽器按照行的關健
位元組來排序的。你是通過檢視資料分割槽鍵的實際值來計算token值的，使用的是一種領先的十六進
製表示的字元。比如說，如果你想把行按照字母順序分割槽，你可以使用A的十六進位制數41分配給A
的token值。
使用順序分割槽鍵，允許通過主鍵來順序掃描。這意味著，你可以掃描行，雖然你只是通過傳統的索
引移動游標。例如，如果你的應用程式使用使用者的名字作為分割槽鍵，那麼你就可以掃描那些名字在
Jake和Joe之間的使用者。這種型別的查詢在RandomPartitioner中是不可能的因為裡面的主鍵
是按照MD5雜湊值的順序儲存的(不按順序)。
雖然有序分割槽器有能力對行範圍掃描聽起來是一個可取的特點，但是使用表索引可以實現相同的功
能。
不推薦有序分割槽器的理由如下：
困難的負載平衡
需要更多的管理開銷來平衡叢集負載。有序分割槽器需要管理員根據分割槽鍵分佈的大概情況來手動計
算分割槽範圍。在實踐中，一旦被載入，就需要積極移動節點的token值來適應資料的實際分佈情況。
順序寫可能會導致熱點
如果你的應用程式傾向於在同一個時間裡寫或者更新一個順序的行，那麼寫操作可能不會分散到集
群中，而是會集中到一個節點上。在程式處理時間戳資料的時候，這經常成為一個問題。
多表的負載不平衡
如果你的應用程式有多個表，那麼很有可能這些表有不同的行健和不同的資料分佈。有序分割槽器可
能導致在一個叢集中，一個表的平衡會導致另一個表有熱點和分佈不平均。
告密者(Snitches)
Snitch決定了節點屬於哪個資料中心和機架。他們告訴Cassandra網路拓撲，這樣一來，路由請求
更有效率，而且允許Cassandra把機器分組到資料中心和機架裡來分佈副本。具體而言，複製策略
是基於新的告密者提供的資訊來存放副本的。所有的節點必須返回到相同的機架和資料中心。
Cassandra也最好不要在同一個機架有多個副本(在物理位置上來說是沒有必要的)。
注:如果你改變了告密者，你可能需要執行額外的步驟，因為告密者會影響副本的存放位置。參考124頁的Switching snitches。
動態告密者(Dynamic snitching)
Monitors the performanceof reads from the various replicas and chooses the best replica based on thishistory.
預設情況下，所有告密者還是用了一個動態snitch層，用來監視讀延遲，如果可能的話，讓路由請
求遠離效能差的節點。動態告密者是預設啟用的，建議在大多數部署中使用。有關如何工作的資訊，見Dynamicsnitching in Cassandra: past, present, and future。在cassandra.yaml檔案中為每個節點配置動態告密者的臨界值。有關更多資訊，參見14頁的故障檢測和恢復中列出的屬性。
簡單告密者(SimpleSnitch)
The SimpleSnitch is usedonly for single-data center deployments.
SimpleSnitch(預設的)只在單資料中心的部署中使用。它不識別資料中心或機架資訊，只用於單資料中心部署或者公共雲的單一區域。它把策略順序當成相近的，這樣當禁用讀恢復時，它可以提高快取區域性性。
使用SimpleSnitch，你在建立keyspace時要使用SimpleStrategy策略，還要指定複製因子。
RackInferringSnitch
RackInferringSnitch決定了在機架和資料中心的相近的節點，假設分別對應於節點IP的第三和第二個位元組。這種告密者最好用於比如寫一個自定義的告密者的類(除非這恰好符合你的部署)。
PropertyFileSnitch
Determines the locationof nodes by rack and data center.
這種告密者決定的距離由機架和資料中心決定的。它使用了位於cassandra-topology.properties檔案中的網路詳細資訊。當使用這種告密者，你可以定義的你的資料中心的名字為你任何想要的名字。確保資料中心的名字和keyspace中定義的資料中心的名稱相關聯。叢集中的每一個節點都應該在cassandra-topology.properties檔案中有描述，而且這個檔案應該在叢集中每個節點上都完全一樣。
步驟
如果你有不一致的IP和兩個物理資料中心，每個資料中心有兩個機架，還有第三個邏輯上的資料中心用來複制分析資料的，cassandra-topology.properties檔案可能看起來像這樣：
注:資料中心和機架名是區分大小寫的
# DataCenter One
175.56.12.105=DC1:RAC1
175.50.13.200=DC1:RAC1
175.54.35.197=DC1:RAC1
120.53.24.101=DC1:RAC2
120.55.16.200=DC1:RAC2
120.57.102.103=DC1:RAC2
# DataCenter Two
110.56.12.120=DC2:RAC1
110.50.13.201=DC2:RAC1
110.54.35.184=DC2:RAC1
50.33.23.120=DC2:RAC2
50.45.14.220=DC2:RAC2
50.17.10.203=DC2:RAC2
#Analytics Replication Group
172.106.12.120=DC3:RAC1
172.106.12.121=DC3:RAC1
172.106.12.122=DC3:RAC1
#default for unknown nodes
default=DC3:RAC1
GossipingPropertyFileSnitch
這種告密者是生產中推薦的。它使用本地節點的機架和資料中心的資訊，在cassandra-rackdc.properties中定義的，而且是通過流言協議(gossip)和其他節點傳播資訊的。
GossipingPropertyFileSnitch的配置包含在cassandrarackdc.properties檔案裡。
要使用GossipingPropertyFileSnitch配置一個節點，編輯cassandra-rackdc.properties如下：
•定義包含此節點的資料中心和機架。預設配置：
dc=DC1
rack=RAC1
注:Datacenter and rack names are case-sensitive.資料中心和機架名是大小寫敏感的。
• 為了節省頻寬，新增prefer_local=true選項。這個選項告訴Cassandra，當通訊不在不同的資料中心的時候，使用本地的IP地址。
從PropertyFileSnitch遷移到GossipingPropertyFileSnitch
允許從PropertyFileSnitch遷移，GossipingPropertyFileSnitch使用cassandratopology.properties檔案。遷移完成後刪除該檔案。更多關於遷移的資訊，參考124頁的Switching snitches。
注:當cassandra-topology.properties檔案存在時，GossipingPropertyFileSnitch總是去載入它。從新叢集上或者任何從PropertyFileSnitch遷移過來的叢集上的每個節點刪除該檔案。
Ec2Snitch
在亞馬遜EC2的單一叢集部署中使用Ec2Snitch，在上面，叢集中所有節點都是在單一區域。
在EC2