Governança de custos do Snowflake Connector for MySQL¶
Nota
O Snowflake Connector for MySQL está sujeito aos Termos do conector.
Este tópico fornece as práticas recomendadas para controle de custos e localização do tamanho de warehouse ideal para o Snowflake Connector for MySQL.
Como medir o custo do conector¶
Se o conector tiver uma conta separada apenas para ingestão e armazenamento de dados e a conta não mostrar nenhuma outra atividade (como a execução de consultas por usuários usando os dados ingeridos), você poderá ler o custo geral no nível da conta. Para saber mais, consulte Exploração do custo total.
Se a conta não for dedicada apenas ao conector ou você precisar investigar mais os custos, analise os custos cobrados pelos três componentes separadamente:
Para obter uma introdução a esses três componentes de custo, consulte Compreensão do custo total.
Recomendações gerais¶
Para obter o custo gerado pelo conector, recomendamos que você crie uma conta separada exclusivamente para usar o conector. Usando uma conta específica, você rastreia a transferência exata de dados gerada pelo conector.
Se você não puder usar uma conta separada para o conector, considere o seguinte:
Crie um banco de dados separado para armazenar dados ingeridos para rastrear o custo de armazenamento mais facilmente.
Aloque um warehouse apenas para o conector para obter o custo de computação exato.
Use tags de objeto em bancos de dados e um warehouse para criar relatórios de custos personalizados.
Custo de computação¶
Recomendamos que você use um par de operações dedicadas e warehouses de computação somente para o conector. Esta configuração permite que você crie monitores de recursos nesses dois warehouses. É possível usar os monitores para enviar alertas por e-mail e suspender ambos os warehouses, interrompendo o conector quando a cota de crédito definida for excedida.
Nota
Definir uma cota de crédito muito baixa em configurações onde grandes volumes de dados são ingeridos pode fazer com que o conector não ingira todos os dados.
Para obter mais informações sobre como verificar os créditos consumidos pelo warehouse, consulte Exploração do custo de computação. Você também pode atribuir tags de objeto ao warehouse e usar as tags para criar relatórios de custos.
Custo de armazenamento¶
O conector MySQL 6.0.0 armazena dados em:
O banco de dados do conector, que é criado durante a instalação do conector e que contém o estado interno do conector.
Um ou muitos outros bancos de dados, que são criados ao configurar fontes de dados e onde os dados ingeridos são armazenados.
O armazenamento de dados também é usado pelo recurso de Fail-safe do Snowflake. A quantidade de dados armazenados no Fail-safe depende das atualizações de tabela feitas pelo conector. Portanto, a quantidade de dados aumenta se as linhas da tabela ingeridas de um banco de dados de origem forem atualizadas com frequência ou se uma tabela inteira for recarregada. Normalmente, sete a dez dias após a configuração do conector, a quantidade de dados Fail-safe se estabiliza (supondo que nenhum recarregamento seja executado e que o fluxo de dados ingeridos esteja em uma taxa constante).
Se quiser verificar o uso do armazenamento usando Snowsight, recomendamos que você use bancos de dados separados para armazenar os dados ingeridos. Dessa forma, é possível filtrar os gráficos de uso de armazenamento por um objeto, o que mostra o uso por bancos de dados individuais. Você também pode exibir o uso do armazenamento consultando a exibição DATABASE_STORAGE_USAGE_HISTORY e filtrando por bancos de dados usados pelo conector.
Se um banco de dados contiver outros esquemas não relacionados ao conector, você poderá consultar o uso de armazenamento de um esquema específico dedicado aos dados ingeridos pelo conector. É possível obter essas informações na exibição TABLE_STORAGE_METRICS após filtrar por nomes de banco de dados e esquema e agregar colunas com uso de armazenamento.
Custo de transferência de dados¶
O conector usa o recurso Snowpipe Streaming do Snowflake para transferir dados de um banco de dados de origem para um banco de dados de destino em sua conta Snowflake.
Para obter informações sobre como verificar os créditos consumidos pelo Snowpipe Streaming, consulte Custos do Snowpipe Streaming.
Como determinar o tamanho ideal do warehouse para a instância do conector¶
Um grande benefício é que o tamanho do warehouse de computação pode ser ajustado ao volume de dados. O conector normalmente requer um warehouse de operações XSMALL e um warehouse de computação XSMALL e não aproveita warehouses maiores durante a ingestão de dados.
Para encontrar o tamanho ideal do warehouse para o conector, você deve considerar os fatores que afetam o desempenho do conector, como o tamanho dos bancos de dados de origem, o número de alterações, o número de fontes de dados e tabelas habilitadas.
Recomendamos que você defina um conjunto de expectativas mensuráveis, como atraso de replicação, e escolha o menor tamanho de warehouse que atenda a essas expectativas. Por outro lado, se você quiser apenas experimentar o conector e habilitar uma única tabela para ingestão, um warehouse X-Small deve ser suficiente.
Para determinar se você pode reduzir o tamanho do warehouse, consulte Monitoramento de carga do warehouse.