Direkt zum Inhalt | Direkt zur Navigation

Focus on your applications!

Benutzerspezifische Werkzeuge

Sie sind hier: Startseite / Blog / Open Source

Open Source

erstellt von vsc zuletzt verändert: 25.08.2020 17:29

Auswahl der richtigen NoSQL-Datenbank

erstellt von Veit Schiele zuletzt verändert: 31.08.2020 18:25
Mitwirkende: Andreas Jung
Relationale Datenbanken dominierten lange die Softwareindustrie und sind mit Mechanismen wie Redundanz, Transaktionskontrolle und Standardschnittstellen sehr ausgereift. Sie konnten jedoch zunächst nur mäßig auf höhere Anforderungen an Skalierbarkeit und Performance reagieren. So kam ab Anfang 2010 verstärkt der Begriff NoSQL auf um neuartige Datenbanken zu beschreiben, die diesen Anforderungen besser genügten.
Auswahl der richtigen NoSQL-Datenbank

NoSQL-Datenbanken

NoSQL-Datenbanken sollten die folgenden Probleme lösen:

  • Überbrücken der internen Datenstruktur der Anwendung und der relationalen Datenstruktur der Datenbank
  • Abkehr von der Integration verschiedenster Datenstrukturen in ein einheitliches Datenmodell
  • Die wachsende Anzahl an Daten erforderte zunehmend Cluster zur Datenspeicherung

Aggregierte Datenmodelle

Die relationale Datenbankmodellierung unterscheidet sich erheblich von den Arten von Datenstrukturen, die Anwendungsentwickler verwenden. Die Verwendung der von Entwickler*innen modellierten Datenstrukturen zur Lösung verschiedener Problemdomänen hat zu einer Abkehr von der relationalen Modellierung hin zu aggregierten Modellen geführt. Der größte Teil davon wird von Domain Driven Design angetrieben. Ein Aggregat ist eine Sammlung von Daten, mit denen wir als Einheit interagieren. Diese Aggregate bilden die Grenzen für ACID-Operationen, wobei die Schlüsselwerte, Dokumente und Column Family als Formen einer aggregatorientierten Datenbank angesehen werden können.

Aggregate erleichtern der Datenbank die Verwaltung der Datenspeicherung auf einem Cluster, da sich die Dateneinheit jetzt auf jedem Computer befinden kann. Aggregatorientierte Datenbanken funktionieren am besten, wenn die meisten Dateninteraktionen mit demselben Aggregat durchgeführt werden, z.B. wenn ein Profil mit allen Details abgerufen werden muss. Es ist besser, das Profil als Aggregationsobjekt zu speichern, und diese Aggregate zu verwenden, um Profildetails abzurufen.

Distributionsmodelle

Aggregatorientierte Datenbanken erleichtern die Verteilung von Daten, da der Verteilungsmechanismus nur das Aggregat verschieben muss und sich nicht um verwandte Daten kümmern muss, da alle verwandten Daten im Aggregat selbst enthalten sind. Dabei gibt es im Wesentlichen zwei Arten der Datenverteilung:

Sharding
Sharding verteilt unterschiedliche Daten auf mehrere Server, sodass jeder Server als einzige Quelle für eine Teilmenge von Daten fungiert.
Replikation

Replikation kopiert Daten über mehrere Server hinweg, sodass jedes Datum an mehreren Stellen gefunden werden kann. Die Replikation erfolgt in zwei Formen:

Die Master-Slave-Replikation macht einen Knoten zur autorisierenden Kopie, die Schreibvorgänge verarbeitet, während Slaves mit dem Master synchronisiert werden und möglicherweise Lesevorgänge verarbeiten.

Die Peer-to-Peer-Replikation ermöglicht Schreibvorgänge auf jeden Knoten. Die Knoten koordinieren sich um ihre Kopien der Daten zu synchronisieren.

Die Master-Slave-Replikation verringert zwar die Wahrscheinlichkeit von Aktualisierungskonflikten, aber die Peer-to-Peer-Replikation vermeidet das Schreiben allerVorgänge auf einen einzelnen Server, wodurch ein einzelner Fehlerpunkt vermieden wird. Ein System kann eine oder beide Techniken verwenden.

