Cassandra数据模型和模式(Schema)的配置检查

时间 2020-11-30

标签 html node 数据库网络数据结构架构 ide 工具性能测试栏目 HTML 繁體版

原文原文链接

免责声明html

本文档提供了有关DataStax Enterprise（DSE）和Apache Cassandra™的常规数据建模和架构配置建议。本文档须要DSE / Cassandra基本知识。它不能代替官方文档。node

在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，确保它们都具备正确的复制设置。注意如下内容：ide

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