Implementare la multi-tenancy
In Milvus, multi-tenancy significa che più clienti o team, detti tenant,condividono lo stesso cluster mantenendo ambienti di dati isolati.
Milvus supporta quattro strategie di multi-tenancy, ognuna delle quali offre un diverso compromesso tra scalabilità, isolamento dei dati e flessibilità. Questa guida illustra ogni opzione, aiutandovi a scegliere la strategia più adatta al vostro caso d'uso.
Strategie multi-tenancy
Milvus supporta la multi-tenancy a quattro livelli: Database, Collezione, Partizione e Chiave di partizione.
Multi-tenancy a livello di database
Con la multi-tenancy a livello di database, ogni tenant riceve un database corrispondente contenente una o più collezioni.
Multitenancy a livello di database
Scalabilità: La strategia di multi-tenancy a livello di database supporta un massimo di 64 tenant per impostazione predefinita.
Isolamento dei dati: I dati di ciascun database sono completamente separati, offrendo un isolamento dei dati di livello aziendale ideale per gli ambienti regolamentati o per i clienti con esigenze di conformità rigorose.
Flessibilità: Ogni database può avere collezioni con schemi diversi, offrendo un'organizzazione dei dati altamente flessibile e consentendo a ogni tenant di avere il proprio schema di dati.
Altri: Questa strategia supporta anche RBAC, consentendo un controllo a grana fine sull'accesso degli utenti per tenant. Inoltre, è possibile caricare o rilasciare in modo flessibile i dati per tenant specifici, per gestire efficacemente i dati caldi e freddi.
Multi-tenancy a livello di collezione
Con la multi-tenancy a livello di collezione, a ogni tenant viene assegnata una collezione, offrendo un forte isolamento dei dati.
Multitenancy a livello di collezione
Scalabilità: Poiché un cluster può contenere fino a 65.536 collezioni per impostazione predefinita, questa strategia può ospitare lo stesso numero di tenant all'interno del cluster.
Isolamento dei dati: Le collezioni sono fisicamente isolate l'una dall'altra. Questa strategia garantisce un forte isolamento dei dati.
Flessibilità: Questa strategia consente a ogni raccolta di avere il proprio schema, per accogliere tenant con schemi di dati diversi.
Altri: Questa strategia supporta anche RBAC, consentendo un controllo granulare dell'accesso ai tenant. Inoltre, è possibile caricare o rilasciare in modo flessibile i dati per tenant specifici, per gestire efficacemente i dati caldi e freddi.
Multi-tenancy a livello di partizione
Nella multi-tenancy a livello di partizione, ogni tenant viene assegnato a una partizione creata manualmente all'interno di una raccolta condivisa.
Multitenancy a livello di partizione
Scalabilità: Una raccolta può contenere fino a 1.024 partizioni per raccolta, consentendo lo stesso numero di tenant al suo interno.
Isolamento dei dati: I dati di ciascun tenant sono fisicamente separati da partizioni.
Flessibilità: Questa strategia richiede che tutti i tenant condividano lo stesso schema di dati. E le partizioni devono essere create manualmente.
Altri: RBAC non è supportato a livello di partizione. I tenant possono essere interrogati singolarmente o su più partizioni, il che rende questo approccio adatto a scenari che prevedono query aggregate o analisi su segmenti di tenant. Inoltre, è possibile caricare o rilasciare in modo flessibile i dati per tenant specifici, per gestire efficacemente i dati caldi e freddi.
Multi-tenancy a livello di chiave di partizione
Con questa strategia, tutti i tenant condividono un'unica raccolta e un unico schema, ma i dati di ciascun tenant vengono automaticamente instradati in 16 partizioni fisicamente isolate in base al valore della chiave di partizione. Anche se ogni partizione fisica può contenere più tenant, i dati dei diversi tenant rimangono logicamente separati.
Livello della chiave di partizione Multi Tenancy
Scalabilità: La strategia a livello di chiave di partizione offre l'approccio più scalabile, in grado di supportare milioni di tenant.
Isolamento dei dati: Questa strategia offre un isolamento dei dati relativamente debole, perché più tenant possono condividere una partizione fisica.
Flessibilità: Poiché tutti i tenant devono condividere lo stesso schema di dati, questa strategia offre una flessibilità limitata.
Altri: Il RBAC non è supportato a livello di chiavi di partizione. I tenant possono essere interrogati singolarmente o su più partizioni, il che rende questo approccio adatto a scenari che prevedono query aggregate o analisi su segmenti di tenant.
Scegliere la giusta strategia multi-tenancy
La tabella seguente offre un confronto completo tra i quattro livelli di strategie multi-tenancy.
Livello di database |
Livello di raccolta |
A livello di partizione |
Livello di chiave della partizione |
|
|---|---|---|---|---|
Isolamento dei dati |
Fisico |
Fisico |
Fisico |
Fisico + logico |
Numero massimo di locatari |
Per impostazione predefinita, 64. È possibile aumentarlo modificando il parametro |
Per impostazione predefinita, 65.536. È possibile aumentarlo modificando il parametro |
Fino a 1.024 per collezione. |
Milioni |
Flessibilità dello schema dei dati |
Alta |
Media |
Bassa |
Basso |
Supporto RBAC |
Sì |
Si |
No |
No |
Prestazioni di ricerca |
Forte |
Forte |
Medio |
Medio |
Supporto per la ricerca cross-tenant |
No |
No |
Si |
Sì |
Supporto per la gestione efficace dei dati caldi e freddi |
Sì |
Sì |
Sì |
No Attualmente non è supportata la strategia a livello di chiave di partizione. |
Ci sono diversi fattori da considerare quando si sceglie la strategia multi-tenancy in Milvus.
Scalabilità: Chiave di partizione > Partizione > Raccolta > Database
Se si prevede di supportare un numero molto elevato di tenant (milioni o più), utilizzare la strategia a livello di chiave di partizione.
Forti requisiti di isolamento dei dati: Database = Collezione > Partizione > Chiave di partizione
Scegliete le strategie a livello di database, di raccolta o di partizione se avete requisiti rigidi di isolamento fisico dei dati.
Schema di dati flessibile per i dati di ciascun tenant: Database > Raccolta > Partizione = Chiave di partizione
Le strategie a livello di database e di raccolta offrono la massima flessibilità negli schemi dei dati. Se le strutture dei dati dei tenant sono diverse, scegliete la multi-tenancy a livello di database o di collezione.
Altri
Prestazioni: Le prestazioni della ricerca sono determinate da vari fattori, tra cui gli indici, i parametri di ricerca e le configurazioni della macchina. Milvus supporta anche il tuning delle prestazioni. Si consiglia di testare le prestazioni effettive prima di scegliere una strategia multi-tenancy.
Gestione efficace dei dati caldi e freddi: Attualmente, le strategie a livello di database, di raccolta e di partizione supportano tutte la gestione dei dati caldi e freddi.
Ricerche cross-tenant: Solo le strategie a livello di partizione e di chiave di partizione supportano le query cross-tenant.
