我的 基本要求 来自 GraphDB:

  • 成熟(生产就绪)
  • native .NET 或 C++ 语言绑定(bind)
  • 水平可扩展性:两者
  • 自动数据冗余和分片
  • 分布式图算法/查询执行

  • 目前我取消了以下资格:
  • InfiniteGraph:无 C++/.NET 语言绑定(bind)
  • HyperGraphDB:无 C++/.NET 语言绑定(bind)
  • 微软三位一体:不成熟
  • Neo4j:未分发

  • 我不确定以下内容的可扩展性:
  • 稀疏 DEX
  • Franz Inc. AllegroGraph
  • Sones GraphDB

  • 我发现有关水平可伸缩性功能的可用信息非常普遍。我想这是有充分理由的。

    任何信息,将不胜感激。

    最佳答案

    不幸的是,您的基本要求已经扩展了当今对图形的一般理解——即使在学术界也是如此。没有列出的纯图数据库能够满足您的所有需求。意识到大型分布式但互连图的分布式图算法仍然是一个很大的研究问题。因此,对于您的应用程序,最好找到匹配良好的图形数据库、图形处理堆栈或 RDF-Store,并自行实现缺失的部分。
    当您的应用程序主要是在线事务图处理 (OLTP)(读/写繁重)并专注于顶点并且您可以暂时放弃分布式算法时,请使用以下其中之一:

  • Neo4j
  • OrientDB
  • DEX
  • HyperGraphDB
  • 无限图
  • 信息网格
  • 微软霍顿

  • 当更多的在线分析处理(OLAP)(主要是阅读)仍然关注顶点和分布时,那么:
  • Apache Hama(早期项目)
  • Microsoft Trinity(研究项目)
  • Golden Orb(不错,但仅限 Java)
  • 信号/收集(http://www.ifi.uzh.ch/ddis/research/sc ,但一个研究项目)

  • 或者它更侧重于边缘、逻辑推理/模式匹配,您需要或者更好地可以使用边缘级别的分布,例如在语义 Web 中,然后使用这些 RDF-/Triple-/Quadstores 之一:
  • AllegroGraph(好吧,它们是一个 graphdb/rdf 存储混合体;)
  • 耶拿
  • 芝麻
  • Stardog
  • 艺术大师
  • ...以及更多 RDF 存储

  • 好的起点可能是 DEX 或 Neo4j:如果您正在为 C++ DEX 寻找一个好的且非常快速的 graphdb 内核,那可能是最好的,但是您必须自己实现很多网络和分发的东西。 Neo4j 有很多分布和容错性,但目前更多的是在顶点分片级别,它的内核是 Java。有关实现分布式图算法的想法和灵感,请查看 Golden Orb 和 Signal/Collect。
    另一种方法可能是从 AllegroGraph 或 Stardog 开始。特别是 AllegroGraph 在开始时可能会有点棘手,直到您接受他们的思维方式。 Stardog 还年轻,Java,但速度很快,已经相当成熟。

    关于nosql - 寻找具有 .NET 或 C++ 绑定(bind)的成熟、可扩展的 GraphDB,我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/7370375/

    10-10 04:40