jug 2016-01-18 public · document database schemafrei horizontal skalierbar ausfallsicher mobil +...

Couchbase

Thomas MatznerBerater für Systemanalyse

www.tamatzner.de

Java User Group München

18. 1. 2016

Überblick

• Warum Couchbase bei der Einkaufszettel-App?

• Eigenschaften von Couchbase

• Entwicklung mit Couchbase auf Server und • Entwicklung mit Couchbase auf Server und Android

• Designüberlegungen

Die Einkaufszettel-App

http://shopping-list.eu

Der synchronisierte Einkaufszettel

Eigenschaften von Couchbase

Key-valuestore

Documentdatabase

schemafrei

horizontal skalierbar

ausfallsicher

mobil + Server

div. Synchronisa

tionen

Couchbase: Node und Bucket

Node

Bucket A

Bucket B

Node

Client

Teilmenge der URLs verbindet

mit allen Bucket-Replikaten

Bucket BBucket A

Bucket CNode

Bucket A

Bucket D

Couchbase vs. relationale DB: Statik

relationale DB Couchbase Produkt Couchbase Anwendung

Datenbank Bucket (Empfehlung)

Tabelle alle Dokumente mit demselben Wert für den JSON-Namen (z.B.) type

Spalte JSON-NameSpalte JSON-Name

Datenwert beliebig; jedoch für viele Features JSON nötig

Datensatz Document

Primärschlüssel Key (wird nicht von Couchbase generiert)

Generierung, z.B.• lfd. Nr. je type• UUID

Fremdschlüssel Fremdschlüssel

Rechte je Benutzer bis auf Feldebene

je Bucket: ein schreibender, ein lesender Benutzer

alle sonstigen Rechte

Couchbase: Client-Zugriff

RESTAPI

Java .NET C Node.js PHP Python Ruby

Couchbase Server

Couchbase vs. relationale DB: Operationen

relationale DB Couchbase Produkt Couchbase Anwendung

CRUD-Operationen CRUD-Operationen• Key ist nicht veränderbar• Update wirkt stets auf gesamtes Dokument

Generieren von Keys

Zugriff über ViewZugriff über Fremdschlüssel oder sonstige Eigenschaften

View

SQL-Abfragen N1QL

Transaktionen (soweit mehrere Objekte in einem Dokument enthalten, entbehrlich)

selbst zu realisieren

Couchbase für Android

Couchbase Server Couchbase Android

Bucket Database

Dokumentenstruktur und -inhalt identisch

View• Logik in JavaScript geschrieben• Zugriff über Konsole, REST oder API

View• Logik in Java geschrieben• Zugriff nur über API• Zugriff über Konsole, REST oder API • Zugriff nur über API

CRUD-Operationen auch, aber mit leicht unterschiedlicher Syntax und Semantik

N1QL fehlt

Verbinden mit einem Bucket

Beispiel-Dokumente

CRUD

Definition einer View

Filter

Hierarch. Index

Wert (Dokumenten-Key kommt immer)

Views: Features

• Definition via JavaScript, prinzipiell beliebige Logik

• Abfrage– Wertebereiche

– Sortierung

– Paginierung– Paginierung

• Reduce– count, sum, min, max, Summe der Quadrate

– selbstdefinierbar

• Emit: (Teile der) Dokumenteninhalte im Index speicherbar

Zugriff über diese View

Android-Synchronisation via Channels

Client jim Client jack Client god

doc1jimdoc3public

doc2jackdoc3

publicdoc5[jim, jack]

doc5[jim, jack]

doc1jim

doc2jack

doc3public

doc4chris

doc5[jim, jack]

Server

doc1jim

doc2jack

doc3public

doc4chris

doc5[jim, jack]

jack] jack]

Channels:jim,public

Channels:jack,public

Channels:all

Android-Synchronisation: config

lokale Administration

Bucket für Sync: noli me tangere!

Android-Synchronisation aktivieren

Designüberlegungen: Schemafreiheit

• Schemadefinition technisch unnötig• Aber sinnvolle Verarbeitung setzt bekannte

Datenstrukturen voraus• Also Schemadefinition logisch nötig• Man kann sich auf nichts verlassen:

– Vorhandensein des type-Attributs– Vorhandensein des type-Attributs– Vorhandensein sonstiger Attribute– zulässige Werte je Attribut– viele Admin-Operationen auf der Konsole

• Also in Summe eher mehr Aufwand:– überall defensiv programmieren– Admin-Funktionen selber schreiben, z.B. Einfügen und

Initialisieren von Attributen

Designüberlegungen: Keys

• Couchbase

– vergibt keine Keys,

– bietet counter mit atomarer Inkrementierung an

• Möglichkeit: selbst erzeugte Zahlenfolgen• Möglichkeit: selbst erzeugte Zahlenfolgen

– über alle Dokumenttypen hinweg

– oder je Dokumenttyp (Key: doctype-currNr)

• Bei synchronisierten Geräten Eindeutigkeit kaum garantierbar � UUID

Designüberlegungen: emit bei Views

• Empfehlung im Lehrbuch: auf keinen Fall ganzes Objekt zurückgeben

• Erfahrungsberichte zeigen, dass dies wohl nicht allgemein gilt

• Jeder emit-Wert führt zu• Jeder emit-Wert führt zu– zusätzlicher Speicherung des Werts– zusätzlichem Update, wenn Wert sich ändert

• Also umso eher einsetzen, als– Platzbedarf des Werts gering– seltene Updates auf dem Attribut– Attribut wird häufig benötigt, wenn über die View

zugegriffen wird

Mechanismen für Synchronisation zwischen Mobil- und Server-App

Alternativ empfohlene Mechanismen