Cassandra數據模型和模式(Schema)的配置檢查

免責聲明 本文檔提供了有關DataStax Enterprise（DSE）和Apache Cassandra™的常規數據建模和架構配置建議。本文檔須要DSE / Cassandra基本知識。它不能代替官方文檔。

 

在DataStax客戶諮詢團隊看到的大多數項目中，數據建模是決定項目成功的主要因素之一。數據建模正確的系統具備可伸縮性，一般問題較少。數據建模不正確的系統一般是不穩定的，即便只有相對少許的數據也會失敗。這是爲何客戶諮詢團隊在審覈集羣時注重數據模型的緣由。若是您須要除此以外更多的有關Cassandra數據建模的信息，請參閱Cassandra或DataStax CQL數據建模文檔。 

 

---

 

 

1 數據模型檢查

本節列出了客戶諮詢團隊在分析現有數據模型時執行的一組常規檢查。（您也能夠用於開發中的數據模型。）他們從由OpsCenter產生的診斷性壓縮文件（tarball）中獲取現有的schema，或從診斷收集腳本中獲取。您能夠經過在一個集羣節點上執行cqlsh -e 'describe schema;' 而後將結果輸出到例如schema.cql的文件中。咱們會在在本文中都使用該名稱。

 

在診斷性壓縮文件中，它是位於節點的driver/schema裏。 除了有關schema的信息以外，您還可使用nodetool命令，這些nodetool命令是在集羣的節點上執行的（或從診斷性壓縮文件中提取），由於在某些狀況下只有某些節點會受到影響。

 

在分析數據模型時，請考慮與CQL相關的Cassandra和DSE（取決於版本）中的硬性限制，以及本文中的建議。

 

---

 

 

2 Keyspace複製設置 

檢查全部Keyspace，確保它們都具備正確的複製設置。注意如下內容：

 

2.1 錯誤的複製策略

當您的集羣具備多個數據中心時，請使用NetworkTopologyStrategy而非SimpleStrategy。若是使用SimpleStrategy，副本可能沒法保證被放置在正確的數據中心位置。

 

提示：即便您只有一個數據中心，也最好使用NetworkTopologyStrategy，由於若是之後您決定添加數據中心，這樣的設置會使問題簡單化。 

 

2.2 Keyspace在數據中心內部複製不足或未複製到全部數據中心

這對於系統Keyspaces（例如system_auth）尤爲重要。 例如，若是丟失了來自system_auth的數據副本，則您或您的應用程序可能會失去登陸集羣的能力。 

 

2.3 Keyspace的過分複製

有時在大型集羣中，某些Keyspace的複製因子比一般設置（「3」）要高得多。在某些狀況下，它是一個有效數字，例如「5」。更高的值一般會增長讀寫操做的延遲，尤爲是在使用一致性級別時，例如QUORUM或LOCAL_QURUM。若是要進一步保護數據並確保集羣可用性，請考慮添加新的數據中心和備份等。 

 

2.4 偶數用於複製因子（RF）

一般，在諸如QUORUM或LOCAL_QURUM之類的一致性級別上，偶數做爲副本數不能很好地發揮做用，由於這會使集羣對故障的適應性下降。QUORUM計算爲N / 2 + 1，其中N是集羣的副本數。LOCAL_QUORUM使用相同的數字計算，但N是特定數據中心中的副本數。

 

例如，對於RF = 2，QUARUM的副本數等於2，所以當一個節點發生故障時，操做將失敗。 若是將RF增長到3，則不會發生這種狀況，由於QUORUM的副本數仍爲2。這意味着，若是一個節點出現故障，將不會影響操做，以下表所示：

 

複製因子	在不喪失集羣一致性級別QUORUM或在一個數據中心實現LOCAL_QUORUM能力的狀況下可關閉的節點數
2	0
3	1
4	1
5	2
6	2
7	3

 

要解決複製問題，您能夠手動執行ALTER KEYSPACE命令，或者使用Adjust-keyspaces.sh腳本或相似的命令自動執行這些操做。使用LocalStrategy或EverywhereStrategy的系統 keyspaces必須保持不變。

 

---

 

 

3 表數 

