每日新闻

每日新闻

GoCN每日新闻资讯
有问必答

有问必答

Go相关的问题,技术相关的问题
文章分享

文章分享

技术文章分享,让知识传播给更多的人
招聘应聘

招聘应聘

为Gopher服务的招聘应聘平台

为什么大公司一定要使用 DevOps?

回复

文章分享CORNERSTONE 发起了问题 • 1 人关注 • 0 个回复 • 138 次浏览 • 5 天前 • 来自相关话题

Golang 扁平项目代码结构

技术讨论jjjjerk 发表了文章 • 0 个评论 • 305 次浏览 • 5 天前 • 来自相关话题

原文地址 https://mojotv ...查看全部

GoCN每日新闻(2019-10-18)

回复

每日新闻DennisMao 发起了问题 • 1 人关注 • 0 个回复 • 4297 次浏览 • 5 天前 • 来自相关话题

是否可以增加一个用 go 编写的开源(国产,或者全部)项目列表呢

开源程序DennisMao 回复了问题 • 3 人关注 • 3 个回复 • 228 次浏览 • 5 天前 • 来自相关话题

[深圳]深圳寻找母星招聘Golang开发工程师

回复

招聘应聘huangzien 发起了问题 • 1 人关注 • 0 个回复 • 183 次浏览 • 6 天前 • 来自相关话题

GoCN每日新闻(2019-10-17)

回复

每日新闻keke001 发起了问题 • 1 人关注 • 0 个回复 • 5199 次浏览 • 6 天前 • 来自相关话题

DevOps落地实践,BAT系列,敏捷看板

每日新闻CORNERSTONE 发表了文章 • 0 个评论 • 370 次浏览 • 2019-10-16 17:58 • 来自相关话题

DevOps 自 2009 年诞生以来,至今整整过去了十年,从最初的摸索,逐步变成一种主流的软件开发交付模式。BAT在2014年左右,甚至更早的时候,内部的DevOps系统就已经差不多成型了,比如腾讯的织云、蓝鲸,阿里的AOne,百度的效率云等。在Dev ...查看全部

DevOps 自 2009 年诞生以来,至今整整过去了十年,从最初的摸索,逐步变成一种主流的软件开发交付模式。BAT在2014年左右,甚至更早的时候,内部的DevOps系统就已经差不多成型了,比如腾讯的织云、蓝鲸,阿里的AOne,百度的效率云等。在DevOps的研发过程中,好的看板功能有助于优化项目管理、提升开发效率,是较重要的功能之一。本文从需求分析角度入手,分析DevOps产品对看板的需求,并结合CORNERSTONE一站式云端DevOps平台看板部分的实际开发经验和用户反馈向大家介绍DevOps看板的设计实践之路。   

一.DevOps需要的看板 


看板是DevOps较为常用的功能,整个项目开发周期都离不开它,从需求划分、任务分配、功能实现到测试上线都需要看板的协助,看板使抽象工作流程可视化,让项目管理者能更清晰的掌握项目进度。由此,看板设计实践就成为了DevOps实践的重要内容之一。首先我们需要了解一下,DevOps中的看板需要具备怎样的功能:

 

1.价值流

 

广义的价值流指的是从原材料变为成品、并给他赋予价值的全部活动。包括原材料的获取,对原材料进行加工后转变为成品交付给客户的过程,其中还包括了各个阶段各方之间的沟通形成的信息流也是价值流的一部分。完整的价值流包括供应链成员之间的沟通,物料的运输,生产计划的制定和产品的生产过程等。

image.png

 

举个简单的例子,服装加工厂要按照客户要求生产一批服装,生产方首先需要和客户确定衣服的款式,用料,具体尺码信息,然后采购制衣所需的布料,将衣服制作图纸下发到相关工人手中,工人按图制衣,完成既定数量的通过质量检测的成衣后将成品送到客户手中,这就是一条完整的价值流。

 

DevOps中的价值流

 

在DevOps中,价值流的概念同样适用。定义:把业务构想转化为客户交付价值的、由技术驱动的服务所需的流程。

 

 

