Categories
程式開發

讀過本文才算真正了解Cassandra數據庫


Cassandra數據庫,值得介紹的技術細節其實挺多的。因為它很多實現思路和關係型數據庫或者其他的NoSQL數據庫,是有一些不同的。這種不同是在數據庫設計實現思路上也是根源上的。所以衍生開來的諸多特點,在介紹起來就不太容易和其他數據庫去類比。那麼Cassandra有這麼大量的內容,本文只能選講其中的一部分,這部分內容是如何挑選的呢?

在《Cassandra The Definitive Guide》這本書裡,有一段概括性的描述,即用50個word描述Cassandra。它歸納了Cassandra的幾大特性,依次為:開源、分佈式、去中心化、可擴展性、高可用、容錯性、可配置的一致性、行存儲。

我把這幾大特性分為四類:

  • 第一類開源,這個不需要討論。其餘的三類7個特性,就是選講的核心提綱。
  • 第二類是高可用、容錯性、可配置的一致性,這是圍繞著多節點冗餘數據的特性,換句話說,如果Cassandra的數據,每一行數據只有一份而沒有副本,那麼第二類特點就是不存在的。
  • 第三類是分佈式、去中心化、可擴展性,這三個特點圍繞的是數據庫的可拆分性,且各節點可以獨立運行的能力。若只裝一個單機的Cassandra,那這一類特點就不存在。
  • 第四類是行存儲,是描述數據庫底層存放數據的最基本的存儲結構特徵,也是我切入的第一個特徵。

行存儲結構

任何數據庫設計和優化始終圍繞一個核心事情——查詢優化。查詢永遠是使用數據的核心需求。為什麼要INSERT?為了以後這個數據要查詢。為什麼要DELETE?因為不再查詢,並且讓其他的數據更快的查詢。為什麼要UPDATE,因為要實時的查詢使用。無論是數據庫的存儲結構,像ORACLE的段、區、塊的設計,還是輔助的存儲結構,像索引這種,歸根結底,為了更快速的查詢出需要數據。 Cassandra也不例外,了解它的存儲結構,就更加能夠理解它是如何在這個存儲體系下提高查詢性能的,即便它是一個號稱更擅長於INSERT的數據庫。

在早期的Cassandra中,數據庫表一直被稱之為ColumnFamily(列族),我也有很長的時間將其理解為列的集合的意思。所以,我有一段時間認為Cassandra是一個列存儲的數據庫。那為什麼Cassandra的數據模型,可以認為是行存儲(ROW-ORIENTED)的,但又會在早期表被稱之ColumnFamily呢?因為從根本上來講,Cassandra不能算一個嚴格的行存儲,當然它更不是列存儲,它的數據是存儲在一個稀疏矩陣中的。可能這個解釋略微抽象。那麼我先來說下它為什麼不是行存儲。

任何傳統的行存儲數據庫,一旦DDL定義了數據表有多少個列。那麼這一行數據一定存儲了所有的列值。即使出現了這一列沒有值的情況,那麼也一定存儲了一個NULL值,或者是由應用程序存儲一個空格或0來表示沒有值。這一列對應的存儲空間一定是存在的,當然數據庫中的varchar或者壓縮算法會使得這個存儲空間盡可能小。

但是,Cassandra允許對於任何給定的行,你可以只包含其中幾列,而並非一行數據要有所有的列,當然KEY列是要有的。這種在列值存儲上的動態性,是傳統的行存儲數據庫根本不具備的。我猜這也可能早期為何有ColumnFamily概念的根源。

前文提到了,我有一段時間認為Cassandra是一個列存儲的數據庫。但是,我從來都認為它是一個不徹底的列存儲數據庫,而是一個受限的列存儲數據庫。不徹底在哪裡?大部分的列存儲數據庫,都是為了OLAP而生的,它的優勢在於,在某一列上做聚合的性能無語倫比。

