Sections: Database as a Service (!DBaaS) by the Example of !PostgreSQL | Einleitung | Zeitplan | Ziele und Aufbau | Software-Tools | Benchmark | Pflichtliteratur | Lieferdokumente und Leistungsbewertung | Tipps zum Seminar | Notizen |

Seminar Datenbanksysteme (Seminar Database Systems) in FS 2019 für Master (MSE) in ICT an der Master Research Unit Software & Systems, HSR Rapperswil und HTW Chur (FHO). Offizielle Bezeichnung des Moduls "Seminar Datenbanksysteme 1 (HSR MSE ICT SWSY)".

Quicklinks: SeminarDatenbanksysteme, SeminarDatenbanksystemeHS1819

Database as a Service (DBaaS) by the Example of PostgreSQL ^

Einleitung ^

Hintergrund: Web Services verwenden Standard-Webdienst-Protokolle (HTTP), um einen einfachen Zugriff auf entfernte Ressourcen zu ermöglichen. Dieser Ansatz ist in heterogenen, verteilten und lose miteinander verbundenen Umgebungen von grossem Vorteil. Wie andere Web Services werden auch Datenbanken immer mehr in die "Cloud" verschoben. Dies kommt Open Source-Datenbanken zugute, denn Sie haben ein günstiges "Total Cost of Ownership" und können einfach erweitert werden. Mit "Database-as-a-Service" (DBaaS) können (Web-)Client-Anwendungen Daten aus der Datenbank abfragen und verändern (CRUD). Clients können so auch Datenbank-Sichten (Views), Funktionen (User Defined Functions, Stored Procedures) aufrufen. Mehr zum Begriff DBaaS für Cloud-Datenbankdienste als eine eigene Kategorie siehe Seibold & Kemper (2012).

Die einfache Kommunikation übers Web mit dem JSON-Format (v.a. als Response) war einer der Gründe zum NoSQL-Hype. Ein weiterer Grund des Hypes war die einfache horizontale Skalierung (Sharding). Der Dokumenten-Datentyp JSON wird inzwischen von vielen NewSQL-Datenbanken unterstützt. Und auch die horizontale Skalierung wurde von diesen verbessert. Zudem nehmen Cloud-Anbieter die Aufgabe der Datenbank-Skalierung den Nutzern ab.

Unter NewSQL-Datenbanken verstehen wir relationale Datenbankmanagementsysteme (RDBMS) mit der bewährten SQL-Anfragesprache, die ACID-Eigenschaften anbieten "trotz" verteilten Workloads. Diese RDBMS festigten ihren Platz als Persistenzschicht (OLTP) und auch Werkzeuge für Data Analytics (OLAP, write-only). PostgreSQL beispielsweise ist so ein RDBMS, bei dem nochmals erstaunliche Erweiterungsmöglichkeiten dazukommen, wie der Geometrie-Datentyp (PostGIS-Erweiterung), Dictionaries/Key-Values (hstore-Erweiterung), User Defined Functions/Stored Procedures sowie erweiterbare Indexe (GIST mit C-Modulen).

Was für ein DBaaS mit RDBS und NewSQL-Datenbanken oft noch fehlt, ist die "verbindende Web-Software" und eine gutes "Tooling".

Problemstellung: Dieses Seminar soll die Möglichkeiten und das Potential von DBaaS aufzeigen. Der Schwerpunkt liegt bei Ad-Hoc-Abfragen in einer verteilten "lose gekoppelten" Umgebung. In diesem Seminar werden ausgewählte Implementationen von DBaaS mit PostgreSQL inklusive SQL-as-an-API versus anderer Query-Sprachen untersucht. Ein Benchmark-Programm dient als Client. Die fünf wichtigsten zu untersuchenden Aspekte sind:

  1. Web Services-Architektur (REST (RESTful) vs. GraphQL).
  2. Konzeption der Anfragesprache (SQL-as-API vs. GraphQL-Query vs. weitere Query-Sprachen?).
  3. Tooling, d.h. eine Auswahl von SW-Libraries, die alle auf dieselbe PostgreSQL-Instanz zugreifen.
  4. Erweiterbarkeit der gewählten Tools (Server, IDE).
  5. Performance der Tools sowie Erfahrungen damit.

Folgendes sind nur Themen am Rande dieses Seminar oder ganz Out-of-Scope:

Konkrete Tätigkeiten in "Hands-on"-Phase (vgl. auch "Vorgehens-Phasen I-IV" unten):

