Introduzione alla piattaforma AEM

La piattaforma AEM in AEM 6 si basa su Apache Jackrabbit Oak.

Apache Jackrabbit Oak è uno sforzo per implementare un archivio di contenuti gerarchici scalabile e performante da utilizzare come base dei siti web moderni e di altre applicazioni di contenuti esigenti.

Sostituisce Jackrabbit 2 e viene utilizzato da AEM 6 come backend predefinito per il relativo archivio di contenuti, CRX.

Principi e obiettivi di progettazione

Oak implementa le JSR-283 (JCR 2.0) specifiche. I suoi principali obiettivi sono:

  • Supporto migliorato 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

chlimage_1-84

Archiviazione

Lo scopo del livello di storage è:

  • Implementare un modello ad albero
  • Rendere lo storage collegabile
  • Fornire un meccanismo di clustering

Oak Core

Oak Core aggiunge diversi livelli al livello di archiviazione:

  • Controlli a livello di accesso
  • Ricerca e indicizzazione
  • Osservazione

Oak JCR

L'obiettivo principale di Oak JCR è quello di trasformare la semantica JCR in operazioni ad albero. È inoltre responsabile:

  • Implementazione dell’API JCR
  • Contenenti hook di commit che implementano vincoli JCR

Inoltre, le implementazioni non-Java sono ora possibili e fanno parte del concetto Oak JCR.

Panoramica sullo storage

Il livello di archiviazione Oak fornisce un livello di astrazione per l'effettivo archiviazione del contenuto.

Al momento sono disponibili due implementazioni di storage in AEM6: Archiviazione Tar e Archiviazione MongoDB.

Archiviazione Tar

Lo storage Tar utilizza file tar. Memorizza il contenuto come vari tipi di record all’interno di segmenti più grandi. Le scritture contabili vengono utilizzate per tenere traccia dello stato più recente dell’archivio.

Ci sono diversi principi chiave di progettazione intorno a cui è stato costruito:

  • Segmenti immutabili

Il contenuto viene memorizzato in segmenti di dimensioni fino a 256 KiB. Sono immutabili, il che rende facile memorizzare nella cache i 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 di altri segmenti di riferimento.

  • Località

I record correlati come un nodo e i relativi figli immediati vengono solitamente memorizzati nello stesso segmento. Questo rende la ricerca dell'archivio molto veloce ed evita la maggior parte degli errori di cache per i clienti tipici che accedono a più di un nodo correlato per sessione.

  • Compattezza

La formattazione dei record è ottimizzata per le dimensioni per ridurre i costi di I/O e per adattare il maggior numero possibile di contenuti nelle cache.

Archiviazione Mongo

Lo storage MongoDB sfrutta MongoDB per la condivisione e il clustering. La struttura dell'archivio viene mantenuta in un database MongoDB in cui ogni nodo è un documento separato.

Ha diverse particolarità:

  • Revisioni

Per ogni aggiornamento (commit) del contenuto, viene creata una nuova revisione. Una revisione è fondamentalmente una stringa costituita da tre elementi:

  1. Una marca temporale derivata dall'ora di sistema del computer in cui è stata generata
  2. Un contatore per distinguere le revisioni create con la stessa marca temporale
  3. ID nodo cluster in cui è stata creata la revisione
  • Rami

I rami sono supportati, il che consente al client di mettere in scena più modifiche e di 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 precedenti vengono spostati quando viene soddisfatta una determinata soglia. I documenti precedenti contengono solo dati immutabili, il che significa che contengono solo revisioni salvate e unite.

  • Metadati nodo cluster

I dati sui nodi del cluster attivi e inattivi vengono conservati nel database per facilitare le operazioni del cluster.

Configurazione cluster AEM tipica con archiviazione MongoDB:

chlimage_1-85

Quali sono le differenze rispetto a Jackrabbit 2?

Poiché Oak è progettato per essere compatibile con lo standard JCR 1.0, non ci saranno quasi modifiche a livello di utente. Tuttavia, ci sono alcune differenze notevoli che è necessario tenere in considerazione quando si imposta un'installazione di AEM basata su Oak:

  • Oak non crea indici automaticamente. Per questo motivo, se necessario, sarà necessario creare indici personalizzati.
  • A differenza di Jackrabbit 2, dove le sessioni riflettono sempre lo stato più recente dell’archivio, con Oak una sessione riflette una vista stabile dell’archivio dal momento in cui la sessione è stata acquisita. Questo è dovuto al modello MVCC su cui si basa Oak.
  • Gli elementi di pari livello con lo stesso nome (SNS) non sono supportati in Oak.

Per ulteriori informazioni sulla piattaforma AEM, consulta anche gli articoli seguenti:

In questa pagina