Hvis du var en investor, ville du give en mellemstor start omfattet fuldt ud af ingeniører og sportslige et open source-produkt $11,5 mio til at forfølge en enestående vej midt i hård konkurrence? Du kan, hvis det var i den varmeste område af data, der blev grundlagt af en tidligere Medarbejder med dyb viden om emnet, og havde et par Fortune 500 kunder allerede.
Det er, hvad Redpoint Ventures, med deltagelse fra tidligere investorer Bain Capital Ventures, Blackbird Ventures, Grok Ventures og Airtree Ventures bare gjorde for Dgraph, Manish Jain ‘ s open source-graph database start. I løbet af sin tid på Google, Jain førte den viden graf, der betjener systemet indsats.
Selv om vi normalt ikke dække finansiering runder, dette var en mulighed for at forbinde med Jain. Dgraph og Jain begge har en slags understrøm ry i graf-database verden, og den samtale, der ikke skuffe.
Graf databaser og Dgraph
Første off, selv hvis du ikke har været efter os, (vi har været i graf-database plads tidligere end de fleste), har du måske bemærket, når Gartner orakler talte graf, der tidligere på året:
“Anvendelsen af grafen behandling og graf Databasestyresystemer vil vokse 100 procent om året gennem 2022 løbende at fremskynde data forberedelse og muliggøre mere kompleks og adaptive data videnskab.
Grafen data butikker kan være en effektiv model, udforske og søge data med komplekse sammenhænge på tværs af data siloer, men behovet for specialiserede kompetencer har begrænset deres vedtagelse til dato.
Graf analytics vil vokse i de kommende år på grund af behovet for at stille komplekse spørgsmål på tværs af komplekse data, og der er ikke altid praktisk eller endog muligt på skalere ved hjælp af SQL-forespørgsler”.
Amen til det, og selv hvis du ikke tage til efterretning, VCs tilsyneladende gjorde. Samtalen med Jain startede vi taler penge. Før i dag, Dgraph havde rejst i alt $3M i frø, og pre-seed-runder. Jain skøn i denne runde En finansiering, der skal give dem en start-og landingsbane til 2022. Afhængigt af, hvordan holdet vokser, det er, som var en god måde at samle op på samtalen.
Grafen er fastsat for vækst, fordi det kan hjælpe model kritisk use case tilfælde i den virkelige verden. Du hørte det her først, nu Gartners af verden er at samle op på dette. Billede: AWS
I øjeblikket, Dgraph har noget, som en halv snes ingeniører fordelt på 2 lokationer – San Francisco og Bangalore. Det er herunder Jain, der er en meget hands-on administrerende DIREKTØR. Planen er, at omtrent dobbelt holdet indtil slutningen af året, men det store spørgsmål der er “på hvilken måde”.
Selvom vi kan forholde sig til, hvordan alle-ingeniør-teams kan få masser af arbejde, der udføres i en ikke-fluff-bare-stuff måde, der er et oplagt problem med denne tilgang: hvordan vil folk i virksomheden komme til at købe dit legetøj uden salg, markedsføring og lignende?
Gøre de har lige snuble på det i naturen, og de begynder at bruge det, så kan lide det så meget, at de beslutter de har brug for til at betale for virksomheden version, og kommer og banker på din dør? Det er temmelig meget, hvordan det har været at arbejde for Dgraph, i henhold til Jain.
Dgraph, Jain sagde, har været bæredygtigt, og har et par virksomhedens kunder, selvom navne kan ikke blive offentliggjort. Jain nævner målet er at rampe op-team og bygge en gentagelig salg proces, men den hårde kerne udvikler-centreret tilgang vil ikke ændre sig. Så det er værd at tjekke, hvad er det, der bliver Dgraph salg uden et salgsteam.
Dgraph måde
Første off, er den indlysende: Dgraph er open source, så alle kan bare hente og begynde at bruge det med det samme. På dette punkt, selv om der er Start-og Enterprise-versioner af open source software, er der ikke meget forskel i form af funktioner, undtagen (afgørende) at støtte og klynge størrelse. Det handler om at ændre selv, med Dgraph prioritering af udvikling af Virksomhedens funktioner.
En anden tast, valg af Dgraph er at opfylde hovedparten af udviklere at bygge applikationer, hvor de er. Og der, i henhold til Jain, er i JSON og GraphQL land. Selvom GraphQL komme til at være, hvor JSON allerede er — en de facto standard — der er et problem: GraphQL, i hvad der er formentlig en af de mest forvirrende misnomers vi har set, er IKKE en graf forespørgsel sprog.
Som en påmindelse, i graf-database, der er et par lejre og mere forespørgsel sprog. RDF graf databaser bruge SPARQL, som gerne RDF er en W3C standard. Ejendom graf databaser er ikke standardiseret, og kommer med en lang række forespørgsel sprog. Mest populære blandt dem er Cypher, åbne indkøbt af Neo4j, og Gremlin, en del af open source Apache Tinkerpop projekt.
Selvom Jain sagde Dgraph kan tilføje understøttelse til Cypher og/eller Gremlin på et tidspunkt, han var ubøjelig, — han er ikke særlig glad for dem. Så i stedet for at vedtage en af disse, Dgraph udvidet GraphQL til rent faktisk at gøre det arbejde med grafer, navngive det GraphQL+. Forvirrende, ingen tvivl om det. Og det bliver værre.
Dgraph er en graf-database, der strejfer fra konventionen i dette rum, og ønsker at løse et større marked.
For nylig W3C har iværksat en proces for at standardisere ejendom graf data model og query sprog, også. Men det er kun begyndelsen, dette kan føre til, at 2 store grafdatabase lejre (RDF og ejendom graf) med fuld interoperabilitet mellem tilbud i hver lejr, potentielt også mellem lejre til en vis grad. Hvorfor ville Dgraph ønsker at være den ulige en ud? Vil de ikke drage fordel af standardisering, også?
Den måde at gøre dette på ville være at have GraphQL+ udvidelser, der er vedtaget af GraphQL. Når du bliver spurgt, Jain nævnte han gjorde drøfte dette med Lee Byron, der er krediteret med co-creating GraphQL på Facebook. Byron ikke har udtrykt nogen interesse i dette, og Jain anerkendt at få GraphQL+ standardiseret som en del af GraphQL er ikke meget sandsynligt. Der synes ikke at genere ham meget, dog.
Selvom det er klart, at det at have en standard i SQL har været medvirkende i en relationel database vedtagelse, Jain sagde, at han ikke ser meget begejstring omkring graf-database standarder. Han gik et skridt videre og rent faktisk at nævne, at han ikke selv kan virkelig ikke se Dgraph som en graf-database, men snarere som et generelt formål database med en graf back-end.
Noget som StackOverflow, Jain sagde, kunne meget vel være bygget på Dgraph. Dette er grunden til, Jain er at placere sin satsning på GraphQL+, og er egentlig ikke opsat på at skubbe Dgraph som en graf-database, men snarere som en “stærk løsning til ansøgning bygning”.
En enestående vej til herlighed?
Det er alt sammen fint og godt, men Dgraph er ikke den eneste database, der understøtter GraphQL – ikke engang den eneste graf-database til at gøre dette. Fauna og Neo4j GRAND stakken kommer til at tænke på, og listen over databaser udnytte GraphQL synes at vokse. Så, hvis du ønsker en database med GraphQL støtte, hvorfor vælge Dgraph?
Fordi, som per Tybirk, Dgraph er den hurtigste og mere skalerbar mulighed: “Dgraph er designet til at udføre lige så godt på grafen stil slutter og traversals og SQL-stil vælger, giver den eneste virkelig skalerbar generelle formål graf-database til rådighed i dag.”
Produkter, der lægger vægt ydeevne og skalerbarhed på denne måde typisk sørg for, at de cirkulere et par benchmarks for at sikkerhedskopiere deres krav. Selvom Jain var ikke genert af citerer benchmarks er udført af kunder, hævder, at de viste Dgraph at være 10 gange eller mere hurtigere end andre muligheder (navns nævnelse, som vi ikke), er der intet at vise for denne på dette tidspunkt. Jain sagde Dgraph kan frigive nogle benchmarks i fremtiden, med de sædvanlige forbehold omkring benchmark kompleksitet og pålidelighed.
Dgraph er carving ud en enestående sti for sig selv i den voksende graf-database. Om det kommer til at blive en succes, vil tiden vise
Getty Images/iStockphoto
Dgraph prale “low-latency vilkårlig dybde slutter og traversals, Jepsen testet distribuerede transaktioner, data sharding og synkron replikering støtte og et fleksibelt skema”. Jain sagde: dette er, hvad folk søger efter i en database, og planen er at bruge midler til at fuldføre Dgraph af virksomhedens funktioner.
Jain også sagt, at de vil bygge en Dgraph managed service til at køre på alle de skyer, der bygger på deres eksisterende støtte til Kubernetes. I form af strategi, vil de prioritere greenfield-projekter, og de vil hellere få et stykke af den (meget større) relationelle og NoSQL-database-markedet, end at gå efter at lederne i graf-database.
Meget af ovenstående ikke kun mening, men også lyder ret imponerende. Vi gør dog, at opretholde en sund skepsis. Dgraph gør nogle krav, som kræver selv-kontrol, og vi ved ikke, hvor mange mennesker kan / vil gøre dette. Plus, du udfører på, at ental vej til herlighed, kan være en ordentlig mundfuld for en start på det tidspunkt, hvor Dgraph er i øjeblikket.
Dgraph er absolut værd at holde et øje på. Om sit enestående vej til grafen herlighed vil vise sig at være den korteste en, er endnu uvist.
Relaterede Emner:
Digital Transformation
Robotteknologi
Tingenes Internet
Innovation
Virksomhedens Software
CXO