Av Techopedia Staff, 11. mai 2016
Takeaway: Vert Rebecca Jozwiak diskuterer fremskritt innen databasearkitektur og lagring med Dez Blanchfield, Robin Bloor og Brian Bulkowski.
Du er ikke logget inn for øyeblikket. Logg inn eller registrer deg for å se videoen.
Rebecca Jozwiak: Mine damer og herrer, Hei og velkommen til Hot Technologies i 2016. I dag er vi, "Å eksponere differensiering: En ny æra av skalerbar infrastruktur kommer." Jeg går inn for Eric Kavanagh i dag. Jeg er Rebecca Jozwiak, din ydmyke vert fra styregruppen mens Eric er på Jamaica. Bra for han.
Så som det har vært i flere tiår, er dette året varmt, selv om teknologien uten tvil beveger seg i et tempo som overgår Moores lov, og hva gjør organisasjoner for å holde følge? De leter etter hva som er raskt, og skala, vil jeg hevde, er sannsynligvis noe av det viktigste når vi tenker på databaser. Og selvfølgelig har vi alternativene til den vanlige relasjonen, nå har vi vår NoSQL, vi har vår kolonnelager, vi har våre grafidatabaser, våre RDF-databaser, men egentlig, det virksomheter ser etter er skala, er parallellitet og er raskt .
Nå var tradisjonelle arkitekturer slags basert på den relasjonsmodellen. Men hvis du ser på de fleste nettvirksomheter som har dukket opp de siste tre, fem, ti årene, er det ikke modellene de bruker for infrastrukturen. De bruker en annen, en parallell arkitektur, de skalerer og de er raske, og det er liksom hva mange mennesker vender seg til i dag.
Vi har Dez Blanchfield, han er forsker fra Bloor Group. Vi har doktor Robin Bloor, vår sjefanalytiker i Bloor Group, og vi har Brian Bulkowski, CTO og grunnlegger av Aerospike. Så folkens med det, jeg kommer til å overføre det til Dez.
Dez Blanchfield: Takk, og takk for at du har meg her. Jeg skal prøve å sette scenen for hvordan vi ganske raskt kom dit vi er, og vi skal dykke inn i mye mer av den tekniske detaljene når vi går gjennom dagens emner. Jeg skal bare få kontroll over skjermen her.
Så større, bedre og raskere. Når jeg tenker på hvor vi er, er det bildet som stadig kommer opp for meg personlig, akkurat dette bildet som jeg har fått på tittelbildet mitt, som er utvidelsen av universet. Vi har fått teknologi til å utvikle og vokse i flere tiår nå, faktisk fra slutten av femtiårene da stordatoren ble en ekte ting. Teknologi har fortsatt å vokse i mange tilfeller på en dårligere eller større enn en lineær kurve, avhengig av hvilken del av kurven du er på, så langt programvaren eller maskinvaren går.
Omfanget har blitt større og større, og raskere og raskere, så langt det vi prøver å levere, og mindre og mindre på produksjons- og halvledernivå. Og i midten er det programvare og applikasjoner og systemer som underbygger den programvaren, og de har en tendens til å bli mindre og mindre i naturen, og vi har sett ting som containert applikasjoner og mikroserver, det har blitt en ting igjen. Vi gjorde det tidligere, tiår før, men som et resultat av å gå mindre og mindre dit, blir vi større og større etter omfanget vi nå kan kjøre ting på, for eksempel applikasjoner og bestemte databaser, og logikken til disse databasene.
Jeg har dette synspunktet der vi har skalert veldig horisontalt, i hovedsak X-aksen; vi har skalert loddrett i Y-aksen. Vi er på det punktet hvor vi trenger å gå et annet sted, og i mitt sinn er det slags mentalt sett forutsatt som en Z-akse, og det er at vi må gå dypt inn i teknologien og se på hvordan vi kan gjøre ting annerledes enn hva vi har gjort så langt, for å få den ekstra hastigheten. Så jeg visualiserer hele utvidelsen av universet, hvor vi har hatt en eksplosjon, og det finnes noen teknologier, og dette bedre lineær vekst og etterspørsel. Vi har måttet finne forskjellige måter å få det større, bedre og raskere resultatet.
Bare for å raskt dekke hva vi er i et par maskinvaremiljøer. Vi har sett de fallende kostnadene ved en gigabyte med diskplass føre til et par ganske store overganger og teknologi, og tilnærminger til det større, bedre og raskere skalaproblemet. Dette er to separate grafer som dekker omtrent et tiårstykke, litt over et tiår hver av den fallende prisen på en gigabyte harddiskplass.
Det er en klassisk J-kurve eller en hockeystokk som vi ofte refererer til dem, for at du for en tid tilbake kunne bruke bokstavelig talt hundretusenvis av dollar på å kjøpe en gigabyte med diskplass, for ikke helt to tiår siden, mens det i dag er blitt dollar og til slutt er jeg sikker på at det vil ende opp, det vi kaller løpet til null, det vil bli øre. Det medførte en interessant endring i typen ting virksomheter kunne gjøre. Og jeg refererer til det som en forstyrrelse gjennom data eller big data spesielt, og med det, det jeg mener er at vi så teknologier, som hvordan vi kan bli en ting der vi kunne skalere veldig horisontalt i lagring, og typen beregning vi kan gjelde for den lagringen, og hvordan den åpner en interessant teknologi fordi den lar oss gjøre veldig stor, overflødig parallell lagring på det raskeste nivået, og Hadoop deler i seg selv, naturlig nok å kunne kopiere data i en skriving en gang lest mange ganger format, og bare skalere saken ut på en nær lineær klasse.
Og det er alle selskaper som dette som oppstår ved forstyrrelser ved bruk av big data. Vi har selskaper som Uber som er verdens største drosjeselskap. De eier faktisk ingen drosjer, og det er en lang liste her. Airbnb er den største overnattingsleverandøren, har faktisk ingen eiendommer. En av favorittene mine er Facebook, for eksempel i denne listen, der de ikke faktisk lager innholdet, vi oppretter det for dem, men de er faktisk den største medieeieren på planeten. Vi har interessante som de bankene som vokser raskt, har faktisk ingen penger. Dette er peer-to-peer utlånsplattformer og banker, og det er en i Australia spesielt som vokser berømmelse her kalt SocietyOne. Og noen av de store bankene som trenger å ha penger, investerer i den aktuelle peer-to-peer-banken. Og vi går gjennom denne listen selv ned til Netflix; de eier faktisk ikke kinoer, og likevel er de effektivt det største kinohuset på planeten.
Så de kom dit de var, i mitt sinn, gjennom bruk av smarte teknologier på datanivå, fordi vi kunne gjøre større og bredere lagring til lavere kostnader på grunn av den falt prisen på en gigabyte harddiskplass, og vi kunne bruke noe intelligent beregne og distribuere en datamodell over det. Disse selskapene hadde muligheten til å skape et konkurransefortrinn og forstyrre som et resultat av de fallende kostnadene for diskplass.
Vi har sett en lignende ting skje på bekostning av minnet. For et par tiår siden, hvis du hadde seks millioner dollar liggende, kunne du kjøpe en gigabyte RAM, og vi har hatt en veldig lik J-kurve eller hockeystokk, foregår i reduksjon av kostnadene eller den falt prisen på RAM. Og det har ført til noen interessante ting, og i mitt sinn er en av de største forstyrrelsene i den plassen mengden minne som kan bygges inn i enheter, som mobile enheter, som telefoner og nettbrett, og til og med bærbare datamaskiner. Datamaskiner i disse dager, hvor mye minne som går inn i en gjennomsnittlig bærbar PC er ganske latterlig i noen tilfeller. I noen tilfeller har den nåværende bærbare datamaskinen mer minne enn noen av serverne de pleide å bruke for ikke så lenge siden.
Dette har medført betydelig endring i seg selv, på en lignende måte som en RAM i mine tanker, det tillot oss å skalere og skalere raskt. Og nå har vi fått fremveksten av en teknologi som vi kaller flash, og dette er en teknologi som opprinnelig stammer fra noe som er satt på maskinvare i form av en EEPROM, en liten brikke som var designet for å kunne være tilgjengelig, og skriv til, og da akkurat når strømmen gikk, ville det beholde det du skrev til brikken som vedvarende lagring. Det var tregt, det var uoversiktlig, og i disse dager tror jeg det var omtrent 1980–1981 det ble en ting. I 1984 gjorde Toshiba som jeg tror oppfant teknologien, den til en kommersiell ting som vi kunne bruke.
Men før lang tid regnet folk ut at de faktisk kunne ta en kombinasjon av komponentene som ble brukt til å lage dette konseptet om en EEPROM, et skrivebeskyttet minne, når det først ble slettet det og skrevet til det, og de faktisk kunne skrive til det med jevne mellomrom, og bruk den litt mer som diskplass, og litt mer som RAM. Over tid utviklet det seg. Nå har denne flashlagringsteknologien vært en sammenslåing mellom tradisjonell disklagring, enten det er en spinnende disk eller i noen tilfeller en hybrid disk med minne, og RAM. Og det viktigste er systemet mellom fordi du kan lese og skrive til det, og deretter slå av strømmen, og det vil beholde det du har skrevet til det. Så en diskplass, tydeligvis skriver du til den, slår du av strømmen, og den spinnende spindelen og den sterkt modifiserte, fordi du ønsker en bedre beskrivelse, holder nullen og de du har skrevet til den.
I minnet til tilfeldig tilgang skriver du noe til minnet i RAM, slår du av datamaskinen og alt blir utslettet fordi det ikke er flere elektroner for å holde det ladet og holde informasjonen du skrev til den. Pluss at det er i midten, og det er ekstremt raskt, raskere enn disk, litt tregere enn RAM. Men du kan skrive til den og lese fra den, og når du slår av strømmen, vil den vedvare. Dette har ført til noen fantastiske teknologier, og spesielt har vi utviklet mobile enheter og bærbare datamaskiner som er virkelig, veldig raske og i stand til å gjøre mange ting, og nå flyttes det inn i infrastrukturområdet rundt lagring og beregning, og det har medført betydelige endringer i hva vi kan levere i skala. Dette er slags hvor jeg tror Z-aksen i tankene mine kommer til nå.
Det er nesten bare i tide på mange måter, fordi vi nå har sett en forstyrrelse gjennom det jeg omtaler som etterspørsel, og det er at forbrukere har, uavhengig av hva som skjer i infrastrukturen og teknologirommet, og muligheten til å kjøre raskere og raskere beregning, og ytelse på infrastrukturnivå, krever forbrukere denne forstyrrelsen i form av det som er referert til nå, kjendisopplevelsen. Alle ønsker at hvert system, hver app, hvert nettsted skal vite hvem de er og hva de liker, og å kunne gi dem en personlig en-til-en-opplevelse. Det er ikke bra nok lenger bare å gå til en webside hvor jeg kjøper kinobilletter. Jeg vil at den skal vite hva jeg har kjøpt før, hvorfor jeg kjøpte den, og potensielt hva folk akkurat som meg kjøpte og anbefaler ting.
Unødvendigvis ser vi det jeg refererer til er en sideordning av det sosiale, og det er at jeg vil ha kjendisopplevelsen, men jeg vil også sosialisere den ideen, jeg vil dele den med alle vennene mine og fortelle dem hva jeg gjør det, og jeg vil også vite hva vennene mine gjør. Og dette er et resultat av en eksplosiv etterspørsel etter ytterligere databehandling og lagring, og rask snuoperasjon av ting. Vi har sett Fitbit-generasjonen, det jeg kaller sporing av alltid. Alt jeg gjør blir sporet, logget og fanget et sted. Vi har sett alt i sanntid: bank, budgivning, anbefalingsmotorer, å være i stand til å takle sanntids ting jeg personlig gjør som forbruker.
Og så ser vi en veldig stor innvirkning, som sikkerhetsrisikoen rundt cybersikkerhet. Det pleide å være at vi hadde individuelle hackere, så hadde vi kriminelle gjenger som bruker seg på det, nå har vi hele nasjoner som går i krig over internett, noe som er en ekte ting og faktisk skjer. Vær oppmerksom på det, sett deg opp og se på det, for det har en reell innvirkning på det, og noen av våre forhåndsvise småbiter dreide seg om å diskutere risikoen for å få din egen datamaskin, eller i det minste nettverket ditt, penetrert.
Vi har sett dette konseptet med utvinning av enheter. Utvinning av enheter er når vi må finne ting av interesse i veldig store datasett og spesielt rundt svindel, og ulovlig aktivitet og hacker-type aktivitet. Men oftere enn ikke, vil vi se at utvinning av enheter blir et fokuspunkt for gode ting, og ting som er av verdi for oss, i motsetning til å se etter ting som angriper oss.
Vi har også sett en eksplosjon, det som omtales som geospatiale data. Dette er data som faktisk vet hvor de stammer fra, eller hvor andre data som de kommer fra. Du kan forestille deg at du står på gaten og ønsker å finne den nærmeste parkeringsstasjonen, eller den nærmeste restauranten, applikasjoner som kan bruke geospatial beregning og data, databehandling til data, som vet hvor det er i verdensrommet, er veldig viktig fordi du må kunne vite hvor andre objekter og enheter er, og gjøre det raskt.
Vi har sett permanent tilkoblet mobil. Selv når vi legger oss om natta, krysser mobilen fremdeles, oppdaterer e-postene våre, sjekker kalenderne våre, ser på hva været er og finner ut om det vi vil ha til frokost kommer til å være tilgjengelig. Det skjer mye støy der, og det har skapt en enorm innvirkning på hva vi trenger å gjøre i bakenden, og hvor raskt vi gjør det.
Totalt sett er det store omfanget og virkningen av det som omtales som tingenes internett, eller oftere enn ikke tilkoblingen mellom maskin og maskin, der enheter snakker med enheter og som går helt opp til motorer som er festet til siden av flyene som forteller selve flyet, eller flystyringssystemet, at en peiling på motor nummer fire opplever for stor slitasje og varme, og bør byttes ut når vi lander, og så kommuniserer den til en annen maskin, og så skal den plassere en ordre, og på magisk vis dukker en ingeniør opp på flyplassen og er forberedt på å erstatte den under drivstoff.
Og skalaen som er så stor og så stor at vi har måttet gå inn på hva jeg refererer til, via tilgang til en slags takle det. Fordi en ny verden, og velkommen til den nye verdenen, en ny verden med alt det vi bruker er koblet sammen; en gang var det satellitter og nettverksenheter, nå er det mobile enheter og våre bærbare datamaskiner og nettbrett og telefoner, og til og med den splitter nye Audi-en min har et skilt innebygd i det, og det rapporterer kontinuerlig om sin egen helse, men oppdaterer også seg selv, og vet hvor det er, og hvilke kart som er aktuelle, og til og med forteller meg når jeg skal gå en annen rute hvis det er trafikk på veien foran.
Alt vi bygger nå, alt vi snakker med deg nå, blir designet for å koble til og koble til andre ting, ikke bare fra meg til system, men fra system til system, og for å kunne takle det vi Jeg må bruke veldig forskjellig tenkning på infrastruktursjiktet, både på maskinvaren og programvaren, og spesielt databaselagene som systemene trenger for å understøtte dette, og på mange måter har databasen blitt motoren, og appene er virkelig bare små roboter som gjør ting.
Jeg kommer til å avvikle raskt her med dette litt humoristiske synet på hva vi skal med disse tingene, og det jeg omtaler som "IoT med et trykk på en knapp." Det har blitt opprettet en ny dings som kalles den Amazon Dash-knapp, og dette er en liten tommelstørrelsesinnretning. Faktisk er det på mange måter det samme som min USB-tommelstasjon. Når du kjøper denne tingen, handler den om $ 4, 99 amerikansk online fra Amazon, den blir sendt til deg, du konfigurerer den med mobiltelefonen din, og du setter den bokstavelig talt til en av enhetene dine, for eksempel kjøleskap eller vaskemaskin eller hva som helst. I vaskemaskineksemplet ditt, hvis du til slutt går tom for vaskepulver, kan du trykke på den knappen og den vil ringe hjem og automatisk bestille mer for deg, og magisk mer vil bli sendt til deg via våre gode venner på Amazon.
For meg skremmer dette meg, fordi det kommer til å se en eksplosjon av en rekke ting som er koblet på nettverket og forsøke å skape tilkobling, og generere etterspørsel. Hvis du kan forestille deg, er en eller to av disse tingene kanskje ikke så skummelt, men forrige gang jeg så det, var det over 110 av disse tingene som er merket, så nesten hvert eneste merke på planeten kommer til å prøve å få sitt eget lille push- knapp IoT, at du drar hjem og trykker på en knapp, og det sier: "Bestill meg en pizza." Du trykker på en annen knapp, og den bestiller en ferdigbygd lunsj til barna dine på skolen i morgen.
Det driver en så massiv etterspørsel etter transformasjon på baksiden, på applikasjonsnivå, spesielt på databasenivå, at jeg tror vi bare har sett toppen av isfjellet av den typen ytelse transformasjon vi trenger å se . Og med det skal jeg overlevere det til doktor Robin Bloor og få innsikt i hva slags sted vi er, også.
Rebecca Jozwiak: Okay Robin, jeg har gitt deg ballen.
Robin Bloor: Er det ikke bra? Ok, her går vi, det er meg. Jeg så Dezs presentasjon før jeg kom til denne, så jeg vil si ting som er gratis i stedet for bare å gjenta noen av tingene som Dez sa. Jeg trodde jeg skulle snakke om evolusjon av databaser i form av hva som faktisk skjedde med arkitekturen, og så videre og så videre, av databaser fra et historisk perspektiv.
Det grunnleggende problemet som enhver databaseleverandør har, er å opprettholde en fleksibel arkitektur som skalerer og holder tritt med maskinvareutviklingen. Jeg skal snakke trodde dette, men når du faktisk ser tilbake og ser hvordan databasene pleide å bli bygget, og måten de er bygget på nå, er de faktisk vesentlig forskjellige fra det jeg vil kalle det arkitektoniske designnivået . Det er verdt å bare vurdere hvorfor det er, eller i det minste tror jeg det er. Maskinvarefaktorene, og Dez har gitt oss en spesielt god oversikt over de nedre lagene når det gjelder minne og disk. Det vi har nå, og dette er fremtiden som kommer, Intel er neste, CP som skal ha en FPGA på det. Hva folk skal gjøre med det har jeg ikke peiling på. AMD slår sammen CPUer og GPUer, og hva er det for en forskjell? Dette er den slags endringer som faktisk vil utgjøre en forskjell for databasen, og jeg mistenker at blant annet Aerospike, fordi Aerospike er drevet av ytelse, det sannsynligvis allerede er å ta en titt på det og finne ut hvor den tror den faktisk kommer til å gå med måten produktet fungerer på.
Vi har et system på en brikke som ikke har tatt av enda. SSD-er vi vet om, men poenget å gjøre er at de faktisk øker i hastighet, omtrent Moore lovens rate, en faktor på 10 hvert sjette år. Men Intel er i ferd med å gi ut 3D-krysspunkt, som hevder å kunne gå mer enn hundre ganger raskere enn SSD-er, faktisk noen dråper i blandingen, da vil det endre hastigheten som produkter som Aerospike faktisk kan gå.
Så har vi de parallelle maskinvarearkitekturene, med andre ord slik vi har konstruert maskinvare i betydningen - opprinnelig var det bare en CPU som satt over minnet, som satt over disk, men det er blitt mer komplisert enn det. Ideen med et system på en brikke er at du faktisk kan ha parallelismebrikke til chip til chip og få alt til å gå i ekstraordinær hastighet, og vi har ingen anelse om nøyaktig hvilke av disse produktene som faktisk kommer til å dominere.
Det er bare et blikk på fremtiden, men på maskinvarenivå akselererer ytelsen, og kostnadene fortsetter å falle, på samme måte som Dez beskrev. CPU-ene dine blir ikke nødvendigvis billigere, de blir bare raskere og så videre.
Fra forretningsperspektiv, i noen situasjoner, og dette er markedssituasjoner, er det å være først der hvor forretningsverdien er. Hvis du spesielt - hvis du er helt overbevist om at en bestemt aksje vil falle i pris, får den første personen som får salgsordren den beste prisen. Det er virkelig så enkelt. Derfor er det et teknologiløp som går videre til automatisert handel i bankene for å faktisk prøve å vinne disse situasjonene. Hva skjedde etter det? Hva skjer etter at bankene har gjort sine ting med alt dette? Du begynner plutselig å se andre områder bli smittet med samme type behov for hastighet.
Det som foregikk, er at mennesker ble fjernet fra ligningen, og det skjedde med internettreklame veldig raskt. Men saken var at det ikke er den spesifikke transaksjonen, utførelse av metoder, dette er en hel forretningsprosess, det er det faktum at en webside nettopp har blitt kastet av, og det må tas en beslutning som kan være en ganske komplisert beslutning, med hensyn til hvilken annonse som faktisk skal legges ut på denne nettsiden, og trekke fra hvem brukeren av nettleseren er hva som vil være den mest passende annonsen å legge den på, og så videre og så videre. Det har blitt en veldig sammensatt ting, og jeg vil nevne det igjen.
Men poenget er at ytelsen og skalerbarheten i forretningsprosessen ikke er det samme problemet som ytelse og skalerbarhet av en spørringsevne, og dette er noe som jeg er godt klar over, på grunn av et nylig orienteringsrom vi gjorde med Aerospike som de er også klar over. En annen ting, når du faktisk jobber med disse hastighetene, betyr eiendeler for en transaksjon, eventuell prosessering. De betyr virkelig noe. Så veldig mye av det noen databaser gjør, og som mister et brev eller to fra eiendelen, kan virke rimelig godt i sammenhengen - dette vil fungere bra i den konteksten vi snakker om. Det er egentlig ikke akseptabelt, for å være ærlig.
Fra et teknologiperspektiv ser du faktisk på - jeg vet at det er to typer gearing, for å skape den typen arkitekturer som faktisk er nødvendige for å gi den typen hastigheter som kan gjøre, som Aerospike, kan utføre en million transaksjoner per sekund. Du må faktisk være veldig presis med tanke på programvareutviklingen. Du kan ikke bare hacke bort. Du må være bekymret for lengde på kodevei. Du må gjøre god bruk i minnet, og du optimaliserer faktisk hele transaksjoner. Du trenger intelligent parallellisme og du trenger også feilsikker parallellitet. Du må skalere opp, i stedet for å skalere ut, for så snart du involverer nettverket i noe, blir det den mest sannsynlige pekeren du kommer til å treffe på forsinkelse, og det vil begynne å gjøre transaksjonene for trege.
Du må komme så mye som mulig inn på et gitt kjent av et nettverk før du faktisk skalerer ut, og du virkelig ikke vil skalere ut raskt, du vil egentlig ikke ha mange prosesser. Du vil ha et nettverk som ikke brukes av noen andre. Og du vil ha et utrolig raskt nettverk.
Akselerert SSD-lagring er noe - faktisk tror jeg det meste av dette gjelder hva Aerospike gjør. Noe av det interessante er at det er en NoSQL-database. Det pleide å bli trodd - jeg vet ikke, for flere år siden - det pleide å bli trodd at den relasjonelle databasen var den eneste databasen og den dominerte alt, og det var bare disse rare små nisjesituasjonene der du ikke trengte å gå relasjonelt. Det er litt snudd på hodet nå. Det er de raske databasene som er på de SQL-databasene, og en av grunnene til det, den viktigste grunnen til det, er at de unngår å bli med i data, de lagrer data ganske mye på en objektiv måte. Når du er ferdig med et objekt, lagrer du det bare, og så drar du hele gjenstanden, det er ikke å slå sammen ting for å faktisk behandle dem. Dette er hva hastighet handler om. Denne typen teknikker som genererer hastighet i databasesammenheng.
Dette er sporet av tårer, dette er hva som skjedde med databasen. Historien eller fortellingen om de relasjonelle databasene var slutten på en database, og det var faktisk ikke sant. Selv da de begynte å bli dominans, var det fortsatt nødvendig. Objektdatabaser gjorde de siste transaksjonene i disse dager, fordi relasjonsdatabaser faktisk ikke kunne gjøre dem, og da viste det seg at de relasjonsdatabaser som bruker radbutikker, de ikke kunne gjøre raske spørsmål heller, du trengte kolonnebutikker. Og så oppdaget vi at hvis du faktisk ønsket å lage grafiske spørsmål om data, verken en kolonnelager eller en relasjonsdatabase ville være noe bra, og du faktisk måtte ha en spesifikk grafbevisst database bygget for deg. Så kom RDF-databaser inn, og så snart du faktisk begynte å vurdere betydningen av semantikk og vi fikk NoSQL-databasene inn, veldig, veldig spesifikt for hastighet. Å kalle dem NoSQL er nesten som om du merker alle disse databasene som om de var de samme, faktisk er de radikalt forskjellige i det som ligger under. Den eneste grunnen til at de bærer navnet NoSQL, er at de ikke gir noen forbannelse om SQL fordi det er for dyrt. Transaksjonens forsinkelser som de trenger.
IoT - som jeg trodde jeg ville fullføre på samme punkt som Dez avsluttet den på - den er ikke over, all denne situasjonen når det gjelder hastighet og forsinkelseskrav, den er ikke over før den fete damen begynner å se bort fra disse dataene, og de har ikke startet ennå. Mange av disse dataene vil ønske å ha forsinkelser som jeg har indikert, så jeg tror det er alt jeg har å si. La oss gi den videre til Aerospike og Brian Bulkowski.
Brian Bulkowski: Hei, tusen takk for at jeg ble med på Bloor Group og meg selv for denne presentasjonen i dag. Når jeg tenkte på hva Dez og Robin bare snakket om, vil jeg fortelle deg litt om stien Aerospike har tatt i å tilby ny databaseteknologi og NoSQL-databaseteknologi til en rekke bransjer. Det har vært en flott sti. Vi startet Aerospike i 2008 for å se mange av trendene som Dez og Robin har nevnt. Spesielt om databaser i minnet som kan dra nytte av blits, så vel som typen utskilt skysystemer, og hvilke skalaer som kreves for å gjøre personalisering, atferdsanalyse og typen VIP-opplevelser som kjendis ble diskutert.
Da vi nærmet oss problemet med en database som var en front-end operativ database som var i stand til å gi underlaget til applikasjoner som kunne skrives for å løse disse, startet vi med problemet hvordan vi i det vesentlige kunne bygge et distribuert hash-bord, minne -distribuert hasjbord som var forbausende rask og i stand til ting som millioner av transaksjoner per sekund, men til en fornuftig pris. Da vi var ferdige med prototypen, innså vi at da måtte vi finne ut hvem som måtte trenge denne typen fart. Som et Silicon Valley-selskap fant vi raskt ut at det virkelig var reklamebransjen som var i stand til å konsumere denne typen informasjon og var interessert i den, og derfor vil jeg gjerne bruke et øyeblikk på å snakke om sanntid-budgivning og hvordan dette markedet fungerer.
Robin nevnte hvordan finansiell handel fungerer, som er den første transaksjonen, er ofte den vinnende transaksjonen, og det er egentlig et tidspunkt til marked for latens og en verdi til latenstid. Reklamebransjen er litt annerledes, på en interessant måte, fordi målet med reklame er et bestemt - det som kalles et inntrykk, muligheten til å levere en annonse - er en auksjon og den auksjonen går mellom ti millisekunder til femti millisekunder. Navnet på spillet, og det er ofte hundrevis av selskaper som nå byder i sanntid på hver eneste annonse som er plassert på internett, er å få mest mulig data og bringe de beste algoritmene som er i løpet av ti til femti millisekunder over største datamengde.
Denne endringen og skiftet skjedde i reklamebransjen, i hvert av de små millisekundene, har en tidsavgrenset komplikasjon med de beste algoritmene over den største datamengden, og for å gjøre det samler du mange små biter av data. Ny informasjon om IP-adresse, nylig informasjon om en bestemt enhetskategori, ny informasjon om nettstedsadferd, nylige søketermer, alt vil gå inn i den hemmelige sausen til et bestemt selskaps algoritmer for å bestemme en pris og et bud.
Dette har vært et fascinerende marked å være en del av. Vi gjorde vår første distribusjon på Aerospike i 2010 med noen av de første selskapene som jobbet seriøst innen sanntids anbudsøkonomi, og deretter har oppnådd, i utgangspunktet å være den front-store butikken av atferdsdata, for de fleste selskapene i det rom. Det vi har funnet siden den gang, og er en spesiell arkitektur som jeg vil detaljere gjennom løpet av denne presentasjonen, er at alt skjedde i 2010, 2011, 2013 og fortsetter å utvikle seg. Reklame er et veldig dynamisk marked.
Men den slags VIP-opplevelse, kan du tenke på å plassere riktig annonse, ikke plassere en annonse for å si barneprodukter, fordi jeg ikke har noen barn, så jeg kommer ikke til å ha en effektiv annonse hvis det plassert på det, men hvis det handler om raske biler, er det den typen annonse som skal plasseres til Brian. Det er virkelig den slags VIP-opplevelsen når det gjelder avtaler, om du vil rabattere eller ikke, hvis du er på en detaljhandelnettsted, til og med når det gjelder svindel. Er dette det normale mønsteret til en bestemt person, eller et bestemt kredittkort? All den formen for teknologi i sanntidsanalyse, av atferdsforutsigelse, av prediktiv analyse, siver nå ut av reklamebransjen, som har gjort det for moro skyld og fortjeneste nå i ganske mange år, og virkelig kommer til detaljhandel og bank- og svindeloppdagelse, etc., gjennom en bestemt arkitektur. Så Aerospike har vært privilegert som en del av en rekke av disse sakene.
Arkitekturen som vi ser fungerer og er praktisk for å gjøre dette, er en der i stedet for å lage et sett med spørsmål fra en applikasjonsserver, i stedet flytte mer av beregningen din til selve appserveren, og deretter bruke en database som egentlig et lagringssted motor for den typen gjenstander som Robin snakket om. I dette tilfellet forveksler disse arkitekturene først og fremst ikke dette med den faktiske analysen her. På høyre side av dette lysbildet ser du at det fremdeles er en analyse her for å generere innsikt. Dette er jobber som ofte arbeider over petabyte, titalls petabyte med data, til og med eksabyte i tilfeller av noen av våre store kunder, ved bruk av en rekke teknologier. Du må ha et stort datateam, et analyseteam, et kvantitativt team der ute for å finne ut hva, si, geospatiale koordinater betyr noe, hvilke modeller som fungerer i forhold til å finne de forholdene og skape VIP-opplevelsen. Det er et helt problem for seg selv og ikke et som Aerospike har deltatt direkte i, og det er en haug med flott teknologi når du har å gjøre med den typen system.
Det vi har vært spent på og jobbet med bransjen om er, når du først har fått den innsikten, hvordan kan du delta i typen maskin-til-maskin eller rask maskin-til-menneske-transaksjon, der du tar den innsikten og lager de virkelige for hver person, øyeblikk for øyeblikk? Arkitekturen som vi har sett som bruker det, er en der det er en applikasjonsserver som er skrevet, og som gjør alt det matte og ser gjennom modellene du har laget, og ser på nyere oppførsel og gjør det over i hovedsak et nøkkelparadigme eller i det minste veldig spørrende-lett slags system.
Når du har å gjøre med de datatypene vi snakker om, den typen strømmer vi snakker om, med millioner av skriv per sekund, millioner av lesninger i sekundet, millioner og hundre og tusenvis av beslutninger per sekund For det andre: å bygge komplekse indekser, flerdimensjonale indekser, fungerer ganske enkelt ikke så bra, det er ikke skalerbart. Måten å oppnå denne formen for skala er å involvere mye parallellitet. Vi skal snakke litt om hvordan vi gjør det senere. Men en del av det er en statløs appserver skrevet på ditt eget språk.
Det vi ofte ser er et bestemt prosjekt som legger til grunn en ny applikasjonsramme basert på menneskene som jobber der, teknologien de bruker, og problemet de nærmer seg. Vi har sett folk som bruker Python, mange mennesker bruker Java, vi ser fortsatt C-programmerere, fordi mye av dette fremdeles er høy ytelse, kanskje til og med bruker ting som de gamle MATLAB-bibliotekene. Og de må ta på tusenvis av tusenvis av datapunkter i sekundet for å ta en effektiv beslutning.
Et spørsmål jeg noen ganger har stilt er: "Vel, Brian, hvis du er i stand til millioner av transaksjoner i sekundet, hvem trenger det?" Hvis du for eksempel ser på nordamerikansk betalingsbehandling, og Aerospike er involvert i løsninger som gjør gjenkjenning av svindel i det systemet, og støtter applikasjonsforfattere som gjør noen veldig innovative ting innen svindelavdekking, er det bare noen få tusen betalingstransaksjoner per sekund som strømmer gjennom til og med den største betalingsprosessoren. Og likevel, da det første selskapet kom til oss og sa at de så på å bruke NoSQL, og ønsket å se hvordan løsningen vår ville se ut som underlag for applikasjonen deres, sa de at de ønsket å berøre 5000 datadeler i et 750 millisekund-vindu. Vel, nå har du plutselig noen hundre forretningstransaksjoner og noen få tusen data som du må vurdere i hver beregning, og nå er du oppe i området med å trenge millioner av transaksjoner per sekund.
Saken om - å legge til side reklame for et sekund, er saken om svindel fascinerende fordi hvor det er penger, det er svindel, og sanntidsforebygging av svindel, i motsetning til å prøve å sortere analytisk etter at et svindel har skjedd, er virkelig en spørsmål om å bringe så mye data online som mulig, og du kan tenke på det som en refleksjon av den VIP-opplevelsen. Oppfører denne personen seg på en måte som de vanligvis ikke oppfører seg? Og dermed øker sjansene for at det er et uredelig system, og ikke faktisk denne personen. Har denne personen vanligvis tilgang via en bestemt enhet eller sett med enheter, med et visst skjermoppløsning? Viser de vanligvis et bestemt atferdsmønster? Kanskje kan vi nappe svindel i knoppen i løpet av selve transaksjonen. Det skal minne deg veldig mye om hva slags ting som skjer i en transaksjon i annonseringssystemet.
Systemene vi løser er de der hver enkelt betalingsprosessor har et stort datateam, de har mange historiske data, de lager nye modeller, de deler ikke med oss på Aerospike alle modellene, fordi de er virkelig en hemmelig saus. Hvis du er en abonnent på Gartner og hørte Gartner snakke om algoritmeøkonomien, er dette en algoritme og ett selskap som kjemper hodet mot hodet for å få ned svindel og for å få opp antall vellykkede transaksjoner, fordi du også ikke t vil blokkere transaksjoner. Det er den typen prosjekter vi ser etter i Aerospike på disse skalaenivåene.
En annen sak som vi har jobbet med selskaper i finansielle tjenester, er det som kalles Intraday System of Record. I dette tilfellet er det som skjer, typen rikere opplevelser, selv i et detaljhandelssystem, der jeg vil være i stand til å se på min spesielle stilling, og jeg vil gjøre det ekstremt nøyaktig. Jeg vil ikke ha en fangst foran DB2-systemet mitt. I stedet ønsker jeg å se på de nøyaktige dataene, og mellom mobil, men også ting som en risikoberegning, skal risikoberegninger nå gjøres på minutt-for-minutt-basis, du vil være i stand til å beregne alles risiko i tillegg til den globale risikoen, systemisk risiko i hele selskapet i løpet av få minutter.
Og igjen, det er det samme problemet. Hver enkelt konto som er spesiell, tenk på den som en nøkkelverdi-oppslag til et bestemt objekt, så kan dette gjøres parallelt, og viktigst av alt, dette paradigmet lar deg skrive koden og algoritmene dine på et høyt nivå språk, som er lettere å feilsøke og raskere tid til å markedsføre. I denne algoritmeøkonomien trenger jeg å kunne få algoritmene mine på nettet nå. Dette er et veldig annet problem for modellering og forretningsforhold, og det er det relasjonelle systemer er gode på. Når du har en tabell over deler, og disse delene er tilknyttet bestillinger, og disse ordrene er assosiert med mennesker, har du en forretningsprosess som kan modelleres strengt og sannsynligvis ikke vil endres i løpet av virksomhetens levetid. Imidlertid må en ny algoritme for å finne et nytt svindelmønster skrives nøyaktig og raskt, og komme på nettet, og ta forretningsavgjørelser i løpet av noen dager, i det minste, om ikke raskere. En NoSQL-løsning for denne typen opptakssystemer er virkelig et fantastisk system for disse karene, fordi det gjør at de kan innta data veldig raskt, så vel som å bygge nye algoritmer, så ikke bare en ny kundeopplevelse når det gjelder adressering av mobil, men egentlig bygge ut et bredt utvalg av nye applikasjoner.
Det vi ser på lang sikt hos Aerospike er det faktum at hver databasetype, hver fysiske utforming av data på disk har sine egne komponenter, og på Aerospike er vi virkelig fokusert på denne nøkkelverdien eller det rolleorienterte systemet, som Robin sa, med høy transaksjonskonsistens, og virkelig tillater folk som kolonnebutikker og datavann med høyt volum og så vel som hardcore transaksjonssystemer som også har hatt rapporteringsbegrensninger. Vi ser at alle trenger å mate inn i en rekke forskjellige spørsmotorer. Vi ser noen av de JSON-baserte spørsmotorene. Vi ser ting som elastisk søk, vi ser Spark, alle trenger forskjellige varianter til forskjellige tider av ting som kolonnebutikker, så vel som radbutikker, og det er her Aerospike utmerker seg.
Vi ser virkelig at disse forskjellige typene og bransjen er i ferd med å komme til et punkt der det å plukke det beste av rasen av hver enkelt av disse kommer til å være en nødvendighet. På grunn av virkeligheten av langsiktige analyser og batchjobber vers analyser og driftsmessige begrensninger, vil vi sannsynligvis ikke komme til poenget med å ha en, en størrelse som passer alle, men vi vil komme til poenget med å være i stand å velge klart mellom noen av kjerneoppsettene.
La oss snakke et øyeblikk om innovasjonen av flash. Jeg får fremdeles spørsmålet, selv om flash som har vært kommentert tidligere, har vært med oss nå i lang tid. Da vi startet Aerospike i 2009 var det, da jeg tror 2009, kanskje, ja, 2009 var da Intel kom ut med X25, som virkelig var den første massemarkedet SATA bemannede flash-stasjon, og det var en rekke blitzsystemer før det, men egentlig var det den som brøt inn i mye teknologis bevissthet. Fusion-io brakte virkelig flash til det bredere bedriftsmarkedet etter det.
Det som skjer nå er fremveksten av et system som heter NVMe. NVMe er en standard som ligner SATA eller SAS eller til og med SCSI som gjør at forskjellige kortleverandører kan samhandle med drivere i operativsystemet med et høyt effektivitetsnivå. Så det skaper et større ytelsesnivå, først og fremst fordi NVMe er basert på PCIE som underliggende transport, som er mye raskere enn SATA, SAS eller noe annet, men også det tillater best-of-race-sjåfører.
For eksempel innen Linux er det denne fyren Jens, og Jens er NVMe-driverguide, Jens expo, og han gjør en bedre jobb enn noen individuell tn Intel eller Fusion-io kunne ha gjort med deres individuelle driver, med alle ressursene sine. Når du har kraften i selve operativsystemet til å kunne bygge den beste driveren, ser vi noen virkelig fantastiske ytelsesnivåer. Dette sikkerhetskopierer ideen om at blitz virkelig kan gi mye av den lave latensen til RAM.
Nå er Aerospike fremdeles en flott RAM-database på grunn av sin klyngemodell, men vi opplever at når du først har et nettverkshopp, som du trenger for å ha skalerbar lagring, bruker du allerede minst fem til 50 mikrosekunder, ekstra 70 mikrosekunder NAND er vanligvis ikke en hindring, og du kan like gjerne bruke blitz, gitt at NAND-blitsen, gitt at nettverket allerede er involvert i det. Mange lurer da på hvordan - alt dette høres bra ut hvis du kjøper din egen maskinvare, hvordan har det med de offentlige skyene? Jeg tror du vil finne akkurat nå, uansett hvilken offentlig sky du bruker, har de offentlige skyene veldig sterke blitz-tilbud. Det skiller seg litt fra skyleverandør til skyleverandør. Amazon har sine I2-forekomster som har vært ute for jeg tror et år, to år nå, som egentlig er ganske høykvalitets flash-planer, og Aerospike har distribusjonsmønsteret på toppen av seg.
Jeg vil gjerne kalle Google Compute, Google Compute Engine, Google Cloud spesielt, fordi de til nå har opplevd at de har noen av de høyeste ytelsesenhetene og noe av den mest fleksible når det gjelder distribusjonsmønstre. Men også ser du nye distribusjonsmønstre som Pivotal, som er en slags offentlig / privat, slik at du kan gjøre riktige Pivotal-apper begge steder som støtter blits og støtter forskjellige lagringsenheter så vel som Docker-mønstre. Så virkelig, dette er et punkt i historien der flash ikke bare er tilgjengelig for deg å kjøpe og legge inn i datasentrene dine, men virkelig har sunket gjennom alle infrastrukturleverandørene, fordi det virkelig er den beste måten å få høye IOPS-systemer på. en veldig rimelig latenstid.
Bare et øyeblikk om Aerospike - Aerospike er en klyngedistribuert database, noe som gjør den veldig mottagelig for sky-stil distribusjoner så vel som datasentre. Vi opplever at fleksibiliteten i å kunne legge til mer data og mer ytelse er absolutt nødvendig i denne typen nett-nye applikasjoner fordi du starter et prosjekt, du vet ikke om du trenger femti tusen transaksjoner per sekund, hundre tusen, en millioner, to millioner, så du vil gi deg selv litt rom for å kunne legge til servere. Og likevel vil du skalere opp slik at hver server kan være rask på egen hånd. Du ønsker egentlig ikke å ende opp med fem hundre eller tusen servere som er databaseservere som går tregt. Skala ut er ikke det eneste spillet i byen, det skaleres ut og skaleres opp, som Dez sa tidligere, det er en ny Z-akse.
Forhåpentligvis gir det deg noen nye ideer om hvordan hastighet og omfang adresserer nye markeder, og kanskje er det prosjekter du jobber med der du kan vurdere å virkelig bygge ut mer rike applikasjoner og bruke et applikasjonsrammeverk med en mer nøkkel verdi eller NoSQL-database under den. Hos Aerospike har jeg absolutt sett mange av kundene våre, og mange av våre open source-brukere lykkes med det mønsteret, og jeg ser frem til at bransjen i større grad tar i bruk det.
Rebecca Jozwiak: Tusen takk Brian, og jeg er sikker på at Dez og Robin har noen gode spørsmål til deg. Robin?
Dez Blanchfield: Jeg er glad for å hoppe inn. Robin, har du et spørsmål? Ellers har jeg en rask jeg kan starte.
Robin Bloor: Beklager, jeg var på stum. Jeg dykket inn, men ingen hørte meg. Spørsmålet dukket umiddelbart opp for meg, fordi dette er et veldig sofistikert sett med teknologifunksjoner. Når det gjelder de eksisterende kundene du har, hva er den typen opptrapping eller transaksjonsrate du opplever angående noen av disse annonseprogrammene? Fortsetter transaksjonsrenten å øke? Og i så fall, til hvilken type hastighet?
Brian Bulkowski: Interessant spørsmål, Robin. Hver bransje har sin egen kurve i hvert selskap. La oss ta nordamerikansk reklame, for å si at Nord-Amerika annonsering formentlig kjørte nærmere 200.000 annonser per sekund, i form av en standard intradag, ikke min tid, og den er nå eskalert til omtrent tre til fem millioner annonser per sekund. Men så skjedde en interessant ting. Annonsebransjen begynte å ta opp noen svindelproblemer, og delene i bransjen som er i stand til å blokkere svindel, så transaksjonsrater falle litt, omtrent en faktor to, i noen av våre mer sofistikerte kunder som var i stand til å bestemme svindel. De måtte selvfølgelig gjøre noen databaseoppslag for å blokkere svindel, så det ender opp med å bli lik det til slutt.
En interessant brukssak er innen telekom, jeg nevnte egentlig ikke det, telekom så transaksjoner øke på grunn av fakturering basert på hver eneste pakke som passerer over mobiltelefonnettverket. I gamle dager hadde vi ringe detaljerte poster, og en gang i minuttet, en samtale, hva du vet, en liten ping ville gå gjennom nettverket og har denne fyren fortsatt et minutt igjen? Nå må vi bygge og til og med rute basert på hver pakke på internett. Det er en - beklager i et mobilnettverk, som plutselig nå er millioner av pakker i sekundet og noe som vokser om og om igjen. Så ett tilfelle er at hvert program kjører en fin liten type 2X per år. Innenfor noen kunder ser vi: “Men vent, jeg har en ny applikasjon. Jeg vil legge til litt svindel til risikoen min. Jeg vil legge litt dypere kundeopplevelser til svindel og risiko. ”Hver av dem skaper ny belastning på den underliggende databasen.
Robin Bloor: Ja, jeg mener at det var det jeg tipset om i den korte presentasjonen jeg ga, at disse - vi trodde en transaksjon er, noen gjør noe og kanskje er det en kaskade av hendelser og det hele blir spilt inn, og nå har mange transaksjoner et enormt oppslag, og du ga noen eksempler i presentasjonen. Og derfor utfører du faktisk ikke en transaksjon lenger, du utfører faktisk en slags applikasjon som kan ha mange, mange elementer i den.
Det andre spørsmålet før jeg overleverer til Dez - fordi vi tydeligvis merker teaming om dette - det andre spørsmålet som jeg ønsker at du skal svare på hvis du har et rimelig svar på det, er både Dez og jeg forventer internett av Ting, eller Internett for alt som det noen ganger kalles, for å skape en ganske dramatisk mengde transaksjonstrafikk. Kan du snakke med det? Er det din opplevelse, har du fått kunder som kommer til deg med den type problemer, og hva er din syn på dette for øyeblikket?
Brian Bulkowski: Jada, jeg tror det er litt forvirring, og for å si det mildt, om Internet of Things. Kundene som jeg ser så langt tar ganske enkelt internett til de tingene de har. Tenk på Amazon-knappene - alt er Amazon - de knappene, du kan ikke bruke dem på nytt og få dem til å gå til Walmart online. Det er ikke som en nettleser som du kan mikse og matche alt. På den annen side skjer maskin-til-maskin, og når du kobler til Tesla-bilen din for å lade den, sender Tesla en enorm tilbakestrøm av informasjon, hver eneste sensor inn i bilen, men den flyter inn i Teslas datamaskin for analyse og forbedring kvalitet. Det jeg ser er at alle de maskinene til maskinene og alle sensorene i et individuelt selskap skaper nye krav.
Nå stort sett i dag, som flyter inn i disse analysesystemene, og ta saken om Tesla; Teslas første bruk av dette, etter min forståelse, var å forbedre batteriets levetid, under “Hvilke driftstemperaturer er de, hva er belastningen? La oss se på det, la oss designe et bedre batteri. ”Men så begynner de å tenke, og det er flott, det er et dypt analyseproblem som er fascinerende, det neste spørsmålet er:“ Hvordan forbedrer jeg opplevelsen øyeblikk for øyeblikk ?”
La oss nå ta saken som Nest, der du prøver å gjøre prediktive analyser for å endre et hjemmets temperatur øyeblikk for øyeblikk. Det er den typen tilfelle der vi begynner å se i Aerospike, hvor det er denne enorme datasjøen og det er disse enorme analytiske prosessene, men hva skal jeg gjøre nå? Jeg trenger å beholde, tenke på det som kontanter, en del av den siste uken, den siste måneden, kanskje til og med bare den siste dagens informasjon, sannsynligvis på baksiden fordi vi har å gjøre med enkel sensor enheter, og jeg kommer til å gjøre et sett med analyser det øyeblikket for øyeblikk for å endre opplevelser. Den slags reirlignende opplevelser, en som jeg ser Aerospike bruke saker til.
Robin Bloor: OK, det jeg forventet med tingenes internett, var at du ville begynne å få terskelutløsere og at de ville begynne å lage kaskader av hendelser. Har du sett noe sånt, eller er det ikke noe du har sett enda?
Brian Bulkowski: Dez og jeg var - jeg bare spurte Dezs mening om det da vi før-pratet. Det jeg ennå ikke har sett, er den typen kaskade av ett selskaps data som kaskaderer inn i et annet selskap, at Samsung-kjøleskapet mitt snakker med LG-vaskemaskinen min fordi det bare fant ut at jeg sølte en hel haug sjokolade over hele gulvet, så den typen selskap til selskap enhet etter enhet, tror jeg at jeg fremdeles venter på det når det gjelder Internet of Things. Jeg tror det er noen problemer innen virksomhet og sikkerhet som stort sett ikke er tekniske som må besvares for å se det.
Robin Bloor: OK, desember?
Dez Blanchfield: Jeg har noen veldig sterke synspunkter på det aktuelle poenget faktisk, som jeg bare kort vil bringe inn i samtalen. Jeg tror ofte business og teknologi tror at de faktisk kjører dit etterspørselen kommer fra, men når vi ser på hva som skjedde da iPhone ble en ting, og i mitt sinn var det slags den første mobile enheten, hvis du vil benåde ordspillet, men en enhet som kan bæres rundt som faktisk kan kjøre mange små apper i lommen, og det førte til en betydelig transformasjon av det vi tenkte på å være en datamaskin. Mange mennesker tenker på iPhones eller smarttelefoner, eller Android-telefoner som telefoner, men det er de ikke, de er faktisk bare en liten datamaskin som kjører apper, og en av appene den kjører ringer, og de er ikke samtaler som vi tenker på lenger, de er ikke et analogt punkt-til-punkt-anrop slik Brian fremhevet, de er små pakker som blir dirigert rundt.
Men oftere enn ikke, det vi har sett, er at dette opprøret av smarttelefoner faktisk ikke brukes til å ringe som ofte, sannsynligheten 98% av det jeg gjør på smarttelefonen, ikke er anrop. Det er alt annet enn samtaler, det er apper. Jeg tror denne overlappende effekten - og jeg er opptatt av å få dette til et spørsmål raskt - men den overlappende effekten er faktisk skapt av forbrukere, og faktisk har jeg denne ene lineren som jeg kaster ut ganske ofte for å få en haug med CXOer å sitte oppe i rommet og ta hensyn hvis jeg tror de sovner med presentasjonen jeg holder på, som ikke skjer så ofte, forhåpentligvis.
Jeg sa det på den måten at forstyrrelsen du ser i virksomheten din faktisk ikke blir drevet av teknologi utelukkende, det er oftere enn ikke å bli drevet av kundene dine. Og de sitter på en måte og lurer faktisk, hva mener han der? Så når jeg tenker på bruk av teknologi, mener jeg at vi så USENET, vi så alle disse morsomme tingene skje på internett, men ikke mange spådde det sosiale, og virkningen av det. Alle som ønsker å fortelle alle hva de hadde til frokost, og støyen som skapte og backend-teknologien vi hadde, og så prøver selvfølgelig reklame å fylle den opp med ting.
Jeg tror vi kommer til å se en forbløffende effekt til et punkt der enheter snakker med enheter, forbrukerne bare fanger opp hva det faktisk betyr, og hva det kan gjøre. Du løftet et interessant poeng rundt hvorfor Amazon-knappen ikke vil snakke med Walmart. Jeg kommer til å stille dette spørsmålet, hva skjer når Walmart får en egen knapp, og hva med om de tjue Amazons og Walmarts og andre større distribusjons- og detaljhandelenettverk alle har sine egne knapper? Hvor tar det oss? Spesielt spørsmålet mitt med Brian kommer til å være: “Hvor skal vi med dette helt nye ytelsesparadigmet? Du er i den blødende kanten av det, og du jobber med selskaper som gjør det på både det fysiske infrastrukturnivået så vel som det overførende datanivået. Hvor tar dette oss når denne neste store bølgen kommer? Hva slags innsikt kan du dele rundt det med det som skjer på baksiden av opplevelsen? "
Brian Bulkowski: Jada, måten jeg tenker på mange av disse tingene er å fokusere på brukeropplevelsene og nøyaktig hva du sa, det er brukerne som driver, selv om vi som teknologer og som forretningsfolk kan komme på en smart idé som vi tror brukerne liker, og jeg vil på en måte gå tilbake til Nest-eksemplet. Da søsteren min installerte Nest i huset sitt, sa hun: “Huset mitt er roligere, jeg kan høre ting. Det er ikke bare det at jeg betaler mindre for strøm, ”er hun, men du kan nå ikke rive det reiret ut av hendene hennes fordi hun liker å være i et roligere hus i motsetning til det der oppvarmingen blåser på maksimalt og deretter slå av igjen.
Spørsmålet ender opp med å være, hva er brukeropplevelsene vi kan styrke? Det ender med at vi blir den livskvalitetsopplevelsen, at hvis vi har pengene og vi er i den første verdenen, vil vi betale mye for. Jeg skal gi deg et eksempel fra mitt eget hus, kjæresten min liker kald melk. Hun liker skikkelig kald melk, og så ofte må vi prøve å finne ut hvor i kjøleskapet kommer til å være kaldt, og ikke ha resten av tingene overopphetet. Dette er bra - og jeg sa til kjæresten min: "Vil du betale 10 dollar i måneden for å ha kald melk og ikke for å ha frosne kjøttpålegg?" Hun var som "Absolutt." Og å få $ 10 i måneden av enhver forbruker er tøff.
Jeg tror at vi i disse erfaringene virkelig må følge med på hva som er den forbrukeropplevelsen som virkelig kan bli drevet. Jeg tror det var en del av hemmeligheten bak iPhone. Jeg tror det er en del av hemmeligheten bak Tesla å bygge en bedre bil med alle dataene, avskaffe ideen om en produktsyklus og en årlig utgivelse og gjøre kontinuerlige forbedringer på alle deler. Vi må komme med noen smarte ideer om hvordan du faktisk kan bruke alle disse dataene på en måte som er overbevisende øyeblikk for menneskers liv.
Dez Blanchfield: Ja, det er flott innsikt. Leder videre fra den andre enden av spekteret, som er ekte med den slags ting vi ser nå med det forbrukerne ber om, og alle av oss har noe i huset som er kaldt av dette og varmt av det. Den andre enden av spekteret er da, og vi har sett dette i form av den tradisjonelle "big data-verdenen" der dataoppdrag blir sjeldnere enn tennene på høner og de som er på markedet blir tilbudt mer enn CIO-ene tjener. i noen tilfeller, er det de typene selskaper du jobber med og hvilke typer utvikling du har sett, er det tilfelle at typene utvikler og typen dataarkitekt og nettverksspesialistene, blir de vanskeligere og vanskeligere å finne ? Trenger vi organisasjoner som skal begynne å tenke nå om å komme foran kurven for hvilken type ferdighetssett de trenger i bakenden for typen utviklere og dataarkitekter? Hva ser du på det nivået så langt ferdighetsressursene de vil forstå hvordan de skal bruke denne teknologien til god bruk nå?
Brian Bulkowski: Ja, jeg tror det er en av utfordringene organisasjonene jeg har snakket med. Enten det er en - de verste problemene jeg har hørt om, er faktisk slags større bedrifter, for hvis du sier: "Jeg kommer fra denne store banken, jeg er fra Chase og jeg var en dataarkitekt, " da Vi har verdens østers og lønnen din går opp, så det er dette problemet med å få jobb på et av de stedene fordi det ikke er nok mennesker, og deretter kunne flytte fra jobb til jobb. Jeg hører ikke annet enn den typen problemer, og det er faktisk en av grunnene til at jeg har fokusert Aerospike rundt å bruke verktøy som passer for det aktuelle prosjektgruppen.
I stedet for å prøve å gå inn i et prosjektgruppe og si: "Hei, du bør bruke spørrespråket vårt." Se, hvis de gutta, kjører de buss i disse dager, gutter og gals, og hvis de bruker et bestemt spørrespråk og verktøy, de kommer til å holde seg til det, og jeg kan ikke snakke dem inn i noe annet. Målet mitt er å kunne plassere den typen Aerospike kraft som en database bak det verktøyet de bruker, og det er en del av denne ideen, lysbildene du ser om fremtiden til Poliglot-databasen. Jeg trenger å støtte mønsterene for applikasjon og analyse mellom disse karene, fordi det virkelig er vanskelig å prøve å finne mennesker som har den matematiske bakgrunnen, så vel som de statistiske evnene til å navigere i denne verden.
Dez Blanchfield: En annen interessant ting som folk kanskje ikke er klar over, jeg mener at Aerospike er en veldig sterk aktør i open source-verdenen. Jeg er opptatt av å få en veldig rask innsikt i hva det betyr så langt virksomheten opererer og hva den gjør for deg. Du nevnte at du jobbet direkte med folk som gjør ting helt ned til kjernenivået inni, så Linux-kjernen. Det er noen store aktører som er i dette rommet, og det er noen kjente merkevarer som vi ikke vil nevne, men en organisasjon som Aerospike, i din moderne tids nyere historie, åpen kildekodeopplevelse, hvordan passer det inn i det store bildet og hvilke konkurransefortrinn har du sett som gir deg?
Brian Bulkowski: Jada, da vi gikk over til open source i 2014, gjorde vi det fordi vi innså at en kjerneinfrastruktur, som en database, må være tilgjengelig, den må stole på og en naturlig motvekt mellom den gamle lukkede verden kilde, og når du først har investert i en bestemt database, har disse karene deg pris på teknologisyklus etter teknologisyklus, og det må være en balanse. Vi må kunne få frem versjoner som gjør nye ting, og kanskje det er i en bedriftsversjon, vi må ha en dual-lisensmodell som har en åpen kildekode-versjon for folk som sparker dekkene som driver ideell arbeid, samt en bedriftsversjon som er innehaverlisens og tillater ubegrenset arbeid.
Og selvfølgelig har vi også de høyeste nivåene av hastighet og skala, som en bedriftsversjon. Vi tror på duelllisensmodellen, og det har vært bra for vår virksomhet. Vi vil at folk skal komme i gang med Aerospike, vi vil at små prosjekter skal sparke dekkene, det er superenkelt å bare gå til Amazon, lansere et bekreftelseskript og ha en Aerospike-klynge i gang i løpet av fem minutter. På den annen side ønsker vi å gi mer til bedriftskundene.
Dez Blanchfield: Vi kommer liksom nær toppen av timen, så jeg kommer til å komme tilbake til Rebecca om et øyeblikk, men hvis det bare var en rutebåt du ville kaste der ute, slags råd du vil gi til folk som ønsker å komme seg inn i teknologien du har brakt til markedet og hvordan de skal ta i bruk den. Hva vil du si at det første trinnet for dem er å sortere minst tå og begynne å se på hvordan de skal få et konkurransefortrinn fra plattformen din?
Brian Bulkowski: Visst, en del av meldingen her er at det er nivåer av hastighet og ferdigheter som nå er enkle. Du trenger ikke en Cassandra-klynge med tusen noder for å oppnå millioner av transaksjoner per sekund. Du kan gjøre det selv i de første fasene av prosjektet. Så ting er mye enklere enn de pleide å være. Så er det andre rådet du må komme på, akkurat som du sier, matematiske forretningsprosesser for kundemengdemodeller som bruker alle disse dataene, så den gode nyheten er at dataene er tilgjengelige, dårlige nyheter er at du faktisk må finne noen mønstre og noen overbevisende brukssaker.
Dez Blanchfield: Ja, gode råd, så jeg kommer til å gi tilbake til Rebecca nå. Tusen takk for det, det var en flott liten prat om teknologien, jeg setter pris på det.
Rebecca Jozwiak: Takk, Dez. Jeg har et par gode spørsmål fra publikum. La meg kaste opp dette lysbildet. Jeg vet at du snakket om systemet med poster og stordrammer, men hvor ofte ser du absolutt avlastning, eller er replikasjonen en sluttforsoning, slags hva du ser mer av?
Brian Bulkowski: Det vi ser i Aerospike bruker en NoSQL-database foran det endelige dags forsoningssystem. Du trenger intradag, riktig svar. Du kan ikke ha feil svar, og det var det Robin sa om eiendeler som ikke blir verdsatt, men forretningsprosessene rundt de juridiske kravene til forsoning kan bli ganske kompliserte, og det er flere tiår med teknologi og flere tiår med lov og rettspraksis rundt å gjøre forsoning. Så det vi ser på Aerospike er at du kommer til å gjøre algoritmene dine i en varmere database med flere transaksjoner per sekund. Men av juridiske grunner trenger du absolutt et forsoningssystem som har vært gjennom de juridiske prosessene. Vi ser begge deler, og vi ser at dette i hovedsak er den to-lags IT-praksisen som den blir utsatt av mennesker som Anderson Consulting og Gartner til en viss grad. Det ser vi mye av.
Rebecca Jozwiak: Ok, bra. Noen andre viste interesse for akkurat dette lysbildet, han sa at det var veldig interessant og lurte på om du bare kunne gå inn på litt mer sammenligning av flash kontra i minne.
Brian Bulkowski: Jada, vel, la meg ta en rask sidestang, igjen, jeg vet at vi er nær tidenes slutt. Vel flash er minne - det er chips - Jeg har en tendens til å tenke på RAM. Så RAM har spesielle egenskaper, krever mye krefter, det er veldig bra i tilfeldige skrivinger så vel som tilfeldig avlesninger. Der NAND er i stand til hurtig tilfeldige lesninger og lavere kraft, men det er veldig dårlig ved tilfeldige skriver. Det er noen subtile forskjeller i hvordan disse to brikkene fungerer på litografinivå, som skaper en rekke tekniske forskjeller.
I tilfelle hvor du gjør analyser og du må hoppe over mye data, eller i Aerospikes tilfelle, der du har indekser, er indekser fremdeles veldig bra å bruke i RAM på grunn av parallellitet og tilfeldig tilgang. Et høyere nivå av tilfeldig tilgang er nødvendig. I Aerospike finner vi imidlertid å bruke disse indeksene til å finne et bestemt objekt eller en bunke med data, det er det rette stedet å nå ut til et NAND fordi det blir en slags større butikk under indeksene. Dette er en transaksjon til en lagringsenhet, men likevel etter å ha gjort en rekke potensialer og filtre i indekseringssystemet ditt.
Rebecca Jozwiak: Ok, bra. Og da, jeg vet at vi allerede har snakket mye om IoT og en deltakerkommentar sa at IoT stort sett er gunstig, men er selskaper, offentlige enheter og utviklere som vokser sikkert og sikrer data i samme takt, tror du?
Brian Bulkowski: Kanskje Dez, vil du hoppe inn?
Dez Blanchfield: Ja, jeg er glad for å hoppe inn i den. Jeg tror svaret er nei. Faktisk er en av mine favorittkast-linjer om dette emnet veldig, veldig kort at jeg tror eksplosjonen av maskin til maskin og generelle tingenes internett, kommunikasjon og sikkerhet, risikoen rundt det, vi er på det punktet der myndighetene kan ikke følge med på endringsgraden. Og faktisk vet vi at mange organisasjoner ikke kan følge med på endringshastigheten. Faktisk, hvis jeg parafraserte det, er endringshastigheten i dag så stor at organisasjonene må sprint bare for å følge med, men de må sprint i flere løp. Jeg tror ikke at loven, og jeg tror ikke regjeringen generelt, verken statlig eller føderalt nivå, klarer å følge med på endringsraten.
Nå er de generelle rådene mine til folk en slags handling nå og ber om tilgivelse senere. Det har vært mange eksempler på det i det siste. De vil ta igjen, men jeg tror det virkelig er opp til bedrifts- og teknologileverandører å innovere på dette området og sikre at vi er kjent med sikkerhetsrisikoer eller personvernrisikoer, og at vi må håndtere disse. Banker spesielt, som du nevnte, når du tenker på hva en bankorganisasjon tradisjonelt har gjort med ting som anti-hvitvasking og kjenner din klient, AML / KYC-utfordringen, pleide det å være at hvert tredje til femte år ville vi prøve og møte samsvar.
Nå tror jeg det må bygges inn i hver eneste transaksjon. Du har alltid vært i stand til å gjøre det på budnivå med annonsering og aksje- og obligasjons- og aksjehandel, jeg tror vi er på det punktet hvor ytelsen du bringer med Aerospike-plattformen gjør at vi nå kan tenke på hvordan vi bringer personvern, hvordan bringer vi sikkerhet inn i den umiddelbare sanntids beslutningskjeden? Og så er svaret nei, jeg tror ikke regjeringer holder følge. Jeg tror selskaper trenger å følge med, og jeg tror vi må handle nå og be om tilgivelse senere.
Brian Bulkowski: La meg også legge til et par poeng. Gutta jeg har kontakt med, teknologiselskapene jeg har med, er veldig bevisste på å sørge for at de er på rett side av loven, og en god del av diskusjonen er, er dette PII, kan jeg bruke dette, hvordan er Bruker jeg denne spesielle delen av data? Hva var dets forsyn, og er dette en beskyttet beslutning eller erfaring? Hvordan gjør jeg alt dette? Så det er den gode nyheten. Noen ganger lurer jeg noen ganger på diskusjonen vår som et samfunn rundt dit vi er på vei, og om til og med samfunnsdiskusjonen vår er på et passende nivå når det gjelder å bruke de nye mulighetene fra IoT helt opp til maskinlæring, noe som er den eneste måten å sortere gjennom datamengdene vi har. Men den gode nyheten er at gutta jeg snakket med virkelig er på høyresiden for å prøve å gjøre rett ved de juridiske beslutningene vi har tatt.
Rebecca Jozwiak: Dette er noen veldig gode svar fra dere begge, og jeg er helt enig. Jeg tror ikke sikkerheten beveger seg i like raskere tempo som teknologiutvikling, spesielt når det gjelder tingenes internett, men jeg må tenke at folk gjør sitt beste og forhåpentligvis kommer vi dit. Det er alltid litt vanskelig å ligge ti skritt foran cybertyver og cyberkriminelle, men vi kommer dit.
Vel folkens, vi har gått åtte minutter forbi toppen av timen. Jeg vil takke våre gjester Brian Bulkowski fra Aerospike og Dez Blanchfield og Robin Bloor. Tusen takk. Du kan alltid finne arkivene våre på insideanalysis.com, SlideShare, YouTube, vi har mange gode webcasts som kommer folk, det har vært en travel måned. Det kommer til å bli en travel måned neste måned, så følg med, og vi håper å se deg neste gang. Takk folkens, farvel.
