nebula

​ 缘起 Nebula Graph 最早的自动化测试是使用搭建在 Azure 上的 Jenkins ，配合着 GitHub 的 Webhook 实现的，在用户提交 Pull Request 时，加个 ready-for-testing 的 label 再评论一句 Jenkins go 就可以自动的运行相应的 UT 测试，效果如下： 因为是租用的 Azure 的云主机，加上 nebula 的编译要求的机器配置较高，而且任务的触发主要集中在白天。所以上述的方案性价比较低，从去年团队就在考虑寻找替代的方案，准备下线 Azure 上的测试机，并且还要能提供多环境的测试方案。 调研了一圈现有的产品主要有： TravisCI CircleCI Azure Pipeline Jenkins on k8s（自建） 虽然上面的产品对开源项目有些限制，但整体都还算比较友好。 鉴于之前 GitLab CI 的使用经验，体会到如果能跟 GitHub 深度集成那当然是首选。所谓“深度”表示可以共享 GitHub 的整个开源的生态以及完美的 API 调用（后话）。恰巧 2019，GitHub Action 2.0 横空出世，Nebula Graph 便勇敢的入了坑。 这里简单概述一下我们在使用 GitHub Action 时体会到的优点： 免费。开源项目可以免费使用 Action 的所有功能，而且机器

首发于 Nebula Graph 官方博客： https://nebula-graph.com.cn/posts/task-management-design-in-nebula-graph/ 讲解 Task Manager 之前，在这里先介绍一些 Task Manager 会使用到的概念术语。 图数据库 Nebula Graph 中，存在一些长期在后台运行的任务，我们称之为 Job。存储层存在的 DBA 使用的部分指令，比如：数据完成导入后，想在全局做一次 compaction，都是 Job 范畴。 作为一个分布式的系统，Nebula Graph 中 Job 由不同的 storaged 完成，而我们管一个 storaged 上运行的 Job 子任务叫做 Task。Job 的控制由 metad 上的 Job Manager 负责，而 Task 的控制由 storaged 上的 Task Manager 负责。 在本文中，我们着重讲述如何对长耗时的 Task 进行管理与调度进一步提升数据库性能。 Task Manager 要解决的问题 上文说到 storaged 上的 Task Manager 控制的 Task 是 meta 控制的 Job 的子任务，那 Task Manager 它自己具体解决什么问题呢？在 Nebula Graph 中 Task Manager 主要解决了以下 2

摘要：用技术来解决 PM 枯燥的 approval pr 工作，本文将阐述如何自动化获取 GitHub Organization 下各个 repo 待 merge 的 pull requests 并通知相关人员，告别每日的手动操作。 首发于 Nebula Graph 官方博客： https://nebula-graph.com.cn/posts/dingding-slack-bot-github-api/ 在日常工作中，你是否遇到以下场景： Github 存在多个 repo，日常工作中需要一个个地手动筛选大量待 merge 的 pull requests 要找出多个 repo 中 ready to review 的 pull requests，要手动筛选，然后一遍又一遍地粘贴复制提交 dev 进行 review #倍感无聊 想自动推送 GitHub 待 merge 的 prs，GitHub Webhooks 却没有该 Event …… 用技术来解决 PM 枯燥的 approval pr 工作，本文将阐述如何自动化获取 GitHub Organization 下各个 repo 待 merge 的 pull requests 并通知相关人员，告别每日的手动操作。此文主要提供了解决自动发送 approval prs 的思路，并以钉钉群和 Slack 为例，给出了其 Python

