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

  • 时间:
  • 浏览:0
  • 来源:uu快3大小_uu快3网站_开奖历史

T:为那先 要新开发五种查询语言 nGQL?做了那先 优化?

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

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

️ D:从使用体验上看,fbthrift 易读性不错。gRPC 事先用过也挺多。当然写个好的 rpc 还是挺不容易的,其他轮子暂时总要很急迫。

还有没人 来越多构造一个多 多超大点出来,不然热点太明显了。回到语言,.我都都 也考虑是总要 nGQL 后边加一层 Driver 支持 Cypher 和 Gremlin,比如 50% 的常见功能。还有以后我考虑在 webconsole 上增加其他流程图的功能模块,CRUD 操作用图形化支持,冗杂的就写 query,对长尾用户上手总要帮助。

T:key 为那先 选泽用 hash 而总要 range?

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

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

关于生态

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

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

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

算法和语言

️ D:人太好并总要一定要 hash,以后我要求 vid 是定长的 64 bit。定长主以后我出于对齐性能考虑,还都时需用上 prefix bloomfilter。没人 变长 id 一般 hash 成 64 bit 最简单,当然用户自己指定 vid 也是支持的,一般其他事先,时需把原始 id 放满点的属性里。

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

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

T:gRPC,bRPC,fbthrift 为那先 没人 选 rpc?有没人 打算自己写一个多 多?

架构和工程

image.png

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

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

T:刚才聊到超大点,有啥优化的依据吗,将会对于构图有那先 建议嘛?

T:在测试方面,Nebula 做了那先 工作?

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

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

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

我感觉描述性的语言,.我都都 的总体风格还是挺例如的,上手学习成本人太好真没人 想象没人 高,花个十几分钟看看要花费也明白了。不得劲例如中国各地方言(温州话除外,划掉),将会欧洲的各语言,共通的次责挺多的,连蒙带猜基本要能用。当然不得劲冗杂的逻辑还是得看看手册才行。

说到大的架构创新,主要看长期的硬件更新速率单位。当然 DB 可做的优化的事情将会其他的,刚才 PPT 后边有提及。

️ D:对于超大点建议还是构图和查询时,想依据防止(分解)比较好,其他和 SQL 分库分表差没人 来越多。比如:遍历过程中 touch 到的交易对手很大(比如:美团),那最好能给其他大点打标,遍历事先过滤掉。当然打标将会要离线 count 一下才知道。

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

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

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

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

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

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

️ D:一个多 多是集成测试框架,包括 混沌工程 、 错误注入 那先 ,等完善事先也会开放出来。还有是关于测试集和数据集,对于 DB 来说,这次责的价值是最大的,不过图领域可参考的数据集较少,总要.我都都 自己积累的。

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

优化方面:为防止存储层将没人 来越多数据回传到计算层,占用宝贵速率单位,Nebula 做了 计算下沉 ,条件过滤会随查询条件一齐分发到存储层节点。将会不带其他过滤,传 50% 和 1% 的数据,性能是数量级的差异。

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