Suche
Interview mit Lukas Eder

„Java-Entwickler würden sehr viel mehr SQL schreiben, wenn sie die Technologie besser verstehen würden“

Hartmut Schlosser

Lukas Eder

„Es gibt keinen besonderen Grund, auf NoSQL-Datensilos auszuweichen“ – mit dieser Aussage bricht Java-Champion und JAX-Speaker Lukas Eder (Data Geekery) eine Lanze für SQL-basierte Datenspeicher. Im JAXenter-Interview erklärt er, was sich hinter NewSQL verbirgt, und verrät SQL-Tricks, die so manchen Java-Entwickler in Staunen versetzen dürften.

JAXenter: Im Zeichen von NoSQL hat SQL ein wenig den Ruf erhalten, vor allem traditionelle Datenbanksysteme zu bedienen. Innovation verortet man eher bei  NoSQL und Big Data-Technologien auf Basis von Hadoop. Wie siehst du das?

Lukas Eder: Wer sagt das, ein MongoDB-Vertriebler? 😉

Im Ernst:

  1. SQL-on-Hadoop ist, was im Moment alle machen wollen. Warum? Map=SELECT und Reduce=GROUP BY. Das war’s auch schon mit der „Mächtigkeit“ von Hadoop. Nach Jahrzenten von SQL und tollen Features für Analytics reicht Map/Reduce für nicht-triviale Reports einfach nicht aus.
  2. Ein paar wichtige Big Data Player:
    •        SAP mit HANA (SQL-basierter Column Store)
    •       Amazon mit RedShift (SQL-basierter Column Store)
    •        HP mit Vertica (SQL-basierter Column Store)
    •       VoltDB (SQL-basierter Column Store)
    •       SQL-on-Hadoop (Hive, Impala, etc.)
    •         Alle “klassischen” Hersteller (SQL Server, Oracle, etc.) haben nun auch Column Store Support.

Und eben auch wie gesagt, SQL-on-Hadoop. Es gibt keinen besonderen Grund, auf NoSQL-Datensilos auszuweichen. SQL als Sprache hat nie an Bedeutung verloren, und das relationale Modell ebenso wenig. Für kurze Zeit gab es ein paar sehr laute Konkurrenten. Diejenigen, die aber nicht mittlerweile aufs SQL-Pferd setzen, sind mittlerweile schon fast alle verstummt.

N.B: Wir hatten das bereits zweimal. Mit den Objektdatenbanken und den XML-Datenbanken. Alles Technologien, die heute niemand mehr braucht.

 

Lukas-Eder

Treffen Sie Lukas Eder auf der JAX 2016 (18. – 22. April):

Ten SQL Tricks that you didn’t think were possible

SQL is the winning language of Big Data. Whether you’re running a classic relational database, a column store (“NewSQL”), or a non-relational storage system (“NoSQL”), a powerful, declarative, SQL-based query language makes the difference. In this fast-paced talk, we’re going to look at very peculiar and interesting data problems and how we can solve them with SQL. We’ll explore common table expressions, hierarchical SQL, table-valued functions, lateral joins, row value expressions, window functions, and advanced data types, such as XML and JSON. Most importantly, however, we’re going to learn that everyone can write advanced SQL.

Nur bis 17. Dezember: Agile Day For Free + Frühbucherpreise + Gratis-Tablet!

 

JAXenter: NewSQL ist da ja so ein Kampfbegriff – was verbirgt sich dahinter?

Lukas Eder: NewSQL ist spannend – ein Begriff von Michael Stonebraker, der nach einer langen Reihe imposanter Innovationen (Ingres, Postgres, Vertica, VoltDB) verdientermaßen den Turing Preis im 2014 gewonnen hatte.

NewSQL dreht sich aber vor allem um Storage, nicht um Abfragesprachen oder Datenmodelle. Im Grunde genommen werden Daten neu einfach nicht mehr Reihe für Reihe abgespeichert, sondern Spalte für Spalte (Column Stores). Damit sind Aggregationen über große Datenmengen viel einfacher zu bewältigen.

Wir haben einen seiner bekannten Vorträge auf unserem Blog verlinkt: definitiv sehenswert!

NewSQL zeigt, dass einmal mehr gewisse neue Funktionalität im analytischen Bereich ins relationale Modell eingegliedert werden kann. So haben wir einmal mehr das beste von allem.

JAXenter: Auf der JAX verrätst du 10 SQL-Tricks, die niemand für möglich hält. Hast du eine kleine Sneak Preview parat?

