As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Prepare-se para o crescimento
Quando você usa o modelo de pool com sucesso, você acaba superando o tamanho de um único cluster de Neptune. Os inquilinos crescem, ou o número de inquilinos aumenta, e a taxa de ingestão de dados necessária em todos os seus clientes excede a capacidade do cluster. Quando isso ocorrer, você precisará dividir seus clientes em vários clusters. Projete essa configuração com antecedência, em vez de tentar adaptá-la posteriormente. Mesmo que sua escala inicial seja usar apenas um único cluster, simule os componentes que você precisará para rotear locatários em vários clusters no futuro quando atingir essa escala.
Se sua solução exigir mais recursos com base no tamanho do seu inquilino, prepare-se também para o crescimento dele. Se vários clientes em um único cluster crescerem significativamente, esse cluster pode não atender mais às suas necessidades. Crie uma estratégia para mover inquilinos para outro cluster ou dividir um cluster existente em dois usando o recurso de clonagem do Amazon Neptune DB.
Familiarize-se com o Protocolo Copy-on-Write Neptune, que pode economizar dinheiro ao implementar a clonagem de banco de dados. Se você dividir um cluster devido a gargalos de ingestão, talvez seja mais eficiente não excluir dados dos clusters, desde que suas políticas permitam isso. Os dois clusters compartilharão uma página de dados se ela não for alterada, mas não se a página de dados tiver sido modificada (porque alguns dados nela foram excluídos).
nota
Esta orientação se aplica à versão mais recente do Netuno no momento da redação deste artigo, que é a versão 1.3.1 do Netuno. Essa orientação pode mudar em versões futuras à medida que a camada de armazenamento Neptune evolui.
Limitações para cenários de multilocação
Esteja ciente de que alguns recursos do Neptune não foram criados para cenários de multilocação. Os inquilinos não devem ter acesso direto aos endpoints do Neptune em um modelo de pool porque essas estratégias de multilocação não são aplicadas no nível do banco de dados. Sempre mantenha algum tipo de proxy entre seus clientes e o endpoint Neptune que aplique os designs descritos neste documento. Exemplos desse proxy incluem o seguinte:
-
Anexando os filtros de etiquetas na sua camada de cliente
-
Ter uma API que mapeia o token de autenticação para um ID de inquilino e injeta esse filtro na consulta
Essa orientação também se aplica ao fornecimento de acesso direto aos clientes a recursos como os notebooks gráficos Neptune, o Neptune Graph-Explorer ou o Neptune Streams.