CAP-Theorem

In verteilten Systemen sind die folgenden drei Aspekte wichtig:

  • Konsistenz (engl.: Consistency)
  • Verfügbarkeit (engl.: Availability)
  • Ausfalltoleranz (engl.: Partition tolerance)

Eric Brewer hat das CAP-Theorem aufgestellt, das besagt, dass wir in jedem verteilten System nur zwei der drei Optionen auswählen können. Viele NoSQL-Datenbanken versuchen, Optionen bereitzustellen, bei denen ein Setup gewählt werden kann, die Datenbank entsprechend dein Anforderungen aufzusetzen. Wenn Ihr beispielsweise Riak als verteilte Schlüssel-Werte-Datenbank betrachtet, gibt es im Wesentlichen die drei Variablen

r
Anzahl der Knoten, die auf eine Leseanforderung antworten sollen, bevor sie als erfolgreich angesehen wird
w
Anzahl der Knoten, die auf eine Schreibanforderung antworten sollen, bevor sie als erfolgreich angesehen wird
n
Anzahl der Knoten, auf denen die Daten repliziert werden, auch Replikationsfaktor genannt

In einem Riak-Cluster mit 5 Knoten können wir die Werte für r, w und n so anpassen, dass das System sehr konsistent ist indem wir r = 5 und w = 5 setzen. Damit haben wir jedoch den Cluster für Netzwerkpartitionen anfällig gemacht, da kein Schreibvorgang möglich ist wenn nur ein Knoten nicht antwortet. Wir können denselben Cluster für Schreib- oder Lesevorgänge hoch verfügbar machen, indem wir r = 1 und w = 1 setzen. Jetzt kann jedoch die Konsistenz beeinträchtigt werden, da einige Knoten möglicherweise nicht über die neueste Kopie der Daten verfügen. Das CAP-Theorem besagt, dass Ihr, wenn Ihr eine Netzwerkpartition erhaltet, die Verfügbarkeit von Daten gegen die Konsistenz von Daten abwägen müsst. Auch die Haltbarkeit kann gegen die Latenz abgewogen werden, insbesondere wenn Ihr Fehler mit replizierten Daten überstehen möchtet.

Häufig benötigtet ihr bei relationalen Datenbanken kaum ein Verständnis für diese Anforderungen; nun werden diese wieder wichtig. So dürftet Ihr gewöhnt gewesen sein, in relationalen Datenbanken Transaktionen zu verwenden. I NoSQL-Datenbanken stehen Euch diese jedoch nicht mehr zur Verfügung und Ihr müsst selbst überlegen, wie diese implementiert werden sollen. Muss das Schreiben transaktionssicher sein? Oder ist es auch mal akzeptabel, dass mal Daten verlorengehen? Schließlich kann manchmal auch ein externer Transaktionsmanager wie ZooKeeper hilfreich sein.

Verschiedene Arten von NoSQL-Datenbanken

NoSQL-Datenbanken können grob in vier Typen eingeteilt werden:

Schlüssel-Werte-Datenbanken

Schlüssel-Werte-Datenbanken sind aus API-Sicht die einfachsten NoSQL-Datenspeicher. Der Client kann entweder den Wert für den Schlüssel abrufen, einen Wert für einen Schlüssel eingeben oder einen Schlüssel aus dem Datenspeicher löschen. Der Wert ist ein Blob, den der Datenspeicher nur speichert, ohne sich darum zu kümmern oder zu wissen, was sich darin befindet. Es liegt ausschließlich in der Verantwortung der Anwendung, zu verstehen, was gespeichert wurde. Da Schlüssel-Werte-Datenbanken immer den Primärschlüsselzugriff verwenden, weisen sie im Allgemeinen eine hohe Leistung auf und können leicht skaliert werden.

Einige der beliebtesten Schlüsselwertdatenbanken sind

Riak KV
Home | GitHub | Docs
Redis
Home | GitHub | Docs
Memcached
Home | GitHub | Docs
Berkeley DB
Home | GitHub | Docs
Upscaledb
Home | GitHub | C API Docs

Ihr müsst sie sorgfältig auswählen da es große Unterschiede zwischen Ihnen gibt. Während Riak z.B. die Daten persistent speichert ist dies bei Memcached üblicherweise nicht der Fall.

