Rapid Cache

Importante:o Anywhere Cache agora se chama Rapid Cache. Ao usar o Rapid Cache com determinadas ferramentas, o nome Anywhere Cache ainda pode ser referenciado na interface ou superfície da ferramenta.

Nesta página, descrevemos o Rapid Cache, um recurso que fornece um cache de leitura zonal com SSD para buckets do Cloud Storage que pode aumentar a capacidade de processamento e reduzir a latência nos dados armazenados. O Rapid Cache oferece capacidade de armazenamento e largura de banda que são escalonar verticalmente automaticamente de acordo com suas necessidades. O Rapid Cache é um serviço totalmente gerenciado e retorna dados consistentes.

O Rapid Cache é útil para melhorar o desempenho de cargas de trabalho com muita leitura e reduzir os custos de rede. Para mais informações, consulte Benefícios.

Consulte Criar e gerenciar caches para saber como criar e gerenciar caches usando o Rapid Cache.

Como o Rapid Cache funciona?

Com o Rapid Cache, é possível criar caches na mesma zona das cargas de trabalho. Quando você cria um cache em uma zona, as solicitações de leitura de dados originadas da zona são processadas pelo cache, e não pelo bucket. Cada cache atende clientes na mesma zona que ele.

Os dados de um bucket são ingeridos em um cache quando são lidos por uma VM que reside na mesma zona que o cache. Se você configurar o comportamento de ingestão na gravação, os dados também serão ingeridos no cache quando forem gravados no bucket.

Os metadados não são armazenados em cache. As solicitações de metadados de objeto são sempre processadas pelo bucket, e não pelo cache.

Para mais informações sobre como os dados são ingeridos em um cache, consulte Ingestão de dados. É possível configurar o time to live (TTL) e o comportamento de ingestão na gravação de um cache ao criá-lo ou atualizá-lo.

Vantagens

Ao armazenar seus dados em cache com o Rapid Cache, você tem os seguintes benefícios:

• Acesso mais rápido aos dados: o Rapid Cache colocaliza seus dados na mesma zona que seus recursos de computação e tem suporte total de SSD. Isso permite que suas cargas de trabalho tenham até 2,5 TB/s de capacidade de processamento e reduz a latência para leituras mais rápidas.

• Reduza as taxas de transferência de dados multirregionais: os dados lidos do cache são cobrados com taxas de transferência de dados reduzidas em comparação com os dados lidos diretamente de um bucket multirregional.

• Reduza as taxas de recuperação: as taxas de recuperação de buckets no Nearline Storage, Coldline Storage e Archive Storage não se aplicam a leituras de dados do cache.

• Acumule custos menores com operações de leitura: as operações de leitura veiculadas pelo Rapid Cache têm preços menores do que as operações de classe B veiculadas de um bucket no Standard Storage.

• Escalonar automaticamente o tamanho do cache: o armazenamento em cache SSD dinâmico do Rapid Cache é escalonado automaticamente com base no uso, sem que você precise especificar um tamanho de cache.

• Usar caches de maneira eficiente: o Rapid Cache pode ser ativado em buckets existentes sem exigir mudanças nos aplicativos ou nas APIs atuais. Os dados armazenados no Rapid Cache têm consistência forte.

Para mais detalhes sobre preços, consulte Preços do Rapid Cache. Para informações sobre cotas, consulte Cotas do Rapid Cache.

Quando usar o Rapid Cache?

Use o Rapid Cache para dados que são alterados com pouca frequência e lidos com frequência para acelerar as leituras de dados em cargas de trabalho de análise e treinamento e carregamento de modelos de IA/ML.

Suponha que você esteja treinando um modelo de IA em vários nós do Google Kubernetes Engine, todos lendo repetidamente dados armazenados nos buckets do Cloud Storage e executados na mesma zona. Ao criar um cache na zona em que a carga de trabalho está sendo executada, ele oferece largura de banda extra e ajuda a reduzir as taxas de transferência de dados associadas à leitura de dados em buckets multirregionais, permitindo que você execute cargas de trabalho maiores e escalonadas com mais eficiência.

