标签: graph-databases

我的目标是为道路网络编写最短路径算法.

目前我的架构是这样的:我将所有数据存储在启用PostGIS的PostgreSQL数据库中.我做了一个SELECT * FROM ways,在一个有100,000个边缘(方式)的表上花了不到3秒钟,然后我将(Java,Ruby或任何基于任何东西的)最短路径算法应用于已经驻留在内存中的图形.在具有100,000个边缘的图形上,第二个操作可能需要大约1.5秒.

所以,它需要:

• 2-3秒将数据库中的所有路径加载到内存中并创建图形(节点以方式(边缘)存储在一个表中);
• 1-1.5秒计算已经在内存中的图形上的最短路径.

这与pgRouting非常相似(根据我的知识,它使用C Boost将图形存储在内存中),除了pgRouting总计大约需要2秒来计算同一数据集上的最短路径(是的,它很快,但是对我来说这是一个黑盒子,所以我需要自己的).

但最近我发现了Graph数据库和Neo4j.在他们的网站上,他们声称"仍然能够在数百万道路和航路点的图表上以亚秒速度进行这些计算,这使得在许多情况下放弃使用K/V存储预先计算索引的正常方法并且能够将路由放入关键路径,可以适应现场条件,建立高度个性化和动态的空间服务."

所以问题是:对于我的特定问题,图表数据库会更快吗？

该问题具有以下属性:

• 数据库由一个表(方式)组成;
• 对数据库的唯一查询是获取进入内存的所有方法(构建图形);
• 我不需要可伸缩性,即图形可能不会增长.

我对neo4j和图形数据库都很新.我是一个应用程序的原型,我不知道我应该如何编写这些查询

我有这个域名:

用户餐厅评论TypeOfFood

因此,Restarurant有一个或多个TypeOfFood,用户留下关于餐馆的评论.用户有一些首选的食物,与餐馆出售的TypeOfFood相匹配.此外,用户通常与朋友关系彼此相关.

我正在尝试编写的一些查询:

• 给我所有的朋友评价的餐厅用3颗或更多星星做成我喜欢的食物(不包括那些我已经评论过的餐馆)

• 建议我认识的朋友(我想这应该是"所有的朋友都是朋友的朋友,但还不是我的朋友,订购的东西)

我想知道如何在用户帐户之间找到有趣的关系,例如最多连接或最有价值的用户,这些用户基于他们与他人的连接.

下面我有我使用的两个表.一个拥有所有用户,另一个拥有他们关注的用户的密钥.

User
{
    id,
    name
}

Follows {
    user_id -> user.id,
    following_id -> user.id
}

我在寻找什么类型的算法？

假设不重要的人很少或没有粉丝,我怎样才能找到图中心的人？我认为他们会很重要,因为他们有重要的人跟随他们.

更新

正如大卫和史蒂夫指出的那样,给定节点的接近程度,子社区形成的节点以及连接最多的用户都是可以从此模式中提取的有用数据的示例.

由于现在许多站点都使用了这种"跟随者"设计,因此我希望获得一些可能对各种各样的人有用的可靠的SQL或编程语言实现.

值得注意的是,虽然某些算法的结果令人着迷,但其他算法(例如查找相关节点)对我们网站的用户来说是值得的,因为我们可以向他们推荐.

我想知道在一个单独的图形中具有多个边缘定义是否有任何优势Vs具有多个图形,每个图形具有单个边缘定义.

谢谢你的帮助,

注意:我使用的是图形数据库(OrientDB是特定的).这使我可以自由地在javascript或groovy中编写服务器端函数,而不是将自己限制为SQL以解决此问题.*

注2:由于这是一个图形数据库,下面的箭头只是描述数据流.我不需要在查询中返回箭头.箭头代表关系.*

我有以时间流方式表示的数据; 即EventC发生在EventA之后的EventB之后,等等.这些数据来自多个来源,所以它不是完全线性的.它需要聚集在一起,这就是我遇到问题的地方.

目前数据看起来像这样:

#     |  event   |  next
--------------------------
12:0  |  EventA  |  12:1
12:1  |  EventB  |  12:2
12:2  |  EventC  |  
12:3  |  EventA  |  12:4
12:4  |  EventD  |  

其中"next"是时间流中下一个事件的out()边缘.在图表上,这看起来像:

EventA-->EventB-->EventC
EventA-->EventD

由于这些数据需要聚集在一起,我需要合并重复事件但保留它们的边缘.换句话说,我需要一个选择查询,结果将导致:

        -->EventB-->EventC
EventA--|
        -->EventD

在此示例中,由于EventB和EventD都发生在EventA之后(仅在不同时间),因此select查询将显示EventA的两个分支,而不是两个单独的时间流.

编辑#2

如果要将一组额外的数据添加到上面的数据中,使用EventB-> EventE,结果数据/图形将如下所示:

#     |  event   |  next
--------------------------
12:0  |  EventA  |  12:1
12:1  |  EventB  |  12:2
12:2  |  EventC  |  
12:3  |  EventA  |  12:4
12:4  |  EventD  |  
12:5  |  EventB  | …

我打算将我开始构建的应用程序分解为带有图形数据库的巨型组件到微服务中.但我面临的困境是试图找到一个合适的解决方案来拆分不同的服务,而不是失去图数据库提供的好处.

我最初考虑的想法是将每个不同的实体分成它自己的微服务,使用文档存储来保存每个服务上的数据.然后定义更高级别的服务来管理关系.

例如,使用关系(A) - >(B),将产生3个微服务,一个服务用于类型A的实体,另一个用于类型B的实体,第三个更高级别用于图形数据库,存储类型的节点A和B,仅包含ID和它们之间的关系.

问题1:这种方法在耦合,容错或其他任何我现在无法想到的方面有什么问题吗？

问题2:当你将第三个实体投入游戏时,例如(A) - >(B),(A) - >(C)和(C) - >(B),哪一个将是这种情况下的最佳方法？

• 我是否坚持只采用一种更高级别服务的策略来维持所有关系？
• 我是否会生成几个更高级别的服务来维护每种类型的关系？

问题3:在相同类型的实体,例如间(人)的关系的情况下- isFriendOf - >(人),铭记的关注点分离的概念,它被appropiate以分离关系的管理进入不同的服务？

任何意见,反馈和想法都非常受欢迎.

我一直在研究这个问题,为了清楚起见,我会提出一个更具体的方案,所以讨论它会更容易.图模型将是这样的:

这里的目标是实现歌曲播放列表推荐服务,试图根据用户已经听过的歌曲中的流派和艺术家以及其他人听过的其他歌曲来找到给定用户尚未收听的歌曲.用户,后跟当前用户.

有人知道可视化在Cosmos DB Graph中创建的图形的工具吗？

我正在寻找类似Gephi（https://gephi.org/）或OrientDB或Neo4j使用的工具。

我正在寻找可以“连接”到数据库的东西。Gephi似乎需要导出，然后使用导出的文件。OrientDB和Neo4j的工具将连接到服务器实例并提供查询的图形结果。

顺便说一句，我目前正在使用Azure Cosmos DB模拟器。因此，我需要可以在本地开发网站（本地主机）上运行的工具。

关于这两个工具的集成,我有几个问题.不是技术问题,也不是如何设置(我将在稍后讨论我的乐趣),但更多关于项目的进程和方向,看看JanusGraph还很年轻.

我正在开始一个新项目,并且已经决定使用Cassandra进行存储,并使用顶部声音图表对我很有吸引力.

在我走这条路之前,我想提前知道几件事.

1. JanusGraph非常年轻,它从大约一年前Titan离开的地方开始.那里存在差距,但是作为Linux基金会的一部分以及所有大型企业支持它的事实听起来很有希望.在这一点上假设JanusGraph会留在这里是否安全？依靠Janus作为启动项目是否安全？并且遵循当然的发展并尽可能地更新.

2. 卡桑德拉.Titan/JanusGraph使用thrift api与Cassandra 2.1.9集成,最终将在Cassandra 4中弃用.我知道目前正在完成工作以使janus与Cassandra 3一起工作并最终使用CQL.从现有的janus和Cassandra 2.1.9开始并稍后处理迁移是否安全？创业公司处理这项任务是否是一项艰巨的任务？

3. 生产就绪JanusGraph.(这个问题涉及到它早期阶段的任何软件以及它是否可以安全地启动使用).据我所知,JanusGraph需要一段时间才能完成生产并赶上其集成的其他工具(尽管我们说的工作正在完成:)).再次开始使用Janus并遵循开发并最终迁移到生产就绪版本是否安全？JanusGraph的整体路线图是什么？

