Como implantar o MongoDB no Google Compute Engine

Esta solução aborda fatores que precisam ser considerados ao desenvolver, implantar e manter uma implantação do MongoDB, além de descrever maneiras de integrá-la a vários serviços do Google Cloud Platform.

Desenvolver uma arquitetura de implantação do MongoDB

Esta seção apresenta os principais recursos de arquitetura do MongoDB e fornece exemplos de arquiteturas de implantação para o Cloud Platform.

Principais conceitos

Conjuntos de réplicas

O MongoDB é compatível com replicação de dados em vários servidores com a criação de conjuntos de réplicas, que contém os seguintes membros:

  • Uma instância primária única, que contém a cópia principal do conjunto de dados. Ao gravar novos dados no MongoDB, o cliente usa a primária.
  • Uma ou mais instâncias secundárias, que mantêm cópias adicionais do conjunto de dados primários. As secundárias têm consistência eventual com a primária.

A instância primária é selecionada por votação dos membros do conjunto de réplicas. Esses conjuntos precisam ter um número ímpar de membros votantes. Se houver um número par de instâncias, adicione um membro votante mais leve, um árbitro, para ajudar a eleger a primária. Diferentemente das primárias e secundárias, o árbitro é apenas um membro votante e não armazena uma cópia no conjunto de dados.

Configure as secundárias de acordo com o caso de uso específico. As possíveis configurações incluem:

  • Membros com prioridade zero: uma secundária pode ser definida com prioridade 0, de modo que nunca se torne primária. Esse servidor pode ser usado para gerar relatórios ou distribuir uma carga de leitura.
  • Membros ocultos: uma secundária pode ser oculta dos servidores de aplicativo, dedicadas apenas à conexão dos clientes. Ela não pode ser usada para geração de relatórios.
  • Membros com atraso: uma secundária pode ser designada a receber atualizações em intervalos atrasados. Ao retornar o MongoDB a um ponto temporal anterior, ela pode ser usada para corrigir erros de usuários.

Fragmentação

É preciso ter cuidado ao usar secundárias para leituras distribuídas. Como a consistência com a primária é eventual, elas podem entregar resultados desatualizados. No geral, lidar com resultados desatualizados aumenta a complexidade do aplicativo e pode ser impossível para alguns aplicativos. Em vez disso, fragmente os dados nos servidores.

A fragmentação é uma abordagem de particionamento de bancos de dados usada pelo MongoDB para armazenar dados em várias máquinas. Escalonando seus dados horizontalmente em vários servidores, você não é mais limitado pelas capacidades de leitura, gravação e armazenamento de um único servidor. Ao criar fragmentos separados, o MongoDB fornece uma visão estritamente consistente dos dados enquanto distribui a carga de leitura e gravação em vários servidores. Assim, você pode combinar a fragmentação com a replicação para atingir uma capacidade de gravação maior enquanto mantém a alta disponibilidade.

Exemplos de arquiteturas

Replicação pelas regiões

O diagrama a seguir demonstra um conjunto de réplicas do MongoDB que está distribuído em várias regiões do Compute Engine. As setas roxas correspondem ao fluxo de dados replicados para as secundárias a partir da primária do MongoDB. As verdes correspondem ao fluxo de gravações de dados para a primária do MongoDB a partir de servidores de aplicativo e aos fluxos de leituras de dados dos servidores do MongoDB para os clientes.

Um diagrama que ilustra a replicação do MongoDB distribuído entre várias regiões do Compute Engine.

Neste exemplo de arquitetura, as regiões são configuradas da seguinte maneira:

  • Região 1 é o local do Compute Engine em que se encontram os servidores de produção. A maioria do tráfego de usuários finais chega aos servidores do aplicativo por essa região. Por impedir interrupções catastróficas, o servidor primário do MongoDB sempre deve ficar nessa região.
  • Região 2 é a região do Compute Engine geograficamente próxima a uma pequena, mas significativa, porção da base de usuários.

