关于nebula:关于-LLM-和图数据库知识图谱的那些事

本文整顿自 NebulaGraph 布道师 wey 在「夜谈 LLM」主题分享上的演讲,次要包含以下内容: 背景 LLMRAGGraph常识抽取Text2CypherGraph RAG将来布局技术背景LLM 是什么这里简略、疾速地介绍下大语言模型:从 GPT-2 开始,到起初风行的 GPT-3,人们逐步意识到语言模型达到肯定规模,借助局部技术手段之后,程序如同能够变得和人一样,去了解人类简单的思维表白。与此同时,一场技术改革也悄悄产生了,已经咱们须要用简单代码、深度学习才可能去形容的某些场景,或是实现的自动化、智能化的零碎能力,当初借助 LLM(Large Language Model)大语言模型就能不便地实现。不只如此,一些大的生成模型能够做更多多模态的事件,去实现一些更有创造性的需要。 如上所示,目前咱们利用大语言模型,将其当作通用智能感知层(接入层),再对接各类传统服务 Service 或者是生成模型服务 AIGC 的利用架构大略是这样。 而当中比拟典型的模式可能就是 RAG。 RAG 是什么RAG,全称 Retrieval Augmented Generation,检索加强生成模型,善于解决常识密集型工作。 对应到下面的利用架构图,在 LLM 层,大语言模型会的常识不足以实现工作,此时咱们须要借助其余的工具,来取得额定常识,可能在之前是低廉的专家资源或者是 Fine-Tuning 微调模型。然而当初 RAG 它能解决这个问题,它能够辅助 LLM 取得额定的常识、数据,亦或是文档。RAG 在用户提交相干工作时,会将发问的问题进行解析,搭配已有的额定知识库,找寻到同它相干的那些常识。 上图下方就是 RAG 罕用的办法,通过 Embedding 和向量数据库达到检索加强的成果。具体来说,RAG 就是将一个语义压缩到一个多维的空间里的向量。尽管在这个过程中,信息是有损失,但如果算法足够正当、压缩的空间足够大的话,也能帮忙咱们在比拟疾速的状况下找到相干信息。 举个例子,之前咱们罕用的以图搜图,在淘宝上传一个商品图片,它会找类似的商品,这背地其实就是淘宝把图片的特征向量化,(并非事实)可能是一万维的向量。而你上传的新照片,用同样的压缩 Embedding 的形式生成一个新向量。再在已有的历史商品图片的向量库里搜寻间隔相近的,兴许是 Top100 的向量,将它对应的图片返回给你,也就是你上传商品的类似商品。 这种形式能够延长一下,用来做语义搜寻。通常来说,咱们能够将一本书或者是几百页的文档,拆分成一片片,每个分片的含意做一个 Embedding。同以图搜图相似,咱们在进行发问时,将这个语义的 Embedding 同已有的 Embedding 向量空间做匹配搜寻,找到同这个发问相近的常识片,而后再把这些常识片作为上下文,和工作一起提交给大语言模型。像是 ChatGPT-4、ChatGLM、LLMam 2 之类的感知智能层,当它有了须要的上下文时,就能够很好地去答复咱们问题或者是实现咱们的工作。 这是最简略的、利用额定的常识做问答的 LLM 工作的形式,在《图技术在 LLM 下的利用:常识图谱驱动的大语言模型 Llama Index》这篇文章中也有具体的介绍。 文中讲述了一些常识图谱驱动 LLM 的背景,然而这里能够略微简略地说下。像是上图下方的选举,它其实会毁坏到局部构造,比如说 TopN 要选多少才可能实现咱们的工作,此外咱们的常识分片也扩散在各处。不过既然是常识,其实用常识图谱是一个十分不便的形式,这也是图数据库 NebulaGraph 典型的利用场景。 ...

August 16, 2023 · 5 min · jiezi

关于nebula:AI-协助办公-|记一次用-GPT4-写一个消息同步-App

GPT-4 最近风头正劲,作为 NebulaGraph 的研发人员的我天然是跟进新技术步调。恰好,当初有一个将 Slack channel 音讯同步到其余 IM 的需要,看看 GPT-4 能不能帮我实现这次的信息同步工具的代码编写工作。 本文记录了我同 GPT 次要的交互过程,两头删减了局部非主线对话。 在开始同 GPT-4 谈 App 需要之前,先让他它科普下什么是 Outgoing Webhook,和 Incoming Webhook,以及 Slack 相干的运行机制。 GPT-4:当咱们在 Slack 中设置了 Outgoing Webhook 之后,当用户在 Slack 上进行某些特定操作时,会触发 Outgoing Webhook,并将相干信息发送到咱们指定的 URL 上。这些信息能够包含文本、图片、文件等等。而 Incoming Webhook 则是另一个平台(如微软 Teams)上的一个 URL,当咱们将信息发送到该 URL 时,信息将显示在指标平台上。 GPT-4 写的第一版程序我:能不能写个程序用来接管 Slack 的 Outgoing Webhook,对接到微软 Teams 的 Incoming Webhook? GPT:能够写一个这样的程序。 以下是一个应用 Python 和 Flask 库的简略示例,能够接管 Slack 的 Outgoing Webhook 并将音讯发送到 Microsoft Teams 的 Incoming Webhook: ...

June 6, 2023 · 12 min · jiezi

关于nebula:图数据库-NebulaGraph-v350-发布支持免索引查询UDFFIND-PATH-性能大幅度提升

本次 v3.5.0 版本次要是优化了 FIND ALL PATH 性能,反对免索引的全表扫描等性能。具体性能晋升幅度,记得浏览下周的 NebulaGraph v3.5.0 性能报告。 个性反对免索引的全表扫描,参见 pr:#5416反对 UDF,参见 pr:#4804 #5391反对在返回语句中应用像 v.tag 这样的表达式,参见 pr:#5440反对 UPDATE 语句中的 json_extract 函数,参见 pr:#5457反对在 EXPLAIN 输入中应用 TCK 格局,参见 pr:#5414DML 反对参数,参见 pr:#5328优化反对以毫秒为单位的 TTL,参见 pr:#5430加强了聚合函数中的属性裁剪性能,参见 pr:#5301进步了遍历执行器的性能,参见 pr:#5308优化了 FIND ALL PATH 性能,参见 pr:#5409为了进步性能,移除了一些 raft 锁,参见 pr:#5451优化了谓词函数过滤变长边,参见 pr:#5464 #5470 #5481 #5503并行遍历执行器,参见 pr:#5314MATCH反对ID 汇合,参见 pr:#5360重构了 GO planner,参见 pr:#5369在配置文件中增加了一些graph性能选项,参见 pr:#5463增加了最大连接数标记,参见 pr:#5309缺点修复修复了 RocksDB 导入数据导致 leader lease 有效的缺点,参见 pr:#5271修复了当用户不存在时 DESC USER 提示信息谬误的缺点,参见 pr:#5345修复了 SPACE 存在时,CREATE IF NOT EXIST 将无奈胜利的缺点,参见 pr:#5375修复了在打算中 GetNeighbors 边的方向谬误的缺点,参见 pr:#5368修复了 SHOW SESSIONS 命令中客户端 IP 格局的缺点,参见 pr:#5388修复了在 USE 和 MATCH 时属性被剪枝的缺点,参见 pr:#5263修复了在某些状况下过滤器未下推的缺点,参见 pr:#5395修复了在某些状况下过滤器谬误地过滤的缺点,参见 pr:#5422修复了模式表达式中外部变量解决不正确的缺点,参见 pr:#5424修复了波及 EMPTY 比拟的缺点,参见 pr:#5433修复了 MATCH 中申请所有列时返回反复列的缺点,参见 pr:#5443修复了在自反边波及门路的比拟谬误的缺点,参见 pr:#5444修复了 MATCH 门路中从新定义别名的缺点,参见 pr:#5446修复了插入地理位置值时的类型查看缺点,参见 pr:#5460修复了最短门路解体的缺点,参见 pr:#5472修复了 GEO 解体的缺点,参见 pr:#5475修复了 MATCH...CONTAINS 报错的缺点,参见 pr:#5485修复了并发时会话计数谬误的 bug,参见 pr:#5496修复了 GET SUBGRAPH 和 FIND PATH 参数的缺点,参见 pr:#5500修复了正则表达式的缺点,参见 pr:#5507变动点禁用 edge list join, 不反对在多个模式中应用边列表,参见 pr:#5268移除 GLR 解析器, 须要将 YIELD 1–-1 批改为 YIELD 1– -1,参见 pr:#5290贡献者本次 v3.5.0 版本由以下用户奉献,排名不分先后: ...

June 1, 2023 · 1 min · jiezi

关于nebula:Springboot-撞上-NebulaGraphNGbatis-初体验