Dokumentendatenbanken

Diese Datenbanken speichern und rufen Dokumente ab, bei denen es sich um XML, JSON, BSON usw. handeln kann. Diese Dokumente sind hierarchische Baumdatenstrukturen, die aus Karten, Sammlungen und Skalarwerten bestehen können. Dokumentendatenbanken bieten umfangreiche Abfragesprachen und Konstrukte wie Datenbanken, Indizes usw., die einen einfacheren Übergang von relationalen Datenbanken ermöglichen.

Einige der beliebtesten Dokumentendatenbanken sind

MongoDB
Home | GitHub | Docs
CouchDB
Home | GitHub | Docs
RavenDB
Home | GitHub | Docs
Elasticsearch
Home | GitHub | Docs
eXist
Home | GitHub | Docs

Column Family Stores

Diese Datenbanken speichern Daten in Column Families als Zeilen, die einem Zeilenschlüssel zugeordnet sind. Sie sind hervorragend geeignet für Gruppen verwandter Daten, auf die häufig zusammen zugegriffen wird. Dies können beispielsweise alle Profilinformationen einer Person sein, nicht jedoch deren Aktivitäten.

Zwar kann jede Column Family mit der Zeile in einer RDBMS-Tabelle verglichen werden, in dem der Schlüssel die Zeile identifiziert und die Zeile aus mehreren Spalten besteht; aber in Column Family Stores müssen die verschiedene Zeilen nicht dieselben Spalten haben.

Einige der beliebtesten Column Family Stores sind

Cassandra
Home | GitHub | Docs
HBase
Home | GitHub | Docs
Hypertable
Home | GitHub | Docs

Cassandra kann als schnell und einfach skalierbar beschrieben werden, da Schreibvorgänge über den Cluster verteilt sind. Der Cluster verfügt nicht über einen Masterknoten, sodass Lese- und Schreibvorgänge von jedem Knoten im Cluster ausgeführt werden können.

Graphdatenbank

In Graphdatenbanken könnt Ihr Entitäten mit bestimmten Eigenschaften und Beziehungen zwischen diesen Entitäten speichern. Entitäten werden auch als Knoten bezeichnet. Stellt Euch einen Knoten als Instanz eines Objekts in einer Anwendung vor; Beziehungen können dann als Kanten bezeichnet werden, die ebenfalls Eigenschaften haben können und gerichtet sind.

Graph-Modelle
Labeled-Property-Graph
In einem Labeled-Property-Graph können sowohl Knoten als auch Kanten Eigenschaften (engl.: Properties) besitzen.
Resource Description Framework (RDF)
Im RDF werden Graphen mit Hilfe von Triplen repräsentiert. Ein Triple besteht aus drei Elementen in der Form Knoten-Kante-Knoten Subjekt --Prädikat-> Objekt, die als Ressourcen in Form einer weltweit eindeutigen URI oder als anonyme Ressource definiert werden. Um innerhalb einer Datenbank verschiedene Graphen verwalten zu können, werden diese als Quads gespeichert wobei ein Quad jedes Triple um eine Referenz auf den zugehörigen Graphen erweitert. Aufbauend auf RDF wurde mit RDF-Schema ein Vokabular entwickelt, um schwache Ontologien zu formalisieren und darüber hinaus mit der Web Ontology Language auch vollständig entscheidbare Ontologien beschreiben.
Algorithmen

Wichtige Algorithmen zur Abfrage von Knoten und Kanten sind:

Breitensuche, Tiefensuche
Breitensuche (engl.: breadth-first search, BFS) ist ein Verfahren zum Durchlaufen der Knoten eines Graphen verwendet. Im Gegensatz zur Tiefensuche (engl.: depth-first search, DFS) werden zunächst alle Knoten beschritten, die vom Ausgangsknoten direkt erreichbar sind. Erst danach werden Folgeknoten beschritten.
Kürzester Pfad
Pfad zwischen zwei unterschiedlichen Knoten eines Graphen, welcher minimale Länge bezüglich einer Kantengewichtsfunktion hat.
Eigenvektor
In der linearen Algebra ein vom Nullvektor verschiedener Vektor, dessen Richtung durch die Abbildung nicht verändert wird. Ein Eigenvektor wird also nur skaliert und der Skalierungsfaktor wird als Eigenwert der Abbildung bezeichnet.
Abfragesprachen
Blueprints
eine Java-API für Eigenschaftsgraphen, die zusammen mit verschiedenen Graphdatenbanken verwendet werden kann.
Cypher
eine Abfragesprache entwickelt von Neo4j.
GraphQL
eine SQL-artige Abfragesprache
Gremlin
eine Open-Source-Graphen-Programmiersprache, die mit verschiedenen Graphdatenbanken (Neo4j, OrientDB) genutzt werden kann.
SPARQL
vom W3C spezifizierte Abfragesprache für RDF-Datenmodelle.
Abgrenzung zu relationalen Datenbanken

Wenn wir Graphen in relationalen Datenbanken speichern wollen, geschieht dies meist nur für spezifische Bedingungen, z.B. für die Beziehungen zwischen Menschen. Das Hinzufügen weiterer Beziehungsarten ist dann normalerweise mit vielen Schemaänderungen verbunden.

In Graphdatenbanken ist das Durchlaufen der Verknüpfungen oder Beziehungen sehr schnell, da die Beziehung zwischen Knoten nicht erst zur Abfragezeit berechnet werden muss.

Einige der beliebtesten Graphdatenbanken sind

Neo4j
Home | GitHub | Docs
InfiniteGraph
Home

Auswahl der NoSQL-Datenbank

Allen NoSQL-Datenbanken ist gemein, dass sie kein bestimmtes Schema erzwingen. Im Gegensatz zu relationalen Datenbanken mit starkem Schema müssen Schemaänderungen nicht zusammen mit dem Quellcode, der auf diese Änderungen zugreift, gespeichert werden. Schemalose Datenbanken können Änderungen im implizierten Schema tolerieren, sodass sie keine Downtime zur Migration benötigen; sie sind daher vor allem bei Systemen, die 24/7 zur Verfügung stehen sollen, sehr beliebt.

Wie wählen wir nun aber unter so vielen NoSQL-Datenbanken die richtige aus? Im Folgenden können wir Ihnen nur einige allgemeine Kriterien nennen:

Schlüssel-Werte-Datenbanken
sind im Allgemeinen nützlich zum Speichern von Sessions, Benutzerprofilen und Einstellungen. Wenn jedoch Beziehungen zwischen den gespeicherten Daten abgefragt oder mehrere Schlüssel gleichzeitig bearbeitet werden sollen, würden wir Schlüsselwertdatenbanken vermeiden.
Dokumentendatenbanken
sind im Allgemeinen nützlich für Content-Management-Systeme und E-Commerce-Anwendungen. Wir würden die Verwendung von Dokumentdatenbanken jedoch vermeiden, wenn komplexe Transaktionen benötigt odermehrere Vorgänge oder Abfragen für unterschiedliche Aggregatstrukturen gestellt werden sollen.
Column Family Stores
sind im Allgemeinen nützlich für Content-Management-Systeme, das Auslaufen der Nutzung und für hohe Schreibvolumen wie z.B. bei der Protokollaggregation. Wir würden die Verwendung von Datenbanken für Column Family Stores vermeiden, die sich in der frühen Entwicklung befinden und deren Abfragemuster sich noch ändern können.
Graphdatenbanken
eignen sich sehr gut für Problembereiche, in denen wir Daten wie soziale Netzwerke, Geodaten, Routing-Informationen sowie Empfehlungssystem miteinander verbunden werden sollen.

Fazit

Der Aufstieg der NoSQL-Datenbanken führte nicht zum Niedergang der relationalen Datenbanken. Sie können gut nebeneinander existieren. Häufig werden unterschiedliche Datenspeichertechnologien verwendet um die Daten passend zu Ihrer Struktur und erforderlichen Abfrage zu speichern.

Microsoft-Alternativen – Migration zu OpenSource-Technologien

erstellt von Veit Schiele zuletzt verändert: 08.09.2020 08:57
Microsoft-Alternativen – Migration zu OpenSource-Technologien