Em cada região, os servidores do MongoDB são configurados com etiquetas de conjuntos de réplicas. Elas permitem que os clientes especifiquem os servidores desejados por função, em vez de por nome.

Na Região 1, a instância primária e as secundárias executam, cada uma, um servidor do MongoDB e são dimensionadas e configuradas de maneira idêntica porque podem ser escolhidas como primárias. A carga de leitura dos servidores de aplicativo de produção sempre vai para o servidor primário do MongoDB nessa região.

Neste exemplo, um árbitro é implantado como membro votante de baixo custo na mesma zona que os outros membros do conjunto de réplicas. Como essa instância não contém dados de conjunto de réplica e não lida com tráfego de usuários finais, ela é configurada sem um disco de dados e usa o tipo de máquina g1-small.

As secundárias na Região 2 são dimensionadas e configuradas de maneira idêntica às instâncias do MongoDB na Região 1 a fim de garantir que possam lidar com o mesmo tamanho de conjuntos de trabalho e carga de aplicativo. Dada a distância geográfica dos servidores de aplicativo de produção, a instância do MongoDB com a etiqueta production nunca deve ser eleita como primária se as instâncias na Região 1 estiverem em bom funcionamento. Ela deve ser configurada com baixa prioridade, para que haja pouca probabilidade de ser selecionada, ou usar prioridade 0, o que impossibilita a seleção.

Os servidores de aplicativo, na Região 2, são configurados para leituras a partir do servidor secundário de produção mais próximo. Essa configuração aumenta a capacidade de resposta dos aplicativos porque as consultas do MongoDB não precisam viajar pelas regiões. No entanto, essa abordagem deve ser realizada com cautela. Como as gravações do MongoDB sempre vão para o servidor primário, o software do servidor do aplicativo neste exemplo precisa ser codificado corretamente para lidar com dados de leitura de consistência eventual.

A secundária marcada como reporting é usada para relatar cargas de trabalho usando aplicativos de geração de relatório dedicados. Essa instância é configurada como membro oculto com prioridade 0 porque apenas aplicativos de geração de relatório se conectam a essa instância.

Fragmentar em várias regiões

O diagrama a seguir demonstra uma arquitetura MongoDB que fragmenta dados em várias regiões do Compute Engine. No diagrama, as setas roxas e azuis correspondem ao fluxo de dados replicados que vão das primárias para as secundárias do MongoDB. As verdes correspondem ao fluxo de gravações de dados para as primárias do MongoDB a partir de servidores de aplicativo e aos fluxos de leituras de dados dos servidores do MongoDB para os clientes.

Um diagrama que representa a fragmentação do MongoDB em várias regiões do Compute Engine.

Neste exemplo de arquitetura, as regiões são configuradas da seguinte maneira:

  • Região 1 é o local do Compute Engine em que se encontram os servidores de produção. A maioria do tráfego de usuários finais chega aos servidores do aplicativo por essa região.
  • Região 2 é um local do Compute Engine geograficamente próximo a uma pequena, mas significativa, porção da base de usuários.

Este exemplo presume que os dados acessados com mais frequência pelos usuários na Região 1 sejam diferentes daqueles acessados pelos usuários da Região 2. Ao criar duas fragmentações e usar etiquetas, a arquitetura garante que os dados sejam armazenados nas duas regiões de acordo com a frequência de acesso.

O MongoDB Query Router cria rotas transparentes de consultas de entrada para os servidores primários apropriados. Como o aplicativo de produção nunca lê dados de um servidor secundário, o aplicativo nunca precisa lidar com a complexidade de leituras desatualizadas e consistência eventual.

A primária e as secundárias executam, cada uma, um servidor do MongoDB e são dimensionadas e configuradas de maneira idêntica porque podem ser escolhidas como primárias para a Fragmentação A. A carga de leitura dos servidores do aplicativo de produção sempre vai para os servidores primários do MongoDB. O tráfego em massa que vem do cliente para o servidor deve ficar na região.

