我知道数据库一般可以使用master/slave replication水平扩展。当并发读取数量增加时,这是一个很好的策略。
但是,随着并发写入的数量或仅数据量开始增长,主/从复制不会为您带来任何好处,因此您需要对数据进行分区。
这对于键值场景非常有用。对我来说一个经典的例子是 TinyURL/bit.ly;读取/写入短URL foo 的数据可以完全独立于读取/写入短URL bar 的数据。
但是,如果您处于图形场景中,您应该怎么做?更具体地说,是否有可能像Neo4j这样的图形数据库进行分区?如果是这样,如何?
我无法理解如何在不违背使用图形数据库(高效遍历)的目的的情况下分解图形。
我使用图形数据库 Neo4J 建模了一个有向树结构。所以我有这样的东西:http : //ouwarovite.net/YAPC/220px-Binary_tree.svg.png(非强制性二进制)
我的数据库的用户可以随意添加现有节点的子节点,所以树的高度和单个节点的度数是未知的。
现在,我想这样查询我的树:从节点 x 开始,给我所有叶子 x 的后代。
这种查询是否可以使用 Gremlin 或 Cypher 执行,如果可以,如何做到这一点以获得最大的性能?(我还没有找到对“通用”树执行查询的可能性,因为您总是必须指定最大深度)
我知道,使用 REST/JSON 框架和 JAVA API 是可能的:
POST /db/data/node/51/traverse/node
{
"return_filter" :
{
"body" : "position.endNode().hasProperty('leave')" ,
"language" : "javascript"
},
"relationships" : [ { "type" : "_default", "direction" : "out" } ] ,
"prune_evaluator" : { "name" : "none" , "language" : "builtin" }
}
Run Code Online (Sandbox Code Playgroud)
(我的叶子有属性“离开”,我的边缘没有类型 -> 所以 _default)
有没有更简单/更好的方法来做到这一点,也许具有更好的性能?
使用OrientDB的查询语言,如何找到集群a中没有出口边缘在类的顶点结束的所有顶点b(即没有类的直接邻居顶点b)?它们是否有其他外围边缘并不重要.
我想为我的Web应用程序构建一个本体,我想用Neo4j来表示本体(因为我还是使用了Neo4j).
现在,我似乎必须从头开始编写它,包括整个本体实现,验证,推理,GUI编辑器.绝对是太多的工作.
是否有一个框架或库可以让我在neo4j上管理我的本体而无需从头开始实现它?如果没有,最合理的选择是什么?(我在Node.js上使用Neo4j)
我需要维护一个大的有向图G,可能有数百万个节点和边.可能它可能不适合记忆.
我需要在此图表上执行的一些常见操作包括:
每个节点/边将具有与之关联的用户定义属性,例如访问计数,权重等.
对于每个节点(顶点),我将需要根据属性值执行有效的查询.例如,找到X值大于v1但小于v2的节点.这可能需要在某些字段上构建索引.
我需要找到给定节点的所有传入边和传出边,并更新边的权重.
我将需要从给定节点进行本地(基于DFS)遍历,并返回满足某个用户定义谓词的所有路径(此谓词可以使用路径中节点/边的属性值).
我需要有效地添加/删除节点/边缘.但是,这并不像操作1,2,3那样频繁地执行.
图中可能存在一些比其他部分更频繁访问的热点,我想将这些热点缓存在内存中.
以最少的实施努力实现这一目标的有效方法是什么?
我正在看一些基于磁盘的图形数据库,例如Neo4j/InfiniteGraph/DEX.尽管它们支持上述所有操作,但由于我不需要它们提供的许多功能,例如一致性/并发控制或基于群集的复制,因此它似乎是一种矫枉过正.此外,它们中的很多都基于Java,我更喜欢使用C/C++接口.
基本上我只需要一个磁盘上的图形库,它可以有效地处理持久性,节点查询和本地遍历.您对我可以使用的现有(开源)项目有什么建议吗?如果没有,实施这样的事情的最佳方式是什么?
graph social-networking neo4j graph-databases data-structures
我想知道Neo4j和OrientDB是否提供了根据特定边缘类型的多重性定义约束的可能性?
我仍在尝试理解为什么为什么针对neo4j中的某种查询而不是针对另一种格式收到笛卡尔乘积警告。这是我设置数据库的方式:
CREATE (q:Form {version: "1.0"})
CREATE (q:Question {text: "Sector de la empresa", active: true})
Run Code Online (Sandbox Code Playgroud)
然后,我尝试了以下查询:
MATCH
(f:Form {version: "1.0"}),
(q:Question {text: "Sector de la empresa"})
CREATE (f)-[:asks]->(q)
RETURN f, q
Run Code Online (Sandbox Code Playgroud)
但是,我收到以下警告:
This query builds a cartesian product between disconnected patterns.
If a part of a query contains multiple disconnected patterns,
this will build a cartesian product between all those parts.
This may produce a large amount of data and slow down query processing.
While occasionally intended, it may often be …Run Code Online (Sandbox Code Playgroud) 在我的ArangoDB图中,我有一个主题,与该主题相关联的消息线程,以及这些消息线程内的消息.我想以这样一种方式遍历图形,即返回与消息线程关联的数据以及消息线程内的消息计数.
数据的结构非常简单:我有主题节点,边缘扩展到线程节点,日期和类别相关联,以及从线程节点到消息节点的边缘.
我想返回存储在线程节点中的数据和附加到线程的消息计数.
我不确定如何使用for v, e, p in 1..2 outbound语法执行此操作.我应该for v, e, p in outbound在里面使用嵌套图吗?这仍然是高性能的吗?
在我学习如何使用Cosmos DB的图形时,我发现了两个Microsoft教程:
虽然我使用相同的查询,但它的执行不同.
使用Gremlin.Net,它立即执行.我经常(我会说70%的时间)得到一个RequestRateTooLargeException.如果我理解正确,这意味着我一直达到我选择的400RU/s限制.但是,当查询进入低谷时,它的速度是Microsoft.Azure.Graph解决方案的两倍.
实际上,使用Micorosft.Azure.Graph,我必须调用ExecuteNextAsync一个循环,一次返回一个结果.
所以问题是:
1°)我应该使用哪种方法来获得更好的性能?
2°)我怎么知道我的查询的RU所以我可以微调它?
3°)是否可以提高现有集合的吞吐量?
更新
问题3,我发现在我的数据库的"数据资源管理器"刀片中,我的图表有一个"Scale&Settings",我可以更新吞吐量.
Update2
问题2,我们无法在使用第一种方法(Gremlin.Net)时收取RU,但Microsoft.Graph方法ExecuteNextAsync返回FeedResponse带有字段的a RequestCharge.
从实际角度来看,我一直在努力理解这些技术何时有用,以及它们之间有何不同。专家可以检查一下我的理解吗?
图形数据库:当关系复杂、继承、以不同程度的置信度推断并且可能发生变化时,图形数据库比关系数据库更容易理解和管理。一些示例:用户不知道他们需要层次结构的深度;从社交媒体推断关系,对 ID 解析、主题解析和关系强度有不同程度的置信度;或者不知道他们要存储什么类型的呼叫中心数据;所有这些都可以存储在关系数据库中,但它们需要不断更新。它们对于某些任务也更具表现力。
本体:这些正式且标准化的知识表示用于打破数据孤岛。例如,假设一家 B2B 销售公司从多个不同的业务领域获得收入,其中包括一次性付款、订阅、IP 销售和咨询服务。收入数据存储在许多不同的数据库中,这些数据库具有很多特性。本体允许用户将“客户付款”定义为“创造或退还收入”的任何内容,以便主题专家可以在其数据库中适当地标记付款。本体可以与图数据库或关系数据库一起使用,但是对类继承的强调使得它们在图数据库中更容易实现,在图数据库中可以轻松地对类的分类进行建模。
知识图:知识图是一种图数据库,其中语言(含义、实体和节点分类法)由本体管理。因此,在我们的 B2B 示例中,“客户付款”边缘具有一次性付款、订阅等子类型,并将“客户”类连接到“业务线”类。
这基本上是正确的吗?
graph-databases ×10
neo4j ×5
graph ×2
ontology ×2
orientdb ×2
traversal ×2
aql ×1
arangodb ×1
gremlin ×1
multiplicity ×1
nosql ×1
scalability ×1