价值流贯穿了整个开发周期,好的价值流在保证快速的交付的同时还能保证部署工作不会产生混乱和破坏。只有打通业务、开发运维等一些列的价值链条,保证价值可以完整畅通的流动,减少积压重组,才能保证产品的顺利交付。在此前提下,提高开发效率实现敏捷开发才是可能的。但是技术价值流与制造业的价值流不同,它是不可见的,因此我们很难发现整个价值流是否顺畅,在哪里产生了阻碍积压。因此我们需要将价值流可视化,清晰的把价值流的呈现出来,这样价值流是否完整,哪里存在缺失就一目了然了。

 

二.DevOps的三步工作法基础原则

 

《凤凰项目》一书把三步工作法作为基础原则并由此衍生了DevOps的行为和模式:

 

 

(1)开发到运维的工作快速的从右向左的流动------流动原则


在保证质量的前提下加快价值流的流动速度,尽可能的优化工作流,减小流动单元合理控制流量,减少等待时间,提高工作效率,可以归结为以下几点:

  1. 使工作可见

  2. 合理控制最流动单元

  3. 减少交接次数

  4. 消除阻碍价值流的问题

(2)从右向左的每一个阶段中,应用持续、快速的工作反馈机制------反馈原则

 

反馈原则是在流动原则的基础上建立的一条信息流,价值流上的各个环节通过这条信息流沟通,好的信息流有助于及时发现并解决问题,从中分析并总结经验可以提升项目开发效率。

 

(3)建立具有创意和高可信度的企业文化,支持动态的、严格的、科学的实验——持续学习与实验原则:他打造出一种高度信任的文化和一种科学的工作方式


常见的项目中每天的站会、每周的周会一般是项目成员集中在一起交流并互相学习的机会,大家对工作作出自我总结并提出自己的想法互相交流意见,实现工作中的自我提升。

 

看板在DevOps中主要作为价值流的载体的一部分,使价值流中一些较为抽象的信息可视,并让用户可以从中看清楚价值流的流通情况、每一个环节及环节的具体操作情况,何处需要改进、何处存在问题。三步工作法则可以帮助提升工作效率。结合对价值流的概念以及三步工作法原则的分析,看板需要具备以下功能:

 

(1)清晰描述最小工作项单元及工作项间的关系

(2)提供便捷的小组成员互相沟通方式

(3)快速直接的反馈某工作项的各种情况

(4)一目了然的任务完分配集成情况,方便开会总结

 

  三.看板实践及优化 

 

首先是工作的最小单元——工作项,工作项是看板上各类工作内容的最小显示单元,负责显示工作内容的各种信息,一些类似的工作项管理看板对工作项类型进行了极为细致的划分,但过于繁杂的工作项类型难于记忆并且存在概念重复反而不利于,结合实际项目开发情况我们将工作项类型分为三类:

 

(1)故事——一个故事代表一个完整的需求点,可以包含多个任务、bug,一  个故事及其包含的所有子项目可以完整的诠释一个需求点在价值流上流通的全过程

 

(2)任务——将故事拆分为一个个的具体工作内容,分配到具体人员

 

(3)Bug——测试人员向开发人员、项目管理人员提出反馈的途径

 

工作项的要展示很多的具体信息:

 

image.png

 

(1)描述信息(标题、描述、附件、COMMENTS、所属迭代、所属版本)COMMENTS是提供给开发人员的交流空间,让开发人员可以在这里进行简短的意见交流,一些较小、内容简短的讨论可以在这里进行,无需所有相关人员聚集在一起讨论节约时间

 

(2)状态信息(工作项状态、优先级)

 

(3)人员信息(责任人、创建人、解决人)明确工作项的相关人员,责任划分明确。

 

(4)时间信息(创建时间、预估时间、耗费时间、到期时间)提供明确的时间信息,有利于项目管理者控制项目开发进度

 

(5)关联的工作项(子任务、BUG)将有关的工作项关联到一起,完整描述产品中某一项功能,从需求分析到开发实现到测试反馈的全过程

工作项设计完成后需要考虑的就是如何一个个的工作项集中在一起展示,考虑到DevOps的用户有很多不同的角色,对看板的关注角度也不同,例如项目经理更希望可以一目了然的看到任务的完成情况,开发人员需更关注的是分配给自己的工作项的具体的内容,CORNERSTONE提供