Neste exemplo, um árbitro é implantado como membro votante de baixo custo na mesma zona que os outros membros do conjunto de réplicas. Como essa instância não contém dados de conjunto de réplica e não lida com o tráfego de usuários finais, ela é configurada sem um disco de dados e usa o tipo de máquina g1-small.

A primária, as secundárias e o árbitro na Fragmentação B são configurados de maneira idêntica àqueles da Fragmentação A. Uma secundária adicional é configurada para as duas fragmentações para gerar relatórios de carga de trabalho. Ela é equipada com mais memória do que todas as outras instâncias de produção. Essa instância é configurada como membro oculto com prioridade 0 porque apenas aplicativos de geração de relatórios se conectam a ela.

Como implantar o MongoDB no Google Cloud Platform

Como escolher um tipo de máquina

O Compute Engine oferece várias classes de tipos de máquinas virtuais para executar cargas de trabalho de bancos de dados. Para implantações do MongoDB, os tipos de máquinas padrão fornecem um ótimo equilíbrio entre recursos de memória e CPU, enquanto os tipos de máquina com alta memória são ideais para cargas de trabalho que requerem mais memória relativa às CPUs. O Compute Engine também oferece tipos de máquina personalizadas, o que permite escalonamento independente de recursos de memória ou CPU.

Diferentes aplicativos terão diferentes demandas, mas uma maneira mais econômica de melhorar o desempenho, no geral, é adicionar memória, em vez de adicionar mais núcleos de vCPU. Os servidores do MongoDB têm melhor desempenho quando o acesso ao disco pode ser minimizado. Para fazer isso, dimensione as instâncias do servidor do MongoDB de modo que o conjunto de dados ativo em funcionamento seja mantido na memória.

Se a sua implantação incluir servidores árbitros do MongoDB, pense em usar instâncias g1-small. As instâncias árbitro ficam ociosas na maior parte do tempo, trocando informações de pulsação com outros servidores MongoDB. Elas ficam significantemente ativas somente por um curto período, quando é necessário selecionar uma nova primária. Usar uma instância de núcleo compartilhado, como a g1-small, é uma maneira econômica de reservar ciclos de CPU críticos que não são necessários com grande frequência.

Como configurar discos permanentes

Os discos permanentes oferecem armazenamento consistente em blocos de alto desempenho para instâncias do Compute Engine. O desempenho do disco é ampliado com o tamanho do disco até a capacidade máxima das máquinas virtuais associadas.

Os discos permanentes do Compute Engine estão disponíveis como unidades de disco rígido padrão (HDD, na sigla em inglês) ou unidades de estado sólido (SSD, na sigla em inglês). Os discos permanentes padrão são úteis para cargas de trabalho de leitura/gravação sequenciais, mas não são ideais para cargas de trabalho de leitura/gravação aleatórias. Para implantações do MongoDB, os discos permanentes SSD são a melhor opção porque oferecem a melhor variedade de preços e são compatíveis com altas taxas de operações de entrada e saída por segundo (IOPS, na sigla em inglês) aleatórias.

Os discos do Compute Engine contam com redundância integrada para proteger dados contra falhas e garantir a disponibilidade deles durante eventos de manutenção. Os dados são automaticamente criptografados antes de serem gravados no disco, eliminando a necessidade de criptografar os arquivos antes da gravação.

Ao dimensionar discos para os dados do MongoDB:

  • avalie o tamanho necessário para os dados;
  • verifique se o tamanho do disco fornece o desempenho necessário para gravar dados, arquivos de descrição e registros. Caso contrário, selecione um tamanho maior.

Se os limites de desempenho de disco do seu tipo de máquina do Compute Engine não forem suficientes para suas necessidades, selecione uma instância maior ou fragmente os dados.

Como implementar o MongoDB

