Como arquivar dados no armazenamento de objetos em nuvem com o MongoDB Online Archive
Maxime Beugnet9 min read • Published Feb 07, 2022 • Updated Sep 09, 2024
Avalie esse Tutorial
O MongoDB Atlas Online Archive é um novo recurso da MongoDB Cloud Data Platform. Ele permite que você defina uma regra para arquivar automaticamente dados do seu Atlas cluster em um armazenamento de objetos na nuvem totalmente gerenciado. Nesta postagem do blog, demonstrarei como você pode usar o Online Archive para definir seus dados de camada para uma estratégia de gerenciamento de dados econômicas.
A plataforma de dados MongoDB Cloud com Atlas Data Federation fornece uma Instância de Banco de Dados Federada sem servidor e escalável que permite executar query nativa de seus dados no armazenamento de objetos na nuvem e nos clusters do MongoDB Atlas no local.
Nesta postagem do blog, usarei uma das coleções de séries temporais do MongoDB Open Data COVID-19 para demonstrar como você pode combinar o Online Archive e o Atlas Data Federation para economizar nos custos de armazenamento e, ao mesmo tempo, manter o acesso fácil para consultar todos os seus dados.
Para este tutorial, você precisará de:
- um clusterdo MongoDB Atlas M10 ou superior, pois o Online Archive não está disponível no momento para os níveis compartilhados,
Para começar, vamos recuperar uma coleção de séries temporais. Para este tutorial, usarei uma das coleções de séries temporais que criei para o projeto MongoDB Open DataCOVID19 .
A collection
covid19.global_and_us é a série temporal COVID-19 mais completa em nosso cluster de dados aberto, pois combina todos os dados que a JHU mantém em CSV separados.Como gostaria de recuperar a coleção inteira e seus índices, usarei
mongodump.1 mongodump --uri="mongodb+srv://readonly:readonly@covid-19.hip2i.mongodb.net/covid19" --collection='global_and_us'
Isso criará uma pasta
dump no seu diretório atual. Vamos agora importar essa coleção em nosso cluster.1 mongorestore --uri="mongodb+srv://<USER>:<PASSWORD@clustername.1a2bc.mongodb.net"
Agora que nossa coleção de séries temporais está aqui, vamos ver como é um documento:
1 { 2 "_id": { 3 "$oid": "5f077868c3bda701aca1a3a7" 4 }, 5 "uid": 175, 6 "country_iso2": "YT", 7 "country_iso3": "MYT", 8 "country_code": 175, 9 "state": "Mayotte", 10 "country": "France", 11 "combined_name": "Mayotte, France", 12 "population": 272813, 13 "loc": { 14 "type": "Point", 15 "coordinates": [ 16 45.1662, 17 -12.8275 18 ] 19 }, 20 "date": { 21 "$date": "2020-06-03T00:00:00.000Z" 22 }, 23 "confirmed": 1993, 24 "deaths": 24, 25 "recovered": 1523 26 }
Essa coleção de séries temporais é bastante simples. Para cada dia e cada lugar, temos uma medida do número de
confirmed, deaths e recovered, se estiver disponível. Mais detalhes em nossa documentação.O problema é que é uma série temporal! Então, a cada dia, adicionamos uma nova entrada para cada lugar do mundo e nossa coleção ficará cada vez maior a cada dia. Mas com o passar do tempo, é provável que os dados mais antigos sejam menos importantes e acessados com menos frequência, portanto podemos nos beneficiar do arquivamento fora do Atlas cluster.
Hoje, de 10julho a 2020, esta collection contém 599760 documentos que correspondem a 3528 locais, hora 170 dias e é apenas 181.5 MB graças ao algoritmo de compressão WiredTiger.
Embora isso não seja realmente um problema com esse exemplo trivial, ele com certeza o forçará a atualizar seu MongoDB Atlas cluster para um nível superior se um GB extra de dados estiver passando em seu cluster a cada dia.
Atualizar para uma camada mais alta custaria mais dinheiro e talvez você não precise manter todos esses dados frios em seu cluster.
Arquivar manualmente um subconjunto desse conjunto de dados é tedioso. Na verdade, escrevi uma postagem no blog sobre isso.
Funciona, mas você mesmo precisará extrair e remover os documentos do cluster do MongoDB Atlas e, em seguida, usar o novo operador $out para gravar seus documentos no armazenamento de objetos na nuvem - Amazon S3 ou Microsoft Azure Blob Storage.
Para sua sorte, o MongoDB Atlas Online Archive faz isso por você automaticamente!
Vamos até MongoDB Atlas e clique em nosso cluster para acessar os detalhes do cluster. Atualmente, o Online Archive não está configurado neste cluster.
Agora vamos clicar em Online Archive e depois em Configure Online Archive.
A próxima página fornecerá algumas informações e documentação sobre o MongoDB Atlas Online Archive e, na próxima etapa, você terá que configurar sua regra de arquivamento.
No nosso caso, será assim:
Como você pode ver, estou usando o campo dedata mencionado acima e, se esse documento tiver mais de 60 dias, ele será movido automaticamente para o meu armazenamento de objetos na nuvem.
Agora, para a próxima etapa, preciso pensar no meu padrão de acesso. Atualmente, estou usando esse conjunto de dados para criar gráficos COVID-19 incríveis.
E a cada vez, primeiro tenho que filtrar por data para reduzir o tamanho do meu gráfico e, opcionalmente, filtro por país e, em seguida, indique se quero ampliar um determinado país ou região.
Como esses campos serão convertidos em nomes de pastas no meu armazenamento de objetos na nuvem, eles precisam existir em todos os documentos. Não é o caso do campo "estado" porque alguns países não têm subdivisões neste conjunto de dados.
Como a data é sempre meu primeiro filtro, eu me certifico de que esteja no topo. As pastas serão nomeadas e organizadas dessa forma no meu armazenamento de objetos na cloud e as pastas que não precisam ser exploradas serão eliminadas automaticamente para acelerar o processo de recuperação de dados.
Por fim, antes de iniciar o processo de arquivamento, há uma etapa final: garantir que o Online Archive possa localizar e remover com eficiência os documentos que precisam ser arquivados.
Eu já tenho alguns índices nessa collection, vamos ver se isso é realmente necessário. Aqui estão os índices atuais:
Como podemos ver, não tenho o índice recomendado. Eu tenho o seu oposto:
{country: 1, date: 1}, mas eles nãosão equivalentes. Vamos ver como essa query se comporta no MongoDB Compass.
Podemos notar várias coisas aqui:
- Estamos usando o índice dedatas . O que é uma boa noticia, pelo menos não é uma varredura de collection!
- A operação de classificação final é
{ date: 1, country: 1} - Nosso índice
{date:1}não contém as informações sobre o país, portanto, uma classificação na memória é necessária. - Aguarde um minuto... Por que tenho 0 documentos devolvidos?!
Tenho 170 dias de dados. Estou filtrando todos os documentos com mais de 60 dias, portanto, devo corresponder a
3528 places * 111 days = 391608 documentos.111 dias (não 170-60=110) porque somos 10julho quando estou escrevendo isto e ainda não tenho os dados de hoje.
Quando verifico a saída json bruta no Compass, vejo que ocorreu um erro.
Tristemente, ele foi cortado. Vamos executar isso novamente no novo mongosh para ver o erro completo:
1 errorMessage: 'Exec error resulting in state FAILURE :: caused by :: Sort operation used more than the maximum 33554432 bytes of RAM. Add an index, or specify a smaller limit.'
Estou sem RAM...ops! Tenho algumas outras collection em meu cluster e os 2GB de RAM do meu cluster M10 estão quase esgotados.
As classificações in-memory realmente usam muita RAM e, se você puder evitá-las, eu com certeza gostaria de recomendável que você se livre delas. Eles estão forçando alguns dados do seu conjunto de trabalho a sair do cache, e isso resultará em pressão de cache e mais IOPS.
Vamos criar o índice recomendado e ver como a situação melhora:
1 db.global_and_us.createIndex({ date: 1, country: 1})
Vamos executar nossa query novamente no plano explicativo do Compass:
Desta vez, a classificação na memória não é mais usada, pois podemos retornar os documentos na mesma ordem em que aparecem em nosso índice. 391608 documentos são retornados e estamos usando o índice correto. Essa consulta é MUITO mais eficiente em termos de memória do que a anterior.
Agora que nosso índice foi criado, podemos finalmente iniciar o processo de arquivamento.
Logo antes de iniciarmos nosso processo de arquivamento, vamos executar um aggregation pipeline no MongoDB Compass para verificar o conteúdo de nossa coleção.
1 [ 2 { 3 '$sort': { 4 'date': 1 5 } 6 }, { 7 '$group': { 8 '_id': { 9 'country': '$country', 10 'state': '$state', 11 'county': '$county' 12 }, 13 'count': { 14 '$sum': 1 15 }, 16 'first_date': { 17 '$first': '$date' 18 }, 19 'last_date': { 20 '$last': '$date' 21 } 22 } 23 }, { 24 '$count': 'number_places' 25 } 26 ]
Como você pode ver, agrupando os documentos por país, estado e condado, podemos ver:
- quantos dias são informados:
170, - a primeira data:
2020-01-22T00:00:00.000+00:00, - a última data:
2020-07-09T00:00:00.000+00:00, - o número de locais que estão sendo monitorados:
3528.
Depois de iniciado, seu Online Archive ficará assim:
Quando a inicialização for concluída, ficará assim:
Depois de algum tempo, todos os seus documentos serão migrados para o armazenamento de objetos na nuvem subjacente.
No meu caso, como eu tinha 599760 em minha coleção e 111 dias foram movidos para meu armazenamento de objetos na nuvem, tenho
599760 - 111 * 3528 = 208152 documentos restantes em minha coleção no MongoDB Atlas.1 PRIMARY> db.global_and_us.count() 2 208152
Bom. Nossos dados agora estão arquivados e não precisamos atualizar nosso cluster para um nível de cluster superior!
Normalmente, o arquivamento de dados anda com "bye bye data". No minuto em que você decide arquivá-lo, ele desaparece para sempre e você simplesmente o retira do antigo sistema de armazenamento empoeirado quando o sistema de produção real simplesmente queima até o chão.
Deixe-me mostrar como você pode manter o acesso ao conjunto de dadosTODO que acabamos de arquivar em meu armazenamento de objetos na nuvem usando o MongoDB Atlas Data Federation.
Primeiro, vamos clicar no botãoCONNECT. diretamente na aba Online Archive:
Ou acesse o menu Data Federation à esquerda para encontrar seu ambiente configurado automaticamente.
Recupere a linha de comando de conexão para o Mongo Shell:
Certifique-se de substituir o banco de dados e a senha no comando. Depois de conectado, você pode executar o seguinte pipeline de agregação:
1 [ 2 { 3 '$match': { 4 'country': 'France' 5 } 6 }, { 7 '$sort': { 8 'date': 1 9 } 10 }, { 11 '$group': { 12 '_id': '$uid', 13 'first_date': { 14 '$first': '$date' 15 }, 16 'last_date': { 17 '$last': '$date' 18 }, 19 'count': { 20 '$sum': 1 21 } 22 } 23 } 24 ]
E aqui está a mesma consulta na linha de comando - mais fácil para uma cópia rápida & colar.
1 db.global_and_us.aggregate([ { '$match': { 'country': 'France' } }, { '$sort': { 'date': 1 } }, { '$group': { '_id': { 'country': '$country', 'state': '$state', 'county': '$county' }, 'first_date': { '$first': '$date' }, 'last_date': { '$last': '$date' }, 'count': { '$sum': 1 } } } ])
Aqui está o resultado que obtive:
1 { "_id" : { "country" : "France", "state" : "Reunion" }, "first_date" : ISODate("2020-01-22T00:00:00Z"), "last_date" : ISODate("2020-07-09T00:00:00Z"), "count" : 170 } 2 { "_id" : { "country" : "France", "state" : "Saint Barthelemy" }, "first_date" : ISODate("2020-01-22T00:00:00Z"), "last_date" : ISODate("2020-07-09T00:00:00Z"), "count" : 170 } 3 { "_id" : { "country" : "France", "state" : "Martinique" }, "first_date" : ISODate("2020-01-22T00:00:00Z"), "last_date" : ISODate("2020-07-09T00:00:00Z"), "count" : 170 } 4 { "_id" : { "country" : "France", "state" : "Mayotte" }, "first_date" : ISODate("2020-01-22T00:00:00Z"), "last_date" : ISODate("2020-07-09T00:00:00Z"), "count" : 170 } 5 { "_id" : { "country" : "France", "state" : "French Guiana" }, "first_date" : ISODate("2020-01-22T00:00:00Z"), "last_date" : ISODate("2020-07-09T00:00:00Z"), "count" : 170 } 6 { "_id" : { "country" : "France", "state" : "Guadeloupe" }, "first_date" : ISODate("2020-01-22T00:00:00Z"), "last_date" : ISODate("2020-07-09T00:00:00Z"), "count" : 170 } 7 { "_id" : { "country" : "France", "state" : "New Caledonia" }, "first_date" : ISODate("2020-01-22T00:00:00Z"), "last_date" : ISODate("2020-07-09T00:00:00Z"), "count" : 170 } 8 { "_id" : { "country" : "France", "state" : "St Martin" }, "first_date" : ISODate("2020-01-22T00:00:00Z"), "last_date" : ISODate("2020-07-09T00:00:00Z"), "count" : 170 } 9 { "_id" : { "country" : "France" }, "first_date" : ISODate("2020-01-22T00:00:00Z"), "last_date" : ISODate("2020-07-09T00:00:00Z"), "count" : 170 } 10 { "_id" : { "country" : "France", "state" : "Saint Pierre and Miquelon" }, "first_date" : ISODate("2020-01-22T00:00:00Z"), "last_date" : ISODate("2020-07-09T00:00:00Z"), "count" : 170 } 11 { "_id" : { "country" : "France", "state" : "French Polynesia" }, "first_date" : ISODate("2020-01-22T00:00:00Z"), "last_date" : ISODate("2020-07-09T00:00:00Z"), "count" : 170 }
Como você pode ver, mesmo que nossos dados frios sejam arquivados, ainda podemos acessar todo o nosso conjunto de dados, mesmo que ele tenha sido parcialmente arquivado. A primeira data ainda é 22janeiro e a última data ainda é 9julho, em um total de 170 dias.
O MongoDB Atlas Online Archive é seu novo melhor amigo para se aposentar e armazenar seus dados frios com segurança no armazenamento de objetos na cloud com apenas alguns cliques.
Neste tutorial, mostrei como configurar um Online Archive para arquivar automaticamente seus dados em um armazenamento de objetos na nuvem totalmente gerenciado, mantendo o acesso fácil para consultar a totalidade do conjunto de dados no local, em fontes, usando o Atlas Data Federation.
Caso esta postagem do blog não tenha deixado claro, o Online Archive NÃOé um substituto para backups ou uma estratégia de backup. Esses são 2 tópicos completamente diferentes e não devem ser confundidos.
Se tiver dúvidas, acesse o site da nossa comunidade de desenvolvedores, no qual os engenheiros e a comunidade do MongoDB ajudarão você a desenvolver sua próxima grande ideia com o MongoDB.
Para saber mais sobre oMongoDB Atlas Data Federation, leia as outras publicações de blogs desta série abaixo ou confira a documentação.