Cassandra中表的數目能夠直接影響集羣的性能。一般，一個集羣中建議最多隻能有200個活躍使用的表。即便集羣正常工做，擁有500個活躍使用的表也會被視爲故障級別，由於極可能效率低下，也容易發生故障。

 

問題出在，每一個表都須要大約1 MB的內存用於元數據。對每一個正在使用的表，系統都分配給一個內存表（memtable）。具備大量數據的表還會爲Bloom篩選器和其餘輔助數據結構存儲更多數據，這也增長了對內存的壓力。並且，每一個keyspace還會給JVM內存帶來額外負擔。全部這些共同影響了Cassandra的性能。如下基準顯示，表的數目增長致使吞吐量的顯著降低：

要檢查集羣中有多少個表和keyspaces能夠用：

$ grep 'CREATE TABLE' schema.cql |wc -l

 

 

---

 

 

4 檢查表的結構

在表的定義中應該作如下幾個檢查，它們可能會影響集羣的操做性能。 

 

4.1 檢查主鍵（primary key）和分區鍵(partition key)的結構

主鍵（尤爲是分區鍵）的結構可能會對集羣的性能和穩定性產生重大影響。分析表的結構時，請考慮如下因素：

•  當主鍵僅由分區鍵組成時，行的大小可能會過小。因爲與分區關聯的元數據可能大於行的自己大小，所以在訪問或存儲數據時可能致使效率低下。

• 當表是由一列組成時，請檢查分區鍵的數據類型。某些數據類型（根據定義）具備低基數(cardinality)，例如boolean或tinyint，這可能致使節點之間的數據分佈不均。例如，若是使用boolean類型定義列，則表中將只有2個分區。當分區中有不少行時，您可能還會獲得較大的分區。

 

用日期類型做爲分區鍵列可能會引發另外一個潛在的問題。在許多狀況下，若是人們使用日期類型做分區鍵並按「天」來組織寫入數據，應用程序會爲某一天在一個分區寫入/讀取大量數據（每秒數百和數千個請求），這樣就容易致使熱點的產生。 

 

4.2 檢查表的列數

咱們不建議爲單個表定義數百或數千列，由於：

