1. Cassandra数据索引概述
Cassandra作为一款分布式NoSQL数据库，其索引机制与传统关系型数据库有着本质区别。我在实际生产环境中发现，许多团队直接套用MySQL的索引思维来使用Cassandra，结果导致集群性能断崖式下跌。Cassandra的二级索引（Secondary Index）实际上是一种"反模式"设计，它的工作方式是在每个节点本地维护索引，而非全局分布。
关键认知：Cassandra的二级索引适用于低基数列（low-cardinality columns），如性别、省份等取值有限的字段。对高基数列如用户ID、手机号等建立二级索引，会导致查询时访问所有节点，引发严重的性能问题。
2. 核心索引策略详解
2.1 分区键设计策略
分区键（Partition Key）是Cassandra最高效的"天然索引"。我曾优化过一个用户画像系统，通过重构分区键使查询性能提升40倍。最佳实践是：
- 复合分区键：将经常一起查询的字段组合，如
(user_region, user_id) - 避免热点：不要直接用时间戳作为分区键，可采用
时间桶+随机数的方式 - 分区大小控制：单个分区建议不超过100MB，可通过
nodetool tablestats监控
-- 不良设计（会导致热点） CREATE TABLE events ( event_time timestamp, event_data text, PRIMARY KEY (event_time) ); -- 优化设计（时间分桶+随机散列） CREATE TABLE events ( bucket int, -- 按天分桶 hash_prefix int, -- 哈希前缀 event_time timestamp, event_data text, PRIMARY KEY ((bucket, hash_prefix), event_time) );2.2 物化视图实战技巧
当需要多维度查询时，物化视图（Materialized View）比二级索引更高效。在某电商项目中，我们通过物化视图将订单查询QPS从50提升到2000+。需要注意：
- 视图会占用额外30%-50%存储空间
- 更新操作会有约10ms的延迟
- 避免在视图上再建二级索引
-- 订单主表 CREATE TABLE orders ( user_id uuid, order_id uuid, order_time timestamp, amount decimal, PRIMARY KEY (user_id, order_id) ); -- 按商家ID查询的物化视图 CREATE MATERIALIZED VIEW orders_by_merchant AS SELECT * FROM orders WHERE merchant_id IS NOT NULL AND user_id IS NOT NULL AND order_id IS NOT NULL PRIMARY KEY (merchant_id, user_id, order_id);2.3 SASI索引深度优化
SASI（SSTable Attached Secondary Index）是Cassandra 3.4+引入的高性能索引方案。在某日志分析系统中，我们通过SASI实现了TB级数据的模糊搜索：
- 前缀搜索：
LIKE 'user123%' - 后缀搜索：
LIKE '%@gmail.com'（需启用SPARSE模式） - 范围查询：
age > 18 AND age < 30
CREATE TABLE user_logs ( log_id uuid, user_email text, log_time timestamp, content text, PRIMARY KEY (log_id) ); CREATE CUSTOM INDEX ON user_logs (user_email) USING 'org.apache.cassandra.index.sasi.SASIIndex' WITH OPTIONS = { 'mode': 'SPARSE', 'analyzed': 'true', 'case_sensitive': 'false' };3. 性能陷阱与调优实录
3.1 二级索引的死亡陷阱
我们曾在一个200节点的集群上踩过这样的坑：在用户手机号字段（cardinality=1000万+）上建了二级索引，导致简单查询都要30秒+。解决方案：
- 改用查询表：专门为高频查询模式设计表结构
- 使用ALLOW FILTERING：对极低频查询反而更高效
- DSE Search集成：对复杂搜索需求使用DataStax Enterprise的搜索功能
3.2 热点分区的紧急处理
某次大促期间，我们发现一个商品分区达到800MB，导致节点频繁GC。通过以下步骤紧急修复：
- 用
nodetool getendpoints定位热点分区 - 临时增加该分区对应节点的JVM堆内存
- 通过
ALTER TABLE添加虚拟列分散数据 - 长期方案：重构数据模型，采用更细粒度分区
# 查看分区大小分布 nodetool tablestats keyspace.table | grep -A10 "Partition count"4. 新型索引方案探索
4.1 存储附加索引（SAI）
DataStax新推出的SAI索引比传统二级索引性能提升5-10倍，支持：
- 多列联合索引
- 高效的数值范围查询
- 更低的写入放大效应
CREATE INDEX ON users (age) USING 'sai'; CREATE INDEX ON users (email) USING 'sai';4.2 自定义索引实现
对于特殊场景，可以开发自定义索引插件。我们曾为地理空间数据实现R-tree索引：
- 继承
org.apache.cassandra.index.SecondaryIndex - 实现
index()和search()方法 - 打包为JAR放入Cassandra的lib目录
经验之谈：自定义索引的开发成本很高，除非QPS要求超过5万+，否则建议优先考虑预计算方案。
5. 监控与维护指南
5.1 关键监控指标
- 读延迟：
nodetool proxyhistograms - 索引命中率：
JMX org.apache.cassandra.metrics.Index - SSTable数量：过多表示需要压缩
5.2 索引重建的正确姿势
当索引损坏或需要调整参数时：
- 先创建新索引
CREATE INDEX new_idx ON ... - 验证新索引功能正常
- 再删除旧索引
DROP INDEX old_idx - 使用
nodetool rebuild_index时务必限制速率
# 控制重建速率（MB/s） nodetool rebuild_index --throttle 50 keyspace table index_name经过多年实战，我认为Cassandra索引优化的核心哲学是："与其事后建索引，不如事前设计好数据模型"。在最近的一个物联网项目中，通过精心设计的分区键和物化视图，我们实现了每秒10万+的写入和毫秒级查询，全程没有使用任何二级索引。这再次证明，在Cassandra的世界里，合适的数据模型设计比任何索引技巧都重要。
