Pesquisa do Podcast do MongoDB com a equipe de conectores e tradutores
Avalie esse Podcast
O connectorBI Connector e o mongomirror são apenas dois exemplos de produtos MongoDB poderosos, mas menos populares. Esses produtos são mantidos por uma equipe no MongoDB conhecida como equipe de Engenharia de Conectores e Translatores. Nesta transcrição de capítulo de podcast, conversamos com Tim Fogarty, Varsha Subraymanyam e Evgeni Dobranova. A equipe nos fornece uma compreensão melhor dessas ferramentas, concentrando-se especificamente no BI Connector e no mongomirror.
Este capítulo do Podcast do MongoDB está disponível no Youtube se você preferir ouvir.
michael lynn (01:58): Tudo bem, bem-vindo de volta. Atualmente, estamos falando de conectores e tradutores, e você pode estar considerando: "espere um minuto. O que é um connector e o que é um tradutor?" Nós vamos chegar a isso. Mas antes, gostaria de apresentar as pessoas que estão se juntando a nós no podcast hoje. Varsha, você se apresentaria?
Varsha Subraymanyam (02:19): Sim. Olá, meu nome é Varsha Subraymanyam. Trabalho como engenhora de software na equipe de tradutores e conectores. Eu me formei na University of Illinois at Urbana-Champagne em 2019 e era estagiário no MongoDB pouco antes da formatura. E retornei em tempo integral no verão seguinte. Então, estou aqui há um ano e meio. [inaudível 00:02:43]
Michael Lynn (02:43): Evgeni?
Evgeni Dobranova (02:44): Sim. Olá. Meu nome é Evgeni Dobranova. Estou mais ou menos ao lado de Varsha. Interagimos juntos em 2018. Nós dois fizemos nossas rotações há cerca de um ano e acabamos trabalhando juntos em connector e tradutores. Eu frequentei a Tufts University e me formei em 2019.
michael lynn (03:02): e tim, bem-vindo.
Tim Fogarty (03:04): Ei, Mike. Então, meu nome é Tim Fogarty. Também sou engenheiro de software na equipe de conectores e tradutores. Na verdade, trabalhei para o MBLab, o serviço de hospedagem do MongoDB, que foi adquirido pelo MongoDB há cerca de dois anos. Então, eu estava trabalhando lá antes do MongoDB e agora estou trabalhando na equipe de conectores e tradutores.
michael lynn (03:25): fantástico. E Nic, quem é você ??
Nic Raboy (03:27): Eu sou Nic e sou o co-apresentador de Mike deste fabuloso podcast e da equipe de relações com desenvolvedores do MongoDB.
michael lynn (03:33): conectores e tradutores. É um tópico tentador. Estávamos conversando antes de começarmos a gravar e eu fiz a suposição incorreta de que os conectores e tradutores são um pouco ignorados e talvez nem apareçam na primeira página, mas não é esse o caso. Então, Tim, será que eu poderia pedir que você explicasse o que são conectores e tradutores? De que tipo de software estamos falando?
Tim Fogarty (03:55): Sim, então nossa equipe trabalha essencialmente em três grupos de software diferentes. Temos o connector BI Connector ou o de business intelligence connector, que é usado essencialmente para traduzir SQL comandos em MongoDB comandos do para que você possa usá-lo com ferramentas como Tableau ou PowerBI, esses tipos de business intelligence ferramentas de .
Tim Fogarty (04:20): Também temos as ferramentas de banco de dados, que são usadas para importar e exportar dados, criar backups na linha de comando e também o mongomirror, que é usado internamente para a função Atlas Live Migrates. Assim, você pode migrar um MongoDB database para um serviço de cloud de aplicativos MongoDB.
Tim Fogarty (04:39): Os conectores e tradutores, é um nome um pouco confuso. E também temos outros produtos chamados conectores. Então, temos o Kafka Connector e o Spark Connector e, na verdade, não estamos trabalhando com eles. É um nome um pouco desajeitado, mas, essencialmente, estamos lidando com restaurações de backups, migrações e tradução do SQL.
Michael Lynn (04:58): Você mencionou o BI Connector e o Tableau e a capacidade de usar SQL com MongoDB. Podemos dar um passo para trás e escrever sobre por que alguém pode querer usar um connector, seja ele de BI ou outro com o MongoDB?
Varsha Subraymanyam (05:16): Sim. Então posso falar um pouco sobre isso. Talvez queiramos usar o BI Connector para pessoas que usam ferramentas de business intelligence, elas são baseadas principalmente em SQL. E, por isso, queremos que as pessoas usem a linguagem de query do MongoDB. Então, nós realmente tinhamos esse mecanismo de tradução que conecta ferramentas de business intelligence ao back-end do MongoDB. Portanto, o BI Connector recebeu SQL. E, em seguida, o BI Connector os traduz para SQL, para a linguagem de agregação MongoDB. E, em seguida, consulta o MongoDB e depois retorna o resultado. Portanto, é muito fácil armazenar seus dados no MongoDB sem saber como consultar o banco de dados com o MQL.
michael lynn (06:03): Isso é em tempo real? Existe um atraso ou um atraso?
Varsha Subraymanyam (06:06): Talvez Evgeni possa falar um pouco sobre isso? Acredito que a maior parte disso acontece na memória. Portanto, é muito, muito rápido e podemos processar, considero que neste ponto 100% de todas as queries SQL, se não estiver muito próximo disso. Mas é muito, muito rápido.
michael lynn (06:22): talvez eu tenha uma infraestrutura implantada em que esteja aproveitando uma ferramenta de BI e queira usar os dados ou um aplicativo que aproveite o MongoDB no back-end. Isso soa como um caso usado popular. Estou interessado em saber como isso faz. É apenas uma tradução direta dos comandos SQL e dos operadores que nos chegam do SQL?
"Então, se você já ouviu falar de transpiladores, eles traduzem o código de uma linguagem de nível superior para outra. Os compiladores regulares traduzem o código de alto nível para o código de nível inferior, algo como montagem, mas o BI Connector age como um transpilers ao traduzir do SQL para a linguagem de query do MongoDB."" -- Varsha Subraymanyam no BI Connector
Varsha Subrahmanyam (06:47): Então, se você já ouviu falar de transpiladores, eles traduzem o código de uma linguagem de nível superior para outra. Compiladores regulares traduzirão código de alto nível para código de nível inferior, algo como assembly, mas o BI Connector funciona como um transpilador, traduzindo do SQL para a linguagem de consulta MongoDB. E há várias etapas para um compilador tradicional. Há o front-end que principalmente verifica a query SQL de uma perspectiva semântica e sintática.
Varsha Subrahmanyam (07:19): Então, mais ou menos, essa consulta faz sentido, dado o contexto da própria linguagem e, de forma mais granular, o banco de dados em questão. E então há mais duas etapas. Há o meio e o backend. Basicamente, logo após verificar se a consulta é aceitável, eles realmente entrarão no processo de tradução.
Varsha Subrahmanyam (07:40): Basicamente, a partir do segmento de análise sintática do compilador, produzimos essa árvore de análise que basicamente pega todos os tokens, constrói a árvore a partir deles usando a gramática do SQL e, com base nisso, iniciaremos o processo de tradução. E há algo chamado push-down. Evgeni, se você quiser falar sobre isso.
Evgeni Dobranov (08:03): Sim, na verdade não fiz ou trabalhei com nenhum código que faça push-down especificamente, infelizmente.
Varsha Subraymanyam (08:09): Posso falar sobre isso.
Evgeni Dobranova (08:13): Sim. Pode ser melhor para você.
Varsha Subraymanyam (08:13): Sim. No push-down, nós temos essa árvore de análise e, a partir dela, construímos algo chamado plano de query, que essencialmente cria estágios para cada parte da query SQL. E os estágios são nossa representação interna do que esses tokens significam. Então construímos como um plano linear, e isso nos leva a algo chamado push-down.
Varsha Subrahmanyam (08:42): Então, basicamente, digamos que você tenha, suponho, como uma consulta SELECT normal. O SELECT será então um estágio em nossa representação intermediária da query. E isso lentamente traduzirá um único token para o equivalente no MQL. E vamos fazer isso de uma forma mais linear, e isso lentamente gerará a representação MQL da query.
michael lynn (09:05): agora, há diferenças na forma como os dados são representados entre um banco de dados relacional ou tabular e na maneira como o MongoDB os representa no documento. Acho que, por meio do push-down e da tokenização, você consegue determinar quando chega uma instrução SQL que está fazendo referência ao que seriam colunas se houvesse um tradutor que fizesse esse campo de referência.
Varsha Subraymanyam (09:31): À direita, à direita. Portanto, temos formas semelhantes de traduzir coisas do modelo relacional para o document model.
Tim Fogarty (09:39): Então, precisamos testar ou definir um esquema específico para a collection principal para que pareça uma tabela com colunas. Mike, talvez você possa falar um pouco mais sobre isso.
michael lynn (09:55): Sim. Então, há um requisito de usar o BI Connector para normalizar seus dados ou fornecer algum tipo de dica sobre como você está representando os dados?
Varsha Subraymanyam (10:06): Com isso não estou muito familiarizado.
Nic Raboy (10:10): Como você desenvolve um connector desses? Que tipo de tecnologias você está usando? Você também está usando algum dos drivers do MongoDB no processo?
Varsha Subraymanyam (10:18): Eu reconheço que para o Connector BI, grande parte do código foi emprestada da lógica de análise existente. E então está tudo escrito em Go. Tudo em nossa equipe é escrito em Go. Faz um tempo que não participo deste recode, então não estou muito certo sobre tecnologias específicas que são usadas. Não sabe se você se lembra, Evgeni.
Evgeni Dobranova (10:40): Bem,acho que a maior coisa é o Mongo AST, a árvore de sintaxe abstrata, que também tem tanto em Go quanto esse tipo de coisa, acha que o que Varsha aludiu anteriormente era como o grande estágio intermediário que ajuda a traduzir queries SQL para queries Mongo, representando coisas como fazer uma aula de linguagem de programação na Universidade. Ele meio que representa coisas como nós em uma árvore e mais ou menos como relata o quão diferentes são os nomes dos verbos e coisas assim em um sentido mais temporal.
michael lynn (11:11): o BI Connector é open source? As pessoas podem dar uma olhada no código-fonte para ver como funciona?
Evgeni Dobranova (11:16): Não é, até onde eu saiba, não.
Michael Lynn (11:19): Esse é o BI Connector. Tenho certeza de que há outros conectores em que você trabalha. Vamos falar um pouco sobre os outros conectores nos quais vocês trabalham.
Nic Raboy (11:26): Sim. Talvez qual seja o mais interessante. Quais são seus favoritos? MEAN, provavelmente todos vocês estão trabalhando em um separadamente, mas existe um que seja comumente interessante e comumente benéfico para os clientes do MongoDB?
Evgeni Dobranov (11:39): Bem, o que eu trabalhei mais recentemente, pessoalmente, pelo menos, foi o mongomirror e eu realmente passei a gostar um pouco só porque acho que tem muitos componentes muito legais. Então, apenas para atualizar, o mongomirror é a ferramenta que usamos ou a principal ferramenta que o Atlas usa para ajudar os clientes na migração live. Portanto, o que isso os ajuda a fazer é que eles poderiam estar apenas executando um banco de dados, recebendo gravações e leituras e coisas do gênero. E então, sem necessariamente desligar o banco de dados, eles podem migrar para uma versão mais recente do Mongo. Talvez apenas clusters maiores, coisas assim, todos usando mongomirror.
Evgeni Dobranov (12:16): E o mongomirror tem alguns estágios que ele faz para ajudar na migração. Ele faz como uma sincronização inicial ou apenas copia os dados existentes tanto quanto pode. E então também registros. Ele também registra as operações que chegam e as coloca no oplog, que é essencialmente outra collection de todas as operações que estão sendo feitas no banco de dados enquanto a sincronização inicial está ocorrendo. E então reproduz esses dados em cima do seu destino, o que você está migrando
Evgeni Dobranova (12:46): Portanto, há muitos malabarismos, principalmente com operações e cópia de dados, coisas assim. Acho que é um sistema muito robusto que parece funcionar bem na maioria das vezes. É um software muito bem projetado.
Nic Raboy (13:02): Também queria comentar sobre isso. Portanto, este é um plug-in para o evento que tivemos recentemente, chamado MongoDB Live, para um de nossos eventos locais na América do Norte. Na verdade, eu assisti a algumas sessões e havia histórias de migração de clientes em que eles realmente usaram o mongomirror para migrar de soluções locais para o MongoDB Atlas. parece que é a ferramenta número um para fazer esse trabalho. Esse é um cenário comum que você também já encontrou? As pessoas também o estão usando para outros tipos de migrações? Como talvez o Atlas, talvez o AWS para o GCP, embora tenhamos várias nuvens agora, ou é principalmente no prem para o tipo de migrações do Atlas?
Evgeni Dobranov (13:43): Trabalhamos mais na manutenção do software em si, tendo atendido a solicitação dos recursos da equipe do Atlas. Acho que as pessoas que saberiam exatamente esses detalhes seriam os TSEs, os engenheiros de serviços técnicos, que trabalham com os clientes reais, e eles recebem mais informações sobre exatamente que tipo de migração está acontecendo, seja do banco de dados privado ou do Mongo Atlas ou do privado para o privado, coisas assim. Mas eu sei com certeza que você tem todas as combinações de migrações. O Mongomirror não está limitado a um único tipo. Tim pode expandir mais sobre isso com certeza.
Tim Fogarty (14:18): Sim. Digo que, sem dúvidas, a migração do on-prem para o Atlas é o principal caso de uso que vemos que, na verdade, é o único caso de uso técnico oficialmente suportado. Portanto, há clientes que estão fazendo outras coisas, como migrar de local para local ou de uma cloud para outra cloud. Então isso definitivamente acontece. Mas, de longe, o maior caso de uso é a migração para o Atlas. E esse é o único caso de uso que testamos e apoiamos oficialmente.
Nic Raboy (14:49): Na verdade, também gostaria de me afundar no mongomirror. MEAN, quantos dados você pode mover com ele em um determinado momento? Você normalmente usa um cluster desses mongomirrors em paralelo para mover quantos terabytes você puder ter em seu cluster? Ou talvez Go em detalhes mais sutis sobre como isso funciona?
Tim Fogarty (15:09): Sim, isso seria legal, mas seria muito mais difícil. Então, geralmente só giramos uma máquina mongomirror. Portanto, se tivermos um cluster de origem local e nosso cluster de destino, que é o MongoDB Atlas, ativamos uma máquina hospedada por nós ou você mesmo pode executar o MongoDB no local, se quiser, se houver, digamos, problemas de firewall, e às vezes facilitamos um pouco as coisas.
Tim Fogarty (15:35): Mas um único processo e depois a própria pessoa fica paralisada. Assim, durante o estágio de sincronização inicial que Evgeni mencionou, ele copiará todos os dados de cada collection em paralelo e, em seguida, começará a criar índices em paralelos também. Você pode migrar terabytes de dados, mas isso pode levar muito tempo. Pode ser um processo longo. Com certeza já vimos clientes que, se tiverem conjuntos de dados muito grandes, podem levar semanas para migrar. E, particularmente, a fase de criação do índice leva muito tempo porque é apenas uma computação muito intensiva, como centenas de milhares de índices em um conjunto de dados muito grande.
"Mas, quando a sincronização inicial terminar, estamos apenas no negócio de replicar todas as alterações que acontecem no banco de dados de origem para o cluster de destino." -- Tim Fogarty sobre o processo mongomirror de migração de dados de um cluster para outro.
Tim Fogarty (16:18): Mas, uma vez que a sincronização inicial termina, estamos apenas no negócio de replicar todas as alterações que acontecem no banco de dados de origem para o cluster de destino.
Nic Raboy (16:28): Então, quando você diz mudanças que aconteceram no banco de dados de origem, você está falando sobre mudanças que podem ter ocorrido enquanto a migração estava acontecendo?
Tim Fogarty (16:35): Exatamente.
Nic Raboy (16:36): Ou algo mais?
Tim Fogarty (16:38): Enquanto a sincronização inicial acontece, armazenamos todas as alterações que aconteceram no destino de origem em um arquivo. Então, essencialmente, apenas os salvamos no disco, prontos para reproduzi-los quando terminarmos a sincronização inicial. Então, uma vez que a sincronização inicial termine, reproduzimos tudo o que aconteceu durante a sincronização inicial e, em seguida, tudo de novo que chega, também passamos a reproduzi-lo quando isso for feito. Portanto, mantemos os dois clusters sincronizados até que o usuário esteja pronto para transferir o aplicativo dali para o banco de dados de origem para o novo cluster de destino.
Nic Raboy (17:12): Quando copia os dados, está usando os mesmos IDs de objeto do banco de dados de origem ou está criando novos documentos no banco de dados de destino?
Tim Fogarty (17:23): Sim. Os IDs dos objetos são os mesmos, considero. E isso é um tipo de requisito porque, no oplog, ele diz como: "Ah, este documento com esse ID de objeto, precisamos atualizá-lo ou alterá-lo dessa forma." Portanto, quando precisarmos reaplicar essas alterações no tipo de cluster de destino, precisaremos garantir que, obviamente, o ID do objeto corresponda ao documento correto quando precisarmos reaplicar essas alterações.
michael lynn (17:50): Ok. Portanto, há duas fontes de dados usadas em uma execução de mongomirror. Há o banco de dados, o próprio banco de dados de origem, e parece que o mongomirror está fazendo, não sabe, uma busca padrão para obter todos os documentos de lá, transmitindo-os para o novo sistema de destino e aproveitando uma referência de ID explícita então que os documentos inseridos tenham o mesmo ID de objeto. E durante esse tempo, isso vai demorar um pouco, isso é física, pessoal. Vai demorar um pouco para movê-los por toda parte, dependendo do tamanho do banco de dados.
michael lynn (18:26): estou assumindo que há um mercado no oplog ou pelo menos no carimbo de data/hora do, a hora em que a execução do mongomirror começou. E então, tudo entre esse momento e a conclusão da sincronização inicial é capturado no oplog, e essas transações no oplog são usadas para recriar as transações que ocorreram no banco de dados de destino.
Tim Fogarty (18:48): Sim, essencialmente correto. Uma coisa é que a fase de sincronização inicial pode levar muito tempo. Portanto, é possível que o seu oplog, como o oplog é uma cap collection, o que significa que ele só pode ter um determinado tamanho finito. Assim, eventualmente, as entradas mais antigas começam a ser excluídas quando não são usadas. Assim que iniciarmos a sincronização inicial, começaremos a ouvir o oplog e a salvá-lo no disco em que temos as informações salvas. Então, se começarmos a excluir coisas na parte de trás do oplog, não nos perderemos essencialmente.
michael lynn (19:19): ótimo. Então, suponha que uma palavra de cautela seria garantir que você tenha espaço em disco suficiente disponível para executar.
Tim Fogarty (19:26): Sim, exatamente.
michael lynn (19:29): Isso é mongomirror. Isso é ótimo. E eu queria esclarecer, mongomirror, parece que está disponível no console do MongoDB Atlas, certo? Porque vamos executar isso no console, mas também parece que você disse que pode estar disponível para o local. É um download? É uma linha de comando executável?
Tim Fogarty (19:47): Sim. Então, em geral, se você deseja migrar para o Atlas, deve usar o serviço Atlas Live Migrate . Então isso está disponível no console Atlas. É como clicar e configurá-lo, e essa é a maneira mais fácil de usá-lo. Há alguns casos em que, por algum motivo, talvez seja necessário executar o mongomirror localmente, caso em que você pode baixar os binários e executá-lo localmente. Esses são casos raros. Acho que esse é um assunto sobre o qual você deve conversar com o suporte se estiver preocupado com a possibilidade de trabalhar localmente.
Nic RaBoy (20:21): Então, em relação aos conectores como o mongomirror, há algo que você fez recentemente em relação ao produto ou algo que esteja chegando em breve no roteiro?
Evgeni Dobranov (20:29): Então Varsha e eu acabamos de terminar um grande épico no Jira, que melhora os relatórios de status. E basicamente isso foi como uma enorme coleção de ingressos que os clientes nos procuraram ao longo do tempo, basicamente apenas dizendo: "Gostaríamos que houvesse um status melhor aqui. Gostaríamos que houvesse um registro melhor ou que os registros nos dessem uma ideia melhor do que estava acontecendo internamente no mongomirror. Então, nós praticamente passamos cerca de um mês, e Varsha gastou um pouco de tempo recentemente em um ticket do qual ela pode falar. Acabamos de passar muito tempo melhorando as mensagens de erro e revelando informações que anteriormente não eram revelados para ajudar os usuários a ter uma ideia melhor do que está rolando no interno do mongomirror.
Varsha Subraymanyam (21:12): Sim. O ticket que acabei de concluir, mas no qual estava trabalhando há algum tempo, era fornecer um melhor registro durante o processo de construção do índice, que acontece durante a sincronização inicial e novamente durante toda a sincronização do oplog. Agora, os usuários poderão obter registros em um nível de coleção, informando qual porcentagem de índices foi criada em uma coleção específica, bem como em cada host em seu conjunto de réplicas. E também se eles quisessem rolar essas informações do servidor HTTP, também poderiam fazer isso.
Varsha Subraymanyam (21:48): Então, essa é uma adição interessante, eu considero. E agora também estou habilitando esses registros na parte de sincronização de oplog do mongomirror, que é bem semelhante, mas provavelmente teremos um pouco menos de informações só porque estamos tentando descobrir quais índices precisam ser construídos de forma contínua base porque estamos apenas adaptando o oplog e vendo o que aparece. Então, pela natureza disso, há um pouco menos de informações sobre quantos índices você pode esperar que sejam construídos. Você não sabe exatamente desde o início, mas sim, esse será uma grande ajuda para as pessoas que não têm certeza se seus índices estão parados ou se estão apenas demorando muito para criar.
michael lynn (22:30): Bem, algumas atualizações fantásticos. Quero devolver a todos por passar por aqui. Eu sei que temos todo um conjunto de conteúdo que eu queria abordar em torno das ferramentas em que você trabalha. Mongoimport, Mongoexport, Mongorestore, Mongodump. Mas acha que gostaria de dar a isso o tempo que ele vale. Essa pode ser uma discussão muito saudável. Então, meio que gostaria de fazer com que voltassem. Isso parece bom?
Varsha Subraymanyam (22:55): Sim.
Tim Fogarty (22:56): Sim.
Varsha Subraymanyam (22:56): parece bom.
Evgeni Dobranova (22:56): Sim. Parece ótimo.
Michael Lynn (22:57): Bem, mais uma vez, quero lhe agradecer muito. Há mais alguma coisa que você queira que o público saiba antes de Go? Como eles podem entrar em contato com você? Você está nas redes sociais, LinkedIn, Twitter? Este é um momento para se conectar.
Varsha Subrahmanyam (23:09): Você pode me encontrar no LinkedIn.
Tim Fogarty (23:12): Estou tentando ficar longe das mídias sociais recentemente.
Nic Raboy (23:15): Não há problema.
Tim Fogarty (23:16): Não, por favor, não entre em contato comigo.
michael lynn (23:19): Entendo. Eu entendo.
Tim Fogarty (23:21): Você pode entrar em contato comigo, eu lhe direi onde, nos fóruns da comunidade.
michael lynn (23:25): Go. Ideal.
Tim Fogarty (23:27): Se você tiver perguntas-
michael lynn (23:28): ótimo.
Tim Fogarty (23:29): se você tiver dúvidas sobre as ferramentas do banco de dados, pode fazer perguntas lá e provavelmente eu as verei.
michael lynn (23:34): Tudo bem. Então , community.mongodb.com. Estaremos todos lá. Se você tiver perguntas, pode passar por lá e fazê-las neste fórum. Bem, obrigado mais uma vez a todos. Tim Fogarty, Varsha Subraymanyam e Evgeni Dobranova.
Evgeni Dobranovo (23:47): Sim, você conseguiu.
michael lynn (23:48): Tudo bem. Então, muito obrigado por passar por aqui. Tenha um ótimo dia.
Varsha Subraymanyam (23:52):Obrigado.
Esperem que tenham aproveitado este capítulo do Podcast do MongoDBe tenham aprender um pouco mais sobre os Conectores e Tradutores do MongoDB, incluindo o Connector for Business Intelligence e o mongomirror. Se você leu este capítulo, considere fazer uma revisão em suas redes de podcast favoritas, incluindo Apple, Googlee Swift.
Para obter mais informações sobre o MongoDB Connector for BI, visite nossos Docs ou páginasde produtos.
Avalie esse Podcast