图数据库爱好者的聚会在谈论什么?

  • 时间:
  • 浏览:1
  • 来源:uu快3玩法_uu快3新平台_棋牌

T:图的生态为什么我么我在么在打造?和付近其它系统为什么我么我在么在集成融合?

架构和工程

️ D:人太好并一定会一定要 hash,越来越来越多要求 vid 是定长的 64 bit。定长主越来越来越多出于对齐性能考虑,还都不都能能 用上 prefix bloomfilter。越来越变长 id 一般 hash 成 64 bit 最简单,当然用户我本人指定 vid 也是支持的,一般两种 前一天,不都能能 把原始 id 放进点的属性里。

️D:Nebula 目前阶段侧重 OLTP,现在支持的算法是 全路径 和 最短路径 。在图库 builtin LPA 有不少工作要做(当然人太好市面上一定会产品),Nebula 现阶段的考虑是采用 存储计算分离架构 ,用户都不都能能 将图形态学 机会子图抽取到 GraphX 两种 图计算框架,在图计算框架中实现传播算法。机会 OLTP 这块工作完成比较多了,再考虑向 OLAP 两种 方向走。

在上周六的聚会中,Nebula Graph Committer 吴敏给爱好者们介绍了整体架构和形态学 ,并可是 被各位大佬轮番蹂躏(划掉)。

关于生态

对图查询的执行计划优化也进行了一定的探索,包括 执行计划缓存 和上下文无关说说的 并发执行 。当然人太好查询优化挺难做的,我感觉 更能有效提升数率的是怎么能能构图 。机会图的自由度还是挺大的,同四个东西,人太好既都不都能能 构图成点、边也都不都能能 做成属性,人太好对大多数目前的使用者来说,构图对性能的影响应该会比 DB 优化更明显更快。当然构图人太好是和 DB 为什么我么我在么在实现也挺有关系的,比如减少网络传输(比如过滤)、用好 SSD 和 cache(比如减少随机读)、增加各种并发(多多多线程 运行、多机)。

比方说,根据业务类型、时间片段,把四个超大点最好能拆成多个小点,那我操作点一般不想落在四个 partition 上,再把当中热点的 partition 迁移到不同的机器上。举例来说,遍历太深说说,通常性能一定会会太好,越来越来越多都不都能能 把属性放进起点和终点上。像 (Subject1)->(Predicate1)->(Object1)  那我, (Subject1)、(Predicate1)、(Object1) 四个节点,两跳宽度,机会要走一次网络,但改成 (Subject1)-[Predicate1]->(Object1)  那我 -[Predicate1]->  改成两种 类型的边,那就不走网络,特别当查询宽度更深时,两种 构图对性能优化很明显。同类的,还有属性值出理 ,如:起点的 Name(string),何必 作为边属性,不然同四个点出去的所有边上都冗余了两种 Name(string),更新的前一天也巨麻烦。

T:图库在设计上趋同化和同质化,架构上还有哪几种创新值得尝试?

Nebula Graph:四个开源的分布式图数据库。

我感觉描述性的语言,我们我们 都 的总体风格还是挺同类的,上手学习成本人太好真越来越想象越来越高,花个十几分钟看看至少也明白了。特别同类中国各地方言(温州话除外,划掉),机会欧洲的各语言,共通的要素挺多的,连蒙带猜基本不都能能用。当然特别复杂性的逻辑还是得看看手册才行。

知乎:https://www.zhihu.com/org/nebulagraph/posts

微博:https://weibo.com/nebulagraph

️ D:在查询语言方面,增加对 Gremlin、Cypher 的支持。

但我人太好人太好文档、关系和图相互还是借鉴非常多的,我记得《DesigningData-Intensive Applications》上面有章越来越来越多做它们之间的比较。

️ D:人太好目前市场上越来越统一的图查询语言,机会 Cypher 和 Gremlin 影响力要大這個 ,当然要说图语言类的人太好更多,比如还有 GraphQL,SPARQL。nGQL 与 SQL 接近,比较容易上手,但不想 SQL 那样嵌套(embedding)。

️ D: Everything is connected. 图数据库天生适合表达 connection,机会说多对多的关系。

