Cassandra資料模型和模式(Schema)的配置檢查

阿新 • • 發佈：2020-11-12

免責宣告

本文件提供了有關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）查詢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）和配置。