比如我一個表有100列,我要對某一列求個SUM。列存儲數據庫可以完美繞過多餘的99列,只把需要的這一列一個不差的拿出來做SUM。但是,用過Cassandra數據庫的人都知道,在任何一列上做全列級的聚合,那簡直是災難性的。就憑Cassandra會將不同的KEY部署在不同的數據庫節點/分區PARTITION(注意這里和傳統數據庫分區不同),任何列級的操作,都會需要在多個數據庫上打轉。更何況,CQL語句到來的時候,還要搞清楚,這個聚合列在這行數據上有沒有。所以,Cassandra是不具備列存儲數據庫的特質的。

讀過本文才算真正了解Cassandra數據庫 1

為什麼,最後Cassandra還是被描述為是一個ROW-ORIENTED呢?

首先,它的存儲是緊緊圍繞著Key的。 Key,它是一行數據的唯一標識符號。一行數據圍繞著Partition Key存在一起,並且圍繞著Clusterting Key局部有序。可見它ROW-ORIENTED的特點還是很鮮明的。什麼樣的存儲結構,就決定一個數據庫擅長做什麼。按主鍵排序的行存儲DB2數據庫最擅長的是什麼?是在OLTP系統裡,通過主鍵做單條記錄的快速查詢(Select by Key),這也正是Cassandra最為常見的CQL形態。什麼樣的存儲結構,也決定了什麼樣的操作會有限制。

在理解了Cassandra數據庫的ROW-ORIENTED的稀疏矩陣存儲之後,再來看看CQL語句的語法限制,那麼這些限制就很容易理解。例如:Select 語句,Where條件裡,一定要送Partition Key(沒有次索引的情況)。如果不送,則語法上必須要添加ALLOW FILTERING。

為什麼是這樣,剛才提到了,Partition Key決定了數據存在哪裡,它像是一個指針,直接指向了這一行數據的物理位置。 ALLOW FILTERING表示什麼,表示的是Cassandra數據庫獲得這條記錄是通過篩選得來的,而不是通過直接定位得來的。

類比一下傳統數據庫,Where 條件送Partition Key就好比通過HASH索引定位記錄,ALLOW FILTERING就如同先做一次TABLE SCAN,讀出大量記錄再從記錄裡過濾出符合WHERE條件的。再看看關於Clusterting Key的,CQL語法要求,範圍查找、Order by一類的語法都需要使用Clusterting Key,這就十分好理解。在定位的Partition Key確定了位置之後,同一Partition Key的數據,都是Clusterting Key有序存放的,那麼通過在這個有序的Key列上,無論範圍也好、排序也好,都不會需要數據庫引擎真正去排序,這就好像在傳統數據庫裡,ORDER BY的列,和某一個索引一致的情況下,執行計劃裡不會真的排序是一個道理。

搞清楚了Cassandra的存儲結構之後,我們來看Cassandra在某一個節點上怎麼做增刪改查。無論Cassandra的多節點特點多麼鮮明,在單一節點上面,數據的讀寫,永遠才是數據庫性能的根基。節點再多,如果單節點上讀寫性能不行,那數據庫終究是快不起來的。所以這裡我們來看一下,Cassandra是怎麼樣讀寫數據的。

先翻譯《Cassandra The Definitive Guide》一段話。 “在Cassandra中,寫入數據非常快,因為它的memtables和SSTables設計,使它插入時,不需要執行磁盤讀取或搜索,這些減慢數據庫速度的操作。Cassandra中的所有寫入都是追加形態的。”

我們看一下Cassandra的寫入步驟,來解讀它的寫入優勢。

讀過本文才算真正了解Cassandra數據庫 2

第一步,寫Commit Logs。這個步驟完全不是什麼新發明。我覺得它和傳統數據庫的REDO Log幾乎是一樣的。無論是什麼數據庫,這個Log的寫入,都是追加形態的。但是,注意看這個圖,Commit Logs直接寫在硬盤上,我認為這個描述並不准確。無論時傳統數據庫的REDO LOG還是Cassandra 的Commit Logs,它都是先到內存,再FLUSH到磁盤上的。而FLUSH的策略是由一些參數決定的,比如commitlog_sync。這和傳統數據庫非常相似,這裡不展開來討論,只需要認識到一點,FLUSH的動作頻率越高,系統奔潰時丟失的數據越少,同時損失部分數據插入性能。就像Mysql數據庫的參數Innodb_flush_log_at_trx_commit=1時,Mysql是最安全,但是也是最慢的。

