3 coisas que você deve saber ao migrar do SQL para o MongoDB
Avalie esse Artigo
Bem-vindo à última postagem da minha série sobre como mudar de SQL para MongoDB. Na primeira postagem, mapeei termos e conceitos de SQL para MongoDB. Na segunda postagem, abordei as quatro principais razões pelas quais você deve usar o MongoDB.
Agora que entendemos a terminologia e por que vale a pena mudar sua mentalidade no MongoDB, vamos falar sobre três maneiras principais de mudar sua mentalidade.
Seu primeiro instinto pode ser o de converter as colunas e linhas existentes em campos e documentos e manter as formas antigas de modelagem de dados. Verificamos que as pessoas que tentam usar o MongoDB da mesma forma que usam um relational database lutam e, às vezes, falham.
Não queremos que isso aconteça com você.
Vamos discutir três maneiras principais de mudar sua mentalidade ao mudar do SQL para o MongoDB.
Como vimos na primeira publicação desta série quando modelamos documentos para leslie, ron e lauron, nem todos os documentos em uma collection precisam ter os mesmos campos.
Usuários
1 { 2 "_id": 1, 3 "first_name": "Leslie", 4 "last_name": "Yepp", 5 "cell": "8125552344", 6 "city": "Pawnee", 7 "location": [ -86.536632, 39.170344 ], 8 "hobbies": ["scrapbooking", "eating waffles", "working"], 9 "jobHistory": [ 10 { 11 "title": "Deputy Director", 12 "yearStarted": 2004 13 }, 14 { 15 "title": "City Councillor", 16 "yearStarted": 2012 17 }, 18 { 19 "title": "Director, National Parks Service, Midwest Branch", 20 "yearStarted": 2014 21 } 22 ] 23 }, 24 25 { 26 "_id": 2, 27 "first_name": "Ron", 28 "last_name": "Swandaughter", 29 "cell": "8125559347", 30 "city": "Pawnee", 31 "hobbies": ["woodworking", "fishing"], 32 "jobHistory": [ 33 { 34 "title": "Director", 35 "yearStarted": 2002 36 }, 37 { 38 "title": "CEO, Kinda Good Building Company", 39 "yearStarted": 2014 40 }, 41 { 42 "title": "Superintendent, Pawnee National Park", 43 "yearStarted": 2018 44 } 45 ] 46 }, 47 48 { 49 "_id": 3, 50 "first_name": "Lauren", 51 "last_name": "Burhug", 52 "city": "Pawnee", 53 "hobbies": ["soccer"], 54 "school": "Pawnee Elementary" 55 }
Para aqueles de nós com experiência em SQL, isso vai se parecer desconforme e provavelmente um pouco estranho no início. Prometo que vai ficar tudo bem. Abrace a diversidade de documentos. Isso nos dá muita flexibilidade e poder para modelar nossos dados.
Na verdade, o MongoDB tem um padrão de modelagem de dados especificamente para quando seus documentos não têm os mesmos campos. É chamado de Padrão Polimórfico. Usamos o padrão polimórfico quando os documentos em uma coleção são de estruturas semelhantes, mas não idênticas.
Vamos dar uma olhada em um exemplo baseado no Padrão Polimórfico. Digamos que decidimos manter uma lista dos seguidores de mídia social de cada usuário dentro de cada documento
User . Lauren e Leslie não têm muitos seguidores, então poderíamos facilmente listar seus seguidores em seus documentos. Por exemplo, o documento de Lauren pode ser parecido com isto:1 { 2 "_id": 3, 3 "first_name": "Lauren", 4 "last_name": "Burhug", 5 "city": "Pawnee", 6 "hobbies": ["soccer"], 7 "school": "Pawnee Elementary", 8 "followers": [ 9 "Brandon", 10 "Wesley", 11 "Ciara", 12 ... 13 ] 14 }
Essa abordagem provavelmente funcionaria para a maioria dos nossos usuários. No entanto, desde que Ron criou uma assento que apareceu na popular Bloosh Store, Ron tem milhões de membros. Se tentarmos listar todos os seus membros em seu document model
User, ele poderá exceder o limite de tamanho do documento16 megabyte. Coloca-se a questão: queremos otimizar nosso document model para o caso de uso típico em que um usuário tem algumas centenas de membros ou para o caso de uso fora do comum em que um usuário tem milhões de membros?Podemos utilizar o Padrão Outlier para resolver este problema. O Padrão Outlier nos permite modelar nossos dados para o caso de uso típico, mas ainda lidar com casos de uso outliers.
Podemos começar a modelar o documento do Ron como o da Lauren e incluir uma lista de seguidores. Quando começarmos a nos aproximar do limite de tamanho do documento, podemos adicionar um novo campo
has_extrasao documento do Ron. (O campo pode ter o nome que quisermos).1 { 2 "_id": 2, 3 "first_name": "Ron", 4 "last_name": "Swandaughter", 5 "cell": "8125559347", 6 "city": "Pawnee", 7 "hobbies": ["woodworking", "fishing"], 8 "jobHistory": [ 9 { 10 "title": "Director", 11 "yearStarted": 2002 12 }, 13 ... 14 ], 15 "followers": [ 16 "Leslie", 17 "Donna", 18 "Tom" 19 ... 20 ], 21 "has_extras": true 22 }
Em seguida, podemos criar um novo documento no qual armazenaremos o restante dos seguidores de Ron.
1 { 2 "_id": 2.1, 3 "followers": [ 4 "Jerry", 5 "Ann", 6 "Ben" 7 ... 8 ], 9 "is_overflow": true 10 }
Se Ron continuar a ganhar mais seguidores, poderíamos criar outro documento de estouro para ele.
O melhor do padrão Outlier é que estamos otimizando para o caso de uso típico, mas temos a flexibilidade de lidar com outliers.
Então, abrace a variedade de documentos. Resista ao impulso de forçar todos os seus documentos a terem estruturas idênticas só porque é o que você sempre fez.
Para obter mais informações sobre os padrões de design de modelagem de dados do MongoDB , consulte Construindo com padrões: um resumo e o curso gratuito da MongoDB University Caminho de modelagem de MongoDBdo MongoDB.
Se você tem experiência com bancos de dados SQL, alguém provavelmente enfiou na sua cabeça que você deve normalizar seus dados. A normalização é considerada boa porque evita a duplicação de dados. Vamos dar um passo para trás e examinar a razão para a normalização do banco de dados.
Quando os bancos de dados relacionais se tornaram populares, o espaço em disco era extremamente caro. Do ponto de vista financeiro, fazia sentido normalizar os dados e economizar espaço em disco. Dê uma olhada no gráfico abaixo que mostra o custo por megabyte ao longo do tempo.
O custo baixou drasticamente. Nossos telefones, tablets, laptops e pen drives têm mais capacidade de armazenamento hoje do que há cinco ou dez anos por uma fração do custo. Quando foi a última vez que você excluiu uma imagem? Não me recordo quando o foi. Eu mantenho até as fotos realmente terrivelmente feias. E atualmente faço backup de todas as minhas fotos em dois discos rígidos externos e vários serviços de nuvem. O armazenamento é tão barato.
O armazenamento se tornou tão barato que vimos uma mudança no custo do desenvolvimento de software. Há trinta ou quarenta anos, o armazenamento era um custo enorme no desenvolvimento de software e os desenvolvedores eram relativamente baratos. Hoje, os custos se inverteram: o armazenamento é um custo pequeno do desenvolvimento de software e os desenvolvedores são caros.
Em vez de otimizar o armazenamento, precisamos otimizar o tempo e a produtividade dos desenvolvedores.
Como desenvolvedor, curto essa mudança. Quero poder me concentrar na implementação da lógica de negócios e iterar rapidamente. Essas são as coisas que importam para os negócios e que impulsionam as carreiras dos desenvolvedores. Não gostaria de ser prejudicado por especificações de armazenamento de dados.
Pense no exemplo da postagem anterior em que codifiquei a recuperação e a atualização das informações de perfil de um usuário. Mesmo nesse exemplo simples, conseguiu escrever menos linhas de código e mover-se mais rapidamente quando usei o MongoDB.
Portanto, otimize seu modelo de dados para a produtividade do desenvolvedor e a otimização de queries. resistir à tentação de normalizar seus dados por normalizar seus dados.
Os dados acessados juntos devem ser armazenados juntos. Se você acabar repetindo dados em seu banco de dados, tudo bem, especialmente se você não atualizará os dados com muita frequência.
Discutimos em uma publicação anterior que o MongoDB suporta transações. A equipe de engenharia do MongoDB fez um trabalho surpreendente na implementação de transações. Eles funcionam tão bem!
Mas aqui está a coisa. Depender de transações é um mau cheiro de design.
Por quê? Isso baseia-se em nossos dois primeiros pontos nesta seção.
Primeiro, nem todos os documentos precisam ter os mesmos campos. Talvez você esteja dividindo os dados entre várias collections porque nem todos têm a mesma estrutura. Se esse for o único motivo pelo qual você separou os dados, provavelmente poderá reuni-los novamente em uma única collection.
Em segundo lugar, os dados acessados juntos devem ser armazenados juntos. Se você estiver seguindo esse princípio, não precisará usar transações. Alguns casos de uso exigem transações. A maioria não. Se você se encontrar usando transações com frequência, dê uma olhada em seu modelo de dados e considere se precisa reestrutura-lo.
Para obter mais informações sobre transações e quando elas devem ser usadas, consulte o whitepaper MongoDB MongoDB Multi-Document ACID Transactions.
Hoje, discutimos as três coisas que você precisa saber ao mudar do SQL para o MongoDB:
Espero que você aproveite o MongoDB! Se você quiser entrar e começar a programar, meus membros de equipe e eu escrevemos Tutoriais de início rápido para várias linguagens de programação. Também recomendamos os cursos gratuitos da MongoDB University.
Em resumo, não seja como Ron. (Quero dizer, não seja como ele neste caso em particular, porque Ron é demais.)
Mude sua mentalidade e aproveite todo o valor do MongoDB.
