cassandra筆記2

1.SSTable 的大小？取決於刷memtable到磁碟的時間間隔。
2.一個SSTable檔案用一次從Memtable中寫入？SSTable是隻讀的。
3.每個CF對應一個Memtable，當Memtable滿足重新整理條件後批次重新整理資料儲存到磁碟上的SSTable中，
下一次Memtable需要重新整理到一個新的SSTable檔案中，這也是保證SSTable中資料是按key的一定順序排列的。
4.幾個寫時間瓶頸：
Memtable到閥值後flush到SSTable；
同一個CF的多個SSTable被合併成一個大的SSTable。
5.Write ConsistencyLevel的三種選擇：
ONE:確保寫入至少一個借點的commitlog和memtable
QUORUM:確保至少寫入n/2+1個節點
ALL:確保寫入n個節點,有單點失效問題。--?一個節點失效，將導致寫失敗
6.read
SSTable+Memtable +Bf+Idx
7.一組和MySQL對比的效能資料：
50GB
MySQL 300ms write 350ms read
Cassandra 0.12ms write 15ms read

20萬條資料
Cassandra單執行緒 161125ms write 0.8ms/條
2658516ms read 13ms/條

SSTable是Sorted Strings Table的縮寫

commitlog與cf的對應關係：無明確關係，為了減少IO競爭最好講commitlog儲存在單獨的磁碟上。

-------------------------------------
Hinted Handoff：
KeyA按照規則首要寫入節點N1,複製到N2
加入N1當機，如果寫入N2能夠滿足ConsistancyLevel要求，
則KeyA對應的RowMutation將封裝一個帶Hint資訊的頭部(包含了目標N1的資訊）
然後隨機的寫入一個節點N3，此副本不可讀。同時正常複製一份資料到N2，
此副本可以提供讀。如果寫N2不滿足寫一致性要求，則寫會失敗。
--？如果replication factor為大於等於三，是在寫N2的同時再多複製一份到下一個
節點?
--?正常情況如果client連線的不是目標寫入節點，此節點充當代理，完成首要節點資料的
寫入，節點間再透過gossip同步資料。
流程：client寫commitlog到代理節點（有可能是一個單獨的磁碟，能夠減少寫SSTableIO競爭），
資料再以RowMutation的形式寫入到首要寫入節點。
--？隨機寫入的節點，資料與通常寫資料到磁碟一樣？寫SSTable Index BloomFilter?

MerkleTree是一種HashTree，葉子節點是Key的hash值，父節點是所有葉子節點的hash值，
透過判斷父節點的異同可以知道所有子節點的異同。
--？葉子節點是Key的hash值，那麼一個CF中同一個Key對應的column value發生變化了，理論上hash值
確是沒有變的，不合理？

執行nodetool repair可以啟動Anti-Entropys，此操作是IO密集型操作。

-------------------------------------
資料分佈策略：
RandomPartitioner
基於MD5的隨機Hash分佈。i*(2^127-1)/N
OrderPreservingPartitioner
基於Key值(UTF-8)的範圍分佈
CollatingOrderPreservingPartitioner
基於Key值(不同語言環境排序)的範圍分佈

-------------------------------------
資料複製：
DatacenterShardStategy
如果replication factor為N,則(N-1)%2的副本複製到不同的資料中心。
所有的副本在兩個資料中心均衡分佈。
--？
RackAwareStrategy
一個副本不知到不同的資料中心，其他副本複製到同資料中心的不同機架。
異地機房只保有一個副本，主要用於容災。
RackUnAwareStrategy
不考慮複製節點的物理位置，一般是hash環右邊的N-1個節點。

N個節點的資料是否最終都相同？

增加節點，bootstrap會根據initialToken自動從現有節點流到新加入的節點。
舊資料需要透過nodetool cleanup手工清理

替換一個節點：
先刪除一個節點，再增加一個節點，需要啟動兩次bootstrap操作？

--cassandra的環怎麼會封閉？
每個節點儲存的資料的key的範圍在(前一個節點的TOKEN,本節點的TOKEN]的半開半閉的區間內，
所有的節點首位相連，所以第一個節點儲存大於最大token,小於等於最小token的資料。

如果節點短時間當機，則只需要節點機器恢復後正常啟動Cassandra即可，系統會自動講
當機期間的HintedHandoff資料寫會該節點。
如果當機時間較長，建議採用一臺備用的機器作為新節點加入叢集。

-------------------------------------
引數解釋：
EndPointSnitch：叢集節點對應物理機器分佈策略，據此路由不同的資料副本。
InitialToken:初始化Token,具體key的第一份副本分佈到哪個節點。
CommitLogDirectory：Commitlog檔案存放的路徑
DataFileDirectory:資料檔案存放的路徑，可以指定多個路徑。
--？
RpcTimeoutInMillis:等待遠端節點返回訊息的超時設定。
CommitLogRotationThreshholdInMB:commitlog檔案大小，超過則進行切換。
DiskAccessMode:磁碟訪問模式。64位系統建議設定為mmap，或auto，32位則為standard
--？
RowWarningThresholdInMB:對超長的行進行告警，如果compact時行不能完全放入記憶體中，
Cassandra會崩潰，所以需要根據記憶體設定告警閥值。
compation時對整行資料進行反序列化，所以一行資料必須能夠全部存放進記憶體中。
SliceBufferSizeInKB:讀取連續列的快取大小
FlushIndexBufferSizeInMB:重新整理Memtable到磁碟索引檔案的快取大小
FlushDataBufferSizeInMB:重新整理Memtable到磁碟索引檔案的快取大小
ColumnIndexSizeInKB:當一行長度超過該值時，新增一個列偏移索引。
MemtableThroughputInMB:Memtable大小
GCGraceSeconds:清理帶有刪除標記的垃圾資料的間隔時間。如果節點當機
時間超過了這個間隔，則節點會永久失效，只能重新進行初始化後才能加入到叢集
預設值為10天。

-------------------------------------
備份恢復：
利用nodetoolde snapshot命令可以生成SSTable的一個快照。
在生成snapshot前，先會執行一次Memtable切換，講最新的資料儲存為SSTable。
複製snapshot即可對節點的資料進行物理的備份。
snapshot實際上是SSTable檔案的一個HardLink。
JSON2SSTable
SSTable2JSON

-------------------------------------
cassandra監控：
jconsole JMX地址：
service:jmx:rmi:///jndi/rmi://localhost:8080/jmxrmi
Nagios:

Cassandra web console:

[@more@]