11

我正在为我的网络应用程序构建后端；它将充当前端的 API，并将用 Python（准确地说是 Flask）编写。

在对设计和实现做出一些决定之后，我进入了数据库部分。我开始思考 NoSQL 数据存储是否可能比传统的 SQL 数据库更适合我的项目。以下是应该由数据库处理的基本功能描述，然后是我可以提出的关于我应该选择哪种类型的存储的优缺点列表。最后说说我为什么考虑使用 RethinkDB 而不是其他 NoSQL 数据存储。

API 的基本功能

API 仅包含几个模型：Artist、Song、Suggestion和。UserUserArtists

我希望能够添加User带有一些关联数据的 a 并将一些Artists 链接到它。我想根据要求将Songs 添加到Artists 中，并Suggestion为 a生成 a User，其中将包含 anArtist和 a Song。

也许最重要的部分之一是Artists 将定期链接到Users （并且Artists 也可以从系统中删除 - 因此也可以从 s 中删除User- 如果它们不满足某些标准）。Songs 也将被动态添加到Artists。这意味着Users 没有固定的 s 集合，Artists 也没有Artist固定的 s 集合Song——它们将不断更新。

优点

对于 NoSQL：

  • 灵活的模式，因为不是每个Artist人都有 FacebookID 或SongSoundcloudID；
  • 虽然是 JSON API，但我相信我会从记录存储为 JSON 的事实中受益；
  • 我相信 s 的数量Song，尤其是Suggestions 的数量会增加很多，因此 NoSQL 会在这里做得更好；

对于 SQL：

  • 它的固定模式可能对模型之间的关系派上用场；
  • Flask 支持 SQLAlchemy，这对定义模型很有帮助；

缺点

对于 NoSQL：

  • 关系更难实现，更新模型类似于事务涉及一些代码；
  • Flask 没有任何包装器或模块来简化事情，因此我需要实现某种包装器来帮助我在执行数据库操作时使代码更具可读性；
  • 我不确定应该如何存储我的记录，尤其是UserArtists

对于 SQL：

  • 操作很庞大，我必须定义模式，检查列是否有默认值，分配默认值，验证数据，开始/提交事务——我相信对于像 API 这样简单的东西来说太麻烦了；

为什么要重新思考数据库？

我考虑过 RehinkDB 可能为我的 API 实现 NoSQL，原因如下：

  • 它看起来比其他解决方案更简单、更轻量；
  • 它具有原生 Python 支持，这是一大优势；
  • 它实现了表连接和其他可以在我的 API 中派上用场的东西，这在模型之间有一些关系；
  • 这是相当新的，我看到了社区的很多暗示和爱。还有意愿不断添加利用数据库交互的新事物。

考虑到所有这些，我很高兴听到关于 NoSQL 或 SQL 是否更适合我的需求的任何建议，以及对这两者的任何其他赞成/反对意见，当然，还有对我没有说明的事情的一些更正适当地。

4

1 回答 1

14

我在 RethinkDB 工作，但这是我作为 Web 开发人员的公正回答（至少尽可能公正）。

  • 从开发人员的角度来看（在您的情况下），灵活的模式很好。就像您说的那样，使用 PostgreSQL 之类的东西，您必须格式化从第三方（SoundCloud、Facebook 等）提取的所有数据。虽然这不是一件很难做到的事情，但也不是一件令人愉快的事情。

  • 能够加入表格，对我来说是自然的做事方式（比如用户/用户艺术家/艺术家）。虽然您可以有一个用户将包含艺术家的结构，但当您需要检索艺术家并为每个人提供用户列表时，使用它会很不愉快。

第一点是 NoSQL 数据库中常见的东西，而 JOIN 操作更像是 SQL 数据库的东西。您可以将 RethinkDB 视为提供世界上最好的东西的东西。

我相信使用 RethinkDB 进行开发是简单、快速和愉快的，这就是我作为 Web 开发人员所寻找的。

但是，您可能需要但 RethinkDB 没有提供的一件事，那就是事务。如果您需要对多个表（或文档 - 就像您必须在用户之间转移资金）进行原子更新，那么使用 PostgreSQL 之类的东西肯定会更好。如果您只需要更新多个表，RethinkDB 可以处理。

就像你说的，虽然 RethinkDB 是新的，但社区很棒，而且我们 - 在 RethinkDB - 非常关心我们的用户。

如果您有更多问题，我很乐意回答：）

于 2013-12-15T22:15:02.533 回答