在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，這意味著，如果一個節點出現故障，將不會影響操作，如下表所示：

要解決復制問題，您可以手動執行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）查找75、95、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）和配置，

標籤：NoSQL

上一篇：MySQL5.6解決‘’（1206）The total number of locks exceeds the lock table size‘’問題

下一篇：【11月10日】Redis 快取系統常見問題及解決方案