在使用 Apache Druid 进行数据管理时，针对数据压缩率和查询性能，通常采取哪些索引优化与存储压缩策略？请给出具体机制和适用场景。
考察说明
考察对 Druid 存储模型下压缩与索引机制的理解。
回答思路
- 【回答框架 1】Druid 的存储核心是面向列式存储的 segment，每个 segment 按列独立编码。对字符串列，Druid 会构建字典表，将原始字符串映射为整型 ID，然后用 Bitmap 索引（如 Roaring Bitmap）记录每个取值对应的行号，这样既压缩了存储，也支持快速过滤。
- 【回答框架 2】数值列和维度列会选用不同的压缩算法：维度常用字典编码加 Bitmap，指标列则常采用 LZ4 或 Zstandard 等压缩算法，并可按列配置。在 ingestion 阶段可通过 dimensionCompression 与 metricCompression 参数指定，底层会按数据类型自动选择合适的编码与压缩组合。
- 【回答框架 3】索引优化上，Druid 为每个 segment 维护时间戳排序的主索引，以及针对各列的倒排索引与区间索引。查询时先裁剪 segment，再通过位图索引加速过滤。对高基数维度，位图可能膨胀，此时可考虑使用近似算法或调整 segment 粒度，使索引尺寸与查询性能达到平衡。
- 【回答框架 4】实际调优中，可通过 rollup 预聚合降低数据量，同时合理设置 segment 大小（推荐 300MB 到 5GB）与分区数，避免过多小 segment 造成索引开销。在 [实际项目] 中，我们通过按时间分区和合并小 segment，将压缩率提升了约 [实际数据] 百分，并显著减少查询扫描的数据量。
- 【关键点 1】列式存储、字典编码与 Roaring Bitmap 是 Druid 压缩和索引的基础。
- 【关键点 2】压缩算法与编码可在 ingestion 阶段按列配置，常用 LZ4 或 Zstandard。
- 【关键点 3】segment 粒度与 rollup 直接影响压缩效率和索引开销，需根据查询模式权衡。
- 【易错点 1】高基数维度使用位图索引可能反而增大存储，需谨慎处理。
- 【易错点 2】不能只依赖压缩配置，查询性能还受 segment 大小、分区策略及预聚合影响。
- 【易错点 3】压缩参数调整后必须做压测验证，避免因过度压缩导致查询解压开销过大。