FSFE: I love free software

Für eine große deutsche Forschungsgesellschaft entwickeln wir eine Migrationsstrategie von Microsoft 365 zu OpenSource-Technologien. Dabei geht es einerseits darum, die digitale Sourveränität zurückzuerhalten und andererseits erhöhte Sicherheitsanforderungen zu erfüllen. Dies soll nun unter Verwendung freier und quelloffener Software (FLOSS) erreicht werden. Insgesamt ähnelt das Projekt dem Microsoft Alternatives-Projekt (MAlt) des CERN und dem Projekt Phoenix von Dataport.

Die Grundsätze des Projekts sind:

  • Allen Mitarbeiter*innen soll der gleiche Service geboten werden
  • Vendor lock-ins sollen vermieden werden um das Risiko der Abhängigkeit zu verringern
  • Die Daten sollen weitestgehend im Besitz der Forschungsgesellschaft bleiben

Pläne für 2020

Für 2020 ist geplant, für viele Services und Dienstleistungen alternative Lösungen zu evaluieren sowie Prototypen und Pilotprojekte zu veröffentlichen.

Produktgruppe Service Product to evaluate Status
Identitäts- und Zugriffsmanagement LDAP OpenLDAP Produktion
Personal Information Management E-Mail Zimbra Evaluation
Kalender Zimbra Evaluation
Kontakte Zimbra Evaluation
Kollaboration Dateiaustausch NextCloud Produktion
Office-Integration NextCloud Evaluation
Direktnachrichten/ Chat Mattermost Produktion
Videokonferenzen Jitsi Meet Produktion
Suche Suchmaschine Elasticsearch Evaluation
Frontend/ Visualisierung Kibana Evaluation
Authentifizierung/ Zugriffskontrolle Open Distro Security Evaluation
Nächste-Nachbarn Klassifikation Open Distro KNN Evaluation
Projektmanagement Aufgaben/Meilensteine GitLab Evaluation
Zeiterfassung gitlabtime Evaluation
Dokumentation GitLab Wiki Evaluation
Forschungssoftware [1], [2] Paketmanager Spack Produktion
IDE JupyterHub Produktion
Entwicklungsumgebungen Jupyter Kernels Produktion
Software-Versionierung Git Produktion
Datenversionierung DVC Produktion
Erhebung und Speicherung von Daten Intake Pilot
Geodaten PostGIS Produktion
Kartographische Daten OpenStreetMap Produktion
DevOps GitLab CI/CD Pipeline Pilot
Dokumentation Sphinx Produktion

Hosting-Strategie

Innerhalb der Forschungsgesellschaft gibt es im wesentlichen drei verschiedene Hosting-Varianten:

Gesellschaftsweite Infrastruktur
Infrastruktur, die institutsübergreifend von einem Großteil der Forschungsprojekte und Verwaltungen genutzt wird, soll von der zentralen IT der Forschungsgesellschaft bereitgestellt werden.
Institutsweite Infrastruktur
Infrastruktur, die für die speziellen Forschungsbereiche eines Instituts benötigt werden oder die IT-Unterstützung vor-Ort benötigen, sollen von der IT des jeweiligen Instituts bereitgestellt werden.
Betriebs- und Georedundanz
Diese werden im Wesentlichen durch Institutskooperationen oder durch Kooperationen einzelner Institute mit der IT der Forschungsgesellschaft hergestellt. Technologisch werden hierfür Floating IPs und das Virtual Router Redundancy Protocol (VRRP) verwendet wobei die Entscheidungen auf Basis von BGP-Announcements getroffen werden.

[1]

Für die Infrastruktur, auf der die Forschungssoftware entwickelt wird, gibt es ausführliche Dokumentationen, die unter der BSD-3-Clause-Lizenz veröffentlicht sind:

[2]Hier stellt das geplante einheitliche API eine deutliche Vereinfachung dar; siehe auch Announcing the Consortium for Python Data API Standards.

IT-Infrastruktur für Hackathons

erstellt von Veit Schiele zuletzt verändert: 25.08.2020 16:06

Was ist ein Hackathon?

