Introduzione alla piattaforma AEM
La piattaforma AEM nell’AEM 6 si basa su Apache Jackrabbit Oak.
Apache Jackrabbit Oak si impegna a implementare un archivio di contenuti gerarchici scalabile e performante da utilizzare come base per siti web moderni e altre applicazioni di contenuti impegnative.
È il successore di Jackrabbit 2 ed è utilizzato da AEM 6 come back-end predefinito per il suo archivio di contenuti, CRX.
Principi e obiettivi di progettazione
Oak implementa le specifiche JSR-283 (JCR 2.0). I suoi principali obiettivi sono:
- Supporto migliore per archivi di grandi dimensioni
- Più nodi cluster distribuiti per un'elevata disponibilità
- Prestazioni migliori
- Supporto per molti nodi figlio e livelli di controllo degli accessi
Concetto di architettura
Archiviazione
Lo scopo del livello di storage è:
- Implementare un modello ad albero
- Rendi lo storage collegabile
- Meccanismo di clustering
Oak Core
Oak Core aggiunge diversi livelli al livello di storage:
- Controlli del livello di accesso
- Ricerca e indicizzazione
- Osservazione
OAK JCR
L’obiettivo principale di Oak JCR è trasformare la semantica JCR in operazioni ad albero. È inoltre responsabile di:
- Implementazione dell’API JCR
- Contenente hook di commit che implementano vincoli JCR
Inoltre, le implementazioni non Java sono ora possibili e fanno parte del concetto JCR di Oak.
Panoramica sull’archiviazione
Il livello di archiviazione Oak fornisce un livello di astrazione per l’archiviazione effettiva del contenuto.
Attualmente, in AEM6 sono disponibili due implementazioni di archiviazione: Archiviazione Tar e Archiviazione MongoDB.
Archiviazione Tar
L’archiviazione Tar utilizza file tar. Memorizza il contenuto come vari tipi di record all’interno di segmenti più grandi. I giornali vengono utilizzati per tenere traccia dello stato più recente dell’archivio.
Sono diversi i principi chiave di progettazione su cui è stato costruito:
- Segmenti immutabili
Il contenuto viene archiviato in segmenti che possono essere fino a 256 KB. Sono immutabili, il che semplifica la memorizzazione nella cache dei segmenti a cui si accede di frequente e riduce gli errori di sistema che possono danneggiare l’archivio.
Ogni segmento è identificato da un identificatore univoco (UUID) e contiene un sottoinsieme continuo della struttura del contenuto. Inoltre, i segmenti possono fare riferimento ad altri contenuti. Ogni segmento mantiene un elenco di UUID degli altri segmenti a cui si fa riferimento.
- Località
I record correlati come un nodo e i relativi elementi secondari immediati vengono memorizzati nello stesso segmento. In questo modo la ricerca nell’archivio diventa rapida ed evita la maggior parte dei problemi di cache per i client tipici che accedono a più di un nodo correlato per sessione.
- Compattezza
La formattazione dei record è ottimizzata in base alle dimensioni per ridurre i costi di I/O e adattare il maggior numero possibile di contenuti nelle cache.
Archiviazione Mongo
Lo storage MongoDB utilizza MongoDB per il partizionamento e il clustering. La struttura dell’archivio è contenuta in un unico database MongoDB in cui ogni nodo è un documento separato.
Presenta diverse particolarità:
- Revisione
Per ogni aggiornamento (commit) del contenuto, viene creata una nuova revisione. Una revisione è fondamentalmente una stringa composta da tre elementi:
- Una marca temporale derivata dall'ora di sistema della macchina su cui è stata generata
- Un contatore per distinguere le revisioni create con la stessa marca temporale
- ID nodo cluster in cui è stata creata la revisione
- Rami
I rami sono supportati e consentono al client di posizionare nell’area intermedia più modifiche e renderle visibili con una singola chiamata di unione.
- Documenti precedenti
L’archiviazione MongoDB aggiunge dati a un documento con ogni modifica. Tuttavia, elimina i dati solo se viene attivata esplicitamente una pulizia. I dati obsoleti vengono spostati quando viene raggiunta una determinata soglia. I documenti precedenti contengono solo dati immutabili, ovvero contengono solo revisioni salvate e unite.
- Metadati nodo cluster
I dati relativi ai nodi cluster attivi e inattivi vengono conservati nel database per facilitare le operazioni del cluster.
Una tipica configurazione cluster AEM con archiviazione MongoDB:
