Nesta página, descrevemos o Rapid Cache, um recurso que oferece um cache de leitura zonal com SSD para buckets do Cloud Storage que pode aumentar a capacidade de processamento e reduzir a latência dos seus 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 que retorna dados consistentes.
O Rapid Cache é útil para melhorar o desempenho de cargas de trabalho com muitas leituras 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 dessa zona são processadas pelo cache em vez do 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 objetos 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 tempo de vida (TTL) e o comportamento de ingestão na gravação de um cache ao criar ou atualizar o cache.
Vantagens
Ao armazenar em cache seus dados com o Rapid Cache, você tem os seguintes benefícios:
Acesse dados mais rápido: o Rapid Cache colocaliza 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 por um bucket no armazenamento padrão.
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.
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 fortemente 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 sua carga de trabalho está sendo executada, o cache 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 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 birregião 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.
Á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 local 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-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 apoio do Cloud Storage. À medida que o sistema entrega esses dados recuperados ao usuário, ele ingere simultaneamente os dados no cache.
Depois que essa primeira solicitação é concluída, os dados ficam no cache, permitindo que todas as leituras subsequentes sejam veiculadas diretamente do cache como ocorrências de cache de alta velocidade. Esse comportamento reduz significativamente a latência de leitura e acelera a recuperação de dados. Os dados ingeridos ficam no cache até que o TTL expire. Depois disso, eles são removidos do cache.
Para evitar a solicitação inicial lenta, você pode configurar o cache para ingerir dados na gravação, além de ingerir dados após a primeira leitura.
Ingestão de dados como partes
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.
Ingerir dados na gravação
Quando você configura 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. Quando a ingestão na gravação está ativada, os objetos que estão sendo gravados são ingeridos após a finalização da gravação. Os blocos de objetos individuais podem ser ingeridos antes da finalização do objeto inteiro.
A capacidade de ingestão na gravação remove as falhas iniciais de cache e permite que sua carga de trabalho se beneficie de um acerto imediato de cache 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 configurar um cache para ingerir dados na gravação ao criar ou atualizar um cache.
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 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 configurar o TTL de um cache ao criar ou atualizar um cache. É possível definir um TTL de 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
Nesta seção, descrevemos 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
É 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 no estado CREATING enquanto está sendo criado e entra no estado RUNNING quando começa a ser executado ativamente. Uma operação de criação de cache pode levar até 48 horas, após o que ela expira.
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 definir o TTL ou o comportamento de ingestão de dados de um cache ao atualizar o cache. Só é possível atualizar caches no estado EM EXECUÇÃO. 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.
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 os 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 máximo de esforço, 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 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. 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, oferecendo compatibilidade com as opções de criptografia compatíveis com o Cloud Storage.
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.
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 de remoção do 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.
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 veiculaçã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, 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 de 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 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.
Falha ao aumentar o tamanho do cache
O Rapid Cache pode não 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 ativos 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 dos 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 do 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.
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 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, 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.
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.