Zeitplan ^

  1. Anfang Semester: Kickoff mit Erläuterungen und Zuordnung der Themen => Di. 19.02.2019.
  2. Ergänzungen zum Benchmark => tba. (durch Betreuer und/oder Mitarbeiter).
  3. Vor der Zwischenpräsentation: eine, zwei Buddy-Sitzungen zum Stand (nicht zwingend face-to-face).
  4. Mitte Semester: Zwischenpräsentation alle. => Do. 4. April 2019, 10-12 Uhr, Raum tba. (Treffpunkt 8.261)
  5. Ggf. einzelne Zwischenbesprechungen nach Absprache des Studierenden mit Betreuer.
  6. Vor Unterrichts-Ende: Buddy-Sitzung zum Seminararbeit-Draft ev. 'face-to-face'.
  7. Abgabe Seminararbeit Draft an Betreuer, spätestens zwei Wochen vor Schlusspräsentation. (Antwort Betreuer vor Mail Seminararbeit Draft an alle).
  8. Mail Seminararbeit Draft an alle ca. eine Woche vor Schlusspräsentation. => d.h. Mo. 27. Mai 2019
  9. Nach Semesterende: Schlusspräsentation/Vortrag => Mo 3. Juni 2019, 15-17 Uhr, Raum 8.025 (Sitzungsraum)
  10. Feedback der Verbesserungen an Seminararbeit und ggf. an Benchmark. Mail von Betreuer an Studenten => Mitte Juni(?)
  11. Schlussabgabe Finale Seminararbeit inkl. alle Lieferdokumente an Betreuer => gem. Absprache, jedoch vor Notenabgabe, d.h. Ende Juni(?)
  12. (Notenabgabe (Betreuer): vor Beginn des nächsten Semester => wie üblich, gem. Vorgaben HSR, bzw. HTW)
  13. Nach Notenabgabe: Upload der Seminararbeit auf Wiki (hier) durch Betreuer.

Ziele und Aufbau ^

Ziele des Seminars:

Aufbau des Seminars in Vorgehens-Phasen:

Software-Tools ^

GraphQL Libraries (Student 1 und Student 2 wählen je eine Library):

SQL API Libraries (Student 1 und Student 2 wählen PostgREST plus je eine Library):

Benchmark ^

Allgemeines:

Benchmark A "DVD Rental Database (Sakila)": Datenbank über einen DVD-Verleih (für diejenigen, die noch wissen, was das ist) mit ein paar netten Eigenschaften: Mittlere Grösse (zwei der 15 Tabellen haben >16'000 Einträgen), normalisiert, einheitliche Spalten-Benennung, Many-to-many-Beziehungen, mehrere Join-Pfade zwischen Entitäten (z.B. film-inventory-rental-payment und film-inventory-store-customer-payment). Quelle: jOOQ-examples/Sakila.

Benchbark B. "Extended OpenStreetMap Schweiz Database (eosm_ch)". Vereinfachte OpenStreetMap-Daten (OSM) mit Geometrien und Hstore ergänzt mit OeV-Haltestellen. Eine Variante von (EOSMDBone als "Snapshot" mit drei Tabellen osm_point, osm_line, osm_polygon (enthaltend je >1.5 Mio. Objekte wovon total >500'000 benannt sind), die folgende gemeinsamen Attribute haben: geom (point, linestring oder polygon), osm_id(bigint), name(text), tags(hstore) ergänzt mit OeV-Haltestellen. Hintergrund OeV-Haltestellen: , DiDok-Homepage auf opentransportdata, Dokumentation der Attribute (Lizenz mit Sammelwerk-Klausel passt zu ODbL, ca. 32'000 Records verknüpft über "uic_ref"). DIDOK hat 22 Attribute ohne Geometrie, OSM hat Attribute geom(point), osm_id, name, uic_ref, sowie shelter, wheelchair, bench und covered.

Pflichtliteratur ^

SQL-as-API:

GraphQL:

Vorteile von GraphQL (und SQL) gegenüber (purem) REST:

Probleme von GraphQL (und SQL) gegenüber (purem) REST mit Lösungsansätzen:

Lieferdokumente und Leistungsbewertung ^

Lieferdokumente / Deliveries:

Technical Report (bitte Original als LibreOffice/OpenOffice oder MS Word oder LaTeX oder Markdown - nebst PDF):

  1. Verständliche Einführung und Aufbereitung des Themas (ca. 8-12 Seiten).
  2. Gesamt-Dokumentation inkl. Einführung und Visualisierung/Diagramme (ca. 20 Seiten)
  3. Usage auf technischer Ebene (kein "Marketing-Talk"): Vorteile wie auch Nachteile/Einschränkungen
  4. Dokumentation und Zeitmessungen der Queries
  5. Lesson Learned und Conclusion
  6. Anhang: Hinweise zur Installation, um die SW mit den Queries selber nachvollziehen zu können.

Leistungsbewertung: siehe SeminarDatenbanksystemeEvaluation, inkl. Report-Layout-Vorgaben und Referenz/Bibliografie-Stil (bevorzugt APA).

Tipps zum Seminar ^

Allgemein:

PostgreSQL:

Hasura:

Postgraphile:

    SELECT 
      ST_AsText(ST_Transform(way,4326)) AS geom, -- WGS84/lat/lon
      name, 
      osm_id, 
      (tags->'uic_ref') AS uic_ref 
    FROM osm_poi           -- View aus osm_point UNION osm_polygon
    WHERE (tags->'uic_ref') IS NOT NULL -- Haltestelle
    AND ST_Within(                     
      way, 
      (SELECT way FROM osm_polygon WHERE osm_id=-51701)
    )  -- streng innerhalb Polygongrenze der CH

Notizen ^

Nicht in die Shortlist aufgenommen:

Verschiedenes: