Nyligen fick jag tillfälle att intervjua Oren Eini, VD och grundare av Hibernating Rhinos som tillhandahåller RavenDB, en dokumentorienterad NoSQL med öppen källkod designad speciellt för .NET/Windows-plattformen.
Oren har mer än 20 års erfarenhet av utvecklingsvärlden med stort fokus på Microsoft och .NET ekosystemet. Oren har blivit erkänd som en av Microsofts mest värdefulla proffs sedan 2007 och är också författare till "DSLs in Boo:Domain Specific Languages in .NET." Han talar ofta på industrikonferenser som DevTeach, JAOO, QCon, Oredev, NDC, Yow! och Progressive.NET.
Du kan läsa hela intervjun nedan:
1. I denna digitaliserade värld har data blivit en av de mest värdefulla tillgångarna. och därför är hur data lagras, organiseras och processer avgörande för företagets framgång. I takt med att företag bombarderas med mer och mer data, blir datalagring och analys mer komplex. Kan du berätta för oss några av de vanliga utmaningarna för databashantering som företag står inför idag?
Den primära frågan, tror jag, är bara själva storleken på data. Jag pratar inte nödvändigtvis om Big Data och komplexiteten i att hantera en datamängd mätt i hundratals terabyte. Jag pratar om antalet databaser och datasilos som du har i en organisation. Eftersom allt är digitalt har du affärskritisk funktionalitet som finns i ett Excel-kalkylblad på en delad enhet och historiska data om kundköp på en server som ingen vill gå i närheten av av rädsla för att acceptera äganderätten till.
Att bara ta reda på vad organisationen som helhet vet kan vara en komplex uppgift. Det är tyvärr vanligt med data som glider igenom stolarna.
Försök att skapa ett centraliserat arkiv för hela företaget är också dömda att misslyckas. Olika delar av företaget har väldigt olika uppfattningar om vad som verkar självklart. Till exempel har faktureringsavdelningen en helt annan uppfattning om vad en kund är än marknadsföringsavdelningen. Att försöka få data att passa en vanlig form gör alla en otjänst.
2. Hur går vi till väga för att övervinna dessa utmaningar? Tycker du att det är första steget att välja en effektiv databashanteringslösning? Och varför?
Det första steget är att definiera, på organisationsnivå, regler för dataägande och ansvar. På den mest grundläggande nivån äger Billing konceptet av vad en kund än har en försenad betalningsstatus och marknadsföring äger kundens intressen. Tanken är inte att skapa silos av information i organisationen utan att ha ett uttryckligt erkännande av de olika behoven. När det är gjort kan du definiera korrekt dataflöde i organisationen.
Faktureringsavdelningen kommer att göra sin syn på en kund tillgänglig för resten av organisationen samtidigt som den behåller friheten att ändra hur den är utformad inom avdelningen.
Jag använder fakturerings- och marknadsföringsavdelningar och föreställningen om en kund som detta exempel för att kunna prata om verksamheten först, vilket är viktigt. För att flytta det till ett lite mer tekniskt sätt pratar vi om tjänster och dataflödeskontrakt. Jag hänvisar dig till Bezos mandat och hur det förvandlade Amazon. Tanken är enkel:istället för att behandla hela organisationen som en helhet, vilket är nästan omöjligt förbi en viss storlek, behandla den som ett gäng samarbetsorganisationer som har mycket tydliga gränser mellan sig.
När du väl har dessa gränser, och du har en bra uppfattning om dataflödet i organisationen, kan du låta dina rörmokare komma in och göra saker åt det som att omdirigera dataflödet till en central plats för analys.
Att ha sådana publicerade gränssnitt hjälper mycket när det är dags att ändra hur vissa saker beter sig. Så länge det yttre beteendet är detsamma är vi fria att ändra hur vi bearbetar det.
3. Under de senaste åren har företag antagit olika typer av NoSQL-databaser. I takt med att allt känsligare data lagras i NoSQL-databaser har säkerhetsproblemen blivit en växande oro. Vad tycker du om detta?
I stort sett är den vanligaste orsaken till bristande säkerhet i NoSQL-databaser operatörsvårdslöshet. Jag vill tydligt skilja två distinkta frågor här. Vi har NoSQL-databaser som Redis, vars säkerhetsmodell uttryckligen handlar om att köra i en pålitlig miljö. Det finns några rudimentära säkerhetsfunktioner för Redis, men det allmänna antagandet är att de endast är avsedda att tjäna som den tredje eller fjärde försvarslinjen.
Andra NoSQL-databaser, som MongoDB, förväntas köras på fientliga nätverk (d.v.s. Internet). Det är dock enkelt att konfigurera MongoDB utan någon som helst säkerhet. På första sidan kommer MongoDB i en säker konfiguration, så att den bara kan lyssna på den lokala maskinen.
Det allra första du hittar när du försöker ansluta till MongoDB på distans är en guide som förklarar hur du aktiverar fjärråtkomst till MongoDB, utan någon som helst säkerhet.
Till viss del är detta operatörsvårdslöshet. Men med tanke på det stora antalet MongoDB-databaser som lämnas vidöppna, tror jag att detta spricker hårstrån. I Kina hade en öppen MongoDB-databas över 200 miljoner CV:n som bara väntade på att någon skulle snoka; en vårdslöst konfigurerad databas har avslöjat Rysslands bakdörrar i över 2 000 företag.
Med säkerhet får du inte en andra chans.
RavenDB, däremot, kommer helt enkelt att vägra att köra i en sårbar konfiguration. Du kan köra RavenDB utan säkerhet på den lokala maskinen, men om du försöker exponera databasen för Internet utan lämpliga skyddsåtgärder kommer databasen att returnera ett felmeddelande som förklarar hur du ska ställa in den på rätt sätt.
Vi fyller i det maximala antalet luckor genom att anta att de flesta människor kommer att göra det minsta arbete som krävs och ser till att när detta händer är sluttillståndet bra, så vi har dig täckt.
4. På tal om RavenDB, kan du nämna några av de viktigaste funktionerna som tillför mer värde till kunderna? Hur sticker RavenDB ut bland andra leverantörer när det gäller funktioner och prestanda?
RavenDB har körts i produktionssystem i över ett decennium. Några av de mest kraftfulla funktionerna har vi daterat tillbaka till vår ursprungliga version. Förmågan att reagera dynamiskt på den operativa miljön är den mest uppenbara. RavenDB analyserar kontinuerligt vad som pågår (inkommande frågor, serverbelastning etc) och reagerar på det genom att ändra resursallokering, interna strukturer etc. Tanken är att istället för att ha en heltids-DBA barnvakt din databas så kan din databas hantera sina egna angelägenheter.
När vi började arbeta med RavenDB ville vi ha en databas som hade alla fördelar med en relationsdatabas (snabb, ACID, pålitlig) men ingen av nackdelarna (stelt schema, löpande underhåll, hög komplexitet).
När vi började hade jag ingen aning om hur stor uppgift det här var. Under de senaste 10 åren har vi fått mycket erfarenhet av att bygga en databas som bara kan fungera, utan att du behöver ägna mycket uppmärksamhet åt den. Vi designade RavenDB för att göra det lättare för oss att implementera saker med fokus på prestanda. Ett nyligen riktmärke på en Raspberry Pi-maskin (25$, 1 GHz, 1 GB RAM) klockade oss till över 5 000 skrivningar per sekund. På råvaruhårdvara kan vi nå över 100 000 skrivningar per sekund och över 1 000 000 läsningar per sekund.
Allt detta är på en enda nod, men RavenDB har varit en distribuerad databas från början. Detta innebär att du kan sätta upp ett kluster på några minuter (och göra det på ett säkert sätt, naturligtvis) och ha ett mycket tillgängligt och robust system.
Vi erbjuder några unika funktioner som inte är tillgängliga någon annanstans. ETL är inbyggt i RavenDB och används flitigt av våra kunder för att möjliggöra ett rikt dataflöde. Du behöver inte sy ihop en lösning från olika delar, det är okej där i lådan och det fungerar bara.
Prenumerationsfunktionen är en som jag är särskilt stolt över. Det låter dig utföra en pågående fråga. Databasen kommer initialt att ge dig alla resultat som matchade din fråga. Eftersom du fortfarande prenumererar på den här frågan kommer din databas att skicka över alla nya dokument som matchar din fråga allt eftersom de skrivs in eller uppdateras för att passa den frågan. Detta gör att du enkelt kan bygga robusta affärsprocesser och backend-system.
Vi har fokuserat mycket på att göra RavenDB till en multimodelldatabas som kan hantera dokument, nyckel-värden, binära data, distribuerade räknare och graffrågor.
5. Och slutligen, vad är framtiden för databashanteringssystem? Hur kommer det att förändras under de kommande 3-4 åren?
Du kommer att se mycket mer fokus på multimodelldatabaser. Istället för att behöva distribuera en dedikerad lösning för varje typ av data du vill ha och hantera den komplexa integrationen mellan var och en av delarna, går marknaden över till en integrerad lösning som kan erbjuda en hel uppsättning alternativ i en enda låda.
Molnet kommer att fortsätta att vara viktigare, men jag skulle inte ha bråttom att säga adjö till lokala och distribuerade system. Vi ser många av våra kunder göra bearbetning på kanten och på ibland uppkopplade system. Jag tror att du kommer att se en förskjutning av fokus, där datacenter från det förflutna skulle flytta till molnet, men mycket av den faktiska behandlingen skulle distribueras i kanten och på mobila enheter. Det kräver ett annat sätt att tänka på datadistribution och hur man skickar data till molnet och hämtar data från molnet.
Det kommer att läggas mycket mer tonvikt på den typ av distribuerad databehandling som en gång var det exklusiva utbudet av avancerade system.
Det kommer verkligen att bli väldigt intressant att se hur landskapet förändras och hur vi bygger verktyg och metoder för att hantera ständigt växande komplexitet och funktionalitet.