Какой выбор для реляционного хранилища баз данных (NoSql?)? - PullRequest
Новая
       21

Какой выбор для реляционного хранилища баз данных (NoSql?)?

1 голос
/ 09 апреля 2011

Какие есть варианты для баз данных хранилища документов, которые позволяют извлекать реляционные данные?Чтобы привести реальный пример, скажем, у вас есть база данных для хранения сообщений в блоге.Я бы хотел, чтобы данные выглядели примерно так:
{id: 12345,<br> title: "My post",<br> body: "The body of my post",<br> author: {<br> id: 123,<br> name: "Joe Bloggs",<br> email: "joe.bloggs@example.com"<br> }<br> }

Теперь у вас, скорее всего, будет несколько таких записей, которые все разделяют сведения об авторе.Что мне действительно нравится, так это чтобы сам автор сохранялся как другая запись в базе данных, чтобы при обновлении этой записи каждая запись, которая ссылается на нее, также получала обновления.На сегодняшний день единственный способ, которым я видел упомянутое, заключается в том, чтобы вместо записи записи хранить идентификатор записи автора, чтобы вызывающий код должен был выполнить два запроса к хранилищу данных - один для сообщения, а другойдля идентификатора автора, который связан с постом.

Существуют ли какие-либо базы данных хранилища документов, которые позволят мне сделать один запрос и вернуть структурированный документ, содержащий связанные записи?И предпочтительно, позвольте мне отредактировать внутреннюю часть документа, сохранить документ в целом и выполнить правильные действия [т. Е. Выше, если я получил весь документ, изменил значение электронной почты и сохранил весь документ, тоадрес электронной почты автора записи изменяется, и отражается во всех сообщениях, которые имеют этого автора ...]

1 Ответ

2 голосов
/ 09 апреля 2011

Во-первых, позвольте мне подтвердить: этот конкретный тип данных несколько реляционный по своей природе. Это просто зависит от того, как именно вы хотите структурировать этот тип данных, и какие технологии вам доступны для этого конкретного проекта. Тем не менее, как вы хотите, чтобы ваши данные структурированы?

Если вы можете структурировать свои данные любым удобным для вас способом, вы можете сделать что-то вроде этого: 

{
  name: 'Joe', 
  email: 'joe.bloggs@ex.com', 
  posts: [
    {
      id: 123, 
      title: "My post"
    },
    {..}
  ] 
}

Где все сообщения содержались в одной конкретной паре ключ / значение. Этот конкретный тип данных, который я бы сказал, уникально подходит для Riak (из-за возможности внутреннего запроса к JSON с использованием встроенного JavaScript). Хотя вы, вероятно, могли бы прийти к этому с любой точки зрения хранилища данных NoSQL ( Cassandra , Couch , Mongo и др.), так как большинство из них могут хранить прямо в формате JSON. На данный момент у меня просто есть склонность к Риаку из-за моего личного опыта.

Более интересные вещи, с которыми вы, вероятно, столкнетесь, будут связаны с тем, как вы справляетесь с хранилищем данных. Например, мне действительно нравится использовать Ripple для Ruby, что позволяет мне очень легко работать с такими данными в Riak. Но если вы находитесь на земле Java, это может усложнить принятие этого метода (хотя я не потратил много времени на изучение принятия Riak на Java), так как он имеет тенденцию отставать от стиля 'edge' методы хранения данных.

Более того, заставить мозг начать думать в терминах NoSQL или без использования «отношений» - это то, что обычно занимает больше всего времени в структурировании данных. Поскольку нет схемы, и нет никаких предвзятых мнений, которые идут с ней, это означает, что вы можете делать много вещей, которые считаются просто неправильными в мире реляционных БД. Например, хранить все сообщения в блоге для одного пользователя в одном документе, что просто не сработает в стандартном реляционном мире со строгими таблицами.

...