寻找一个成熟的、可扩展的、带有.net或c++绑定的GraphDB

Question

我的基本要求从一个GraphDB:

• 成熟(生产就绪)
• 本地。net或c++语言绑定
• 水平可扩展性:两者都有
  • 自动数据冗余和分片
  • 分布式图算法/查询执行

目前我取消了以下内容:

• InfiniteGraph:没有c++/.NET语言绑定
• HyperGraphDB:没有c++/.NET语言绑定
• Microsoft Trinity:不成熟
• Neo4j: not distributed

我不确定以下内容的可伸缩性:

• 稀疏敏捷
• Franz Inc .)AllegroGraph
• Sones GraphDB

我发现关于水平可伸缩性的可用信息相当普遍。我想这是有充分理由的。

Answer 1

不幸的是，您的基本要求已经扩展了今天对图的一般理解-甚至在学术界也是如此。没有列出的纯图形数据库将能够满足您的所有需求。分布式图算法是一个重要的研究课题，它能够识别大型分布但又相互关联的图。因此，对于您的应用程序，最好找到一个匹配良好的图形数据库、图形处理堆栈或RDF-Store，并自己实现缺失的部分。当你的应用程序主要是在线事务性图形处理(OLTP)(读/写重)，重点放在顶点上，你可以暂时放弃分布式算法，然后使用以下其中一个:

• Neo4j
• OrientDB
• 敏捷
• HyperGraphDB
• InfiniteGraph
• InfoGrid
微软霍顿

当更多的在线分析处理(OLAP)(主要是阅读)仍然关注顶点和分布时，真正重要的是:

• Apache Hama(早期项目)
• Microsoft Trinity(研究项目)
• Golden Orb(很好，但仅限于Java)
• 信号/收集(http://www.ifi.uzh.ch/ddis/research/sc，但一个研究项目)

或者它更关注边缘，逻辑推理/模式匹配，并且你需要或更好地能够在像语义Web这样的边缘级别上使用分布，然后使用这些RDF-/Triple-/Quadstores之一:

• AllegroGraph(好吧，他们是一个graphdb/rdf存储混合;)
• Jena
芝麻
• Stardog
精湛的
• …以及更多的RDF存储

好的起点可能是DEX或Neo4j:如果你正在为c++寻找一个好的、真正快速的graphdb内核，DEX可能是最好的，但你必须自己实现很多网络和分发的东西。Neo4j有很多分布和容错性，但目前更多的是在顶点分片级别，它的内核是Java。关于实现分布式图算法的想法和灵感，可以看看Golden Orb和Signal/Collect。另一种方法可能是从AllegroGraph或Stardog开始。特别是AllegroGraph在开始时可能会有点棘手，直到你习惯了他们的思维方式。