Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà. # Multi-tenancy modello pool A volte non è necessario o fattibile implementare il modello a silo a causa dei costi o delle spese operative: + Potresti non avere le risorse per gestire un singolo cluster per tenant. + Potrebbe non essere necessario separare fisicamente i dati di ciascun tenant e una separazione logica è sufficiente per soddisfare le loro esigenze e i requisiti di conformità. Il diagramma seguente mostra il modello di pool, con i dati dei tenant collocati in un singolo cluster Amazon Neptune e tutti i tenant condividono un database comune. ![L'architettura include IAM e una politica dei tenant.](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/multi-tenancy-amazon-neptune/images/pool-model.png) Questo [modello di isolamento del pool](https://docs.aws.amazon.com/whitepapers/latest/saas-tenant-isolation-strategies/pool-isolation.html) riduce il sovraccarico di gestione e può migliorare l'efficienza operativa perché ci sono meno cluster da gestire. Inoltre, le risorse di elaborazione possono essere condivise tra più clienti anziché rimanere inattive durante i periodi di inattività dei clienti. Quando si utilizza il modello pool, esistono due modi per modellare i dati. Il tuo approccio dipende dal fatto che tu stia creando un grafico delle [proprietà etichettate (LPG) o un grafico](pool-model-lpg.md) con il [Resource Description Framework (RDF](pool-model-rdf.md)).