【表格、分栏、看板、甘特图、日历、统计、周汇总、分类导图】八种视图,方便企业成员通过多种角度查看项目,全方位了解项目状况。

 

(1)表格视图


信息以列表形式呈现,可拖动查看所有字段下的内容,方便概览任务情况。




(2)分栏视图


分栏视图可帮助团队成员更快的找到他所需要的信息;





(3)看板视图

看板视图可更直观的显示每种状态下的任务情况,方便团队成员及时更改任务内容;

 

 

(4)甘特图  推荐★

 

CORNERSTONE的甘特图功能可方便管理者弄清项目的剩余时间,评估工作进度,调整工作任务,更好地把握项目的整体。



 

(5)日历


CORNERSTONE的日历视图是基于时间,让项目更加易于理解的管理工具。


 

(6)统计视图

CORNERSTONE提供报表和统计图,可查看团队总体任务状态,也可查看团队成员个人工作贡献,便于把控总体项目进程。

 

 

(7)周汇总


CORNERSTONE的周汇总视图可直接提取项目中各项任务的完成情况和相应指标,自动生成简洁的分析报告。

 

Clipboard Image.png

 

(8)分类导图

CORNERSTONE的分类导图其实就是思维导图,它有一个中心主题,由中心主题发散出不同的关节点,每个关节点又可以独立成为一个分支的中心主题,整个图形呈现出放射性立体结构,这种结构更方便记性和理清思绪。

 

image.png

 

以上就是CORNERSTONE一站式云端DevOps平台看板模块的设计和实践历程,在价值流可视化和项目成员沟通等方面我们仍在持续改进,希望能打造出更便捷、更清晰的看板,完善DevOps平台看板模块。最后,回到DevOps的理念上,DevOps并不是专门称呼一项技术,也不是一套流程和方法论,更不是一套简单的工具产品,越来越多的迹象表明,DevOps是一种文化,这种文化崇尚的是以客户价值为根本导向让IT可以变得更敏捷更精益。

GoCN每日新闻(2019-10-16)

回复

每日新闻yulibaozi 发起了问题 • 1 人关注 • 0 个回复 • 5771 次浏览 • 2019-10-16 13:47 • 来自相关话题

1.8正式版已经发布,希望GoCN下载里面能同步上

站点反馈 回复了问题 • 6 人关注 • 5 个回复 • 3720 次浏览 • 2019-10-16 12:02 • 来自相关话题

[上海] 晓信科技招聘Go工程师(15~40K)

招聘应聘f1402900533 回复了问题 • 10 人关注 • 58 个回复 • 7737 次浏览 • 2019-10-16 10:24 • 来自相关话题

分享一个 go 的开源项目 - Jenkins 命令行客户端 jcli

回复

开源程序linuxsuren 发起了问题 • 1 人关注 • 0 个回复 • 82 次浏览 • 2019-10-16 10:03 • 来自相关话题

Nebula 架构剖析系列(一)图数据库的存储设计

文章分享NebulaGraph 发表了文章 • 0 个评论 • 280 次浏览 • 2019-10-15 17:05 • 来自相关话题

摘要在讨论某个数据库时,存储 ( Storage ) 和计算 ( Query Engine ) 通常是讨论的热点,也是爱好者们了解某个数据库不可或缺的部分。每个数据库都有其独有的存储、计算方式,今天就和图图来学习下图数据库 Nebula ...查看全部

摘要

在讨论某个数据库时,存储 ( Storage ) 和计算 ( Query Engine ) 通常是讨论的热点,也是爱好者们了解某个数据库不可或缺的部分。每个数据库都有其独有的存储、计算方式,今天就和图图来学习下图数据库 Nebula Graph 的存储部分。

Nebula 的 Storage 包含两个部分, 一是 meta 相关的存储, 我们称之为 Meta Service ,另一个是 data 相关的存储, 我们称之为 Storage Service。 这两个服务是两个独立的进程,数据也完全隔离,当然部署也是分别部署, 不过两者整体架构相差不大,本文最后会提到这点。 如果没有特殊说明,本文中 Storage Service 代指 data 的存储服务。接下来,大家就随我一起看一下 Storage Service 的整个架构。 Let's go~