Lukas Eder: Klar doch! Folgende Oracle-spezifische Abfrage berechnet die beste „Teilmengensumme“ für einen beliebigen Wert („ASSIGN“) aus einer Teilmenge von Werten („WORK“):

WITH
    ASSIGN (ID, ASSIGN_AMT) AS (
                  SELECT 1, 25150 FROM DUAL
        UNION ALL SELECT 2, 19800 FROM DUAL
        UNION ALL SELECT 3, 27511 FROM DUAL
    ),
    WORK (ID, WORK_AMT) AS (
                  SELECT 1 , 7120  FROM DUAL
        UNION ALL SELECT 2 , 8150  FROM DUAL
        UNION ALL SELECT 3 , 8255  FROM DUAL
        UNION ALL SELECT 4 , 9051  FROM DUAL
        UNION ALL SELECT 5 , 1220  FROM DUAL
        UNION ALL SELECT 6 , 12515 FROM DUAL
        UNION ALL SELECT 7 , 13555 FROM DUAL
        UNION ALL SELECT 8 , 5221  FROM DUAL
        UNION ALL SELECT 9 , 812   FROM DUAL
        UNION ALL SELECT 10, 6562  FROM DUAL
    ),
 
    SUMS (SUBSET_SUM, MAX_ID, CALC) AS (
        SELECT
            WORK_AMT,
            ID,
            TO_CHAR(WORK_AMT)
        FROM WORK
         
        UNION ALL
         
        SELECT
            WORK_AMT + SUBSET_SUM,
            GREATEST (MAX_ID, WORK.ID),
            CALC || '+' || WORK_AMT
        FROM
            SUMS
        JOIN
            WORK
        ON
            SUMS.MAX_ID < WORK.ID
    )
 
SELECT
    ASSIGN.ID,
    ASSIGN.ASSIGN_AMT,
    MIN (SUBSET_SUM) KEEP (
        DENSE_RANK FIRST
        ORDER BY ABS (ASSIGN_AMT - SUBSET_SUM)
    ) AS CLOSEST_SUM,
    MIN (CALC) KEEP (
        DENSE_RANK FIRST
        ORDER BY ABS (ASSIGN_AMT - SUBSET_SUM)
    ) AS CALCULATION
FROM
    SUMS
CROSS JOIN
    ASSIGN
GROUP BY
    ASSIGN.ID, ASSIGN.ASSIGN_AMT

Das Resultat zeigt, was gemeint ist:

ID  ASSIGN_AMT  CLOSEST_SUM  CALCULATION
————————————————————
1        25150        25133  7120 + 8150 + 9051 + 812
2        19800        19768  1220 + 12515 + 5221 + 812
3        27511        27488  8150 + 8255 + 9051 + 1220 + 812

Das wird einer der komplexeren Tricks meiner Session sein. Die Teilnehmer werden die Lösung nach der Teilnahme aber verstehen und hoffentlich bald auch selber in Projekten anwenden, das verspreche ich!

JAXenter: Mal kurz zu einem anderen Thema, das gerade heftig diskutiert wird: Java 9 wurde abermals um 6 Monate verschoben – Jigsaw ist wohl noch nicht soweit. Wie beurteilst du die Verschiebung?

Lukas Eder: Ich kenne mich in diesem Bereich leider zu wenig aus. Es ist natürlich schade, wenn ein Feature, was schon so oft verschoben wird, nochmals verschoben wird. Umgekehrt schätzen wir Java alle für das hohe Maß an Rückwärtskompatibilität. Wenn bei Jigsaw etwas schief gehen würde (und das Potential ist groß), dann würde Java großen Schaden erleiden. Wir können froh sein, dass dieses Feature nicht zu früh geliefert wird.

Persönlich finde ich es natürlich schade, da mit dieser Verzögerung wohl auch Projekt Valhalla (Java 10) weiter verzögert wird, ein Projekt, das mich persönlich viel mehr interessiert.

JAXenter: Wie wichtig schätzt du Java 9 für deine persönliche Arbeit ein?

Lukas Eder: Gar nicht. Außer Jigsaw gibt es keine größeren Neuerungen, die für jOOQ relevant sein werden. Und auch Jigsaw ist für jOOQ nicht sonderlich wichtig. Unsere Kunden im Consulting-Umfeld verwenden aktuell immer noch Java 6 – von daher gesehen können wir sogar von Lamdbas und anderen Java 8 Features nur träumen.

JAXenter: Was ist die Kernbotschaft, die du in deiner JAX-Session vermitteln möchtest?

