很高兴能接触到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.是的,不过就我们使用来看,dgraph在大数据的场景存在很多问题,实际使用中badger还存在很多问题,崩溃和compaction效率都有,rocksdb久经验证,应该会避免很多坑。
2.主要是对于自定义生成vid很多时候也需要类似的操作,比如对于用户可以按照id生成vid,但是对于业务上的uuid类似的还是需要做一个kv映射,现在我们的做法是用hbase保存下历史映射关系,具体生成插入语句还是要查询映射,这种要是能够直接很好集成到nebula,会少很多依赖而且使用上也会顺畅。
至于这里的混用冲突问题,可以看下dgraph的解决的方案——提供一个设置,将一定范围的vid允许用户自定义,剩下的数据库保留自己内部分配使用,这样就不会冲突了。
3.删除点时删除关联边应该是常见需求,有没有可能在定义ttl时指定删除时需要删除的关联边, 对边ttl也类似。
我还是推荐vid应用自己生成和控制,uuid完全不建议使用。
min.wu
10
这个负担目前是交给应用的,因为nebula是nosql不保证事务的。
点和边各自指定一个属性字段用于ttl,只能应用在逻辑上保证吧。(也许需要把某个字段在点和边上都冗余一份,这样TTL时效比较一致)
min.wu
11
delete vertex 的API操作,是DB内部做了同时删除点和周围边。因为这个操作是客户端发起的。
但是TTL是在storage里面单机发起的,如果要跨机删除会引入太多复杂性。