Escalonamento automático do tamanho do cache e do limite de largura de banda

O Rapid Cache oferece capacidade de armazenamento temporário e largura de banda que são escalonadas automaticamente para cima ou para baixo de acordo com a quantidade de dados armazenados em um cache.

O limite de largura de banda do cache começa em 100 Gbps e aumenta na taxa de 20 Gbps por 1 TiB de dados armazenados. É possível aumentar a largura de banda inicial ou o limite total de largura de banda aumentando a quantidade de dados armazenados no cache, criando mais caches em uma zona ou entrando em contato com o gerente técnico de contas ou o representante do Google.

Para saber mais sobre os limites de tamanho e largura de banda do Rapid Cache, consulte Cotas e limites do Cloud Storage.

Armazenamento de dados em cache em zonas

Ao criar um cache para um bucket, ele precisa ser criado em uma zona dentro do local do bucket. Por exemplo, se o bucket estiver localizado na região us-east1, será possível criar um cache em us-east1-b, mas não em us-central1-c. Se o bucket estiver localizado na birregião ASIA, será possível criar um cache em qualquer zona que componha as regiões asia-east1 e asia-southeast1.

Para cada bucket, é possível criar no máximo um cache por zona. Por exemplo, se um bucket estiver localizado na região us-east1, será possível criar um cache em us-east1-b e outro em us-east1-c. Se um bucket estiver localizado em uma multirregião que abrange us-central1 e us-east1, você poderá criar um cache em us-central1-a e outro em us-east1-b.

É possível criar caches em zonas, desde que haja capacidade disponível. Se a capacidade para criar um cache não estiver disponível, o Rapid Cache continuará tentando criar um cache até que a capacidade fique disponível ou o processo de criação seja cancelado pelo usuário. A capacidade pode permanecer indisponível por um longo período.

É possível usar o Rapid Cache nas seguintes zonas. Essas zonas podem ser usadas dependendo do tipo de local do bucket.

Ásia

A tabela a seguir mostra as zonas e os tipos de local disponíveis para o Rapid Cache na área geográfica da Ásia.

Nome da zona	Região	Birregional	Multirregional	Birregião personalizada
asia-east1-a
asia-east1-b
asia-east1-c
asia-northeast1-a
asia-northeast1-b
asia-northeast1-c
asia-south1-a
asia-south1-b
asia-south1-c
asia-southeast1-a
asia-southeast1-b
asia-southeast1-c

Europa

A tabela a seguir mostra as zonas e os tipos de locais disponíveis para o Rapid Cache na área geográfica da Europa.

Nome da zona	Região	Birregional	Multirregional	Birregião personalizada
europe-north1-a
europe-north1-b
europe-north1-c
europe-west1-b
europe-west1-c
europe-west1-d
europe-west3-a
europe-west3-b
europe-west3-c
europe-west4-a
europe-west4-b
europe-west4-c
europe-west4-ai1a (zona de IA)
europe-west6-a
europe-west6-b

Estados Unidos

A tabela a seguir mostra as zonas e os tipos de local disponíveis para o Rapid Cache na área geográfica dos Estados Unidos.

Nome da zona	Região	Birregional	Multirregional	Birregião personalizada
us-central1-a
us-central1-b
us-central1-c
us-central1-f
us-central1-ai1a (zona de IA)
us-east1-b
us-east1-c
us-east1-d
us-east4-a
us-east4-b
us-east4-c
us-east5-a
us-east5-b
us-east5-c
us-south1-a
us-south1-b
us-south1-c
us-south1-ai1b (Zona de IA)
us-west1-a
us-west1-b
us-west1-c
us-west2-a
us-west3-a
us-west3-b
us-west3-c
us-west4-a
us-west4-b
us-west4-c

Ingestão de dados para caches

Por padrão, os dados são ingeridos em um cache depois de serem solicitados pela primeira vez.