Architecture

 图一  storage service 架构图

如图1 所示,Storage Service 共有三层,最底层是 Store Engine,它是一个单机版 local store engine,提供了对本地数据的 get / put / scan / delete 操作,相关的接口放在 KVStore / KVEngine.h 文件里面,用户完全可以根据自己的需求定制开发相关 local store plugin,目前 Nebula 提供了基于 RocksDB 实现的  Store Engine。

在 local store engine 之上,便是我们的 Consensus 层,实现了 Multi Group Raft,每一个 Partition 都对应了一组 Raft Group,这里的 Partition 便是我们的数据分片。目前 Nebula 的分片策略采用了 静态 Hash 的方式,具体按照什么方式进行 Hash,在下一个章节 schema 里会提及。用户在创建 SPACE 时需指定 Partition 数,Partition 数量一旦设置便不可更改,一般来讲,Partition 数目要能满足业务将来的扩容需求。

在 Consensus 层上面也就是 Storage Service 的最上层,便是我们的 Storage interfaces,这一层定义了一系列和图相关的 API。 这些 API 请求会在这一层被翻译成一组针对相应 Partition 的 kv 操作。正是这一层的存在,使得我们的存储服务变成了真正的图存储,否则,Storage Service 只是一个 kv 存储罢了。而 Nebula 没把 kv 作为一个服务单独提出,其最主要的原因便是图查询过程中会涉及到大量计算,这些计算往往需要使用图的 schema,而 kv 层是没有数据 schema 概念,这样设计会比较容易实现计算下推。

Schema & Partition

图存储的主要数据是点和边,但 Nebula 存储的数据是一张属性图,也就是说除了点和边以外,Nebula 还存储了它们对应的属性,以便更高效地使用属性过滤。

对于点来说,我们使用不同的 Tag 表示不同类型的点,同一个 VertexID 可以关联多个 Tag,而每一个 Tag 都有自己对应的属性。对应到 kv 存储里面,我们使用 vertexID + TagID 来表示 key,  我们把相关的属性编码后放在 value 里面,具体 key 的 format 如图2 所示:

 图二 Vertex Key Format

  • Type :  1 个字节,用来表示 key 类型,当前的类型有 data, index, system 等
  • Part ID : 3 个字节,用来表示数据分片 Partition,此字段主要用于 Partition 重新分布(balance) 时方便根据前缀扫描整个 Partition 数据
  • Vertex ID : 4 个字节, 用来表示点的 ID
  • Tag ID : 4 个字节, 用来表示关联的某个 tag
  • Timestamp : 8 个字节,对用户不可见,未来实现分布式事务 ( MVCC ) 时使用

在一个图中,每一条逻辑意义上的边,在 Nebula Graph 中会建模成两个独立的 key-value,分别称为 out-key 和in-key。out-key 与这条边所对应的起点存储在同一个 partition 上,in-key 与这条边所对应的终点存储在同一个partition 上。通常来说,out-key 和 in-key 会分布在两个不同的 Partition 中。

两个点之间可能存在多种类型的边,Nebula 用 Edge Type 来表示边类型。而同一类型的边可能存在多条,比如,定义一个 edge type "转账",用户 A 可能多次转账给 B, 所以 Nebula 又增加了一个 Rank 字段来做区分,表示 A 到 B 之间多次转账记录。 Edge key 的 format 如图3 所示:

 图三 Edge Key Format

  • Type :  1 个字节,用来表示 key 的类型,当前的类型有 data, index, system 等。
  • Part ID : 3 个字节,用来表示数据分片 Partition,此字段主要用于 Partition 重新分布(balance) 时方便根据前缀扫描整个 Partition 数据
  • Vertex ID : 4 个字节, 出边里面用来表示源点的 ID, 入边里面表示目标点的 ID。
  • Edge Type : 4 个字节, 用来表示这条边的类型,如果大于 0 表示出边,小于 0 表示入边。
  • Rank : 4 个字节,用来处理同一种类型的边存在多条的情况。用户可以根据自己的需求进行设置,这个字段可_存放交易时间_、交易流水号、或_某个排序权重_
  • Vertex ID : 4 个字节,  出边里面用来表示目标点的 ID, 入边里面表示源点的 ID。
  • Timestamp : 8 个字节,对用户不可见,未来实现分布式做事务的时候使用。