Você pode realizar algumas etapas diferentes para implantar o MongoDB no Cloud Platform:

  • O Cloud Marketplace para MongoDB fornece o ponto de entrada mais simples para implantação do MongoDB, permitindo que você implante rapidamente um conjunto de réplicas por meio de uma interface da Web.
  • O MongoDB Cloud Manager oferece suporte a implantações mais complexas que o Cloud Marketplace, como conjuntos de réplicas complexos ou clusters fragmentados. No entanto, é necessário provisionar e configurar suas instâncias do Compute Engine e implantar manualmente os agentes de software.
  • Com o Google Cloud Deployment Manager, é possível automatizar a configuração do MongoDB Cloud Manager, incluindo as etapas de configuração e provisionamento de recursos que teriam de ser feitas manualmente.

Como usar o Cloud Marketplace para MongoDB

Com o Cloud Marketplace, é possível implantar rapidamente pacotes de software funcionais que são executados no Cloud Platform. O serviço permite implantação simples de pacotes de softwares com configurações predeterminadas, sem precisar configurar manualmente o software, as máquinas virtuais, o armazenamento ou as configurações de rede.

O Cloud Marketplace para MongoDB permite implantar rapidamente um conjunto de réplicas com até sete máquinas virtuais, além de simplificar as etapas de configuração inicial.

Por padrão, o Cloud Marketplace implanta um conjunto de réplicas do MongoDB com uma primária, uma secundária e um árbitro, mas você pode alterar a configuração de acordo com as suas necessidades. Além disso, você pode selecionar os tipos de máquina e de disco preferidos com base na configuração desejada. Após a implantação do conjunto de réplicas, atualize a configuração do cluster conforme sua necessidade.

Configurar o MongoDB Cloud Manager

O MongoDB Cloud Manager é um aplicativo Software as a Service (SaaS) hospedado que unifica as tarefas de gerenciamento do MongoDB em uma única interface. O MongoDB Cloud Manager integra a configuração, a otimização de consultas, o monitoramento e os recursos de backup do MongoDB.

Com o MongoDB Cloud Manager, você pode implantar e configurar conjuntos de réplica e clusters fragmentados do MongoDB, além de fazer upgrade ou downgrade de clusters sob demanda. Ele também inclui monitoramento abrangente, que permite a você visualizar mais de cem métricas do MongoDB, bem como alertas personalizados e integração com outras soluções de monitoramento de desempenho de aplicativos. O MongoDB Cloud Manager também oferece uma solução de backup totalmente gerenciada para implantações do MongoDB com backups contínuos e incrementais e recuperações em pontos no tempo.

Para usar o MongoDB Cloud Manager com o Google Cloud Platform:

  1. Crie uma conta do MongoDB Cloud Manager e copie o "mmsGroupId" e "mmsApiKey".
  2. Provisione instâncias do Compute Engine e discos permanentes para o cluster do MongoDB.
  3. Anexe e configure discos permanentes para cada instância do Compute Engine.
  4. Instale e configure o agente de automação do MongoDB Cloud Manager.
  5. Volte para a interface do MongoDB Cloud Manager e conclua a configuração do cluster.

Como executar bootstrapping do MongoDB Cloud Manager usando o Deployment Manager

Como alternativa para a realização manual de todas as etapas em Como configurar o MongoDB Cloud Manager, use os modelos do Cloud Deployment Manager para automatizar o provisionamento e a configuração das instâncias do Compute Engine.

O Deployment Manager permite que você especifique todos os recursos necessários para a implantação do MongoDB em um formato declarativo. Além disso, você pode criar parâmetros para os modelos, o que permite que eles coletem valores de entrada diferentes e os torna mais flexíveis e reutilizáveis. Os modelos do Deployment Manager são organizados em configurações declarativas que comportam as definições de recurso e as propriedades de tempo de execução.

Para implantações usando o MongoDB Cloud Manager, use os modelos de amostra do Deployment Manager disponíveis no GitHub. Esses modelos permitem que você configure e provisione rapidamente várias instâncias do Compute Engine, cada qual com SSD permanente para armazenamento de dados, e instale e configure automaticamente o agente de automação do MongoDB Cloud Manager.