Lukas Eder: SQL ist mächtig, komplex, aber eigentlich gar nicht so schwierig. Wenn man bereit ist, von imperativer Programmierung auf deklarative / funktionale Programmierung umzudenken, dann werden sehr schwierige Probleme (wie eben das Teilmengensummenproblem) plötzlich ziemlich einfach und elegant zu lösen.

Java-Entwickler würden sehr viel mehr SQL schreiben, wenn sie die Technologie besser verstehen würden. Daran arbeite ich.

JAXenter: Vielen Dank für dieses Interview!

Lukas Eder ist leidenschaftlicher Java- und SQL-Entwickler. Er ist Gründer und Leiter der Forschungs- und Entwicklungsabteilung der Data Geekery GmbH, dem Unternehmen hinter jOOQ – die einfachste Art, um SQL in Java zu schreiben.
Blockchain Whitepaper 2018

Free: Blockchain Technology Whitepaper

If building a blockchain from scratch is beyond your current scope, the blockchain technology whitepaper is worth a look. Experts from the field share their know-how, tips and tricks, development advice, and strategy for becoming a blockchain master.

Geschrieben von
Hartmut Schlosser
Hartmut Schlosser
Content-Stratege, IT-Redakteur, Storyteller – als Online-Teamlead bei S&S Media ist Hartmut Schlosser immer auf der Suche nach der Geschichte hinter der News. SEO und KPIs isst er zum Frühstück. Satt machen ihn kreative Aktionen, die den Leser bewegen. @hschlosser
Kommentare

Hinterlasse einen Kommentar

4 Kommentare auf "„Java-Entwickler würden sehr viel mehr SQL schreiben, wenn sie die Technologie besser verstehen würden“"

avatar
400
  Subscribe  
Benachrichtige mich zu:
Mat
Gast
Entwickler sollten „viel mehr SQL schreiben“? Das halte ich fuer Quatsch mit Sosse. Die meisten der genannten Konstrukte sind datenbankspezifisch, dass es in einem Team zwei Leute gibt die das o.g. Beispiel auf Anhieb verstehen halte ich zusaetzlich fuer sehr unwahrscheinlich. Dazu sind solche Statements nicht vernuenftig zu debuggen, muessen separat gewartet werden und immer wieder fuer die ein oder andere „Uberaschung“ gut. Entwickler wollen i.d.R. aus gutem Grund nichts mit nativem SQL zu tun haben. Mit einem OR-Mapper halte ich mir die technischen Details von Hals und falls doch map reduce o.ae. benoetigt wird sind Engines die JavaScript sprechen… Read more »
Lukas Eder
Gast
@Mat, vielen Dank für deinen Kommentar. Du triffst den Nagel genau auf den Kopf! Leider denken 95% der Java Entwickler so wie du: „Ich kann das nicht“. „Meine (dummen?) Mitarbeiter können das noch viel weniger“. „Lieber programmiere ich alles imperativ, da versteh ich wenigstens was passiert“. Das kann doch gar nicht sein. SQL als Technologie ist mehr als 30 Jahre alt, und noch nie hat SQL so gut funktioniert wie heute, mit modernen RDBMS. Diese Technologie kann doch gar nicht so schwierig sein. Trau dich. Und trau dir diese Technologie zu, du wirst sie verstehen, und die anderen 95% der… Read more »
Marco
Gast
Sehr interessanter Artikel, aber ich kann dem leider nicht zustimmen. Ich kann PL/SQL programmieren und auch SQL schreiben, sogar komplexere als das im obrigen Beispiel. Aber ich bin auch JAVA Entwickler und freue mich, dass jemand so genial war und einen ORM entwickelt hat. Das Problem was doch vorherrscht, dass viele DBs eigene Syntax mitbringen. Das obrige Beispiel ist ja nur Oracle Spezifisch, man macht sich doch mit JAVA abhängig von der Datenbank, wenn man jetzt diesen Code verwendet, macht man sich doch abhängig von der DB. Dies macht die ganze Anwendung unflexible. Wir müssen uns auf der Arbeit die… Read more »
Mat
Gast

@Lukas. Ich glaube du hast mich nicht richtig verstanden. Ich habe kein Problem mit deklarativen oder funktionalen Ansätzen. Ich verstehe sehr wohl was da passiert.
Ich bevorzuge lediglich imperative Lösungen aus den bereits genannten Gründen.

Wie du allerdings bereits erwähnt hast können viele Entwickler nichts damit anfangen, was für größere Projekte bereits ein show-stopper ist. Zusätzlich sollten in jedem Software-Projekt Nutzen und Kosten jeglicher eingesetzter Technologien in Relation gesetzt werden und spätestens dann hat sich „NewSQL“ erledigt.