StorageReview.com

Benchmark di archiviazione del database MarkLogic NoSQL

MarkLogic 6 è un database Enterprise NoSQL ("Not Only SQL") che offre la flessibilità e la scalabilità necessarie per gestire le sfide odierne relative ai dati che i database basati su SQL non sono stati progettati per gestire. Dispone inoltre di funzionalità di livello aziendale come ricerca, transazioni ACID, failover, replica e sicurezza per eseguire applicazioni mission-critical. MarkLogic combina funzionalità di database, ricerca e servizi applicativi in ​​un unico sistema. Fornisce le funzionalità di cui le aziende hanno bisogno per fornire valore. MarkLogic sfrutta gli strumenti, le conoscenze e l'esperienza esistenti fornendo al contempo una piattaforma affidabile, scalabile e sicura per i dati mission-critical.

Aziende e organizzazioni di tutti i settori, tra cui il settore pubblico, i media e i servizi finanziari, hanno beneficiato dell’architettura unica di MarkLogic. Qualsiasi ambiente che deve far fronte a una combinazione di volume, velocità, varietà e complessità dei dati, una sfida nota come Big Data, può essere migliorato con MarkLogic. Soluzioni di esempio basate su MarkLogic includono analisi di intelligence, supporto decisionale in tempo reale, gestione del rischio, gestione delle risorse digitali, catena di fornitura digitale e distribuzione di contenuti.

Benchmark MarkLogic

Il benchmark che stiamo utilizzando è sviluppato internamente da MarkLogic e viene utilizzato per valutare sia le configurazioni hardware che le prossime versioni del software MarkLogic. Il carico di lavoro è diviso in due parti distinte:

  1. Fase di inserimento in cui un set di dati di grandi dimensioni viene inserito con indici nel database MarkLogic.
  2. Fase di query in cui le ricerche, gli aggiornamenti delle visualizzazioni e le eliminazioni vengono applicati al set di dati inserito. Queste query utilizzano anche funzionalità MarkLogic come sfaccettature, impaginazione e segnalibri.

Il corpus utilizzato è la raccolta xml di Wikipedia disponibile pubblicamente. I file vengono conservati su disco in formato zippato. Per l'acquisizione utilizziamo MarkLogic Content Pump (mlcp).  

La fase di acquisizione in particolare è ad alta intensità di I/O. Gli I/O sono suddivisi in tre categorie:

  1. Inizialmente i documenti vengono inseriti in supporti in memoria e le uniche scritture su disco sono i salvataggi del Journal.
  2. I supporti in memoria traboccano rapidamente e vengono continuamente scritti come supporti su disco. Questa è un'attività di salvataggio.
  3. Man mano che il numero di supporti su disco aumenta, MarkLogic deve unirli per ridurre il sovraccarico delle query. L'unione implica la lettura di più supporti su disco, la riscrittura di un'unica versione unita e l'eliminazione degli originali.

Per garantire il massimo livello di precisione e forzare ogni dispositivo allo stato stazionario, ripetiamo le fasi di acquisizione e query 24 volte per i dispositivi basati su flash. Per gli acceleratori di applicazioni PCIe, il completamento di ogni intervallo richiede dai 60 ai 120 minuti, quindi il tempo totale del test rientra in un intervallo di 24-48 ore. Per i dispositivi con un throughput I/O inferiore, il tempo totale del test può durare giorni. Il nostro obiettivo in questo test è esaminare la latenza complessiva di ciascuna soluzione di storage in quattro aree di interesse: scritture journal (J-lat), scritture salvate (S-lat), nonché lettura unione (MR-lat) e scrittura unione latenza (MW-lat).

