Embed Size (px)
Citation preview
Big Repository Implementation Le sfide, le criticità e soprattutto i vantaggi/benefici
Francesco Fornasari Alfresco Engineer - Alfresco Administrator
Lo Scenario
Caso d’uso
• Content Repository a supporto delle applicazioni di business
• Documenti gestiti di tipo fattura, protocollo e altri documenti aziendali
• Integrazione con sistemi terzi
• Ricerche sui contenuti
• Volumi documentali significativi
• Migrazione da ECM legacy
Big Repository
Volumi documentali
• Target: +500 milioni di documenti presenti nel sistema legacy
• Crescita: 120 milioni di documenti/anno
• Documenti migrati in Alfresco: 10 milioni
• L’architettura deve essere dimensionata di conseguenza a tutti i livelli per
affrontare al meglio il carico e la crescita del repository
Big Repository
Integrazione sistemi terzi
Applicazioni esistenti in essere dal cliente che necessitano dei servizi documentali
• SAP
• EMC2 Centera o Atmos
• Hitachi HCP Content Platform
• Applicazioni custom
Big Repository
Migrazione da ECM legacy • Analisi congiunta con il cliente
finale dello scenario dell’ECM da dismettere
• Verifica e stima del numero dei documenti da migrare
• Preparazione di un modello dati specifico per Alfresco
• Preparazione e modellazione del repository
• Integrazione con altre applicazioni
• Dimensionamento dell’architettura finale
• Creazione/utilizzo di un tool guidato di migrazione
• Analisi dei log e del comportamento del sistema durante la migrazione
• Verifica analitica dei contenuti migrati
• Avvio in Produzione
Big Repository
Ricerche
• Possono rappresentare uno dei problemi più impegnativi da risolvere
• Il cliente deve capire le capacità/limiti del sistema di indicizzazione basato
su SOLR 1.4
• Va stabilita la soglia di soddisfazione nel tempo di retrieval
• Va stabilito cosa ha senso indicizzare sia per i metadati che per i contenuti
Big Repository
Criticità
Criticità • Non sempre i contenuti nell’ECM da dismettere sono validi • Il cliente non ha inizialmente sufficiente know-how per dare indicazioni su
quali tipologie di formati e metadati migrare • Potrebbe essere necessario ristrutturare il modello dati iniziale • Il cliente deve avere chiara percezione di eventuali utilizzi massivi delle
modalità di ricerca full-text • L’integrazione con altre applicazioni o sistemi deve essere valutata
attentamente • Raccogliere sufficienti informazioni per dimensionare e strutturare query di
ricerca può essere veramente difficile • I tempi di risposta si devono mantenere nei limiti di accettazione per il cliente
finale
Big Repository
Soluzione
Architettura e configurazione minimale • Alfresco Repository: 2 nodi in cluster • Index Server SOLR: 2 nodi + 2 Alfresco Repository read-only mode • Alfresco Repository Injection: 1 nodo • DBMS ad alte prestazioni (i.e: Oracle Exadata) che supporta tecniche di
partizionamento dei dati
Big Repository
Web Services
• Ottimizzazione parametri JVM Alfresco e SOLR
• Disabilitare servizi non necessari • Disabilitare estrazione automatica
metadati non necessari (i.e: Exif, RFC822)
Strutturare il processo di migrazione • Il processo di migrazione deve avvalersi di tool o strumenti adatti a
mappare dinamicamente dalla sorgente alla destinazione contenuti e metadati associati
• Creare lotti a batch temporali • Esecuzione parallela dei batch definiti per minimizzare i tempi di
migrazione • Definire logiche di controllo durante le fasi di migrazione al fine di
generare reportistica oppure fermare il processo di migrazione
• Soluzione TAI: Enterprise Content Mapper – http://www.tai.it/progetti/migrazione-documentale/
Big Repository
Strutturare l’integrazione applicativa e di sistema • Creare se possibile uno strato di servizi unificato per l’accesso ai servizi
documentali (astrazione) – Soluzione TAI:
• Layer servizi in standard SOAP + MTOM + WS-Security • Implementazione specifica per un uso ottimale di Alfresco • Non è necessario conoscere nativamente Alfresco
• Guidare gli sviluppatori all’utilizzo ottimale dei servizi documentali CMIS o Alfresco REST
• Utilizzare connettori specifici e certificati Alfresco per sistemi come EMC2 Centera e SAP (Connexas-connector)
Big Repository
Punti di attenzione 1/3
• Modellare solo i metadati minimali e necessari
• Modellare tipi significativi
• Strutturare il repository in modo da non avere troppi figli diretti di uno stesso nodo cm:folder
• Attenti a non esagerare con le ACL e preferire un approccio di configurazione sui Gruppi
• Categorizzare se possibile i nodi documentali attraverso l’aspect cm:classifiable
Big Repository
Punti di attenzione 2/3 • Indicizzare solo i metadati che verranno effettivamente utilizzati nelle
ricerche • Guidare le ricerche applicative in modo che utilizzino il più possibile il
Metadata Search Engine (utilizzare linguaggi come AFTS o CMIS ed evitare l’utilizzo dell’operatore OR, PATH, NOT e @)
• Utilizzare in corso d’opera l’aspect cm:indexControl • Abilitare il full-text per un sotto-insieme di tipi documentali • Ricerche con result-set elevati possono portare il processo java
dell’istanza Alfresco Repository in out-of-memory • Avere gli indici su dischi locali e comunque performanti • Avere circa la metà di spazio disco degli indici sempre libero
Big Repository
Punti di attenzione 3/3 • Evitare query troppo generiche e restringere il più possibile i campi di
ricerca su metadati significativi • Interrogare direttamente il DB nel caso in cui:
– Il result-set abbia una cardinalità troppo elevata (>~20.000 elementi) – Sia necessario conoscere il numero di elementi di un certo tipo o eseguire
aggregazioni particolari
Big Repository
SELECT names.local_name as node_type, count(*) as occurrencies FROM alf_node nodes, alf_qname names WHERE nodes.type_qname_id=names.id AND ( names.local_name='PRAI_AP01' OR names.local_name='PRAI_COIMA' OR …. ) GROUP BY nodes.type_qname_id, names.local_name ORDER BY occurrencies desc;
Punti di attenzione DBMS 1/2 • Nel disegno e dimensionamento architetturale confrontarsi con un DBA • Monitorare le tabelle più critiche dello schema dati alfresco e nel caso attivare
tecniche di partizionamento: – ALF_NODE: riferimenti ai nodi del repository – ALF_NODE_PROPERTIES: proprietà definite nei modelli dati per ogni tipo o aspetto – ALF_CONTENT_URL: contiene il riferimenti fisico al contenuto – ALF_CHILD_ASSOC: relazioni padre-figlio tra nodi del repository
• Fattori di crescita indicativi ~ (per ogni nuovo inserimento di cm:content o cm:folder): – ALF_NODE: +3 – ALF_NODE_PROPERTIES: +4 – ALF_NODE_PROPERTIES (versioning attivo): +25 – ALF_CONTENT_URL: +1
Big Repository
Punti di attenzione DBMS 2/2 • ALF_NODE_PROPERTIES crescerà a seconda della complessità del
modello dati • I.E: ~10M documenti potrebbero produrre ~200M di righe su
ALF_NODE_PROPERTIES • Tecniche di partizionamento basate su HASH sui campi univoci
identificativi • Evitare quindi in fase di analisi del modello:
– Modellare metadati di cui non si è SICURI dell’effettivo utilizzo – Abilitare estrattori su meta-type conosciuti non necessari – Riportare stessi metadati su tipi differenti, utilizzare in questi casi gli aspect
Big Repository
Vantaggi/Benefici
Vantaggi/Benefici
• Riduzione dei costi a lungo termine
• Scalabilità del sistema
• Performance
• Strutturazione evolutiva dei servizi documentali
• Organizzazione delle informazioni (i dati parlano di sé stessi)
Big Repository
TAI Enterprise Content Mapper DEMO
http://www.tai.it/soluzioni-software/enterprise-content-mapper/
