Michael Stonebraker bedenkt nieuwe databases

"Om me even op het heden te concentreren: we gebruiken databases voor twee hoofdzaken. Ten eerste de administratie van transacties, aan de andere kant voor het doen van onderzoek in de verzamelde gegevens. Dan gaat het over datamining en datawarehousing. Hoe gaat dat in zijn werk? Er wordt een transactie uitgevoerd en die heeft tot gevolg dat een plukje gegevens klaar staat om in je database te worden ingevoerd. Het is slim om dat rij voor rij te doen. Om de snelheid niet nadelig te beïnvloeden kun je beter afzien van compressie van gegevens. En natuurlijk wil je de opgeslagen gegevens later ook nog eens terugvinden, met andere woorden er wordt een B­tree­index van gemaakt." "Mooi, na een dagje transactieverwerken wil je weleens weten wat er allemaal is gebeurd en is het tijd voor een analyse van de gegevens. Als je de Oracle’s van deze wereld moet geloven, kan dat met precies dezelfde database als die waarmee je de OLTP (OnLine Transaction Processing, red.) hebt bijgehouden. Ik zal even voordoen wat er bij datawarehousing allemaal aan de hand is: Je vult de database niet beetje voor beetje, er wordt een hele sloot gegevens tegelijk ingepompt. Omdat je bij het analyseren van de gegevens niet in alles bent geïnteresseerd is het het beste om de database kolomsgewijs te vullen. Omdat het zoveel gegevens zijn, als je tenminste serieus bezig bent, dan is compressie wel een goed idee. Een echte index is niet zo nodig. Nou, als je die twee pakketten eisen met elkaar vergelijkt, heb je dan nog steeds het idee dat je het met dezelfde soort database kan doen? Kom nou toch." Sensortechnologie "Dat was het heden, maar we stevenen af op een toekomst, waar voor een database heel andere toepassingen worden bedacht. Op het MIT zijn we bezig met een nieuw project dat je het beste kunt omschrijven als ‘sensortechnologie van een volgende generatie’. Sensoren kunnen steeds kleiner worden gemaakt, waardoor ze goedkoper worden. Op een gegeven moment ben je in staat alle zaken in een bepaalde omgeving, ik denk aan een winkel, een fabriekshal of zelfs een militair slagveld, van een sensor te voorzien. Daarmee kan ieder voorwerp in die omgeving doorlopend gegevens over zichzelf verspreiden. Werk je buiten, dan kan de locatie van een voorwerp of een mens, worden bepaald met behulp van GPS. Binnen een afgesloten ruimte werkt dat niet, maar dan kun je andere technieken gebruiken voor de plaatsbepaling." "Okee, wat hebben we dan: een hoeveelheid gegevensbronnen die continu data uitsturen. Via een monitorsysteem worden die gegevens opgevangen en dan doorgesluisd naar een database. Je hebt dan niet meer te maken met een aantal onlinetransacties per seconde die verwerkt moeten worden, maar met een miljoen of meer sensoren die hun data doorsturen. We gaan dan van een traditionele opzet, waar de database het grootste deel van de tijd passief is en het werk wordt gedaan door de applicatie, naar precies het omgekeerde. De database verricht al het werk, terwijl de applicatie maar een beperkt deel van de tijd actief is." "Zo’n applicatie kan een beheersysteem voor een strijdtoneel zijn. Zo’n programma wordt actief wanneer bepaalde vragen beantwoord moeten worden, zoals ‘waar is tank 38997 de afgelopen drie uur precies geweest’ of ‘dreigt die tank soms een mijnenveld binnen te rijden’. Op zo’n moment genereert de database een ‘trigger’ en die zorgt ervoor dat het programma iets gaat doen." "Het hoeft allemaal niet zo moorddadig hoor, je kunt je ook voorstellen dat de slimme labels op voedingsmiddelen zijn bevestigd. Zo gauw een klant in een supermarkt een artikel uit het schap haalt en in het winkelwagentje legt, wordt ook een triggersignaal gegeven. Bijvoorbeeld voor het systeem dat de voorraad van de winkel bijhoudt. Maar je kunt ook nog in een andere richting denken, als je weet wie degene is die het artikel net heeft gepakt. Heeft niets met privacy te maken hoor, het kan ook anoniem, bijvoorbeeld op het nummer van de klantenkaart. Stel, je weet wie net een bepaald artikel heeft gekocht en uit het profiel van diegene kun je vaststellen welke artikelen hij of zij meestal ook koopt. Het is dan een koud kunstje om, als een van die spullen in de aanbieding is, via een display boven het schap heel snel een persoonlijke reclame weer te geven. Het zal misschien nog een paar jaar duren, maar zo’n intelligente winkel komt er beslist." Inslikken "Kijken we nog verder vooruit, zeg een jaar of twintig, dan zijn de sensoren inmiddels zo klein geworden dat je ze kunt inslikken. Voor sommige landen kan dat een vervanging zijn voor een visumstempel in je paspoort. Je slikt bij binnenkomst een sensor in en de autoriteiten weten dan steeds waar je je bevindt. Zover zijn we echter nog niet. Wie denkt dat deze voorspelling vergezocht is, moet maar eens goed kijken naar wat we de afgelopen twintig jaar op databasegebied voor elkaar hebben weten te brengen. De databasesoftware die we nu zo vanzelfsprekend vinden, heeft een lange ontwikkeling achter zich die zeker niet zonder slag of stoot is verlopen." "In de jaren zestig van de vorige eeuw bestond er een databasestandaard die Codasyl heette. Dat was een combinatie van een recordbeschrijving voor de bestanden en de manieren om daar gegevens in te zoeken. Uit de Codasyl­hoek kwam bijvoorbeeld ook een programmeertaal als Cobol. Codasyl was een behoorlijk ingewikkeld stukje werk en wij hadden zo rond 1972 het idee dat het een stuk simpeler moest kunnen. Onder het motto: iets dat zo complex is als Codasyl kan nooit goed werken. Je moet het op een hoger niveau tillen en nieuwe talen ontwikkelen." Uiteindelijk kwamen we uit op het relationele model, dat door het Codasyl­kamp gewoon werd weggelachen. Met reacties als: ‘Je kunt dat relationele model niet eens implementeren op een computersysteem’ en ‘Die taaltjes van jullie zijn echt niet te begrijpen laat staan dat iemand ze kan gebruiken’. Je snapt het, de oorlog was verklaard en we hadden meteen een nieuw onderzoeksdoel: ‘bewijs dat die lui van Codasyl ongelijk hebben’." "Ik ging aan de slag met een handjevol studenten en afgestudeerden van Berkeley, op een PDP­11 van Digital waar we toevallig over konden beschikken. Dat apparaat werkte onder Unix, toen een gloednieuw besturingssysteem. Wij waren een van de eerste tien sites buiten AT&T waar Unix werd gebruikt. Met die PDP­11/40 hadden we een interactief systeem tot onze beschikking, in tegenstelling tot de rest van de universiteit die op een 6600­systeem van CDC moest werken. Een apparaat dat alleen geschikt was voor batchverwerking." Quel "Het onderzoek vorderde gestaag en mondde uit in de zoektaal Quel, inderdaad heel eenvoudig de afkorting van Query Language. De database die daar omheen paste droeg de naam Ingres. Voor de commerciële exploitatie van de software werd een eigen firma opgericht, die de naam Relational Technology Inc (RTI) droeg. Halverwege de jaren tachtig werd de naam gewijzigd in Ingres Corp. De voornaamste concurrent in die tijd was Oracle en zo tegen 1988 begonnen zij de marketingslag te winnen. Ingres had versterking nodig en vond die in een fusie met ASK." "Tja, hadden we maar geweten wat ons te wachten stond. Sandra Kurtzig, de baas van ASK, had een slimme manier bedacht om op kosten te besparen. Die bestond er in, dat de hele afdeling R&D inclusief engineering werd opgeheven. Toen was voor mij de maat vol en ben ik weggegaan. ASK/Ingres heeft het tij niet kunnen keren en werd uiteindelijk opgekocht door Computer Associates."