The End of an Architectural Era M. Stonebraker, S. Madden, D. J. Abadi, S. Harizopoulos, N. Hachem, P. Helland
Jorn Van Loock
Inleiding Oorsprong relationele DBMS IBM System R (1974) ○ DB2 ○ Sybase ■ SQL Server ○ Oracle
Populaire systemen gebaseerd op oude fundamenten 2
Inleiding ● Hardware evolutie in 25 jaar: ○ ○ ○ ○
1000 x snellere processoren 1000 x meer hoofdgeheugen Kost externe geheugens minimaal Bandbreedte tussen HDD en hoofdgeheugen groeit minder snel
● Markt evolutie Veel veranderingen in tegenstelling tot de database systemen zelf 3
Inleiding RDBMS steunt op oude fundamenten: ○ ○ ○ ○
Opslag op secundair geheugen Multithreading Concurrency met locks Recovery door middel van logs
4
Inleiding RDBMS ingehaald door gespecialiseerde architecturen: ○ Google's gespecialiseerde engines voor tekst ○ Array storage engines zoals MATLAB
RDBMS enkel goed genoeg voor de oude business data processing Bewijs: H-STORE bijna ordegrootte 2 sneller 5
Inhoudstafel ● Ontwerp voor Online Transaction Processing ○ 5 verbeteringen
● ● ● ● ●
Assumpties & overige bottlenecks Overige bottlenecks elimineren H-Store Vergelijkende tests Opmerkingen ○ RDBMS ○ SQL
● Toekomst 6
Ontwerp voor OLTP Wat valt er te verbeteren bij klassieke RDBMS? ○ ○ ○ ○ ○
Hoofdgeheugen herzien Single-threaded Grid computing Hoge beschikbaarheid No Knobs
7
Ontwerp - Hoofdgeheugen herzien Eind 1970: 1 MB hoofdgeheugen Ontwerp met secundair geheugen is nodig Stel netwerk van onafhankelijke nodes: Totaal van +1TB hoofdgeheugen Trage BB naar secundair geheugen: Alles in hoofdgeheugen 8
Ontwerp - Single-threaded Waarom single-threaded? ○ OLTP transacties: niet zwaar ○ Stel: alleen hoofdgeheugen
Single-threaded lijkt meer logisch dan de isolation-overhead er bij te nemen. Complexe code van multi-threaded data kan ook weg 9
Ontwerp - Grid computing 1970: shared-memory multiprocessors Toekomst: individuele systemen Horizontally partition data: maakt het toevoegen van extra nodes gemakkelijk (vergelijking met fork-lift)
10
Ontwerp - Hoge beschikbaarheid 1970: 1 machine + backups op tapes 1980: 1 machine + tapes + backup machine Nu: Hot standby - betalen voor beschikbaarheid Horizontally partition data + intermachine replication + p2p tijdelijke undo-log; geen redo-log meer 11
Ontwerp - No Knobs RDBMSs veel (oude) tuning opties Kennis van DBA nodig Mensen zijn duur, dus op zoek naar een self-everything (self-maintaining, self-healing, self-tuning, ...) systeem
12
Assumpties & overige bottlenecks Stel: ○ ○ ○ ○ ○
Hoofdgeheugen Single-threaded Grid computing Hoge beschikbaarheid No Knobs
Andere bottlenecks 1) JDBC 2) 2PC protocol voor gedistribueerde acties (network overhead) 3) Undo-log 13
Overige bottlenecks elimineren 1) JDBC - Transaction classes in OLTP 2) 2PC protocol ● Veel OLTP tabellen zijn bomen ○ goed voor horizontal paritioning ○ Data goed alloceren over sites ■ Transacties gebeuren volledig binnen 1 site ■ "Vaak tot bijna altijd mogelijk"
● One-shot applicaties ○ Alle transacties kunnen parallel gebeuren zonder dat tussentijdse resultaten naar andere sites moeten ■ Vaak mogelijk met vertical partitioning
14
Overige bottlenecks elimineren 3) Veel transacties 2 fasen: ○ lees ○ schrijf
Uitbuiten om undo-log te elimineren
15
H-Store Ontwikkeld door: ○ Brown University ○ MIT ○ Yale University
Developed in 2007 Doel: ○ Hoge doorvoer ○ Geen oude fundamenten meer
Commerciele versie: VoltDB 16
H-Store Architectuur ○ ○ ○ ○
Grid met share-nothing nodes Tabelrijen in hoofdgeheugen Single-threaded Stored procedures
Queries ○ Query optimizer maakt een query plan om ze op te delen, single-sited te maken, ...
Database Ontwerper ○ Automatische ontwerper om juiste horizontale partitionering, replicatie locaties, ... te vinden 17
H-Store Replicatie, recovery en transactiebeheer ● Single-sited ○ Intermachine replicatie ○ Transacties met timestamps naar replica's ■ Zelfde staat behouden ■ Niet nodig bij "steriele" transacties
● Inter-sites ○ Stel tussentijdse resultaten van sites nodig ■ Transaction Coordinator ontvangt commando ● ●
Zendt een plan verder naar andere sites en workers coordineert
18
Vergelijkende tests RDBMS vs H-Store Benchmark software: TPC-C ○ Transaction Processing Performance Council
19
Verglijkende tests
20
Vergelijkende tests Verschillende aanpassingen, analyses en meevallers ○ 2 fase transacties ○ One-shot ○ Steriel
"It is difficult to imagine that an automatic program could figure out what is required to make TPC-C either one-shot or sterile." 21
Vergelijkende tests Dual-core 2.8GHz TPC-C op H-store ○ 70 416 transacties / seconde (~35 000 / core)
TPC-C op RDBMS ○ 850 transacties / seconde ○ zonder logging : 2500 transacties / seconde
Beste op TPC-C website: ~1000 / core 22
Opmerkingen bij RDBMS 30 jaar dienst gedaan voor business data processing Nu zijn er andere markten: Datawarehouses: ER modellen Stream processing: snelheid
23
Opmerkingen bij SQL One size fits all language ● Overhead interfaces JDBC/ODBC ● Moeilijk te integreren in alledaagse programmeertaal Kleine programmeertalen: voor specifiek iets Ruby-on-Rails: geintegreerde support voor dbaccess 24
Toekomst "Auto-everything-tool": ○ Aangeven welke partitionering leidt tot one-shot, single-sited, sterile, ...
Studie in overhead van logs Studie in data structuren
25
Vragen?
