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）查找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）和配置。

 

Tags:

VirMach 便宜 VPS

QNews

QNews