本文首发于 NebulaGraph 公众号 https://mp.weixin.qq.com/s/z56o6AEz1Z4RmS8Zdx6dTA大家好,我是开源我的项目 NGbatis 的发起人大叶(CorvusYe@GitHub)。目前 NGbatis 也已成为 NebulaGraph 开源生态我的项目之一。在过来的 4 个月里,NGbatis 从提交第一行代码以来,曾经公布了 3 个版本,正在一步步变得越来越好。感激一路同行的人们。 这里给大家贴上仓库地址:https://github.com/nebula-contrib/ngbatis,欢送大家在仓库下方留言提出倡议反馈。 一、目前有哪些参与者? 其中,@Szt-1 做了和 Spring Cloud 和 Nacos 的兼容,@liuxiaocs7 欠缺了文档,@soul-gin 做了 Java 与数据库之间属性别名的映射,@Nicole00 做了我的项目自动化与代码标准,@wey-gu 提了很多有利于我的项目倒退的倡议并做了国际化。@DawnZzzzz、@hejiahuichengxuyuan、@yarodai 与 @LiuTianyou 则提了不少 issues,issues 让人取得不少灵感。 能够说现阶段的 NGbatis 是使用者与开发者想法碰撞后的独特产物。 二、什么是 NGbatis?NGbatis 是一款针对 NebulaGraph + Spring Boot 的数据库 ORM 框架。借鉴于 MyBatis 的应用习惯进行开发。蕴含了一些相似于 mybatis-plus 的单表操作,另外还有一些图特有的实体-关系基本操作。 如果是 Java 后端服务的开发人员,置信看到这里,大家对 NGbatis 的用处有了比拟清晰的了解。接下来会从几个问题登程,跟读者们介绍 NGbatis: 对于 NGbatis 有哪些思考?NGbatis 能做什么?NGbatis 是怎么实现的?NGbatis 怎么应用?三、对于 NGbatis 有哪些思考?Q: 最原始的诉求是什么? A: 与 MyBatis 雷同,想实现 GQL 与 Java 代码的拆散 。Q: 为什么不间接应用 MyBatis 集成? ...

March 24, 2023 · 3 min · jiezi

关于nebula:图数据库中的分布式和数据切分切图

明天,我试着简要综述几类不同的图数据库的分布式与切图的设计,心愿能够帮忙大家理解不同我的项目、产品的设计差别。如果有了解不对的中央,欢送留言探讨。 什么是分布式系统一般来说,分布式系统是一组计算机程序的汇合,这些程序利用跨多个独立节点的资源来实现独特的指标;这里的独立节点,硬件上大多是指商用服务器(Commodity Servers)而不是大型主机(Mainframe);这里的跨节点协同,硬件上大多是基于以太网设施或者更高端的 RMDA 设施。 为什么咱们须要分布式系统?应用分布式技术的次要目标,实质上是用软件技术+便宜硬件来换取低廉硬件设施(比方主机)的老本;特地是在大多数公有机房环境——而不是私有云端或者超算条件下,此时洽购老本是商业决策的重要依据。 除了升高硬件老本外,分布式技术带来的另一个益处是其“扩展性”,通过在原有商用服务器的数量根底上,减少几台服务器,再联合分布式软件的调度和散发能力,使得新退出的这几台服务器也再额定提供更多的服务; 相比于每次扩容都要 1 比 1 洽购更多的等数量服务器,或者购买更高配置的服务器;分布式技术这一方面使得采购计划能够按需扩容,升高了一次性的大额资本收入;另一方面也使得业务容量能够更加容易布局。 分布式系统的根底问题在分布式技术中,因为数据的存储和计算须要跨多个独立节点来实现,因而不得不波及到一系列根底技术。在本文中咱们只探讨两个:一是提供数据(和服务)的拷贝或者正本的问题;二是对于那些宏大数据的存储和计算该如何散发到各个独立节点上实现? 一、数据的正本问题因为是商用服务器,其硬件上的可靠性和可维护性远远低于主机,网线松动、硬盘损坏、电源故障在大型机房中简直每小时都在产生,是常态;解决屏蔽这些硬件问题是分布式软件系统要解决的根本问题。一个罕用的形式是为数据(和其服务)提供更多的拷贝或者正本,这些正本存在于多台商用服务器上。当一些正本产生故障时,由失常的正本持续提供服务;并且当拜访压力减少时,还能够减少更多的副原本加强服务能力。此外,还须要通过肯定的技术手段来保障这些正本的“一致性”,也就是每个服务器上各个正本的数据是一样的。 当然,在图数据库中,正本问题也存在;其解决形式和大多数大数据、RDBMS 会较为相似。 二、是数据的切分问题单台服务器的硬盘、内存、CPU 都是无限的,TB、PB 级别的数据通过肯定的方法散发到各个服务器上,这称为”切片”。当一些申请要拜访多个切片时,分布式系统要可能将这些申请拆散散发到各个正确的分片上,并将各分片的返回从新“拼装”成残缺的后果。 图数据中的切分问题:切图在图数据库中,这个散发过程被形象的称为“切图”:就是把一个大图切成很多的小图,把对于这些小图的存储或者计算再搁置在不同的服务器上。相比大数据、RDBMS 的大多数计划,值得一些特地的阐明。 咱们先思考一个动态的(不会发生变化的)图构造,比方“CiteSeer 数据集”,这外面记录了 3,312 篇论文,以及这些论文之间的援用关系;这是一个很小规模的数据集,因而工程上,咱们能够根本置信对于这个数据集的解决是能够交给单个服务器。 再对于 twitter2010 这个数据集,其中有 1,271 万个顶点和 2.3 亿条边,对于明天(2023 年)的支流服务器来说,绝对能够轻松解决;但对于 10 年前的服务器来说,可能就须要选购十分低廉的高端服务器才行。 但对于 WDC 数据集(Web Data Commons),其中有 17 亿个顶点和 640 亿条边,这样规模的计算这对于以后单台支流服务器来说也相当艰难了。 另一方面,因为人类社会数据产生的速度快于摩尔定律,而数据之间的交互与关系又指数级高于数据产生的速度;“切图”仿佛是一个不可避免的问题;但这听下来仿佛和各种支流分布式技术外面的数据分片和散列的形式没啥区别。毕竟那么多大数据系统,不都要“切”吗 等等——图真的那么好”切”吗? 遗憾的是,并不是。图畛域外面,”切图”是一个在技术、产品和工程上须要认真衡量的问题。 切图面临的三个问题第一个问题,切在哪里?在大数据或者 RDBMS 中,咱们依据记录或者字段来进行 行切 row-based 或者 列切 column-based,也能够依据 ID 规定进行切分;这些在语义和技术都比拟直观。可是图的特点是它的强连通性,一个点通过一些边,关联上了另外一些点,这些点又通过它们的邻边关联上了更多的点,就像全世界的 Web 网页,简直都通过超链接关联在一起,那对于图来说,切在哪里才是语义上直观与天然的。(如果用 RDBMS 的术语,相当于有大量的外键状况下,如何切分)。当然,也存在一些人造语义上的图切片形式,例如在新冠疫情下,各种毒株在中国的传染链条和国外的链条曾经人造是两个不同的网络结构。但此时,引入了第二个问题。 第二个问题,如何保障切了之后,各分片的负载是大抵平衡的?人造造成的图合乎幂率定律——20% 的多数节点连贯了 80% 的其余节点,这些多数节点也称为“超级节点”或者“浓密点”。这意味着多数超级节点关联了大多数其余的平平无奇的节点。因而能够预计含有超级节点的分片(服务器)的负载和热点会远远大于其余不含超级节点的分片。 图解:互联网上网站通过超链接造成的关联网络可视成果,其中的超级网站(节点)清晰可见 ...

March 15, 2023 · 2 min · jiezi

关于nebula:读-NebulaGraph源码-|-查询语句-LOOKUP-的一生

本文由社区用户 Milittle 供稿LOOKUP 是图数据库 NebulaGraph 的一个查问语句。它依赖索引,能够查问点或者边的信息。在本文,我将着重从源码的角度解析一下 LOOKUP 语句的毕生是如何度过的。 本文源码浏览基于内核源码的 v3.3.0 版本,详见 GitHub https://github.com/vesoft-inc/nebula/releases/tag/v3.3.0 读源码之前首先,咱们须要明确 NebulaGraph 中 LOOKUP 语句的语法: LOOKUP ON {<vertex_tag> | <edge_type>}[WHERE <expression> [AND <expression> ...]]YIELD <return_list> [AS <alias>][<clause>];<return_list> <prop_name> [AS <col_alias>] [, <prop_name> [AS <prop_alias>] ...];<vertex_tag> 是 Tag 的类型,比方:数据集 basketballplayer 中的 player 和 team;<edge_type> 是 EdgeType 的类型,比方:数据集 basketballplayer 中的 follow 和 serve;<expression> 是表达式;<return_list> 是返回的列表,比方:id(vertex),这部分内容具体参见 nGQL 的 Schema 函数 nGQL Schema 函数详解;<clause> 是子句,能够是 ORDER BY、LIMIT 等子句,子句详情参见 子句;这里有个 LOOKUP 应用注意事项: ...

January 5, 2023 · 15 min · jiezi

关于nebula:图查询语言-nGQL-简明教程-vol01-快速入门