讀過本文才算真正了解Cassandra數據庫 3

第二步,Add to memtable,這是關鍵的一步,Cassandra的這一步是完完全全的內存動作。而若是傳統的數據庫,則大約需要做這麼幾個動作:

  • 逐層搜索索引,若這個索引塊不在DATA BUFFER裡,觸發磁盤IO。
  • 通過索引定位數據塊,若數據塊不在DATA BUFFER裡,觸發磁盤IO。
  • 修改索引塊,修改數據塊,如果修改並發量大時,可能產生鎖等。

當然,若是像Oracle數據庫那樣的堆表設計,純粹的INSERT動作在b的IO觸發可能性要少一點,但是在UPDATE(Cassandra中也是Insert)場景下,這些開銷都是不可少的。 Cassandra為什麼可以在Memtable上純粹的做追加寫入,這個Cassandra記錄的Timestamp概念是分不開的,即無論你寫入多少次,數據庫只會以最新Timestamp的記錄為準。這樣就不需要去對記錄資源上鎖。這樣的設計,不要說沒有鎖衝突了,就連去把需要上鎖的記錄找出來的開銷都省了,快就快在這個地方。

但是,這個快是有代價的,那就是數據的一致性。比如一個簡單的需求,在數據寫入之前,需要看看這條數據是不是存在,如果存在了就不能插入(CQL的IF NOT EXIST語法),或者UPDATE需要看數據條件(WHERE IF Column = ‘* ‘) 。一旦這種帶條件CQL使用,那可以推斷,上面的這些優勢,也就不存在了。

看第三步,如果這行數據在Row Caches裡,使它失效。注意這個地方,Row Caches裡的記錄是不改的。那麼Row Caches的使用場景,只有特別熱點的數據讀取的時候使用,它並不適合高並發熱點數據修改的場景。

常規交易,做完這三步就返回成功了,不需要等待Memtable的內容落盤。換句話說,直接影響交易性能的步驟,結束了。這和傳統數據庫也沒有太大的差別。那麼接下來的步驟,就不直接影響數據庫的寫入能力。

第四步,數據的落盤,這個動作通常是異步的,在後面會詳細展開將SSTable的存儲。第五步,這個就是多節點特性了,是一個節點異常的處理過程。

總結一下,傳統的數據庫的寫入(包括INSERT、UPDATE、Delete),通常是一個讀後寫的過程。而Cassandra的寫入,是沒有先讀這個動作的,這也是它快的根本原因。一旦使用了IF NOT EXIST之類的語法,那麼它的寫入性能也就會要受損。

接下來看一下Cassandra的讀取,它的讀取是多節點、多副本的讀取。此處,我們先關註一個節點上的情況。

讀過本文才算真正了解Cassandra數據庫 4

第一步,如果這一行數據在Row Caches中,直接返回數據,這個好理解。

第二步,檢查檢查KeyCaches裡的索引,這裡可以理解為,這是一個主鍵索引,它存儲的是未來在Memtables或者SSTables用來定位的信息(書上原文是offset location)。需要注意的是,這裡面的值,在第三步、和第四步的時候,都可能用得上,而不是僅僅用於第三步。看到這個地方,可以發現,其實這個圖有個問題,就是沒有指出KeyCaches的維護。 Cache是​​可以在建表時配置的一個參數。可以推測,假如我們建表的時候,keys的Cache採用了ALL的設置,那麼應該是在有新的KEY值寫入Memtables時,維護到了Key Caches中。

第三步,這一步需要關注是,對於一個指定的表(或列族),是只會使用唯一的一個Memtable 的,那麼這個搜索就是線性的。 Memtable中的內容,是還沒有FLUSH到SSTables裡的數據,在查詢是,它裡面的內容和SSTables中的內容,都是要同步讀取的,但對單節點而言,它的內容通常更新。

