Construindo com padrões: o Padrão Outlier
Avalie esse Tutorial
Até agora nesta sérieConstruindo com Padrões, examinamos os padrõesPolimórfico, Atributoe Bucket. Embora o esquema do documento nesses padrões tenha pequenas variações, do ponto de vista do aplicativo e da query, as estruturas do documento são bastante consistentes. O que acontece, no entanto, quando este não é o caso? O que acontece quando há dados que estão fora do padrão "normal"? E se houver um outlier?
Imagine que você está começando um site de e-commerce que vende livros. Uma das queries que você pode estar interessado em executar é "quem comprou um livro específico". Isso pode ser útil para um sistema de recomendações mostrar a seus clientes livros de interesse semelhantes. Você decide armazenar o
user_id de um cliente em uma array para cada livro. Simples o suficiente, certo?Bem, isso pode realmente funcionar para 99.99% dos casos, mas o que acontece quando JKRowling lança um novo livro deHarryPotter e as vendas disparam na casa dos milhões? O limite de tamanho do documento 16MB BSON pode ser facilmente atingido. Redesenhar todo o nosso aplicativo para essa situaçãoatípico pode resultar em um desempenho reduzido para o livro típico, mas precisamos levar isso em consideração.
Com o padrão Outlier, estamos trabalhando para evitar que algumas consultas ou documentos direcionem nossa solução para uma solução que não seria ideal para a maioria dos nossos casos de uso. Nem todo livro vendido vende milhões de cópias.
Um documento
booktípico que armazena informaçõesuser_id pode ser semelhante a:1 { 2 "_id": ObjectID("507f1f77bcf86cd799439011") 3 "title": "A Genealogical Record of a Line of Alger", 4 "author": "Ken W. Alger", 5 ..., 6 "customers_purchased": ["user00", "user01", "user02"] 7 8 }
Isso funcionaria bem para a grande maioria dos livros que provavelmente não alcançarão as listas de "mais vendidos". A contabilização de outliers embora resulte na expansão da array
customers_purchased além de um limite de item 1000 que definimos, adicionaremos um novo campo para "sinalizar" o livro como um outlier.1 { 2 "_id": ObjectID("507f191e810c19729de860ea"), 3 "title": "Harry Potter, the Next Chapter", 4 "author": "J.K. Rowling", 5 ..., 6 "customers_purchased": ["user00", "user01", "user02", ..., "user999"], 7 "has_extras": "true" 8 }
Em seguida, moveríamos as informações de estouro para um documento separado vinculado ao
iddo livro. Dentro do aplicativo, seríamos capazes de determinar se um documento tem um campohas_extras com um valor de true. Se esse for o caso, o aplicativo recuperaria as informações extras. Isso poderia ser tratado de modo a ser bastante transparente para a maior parte do código do aplicativo.Muitas decisões de design serão baseadas na carga de trabalho do aplicativo, portanto, essa solução tem como objetivo mostrar um exemplo do padrão Outlier. O conceito importante a ser entendido aqui é que os outliers têm uma diferença significativa o suficiente em seus dados que, se fossem considerados "normais", alterar o design do aplicativo para eles degradaria o desempenho das queries e documentos mais típicos.
O padrão Outlier é um padrão avançado, mas que pode resultar em grandes melhorias de desempenho. É frequentemente usado em situações em que a popularidade é um fator, como relacionamentos em redes sociais, vendas de livros, resenhas de filmes etc. A Internet transformou nosso mundo em um lugar muito menor e, quando algo se torna popular, transforma a maneira como precisamos modelar os dados em torno do item.
Um exemplo é um cliente que possui um produto de vídeoconferência. A lista de participantes autorizados na maioria das videoconferências pode ser mantida no mesmo documento da conferência. No entanto, existem alguns eventos, como o all hands de uma empresa, que têm milhares de participantes esperados. Para essas conferências atípicas, o cliente implementou documentos "overflow" para registrar as longas listas de participantes.
O problema que o padrão Outlier aborda é impedir que alguns documentos ou consultas determinem a solução de um aplicativo. especialmente quando essa solução não seria ideal para a maioria dos casos de uso. Podemos aproveitar o modelo de dados flexível do MongoDB para adicionar um campo ao documento "sinalizando-o" como um outlier. Em seguida, dentro do aplicativo, tratamos os outliers de forma ligeiramente diferente. Ao adaptar seu esquema para o documento ou consulta típico, o desempenho do aplicativo será otimizado para esses casos de uso normais e os valores discrepantes ainda serão resolvidos.
Uma coisa a considerar com esse padrão é que ele geralmente é adaptado para consultas e situações específicas. Portanto, as consultas ad hoc podem resultar em um desempenho inferior ao ideal. Além disso, como grande parte do trabalho é feito dentro do próprio código do aplicativo, a manutenção adicional do código pode ser necessária ao longo do tempo.
Em nossa próxima postagemConstruindo com Padrões, daremos uma olhada no Padrão Computado e como otimizar o esquema para aplicativos que podem resultar em desperdício desnecessário de recursos.