T:图库相比其它系统和数据库未来发展趋势,比如相比文档和关系型,它的核心价值是哪几种?

优化方面:为出理 存储层将越来越来越多数据回传到计算层,占用宝贵数率,Nebula 做了 计算下沉 ,条件过滤会随查询条件同時 架构设计 到存储层节点。机会不带两种 过滤,传 200% 和 1% 的数据,性能是数量级的差异。

在工具方面,提供数据批量导入和导出的工具,比如 GraphX,Yarn,Spark 等。还有,越来越来越多对机器学习的需求支持,存储计算相分离的架构使得 Nebula 非常容易集成图计算框架。机会 Nebula 是开源产品,哪几种工具欢迎我们我们 都 同時 参与:)

T:为哪几种要新开发两种 查询语言 nGQL?做了哪几种优化?

图数据库都不都能能 很高效的查询几度关系,而传统关系型数据库不擅长,一般都不都能能 做表连接,表连接是四个很昂贵的操作,涉及到少许的 IO 操作及内存消耗。

️ D:人太好图产品有越来越来越多,我人太好哪几种产品都能能了说一定会趋同,毕竟从几个知名竞品的架构看,彼此之间相差还是蛮大的 :)。机会功能集和架构出发点主要还是针对业务目标,Nebula 设计目标是实现 万亿级别关联关系 和 大并发 低数率 ,越来越来越多选着了存储计算分离,存储层采用 raft 一致协议,数据 partition 到不同机器上。那我设计主要考虑到存储和计算两者的业务特点和增长数率不一样,比如 learner 都不都能能 拿来给這個 throughput 优先的场景使用,原集群给 latency 优先的场景使用。

还有何必 构造四个超大点出来,不然热点太明显了。回到语言,我们我们 都 也考虑是一定会 nGQL 上面加一层 Driver 支持 Cypher 和 Gremlin,比如 200% 的常见功能。还有越来越来越多考虑在 webconsole 上增加這個 流程图的功能模块,CRUD 操作用图形化支持,复杂性的就写 query,对长尾用户上手一定会帮助。

️ D:从使用体验上看,fbthrift 易读性不错。gRPC 前一天用过也挺多。当然写个好的 rpc 还是挺不容易的,两种 轮子暂时一定会很急迫。

image.png

T: 图库的 builtin 只搞在线查询都不都能能 吗?有必要搞传播算法和最短路径吗?Nebula 为什么我么我在么在实现对图分析算法的支持?

T:key 为哪几种选着用 hash 而一定会 range?

T:gRPC,bRPC,fbthrift 为哪几种越来越选 rpc?有越来越打算我本人写四个?

Nebula Graph:四个开源的分布式图数据库。作为唯一不想都能能存储万亿个带属性的节点和边的在线图数据库,Nebula Graph 不仅不想都能能在高并发场景下满足毫秒级的低数率查询要求,还不想都能能实现服务高可用且保障数据安全性。

️ D:四个是集成测试框架,包括 混沌工程 、 错误注入 哪几种,等完善前一天也会开放出来。还有是关于测试集和数据集,对于 DB 来说,这要素的价值是最大的,不过图领域可参考的数据集较少,一定会我们我们 都 我本人积累的。

算法和语言

下面是现场的 Topic ( 以下简称:T ) & Discussion ( 以下简称:D ) 速记:

GitHub:https://github.com/vesoft-inc/nebula

T:刚才聊到超大点,有啥优化的方式吗,机会对于构图有哪几种建议嘛?

T:在测试方面,Nebula 做了哪几种工作?

️ D:对于超大点建议还是构图和查询时,想方式出理 (分解)比较好,两种 和 SQL 分库分表差越来越来越多。比如:遍历过程中 touch 到的交易对手很大(比如:美团),那最好能给两种 大点打标,遍历前一天过滤掉。当然打标机会要离线 count 一下才知道。

说到大的架构创新,主要看长期的硬件更新数率。当然 DB 可做的优化的事情机会越来越来越多的,刚才 PPT 上面有提及。

本次分享主要介绍了 Nebula Graph 的形态学 ,以及新上线的《使用 Docker 构建 Nebula Graph》功能。