Usar modelos do Deployment Manager para executar bootstrapping do MongoDB Cloud Manager:

  1. Crie uma conta do MongoDB Cloud Manager e copie o "mmsGroupId" e "mmsApiKey".
  2. Clone o repositório GitHub do mongodb-cloud-manager.
  3. Implante a configuração usando os valores copiados anteriormente, conforme descrito no arquivo README do mongodb-cloud-manager.
  4. Volte para a interface do MongoDB Cloud Manager e conclua a configuração do cluster.

Como ajustar a implantação do MongoDB

Para ajustar o desempenho da implantação do MongoDB no Compute Engine, comece com o desempenho do software do MongoDB. Por mais bem configurado que seja, o hardware não compensa um projeto de banco de dados ineficiente ou uma indexação ineficaz ou insuficiente. Consulte Estratégias de otimização do MongoDB para ver dicas e práticas recomendadas.

Após decidir a arquitetura do MongoDB apropriada, otimizada para seu padrão de consultas esperado, tente a sugestão a seguir para otimizar a implantação do MongoDB no Google Compute Engine.

Colocar os arquivos de descrição e de dados do MongoDB no mesmo disco

O MongoDB recomenda separar componentes em diferentes dispositivos de armazenamento. No entanto, os discos permanentes do Compute Engine já gravam dados em um grande número de volumes, eliminando a necessidade de realizar essa etapa manualmente.

Os dados de descrição do MongoDB são pequenos. Se você colocá-los em um disco próprio, acabará criando um disco pequeno, com desempenho de gravação insuficiente, ou um disco grande, que será praticamente inutilizado. Coloque os arquivos de descrição do MongoDB no mesmo disco que seus dados.

Aumentar o número máximo de arquivos abertos

Cada sistema operacional monitora arquivos de disco e conexões de rede abertas, coletivamente considerando-os arquivos abertos. Essa tarefa pode exigir recursos de sistema significativos. Por isso, o sistema operacional impõe limites configuráveis na quantidade de arquivos que podem ser abertos em determinado momento.

Em geral, os limites padrão para arquivos abertos são de poucos milhares. No entanto, um servidor executando o MongoDB muitas vezes precisa manter dezenas de milhares de arquivos abertos. Para aumentar o desempenho, pense em aumentar o número máximo de arquivos abertos para o sistema operacional do host do servidor MongoDB.

Para ver mais informações, consulte Configurações ulimit do UNIX.

Diminuir o tempo de manutenção de atividade do TCP

Os sistemas operacionais têm um mecanismo de pulsação que informa à extremidade de uma conexão de rede se a outra extremidade ainda está conectada. O tempo que uma pode ficar sem saber da outra é conhecido como manutenção de atividade. Quando uma extremidade da conexão não sabe da outra por um período significativo, a conexão será considerada inativa e será apagada.

Um servidor do MongoDB com alta taxa de conexão de entrada pode encontrar um problema em que a pilha de rede mantém conexões inativas por muito tempo. Para evitar esse tipo de situação, diminua o tempo padrão de manutenção de atividade do TCP.

Para mais informações, veja as perguntas frequentes de diagnóstico do MongoDB.

Diminuir os valores de cache de leitura à frente

Quando um aplicativo solicita que parte de um arquivo seja lido no disco, o sistema operacional tipicamente lê mais do que a quantia solicitada e a armazena em cache, suponto que o aplicativo em breve solicitará mais do arquivo. Esse mecanismo é chamado de leitura à frente.

Em geral, o acesso do MongoDB a dados no disco é aleatório, e não sequencial. Isso significa que uma grande leitura à frente pode prejudicar o desempenho, em vez de ajudar, ocupando recursos de memória, CPU e rede com leituras desnecessárias.

Para evitar impactos desnecessários no desempenho, diminua os valores de leitura à frente no volume de dados do MongoDB.

Para mais informações, consulte as notas de produção do MongoDB.

Fragmentar os dados com antecedência