Como o cache está vazio quando essa solicitação inicial chega, os dados ainda não podem ser encontrados nele. Isso resulta em uma falha inicial de cache, em que o sistema recupera os dados do bucket de backup do Cloud Storage. À medida que o sistema entrega esses dados recuperados ao usuário, ele os ingere simultaneamente no cache.

Depois que essa primeira solicitação é concluída, os dados residem no cache, permitindo que todas as leituras subsequentes sejam veiculadas diretamente do cache como ocorrências em cache de alta velocidade. Esse comportamento reduz significativamente a latência de leitura e acelera a recuperação de dados. Os dados ingeridos residem no cache até que o TTL expire. Depois disso, os dados são removidos do cache.

Para evitar totalmente a solicitação inicial lenta, configure o cache para ingerir dados na gravação, além de ingerir dados após a primeira leitura.

Como ingerir dados como blocos

Ao ingerir dados em um cache, o Rapid Cache divide os objetos em blocos menores de tamanho fixo. Dividir objetos em partes permite um armazenamento em cache mais granular, especialmente para arquivos grandes em que apenas partes específicas são acessadas.

Um bloco é um bloco de dados de 2 MB. Quando um objeto é solicitado, o Rapid Cache identifica quais blocos de 2 MB cobrem o intervalo de bytes solicitado e gerencia esses blocos de forma independente.

O comportamento da ingestão de dados varia de acordo com o tamanho do objeto que está sendo ingerido no cache:

• Para solicitações de leitura de objetos maiores que 2 MB, somente os blocos que contêm o intervalo de bytes solicitado são ingeridos. Por exemplo, a leitura do primeiro 1 MB de um arquivo de 100 MB ingere apenas o primeiro bloco de 2 MB.

• Para solicitações de leitura de objetos menores que 2 MB (por exemplo, uma imagem de 500 KB), todo o objeto é ingerido no cache.

Ingestão de dados na gravação

Quando você ativa um cache para ingerir dados na gravação, os dados são ingeridos no cache no momento em que são gravados no bucket. Esse comportamento pode ser ativado opcionalmente, além do comportamento padrão de ingestão de dados após a leitura inicial.

O recurso de ingestão na gravação remove as ausências no cache iniciais e permite que sua carga de trabalho se beneficie de uma ocorrência em cache imediata na primeira leitura de dados. A ingestão de dados na gravação acelera as cargas de trabalho de leitura após gravação, como restaurar checkpoints do sistema ou preparar pipelines de dados para treinamento de modelo.

É possível ativar um cache para ingerir dados na gravação ao criar ou atualizar o cache. É possível configurar um cache para ingerir todos os objetos gravados em um bucket (também conhecido como "ingestão no nível do bucket na gravação") ou ingerir seletivamente objetos gravados no bucket em uma pasta gerenciada especificada (também conhecida como "ingestão no nível do prefixo na gravação").

Por exemplo, digamos que você ative um cache para realizar a ingestão na gravação no nível do prefixo para objetos no bucket my-bucket que têm o prefixo red/ no nome. Em seguida, você faz upload de três objetos para my-bucket: os objetos red/my-dog.png, blue/my-cat.png e red/my-goldfish.png. Como resultado, apenas os objetos red/my-dog.png e red/my-goldfish.png são ingeridos no cache ao serem enviados para my-bucket.

Ao configurar a ingestão na gravação no nível do prefixo usando determinadas ferramentas (como o console doGoogle Cloud ), uma nova pasta gerenciada é criada automaticamente para você se você especificar um prefixo que não seja o nome de uma pasta gerenciada atual. No entanto, ao usar a API JSON, é necessário criar manualmente a pasta gerenciada e aplicar as configurações de ingestOnWrite para cada zona de cache. Confira as instruções para ativar ou desativar a ingestão na gravação usando cada ferramenta em Usar o Rapid Cache.