本文旨在让老手疾速理解 nGQL,把握方向,之后能够脚踩在地上借助文档写出任何心中的 NebulaGraph 图查问。 视频本教程的视频版在B站这里。 筹备工作在正式开始 nGQL 实操之前,记得先看过文档「疾速入门流程」,部署、连贯过 NebulaGraph,并且看过了「常用命令」。如果你还没看过这两个文档,为了跟上进度,记得先疾速过一遍,下面两个文档链接可在文末「参考资料」中获取。 咱们的指标是本教程目标在于让大家大略晓得了 NebulaGraph 的查问语句后,解决“不晓得什么样的查问应该用什么语句”的问题。 nGQL 是什么咱们先强调一下概念:nGQL 是 NebulaGraph Query Language 的缩写,它示意 NebulaGraph 的查询语言,能够不谨严地分为这 5 局部: NebulaGraph 独有 DQL(Data Query Language)查问语句NebulaGraph openCypher DQLNebulaGraph DML(Data Mutation Language)写语句NebulaGraph DDL(Data Definition Language) Schema 语句NebulaGraph Admin Queries 治理语句这里,作为扼要教程一把梭,咱们只关注前两个局部,后边的内容会在 Part 2 中介绍。 nGQL 速查表 cheatsheet大家能够保留下这份单页速查表,一次理解所有 nGQL 的用法。 NebulaGraph 独有 DQLNebulaGraph 的独有读查问语句的设计十分简洁,对初学者十分敌对。它联合了管道的概念,做到了只波及了几个关键词就能够形容出大多数的图查问模式。因为篇幅的问题,所有 DQL 查问语句的更多用法记得查阅本文的「参考资料」。 简略来说,nGQL 的独有 DQL 一共分成四类语句: 图拓展 / 遍历:GO索引反查:LOOKUP取属性:FETCH门路与子图:FIND PATH 与 GET SUBGRAPH和两个特地的元素: 管道:|援用属性: $ 结尾的几个符号,用来形容一些特定的上下文用 GO 来图拓展 / 遍历GO 的语义十分直观:从给定的终点,向外拓展,按需返回起点、终点的信息。 ...

December 29, 2022 · 3 min · jiezi

关于nebula:从全球顶级数据库大会-SIGMOD-看数据库发展趋势

本文来自 NebulaGraph 的软件工程师文豪在美国费城加入 2022 年 SIGMOD 大会时的见闻。SIGMOD 是数据库畛域的顶级会议之一,是 CCF 数据库 / 数据挖掘 / 内容检索畛域 A 类会议。 NebulaGraph 作为国内惟一的开源图数据库厂商加入,并以展商身份在会上发表了《NebulaGraph: a nex t-generation of hyperscale graph database》演讲。 以下内容文豪将以第一人称开展叙述: 往年 SIGMOD'22 在费城 Philadelphia 举办,我有幸代表公司加入这次盛会。此次参会,我和学生、传授、厂商多有交换,一方面宣传了咱们的产品,另一方面也获取了许多贵重的倡议和意见。接下来,我将分享其中一些倡议,以及我整体的思考。 图学习和存储技术广受关注首先是行业新趋势,本次会议大家关注的热点次要有两个。 第一,机器学习的比重进一步减少,尤其图学习(graph learning)可能成为新的热点。近年来,越来越多的零碎畛域的会议会专门开设机器学习的专区,次要是使用一些机器学习的办法来优化零碎或者算法。其中,有一个方向最近异军突起,就是图学习。简略来说,图学习就是在图上的机器学习。和其余用机器学习解决理论问题相似,图学习通过 embedding 的形式,从 graph 中提取出特征向量(feature vector),再用机器学习的办法解决图中那些艰难的问题,包含分类、子图匹配、链接预测(classfication,subgraph matching,link prediction)等。 从会议的偏向和 NSF (National Science Foundation) 的领导来看,这个趋势还会继续炽热。咱们也收到很多学生和传授对于是否反对图学习的询问。从图数据库供应商角度登程,图学习是 NebulaGraph 的利用之一。咱们不能仅仅满足于提供图数据库外围,还得为下层利用提供库、接口,甚至优化,来保障下层利用的顺利高效运行。从另一个角度登程,如果咱们的 NebulaGraph 能够帮忙学界在一些畛域,比方在图学习方面有所突破,对咱们公司、全行业倒退也是大有裨益的。 除了机器学习,我认为另一个热点趋势就是内存,包含 in-memory database, persistent memory 等。目前非易失性存储(non volatile memory),或者叫持久性存储(persistent memory),通过学术界和工业界十多年的共同努力曾经越来越成熟。目前针对如何应用持久性存储的钻研也是十分炽热,简直所有零碎的顶会都有大量相干的文章。 具体到数据库畛域,就包含:如何设计内存数据库(in-memory database)、如何将持久性存储(persistent memory) 和 SSD、DRAM 等混合应用,如何解决内存隔离(memory segregation)的问题。NebulaGraph 作为图数据库供应商,也应该踊跃拥抱新硬件带来的扭转,积极探索基于 persistent memory 的存储系统。 ...

December 22, 2022 · 1 min · jiezi

关于nebula:实操适配-NebulaGraph-新版本与压测实践

本文来自邦盛科技-常识图谱团队-繁凡,本文以 NebulaGraph v3.1.0 为例。 前言NebulaGraph v3.1 版本曾经公布有一段时间了,然而咱们的我的项目之前是基于 v2.6.1 版本开发的,因为始终在做性能相干的工作,所以始终没有对图库进行降级。 最近,刚好实现了 NebulaGraph v3.1 版本的降级,并做了一些测试工作,这期间的一些问题总结,在这里分享一下,都是实际中踩过的坑,文中的一些问题可能也是 NebulaGraph 相干的 bug。 降级事项v2.6.1 版本到 v3.1.0 版本是一个较大版本,从不反对间接降级来看,改变的货色还是蛮多的,那么我的项目中须要革新的中央应该也是比拟多的。下边是咱们在降级过程中的一些总结。 语法改变首先是 MATCH 查问的调整,优化了 MATCH 的查问性能,并且反对多 MATCH 的子句,这个的确极大地提高了 MATCH 查问的表达能力,然而实测当中,简单的查问性能并不会太高,用于不须要毫秒级响应的查问剖析还是很不便的。MATCH 查问属性须要指定 Tag,这个肯定水平上解决了同名属性的问题,顺带提一下在 GO 语句中,同名属性尚未解决,用的时候须要留神。match (v) return v 这个切实是太有用了,之前必须要指定 vid,然而很多时候导入了数据不晓得 vid,只想大抵看一下,还要去翻一下数据很麻烦。GO 等语句必须要带 YIELD 返回了,之前我的项目中所有用到的中央都要做批改,这个要留神。GO、FETCH 等能够返回 vertex 和 edge 了,这个也解决了一大痛点,因为 API 查问须要返回 path 或者 vertex 和 edge,用于渲染图,然而 v2.6 中 MATCH 的查问太慢了,只好应用 GO 查问。于是,就要把点边的所有信息都 YIELD 进去,造成特殊化的返回,须要专门写代码解析。当初能够间接一次返回 vertex 和 edge,应用通用的解析办法很 easy 了。SHOW ALL QUERIES 变动了,我的项目中有用到超时 kill 的机制,须要 kill 掉慢查问,当初要改成 show local queries,拿到 sessionId(ps:这个 sessionId 公有了,要不就不必查了...),再应用 SHOW QUERIES 查问到对应的 planId 执行 kill 命令。Console 的查问数据导出曾经不可用了,有用到的须要留神。新增局部KV 拆散是一个很大的扭转了,不过目前没有对这个性能进行测试,有实际过的能够谈谈未分离的差别。减少了限度一个用户和机器的 session 个数,这个不留神的话在并发的状况下很容易超出限度。反对了 CLEAR SPACE,革除图空间语句,这个十分好用,在测试时常常要清空图库,以前只能删除重建。不过实测中数据量较多会有肯定耗时,须要审慎应用。BALANCE DATA 这个命令不间接可用了,论坛问了一下须要关上试验性功能。因为关上了试验性功能,所以间接开启了 v2.6.0 开始反对的 TOSS 这个性能,强制保证数据一致性,导致数据写入迟缓,于是就又关掉了。所以目前 BALANCE DATA 不太不便,可能后续会有一些调整吧。改变局部删除点只会删掉点了,之前是连带点的边都会删除,这里应用肯定要留神悬挂边导致的数据一致性的问题。反对不带 Tag 的点,就是容许只有一个 vid 存在。这个仿佛引起一个 bug,只有一个 tag 的点在 TTL 过期之后,点依然存在,跟文档不符。另外 TTL 的工夫也仿佛是一个 bug,总是提前个 30 几秒就过期了,比方设置 60 秒,再 30 秒左右就过期了。ADD HOSTS 命令,用于增加 storage 服务,这样就能够较好的治理 storage 节点了,然而 BALANCE DATA 命令应用的问题,导致扩缩容没有 2.6 版本不便了。会话超时工夫必须要限度了,实测中 session 那里可能是有一个 bug,session 被程序 release 之后没有革除,导致触发了最大 session 数,所以就将 session 超时工夫改小一点,清理掉不必的 session。修复了大量会引起解体的语句,之前的一些聚合语句使用不当就会引起解体,着实有点吓人...适配层面大抵总结这么多吧,还有一些改变就不再细说了,这里讲到的都是在理论中应用时的感触。 ...

