Como otimizar sua fatura de instância sem servidor com indexação
Avalie esse Artigo
As soluções sem servidor estão ganhando força rapidamente entre os desenvolvedores e as organizações como um meio de agir rapidamente, minimizar a sobrecarga e otimizar os custos. Mas a mudança de uma fatura mensal tradicional pré-provisionada e previsível para um modelo baseado no consumo ou no uso pode, às vezes, resultar em confusão em torno de como essa fatura é gerada. Neste artigo, mostraremos os fundamentos do nosso modelo de cobrança sem servidor e daremos dicas sobre como otimizar da melhor forma possível seu banco de dados sem servidor para otimizar os custos.
As instâncias sem servidor do MongoDB Atlas, recentemente anunciadas como comdisponibilidade geral, fornecem um endpoint sem servidor sob demanda para seu aplicativo, sem necessidade de dimensionamento. Basta escolher um provedor de nuvem e uma região para começar e, à medida que seu aplicativo cresce, seu banco de dados sem servidor será facilmente escalado com base na demanda e cobrará apenas pelos recursosque você usa.
Ao contrário de nossos clusters tradicionais, as instâncias sem servidor oferecem um modelo de definição de preçofundamentalmente diferente , que é medido principalmente em leituras, gravações e armazenamento, com descontos automáticos em camadas em leituras à medida que seu uso aumenta. Assim, você pode começar pequeno sem nenhum compromisso inicial e nunca se preocupar em pagar por recursos não utilizados se sua carga de trabalho estiver ociosa.
Pague apenas pelas operações que você executa.
| Item | Descrição | Preços |
|---|---|---|
| Unidade de processamento de leitura (RPU) | Número de operações de leitura e documentos digitalizados* por operação *Número de documentos lidos em blocos de 4KB e índices lidos em blocos de 256 bytes | $0.10/milhão para os primeiros 50 milhões por dia* *Níveis diários de RPU: próximos 500 milhões: $0.05/milhão Leituras posteriores: $0.01/milhão |
| Unidade de processamento de gravação (WPU) | Número de operações de gravação* no banco de dados *Número de documentos e índices gravados em blocos de 1KB | $1.00/milhão |
| Armazenamento | Dados e índices armazenados no banco de dados | $0.25/GB-mês |
| Backup padrão | Download e restauração de snapshots de backup* *2 snapshots diários gratuitos incluídos por instância sem servidor* | $2.50/hora* *Para baixar ou restaurar os dados* |
| Backup contínuo sem servidor | 35Retenção de backup em todos os dias para snapshots diários | $0.20/GB-mês |
| transferência de dados | Dados de entrada/saída de/para o banco de dados | $0.015 - $0.10/GB* *Dependendo da origem e do destino do tráfego |
À primeira vista, as unidades de processamento de leitura (RPU) e as unidades de processamento de gravação (WPU) podem ser novas unidades para você, então vamos nos aprofundar rapidamente no que elas significam. Usamos RPUs e WPUs para quantificar a quantidade de trabalho que o banco de dados precisa fazer para atender a uma consulta ou executar uma gravação. Simplificando, uma unidade de processamento de leitura (RPU) refere-se às operações de leitura no banco de dados e é calculada com base no número de operações executadas e documentos verificados por operação. Da mesma forma, uma unidade de processamento de gravação (WPU) é uma operação de gravação no banco de dados e é calculada com base no número de bytes gravados em cada documento ou índice. Para obter mais explicações sobre as unidades de custo, consulte nossa documentação.
Agora que você tem uma compreensão básica do modelo de preços, Go ver um exemplo para fornecer mais contexto e dicas sobre como garantir que suas operações sejam otimizadas da melhor forma para minimizar os custos.
Para este exemplo, usaremos o conjunto de dados de amostra no Atlas. Para usar dados de amostra, basta acessar a implantação da instância sem servidor e selecionar "Load Sample Dataset" no menu suspenso, conforme mostrado abaixo.
Isso carregará algumas collections, como dados meteorológicos e dados de listagem do Airbnb. Observe que o carregamento do conjunto de dados de amostra consumirá aproximadamente um milhão de WPUs (menos de US$1 na maioria das regiões compatíveis), e você será cobrado de acordo. Agora, vamos dar uma olhada no que acontece quando interagimos com nossos dados e realizamos algumas consultas de pesquisa.
Para este exercício, escolhi a coleção sample_weatherdata. Ao observar os dados na visualização Coleções do Atlas, fica claro que a coleta de dados meteorológicos contém informações de vários locais e que a maioria dos locais possui um código de letra de chamada como uma forma conveniente de identificar onde esses dados de leitura meteorológica foram obtidos.
Para este exemplo, vamos simular o que aconteceria se um usuário acessasse seu aplicativo de meteorologia e fizesse uma pesquisa por uma localização geográfica. Nesta coleta de dados meteorológicos, as localizações geográficas podem ser identificadas por CallLetters, que são códigos específicos para várias estações meteorológicas em todo o mundo. Eu escolhi arbitrariamente o código da estação “ESVJ,”, que é uma bóia meteorológica no Oceano Atlântico.
Aqui está o que vemos quando executamos esta consulta no Atlas Data Explorer:
Podemos ver que esta consulta retorna três registros. Vamos dar uma olhada em quantos RPUs essa consulta me custaria. Devemos lembrar que os RPUs são calculados com base no número de operações de leitura e no número de documentos digitalizados por operação.
Para executar a consulta anterior, é necessária uma verificação de coleção completa, o que resulta em aproximadamente 1000 RPUs.
Peguei essa query e a executei quase 3,000 vezes em um script de shell. Isso simulará cerca de 3,000 os usuários acessam um aplicativo para verificar o clima em um dia. Este é o código por trás do script:
1 weatherRPUTest.sh 2 3 for ((i=0; i<=3000; i++)); do 4 5 echo testing $i 6 7 mongosh "mongodb+srv://vishalserverless1.qdxrf.mongodb.net/sample_weatherdata" --apiVersion 1 --username vishal --password ******** < mongoTest.js 8 9 done 10 11 12 mongoTest.js 13 14 db.data.find({callLetters: "ESVJ"})
Como esperado, 3,000 iterações serão 1,000 * 3,000 = 3,000,000 RPUs = 3MM RPUs = $0.30.
Com base nisso, o custo por usuário desse aplicativo seria $0.01 por usuário (calculado como: 3,000,000 / 3,000 = 1,000 RPUs = $0.01).
O custo de $0.01 por usuário parece ser muito alto para uma pesquisa no banco de dados, porque se esse aplicativo meteorológico fosse dimensionado para atingir um nível de atividade semelhante ao Accuweather, que vê cerca de 9.5B solicitações meteorológicas em um dia, você pagaria cerca de US$1 milhões em custos de banco de dados por dia. Ao deixar sua consulta dessa forma, é provável que você se depare com uma conta inesperadamente alta à medida que seu uso aumenta – caindo em uma armadilha comum que muitos novos usuários sem servidor enfrentam.
Para evitar esse problema, recomendamos que você siga as práticas recomendadas do MongoDB e indexe seus dados para otimizar suas queries por desempenho e custo. Índices são estruturas de dados especiais que armazenam uma pequena parte do conjunto de dados da coleta em um formato fácil de percorrer.
Sem índices, o MongoDB deve executar uma verificação da coleção, ou seja, digitalizar todos os documentos de uma coleção, para selecionar os documentos que correspondem à instrução da query (algo que você acabou de ver no exemplo acima). Ao adicionar um índice às consultas apropriadas, você pode limitar o número de documentos que ele deve inspecionar, reduzindo significativamente as operações pelas quais você é cobrado.
Vejamos como a indexação pode ajudar a reduzir significativamente as RPUs.
Primeiro, vamos criar um índice simples no campo 'callletters':
Essa operação normalmente termina dentro de 2a3 segundos. Para referência, podemos ver o tamanho do índice criado na guia de índice:
Devido à estrutura de dados do índice, é difícil calcular o número exato de leituras do índice. No entanto, podemos executar o mesmo script novamente para 3,000 iterações e comparar o número de RPUs.
As queries de 3,000 no campo indexado agora resultam em aproximadamente 6,500 RPUs em contraste com os 3 milhões de RPUs da consulta não indexada, que é uma 99.8% de redução em RPUs.
Podemos ver que, simplesmente adicionando o índice acima, conseguimos reduzir o custo por usuário para cerca de $0.000022 (calculado como: 6,500/3,000 = 2.2 RPUs = $0.000022), o que representa uma grande economia de custos em comparação com o custo anterior de US$0.01 por usuário.
Portanto, a indexação não apenas ajuda a melhorar o desempenho e a escala de suas queries, mas também pode reduzir significativamente as RPUs consumidas, o que reduz seus custos. Observe que pode haver cenários raros em que isso não seja verdade (quando o tamanho do índice é muito maior do que o número de documentos). No entanto, na maioria dos casos, você deverá ver uma redução significativa no custo e uma melhoria no desempenho.
Como você pode ver, a adoção de um modelo de preços baseado no uso às vezes pode exigir que você seja extremamente diligente para garantir que sua estrutura de dados e consultas sejam otimizadas. Mas, quando feito corretamente, o tempo gasto para fazer essas otimizações geralmente compensa de várias maneiras.
Se você não souber por onde começar, temos ferramentas de monitoramento integradas disponíveis na interface do usuário do Atlas que podem ajudá-lo. O consultor de desempenho monitora automaticamente seu banco de dados para queries de execução lenta e sugerirá novos índices para ajudar a melhorar o desempenho da consulta. Ou, se estiver procurando investigar mais as queries de execução lenta, pode usar o analisador de query para visualizar um detalhamento de todas as queries de execução lenta que ocorreram nas últimas 24 horas. Se você preferir uma experiência de terminal, também pode analisar o desempenho de sua query no MongoDB Shell ou no MongoDB Compass.
Se precisar de mais assistência, você sempre pode entrar em contato com nossa equipe de suporte por meio de chat ou do portal de suporte do MongoDB.
Avalie esse Artigo
Relacionado
Tutorial
Acelere sua experiência em AI : simplifique a geração de AI RAG com o MongoDB Atlas e o mecanismo de lógica de AI Vertex do Google
Aug 16, 2024 | 6 min read