Para entender como ativar ou desativar a ingestão na gravação no nível do bucket ou do prefixo ao usar a API JSON, expanda a seção Entenda como ativar a ingestão na gravação. As informações nesta seção se referem principalmente à API JSON. Outras ferramentas, como o consoleGoogle Cloud , ocultam algumas das configurações para facilitar a ativação e o gerenciamento da ingestão na gravação.

Entender como ativar a ingestão na gravação

Esta seção ajuda você a entender quais configurações da API JSON usar para ativar a ingestão na gravação para todos os objetos gravados em um bucket ou apenas para objetos selecionados que são gravados no bucket em um prefixo de pasta gerenciada.

Há duas configurações que controlam se um cache ingere dados na gravação para todos os objetos em um bucket ou apenas objetos seletivos em um prefixo:

• A ativação da ingestão na gravação no nível do bucket é feita usando o campo ingestOnWrite de um recurso de cache. O campo é assim:

  {
  "zone": "us-east1-a",
  "ttl": "24h",
  "ingestOnWrite": true
  }

  • Se definido como true, a ingestão na gravação será ativada para todos os objetos gravados no bucket. Isso substitui todas as configurações no nível da pasta gerenciada que ativam a ingestão na gravação para objetos seletivos por prefixo.
  • Se definido como false, a ingestão na gravação será desativada em objetos de todo o bucket. Essa configuração permite ativar a ingestão na gravação para objetos seletivos por prefixo usando as configurações de pastas gerenciadas.

• A ativação da ingestão na gravação no nível do prefixo é feita usando pastas gerenciadas, que representam caminhos de prefixo que terminam com uma barra (por exemplo: my-prefix/). Quando a ingestão na gravação no nível do prefixo está ativada, um cache ingere seletivamente objetos na gravação somente se o objeto tiver o prefixo no nome.

  A ingestão na gravação no nível do prefixo é controlada pelo campo ingestOnWrite do mapeamento rapidCacheConfig.policies em um recurso de pasta gerenciada. Uma instância de cache precisa existir para ser especificada no mapeamento rapidCacheConfig.policies.

  O mapeamento rapidCacheConfig.policies de uma pasta gerenciada é semelhante ao seguinte:

  "rapidCacheConfig": {
    "policies": {
      "us-east1-a": {
        "rapidCacheId": "us-east1-a",
        "ingestOnWrite": "unspecified"
      }
      "us-east1-b": {
        ...,
        ...
      }
    }
  }

  • As instâncias de cache especificadas no mapeamento policies precisam existir para que a ingestão na gravação no nível do prefixo funcione. Por exemplo, para especificar rapidCacheId: "us-east1-a" no mapeamento policies, primeiro é preciso ter um cache para a zona us-east1-a.
  • É possível atualizar várias instâncias de cache especificadas no mapeamento policies em uma única chamada de API.
  • Se ingestOnWrite for definido como enabled, a ingestão na gravação será ativada para todos os objetos gravados no bucket com esse prefixo de pasta gerenciada. A ingestão na gravação no nível do prefixo só pode ser ativada se o campo ingestOnWrite do recurso de cache for false.
  • Se definido como unspecified (padrão), a ativação da ingestão na gravação será herdada do recurso pai imediato, que pode ser uma pasta gerenciada pai ou o bucket que contém a pasta gerenciada.
  • Os caches não especificados no mapeamento de políticas são tratados como se a configuração ingestOnWrite fosse definida como unspecified.

Veja a seguir um resumo de como configurar os recursos de cache e pasta gerenciada para ativar ou desativar a ingestão na gravação no nível do bucket ou do prefixo:

• Ativar a ingestão na gravação no nível do bucket (mas não no nível do prefixo)

  • Configuração: defina o campo ingestOnWrite do recurso de cache como true.

  • Comportamento: a ingestão na gravação está ativada para todos os objetos gravados no bucket. Essa configuração em todo o bucket substitui todas as configurações gerenciadas no nível da pasta. Isso significa que as configurações seletivas no nível do prefixo são ignoradas.

