Het resultaat was SQL, voor het eerst geïntroduceerd aan de wereld in 1974. In de komende decennia zou SQL immens populair blijken te zijn. Toen relationele databases zoals System R, Ingres, DB2, Oracle, SQL Server, PostgreSQL, MySQL (en meer) de software industrie overnamen, werd SQL de taal bij uitstek voor interactie met een database, en werd de lingua franca voor een steeds drukker en concurrerender ecosysteem.
(Helaas heeft Raymond Boyce nooit de kans gehad om getuige te zijn van SQL’s succes. Hij stierf aan een hersen aneurysma 1 maand na het geven van een van de eerste SQL presentaties, slechts 26 jaar oud, een vrouw en jonge dochter achterlatend.)
Een tijdje leek het erop dat SQL met succes zijn missie had volbracht. Maar toen gebeurde het Internet.
Deel 2: NoSQL Strikes Back
Terwijl Chamberlin en Boyce bezig waren met de ontwikkeling van SQL, realiseerden zij zich niet dat een tweede groep ingenieurs in Californië bezig was met een ander ontluikend project dat zich later wijd zou verspreiden en het bestaan van SQL zou bedreigen. Dat project was ARPANET, en op 29 oktober 1969 werd het geboren.
Maar SQL was eigenlijk prima totdat een andere ingenieur opdook en het World Wide Web uitvond, in 1989.
Het internet en het web bloeiden als onkruid en ontwrichtten onze wereld op talloze manieren, maar voor de gegevensgemeenschap veroorzaakte het een bijzondere hoofdpijn: nieuwe bronnen die gegevens genereerden met veel grotere volumes en snelheden dan voorheen.
Toen het internet bleef groeien, ontdekte de softwaregemeenschap dat de relationele databases van die tijd deze nieuwe belasting niet aankonden. Er was een verstoring in de kracht, alsof een miljoen databases het uitschreeuwden en plotseling overbelast raakten.
Toen braken twee nieuwe internetgiganten door en ontwikkelden hun eigen gedistribueerde, niet-relationele systemen om te helpen met deze nieuwe stortvloed aan gegevens: MapReduce (gepubliceerd in 2004) en Bigtable (gepubliceerd in 2006) door Google, en Dynamo (gepubliceerd in 2007) door Amazon. Deze baanbrekende papers leidden tot nog meer niet-relationele databases, waaronder Hadoop (gebaseerd op de MapReduce paper, 2006), Cassandra (sterk geïnspireerd door zowel de Bigtable en Dynamo papers, 2008) en MongoDB (2009). Omdat dit nieuwe systemen waren, grotendeels vanaf nul geschreven, vermeed men ook SQL, wat leidde tot de opkomst van de NoSQL beweging.
En wat heeft de software ontwikkelaars gemeenschap NoSQL opgegeten, door het veel breder te omarmen dan de oorspronkelijke Google/Amazon auteurs bedoelden. Het is gemakkelijk te begrijpen waarom: NoSQL was nieuw en glanzend; het beloofde schaal en kracht; het leek de snelle weg naar technisch succes. Maar toen begonnen de problemen op te duiken.
De ontwikkelaars kwamen er al snel achter dat het niet hebben van SQL eigenlijk heel beperkend was. Elke NoSQL-database bood zijn eigen unieke querytaal, wat betekende: meer talen om te leren (en om aan je collega’s te leren); meer problemen bij het koppelen van deze databases aan applicaties, wat leidde tot tonnen broze lijmcode; een gebrek aan een ecosysteem van derden, waardoor bedrijven hun eigen operationele en visualisatietools moesten ontwikkelen.
De NoSQL-talen waren, omdat ze nieuw waren, ook nog niet volledig ontwikkeld. Zo was er in relationele databases jarenlang gewerkt om noodzakelijke functies aan SQL toe te voegen (bijv. JOINs); de onvolwassenheid van NoSQL talen betekende dat er meer complexiteit op applicatieniveau nodig was. Het gebrek aan JOINs leidde ook tot denormalisatie, wat leidde tot data bloat en rigiditeit.
Sommige NoSQL databases voegden hun eigen “SQL-achtige” query talen toe, zoals Cassandra’s CQL. Maar dit maakte het probleem vaak alleen maar erger. Het gebruik van een interface die bijna identiek is aan iets wat algemener is, zorgde in feite voor meer mentale wrijving: engineers wisten niet wat wel en niet werd ondersteund.
Sommigen in de gemeenschap zagen de problemen met NoSQL al vroeg (bijv. DeWitt en Stonebraker in 2008). Na verloop van tijd sloten meer en meer softwareontwikkelaars zich bij hen aan, door hard verdiende littekens van persoonlijke ervaring.
Deel 3: Terugkeer van SQL
In eerste instantie verleid door de donkere kant, begon de softwaregemeenschap het licht te zien en terug te keren naar SQL.
Eerst kwamen de SQL-interfaces bovenop Hadoop (en later Spark), wat de industrie ertoe aanzette om NoSQL te “back-cronimeren” tot “Niet alleen SQL” (ja, leuk geprobeerd).
Toen kwam de opkomst van NewSQL: nieuwe schaalbare databases die SQL volledig omarmden. H-Store (gepubliceerd 2008) van MIT en Brown onderzoekers was een van de eerste schaalbare OLTP databases. Google leidde opnieuw de weg voor een geo-repliceerde SQL-interfaced database met hun eerste Spanner paper (gepubliceerd 2012) (onder wie de oorspronkelijke MapReduce auteurs), gevolgd door andere pioniers zoals CockroachDB (2014).
Op hetzelfde moment begon de PostgreSQL gemeenschap te herleven, met het toevoegen van kritische verbeteringen zoals een JSON datatype (2012), en een potpourri van nieuwe functies in PostgreSQL 10 (betere native ondersteuning voor partitionering en replicatie, ondersteuning voor full text search voor JSON, enz.) en PostgreSQL 11 (toegevoegde mogelijkheden voor parallelle datadefinitie, introduceerde just-in-time complilatie, enz.), met nog meer te komen in PostgreSQL 12. Andere bedrijven zoals CitusDB (2016, nu eigendom van Microsoft) en ondergetekende (TimescaleDB, uitgebracht in 2017 ) vonden nieuwe manieren om PostgreSQL te schalen voor gespecialiseerde dataworkloads.
In feite weerspiegelt onze reis in de ontwikkeling van TimescaleDB nauw het pad dat de industrie heeft genomen. Vroege interne versies van TimescaleDB waren voorzien van onze eigen SQL-achtige querytaal, “ioQL” genaamd. Ja, ook wij werden verleid door de duistere kant: het bouwen van onze eigen querytaal voelde krachtig. Maar hoewel het de makkelijkste weg leek, realiseerden we ons al snel dat we veel meer werk zouden moeten doen: bijv. het bepalen van de syntaxis, het bouwen van verschillende connectors, het opleiden van gebruikers, enz. We moesten ook voortdurend de juiste syntaxis opzoeken voor queries die we al in SQL konden uitdrukken, voor een query taal die we zelf hadden geschreven!
Op een dag realiseerden we ons dat het bouwen van onze eigen query taal geen zin had. Dat de sleutel was om SQL te omarmen. En dat was een van de beste ontwerpbeslissingen die we hebben genomen. Onmiddellijk ging er een hele nieuwe wereld voor ons open. Slechts een paar maanden na onze officiële lancering in 2017 konden gebruikers ons in productie gebruiken en allerlei prachtige dingen uit de doos krijgen: visualisatietools, connectoren naar gangbare ORM’s, een verscheidenheid aan tooling en back-upopties, een overvloed aan tutorials en syntaxisuitleg online, enz.
Maar geloof ons niet op ons woord.
Google loopt al meer dan een decennium duidelijk voorop op het gebied van datatechniek en -infrastructuur. Het loont de moeite om goed op te letten waar zij mee bezig zijn.
Bekijk Google’s tweede grote Spanner-paper (Spanner: Becoming a SQL System, mei 2017), en je zult zien dat het onze onafhankelijke bevindingen ondersteunt.
Google begon bijvoorbeeld bovenop Bigtable te bouwen, maar ontdekte vervolgens dat het gebrek aan SQL voor problemen zorgde (nadruk in alle citaten hieronder de onze):
“Hoewel deze systemen enkele van de voordelen van een databasesysteem boden, misten ze veel traditionele databasefuncties waar applicatieontwikkelaars vaak op vertrouwen. Een belangrijk voorbeeld is een robuuste querytaal, wat betekende dat ontwikkelaars complexe code moesten schrijven om de gegevens in hun applicaties te verwerken en aggregeren. Daarom hebben we besloten om van Spanner een volwaardig SQL-systeem te maken, waarbij de uitvoering van query’s nauw is geïntegreerd met de andere architecturale kenmerken van Spanner (zoals sterke consistentie en globale replicatie).”
Later in de paper leggen ze de beweegredenen voor hun overgang van NoSQL naar SQL verder vast:
De oorspronkelijke API van Spanner bood NoSQL methoden voor point lookups en range scans van individuele en interleaved tabellen. Terwijl NoSQL methoden een eenvoudige manier boden om Spanner te starten, en nog steeds nuttig zijn in eenvoudige opvraag scenario’s, heeft SQL een significante toegevoegde waarde geboden in het uitdrukken van meer complexe data toegangspatronen en het pushen van berekeningen naar de data.
De paper beschrijft ook hoe de adoptie van SQL niet stopt bij Spanner, maar zich feitelijk uitbreidt over de rest van Google, waar meerdere systemen tegenwoordig een gemeenschappelijk SQL dialect delen:
De SQL-engine van Spanner deelt een gemeenschappelijk SQL-dialect, genaamd “Standard SQL”, met verschillende andere systemen bij Google, waaronder interne systemen zoals F1 en Dremel (onder andere), en externe systemen zoals BigQuery…
Voor gebruikers binnen Google verlaagt dit de drempel om over de systemen heen te werken. Een ontwikkelaar of data analist die SQL schrijft in een Spanner database kan zijn kennis van de taal overbrengen naar Dremel zonder zich zorgen te maken over subtiele verschillen in syntaxis, NULL afhandeling, etc.
Het succes van deze aanpak spreekt voor zich. Spanner is al de “bron van de waarheid” voor belangrijke Google-systemen, waaronder AdWords en Google Play, terwijl “Potentiële Cloud-klanten zijn overweldigend geïnteresseerd in het gebruik van SQL.”
In aanmerking genomen dat Google de NoSQL-beweging in de eerste plaats heeft helpen initiëren, is het nogal opmerkelijk dat het vandaag de dag SQL omarmt. (Sommigen vragen zich af: “Heeft Google de Big Data industrie op een 10 jarige kopstoot gestuurd?”.)
Wat dit betekent voor de toekomst van data: SQL als universele interface
In computernetwerken bestaat een concept dat de “smalle taille” wordt genoemd en een universele interface beschrijft.
Dit idee is ontstaan om een belangrijk probleem op te lossen: stel je op een willekeurig netwerkapparaat een stack voor, met lagen hardware aan de onderkant en lagen software aan de bovenkant. Er kan een verscheidenheid aan netwerkhardware bestaan; evenzo kan er een verscheidenheid aan software en toepassingen bestaan. Er is een manier nodig om ervoor te zorgen dat ongeacht de hardware, de software toch verbinding kan maken met het netwerk; en ongeacht de software, dat de netwerkhardware weet hoe de netwerkaanvragen moeten worden afgehandeld.
In netwerken wordt de rol van universele interface vervuld door Internet Protocol (IP), dat fungeert als verbindingslaag tussen netwerkprotocollen op lager niveau die zijn ontworpen voor lokale netwerken, en toepassings- en transportprotocollen op hoger niveau. (Hier is een mooie uitleg.) En (in een brede oversimplificatie), deze universele interface werd de lingua franca voor computers, waardoor netwerken met elkaar verbonden konden worden, apparaten met elkaar konden communiceren, en dit “netwerk van netwerken” kon uitgroeien tot het rijke en gevarieerde Internet van vandaag.
Wij geloven dat SQL de universele interface is geworden voor data analyse.
We leven in een tijdperk waarin gegevens “s werelds meest waardevolle bron” worden. Als gevolg daarvan hebben we een Cambrische explosie gezien van gespecialiseerde databases (OLAP, time-series, document, grafiek, etc.), data processing tools (Hadoop, Spark, Flink), data bussen (Kafka, RabbitMQ), etc. We hebben ook meer applicaties die op deze data-infrastructuur moeten vertrouwen, of het nu gaat om datavisualisatietools van derden (Tableau, Grafana, PowerBI, Superset), webframeworks (Rails, Django) of op maat gemaakte datagestuurde applicaties.
Netwerken hebben we een complexe stack, met infrastructuur aan de onderkant en applicaties aan de bovenkant. Normaal gesproken schrijven we een heleboel code om deze stack te laten werken. Maar lijmcode kan broos zijn: het moet worden onderhouden en bijgehouden.
Wat we nodig hebben is een interface waarmee onderdelen van deze stack met elkaar kunnen communiceren. Idealiter iets dat al gestandaardiseerd is in de industrie.
Dat is de kracht van SQL. Net als IP is SQL een universele interface.
Maar SQL is in feite veel meer dan IP. Want gegevens worden ook door mensen geanalyseerd. En trouw aan het doel dat de makers van SQL er aanvankelijk aan gaven, is SQL leesbaar.
Is SQL perfect? Nee, maar het is de taal die de meesten van ons in de gemeenschap kennen. En hoewel er al ingenieurs zijn die werken aan een meer op natuurlijke taal georiënteerde interface, waar zullen die systemen dan op aansluiten? SQL.
Dus er is nog een laag, helemaal boven op de stapel. En die laag zijn wij.
SQL is terug
SQL is terug. Niet alleen omdat het vervelend is om lijmcode te schrijven om NoSQL-tools in elkaar te flansen. Niet alleen omdat het omscholen van werknemers om een groot aantal nieuwe talen te leren moeilijk is. Niet alleen omdat standaarden een goede zaak kunnen zijn.
Maar ook omdat de wereld gevuld is met data. Het omringt ons, bindt ons. In het begin vertrouwden we op onze menselijke zintuigen en zintuiglijke zenuwstelsels om die te verwerken. Nu worden onze software- en hardwaresystemen ook slim genoeg om ons te helpen. En naarmate we meer en meer gegevens verzamelen om onze wereld beter te begrijpen, zal ook de complexiteit van onze systemen om die gegevens op te slaan, te verwerken, te analyseren en te visualiseren alleen maar toenemen.
Of we kunnen leven in een wereld van broze systemen en een miljoen interfaces. Of we kunnen SQL blijven omarmen.
Leuk dit bericht en geïnteresseerd in meer informatie?
Kijk op onze GitHub, word lid van onze Slack-community en meld je hieronder aan voor de community-mailinglijst. We nemen ook mensen aan!
Aanbevolen lectuur voor wie meer wil weten over de geschiedenis van databases (ook wel syllabus voor de toekomstige TimescaleDB Intro to Databases Class):
- A Relational Model of Data for Large Shared Data Banks (IBM Research, 1970)
- SEQUEL: A Structured English Query Language (IBM Research, 1974)
- System R: Relational Approach to Database Management (IBM Research, 1976)
- MapReduce: Vereenvoudigde gegevensverwerking op grote clusters (Google, 2004)
- C-Store: A Column-oriented DBMS (MIT, anderen, 2005)
- Bigtable: Een gedistribueerd opslagsysteem voor gestructureerde gegevens (Google, 2006)
- Dynamo: Amazon’s Highly Available Key-value Store (Amazon, 2007)
- MapReduce: Een grote stap terug (DeWitt, Stonebreaker, 2008)
- H-Store: A High-Performance, Distributed Main Memory Transaction Processing System (MIT, Brown, anderen, 2008)
- Spark: Cluster Computing with Working Sets (UC Berkeley, 2010)
- Spanner: Google’s Globally-Distributed Database (Google, 2012)
- Early History of SQL (Chamberlin, 2012)
- How the Internet was Born (Hines, 2015)
- Spanner: Een SQL-systeem worden (Google, 2017)