针对 Edge Type 的值,若如果大于 0 表示出边,则对应的 edge key format 如图4 所示;若 Edge Type 的值小于 0,则对应的 edge key format 如图5 所示

 图4 出边的 Key Format  图5 入边的 Key Format

对于点或边的属性信息,有对应的一组 kv pairs,Nebula 将它们编码后存在对应的 value 里。由于 Nebula 使用强类型 schema,所以在解码之前,需要先去 Meta Service 中取具体的 schema 信息。另外,为了支持在线变更 schema,在编码属性时,会加入对应的 schema 版本信息,具体的编解码细节在这里不作展开,后续会有专门的文章讲解这块内容。

OK,到这里我们基本上了解了 Nebula 是如何存储数据的,那数据是如何进行分片呢?很简单,对 Vertex ID 取模 即可。通过对 Vertex ID 取模,同一个点的所有_出边_,_入边_以及这个点上所有关联的 _Tag 信息_都会被分到同一个 Partition,这种方式大大地提升了查询效率。对于在线图查询来讲,最常见的操作便是从一个点开始向外 BFS(广度优先)拓展,于是拿一个点的出边或者入边是最基本的操作,而这个操作的性能也决定了整个遍历的性能。BFS 中可能会出现按照某些属性进行剪枝的情况,Nebula 通过将属性与点边存在一起,来保证整个操作的高效。当前许多的图数据库通过 Graph 500 或者 Twitter 的数据集试来验证自己的高效性,这并没有代表性,因为这些数据集没有属性,而实际的场景中大部分情况都是属性图,并且实际中的 BFS 也需要进行大量的剪枝操作。

KVStore

为什么要自己做 KVStore,这是我们无数次被问起的问题。理由很简单,当前开源的 KVStore 都很难满足我们的要求:

  • 性能性能性能:Nebula 的需求很直接:高性能 pure kv;
  • 以 library 的形式提供:对于强 schema 的 Nebula 来讲,计算下推需要 schema 信息,而计算下推实现的好坏,是 Nebula 是否高效的关键;
  • 数据强一致:这是分布式系统决定的;
  • 使用 C++实现:这由团队的技术特点决定;

基于上述要求,Nebula 实现了自己的 KVStore。当然,对于性能完全不敏感且不太希望搬迁数据的用户来说,Nebula 也提供了整个KVStore 层的 plugin,直接将 Storage Service 搭建在第三方的 KVStore 上面,目前官方提供的是 HBase 的 plugin。

Nebula KVStore 主要采用 RocksDB 作为本地的存储引擎,对于多硬盘机器,为了充分利用多硬盘的并发能力,Nebula 支持自己管理多块盘,用户只需配置多个不同的数据目录即可。分布式 KVStore 的管理由 Meta Service 来统一调度,它记录了所有 Partition 的分布情况,以及当前机器的状态,当用户增减机器时,只需要通过 console 输入相应的指令,Meta Service 便能够生成整个 balance plan 并执行。(之所以没有采用完全自动 balance 的方式,主要是为了减少数据搬迁对于线上服务的影响,balance 的时机由用户自己控制。)

为了方便对于 WAL 进行定制,Nebula KVStore 实现了自己的 WAL 模块,每个 partition 都有自己的 WAL,这样在追数据时,不需要进行 wal split 操作, 更加高效。 另外,为了实现一些特殊的操作,专门定义了 Command Log 这个类别,这些 log 只为了使用 Raft 来通知所有 replica 执行某一个特定操作,并没有真正的数据。除了 Command Log 外,Nebula 还提供了一类日志来实现针对某个 Partition 的 atomic operation,例如 CAS,read-modify-write,  它充分利用了Raft 串行的特性。

关于多图空间(space)的支持:一个 Nebula KVStore 集群可以支持多个 space,每个 space 可设置自己的 partition 数和 replica 数。不同 space 在物理上是完全隔离的,而且在同一个集群上的不同 space 可支持不同的 store engine 及分片策略。