• Ativar a ingestão na gravação no nível do prefixo (mas não no nível do bucket)

  • Configuração:

    1. Defina o campo ingestOnWrite do recurso de cache como false.
    2. Configure um mapeamento policies válido (não nulo) no recurso de pasta gerenciada.
    3. Defina o campo ingestOnWrite da pasta gerenciada como enabled ou unspecified se for uma pasta filha que herda enabled de uma pasta gerenciada mãe ativada.

  • Comportamento: a ingestão na gravação só ocorre para objetos gravados em prefixos de pastas gerenciadas correspondentes.

• Como ativar a ingestão no nível de prefixo na gravação em pastas gerenciadas principais e secundárias

  Não é possível ativar a ingestão na gravação para pastas gerenciadas filhas sem também ativá-la na pasta gerenciada mãe.

• Desativar a ingestão no momento da gravação de bucket e prefixo

  • Configuração:

    1. Defina o campo ingestOnWrite do recurso de cache como false.

    2. Defina todos os campos ingestOnWrite das pastas gerenciadas como unspecified, garantindo que nenhum campo ingestOnWrite das pastas gerenciadas principais seja enabled.

       Como alternativa, não configure nenhuma política deixando o mapa policies null ou omitindo totalmente a configuração rapidCacheConfig.

  • Comportamento: a ingestão na gravação é desativada globalmente para o bucket e todos os prefixos.

Quando você ativa a ingestão na gravação no nível do prefixo em uma pasta gerenciada mãe, ela é ativada para todas as pastas gerenciadas filhas que estão aninhadas na pasta gerenciada mãe. Para saber mais sobre como os recursos herdam a ativação e desativação da ingestão na gravação, expanda a seção Como funciona a herança da ingestão na gravação.

Como funciona a herança de ingestão na gravação

Quando uma pasta gerenciada não ativa explicitamente a ingestão na gravação (em que o campo ingestOnWrite da pasta gerenciada está definido como unspecified), o comportamento de ingestão na gravação do cache é herdado do recurso pai da pasta gerenciada, seja do bucket ou de uma pasta gerenciada mãe.

Ao usar a ingestão na gravação no nível do prefixo, a configuração que você define em uma pasta gerenciada mãe é herdada por todas as pastas gerenciadas filhas.

Por exemplo, considere o seguinte cenário:

• Você tem uma pasta gerenciada a/ cujo recurso pai é o bucket my-bucket.
• Você tem uma pasta gerenciada a/b/ cujo recurso pai é a pasta gerenciada a/ em my-bucket.

Quando um objeto chamado a/b/info.txt é gravado, o Rapid Cache avalia a hierarquia de configuração de cima para baixo:

1. Verifique a pasta gerenciada imediata: se a/b/ estiver definido como enabled, a ingestão na gravação no nível do prefixo estará ativada para objetos gravados em a/b/. Se a/b/ estiver definido como unspecified, o Rapid Cache vai verificar o recurso pai imediato, que é a pasta gerenciada a/.
2. Verifique a pasta gerenciada pai: se a/ estiver definido como enabled, a ingestão na gravação no nível do prefixo estará ativada para a/ e a/b/. Se a/ estiver definido como unspecified, o Rapid Cache vai verificar o bucket pai.
3. Verifique a configuração ingestOnWrite no nível do cache do bucket: se o campo ingestOnWrite do cache estiver definido como true, a inclusão no nível do bucket ao gravar será ativada e vai substituir qualquer pasta gerenciada que tenha a inclusão no nível do prefixo configurada. Se o campo ingestOnWrite do cache for false e o campo ingestOnWrite das pastas gerenciadas pai e filho forem unspecified, a ingestão na gravação será desativada para objetos no bucket que estão nas pastas gerenciadas pai e filho. Nesse cenário, se não houver outras pastas gerenciadas no bucket com a ingestão na gravação configurada, ela será desativada para todos os objetos no bucket.

Time to live (TTL)

