聊聊图数据库和图数据库的小知识 Vol.02

  • 时间:
  • 浏览:2
  • 来源:万人炸金花_万人炸金花官网

【回复】交流群群友 S:相似于于 Janusgraph 的索引,若果大伙 的设计更 general,支持 multi-column 的索引

【回复】交流群群友 S:人太好,shared-storage 能可不都后能 了被看成是从前存储空间极大的单机版,并就有从前分布式系统

【回复】交流群群友 B:在做实时图数据库的数据模型设计时,尽量正确处理大出入度的节点。若果正确处理不了,那为宜正确处理此类节点再往后的 traversal。若果还是正确处理不了,那别指望从前的查询会有好的性能

【回复】交流群群友 W:会从前 block 一起去读出来

上文摘录了#聊聊图数据库和图数据库小知识# Vol.01 的【图数据库兴起的契机】,在本次第二期#聊聊图数据库和图数据库小知识#大伙 将了解以下内容,若果有感兴趣的图数据库话题,欢迎打上去 Nebula 小助手微信号:NebulaGraphbot 为好友进群来交流图数据库心得。

【回复】交流群群友 W:这俩人太好。所以开源的创业公司走 shared-nothing,云厂商走 shared-storage,也有无都利用了每个人的优势

就有。Meta Service的架构人太好和 Storage Service 架构相似于,是个独立服务。

在这俩主次大伙 会摘录一点开源的分布式图数据库 Nebula Graph 在实践过程中遇到的问题,若果用户使用图数据库 Nebula Graph 中遇到的问题。

存储与计算分离主要出于以下四方面的考虑:

在这俩主次,大伙 会摘录一点图数据库设计通用的设计思路,若果已有图数据库的实践思考。

图数据库和图数据库设计

【提问】:Nebula 的存储模型中属性和边信息一起去存储在顶点上,针对大顶点问题有好的正确处理方案吗?属性和关系多状态下,针对这俩实体的查询该为什么在正确处理,比如:比如美国最有名的特产,中国最高的人,浙江大学年龄最大的校友

partition 是个逻辑概念,主要目的是为了从前 partition 内的数据能可不都后能 了一起去迁移到另外一台机器。partition 数量是由创建图空间时指定的 partition_num 确立。而单副本 partition 的分布规则如下

【回复】交流群群友 W:ranking 字段人太好给客户用的,一般能可不都后能 了拿来放时间戳,版本号相似于的。

A:部署集群时时要设置 Partition 数,比如 30000 个 Partition。插入某个点时,会针对这俩点的id做 Hash,找寻对应的 Partition 和对应 Leader。PartitionID 计算公式 = VertexID % num_Partition

【回复】交流群群友 W:errr,单个 storage 能可不都后能 了放下可不都后能 了多数据,不为什么在么在数据量增加了会是个比较麻烦的问题。另外第二步人太好是随机的,若果取第二步数据的完后 能可不都后能 了从多台机器并发

此外,“第二步人太好是随机的,若果取第二步数据的完后 能可不都后能 了从多台机器并发吧”这俩倒是,Nebula 有个 storage server 能可不都后能 了做这俩事情,但逻辑上似乎这俩应该是 query engine 应该干的。

2010 年前后,对于社交媒体网络研究的兴起带动了图计算的大规模应用。

30000 年前后热门的是 信息检索分析 ,主要是 Google 的带动,以及 Amazon 的 e-commerce 所用的协同过滤推荐,当时 collaborative filtering也被认为是 information retrieval 的从前细分领域,包括 Google 的 PageRank 也是在信息检索领域研究较多。随后才是 Twitter,Facebook 的崛起带动了网络科学 network science的研究。

图理论和图算法就有新科学,很早就有,要是最近 20 年大数据,网络零售和社交网络的发展, big datasocial networkse-commerce 、IoT让图计算有了新的用武之地,若果硬件计算力的提高和分布式计算日益心智心智开花结果是什么是什么 期是什么的一段话的支持也使图在高效正确处理海量关联数据成为若果。

【回复】交流群群友 B:图数据库的从前查询的性能最终取决于 physical block reads 的数量。不同方案会意味分析最后 block reads 不一样,性能会有差别。任何这俩 方案不若果对所有查询就有优化的,最终往往要是 tradeoff。主要看你大主次实际的 query pattern 和数据分布式如可,该数据库实现是有无优化。拆边和不拆边,各有其优缺点。

