| Entrambe le parti precedenti la revisioneRevisione precedenteProssima revisione | Revisione precedente |
| documentazione_3di_riservata:extraway_ee:storage [2019/04/10 18:13] – [Esempi] rtirabassi | documentazione_3di_riservata:extraway_ee:storage [Data sconosciuta] (versione attuale) – eliminata - modifica esterna (Data sconosciuta) 127.0.0.1 |
|---|
| ====== Uso degli Storage da parte di eXtraWay Server ====== | |
| |
| Con la versione Enterprise di eXtraWay Server è stato introdotto l'utilizzo di Storage Esterni.\\ | |
| Essi assolvono a tre diversi compiti: | |
| * Conservazione di informazioni riferite ai singoli utenti, con particolare accezione dei loro eventuali diritti applicativi e funzionali. | |
| * Conservazione degli allegati d'archivio su Storage Server al posto del __file system__ usato di default. | |
| * Conservazione dei record di Metadati al posto dei file XML di default. | |
| |
| Vediamo i seguenti casi e le relative configurazioni. | |
| |
| ===== Informazioni utente ===== | |
| Per la registrazione delle informazioni utente, il server eXtraWay si avvale di un semplice [[https://en.wikipedia.org/wiki/Lightning_Memory-Mapped_Database|LMBD]] che trova collocazione in una delle cartelle di servizio di eXtraWay. Anche se si tratta di una componente pressoché fissa, essa è configurata come tutti gli altri Storage, perché possa essere sostituita al bisogno.\\ | |
| |
| Rientra nella configurazione delle ''caches'' usate da eXtraWay, e non in quella degli ''storages''. | |
| ===== Allegati su Storage Server ===== | |
| |
| ===== Record su Storage ===== | |
| |
| ===== Configurazione ===== | |
| |
| |
| La configurazione di ''caches'' e ''storages'' utilizzati da eXtraWay si trova nel file ''storage.conf.xml'' collocato nella cartella...\\ | |
| {{:documentazione_3di_riservata:extraway_ee:linux.png?25|}} ''/opt/3di.it/extraway/xwee/conf''\\ | |
| {{:documentazione_3di_riservata:extraway_ee:windows.jpg?25|}} ''<drive>:\3di.it\extraway\xwee\conf''\\ | |
| |
| Esso si compone di diverse sezioni. | |
| |
| ==== caches e storages ==== | |
| Gli Storage utilizzati assolvono a due scopi: Fungere da [[#informazioni_utente|cache di dati utili ad eXtraWay]] ovvero essere veri e propri contenitori di [[#record_su_storage_server|metadati]] o [[#allegati_su_storage_server|allegati]]. | |
| |
| Per la prima tipologia, le ''caches'' esiste un apposita sezione che contiene uno o più elementi ''cache''.\\ | |
| Per ciascuno di essi si deve compilare una configurazione: | |
| * '@id': Identificatore che consente ad eXtraWay Server di riconoscere la configurazione di quale ''cache'' sta accedendo. <wrap rounded alert>Obbligatorio</wrap> | |
| * '@persistor': Identificatore del [[#persistors|persistor]] che si utilizzerà per questa cache. <wrap rounded alert>Obbligatorio</wrap> | |
| * '@expiry_secs': numero di secondi trascorsi i quali il dato conservato nella cache si considera non più valido. <wrap rounded info>Facoltativo. Default: 24 ore</wrap> | |
| |
| La seconda tipologia, gli ''storages'', racchiude uno o più elementi ''storage''.\\ | |
| Per ciascuno di essi si deve compilare una configurazione: | |
| * '@id': Identificatore dello storage che si desidera utilizzare. Il legame che si costituisce con questi storage è registrato nei file di configurazione d'archivio. <wrap rounded alert>Obbligatorio</wrap> | |
| * '@persistor': Identificatore del [[#persistors|persistor]] che si utilizzerà per questo storage. <wrap rounded alert>Obbligatorio</wrap> | |
| |
| Si vedano gli [[#esempi|esempi]] per maggior dettaglio. | |
| ==== persistors ==== | |
| È l'elenco di tutti i ''persistor'' e quindi di ciascuno strumento di storage. La forma assunta da ciascuno di essi, vale a dire le impostazioni in esso contenute sotto forma di elementi ed attributi, varia a seconda della sua tipologia. | |
| |
| Ciascun ''persistor'' si caratterizza per mezzo di tre attributi: | |
| * '@name': il nome del ''persistor'' così come utilizzato nella sezione [[#cache_e_storages| delle cache e degli storages]] | |
| * '@class': la classe del ''persistor'' da utilizzare per questo storage, da essa dipendono le configurazioni di dettaglio | |
| * '@policy': il [[#policies|comportamento atteso]] per il ''persistor'', riferito principalmente a come i record debbano essere salvati e così via. | |
| |
| Le classi attualmente disponibili sono: | |
| * **xw::strg::persistor_lmdb**: Persistor basato su LMBD. | |
| * **xw::strg::persistor_mongo**:Persistor basato su MongoDB. | |
| |
| Si vedano gli [[#esempi|esempi]] per maggior dettaglio. | |
| ==== policies ==== | |
| Elenco delle diverse tipologie comportamentali per i vari ''persistors''.\\ | |
| Ciascuna ''policy'' è riconosciuta per mezzo di un attributo '@name' che la qualifica. Al suo interno avremo alcuni elementi atti ad indicare le diverse caratteristiche. | |
| |
| * **update_existing_only**: Quando si richiede l'aggiornamento di un record nello Storage, ma il record con la chiave indicata non esiste, lo Storage deve: | |
| * Tornare errore in quanto la chiave richiesta non esiste quando il valore dell'attributo è **true**. | |
| * Consentire il salvataggio del record con la chiave indicata quando il valore dell'attributo è **false**. | |
| * **generate_auto_key**: Quando si procede al salvataggio di un record nuovo senza indicare una chiave per il detto record, lo Storage deve: | |
| * Tornare errore in quanto la chiave non è stata indicata quando il valore dell'attributo è **false**. | |
| * Consentire il salvataggio del record generando (e tornando) una chiave univoca quando il valore dell'attributo è **true**. | |
| |
| Il più classico degli esempi è il seguente:\\ | |
| * Per uno storage di tipo ''cache'' è necessario che la chiave con la quale si registra un record sia sempre esplicitata mentre l'aggiornamento di una chiave inesistente è tollerabile e si trasforma, in pratica, in inserimento. | |
| * Per uno storage di metadati non è ammesso modificare record inesistenti mentre è lecito (ed anzi normale) che la chiave di un nuovo record venga generata dal ''peristor'' prescelto. | |
| * Per uno storage di allegati si opera esattamente all'opposto: è ammesso aggiornare un allegato non esistente (quindi inserirlo) ma la chiave con la quale lo si genera dev'essere sempre esplicitata in quanto viene calcolata da eXtraWay. | |
| |
| Si vedano gli [[#esempi|esempi]] per maggior dettaglio. | |
| |
| ==== Esempi ==== | |
| Di seguito un esempio "commentato" di file di configurazione.\\ | |
| <code xml> | |
| <?xml version="1.0"?> | |
| <config> | |
| <policies> | |
| <policy name="default"> | |
| <!-- Politica di base, minimale. | |
| Si aggiorna solo quello che esiste, ma una chiave non dichiarata viene generata. | |
| --> | |
| <update_existing_only>true</update_existing_only> | |
| <generate_auto_key>true</generate_auto_key> | |
| </policy> | |
| |
| <policy name="db_mode_policy"> | |
| <!-- Politica per Storage di METADATI. | |
| Si aggiorna solo quello che esiste, ma una chiave non dichiarata viene generata. | |
| --> | |
| <update_existing_only>true</update_existing_only> | |
| <generate_auto_key>true</generate_auto_key> | |
| </policy> | |
| |
| <policy name="media_mode_policy"> | |
| <!-- Politica per Storage di ALLEGATI. | |
| Si opera in 'upsert' ma la chiave va sempre dichiarata. | |
| --> | |
| <update_existing_only>false</update_existing_only> | |
| <generate_auto_key>false</generate_auto_key> | |
| </policy> | |
| | |
| <policy name="lmdb_cache_policy"> | |
| <!-- Politica per CACHE. | |
| Si opera in 'upsert' ma la chiave va sempre dichiarata. | |
| --> | |
| <update_existing_only>false</update_existing_only> | |
| <generate_auto_key>false</generate_auto_key> | |
| </policy> | |
| </policies> | |
| | |
| <persistors> | |
| <!-- Persistor per la CACHE. Usa la 'lmdb_cache_policy' --> | |
| <persistor name="eXtraWayUsers_persistor" class="xw::strg::persistor_lmdb" policy="lmdb_cache_policy">> | |
| <path>/var/lib/3di.it/usersData</path> | |
| </persistor> | |
| |
| <!-- Persistor per Record. Usa una polcy adatta e registra i record su mongo. | |
| Il nome della collection viene imposto da eXtraWay | |
| --> | |
| <persistor name="dcwData" class="xw::strg::persistor_mongo" policy="db_mode_policy"> | |
| <host>localhost</host> <!-- Url di connessione in modalità MongoDB --> | |
| <dbname>dcwRecords</dbname> | |
| <!-- | |
| Vedasi la documentazione MongoDB https://docs.mongodb.com/manual/reference/write-concern/ | |
| --> | |
| <write_concern w="1" j="true" wtimeout="0" /> | |
| </persistor> | |
| <!-- Persistor per Allegati. Usa una polcy adatta e registra i record su mongo. | |
| Il nome della collection è lo stesso usato dallo Storage Server ed idem il nome del DB | |
| --> | |
| <persistor name="dcwMedia" class="xw::strg::persistor_mongo" policy="media_mode_policy"> | |
| <host>localhost</host> <!-- Url di connessione in modalità MongoDB --> | |
| <dbname>content_storage</dbname> | |
| <!-- | |
| Vedasi la documentazione MongoDB https://docs.mongodb.com/manual/reference/write-concern/ | |
| --> | |
| <write_concern w="1" j="true" wtimeout="0" /> | |
| </persistor> | |
| </persistors> | |
| |
| <caches> | |
| <cache id="usersData" persistor="eXtraWayUsers_persistor" expiry_secs="1800"/> | |
| </caches> | |
| | |
| <storages> | |
| <storage id="dcwData" persistor="dcwData"/> | |
| <storage id="dcwMedia" persistor="dcwMedia"/> | |
| </storages> | |
| </config> | |
| </code> | |
| |
| Al fine di far uso dell'uno o dell'altro tipo di Storage, i file di configurazione dell'archivio eXtraWay deve essere modificato prevedendo quanto segue: | |
| |
| ** Uso dello storage per METADATI** <wrap rounded info>eXtraWAy EE 2.0.0 e superiori</wrap> | |
| <code xml> | |
| <storage id="dcwData"/> | |
| <code> | |
| |
| ** Uso dello storage per ALLEGATI** <wrap rounded info>eXtraWAy EE 1.6.0 e superiori</wrap> | |
| <code xml> | |
| <mediaStorage id="dcwMedia" parkInStorage="false" keepTextLocally="true"/> <!-- default values --> | |
| <code> | |
| |
| In particolare, questa configurazione ci dice, oltre all'identificatore dello ''storage'' che si intende utilizzare e che è configurato nel file ''storage.conf.xml'' anche alcune impostazioni che intendiamo dare ad esso.\\ Nello specifico abbiamo: | |
| * parkInStorage: Il server eXtraWay opera solitamente in questo modo. Quando gli viene dato un nuovo allegato lo colloca in una zona detta //area di parcheggio//. Assegna al file un ID univoco e lo torna al richiedente il quale lo associa ad un documento che poi salva. Al momento del salvataggio del documento il server eXtraWay sposta il file dall'//area di parcheggio// nella sua collocazione definitiva su disco, ma se il record non viene salvato l'allegato ricevuto rimane in area di parcheggio ed è potenzialmente cancellabile.\\ Utilizzando uno Storage per gli allegati il comportamento sarà il seguente: | |
| * Valore **true**: Il nuovo allegato viene inviato immediatamente allo Storage Server anche se poi non verrà associato ad alcun documento. In questo modo si possono generare dei file inutili nello Storage Server, si rende più complesso il processo di calcolo dell'impronta solitamente utilizzato dalle applicazioni eXtraWay ma si guadagna in performance durante il salvataggio del documento. | |
| * Valore **false**: Il nuovo allegato trova posto, come sempre, in //area di parcheggio// e viene spostato nello Storage Server solo all'atto dell'effettivo salvataggio di un documento che lo referenzia. Il calcolo dell'impronta "vecchio stile" e la possibilità di cancellare allegati non assegnati va a discapito delle prestazioni al momento del salvataggio del record. | |
| * keepTextLocally: Un valore **true** indica al server eXtraWay di non inviare allo Storage Server i file di tipo testuale assoggettati ad indicizzazione e che li conservi invece secondo le modalità canoniche, vale a dire su //file system// in cartelle numerate. In questo modo, in caso di necessità di rigenerare gli indici, essi possono essere calcolati anche con Storage Server indisponibile. | |
