源位址 ： http://blog.csdn.net/zyz511919766/article/details/38683219/
1基本安裝
1.1在基于RHEL的系統中安裝Cassandra
1.1.1必要條件
Ø YUM包管理器
Ø Root或sudo權限
Ø JRE6或者JRE7
Ø JNA(Java native Access)（生産環境需要）
1.1.2步驟
Ø 安裝配置JRE(略)
Ø 添加軟體包倉庫到YUM的軟體庫
将以下内容添加進/etc/yum.repos.d/datastax.repo檔案即可：
[datastax]
name = DataStax Repo for ApacheCassandra
baseurl =http://rpm.datastax.com/community
enabled = 1
gpgcheck = 0
Ø 安裝2.0版最新的軟體包
$ sudo yuminstall dsc20
Ø 安裝JNA
$ sudo yuminstall jna
經過上述步驟即安裝好了Cassandra，随後便可對其進行配置。以此方式安裝的Cassandra會建立一個名為cassandra的使用者，cassandra以此使用者啟動服務。
1.2在任意基于Linux的系統中安裝Cassandra
1.2.1必要條件
Ø JRE6或者JRE7
Ø JNA(Java native Access) （生産環境需要）
1.2.2步驟
Ø 安裝配置JRE(略)
Ø 下載下傳Cassandra二進制 tarball
由http://planetcassandra.org/Download/StartDownload頁面手工下載下傳對應版本的Cassandra，或者通過curl -OLhttp://downloads.datastax.com/community/dsc.tar.gz指令自動下載下傳最新的DataStaxCommunity，也可由http://cassandra.apache.org/download/頁面手工下載下傳對應版本。
Ø 解壓tarball
tar –xzvf dsc-cassandra-2.0.0-bin.tar.gz
根據下載下傳的版本也可能是：tar –xzvf apache-cassandra-2.0.0-bin.tar.gz
Ø 安裝配置JNA
² 下載下傳jna.jar(https://github.com/twall/jna/ )。
² 将下載下傳的jna.jar添加進Cassandra安裝目錄的lib目錄下或将其添加進CLASSPATH環境變量中
² 在/etc/security/limits.conf檔案中加入如下行：
$USER soft memlock unlimited
$USER hard memlock unlimited
其中$USER為運作cassandra的使用者
Ø 建立資料目錄和日志目錄并指定給用于運作cassandra服務的具有相應讀寫權限的使用者
$ sudo mkdir/var/lib/cassandra
$ sudo mkdir/var/log/cassandra
$ sudo chown-R $USER: $GROUP /var/lib/cassandra
$ sudo chown-R $USER: $GROUP /var/log/Cassandra
Cassandra配置檔案中預設使用上述目錄分别作為資料目錄和日志目錄，可建立不同的目錄，賦予對應的權限，并在配置檔案中重新指定以改變預設行為。
至此已安裝好了Cassandra，随後便可對其進行配置。
1.3在其他平台安裝Cassandra（略）
1.5通過源碼建構Cassandra（略）
2簡單配置
Cassandra的主配置檔案為cassandra.yaml，其位置随Cassandra安裝方式不同而不同。
Ø 對于CassandraPackage安裝：/etc/cassandra/conf
Ø 對于CassandraBinary安裝：<install_location>/conf
Ø 對于DataStaxEnterprise Packaged安裝：/etc/dse/cassandra
Ø 對于DataStaxEnterpriseBinary安裝：<install_location>/resources/cassandra/conf
配置檔案中的配置參數被分為如下幾個組
Ø Initialization properties：控制叢集内的節點如何配置，包括節點間通訊，資料分區及複制布置。
Ø Global row and key caches properties：用于緩存表的參數的配置參數。
Ø Performance tuning properties：調整性能和系統資源的利用，包括記憶體、磁盤I/O、CPU、讀和寫。
Ø Binary and RPC protocol timeout properties：用于二進制協定的逾時設定。
Ø Remote procedure call tuning（RPC）properties：用于配置和調整RPCs（用戶端連接配接）
Ø Fault detection properties：用于處理運作情況較差或者失敗的節點。
Ø Automatic backup properties：用于自動化備份。
Ø Security properties：用于伺服器端和用戶端的安全設定
每個組包都含若幹具體的參數（具體内容可參考：http://www.datastax.com/documentation/cassandra/1.2/webhelp/index.html#cassandra/configuration/configCassandra_yaml_r.html）
例如，對于新安裝的Cassandra可能會修改配置檔案中的下面幾個參數
Ø data_file_directories：資料目錄，對于包方式（如deb或rpm）安裝的Cassandra，該目錄會在安裝過程中自動建立并具有正确的權限，預設位置為/var/lib/cassandra/data。
Ø commitlog_directory：commit log目錄，對于包方式安裝的Cassandra，該目錄會在安裝過程中自動建立并具有正确的權限，預設位置為/var/lib/cassandra/commitlog。
Ø saved_caches_directory：儲存的緩存目錄，對于包方式安裝的Cassandra，該目錄會在安裝過程中自動建立并具有正确的權限，預設位置為/var/lib/cassandra/saved_caches。
如果以二進制方式或源碼方式安裝Cassandra需自行建立相應目錄，賦予正确的權限。又或者不想使用預設的位置，也可以自行建立新的目錄，賦予正确的權限，并在配置檔案中指定。比如：
data_file_directories:/data/cassandra/data
commitlog_directory:/data/cassandra/commitlog
saved_caches_directory:/data/cassandra/saved_caches
另外，對于包方式安裝的Cassandra，還會在安裝過程中自動建立/var/log/cassandra目錄并賦予正确的權限。預設情況下Cassandra将其日志寫進該目錄的system.log檔案中。可通過修改log4j-server.properies檔案（與cassandra.yaml位于同一目錄）中的log4j.appender.R.File來改變預設行為，比如：log4j.appender.R.File=/data/cassandra/system.log
還可能要修改JVM級别的參數，該部分的參數可在cassandra-env.sh檔案（與cassandra.yaml位于同一目錄）中設定。
3啟動及簡單使用
3.1啟動Cassandra
對于二進制包安裝方式
Ø 執行bin/cassandra–f，前台啟動cassandra，cassandra會将日志輸出到标準輸出中。若沒在輸出中看到“error”、“fatal”或者類似“java stack trace”的内容表明cassandra可正常工作。可通過“Control-C“停止casandra。
Ø 執行bin/cassandra，背景啟動cassandra。
Ø 可通過kill或pkill指令停止cassandra
對于YUM安裝方式
Ø 執行sudoservice Cassandra start啟動cassandra
Ø 執行sudoservice Cassandra stop 停止cassandra
3.2使用cqlsh
執行bin/cqlsh，出現如下提示則表明連接配接成功（需python2.7）：
Connected toTest Cluster at localhost:9160.
[cqlsh 4.0.0 |Cassandra 2.0.0 | CQL spec 3.1.0 | Thrift protocol 19.37.0]
Use HELP forhelp.
可在cqlsh指令提示符下輸入help或？獲得幫助，輸入exit或quit退出cqlsh，指令預設以“;”結束。
檢視keyspace
DESCRIBEkeyspaces;
建立keyspace
CREATEKEYSPACE mykeyspace WITH REPLICATION = { 'class' : 'SimpleStrategy','replication_factor' : 2 };
切換keyspace
USE mykeyspace;
建立表
CREATE TABLEusers (
user_id int PRIMARY KEY,
fname text,
lname text
);
檢視表
DESCRIBETABLES;
插入資料
INSERT INTOusers (user_id, fname, lname)
VALUES (1745, 'john', 'smith');
INSERT INTOusers (user_id, fname, lname)
VALUES (1744, 'john', 'doe');
INSERT INTOusers (user_id, fname, lname)
VALUES (1746, 'john', 'smith');
查詢資料
SELECT * FROMusers;
建立索引後使用WHERE從句查找
CREATE INDEXON users (lname);
SELECT * FROMusers WHERE lname = 'smith';
删除表
DROP TABLEusers;
至此已經擁有了單節點的Cassandra，且能夠通過cqlsh連接配接至cassandra并使用CQL執行操作。下面對Cassandra作進一步介紹。
4搭建叢集
4.1單資料中心叢集
4.1.1前置工作
Ø 在每個節點上裝配Cassandra
Ø 為叢集确定名稱
Ø 擷取每個節點的IP
Ø 确定用來做種子的節點（Cassandra通過種子節點來找到彼此并了解環的拓撲）
Ø 确定snitch（用于确定向/從哪個資料中心和網架寫入/讀取資料。有不同的類型可選，具體參考：http://www.datastax.com/documentation/cassandra/2.0/webhelp/cassandra/architecture/architectureSnitchesAbout_c.html）
4.1.2具體配置
1.假定使用以下已經安裝了Cassandra的節點配置叢集(資源有限，這裡隻用兩台機器來說明過程。真實環境下最好是有多台機器，且一個叢集中最好有一個以上的種子)
node0192.168.83.35 (seed)
node1192.168.83.37
2.假定節點所在機器有防火牆，注意開放Cassandra所使用的端口（相關端口可查http://www.datastax.com/documentation/cassandra/2.0/webhelp/cassandra/security/secureFireWall_r.html）
3.若Cassandra正運作則先關閉，後清除資料。
$ sudo servicecassandra stop
或者（根據安裝方式而不同）
$ ps auwx |grep cassandra
$ sudo kill <pid>
4.清除資料
$ sudo rm -rf/var/lib/cassandra/*
5.修改cassandra.yaml檔案中的相應内容
cluster_name:'MyDemoCluster'
num_tokens:256
seed_provider:
- class_name:org.apache.cassandra.locator.SimpleSeedProvider
parameters:
- seeds: "192.168.83.35"
listen_address:192.168.83.35
rpc_address:0.0.0.0
endpoint_snitch:SimpleSnitch
若是建立全新的還不包含資料的叢集則加上auto_bootstrap:false
6.剩餘節點的配置與除了listen_address應當為自身IP外，其他配置與上述相同
7.先啟動逐個啟動seed節點，再逐個啟動剩餘節點
$ sudo servicecassandra start
或者
$ cd<install_location>
$ bin/Cassandra
8.使用nodetoolstatus指令檢視叢集是否成功運作
4.2多資料中心叢集
這裡，資料中心指的就是一組節點，與複制組是同義詞。多資料中心叢集中，資料可以在不同資料中心間自動、透明複制。
4.2.1前置工作
與單節點叢集配置基本相同，不同的是還需要确定資料中心和網架的命名。
4.2.2具體配置
1.假定在以下已經安裝了Cassandra的節點配置叢集
node0 192.168.83.35(seed1)
node1 192.168.83.36
node2 192.168.83.37
node3 192.180.83.35(seed2)
node4 192.180.83.36
node5 192.168.83.37
2.若如防火牆，則先開放相應端口（同上）
3.若Cassandra正運作則先關閉（同上）
4.清除資料（同上）
5.修改cassandra.yaml檔案中的相應内容
…同上…
endpoint_snitch:PropertyFileSnitch
若是建立全新的還不包含資料的叢集則加上auto_bootstrap:false
6.剩餘節點的配置與除了listen_address應當為自身IP外，其他配置與上述相同
7.步驟5中指定endpoint_snitch為PropertyFileSnitch是以要編輯對應的cassandra-topologies.properties配置檔案（若endpoint_snitch指定為GossipingPropertyFileSnitch則要編輯cassandra-rackdc.properties，指定為YamlFileNetworkTopologySnitch則要編輯cassandra-topology.yaml）
# CassandraNode IP=Data Center:Rack
192.168.83.35=DC1:RAC1
192.168.83.36=DC2:RAC1
192.168.83.37=DC1:RAC1
192.180.83.35 =DC2:RAC1
192.180.83.36=DC1:RAC1
192.168.83.37=DC2:RAC1
之後還要為位置的節點設定一個預設的資料中心和網架名
# default forunknown nodes
default=DC1:RAC1
8.逐個啟動種子節點，之後逐個啟動剩餘節點（同上）
9.驗證環是否成功啟動（同上）
5使用CQL
CQL:CassandraQuery Language
激活CQL：cqlsh、DataStaxJava Driver、Thrift方法set_cql_version、Python驅動中的connect()調用。
使用cqlsh
bin/cqlsh hostport –u username –p password
建立keyspace
keyspace為表命名空間，指明節點中資料如何複制，一般一個應用對應一個keyspace。cassandra中的複制控制以單個keyspace為基礎。
CREATEKEYSPACE demodb WITH REPLICATION = {'class' : 'SimpleStrategy','replication_factor': 3};
class指明複制政策，replication_factor指明複制的份數
使用keyspace
USE demodb;
更新keyspace
ALTER KEYSPACEdemodb WITH REPLICATION = { 'class' : 'SimpleStrategy', 'replication_factor' : 2};
ALTER KEYSPACEdemodb WITH REPLICATION ={'class' : 'NetworkTopologyStrategy', 'dc1' : 3, 'dc2': 2};
之後在每個受影響的節點執行nodetoolrepair demodb
建立表
use demodb
CREATE TABLEusers (
user_name varchar,
password varchar,
gender varchar,
session_token varchar,
state varchar,
birth_year bigint,
PRIMARY KEY (user_name));
使用複合primary key建立表
CREATE TABLEemp (
empID int,
deptID int,
first_name varchar,
last_name varchar,
PRIMARY KEY (empID, deptID));
插入資料
INSERT INTOemp (empID, deptID, first_name, last_name) VALUES (104, 15, 'jane', 'smith');
查詢表（以系統表為例）
system是Cassandra的系統庫，目前含schema_keyspaces、local、peers、schema_columns和schema_columnfamilies幾個表，分别包含keyspace資訊，本地節點資訊、叢集節點資訊、columns資訊和columnfamilies資訊
use system
SELECT * from schema_keyspaces;擷取到目前節點中的eyspace
SELECT * FROMpeers擷取節點所在叢集資訊
提取并排序查詢結果
SELECT * FROMemp WHERE empID IN (103,104) ORDER BY deptID DESC;
使用keyspace限定符
經常使用USE keyspacename來切換keyspace可能不友善，可使用keyspace限定符指定表所屬的keyspace，如
SELECT * fromsystem.schema_keyspaces;
可在ALTER TABLEC、REATE TABLE、DELETE、INSERT、SELECT、TRUNCATE、UPDATE中使用
指定column的過期時間
INSERT INTOemp (empID, deptID, first_name, last_name) VALUES (105, 17, 'jane', 'smith')USING TTL 60;
其中USING TTL 60指明該條資料60秒後過期，屆時會被自動删除。另外指定了TTL的資料columns會在compaction和repair操作中被自動删除。指定TTL會有8位元組額外開銷。
查詢過期時間
SELECT TTL(last_name)from emp;
更新過期時間
INSERT INTOemp (empID, deptID, first_name, last_name) VALUES (105, 17, 'miaomiao', 'han')USING TTL 3600;也即，以新的TTL重插一遍資料即可。（指定插入的整條資料的過期時間）
或者UPDATA emp USINGTTL 3600 SET last_name='han' where empid=105 and deptid=17; （指定set指明的資料的過期時間）
查詢寫入時間
SELECTWRITETIME(first_name) from emp;可查的該資料何時被插入。
添加columns
ALTER TABLEemp ADD address varchar;
更改column資料類型
ALTER TABLEemp ALTER address TYPE text;
移除資料
² 指定過期時間（同上）
² 删除table或keyspace
DROP TABLE table_name
DROP KEYSPACE keyspace_name;
² 删除columns和rows
DELETE last_name FROM emp WHEREempid=104 and deptid=15;
DELETE FROM emp WHERE empid=104 anddeptid=15;
使用collection類型
² set類型
CREATE TABLE users (
user_id text PRIMARY KEY,
first_name text,
last_name text,
emails set<text>
);
n INSERT INTO users (user_id, first_name, last_name, emails) VALUES('frodo','Frodo', 'Baggins', {'[email protected]', '[email protected]'});
n UPDATE users SET emails = emails + {'[email protected]'} WHEREuser_id = 'frodo';
n UPDATE users SET emails = emails - {'[email protected]'} WHEREuser_id = 'frodo';
n UPDATE users SET emails = {} WHERE user_id = 'frodo';
n DELETE emails FROM users WHERE user_id = 'frodo';
² list類型
n ALTER TABLE users ADD top_places list<text>;
n UPDATE users SET top_places = [ 'rivendell', 'rohan' ] WHERE user_id= 'frodo';
n UPDATE users SET top_places = [ 'the shire' ] + top_places WHEREuser_id = 'frodo';
n UPDATE users SET top_places = top_places + [ 'mordor' ] WHEREuser_id = 'frodo';
n UPDATE users SET top_places[2] = 'riddermark' WHERE user_id ='frodo';
n DELETE top_places[3] FROM users WHERE user_id = 'frodo';
n UPDATE users SET top_places = top_places - ['rivendell'] WHEREuser_id = 'frodo';
² map類型
n ALTER TABLE users ADD todo map<timestamp, text>;
n UPDATE users SET todo =
{ '2012-9-24' : 'entermordor',
'2012-10-2 12:00' : 'throwring into mount doom' }
WHERE user_id = 'frodo';
n UPDATE users SET todo['2012-10-2 12:00'] = 'throw my precious intomount doom'WHERE user_id = 'frodo';
n INSERT INTO users (user_id,todo) VALUES ('miaohan', { '2013-9-22 12:01' : 'birthday wishes to Bilbo', '2013-10-1 18:00' : 'Check into Inn of Prancing Pony' });
n DELETE todo['2012-9-24'] FROM users WHERE user_id = 'frodo';
n UPDATE users USING TTL 60 SET todo['2012-10-1'] = 'find water' WHEREuser_id = 'frodo';
注；可為上述三種集合類型的每個元素設定單獨的過期時間。
建立和使用索引
CREATE INDEXlast_name_key ON users(last_name);
SELECT * FROMusers WHERE last_name = 'Baggins'（需建立了索引才能在WHERE中使用該列進行查詢，暫無多列索引，需逐列分别建立索引）
輕量級事務
使用IF從句實作
n INSERT INTO emp(empid,deptid,address,first_name,last_name) VALUES(102,14,'luoyang','Jane Doe','li') IF NOT EXISTS;
n UPDATE emp SET address = 'luoyang' WHERE empid = 103 and deptid = 16IF last_name='zhang';
使用counter
用于記錄特定時間或處理的次數。對應的column需使用counter資料類型，該類資料一般存儲于專門的表中，且使用UPDATE載入并增減counter值，不使用INSERT插入counter值。隻能在原數值的基礎上增減，不能為直接指定一個數值。
CREATEKEYSPACE counterks WITH REPLICATION = { 'class' : 'SimpleStrategy','replication_factor' : 3 };
CREATE TABLEcounterks.page_view_counts
(counter_valuecounter,
url_name varchar,
page_name varchar,
PRIMARY KEY (url_name, page_name)
);
UPDATEcounterks.page_view_counts
SET counter_value = counter_value + 1
WHERE url_name='www.datastax.com' ANDpage_name='home';
若原來不存在WHERE條件中指定的内容，該條語句會将表中的url_name值置為'www.datastax.com'将page_name置為’home’,将counter_value指定為預設初始值0加1。若WHERE條件中指定的内容存在，則将counter_value置為原來的counter_value加1
UPDATEcounterks.page_view_counts
SET counter_value = counter_value + 2
WHERE url_name='www.baidu.com' ANDpage_name='map';
更多CQL内容請參見：http://www.datastax.com/documentation/cql/3.1/webhelp/index.html
6安全
三方面安全政策
Ø Client-to-node/node-to-node加密（SSL）：加密傳輸的資料
Ø 基于登入賬戶/密碼的認證：确定誰可以使用資料庫
Ø 對象授權管理：确定使用者可在在資料庫上幹什麼
6.1 SSL加密
6.1.1Client-to-node
準備證書
Ø 為每個節點産生私鑰/公鑰對
keytool-genkey -alias cassandra_vms00780 -keystore ~/keys/.keystore
Ø 導出公鑰部分到單獨的證書檔案，并拷貝該檔案到其他所有節點
keytool-export -alias cassandra_vms00780 -file ~keys/cassandra_vms00780.cer -keystore ~/keys/.keystore
Ø 将每個節點的證書添加到所有節點的信任庫中
keytool-import -v -trustcacerts -alias cassandra_vms00780 -file cassandra_vms00780.cer–keystore ~/keys/ .truststore
Ø 保證将.keystore和truststore檔案分發到所有節點
Ø 确認.keystore檔案隻對Cassandradaemon可讀
編輯配置檔案
配置cassandra.yaml檔案中client_encryption_options部分的參數
client_encryption_options:
enabled: true
keystore: ~keys/.keystore## .keystore file路徑
keystore_password:<keystore password> ## 産生keystore時用的密碼
truststore: ~keys/.truststore
truststore_password:<truststore password>
require_client_auth:<true or false>
6.1.2node-to-node
準備證書
同上
編輯配置檔案
配置cassandra.yaml檔案中server_encryption_options部分的參數
server_encryption_options:
internode_encryption: <internode_option:all/none/dc/rack>
keystore: ~keys/.keystore
keystore_password: <keystore password>
truststore:~keys/.truststore
truststore_password: <truststorepassword>
require_client_auth: <true or false>
6.1.3在cqlsh中使用SSL
可在主目錄依據樣例檔案cqlshrc.sample建立.cqlshrc檔案
[authentication]
username = cassandra
password = cassandra
[connection]
hostname = localhost
port = 9160
factory =cqlshlib.ssl.ssl_transport_factory
[ssl]
certfile =~/keys/cassandra.cert
validate = true
[certfiles]
192.168.1.3 =~/keys/cassandra01.cert
192.168.1.4 =~/keys/cassandra02.cert
6.2内部認證
基于Cassandra控制的登入賬戶和密碼
認證用的登入名和經bcrypt散列的密碼存儲于system_auth.credentials表中
6.2.1配置
第一步
Ø 若要使用基于使用者名/密碼的認證機制，需要先配置cassandra.yaml檔案中authenticator的值為PasswordAuthenticator（該參數預設值為AllowAllAuthenticator，即，不進行任何認證）。這樣cassandra會在system_auth.user建立一個超級使用者，使用者名和密碼均為cassandra。之後，配置system_auth這個keyspace的replication factor為較大的值（詳見第5章使用建立、更新keyspace部分的内容）
認證語句
Ø ALTER USER
ALTER USERuser_name WITH PASSWORD 'password' (NOSUPERUSER| SUPERUSER)
注：SUPERUSER可更改其他使用者的密碼和SUPERUSER狀态(NOSUPERUSER或 SUPERUSER)，但不能改變自己的SUPERUSER狀态。普通使用者隻能更改自己的密碼。
Ø CREATE USER
CREATE USERuser_name WITH PASSWORD 'password' (NOSUPERUSER| SUPERUSER)
隻有SUPERUSER可建立使用者，建立的使用者預設為NOSUPERUSER
Ø DROP USER
DROP USER user_name
隻有SUPERUSER可删除使用者，使用者不能自己删除自己。
Ø LIST USERS
LIST USERS（為什麼沒有結果？？？）
列出使用者
更改預設SUPERUSER
Ø 使用預設SUPERUSER也即cassandra登入
./cqlsh -ucassandra -p Cassandra
Ø 建立另一SUPERUSER，之後删除原cassandraSUPERUSER
create userus_yanzhaozhang with password 'cassandra' superuser;
drop usercassandra;
Ø 重新開機cassandra，使用新的SUPERUSER登入，執行後續操作。
6.2.2使用cqlsh登入
若使用cqlsh登入，可将認證資訊存儲于.cqlshrc文本檔案，放置在使用者主目錄中，以免重複錄入登入資訊。注意對該文本檔案設定對應的權限以防資訊洩露。
[authentication]
username = example_username
password = example_password
6.3内部授權
對象權限管理基于内部授權，與關系型資料庫GRANT/REVOKE文法類似。
首先要配置cassandra.yaml中authorizer的值為CassandraAuthorizer(預設為AllowAllAuthorizer，允許任何使用者的任何動作)，設定為該值後會将授權資訊存儲在system_auth.permissions表中。
之後，配置system_auth這個keyspace的replicationfactor為較大的值。
通過設定permissions_validity_in_ms選項調整權限有效期。
文法
GRANTpermission_name PERMISSION
| ( GRANT ALLPERMISSIONS ) ON resource TO user_name
REVOKE (permission_name PERMISSION )
| ( REVOKE ALLPERMISSIONS )
ON resourceFROM user_name
LISTpermission_name PERMISSION
| ( LIST ALLPERMISSIONS )
ON resource OF user_name
NORECURSIVE
其中permission_name為
Ø ALL
Ø ALTER
Ø AUTHORIZE
Ø CREATE
Ø DROP
Ø MODIFY
Ø SELECT
resource為
Ø ALL KEYSPACES
Ø KEYSPACE keyspace_name
Ø TABLE keyspace_name.table_name
6.4配置防火牆端口通路
需在防火牆政策中開放一下端口
Ø 公共端口
n 22 ssh端口
n 8888 OpsCenter website端口
Ø Cassandra節點間端口
n 1024+ JMX reconnection/loopback端口
n 7000 Cassand叢集内節點間通訊端口
n 7199 Cassandra JMX 監控端口
n 9160 Cassandra用戶端端口
Ø Cassandra OpsCenter 端口
n 61620 OpsCenter監控端口
n 61621 OpsCenter代理端口
7架構
7.1梗概
點對點分布式系統，叢集中各節點平等，資料分布于叢集中各節點，各節點間每秒交換一次資訊。每個節點的commit log捕獲寫操作來確定資料持久性。資料先被寫入memtable-記憶體中的資料結構，待該結構滿後資料被寫入SSTable-硬碟中的資料檔案。所有的寫内容被自動在叢集中分區并複制。
Cassandra資料庫面向行。授權使用者可連接配接至任意資料中心的任意節點，并通過類似SQL的CQL查詢資料。叢集中，一個應用一般包含一個keyspace，一個keyspace中包含多個表。
用戶端連接配接到某一節點發起讀或寫請求時，該節點充當用戶端應用與擁有相應資料的節點間的協調者(coordinator）以根據叢集配置确定環中的哪個節點當擷取這個請求。
關鍵詞
Ø Gossip：點對點通信協定，用以Cassandra叢集中節點間交換位置和狀态資訊。
Ø Partitioner：決定如何在叢集中的節點間分發資料，也即在哪個節點放置資料的第一個replica。
Ø Replica placement strategy：決定在哪些節點放置資料的其他replica。Cassandra在叢集中的多個節點存儲資料的多份拷貝-replicas來確定可靠和容錯。
Ø Snitch：定義了複制政策用來放置replicas和路由請求所使用的拓撲資訊
Ø cassandra.yaml檔案：Cassandra主配置檔案
Ø system:Cassandra的系統keyspace，存放table、keyspace的屬性資訊等。而屬性資訊可通過CQL或其他驅動設定。
7.2節點間通信
Cassandra使用點對點通訊協定gossip在叢集中的節點間交換位置和狀态資訊。gossip程序每秒運作一次，與至多3個其他節點交換資訊，這樣所有節點可很快了解叢集中的其他節點資訊。
配置gossip（在cassandra.ymal中設定）
Ø cluster_name:節點所屬叢集名，叢集中每個節點應相同。
Ø listen_address：供其他節點連接配接至該節點的IP位址或主機名，當由localhost設為公共位址。
Ø seed_provider：逗号分隔的IP位址（種子清單），gossip通過種子節點學習環的拓撲，叢集中各節點種子清單當相同。多資料中心叢集中每個資料中心的種子清單當至少包含一個該中心内的節點。
Ø storage_port：節點間通訊端口，叢集中各節點當一緻。
Ø initial_token：用于single-node-per-token結構，節點在環空間隻擁有一段連續的token範圍。
Ø num_tokens：用于virtual nodes，定義了節點在環空間所擁有的随機配置設定的token數目。
失敗檢測與恢複
Ø gossip可檢測其他節點是否正常以避免将請求路由至不可達或者性能差的節點（後者需配置為dynamic snitch方可）。
Ø 可通過配置phi_convict_threshold來調整失敗檢測的敏感度。
Ø 對于失敗的節點，其他節點會通過gossip定期與之聯系以檢視是否恢複而非簡單将之移除。若需強制添加或移除叢集中節點需使用nodetool工具。
Ø 一旦某節點被标記為失敗，其錯過的寫操作會有其他replicas存儲一段時間（需開啟hinted handoff，若節點失敗的時間超過了max_hint_window_in_ms，錯過的寫不再被存儲。）Down掉的節點經過一段時間恢複後需執行repair操作，一般在所有節點運作nodetool repair以確定資料一緻。
7.3資料複制和分發
Cassandra中分發、複制同時進行。Cassandra被設計為點對點系統，會建立資料的多個副本存儲在叢集中的一組節點中。Cassandra中資料被組織為表，由primary key辨別，primary key決定資料将被存儲在哪個節點。
需指定的内容
Virtual nodes：指定資料與實體節點的所屬關系
Partitioner：在叢集内劃分資料
Replicationstrategy：決定如何處理每行資料的replicas
Snitch：定義replicationstrategy放置資料的replicas時使用的拓撲資訊
一緻性哈希
表中每行資料由primary key辨別，Cassandra為每個primarykey配置設定一個hash值，叢集中每個節點擁有一個或多個hash值區間。這樣便可根據primary key對應的hash值将該條資料放在包含該hash值的hash值區間對應的節點中。
虛拟節點
使用虛拟接電視資料在叢集中的分布
若不使用虛拟節點則需手工為叢集中每個節點計算和配置設定一個token。每個token決定了節點在環中的位置以及節點應當承擔的一段連續的資料hash值的範圍。如上圖上半部分，每個節點配置設定了一個單獨的token代表環中的一個位置，每個節點存儲将row key映射為hash值之後落在該節點應當承擔的唯一的一段連續的hash值範圍内的資料。每個節點也包含來自其他節點的row的副本。而是用虛拟節點允許每個節點擁有多個較小的不連續的hash值範圍。如上圖中下半部分，叢集中的節點是用了虛拟節點，虛拟節點随機選擇且不連續。資料的存放位置也由row key映射而得的hash值确定，但是是落在更小的分區範圍内。
使用虛拟節點的好處
Ø 無需為每個節點計算、配置設定token
Ø 添加移除節點後無需重新平衡叢集負載
Ø 重建死掉的節點更快
Ø 改善了在同一叢集使用異種機器
資料複制
Cassandra在多個節點中存放replicas以保證可靠性和容錯性。replicationstrategy決定放置replicas的節點。replicas的總數由複制因子- replication factor确定，比如因子為2代表每行有兩份拷貝，每份拷貝存儲在不同的節點中。所有的replicas無主從之分。replication factor通常不能超過叢集中節點總數。然而，可現增加replication facto之後在将節點增至期望的數量。當replication facto超過總結點數時，寫操作被拒絕，但讀操作可進行，隻要滿足期望的一緻性級别。
目前有兩種可用的複制政策：
Ø SimpleStrategy：僅用于單資料中心，将第一個replica放在由partitioner确定的節點中，其餘的replicas放在上述節點順時針方向的後續節點中。
Ø NetworkTopologyStrategy：可用于較複雜的多資料中心。可以指定在每個資料中心分别存儲多少份replicas。在每個資料中心放置replicas的方式類似于SimpleStrategy，但傾向于将replicas放在不同rack，因為同一rack的節點傾向于同時失敗。配置每個資料中心分别放置多少replicas時要考慮兩個主要方面：(1)可滿足本地讀而非跨資料中心讀；(2)失敗場景。兩種常用的配置方式為(1)每個資料中心兩份replicas，(2)每個資料中心3份replicas。當然，用于特殊目的的非對稱配置也是可以的，比如在讀操作較頻繁的資料中心配置3份replicas而在用于分析的資料中心配置一份replicas。
複制政策在建立keyspace時指定，如
CREATEKEYSPACE Excelsior WITH REPLICATION = { 'class' : 'SimpleStrategy','replication_factor' : 3 };
CREATEKEYSPACE "Excalibur" WITH REPLICATION = {'class' :'NetworkTopologyStrategy', 'dc1' : 3, 'dc2' : 2};
其中dc1、dc2這些資料中心名稱要與snitch中配置的名稱一緻。
7.4Partitioners
在Cassandra中，table的每行由唯一的primarykey辨別，partitioner實際上為一hash函數用以計算primary key的token。Cassandra依據這個token值在叢集中放置對應的行。
三種partitioner(在cassandra.yaml中設定)
Ø Murmur3Partitioner：目前的預設值，依據MurmurHash哈希值在叢集中均勻分布資料。
Ø RandomPartitioner：依據MD5哈希值在叢集中均勻分布資料。
Ø ByteOrderedPartitioner：依據行key的位元組從字面上在叢集中順序分布資料。（不推薦使用）
Murmur3Partitioner和RandomPartitioner使用token向每個節點指派等量的資料進而将keyspace中的表均勻分布在環中，即使不同的表使用不同的primary key。讀寫請求均被均勻的分布。ByteOrderedPartitioner允許通過primary key順序掃描（可通過index達到同樣目的），但已引起如下問題(1)較複雜的負載均衡，(2)順序的寫易導緻熱點，(3)多表不均勻的負載均衡。
注意：若使用虛拟節點(vnodes)則無需手工計算tokens。若不使用虛拟節點則必須手工計算tokens将所得的值指派給cassandra.ymal主配置檔案中的initial_token參數。具體可參考：http://www.datastax.com/documentation/cassandra/2.0/webhelp/index.html#cassandra/architecture/../configuration/configGenTokens_c.html
7.5Snitches
提供網絡拓撲資訊，用以确定向/從哪個資料中心或者網架寫入/讀取資料。
注意：(1)所有節點需用相同的snitch;(2)叢集中已插入資料後由更改了snitch則需運作一次fullrepair。
Ø Dynamic snitching
監控從不同replica讀操作的性能，選擇性能最好的replica。dynamic snitch預設開啟，所有其他snitch會預設使用dynamic snitch 層。
Ø SimpleSnitch
預設值，用于單資料中心部署，不使用資料中心和網架資訊。使用該值時keyspace複制政策中唯一需指定的是replication factor
Ø RackInferringSnitch
根據資料中心和網架确定節點位置，而資料中心及網架資訊又有節點的IP位址隐含訓示。
Ø PropertyFileSnitch
根據資料中心和網架确定節點位置，而網絡拓撲資訊又由使用者定義的配置檔案cassandra-topology.properties 擷取。在節點IP位址格式不統一無法隐含訓示資料中心及網架資訊或者複雜的複制組中使用該值。需注意的是：(1)配置檔案中資料中心名需與keyspace中複制政策中指定的資料中心名稱一緻；(2)配置檔案中需包含叢集中任一節點；（3）叢集中各節點内cassandra-topology.properties配置檔案需相同。
Ø GossipingPropertyFileSnitch
Ø 在cassandra-rackdc.properties配置檔案中定義本節點所屬的資料中心和網架，利用gossip協定與其他節點交換該資訊。若從PropertyFileSnitch切至該值，則需逐節點逐次更新值為GossipingPropertyFileSnitch以確定gossip有時間傳播資訊。
Ø EC2Snitch
用于部署在Amazon EC2中且所有節點在單個區域中的叢集。
Ø EC2MultiRegionSnitch
Ø 用于部署在AmazonEC2中，且節點跨多個區域的叢集。
7.6用戶端請求
client連接配接至節點并發出read/write請求時，該node充當client端應用與包含請求資料的節點(或replica)之間的協調者，它利用配置的partitioner和replicaplacement政策确定那個節點當擷取請求。
7.6.1寫請求
協調者(coordinator)将write請求發送到擁有對應row的所有replica節點，隻要節點可用便擷取并執行寫請求。寫一緻性級别(write consistency level)确定要有多少個replica節點必須傳回成功的确認資訊。成功意味着資料被正确寫入了commit log個memtable。
上例為單資料中心，11個節點，複制因子為3，寫一緻性等級為ONE的寫情況。
7.6.2多資料中心的寫請求
基本同上，但會在各資料中心分别選擇一個協調者以處理該資料中心内的寫請求。與client直接連接配接的coordinator節點隻需将寫請求發送到遠端資料中心的coordinator一個節點即可，剩餘的由該coordinator完成。若一緻性級别設定為ONE或者LOCAL_QUORUM則僅與直接協調者位于同一資料中心的節點需傳回成功确認。
上例為雙單資料中心，各11個節點，複制因子為6，寫一緻性等級為ONE的寫情況。
7.6.3讀請求
Ø 直接讀請求
Ø 背景讀修複請求
與直接讀請求聯系的replica數目由一緻性級别确定。背景讀修複請求被發送到沒有收到直接讀請求的額外的replica，以確定請求的row在所有replica上一緻。
協調者首先與一緻性級别确定的所有replica聯系，被聯系的節點傳回請求的資料，若多個節點被聯系，則來自各replica的row會在記憶體中作比較，若不一緻，則協調者使用含最新資料的replica向client傳回結果。
同時，協調者在背景聯系和比較來自其餘擁有對應row的replica的資料，若不一緻，會向過時的replica發寫請求用最新的資料進行更新。這一過程叫read repair。
上例為單資料中心，11個節點，複制因子為3，一緻性級别為QUORUM的讀情況。
8資料庫内部
8.1資料管理
使用類似Log-StructuredMerge Tree的存儲結構，而非典型的關系型資料庫使用的B-Tree結構。存儲引擎連續的将資料以追加的模式寫物磁盤并持續存儲資料。節點間/内的操作并行運作。因不使用B-Tree故無需協同控制，在寫時不必執行更新。Cassandra在SSD中性能表現極佳。
高吞吐量和低延遲
操作并行運作，吞吐量和延遲互相獨立。log-structured設計避免詢盤開銷。去除on-disk資料修改，省時且延長SSD壽命。無on-disk型的資料修改故無需鎖定寫請求這樣的協同控制。無主、從，在所有節點運作同樣的代碼。
單獨的表目錄
/var/lib/cassandra/data/ks1/cf1/ks1-cf1-ja-1-Data.db
其中/var/lib/cassandra/data/為cassandra.yaml中指定的資料檔案目錄。ks1為keyspace名cf1/為columnfamilies名。這樣可将表連接配接至標明的目标位置以便于将活躍的表移到更快的存儲媒體，或者将表分不到多個可用的儲存設備以均衡負載
8.2關于寫
複制的角色
通過在多個同級節點建立資料的多個副本保證可靠性和容錯。表是非關系型的，無需過多額外工作來維護關聯的表的完整性，是以寫操作較關系型資料庫快很多。
寫過程
先将資料寫進記憶體中的資料結構memtable，同時追加到磁盤中的commitlog中。表使用的越多，對應的memtable應越大，cassandra動态的為memtable配置設定記憶體，也可自己手工指定。memtable内容超出指定容量後memtable資料（包括索引）被放進将被刷入磁盤的隊列，可通過memtable_flush_queue_size配置隊列長度。若将被刷入磁盤的資料超出了隊列長度，cassandra會鎖定寫。memtable表中的資料由連續的I/O刷進磁盤中的SSTable，之後commit log被清空。每個表有獨立的memtable和SSTable。
8.3關于更新、删除和hinted handoff writes
更新（cassandra中插入重複的primarykey也被看做是更新操作）
不直接在磁盤中原地更新而是先在memtable進行所有的更新。最後更新内容被刷入磁盤存儲在新的SSTable中，僅當column的時間戳比既存的column更新時才覆寫原來的資料。
删除
Ø 不會立即從磁盤移除删除的資料
被删除的資料會被tombstone标記以指定其狀态，它會存在一定的時間（由gc_grace_seconds指定），超出該時間後compaction程序永久删除該column。
Ø 若不例行性的執行節點repair操作，被删除的column可能重新出現
若删除期間節點down掉，被标記為tombstone的column會發送信号給Cassandra使其重發删除請求給該replica節點。若replica在gc_grace_seconds期間複活，會最終受到删除請求，若replica在gc_grace_seconds之後複活，節點可能錯過删除請求，而在節點恢複後立即删除資料。需定期執行節點修複操作來避免删除資料重制。
hinted handoff writes
在不要求一緻性時確定寫的高可用，在cassandra.yaml中開啟該功能。執行write操作時若擁有對應row的replica down掉了或者無回應，則協調者會在本地的system.hints表中存儲一個hint，訓示該寫操作需在不可用的replica恢複後重新執行。預設hints儲存3小時，可通過max_hint_window_in_ms改變該值。
提示的write不計入consistencylevel中的ONE，QUORUM或ALL，但計入ANY。ANY一緻性級别可確定cassandra在所有replica不可用時仍可接受write，并且在适當的replica可用且收到hint重放後該write操作可讀。
移除節點後節點對應的hints自動移除，删除表後對應的hints也會被移除。
仍需定期執行repair（避免硬體故障造成的資料丢失）
8.4關于讀
從SSD并行随機讀取，延時極低（不推薦cassandra使用轉盤式硬碟）。以partition key讀/寫，消除了關系型資料庫中複雜的查詢。
讀SSTable
首先檢查Bloom filter，每個SSTable都有一個Bloomfilter，用以在進行任何磁盤I/O前檢查請求的partition key對應的資料在SSTable中存在的可能性。若資料很可能存在，則檢查Partition key cache(Cassandra表partition index的緩存)，之後根據index條目是否在cache中找到而執行不同步驟：
Ø 找到
從compression offset map中查找擁有對應資料的壓縮快。
從磁盤取出壓縮的資料，傳回結果集。
Ø 未找到
搜尋Partition summary（partition index的樣本集）确定index條目在磁盤中的近似位置。
從磁盤中SSTable内取出index條目。
從compression offset map中查找擁有對應資料的壓縮快。
從磁盤取出壓縮的資料，傳回結果集。
回顧插入/更新資料
讀的過程
由insert/update過程可知，read請求到達某一節點後，必須結合所有包含請求的row中的column的SSTable以及memtable來産生請求的資料。
例如，要更新包含使用者資料的某個row中的email 列，cassandra并不重寫整個row到新的資料檔案，而僅僅将新的email寫進新的資料檔案，username等仍處于舊的資料檔案中。上圖中紅線表示Cassandra需要整合的row的片段用以産生使用者請求的結果。為節省CPU和磁盤I/O，Cassandra會緩存合并後的結果，且可直接在該cache中更新row而不用重新合并。
8.5關于事務和協同控制
不支援RDBMS中具有復原和鎖定機制的ACID事務，但提供了一定程度的原子性（行級）、隔離性（行級）、持久性和eventual/tunable 類型的一緻性（因不支援連接配接和外鍵，故不提供ACID場景下的一緻性）。
Ø 原子性
row-level，對一個row的插入/更新被當做一個原子操作。不支援要麼都做要麼都不做的多行插入/更新。不支援在一個replica上write成功而在其他replica上write失敗的復原。用時間戳确定column的最新更新。若多個session同時更新同樣的column則使用最近的更新。
Ø 一緻性
l Tuneable一緻性
提供partition容錯。使用者可以以單個操作為基礎決定需多少個節點接收DML操作或響應SELECT操作。
l Linearizable一緻性
l 輕量事務(compare-and-set)的一系列隔離級别。在tuneable一緻性不足以滿足要求時使用，如執行無間斷的相繼操作或同時/不同時運作一個操作産生同樣的結果。Cassandra2.0使用類似2-phase commit的Paxos consensus協定實作Linearizable一緻性。（為支援該一緻性引入了SERIAL類型的consistency level及在CQL中使用了帶IF從句的輕量事務）
Ø 隔離性
Cassandra2.0開始支援row-level的隔離性。對行的寫操作在完成之前對其他使用者不可見。
Ø 持久性
同時将資料寫入記憶體中的memtable及磁盤中的commit log。伺服器故障時若memtable尚未刷入磁盤，在故障恢複後可重放commit log恢複丢失資料。這提供了本地持久性。資料在其他節點的副本加強了持久性。
輕量事務
Cassandra2.0中引入，彌補Tuneable一緻性。
n INSERT INTO emp(empid,deptid,address,first_name,last_name) VALUES(102,14,'luoyang','Jane Doe','li') IF NOT EXISTS;
n UPDATE emp SET address = 'luoyang' WHERE empid = 103 and deptid = 16IF last_name='zhang';
8.6配置資料一緻性
Cassandra中，一緻性級别可配置，以确定請求的資料如何在不同的replica保持一緻性，進而平衡響應時間和資料精确性。
Ø 寫一緻性
指明在傳回确認至用戶端前，write操作必須成功的replica數。
l ANY：write至少在一個replica成功。即使所有replica 都down掉，在寫hinted handoff後write仍成功。在replica恢複後該write可讀。
l ONE：write必須成功寫入至少一個replica的commit log和memtable。
l TWO：至少兩個
l THREE：至少三個
l QUORUM：至少(replication_factor/ 2) + 1個
l LOCAL_QUORUM：至少(replication_factor/ 2) + 1個，且與協調者處于同一資料中心
l EACH_QUORUM：所有資料中心，至少(replication_factor/ 2) + 1個
l ALL：全部
l SERIAL：至少(replication_factor/ 2) + 1個，用于達成輕量事務的linearizable consistency
需注意的是：實際上write還是會被發到所有相關的replica中，一緻性級别隻是确定必需要回報的replica數。
Ø 讀一緻性
指明在傳回資料值用戶端前，需要相應read請求的相關replica數。Cassandra從這些數量的replica中根據時間戳檢查最新的資料。級别同寫一緻性。
可通過cqlsh指令CONSISTENCY設定keyspace的一緻性，也可程式設計設定一緻性。
9操作
9.1監控Cassandra叢集
工具：nodetool utility、DataStaxOpsCenter、JConsole
Ø nodetool utility：Cassandra發行版附帶的指令行工具，用于監控和正常資料庫操作。一些常用指令如status、cfstats、cfhistograms、netstats、tpstats等。
Ø DataStax OpsCenter：圖形使用者界面工具，從中央控制台監控和管理叢集中所有節點。
Ø JConsole：JMX相容工具用以監控java應用程式，提供Overview、Memory、Thread、Classes、VM summary、Mbeans方面的資訊。
9.2調整Bloom filters
Bloom filters用以在執行I/O前确定SSTable是否含特定的row。用于index掃描而不用于range掃描。通過bloom_filter_fp_chance參數配置其屬性值，範圍為0至1.0(關閉)，值越大則使用的記憶體越少，但也意味着若SSTable由較多碎片則導緻較高的磁盤I/O。預設值依賴于compaction_strategy類型。值的設定依賴工作負荷，如，若需在一特定表上運作繁重的scan則需将bloom_filter_fp_chance設定高一點。
通過如下語句設定：
ALTER TABLEaddamsFamily WITH bloom_filter_fp_chance = 0.1;
設定好後需使用Initiatecompaction或Upgrade SSTables方式之一重新産生Bloom filter。
9.3資料緩存
兩類cache：partitionkey cache和row cache
Ø partition key cache：Cassandra表partition index的cache
Ø row cache：一個row首次被通路後整個row(合并自多個對應的SSTable及memtable)被放在row cache中以便于後續對改row的通路能直接由記憶體擷取資料。
對于很少通路的archive表當禁用緩存。
開啟與配置cache
Ø 開啟
CREATE TABLEusers (
userid text PRIMARY KEY,
first_name text,
last_name text,
)
WITH caching ='all';
Ø 配置
在cassandra.yaml中，調整下列參數；
l key_cache_keys_to_save
l key_cache_save_period
l key_cache_size_in_mb
l row_cache_keys_to_save
l row_cache_size_in_mb
l row_cache_save_period
l row_cache_provider
工作原理：
第一個read操作直接命中rowcache，從記憶體取出資料。第二個read操作為命中row cache，但命中partition key cache，并由此整合所有相關的SSTable及memtable中的片段為請求的row，傳回row并寫進row cache。
cache使用優化建議
Ø 将很少請求的資料或row很長的資料放在cache較小或不使用cache的表中
Ø 用較多的節點部署各節點負載較輕的叢集
Ø 邏輯上将read稠密的資料分開在離散的表中
9.4配置memtable吞吐量
可改善write性能。Cassandra在commit logspace threshold超出時将memtables内容刷進磁盤建立SSTable。在cassandra.ymal中配置commit log space threshold來調整memtable吞吐量。配置的值依賴于資料和write負載。下列兩種情況可考慮增加吞吐量：
Ø write負載包含大量在小資料集上的更新操作
Ø 穩定持續的寫操作
9.5Compaction與Compression
9.5.1Compaction
周期性的背景程序。Compaction期間Cassandra通過整合row片段合并SSTable、移除過期的tombstones、重建索引等，并在新SSTable合并完成後移除舊的SSTable。
兩類Compaction
Ø SizeTieredCompactionStrategy
收集尺寸相近的SSTable合并為一個較大的SSTable。
Ø LeveledCompactionStrategy
建立相對較小的SSTable，尺寸被固定為不同等級（L0、L1、L2……），同一級内SSTable大小相同，每差一個等級尺寸差10倍。SSTable從較小的等級逐漸合并至較高的等級。
Compaction操作會臨時增加磁盤I/O，但完成後可改善read性能。
開啟與配置Compaction
Ø 使用CQL語句CREATE/ALTER TABLE
l ALTER TABLE users WITH
compaction = { 'class' : 'LeveledCompactionStrategy', 'sstable_size_in_mb' : 10 }
l ALTER TABLE users
WITH compaction ={'class' : 'SizeTieredCompactionStrategy','min_threshold' : 6 }
更多屬性參見CQL keyspace and table properties.
Ø 配置cassandra.yaml檔案
l snapshot_before_compaction
l in_memory_compaction_limit_in_mb
l multithreaded_compaction
l compaction_preheat_key_cache
l concurrent_compactors
l compaction_throughput_mb_per_sec
9.5.2Compression
通過減少資料體積和磁盤I/O來最大化存儲能力。大大提升讀性能且不會像傳統關系型資料庫中的Compression操作降低write性能。
什麼時候執行Compression
适用于擁有大量的row且每個row與其他row有一樣的column或盡可能多相同的column的表。越相似壓縮比越高，性能提升越明顯。row具有差異較大的column集的表不适于Compression。如Dynamic表。
配置好compression後後續建立的SSTable被壓縮，之前已經存在的SSTable不被立即壓縮直到正常的Cassandracompaction程序開始。可使用nodetool upgradesstables指令強制壓縮既存的SSTable
配置Compression
Ø 禁用
CREATE TABLEDogTypes (
block_id uuid,
species text,
alias text,
population varint,
PRIMARY KEY (block_id)
)
WITH compression = {'sstable_compression' : '' };
Ø 開啟
CREATE TABLEDogTypes (
block_id uuid,
species text,
alias text,
population varint,
PRIMARY KEY (block_id)
)
WITH compression = {'sstable_compression' : 'LZ4Compressor' };
Ø 調整
ALTER TABLECatTypes
WITH compression = { 'sstable_compression' :'DeflateCompressor', 'chunk_length_kb' : 64 }
9.6調整Java資源
性能下降或記憶體消耗過多時需考慮調整Java資源。有兩個檔案用于Cassandra中環境設定：
Ø comf/cassandra-env.sh：配置JVM
Ø bin、cassandra-in.sh：配置Cassandra環境變量
調整Heap尺寸時MAX_HEAP_SIZE與HEAP_NEWSIZE要同時設定，前者設定JVM最大heap尺寸，後者設定新生代的尺寸，新生代尺寸越大垃圾回收暫停時間越長，反之垃圾回收消耗越大。
目前預設配置：
| 系統記憶體 | Heap 大小 |
| 少于 2GB | 系統記憶體的1/2 |
| 2GB t到 4GB | 1GB |
| 大于 4GB | 系統記憶體的1/4，但不會超過8GB |
heap大小并非越大越好：首先Java6處理8GB以上的垃圾收集的能力會迅速縮減；其次會減少作業系統緩存頁所能使用的記憶體。
Cassandra1.2以後版本Bloomfilter和compression offset map是off-heap的，不算在JVM的heap之内。Cassandra2.0後partition summary也是off-heap的。若在Cassandra中使用JNA庫，row cache也會更新為off-heap。這些可幫減少heap大小，增強JVM GC性能，進而增加Cassandra高效處理每個節點中資料的能力。
若GC頻發發生且在适度的時間完成表明JVM GC壓力過大，此時需作出增加節點、降低cache大小、調整JVM中有關GC的參數等補救措施。
JavaManagement Extensions (JMX)提供了管理和監控Java應用和服務的各種工具。如JConsole,、the nodetool utility和 DataStax OpsCenter這些JMX相容工具。
comf/cassandra-env.sh中其他相關參數
Ø com.sun.management.jmxremote.port
Ø com.sun.management.jmxremote.ssl
Ø com.sun.management.jmxremote.authenticate
Ø -Djava.rmi.server.hostname
9.7修複 node
使用nodetool的repair指令，修複與給定的資料範圍相關的replica間的不一緻性。在下屬情形運作修複：
Ø 規律的、計劃的叢集維護操作期間（除非沒有執行過delete）
Ø 節點恢複後
Ø 在包含較少被通路的資料的節點上
Ø 在down掉的節點更新資料
運作節點修複的方針：
Ø 正常修複操作執行次數由gc_grace值硬性規定。需在該時間内在每個節點至少運作一次修複操作。
Ø 同時在多于一個的節點運作正常修複時需謹慎，最好在低峰期規律運作修複。
Ø 在很少delete或overwrite資料的系統中，可增加gc_grace的值。
修複操作消耗磁盤I/O，可通過下述途徑減輕：
Ø 使用nodetool的compactionthrottling選項。
Ø 使用nodetoolsnapshot之後從snapshot執行修複。
修複操作會導緻overstreaming（問題源于Cassandra内部Merkletrees資料結構）。比如隻有一個損壞的partition但卻需發送很多的stream，且若節點中存在的partition越多問題越嚴重。這會引起磁盤空間浪費和不必要的compaction。可使用subrange 修複來減輕overstreaming。subrange repair隻修複屬于節點的部分資料。
9.8添加/移除節點或資料中心
Ø 在既存叢集中添加節點
以使用vnodes的節點為例（推薦此種方式，虛拟節點相關内容見第7節）
1. 在新節點安裝Cassandra，關閉cassandra，清除資料。
2. 在cassandra.yaml和cassandra-topology.properties中配置如下屬性：
l cluster_name
l listern_address/broadcast_address
l endpoint_snitch
l num_tokens
l seed_provider
3. 逐個啟動新節點中的cassandra，不同節點的初始化之間保持兩分鐘的間隔。可用nodetool netstats監控啟動和資料流處理
4. 待所有新節點運作起來後逐個在每個之前已存在的節點執行nodetool cleanup來移除不再屬于這些節點的key。在下一個節點執行nodetool cleanup前必須等上一個節點中的nodetool cleanup結束。另外cleanup操作可考慮在低峰期進行。
Ø 向既存叢集中添加資料中心
以使用vnodes的節點構成的叢集為例
1. 確定keyspace使用NetworkTopologyStrategy複制政策
2. 對于每個新節點在cassandra.yaml中設定如下屬性
l auto_bootstrap: false.
l 設定其他與所屬叢集比對的屬性（參見上一部分：在既存叢集中添加節點）
3. 根據設定的snitch類型在各新節點配置對應的指明網絡拓撲的配置檔案（無需重新開機）
4. 確定使用的用戶端不會自動探測新的節點。
5. 若使用QUORUM一緻性級别，需檢查LOCAL_QUORUM或EACH_QUORUM一緻性級别是否滿足多資料中心的要求
6. 逐個在每個節點開啟cassandra。注意初始化時間間隔。
7. 所有節點運作起來後執行下列操作
Ø 替換死掉的節點
以使用vnodes的節點構成的叢集為例
1. 用nodetool status指令确認環中死掉的節點，從輸出中記錄該節點的HOST ID。
2. 添加并啟動新的替代節點（參見：在既存叢集中添加節點）
3. 使用nodetool removenode指令根據記錄的死亡節點的HOST ID從叢集中移除死掉的節點。
Ø 移除資料中心
1. 确認沒有client正在向資料中心内的任何節點寫資料
2. 在資料中心内的各節點中執行nodetool repair以確定資料從該中心得到正确的傳播。更改所有的keyspace屬性確定不再引用即将移除的資料中心。
3. 在資料中心内的各節點分别運作nodetool decommission
9備份恢複
Cassandra通過為磁盤中的資料檔案（SSTable檔案）建立快照來備份資料。可為單個表、單個keyspace、所有keyspace建立快照。可用并行SSH工具為整個叢集建立快照。建立時不保證所有replica一緻，但在恢複快照時Cassandra利用内建的一緻性機制保持一緻性。建立了系統範圍的快照後可開啟增量備份隻備份自上次快照以來變化了的資料（每當一個SSTable被flush後，一個對應的硬連結被拷貝至與/snapshot同級的/backups子目錄(需使用JNA)）。
若在Cassandra中使用了JNA，則快照通過硬連結建立。否則會因将檔案拷貝至不同的位置而增加磁盤I/O。
9.1建立快照
在每個節點執行nodetoolsnapshot指令為節點建立快照。也可通過并行SSH工具（如pssh）運作nodetool snapshot建立全局的快照。
$ nodetool -h localhost -p 7199 snapshot demdb
執行指令後首先會将記憶體中的資料刷進磁盤，之後為每個keyspace的SSTable檔案建立硬連結。快照的預設位置為/var/lib/cassandra/data/<keyspace_name>/<table_name>/snapshots。其中/var/lib/cassandra/data部分依據資料目錄設定而不同。
要保證空間充足，建立後可考慮移至其他位置。
9.2删除快照
建立新的快照并不會自動删除舊的快照，需在建立新快照前通過nodetool clearsnapshot指令移除舊的快照。
$ nodetool -h localhost -p 7199 clearsnapshot
同樣可通過并行SSH工具（如pssh）運作nodetoolclearsnapshot一次删除所有節點的快照。
9.3啟用增量備份
預設不開啟，可通過在各節點的cassandra.yaml配置檔案中設定incremental_backups為true來開啟增量備份。開啟後會為每個新的被刷入的SSTable建立一個硬連結并拷貝至資料目錄的/backups子目錄。
Cassandra不會自動删除增量備份檔案，建立新的快照前需手工移除舊的增量備份檔案。
9.4從快照恢複資料
需所有的快照檔案，若使用了增量備份還需快照建立之後所有的增量備份檔案。通常，在從快照恢複資料前需先truncate表。（若備份發生在delete前而恢複發生在delete後且沒truncate表時，則不能得到最原始的資料，因為直到compaction操作發生前被标記為tombstone的資料與原始資料處于不同的SSTable中，是以恢複包含原始資料的SSTable不會移除被标記被tombstone的資料，這些資料仍然顯示為将被删除）。
可以用如下方式從快照恢複資料
Ø 使用sstableloader工具
http://www.datastax.com/documentation/cassandra/2.0/webhelp/cassandra/tools/toolsBulkloader_t.html
Ø 先拷貝snapshot目錄中的快照檔案至相應資料目錄。之後通過JConsole調用column family MBean 中的JMX方法loadNewSSTables()或者使用nodetool refresh指令而不調用上述方法。
Ø 使用重新開機節點的方式
1. 若恢複單節點則先關閉該節點，若恢複整個叢集則需先關閉所有節點
2. 清除/var/lib/cassandra/commitlog中的所有檔案
3. 删除<data_directory_location>/<keyspace_name>/<table_name>中所有*.db檔案
4. 拷貝最新<data_directory_location>/<keyspace_name>/<table_name>/snapshots/<snapshot_name>的快照檔案至<data_directory_location>/<keyspace_name>/<table_name>/snapshots/<snapshot_name>
5. 若使用了增量備份則還需拷貝<data_directory_location>/<keyspace_name>/<table_name>/backups中的内容至<data_directory_location>/<keyspace_name>/<table_name>
6. 重新開機節點
7. 運作nodetool repair
10工具
Ø nodetool：管理Cassandra叢集的指令行工具
http://www.datastax.com/documentation/cassandra/2.0/webhelp/index.html#cassandra/tools/toolsNodetool_r.html
Ø sstableloader：載入大量外部資料至一叢集；将已經存在的SSTable載入到另外一個節點數不同或者複制政策不同的叢集；從快照恢複資料。上述操作無需停機。
http://www.datastax.com/documentation/cassandra/2.0/webhelp/index.html#cassandra/tools/toolsBulkloader_t.html
Ø cassandra：啟動cassandra 伺服器程序
http://www.datastax.com/documentation/cassandra/2.0/webhelp/index.html#cassandra/tools/toolsCUtility_t.html
Ø cassandra-stress：基于java的Cassandra叢集壓力測試工具。
http://www.datastax.com/documentation/cassandra/2.0/webhelp/index.html#cassandra/tools/toolsCStress_t.html
Ø cassandra-shuffle：在不停機的狀态下将single-token-per-node的結構轉化為使用虛拟節點的結構。
http://www.datastax.com/documentation/cassandra/2.0/webhelp/index.html#cassandra/tools/toolsCassandraShuffle.htm
Ø sstablescrub：清洗指定的表的SSTable。
http://www.datastax.com/documentation/cassandra/2.0/webhelp/index.html#cassandra/tools/toolsSSTableScrub_t.html
Ø sstable2json/json2sstable：前者将磁盤中表示表的SStable轉化為JSON格式的文檔，用于調試和測試目的；後者做反向轉換。
http://www.datastax.com/documentation/cassandra/2.0/webhelp/index.html#cassandra/tools/toolsSStable2json_t.html
http://www.datastax.com/documentation/cassandra/2.0/webhelp/index.html#cassandra/tools/toolsJson2sstable_t.html
Ø sstablekeys：sstable2json –e 的縮寫，僅作用于key。
http://www.datastax.com/documentation/cassandra/2.0/webhelp/index.html#cassandra/tools/toolsSStabkeys_t.html
Ø sstableupgrade：将特定表中或快照中的SSTable更新至比對目前Cassandra版本。
http://www.datastax.com/documentation/cassandra/2.0/webhelp/index.html#cassandra/tools/ToolsSSTableupgrade_t.html
參考
http://www.datastax.com/documentation/cassandra/2.0/webhelp/index.html