View
3
Download
0
Category
Preview:
Citation preview
Vergleich von großen relationalen DBs im Cloud Zeitalter
DOAG Big Data Days – 22. September 2017 - Kassel
Matthias Fuchs, Principal Consultant, esentri AG Nürnberg
@hias222
3
Relationale DBs
> Relationale DBs
ACID
Transaktion
Serializable
Per-formance
verfügbar
Groß
Managed
SQLStandard
Cloudoptimiert
4
Auswahl Cloud Produkte
> Auswahl Cloud Produkte
OLT
P W
orkl
oad
DW
H
Que
ry P
erfo
rman
ceA
mou
nt o
f Dat
a
GoogleSpanner
Agenda
> Aurora, Oracle, Spanner
> Transaktionen> Verfügbarkeit> SQL Standard> Demos > Preise
> Ausblick - Zukunft
5> Oracle RDBMS vs NoSQL - Agenda
Aurora
> Aurora compatible zu MySQL 5.6 und Postgres 9.6.1
> Maximale Tabellen Größe 64TB
> Nutzung S3 Storage, Async Quorum> Replica Shares Storage
> Aurora Lock Manger Enhancments> Index Optimization
> Aurora
Aurora MySQL
> Aurora MySQL
> Cluster mit maximal 15 Read Nodes
> Write Endpoint> Standbyfailover
> Read Endpoint> Loadbalancing over replicas
> Supports only InnoDB> Aurora Replicas are automatic
failover targets with no data loss> Supports only MySQL version
5.6.
Oracle 12c Cloud
> Infrastruktur Service
> Database und Exadata Cloud Service> Cloud Infrastructure Database with Real Application Clusters (RAC)
> Optimierte Server oder Exadata
Spanner – Outages - CAP
> Spanner – Outages - CAP
> Spanner claims to be consistent and available
> Aber CP System> modern geographically distributed Chubby cells
provide an average availability of 99.99958
A
C P
CASystemsRDBMS(e.g.OracleDatabase,
MySQL,...)
APSystemsDynamoDB,Redis,Riak,
Cassandra
SimpleDB
CPSystemsMySQLCluster,OracleRAC,
HBase,Accumolo,
MongoDB,RethinkDB
Everyclient can
always read and
write
Allnodes continue
working under
network partitions
Allclients share
the sameview on
the data
Google:
https://research.google.com/pubs/archive/45855.pdf
Spanner
> Horizontal skalierbar über Regionen und Rechenzentren von einem bis zu Hunderten oderTausenden von Knoten.
> Automatische Replikation und Wartung dank Datenbankmanagementdienst> Schemas, ACID-Transaktionen und SQL-Abfragen (ANSI 2011).> Client-Bibliotheken in Go, Java, Node.js, PHP und Python. Weitere werden hinzukommen. JDBC-
Treiber für Konnektivität mit den gängigen Tools anderer Anbieter.> Speziell für hohe, globale Last bei transaktionaler Konsistenz.
> Vergleichbar Open Source:
> Transaktions - Isolation (Atomar Consitenz Isolation Durable)> ANSI/ISO SQL-Standard (SQL-92) > Ziel: Serializable (höchster Standard)> Hauptmerkmal Row Locks> Multi Version Concurrency Control
Row Locks
> Row Locks
> Wie werden die Locks erstellt?
Locks
Sharedlock eXclusive Lock
oracle SELECTFORUPDATE Insert,update, delete,merge
postgres SELECTFORUPDATEandSELECTFORSHARE
Insert,update, delete,merge
spanner Read-writetransactionsread
Read-writetransactionsWrite
> Locks
Transaktionen
> jede Änderung erzeugt neue Objektversion– Lesezugriffe sehen den beim BOT (Begin of Transaction) gültigen DB-Zustand-> keine Synchronisation mehr für Lese-Transaktionen (dennoch Serialisierbarkeit) – erheblich weniger Synchronisationskonflikte– Realisierung über Commit-Zähler für Änderungen– anwendbar für Sperrverfahren und optimistische Synchronisation
> Postgres> Neues Version Tuple mit transactionid – marked as expired (Row)
> Transactionid, Status ist im clog ($Data/pg_clog)> On commit/rollback mark in clog
> Vacuum cleaner process beseitigt abort/expired Einträge
> Oracle> Old versions in Rollback Segment (undo)
> Im Block wird der Status eingetragen, transaction IDs mit einem Zeiger auf Rolbacksegmente> Der Status der Transaction wird mit SCNs (System Change Number) im Block gepflegt
> Beim Start wird die SCN gelesen> Überprüfung ob die Page/Block Transaktionen enthählt, die nicht sichtbar sein sollen
> Dazu wird der Rollbackstatus überprüft, und ggf. zurückgeschrieben
> Transaktionen
Spanner Transaktionen
> TrueTime external consistency
> GPS und atomic clocks – Ungenauigkeit 10ms> if T2 starts to commit after T1 finishes committing, then the timestamp for T2 is greater than the timestamp for T1
> Während eines commit muss der Hauptprozess warte, bis er sicher ist, das der commit in der Vergangenheit > MVCC
> MVCC (Multiversion Concurrency Control) Spanner snapshots sind konsitent zu einem Zeitpunkt > Vorhalten ca 1 Stunde
> alle Änderungen am System werden in einem Snapshot gehalten> Änderungen (Writes) werden am Client gepuffert bis zum commit
> woundwait zur Vermeidung von deadlocks> preemptiver Ansatz: Sperrbesitzer wird zurückgesetzt, wenn er bei einem Sperrkonflikt jünger als anfordernde Transaktion ist
> kein Zyklus möglich, da nur jüngere auf ältere Transaktionen warten
> Spanner Transaktionen
https://static.googleusercontent.com/media/research.google.com/en//archive/spanner-osdi2012.pdf
Spanner Transaktionen
> Spanner Transaktionen
> Zum Zeitpunkt Txn2 - Read A sieht Txn2 die Änderung von Txn1> Eigene Änderungen sieht der Client nicht – Pufferung am Client bis zum commit
Oracle – Bare Metal Cloud Infrastrukture
http://www.oracle.com/technetwork/database/availability/bmc-maa-blueprints-3754051.pdf
Oracle – one Region
> Alle in einer Region
> Observer im 3 Rechenzentrum> Active Dataguard für Readonly
Oracle Maximum Availibility
> Asynchronos Sync (Bild) Oder Far Sync
> Golden Gate Target für Migrationen
> Observer für Failover
> Duplicate BAckup
AWS - Aurora
AmazonRelationalDatabaseServiceUserGuideAPIVersion2014-10-31https://de.slideshare.net/AmazonWebServices/whats-new-in-amazon-aurora-for-mysql-and-postgresql
> standby replica> Read Replica> tFailover Zeiten typischer weise 60-120
seconds> Automatischer Mechanismus, der
zusätzlich den DNS Eintrag aktualisiert> 15 Aurora Replicas> Postgres
> "Survivable" cache warming
Google Spanner
> Universe:> Universemaster Status information> Placement driver – Replaction und Balancing über Zonen
> Zone
> Eine Zone hat 100 oder bis zu 1000 Sapnner Server Der Zonemasterverteilt die Daten, die Clients laden direkt von den Spanner Servern. Proxies optimieren den Clientzugriff.
> Es gibt immer eine 3-fache Replikation der Daten in der Google Cloud Platform availability zone
> Es gibt ebenso eine Replizierung in verschiedene Zonen um einemZonenverlust vorzubeugen
> When best practices are followed, each Cloud Spanner node can provide up to 10,000 queries per second (QPS) of reads or 2000 QPS of writes (writing single rows at 1 KB data per row), and 2 TB storage.
> Shared nothing
> Google Spanner
Vergleich Überblick
AuroraPostgres Oracle SpannerEntwickler Sprache Intern PL/pgSQL,R, PL/SQL,Java,R -
AdvancedSQL yes yes SQL2011
Tuning ++ + 0
jdbc ja ja Ja(simba)
Active-Active - RAC Ja (sharednothing)
views ja ja -
OwnFunctions/Procedures ja ja -
Index,ForeignKeys ja ja ja
RestZugriff ja ja Ja(standard)
MigrationvonOraclemöglich
Ja,Tools - manuell
> Vergleich Überblick
Besipiel Datatypes
Oraclestandard Postgres SpannerVARCHAR2 TIMESTAMP bigint double precision lseg BOOL
NVARCHAR2 NCLOB bigserial inet macaddr INT64
NUMBER INTERVALYEAR bit integer money FLOAT64
FLOAT INTERVAL DAY bit varying interval numeric STRING( length )
LONG RAW(size) boolean json path BYTES( length )
DATE LONG RAW box jsonb pg_lsn DATE
BINARY_FLOAT ROWID bytea line point TIMESTAMP
BINARY_DOUBLE UROWID character xml polygon Arrays
TIMESTAMP CHAR character varying uuid real
BLOB NCHAR cidr timestamp smallint
BFILE CLOB circle tsquery smallserial
date tsvector serial
text txid_snapshot
> Besipiel Datatypes
Was bedeutet NewSQL - Spanner Patterns
> Spanner Best Practice
> Anti-pattern: timestamp ordering> Many schema designers are inclined to define a root table that is timestamp ordered, and updated on every
write. Unfortunately, this is one of the least scalable things that you can do. The reason is that this design results in a huge hot spot at the end of the table that can't easily be mitigated. As write rates increase, so do RPCs to a single split, as do lock contention events and other problems. Often these sorts of problems don't appear in small load tests, and instead appear after the application has been in production for some time. By then, it's too late!
> Anti-pattern: sequences> Application developers love using database sequences (or auto-increment) to generate primary keys.
Unfortunately, this habit from the RDBMS days (called surrogate keys) is almost as harmful as the timestamp ordering anti-pattern described above. The reason is that database sequences tend to emit values in a quasi-monotonic way, over time, to producing values that are clustered near each other. This typically produces hot spots when used as primary keys, especially for root rows.
> Was bedeutet NewSQL - Spanner Patterns
Modell/Schema
SQL_STMTSSQL_UUIDVARCHAR2(50)
USERNAMEVARCHAR2(124)
SQL_IDVARCHAR2(32)
SQL_TEXTCLOB
CREATEDTIMESTAMP
> Modell/Schema
SQL_SESSIONSES_UUIDVARCHAR2(50)
SQL_UUIDVARCHAR2(50)
SIDVARCHAR2(20)
USERNAMEVARCHAR2(124)
SQL_IDVARCHAR2(32)
SQL_EXEC_IDNUMBER(22,0)
NUMBERSNAPSNUMBER(22,0)
NUMBERCPUNUMBER(22,0)
NUMBERIONUMBER(22,0)
MACHINEVARCHAR2(124)
TERMINALVARCHAR2(124)
OSUSERVARCHAR2(124)
PROGRAMVARCHAR2(124)
MODULEVARCHAR2(124)
"ACTION"VARCHAR2(124)
CREATEDDATE
ForeignKey
1,4 GB CSV Data4.751.303 Zeilen SQL_STMTS2.128 Zeilen SQL_SESSION
Ladezeit ca 30-45 Minuten 10 MBit
https://github.com/hias222/cloudsql/tree/master/spanner/cloud-client
Example Queries
Type StatementSingle SELECT*FROMSQL_SESSION
WHERESES_UUID='7e7ffe8c-dbe9-4822-96ef-234cbbc2088b';
Join,nonindexequal select*
FROMSQL_SESSIONs,SQL_STMTSstmtWHEREs.SQL_UUID =stmt.SQL_UUID
andstmt.sql_id ='95mpkn5xz9001';
Groupby SELECTcount(*)anzahl,s.username,s.sql_id,s.MACHINE,s.TERMINAL,s."ACTION",s.MODULE
FROMSQL_SESSIONsGROUPBYs.username,s.sql_id,s.MACHINE,s.TERMINAL,s."ACTION",s.MODULE;
Joinn, Groupbynonindexlike SELECTcount(*)anzahl,s.username,s.sql_id,s.MACHINE,s.TERMINAL,s."ACTION",s.MODULE
FROMSQL_SESSIONs,SQL_STMTSstmtWHEREs.SQL_UUID =stmt.SQL_UUID
ANDupper(stmt.SQL_TEXT)LIKE'%INSERT%'GROUPBYs.username,s.sql_id,s.MACHINE,s.TERMINAL,s."ACTION",s.MODULE;
> Example Queries
Ergebnisse ms
> Ergebnisse ms
MiiliSeconds Single join,nonindexequal groupbyjoin,groupbynonindexlike
1(rows1) 2(rows8) 3(rows 825) 4(rows229)
Oracle* 118 2.602 3.660 3.290
Aurora(postgres) 122 949 31.817 36.390
Spanner** 15 169.470 18.000 203.000
Spanner3instances** 13 155.000 13.000 136.000
OracleLocal(6GB,4
cores,VMSSD,corei7) 2 3.685 4.708 5.100
Aurora(MySQL) 55 53 27.810 47.472
*Zeit für Übertragung abgezogen
**Abfrage über Web
Spanner
When best practices are followed, each Cloud Spanner node can provide up to
10,000 queries per second (QPS) of reads or 2000 QPS of writes (writing single rows at 1
KB data per row), and 2 TiB storage.
You are billed only for the storage you use, including tables, secondary indexes, and
overhead for those indexes
50
Reale Tests
> Für aussgaekräftige Tests sollte man VMs in der Cloud nutzen>Der Usecase ist entscheidend>Die quasi NoSQL Datenabank Spanner kann einfache Joins bedienen
>Das Laden von Daten ist der aufwendigeste Teil
> Reale Tests
51
Ausblick - Zukunft
> The hybrid world is here
> Delivering continuous analytics and offering greater simplicity, performance, security and agility for next generation applications
> https://www.iguazio.com/continuous-analytics-real-time-meets-cloud-native/
52
Link with esentri
Über mich
Matthias FuchsPrincipal ConultantMatthias.fuchs@esentri.com
@hias222
> 10+ years Experience with Oracle> Database, Middleware, SOA> OCP> Engineered Systems
> Exadata
> Exalogic
Recommended