我一般关注的是这些工具的组合是否是启动的安全选择.整个堆栈对我们来说已经是新的了,我们很高兴尝试学习,但我们将很快达到迁移期.这是你会做/推荐的事情吗？这是自杀吗？

请分享您的想法,并记住它不一定是关于我正在谈论的堆栈.它可能是任何初创公司在其早期阶段处理任何类型的软件.

干杯

想象一下社交网络应用程序.用户关注其他用户和用户拍照.照片上有其他用户的标签.

我正在尝试为该应用程序获得有效的Cosmos数据库实现.我提供了SQL Server版本以及基准测试.

这是图表:

这是它的表格版本:

这是Gremlin查询:

g.V('c39f435b-350e-4d08-a7b6-dfcadbe4e9c5')
.out('follows').as('name')
.out('took').order(local).by('postedAt', decr).as('id', 'postedAt')
.select('id', 'name', 'postedAt').by(id).by('name').by('postedAt')
.limit(10)

这是等效的SQL查询(实际上是linq):

Follows
.Where(f => f.FollowerId == "c39f435b-350e-4d08-a7b6-dfcadbe4e9c5")
.Select(f => f.Followees)
.SelectMany(f => f.Photos)
.OrderByDescending(f => f.PostedAt)
.Select(f => new { f.User.Name, f.Id, f.PostedAt})
.Take(10)

该用户跟随136个用户,他们共同拍摄了257张照片.

SQL Server和Cosmos db都位于West Europe Azure位置.我在法国.我在Linpad上做了一些测试.

• Gremlin查询运行时间超过1.20秒,消耗约330 RU.仅供参考,400RU/s的费用为20美元/月.
• SQL查询在70毫秒内运行.db是10 DTU(S0的1个实例).因此它的成本为12.65eur /月

如何使用cosmos db更快更便宜地获取Feed？

注意:为了让RU充电,我正在使用Microsoft.Azure.Graph.但我也可以使用Gremlin.Net并得到类似的结果.

使用图形数据库的大多数原因似乎是关系数据库在进行图形查询时很慢.

但是,如果我将GraphQL与数据加载器一起使用,那么我的所有查询都会使用数据加载器进行展平和组合,因此您最终会进行更简单的SELECT * FROM X类型查询,而不是进行任何繁重的连接.我甚至可能使用No-SQL数据库,这种数据通常在这些平面查询中非常快.

如果是这种情况,当与GraphQL结合使用时,是否还有Graph数据库的用例？Neo4j似乎正在推广 GraphQL.我想了解其中的优势.