For nylig havde jeg lejlighed til at interviewe Oren Eini, CEO og grundlægger af Hibernating Rhinos, som leverer RavenDB, en open source dokumentorienteret NoSQL designet specielt til .NET/Windows-platformen.
Oren har mere end 20 års erfaring i udviklingsverdenen med stort fokus på Microsoft og .NET økosystemet. Anerkendt som en af Microsofts mest værdifulde fagfolk siden 2007, er Oren også forfatter til "DSLs in Boo:Domain Specific Languages in .NET." Han taler ofte ved branchekonferencer som DevTeach, JAOO, QCon, Oredev, NDC, Yow! og Progressive.NET.
Du kan læse hele interviewet nedenfor:
1. I denne digitaliserede verden er data blevet et af de mest værdifulde aktiver. og derfor er måden data lagres, organiseres og behandles på afgørende for virksomhedens succes. Efterhånden som virksomheder bliver bombarderet med flere og flere data, bliver datalagring og analyser mere komplekse. Kan du fortælle os nogle af de almindelige udfordringer for databasestyring, som virksomheder står over for i dag?
Det primære problem, tror jeg, er blot størrelsen af dataene. Jeg taler ikke nødvendigvis om Big Data og kompleksiteten ved at administrere et datasæt målt i hundredvis af terabyte. Jeg taler om antallet af databaser og datasiloer, som du har i en organisation. Da alt er digitalt, har du forretningskritisk funktionalitet, der ligger i et Excel-regneark på et fællesdrev og historiske data om kundekøb på en server, som ingen vil nærme sig af frygt for at acceptere ejerskab på.
Bare det at finde ud af, hvad organisationen som helhed ved, kan være en kompleks opgave. Data, der glider igennem sprækkerne, er desværre almindeligt.
Forsøg på at skabe et centraliseret lager for hele virksomheden er også dømt til at mislykkes. Forskellige dele af virksomheden har meget forskellige ideer om, hvad der tilsyneladende er indlysende. For eksempel har Billing-afdelingen en meget anden opfattelse af, hvad en kunde er, end marketingafdelingen. At forsøge at få dataene til at passe til en almindelig form gør alle en bjørnetjeneste.
2. Hvordan skal vi overkomme disse udfordringer? Synes du, at valget af en effektiv databasestyringsløsning er det første skridt? Og hvorfor?
Det første skridt er at definere, på organisationsniveau, dataejerskab og ansvarsregler. På det mest basale niveau ejer Billing konceptet af, hvad end en kunde er i en forsinket betaling-status, og Marketing ejer en kundes interesser. Tanken er ikke at skabe siloer af information i organisationen, men at have en eksplicit anerkendelse af de forskellige behov. Når det er gjort, kan du definere korrekt dataflow i organisationen.
Faktureringsafdelingen vil gøre sit syn på en kunde tilgængeligt for resten af organisationen, samtidig med at den bevarer friheden til at ændre, hvordan den er formet inde i afdelingen.
Jeg bruger fakturerings- og marketingafdelinger og forestillingen om en kunde som dette eksempel for at kunne tale om forretningen først, hvilket er vigtigt. For at flytte det til en lidt mere teknisk måde, taler vi om tjenester og dataflowkontrakter. Jeg vil henvise dig til Bezos’ mandat og hvordan det forvandlede Amazon. Ideen er enkel:I stedet for at behandle hele organisationen som en enkelt helhed, hvilket er næsten umuligt forbi en vis størrelse, skal du behandle det som en flok samarbejdende organisationer, der har meget klare grænser mellem dem.
Når først du har disse grænser, og du har en god idé om strømmen af data i organisationen, kan du få dine blikkenslagere til at komme ind og gøre ting ved det som at omdirigere datastrømmen til et centralt sted til analyse.
At have sådanne offentliggjorte grænseflader hjælper meget, når tiden kommer til at ændre, hvordan nogle ting opfører sig. Så længe den ydre adfærd er den samme, er vi frie til at ændre, hvordan vi behandler den.
3. I de senere år har virksomheder taget forskellige typer NoSQL-databaser til sig. Med stadig mere følsomme data, der lagres i NoSQL-databaser, er sikkerhedsproblemer blevet voksende bekymringer. Hvad er din holdning til dette?
I det store og hele er den mest almindelige årsag til manglende sikkerhed i NoSQL-databaser operatørens uagtsomhed. Jeg vil klart adskille to adskilte spørgsmål her. Vi har NoSQL-databaser som Redis, hvis sikkerhedsmodel eksplicit handler om at køre i et betroet miljø. Der er nogle rudimentære sikkerhedsfunktioner for Redis, men den generelle antagelse er, at de kun er beregnet til at tjene som den tredje eller fjerde forsvarslinje.
Andre NoSQL-databaser, såsom MongoDB, forventes at køre på fjendtlige netværk (dvs. internettet). Det er dog nemt at konfigurere MongoDB uden nogen som helst sikkerhed. Umiddelbart kommer MongoDB i en sikret konfiguration, så den kun kan lytte til den lokale maskine.
Den allerførste ting, du finder, når du forsøger at oprette forbindelse til MongoDB eksternt, er en guide, der forklarer, hvordan du aktiverer fjernadgang til MongoDB, uden nogen som helst sikkerhed.
Til en vis grad er dette operatørens uagtsomhed. Men i betragtning af det store antal MongoDB-databaser, der er efterladt på vid gab, tror jeg, at dette er ved at splitte hår. I Kina havde en åben MongoDB-database over 200 millioner CV'er, der bare ventede på, at nogen skulle snuse; en skødesløst opsat database har afsløret Ruslands bagdøre i over 2.000 virksomheder.
Med sikkerhed får du ikke en ny chance.
RavenDB derimod vil simpelthen nægte at køre i en sårbar konfiguration. Du kan køre RavenDB uden sikkerhed på den lokale maskine, men hvis du forsøger at udsætte databasen for internettet uden de rette sikkerhedsforanstaltninger, vil databasen returnere en fejl, der forklarer, hvordan du skal konfigurere den korrekt.
Vi udfylder det maksimale antal huller ved at antage, at de fleste mennesker vil udføre den mindste mængde arbejde, der kræves, og sørger for, at når dette sker, er den endelige tilstand god, så vi har dig dækket.
4. Taler om RavenDB, kan du nævne nogle af de vigtigste funktioner, der tilføjer mere værdi til kunderne? Hvordan skiller RavenDB sig ud blandt andre leverandører med hensyn til funktioner og ydeevne?
RavenDB har kørt i produktionssystemer i over et årti. Nogle af de mest kraftfulde funktioner, vi har dateret tilbage til vores originale version. Evnen til at reagere dynamisk på det operationelle miljø er den mest oplagte. RavenDB analyserer løbende, hvad der foregår (indkommende forespørgsler, serverbelastning osv.) og reagerer på det ved at ændre ressourceallokering, interne strukturer osv. Tanken er, at i stedet for at have en fuldtids DBA babysitte din database, kan din database administrere sine egne anliggender.
Da vi begyndte at arbejde på RavenDB, ønskede vi en database, der havde alle fordelene ved en relationel database (hurtig, ACID, pålidelig), men ingen af ulemperne (stift skema, løbende vedligeholdelse, høj kompleksitet).
Da vi startede, anede jeg ikke, hvor stor en opgave det her var. I løbet af de sidste 10 år har vi fået en masse erfaring med at opbygge en database, der bare kan fungere, uden at du skal være særlig opmærksom på den. Vi har designet RavenDB for at gøre det nemmere for os at implementere ting med fokus på ydeevne. Et nyligt benchmark på en Raspberry Pi (25$, 1 GHz, 1 GB RAM) maskine gav os over 5.000 skrivninger i sekundet. På råvarehardware kan vi nå over 100.000 skrivninger i sekundet og over 1.000.000 læsninger i sekundet.
Alt dette er på en enkelt node, men RavenDB har været en distribueret database fra starten. Det betyder, at du kan oprette en klynge på få minutter (og gøre det på en sikker måde, selvfølgelig) og have et yderst tilgængeligt og robust system.
Vi tilbyder nogle unikke funktioner, som ikke er tilgængelige andre steder. ETL er indbygget i RavenDB og er flittigt brugt af vores kunder for at muliggøre rigt dataflow. Du behøver ikke at sy en løsning sammen fra forskellige stykker, det er okay der i kassen, og det virker bare.
Abonnementsfunktionen er en, som jeg er særlig stolt af. Det giver dig mulighed for at udføre en løbende forespørgsel. Databasen vil i første omgang give dig alle de resultater, der matchede din forespørgsel. Da du stadig abonnerer på denne forespørgsel, sender din database alle nye dokumenter, der matcher din forespørgsel, efterhånden som de indtastes eller opdateres, så de passer til forespørgslen. Dette giver dig mulighed for nemt at bygge robuste forretningsprocesser og backend-systemer.
Vi har fokuseret meget på at gøre RavenDB til en multi-model database, der er i stand til at håndtere dokumenter, nøgleværdier, binære data, distribuerede tællere og grafforespørgsler.
5. Og endelig, hvad er fremtiden for databasestyringssystemer? Hvordan kommer det til at ændre sig i de næste 3-4 år?
Du vil se meget mere fokus på multi-model databaser. I stedet for at skulle implementere en dedikeret løsning for hver type data, du ønsker, og håndtere den komplekse integration mellem hver af brikkerne, bevæger markedet sig til en integreret løsning, der kan tilbyde en komplet suite af muligheder i en enkelt boks.
Skyen vil fortsat være vigtigere, men jeg ville ikke skynde mig at sige farvel til on-premise og distribuerede systemer. Vi ser mange af vores kunder udføre behandling på kanten og på lejlighedsvis tilsluttede systemer. Jeg tror, du vil se et fokusskifte, hvor fortidens datacentre ville flytte til skyen, men meget af den faktiske behandling ville blive distribueret i kanten og på mobile enheder. Det kræver en anden måde at tænke på datadistribution og hvordan man skubber data til skyen og trækker data fra skyen.
Der vil blive lagt meget mere vægt på den form for distribueret databehandling, der engang var det eksklusive udvalg af avancerede systemer.
Det bliver bestemt meget interessant at se, hvordan landskabet ændrer sig, og hvordan vi bygger værktøjer og metoder til at håndtere stadigt voksende kompleksitet og funktionalitet.