【回复】交流群群友 W:Neo4j 的 relationship group 是落在存储上的,请教下,Nebula 的这俩 index 和 Janusgraph 的 vertex centric 索引相似于麽,还是指存储格式里面的 ranking 字段啊

图数据库相对传统数据库优化点在于,数据模型。传统数据库是从前关系型,是这俩 表形态学 做 Join,但存储形态学 表明了没能支持多度拓展,比如一度好友,两度好友,一度还支持,使用从前 Select 和 Join 就可完成,若果二度查询开销成本较大,更别提多度 Join 查询开销更大。图数据库的存储形态学 为面向图存储,更能助 查询多度关系。不为什么在么在的,一点图上特有的操作,用关系型数据库比较难实现和表达,比如最短路径、子图、匹配特定规则的路径这俩。

【回复】交流群群友 W:恩恩。对于 supernode 这俩状态,有可不都后能 了做这俩优化?Titian/Janusgraph 有从前节点所有边的局部索引,Neo4j 应该有在 object cache 中对从前节点的边按照类型组织

单个 Partition 的大小,取决于总数据量和 Partition 个数;Partition 的个数的挑选取决于集群中最大若果的机器节点数,Partition 数目越大,每个 Partition 数据量越小,机器间数据量不均匀指在的概率也就越小。

【回复】交流群群友 W:嗯嗯。不过 Neptune 那种跟单机版的区别在于计算那主次是可扩展的,一写多读,甚至 Aurora 若果做到了多写。不过就像前面所说的,开源的东西基于那种需定制的高大上存储来做不现实。想了下拿 AWS 的存储做对比不大为宜,存储內部跨网络访问的开销还是从前问题,拿 Polarstore 这俩 RDMA 互联更能说明。若果 2 种方案都差可不都后能 了来越多,本质上就有能可不都后能 了减少跨网络访问的开销。

Nebula Graph 实践细节

通过算子:partID%engine_size,而多副本的状态,原理相似于,follower 在另外从前机器上。

【回复】交流群群友 S:Nebula 也是用 index 来正确处理这俩问题

【回复】交流群群友 W:若果能可不都后能 了排序,那分数能可不都后能 了贴到 key 上,从前人太好要是用 scan 可不都后能 了来越多了,ranking 字段就能可不都后能 了放这俩。要不然还有个法子是允许遍历的过程中截断若果采样,不然很容易爆炸的。

A:KV 那层。目前可不都后能 了针对顶点的 Cache,顶点的访问具有随机性,若果可不都后能 了 Cache,性能较差。Query Plan 那层现在还可不都后能 了。

【回复】交流群群友 H:单纯的大点若果不从它现在现在开始 traversal,人太好问题要是大。load 的 unbalance 就有有法子正确处理的。数据的 unbalance 若果分 part 存储,在分配 part 到 host 时可加入 part 数据量的权重,而 load 的 unbalance,对于读,可通过拓展只读副本 + cache 正确处理,写一段话,可做 group commit,client 不可不都后能 可不都后能 了做本地 cache。

单机按分布式架构部署,有一定网络开销若果经过网卡,所以性能还行。一定要分布式架构部署的意味分析在于强一致、多副本的业务需求,你不可不都后能 可不都后能 了按照业务需求部署单副本。

【回复】交流群群友 W:“网络这块的优化,可参考阿里云的 polarstore,基本上网络若果就有这俩问题了。” 网络这问题,部署环境的网络不一定可控,毕竟机房质量参差不齐,当然云厂商当事人的机房会好所以。

【回复】交流群群友 W:主要的云厂商,比如 AWS 的共享存储能可不都后能 了到 64 T,存储应该够,若果这俩法子存储內部有多副本。顺便提一句:AWS 的 Neptune 的底层存储用的也是 Aurora 的那个存储。网络这块的优化,可参考阿里云的 Polarstore,基本上网络若果就有这俩问题了。

【提问】请教从前问题。Nebula 的顶点和出边是连续存放的。可不都后能 了在查询一段话进行 IO 读取时,是顶点和出边会一起去读出来呢,还是根据查询一段话的不同而不同?

【提问】对于图数据库来说,是就有 shared-storage 相比 shared-nothing 法子更好呢。若果图的节点间是厚度关联的,shared-nothing 法子将这俩联系拆掉了。对于多步遍历等操作来说,时要跨节点。若果若果第二步现在现在开始 的不挑选性,要不需要说跨节点好像可不都后能 了提前通过执行计划进行优化。