Die NoSQL-Generation: Das Dokumentenmodell
Werbung
Die NoSQL-Generation: Das Dokumentenmodell Mai 2014 Inhalt Einleitung _________________________________________________________________ 3 Die Geschichte von „NoSQL“ ____________________________________________________ 3 Die verschiedenen Arten der NoSQL-Datenbanken ____________________________________ 4 Das Dokumentenmodell _______________________________________________________ 7 Die Definition von Enterprise NoSQL _____________________________________________ 11 Einleitung NoSQL-Datenbanken stellen eine neue Generation von Datenbanken dar, die äußerst erfolgreich sind, weil sie die Herausforderungen im Hinblick auf das Volumen, die Vielfalt und die Geschwindigkeit von Big Data bewältigen. NoSQL (Not only SQL = nicht nur SQL) steht für eine grundlegend neue Denkweise bezüglich der Art und Weise, wie Daten gespeichert und verwaltet werden. Diese neue Denkweise widerspricht dem Ansatz der relationalen Datenbanken, der für Oracle Database 12c, Oracle MySQL, Microsoft SQL Server, IBM DB2, Postgres u. v. a. verwendet wird. 1 Der Begriff „NoSQL“ beschreibt eine Vielzahl neuer Datenbanken, die sich in vier Hauptkategorien unterteilen lassen: Dokumenten-, Key-Value-, spaltenorientierte und Graphdatenbanken. Die Dokumentendatenbanken stellen dabei die besten Mehrzweck-Datenbanken dar. Dokumentendatenbanken verfolgen einen logischeren, „menschlicheren“ Ansatz der Datenmodellierung. Sie sind in der Regel sehr flexibel und benutzerfreundlich und daher am beliebtesten. Von den Dokumentendatenbanken unterscheidet sich MarkLogic als „Enterprise NoSQL“-Datenbank, weil es sich hierbei um eine NoSQL-Datenbank mit allen wichtigen Merkmalen handelt, die Unternehmen für die Ausführung betriebskritischer Anwendungen benötigen. Dazu gehören ACID-Transaktionen, Hochverfügbarkeit, Disaster Recovery, Hochsicherheit, Elastizität und Skalierbarkeit sowie Tools zur Leistungsüberwachung. Mit MarkLogic können Unternehmen das Dokumentenmodell einführen und sicher in das nächste Zeitalter der Datenbanken eintreten. Die Geschichte von „NoSQL“ MarkLogic hat sich mittlerweile einen Namen als Enterprise NoSQL-Datenbank gemacht, war ursprünglich jedoch aufgrund ihrer Fähigkeit bekannt, XML zu speichern und zu durchsuchen. Bei den Patenten von 2002 ging es um eine neue Methode zum Speichern von Daten mithilfe der XML-Baumstruktur und zum Abfragen dieser Daten. Diese Patente wurden vom MarkLogic Gründer Christopher Lindblad angemeldet, lange bevor der Begriff „NoSQL“ geprägt wurde. Seitdem verwendet MarkLogic diesen Begriff mit dem Zusatz „Enterprise“ oder „unternehmenserprobt“, um ihn von den zahlreichen neuen Datenbanken zu unterscheiden, die seitdem entwickelt wurden, aber noch keine unternehmenskritische Funktionen umfassen. Der Begriff „NoSQL“ ist erst seit 2009 in Gebrauch. Er wurde ursprünglich als Twitter-Hashtag verwendet, um für eine Gruppe zu werben, die sich in San Francisco zusammenfand, um sich mit neuen Datenbanktechnologien auseinanderzusetzen. Diese Gruppe wurde von Johan Oskarsson organisiert, einem Entwickler aus London. Eric Evans, ein Entwickler von Rackspace, schlug den Begriff „NoSQL“ vor. Eigentlich sollte „NoSQL“ nur als eine Art Arbeitstitel dienen, setzte sich aber schnell dauerhaft durch. Mit der explosionsartigen Entstehung neuer 1 Gartner, „Hype Cycle for Big Data, 2013“, 31. Juli 2013. MarkLogic Corporation Die NoSQL-Generation: Das Dokumentenmodell 3 Datenbanken wie Cassandra, MongoDB und CouchDB, die Googles Bigtable und Amazons Dynamo nachfolgten, benötigte der Markt einen Begriff, der diese neuen Technologien beschrieb.2 Ein häufiges Missverständnis ist, dass „NoSQL“ so viel bedeutet wie „Kein SQL“ und dass NoSQL-Datenbanken kein SQL (Structured Query Language) als Abfragesprache verwenden. Viele NoSQL-Datenbanken nutzen jedoch SQL als eine von vielen unterstützten Abfragesprachen. So unterstützt MarkLogic z. B. Java, SQL, XQuery und SPARQL. Daher wird NoSQL gemeinhin als Abkürzung für „Not only SQL“ („nicht nur SQL“) verstanden. Obwohl der Begriff „NoSQL“ besser beschreibt, was er nicht ist (anstatt was er ist), stellt er dennoch eine passende Beschreibung für viele Datenbanken dar, die optimal für die Lösung moderner Datenprobleme geeignet sind. Die verschiedenen Arten der NoSQL-Datenbanken NoSQL-Datenbanken sind sehr gut für die Handhabung des hohen Volumens, der Vielfalt und der Geschwindigkeit von Big Data geeignet. Die Handhabung dieser drei Faktoren ist allerdings je nach dem verwendeten Datenmodell sehr unterschiedlich. Darum werden NoSQL-Datenbanken gemäß ihrem Datenmodell in Dokumenten-, Key-Value-, spaltenorientierte und Graphdatenbanken unterteilt. MarkLogic ist eine Dokumentendatenbank, die jedoch auch RDF-Tripel speichern kann (diese Funktion wird als „Semantik“ bezeichnet) und daher Merkmale einer Graphdatenbank aufweist. Dokumentendatenbanken Dokumentendatenbanken werden auch als „dokumentenorientierte Datenbanken“ bezeichnet und verwenden Dokumente als Grundeinheit für Speicherung und Abfragen. Der Begriff „Dokument“ bezeichnet hier nicht unbedingt ein PDF- oder Microsoft Word-Dokument, es kann sich auch um einen einzelnen XML- oder JSON-Block handeln. Abbildung 1: MarkLogic ist eine Dokumentendatenbank, die XML, JSON, Text und große Binärdateien wie PDF- und Microsoft Office-Dokumente speichern kann. 2 Fowler, Martin, NoSQL Distilled. Pearson Education, Inc., 2013. MarkLogic Corporation Die NoSQL-Generation: Das Dokumentenmodell 4 Ein XML-Dokument erfordert keine vordefinierten Felder und kann auch verschachtelte Daten speichern, häufig in einer baumartigen Struktur, die für Abfragen geeignet ist. Dokumentendatenbanken sind ideal für das Speichern großer Mengen an Textinformationen wie Bücher oder andere Schriften, können aber auch zur Speicherung zahlreicher anderer Informationsarten wie Finanzdaten, Krankenakten oder Metadaten eingesetzt werden. Anders gesagt, könnte ein Dokument also alle Informationen enthalten, die in der Zeile einer relationalen Tabelle enthalten sind. Aufgrund ihrer Flexibilität sind Dokumentendatenbanken die beliebtesten NoSQL-Datenbanken. Key-Value-Datenbanken Key-Value-Datenbanken weisen das einfachste Datenmodell aller NoSQL-Datenbanken auf – sie verwenden einen durchsuchbaren Indexschlüssel, der mit einem Wert verknüpft ist. Relationale Key-Value-Datenbanken gibt es bereits seit vielen Jahren, doch die neueren Key-Value-Datenbanken fallen unter die NoSQL-Kategorie, weil sie speziell im Hinblick auf Geschwindigkeit und Skalierbarkeit entwickelt wurden, was zulasten der Funktionsvielfalt geht. So gibt es z. B. generell keine Alternativschlüssel und keine Fremdschlüssel, kein implizites Ordnen und keine Textsuchfunktionen zu den Werten. Diese Datenbanken werden häufig für das Caching von Websitebesuchen verwendet, und eine der bekanntesten Key-Value-Datenbanken, „memcache“, wurde nach diesem Zweck benannt. Zu den weiteren Nutzungsmöglichkeiten gehören das Speichern der Benutzereinstellungen in einer Anwendung oder großer nicht-transaktionaler Datenströme. Spaltenorientierte Datenbanken Eine spaltenorientierte Datenbank ist theoretisch mit einer Tabelle in einer relationalen Datenbank vergleichbar, ist jedoch auf zig Milliarden Zeilen skalierbar, wobei jede Zeile eine beliebige Anzahl an Spalten aufweisen kann. Jede sogenannte „Spaltenfamilie“, die mit einer Zeile verbunden ist, besteht aus einem Schlüssel-Wert-Paar (einem Spaltenschlüssel und einem Schlüsselwert). Spaltenfamilien wurden nach der Veröffentlichung des Bigtable Paper von Google bekannt, und diese Bekanntheit wurde durch die Beliebtheit von Cassandra und HBase noch gesteigert. Spaltenorientierte Datenbanken kommen vor allem bei der Überwachung von Anwendungsereignissen, in Content-Management-Systemen und bei BlogPlattformen zum Einsatz. Sie sind allerdings nicht die beste Wahl, wenn es um ACID-Transaktionen oder um komplexe und wechselnde Abfragen geht. Abbildung 2: Spaltenorientierte Datenbanken wie Cassandra ordnen Daten nach einem Zeilenschlüssel, der mit beliebig vielen Spalten verknüpft ist. MarkLogic Corporation Die NoSQL-Generation: Das Dokumentenmodell 5 Graphdatenbanken Bei Graphdatenbanken stehen die Beziehungen zwischen den Daten im Mittelpunkt. Daher werden Graphdaten auch als „Linked Data“ (verknüpfte Daten) bezeichnet. Datenpunkte werden als „Knoten“ bezeichnet, und die Beziehungen zwischen den Datenpunkten heißen „Edges“. Aufgrund dieser Beziehungen sind Graphdatenbanken ideal für Social-Media-Websites wie LinkedIn, Facebook oder Twitter, wo Fragen zum „Grad der Trennung“ zwischen Personen gestellt werden. Eine Methode zur Speicherung von Linked Data beruht auf einer bestimmten Art von Graphdatenbank, die als „RDFTripel-Datenbank“ bezeichnet wird. RDF steht für „Resource Description Framework“, und ein Tripel ist eine Kombination aus Subjekt, Prädikat und Objekt – z. B. „Karl [Subjekt] kennt [Prädikat] Shakespeare [Objekt].” Es gibt jedoch einige kleine, aber feine Unterschiede zwischen RDF-Tripel-Datenbanken und Mehrzweck-Graphdatenbanken. Graphdatenbanken RDF-Tripel-Datenbanken Beispiele Neo4j, Titan, OrientDB MarkLogic, AllegroGraph, Sesame Arten der gespeicherten Daten Unbenannte Graphe, Graphe ohne Ausrichtung, gewichtete Graphe, Hypergraphe RDF-Tripel Abfragesprache(n) Cypher, G, GraphLog, GOOD, SoSQL, BiQL, SNQL u. v. a. m. SPARQL Weitere Attribute Optimiert für Graphentraversierung Graphentraversierung kann langsam sein Keine Schlussfolgerungen möglich (d. h. kein Schlussfolgern neuer Tripel auf der Grundlage vorhandener Daten) Schlussfolgerungen möglich (Beispiel: Wenn Menschen eine Unterklasse von Säugetieren darstellen und ein Mann eine Unterklasse von Menschen ist, kann geschlussfolgert werden, dass ein Mann eine Unterklasse von Säugetieren darstellt.) MarkLogic weist Funktionen des semantischen Web sowie Merkmale einer Graphdatenbank auf, weil diese Lösung RDF-Tripel speichern und sie mit SPARQL abfragen kann. Das folgende Beispiel zeigt, wie MarkLogic Semantik für die Erstellung einer interaktiven Visualisierung verwendet werden kann – eine Funktion, die durch Linked Data ermöglicht wird. Abbildung 3: GoldmineR ist eine von FactGem entwickelte Anwendung, die Semantik von MarkLogic nutzt, um Verbindungen wie Investmentbeziehungen zwischen Risikokapitalgebern darzustellen. MarkLogic Corporation Die NoSQL-Generation: Das Dokumentenmodell 6 Das Dokumentenmodell Dokumentendatenbanken sind die beliebtesten NoSQL-Datenbanken, weil sie leistungsstark und flexibel genug sind, um als Mehrzweck-Datenbank zu fungieren. MarkLogic weist zwar einige Funktionen einer Graphdatenbank auf, ist aber im Prinzip eine Dokumentendatenbank. Dieser Ansatz hat sich bewährt, weil es wesentlich einfacher ist, eine Dokumentendatenbank durch Graph-Funktionen zu erweitern als umgekehrt. Im Folgenden werden die fünf Hauptargumente für die Einführung des Dokumentenmodells von MarkLogic genannt. Eine logischere und „menschlichere“ Struktur Der Mensch gliedert Informationen naturgemäß anhand von Hierarchien und Gruppierungen – was der Struktur von Dokumenten entspricht. Dies wird sogar in Branchen wie dem Finanzsektor oder dem Gesundheitswesen deutlich, von denen man annehmen könnte, dass ihre Daten immer strukturiert sind. Daten zu Derivategeschäften und Gesundheitsdaten lassen sich problemlos als Dokumente modellieren. Dennoch versucht man seit Jahren, diese Daten in relationale Schemas zu bringen, auf die sich nie alle Beteiligten einigen können. Das Dokumentenmodell erleichtert das Verständnis der Daten aus einer menschlichen Perspektive, und MarkLogic sorgt dafür, dass sie auch für den Computer leicht verständlich sind. Weitere Informationen zum neuen MarkLogic Ansatz der Datenmodellierung erhalten Sie in der Präsentation Data Modeling in NoSQL with XML, RDF, and JSON (Datenmodellierung in NoSQL mit XML, RDF und JSON). Schema-agnostisch und strukturbewusst Dokumentendatenbanken sind Schema-agnostisch, können bei Bedarf jedoch ein Schema erzwingen, weil sie auch strukturbewusst sind. Investmentbanken müssen bei der Verarbeitung von Finanztransaktionen immer wieder Schemas erzwingen. Wenn die Bank solch ein Schema später jedoch ändern muss, kann diese Änderung relativ schnell vorgenommen werden. Dieser Ansatz – Verwendung von Schemas nach Bedarf – stellt einen großen Unterschied zum relationalen Ansatz dar, bei dem die Änderung eines Schemas mehrere Monate in Anspruch nehmen kann. Beim Laden von Daten muss im Vorfeld nicht viel über die Daten bekannt sein. So ist es zwar hilfreich, wenn man weiß, wie die Abfragen strukturiert werden sollen, weil dies die primären IDs der Dokumentengruppen beeinflussen kann, aber dieses Wissen ist nicht unbedingt erforderlich. Mit MarkLogic werden die Daten indexiert und können unabhängig vom Schema unmittelbar nach dem Import abgefragt werden. Sämtliche Daten innerhalb eines Dokuments sind eigenständig und damit unabhängig von Daten aus anderen Dokumenten innerhalb der Datenbank. Das bedeutet, dass weder Fremdschlüssel noch eine Normalisierung erforderlich sind. Da alle Dokumente eigenständig sind, lassen sich Daten mühelos auf mehrere Cluster verteilen, was wiederum die Einrichtung von Clustern und die Skalierung von Dokumentendatenbanken vereinfacht. Mit MarkLogic sind Sie in der Lage, einen Cluster in der Cloud innerhalb von Minuten zu erstellen oder zu entfernen. MarkLogic Corporation Die NoSQL-Generation: Das Dokumentenmodell 7 Außerdem verbessert das Dokumentenmodell die Systemleistung, weil eine Gruppe von Dokumenten als fortlaufender Inhalt für Abfragen auf der Festplatte dargestellt werden kann. Weitere Informationen darüber, wie MarkLogic mit Legacy-Schemas für Investmentbanken umgeht, erhalten Sie in der Präsentation Schema on Read in Financial Services („Schema on Read“ für Finanzdienstleister). Einfache Anwendungsentwicklung Es überrascht nicht, dass in den meisten IT-Abteilungen Entwickler die absoluten NoSQL-Verfechter sind, denn NoSQL macht ihnen das Leben leichter. Der größte Vorteil besteht in der Zeitersparnis, die dadurch erzielt wird, dass unstrukturierte Daten nicht relational modelliert und komplex strukturierte Daten nicht aggregiert werden müssen. Vor allem das Dokumentenmodell spart Zeit, weil die Daten häufig bereits in einem Dokumentenformat wie XML oder JSON vorliegen. Founder's Online, eine Anwendung, die von der University of Virginia Press in Zusammenarbeit mit dem USamerikanischen Staatsarchiv entwickelt wurde, enthält z. B. annähernd 150.000 durchsuchbare Dokumente, die mit XML markiert und anschließend in MarkLogic geladen wurden. Diese Anwendung wurde von zwei Entwicklern in wenigen Monaten erstellt und zeichnet sich durch eine hohe Skalierbarkeit mit Antwortzeiten von 120 ms bei 5.000 gleichzeitigen Benutzerzugriffen aus.3 Abbildung 4: Founder's Online, eine leistungsstarke Suchanwendung von zwei Entwicklern Entwickler bevorzugen das Dokumentenmodell, weil es mit den bei Entwicklern besonders beliebten Sprachen PHP, Ruby und JavaScript kompatibel ist, die in erster Linie objektbasiert sind. Diese Sprachen erleichtern die Darstellung des Dokuments als Objekt. Wenn Dokumente nativ als JSON in der Datenbank gespeichert werden, sind JavaScript und JSON in der Datenbank, auf dem Server und auf dem Front-End-Client einsetzbar. Die Daten müssen also nicht transformiert werden, um sie zwischen verschiedenen Tiers verschieben zu können. So werden die ServerAuslastung reduziert und die Entwicklung vereinfacht. Darüber hinaus profitieren Sie von höherer Flexibilität, weil die Anwendungs- und Geschäftslogik auf jedem beliebigen Tier abgelegt werden kann. Im Falle eines Fehlers sind die Kosten einer nachträglichen Änderung minimal. 3 Weitere Informationen erhalten Sie in der Präsentation Planning For Growth With and Without Performance Metering (Wachstumsplanung mit und ohne Leistungsmessung) von David Sewell, Editorial and Technical Manager der University of Virginia Press. MarkLogic Corporation Die NoSQL-Generation: Das Dokumentenmodell 8 Informationen zur schnellen Anwendungsentwicklung am Beispiel eines Unternehmens erhalten Sie in der Präsentation Building Applications on MarkLogic Fast and Easy (Schnelle und einfache Anwendungsentwicklung mit MarkLogic). Erweiterte Suche Ein Nachteil von stark vereinfachten NoSQL-Datenbanken wie Key-Value-Datenbanken besteht darin, dass Abfragen in der Regel nur für den Primärschlüssel gelten. In einer Dokumentendatenbank gelten Abfragen für sämtliche Daten einschließlich der Dokumenten-ID und der Inhalte der Dokumente. Dokumentendatenbanken können sich zur Unterstützung der Suche auch auf Indexe stützen. MarkLogic verfügt über fast 30 verschiedene Indexe, die sich aktivieren und deaktivieren lassen, um möglichst detaillierte und anpassbare Suchvorgänge zu ermöglichen, einschließlich facettierter Suchen und Echtzeit-Benachrichtigungen. Diese Suchfunktionen waren von Anfang an in MarkLogic integriert, denn der Gründer von MarkLogic verfügt über langjährige Erfahrungen auf diesem Gebiet: Christopher Lindblad war der Architekt von Ultraseek Server. MarkLogic unterstützt zudem viele weitere Suchfunktionen wie Wort- und Phrasensuche, Boolesche Suche, Näherung, Platzhalter, automatische Zurückführung eines Wortes auf den Wortstamm (Stemming), Tokenisierung, Zerlegung von Komposita, Unterscheidung nach Groß-/Kleinschreibung, Interpunktion, diakritische Zeichen, Einstellungen zur Dokumentenqualität, verschiedene Relevanzalgorithmen, individuelle Begriffsgewichtung, Themengruppierung, facettierte Navigation und Benutzer-indexierte Felder. Diese zahlreichen Funktionen werden durch die Nutzung des Dokumentenmodells in MarkLogic ermöglicht, aber nur MarkLogic verfügt über eine integrierte Suche. Andere Dokumentendatenbanken sind im Hinblick auf Suchfunktionen von externen Technologien wie Lucene oder Solr abhängig, was zu einer höheren Komplexität führt. Ein weiteres Unterscheidungsmerkmal besteht darin, dass Dokumente in MarkLogic unmittelbar nach dem Laden durchsucht werden können, wenn ihre Inhalte indexiert sind. Weitere Informationen darüber, wie MarkLogic die Datenbanksuche revolutioniert, erhalten Sie in der Präsentation Search, Relevance, and Context: Getting the Most out of MarkLogic Search (Suche, Relevanz und Kontext: Optimale Nutzung von MarkLogic Search). Riesenvielfalt möglicher Anwendungsbereiche Unternehmensgerechte Datenbanken, die auf dem Dokumentenmodell basieren, sind flexibel und leistungsstark genug, um als Mehrzweck-Datenbanken für vielfältige Anwendungsfälle zu fungieren. MarkLogic ist die perfekte Lösung, wenn es darum geht, Datensilos zu beseitigen, Suchen und Analysen über eine einzige Plattform abzuwickeln, Speicherkosten zu senken, Daten besser zu sichern oder Anwendungen schneller zu entwickeln. Dies gilt für fast jede Branche, von Medien und Verlagswesen über Finanzdienstleistungen bis hin zum Gesundheitswesen: MarkLogic Corporation Die NoSQL-Generation: Das Dokumentenmodell 9 • Medien und Verlagswesen: Diese Branche war die erste, die Dokumentendatenbanken eingeführt hat. Ein großer Verlag, LexisNexis, war der erste MarkLogic Kunde und setzt MarkLogic auch heute noch ein. Ein weiterer Verlag, Wiley, hat mithilfe von MarkLogic 4 Millionen Artikel, 9.000 Bücher und Tausende von Nachschlagewerken konsolidiert. Damit konnte der Verlag die Nutzung seines Angebots um 50 Prozent erhöhen und nach einigen strategischen Übernahmen von Inhaltsbibliotheken das neue Material schnell integrieren und gewinnbringend anbieten. • Finanzdienstleister: Investmentbanken benötigen zuverlässige Governance-Richtlinien und müssen in der Lage sein, schnell auf Anfragen von Regulierungsbehörden zu reagieren. Eine führende Bank hatte Probleme bei der Erstellung von Risikoprofilen und Nachhandelsberichten, weil ihre verteilten, heterogenen Datenquellen in Legacy-Mainframes und Sybase-Datenbanken abgelegt waren. Mit MarkLogic konnte die Bank diese Daten jedoch in einem zentralen System zusammenführen und war dadurch in der Lage, Millionenbeträge an IT-Kosten einzusparen und schneller auf Anfragen der Regulierungsbehörden zu reagieren. • Gesundheitswesen: Das Gesundheitswesen ist ebenfalls eine stark regulierte Branche, die sich schwertut, ihre Datenvielfalt zu verwalten, und die mit schrumpfenden Margen und behördlicher Beaufsichtigung zu kämpfen hat. Ein MarkLogic Kunde, Zynx Health, bietet im Verbund mit mehreren Krankenhäusern in den USA personalisierte Versorgungspläne an. Obwohl die Partnerschaft mit über 2.000 Krankenhäusern eine große Herausforderung darstellte, konnte Zynx Health in weniger als einem Jahr eine Anwendung entwickeln, die heute von all diesen Krankenhäusern genutzt wird, um die Qualität ihrer Versorgung zu verbessern. • Behörden: Behörden lieben Dokumente. Wenn die Budgets jedoch eng sind und bestimmte Dienste online angeboten werden sollen, stehen Behörden vor der Herausforderung, fristgerecht und effizient Anwendungen entwickeln zu müssen. Darüber hinaus wollen sie kein komplett neues System aufbauen oder ihre Daten für jede neue Anwendung immer wieder replizieren – und natürlich unterliegen sie strengsten Auflagen zum Datenschutz. MarkLogic hat US-Behörden wie die Bundesluftfahrtbehörde (FAA), die Centers for Medicare and Medicaid Services (CMS), die Arzneimittelzulassungs- und Lebensmittelüberwachungsbehörde (FDA) und das Verteidigungsministerium (DoD) sowie Nachrichtendienste bei der Bewältigung dieser Herausforderungen unterstützt. Während relationale Datenbanken und andere Arten von NoSQL-Datenbanken auch weiterhin für bestimmte Zwecke eingesetzt werden, kommen Dokumentendatenbanken wie MarkLogic bei der Lösung der dringlichsten Big DataProbleme zum Einsatz, denen sich Organisationen heutzutage gegenübersehen. Weitere Informationen zu den zahlreichen Einsatzmöglichkeiten von MarkLogic erhalten Sie in der Präsentation Reimagine: Data, Applications and MarkLogic (Neue Möglichkeiten: Daten und Anwendungen und MarkLogic). MarkLogic Corporation Die NoSQL-Generation: Das Dokumentenmodell 10 Die Definition von Enterprise NoSQL Es ist eine weitverbreitete Fehlannahme, dass NoSQL-Datenbanken nicht für „seriöse“ Anwendungsbereiche geeignet sind, sondern nur für Neuunternehmen oder als Aufbewahrungsort für nicht betriebskritische Daten. Die oben genannten Beispiele zeigen jedoch, dass dies nicht mehr der Wahrheit entspricht. „Enterprise NoSQL“ bezeichnet eine Datenbank, die wie alle anderen NoSQL-Lösungen das hohe Volumen, die Vielfalt und die Geschwindigkeit heutiger Daten bewältigen kann und darüber hinaus mit den Funktionen ausgestattet ist, um das Herzstück eines Unternehmens zu bilden. Eine NoSQL-Lösung ist erst dann „unternehmensgerecht“, wenn sie die folgenden Funktionen aufweist, und sollte andernfalls nicht für betriebskritische Anwendungen eingesetzt werden: • ACID-Transaktionen: ACID-Transaktionen kommen nicht nur im Bankwesen zum Einsatz. Ohne ACIDTransaktionen (Atomarität, Konsistenz, Isolation, Dauerhaftigkeit) steigt die Gefahr des Datenverlusts. Und wenn es zu einem Netzwerkausfall kommt, kann dies katastrophale Folgen für die Datenbank haben. Unternehmen müssen in der Lage sein, Transaktionen auszuführen, die aus mehreren Datensätzen bestehen, und detaillierte Abfragen mit mehreren Begriffen vorzunehmen – zusätzliche Funktionen, die durch ACID-Transaktionen bereitgestellt werden. • Hochverfügbarkeit und Disaster Recovery: Unternehmen sollten nicht dazu gezwungen sein, komplett neue Verfahren und Governance-Strukturen zu implementieren, um Daten in einer NoSQLDatenbank zu verwalten. Für die Disaster Recovery benötigen sie Hochverfügbarkeit mit automatischem Failover auf lokale Festplatten, zeitgenauer Wiederherstellung und asynchroner Replikation über verschiedene Rechenzentren hinweg. All diese Funktionen sind erforderlich, um zu verhindern, dass Daten verlorengehen und die Datenbank neu aufgebaut werden muss, falls es zu einem Ausfall des Rechenzentrums kommt. • Hochsicherheit: Nicht nur bei Behörden spielt Sicherheit eine zentrale Rolle. Das Risiko, das mit nicht gesicherten Daten einhergeht, ist ganz einfach zu hoch – daher werden die Investitionen in die ITSicherheit laut Gartner bis zum Jahr 2017 um etwa 39 Prozent auf 93 Mrd. US-Dollar steigen. Für Hochsicherheit bürgt eine Zertifizierung der National Information Assurance Partnership (NIAP) im Rahmen des Common Criteria Evaluation and Validation Scheme (CCEVS) für die Unterstützung der Hauptsicherheitsfunktionen wie Audits, Schutz von Benutzerdaten, Sicherheitsmanagement, Datenschutz, TOE-Zugriff (Target of Evaluation, Evaluierungsgegenstand) sowie Identifizierung und Authentifizierung (mit Drittanbieter-Support für LDAP und Kerberos). • Elastizität und Skalierbarkeit: Unternehmen sollten in der Lage sein, Aufwärts- oder Abwärtsskalierungen innerhalb von Minuten vorzunehmen, um den anfallenden Datenmengen und Zugriffsanforderungen gerecht zu werden sowie Over-Provisioning und unnötige Ausgaben zu vermeiden. Dies muss ohne Ausfallzeiten, ohne Inkonsistenzen und ohne Risiko eines Datenverlusts geschehen. Die Datenbank sollte problemlos auf Amazon Web Services oder anderen Cloud-Anbietern laufen, gleichzeitig aber flexibel genug sein, um in anderen virtualisierten Umgebungen oder vor Ort installiert werden zu können. MarkLogic Corporation Die NoSQL-Generation: Das Dokumentenmodell 11 • Überwachungs- und Leistungstools: Ausgereifte Überwachungs- und Verwaltungstools sorgen dafür, dass sowohl die Entwickler als auch die IT-Mitarbeiter mit der Wahl der Plattform zufrieden sind. Unternehmen benötigen Tools für den automatischen Lastenausgleich und die Cluster-Überwachung sowie funktionsreiche APIs für Verwaltung, Prozessautomatisierung, Zugriffssteuerung, Datenbank-Klonung und Audit-Trails. Außerdem brauchen sie sofort einsatzbereite Schnittstellen mit Tools wie Nagios oder HP OpenView. MarkLogic enthält all diese Funktionen seit jeher und wird auch in Zukunft auf die Entwicklung von Unternehmensfunktionen setzen, die keine andere NoSQL-Lösung vorweisen kann. Weitere Ressourcen finden Sie online unter MarkLogic.com. Ausführlichere Informationen enthält das Whitepaper Inside MarkLogic (Überblick über MarkLogic). Wenn Sie Fragen zur Implementierung von MarkLogic in Ihrem Unternehmen haben, rufen Sie uns unter +1 877 992 8885 an oder kontaktieren Sie einen Vertriebsmitarbeiter per E-Mail an [email protected]. MarkLogic Corporation Die NoSQL-Generation: Das Dokumentenmodell 12 Über MarkLogic MarkLogic stellt seinen Kunden seit über einem Jahrzehnt eine leistungsstarke, flexible und bewährte Enterprise NoSQL-Datenbank-Plattform bereit, die Unternehmensdaten in wertvolle und praktisch anwendbare Informationen verwandelt. Unternehmen auf der ganzen Welt verlassen sich bei Datenanwendungen der neuen Generation auf die hochsichere Technologie von MarkLogic. MarkLogic hat seinen Hauptsitz im Silicon Valley und betreibt Niederlassungen in New York, Chicago, Washington D.C., London, Frankfurt, Paris, München, Stockholm, Utrecht, Singapur und Tokio. Weitere Informationen finden Sie auf www.marklogic.com. © 2014 MarkLogic Corporation. Alle Rechte vorbehalten. Diese Technologie ist durch die US-amerikanischen Patente Nr. 7,127,469 B2, Nr. 7,171,404 B2, Nr. 7,756,858 B2 und Nr. 7,962,474 B2 geschützt. MarkLogic ist eine Marke oder eingetragene Marke der MarkLogic Corporation in den USA und/oder anderen Ländern. Alle anderen genannten Marken sind Eigentum ihrer jeweiligen Inhaber. [SS-MLIH-13-06] Skyper Villa, Taunusanlage 1, Frankfurt 60329, Germany Theatinerstr. 11, 8. Etage, Munich 80333, Germany › DE: +49-69-50 50 60588 › INT.: +1 877 992 8885 › [email protected] › [email protected] › www.marklogic.com
