MarkLogic 6 är en Enterprise NoSQL (“Not Only SQL”)-databas som har flexibiliteten och skalbarheten för att hantera dagens datautmaningar som SQL-baserade databaser inte var designade för att hantera. Den har också funktioner i företagsklass som sökning, ACID-transaktioner, failover, replikering och säkerhet för att köra verksamhetskritiska applikationer. MarkLogic kombinerar databasfunktionalitet, sök- och applikationstjänster i ett enda system. Det ger den funktionalitet företag behöver för att leverera värde. MarkLogic utnyttjar befintliga verktyg, kunskap och erfarenhet samtidigt som de tillhandahåller en pålitlig, skalbar och säker plattform för uppdragskritiska data.
Företag och organisationer över branscher inklusive offentlig sektor, media och finansiella tjänster har dragit nytta av MarkLogics unika arkitektur. Alla miljöer som möter en kombination av datavolym, hastighet, variation och komplexitet – en datautmaning som kallas Big Data – kan förbättras med MarkLogic. Exempel på lösningar byggda på MarkLogic inkluderar intelligensanalys, beslutsstöd i realtid, riskhantering, digital tillgångshantering, digital leveranskedja och innehållsleverans.
MarkLogic Benchmark
Benchmarken vi använder är internt utvecklad av MarkLogic och används för att utvärdera både hårdvarukonfigurationer och kommande MarkLogic-programvaruversioner. Arbetsbelastningen är uppdelad i två distinkta delar:
- Intagsfas där en stor datamängd infogas med index i MarkLogic-databasen.
- Frågefas där sökningar, vyuppdateringar och raderingar tillämpas på den infogade datamängden. Dessa frågor använder också MarkLogic-funktioner som facetter, sidnumrering och bokmärken.
Korpusen som används är den allmänt tillgängliga Wikipedia xml-samlingen. Filer lagras på disken i zippat format. För intag använder vi MarkLogic Content Pump (mlcp).
Särskilt intagsfasen är I/O-intensiv. I/O är uppdelad i tre kategorier:
- Initialt matas dokument in i minnesställen och de enda diskskrivningarna är journalsparningar.
- In-memory-stativ svämmar snabbt över och skrivs kontinuerligt som on-disk-stativ. Detta sparar aktivitet.
- I takt med att antalet ställen på disken ökar måste MarkLogic slå samman dem för att minska frågeoverhead. Sammanfogning innebär att läsa flera ställen på disken, skriva tillbaka en sammanslagen version och radera originalen.
För att säkerställa högsta noggrannhet och för att tvinga varje enhet till stationärt tillstånd upprepar vi inmatnings- och frågefaserna 24 gånger för flashbaserade enheter. För PCIe Application Acceleratorer tar varje intervall mellan 60-120 minuter att slutföra, vilket innebär att den totala testtiden ligger inom intervallet 24-48 timmar. För enheter med lägre I/O-genomströmning kan den totala testtiden sträcka sig över dagar. Vårt fokus i det här testet är att titta på övergripande latens från varje lagringslösning över fyra intresseområden: journalskrivningar (J-lat), spara skrivningar (S-lat), samt sammanfoga läsning (MR-lat) och sammanfoga skrivning latens (MW-lat).
I diagrammet ovan ser vi I/O-vägarna och latenserna i MarkLogic:
- Journal skriver registrera deltan till databasen. När en uppdateringsbegäran körs, registreras alla ändringar som den gjorde i databasens tillstånd i journalen. Dessa ändringar kan tillämpas igen från journalen, utan att köra begäran igen. Uppdateringar kan vara tillägg, ersättningar eller raderingar av dokument. Journalen skyddar mot avbrott, den kommer garanterat att överleva en systemkrasch därefter. Latensen för Journalskrivningar fångar in J-lat-måttet
- När tillräckligt många dokument har laddats kommer minnesstället att fyllas upp och spolas till disken, skrivet ut som ett på diskstället. Denna flush till disk kallas en Save. Latensen för Save-skrivningar fångas i S-lat
- I takt med att det totala antalet on-disk-stativ växer, hotar ett effektivitetsproblem att uppstå. För att läsa en enskild termlista måste MarkLogic läsa termlistdata från varje enskild monter och förena resultaten. För att hålla antalet montrar på en hanterbar nivå kör MarkLogic sammanslagningar i bakgrunden. En sammanfogning läser (Merge Read) några av stativen på disken och skapar en ny singularis av dem Merge Write), kombinerar och optimerar index och data, samt tar bort alla tidigare raderade fragment. Latensen för Merge-läsningar fångas i MR-lat och latensen för Merge-skrivningar i MW-lat.
Under inmatning indexerar MarkLogic också alla dokument, skapar termlistor etc. Denna aktivitet kräver CPU-cykler som gör riktmärket till en bra balans mellan hög I/O och hög CPU-användning.
Wikipedia-datan valdes också eftersom den innehåller icke-engelsk och icke-ASCII-text som vi använder: arabiska, holländska, franska, tyska, italienska, japanska, koreanska, persiska, portugisiska, ryska, spanska, förenklad kinesiska och traditionell kinesiska. Dessa alternativ betonar de flerspråkiga funktionerna hos MarkLogic. Slutligen gör den intagna statiska data riktmärket repeterbart, vilket är viktigt för prestandajämförelser mellan flera programvaruversioners olika hårdvarukonfigurationer.
MarkLogic testmiljö
Lagringslösningar testas med MarkLogic NoSQL benchmark i StorageReview Enterprise Test Lab som använder flera servrar anslutna över ett höghastighetsnätverk. Vi använder servrar från EchoStreams och Lenovo för olika segment av MarkLogic NoSQL-testmiljön, och för tyget som ansluter utrustningen använder vi Mellanox InfiniBand Switching och NIC.
Lagringslösningen är uppdelad i tre sektioner: lagringsvärden, MarkLogic NoSQL Database Cluster och MarkLogic Database Client. För lagringsvärden använder vi en 2U Lenovo ThinkServer RD630 för att presentera PCIe Application Acceleratorer, grupper om fyra SATA/SAS SSD:er och en värd för NAS/SAN-utrustning för att presentera dem på InfiniBand-tyget. För MarkLogic Database Cluster använder vi en EchoStreams GridStreams quad-node-server utrustad med åtta Intel Xeon E5-2640-processorer för att tillhandahålla de beräkningsresurser som behövs för att effektivt stressa de snabbaste lagringsenheterna. På klientsidan använder vi 1U Lenovo ThinkServer RD530-servrar som tillhandahåller arbetsdata som laddas in i systemminnet och skjuts till NoSQL Database-klustret över vårt höghastighetsnätverk. Länkar alla dessa servrar samman är ett Mellanox 56Gb/s InfiniBand-tyg inklusive både switch och NIC som ger oss de högsta överföringshastigheterna och lägsta latensen för att inte begränsa prestandan hos högpresterande lagringsenheter.
Mellanox InfiniBand sammankopplingar användes för att ge högsta prestanda och största nätverkseffektivitet för att säkerställa att de anslutna enheterna inte är nätverksbegränsade. Om man bara tittar på PCIe-lagringslösningar kan en enda PCIe Application Accelerator enkelt köra mer 1-3 GB/s till nätverket. Rampa upp till en all-flash-lagringsenhet med toppöverföringshastigheter på över 10-20 GB/s och du kan snabbt se hur nätverkslänkkapaciteten lätt kan mättas, vilket begränsar den totala prestandan för hela plattformen. InfiniBands länkar med hög bandbredd gör att den största mängden data kan flyttas över det minsta antalet länkar, vilket gör att hela systemets kapacitet kan realiseras.
Förutom högre nätverksgenomströmning möjliggör InfiniBand även högre total klustereffektivitet. InfiniBand använder iSER (iSCSI-RDMA) och SRP (SCSI RDMA-protokoll) för att ersätta den ineffektiva iSCSI TCP-stacken med RDMA-funktionalitet (Remote Direct Memory Access), vilket tillåter nästan infödda åtkomsttider för extern lagring. iSER och SRP möjliggör större effektivitet i hela den klustrade miljön genom att tillåta nätverkstrafik att kringgå systemens processorer och tillåta att data kopieras från de sändande systemens minne direkt till de mottagande systemens minne. Som jämförelse dirigerar traditionell iSCSI-drift nätverkstrafik genom en komplex multipelkopierings- och överföringsprocess, äter upp värdefulla CPU-cykler och minnesutrymme och ökar drastiskt dataöverföringsfördröjningar. I vår MarkLogic NoSQL-miljö använder vi SCSI RDMA-protokollet för att ansluta varje nod till ett SCSI-målundersystem för Linux (SCST) som körs på vår lagringsvärd.
MarkLogic Benchmark-utrustning
- EchoStreams GridStreams Quad-Node Database Cluster
- Åtta Intel E5-2640-processorer (två per nod, 2.5 GHz, 6-kärnor, 15 MB cache)
- 256 GB RAM (64 GB per nod, 8 GB x 8 Micron DDR3, 32 GB per CPU)
- 4 x 100GB Micron RealSSD P400e (En per nod, inbyggd SATA)
- 4 x Mellanox ConnectX-3 InfiniBand-adapter
- 6.3 CentOS
- Lenovo ThinkServer RD530 Databasklient
- Dubbla Intel E5-2640-processorer (2.5 GHz, 6-kärnor, 15 MB cache)
- 64 GB RAM (8 GB x 8 Micron DDR3, 32 GB per CPU)
- 200GB x 3 Toshiba 10k SAS RAID5 (via LSI 9260-8i)
- 1 x Mellanox ConnectX-3 InfiniBand-adapter
- 6.3 CentOS
- Lenovo ThinkServer RD630 Lagringsvärd
- Dubbla Intel E5-2680-processorer (2.7 GHz, 8-kärnor, 20 MB cache)
- 32 GB RAM (8 GB x 4 DDR3, 16 GB per CPU)
- 100 GB mikron RealSSD P400e SSD (via LSI 9207-8i)
- 1 x Mellanox ConnectX-3 InfiniBand-adapter
- 6.3 CentOS
- Extern JBOD: iXsystems Titan iX-316J
- Mellanox SX6036 InfiniBand Switch
- 36 FDR (56Gb/s) portar
- 4Tb/s sammanlagd växlingskapacitet
Huvudmålet med den här plattformen är att belysa hur företagslagring fungerar i en verklig företagsmiljö och arbetsbelastning, istället för att förlita sig på syntetiska eller pseudosyntetiska arbetsbelastningar. Syntetiska arbetsbelastningsgeneratorer är bra på att visa hur bra lagringsenheter presterar med ett kontinuerligt syntetiskt I/O-mönster, men de tar inte hänsyn till någon av de andra externa variablerna som visar hur enheter faktiskt fungerar i produktionsmiljöer. Syntetiska arbetsbelastningsgeneratorer har fördelen av att visa ett rent I/O-mönster gång på gång, men kommer aldrig att replikera en verklig produktionsmiljö. Att introducera applikationsprestanda ovanpå lagringsprodukter börjar visa hur väl lagringen interagerar med dess drivrutiner, det lokala operativsystemet, applikationen som testas, nätverksstacken, nätverksväxlingen och externa servrar. Dessa är variabler som en syntetisk arbetsbelastningsgenerator helt enkelt inte kan ta hänsyn till, och är också en storleksordning mer resurs- och infrastrukturkrävande när det gäller den utrustning som krävs för att utföra just detta riktmärke.
MarkLogic prestandaresultat
Vi testar ett brett utbud av lagringslösningar med MarkLogic NoSQL benchmark som uppfyller testmiljöns minimikrav. För att kvalificera sig för testning måste lagringsenheten ha en användbar kapacitet som överstiger 650 GB och vara inriktad på att fungera under stressiga företagsförhållanden. Detta inkluderar nya PCIe-applikationsacceleratorer, grupper om fyra SAS- eller SATA-företags-SSD:er, såväl som stora hårddiskar som är lokalt eller nätverksanslutna. Nedan listas de totala latenssiffrorna från alla enheter som testats hittills i detta test. I produktrecensioner dyker vi in i mer detaljer och sätter konkurrerande produkter mot varandra medan vår huvudlista visar skiktningen av olika lagringslösningar.
| Anordning | Totalt genomsnittlig latens | Spjäla | J-lat | MR-lat | MW-lat |
|---|---|---|---|---|---|
| Dell R720 ExpressFlash 350GB JBOD x 4 (SLC) |
1.24 | 1.56 | 1.56 | 0.46 | 1.37 |
| Huawei Tecal ES3000 2.4TB 4 partitioner (MLC) |
1.31 | 1.41 | 1.53 | 0.98 | 1.32 |
| Huawei Tecal ES3000 1.2TB 4 partitioner (MLC) |
1.43 | 1.42 | 1.76 | 1.20 | 1.33 |
| EchoStreams FlacheSAN2 w/ Intel SSD 520 S/W RAID0, 4 grupper om 8 180 GB SSD-enheter (MLC) |
1.48 | 1.65 | 2.01 | 0.81 | 1.46 |
| Micron P320h 700GB 4 partitioner (SLC) |
1.49 | 1.62 | 2.13 | 0.79 | 1.41 |
| Fusion ioDrive2 Duo MLC 2.4TB S/W RAID0, högpresterande läge, 4 partitioner (MLC) |
1.70 | 1.73 | 2.57 | 0.97 | 1.51 |
| Fusion ioDrive2 Duo SLC 1.2TB S/W RAID0, högpresterande läge, 4 partitioner (SLC) |
1.72 | 1.78 | 2.69 | 0.90 | 1.52 |
| OCZ Z-Drive R4 1.6TB 4 partitioner (MLC) |
1.73 | 1.67 | 2.38 | 1.43 | 1.42 |
| Hitachi Ultrastar SSD400S.B 400GB JBOD x 4 (SLC) |
1.77 | 1.75 | 2.72 | 1.11 | 1.51 |
| Smart Optimus 400GB JBOD x 4 (MLC) |
1.82 | 1.69 | 2.74 | 1.36 | 1.49 |
| EchoStreams FlacheSAN2 w/ Intel SSD 520 S/W RAID10, 4 grupper om 8 180 GB SSD-enheter (MLC) |
2.02 | 2.12 | 3.02 | 1.17 | 1.79 |
| Virident FlashMAX II 2.2TB Högpresterande läge, 4 partitioner (MLC) |
2.26 | 2.30 | 3.39 | 1.57 | 1.81 |
| Hitachi Ultrastar SSD400M 400GB JBOD x 4 (MLC) |
2.58 | 2.09 | 4.49 | 2.07 | 1.68 |
| OCZ Talos 2 400GB JBOD x 4 (MLC) |
2.62 | 2.10 | 4.33 | 2.28 | 1.78 |
| Intel DC S3700 200GB JBOD x 4 (MLC) |
3.27 | 2.71 | 5.80 | 2.59 | 1.95 |
| OCZ Talos 2 200GB JBOD x 4 (MLC) |
3.53 | 2.62 | 6.16 | 3.40 | 1.96 |
| Intel SSD 910 800GB Icke-RAID, JBOD x 4 (MLC) |
4.29 | 3.21 | 8.27 | 3.43 | 2.23 |
| Fusion ioDrive2 MLC 1.2TB S/W RAID0, högpresterande läge, 4 partitioner (MLC) |
4.69 | 3.58 | 9.15 | 3.74 | 2.28 |
| OCZ Deneva 2 200GB JBOD x 4 (MLC) |
6.65 | 5.38 | 13.48 | 4.54 | 3.18 |
| Kingston E100 200GB JBOD x 4 (MLC) |
8.00 | 6.82 | 16.22 | 5.46 | 3.49 |
| Smart CloudSpeed 500 240GB JBOD x 4 (MLC) |
11.06 | 9.07 | 22.74 | 7.19 | 5.23 |
| Micron P400m 400GB JBOD x 4 (MLC) |
12.60 | 9.70 | 27.51 | 8.70 | 4.51 |
| Fusion ioDrive Duo MLC 1.28TB S/W RAID0, högpresterande läge, 4 partitioner (MLC) |
12.89 | 10.52 | 26.77 | 9.70 | 4.58 |
| Micron P400m 200GB JBOD x 4 (MLC) |
14.98 | 11.99 | 31.93 | 10.54 | 5.46 |
| Toshiba 15K MK01GRRB 147GB H/W LSI 9286-8e x 16, RAID10 x 4 |
16.58 | 7.85 | 40.61 | 12.25 | 5.61 |
| LSI Nytro WarpDrive 800GB 4 partitioner (MLC) |
17.39 | 17.08 | 31.42 | 13.63 | 7.43 |
| Toshiba 10K MBF2600RC 600GB H/W LSI 9286-8e x 16, RAID10 x 4 |
24.20 | 10.89 | 57.94 | 20.61 | 7.35 |
| Toshiba 15K MK01GRRB 147GB S/W RAID x 16, RAID10 x 4 |
61.40 | 54.33 | 126.77 | 45.21 | 19.28 |