December 21, 2022 · 2 min · jiezi

关于nebula:答对这-9-题你就超越了-833-的图数据库-NebulaGraph-用户

相熟 NebulaGraph 社区的小伙伴可能都晓得一个技能认证叫做:NGCP,全称 NebulaGraph Certified Professional。用户在考试认证期间在 1 个小时内答复 100 道题目,并取得 60+ 分,便是 NebulaGraph 认证过的 NGCP 用户。NGCP 用户除了会有实体证书之外,领有与企业认证用户雷同的技术支持服务。 看样子,只有答复 100 道问题,NGCP 证书、认证处分就到手!但,你晓得 NGCP 通过率是多少吗? 答案是:16.7%。 在 NebulaGraph 认证考试出题人查看 NGCP 考试成绩时,发现有局部试题的正确率特地低,针对这些难题这次咱们来一把解析,给考过没考过的小伙伴递个“小纸条”。 上面,请听题: 题 1. 要查看 TAG player 上的 TTL 选项值,谬误的命令有: A. SHOW TAGS B. DESCRIBE TAG player C. SHOW CREATE TAG player D. SHOW TTL ON player 解析: SHOW TAGS 显示以后图空间内的 Tag 名称;DESCRIBE TAG 显示 Tag 的字段名称、数据类型、是否反对为 NULL、默认值和形容;SHOW TTL ON player 是谬误命令。只有 SHOW CREATE TAG player 命令能看到残缺的 Tag 创立语句,蕴含 TTL 选项值。所以,正确答案为 ABD。 ...

December 15, 2022 · 2 min · jiezi

关于nebula:无依赖单机尝鲜-Nebula-Exchange-的-SST-导入

本文尝试分享下以最小形式(单机、容器化 Spark、Hadoop、Nebula Graph),疾速趟一下 Nebula Exchange 中 SST 写入形式的步骤。本文实用于 v2.5 以上版本的 Nebula- Exchange。 原文链接: 国外拜访:https://siwei.io/nebula-exchange-sst-2.x/国内拜访:https://cn.siwei.io/nebula-exchange-sst-2.x/什么是 Nebula Exchange?之前我在 Nebula Data Import Options 之中介绍过,Nebula Exchange 是一个 Nebula Graph 社区开源的 Spark Applicaiton,它专门用来反对批量或者流式地把数据导入 Nebula Graph Database 之中。 Nebula Exchange 反对多种多样的数据源(从 Apache Parquet、ORC、JSON、CSV、HBase、Hive MaxCompute 到 Neo4j、MySQL、ClickHouse,再有 Kafka、Pulsar,更多的数据源也在一直减少之中)。 如上图所示,在 Exchange 外部,从除了不同 Reader 能够读取不同数据源之外,在数据通过 Processor 解决之后通过 Writer写入(sink) Nebula Graph 图数据库的时候,除了走失常的 ServerBaseWriter 的写入流程之外,它还能够绕过整个写入流程,利用 Spark 的计算能力并行生成底层 RocksDB 的 SST 文件,从而实现超高性能的数据导入,这个 SST 文件导入的场景就是本文带大家上手相熟的局部。 详细信息请参阅:Nebula Graph 手册:什么是 Nebula Exchange ...

March 3, 2022 · 8 min · jiezi

关于nebula:Nebula-在-Akulaku-智能风控的实践图模型的训练与部署

本文整顿自 Akulaku 反欺诈团队在 nMeetup·深圳场的演讲,B站视频见:https://www.bilibili.com/video/BV1nQ4y1B7Qd 这次次要来介绍下 Nebula 在 Akulaku 智能风控的实际。分为以下 6 个局部内容: 图的基本概念与利用场景概述图数据库选型图数据库平台建设Nebula 利用案例图模型的训练与部署总结与瞻望 先来解说下图的基本概念,图是由节点和边形成的形容关联关系的汇合。图最大的劣势就是比拟形象,比方上图便是一个脱敏之后的欺诈团伙的图构造,能够看到某个用户和其余节点的关联关系是否存在异样。如果咱们应用的是单纯的行式数据库(关系型数据库)是看不出来异样的,然而从图的角度就能够很容易地发现数据的异样。 再来解说下图的利用场景,在 Akulaku 的场景中次要是图谱关系开掘和可视化剖析,以及图查问代替简单查问。这里解释下图查问代替简单查问,你的利用背景可能和图无关,然而波及的后端操作具备肯定的深度,用图的关系进行查问建模,就比拟容易了解查问语句和保护操作。 再者是图数据库选型这块,先来讲一下 Akulaku 在图数据库选型上踩过的坑。刚开始咱们应用 Neo4j,次要做一些关联性特色,Neo4j 查问效率较高然而可扩展性是短板,分布式的 Neo4j 性能和单机版效率相差不大。咱们也尝试过其余图数据库,这里要说下咱们的业务需要: 良好的可扩展性疾速的数据导入良好的查问效率开展来讲,Neo4j 不具备良好的可扩展性,所以 pass。因为咱们的图规模十分大,次要是面向金融风控场景,图的规模能达到十亿节点、百亿级别边,所以须要疾速的数据导入来做初始化。这里要说下咱们尝试用过 Dgraph,之前咱们浏览过它的相干学术论文,论文写得十分的好然而工程实现欠佳。尤其是批量导入这块,当你导入的数据超过一定量级之后会产生相似内存透露的问题,所以 Dgraph pass。 最初一点是良好的查问效率,这里要讲下 JanusGraph,它的长处是后端能够集成其余存储引擎,这也是过后测试 JanusGraph 的次要起因。然而当咱们导入和初始化数据之后,发现它的查问效率十分的蹩脚。 这里看下 Akulaku 团队对 Nebula Graph 做的可扩展性和查问性能测试: 图规模:10亿点,100亿边测试形式:nebula-bench https://github.com/vesoft-inc/nebula-bench查问语句: 两个一度查问两个二度查问一个三度查问随机源:注册手机号随机抽样 500 W个 phone压测时从随机源 phone 随机查问其中 1 个数据。横轴为并发,纵轴为 QPS,不同色彩的曲线代表并发节点的个数,这里能够看到整个 Nebula Graph 的查问性能是比拟好的。 图上能够看到,可扩展性大略在 12 台机器的时达到较高的性能,后续再增加节点个数,分布式的开销就要开始大于并发带来的效益。所以你会看到这个节点个数进步,查问性能会有所降落。这里说下咱们做的查问,随机抽取 500 万个节点,进行多批查问,每一批查问中蕴含两个一度查问,两个二度查问和一个三度查问。测试过程中,咱们还遇到热点问题,上图是最初验证的后果。 压测时,应用的 Nebula 版本是 v1.x,起初 Nebula v2.x 公布之后,Akulaku 团队开始尝试降级。但刚降级尝试 2.0.1 时,发现一些问题: ...

February 28, 2022 · 1 min · jiezi

关于nebula:Nebula-Graph-源码解读系列-|-Vol06-MATCH-中变长-Pattern-的实现

目录问题剖析 定长 Pattern变长 Pattern 与变长 Pattern 的组合执行打算 拓展一步拓展多步保留门路变长拼接总结MATCH 作为 openCypher 语言的外围,通过简洁的 Pattern 模式,能够让用户不便地表白图库中的关联关系。变长模式又是 Pattern 中用来形容门路的一种罕用模式,对变长模式的反对是 Nebula 兼容 openCypher MATCH 性能的第一步。 由之前的系列文章能够理解到,Nebula 的执行打算是由许多的物理算子组成,每个算子都负责执行特有的计算逻辑,在 MATCH 的实现中也会波及前述文章中的这些算子,比方 GetNeighbors、GetVertices、Join、Project、Filter、Loop 等等。因为 Nebula 的执行打算不同于关系数据库中的树状构造,在执行的流程上其实是一个有环的图。如何把 MATCH 中的变长 Pattern 变成 Nebula 的物理打算是 Planner 要解决的问题的重点。以下便简略介绍一下在 Nebula 中解决变长 Pattern 问题的思路。 问题剖析定长 Pattern在应用 MATCH 语句时,定长 Pattern 也是比拟罕用的查问模式。如果把定长 Pattern 了解成向外拓展 X 步的变长 Pattern,认为其是后者的一种特例,那么定长和变长 Pattern 的实现便能够对立起来,如下所示: // 定长 Pattern MATCH (v)-[e]-(v2)// 变长 Pattern MATCH (v)-[e*1..1]-(v2)上述示例中的区别就是变量 e 的类型,定长时 e 示意的是一条边,而变长时 e 示意的是长度为 1 的边列表。 ...

December 17, 2021 · 1 min · jiezi

