Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Prepárese para el crecimiento
Cuando se utiliza correctamente el modelo de grupo, al final se supera el tamaño de un único cúmulo de Neptuno. Los inquilinos aumentan, o el número de inquilinos aumenta, y la tasa de ingesta de datos necesaria para todos sus clientes supera la capacidad del clúster. Cuando esto ocurra, tendrá que dividir a sus clientes en varios clústeres. Diseñe esta configuración por adelantado en lugar de intentar adaptarla más adelante. Incluso si su escala inicial consiste en utilizar un solo clúster, simule los componentes que necesitará para enrutar a los inquilinos entre varios clústeres en el futuro cuando alcance esa escala.
Si su solución requiere más recursos en función del tamaño del inquilino, prepárese también para su crecimiento. Si varios de los clientes de un solo clúster crecen de forma significativa, es posible que ese clúster deje de satisfacer sus necesidades. Diseñe una estrategia para mover a los inquilinos a otro clúster o dividir un clúster existente en dos mediante la función de clonación de Amazon Neptune DB.
Familiarícese con el Copy-on-Write Protocolo de Neptune, que puede ahorrarle dinero al implementar la clonación de bases de datos. Si divide un clúster debido a los cuellos de botella en la ingesta, podría ser más eficiente no eliminar los datos de los clústeres, siempre que sus políticas lo permitan. Los dos clústeres compartirán una página de datos si no ha cambiado, pero no si la página de datos se ha modificado (porque se han eliminado algunos de sus datos).
nota
Esta guía se aplica a la versión más reciente de Neptuno en el momento de escribir este artículo, que es la versión 1.3.1 de Neptuno. Esta guía podría cambiar en futuras versiones a medida que evolucione la capa de almacenamiento de Neptune.
Limitaciones de los escenarios de tenencia múltiple
Tenga en cuenta que algunas funciones de Neptune no están diseñadas para escenarios de tenencia múltiple. Los inquilinos no deberían tener acceso directo a los puntos finales de Neptune en un modelo de grupo porque estas estrategias de tenencia múltiple no se aplican a nivel de base de datos. Mantenga siempre algún tipo de intermediario entre sus clientes y el terminal Neptune que haga cumplir los diseños descritos en este documento. Entre los ejemplos de un proxy de este tipo se incluyen los siguientes:
-
Añadir los filtros de etiquetas a la capa de clientes
-
Tener una API que asigne el token de autenticación a un ID de inquilino e inyecte este filtro en la consulta
Esta guía también se aplica a la hora de ofrecer a los clientes acceso directo a funciones como las libretas gráficas Neptuno, el explorador gráfico Neptune o Neptune Streams.