Как бы вы разработали блог, используя хранилище документов (например, CouchDB, Redis, MongoDB, Riak и т. Д.)

Question

Мне немного стыдно признать это, но у меня возникают проблемы с концептуализацией того, как создавать данные в нереляционном мире. Особенно с учетом того, что большинство магазинов документов / KV имеют немного другие функции.

Мне бы хотелось поучиться на конкретном примере, но я не смог найти никого, кто бы обсуждал, как вы будете проектировать, например, блог с использованием CouchDB / Redis / MongoDB / Riak / и т.д.

Есть ряд вопросов, которые я считаю важными:

1. Какие биты данных должны быть денормализованы (например, теги, вероятно, соответствуют документу, но как насчет пользователей)
2. Как вы связываетесь между документами?
3. Каков наилучший способ создания сводных представлений, особенно тех, которые требуют сортировки (например, индекса блога)

Answer 1

Прежде всего, я думаю, что вы захотите удалить redis из списка, так как это хранилище значений ключей вместо хранилища документов.Riak также является хранилищем значений ключей, но вы можете быть хранилищем документов с библиотекой, подобной Ripple .

Короче говоря, для моделирования приложения с хранилищем документов необходимо выяснить:

1. Какие данные вы бы сохранили в своем собственном документе и чтобы к нему относился другой документ.Если этот документ будет использоваться многими другими документами, то имеет смысл смоделировать его в своем собственном документе.Вы также должны подумать о запросе документов.Если вы собираетесь часто запрашивать его, возможно, было бы неплохо сохранить его в своем собственном документе, так как вам будет сложно выполнять запросы к встроенному документу.
   • Например, если у вас есть несколько экземпляров блога, блог и статья должны быть в своем собственном документе, даже если статья может быть встроена в документ блога.
   • Другим примером является пользователь и роль.Имеет смысл иметь отдельный документ для них.В моем случае я часто опрашиваю пользователя, и было бы проще, если бы он был отделен как его собственный документ.

2. Какие данные вы хотели бы сохранить (внедрить) внутри другого документа,Если этот документ принадлежит только одному документу, то «возможно» будет хорошим вариантом сохранить его в другом документе.

   • Иногда комментарии более целесообразно встраивать в другой документ

   { article : { comments : [{ content: 'yada yada', timestamp: '20/11/2010' }] } }

   Еще одно предостережение, которое вы хотели бы рассмотреть, - насколько великоразмер внедренного документа будет потому, что в mongodb максимальный размер внедренного документа составляет 5 МБ.

3. Какие данные должны быть простым массивом.Например:
   • Теги имеют смысл хранить в виде массива.{ article: { tags: ['news','bar'] } }
   • Или, если вы хотите сохранить несколько идентификаторов, т. Е. Пользователь с несколькими ролями { user: { role_ids: [1,2,3]}}

Это краткий обзор моделирования с помощью документахранить.Удачи.

Answer 2

1. Решение о том, какие объекты должны быть независимыми, а какие должны быть встроены как часть других объектов, в основном зависит от баланса производительности / усилий при чтении / записи. Если дочерний объект независим, обновление означает изменение только одного документа, при чтении родительского объекта у вас есть только идентификаторы и вам нужны дополнительные запросы для получения данных. Если дочерний объект внедрен, все данные находятся там же, когда вы читаете родительский документ, но для внесения изменений требуется найти все документы, которые используют этот объект.

2. Связывание между документами мало чем отличается от SQL - вы храните идентификатор, который используется для поиска соответствующей записи. Основное отличие состоит в том, что вместо фильтрации дочерней таблицы для поиска записей по родительскому идентификатору у вас есть список дочерних идентификаторов в родительском документе. Для многих отношений у вас будет список идентификаторов с обеих сторон, а не таблица посередине.

3. Возможности запросов сильно различаются между платформами, поэтому нет четкого ответа на вопрос, как к этому подойти. Однако, как правило, вы обычно настраиваете представления / индексы при написании документа, а не просто сохраняете документ и выполняете специальные запросы позже, как это было бы с SQL.

Answer 3

Райан Бейтс пару недель назад сделал скринкаст о mongoid, и он использует пример блогового приложения: http://railscasts.com/episodes/238-mongoid это может быть хорошим местом для начала.