O TTL de um cache determina por quanto tempo os dados permanecem no cache antes de serem removidos. O TTL é o período em que os dados permanecem no cache desde a última leitura. Por exemplo, se o TTL estiver definido como 24 horas, um bloco de dados que foi lido pela última vez às 11h de segunda-feira sem leituras subsequentes será removido do cache às 11h de terça-feira.

É possível definir o TTL de um cache ao criá-lo ou atualizá-lo. É possível definir o TTL de um cache como um valor entre 24 horas e 7 dias, inclusive. Se não for especificado, o TTL será de 24 horas por padrão.

Operações de cache

Esta seção descreve as operações que você pode realizar nos caches do Rapid Cache. Algumas operações são assíncronas e retornam uma operação de longa duração, enquanto outras são síncronas, em que as operações são feitas imediatamente e retornam um recurso AnywhereCache.

Criar um cache

É possível definir o local, o TTL e o comportamento de ingestão de dados de um cache ao criar o cache. O cache entra em um estado CREATING enquanto está sendo criado e entra em um estado RUNNING quando se torna ativo. Uma operação de criação de cache pode levar até 48 horas, após o que ela expira.

A API Create do AnywhereCaches é assíncrona. Uma operação de criação faz com que uma operação de longa duração seja retornada. A operação de longa duração fornece um status da operação de criação e permite cancelar a operação antes que ela seja concluída.

Observação: se houver uma tentativa de cancelar a operação de criação, o servidor fará o possível para cancelar a operação, mas o sucesso não é garantido.

Atualizar um cache

É possível definir o TTL ou o comportamento de ingestão de dados de um cache ao atualizar o cache. Só é possível atualizar caches que estejam no estado RUNNING. Não é possível atualizar um cache no estado CREATING ou DISABLED.

Quando um cache está sendo atualizado, o campo pending_update é avaliado como true. Enquanto o campo pending_update for avaliado como true, o cache não poderá ser atualizado novamente. Quando o TTL de um cache termina de ser atualizado, o novo TTL é aplicado imediatamente aos dados atuais e novos no cache.

A API AnywhereCaches Update é assíncrona e retorna uma operação de longa duração.

Acessar um cache

Quando você recebe um cache, o Rapid Cache retorna o estado e a configuração da instância de cache. A API Get do AnywhereCaches é síncrona e retorna um recurso AnywhereCache.

Listar caches

É possível retornar uma lista de caches associados a um determinado bucket. A API List do AnywhereCaches é síncrona e oferece suporte à paginação.

Desativar um cache

É possível desativar um cache para removê-lo permanentemente da configuração do bucket. Quando você desativa um cache, ele entra no estado DESATIVADO. Durante esse estado, ainda é possível ler os dados atuais do cache, mas não é possível ingerir novos dados nele.

Depois de desativar um cache, há um período de carência de 1 hora em que é possível cancelar a desativação retomando o cache. Após esse período de carência de uma hora, o cache é excluído. Quando o cache é excluído, todos os dados dentro dele são removidos, e o cache é removido do bucket.

Durante o período de uma hora antes da exclusão, é possível reverter o estado DISABLED retomando o cache, que volta ao estado RUNNING.

A API AnywhereCaches Disable é síncrona e retorna um recurso AnywhereCache.

Retomar um cache

É possível retomar caches que estão no estado DISABLED, desde que o cache desativado esteja dentro do período de carência de 1 hora. Após o período de carência de uma hora, a operação de retomada é feita com o melhor esforço possível, já que o cache pode ser excluído a qualquer momento após o período de carência. Depois que um cache é retomado, ele entra no estado EM EXECUÇÃO.

A API AnywhereCaches Resume é síncrona e retorna um recurso AnywhereCache.

Recomendador do Rapid Cache

O recomendador do Rapid Cache oferece recomendações e insights para criar caches em pares de bucket e zona analisando seu uso e armazenamento de dados. Para informações gerais e instruções sobre como usar o recomendador do Rapid Cache, consulte Recomendador do Rapid Cache.

Como usar o Rapid Cache para acelerar as leituras do BigQuery

