View
6
Download
0
Category
Preview:
Citation preview
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
Recommended