Multitenancy durante la distribuzione
- Logica di business completamente isolata (dedicato processo di business personalizzata del server)
- Application Server virtuale (server applicativo dedicato, VM singolo per server app)
- Condivise server virtuali (server applicativo dedicato il comune VM)
- Server applicativi condivisi (le discussioni e sessioni)
Questo spettro di diverse installazioni può essere visto qui:
Multitenancy e dati
- Dedicato server fisico (DB risiede in isolati host fisici)
- Shard ospite virtualizzato (DB separato su macchine virtuali)
- Database su host condiviso (DB separato sullo stesso host fisico)
- Schema dedicati all'interno di database condivisi (DB stesso, dedicato schema / tabella)
- Tabelle condivise (DB stesso schema, segregati dai tasti - righe)
Prima di saltare nella API, è importante capire come interno di Google memorizzazione dei dati di lavoro soluzione. L'introduzione di tecnologia di BigTable di Google: Si tratta di una soluzione di storage per le proprie applicazioni di Google come Search, Google Analytics, GMail, AppEngine, etc BigTable è NOT :
- Un database
- Un dato in orizzontale sharded
- Una tabella di hash distribuita
E ' IS : un rado, distribuito, persistente mappa multidimensionale ordinati. In termini di base, si tratta di una hash di hash (la mappa di mappe, o di un dict di dicts). AppEngine dati si trova in una "tabella" distribuiti su più computer. Ogni entità ha una chiave con cui è identificato in modo univoco (genitore + figlio ID +), ma c'è anche metadati che indica che l'applicazione GAE (appId) un'entità a cui appartiene.Dal grafico qui sopra, BigTable distribuisce i propri dati in un formato chiamato compresse, che sono sostanzialmente fette dei dati. Queste compresse vivono su diversi server in the cloud. Per indicizzare in uno specifico record (record e di entità più o meno significano la stessa cosa) si utilizza una stringa di 64 KB, chiamato Key. Questa chiave contiene informazioni sulla riga specifica e il valore della colonna che si desidera leggere. Esso contiene anche un timestamp per consentire più versioni dei dati da memorizzare. Inoltre, i record per un gruppo di entità specifico si trovano contiguo. Questo facilita la scansione dei record. Ora siamo in grado di tuffarsi come Google implementa multitenancy. implementato nella versione 1.3.6 di App Engine, l'API dei nomi (vedi risorse) è progettato per essere altamente personalizzabile, con ganci nel tuo codice che è possibile controllare, in modo da poter impostare multi-tenancy in base alle esigenze dell'applicazione. L'API funziona con tutte le pertinenti App Engine API (Datastore, Memcache, Blobstore e code Task). In termini Gae,
namespace == inquilino
A livello di storage di archivio dati, uno spazio dei nomi è proprio come un app-id. Ogni spazio dei nomi guarda essenzialmente al datastore come un altro in vista dei dati dell'applicazione. Quindi, le query non possono estendersi su spazi dei nomi (almeno per ora) e intervalli di chiavi sono diverse per spazio dei nomi. Una volta che un ente è stato creato, lo spazio dei nomi non cambia, in modo da fare una
namespace_manager.set (...)non avrà alcun effetto sulla sua chiave. Allo stesso modo, una volta che una query è stato creato, lo spazio dei nomi viene impostato. Stessa cosa con
memcache_service ()e tutti gli altri APIS GAE. Quindi è importante sapere quali oggetti avere quale namespace. Nella mia mente, dal momento che tutte le vite di dati utente GAE ha a BigTable, aiuta a visualizzare un oggetto GAE chiave come: ID Application | Keys antenati | Nome Tipo | Nome chiave o ID Tutte queste valori di fornire un indirizzo per individuare i dati dell'applicazione. Allo stesso modo, si può immaginare la chiave multi-tenant come: Application ID | | Spazio dei nomi degli antenati Keys | Nome Tipo | Nome chiave o ID Ora brevemente l'API (Python):| Nome Funzione | Argomenti | API |
|---|---|---|
| get_namespace | Nessuno | Restituisce lo spazio dei nomi corrente, o restituisce una stringa vuota se lo spazio dei nomi non è impostata. |
| set_namespace | namespace: Un valore di valore vengono annullati Nessuno spazio dei nomi predefinito.In caso contrario, ([0-9A-Za-z._-] {0100}) | Imposta lo spazio dei nomi per la richiesta HTTP corrente |
| validate_namespace | valore: stringa che contiene lo spazio dei nomi in corso di valutazione. Aumenta il BadValueError se non ([0-9A-Za-z._-] {0100}).eccezione = BadValueError | Solleva l'eccezione BadValueError se la stringa spazio dei nomi non è valido. |
Ecco un esempio veloce:
01.tid = getTenant ()02. 03.namespace = namespace_manager.get_namespace ()04. 05.cercare :06.namespace_manager.set_namespace ( '-tenant' + str (tid))07. 08.N. Tutte le operazioni di datastore fatto qui09.user = Utente ( 'Luis' , 'Atencio' )10.user.put ()11. 12.infine :13. 14.# Ripristina lo spazio dei nomi salvato 15.namespace_manager.set_namespace (namespace)La cosa importante da notare è il modello che fornisce GAE. Sarà la stessa identica cosa per le API Java.La fine del blocco è immensamente importante in quanto ripristina lo spazio dei nomi a ciò che era in origine (prima della richiesta). Omettendo la fine del blocco causerà lo spazio dei nomi da impostare per la durata della richiesta. Ciò significa che l'accesso API se si tratta di query datastore o recupero Memcache utilizzeranno lo spazio dei nomi precedentemente impostato. Inoltre, per eseguire una query per tutti i domini creati, GAE fornisce alcune query meta, in quanto tale:
01.da google.appengine.ext.db.metadata import Namespace02. 03.q = Namespace.all (). 04se start_ns:05.q.filter ( '__key__> =' , Namespace.key_for_namespace (start_ns))06.ifend_ns:07.q.filter ( '__key__ <=' , Namespace.key_for_namespace (end_ns))08. 09.risultati = q.fetch (limite)10.# Ridurre gli oggetti dello spazio dei nomi in una lista di nomi dei namespace11.inquilini = map (lambda ns: ns.namespace_name, risultati)12.ritorno inquilini
Nessun commento:
Posta un commento
Nota. Solo i membri di questo blog possono postare un commento.