與寫入場景大有不同的地方是,讀數據的關鍵步驟,是第4步,讀SSTables。這裡在後面的內容展開,看一下第五步,如果Row Caches還可用,把這條記錄加入的Row Caches。 Row Caches放的是一整行的數據,如前面提到了,適合於存放熱點讀取的數據。

所有的數據庫,通常都是有四大常規操作,謂之“增刪改查”。介紹了寫入、查詢之後,這裡簡單的介紹一下Cassandra的刪和改。一句話簡述之,Cassandra的刪除都是修改,Cassandra的修改都是寫入,所以Cassandra只有寫入和查詢。 Cassandra一直寫入數據,豈不是會存儲爆炸不成。在這裡,我們介紹三個新概念(相對傳統數據庫)-Tombstones,Timestamps,Compaction。

Cassandra的刪除都是修改,這個好理解,在很多業務數據庫表裡面,經常會為了保留痕跡,而做一個邏輯刪除動作。也就是修改某個標識,表示這條記錄以及刪除或作廢,而並沒有在數據庫裡真正的刪除。 Cassandra在收到Delete命令時,並不會立刻去刪除這行記錄。而是會給這行記錄一個Tombstones,表示它被刪除了。

Cassandra的修改都是寫入。前面提到Cassandra速度快,快在不需要定位數據。任何Update命令,在傳統數據庫上,都需要把這條記錄讀到內存裡,並上鎖。而在Cassandra上,Update命令會變成一條INSERT語句,那豈不是在系統裡重KEY了嗎?這里便要依靠記錄上的Timestamps。

Cassandra的每次查詢,都會把所有重的KEY讀出來,但是永遠會以最新的Timestamps為準。這就解決了把所有的修改,都變成寫入的問題。但是,這麼幹有兩大顯而易見問題。第一,數據會無限的膨脹,吃掉磁盤。第二,數據膨脹會帶來查詢需要讀出的重複數據增加,無限的膨脹則會無限的增加,讀取性能就會受損。

所以這裡,就要介紹壓縮(Compaction)的概念。這裡要特別的注意,這不是我們通常說的數據庫壓縮技術,那個通常用的Compress。只是由於多個官方文檔都把Compaction翻譯成了壓縮,我個人覺得它更應該翻譯成數據的整理。 Compaction是在數據庫後台異步做的,接著前面的內容,它的內容至少有比如把墓碑數據真實移除,把時間戳比較老的數據移除,重新整理SSTable的存儲文件等。這樣來解決前面那兩個問題。這個動作在某種意義上來講甚至有一點像DB2數據庫的REORG動作。不同的數據庫表,可以在Keyspace級別選擇不一樣的CompactionStrategy。它常翻譯為壓縮算法,我覺得翻譯成整理策略更加合適。我覺壓縮算法,應該和Compress的那個概念一致。畢竟,這個Compaction沒有給數據文件裡連續的值,用個RLE算法,或者建個字典什麼的對吧。介紹完了這些之後,讓我們來直面數據庫最大的瓶頸。

只要一個數據庫不是內存數據庫,那它永遠都要面對它最大的性能瓶頸,磁盤IO。我們前面提到的諸多概念,比如Cache、列存儲、索引等等,他們優化性能的本質都指向一處,減少磁盤IO。前面講讀寫部分時,都跳過了第4步。而對於SSTable的讀取,其實才是影響性能的關鍵步驟。

讀過本文才算真正了解Cassandra數據庫 5

我們來看一下,SSTable到底是什麼,它的讀取是什麼樣子的。我們根據SSTable的訪問順序來看,在3.0版本中,SSTable包含以下這麼幾個文件:

Filter.db這是SSTable的Bloom過濾器,簡單的講,它告訴你,你要的Key,在我這裡有沒有。 Bloom過濾器的工作方式是將數據集中的值映射到位數組,並使用散列函數將較大的數據集壓縮為摘要字符串。根據定義,摘要使用的內存量比原始數據少得多。它速度快,可能誤報,但不會漏。簡言之,有可能告訴你有,但是沒有。但絕不會告訴沒有,卻有。注意!這裡劃一個重點,Cassandra會維護一個Bloom filter的副本在內存裡面。所以,這一步不一定會有實際IO。在書上也提到,如果加大內存,是可以減少Bloom過濾器誤報的情況。

Summary.db,這裡是索引的抽樣,用來加速讀取的。

Index.db,提供Data.db裡的行列偏移量。

CompressionInfo.db提供有關Data.db文件壓縮的元數據。這裡值得關注的是,它用了Compression這個詞,我猜測,如果Data.db裡面採用了壓縮算法,比如說​​字典壓縮之類的,那麼這個文件裡面應該就會存儲字典數據,或者類似的Compress相關的元素據。這也就是為什麼這個文件,在訪問流程中是不可繞過的。因為一旦Data.db的數據進行了壓縮,那就必須依靠相關的元數據來解壓縮數據。從圖上可以看出,這個元數據在內存中,相對性能會比較快。

Data.db是存儲實際數據的文件,是Cassandra備份機制保留的唯一文件。它是唯一的真實數據,其他的都是輔助數據。比如索引可以重建,字典可以重建等等。

Digest.adler32是Data.db校驗用的。

Statistics.db存儲nodetool tablehistograms命令使用的有關SSTable的統計信息。

TOC.txt列出此SSTable的文件組件。

其中1-5是跟SSTable訪問數據性能相關的文件。如果Cache是​​ALL的情況下,Cassandra在通常都可以在內存訪問之後,直接定位到SSTable的具體文件和數據所在偏移量中去。相對於傳統數據庫,B樹索引層層向下,遇到沒有的索引塊就要IO。這個性能應該還是非常可觀的。

講到這裡,不知道你有沒有感受到,Cassandra的一個重要精華所在,那就是沒有鎖,或者叫沒有資源上的衝突和爭搶。通過Timestamps概念,解決數據可相同Key數據不要上鎖的問題。儘管我們前面的內容,全部都還只是在圍繞單節點數據庫介紹。但是Timestamps的使用,是為Cassandra分佈式、去中心、可擴展、高可用、容錯性、可配置一致性提供了更多靈活方便的地方。

讀過本文才算真正了解Cassandra數據庫 6

分佈式、去中心、可擴展性

前面我們把這六條分成了兩類,分佈式、去中心、可擴展,這三個圍繞的是KEY的獨立性。尤其是Partition Key,它是具有極強的獨立性的。由於它的極度獨立,理論上任何不同Partition Key的數據,就都可以放在不同機器上,去獨立的提供服務,也就成就它的分佈式、去中心和可擴展。對照這幾條特性看一下。

分佈式,百度詞條上解釋為,建立在網絡上的軟件系統。有四大特性:

  • 分佈性。分佈式系統由多台計算機組成,它們在地域上是分散的,可以散佈在一個單位、一個城市、一個國家,甚至全球範圍內。整個系統的功能是分散在各個節點上實現的,因而分佈式系統具有數據處理的分佈性。一個邏輯上的數據庫表,他是分散存儲來多個Node中的。不同的Key值的記錄會由Cassandra的不能節點提供分散的的服務。
  • 自治性。分佈式系統中的各個節點都包含自己的處理機和內存,各自具有獨立的處理數據的功能。通常,彼此在地位上是平等的,無主次之分,既能自治地進行工作,又能利用共享的通信線路來傳送信息,協調任務處理。 Cassandra只有在Partition Key劃分數據所屬Node的存儲位置時,有主次副本之分。比如說,我的Node1要存放的Key值是多少到多少,其他的勉強稱之為副本。其實Cassandra存的是多個地位平等主本,且都具備獨立處理數據等能力,它們協同處理任務,並非傳統意義上的主備數據概念。
  • 並行性。一個大的任務可以劃分為若干個子任務,分別在不同的主機上執行。每個Node自然是自己提供涉及的Key的服務,相互之間獨立、並行。對於不同的CQL而言,可能會由不同Node來完成查詢。也可以是一個CQL裡面涉及的多個Node,它們也基本上是並行來完成這個CQL的。
  • 全局性。分佈式系統中必須存在一個單一的、全局的進程通信機制,使得任何一個進程都能與其他進程通信,並且不區分本地通信與遠程通信。同時,還應當有全局的保護機制。系統中所有機器上有統一的系統調用集合,它們必須適應分佈式的環境。在所有CPU上運行同樣的內核,使協調工作更加容易。 Cassandra是完全符合這個定義的,Coordinator節點並不是固定的。每個節點都可以接受任何的CQL,並且來充當協調者的角色。重要的是,對於一個應用程序或者客戶端而且,可以不關心Cassandra後來是怎麼樣存儲和查詢數據的。它從外面看到的,始終只有一張完整的邏輯數據表。