O MongoDB fragmenta os dados enquanto dá continuidade às solicitações de serviço, além de priorizar o processamento do tráfego de usuários finais em relação às solicitações de fragmentação. Dessa forma, não é necessário desativar o banco de dados para a fragmentação.

Porém, a fragmentação não usa recursos de rede, memória e CPU. À medida que o sistema cresce, mais dados precisam ser fragmentados, mas usando menos recursos. Dependendo do tamanho do banco de dados e dos recursos de computação disponíveis no seu cluster, a fragmentação pode levar horas ou dias.

Com o Compute Engine, você pode adicionar novas instâncias de máquinas virtuais conforme necessário. Existem diversas opções de quantidade de CPU e memória para suas implantações. Ao monitorar sua infraestrutura do MongoDB e configurar fragmentações menores em detrimento de maiores, você mantém as implantações sempre ágeis e fica sempre a par dos recursos necessários.

Como manter a implantação do MongoDB

Como fazer upgrade e downgrade de instâncias de máquinas virtuais

Os discos permanentes do Compute Engine são independentes das instâncias às quais estão anexados, o que significa que você pode excluir uma instância de máquina virtual sem excluir os discos permanentes associados e iniciar uma nova instância com os mesmos discos posteriormente. Neste processo, o tipo de máquina virtual da nova instância não precisa ser igual ao da original. Assim, você pode fazer upgrade e downgrade do hardware com rapidez e facilidade.

A capacidade de alterar rapidamente o tipo de máquina virtual, juntamente com a replicação do MongoDB, permite que você altere com facilidade o tipo de máquina virtual de um conjunto de réplicas inteiro com um impacto mínimo no tráfego de produção. Considere a seguinte sequência de operações:

Para cada servidor secundário:

  1. Exclua a instância do servidor, certificando-se de manter os discos anexados.
  2. Inicie uma nova instância de servidor com os seguintes atributos:

    • novo tipo de máquina virtual
    • mesmo nome, discos, rede, tag etc.

Quando a replicação para as instâncias secundárias estiver concluída, realize as seguintes tarefas:

  1. Exclua a instância de servidor primária, certificando-e de manter os discos anexados.
  2. Inicie uma nova instância de servidor com os seguintes atributos:

    • novo tipo de máquina virtual
    • mesmo nome, discos, rede, tag etc.

Quando o servidor primário é excluído, o conjunto de réplicas escolhe um novo servidor primário dentre os secundários cujo hardware já tenha passado por upgrade ou downgrade. Depois que o servidor primário original for reiniciado, ele se juntará ao conjunto de réplicas como um secundário.

Quando um servidor MongoDB for reiniciado, os dados não ficarão inicialmente na memória e serão carregados a ela sob demanda. O carregamento inicial pode afetar significativamente o desempenho. Ao fazer upgrade ou downgrade das instâncias da máquina virtual usando os métodos descritos nesta seção, use o comando touch para trazer explicitamente os dados do armazenamento para a memória. Essa ação melhora a inicialização da instância secundária e reduz a quantidade de tempo necessário para concluir o processo de manutenção.

Como recuperar após fragmentação tardia

Conforme discutido na seção Fragmentar os dados com antecedência, esperar muito tempo para fragmentar os dados pode criar um problema real para um cluster de produção. Porém, se você se deparar com essa situação, ainda poderá concluir a fragmentação sem impactar o tráfego de produção.

Se os servidores do MongoDB ainda não estiverem funcionando nas maiores instâncias do Compute Engine disponíveis, tente as seguintes etapas:

  1. Faça upgrade das máquinas virtuais no conjunto de réplicas. Por exemplo, se as instâncias estiverem vinculadas à CPU, faça o upgrade delas, do tipo de máquina n1-standard-4 para n1-standard-8. Se estiverem vinculadas à memória, faça upgrade de n1-standard-4 para n1-highmem-4.
  2. Crie um novo conjunto de réplicas e configure o MongoDB para fragmentá-lo.
  3. Faça o downgrade do hardware para o conjunto de réplicas original após a fragmentação estar concluída.