O Rapid Cache pode ser usado para veicular dados de solicitações de leitura de objetos emitidas pelo BigQuery. Com o Rapid Cache, é possível acelerar as leituras de dados dos seus aplicativos e otimizar a eficiência de custos.

Embora o BigQuery seja um serviço regional, os recursos de computação subjacentes podem, ocasionalmente, mudar de zona para balanceamento de carga. Como prática recomendada, ative o Rapid Cache para uma carga de trabalho do BigQuery em todas as zonas de uma região para garantir que haja um cache disponível para uso caso os recursos de computação subjacentes mudem de zona. Se um cache em uma zona não for usado, ele não vai gerar custos extras, já que o Rapid Cache é pago por uso. Se os recursos de uma carga de trabalho mudarem de zona, o cache na nova zona precisará ingerir os dados novamente, o que pode gerar um aumento único nos custos de ingestão de dados.

Criptografia de dados em cache

Os dados são armazenados no cache no formato original criptografado do lado do servidor, fornecendo compatibilidade com as opções de criptografia compatíveis com o Cloud Storage.

Limitações e restrições

• Para excluir um bucket, primeiro é necessário excluir todos os caches associados a ele. A única exceção é quando você exclui um bucket usando o console do Google Cloud , que exclui todos os caches associados junto com o bucket.

• Ao realizar operações de criação, desativação, retomada ou atualização de cache, limite a taxa de operações a não mais de uma operação por segundo. Realizar mais de uma operação por segundo pode resultar em falhas.

• O cache rápido não é um armazenamento durável, e os dados podem ser removidos do cache em vários cenários. Um cenário é quando o cache é redimensionado automaticamente para garantir que recursos suficientes estejam disponíveis para suas cargas de trabalho. Nesse cenário, alguns dados podem ser removidos de acordo com um algoritmo de uso mais recente (LRU, na sigla em inglês) até que o serviço de cache rápido termine de aumentar o tamanho do cache.

  Em qualquer caso, seus dados permanecem armazenados com segurança no bucket de origem. Quando os dados são removidos do cache por motivos que não sejam a expiração do TTL, o serviço Rapid Cache tenta reingerir os dados no cache de forma transparente e sem custo financeiro para você. Se os dados não puderem ser ingeridos novamente de forma transparente ou forem descartados devido ao vencimento do TTL, o serviço de cache rápido vai ingerir os dados novamente na primeira leitura.

• As recomendações e os insights gerados pelo recomendador do Rapid Cache não podem ser lidos usando o BigQuery.

Considerações sobre desempenho

• Falhas de bloco: se uma solicitação abranger vários blocos e alguns deles estiverem no cache enquanto outros não, o Rapid Cache vai recuperar de forma transparente os blocos ausentes do bucket de origem.

• TTL e remoção: as políticas de Time to Live (TTL) e remoção de dados usados menos recentemente (LRU) também operam em partes. As partes usadas com frequência de um arquivo grande podem permanecer no cache, enquanto as partes usadas com pouca frequência são removidas.

Preços

Para saber os preços de uso do Rapid Cache, consulte Preços do Rapid Cache.

Controle de custos

Confira as dicas a seguir para saber como minimizar os custos de execução de caches:

Seleção de bucket

Crie caches apenas para buckets que contenham dados que você quer armazenar em cache.

Seleção de zona

Crie caches apenas em zonas em que a carga de trabalho se beneficie do armazenamento em cache.

Configuração de TTL

Especifique o TTL mínimo necessário para armazenar dados no cache. O TTL pode ser alterado sem interrupções. O padrão é 1 dia.

Desativar o cache

É possível desativar um cache para removê-lo permanentemente do serviço e interromper o acúmulo de todas as taxas de cache associadas.

Solução de problemas de escassez temporária de recursos

As seções a seguir descrevem como resolver problemas quando ocorre uma escassez temporária de recursos, em que não há capacidade de SSD ou de veiculação suficiente em uma zona especificada para criar ou aumentar o tamanho ou o limite de largura de banda de um cache.