• 容易超過一般建議的每一個分區的最大單元數（number of cells）(每行太多列）。 請參閱下面的每一個分區的單元數。

• 存儲單個值的負荷：每一個單元都有與其相關的時間戳，這至少增長了8個字節。若是存在TTL，則會增長更多負荷。

• 它可能會影響範圍掃描的性能。

 

若是表中的列過多，請首先分析數據訪問模式。 解決方案包括：

• 若是幾個列是常常一塊兒讀取的，能夠把這些列組合成一個凍結的用戶定義類型（UDT），其中UDT中的全部數據都做爲一個單元寫入。

• 在應用程序內部執行數據的序列化和反序列化。

• 將數據存儲爲Blob。 

 

4.3 檢查數據使用類型的適用性

Cassandra提供了豐富的數據類型，可用於表的數列。因爲數據類型太多，致使用戶常用不正確的數據類型。例如，使用文本類型存儲時間戳，使用不當的數值類型（其數值範圍比所需的範圍大得多，例如，原本用int就足夠了的列卻使用long type類型）。 這種不當使用會致使如下問題：

• 沒必要要地使用磁盤空間。例如，把時間戳標爲ISO-8601編碼類的文本類型要佔用28個字節，而時間戳類型僅使用8個字節。一樣，對於數字類型，long type類型佔用8個字節，而int僅使用4個字節。使用十進制和varint類型時，狀況更糟，由於它們的大小不固定，大小取決於實際值。

• 若是使用DSE Search，您可能沒法正確搜索數據。例如，若是使用文本數據類型來存儲數字或時間戳，您可能沒法執行範圍查詢。

• 當數據編碼不正確時，您可能沒法執行正確的數據排序。 

 

4.4 檢查集合類型的使用

Cassandra提供了幾種數據類型，可在單個列中存儲多個值：列表，集合和映射。 每種類型都要求在建表時就定義好集合中元素的類型。集合類型爲：

凍結的

集合的所有內容被序列化並存儲爲一個值。這種類型解決了下面描述的一些問題，但不容許更新集合的單個元素。

非凍結的

該集合做爲一組單獨元素存儲在單獨的單元格中。 

 

集合類型便於開發。使用時請考慮如下因素：

•  使用非凍結集合時用於保留單個元素的元數據的額外負荷。這包括寫時間戳和可選的TTL。對於列表類型，使用UUID的元素索引（每一個元素16個字節）要求額外的負荷來存儲。

• 當發生非凍結集合的插入或徹底更新時，例如用一個值來取代列的另外一個值時（如UPDATE table SET field = new_value…），Cassandra會插入一個墓碑標記，以防止與之前的數據發生重疊，即便這個數據之前沒有存在過。大量的墓碑會嚴重影響讀取性能。

• 集合中元素的數量有一個上限。對於Cassandra 3.0.1 / 3.1及更高版本：20億。對於早期版本：65,535。元素數量過多可能會在訪問非凍結集合中的數據或使用凍結集合時超出最大寫入值大小限制, 從而致使性能問題。另外，在讀取具備集合類型的數列時，其所有內容將被返回，如此大量數據的傳輸可能會損害性能。

• 對於非凍結集合，其中的單個元素在被插入和更新以後，因爲數據可能散佈在多個SSTable之間，在被讀取之後須要重建實際列值，所以可能致使性能降低。

•  因爲讀取修復不會傳播墓碑，有刪除元素的集合的內容可能會受到影響。發生這種狀況是由於做爲刪除標記的自定義墓碑得不到傳播。

 

遵循如下幾個規則能夠緩解上面列出的問題：

• 使用凍結的集合，直到有必要更新單個元素爲止。

• 將全部集合類型中的元素數量保持在幾十個的數量級，最大數量爲數百個。集合列的內容是總體讀取的，所以，若是元素太多，會出現讀取問題，由於該頁面的最大可能大小爲256 MB。

 

注意：當查詢返回許多行時，將它們做爲單個響應消息返回是效率很低的。相反，驅動程序將結果分紅若干頁面，這些頁面將根據須要返回。應用程序能夠控制單個頁面中包含多少行，可是頁面最大值是由原生協議來定義的。

• 若是您知道之前不存在任何數據，爲了防止建立墓碑，在將數據插入到集合或映射中（或執行集合或映射的完整更新）時，您能夠對列使用追加操做。 例如：

CREATETABLE test.m1 (

id int PRIMARY KEY,

m map<int, text>

);

 

不是使用：

INSERT INTO test.m1(id, m) VALUES (1, {1:'t1', 2:'t2'});

或

UPDATE test.m1 SET m = {1:'t1', 2:'t2'} WHERE id = 1;

 

 

那樣會生成墓碑，執行：

UPDATE test.m1 SET m = m + {1:'t1', 2:'t2'} WHERE id = 1;

 

這樣的話，結果相同，但沒有墓碑生成。

 

若是表中只有一列具備集合類型，您則能夠將其建模爲其餘集羣列。 例如：

CREATETABLE test.m1 (

    id int PRIMARY KEY,

       m map<int, text>

       );

 

能夠在沒有映射列的狀況下建立此表（對集合和列表使用相同的方法）：

CREATETABLE test.m1 (

id int,

m_key int,

m_value text,

PRIMARY KEY(id, m_key)

);

 

您能夠經過省略m_key的條件來爲特定分區選擇全部值，或者經過提供完整的主鍵來僅僅選擇特定元素。相比於會被總體返回的集合類型的列，這是一個更大的優點。

 

4.5 檢查清單類型的使用

上節中描述的全部內容也適用於列表類型。可是，列表類型還有其餘限制：

•  按位置設置和刪除元素，以及刪除特定值的出現，會致使內部先讀後寫 (read-before-write)。

• 前置或追加操做不是冪等的（idempotent）。

 

萬一失敗，您不能簡單地重試該操做，由於不知道該操做是否完成。重試會致使重複的元素；不重試則可能會丟失數據。有關更多信息，請參見列表字段（List fields）文檔。

 

若是您不須要按特定順序排列元素，也沒必要讓元素具備重複的值，請使用集合類型而不是列表類型。 若是您仍然須要使用列表類型的列，請考慮使用其凍結版本。 

 

4.6 檢查用戶定義類型的使用

Cassandra容許建立用戶定義類型（UDT）。您可使用UDT類型將相關信息分組在一塊兒，把每一個組合做爲單個實體來使用。從數據模型分析的角度來看，您能夠應用與集合相同的規則：

• 儘量使用凍結的UDT。

• 對於非凍結的UDT，請不要指定太多字段。

 

可是，UDT仍然存在與UDT的序列化/反序列化有關的問題。從模式（schema）演變的角度來看，另外一個問題是：雖然能夠向UDT添加字段，但卻沒法刪除它們。這意味着UDT僅應在很是必要的有限狀況下使用。不然，最好將此數據定義爲表的常規列。另外一種選擇是在應用程序內部執行UDT數據的序列化和反序列化，並將數據存儲爲Blob。 

 

4.7 檢查深度嵌套的UDT和UDT集合的使用

儘管UDT能夠嵌套在其餘UDT中或做爲集合中的元素，您必須很是當心。若是集合中存在太多元素或嵌套的UDT太多，則將達到最大的寫入值上限，致使操做失敗。

 

4.8 檢查元組類型的使用

CQL提供了元組數據類型，能夠將不一樣數據類型的多個元素分組爲一個實體。此類型的侷限性是：

• 它的值老是凍結的，這意味着每次更新都會重寫該列。

• 您必須按位置訪問元素，這使得開發代碼更加困難，由於您須要記住在哪一個位置使用了哪一種類型以及該位置的含義。

 

因爲這些限制，DataStax建議不要使用此數據類型，而應使用UDT。 

 

4.9 檢查計數器數據類型的使用

計數器數據類型容許您執行遞增和遞減操做，這對某些應用程序頗有用。從Cassandra 2.1開始，計數器的執行更加魯棒，但仍存在侷限性：

•  當節點發生故障，寫入丟失、或相似狀況時，計數器的值可能並不精確，由於計數器操做不是冪等的，而且沒法重試：重試可能會致使計數過多；不重試，則可能計數不足。

•  表可能只包含針對計數器類型的常規列；不可能與其餘數據類型混合使用。 

 

4.10 檢查Blob數據類型的使用

Cassandra經過提供blob類型來支持將二進制數據存儲在數據庫中。使用blob時，請確保您沒有在Cassandra中存儲大於幾百KB的對象，不然從數據庫中獲取數據時可能會發生問題。例如，當獲取的頁面大小大於原生協議設置的限制（256MB）時，查詢可能會失敗。 

 

4.11 定義集羣列的排序順序 

定義表時，能夠定義集羣列的排序方向。執行查詢時應用程序能夠顛倒定義的排序方向，但效率不如相同排序（在表級別上定義的）方向上讀取數據。DataStax建議在建表時定義正確的排序方向。一樣，若是查詢時排序顛倒了，它會影響到全部列，而不只是一列，致使Cassandra沿着反方向讀取數據。 

 

---

 

 

5 每一個分區的單元數

Cassandra文檔常用術語「單元‘（cell）來描述常規列（非主鍵列）的存儲值。除了實際值以外，每一個單元還具備關聯的元數據，例如時間戳，可選的TTL和複雜單元的其餘數據。集合和用戶定義的類型會更加複雜。

 

Cassandra每一個分區的硬限制爲20億個單元。爲了確保讀取操做具備可預測性，DataStax建議限制分區中的單元數，以使分區小於100 MB。

 

您可使用nodetool tablehistograms命令（舊版Cassandra中的cfhistograms）檢查每一個分區的單元數。較新版本的Cassandra和DSE能夠輸出系統中全部表的數據，而較舊版本則須要給出具體的keyspace和表名。

 

查看輸出的「單元計數」列，並檢查99％百分位和「最大」行中的值。若是您的值大於100,000，請考慮更改數據模型；這可能代表存在大的分區（在下一節中介紹），列過多，或在非凍結集合中的元素過多。

 

$ nodetool tablehistograms test widerows

 

test/widerows histograms
Percentile     SSTables     Write Latency     Read Latency     Partition Size     Cell Count
                            (micros)          (micros)         (bytes)
50%           1.00          0.00              1310.72          545791             103
75%           1.00          0.00              1310.72          545791             124
95%           1.00          0.00              1310.72          545791             124
98%           1.00          0.00              1310.72          545791             124
99%           1.00          0.00              1310.72          545791             124
Min           1.00          0.00              1310.72          454827             87
Max           1.00          0.00              1572.86          545791             124

 

 

---

 

 

6 大分區

對於Cassandra，咱們建議將分區大小保持在100MB如下。大分區的存在現象代表數據模型有錯誤，一般是由如下因素觸發的：

• 分區鍵的基數低。 ——分區鍵的可能值太少。

• 分區之間的數據分佈不均勻。

例如，若是用客戶ID做分區鍵，則大客戶的應用程序將比小客戶寫入更多的數據。結果致使，某些節點可能比其餘節點擁有更多的數據。更多的數據會增長這些節點的負載，由於它們要處理更多的請求，須要更多的壓實操做等。

• 表中的列和行太多，尤爲是當每一行包含全部或大多數列的數據時。

• 在表中存儲大blobs或長文本(long texts)。

• 大分區會對Cassandra形成額外的負擔，例如分配額外的內存來保存分區索引。注意：在Cassandra 3.6版以前，讀取大分區會對Java heap施加更大的壓力，並常常致使節點崩潰。

• 當某些節點處理請求比其餘節點多時，節點之間的數據分配不均會致使熱點。

• 在讀取整個分區時，大分區之間須要傳輸更多的數據。

• Cassandra分區的大小會影響外部系統，例如Spark，由於Cassandra的分區是映射到Spark分區的最小對象。任何Cassandra中的不平衡均可能致使Spark處理數據時的不平衡。 

 

6.1 查找有關分區的信息

使用如下工具查找分區的大小：

•  使用nodetool tablehistograms命令（舊版Cassandra中的cfhistograms）查找7五、9五、99和100％百分位數的分區大小。若是看到這些值之間有很大差別，則多是分區鍵值的分佈不均勻。用sstablepartitions命令也能夠得到相似信息。

•  有關最大分區大小的信息可經過nodetool tablestats（舊版Cassandra中的cfstats）得到。檢查「Compacted partition maximum bytes」行中的值是否大於建議的100 MB。

• 若是分區鍵值的分佈不均勻，則可以使用DataStax Bulk loader（dsbulk）來識別，找到擁有最大行數的分區鍵值。dsbulk的主要優勢是，它能夠與整個集羣一塊兒使用。例如，要在測試表中查找最大的分區：

$ dsbulk count -k test -t widerows --log.verbosity 0 --stats.mode partitions

'29' 106 51.71

'96' 99 48.29

• 您能夠用sstablemetadata功能與-s命令行參數一塊兒使用，來找到特定SSTables中最大的分區。-s標誌在Cassandra 4.0和DSE 6.x中可用。對於Cassandra 3.x，請使用sstable-tools項目（這是sstablemetadata功能的靈感）。sstablemetadata的一個優勢是，它提供有關最大分區的信息，包括行數和字節大小。缺點是它與單個SSTable文件一塊兒使用，而一個分區可能被分割在幾個不一樣的SSTable文件。 例如：

$ sstablemetadata -u -s path_to_file/mc-1-big-Data.db

SSTable: /Users/ott/var/dse-5.1/data/cassandra/data/datastax/vehicle-8311d7d14eb211e8b416e79c15bfa204/mc-1-big

Size: 58378400

Partitions: 800

Tombstones: 0

Cells: 2982161

WidestPartitions:

  [266:20180425] 534

  [202:20180425] 534

  [232:20180425] 534

  [187:20180425] 534

  [228:20180425] 534

LargestPartitions:

  [266:20180425] 134568 (131.4 kB)

  [202:20180425] 134568 (131.4 kB)

  [232:20180425] 134568 (131.4 kB)

  [187:20180425] 134568 (131.4 kB)

  [228:20180425] 134568 (131.4 kB)

...

 

經過查看tablestats / cfstats輸出中分區的行數（估計）或經過執行SELECT DISTINCT partition_key_list，count（*）FROM table並檢查輸出的列數來檢查分區鍵值的低基數。

 

對本節中描述的問題，惟一的解決方案是更改數據模型以選擇正確的分區鍵和聚類鍵。在某些狀況下，您也許能夠把聚類鍵提高爲分區鍵，或引入人工分組列（artificial bucketing column）做爲分區鍵。

 

---

 

 

7 檢查壓實策略 

通常狀況下，優先使用默認的壓實策略（SizeTieredCompactionStrategy，STCS），除非它會致使問題，或其餘策略存在明顯的優點。有關調整壓實策略的更多信息，請參見單獨的文檔。

 

---

 

 

8 檢查輔助索引的使用

經過利用非分區鍵列的數列，Cassandra和DSE提供了多種方法執行表的搜索，包括：

• 二級索引

• 物化視圖

• SASI 索引

• DSE Search 索引 - 注意：DSE 6.8包括Beta版的存儲附加索引（SAI）。

經過使用這些技術，用戶能夠沒必要將數據反範式化爲其餘表。可是，以上每一個實現方法都有其自身的限制。

 

8.1 檢查二級索引的使用

Cassandra中的原生二級索引是反向索引，它在內部建表，將每一個列的特定值映射到一個完整的主鍵上，以此來索引每一個節點上的數據。因爲基表中定義的主鍵結構不容許數據訪問，這個索引方法的目的是爲繞過這個障礙來支持數據訪問。

 

二級索引有一些限制：

• 每一個索引只能索引單個常規列。

• 不支持非相等（non-equality）或範圍條件。

• 可能會受到索引列基數的嚴重影響。若是低基數存在，則可能致使建立很寬的分區。若是是高基數，您可能會建立許多很是小的分區。二者都會對性能形成不利影響。

•  不能很好地處理刪除。二級索引中的大量墓碑會嚴重下降其性能。

• 因爲二級索引是在本地將數據索引到每一個節點上的基表裏，它們不能經過分區鍵獲得正常放置。因爲缺少分區鍵的限制，它會致使查詢時要向數據中心中全部節點發出分散收集的請求，從而致使性能欠佳。

因爲這些緣由，使用二級索引時必須很是謹慎，並在可能的狀況下經過反範式化來避免使用二級索引。較小分區中的單個分區裏，一些表是不多發生刪除的，基本分區位於本節點上，該索引能夠在之後被重複使用到 —— 若是知足全部這些條件，那麼在篩選結果時，二級索引多是一個合理的選擇。即便在這些條件下，咱們也強烈建議使用具備表明性的數據和負載，完全測試使用二級索引的查詢。

 

因爲Cassandra須要消耗資源來構建和維護二級索引，才能使其保持一致的狀態，所以DataStax建議，保持相對較低數量的二級索引，並刪除全部未使用的二級索引。 您可使用如下方法檢查已定義的二級索引的數量：

$ grep 'CREATE INDEX' schema.cql|wc -l 

 

 

8.2 檢查物化視圖（materialized views）的使用

Cassandra 3.0和DSE 5.0引入了對物化視圖的支持，以使客戶端應用程序更容易自動透明地對數據進行反範式化。物化視圖是在模式（schema）級別上定義的指定基表的視圖。這些視圖包含基表（或其子集）的相同信息，但具備不一樣的主鍵，所以原始鍵結構下沒法實現的讀取模式能夠經過視圖變爲可能。

 

將數據寫入基表時，其全部物化視圖都會相應地自動更新，以便在任什麼時候候能夠像常規表同樣根據其鍵來讀取它們。請注意，數據實際上存儲在每一個視圖中，所以總佔用量會根據視圖的數量及其包含的信息而增長。

 

在表上使用物化視圖時，請考慮如下因素：

• 物化視圖的主鍵結構上的約束：

• 物化視圖的鍵必須包含構成基表鍵的全部列。這是由於行的惟一性定義必須是相同的。

• 物化視圖的鍵最多能夠包含基表中的一個常規列，條件是該列永遠不能爲null。

•  在表上使用物化視圖將對數據庫形成額外的負擔，所以請相應地計劃資源。

• 爲了在物化視圖中構建行，Cassandra須要從基表中讀取相應的行，這給IO系統增長了額外的負擔並增長了延遲。

• 若是物化視圖具備不一樣的分區鍵，則數據的插入須要與負責相應令牌範圍的其餘節點進行網絡通訊。

• 在某些狀況下，物化視圖可能與基表不一樣步。若是發生這種狀況，請使用nodetool rebuild_view進行重建（常規修復不適用於物化視圖）。

• 在現有數據的表上建立物化視圖時，可能須要一些時間，具體取決於現有數據量的大小。可使用nodetool viewbuildstatus命令檢查已構建操做的狀態。

• 在Cassandra中，物化視圖仍標記爲實驗性質，不建議用於生產環境。

 

儘管從開發的角度來看，物化視圖很方便，可是您能夠經過建立一個或多個輔助表並寫入全部輔助表來得到更好的性能。儘管它增長了應用程序代碼的複雜性，但它也有其好處，例如在定義輔助表的主鍵時具備更大的靈活性，而且避免在將條目寫入物化視圖以前從磁盤讀取數據。

若是仍然須要使用物化視圖，請將其數量保持在較低水平。使用如下命令檢查物化視圖的數量：

$ grep 'CREATE MATERIALIZED VIEW' schema.cql|wc -l 

 

8.3 檢查SASI索引的使用

SASI（附有SSTable的二級索引）是二級索引的另外一種實現方式，旨在使查詢條件具備更大的靈活性並提升性能。SASI是由一位外部貢獻者爲Apache Cassandra貢獻的，其最初的實現是針對一個很是特定的用例開發的，使用的是舊版本的Cassandra和已棄用的API。

 

此外，它只在很是有限的程度上獲得了測試。進一步的測試和初步實驗代表，SASI索引受衆多錯誤(bugs)的影響。儘管進行了修復和改進，它仍然不可靠並且可能返回不一致的結果，所以咱們認爲它還不能用於生產環境。

 

DataStax建議避免對生產系統上的任何查詢使用SASI索引。 

 

您可使用如下命令檢查SASI索引的使用狀況：

$ grep -e 'CREATE CUSTOM INDEX.*SASIIndex' schema.cql|wc -l

 

8.4 檢查DSE Search索引的使用

DSE具有基於Apache Solr的本身的搜索索引實現，稱爲DSE Search。 此實現與核心Cassandra透明集成，並容許對存儲的數據進行索引。它能夠對錶的任意列或列組合執行不一樣類型的搜索，例如全文搜索，範圍搜索，精確搜索等。

 

儘管它很是靈活，可是須要考慮如下幾點：

注意：Apache Lucene和Solr以及DSE Search有一些限制。DSE 6.8中的存儲附加索引（SAI）改進了許多這些限制。

•  要在DSE Search索引中構建對象，DSE須要從基表中讀取相應的行，這會增長IO。

• 帶有DSE Search索引的表數

建議的最大索引數取決於DSE和硬件的版本。請參閱DSE Search的容量規劃。

• 虛擬節點的使用和數量。

因爲DSE Search針對全部令牌範圍執行分散收集查詢，所以發送的查詢數量與令牌範圍的數量成正比。對於DSE Search，請使用單令牌體系結構或將vnode的數量保持爲8個或更少。

• 搜索索引的大小。

建議將單個索引端保持在250 GB的限制之下，全部搜索索引的大小不超過500 GB。

•  索引哪些數列及其類型。

DSE Search索引的大小可能明顯大於Cassandra中的數據大小，具體取決於索引列的類型和索引的類型。爲了使索引大小處於控制之下，僅索引搜索所需的列。不一樣的索引類型也會影響性能。例如，文本列被索引爲全文搜索而不是子字符串搜索。

• 不支持某些數據類型，例如計數器和凍結映射。

•  靜態列不能被索引。

• 單節點上單個搜索索引內的對象（文檔）數目（最多20億個文檔）。

當索引表使用具備用戶定義類型的列時，可能很快達到上限，由於這些列被索引成單獨的文檔。

• DSE Search執行查詢的一致性級別爲ONE。這意味着若是不修複數據，返回結果可能會有差別。

• 不支持「行」級別的訪問控制。

 

您可使用如下命令檢查DSE Search索引的使用狀況：

$ grep -e 'CREATE CUSTOM INDEX.*Cql3SolrSecondaryIndex' schema.cql|wc -l

 

使用DESCRIBE ACTIVE SEARCH INDEX命令訪問各個索引的架構（schema）和配置。