缘起 Nebula Graph 最早的自动化测试是使用搭建在 Azure 上的 Jenkins ，配合着 GitHub 的 Webhook 实现的，在用户提交 Pull Request 时，加个 ready-for-testing 的 label 再评论一句 Jenkins go 就可以自动的运行相应的 UT 测试，效果如下： 因为是租用的 Azure 的云主机，加上 nebula 的编译要求的机器配置较高，而且任务的触发主要集中在白天。所以上述的方案性价比较低，从去年团队就在考虑寻找替代的方案，准备下线 Azure 上的测试机，并且还要能提供多环境的测试方案。 调研了一圈现有的产品主要有： TravisCI CircleCI Azure Pipeline Jenkins on k8s（自建） 虽然上面的产品对开源项目有些限制，但整体都还算比较友好。 鉴于之前 GitLab CI 的使用经验，体会到如果能跟 GitHub 深度集成那当然是首选。所谓“深度”表示可以共享 GitHub 的整个开源的生态以及完美的 API 调用（后话）。恰巧 2019，GitHub Action 2.0 横空出世，Nebula Graph 便勇敢的入了坑。 这里简单概述一下我们在使用 GitHub Action 时体会到的优点： 免费。开源项目可以免费使用 Action 的所有功能，而且机器 配置较高

D3.js 作为一个前端，说到可视化除了听过 D3.js 的大名，常见的可视化库还有 ECharts 、 Chart.js ，这两个库功能也很强大，但是有一个共同特点是 封装层次高 ，留给开发者可设计和控制的部分太少。和 EChart、Chart.js 等相比，D3.js** 的相对来说自由度会高很多，得益于 D3.js **中的 SVG 画图对事件处理器的支持 ，D3.js 可将任意数据绑定到文档对象模型（DOM）上，也可以直接操作对象模型（DOM）完成 W3C DOM API 相关操作，对于想要展示自己设计图形的开发者，D3.js 绝对是一个不错的选择。 d3-force 力导向图 以实现一个关系网来说，d3-force 力导向图是不二的选择。 d3-force 是 D3.js 实现以模拟粒子物理运动的 velocity Verlet 数值积分器的模块，可用来控制粒子和边秩序。在 力导向图 中，d3-force 中的每个节点都可以看成是一个放电粒子，粒子间存在某种斥力（库仑斥力）。同时，这些粒子间被它们之间的“边”所牵连，从而产生牵引力。 而 d3-force 中的粒子在斥力和牵引力的作用下，从随机无序的初态不断发生位移，逐渐趋于平衡有序。整个图只有点 / 边，图形实现 样例 较少且自定义样式居多。 下图就是最简单的关系网图，想要实现自己想要的关系网图，还是动手自己实现一个

Nebula Graph 是一个高性能、高可用、强一致的分布式图数据库。由于 Nebula Graph 采用的是存储计算分离架构，在存储层实际只是暴露了简单的 kv 接口，采用 RocksDB 作为状态机，通过 Raft 一致性协议来保证多副本数据一致的问题。Raft 协议虽然比 Paxos 更加容易理解，但在工程实现上还是有很多需要注意和优化的地方。 另外，如何测试基于 Raft 的分布式系统也是困扰业界的问题，目前 Nebula 主要采用了 Jepsen 作为一致性验证工具。之前我的小伙伴已经在《 Jepsen 测试框架在图数据库 Nebula Graph 中的实践 》中做了详细的介绍，对 Jepsen 不太了解的同学可以先移步这篇文章。 在这篇文章中将着重介绍如何通过 Jepsen 来对 Nebula Graph 的分布式 kv 进行一致性验证。 强一致的定义 首先，我们需要什么了解叫强一致，它实际就是 Linearizability，也被称为线性一致性。引用《Designing Data-Intensive Applications》里一书里的定义： In a linearizable system, as soon as one client successfully completes a write, all clients reading from the

Nebula Graph 是一个高性能、高可用、强一致的分布式图数据库。由于 Nebula Graph 采用的是存储计算分离架构，在存储层实际只是暴露了简单的 kv 接口，采用 RocksDB 作为状态机，通过 Raft 一致性协议来保证多副本数据一致的问题。Raft 协议虽然比 Paxos 更加容易理解，但在工程实现上还是有很多需要注意和优化的地方。 另外，如何测试基于 Raft 的分布式系统也是困扰业界的问题，目前 Nebula 主要采用了 Jepsen 作为一致性验证工具。之前我的小伙伴已经在《 Jepsen 测试框架在图数据库 Nebula Graph 中的实践 》中做了详细的介绍，对 Jepsen 不太了解的同学可以先移步这篇文章。 在这篇文章中将着重介绍如何通过 Jepsen 来对 Nebula Graph 的分布式 kv 进行一致性验证。 强一致的定义 首先，我们需要什么了解叫强一致，它实际就是 Linearizability，也被称为线性一致性。引用《Designing Data-Intensive Applications》里一书里的定义： In a linearizable system, as soon as one client successfully completes a write, all clients reading from the

