Звучит ли эта схема лучше для документно-ориентированного хранилища данных или реляционного?

Отказ от ответственности: дайте мне знать, если этот вопрос лучше подходит для serverfault.com

Я хочу хранить информацию о музыке, а именно:

  • жанры
  • художники
  • альбомы
  • песни

Эта информация будет использоваться в веб-приложении, и я хочу, чтобы люди могли видеть все песни, связанные с альбомом, а также альбомы, связанные с исполнителем, и исполнители, связанные с жанром.

В настоящее время я использую MySQL, но прежде чем принять решение о переключении, я хочу знать:

  1. Насколько легко масштабировать по горизонтали?
  2. Это проще в управлении, чем решение на основе SQL?
  3. Будут ли данные, которые я хочу сохранить, слишком сложно сделать без схемы?
  4. Когда я думаю об ассоциации, я сразу думаю о РСУБД; могут ли данные храниться в чем-то вроде CouchDB, но все же иметь какую-то связь, как указано выше?
  5. Мое веб-приложение требует репликации. Насколько хорошо CouchDB или другие пользователи справляются с этим?
Источник

2 ответа

Решение

Этот вид информации идеально подходит для баз данных документов. Как и в случае с большинством реальных данных, они не являются по своей природе реляционными, поэтому использование их в реляционной схеме приведет к головным болям (даже при использовании ORM - я говорю по опыту). Ubuntu уже использует CouchDB для хранения музыкальных метаданных, а также других вещей, в своем продукте One.

Возьмите оставшиеся вопросы по одному:

  1. Горизонтальное масштабирование намного проще, чем в RDBMS. Это одна из многих причин, по которой крупные сайты, такие как Facebook, Digg и LinkedIn, используют или активно изучают базы данных без схем. Например, разделение (разделение ваших данных между различными узлами в системе) прекрасно работает благодаря концепции, называемой конечной согласованностью; то есть данные могут быть несовместимыми между узлами в течение некоторого времени, но в конечном итоге они перейдут в согласованное состояние.
  2. Это зависит от того, что вы подразумеваете под "управлять"... Установка обычно быстрая и простая в завершении. Нет учетных записей пользователей для настройки и защиты (обычно это делается на уровне бизнес-логики приложения). Работа с БД документов в реальном времени может быть интересной: например, в CouchDB нет специальных запросов; Вы должны использовать пользовательский интерфейс Futon или общаться с ним через HTTP-запросы. MongoDB, однако, поддерживает специальные запросы.
  3. Я не должен так думать. Ответ Бастьена представляет собой хороший пример документа JSON, сериализующего некоторые данные. Прелесть БД без схемы в том, что поля могут отсутствовать в одном документе и присутствовать в другом, или документы могут полностью отличаться друг от друга. Это устраняет многие проблемы, связанные с RDBMS null Значение, которое много и разнообразно.
  4. Да; ассоциации хранятся в виде вложенных документов, которые анализируются в вашем приложении как ссылки на объекты, коллекции и т. д. В ответе Бастиена клавиша "песни" идентифицирует массив документов песен.
  5. Это очень похоже на ваш первый вопрос о горизонтальном масштабировании (горизонтальное масштабирование и репликация взаимосвязаны). Как отметил Бастиен в блоге CouchIO, "Репликация… была встроена в CouchDB с самого начала". Насколько я понимаю, все базы данных документов хорошо справляются с репликацией и делают это проще, чем настраивают ее в СУБД.

Если бы вы решили, что хотите сохранить сам файл песни вместе с метаданными, вы можете сделать это и в CouchDB, предоставив файл песни как приложение к документу; Более того, вы не будете иметь никаких несоответствий схемы в результате этого, потому что нет схемы!

Я надеюсь, что я не сделал слишком много ошибок здесь; Я совершенно новичок в документировании БД самостоятельно.

Источник

Ваши данные идеально подходят для баз данных, ориентированных на документы.
Пример документа:
{
"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)
Вы также можете взглянуть на Риака.

Источник
Другие вопросы по тегам