認識Cassandra

Cassandra

Apache Cassandra 是一個開源的、分布式、去中心化、彈性可擴展、高可用性、容錯、一致性可調(diào)、面向行的數(shù)據(jù)庫，它基于 Amazon Dynamo 的分布式設計和 Google Bigtable 的數(shù)據(jù)模型。它最初由 Facebook 創(chuàng)建，用于儲存收件箱等簡單格式數(shù)據(jù)，于2008年開源。此后，由于 Cassandra 良好的可擴展性，被 Digg、Twitter 等知名 Web 2.0 網(wǎng)站所采納，成為了一種流行的分布式結構化數(shù)據(jù)存儲方案。

截止目前，Apache Cassandra 最新版本為 3.7。

Apache Cassandra 官方網(wǎng)站為 http://cassandra.apache.org/。

簡介

Cassandra 是 Facebook 于2008年7月在 Google Code 上開源的項目，最早是由 Amazon 前雇員和一位 Microsoft 的工程師寫成的。這個系統(tǒng)受到 Amazon Dynamo 的巨大影響（有關 Amazon Dynamo 的介紹，可以查閱論文《Dynamo: Amazon’s Highly Available Key-value Store》，網(wǎng)址為http://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf）。Cassandra 實現(xiàn)了 Dynamo 風格的副本復制模型和沒有單點失效的架構，增加了更加強大的 column family 數(shù)據(jù)模型。

之后，在2009年1月，Cassandra 被接納為 Apache 基金會的孵化器項目，并于2010年3月畢業(yè)后成為了頂級項目。此時，很多知名公司包括 Facebook、Rackspace、Digg、Twitter 等都成為了 Cassandra 的用戶。

有關 Cassandra 論文，最早可見由 Facebook 的 Lakshman 和 Malik 發(fā)表的《A Decentralized Structured Storage System》（在線閱讀地址為 http://www.cs.cornell.edu/projects/ladis2009/papers/lakshman-ladis2009.pdf）。在 Cassandra 2.0 發(fā)布以后，Jonathan Ellis 對該論文相應的做了修改，發(fā)表于 http://docs.datastax.com/en/articles/cassandra/cassandrathenandnow.html。

伴隨著業(yè)界對于 Cassandra 商業(yè)化、產(chǎn)品化的需求，在2010年4月 Apache Cassandra 項目主席 Jonathan Ellis 以及其同事 Matt Pfeil 成立了一家服務公司，稱為 DataStax（原先的名字為 Riptano）。DataStax 雇傭了多名 Cassandra 貢獻者，成為了領導和支持 Cassandra 項目的主力。

2015年11月，Cassandra 發(fā)布了 3.0 版本，其底層的存儲引擎已被重寫，支持全局索引，支持 Java 8，并將基于 Thrift 命令行界面給移除了。

Apache Cassandra 具有如下特性：

1. 分布式與去中心化

Cassandra 是分布式的，這意味著它可以運行在多臺機器上，并呈現(xiàn)給用戶一個一致的整體。

對于很多存儲系統(tǒng)（如 MySQL、Bigtable、HBase 等），一旦你開始擴展它，就需要把某些節(jié)點設為主節(jié)點，其他則作為從節(jié)點。但 Cassandra 是去中心的，也就是說每個節(jié)點都是一樣的，沒有節(jié)點會承擔特殊的管理任務。與主從模式（master-slave）相反，Cassandra 的協(xié)議是 P2P 的，并使用 gossip 來維護存活或死亡節(jié)點的列表。

去中心化這一事實意味著 Cassandra 不會存在單點失效。Cassandra 集群中的所有節(jié)點的功能都完全一樣， 所以不存在一個特殊的主機作為主節(jié)點來承擔協(xié)調(diào)任務。有時這被叫做“server symmetry（服務器對稱）”。

綜上所述，因為 Cassandra 是分布式、去中心化的，它不會有單點失效的問題，所以支持高可用性。

2. 彈性可擴展

可擴展性是指系統(tǒng)架構可以讓系統(tǒng)提供更多的服務而不降低使用性能的特性。最簡單的達到可擴展性的手段，就是給現(xiàn)有的機器增加硬件的容量、內(nèi)存進行垂直擴展。而水平擴展則需要增加更多機器，每臺機器提供全部或部分數(shù)據(jù)，這樣所有主機都不必負擔全部業(yè)務請求。但軟件自己需要有內(nèi)部機制來保證集群中節(jié)點間的數(shù)據(jù)同步。

彈性可擴展是指水平擴展的特性，意即你的集群可以不間斷的情況下，方便擴展或縮減服務的規(guī)模。這樣，你就不需要重新啟動進程，不必修改應用的查詢，也無需自己手工重新均衡數(shù)據(jù)分布。在 Cassandra 里，你只要加入新的計算機，Cassandra 就會自動地發(fā)現(xiàn)它并讓它開始工作。

3. 高可用與容錯

系統(tǒng)的可用性是由滿足請求的能力來量度的。但計算機可能會有各種各樣的故障，從硬件器件故障到網(wǎng)絡中斷都有可能。所以它們一般都有硬件冗余，并在發(fā)生故障事件的情況下會自動響應并進行熱切換。從軟件的層次來說，設置多個數(shù)據(jù)中心，就是“軟件冗余”，它能保障在災難發(fā)生時，故障中斷的功能在剩余系統(tǒng)上能夠進行恢復。

Cassandra 就是高可用的。你可以在不中斷系統(tǒng)的情況下替換故障節(jié)點，還可以把數(shù)據(jù)分布到多個數(shù)據(jù)中心里，從而提供更好的本地訪問性能，并且在某一數(shù)據(jù)中心發(fā)生火災、洪水等不可抗災難的時候防止系統(tǒng)徹底癱瘓。

4. Tuneable Consistency（可調(diào)一致性）

一致性的基本含義是讀操作一定會返回最新寫入的結果。擴展數(shù)據(jù)存儲系統(tǒng)就意味著我們不得不在數(shù)據(jù)一致性、節(jié)點可用性和分區(qū)容錯性之間做某些折衷（即 CAP 理論）。Cassandra 常被稱作是“最終一致性”的，簡單地說，Cassandra 犧牲了一點一致性來換取了完全的可用性。但是 Cassandra 實際更應該表述為“可調(diào)一致性”，它允許你來方便地選定需要的一致性水平與可用性水平，在二者間找到平衡點。

因為客戶端可以控制在更新到達多少個副本之前，必須阻塞系統(tǒng)。這是通過設置 replication factor（副本因子）來調(diào)節(jié)與之相對的一致性級別。
通過 replication factor，你可以決定準備犧牲多少性能來換取一致性。 replication factor 是你要求更新在集群中傳播到的節(jié)點數(shù)（注意，更新包括所有增加、刪除和更新操作）。

客戶端每次操作還必須設置一個 consistency level（一致性級別）參數(shù)，這個參數(shù)決定了多少個副本寫入成功才可以認定寫操作是成功的，或者讀取過程中讀到多少個副本正確就可以認定是讀成功的。這里，Cassandra 把決定一致性程度的權利留給了客戶自己。

所以，如果需要的話，你可以設定 consistency level 和 replication factor 相等，從而達到一個較高的一致性水平，不過這樣就必須付出同步阻塞操作的代價，只有所有節(jié)點都被更新完成才能成功返回一次更新。而實際上，Cassandra 一般都不會這么來用，原因顯而易見（這樣就喪失了可用性目標，影響性能，而且這不是你選擇 Cassandra 的初衷）。而如果一個客戶端設置 consistency level 低于 replication factor 的話，即使有節(jié)點宕機了，仍然可以寫成功。

5. Row-Oriented（面向行）

Cassandra 不是真正意義上的“Column-Oriented（面向列）”的數(shù)據(jù)庫而是“Row-Oriented（面向行）”， 它的數(shù)據(jù)結構不是關系型的，而是一個多維稀疏哈希表?！跋∈琛币馕吨魏我恍卸伎赡軙幸涣谢蛘邘琢?，但每行都不一定（像關系模型那樣）和其他行有一樣的列。每行都有一個唯一的鍵值，用于進行數(shù)據(jù)訪問。所以，更確切地說，應該把 Cassandra 看做是一個有索引的、Row-Oriented 的存儲系統(tǒng)。

