Andere Datenbankmodelle. Graphendatenbanken

Transkript

1 Andere Datenbankmodelle Graphendatenbanken

2 Datenbankmodelle Relationale Datenbank (SQL) NoSQL (Not Only SQL): Implementierungen können folgendermaßen nach Datenmodell gegliedert werden: Dokumentorientierte Datenbanken Objektdatenbanken Graphdatenbanken Key-Value-Datenbanken Multivalue-Datenbanken u.a.

3 Relationale Datenbank Daten werden in Tabellen gespeichert Die Tabellen stehen zueinander in Beziehung (Fremdschlüssel) Nachteil: die Daten sind segmentiert mit der Erhöhung der Anzahl der abgefragten Segmente verringert sich die Performanz der Abfrageverarbeitung

4 NoSQL Objektorientierte Datenbank Objektdatenbankmanagementsystem wird als ODBMS gekennzeichnet Die zu einem Objekt gehörenden Daten werden im Objekt selbst abgelegt Die interne Organisation und Verwaltung der Daten wird komplett vom ODBMS übernommen Für die Abfrage und Manipulation der Daten stellt das ODBMS geeignete Objektsprachen bereit Nachteile: Sind nur gering verbreitet und damit gibt es auch wenige Tools Durch die hohe Komplexität eines einzelnen Objektes kann es bei Manipulationsoperationen zu massiven Performanceproblemen kommen

5 NoSQL Dokumentbasierte Datenbank Es gibt keine Relation zwischen den Daten Jeder Eintrag in der DB wird in einem eigenen Dokument gespeichert, das über eine eindeutige ID identifiziert wird Werden am häufigsten in Web-Applikationen eingesetzt Meistgenutzte Formate sind XML und Json In den unterschiedlichen Formate findet man meistens die Informationen als Key/Value - Paaren Jedes Dokument enthält seine eigene Struktur Nachteile: Ungeeignet für komplexe Datenstrukturen Der Aufwand bei der Programmierung, wenn man mit solchen DBs arbeitet kann erhöht werden, da die Struktur der Dokumente nicht festgelegt ist Viele in der relationalen oder objektorientierten DB zur Verfügung stehende Funktionalitäten (z.b. Datenmanipulation) müssen individuell programmiert werden

6 NoSQL Dokumentbasierte Datenbank - MongoDB MongoDB abgeleitet von humongous Ist eine dokumentorientierte NoSQL-Datenbank (geschrieben in C++) Eine der am weitesten verbreitete NoSQL-Datenbank Bietet eine weniger mächtige Abfragesprache an im Vergleich zu SQL Nachteil: die Anwendugsschicht muss mehr Logik implementieren um die gleichen Ergebnisse zu erzielen wie mit SQL-Datenbanken Vorteil: die Arbeitslast kann einfacher auf mehrere Server verteilt werden (man braucht nicht große Join Operationen) Es gibt kein Schema, das die Daten beschreibt Vorteil: unterstützt agile Softwareentwicklung, da es einfacher ist, auf veränderte Anforderungen zu reagieren Nachteil: man muss selber wissen, wie die Daten strukturiert sind

7 NoSQL Graphdatenbanken Motivation: Fremdschlüssel führen zu Entwicklungoverhead: das Überprüfen der Fremdschlüsseln ist aufwändig Das starre Schema der relationalen Datenbank fürht zu vielen NULL-Werten Viele JOINs nötig um Beziehungen wiederherzustellen Anwendung hat großen Einfluss auf Schemadesign Die Semantik von Beziehungen ist im Schema nicht ersichtlich Lösung: Graphendatenbank

8 NoSQL Graphdatenbanken Graphendatenbank = eine Datenbank, die Graphen benutzt um stark vernetzte Informationen darzustellen und abzuspeichern Ein Graph besteht aus Knoten und Kanten, welche die Knoten verbinden Sowohl Knoten als auch Kanten können Eigenschaften (Properties) haben dann redet man von einem Property-Graphen Da innerhalb eines solchen Graphen Kanten traversiert werden können, ist die Suche von Beziehungen unter den Knoten ungleich schneller als bei relationalen Datenbanken

9 NoSQL Graphdatenbanken Graphendatenbanken können spezialisierte Graphenalgorithmen benutzen, um komplizierte Datenbankabfragen zu vereinfachen (z.b. Dijkstra-Algorithmus oder A*-Algorithmus für kürzeste Weg) Es gibt keinen Standard für die Abfrage von Graphdatenbanken, daher gibt es unterschiedliche Abfragesprachen

10 NoSQL Graphdatenbanken Neo4j Neo4j ist eine Graphendatenbank welche Property-Graphen benutzt Neo4j ist schemafrei und gut skalierbar Die Community-Edition der Datenbank ist Open Source Abfragesprache: Cypher (besitzt aber auch eine REST-API für Abfragen) Beispiel von Abfrage: MATCH (actor:person)-[:acted_in]->(movie:movie) WHERE movie.title STARTS WITH "T" RETURN movie.title AS title, collect(actor.name) AS cast ORDER BY title ASC LIMIT 10;

11 NoSQL Graphdatenbanken Neo4j Interessante Anwendungen: Soziale Beziehungen können sehr gut als Graph dargestellt werden Geoinformationen eignen sich auch gut Usw. Neo4j ist eine der populärsten Graphdatenbanken mit Kunden wie ( ): ebay Airbnb Microsoft IBM NASA Cisco

12 Neo4j vs. relationale Datenbank Bemerkungen: Die Fremdschlüsseln aus der relationalen Datenbank werden als Labels für die Kanten benutzt (Beziehungen in dem Graphendatenbank) Aus einfachen Join Tabellen entstehen Beziehungen Z.B. Enrolled(MatrNr, VorlNr) ENROLLED Aus Join Tabellen mit Attributen entstehen Beziehungen mit Properties Z.B. OrderDetails(OrderID, ProductID, Quantity,..) ORDERS mit Property Quantity

13 Neo4j vs. relationale Datenbank Beispiel von relationale Datenbank: Products(ProductID, ProductName, CategoryID, SupplierID, Price,...) Suppliers(SupplierID, CompanyName,...) Category(CategoryID, CategoryName,...) Customers(CustomerID, CompanyName,...) Employees(EmployeeID, LastName, FirstName,...) Orders(OrderID, CustomerID, EmployeeID, Date,...) OrderDetails(OrderID, ProductID, Quantity,..)

14 Neo4j vs. relationale Datenbank Beispiel von Graphendatenbank: Employee Product Category Order Supplier Customer

15 Neo4j vs. relationale Datenbank

16 Cypher vs. SQL Finde alle Produkte: SQL: SELECT p.* FROM Products p Cypher: MATCH (p:product) RETURN p Gebe die Namen und Preise aller Produkte sortiert aus: SQL: SELECT p.productname, p.price FROM Products p ORDER BY Price DESC Cypher: MATCH (p:product) RETURN p.productname, p.price ORDER BY price DESC Finde das Produkt Schokolade SQL: SELECT * FROM Products WHERE ProductName = Schokolade Cypher: MATCH (p:product) WHERE p.productname = Schokolade RETURN p oder MATCH (p:product {productname: Schokolade }) RETURN p

17 Cypher vs. SQL Finde die Kunde, die Schokolade gekauft haben SQL: SELECT C.companyName FROM Customers INNER JOIN Orders O ON C.customerID=O.customer.ID INNER JOIN OrderDetails OD ON O.orderId = OD.orderId INNER JOIN Products P ON OD.productId = P. productid WHERE P.productName = Schokolade Cypher: MATCH (p:product {productname:"schokolade"})<-[: ORDERS]- (:Order)<-[:PURCHASED]-(c:Customer) RETURN c.companyname;

18 Cypher vs. SQL Finde Produkte deren Name mit C anfängt und deren Preis > 100 ist SQL: SELECT p.productname, p.unitprice FROM products P WHERE p.productname LIKE C% AND p.unitprice > 100 Cypher: MATCH (p:product) WHERE p.productname STARTS WITH C AND p.unitprice > 100 RETURN p.productname, p.unitprice oder mit regulären Ausdrücke: p.productname =~ C.*

19 Cypher vs. SQL Outer Joins in Cypher -> OPTIONAL MATCH SQL: SELECT p.productname FROM customers C LEFT OUTER JOIN orders O ON C.CustomerId = O.CustomerId LEFT OUTER JOIN order_details OD ON O.OrderId = OD.OrderId LEFT OUTER JOIN products P ON OD.ProductId = P.ProductId GROUP BY p.productname Cypher: MATCH (C:Customer) OPTIONAL MATCH (P:Product) <- [PU:PRODUCT] (:Order) <- [:PURCHASED] (C) RETURN p.productname

20 Cypher vs. SQL Indexe in Neo4J: CREATE INDEX ON :Product(productName); Gruppierung in Neo4j ist implizit wenn man Aggregationsfunktionen benutzt: SQL: SELECT e.employeeid, count(*) as cnt FROM Employee e INNER JOIN Order o ON o.employeeid=e.employeeid GROUP BY e.employeeid Cypher: MATCH (:Order) <-[:SOLD] (e:employee) RETURN e. EmployeeId, count(*) AS cnt

21 Cypher vs. SQL Wenn man alle Angestellten aus einer Region sehen will: In Cypher gibt es collect eine Aggregationfunktion die eine Collection von Werte erstellt (list,array) SQL: SELECT e.lastname, t.description FROM Employee e INNER JOIN EmployeeTerritory et ON... INNER JOIN Territory t ON... Cypher: man kann das Ergebnis in derselben Form ausgeben oder: MATCH (t:territory) <- [:IN_TERRITORY] (e:employee) RETURN t.description, collect(e.lastname)

22 Cypher vs. SQL Füge einen neuen Produkt ein SQL: INSERT INTO Product (ProductName) VALUES ( Laptop ) Cypher: CREATE (p:product {productname: Laptop }) Dieselbe Methode kann benutzt werden auch um neue Properties zu einem Knoten einzufügen (ohne ALTER TABLE wie in SQL wenn man eine neue Spalte einfügen muss)

23 Schlussfolgerungen Willst du das durchschnittliche Einkommen berechnen? Frage eine relationale Datenbank ab. Brauchst du einen Onlineshop? Benutze eine Key-Value-Datenbank. Willst du strukturierte Informationen über ein Produkt speichern? Benutze eine Dokumentbasierte Datenbank. Willst du beschreiben wie ein Benutzer aus Punkt A zu Punkt B gekommen ist? Benutze eine Graphdatenbanken. Hauptidee: Wenn wir das Datenbankmodell auswählen, sollten wir sowohl das Ziel unserer Applikation, als auch die Struktur der Daten, die wir verwalten wollen, berücksichtigen!