Nel diagramma sopra vediamo i percorsi I/O e le latenze in MarkLogic:

  • Le scritture del journal registrano i delta nel database. Quando viene eseguita una richiesta di aggiornamento, tutte le modifiche apportate allo stato del database vengono registrate nel journal. Tali modifiche possono essere applicate nuovamente dal journal, senza eseguire nuovamente la richiesta. Gli aggiornamenti possono essere aggiunte, sostituzioni o cancellazioni di documenti. Il diario protegge dalle interruzioni, è garantito che sopravviva a un successivo arresto anomalo del sistema. La latenza delle scritture del Journal viene catturata nella metrica J-lat
  • Dopo che sono stati caricati abbastanza documenti, il supporto in memoria si riempirà e verrà scaricato su disco, scritto come supporto su disco. Questo scaricamento su disco è chiamato salvataggio. La latenza delle scritture di salvataggio viene catturata in S-lat
  • Con l'aumento del numero totale di supporti su disco, un problema di efficienza rischia di emergere. Per leggere un singolo elenco di termini, MarkLogic deve leggere i dati dell'elenco di termini da ogni singolo stand e unificare i risultati. Per mantenere il numero di stand a un livello gestibile, MarkLogic esegue le fusioni in background. Una fusione legge (Merge Read) alcuni dei supporti sul disco e ne crea un nuovo singolare (Merge Write), unendo e ottimizzando gli indici e i dati, oltre a rimuovere eventuali frammenti precedentemente eliminati. La latenza delle letture Merge viene catturata in MR-lat e la latenza delle scritture Merge in MW-lat.

Durante l'acquisizione, MarkLogic indicizza anche tutti i documenti, crea elenchi di termini, ecc. Questa attività richiede cicli della CPU che rendono il benchmark un buon equilibrio tra I/O elevato e utilizzo elevato della CPU.

I dati di Wikipedia sono stati scelti anche perché contengono testo non inglese e non ASCII tra cui utilizziamo: arabo, olandese, francese, tedesco, italiano, giapponese, coreano, persiano, portoghese, russo, spagnolo, cinese semplificato e cinese tradizionale. Queste opzioni sottolineano le funzionalità multilingue di MarkLogic. Infine, i dati statici acquisiti rendono il benchmark ripetibile, il che è essenziale per il confronto delle prestazioni tra le diverse configurazioni hardware di più versioni software.

Ambiente di test MarkLogic

Le soluzioni di storage vengono testate con il benchmark MarkLogic NoSQL nello StorageReview Enterprise Test Lab utilizzando più server collegati tramite una rete ad alta velocità. Utilizziamo server di EchoStreams e Lenovo per diversi segmenti dell'ambiente di test MarkLogic NoSQL e per la struttura che collega le apparecchiature utilizziamo Mellanox InfiniBand Switching e NIC.

La soluzione di storage è suddivisa in tre sezioni: l'host di storage, il cluster di database NoSQL MarkLogic e il client di database MarkLogic. Per l'host di storage, utilizziamo un Lenovo ThinkServer RD630 2U per ospitare acceleratori di applicazioni PCIe, gruppi di quattro SSD SATA/SAS e un host per apparecchiature NAS/SAN, che vengono presentati sulla rete InfiniBand. Per il cluster di database MarkLogic, utilizziamo un server EchoStreams GridStreams a quattro nodi, dotato di otto CPU Intel Xeon E5-2640, per fornire le risorse di calcolo necessarie a testare efficacemente i dispositivi di storage più veloci. Lato client, utilizziamo server Lenovo ThinkServer RD530 1U che forniscono i dati di lavoro, caricati nella memoria di sistema e inviati al cluster di database NoSQL tramite la nostra rete ad alta velocità. A collegare tutti questi server c'è una struttura InfiniBand Mellanox da 56 Gb/s che include sia switch che schede di rete, garantendoci le massime velocità di trasferimento e la minima latenza, in modo da non limitare le prestazioni dei dispositivi di storage ad alte prestazioni.