Das Wort Hackathon setzt sich zusammen aus den beiden Worten Hack und Marathon. Es ist eine kollaborative IT-Veranstaltung mit dem Ziel, gemeinsam Prototypen zu spezifischen Themen oder Problemen herzustellen.

Über die thematische Ausrichtung eines Hackathons können Bezüge zu den Lebenswelten der Teilnehmer*innen hergestellt werden. Sie erfahren, wie Probleme gemeinsam mit technischen Mitteln gelöst werden können. Häufig wurden Hackathons jedoch auch veranstaltet um kreativ Lösungswege zu finden. Schließlich führen sie auch zu einer Vernetzung der Teilnehmer*innen, auch wenn diese aktuell nur online möglich ist.

Nach dem erfolgreichen Hackathon der Bundesregierung WirVsVirus u.a. zusammen mit Code for Germany und Prototype Fund haben auch andere für sich Hackathons als geeignetes Veranstaltungsformat gefunden, so beispielsweise auch das Hochschulforum Digitalisierung mit ihrem SemesterHack.

Für den Lüneburg Hackathon 2020 mit bis zu 500 Teilnehmer*innen konzipierten wir nicht nur die IT-Infrastruktur sondern auch die Event-Begleitung mit folgenden Phasen:

  1. Setup mit 24h
  2. 14-tägiger Vorlauf mit 9h
  3. 3-tägiger Event mit 36h
  4. 14-tägiger Nachlauf mit 5h

Im Wesentlichen sahen wir die drei große Herausforderungen:

  • in kurzer Zeit uns eng mit den Veranstalter*innen der Leuphana-Universität Lüneburg abzustimmen
  • eine einfache Integration der verwendeten IT-Komponenten:
  • Jitsi als hochverfügbaren Cluster-Service bereitzustellen, mit dem die 500 Teilnehmer*innen gleichzeitig kommunizieren können

Wie läuft ein Hackathon ab?

Der typische Ablauf eines Online-Hackathons kann dann z.B. so aussehen:

  1. Begrüßung der Teilnehmer*innen und Kennenlernen im Mattermost Chat
  2. Vorstellung des Formats und Agenda des Hackathons mit Jitsi-Videokonferenz und Screensharing
  3. Kurze Impulsvorträge zu den wichtigsten Tools, Daten und thematischen Schwerpunkten
  4. Brainstorming mit GitLab Kanban-Boards
  5. Gruppenbildung mit jeweils eigenen Kanban-Boards, Git-Repositories, Mattermost-Channels und ggf. Entwicklungsumgebungen auf Basis von Jupyter Notebooks.
  6. Präsentationen mit Jitsi-Videokonferenzen und ggf. Jupyter Notebooks im Präsentationsmodus

Welche Hackathons gibt es in Deutschland?

Jugend hackt
Ihr Motto ist Mit Code die Welt verbessern und soll einen verantwortungsbewussten Umgang mit Technik fördern um Lösungen für gesellschaftspolitische Fragen zu finden. Es ist ein nicht-gwinnorientiertes Programm der gemeinnützigen Vereine Open Knowledge Foundation Deutschland e.V. und mediale pfade.org.
Coding da Vinci
Seit 2014 vernetzt Coding da Vinci technikaffine und kulturbegeisterte Communities mit deutschen Kulturinstitutionen, um offene Kulturdaten zu erhalten.
Science Hack Day Berlin
Der Science Hack Day Berlin wird von Freiwilligen aus den Bereichen Wissenschaft, Design, IT, Ingenieurwesen und Kommunikation organisiert.
Wikimedia Hackathon
Die Wikimedia Hackathons werden veranstaltet um um die technologische Infrastruktur von Wikipedia und anderen Wikimedia-Projekten, insbesondere der ihnen zugrunde liegenden MediaWiki-Plattform zu verbessern.

Falls Ihr nun selbst einen Hackathon veranstalten möchtet, so kann Cusy auch Euch mit der passenden IT-Infrastruktur und Support unterstützen.

Lasst Euch beraten

Ich berate Euch gerne und erstelle ein passgenaues Angebot für IT-Infrastruktur und Support bei einem Hackathon.

Veit Schiele

Veit Schiele
Telefon: +49 30 22430082

Wir rufen Sie auch gerne an!

Jetzt anfragen