Cassandra 的數(shù)據(jù)存儲結構基本可以看做是一個多維哈希表。這意味著你不必事先精確地決定你的具體數(shù)據(jù)結構或是你的記錄應該包含哪些具體字段。這特別適合處于草創(chuàng)階段，還在不斷增加或修改服務特性的應用。而且也特別適合應用在敏捷開發(fā)項目中，不必進行長達數(shù)月的預先分析。對于使用 Cassandra 的應用，如果業(yè)務發(fā)生變化了，只需要在運行中增加或刪除某些字段就行了，不會造成服務中斷。

當然， 這不是說你不需要考慮數(shù)據(jù)。相反，Cassandra 需要你換個角度看數(shù)據(jù)。在 RDBMS 里， 你得首先設計一個完整的數(shù)據(jù)模型， 然后考慮查詢方式， 而在 Cassandra 里，你可以首先思考如何查詢數(shù)據(jù)，然后提供這些數(shù)據(jù)就可以了。

6. Flexible Schema（靈活的模式）

早期版本的 Cassandra 是忠實于 Bigtable 的設計，而采用的是“schema-free（無模式）”的數(shù)據(jù)模型，新的 column 可以被動態(tài)定義。schema-free 模式的數(shù)據(jù)庫在處理大數(shù)據(jù)時有非常強的擴展和高性能的優(yōu)勢。但這種模式的主要缺點是在確定數(shù)據(jù)的含義和數(shù)據(jù)的格式時存在難點，而這限制了執(zhí)行復雜查詢的能力。

Cassandra Query Language（CQL）正是為了解決上面提到的問題。CQL 它提供了一種通過類似于 Structured Query Language（SQL）的語法來定義的模式。起初，CQL 是基于 Apache Thrift 項目的 schema-free 接口來提供額外的 Cassandra 接口的。在這個過渡階段，模式是可選的，可以通過 CQL 來定義，也可以通過 Thrift API 來實現(xiàn)在添加新的 column 時動態(tài)擴展。

自 Cassandra 3.0 以來，將不推薦采用通過基于 Thrift API 來實現(xiàn)動態(tài)創(chuàng)建 column 的方式。Cassandra 的底層存儲已重新實現(xiàn)，并與 CQL 更緊密地結合起來。Cassandra 并不限制動態(tài)擴展模式，但它的工作方式已經(jīng)顯著的不同了。CQL 的集合，如 list、set，特別是 map 提供在無結構化的格式里面添加內(nèi)容的能力，從而能擴展現(xiàn)有的模式。CQL 還提供了改變列的類型的能力，以支持 JSON 格式的文本的存儲。

因此， Cassandra 是支持“靈活的模式”。

7. 高性能

Cassandra 在設計之初就特別考慮了要充分利用多處理器和多核計算機的性能，并考慮在分布于多個數(shù)據(jù)中心的大量這類服務器上運行。它可以一致而且無縫地擴展到數(shù)百臺機器。Cassandra 已經(jīng)顯示出了高負載下的良好表現(xiàn)，在一個非常普通的工作站上，Cassandra 也可以提供非常高的寫吞吐量。而如果你增加更多的服務器，你還可以繼續(xù)保持 Cassandra 所有的特性而無需犧牲性能。

Cassandra 應用場景

盡管 Cassandra 設計精巧、功能出色，但也并非能勝任所有工作。所以，這里我們來介紹一下 Cassandra 最擅長的領域。

1. 大規(guī)模部署

Cassandra 的很多精巧設計都專注于高可用、可調(diào)一致性、P2P 協(xié)議、無縫擴展等，這些都是 Cassandra 的賣點。這些特性在單節(jié)點工作時都是沒有意義的，更無法展現(xiàn)它的全部能力。所以，你需要做一些評估，考慮你期望的流量、吞吐需求以及 SLA 等。如果你認為有幾種關系型數(shù)據(jù)庫可以很好地應付你的流量，提供不錯的性能，那可能選關系型數(shù)據(jù)庫更好。簡單地說，這是因為 RDBMS 更易于在單機上運行，對你來說也更熟悉。

