复合索引创建内存问题

提问参考模版:

  • nebula 版本:2.0.1
  • 部署方式(分布式 / 单机 / Docker / DBaaS):分布式
  • 是否为线上版本: N
    比如有一个tag,有id、name、age、sex、hobby5的字段,需要创建复核索引满足多条件查询,
    复核索引创建(id、name、age、sex、hobby)和(id、name、sex)使用内存差别大吗?如果新添加age用于多条件查询,对于复核索引(id、name、sex)只能删掉索引,再创建(age、sex)?
    主要想了解(id、name、age、sex、hobby)全字段索引和(id、name、sex)部分字段索引差别,对于一个千万级可能存在几十个字段的tag,并且可能随时增添索引,两种差别
  1. 复核索引创建(id、name、age、sex、hobby)和(id、name、sex)使用内存差别大吗?

    不大, 数据会膨胀, 内存几乎没区别

  2. 如果新添加age用于多条件查询,对于复核索引(id、name、sex)只能删掉索引,再创建(age、sex)?

    不用, 直接新建即可

  3. 主要想了解(id、name、age、sex、hobby)全字段索引和(id、name、sex)部分字段索引差别,

    规则是尝试新建的索引, 如果与已有索引的结果相同, 就不允许建新的.
    比如您已经用 第 1,2,3,4,5 个字段建索引了,
    那么下面 4 中索引是不允许建的, 即第 1,2,3,4 个字段 / 第1,2,3个字段 / 第1,2个字段 / 第1个字段
    但是 用第 1,2,4 个字段建索引是允许的

复合索引为(id、name、age、sex、hobby),也能使用id、age、sex查询,
如果有10个字段,都要满足相互查询,那只能创建10个复合索引,按照每个字段往后依次把字段添进去?

在2000W的tag上创建单索引,drop后compact,物理空间多占用1-2G,
如果T+1更新,每次更新都需要重构索引,物理空间冗余会越来越多?

复合索引为(id、name、age、sex、hobby),也能使用id、age、sex查询,
如果有10个字段,都要满足相互查询,那只能创建10个复合索引,按照每个字段往后依次把字段添进去?

您举得例子很有代表性, 用字段 1,2,3,4,5建索引 , 然后按字段1, 3, 4 查询, 索引是不生效的(只会对字段 1 生效).
(索引需要按照连续字段查找, 以本例来说, 索引可以对字段 1,2,3,4,5 / 1,2,3,4 / 1,2,3/ 1,2 和 1 五种组合生效)

理论上, 如果您想随意组合查询条件, 那么对于 n 个字段的 tag , 您需要建 2 的 n次方个索引,
这肯定不是您需要的. 所以还是得再考虑下业务.

在2000W的tag上创建单索引,drop后compact,物理空间多占用1-2G,
如果T+1更新,每次更新都需要重构索引,物理空间冗余会越来越多?

理论上索引在 drop & compact 之后不会有多余的空间. 您这个情况, 我个人怀疑可能是 nebula 的其它模块在导数据时留下的 WAL. 您这个数据是多久之前导的呢?

数据前几天导的,执行了第一次compact后是51G,重新创建索引,drop后再次compact是53G,3台服务器基本都是这个占用

几天的话应该不是 nebula 的 wal了, 不知道是不是 rocksdb 再搞事情. 您可以再关注下, 要持续, 大比例增长可能是哪里有 bug.

后面我注意看下,配置文件基本就改的端口

测试了下对表age,sex,hobby建索引,可以对age,hobby查询
image


最新版本是支持这种?
测试了3个tag3000W数据,删除后compact后物理内存没有增加,之前的可能是对索引操作导致的

哦, 我之前说的那些都是针对 lookup, match 挑索引现在有个已知 bug, 有可能用不上后面的多级索引. 正在修.

后面索引会优化吗?
还有想问下look或者match语句支持这种吗?
a->b,a->c,a->d,同时满足b,c,d条件的a的点

如果a点是已知的,建议用fetch语句查询;如果a不是已知的,需要条件 b,c,d来过滤出a点的话,目前只能创建一个包含字段b,c,d的index。

浙ICP备20010487号