有了分佈式的基礎,Cassandra可以運行在多個Node下,並且多個Node可以部署在真實的不同的數據中心機房裡,不同機架上,也就能做到去中心Decentralized。有了這個基礎,就可以配合Cassandra的多中心的複制策略NetworkTopologyStrategy,在每一個數據中心定義數據複製了。

可擴展這個詞其實,並不是特別準確,它的重點其實是可水平擴展。簡而言之,就是在圖中環上加Node,就可以提高Cassandra的處理能力。這其實和它的分佈式特點是密不可分的。 Cassandra的拆分粒度最細,理論上幾乎可以到一個Partition KEY。或者說,每一個Partition KEY,都可以被看作可以拆分的,獨立處理的最小的單位。增加數據的同時只要增加Node就可以了,這就使得它的水平擴展性是很好的。

做一個偏激的假設,如果Cassandra只有一份數據存儲,就憑Key獨立的特點,把不同的Key分到不同的機器上提供服務,也可以算得上是分佈式、去中心和可擴展的。但是它這個特點是不完美,不徹底的。因為機器分得越多,任何一台機器故障,它提供的服務就是不完整的。

高可用、容錯性、可配置一致性

接下來,我們繼續看另外三個特點,高可用、容錯性、可配置的一致性,這些特點圍繞的核心就數據冗餘。

任何的高可用背後,一定是有數據冗餘的。傳統數據庫通常偏愛的是主備模式,就是當提供服務的數據庫節點DOWN掉之後,備節點開始提供服務。這時候往往故障檢測、主備切換,應用切換的時間就會成為關注的焦點,做得好一點的數據庫可以在1分鐘或者幾十秒內完成切換。不過在如今7*24*365的環境下,1分鐘的故障恢復時間通常並不能讓用戶十分滿意,當切換時間壓縮到一定程度,還會出現一個矛盾點,就是數據庫異常時間監測閾值。如果設得太長,主備切換就慢,設太短了,一個網絡抖動,就可能觸發不必要的主備切換誤判。

Cassandra的數據複製(replicas)並不像傳統的備份數據,它更像是多份主數據,這些數據都是時時刻刻對外提供服務的,換句話說,有一個數據庫節點DOWN掉,完全不需要主備切換時間。在資源充足的情況下,甚至是幾乎無感的(比如7個replicas壞了1個)。

在Cassandra裡面,數據複製(replicas)多少份,怎麼存儲,這個策略是可以根據不同的Keyspace來設置的,相當於提供一個靈活的選擇,可以根據數據庫表的實際使用場景和形態,來決定數據複製的策略。

數據冗餘可以說是分佈式系統中的常規操作,像參數數據之類的,經常會採用數據冗餘的方法來處理。然而,有冗餘的地方就有同步。數據一致性問題,永遠和數據冗餘相伴而生。好在Cassandra有Timestamps來解決一致性問題,容錯性只是一致性的一個衍生產品,簡單的說,只是Cassandra發現了一個老Timestamps的錯誤數據,後台修復一下而已。

