Como estruturar relacionamentos em Azure Cosmos DB?

votos
0

Eu tenho dois conjuntos de dados na mesma coleção no cosmos, um são 'posts' e outro são 'utilizadores', eles estão ligados pelos postos criados pelos usuários.

Atualmente minha estrutura é a seguinte;

// user document
{
id: 123,
postIds: ['id1','id2']
}

// post document
{
id: 'id1',
ownerId: 123
}
{
id: 'id2',
ownerId: 123
}

A principal problema com esta configuração é a natureza fungível dele, código tem de fazer cumprir o link e se há um conjunto de dados de bugs vai muito facilmente ser perdido com nenhuma maneira clara para recuperá-lo.

Estou também preocupado com o desempenho, se um usuário tem 10.000 mensagens isso é 10.000 pesquisas eu vou ter que fazer para resolver todas as mensagens ..

É este o método correto para a modelagem de relacionamentos de entidade?

Publicado 19/12/2018 em 14:09
fonte usuário
Em outras línguas...                            


1 respostas

votos
2

Como foi dito por David, é uma longa discussão, mas é muito comum assim, desde que eu tenho na hora ou mais de tempo "livre", eu estou mais do que feliz em tentar responder-lhe, uma vez por todas, eu espero.

PORQUE NORMALIZE?

Primeira coisa que noto em seu post: você está procurando algum nível de integridade referencial ( https://en.wikipedia.org/wiki/Referential_integrity ), que é algo que é necessário quando você decompor um objeto maior em suas partes constituintes. Também chamado de normalização.

Enquanto isto é normalmente feito em um banco de dados relacional, é agora também está se tornando popular na base de dados não-relacional, uma vez que ajuda muito a evitar a duplicação de dados que geralmente cria mais problema do que o que ele resolve.

https://docs.mongodb.com/manual/core/data-model-design/#normalized-data-models

Mas você realmente precisa dele? Desde que você escolheu para usar banco de dados de documentos JSON, você deve aproveitar o fato de que é capaz de armazenar todo o documento e, em seguida, apenas armazenar o documento juntamente com todos os dados do proprietário: nome, sobrenome, ou todos os outros dados que você tem sobre o usuário que criou o documento. Sim, eu estou dizendo que você pode querer avaliar não ter posto e usuário, mas apenas as mensagens com informação do usuário dentro it.This pode ser realmente muito correto, como você vai ter certeza de obter os dados exatos para o usuário existente no momento da criação post. Digamos, por exemplo, eu criar um post e tenho biografia "X". Eu, então, atualizar a minha biografia para "Y" e criar um novo post. Os dois pós terão diferentes biografias do autor e este é apenas um direito, como eles têm exatamente capturado realidade.

Claro que você pode querer exibir também uma biografia em uma página do autor. Neste caso, você terá um problema. Qual deles você vai usar? Provavelmente o último.

Se todos os autores, a fim de existir em seu sistema, deve ter post publicado, que pode muito bem ser o suficiente. Mas talvez você quer ter um autor escrever sua biografia e sendo listado em seu sistema, antes mesmo que ele escreve um post de blog.

Nesse caso, você precisa para normalizar o modelo e criar um novo tipo de documento, apenas para autores. Se este for o seu caso, então, você também precisa descobrir como manipulador a situação descrita antes. Quando o autor irá atualizar a sua própria biografia, será que você acabou de atualizar o documento autor, ou criar um novo? Se você criar um novo, para que você possa manter o controle de todas as alterações, você também vai atualizar todo o post anterior para que eles vão fazer referência ao novo documento, ou não?

Como você pode ver, a resposta é complexa, e realmente depende de que tipo de informação que você deseja capturar a partir do mundo real.

Então, em primeiro lugar, descobrir se você realmente precisa para manter mensagens e usuários separados.

CONSISTÊNCIA

Vamos supor que você realmente quer ter as mensagens e usuários mantidos em documentos separados, e assim normalizar o seu modelo. Neste caso, tenha em mente que Cosmos DB (mas NoSQL em geral) bancos de dados não oferecem qualquer tipo de suporte nativo para impor a integridade referencial, então você está praticamente no seu próprio país. Os índices podem ajudar, é claro, assim que você pode querer indexar a propriedade ownerId, de modo que antes de excluir um autor, por exemplo, você pode verificar de forma eficiente se houver qualquer post feito por ele / ela que permanecerá órfãos contrário. Outra opção é criar manualmente e manter actualizado um outro documento que, para cada autor, guarda informação sobre os posts que ele / ela escreveu. Com essa abordagem, você pode simplesmente olhar para este documento para entender quais as mensagens de blog pertence a um autor. Você pode tentar manter este documento atualizado automaticamente usando gatilhos, ou fazê-lo em sua aplicação. Basta ter em mente que, quando você normalizar, em um banco de dados NoSQL, manter os dados consistentes é de sua responsabilidade. Este é exatamente o oposto de um banco de dados relacional, onde a sua responsabilidade é a de manter os dados consistentes quando você de-normalizá-lo.

PRESTAÇÕES

Desempenho poderia ser um problema, mas você não costumam modelar a fim de apoiar performances em primeiro lugar. Você modela, a fim de se certificar que seu modelo pode representar e armazenar a informação que você precisa do mundo real e então você otimizá-lo, a fim de ter um desempenho decente com o banco de dados que você tem escolheu usar. Como banco de dados diferente terá diferentes restrições, o modelo será então adaptado para lidar com que as restrições. Isso não é nada mais e nada menos que o bom e velho “lógico” vs “físico” discussão de modelagem.

No caso Cosmos DB, você não deve ter consultas que vão-partição cruz como eles são mais caros.

Infelizmente particionamento é algo que você escolheu uma vez por todas, para que você realmente precisa ter claro em sua mente o que é o caso de uso mais comum você quiser apoiar na melhor das hipóteses. Se a maioria de suas consultas são feitas em por autor base, gostaria de particionar por autor.

Agora, enquanto isso pode parece uma escolha inteligente, será somente se você tem um monte de autores. Se você tiver apenas um, por exemplo, todos os dados e consultas entrará em apenas uma partição, limitando A LOT seu desempenho. Lembre-se, na verdade, que Cosmos DB RU são divididos entre todas as partições disponíveis: com 10.000 RU, por exemplo, você normalmente obter 5 partições, o que significa que todos os seus valores serão distribuídos por 5 partições. Cada partição terá um limite superior de 2000 RU. Se todas as suas consultas usar apenas uma partição, o seu máximo desempenho real é que 2000 e não 10000 RUs.

Eu realmente espero que esta ajuda você a começar a descobrir a resposta. E eu realmente espero que isso ajuda a promover e fazer crescer uma discussão (como modelo para um banco de dados de documentos) que eu acho que é realmente devido e maduro agora.

Respondeu 03/01/2019 em 02:37
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more