Stonebraker, klassische Datenbanken und NoSQL

Stonebraker, klassische Datenbanken und NoSQL Udo Lipeck, DBSem12.07.12 1 Teil I Geschichte 2 Michael Stonebraker •  geb. 1943, PhD 1971 •  DB-‐Pionier •  1971-‐2000 Ass. ... Full Prof. Univ. of Calif. at Berkeley
(Ingres, ein RDBMS für [kleinere] UNIX-‐Maschinen, u.a. “query modiﬁcaVon“, später Postgres, u.a. UDFs,Erweiterbarkeit) •  seit 2001 Adjunct Prof. am MIT (Aurora, C-‐Store, H-‐Store, Morpheus, SciDB) •  hat viele DB-‐Firmen gegründet (Ingres, Illustra, Cohera, Streambase,VerVca,VoltDB, Paradigm4) •  seit 2010 KriVker der NoSQL-‐Bewegung 3 RelaVonale DBMS •  ca. 1976: Forschungsprototypen System R (IBM), Ingres (Stonebraker et al.) •  ab frühe 1980er: Kommerzielle Gegenstücke: DB2, Ingres •  dann weitere Nachfolger: (Ingres)→Sybase→SQLServer, Ingres→PostgreSQL, (System R) →Oracle, (Ingres →) Informix u.v.a. •  sollten ursprünglich hierarchische und Netzwerk-‐
Datenbanken, insbes. IMS und CODASYL ablösen 4 RelaVonale DBMS: Szenario damals •  1000x langsamere Prozessoren •  1000x kleinere interne Speicher •  viel weniger Plajenplatz, viel geringere Bandbreite zwischen ext. und int. Speicher •  nur ein DBMS-‐Markt •  dumme Terminals: „interakVve“ Anfrage-‐
Eingabe (per Terminal-‐Prompts) •  [heute PCs/APR: GUIs, kaum interakVve TransakVonen oder direkte SQL-‐Schnijstellen] 5 RelaVonale DBMS: CharakterisVka • 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
SQL vor allem für „Online TransacVon Processing“ (OLTP) auch für (einfaches) „Online AnalyVcal Processing“ (OLAP) zeilenweise Speicherung relaVonaler Tabellen externe Speicherung zeilenorienVerte Verarbeitung, incl. Pipelining B-‐Bäume für Indexierung kostenbasierter OpVmierer, ursprgl. zur Minimierung von externen Speicherzugriﬀen TransakVonen mit ACID-‐Eigenschao (atomicity, consistency, isolaVon, duraVon) MulV-‐Threading Sperrbasiertes Concurrency Control Log-‐basiertes Recovery 6 Teil II Stonebraker gegen klassische DBMS 7 OSFA ? •  “One Size Fits All (OSFA): An Idea Whose Time Has Come and Gone“ [ICDE 2005] •  und Teil 2: “...Benchmarking Results“ [CIDR 2007] •  “The End of an Architectural Era (It‘s Time for a Complete Rewrite)“ [VLDB 2007] •  OSFA steht für 25 Jahre kommerzielle DBMS •  ursprünglich für betriebswirtschaolich-‐administraVve Anwendungen entworfen und opVmiert •  aber benutzt für alle möglichen datenzentrierten Anwendungen 8 RelaVonale DBMS: OSFA-‐Strategie •  Die gleiche Code-‐Zeile für alle Anwendungen, um Probleme zu vermeiden –  Wartungskosten für Codevarianten –  InkompaVbiltät bei wechselnden Anwendungen –  Verkaufs-‐ und MarkeVngposiVonierung oder einfacher: “I am the guy with the hammer, and everything is a nail.“ •  Diverseste Erweiterungen: –  UDT/UDF, objekt-‐relaVonal, ... –  neue MulV-‐Prozessor-‐KonﬁguraVonen bis zu Grids (ursprgl. shared-‐memory, inzw. auch shared-‐nothing) –  XML, Data Warehouse Support, ... •  Aber kein Redesign ! 25 Jahre alter “Legacy“-‐Code 9 RDBMS nicht geeignet für: Data Warehousing •  Online-‐Benutzer wollen schnelle Antwortzeiten für ihre (meist vorbereiteten) Anfragen/TransakVonen. •  Management („Business-‐intelligence“) -‐ Benutzer wollen komplexe ad-‐hoc Anfragen stellen, historische Trends sehen und Daten korrelieren. •  Deshalb getrenntes System, mit periodischer Übertragung von Schnappschüssen; aber letztlich ein weiteres RDBMS(+). 10 RDBMS nicht geeignet für: Data Warehousing •  Illusion eines einzigen DBMS-‐Produkts: •  Warehouse: –  Star/Snowﬂake-‐Schema  –  Filter-‐MulVjoin-‐Aggregie-‐ rungs-‐Anfragen –  zugeh.SQL-‐Erweiterungen (cube, rollup, ...) –  materialisierte Sichten –  Bitmap-‐Indexe, Join-‐Indexe –  Datenkompression, minimale Codierungen, ... OpVmierungstakVk rungs-‐
•  OLTP: –  virtuelle Sichten, B-‐Baum-‐Indexe, kostenbasierter OpVmierer •  Immerhin noch ein gemeinsames Front End 11 12 RDBMS nicht geeignet für: Stream Processing •  Datenströme von Sensoren → ReakVonen, Alarme –  Militär: Fahrzeuge, Soldaten; –  Verkehr: Staus, Maut; –  Wirtschao: Börsenvorgänge –  und alle Arten von akVven Geräten •  z.B. Analyse von Börsendatenströmen mehrerer Datenlieferanten auf verspätete Daten 13 14 RDBMS nicht geeignet für: Stream Processing • 
Im „Vorbeiﬂug“ verarbeiten – 
– 
–
DBMS: erst speichern, dann verarbeiten → Latenz Outbound vs. Inbound processing oder DBMS mit Triggern ?: keinerlei Programmier-‐ und Ausführungsunterstützung (“second-‐class ciMzens“) 15 RDBMS nicht geeignet für: Stream Processing •  Passende OperaVonen benutzen, insbes. ständige Aggregierungen über sliding windows, Timeouts –  DBMS: erwartet beendete Tabellen für Aggregierung •  Nachrichtenverarbeitung (Anw.) und Zustandsspeicherungen (DB) in einem Prozess –  DBMS: Client-‐Server-‐Architektur → getrennte Adressräume für DB-‐ und Anwendungslogik (bis auf stored UDFs) → häuﬁge Prozesswechsel •  High Availabilty, z.B. 7x24h für Finanzdienste –  DBMS: evtl. Recovery braucht Down-‐Zeit; transiente Daten (hier Zustände) verloren 16 RDBMS nicht geeignet für: Stream Processing •  Noch schlimmer: Klassisch faktorisierte Komponenten-‐Architektur ⇒  3x heavy-‐weight&isolierte Systemsooware ⇒  gewalVger Overhead pro Nachricht 17 Spezialisierte DB-‐Maschinen für Stream Processing •  Stream Processing Engine (SPE): Streambase*: •  eingebejetes System, nicht im Client-‐Server-‐Modus, ein Adressraum, keine Prozesswechsel, obwohl BerkeleyDB für Zustandsspeicherung integriert •  rechnet ohnehin überwiegend im virtuellen Speicher •  Backup-‐Maschine für “hot standby“ => kein Logging nöVg •  je nach Anwendung kurze Nachrichtenverluste und/oder Nachrichtenduplikate tolerabel => also nicht immer perfektes Recovery nöVg •  Stream Processing ist keine Mehrbenutzeranwendung => keine ACID-‐TransakVonen, kein Locking •  inzwischen SQL-‐ähnliche NotaVon für Nachrichtenberechnungen/ -‐auswahlen/-‐aggregierungen (StreamSQL), unterstützen Zei}enster •  Vergleich vs. komm. RDBMS: 333000 Nachrichten pro Sekunde vs. 12640 (mit Triggern noch schlechter) •  weiteres: Vorcompilieren bis auf Maschinenebene, opVmiert für die Verarbeitung einer Nachricht durch viele OperaVonen mit min. Latenz * Stonebraker et al., MIT & Streambase Inc
18 Spezialisierte DB-‐Maschinen für Data Warehousing •  Beispiele: C-‐Store→VerAca*, MonetDB** •  **) “Database Architecture EvoluMon: Mammals ﬂourished long before Dinosaurs became exMnct“ von Kersten et al. CWI Amsterdam [VLDB 2009] •  Lese-‐OpVmierung: Spaltenweise Speich./Verarb., “column-‐store“-‐System •  nur in Anfragen/Aggregierungen benöVgte Ajribute zugreifen staj (über)breiter Tupel •  ermöglicht typbezogene Datenkompression, SorVerung und Indexierung * Stonebraker et al. MIT & Vertica Inc.
19 Spezialisierte DB-‐Maschinen für Data Warehousing •  BAT = binary associaVon table •  nutzt verVkale ParVVonierung •  Addressierung bei dichten Surrogat-‐
schlüsseln hardwareseiVg unterstützt! (staj B-‐Baum-‐
Primärschlüssel-‐
Index) 20 Spezialisierte DB-‐Maschinen für Data Warehousing •  Column-‐Stores eigentlich schon seit 1970ern für staVsVsche Anwendungen •  eﬃziente Umsetzung möglicht durch größere Hauptspeicher (viele Spaltenwerte staj einem Record) •  passend zu MulV-‐Core-‐Prozessoren: Parallelisierung von FunkVonen (auf versch. Spalten) , nur anschl. Join nöVg •  BAT-‐Algebra-‐Ausdruck nicht → Tupel-‐Iterator mit “instrucVon cache misses“, sondern → ein MonetDB-‐Assembler-‐Language mit „operator-‐at-‐a-‐Vme“-‐
Verarbeitung, mehr “instrucVon locality“ für Compiler-‐OpVmierungen •  Nachteil: viele Zwischenmaterialierungen •  Cache-‐bewusste Algorithmen wie “parVVoned hash join“ •  Vergleich vs. komm. RDBMS (erfahren getunt): 300x schneller bei sehr breiter Faktentabelle (212 Spalten) und schmaler Anfrage (7 Spalten), aber auch TPC-‐Benchmark für DWH 7x schneller 21 Spezialisierte DB-‐Maschinen für Textsuche (meint: Suchmaschinen) •  Vorbereitung: ähnlich inbound stream processing (Daten von Webcrawlern) + Bereinigung + Indexierung •  Textsuche: nur ganz wenige Anfragetypen! •  Kein Bedarf an TransakVonen/Sperren, nur Text-‐Daten, nicht einmal wiederholbare/vollständige Antworten nöVg •  Aber Bedarf an horizontaler DatenparVVonierung, anw.speziﬁsche Kompressionen •  Schreiben: append only, Lesen: hochgradig parallel •  deshalb MulV-‐Server-‐Architektur, High Availability durch schnelle Recovery aus Replikaten •  Vergleiche Google‘s GFS, später BigTable sowie DatenabstrakVonen für Parallelverarbeitung wie MapReduce ! 22 Spezialisierte DB-‐Maschinen für wissenschaoliche Anwendungen Anforderungen: •  fortlaufend wachsende Riesendatensammlungen zu analysieren (z.B. Daten von Weltraumsensoren) •  erfordert hocheﬃziente mulVdimensionale Indexierung und komplexe anwendungsspeziﬁsche Aggregierungen •  => mulVdimensionale Arrays als Datenmodell ! •  Erfahrung aus Sequoia2000 [Stonebraker et.al. 1993]: SimulaVon von Arrays durch RDBMS war ineﬃzient und inﬂexibel –  Standarddarstellung: Arraytable (i1,i2,...,in,value) •  “Lineage“ (Abstammung) der Daten: “Cooking“ (Bereinigung+RedukVon+Aggregierung) soll nachverfolgbar sein •  kein Vergessen von Daten •  Daten sind mit Unsicherheiten behaoet 23 Spezialisierte DB-‐Maschinen für wissenschaoliche Anwendungen SciDB* (Vorläufer ASAP) [2009ﬀ]: •  Arrays (Matrizen) als Datenmodell, –  umfasst Tabellen •  Strukturelle Operatoren (umdimensionierung) –  subsample, reshape bzw. transform, sjoin , regrid, concat •  Inhaltliche Operatoren: –  ﬁlter, aggregate, cjoin, auch mulVply •  FunkVonale Anfragesprache AFL –  erinnert an APL –  für komm. Benutzer SQL-‐arVge AQL (wird in AFL compiliert) •  Postgres-‐arVge UDFs/UDAs für komplexe Analysen •  Versch. Programmiersprachen für Einbejung –  Parse-‐Tree-‐ZwischenrepräsentaVon •  Open Source * Stonebraker et al. MIT & Paradigm4 Inc
24 Spezialisierte DB-‐Maschinen für wissenschaoliche Anwendungen SciDB (Forts.): •  Im Grid, mit dynamischer ParVVonierung •  Speicherung von Arrays –  durch ParVVonierung in evtl. überlappende Rechtecke (chunks), kontrolliert durch R-‐Baum (?) –  Unterscheidung, ob dicht/dünn besetzte Arrays mit regulären/nichtregulären Nullwertlücken • 
• 
Normalerweise keine Speicherung der Dimensionsindices, schnelle Zugriﬀe OpVmierung auf Pipelining und Parallelisierung • 
Vergleich vs. komm. RDBMS und vs. Matlab • 
Weitere Features: –  nutzt kommutaVve, blockierende OperaVonen (Zwischenarrays, ggf. Umverteilung) –  Inkrementell zur Laufzeit –  2-‐82fach gegenüber Matlab (MatrixmulVplikaVon eingebaut), –  100-‐800fach gegenüber RDBMS (obwohl Matrixmult. mit 1 SQL-‐Anfrage geht) Kompressionen (ähnlich Bildverarbeitung) Auch In situ-‐Daten (Dateien) erlaubt Lineage: Versionen, Herkuno von (ganzen) Arrays Unsicherheit: Inhaltswerte mit Wahrscheinlichkeiten oder mit unteren/oberen Schranken + Wahrscheinlichkeiten, dass diese überschrijen –  Noch keine unsicherheitsbehaoete Dimensionsindices – 
– 
– 
– 
25 Klassische RDBMS sogar ungeeignet für: OLTP !!!??? •  große Hauptspeicher sollten inzwischen reichen •  High Availability inzwischen auch hier üblich  –  keine möglichst kurzen Reparaturzeiten, sondern Backup Maschinen für “hot standby“, “real-‐Vme failover“ –  Unternehmen zahlen eher für Mehrfachsysteme als für Konsequenzen von Down-‐Zeiten •  TransakVonen eher kurz, überwiegend kollisionsfrei/-‐kontrollierbar, vorbereitbar •  RelaVv einfache Anfragen (max. 6 Joins) „In an OLTP world one never asks for the employees who earn more than their managers.“
26 27 Spezialisierte DB-‐Maschinen für OLTP VoltDB* (Vorläufer H-‐Store)[2007ﬀf]: •  Für kurze TransakVonen sollte „single-‐thread“ pro Server reichen
=> keine Ressourcenkontrolle für parallele Threads, keine “concurrent“ B-‐Bäume •  Mit ReplikaVonsbasiertem Recovery in MulV-‐shared-‐nothing-‐Server-‐Umgebung => en}ällt Log-‐basiertes Recovery, keine redo-‐Logs mehr !!! •  Undo-‐Logs ja, aber nicht persistent •  Mit horizontaler, auch Hash-‐basierter ParVVonierung •  Vorbereitete TransakVonen als “stored procedures“ => kein ODBC/JDBC-‐Overhead, keine Prozesswechsel •  TransakVonsklassen unterscheiden (ggf. darau•in entwerfen): • 
• 
• 
• 
–  z.B. “constrained tree applicaVons“, bleiben bei passender abgeleiteter ParVVonierung “single-‐sited“, wegen „single thread“ keine Concurrency Control (bis auf Replikate) –  Andere: „one-‐shot“ (ohne Datenaustausch), “two-‐phase“ (nicht integritätsverletzend), “commuVng“ TransakVonen in eindeuVger Zeitstempel-‐Reihenfolge hintereinander (mit etwas Warten) =>=>=> nur noch Rest-‐Concurrency-‐Control, opVmisVsch => en}ällt Locking !!! allerdings ggf. Umschalten auf ausgefeiltere Strategien bei zuvielen Aborts Im TPC-‐Benchmark für OLTP 82x schneller als klass.RDBMS * Stonebraker et al. MIT & VoltDB Inc
28 Und was sonst zum Teil I zu sagen wäre •  The RelaMonal Model is not necessarily the answer •  SQL is not the answer •  Es gibt schon viele domain/markt-‐speziﬁsche DB-‐
Maschinen (“tailored DBS“) mit divergierenden Fähigkeiten. RDBMS-‐Overheads vermeiden hilo. •  bessere Einbejung in Programmiersprachen nöVg (vgl. auch kein OSFA mehr in Programmiersprachen) zB Ruby-‐on-‐Rails für stored procs ? •  außerdem gewünscht: möglichst “no knobs“, “self-‐tuning machines“ •  Klassische DBMS „nur“ noch für hybride Anwendungen? 29 Teil III Stonebraker für DBMS gegen NoSQL 30 Beobachtungen • 
• 
„A Comparison of Approaches to Large-‐Scale Data Analysis“ Vergleich von Map-‐Reduce (MR) bzw. Hadoop
mit einem komm.parDBMS und mit VerVca-‐DBMS (grep/weblog/join tasks) MapReduce eigtl. bekannter Kontrollﬂuss in parallelen DBMS InstallaVon Hadoop überraschend leicht Laden/Einlesen für DBMSe viel langsamer Berechnungen in DBMSen schneller: VerVca 2.3x schneller als parDBMS 3.2x schneller als Hadoop (Knotenanzahl?; Google-‐Impl.?) •  MapReduce muss programmiert werden, aber inzwischen Ansätze für deklaraVve SQL-‐ähnliche Schnijstellen • 
• 
• 
• 
• 
• 
Vergleiche hinken, da nur eine MR-‐ImplemenVerung und nur abgeschlossene Datenﬂüsse berücksichVgt 31 Ursachen •  DBMS parsen zur Ladezeit (einmal, mit Schema) und speichern kontrolliert & typisiert •  MR-‐Systeme bzw. Programme speichern unkontrolliert & untypisiert, aber parsen zur Laufzeit (wiederholt, da ohne Schema) •  Wegen fehlender Typisierung auch keine diﬀerenzierte Datenkompressionen möglich •  MR-‐Systeme unterstützen nur Primärschlüsselzugriﬀe, könnten aber auch Indexe erzeugen und (konsistent?) warten •  Vorteile der SpaltenorienVerung für schmale Anfragen •  DBMS und MR-‐Systeme können Daten hash-‐parVVonieren und passende Schlüssel ausnutzen; beide sind skalierbar!? 32 Folgerungen •  DBMS bleiben ideal für deklaraVve Anfragen. •  DBMS können MR-‐Tasks, soweit nöVge UDF/UDAs formulierbar und eﬃzient ausführbar •  MR-‐Systeme ideal für ETL (cooking) + read once, •  MR-‐Systeme besser als SQL für komplizierte TransformaVonen /
Analysen und für semi-‐strukturierte Daten •  Eigtl. MR-‐Programmierparadigma nicht nur auf Dateien, auch auf DBen, DB-‐Anfrageergebnisse anwendbar •  Bessere MR-‐ImplemenVerungen wie Google können auch „etwas Schema“, etwas besser komprimieren, viele Zwischendateien besser handlen u.a. •  MR-‐Systeme: Scheduling erst zur Laufzeit +/-‐ ? •  MR-‐Systeme: auch open source (es gibt kein open source parDBMS!) 33 Weitere Diskussionsbeiträge •  “The NoSQL Discussion has Nothing to Do with SQL“ •  vergleicht OLTP-‐Ansätze (erinnere Amazon) : DB-‐Server beschleunigbar durch Vermeidung von Overheads, shared-‐nothing DBMS längst skalierbar, aber noch ACID-‐TransakVonen •  “Errors in DBS, Eventual Consistency and the CAP Theorem“ •  AP! => C aufgeben? : Ev. Cons. hilo nicht bei allen Fehlerfällen: Anw‘fehler, sich wiederholende DBMS-‐Fehler, Katastrophen; LANs und neuere OLTP-‐DBMS sagen: CA! •  “Why [standard] Enterprises are Uninterested in NoSQL“: –  OLTP erfordert ACID –  DWH erfordert mächVge deklaraVve Anfragesprache –  NoSQL = no standards •  “Those who do not understand the lessons from previous generaMon systems are doomed to make their mistakes“. “Stand on the shoulders of those who came before you, not on their toes.“ 34 Zum Schluss: Teil IV Stonebraker – wohin ? 35 HPTS Oct 2011
36 VoltDB
37