Esta página descreve o Rapid Cache, um recurso que fornece um cache de leitura zonal com suporte de SSD para buckets do Cloud Storage, permitindo que você tenha mais capacidade de processamento e menor latência nos seus dados armazenados. O Rapid Cache oferece capacidade de armazenamento e largura de banda que são escalonar verticalmente verticalmente de forma automática de acordo com suas necessidades.
Devido aos benefícios, o Rapid Cache ajuda a melhorar o desempenho e reduzir os custos de rede associados a cargas de trabalho com muitas leituras.
Consulte Criar e gerenciar caches para saber como criar e gerenciar caches no Rapid Cache.
Como 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 dessa zona são processadas pelo cache em vez do bucket. Cada cache atende clientes na mesma zona que ele. Os dados só serão inseridos no cache do seu bucket quando forem lidos por uma VM que esteja na mesma zona que o cache. Além disso, os dados podem ser ingeridos quando são gravados no bucket se você configurar a ingestão na gravação. Os metadados não são armazenados em cache, e as solicitações de metadados de objetos são processadas pelo bucket em vez do cache.
O Rapid Cache é um serviço totalmente gerenciado e sempre retorna dados consistentes.
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 escalonar verticalmente ou horizontalmente automaticamente 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 seu gerente técnico de contas ou 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.
Como armazenar 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, você poderá criar um cache em us-east1-b, mas não em us-central1-c. Se o bucket estiver localizado na birregional ASIA, você poderá
criar um cache em qualquer uma das zonas que compõem 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, você poderá criar um cache em us-east1-b e outro em us-east1-c. Se um bucket estiver 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 ficar 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 seu bucket.
| Área geográfica | Local | ||||
|---|---|---|---|---|---|
| Nome da zona | Região | Birregional | Multirregional | Birregião personalizada | |
| Ásia | |||||
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 | |||||
europe-north1-a |
|||||
europe-north1-b |
|||||
europe-north1-c |
|||||
europe-west1-b |
|||||
europe-west1-c |
|||||
europe-west1-d |
|||||
europe-west4-a |
|||||
europe-west4-b |
|||||
europe-west4-c |
|||||
europe-west6-a |
|||||
europe-west6-b |
|||||
| Estados Unidos | |||||
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-west3-a |
|||||
us-west3-b |
|||||
us-west3-c |
|||||
us-west4-a |
|||||
us-west4-b |
|||||
us-west4-c |
|||||
Ingestão de dados
Os dados são sempre ingeridos no cache quando são acessados pela primeira vez em um bucket. A primeira leitura é disponibilizada como uma ausência no cache, e as leituras subsequentes são disponibilizadas como ocorrências em cache, acelerando as leituras de dados. Você também pode configurar um cache para ingerir dados na gravação e evitar a ausência inicial no cache. Isso beneficia casos de uso como a restauração de pontos de verificação ou a preparação de pipelines de dados para treinamento de modelos.
Ao ingerir dados em um cache, o Rapid Cache divide os objetos em pedaços 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 uma solicitação é feita para um objeto, o Rapid Cache identifica quais partes de 2 MB cobrem o intervalo de bytes solicitado e gerencia essas partes 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.
Configuração do cache
É possível definir as seguintes propriedades ao configurar um cache:
Time to live (TTL)
O TTL é o tempo máximo que um bloco de dados vai permanecer no cache desde a última leitura. Por exemplo, se o TTL for definido como 24 horas, um bloco de dados 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 um TTL entre 24 horas e 7 dias. Se não for especificado, o TTL será de 24 horas por padrão.
Ingerir na gravação
A ingestão de dados no cache durante a gravação de objetos acelera as cargas de trabalho de leitura após gravação, como checkpoint e saída de preparação de dados para um job de treinamento. Quando você configura um cache para ingerir dados na gravação, os dados são gravados no cache à medida que são enviados para o bucket. Essa abordagem proativa remove ausências iniciais no cache e permite que suas cargas de trabalho se beneficiem de uma ocorrência imediata em cache na primeira leitura.
A ingestão na gravação pode ser ativada opcionalmente ao atualizar os critérios de ingestão de um cache atual. Não é possível configurar isso durante a criação inicial do cache.
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 menos recentemente usado (LRU) também operam em partes. 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 informações sobre preços 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 sua carga de trabalho se beneficiará 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 associadas.
Vantagens
Ao armazenar seus dados em cache com o Rapid Cache, você tem os seguintes benefícios:
Acesse dados mais rapidamente: o Rapid Cache aloca seus dados na mesma zona dos recursos de computação e é totalmente compatível com SSD. Isso permite que suas cargas de trabalho tenham até 2,5 TB/s de capacidade 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 para buckets em 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.
Ajuste automático do tamanho do cache: o cache dinâmico de SSD do Rapid Cache é dimensionado automaticamente com base no uso, sem que você precise especificar um tamanho de cache.
Use caches de maneira eficiente: o Rapid Cache pode ser ativado em buckets existentes sem exigir mudanças nos aplicativos ou APIs atuais. Os dados armazenados no Rapid Cache são altamente consistentes.
Para 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 seus 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.
Como usar o Rapid Cache para acelerar as leituras do BigQuery
O Rapid Cache pode ser usado para veicular dados para solicitações de leitura de objetos emitidas pelo BigQuery. Com o Rapid Cache, é possível acelerar as leituras de dados dos aplicativos e otimizar a eficiência de custos.
Embora o BigQuery seja um serviço regional, os recursos de computação subjacentes podem mudar ocasionalmente entre zonas 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. Observe que, 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.
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 de dados e armazenamento. Para informações gerais e instruções sobre como usar o recomendador do Rapid Cache, consulte Recomendador do Rapid Cache.
Operações de cache
Esta seção descreve as operações que podem ser realizadas 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
Quando você cria um cache, ele entra no estado CREATING enquanto está sendo criado e entra no estado RUNNING quando começa a ser executado ativamente. A operação de criação de cache pode levar até 48 horas. Depois disso, ela vai expirar.
A API AnywhereCaches Create é 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.
Atualizar um cache
É possível atualizar o TTL ou o comportamento de ingestão de um cache no estado RUNNING. 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.
Não é possível atualizar um cache no estado CREATING ou DISABLED. A API AnywhereCaches Update é assíncrona e retorna uma operação de longa duração.
Quando o TTL de um cache termina de ser atualizado, o novo TTL é aplicado imediatamente aos dados atuais e novos no cache.
Receber 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 remover permanentemente o cache da configuração do bucket. Quando você desativa um cache, ele entra no estado DISABLED. Durante esse estado, ainda é possível ler dados atuais do cache, mas não ingerir novos dados nele.
Depois de desativar um cache, há um período de carência de uma 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 uma 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 Resume do AnywhereCaches é síncrona e retorna um recurso AnywhereCache.
Limitações e restrições
Para excluir um bucket, primeiro é preciso excluir todos os caches associados a ele. A única exceção é quando um bucket é excluído usando o console do Google Cloud , que exclui todos os caches associados junto com o bucket.
Ao realizar as operações de criação, desativação, retomada ou atualização do 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 menos usados recentemente (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 diferentes da expiração do TTL, o serviço de cache rápido tenta ingerir os dados novamente no cache de forma transparente e sem custo 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.
Solução de problemas de escassez temporária de recursos
As seções a seguir descrevem como solucionar problemas quando ocorre uma escassez temporária de recursos, em que não há capacidade de SSD ou de serviço suficiente em uma zona especificada para criar um cache, aumentar o tamanho ou o limite de largura de banda dele.
Falha ao criar um novo cache
O Rapid Cache pode não criar um novo cache em uma zona específica devido à falta de capacidade de SSD ou recursos de veiculação de capacidade de processamento, 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 vai concluir a solicitação de criação do cache. Se os recursos não ficarem disponíveis dentro do período de 48 horas, a solicitação de criação de cache vai falhar.
Como resolver problemas: para evitar interrupções no seu cache, cancele manualmente a operação de criação 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 vai 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 atuais no cache são removidos com base no uso menos recente. Caches grandes o suficiente para armazenar a maioria dos dados quentes têm pouco ou nenhum impacto nas métricas de cache. Caches com menos capacidade do que a quantidade de dados ativos podem desalojar e ingerir os mesmos dados com mais frequência do que 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 mais baixo, menor capacidade de processamento de cache, maior consumo 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 nos custos da taxa de ingestão de cache
- Custos reduzidos da taxa de armazenamento em cache
- Redução de custos da taxa de saída de transferência de dados do cache
- Redução dos custos das taxas de operação de transferência de dados de cache
- Aumento dos custos devido à taxa de transferência de dados multirregional
- Aumento dos custos devido ao uso de operações de classe B
Para informações sobre essas taxas, consulte Preços do Rapid Cache.
Solução de problemas: para ter os melhores resultados durante uma escassez temporária de recursos, recomendamos monitorar seus caches e desativar os desnecessários ou cargas de trabalho com base nas suas necessidades.
Falha ao escalonar verticalmente o limite de largura de banda de um cache
Uma escassez temporária de 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 dimensionar 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 atendendo à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.
Solução de 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.