但是，如果你認為需要至少幾個節(jié)點才能支撐你的業(yè)務，那 Cassandra 就是個不錯的選擇。如果你的應用可能需要數(shù)十個節(jié)點，那 Cassandra 可能就是個很棒的選擇了。

2. 寫密集、統(tǒng)計和分析型工作

Cassandra 是為優(yōu)異的寫吞吐量而特別優(yōu)化的。許多早期使用 Cassandra 的產(chǎn)品都用于存儲用戶狀態(tài)更新、社交網(wǎng)絡、建議/評價以及應用統(tǒng)計等。這些應用大都是寫多于讀的，并且更新可能隨時發(fā)生并伴有突發(fā)的峰值。事實上，支撐應用負載需要很高的多客戶線程并發(fā)寫性能，這正是 Cassandra 的主要特性。

Cassandra 已經(jīng)被用于開發(fā)了多種不同的應用，包括窗口化的時間序列數(shù)據(jù)庫，用于文檔搜索的反向索引，以及分布式任務優(yōu)先級隊列。

3. 地區(qū)分布

Cassandra 直接支持多地分布，可以很容易配置成將數(shù)據(jù)分布到多個數(shù)據(jù)中心的存儲方式。如果你有一個全球部署的應用，那么讓數(shù)據(jù)貼近用戶會獲得不錯的性能收益，Cassandra 正適合這種應用場合。

4. 變化的應用

如果你正在“初創(chuàng)階段”，業(yè)務會不斷改進，Cassandra 這種靈活的模式的數(shù)據(jù)模型可能更適合你。這讓你的數(shù)據(jù)庫能更快地跟上業(yè)務改進的步伐。

Cassandra 架構、數(shù)據(jù)模型

Cassandra 是設計來處理跨多個節(jié)點的大數(shù)據(jù)工作負載，且不會產(chǎn)生單點故障問題。它的架構是基于對系統(tǒng)和硬件故障也時有發(fā)生的理解，即計算機的故障不可避免。Cassandra 通過在集群中的所有節(jié)點之間分布均勻的節(jié)點，采用 P2P 的方式來定位分布式系統(tǒng)涉及的故障問題。每個節(jié)點經(jīng)常交流有關其自身的狀態(tài)信息，其他節(jié)點利用 P2 gossip 通信協(xié)議與集群進行交互。Commit 日志在每個節(jié)點上會依次寫入活動信息，以確保數(shù)據(jù)的持久性，然后數(shù)據(jù)被索引并寫入內(nèi)存結構 memtable 中。memtable 類似于一個回寫高速緩存。每次這個內(nèi)存結構滿時，數(shù)據(jù)就被寫入磁盤中的 SSTable 數(shù)據(jù)文件中。所有的寫操作都會自動分區(qū)，并在整個集群中進行復制。Cassandra 定期合并使用一種稱為 compaction 過程來合并 SSTable，合并過程中會丟棄標記為 tombstone 的數(shù)據(jù)。為了確保所有的數(shù)據(jù)在整個集群保持一致，不同的修復機制將被使用。

Cassandra 是一個分區(qū) row 存儲數(shù)據(jù)庫，其中 row 被組織成一個必需有主鍵的 table。 Cassandra 的架構允許任何已授權的用戶可以使用 CQL 語言來連接到任何數(shù)據(jù)中心的任何節(jié)點。為了方便使用，CQL 使用了類似的 SQL 的語法來操作表數(shù)據(jù)。開發(fā)人員可以通過 cqlsh、DevCenter 或者應用語言的驅動程序來訪問 CQL。通常情況下，集群都每個應用程序都會有一個 keyspace （密鑰空間），由許多不同的 table 組成。