【推荐阅读】微服务还能火多久？>>> Nebula Graph 是一个高性能、高可用、强一致的分布式图数据库。由于 Nebula Graph 采用的是存储计算分离架构，在存储层实际只是暴露了简单的 kv 接口，采用 RocksDB 作为状态机，通过 Raft 一致性协议来保证多副本数据一致的问题。Raft 协议虽然比 Paxos 更加容易理解，但在工程实现上还是有很多需要注意和优化的地方。 另外，如何测试基于 Raft 的分布式系统也是困扰业界的问题，目前 Nebula 主要采用了 Jepsen 作为一致性验证工具。之前我的小伙伴已经在《 Jepsen 测试框架在图数据库 Nebula Graph 中的实践 》中做了详细的介绍，对 Jepsen 不太了解的同学可以先移步这篇文章。 在这篇文章中将着重介绍如何通过 Jepsen 来对 Nebula Graph 的分布式 kv 进行一致性验证。 强一致的定义 首先，我们需要什么了解叫强一致，它实际就是 Linearizability，也被称为线性一致性。引用《Designing Data-Intensive Applications》里一书里的定义： In a linearizable system, as soon as one client successfully completes a write, all clients

【推荐阅读】微服务还能火多久？>>> Nebula Graph 是一个高性能、高可用、强一致的分布式图数据库。由于 Nebula Graph 采用的是存储计算分离架构，在存储层实际只是暴露了简单的 kv 接口，采用 RocksDB 作为状态机，通过 Raft 一致性协议来保证多副本数据一致的问题。Raft 协议虽然比 Paxos 更加容易理解，但在工程实现上还是有很多需要注意和优化的地方。 另外，如何测试基于 Raft 的分布式系统也是困扰业界的问题，目前 Nebula 主要采用了 Jepsen 作为一致性验证工具。之前我的小伙伴已经在《 Jepsen 测试框架在图数据库 Nebula Graph 中的实践 》中做了详细的介绍，对 Jepsen 不太了解的同学可以先移步这篇文章。 在这篇文章中将着重介绍如何通过 Jepsen 来对 Nebula Graph 的分布式 kv 进行一致性验证。 强一致的定义 首先，我们需要什么了解叫强一致，它实际就是 Linearizability，也被称为线性一致性。引用《Designing Data-Intensive Applications》里一书里的定义： In a linearizable system, as soon as one client successfully completes a write, all clients

导读 索引是数据库系统中不可或缺的一个功能，数据库索引好比是书的目录，能加快数据库的查询速度，其实质是数据库管理系统中一个排序的数据结构。不同的数据库系统有不同的排序结构，目前常见的索引实现类型如 B-Tree index、B+-Tree index、B*-Tree index、Hash index、Bitmap index、Inverted index 等等，各种索引类型都有各自的排序算法。 虽然索引可以带来更高的查询性能，但是也存在一些缺点，例如： 创建索引和维护索引要耗费额外的时间,往往是随着数据量的增加而维护成本增大 索引需要占用物理空间 在对数据进行增删改的操作时需要耗费更多的时间,因为索引也要进行同步的维护 Nebula Graph 作为一个高性能的分布式图数据库，对于属性值的高性能查询，同样也实现了索引功能。本文将对 Nebula Graph的索引功能做一个详细介绍。 图数据库 Nebula Graph 术语 开始之前，这里罗列一些可能会使用到的图数据库和 Nebula Graph 专有术语： Tag：点的属性结构，一个 Vertex 可以附加多种 tag，以 TagID 标识。（如果类比 SQL，可以理解为一张点表） Edge：类似于 Tag，EdgeType 是边上的属性结构，以 EdgeType 标识。（如果类比 SQL，可以理解为一张边表） Property