开启找 bug 之旅~
获得徽章 0
- PM 小姐姐要在苦恼如何在中英之间添加空格的问题，一搜发现有一个 VSCode 扩展可用赞过
评论2 - #图数据库##图数据库小知识# 今日份的图数据库小知识点--「图数据库模型：原生图数据库 vs 多模数据库」，欢迎对图数据库感兴趣的你在 GitHub 上 star Nebula & 向我们提 issue
t.cn 
图数据库模型：原生图数据库 vs 多模数据库
大家如果网上搜图数据库，可能有 20 个自称图数据库的产品。NebulaGraph 认为这些产品可以分成两类，一种就是原生的，还有一类是多模的。
对于图原生的产品，在设计时考虑了图数据的特性，存储、计算引擎都是基于图的特点做的特别设计和优化。
而对于多模的产品，数量就有很多，比如， ArangoDB 或者 OrientDB，及云厂商的服务，它们的底层是一个表或文档型数据库，在上层增加图的服务。对于这类多模数据库，图服务层所做的操作，举个例子：遍历、写入，最终将被映射到下面的存储层，成为一系列表和文档的操作。因此它最大的问题是整个系统并不是为了图这种多对多的结构特点设计，一旦数据量或者并发量增大后，问题就比较明显。我们最近碰到一个比较典型的 Case，客户使用多模 DB：在数据量小时，使用还比较方便，但当数据量大到一定程度，做二跳三跳查询 touch 的数据非常多，而多模 DB 底层是关系型数据库，所有关系最终要映射到关系型数据库的 Join 操作，做三四层的 Join ，性能非常差。展开赞过 评论2 - #图数据库##图数据库小知识# 今日份的图数据库小知识点--「图数据库存储计算什么数据」，欢迎对图数据库感兴趣的你在 GitHub 上 star Nebula & 向我们提 issuestrace.co[爱你]图数据库存储计算什么数据
今天我们谈数据库肯定离不开数据，因为数据库只是一个载体，一个存储和计算的载体，那么 NebulaGraph 它里面的数据到底是什么呢？就是我们平时说的图，这里列出了几个目前为止比较常见的多对多的关系数据。
图数据的常见多对多关系数据库场景
第一个 Social Network（社交网路），比如：微信或者 Facebook 好友关系，这个网络有几十亿个用户，几千亿到几万亿的连接关系。
第二个 Business Relation，商业关系，常见的有两种网络：
- 金融与资金关系网络：在支付网络里，账户和账户之间存在支付关系或者转账关系，这就是比较典型的金融与资金关系网络；
- 公司关系：在 Business 里，举个例子：公司控股关系，法人关系，它是一个非常庞大的网络。这个网络的节点规模也有亿到十亿的级别，大概几百亿条边，如果算上交易转账数据那就非常庞大了。顺便提一句，基于工商总局数据，有许多公司耕耘在这一领域。
第三个是知识图谱，也是最近比较热的一个领域。在各个垂直领域会有不同的知识点，而知识点之间有相关性。部分垂直领域知识的网络能有几百亿条关系，比如：银行、公安还有医学领域。
最后就是这几年热门的 IoT（Internet of Things）领域，随着近年智能设备的增长，预计以后 IoT 设备数量会远超过人口数量，像现在我们每个人身边佩带的智能设备已不止一个：智能手机、智能手表，它们之间组成一个庞大的关系网络，虽然具体应用有待后续开发，但这个领域在未来会有很大的应用空间。展开赞过 评论2 - #图数据库# 今日的图数据库小知识点是--「图领域的 OLAP & OLTP 场景」，本条内容来源于第三期 nMeetup 整理稿，欢迎对图数据库感兴趣的你在 GitHub 上 star Nebula & 向我们提 issuestrace.co图领域的 OLAP & OLTP 场景
图计算或者图数据库本身跟传统数据库很类似，也分为 OLAP 和 OLTP 两个方向。
上图中下面这根轴表示数据对查询时效性的要求，OLAP 更偏向于做离线分析，OLTP 更偏向于线上处理。我们认为图领域也可以这么划分。
首先在 OLAP 这个领域，我们称为图计算框架，这些图计算框架的主要目的，是做分析。基于图的结构的分析——这里图代指一个关系网络。整体上这个分析比较类似于传统数据库的 OLAP，但一个主要特点就是基于图结构的迭代算法，这个在传统数据库上是没有的。最典型的算法是谷歌 PageRank，通过一些不断的迭代计算来算网页的相关度，还有非常常见的 LPA 算法，使用的也非常多。
如果我们继续沿着这个线向右边延伸,可以看到一个叫做 Graph Stream 的领域，这个领域相当于图的基础计算跟流式计算相结合的产物。大家知道关系网络并不是单单一个静态结构，而是会在业务中不断地发生变化：可能是图的结构，或者图上的属性发生变化，当图结构和属性发生变化时，我们希望去做一些计算，这里的计算可能是一种触发的计算或判断——例如在变化过程当中是不是动态地在图上形成一个闭环，或者动态地判断图上是否形成一个隔离子图等等。Trigger（触发）的话，一般是通过事件来驱动这类计算。对时效性的响应当然是越高越好，且往往响应时间一般是在秒级左右。
那么再往轴上右边这个方向看，是线上的在线响应系统。大家知道这类系统的特点是对延时要求非常高。可以看到最右边的场景和要求跟左边的是完全不一样的，是一种典型的 OLTP 场景。在这种场景里面，通常是对子图的计算或者遍历——这个和左边对全图做计算是完全不一样的：比如说从几个点出发，得到周边 3、4 度的邻居构成一个子图，再基于这个子图进行计算，根据计算的结果再继续做一些图遍历，我们把这种场景称为图数据库。Nebula 现在主要研发内容主要面向 OLTP 这类场景。展开赞过 评论1 - #图数据库#今日的图数据库小知识点是--「图结构的可视化与 GIS 数据的可视化」，欢迎对图数据库感兴趣的你在 GitHub 上 star Nebula & 向我们提 issuegithub.com [爱你]图结构的可视化与 GIS 数据的可视化
图数据与 GIS 数据的可视化本质上有比较大的差异：
GIS是 Hierarchical + 瓦片式贴片展示的，而图数据本身是 flat 的，只能一次性将所有 touch 到的数据全部展示出来。
但是 GIS 的做法可以给我们启示，结合具体的业务场景，能否也做一个层级抽样，但是图抽样的问题是：如何在抽样的同时，尽量保持子图的连通性（否则可能 High level 的层次显示的都是孤立的点，只有最后最细粒度的一层才会显示所有数据）
一些粗浅的想法：可以结合图计算的技术，先算连通子图，然后在连通子图内部算 PageRank，按照 PageRank 大小划分成不同的区间，相当于按照 PageRank 值做 Hierarchical 分层，在层次切换时，为了保证图的连通性，除了显示下一个层次的顶点（PageRank 值在下一个区间）之外，还需要
显示这 2 个层次抽样出来的顶点的边（这相当于一个子图内的连通路径的检索，如果能做 aggregate 更好，如果这些边很多，是否可以按照 EdgeType aggregate，先显示统计值，如果用户有兴趣再展开——即图数据库返回 Aggregation 值，前端生成“虚拟”边，随着进一步展开，这些“虚拟边”会
被实际明细边取代）
上述 trick 只是为了解决图数据像 GIS 一样平滑展示的问题，缺点也比较明显，Hierarchical 抽样代价高。
另外，图数据的展示问题，不是一个独立的前端技术问题，还涉及到后端图数据库如下 feature 的支持：
1. Degree 统计；
2. 按照 EdgeType 进行 aggregate；
3. query 时遇到超级顶点做截断，并返回截断信息给 Client 内置一些 AP 性算法，如 PageRank、LPA、环探测等；展开赞过 评论3 - #图数据库##图数据库小知识# 今日的图数据库 Q&A 小知识点是--「怎么理解图数据库 Nebula 的顶点 vertex 和标签 tag」，本条内容来源于 Nebula Graph 交流群 BTW，欢迎对图数据库感兴趣的你在 GitHub 上 star Nebula & 向我们提 issue github.com
🙋：怎么理解 vertex 和 tag 之间的关系，Schema 里面有没有 vertex 的概念？一个顶点 id 可以对应多个 tag 是这个意思吗？
🎙️：解释一下 vertex，tag，edge 以及他们之间的关系
🎙️：vertex 是一个顶点，用一个 64 位的 id 来标识，一个 vertex 可以被打上多个 tag（标签），每个 tag 定义了一组属性，举个例子，我们可以有 person 和 developer 这两个 tag，person 这个 tag 里定义了姓名、电话、住址等等信息，developer 这个 tag 里可能定义了熟悉的编程语言、工作年限、GitHub 账号等等信息。一个 vertex 可以被打上 person 这个 tag，这就表示这个 vertex 代表了一个 person，同时也包含了 person 里的属性。另一个 vertex 可能被同时打上了 person 和 developer 这两个 tag，那就表示这个 vertex 不仅是一个 person，还是一个 developer。
🎙️：vertex 和 vertex 之间可以用 edge 相连，每一条 edge 都会有类型，比如是好友关系。每个 edge type 也可以定义一组属性。edge 一般用来表示一种关系，或者一个动作。比如，peraon A 给 person B 转了一笔钱，那 A 和 B 之间就会有一条 transfer 类型的边，transfer 这个边类型（edge type）可以定义一组属性，比如转账金额，转账时间等等
🎙️：任何两个 vertex 之间可以有多种类型的边，也可以有多条同种类型的边，比如转账，两个 person 之间可以有多笔转账，那么每笔转账就是一条边展开评论点赞 - #图数据库##图数据库小知识# 今日的图数据库小知识点是--「图数据库兴起的契机」，本条内容来源于 Nebula Graph 交流群
由群友@阿秾 贡献图数据库兴起的契机
2010 年前后几年，对于社交媒体网络研究的兴起带动了图计算的大规模应用。
2000 年前后热门的是信息检索和分析，主要是Google的带动，以及Amazon的e-commerce所用的协同过滤推荐，当时collaborative filtering也被认为是information retrieval的一个细分领域，包括Google的PageRank也是在信息检索领域研究较多。后来才是Twitter, Facebook的崛起带动了网络科学 network science的研究。图理论和图算法不是新科学，很早就有，只是最近20年大数据，网络零售和社交网络的发展， big data, social networks, e-commerce, Web 2.0让图计算有了新的用武之地，而且硬件计算力的提高和分布式计算日益成熟的支持也使图计算在高效处理海量数据成为可能。展开评论点赞
这 Banner 如何，哪里要改的吗？
来源见水印
t.cn