客戶端讀取或寫入請求可以被發(fā)送到集群中的任何節(jié)點。當客戶端通過一個請求連接到一個節(jié)點時，則該節(jié)點充當協(xié)調(diào)器用于該客戶端特定的操作。協(xié)調(diào)器充當客戶端應用程序和擁有被請求數(shù)據(jù)的節(jié)點之間的代理。協(xié)調(diào)器來決定在哪些節(jié)點能收到請求，這往往是基于集群的配置要求。

Cassandra 包含如下核心構件：

  • Node（節(jié)點）：存儲數(shù)據(jù)的地方。它是 Cassandra 的基礎設施組件。
  • Data center（數(shù)據(jù)中心）：相關節(jié)點的集合。數(shù)據(jù)中心可以是物理數(shù)據(jù)中心或虛擬數(shù)據(jù)中心。不同的工作負載應使用單獨的數(shù)據(jù)中心，無論是物理的還是虛擬。復制是由數(shù)據(jù)中心的設置。使用單獨的數(shù)據(jù)中心可以防止由其他工作負荷受到影響卡桑德拉交易，并保持彼此接近為較低的延遲請求。根據(jù)不同的復制因子，可將數(shù)據(jù)寫入到多個數(shù)據(jù)中心。數(shù)據(jù)中心必須永遠跨越物理位置。
  • Cluster（集群）：一個集群包含一個或多個數(shù)據(jù)中心。它可以跨越物理位置。
  • Commit log（Commit 日志）：
    所有數(shù)據(jù)首先被寫入 Commit 日志以確保數(shù)據(jù)的持久性。當其所有的數(shù)據(jù)已沖刷到 SSTable 時，它可以存檔、刪除或回收。
  • SSTable：
    SSTable（sorted string table，經(jīng)排序的字符串表）是 Cassandra 定期寫 memtable 的不變的數(shù)據(jù)文件。SSTable 僅追加并在磁盤上依次存儲并保持 Cassandra table。
  • CQL Table：
    通過 table row 獲取到的有序的 column 集合。table 由 column 和一個主鍵組成。

用于配置 Apache Cassandra 的核心組件

1. Gossip

P2P 通信協(xié)議用于發(fā)現(xiàn)和分享在 Cassandra 集群中的其他節(jié)點的位置和狀態(tài)信息。Gossip 信息也保存在每個節(jié)點本地，當一個節(jié)點重新啟動時可以被立即使用。

2. Partitioner（分區(qū)工具）

partitioner 用于確定哪些節(jié)點先接收第一個數(shù)據(jù)片段的副本，以及如何分配其他副本到集群的其他節(jié)點上。數(shù)據(jù)的每一 row 由唯一的主鍵來識別，該主鍵可以與 partition key（分區(qū)鍵）相同，但也可能包括了其他 clustering column。一個 partitioner 是一個是哈希函數(shù)，用于從 row 的主鍵中派生一個 token。partitioner 使用 token 值，以確定集群中哪些節(jié)點來接收該 row 的副本。Murmur3Partitioner 是新的 Cassandra 集群默認分區(qū)策略，在大部分情況下，也是在新的集群的正確選擇。

必須設置 partitioner，并為每個節(jié)點分配 num_tokens 值。token 的分配數(shù)量取決于系統(tǒng)的硬件功能。如果不能使用 virtual nodes（vnodes，虛擬節(jié)點），請使用 initial_token 設置來代替。

3. Replication factor（副本因子）

replication factor 是指集群副本的總數(shù)。replication factor 為 1 意味著一個節(jié)點上每個 row 僅有一個副本；為 2 意味著 每個 row 有2個副本，且每個副本位于不同節(jié)點上。所有副本都同樣重要，不區(qū)分是否是主副本。您需要為每個數(shù)據(jù)中心定義 replication factor。通常應設置策略大于1，但不超過集群中節(jié)點總數(shù)。

4. Replica placement strategy（副本放置策略）

Cassandra 存儲數(shù)據(jù)的副本到多個節(jié)點，以確?？煽啃院腿蒎e性。復制策略決定哪些節(jié)點需要放置到副本上。第一個數(shù)據(jù)的副本是簡單的第一拷貝，它并不是唯一的。強烈建議大多數(shù)部署情況下使用 NetworkTopologyStrategy ，因為它在需要時更容易擴展到多個數(shù)據(jù)中心。

