NoSQL mit PostgreSQL Swiss Postgres Conference Juni Hannu Krosing Harald Armin Massa

Transkript

1 NoSQL mit PostgreSQL Swiss Postgres Conference Juni 2015 Hannu Krosing Harald Armin Massa

2 Agenda Wer sind 2ndQuadrant, Hannu, Harald (2min) Begriffsbestimmung: NoSQL Warum NoSQL? Postrelationales PostgreSQL: Not Only SQL

3 2ndQuadrant Beiträge zu Core PostgreSQL (Beispiele) PITR Hot Standby Synchronous Replication CREATE EXTENSION BDR / UDR Ecosystem (Beispiele) pgbarman repmgr

4 Wer ist 2ndQuadrant? Zentrales Produkt: 24/7 Produktiv Support Wir finden in vereinbarter Zeit Lösungen für Bugs, die den PostgreSQL Betrieb stören. Gegen Geld. Platin Sponsor PostgreSQL Projekt Dienstleistungen rund um PostgreSQL Entwicklungen Consulting Training

5 Hannu DBA und Database Architect bei Skype Betreuung Wachstum 1 nach 100en von Servern Co-Author des Buches "PostgreSQL 9 Administration Cookbook" zusammen mit Simon Riggs. Code & Bugfixes & Designbeiträge PostgreSQL Spezialisiert auf Skalierung, Python um und in PostgreSQL

6 Harald PostgreSQL Nutzer seit 1996 Unternehmer, Python-Anwendungen mit PostgreSQL (+andere DB) Mitorganisator europäische PostgreSQL Konferenz Pilotanwender PostgreSQL unter Windows Seit ndQuadrant Partner, Geschäftsführender Gesellschafter 2ndQuadrant Deutschland GmbH

7 NoSQL - Begriffsbestimmung Initiiert als Not Only SQL = nicht nur SQL Speichern und Lesen von Daten in anderen Modellen als Tabellen / Relationen Eigentlich NoREL Aufbegehren gegen SQL

8 Warum nicht relational?

9 Herausforderungen Relationale DB 1 Struktur sehr weit weg von Relationen Verträge Webseiten gefühlter Overhead von SQL Parser / Executor kognitive Last weitere Sprache kognitive Last descriptive Sprache / Kontrollverlust Serialisierungs-Overhead Objekt Relation

10 Herausforderungen Relationale DB 2 Datenschema Transaktionales DML selten außerhalb Organisatorisches Hemmen von Änderungen Applikationskompatibilität? Schemaänderungen bei logischen Replikationen herausfordernd ALTER TABLE Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions. (Simon, 28. July 2010)

11 Herausforderungen Relationale DB 3 Anforderungen verteilte Datenbanken (WebScale) CAP (Konsistent, Verfügbar, Paritionstolerant consistent, available, partition tolerance) Konsistenz dauert länger Service Oriented Architecture Programmkommunikation über Service-APIs Relative einfache Abfragen Service-Middleware verantwortet Datenkonsistenz

12 NoSQL Varianten Column Oriented Stores Key-Value Datenbanken / Stores (z.b. REDIS, Memcache, Btrieve) Document Databases (CouchDB, MongoDB) GraphDatabases "GraphDatabase PropertyGraph" by Originally uploaded by Ahzf (Transferred by Obersachse) Licensed under CC0 via Wikimedia Commons -

13 Warum dennoch PostgreSQL ACID wird gebraucht Langlebigkeit / Fehlertoleranz mit bewährten PostgrSQL Techniken Disaster Recovery / PITR (pg_barman) Hochverfügbarkeit Kombination teilstrukturierte Daten mit relationalen Informationen z.b. Dokumente mit organisatorischer Einbindung Nutzung weltbestes Supportangebot Because you can.

14

15 Gründe, warum das möglich ist PostgreSQL = PostRelational Erweiterbarkeit PostgreSQL NoSQL als Hack PostgreSQL die Hackers Database PostgreSQL sehr verlässlich Verlässlichkeit dauert; tuning nach schneller

