关于导入数据的几个问题

很高兴能接触到nebula这款优秀的产品,现考虑将现有图数据库从dgraph切换到nebula,有如下几个问题请教下

1.看文档同一条点或边可被多次插入或写入,读取时以最后一次插入为准。
因为我们的数据在线实时写入速度较快,每次写入当前动作和动作关联的设备等信息,因此用upsert会很慢,所以考虑直接overwrite方式来写,10min去重下写入设备等信息,会出现重复写。nebula底层是rocksdb,我理解重复的写入只会在compaction时擦除,这里是否会出现数据膨胀速度过快导致磁盘增长过快的问题?

2.nebula提供的uuid相当于自己在内部维护了一个vid映射表,如果我自己有的元素自己生产vid,有的元素依赖nebula uuid来生产vid,这里uuid的vid会和自定义的vid重叠吗,现在支持这样混用吗?

3.nebula支持的ttl自动删除,如果只定义了点的ttl,当点被ttl自动删除时对应的边会自动删除吗?

4.看代码有定义spark sst导入方式,但是没看到具体文档,这块现在已经支持了吗?

  1. 原理理解是对的。rocksdb确实有写放大和存储放大的潜在问题,这个其实和Badger原理没啥区别(除了wisckey部分)。但是——nebula默认有个 auto_compaction 参数,会做小范围的合并,也可以通过submit job compact 来做全局合并。——相应的,LSM-tree这种架构还是需要留有足够的buffer。
  1. 可以的话,还是用你自己的vid比较好。uuid的性能并不好。
    如果混用,理论上有冲突的可能——uuid的生成算法你可以看下代码,很短。
  1. 不会,这会导致悬挂边。
  1. 之前有个社区贡献的版本,但是有些问题,我们在重构,应该已经重构的差不多了

1.是的,不过就我们使用来看,dgraph在大数据的场景存在很多问题,实际使用中badger还存在很多问题,崩溃和compaction效率都有,rocksdb久经验证,应该会避免很多坑。

2.主要是对于自定义生成vid很多时候也需要类似的操作,比如对于用户可以按照id生成vid,但是对于业务上的uuid类似的还是需要做一个kv映射,现在我们的做法是用hbase保存下历史映射关系,具体生成插入语句还是要查询映射,这种要是能够直接很好集成到nebula,会少很多依赖而且使用上也会顺畅。

至于这里的混用冲突问题,可以看下dgraph的解决的方案——提供一个设置,将一定范围的vid允许用户自定义,剩下的数据库保留自己内部分配使用,这样就不会冲突了。

3.删除点时删除关联边应该是常见需求,有没有可能在定义ttl时指定删除时需要删除的关联边, 对边ttl也类似。

我还是推荐vid应用自己生成和控制,uuid完全不建议使用。

这个负担目前是交给应用的,因为nebula是nosql不保证事务的。
点和边各自指定一个属性字段用于ttl,只能应用在逻辑上保证吧。(也许需要把某个字段在点和边上都冗余一份,这样TTL时效比较一致)

delete vertex 的API操作,是DB内部做了同时删除点和周围边。因为这个操作是客户端发起的。
但是TTL是在storage里面单机发起的,如果要跨机删除会引入太多复杂性。

明白了,非常感谢您耐心解答。