當創(chuàng)建一個 keyspace（密鑰空間），你必須定義副本放置策略和副本數(shù)。

5. Snitch

snitch 定義了數(shù)據(jù)中心的計算機組以及復制策略用于放置副本的機架（拓撲）。

當你創(chuàng)建一個集群時，必須配置一個 snitch。所有 snitch 使用動態(tài) snitch 層，來監(jiān)控性能，并選擇最佳副本來用于讀取。它是默認是啟用的，并推薦在大多數(shù)部署情況下使用。在 cassandra.yaml 配置文件里面來配置每個節(jié)點的動態(tài) snitch 閾值。

默認 SimpleSnitch 不能識別的數(shù)據(jù)中心或機架的信息，可以在公共云的單數(shù)據(jù)中心部署或單區(qū)中使用它。建議在生產(chǎn)環(huán)境中使用 GossipingPropertyFileSnitch ，它定義了一個節(jié)點的數(shù)據(jù)中心和機架，并且使用 gossip 來傳播該信息到其他節(jié)點。

6. cassandra.yaml 配置文件

主配置文件用于設置集群的初始化屬性，比如 table 參數(shù)的緩存、調(diào)節(jié)屬性和資源利用率、超時設置、客戶端連接、備份、安全等。

默認情況下，節(jié)點被配置用于存儲受其管理的設置在 cassandra.yaml 文件的目錄下的數(shù)據(jù)。

在集群的生產(chǎn)部署環(huán)境，可以修改 commitlog-directory 目錄到與 data_file_directories 不同的磁盤驅動下。

7. 系統(tǒng) keyspace table 屬性

你可以通過基本的編程方式來設置每個 keyspace 或 table 的存儲配置屬性，或者使用客戶端應用，比如 CQL。

Cassandra 安裝、配置、使用

本節(jié)將演示 Apache Cassandra 安裝、配置，以及通過命令行來使用 Cassandra。

1. 前置條件

2. 從編譯包來安裝

tar -xvf apache-cassandra-3.6-bin.tar.gz cassandra

解壓后的目錄名為 apache-cassandra-3.6。

  • 可以選擇添加 apache-cassandra-3.6\bin 到您的路徑。
  • 通過執(zhí)行命令行bin/cassandra -f來在前臺啟動 Cassandra 按“Ctrl-C”來停止 Cassandra。通過執(zhí)行命令行bin/cassandra來在后臺啟動 Cassandra。調(diào)用 kill pid 或 pkill -f CassandraDaemon來停止 Cassandra，其中 pid 是 Cassandra 的進程 ID，您可以通過pgrep -f CassandraDaemon來查詢。
  • 調(diào)用bin/nodetool status來驗證 Cassandra 是否在運行。
  • 配置文件位于在conf子目錄。
  • 自 Cassandra 2.1 以來，日志和數(shù)據(jù)目錄分別位于logs和data子目錄下。舊版本默認在 /var/log/cassandra 和 /var/lib/cassandra。由于這一點，就必須要么使用 root 權限或改變conf/ cassandra.yaml中當前用戶所使用的用戶目錄。

3. 從 Debian 包來安裝

  • 添加 Cassandra 的 repository（倉庫）到 /etc/apt/sources.list.d/cassandra.sources.list，例如 3.6 版本的配置如下：
echo "deb http://www.apache.org/dist/cassandra/debian 36x main" | sudo tee -a /etc/apt/sources.list.d/cassandra.sources.list
  • 更新 repository
sudo apt-get update
  • 如果遇到如下錯誤：
GPG error: http://www.apache.org 36x InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 749D6EEC0353B12C

就按如下方式來添加公鑰749D6EEC0353B12C（該密鑰要根據(jù)你實際的出錯信息來獲?。?

gpg --keyserver pgp.mit.edu --recv-keys 749D6EEC0353B12C
gpg --export --armor 749D6EEC0353B12C | sudo apt-key add -