Le interconnessioni Mellanox InfiniBand sono state utilizzate per fornire le massime prestazioni e la massima efficienza di rete per garantire che i dispositivi collegati non siano limitati dalla rete. Considerando solo le soluzioni di storage PCIe, un singolo acceleratore di applicazioni PCIe può facilmente trasferire più di 1-3 GB/s sulla rete. Passa a un dispositivo di storage all-flash con velocità di trasferimento di picco superiori a 10-20 GB/s e vedrai rapidamente come la capacità del collegamento di rete può essere facilmente saturata, limitando le prestazioni complessive dell'intera piattaforma. I collegamenti a larghezza di banda elevata di InfiniBand consentono di spostare la massima quantità di dati sul minor numero di collegamenti, consentendo di realizzare tutte le funzionalità del sistema.

Oltre a un throughput di rete più elevato, InfiniBand consente anche una maggiore efficienza complessiva del cluster. InfiniBand utilizza iSER (iSCSI-RDMA) e SRP (protocollo SCSI RDMA) per sostituire l'inefficiente stack iSCSI TCP con la funzionalità RDMA (Remote Direct Memory Access), consentendo tempi di accesso quasi nativi per l'archiviazione esterna. iSER e SRP consentono una maggiore efficienza in tutto l'ambiente cluster consentendo al traffico di rete di bypassare le CPU dei sistemi e consentendo la copia dei dati dalla memoria dei sistemi di invio direttamente alla memoria dei sistemi di ricezione. In confronto, il tradizionale funzionamento iSCSI instrada il traffico di rete attraverso un complesso processo di copia e trasferimento multiplo, consumando preziosi cicli della CPU e spazio di memoria e aumentando drasticamente le latenze di trasferimento dei dati. Nel nostro ambiente MarkLogic NoSQL, utilizziamo il protocollo SCSI RDMA per connettere ciascun nodo a un sottosistema di destinazione SCSI per Linux (SCST) in esecuzione sul nostro host di archiviazione. 

Attrezzatura di riferimento MarkLogic

L'obiettivo principale di questa piattaforma è evidenziare le prestazioni dello storage aziendale in un ambiente e in un carico di lavoro aziendali reali, invece di fare affidamento su carichi di lavoro sintetici o pseudo-sintetici. I generatori di carichi di lavoro sintetici sono ottimi nel mostrare le prestazioni dei dispositivi di storage con un modello I/O sintetico continuo, ma non prendono in considerazione nessuna delle altre variabili esterne che mostrano come funzionano effettivamente i dispositivi negli ambienti di produzione. I generatori di carichi di lavoro sintetici hanno il vantaggio di mostrare ripetutamente un modello I/O pulito, ma non replicheranno mai un vero ambiente di produzione. L'introduzione delle prestazioni delle applicazioni sui prodotti di storage inizia a mostrare quanto bene lo storage interagisce con i suoi driver, il sistema operativo locale, l'applicazione testata, lo stack di rete, la commutazione di rete e i server esterni. Si tratta di variabili che un generatore sintetico di carico di lavoro semplicemente non può prendere in considerazione e che richiedono anche un ordine di grandezza che richiede più risorse e infrastrutture in termini di attrezzature necessarie per eseguire questo particolare benchmark.

Risultati delle prestazioni MarkLogic

Testiamo un'ampia gamma di soluzioni di storage con il benchmark MarkLogic NoSQL che soddisfano i requisiti minimi dell'ambiente di test. Per qualificarsi per il test, il dispositivo di storage deve avere una capacità utilizzabile superiore a 650 GB ed essere progettato per funzionare in condizioni aziendali stressanti. Ciò include nuovi acceleratori di applicazioni PCIe, gruppi di quattro SSD aziendali SAS o SATA, nonché array di HDD di grandi dimensioni collegati localmente o in rete. Di seguito sono elencati i dati complessivi sulla latenza acquisiti da tutti i dispositivi testati finora in questo test. Nelle recensioni dei prodotti entriamo più nel dettaglio e mettiamo a confronto i prodotti concorrenti, mentre il nostro elenco principale mostra la stratificazione delle diverse soluzioni di archiviazione. 

 