而可配置一致性,就是Cassandra的一個特別重要的特性了。因為它的影響但不僅僅是對於高可用,它還直接影響數據庫性能。就傳統數據庫而言,開不開備庫,對OLTP交易性能也是有直接影響的(包括Redis也是)。從理論上來說,Cassandra要等更多的Node寫入數據,那響應時間就會越慢。這個響應時間取決與最慢的那個Node。若要交易響應更快,就需要通過異步的方式。所以Cassandra通常都不會等所有的Node都響應,等多少Node,等哪些Node,就是可配置一致性。

在數據寫入讀取方面Cassandra的一直性級別有:

ANY(僅寫入),ONE,TWO,THREE ,QUORUM,ALL
LOCAL_ONE, LOCAL_QUORUM,EACH_QUORUM

以上這些級別很好理解,不需要逐個解釋。關於高可用和強一致性,永遠都是魚和熊掌。假如我們的系統使用了最快的方式寫入,比如寫ANY,讀ONE。那麼讀到的數據並不是最實時的準確數據的可能性就會大幅增加。如上面的圖,有6個節點在寫入數據,任意一個寫成功,程序就成功返回。那麼假定其餘5個節點還沒有完成寫入。那這時候,有一個讀ONE的程序,恰好讀到了這5節點中的一個,並成功返回,這就產生了數據的不一致。要做到數據的強一致,讀寫策略就必須配合設置,滿足這樣的條件。

W+R>RF W—寫一致性級別 R—讀一致性級別 RF—副本數

Cassandra的這個設計非常的巧妙,它提供極好的調優靈活性。數據庫調優的本質無非是個損有餘而補不足的過程,這個有餘並非指損性能好的地方去補性能不好的地方。

數據庫或數據,有些地方有些功能,我們不用或者少用,性能不需要那麼好,稱之為有餘;有些地方有些功能我們常用,主要用,性能要越快越好,我們稱之為不足。比如很多系統的某個數據庫表,它的訪問形態是有局限性的。有可能一張表,100次插入,只有1次讀取,像流水數據。有可能一張表,1次插入,100次讀取,像參數數據。這裡面就有了極大的靈活性,我們可以損失冷門操作的性能,來保障我們的主要操作。例如,以讀取為主的表,我們可以設置寫入的一致性為ALL ,讀取的一致性為ONE。從而獲得一個非常高效的系統性能。

讀過本文才算真正了解Cassandra數據庫 7

需要注意的是,數據的複制因子,是定義在Keyspace,也就是在存儲方面決定。而讀取的一致性,是由客戶端決定的。同樣的數據,也可以根據不同使用場景來使用不同的一致性級別。比如說,對數據實時性要求高時,可以設置成讀QUORUM或者ALL,實時性要求低時,選擇讀ONE。

總結

至此,我已經完整的講解了Cassandra的分佈式、去中心化、可擴展性、高可用、容錯性、可配置的一致性、行存儲的特性。

回顧一下,我們先講了Cassandra單節點上的行存儲結構,然後圍繞Cassandra數據Key的獨立性介紹了分佈式、去中心化、可擴展性。繼而討論了關於Cassandra多副本數據帶來的高可用、容錯性、和可配置一致性。

當然Cassandra數據庫還有很多值得探討和介紹的內容和概念,如Secondary Index、Tokens、Hinted等等。此外在Cassandra數據庫的使用過程中,也還有監控、備份恢復、性能調優、安全等等內容值得關注學習,這裡就不一一介紹了,未來有機會,再做續集吧。

作者介紹

宇文湛泉,現任金融行業核心業務系統DBA,主要涉及Oracle、DB2、Cassandra等數據庫開發工作。

原文鏈接

https://mp.weixin.qq.com/s?__biz=MzI4NTA1MDEwNg==&mid=2650784795&idx=1&sn=cc3bf16a6175e24a83bf4d8ca398147e&chksm=f3f9718ec48ef89893cbe7823161aac12b12e0cde54e5db1893df48479db3633aac651592ccd&scene=27#wechat_redirect