并再次執(zhí)行 sudo apt-get update。

  • 安裝 Cassandra：
sudo apt-get install cassandra
  • 執(zhí)行 sudo service cassandra start來啟動 Cassandra，執(zhí)行 sudo service cassandra stop來停止。
  • 執(zhí)行nodetool status來驗證 Cassandra 是否在運行。
  • 默認配置文件路徑在/etc/cassandra。
  • 默認的日志和數(shù)據(jù)目錄在/var/log/cassandra/和/var/lib/cassandra。

4. 配置集群

上述運行一個單節(jié)點 Cassandra，但若要部署集群，還要進行一些列參數(shù)的配置。

Cassandra 的配置文件在安裝文件的conf目錄下， 對于包，配置文件將位于/etc/cassandra。

（1）主運行屬性

大多數(shù)配置都在 cassandra.yaml文件中配置，你至少需要配置下面的屬性：

  • cluster_name：集群的名稱；
  • seeds：用逗號分隔的集群種子的 IP 地址列表;
  • storage_port：這項不一定要改，但請確保沒有防火墻阻止此端口；
  • listen_address：您的節(jié)點的 IP 地址，通過它來讓其他節(jié)點與該節(jié)點進行通信?；蛘撸部梢栽O置listen_interface告訴 Cassandra 哪些接口可以使用，使用哪個連續(xù)的地址。設置一個即可，不能同時使用。
    native_transport_port：作為storage_port，確保此端口不會被阻止通過防火墻的客戶端將與卡桑德拉此端口上進行通訊。

（2）更改目錄位置

下面是屬性是控制目錄的位置。

  • data_file_directories：一個或多個數(shù)據(jù)文件位置的目錄；
  • commitlog_directory：commit log 文件所在的目錄；
  • saved_caches_directory：其中保存的緩存的位置目錄；
  • hints_directory： hints 所在的目錄。

由于性能原因，如果你有多個磁盤，考慮將 commit log 和數(shù)據(jù)文件放在不同的磁盤。

（3）環(huán)境變量

可以在cassandra-env.sh進行 JVM 參數(shù)的設置，如堆大小等。您可以添加任何額外的 JVM 命令行參數(shù)到 JVM_OPTS環(huán)境變量，當 Cassandra 啟動時，這些參數(shù)將被傳遞給 JVM。

（4）日志

日志框架是使用的 logback?？梢孕薷?code>logback.xml來修改日志屬性。默認日志 INFO 級別是記錄在 system.log 文件，而 debug 級別記錄在debug.log。當 Cassandra 是在前臺運行時，INFO 級別的信息會打印到控制臺。

5. 插入和查詢

使用 CQL 來進行插入和查詢操作。為了使用 CQL，首先要連接到集群，可以使用 cqlsh 或者客戶端應用的驅動。

（1）使用 CQLSH

cqlsh 是通過 CQL 與 Cassandra 交互的命令行 shell。該可執(zhí)行命令，可以在bin/目錄找到。例如，使用它連接到指定的單個節(jié)點：

$ bin/cqlsh localhost
Connected to Test Cluster at localhost:9042.
[cqlsh 5.0.1 | Cassandra 3.8 | CQL spec 3.4.2 | Native protocol v4]
Use HELP for help.
cqlsh> SELECT cluster_name, listen_address FROM system.local;

 cluster_name | listen_address
--------------+----------------
 Test Cluster |      127.0.0.1

(1 rows)
cqlsh>

可以參見 http://cassandra.apache.org/doc/latest/tools/cqlsh.html 來了解更多 cqlsh 的用法。

（2）使用客戶端應用的驅動

很多語言都提供了客戶端的驅動。在選擇驅動時，需要驗證 Cassandra 版本是否支持該驅動。

完整的驅動列表，可以參見 http://cassandra.apache.org/doc/latest/getting_started/drivers.html。

最后編輯于 ：
?著作權歸作者所有,轉載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時請結合常識與多方信息審慎甄別。
平臺聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點，簡書系信息發(fā)布平臺，僅提供信息存儲服務。

相關閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容