Raft

作为一个分布式系统,KVStore 的 replication,scale out 等功能需 Raft 的支持。当前,市面上讲 Raft 的文章非常多,具体原理性的内容,这里不再赘述,本文主要说一些 Nebula Raft 的一些特点以及工程实现。

Multi Raft Group

由于 Raft 的日志不允许空洞,几乎所有的实现都会采用 Multi Raft Group 来缓解这个问题,因此 partition 的数目几乎决定了整个 Raft Group 的性能。但这也并不是说 Partition 的数目越多越好:每一个 Raft Group 内部都要存储一系列的状态信息,并且每一个 Raft Group 有自己的 WAL 文件,因此 Partition 数目太多会增加开销。此外,当 Partition 太多时, 如果负载没有足够高,batch 操作是没有意义的。比如,一个有 1w tps 的线上系统单机,它的单机 partition 的数目超过 1w,可能每个 Partition 每秒的 tps 只有 1,这样 batch 操作就失去了意义,还增加了 CPU 开销。 实现 Multi Raft Group 的最关键之处有两点,** 第一是共享 Transport 层**,因为每一个 Raft Group 内部都需要向对应的 peer  发送消息,如果不能共享 Transport 层,连接的开销巨大;第二是线程模型,Mutli Raft Group 一定要共享一组线程池,否则会造成系统的线程数目过多,导致大量的 context switch 开销。

Batch

对于每个 Partition来说,由于串行写 WAL,为了提高吞吐,做 batch 是十分必要的。一般来讲,batch 并没有什么特别的地方,但是 Nebula 利用每个 part 串行的特点,做了一些特殊类型的 WAL,带来了一些工程上的挑战。

举个例子,Nebula 利用 WAL 实现了无锁的 CAS 操作,而每个 CAS 操作需要之前的 WAL 全部 commit 之后才能执行,所以对于一个 batch,如果中间夹杂了几条 CAS 类型的 WAL, 我们还需要把这个 batch 分成粒度更小的几个 group,group 之间保证串行。还有,command 类型的 WAL 需要它后面的 WAL 在其 commit 之后才能执行,所以整个 batch 划分 group 的操作工程实现上比较有特色。

Learner

Learner 这个角色的存在主要是为了 应对扩容 时,新机器需要"追"相当长一段时间的数据,而这段时间有可能会发生意外。如果直接以 follower 的身份开始追数据,就会使得整个集群的 HA 能力下降。 Nebula 里面 learner 的实现就是采用了上面提到的 command wal,leader 在写 wal 时如果碰到 add learner 的 command, 就会将 learner 加入自己的 peers,并把它标记为 learner,这样在统计多数派的时候,就不会算上 learner,但是日志还是会照常发送给它们。当然 learner 也不会主动发起选举。

Transfer Leadership

Transfer leadership 这个操作对于 balance 来讲至关重要,当我们把某个 Paritition 从一台机器挪到另一台机器时,首先便会检查 source 是不是 leader,如果是的话,需要先把他挪到另外的 peer 上面;在搬迁数据完毕之后,通常还要把 leader 进行一次 balance,这样每台机器承担的负载也能保证均衡。

实现 transfer leadership, 需要注意的是 leader 放弃自己的 leadership,和 follower 开始进行 leader election 的时机。对于 leader 来讲,当 transfer leadership command 在 commit 的时候,它放弃 leadership;而对于 follower 来讲,当收到此 command 的时候就要开始进行 leader election, 这套实现要和 Raft 本身的 leader election 走一套路径,否则很容易出现一些难以处理的 corner case。

Membership change

为了避免脑裂,当一个 Raft Group 的成员发生变化时,需要有一个中间状态, 这个状态下 old group 的多数派与 new group 的多数派总是有 overlap,这样就防止了 old group 或者新 group 单方面做出决定,这就是论文中提到的 joint consensus 。为了更加简化,Diego Ongaro 在自己的博士论文中提出每次增减一个 peer 的方式以保证 old group 的多数派总是与 new group 的多数派有 overlap。 Nebula 的实现也采用了这个方式,只不过 add member 与 remove member 的实现有所区别,具体实现方式本文不作讨论,有兴趣的同学可以参考 Raft Part class 里面 addPeer  /  removePeer  的实现。