Falha ao criar um novo cache

O Rapid Cache pode falhar ao criar um novo cache em uma zona específica devido à falta de capacidade de SSD ou de recursos de exibição de capacidade, o que resulta em uma escassez temporária de recursos. Durante esse período, o Rapid Cache tenta criar o novo cache por até 48 horas. Se os recursos ficarem disponíveis dentro do período de 48 horas, o Rapid Cache concluirá a solicitação de criação de cache. Se os recursos não ficarem disponíveis dentro do período de 48 horas, a solicitação de criação do cache vai falhar.

Como resolver problemas: para evitar interrupções no armazenamento em cache, cancele manualmente a operação de criação de cache e crie um novo cache em uma zona diferente que possa ter capacidade disponível. Para monitorar ou cancelar uma operação de criação de cache, consulte Como usar operações de longa duração.

Não foi possível aumentar o tamanho do cache

O Rapid Cache pode não conseguir aumentar o tamanho de um cache quando a quantidade necessária de capacidade de SSD não está disponível na zona do cache.

Embora o Rapid Cache ofereça aumentos automáticos no tamanho do cache sob demanda, esses aumentos dependem da disponibilidade de capacidade do SSD. Se a capacidade do SSD não estiver disponível quando a solicitação de aumento automático do tamanho do cache for feita, o Rapid Cache continuará enviando a solicitação até que a escassez temporária de recursos termine ou um aumento no tamanho do cache não seja mais necessário.

Durante uma escassez temporária de recursos, novos dados são ingeridos e os dados existentes no cache são removidos com base no uso mais recente. Os caches grandes o suficiente para armazenar a maior parte dos dados quentes têm pouco ou nenhum impacto nas métricas de cache. Os caches com capacidade menor do que a quantidade de dados frequentemente acessados podem remover dados e ingerir novamente os mesmos dados com mais frequência do que os caches não afetados por escassez de recursos. Quando o tamanho real do cache é muito menor do que a capacidade necessária, você pode notar o seguinte comportamento relacionado à falta de recursos:

• Um limite de largura de banda de cache menor, uma capacidade de processamento de cache menor, um consumo maior de cota de largura de banda de transferência de dados e um possível impacto em outras métricas.
• O faturamento pode ser afetado das seguintes maneiras:
  • Aumento dos custos da taxa de ingestão de cache
  • Redução de custos da taxa de armazenamento em cache
  • Redução dos custos da taxa de saída de transferência de dados do cache
  • Redução de custos com as taxas de operação de transferência de dados para fora do cache
  • Aumento dos custos da taxa de transferência de dados multirregional
  • Aumento dos custos com o uso de operações de classe B

Para informações sobre essas taxas, consulte Preços do Rapid Cache.

Como resolver problemas: para ter os melhores resultados durante uma escassez temporária de recursos, recomendamos monitorar seus caches e desativar os caches ou cargas de trabalho desnecessários com base nas suas necessidades.

Falha ao escalonar verticalmente o limite de largura de banda de um cache

Uma escassez temporária no limite de largura de banda do cache pode ocorrer durante um aumento no tamanho do cache quando os recursos de capacidade de processamento em uma zona específica são insuficientes para escalonar o limite de largura de banda do cache de caches atuais em 20 Gbps por TiB. Durante uma escassez de largura de banda de cache disponível, o Rapid Cache não permite que o limite de largura de banda de cache seja escalonado em 20 Gbps por TiB de dados, mas o cache continua a atender às solicitações de leitura. Para solicitar mais largura de banda de cache, entre em contato com seu gerente técnico de contas ou representante do Google. Durante uma escassez de largura de banda de cache disponível, talvez você note um aumento no consumo de largura de banda de saída de dados do bucket.

Como resolver problemas: para melhores resultados durante uma escassez temporária de recursos, recomendamos monitorar seus caches e desativar caches ou cargas de trabalho desnecessários com base nas suas necessidades.

A seguir

• Criar e gerenciar caches.