Arrays massivas
Lauren Schaefer, Daniel Coupal4 min read • Published Feb 12, 2022 • Updated Oct 01, 2024
Avalie esse Artigo
Os padrões de projeto são uma parte fundamental da engenharia de software. Eles servem como práticas recomendadas para desenvolvedores e apresentam uma linguagem comum para o desenvolvimento de aplicativos.
No MongoDB, temos padrões de projeto de esquema para ajudar desenvolvedores a planejar e fazer iterações em seus projetos de esquema. Daniel Coupal e Ken Alger escreveram juntos uma fantástica série no blog que destaca cada um dos padrões de projeto de esquema. Se você realmente quer se aprofundar nos detalhes (e nós recomendamos que sim), confira o curso gratuito sobre Modelagem de dados da MongoDB University.
Às vezes, os desenvolvedores começam a projetar seus esquemas e a criar seus aplicativos sem pensar nas práticas recomendadas. À medida que seus aplicativos começam a ser dimensionados, eles notam que as coisas não andam bem.
Identificamos vários erros comuns que desenvolvedores cometem com o MongoDB. Chamamos esses erros de "antipadrões de projeto de esquema".
Ao longo desta série do blog, vou apresentar seis antipadrões comuns. Vamos começar hoje com o antipadrão "arrays gigantes".
Prefere aprender por vídeo? Podemos ajudar você.
Uma das regras de ouro ao modelar dados no MongoDB é que os dados que são acessados juntos devem ser armazenados juntos. Se você estiver recuperando ou atualizando dados juntos com frequência, provavelmente deverá armazená-los juntos. Os dados são geralmente armazenados juntos, incorporando informações relacionadas em subdocumentos ou arrays.
O problema é que às vezes os desenvolvedores se empolgam e incorporam grandes quantidades de informações em um único documento.
Considere um exemplo em que armazenamos informações sobre funcionários que trabalham em vários prédios do governo. Se incorporássemos os funcionários no documento do edifício, poderíamos armazenar nossos dados em uma coleção de edifícios como a seguinte:
1 // buildings collection 2 { 3 "_id": "city_hall", 4 "name": "City Hall", 5 "city": "Pawnee", 6 "state": "IN", 7 "employees": [ 8 { 9 "_id": 123456789, 10 "first": "Leslie", 11 "last": "Yepp", 12 "cell": "8125552344", 13 "start-year": "2004" 14 }, 15 { 16 "_id": 234567890, 17 "first": "Ron", 18 "last": "Swandaughter", 19 "cell": "8125559347", 20 "start-year": "2002" 21 } 22 ] 23 }
Neste exemplo, a matriz "funcionários" é ilimitada. À medida que começarmos a armazenar informações sobre todos os funcionários que trabalham na prefeitura, o conjunto de funcionários expandirá – potencialmente nos enviando mais de 16 mb de documentos no máximo. Além disso, a leitura e a criação de índices em arrays se tornam gradualmente menos eficientes à medida que o tamanho da array aumenta.
Acima tempos um exemplo do antipadrão de arrays gigantes.
Então, como podemos corrigir isso?
Em vez de incorporar os funcionários nos documentos dos edifícios, poderíamos inverter o modelo e fazer o contrário, ou seja, incorporar os edifícios nos documentos dos funcionários:
1 // employees collection 2 { 3 "_id": 123456789, 4 "first": "Leslie", 5 "last": "Yepp", 6 "cell": "8125552344", 7 "start-year": "2004", 8 "building": { 9 "_id": "city_hall", 10 "name": "City Hall", 11 "city": "Pawnee", 12 "state": "IN" 13 } 14 }, 15 { 16 "_id": 234567890, 17 "first": "Ron", 18 "last": "Swandaughter", 19 "cell": "8125559347", 20 "start-year": "2002", 21 "building": { 22 "_id": "city_hall", 23 "name": "City Hall", 24 "city": "Pawnee", 25 "state": "IN" 26 } 27 }
No exemplo acima, estamos repetindo as informações sobre a prefeitura no documento de cada funcionário da prefeitura. Se exibimos com frequência informações sobre um funcionário e seu prédio juntas no aplicativo, esse modelo provavelmente faz sentido.
A desvantagem dessa abordagem é que temos muita duplicação de dados. O armazenamento é barato, então a duplicação de dados não é necessariamente um problema do ponto de vista do custo de armazenamento. No entanto, toda vez que precisarmos atualizar informações sobre a Prefeitura, precisaremos atualizar o documento para cada funcionário que trabalha lá. Se dermos uma olhada nas informações que estamos armazenando atualmente sobre os edifícios, as atualizações provavelmente serão muito raras, então essa abordagem pode ser uma boa.
Se nosso caso de uso não exigir que as informações sobre os funcionários e seu prédio sejam exibidas ou atualizadas juntas, talvez seja melhor separar as informações em duas coleções e usar referências para vinculá-las:
1 // buildings collection 2 { 3 "_id": "city_hall", 4 "name": "City Hall", 5 "city": "Pawnee", 6 "state": "IN" 7 } 8 9 // employees collection 10 { 11 "_id": 123456789, 12 "first": "Leslie", 13 "last": "Yepp", 14 "cell": "8125552344", 15 "start-year": "2004", 16 "building_id": "city_hall" 17 }, 18 { 19 "_id": 234567890, 20 "first": "Ron", 21 "last": "Swandaughter", 22 "cell": "8125559347", 23 "start-year": "2002", 24 "building_id": "city_hall" 25 }
Aqui separamos completamente nossos dados. Removemos arrays gigantes e não temos duplicação de dados.
A desvantagem é que, se precisarmos recuperar informações sobre um funcionário e seu prédio juntos, precisaremos usar $lookup para unir os dados. Operações $lookup podem ser caras, por isso é importante considerar com que frequência você precisará realizar $lookup se escolher essa opção.
Se estivermos usando $lookup com frequência, outra opção é usar o padrão de referência estendida. O padrão de referência estendida é uma mistura das duas abordagens anteriores, em que duplicamos alguns - mas não todos - os dados das duas coleções. Duplicamos apenas os dados que são frequentemente acessados juntos.
Por exemplo, se nosso aplicativo tiver uma página de perfil de usuário que exibe informações sobre o usuário e também o nome do prédio e o estado onde ele trabalha, pode ser melhor incorporar os campos nome do prédio e estado no documento do funcionário:
1 // buildings collection 2 { 3 "_id": "city_hall", 4 "name": "City Hall", 5 "city": "Pawnee", 6 "state": "IN" 7 } 8 9 // employees collection 10 { 11 "_id": 123456789, 12 "first": "Leslie", 13 "last": "Yepp", 14 "cell": "8125552344", 15 "start-year": "2004", 16 "building": { 17 "name": "City Hall", 18 "state": "IN" 19 } 20 }, 21 { 22 "_id": 234567890, 23 "first": "Ron", 24 "last": "Swandaughter", 25 "cell": "8125559347", 26 "start-year": "2002", 27 "building": { 28 "name": "City Hall", 29 "state": "IN" 30 } 31 }
Como vimos quando duplicamos os dados anteriormente, devemos estar atentos à duplicação de dados que serão atualizados com frequência. Nesse caso específico, é muito improvável que o nome do edifício e o estado em que ele se encontra sejam alterados, portanto, essa solução funciona.
Armazenar informações relacionadas nas quais você executará queries com frequência em conjunto geralmente é bom. No entanto, armazenar informações em arrays gigantes que continuarão a aumentar com o tempo geralmente é ruim.
Como acontece com todos os padrões e antipadrões de projeto de esquema do MongoDB, considere cuidadosamente seu caso de uso - os dados que serão armazenados e como será feita a query deles - para determinar qual projeto de esquema é melhor para você.
Aguarde mais publicações desta série sobre antipadrões nas próximas semanas.
Quando quiser criar um esquema no MongoDB, confira o MongoDB Atlas, que é o banco de dados como serviço totalmente gerenciado do MongoDB. O Atlas é a maneira mais fácil de começar a usar o MongoDB. Com um nível grátis permanente, você está no caminho certo para aproveitar todo o valor do MongoDB.
Confira os seguintes recursos para obter mais informações: