La tua piattaforma SaaS ospita 200 piccoli database per tenant. Ogni tenant sperimenta picchi di attività brevi e imprevedibili, mentre l'utilizzo aggregato rimane moderato. Vuoi ridurre al minimo i costi di calcolo, utilizzare gli sconti sulla capacità riservata ed evitare di gestire lo scaling per ogni database. Quale distribuzione dovresti scegliere?

La risposta corretta è un pool elastico di Azure SQL Database basato su vCore (General Purpose). Questo approccio è ideale per carichi di lavoro multi-tenant con picchi imprevedibili, poiché consente di condividere le risorse di calcolo tra tutti i database, ottimizzando i costi e permettendo l'uso di sconti per capacità riservata. La configurazione min/max per ogni database all'interno del pool garantisce che ogni tenant riceva le risorse necessarie durante i picchi, senza la necessità di gestire lo scaling individuale. Le altre opzioni sono meno adatte: Un singolo Azure SQL Database serverless per tenant con sospensione automatica sarebbe costoso a causa dei 200 database individuali e non beneficerebbe appieno degli sconti sulla capacità riservata. Un'istanza gestita di Azure SQL non è ottimizzata per la condivisione elastica delle risorse tra database piccoli e numerosi. I database Premium basati su DTU non offrono la flessibilità e l'ottimizzazione dei costi dei vCore per questo scenario. Un singolo database Hyperscale con sharding non è l'ideale per 200 database piccoli e separati, in quanto introduce complessità di gestione e non sfrutta la condivisione elastica delle risorse tra database distinti.