这种模式听起来更适合面向文档的数据存储还是关系？

Question

免责声明：如果这个问题更适合 serverfault.com，请告诉我

---

我想存储有关音乐的信息，具体来说：

• 类型
• 艺术家
• 专辑
• 歌曲

此信息将在网络应用程序中使用，我希望人们能够看到与专辑关联的所有歌曲、与艺术家关联的专辑以及与流派关联的艺术家。

我目前正在使用 MySQL，但在我决定切换之前，我想知道：

1. 水平缩放有多容易？
2. 是否比基于 SQL 的解决方案更易于管理？
3. 我要存储的上述数据是否太难实现无架构？
4. 当我想到关联时，我立即想到 RDBMS；数据是否可以存储在 CouchDB 之类的东西中，但仍具有如上所述的某种关联？
5. 我的 Web 应用程序需要复制，CouchDB 或其他人如何处理这个问题？

Answer 1

您的数据似乎非常适合面向文档的数据库。
文档示例：
{
"type":"Album",
"artist":"ArtistName",
"album_name":"AlbumName",
"songs" : [
{"title":"SongTitle","duration":4.5}
],
"genres":["rock","indie"]
}

复制是 couchDB 最酷的功能之一 (http://blog.couch.io/post/468392274/whats-new-in-apache-couchdb-0-11-part-three-new)
您可能还想看看 Riak。

Answer 2

这类信息非常适合文档数据库。与许多现实世界的数据一样，它本质上不是关系的，因此将其硬塞到关系模式中会让人头疼（即使使用 ORM - 我是根据经验说话的）。 Ubuntu 已经在他们的One product 中使用 CouchDB 来存储音乐元数据以及其他内容。

一一回答剩下的问题：

1. 水平缩放方式比使用 RDBMS 更容易。这是 Facebook、Digg 和 LinkedIn 等大型网站正在使用或正在积极调查无模式数据库的众多原因之一。例如，由于Eventual Consistency 的概念，分片（在系统中的不同节点之间划分数据）工作得很好；即，数据可能会在一段时间内跨节点不一致，但最终会解析为一致状态。
2. 这取决于您所说的“管理”... 安装通常快速且容易完成。没有需要配置和保护的用户帐户（这通常在应用程序的业务逻辑层中完成）。实时处理文档数据库可能很有趣：例如，CouchDB 中没有临时查询；您必须使用 Futon UI 或通过 HTTP 请求与其通信。然而，MongoDB 确实支持 ad hoc 查询。
3. 我不应该这么认为。 Bastien 的回答提供了一个 JSON 文档序列化一些数据的好例子。无模式数据库的美妙之处在于，一个文档中可能缺少字段而出现在另一个文档中，或者文档之间可能完全不同。这消除了与 RDBMS 的null 值相关的许多问题，这些问题多种多样。
4. 是的；关联存储为嵌套文档，在您的应用程序中解析为对象引用、集合等。在 Bastien 的回答中，“songs”键标识歌曲文档数组。
5. 这与您关于水平缩放的第一个问题非常相似（水平缩放和复制交织在一起）。正如 CouchIO 博客文章 Bastien 提到的那样，“复制……从一开始就融入了 CouchDB。”。我的理解是，所有文档数据库都可以很好地处理复制，并且比在 RDBMS 中设置它更容易。

如果您决定要将歌曲文件本身与元数据一起存储，您也可以在 CouchDB 中执行此操作，方法是将歌曲文件作为文档的附件提供；此外，这样做不会导致任何模式不一致，因为没有模式！

我希望我在这里没有犯太多错误；我对自己记录数据库很陌生。