Neo4j替代关系数据库

Question

我正在实现一个基于sinatra/rails的Web门户网站，可能最终会在表/模型之间具有几个多对多的关系。这是一个单人团队和兼职但真实世界的应用程序。

我与某人讨论了我的实体，并建议尝试neo4j。来自真正的“非性感”企业世界，我的倾向是使用关系数据库，直到它停止扩展或因分片等原因变成噩梦，然后考虑其他任何东西。

然而，

- 我第一次在这个项目中使用postgres以及datamapper，需要花费时间快速入门 - 我只是尝试一些事情并构建更多用例，因此我必须持续更新我的架构（原型设计和beta反馈）。我不必在neo4j中做到这一点（除了更改我的查询） - 看起来使用neo4j很容易设置搜索。但Postgres也可以进行全文搜索。 - Postgres最近宣布支持json和javascript。想知道是否应该坚持使用PG并投入更多时间学习PG（拥有良好社区）而不是neo4j。

寻找neo4j更好的用例，特别是在项目的原型/初始阶段。我明白如果网站增长，我可能最终会有多个持久技术，如S3，关系（PG），mongo等。

还好知道它如何在Rails/Ruby生态系统中发挥作用。

更新1：

我得到了很多好的答案，似乎现在坚持使用Postgres是正确的选择（特别是因为我部署到heroku）。

然而，无模式的想法很诱人。基本上，我正在考虑一种方法，在你有100-150个用户并且你已经为你的产品找到了一个好的架构（业务用例）时，你不定义数据模型，而是在演示概念并通过有限的注册获取反馈。然后可以决定架构并开始进行关系。

如果有易于使用/设置的无模式持久性选项（基于新用户的易用性），这将非常好（可能会放弃某些方面，如可扩展性）。

- codeObserver

---

扩展和分片并不是我选择图形数据库的主要原因。您能提供更多关于您领域的信息吗？您是否正在建模一个网络？您是否需要计算任何网络统计数据或运行任何图形算法？存在几个多对多表可能表示一个网络，因为您可以将这些关系视为边缘。您的边缘代表什么？ - Bobby Norton

Answer 1

如果你的数据模型非常混乱，应该考虑使用图形数据库。它们用于表达实体之间高度复杂的关系。为此，它们在数据级别存储关系，而RDBMS则使用声明性方法。仅存储关系只有在这些关系非常不同的情况下才有意义，否则您将不断地重复数据，浪费大量空间。

要求这样多样化的关系，您必须处理大量数据。这就是图形数据库的优势所在，因为它们只需选择一条记录并跟随其关系，而不是执行大量连接操作。支持我的说法：您会注意到Neo4j网站上的每个用例都涉及非常复杂的数据。

简而言之，如果您对我上面说的内容不感兴趣，我认为您应该使用其他技术。如果这仅仅是关于扩展、无模式或快速启动项目，那么请查看其他NoSQL解决方案（更具体地说，是列或文档导向数据库）。否则，您应该坚持使用PostgreSQL。您也可以像您所说的那样考虑polyglot persistence。

关于你的更新，你可以考虑hStore。我认为它符合你的要求。它是一个在Heroku上也能工作的PostgreSQL模块。

- LMeyer

---

感谢您推荐hstore。它看起来很不错，可能非常适合快速原型设计和演示用例。更重要的是，它由Heroku提供！！因此，我的Rails应用程序可以使用它们。 令人惊讶的是，鉴于它对于快速原型设计如此简单，我并没有看到很多GitHub示例和博客文章。现在，我会继续使用Postgres，但一旦发现自己在模式设计上花费更多时间，我肯定会转换过去。 - codeObserver

原来有一个活跃记录的 hstore 宝石 [但没有 datamapper 宝石 :( ] gem 'activerecord-postgres-hstore' https://github.com/engageis/activerecord-postgres-hstore - codeObserver

这并不一定意味着有大量的数据。在我们的情况下，我们使用PostgreSQL来存储用户数据和数据集，使用Neo4J进行人口复杂性分析和大量关系的存储。它确实有助于数据湖的管理。 - Andrew Scott Evans

Answer 2

我认为只有在数据模型非常复杂时才应该使用图形数据库的说法我不太同意。我相信它们也可以处理简单的数据模型/关系。

如果您没有使用过Neo4j或Postgres的经验，那么很可能需要花费相当长的时间来学习。

选择时需要考虑以下几点：

1. 这不仅仅是针对数据库技术进行开发。您还应该考虑部署。Postgres/Neo4j的部署和扩展有多容易？

2. 考虑每种技术周围的社区和工具。是否有类似于Postgres的数据映射器的Neo4j？

3. 请注意两者之间的数据模型差异非常大。如果您已经能够以关系方式思考，那么我可能会坚持使用Postgres。如果您选择Neo4j，则在几个月内您将犯很多错误。

4. 随着时间的推移，我学会了在可以的情况下保持简单。与Neo4j相比，Postgres可能是无聊的选择，但无聊不会让您熬夜。=)

此外，我从未看到有人提到过，但你应该也看看 Riak（http://basho.com/riak/）。它是一个文档数据库，还可以在对象之间提供关系（链接）。虽然不像图形数据库那样成熟，但它可以快速连接几个实体。

- ryan1234

---

++ 推荐Riak -- 真的很喜欢它！然而，我们最近邀请了一位来自Basho的工程师进行技术演讲，他完全否定了链接 -- 他们现在不鼓励使用链接，而是建议将子对象的键（列表）存储在文档中，然后由调用应用程序去获取它们。 - Transact Charlie

啊，好的，知道了。是的，我在文档中看到了这些链接，想着，“哇！终于有一个带有一些‘关系’的文档数据库了”。他们说由于这些链接使用map/reduce，所以要以浅层次的方式使用它们——换句话说，不要试图构建一个大的图形。很失望他们不鼓励这种做法——我觉得这是个很酷的想法。 - ryan1234

Answer 3

最合适的选择取决于您要解决的问题。如果您只有一些多对多表格，关系型数据库就可以胜任。一般来说，关系型数据库有更好的OR-mapper支持，因为它们存在时间较长并且具有标准化的接口和行列结构。它们也已经得到了长时间的改进，因此它们是稳定的并且针对它们所做的优化。如果您的问题更多地涉及实体之间的连接，特别是如果您需要更高距离的连接，例如“检测未指定长度的循环”，一些“朋友的朋友喜欢什么”，那么图形数据库更好。当限制为SQL连接时，这些事情变得难以管理。像Neo4j的cypher这样的问题特定语言使得这更加简洁。不足之处在于，虽然存在图形数据库与对象之间的映射器，但并非每个框架和语言都有。

我最近使用neo4j实现了一个系统原型，能够讨论我们数据的结构和连接，并能够将其一对一地建模到数据存储中，这非常有用。此外，由于neo4j是一个无模式存储，添加其他数据点之间的连接也很容易。但由于写入性能问题，我们最终转向了mongodb，但我认为如果使用mongodb，我们不可能在同样的时间内完成该原型。

像基于文档、列、键值等其他NoSQL数据存储也涵盖特定的用例。多语言持久化绝对值得关注，因此请合理地将后端选择与业务逻辑分离，以便稍后更改技术。

- Thomas Fenzl

---

首先，我认为这是最好的答案。我想知道你从neo4j转换到mongodb的原因更多的细节。你后来是否因为转换而感到后悔，还是仍然对转换感到满意？谢谢。 - Farah