关于nebula:Nebula-Graph-源码解读系列-|-Vol05-Scheduler-和-Executor-两兄弟

本文首发于 Nebula Graph Community 公众号 上篇咱们讲述了 Query Engine Optimizer 局部的内容,在本文咱们解说下 Query Engine 剩下的 Scheduler 和 Executor 局部。 概述在执行阶段,执行引擎通过 Scheduler(调度器)将 Planner 生成的物理执行打算转换为一系列 Executor,驱动 Executor 的执行。Executor,即执行器,物理执行打算中的每个 PlanNode 都会对应一个 Executor。 源码定位调度器的源码在 src/scheduler 目录下: src/scheduler├── AsyncMsgNotifyBasedScheduler.cpp├── AsyncMsgNotifyBasedScheduler.h├── CMakeLists.txt├── Scheduler.cpp└── Scheduler.hScheduler 抽象类定义了调度器的公共接口,能够继承该类实现多种调度器。目前实现了 AsyncMsgNotifyBasedScheduler 调度器,它基于异步音讯通信与广度优先搜寻防止栈溢出。执行器的源码在 src/executor 目录下: src/executor├── admin├── algo├── CMakeLists.txt├── ExecutionError.h├── Executor.cpp├── Executor.h├── logic├── maintain├── mutate├── query├── StorageAccessExecutor.cpp├── StorageAccessExecutor.h└── test执行过程首先,调度器从执行打算的根节点开始通过应用广度优先搜索算法遍历整个执行打算并依据节点间的执行依赖关系,构建它们的音讯告诉机制。执行时,每个节点收到它的所依赖的节点全副执行结束的音讯后,会被调度执行。一旦本身执行实现,又会发送音讯给依赖本人的节点,直至整个打算执行结束。 void AsyncMsgNotifyBasedScheduler::runExecutor( std::vector<folly::Future<Status>>&& futures, Executor* exe, folly::Executor* runner, std::vector<folly::Promise<Status>>&& promises) const { folly::collect(futures).via(runner).thenTry( [exe, pros = std::move(promises), this](auto&& t) mutable { if (t.hasException()) { return notifyError(pros, Status::Error(t.exception().what())); } auto status = std::move(t).value(); auto depStatus = checkStatus(std::move(status)); if (!depStatus.ok()) { return notifyError(pros, depStatus); } // Execute in current thread. std::move(execute(exe)).thenTry( [pros = std::move(pros), this](auto&& exeTry) mutable { if (exeTry.hasException()) { return notifyError(pros, Status::Error(exeTry.exception().what())); } auto exeStatus = std::move(exeTry).value(); if (!exeStatus.ok()) { return notifyError(pros, exeStatus); } return notifyOK(pros); }); });}每个 Executor 会经验 create-open-execute-close 四个阶段: ...

November 19, 2021 · 4 min · jiezi

关于nebula:Nebula-Graph-源码解读系列-|-Vol03-Planner-的实现

上篇咱们讲到 Validator 会将由 Parser 生成的形象语法树(AST)转化为执行打算,这次,咱们来讲下执行打算是如何生成的。 概述   Planner 是执行打算(Execution Plan)生成器,它会依据 Validator 校验过、语义非法的查问语法树生成可供执行器(Executor)执行的未经优化的执行打算,而该执行打算会在之后交由 Optimizer 生成一个优化的执行打算,并最终交给 Executor 执行。执行打算由一系列节点(PlanNode)组成。 源码目录构造src/planner├── CMakeLists.txt├── match/├── ngql/├── plan/├── Planner.cpp├── Planner.h├── PlannersRegister.cpp├── PlannersRegister.h├── SequentialPlanner.cpp├── SequentialPlanner.h└── test其中,Planner.h中定义了 SubPlan 的数据结构和 planner 的几个接口。  struct SubPlan {    // root and tail of a subplan.    PlanNode*   root{nullptr};    PlanNode*   tail{nullptr};};PlannerRegister 负责注册可用的 planner,Nebula Graph 目前注册了 SequentialPlanner、PathPlanner、LookupPlanner、GoPlanner、MatchPlanner。 SequentialPlanner 对应的语句是 SequentialSentences,而 SequentialSentence 是由多个 Sentence 及距离分号组成的组合语句。每个语句又可能是 GO/LOOKUP/MATCH等语句,所以 SequentialPlanner 是通过调用其余几个语句的 planner 来生成多个 plan,并用 Validator::appendPlan 将它们首尾相连。 ...

September 25, 2021 · 8 min · jiezi

关于nebula:Nebula-Graph-源码解读系列-|-Vol02-详解-Validator

整体架构  Nebula Graph Query Engine 次要分为四个模块,别离是 Parser、Validator、Optimizer 和 Executor。   Parser 实现对语句的词法语法解析并生成形象语法树(AST),Validator 会将 AST 转化为执行打算,Optimizer 对执行打算进行优化,而 Executor 负责理论数据的计算。 这篇文章咱们次要介绍 Validator 的实现原理。 目录构造Validator 代码实现在 src/validator 和 src/planner 目录。 src/validator 目录次要包含各种子句的 Validator 实现,比方 OrderByValidator、LimitValidator、GoValidator 等等。 validator/├── ACLValidator.h├── AdminJobValidator.h├── AdminValidator.h├── AssignmentValidator.h├── BalanceValidator.h├── DownloadValidator.h├── ExplainValidator.h├── FetchEdgesValidator.h├── FetchVerticesValidator.h├── FindPathValidator.h├── GetSubgraphValidator.h├── GoValidator.h├── GroupByValidator.h├── IngestValidator.h├── LimitValidator.h├── LookupValidator.h├── MaintainValidator.h├── MatchValidator.h├── MutateValidator.h├── OrderByValidator.h├── PipeValidator.h├── ReportError.h├── SequentialValidator.h├── SetValidator.h├── TraversalValidator.h├── UseValidator.h├── Validator.h└── YieldValidator.h src/planner/plan 目录定义了所有 PlanNode 的数据结构,用于生成最终的执行打算。比方,当查问语句中含有聚合函数时,执行打算中会生成 Aggregate 节点,Aggregate 类会指定聚合函数计算时所需的全副信息,包含分组列和聚合函数表达式,Aggregate 类定义在 Query.h 中。Nebula 定义了一百多种 PlanNode,PlanNode::kind 定义在 PlanNode.h 中,在此不做具体论述。 ...

September 24, 2021 · 4 min · jiezi

关于nebula:Nebula-Graph-源码解读系列-|-Vol01-Nebula-Graph-Overview

上篇序言中咱们讲述了源码解读系列的由来,在 Nebula Graph Overview 篇中咱们将带你理解下 Nebula Graph 的架构以及代码仓散布、代码构造和模块布局。 1. 架构Nebula Graph 是一个开源的分布式图数据库。Nebula采纳存储计算拆散的设计,解耦存储与计算。同时在数据库内核之外,咱们也提供了很多周边工具,比方数据导入,监控,部署,可视化,图计算等等。 Nebula 设计请参见《图数据库综述与 Nebula 在图数据库设计的实际》。 整体架构设计如下图所示: 查问引擎采纳无状态设计,可轻松实现横向扩大,分为语法分析、语义剖析、优化器、执行引擎等几个次要局部。 具体设计参见《图数据库的查问引擎设计》,《初识 Nebula Graph 2.0 Query Engine》。 查问引擎架构设计如下图所示: Storage 蕴含两个局部, 一是 meta 相干的存储, 咱们称之为 Meta Service ,另一个是 data 相干的存储, 咱们称之为 Storage Service。 Storage Service 共有三层:最底层是 Store Engine;之上便是咱们的 Consensus 层,实现了 Multi Group Raft;最上层,便是咱们的 Storage interfaces,这一层定义了一系列和图相干的 API。 具体设计参见《图数据库的存储设计》 。 存储引擎架构设计如下图所示: 2. 代码仓库概览 欢送来到 vesoft 代码仓库(vesoft 为图数据库 Nebula Graph 开发商)。 ...

September 24, 2021 · 2 min · jiezi

关于nebula:开源之夏项目分享图数据库-Nebula-Graph-支持-JDBC-协议

本文首发于 Nebula Graph Community 公众号 开源之夏开源软件供应链点亮打算 - 暑期 2021(下简称:开源之夏)是由中国科学院软件研究所与 openEuler 社区独特举办的一项面向高校学生的暑期流动,旨在激励在校学生积极参与开源软件的开发保护,促成优良开源软件社区的蓬勃发展。中科院联结包含 Nebula Graph 在内的国内各大开源社区,针对重要开源软件的开发与保护提供我的项目,并向寰球高校学生凋谢报名。学生在自由选择我的项目后,与社区导师沟通实现计划并撰写我的项目计划书。被选中的学生将在社区导师领导下,按计划实现开发工作,并将成绩奉献给社区。依据我的项目的难易水平和实现状况,参与者将取得由主办方发放的 6,000 - 12,000 不等的我的项目奖金。 流动官网:https://summer.iscas.ac.cn/ 本期分享来自 Nebula Graph 社区郑东阳同学(图数据库 Nebula Graph 反对 JDBC 协定)的我的项目教训。 我的项目信息项目名称:图数据库 Nebula Graph 反对 JDBC 协定 我的项目详情让 Nebula Graph 能够对接 JDBC 协定,实现 Nebula JDBC driver,实现 JDBC 的相干接口。要求:用户可间接应用 JDBC 驱动操作 Nebula 服务,我的项目 repo 有主动运行的单元测试。 Nebula Graph 简介一个牢靠的分布式、线性扩容、性能高效的图数据库;世界上惟一可能包容千亿个顶点和万亿条边,并提供毫秒级查问延时的图数据库解决方案。Nebula Graph 特点 开源:致力于与社区单干, 遍及及促成图数据库的倒退;平安:具备基于角色的权限管制,受权能力拜访;扩展性:反对 Spark、Hadoop、GraphX、Plato 等等多种周边生态工具;高性能:Nebula Graph 在维持高吞吐量的同时仍旧能做到低时延的读写;扩容:基于 shared-nothing 分布式架 Nebula Graph 反对线性扩容;兼容 openCypher:逐渐兼容 openCypher9 ,Cypher 用户可轻松上手 Nebula Graph;高可用:反对多种形式复原异样数据,保障在部分失败的状况下服务的高可用性;稳固发行版:通过一线互联网大厂,诸如京东、美团、小红书在生产环境上的业务考验。Nebula Graph 具备沉闷的社区与及时的技术支持,这是官网:https://nebula-graph.com.cn 和 GitHub 仓库:https://github.com/vesoft-inc/nebula,欢送关注及应用 Nebula Graph,一起成为 Nebula Graph 的 Contributor,为图数据库的倒退贡献力量!!! ...

September 9, 2021 · 2 min · jiezi

关于nebula:nebula-error-while-loading-shared-libraries-libreadlineso6

问题形容操作系统为centos8运行命令报错 ./nebula: error while loading shared libraries: libreadline.so.6: cannot open shared object file: No such file or directory揣测可能是零碎版本为centos8,相应的库版本不对应,尝试通过增加软链解决 解决方案于/usr/lib64下增加软链 sudo ln -s libreadline.so.7.0 libreadline.so.6再次运行时报错变为 ./nebula: error while loading shared libraries: libncurses.so.5: cannot open shared object file: No such file or directory再次增加相应软链 sudo ln -s libncurses.so.6 libncurses.so.5再次运行时报错变为 ./nebula: error while loading shared libraries: libtinfo.so.5: cannot open shared object file: No such file or directory依据报错信息判断后再次增加软链 sudo ln -s libtinfo.so libtinfo.so.5再次运行时发现可失常运行 总结通过增加多条软链可解决该问题 ...

August 23, 2021 · 1 min · jiezi

关于nebula:解析-Nebula-Graph-子图设计及实践

本文首发于 Nebula Graph 公众号 NebulaGraphCommunity,Follow 看大厂图数据库技术实际。 前言在先前的 Query Engine 源码解析中,咱们介绍了 2.0 中 Query Engine 和 1.0 的次要变动和大体的构造: 大家能够大略理解到用户通过客户端发送一条查问语句,Query Engine 是如何解析语句、把语句构建为形象语法树,在形象语法树进行校验、生成执行打算的过程。本文会通过 2.0 中新增的子图算法模块持续解说 Query Engine 背地所做的内容,并着重介绍执行打算生成的过程,以便增强你对源码更好地了解。 子图的定义子图是指节点汇合和边汇合别离是某一图的节点集的子集和边集的子集的图。直观地了解,就是从用户指定的终点开始登程沿着指定的边一步步拓展,直到达到用户所设定的步数为止,而后返回在拓展过程中遇到的所有点集和边集。 子图的语法GET SUBGRAPH [<step_count> STEPS] FROM {<vid>, <vid>...} [IN <edge_type>, <edge_type>...][OUT <edge_type>, <edge_type>...] [BOTH <edge_type>, <edge_type>...]step_count:指定从起始点开始的跳数,返回从 0 到 step_count 跳的子图。必须是非负整数。默认值为 1vid:指定起始点 IDedge_type:指定边类型。能够用 IN、OUT 和 BOTH 来指定起始点上该边类型的方向。默认为 BOTH子图的实现当 Query Engine 接管到 GET SUBGRAPH 命令后,Parser 模块(由 flex 和 bison 实现)会依据曾经写好的规定(parser.yy 中 get_subgraph_sentence 规定)把所须要的内容从查问语句中提取进去,生成一个形象语法树,如下所示: 而后进入 Validate 阶段,此时对生成的形象语法树进行校验,目标是为了验证用户的输出是否非法(参考 Query Engine 的文章),当校验通过后,会把语法树中的内容提取进去,生成一个执行打算。那么这个执行打算是如何生成的呢?对同一性能不同的数据库厂商可能会生成不同的执行打算,然而原理都是雷同的。那就是要看本身的算子有哪些和查问层和存储层是如何进行交互的。因为咱们的每一条查问语句到最初都是要从存储层取数据的。在 Nebula Graph 中 Query Engine 和存储层是通过 RPC 形式(fbthrift)进行交互的(接口定义在 common 仓中的 interface 目录下)。这里有两个十分要害的接口 getNeighbors 和 getProps 须要理解一下。 ...

June 25, 2021 · 2 min · jiezi

关于nebula:百亿级图数据在快手安全情报的应用与挑战

本文首发于 Nebula Graph 公众号 NebulaGraphCommunity,Follow 看大厂图数据库技术实际。 【作者介绍】 戚名钰:快手平安-挪动平安组,次要负责快手平安情报平台的建设倪雯:快手数据平台-分布式存储组,次要负责快手图数据库的建设姚靖怡:快手数据平台-分布式存储组,次要负责快手图数据库的建设【公司简介】 快手是一家寰球当先的内容社区和社交平台,旨在通过短视频的形式帮忙人们发现所需、发挥所长,继续晋升每个人独特的幸福感。 一. 为什么须要图数据库传统的关系型数据库,在解决简单数据关系运算上体现很差,随着数据量和深度的减少,关系型数据库无奈在无效的工夫内计算出后果。 所以,为了更好的体现数据间的连贯,企业须要一种将关系信息存储为实体、灵便拓展数据模型的数据库技术,这项技术就是图数据库(Graph Database)。 相比于传统关系型数据库,图数据库具备以下两个长处: 第一点,图数据库能很好地体现数据之间的关联关系 从下面的图模型能够看出,图数据库的指标就是基于图模型以一种直观的形式来展现这些关系,其基于事物关系的模型表白,使图数据库人造具备可解释性。 第二点,图数据库能很好地解决数据之间的关联关系: 高性能:传统关系型数据库在解决关联关系数据时次要靠 JOIN 操作,而随着数据量的增多和关联深度的减少,受制于多表连贯与外键束缚,传统关系型数据库会导致较大的额定开销,产生重大的性能问题。而图数据库从底层适配了图模型的数据结构,使得它的数据查问与剖析速度更快。灵便:图数据库有非常灵活的数据模型,使用者能够依据业务变动随时调整图数据结构模型,能够任意增加或删除顶点、边,裁减或者放大图模型等,这种频繁的数据schema更改在图数据库上能到很好的反对。麻利:图数据库的图模型十分直观,反对测试驱动开发模式,每次构建时可进行功能测试和性能测试,合乎当今最风行的麻利开发需要,对于进步生产和交付效率也有肯定帮忙。基于以上两个长处,图数据库在金融反欺诈、公安刑侦、社交网络、常识图谱、数据血统、IT 资产及运维、威逼情报等畛域有微小需要。 而快手平安情报则是通过整合挪动端、PC Web 端、云端、联盟及小程序等全链条的平安数据,最终造成对立的根底平安能力赋能公司业务。 因为平安情报自身具备数据实体多样性、关联关系复杂性、数据标签丰富性等特点,因而采纳图数据库来做是最为适合的。 二. 为什么抉择 Nebula Graph通过收集需要及后期调研,快手平安情报在图数据库上最终抉择了Nebula Graph作为生产环境的图数据库。 2.1 需要收集对于图数据库的选型来说,其次要需要是在数据写入与数据查问两个方面: 数据写入形式:离线 + 在线 须要反对天级的离线数据批量导入,每天新增写入数据量在百亿级别,要求当天产生的关联关系数据,小时级能写完须要反对数据的实时写入,Flink 从 Kafka 中生产数据,并在做完逻辑解决之后,间接对接图数据库,进行数据的实时写入,须要反对的 QPS 在 10W 量级数据查问形式:毫秒级的在线实时查问,须要反对的 QPS 在 5W 量级 点及边的属性过滤及查问多度关联关系的查问局部根本图数据分析能力 图最短门路算法等综上所述,此次选型的实用于大数据架构的图数据库次要须要提供 3 种根本能力:实时和离线数据写入、在线图数据根本查问、基于图数据库的简略 OLAP 剖析,其对应定位是:在线、高并发、低时延 OLTP 类图查问服务及简略 OLAP 类图查问能力。 2.2 选型基于以上的确定性需要,在进行图数据库的选型上,咱们次要思考了以下几点: 图数据库所能反对的数据量必须要足够大,因为企业级的图数据常常会达到百亿甚至千亿级别集群可线性拓展,因为须要可能在生产环境不停服的状况下在线扩大机器查问性能要达到毫秒级,因为须要满足在线服务的性能要求,且随着图数据量的增多,查问性能不受影响可能较不便的与 HDFS、Spark 等大数据平台买通,前期可能在此基础上搭建图计算平台2.3 Nebula Graph的特点 高性能:提供毫秒级读写可扩大:可程度扩容,反对超大规模图存储引擎架构:存储与计算拆散图数据模型:点(vertex)、边(edge),并且反对点或边的属性(properties)建模查询语言:nGQL,类 SQL 的查询语言,易学易用,满足简单业务需要提供了较为丰盛和欠缺的数据导入导出工具Nebula Graph 作为开源图数据库产品,在开源社区具备良好的活跃度相较于 JanusGraph 和 HugeGraph,Nebula Graph查问性能有极大的晋升正是基于Nebula Graph的以上特点以及对咱们应用场景和需要的恰好满足,因而最终抉择Nebula Graph作为咱们生产环境的图数据库来应用。 ...

May 18, 2021 · 2 min · jiezi

关于nebula:手把手教你从数据预处理开始体验图数据库

本文首发于 Nebula 公众号:手把手教你从数据预处理开始体验图数据库,由社区用户 Jiayi98 供稿,分享了她离线部署 Nebula Graph、预处理 LDBC 数据集的教训,是个对老手极度敌对的手把手教你学 Nebula 分享。 这不是一个规范的压力测试,而是通过一个小规模的测试帮忙我相熟 Nebula 的部署,数据导入工具,查询语言,Java API,数据迁徙,以及集群性能的一个简略理解。 筹备所有的筹备都须要找个有网的环境 docker RPM 包 https://docs.docker.com/engine/install/centos/#install-from-a-packagedocker-compose tar 包 https://github.com/docker/compose/releases提前下载镜像 https://hub.docker.com/search?q=vesoft&type=image,将 metad、graphd、storaged、console、studio、http-gateway、http-client、nginx、importer(用 docker save xxx 命令将拉好的镜像导出成 tar 包)配置文件 https://github.com/vesoft-inc/nebula-docker-compose/blob/docker-swarm/docker-stack.yamlnebula-studio GitHub 上下载 zip 包 https://github.com/vesoft-inc/nebula-web-docker装置装置 Docker:$ rpm -ivh <rpm包>$ systemctl start docker --启动$ systemctl status docker --查看状态装置 docker-compose$ mv docker-compose /usr/local/bin/ --把docker-compose文件挪动到/usr/local/bin$ chmod a+x /usr/local/bin/docker-compose --改权限$ docker-compose -version导入镜像$ docker load <镜像tar包>$ docker image ls在机器 manager machine 上执行以下命令初始化 Docker Swarm 集群:$ sudo docker swarm init --advertise-addr <manager machine ip>依据提醒在另一台服务器上以 worker 的身份 join swarm$ docker node ls增加 worker node 如果呈现以下报错:Error response from daemon: rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing dial tcp 172.16.9.129:2377: connect: no route to host" ...

April 22, 2021 · 2 min · jiezi

关于nebula:Nebula-Storage-20-存储格式

随着 2.0 各版本的陆续公布,Nebula Graph 迎来了一系列的改变,在存储方面,影响最大的改变就是底层编码格局进行了批改。Nebula Graph 的底层存储是基于 KV 保留在 RocksDB 中,本文将介绍新老编码格局的差别,以及为什么要批改存储格局等一系列问题。 1.0 版本的格局咱们先简略回顾下 1.0 版本的编码格局,不相熟的能够参考这篇博客《Nebula 架构分析系列(一)图数据库的存储设计》。因为在 1.0 版本中,点的 ID 只可能用整型来示意,所以底层所有 VertexID 都是以 int64 来保留的。 点的格局 边的格局 给定任何一个 VertexID,通过 hash,能够失去对应的 PartID,因而对于一个点和这个点的所有边(边用终点计算 hash),都会映射到同一个分片中。须要指出的是,在 1.0 版本中,点和边的第一个字节的 Type 是雷同的。也就是说,对于一个点而言,它的所有 tag 并没有在物理上间断保留,比方可能是如下保留的。对于这个 src 这个点的三个 tag(tag1 tag2 tag3),实际上可能会被其余边隔开。 这个格局可能满足 1.0 绝大多数接口的须要,比方 fetch 和 go 都只须要指定对应前缀,就能获取对应数据。 2.0 版本的格局在 GA 之前公布的版本,底层存储格局其实和 1.0 是基本相同的。如果 VertexID 是整型,和 1.0 格局完全一致。而如果 VertexID 类型反对 string,则从占用 8 个字节的 int64 改成了固定长度的 FIXED_STRING,长度须要用户在 create space 时候指定长度。对于有余的长度零碎主动应用 \0 补齐,而超过指定长度的 VertexID 会间接报错。 ...

March 10, 2021 · 2 min · jiezi

关于nebula:在-Spark-数据导入中的一些实践细节

本文由合合信息大数据团队柳佳浩撰写1.前言图谱业务随着工夫的推移愈发的复杂化,逐步体现出了性能上的瓶颈:单机不足以反对更大的图谱。然而,从性能上来看,Neo4j 的原生图存储有着不可代替的性能劣势,这一点是之前调研的 JanusGraph、Dgraph 等都难以逾越的鸿沟。即便 JanusGraph 在 OLAP 下面十分杰出,对 OLTP 也有肯定的反对,然而 GraphFrame 等也足以撑持其 OLAP 需要,更何况在 Spark 3.0 会提供 Cypher 反对的状况下,图谱的 OLAP 需要相比 OLTP 有更多路径能够解决。这个时候,Nebula Graph 的“横空出世”无疑是对分布式 OLTP 效率低下现状的一种冲破。 之前在各类调研、部署后,特地是从 JanusGraph 的 OLTP 效率最终测试发现无奈满足线上需要之后,咱们不再对同一图谱能够同时进行 OLAP 和 OLTP 进行强制性要求,而 Nebula Graph 的架构刚好合乎图谱方面的须要: 分布式——shared-nothing 分布式架构高速 OLTP(性能须要和 Neo4j 相近)——Nebula Graph 的存储层架构查问间接映射物理地址,实际上能够算是原生图存储服务的高可用(即在非人为状况下,图谱能够稳固提供服务)——部分失败服务可用、有快照机制保障可扩展性——反对线性扩容,因为开源、反对二次开发综上所述,Nebula Graph 架构上符合实际生产需要,因而对 Nebula Graph 进行了调研、部署、测试。对于部署、性能测试(美团 NLP 团队性能测试、腾讯云平安团队性能测试)的局部无论是官网还是其他同学在博客中都有比拟详尽的数据,本文次要从 Spark 导入登程,算是对 Nebula Graph 对 Spark 的反对进行浅显的了解。 2.测试环境Nebula Graph 集群 3 台 32 c(理论限度了16 c)400 G 内存(理论配置了 100 G)SSD版本信息:Nebula Graph 版本 1.0.0(过后测试比拟早)。网络环境:万兆。图谱大小:十亿级别节点(属性较少),百亿级别边(有向,无属性或带权值)。Spark 集群 ...

November 25, 2020 · 2 min · jiezi

关于nebula:基于-Nebula-Operator-的-K8s-自动化部署运维

摘要:Nebula Operator 是 Nebula Graph 在 Kubernetes 零碎上的自动化部署运维插件。在本文,你将理解到 Nebula Operator 的个性及它的工作原理。 从 Nebula Graph 的架构谈起 Nebula Graph 是一个高性能的分布式开源图数据库,从架构上能够看出,一个残缺的 Nebula Graph 集群由三类服务组成,即 Meta Service, Query Service(Computation Layer)和 Storage Service(Storage Layer)。 每类服务都是一个由多正本组件组成的集群,在 Nebula Operator 中,咱们别离称这三类组件为: Metad / Graphd / Storaged。 Metad:次要负责提供和存储图数据库的元数据,并承当集群中调度器的角色,指挥存储扩容和数据迁徙,leader 变更等运维操作。Graphd:次要负责解决 Nebula 查询语言语句(nGQL),每个 Graphd 都运行着一个无状态的查问计算引擎,且彼此间无任何通信关系。计算引擎仅从 Metad 集群中读取元信息,并和 Storaged 集群进行交互。同时,它也负责不同客户端的接入和交互。Storaged:次要负责 Graph 数据存储。图数据被切分成很多的分片 Partition,雷同 ID 的 Partition 组成一个 Raft Group,实现多正本一致性。Nebula Graph 默认的存储引擎是 RocksDB 的 Key-Value 存储。在理解了 Nebula Graph 外围组件的性能后,咱们能够得出一些论断: ...

November 18, 2020 · 2 min · jiezi

关于nebula:用-Docker-swarm-快速部署分布式图数据库-Nebula-Graph-集群

本文作者系:视线金服工程师 | 吴海胜首发于 Nebula Graph 论坛:https://discuss.nebula-graph.com.cn/t/topic/1388一、前言本文介绍如何应用 Docker Swarm 来部署 Nebula Graph 集群,并部署客户端负载平衡和高可用。 二、nebula 集群搭建2.1 环境筹备机器筹备 在装置前确保所有机器已装置 Docker 2.2 初始化 swarm 集群在 192.168.1.166 机器上执行 $ docker swarm init --advertise-addr 192.168.1.166Swarm initialized: current node (dxn1zf6l61qsb1josjja83ngz) is now a manager.To add a worker to this swarm, run the following command: docker swarm join \ --token SWMTKN-1-49nj1cmql0jkz5s954yi3oex3nedyz0fb0xx14ie39trti4wxv-8vxv8rssmk743ojnwacrr2e7c \ 192.168.1.166:2377 To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.2.3 退出 worker 节点依据 init 命令提醒内容,退出 swarm worker 节点,在 192.168.1.167 192.168.1.168 别离执行 ...

October 14, 2020 · 7 min · jiezi

关于nebula:一文了解-Nebula-Graph-DBaaS-服务Nebula-Graph-Cloud-Service

Nebula Graph DBaaS作为一款 DBaaS(DataBase as s Service)的产品,Nebula Graph Cloud Service 极大地升高了研发人员应用 Nebula Graph 的老本,更专一于应用 Nebula Graph 开掘、剖析数据背地的关联价值。 Nebula Graph Cloud Service Trial 版本已于近期开始公测试用,本篇文章次要帮忙感兴趣的敌人疾速理解咱们云服务 Trial 版本的次要性能及凋谢范畴。 次要性能一键创立 Nebula Graph 云服务实例权限治理 - 可邀请其余 Nebula Graph Cloud Service 注册用户一起应用实例日志记录 - 记录查看实例无关操作记录 提供在线 Nebula Graph Studio——图数据库可视化工具:控制台 - 疾速尝试 nebula 语句的基本功能图摸索 - 通过图可视化挖掘数据之间的分割导数据 - 通过可视化配置将数据导入 nebula可视化构图 - 通过可视化操作,迅速实现 点/边 构图建模(近期公布) 服务监控 - 实时洞察机器运行的根本状况 团队治理 - 简略的团队创立及成员增加,不便实例所属权的转移和交接 公测范畴首次理解 Nebula Graph 图数据库,想要疾速无障碍体验 Nebula Graph 产品服务有图数据库应用需要的用户,诸如金融风控、实时举荐、常识图谱等利用场景企业用户:最好应用公司邮箱注册,无限的试用资源能帮忙真正须要尝试的敌人Trial 版本限度试用期间无奈提供独立 IP 供业务客户端直连,所有偏重产品性能体验为主,商用版本会提供。试用期提供的实例服务均为单正本的对立资源:1G 内存单核40G 磁盘大小其余:商用版本会通过资源配置抉择。数据导入时上传的数据集单个文件大小不能超过 100M,总文件大小限度 1G。试用链接及官网联系方式欢送感兴趣的敌人前来申请试用:https://cloud.nebula-graph.com.cn/,有更多需要和问题征询的敌人,也欢送分割咱们????。 ...

September 25, 2020 · 1 min · jiezi

关于nebula:从-Neo4j-导入-Nebula-Graph-实践见-SPark-数据导入原理

本文次要讲述如何应用数据导入工具 Nebula Graph Exchange 将数据从 Neo4j 导入到 Nebula Graph Database。在讲述如何实操数据导入之前,咱们先来理解下 Nebula Graph 外部是如何实现这个导入性能的。 Nebula Graph Exchange 的数据处理原理咱们这个导入工具名字是 Nebula Graph Exchange,采纳 Spark 作为导入平台,来反对海量数据的导入和保障性能。Spark 自身提供了不错的形象——DataFrame,使得能够轻松反对多种数据源。在 DataFrame 的反对下,增加新的数据源只需提供配置文件读取的代码和返回 DataFrame 的 Reader 类,即可反对新的数据源。 DataFrame 能够视为一种分布式存表格。DataFrame 能够存储在多个节点的不同分区中,多个分区能够存储在不同的机器上,从而反对并行操作。Spark 还提供了一套简洁的 API 使用户轻松操作 DataFrame 如同操作本地数据集个别。当初大多数数据库提供间接将数据导出成 DataFrame 性能,即便某个数据库并未提供此性能也能够通过数据库 driver 手动构建 DataFrame。 Nebula Graph Exchange 将数据源的数据处理成 DataFrame 之后,会遍历它的每一行,依据配置文件中 fields 的映射关系,按列名获取对应的值。在遍历 batchSize 个行之后,Exchange 会将获取的数据一次性写入到 Nebula Graph 中。目前,Exchange 是通过生成 nGQL 语句再由 Nebula Client 异步写入数据,下一步会反对间接导出 Nebula Graph 底层存储的 sst 文件,以获取更好的性能。接下来介绍一下 Neo4j 数据源导入的具体实现。 ...

September 16, 2020 · 3 min · jiezi

关于nebula:360-数科实践JanusGraph-到-NebulaGraph-迁移

摘要:在本文中 360 数科的周鹏具体解说了业务从 JanusGraph 迁徙到 Nebula Graph 带来的性能晋升,在机器资源不到之前 JanusGraph 配置三分之一的状况下,业务性能晋升至多 20 倍。 本文作者系 360 数科开发工程师:周鹏迁徙背景咱们之前图数据用的是单机版的 AgensGraph, 前面因为单机带来的性能限度问题,迁徙到了分布式数据库 JanusGraph,具体的迁徙信息能够看我之前的一篇文章《百亿级图数据JanusGraph迁徙之旅》。然而随着数据量和业务调用量的减少,新的问题又呈现了——单次查问的耗时很高个别业务场景曾经到了 10s,数据量略微多点,逻辑简单点的查问耗时也在 2~3s 左右,这重大影响了整个业务流程的性能和相干业务的倒退。 JanusGraph 的架构决定了单次耗时高,外围的起因在于它的存储依赖内部,本身不能很好地管制内部存储,咱们生产环境用的便是 HBase 集群,这导致所有的查问没法下推到存储层进行解决,只能把数据从 HBase 查问到 JanusGraph Server 内存再做相应的过滤。 举个例子,查问一层关联关系年龄大于 50 岁的用户,如果一层关联有 1,000 人,年龄大于 50 岁的只有 2 集体。介于 JanusGraph 查问申请发送到 HBase 时做不了一层关联顶点属性的过滤,咱们不得不通过并发申请去查问 HBase 获取这 1,000 人的顶点属性,再在 JanusGraph Server 的内存做过滤,最初返回给客户端满足条件的 2 个用户。 这样做的问题就是磁盘 IO、网络 IO 节约很大,而且查问返回的大多数据在而后查的查问并未用到。咱们生产环境用的 HBase 为 19 台高配 SSD 服务器的,具体的网络 IO、磁盘 IO 应用状况如下图: ...

September 9, 2020 · 2 min · jiezi

关于nebula:新手阅读-Nebula-Graph-源码的姿势

摘要:在本文中,咱们将通过数据流疾速学习 Nebula Graph,以用户在客户端输出一条 nGQL 语句 SHOW SPACES 为例,应用 GDB 追踪语句输出时 Nebula Graph 是怎么调用和运行的。首发于 Nebula Graph 博客:https://nebula-graph.com.cn/p... 导读对于一些刚开始接触 Nebula Graph 开源库的小伙伴来说,刚开始可能和我一样,想要进步本人,看看大神们的代码而后试着可能做点什么,或者可能修复一个看起来并不是那么艰难的 Bug。然而面对如此多的代码,我裂开了,不晓得如何下手。最初硬着头皮,再看了一遍又一遍代码,跑了一个又一个用例之后终于有点头绪了。 上面就分享下集体学习 Nebula Graph 开源代码的过程,也心愿刚接触 Nebula Graph 的小伙伴可能少走弯路,疾速入门。另外 Nebula Graph 自身也用到了一些开源库,详情能够见附录。 在本文中,咱们将通过数据流疾速学习 Nebula Graph,以用户在客户端输出一条 nGQL 语句 SHOW SPACES 为例,应用 GDB 追踪语句输出时 Nebula Graph 是怎么调用和运行的。 整体架构 一个残缺的 Nebula Graph 蕴含三个服务,即 Query Service,Storage Service 和 Meta Service。每个服务都有其各自的可执行二进制文件。 Query Service 次要负责 客户端连贯的治理解析来自客户端的 nGQL 语句为形象语法树 AST,并将形象树 AST 解析成一系列执行动作。对执行动作进行优化执行优化后的执行打算Storage Service 次要负责 ...

August 5, 2020 · 2 min · jiezi