Dispositivo Latenza media complessiva S-lat J-lat MR-lat MW-lat
Dell R720 Express Flash da 350 GB
JBODx4 (SLC)
1.24 1.56 1.56 0.46 1.37
HuaweiTecal ES3000 2.4TB
4 partizioni (MLC)
1.31 1.41 1.53 0.98 1.32
HuaweiTecal ES3000 1.2TB
4 partizioni (MLC)
1.43 1.42 1.76 1.20 1.33
EchoStreams FlacheSAN2 w/ Intel SSD 520
S/W RAID0, 4 gruppi di 8 SSD da 180 GB (MLC)
1.48 1.65 2.01 0.81 1.46
Micron P320h 700 GB
4 Partizioni (SLC)
1.49 1.62 2.13 0.79 1.41
Fusion ioDrive2 Duo MLC da 2.4 TB
S/W RAID0, modalità ad alte prestazioni, 4 partizioni (MLC)
1.70 1.73 2.57 0.97 1.51
Fusion ioDrive2 Duo SLC da 1.2 TB
S/W RAID0, modalità ad alte prestazioni, 4 partizioni (SLC)
1.72 1.78 2.69 0.90 1.52
OCZ Z-Drive R4 1.6 TB
4 partizioni (MLC)
1.73 1.67 2.38 1.43 1.42
Hitachi Ultrastar SSD400S.B 400 GB
JBODx4 (SLC)
1.77 1.75 2.72 1.11 1.51
SmartOptimus 400 GB
JBODx4 (MLC)
1.82 1.69 2.74 1.36 1.49
EchoStreams FlacheSAN2 w/ Intel SSD 520
S/W RAID10, 4 gruppi di 8 SSD da 180 GB (MLC)
2.02 2.12 3.02 1.17 1.79
Virident FlashMAX II 2.2 TB
Modalità ad alte prestazioni, 4 partizioni (MLC)
2.26 2.30 3.39 1.57 1.81
Hitachi Ultrastar SSD400M 400 GB
JBODx4 (MLC)
2.58 2.09 4.49 2.07 1.68
OCZ Talos 2 400 GB
JBODx4 (MLC)
2.62 2.10 4.33 2.28 1.78
Intel DC S3700 200 GB
JBODx4 (MLC)
3.27 2.71 5.80 2.59 1.95
OCZ Talos 2 200 GB
JBODx4 (MLC)
3.53 2.62 6.16 3.40 1.96
SSD Intel 910 da 800 GB
Non RAID, JBOD x 4 (MLC)
4.29 3.21 8.27 3.43 2.23
Fusion ioDrive2 MLC da 1.2 TB
S/W RAID0, modalità ad alte prestazioni, 4 partizioni (MLC)
4.69 3.58 9.15 3.74 2.28
OCZ Deneva 2 200 GB
JBODx4 (MLC)
6.65 5.38 13.48 4.54 3.18
Kingston E100 da 200 GB
JBODx4 (MLC)
8.00 6.82 16.22 5.46 3.49
Smart Cloud Speed ​​500 240 GB
JBODx4 (MLC)
11.06 9.07 22.74 7.19 5.23
Micron P400m 400 GB
JBODx4 (MLC)
12.60 9.70 27.51 8.70 4.51
Fusion ioDrive DuoMLC 1.28 TB
S/W RAID0, modalità ad alte prestazioni, 4 partizioni (MLC)
12.89 10.52 26.77 9.70 4.58
Micron P400m 200 GB
JBODx4 (MLC)
14.98 11.99 31.93 10.54 5.46
Toshiba 15K MK01GRRB 147 GB
H/W LSI 9286-8e x 16, RAID10 x 4
16.58 7.85 40.61 12.25 5.61
LSI Nytro Warp Drive da 800 GB
4 partizioni (MLC)
17.39 17.08 31.42 13.63 7.43
Toshiba 10K MBF2600RC 600 GB
H/W LSI 9286-8e x 16, RAID10 x 4
24.20 10.89 57.94 20.61 7.35
Toshiba 15K MK01GRRB 147 GB
RAID S/W x 16, RAID 10 x 4
61.40 54.33 126.77 45.21 19.28

Pagina del prodotto MarkLogic