Presumindo que fazer upgrade das suas máquinas alivie a escassez imediata de recursos, poderá ser possível fazer a fragmentação com impacto limitado no tráfego de produção.

Como integrar o MongoDB aos serviços do Cloud Platform

Como integrar ao Cloud Storage

É fácil exportar seus dados do MongoDB para o Google Cloud Storage, que oferece armazenamento de objetos durável e altamente disponível. O Cloud Storage oferece várias classes de armazenamento para abranger uma grande variedade de casos de uso:

  • Multirregional oferece o mais alto nível de disponibilidade e desempenho, além de redundância geográfica em mais de duas regiões.
  • Regional fornece os mesmos benefícios da opção Multirregional, mas com custo menor e armazenamento de dados em apenas uma região.
  • Nearline oferece uma opção de armazenamento altamente durável e de baixo custo, ideal para dados que costumam ser acessados menos de uma vez por mês.
  • Coldline é a opção com menor custo para arquivamento, backup e recuperação de desastres, e apresenta a mesma durabilidade de todas as classes do Cloud Storage.

Para backup e arquivamento, use as opções Padrão e Nearline, respectivamente, exportando dados localmente a partir de uma secundária do MongoDB, usando mongodump. Depois, envie os dados para o Cloud Storage. Para mais informações, consulte a documentação Fazer backup e restaurar com as ferramentas do MongoDB.

Para análises, use a opção "Padrão". Exporte os dados localmente de uma instância secundária do MongoDB com mongoexport como JSON ou CSV e faça upload dos arquivos simples no Cloud Storage. Depois de enviar os dados exportados, use-os com diversas ferramentas do Google Platform, incluindo BigQuery, Cloud Dataflow e Cloud Dataproc.

Como integrar ao BigQuery

O BigQuery é um armazém de dados totalmente gerenciável que suporta escalabilidade a até petabytes, ideal para análises de grandes volumes de dados. Você pode importar dados exportados do MongoDB em JSON ou CSV e combiná-los com outras fontes de dados para gerar análises e relatórios ad-hoc. O BigQuery tem suporte nativo a JSON, o que significa que os documentos do MongoDB com objetos aninhados podem ser armazenados e enfileirados usando um SQL padrão.

Como integrar ao Cloud Dataflow

O Cloud Dataflow é um modelo de programação unificado e um serviço gerenciado para desenvolvimento e execução de uma grande variedade de padrões de processamento de dados. Com o Cloud Dataflow, você pode criar pipelines de processamento de dados de computação em lote ou ETL e executá-los usando um serviço totalmente gerenciável que provisiona recursos dinamicamente à medida que são necessários. O modelo de programação Cloud Dataflow suporta muitas transformações de dados integrados, como agregações estatísticas/matemáticas e algoritmos no estilo no estilo Mapear/Redistribuir/Reduzir, como agrupar e participar. O modelo de programação também é compatível com transformações personalizadas e compostas para tarefas de processamento de dados mais complexas. Os pipelines do Cloud Dataflow leem dados de entrada a partir do Cloud Storage e geram dados processados de volta ao Cloud Storage ou diretamente ao BigQuery ou Cloud Bigtable.

Como integrar ao Cloud Dataproc

Para cargas de trabalho Hadoop e Spark, o Cloud Dataproc oferece a capacidade de implantar rapidamente clusters, redimensioná-los a qualquer momento e excluí-los assim que o processamento é concluído. Você pode lançar clusters Hadoop e Spark em 90 segundos. Se o seu job requer menos de 24 horas de tempo de processamento, você também pode usar máquinas virtuais preemptivas do Compute Engine nos clusters para minimizar custos. Jobs Hadoop e Spark podem ler dados exportados do MongoDB a partir do Cloud Storage (BSON, JSON ou CSV) ou a partir de implantações do MongoDB em execução diretamente a partir do MongoDB Connector para Hadoop.

Próximas etapas

Conheça outros recursos do Google Cloud Platform para seu uso. Veja nossos tutoriais.

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…