Snapshot

Snapshot 如何与 Raft 流程结合起来,论文中并没有细讲,但是这一部分我认为是一个 Raft 实现里最容易出错的地方,因为这里会产生大量的 corner case。

举一个例子,当 leader 发送 snapshot 过程中,如果 leader 发生了变化,该怎么办? 这个时候,有可能 follower 只接到了一半的 snapshot 数据。 所以需要有一个 Partition 数据清理过程,由于多个 Partition 共享一份存储,因此如何清理数据又是一个很麻烦的问题。另外,snapshot 过程中,会产生大量的 IO,为了性能考虑,我们不希望这个过程与正常的 Raft 共用一个 IO threadPool,并且整个过程中,还需要使用大量的内存,如何优化内存的使用,对于性能十分关键。由于篇幅原因,我们并不会在本文对这些问题展开讲述,有兴趣的同学可以参考 SnapshotManager  的实现。

Storage Service

在 KVStore 的接口之上,Nebula 封装有图语义接口,主要的接口如下:

  • getNeighbors :  查询一批点的出边或者入边,返回边以及对应的属性,并且需要支持条件过滤;
  • Insert vertex/edge :  插入一条点或者边及其属性;
  • getProps : 获取一个点或者一条边的属性;

这一层会将图语义的接口转化成 kv 操作。为了提高遍历的性能,还要做并发操作。

Meta Service

在 KVStore 的接口上,Nebula 也同时封装了一套 meta 相关的接口。Meta Service 不但提供了图 schema 的增删查改的功能,还提供了集群的管理功能以及用户鉴权相关的功能。Meta Service 支持单独部署,也支持使用多副本来保证数据的安全。

总结

这篇文章给大家大致介绍了 Nebula Storage 层的整体设计, 由于篇幅原因, 很多细节没有展开讲, 欢迎大家到我们的微信群里提问,加入 Nebula Graph 交流群,请联系 Nebula Graph 官方小助手微信号:NebulaGraphbot。

相关阅读

附录

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

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

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

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

GoCN每日新闻(2019-10-15)

回复

每日新闻傅小黑 发起了问题 • 1 人关注 • 0 个回复 • 6536 次浏览 • 2019-10-15 15:34 • 来自相关话题

HTTP-Reverse-Proxy反向代理Nginx硬件指纹校验

文章分享jjjjerk 发表了文章 • 0 个评论 • 280 次浏览 • 2019-10-15 15:06 • 来自相关话题

原文地址 https://moj ...查看全部

趣头条 数据中心 急招高级Golang开发工程师、玩转海量数据

招聘应聘Frankfxm 发表了文章 • 0 个评论 • 167 次浏览 • 2019-10-15 14:58 • 来自相关话题

趣头条是增长最快的个性化资讯阅读APP,通过差异化定位、独特的获客机制、快速发展的自媒体内容平台、以及基于深度学习的推荐算法。趣头条短短2年多的时间用户自然增长达到近4000万日活,月活突破1.1亿;优质内容提供者10000家;B轮融资2亿美金,腾讯领投,小米、顺为资本等 顶级投资机构跟投,2018914日在美国纳斯达克上市.













工作职责:

1. 
平台型产品的技术架构设计与开发

2. 
参与复杂业务系统设计与开发

3. 
攻克高并发、系统解耦等方面的技术难关

任职资格:

1. 
熟练掌握至少一种后端开发语言,能够或愿意使用Golang进行开发

2. 
有良好的数据结构、算法基础,熟悉Linux操作系统、网络协议、多线程编程

3. 
具备很强的编码能力、抽象能力,有良好的编程风格

4. 
有大流量、复杂业务分布式系统的设计和开发经验优先

5. 
有大型画像、实验、日志收集等数据系统的设计和开发经验优先

6. 
有良好的学习能力,沟通能力,上进心和团队协作能力

地点:上海浦东新区申江路5005弄星创科技广场

邮箱:fanxiangmin@qutoutiao.net

微信:Frank-happyhappy