Onlangs had ik de gelegenheid om Oren Eini te interviewen, CEO en oprichter van Hibernating Rhinos, dat RavenDB levert, een open source documentgeoriënteerde NoSQL die speciaal is ontworpen voor het .NET/Windows-platform.
Oren heeft meer dan 20 jaar ervaring in de ontwikkelingswereld met een sterke focus op het Microsoft- en .NET-ecosysteem. Oren, erkend als een van Microsoft's Most Valuable Professionals sinds 2007, is ook de auteur van "DSLs in Boo:Domain Specific Languages in .NET". Hij spreekt regelmatig op brancheconferenties zoals DevTeach, JAOO, QCon, Oredev, NDC, Yow! en Progressive.NET.
Je kunt het volledige interview hieronder lezen:
Het belangrijkste probleem, denk ik, is gewoon de enorme omvang van de gegevens. Ik heb het niet per se over Big Data en de complexiteit van het beheren van een dataset gemeten in honderden terabytes. Ik heb het over het aantal databases en datasilo's dat je in een organisatie hebt. Omdat alles digitaal is, heb je bedrijfskritieke functionaliteit in een Excel-spreadsheet op een gedeelde schijf en historische gegevens van klantaankopen op een server waar niemand in de buurt wil komen uit angst om het eigendom ervan te accepteren.
Alleen maar uitzoeken wat de organisatie als geheel weet, kan een complexe taak zijn. Gegevens die door de kieren glippen komt helaas vaak voor.
Pogingen om een gecentraliseerde repository voor het hele bedrijf te creëren, zijn ook gedoemd te mislukken. Verschillende delen van het bedrijf hebben heel verschillende ideeën over wat vanzelfsprekend lijkt. De afdeling Facturering heeft bijvoorbeeld een heel ander idee van wat een klant is dan de afdeling Marketing. Proberen om de gegevens in een gemeenschappelijke mal te laten passen, levert iedereen een slechte dienst op.
De eerste stap is om op organisatieniveau regels voor gegevenseigendom en verantwoordelijkheid te definiëren. Op het meest basale niveau is Facturering eigenaar van het concept van wat een Klant een Achterstallige Betalingsstatus heeft en Marketing bezit de Belangen van een Klant. Het idee is niet om informatiesilo's in de organisatie te creëren, maar om een expliciete erkenning van de verschillende behoeften te hebben. Zodra dat is gebeurd, kunt u de juiste gegevensstroom in de organisatie definiëren.
De factureringsafdeling zal haar visie op een klant beschikbaar stellen aan de rest van de organisatie, terwijl de vrijheid behouden blijft om de vorm binnen de afdeling te veranderen.
Ik gebruik de afdelingen Facturering en Marketing en het begrip klant als voorbeeld om eerst over het bedrijf te kunnen praten, wat belangrijk is. Om het iets technischer te maken, hebben we het over diensten en datastroomcontracten. Ik verwijs je naar het mandaat van Bezos en hoe het Amazon heeft getransformeerd. Het idee is simpel:in plaats van de hele organisatie als één geheel te behandelen, wat bijna onmogelijk is voorbij een bepaalde omvang, behandel het als een stel samenwerkende organisaties die heel duidelijke grenzen tussen hen hebben.
Als je die grenzen eenmaal hebt en je een goed idee hebt van de gegevensstroom in de organisatie, kun je je loodgieters laten komen en dingen doen, zoals het omleiden van de gegevensstroom naar een centrale locatie voor analyse.
Het hebben van dergelijke gepubliceerde interfaces helpt veel als het tijd is om het gedrag van sommige dingen te veranderen. Zolang het externe gedrag hetzelfde is, zijn we vrij om de manier waarop we het verwerken te veranderen.
Over het algemeen is de meest voorkomende reden voor een gebrek aan beveiliging in NoSQL-databases nalatigheid van de operator. Ik wil hier duidelijk twee verschillende kwesties scheiden. We hebben NoSQL-databases zoals Redis, waarvan het beveiligingsmodel expliciet gaat over het draaien in een vertrouwde omgeving. Er zijn enkele rudimentaire beveiligingsfuncties voor Redis, maar de algemene veronderstelling is dat ze alleen bedoeld zijn als derde of vierde verdedigingslinie.
Andere NoSQL-databases, zoals MongoDB, zullen naar verwachting op vijandige netwerken (d.w.z. internet) draaien. Het is echter eenvoudig om MongoDB in te stellen zonder enige beveiliging. Op het eerste gezicht wordt MongoDB geleverd in een beveiligde configuratie, waardoor het alleen naar de lokale machine kan luisteren.
Het allereerste dat u tegenkomt als u op afstand verbinding probeert te maken met MongoDB, is een handleiding waarin wordt uitgelegd hoe u externe toegang tot MongoDB kunt inschakelen, zonder enige beveiliging.
Tot op zekere hoogte is dit nalatigheid van de operator. Maar gezien het enorme aantal MongoDB-databases dat wijd open is gelaten, geloof ik dat dit haarkloven is. In China had een open MongoDB-database meer dan 200 miljoen cv's die wachtten op iemand om mee te snuffelen; een onzorgvuldig opgestelde database heeft de achterdeurtjes van Rusland in meer dan 2000 bedrijven blootgelegd.
Met beveiliging krijg je geen tweede kans.
RavenDB daarentegen zal eenvoudigweg weigeren te draaien in een kwetsbare configuratie. U kunt RavenDB zonder beveiliging op de lokale computer uitvoeren, maar als u probeert de database zonder de juiste beveiliging op internet te zetten, geeft de database een foutmelding waarin wordt uitgelegd hoe u deze correct moet instellen.
We vullen het maximale aantal hiaten in door ervan uit te gaan dat de meeste mensen het minimaal vereiste werk zullen doen en ervoor te zorgen dat wanneer dit gebeurt, de uiteindelijke staat goed is, dus we helpen je verder.
RavenDB draait al meer dan tien jaar in productiesystemen. Enkele van de krachtigste functies die we hebben dateren uit onze oorspronkelijke versie. Het vermogen om dynamisch te reageren op de operationele omgeving ligt het meest voor de hand. RavenDB analyseert continu wat er gaande is (inkomende vragen, serverbelasting, enz.) en reageert daarop door de toewijzing van middelen, interne structuren, enz. zijn eigen zaken.
Toen we aan RavenDB begonnen te werken, wilden we een database die alle voordelen had van een relationele database (snel, ACID, betrouwbaar) maar geen van de nadelen (rigide schema, doorlopend onderhoud, hoge complexiteit).
Toen we begonnen, had ik geen idee hoe groot een taak dit was. In de afgelopen 10 jaar hebben we veel ervaring opgedaan met het bouwen van een database die gewoon kan werken, zonder dat je er veel aandacht aan hoeft te besteden. We hebben RavenDB ontworpen om het ons gemakkelijker te maken om dingen te implementeren met een focus op prestaties. Een recente benchmark op een Raspberry Pi (25 $, 1 GHz, 1 GB RAM) machine klokte ons op meer dan 5.000 schrijfbewegingen per seconde. Op basishardware kunnen we meer dan 100.000 schrijfbewerkingen per seconde en meer dan 1.000.000 leesbewerkingen per seconde halen.
Dat alles bevindt zich op één enkel knooppunt, maar RavenDB is vanaf het begin een gedistribueerde database. Dit betekent dat u in een paar minuten een cluster kunt opzetten (en dit natuurlijk op een veilige manier doet) en beschikt over een zeer beschikbaar en robuust systeem.
We bieden een aantal unieke functies die nergens anders beschikbaar zijn. ETL is ingebouwd in RavenDB en wordt intensief gebruikt door onze klanten om een rijke gegevensstroom mogelijk te maken. Je hoeft geen oplossing aan elkaar te naaien uit verschillende stukken, het zit allemaal in de doos en het werkt gewoon.
De abonnementsfunctie is er een waar ik bijzonder trots op ben. Hiermee kunt u een lopende query uitvoeren. De database geeft u in eerste instantie alle resultaten die aan uw zoekopdracht voldoen. Aangezien u nog steeds bent geabonneerd op deze zoekopdracht, verzendt uw database alle nieuwe documenten die overeenkomen met uw zoekopdracht wanneer ze worden ingevoerd of bijgewerkt om aan die zoekopdracht te voldoen. Hierdoor kunt u met gemak robuuste bedrijfsprocessen en backend-systemen bouwen.
We hebben veel energie gestoken in het maken van RavenDB tot een database met meerdere modellen die documenten, sleutelwaarden, binaire gegevens, gedistribueerde tellers en grafiekquery's kan verwerken.
Je gaat veel meer focus zien op multi-model databases. In plaats van een speciale oplossing te moeten implementeren voor elk type gegevens dat u wilt en de complexe integratie tussen elk van de onderdelen aan te pakken, evolueert de markt naar een geïntegreerde oplossing die een volledige reeks opties in een enkele doos kan bieden.
De cloud zal belangrijker blijven, maar ik zou niet overhaast afscheid nemen van on-premise en gedistribueerde systemen. We zien dat veel van onze klanten de verwerking aan de rand doen en op af en toe aangesloten systemen. Ik denk dat je een verschuiving van focus zult zien, waarbij de datacenters uit het verleden naar de cloud zouden verhuizen, maar veel van de daadwerkelijke verwerking zou aan de rand en op mobiele apparaten worden gedistribueerd. Dat vereist een andere manier van denken over datadistributie en hoe je data naar de cloud pusht en data uit de cloud haalt.
Er zal veel meer nadruk komen te liggen op het soort gedistribueerde gegevensverwerking dat ooit het exclusieve assortiment van de high-end systemen was.
Het wordt zeker heel interessant om te zien hoe het landschap verandert en hoe we de tools en methodologieën bouwen om de steeds grotere complexiteit en functionaliteit aan te kunnen.