3

免责声明：让我知道这个问题是否更适合 serverfault.com

我想存储有关音乐的信息，特别是：

  • 流派
  • 艺术家
  • 专辑
  • 歌曲

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

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

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

2 回答 2

3

您的数据似乎非常适合面向文档的数据库。
文档示例：
{
"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）
您可能还想看看在里亚克。

于 2010-03-24T09:36:02.723 回答
2

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

一个接一个地回答你剩下的问题：

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

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

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

于 2010-03-24T11:07:47.483 回答