Danmarks flotteste huse
fredag, juni 17
Forstyrrende Cloud Start-Ups - Del 1: NimbusDB
At være på Under The Radar (UTR), ser forstyrrende tilstedeværende selskaber og netværk med iværksættere, tænkte ledere, og venture kapitalister er en årlig tradition, at jeg ikke gå glip af. Jeg har blogges om forstyrrende start-ups, jeg så i de foregående år. Den største exit ud af UTR, at jeg har været vidne til hidtil, er Salesforce.com 's 212 millioner dollars erhvervelse af Heroku. Dette indlæg handler om en af de forstyrrende start-ups, som jeg så på UTR i år - NimbusDB.
Jeg mødtes med Barry Morris, den administrerende direktør og grundlægger af NimbusDB ved en reception natten før. Jeg havde lang samtale med ham omkring problemer med arven databaser, NoSQL, og selvfølgelig NimbusDB. Jeg må sige, at efter lang tid, har jeg set et firma anvender alle de rigtige design principper for at løse et kronisk problem - hvordan kan du gøre SQL databaser skala, således at de ikke sutte.
Et af de vigtigste spørgsmål med arven relationsdatabaser er, at de aldrig var designet til at skalere ud til at begynde med. En række NoSQL løsninger rettet omfang-out spørgsmål, men det største problem med en NoSQL er, at NoSQL ikke er SQL. Det er derfor, jeg var ophidset, når jeg så, hvad NimbusDB har at byde på: det er en SQL-database på overfladen, men har radikalt moderne arkitektur nedenunder, der udnytter MapReduce at dele og erobre forespørgsler, BitTorrent til messaging, og Dynamo for vedholdenhed.
NimbusDB arkitektur isolater transaktioner fra lager og bruger asynkron messaging på tværs af knudepunkter - et ikke-blokerende atom forpligte protokol - for at få vandret skalerbarhed. På applikationslaget, understøtter det \ "mest \" af SQL 99 funktioner og kræver ikke, at udviklerne at re-lære eller re-kode. Arkitekturen indebærer ikke nogen form for sharding og knuderne kan skalaen på enhver vare maskine på en række forskellige operativsystemer. Dette eliminerer en eksplicit behov for en særskilt hot back-up, da enhver og alle knuder fungere som en levende database i en zone. Dette gør NimbusDB en altid levende system, som også løser et stort problem med traditionelle relationelle databaser - høj tilgængelighed. Det er en kun indsætte databasen og det versioner hvert enkelt atom / rekord. Sådan er det opnår MVCC så godt. De data er komprimeret på en disk, og er tilgængelig fra en in-memory node.
Jeg spurgte Barry om brug NimbusDB som en analytisk database, og han sagde, at databasen er i øjeblikket ikke optimeret til analytiske forespørgsler, men han ikke se, hvorfor det ikke kan indstilles og konfigureres som en analytisk database, da den iboende arkitekturen ikke rigtig nødt til at ændre. Men under hans pitch, han nævner, at NimbusDB kan have udfordringer med tunge læser og tunge skriver. Jeg tror personligt, at løse et problem med analytisk forespørgsel på store mængder af data er en meget større udfordring i skyen på grund af den iboende distribuerede karakter af skyen. Tilsvarende opbygge et heavy-sæt er lige så vanskelig. Men de fleste systemer passer et sted midt imellem. Dette kunne være en stor målmarked for NimbusDB.
Jeg har ikke spillet rundt med databasen, men jeg har til hensigt at gøre det. På en summarisk, synes det at trodse den fælles landbrugspolitik teorem. Barry synes at være uenig med mig. Grundlæggerne af NimbusDB har stor baggrunde. Barry var administrerende direktør for Iona og StreamBase og har stor erfaring med opbygning og førende teknologivirksomheder. Hvis NimbusDB kan udføre baseret på de principper, den er designet til, vil dette være et enormt gennembrud.
Som en generel tendens, ser jeg en klar overgang, hvor folk endelig enige i, at SQL er stadig den foretrukne interface, men det vigtigste er at nytænke den underliggende arkitektur.
Update: Efter jeg udgivet stillingen, rejste Benjamin Block bekymringer omkring NimbusDB ikke at få den fælles landbrugspolitik teorem. Som jeg nævnte i posten, jeg havde også samme problem, men jeg ville give dem fordel af tvivl for nu og se den feedback som produktet går i beta.
Tjek deres dias og præsentation:
Dias:
Præsentation:
Jeg mødtes med Barry Morris, den administrerende direktør og grundlægger af NimbusDB ved en reception natten før. Jeg havde lang samtale med ham omkring problemer med arven databaser, NoSQL, og selvfølgelig NimbusDB. Jeg må sige, at efter lang tid, har jeg set et firma anvender alle de rigtige design principper for at løse et kronisk problem - hvordan kan du gøre SQL databaser skala, således at de ikke sutte.
Et af de vigtigste spørgsmål med arven relationsdatabaser er, at de aldrig var designet til at skalere ud til at begynde med. En række NoSQL løsninger rettet omfang-out spørgsmål, men det største problem med en NoSQL er, at NoSQL ikke er SQL. Det er derfor, jeg var ophidset, når jeg så, hvad NimbusDB har at byde på: det er en SQL-database på overfladen, men har radikalt moderne arkitektur nedenunder, der udnytter MapReduce at dele og erobre forespørgsler, BitTorrent til messaging, og Dynamo for vedholdenhed.
NimbusDB arkitektur isolater transaktioner fra lager og bruger asynkron messaging på tværs af knudepunkter - et ikke-blokerende atom forpligte protokol - for at få vandret skalerbarhed. På applikationslaget, understøtter det \ "mest \" af SQL 99 funktioner og kræver ikke, at udviklerne at re-lære eller re-kode. Arkitekturen indebærer ikke nogen form for sharding og knuderne kan skalaen på enhver vare maskine på en række forskellige operativsystemer. Dette eliminerer en eksplicit behov for en særskilt hot back-up, da enhver og alle knuder fungere som en levende database i en zone. Dette gør NimbusDB en altid levende system, som også løser et stort problem med traditionelle relationelle databaser - høj tilgængelighed. Det er en kun indsætte databasen og det versioner hvert enkelt atom / rekord. Sådan er det opnår MVCC så godt. De data er komprimeret på en disk, og er tilgængelig fra en in-memory node.
Jeg spurgte Barry om brug NimbusDB som en analytisk database, og han sagde, at databasen er i øjeblikket ikke optimeret til analytiske forespørgsler, men han ikke se, hvorfor det ikke kan indstilles og konfigureres som en analytisk database, da den iboende arkitekturen ikke rigtig nødt til at ændre. Men under hans pitch, han nævner, at NimbusDB kan have udfordringer med tunge læser og tunge skriver. Jeg tror personligt, at løse et problem med analytisk forespørgsel på store mængder af data er en meget større udfordring i skyen på grund af den iboende distribuerede karakter af skyen. Tilsvarende opbygge et heavy-sæt er lige så vanskelig. Men de fleste systemer passer et sted midt imellem. Dette kunne være en stor målmarked for NimbusDB.
Jeg har ikke spillet rundt med databasen, men jeg har til hensigt at gøre det. På en summarisk, synes det at trodse den fælles landbrugspolitik teorem. Barry synes at være uenig med mig. Grundlæggerne af NimbusDB har stor baggrunde. Barry var administrerende direktør for Iona og StreamBase og har stor erfaring med opbygning og førende teknologivirksomheder. Hvis NimbusDB kan udføre baseret på de principper, den er designet til, vil dette være et enormt gennembrud.
Som en generel tendens, ser jeg en klar overgang, hvor folk endelig enige i, at SQL er stadig den foretrukne interface, men det vigtigste er at nytænke den underliggende arkitektur.
Update: Efter jeg udgivet stillingen, rejste Benjamin Block bekymringer omkring NimbusDB ikke at få den fælles landbrugspolitik teorem. Som jeg nævnte i posten, jeg havde også samme problem, men jeg ville give dem fordel af tvivl for nu og se den feedback som produktet går i beta.
Tjek deres dias og præsentation:
Dias:
Præsentation:
posted by Forfatteren at fredag, juni 17, 2011
0 Comments:
Send en kommentar
<< Home