16 als Dokument Datenbank Unstrukturierte Daten in PostgreSQL einfach möglich seit 2003

17 Teodor Sigaev, Oleg Bartunov, Alexander Korotkov

18 hstore Id, Col1, col2, col3, col4. Viele Datenspalten Nur nach wenigen wird gesucht, andere einzig Ausgabe Speichert Key/Value Paare (inspiriert durch Perl Hashes) Binäres Speicherformat

19 hstore Vor- und Nachteile Flexible Speicherung Semi-strukturierter Daten Reichhaltige Operatoren vorhanden Kompakte Speicherung Binärformat Keine Baumstrukturen (wie in JSON verfügbar, JSON existiert seit ~2006) Abbildung in Programmiersprachen? Standard für JSON: (ECMA-404 The JSON Data Interchange Standard, JSON RFC-7159) Standard für hstore?

20 JSON

21 JSON in PostgreSQL Vor PostgreSQL 9.2: Speichern in TEXT Spalten, zugriff per PL/PERL, PL/PYTHON, PL/V8 PostgreSQL 9.2: JSON Datentyp; Speicherung als Text, Validierung, Zugriffsoperatoren PostgreSQL 9.4: JSONB November 2013: Binäres Speicherformat gemeinsam für hstore und jsonb Januar 2014: binäres Speicherformat in PostgreSQL Core

22 jsonb CREATE TABLE BUECHER ( Titel citext not null, isbn isbn not null primary key, publikationsinfo jsonb not null ) CREATE INDEX ON buecher USING GIN (publikationsinfo); Alle Operationen CREATE INDEX ON buecher USING GIN (publikationsinfo json_path_ops); nur search path operator "@>", kleinerer Index SELECT count(*) FROM buecher WHERE '{ "Verlag" : "2ndQuadrant Verlag" }';

23 Wie schnell? Benchmarks von Oleg / Teodor / Alexander MacBookAir, 8GB RAM, 256 GB SSD 1'252'973 Delicious Lesezeichen Ladezeiten TEXT: 34 s ohne Validierung JSON: 37 s - json Validierung Jsonb: 43 s - json Validierung, Binäre Speicherung (MongoDB 2.6.0: ~13 Minuten für Load)

24 Suche in JSON-Data CREATE INDEX gin_jb_path_idx ON jb USING gin(jb jsonb_path_ops); EXPLAIN ANALYZE SELECT count(*) FROM jb WHERE '{"tags": [{"term":"nyc"}]}'::jsonb; QUERY PLAN Aggregate (cost= rows=1 width=0) (actual time= rows=1 loops=1) -> Bitmap Heap Scan on jb (cost= rows=1253 width=0) (actual time= rows=285 loops=1) Recheck Cond: '{"tags": [{"term": "NYC"}]}'::jsonb) Heap Blocks: exact=285 -> Bitmap Index Scan on gin_jb_path_idx (cost= rows=1253 width=0) (actual time= rows=285 loops=1) Index Cond: '{"tags": [{"term": "NYC"}]}'::jsonb) Planning time: ms Execution runtime: ms

25 Suche hier und anderswo Operator contains, in PostgreSQL Json: 10s, seqscan Jsonb: 8.5ms, GIN JSONB_OPS Jsonb: 0.7ms, GIN JSONB_PATH_OPS Mongo: 1.0ms btree index

26 Mögliche Anwendung Daten mit häufigen Änderungen in JSONb feld speichern indizieren per GIN evtl. funktionale Indizes auf Inhalte einzelner Felder wenn sich Datenmodell stabilisiert, keys / Values aus JSON Objekten nach Spalten migrieren kann über Update / Insert Trigger Applikations- Transparent erfolgen Daten in Spalten dann in kompletter relationaler Reportbarkeit

27 Geschwindigkeit Mehr im Speicher halten Verlässlichkeit reduzieren Schreiben reduzieren Scaling auf multiple Maschinen

28 PostgreSQL als in-memory-db Festplatten und Speicherformat identisch Persistenz ist durch WAL entkoppelt, kann ausgeschaltet werden Prozess-Modell mit gemeinsamen Daten + Speicherbereichen per Backend gut genug für viele Anwendungen darf's ein Terabyte mehr sein

29 Verlässlichkeit reduzieren Daten werden verloren gehen Es ist einzig unsicher, wann nur verwenden, wenn Daten nicht erhalten bleiben müssen

30 Was macht so verlässlich? 1340 in Genua erfunden

31 Was macht so verlässlich? 1340 in Genua erfunden WALrecords table files

32 Verlässlichkeit reduzieren (0) UNLOGGED TABLES Seit PostgreSQL 9.1 verfügbar CREATE UNLOGGED TABLE GRBILANZ (soll NUMERIC(40), haben NUMERIC(2)); Kein WAL wird geschrieben Messungen: 13-17% mehr TPS gemäßt pg_bench PITR, Disaster Recovery, Streaming Replication sind nicht mehr möglich

33 Verlässlichkeit reduzieren Nur bei Daten, die verlorengehen dürfen, Beispiele Load OpenGeo Daten Initialladen Datenbank aus DUMP NACH LOAD WIEDER VERLÄSSLICH MACHEN Datawarehouses, beschickt aus anderen Systemen Sessionstores bei Webservern

34 Verlässlichkeit reduzieren (1) WAL_LEVEL = minimal Weniger WAL Schreiblast Crash Recovery bleibt möglich PITR; Streaming Replication; disaster Recovery entfallen Sowieso Default Einstellung :(

35 Verlässlichkeit reduzieren (2) SYNCHRONOUS_COMMIT = off Kein Warten auf geschriebenes WAL, bevor COMMIT als erfolgreich gemeldet ist Keine Datenkorruption Transaktionen, die als geschrieben gemeldet waren, können verloren gehen Transaktionen gehen konsistent verloren Bewußt einsetzen! In Beratung durch Datenbank Experten investieren

36 Verlässlichkeit reduzieren (3) FULL_PAGE_WRITES = OFF Nach Checkpoint, erstes WAL-Schreiben nicht mehr zwingend ganze Seite weniger Schreiblast Systemcrash wird zur Datenkorruption führen Recovery kann scheitern Einzig für verlierbare Situationen Verwenden. z.b. initialload von Datenbank Dumps. Nicht im Regelbetrieb verwenden

37 Verlässlichkeit reduzieren (4) FSYNC = OFF Bestätigung des Schreibens auf Festplatte wird nicht abgewartet Datenkorruption wird passieren Sehr schnell Verwenden für: - initialload von Datenbanken - einlesen von Geodaten - Datenabzug nur schauen auf Extranet-Server NACH LOAD für Betrieb wieder einschalten! Einschalten prüfen: postgres=# show fsync; fsync on

38 Weniger Schreiblast multiple Server Umstellen Trigger Based Replikation (Slony, Bucardo, Londiste) nach Streaming Replication / UDR (BDR). Trigger basiert: Trigger auf DML (insert, update..) Speicherung in Queue-Tabelle Daten in Haupttabelle+WAL, Daten in Queue+WAL Kosten für Encoding Kosten für Queue Maintainance

39 Schreiben Reduzieren, multiple Server

40 Leseskalierung Daten werden von Applikation auf 1x PostgreSQL geschrieben PostgreSQL repliziert an viele Slaves Lesezugriffe erfolgen auf Slaves verteilt

41 Leseskalierung Schreibzugriffe Applikation Replikation Lesende Zugriffe Applikation

42 Leseskalierung pg_bouncer Replik ation Anwendung

43 Gesprächsanregungen Mittagessen, Pause Pl/proxy statt pg_bouncer - sharding mit PostgreSQL Performance PostgreSQL für Friends of Friends Queries Tasse beim 2ndQuadrant Tisch abholen pg_bouncer zusammen mit RepMgr