[RIPRODUZIONE DI BRANI MUSICALI] RICK Houlihan: Va bene. Salve a tutti. Il mio nome è Rick Houlihan. Io sono un anziano preside Le soluzioni architetto AWS. Mi concentro su NoSQL e Tecnologie DynamoDB. Sono qui oggi per parlare un po 'di quelle. 

Il mio background è principalmente nello strato di dati. Ho passato metà della mia sviluppo carriera scrivendo dati, accesso ai dati, soluzioni per varie applicazioni. Sono stato nella virtualizzazione Nube per circa 20 anni. Quindi, prima che il Cloud era il Cloud, abbiamo usato per chiamare l'utility computing. E l'idea è stata, è come PG & E, si paga per ciò che si utilizza. Oggi la chiamiamo la nuvola. 

Ma nel corso degli anni, ho lavorato per un paio di aziende probabilmente non avete mai sentito parlare. Ma ho compilato una lista di tecnica realizzazioni, credo che ci si dice. Ho otto brevetti in sistemi cloud virtualizzazione, progettazione di microprocessori, elaborazione di eventi complessi, e altre aree. 

Così in questi giorni, mi concentro soprattutto su NoSQL tecnologie e la prossima generazione Database. E questo è in genere quello che ho intenzione di essere qui a parlare con voi oggi circa. Allora, cosa ci si può aspettare da questa sessione, andremo attraverso una breve Storia di elaborazione dei dati. E 'sempre utile capire da dove veniamo e perché siamo dove siamo. E parleremo un po ' po 'di tecnologia NoSQL dal punto di vista fondamentale. 

Ci metteremo in alcuni dei l'interno DynamoDB. DynamoDB c'è sapore di AWS. E 'completamente gestito e soluzione NoSQL hosted. E parleremo un po 'di tavola struttura, API, tipi di dati, indici, e alcune funzioni interne di tale tecnologia DynamoDB. Arriveremo in alcuni dei design modelli e best practice. Parleremo di come si utilizzare questa tecnologia per qualche di applicazioni di oggi. E poi parleremo un po ' circa l'evoluzione o la comparsa di un nuovo paradigma di programmazione chiamati applicazioni event-driven e come DynamoDB suona in quello. E vi lasciamo un po 'di una architettura di riferimento discussione così possiamo parlare di alcuni dei i modi è possibile utilizzare DynamoDB. 

Quindi, prima off-- questa è una domanda Ho sentito un sacco è, che cosa è un database. Un sacco di gente pensa che sanno cosa sia un database. Se Google, vedrai questo. Si tratta di un un insieme strutturato di dati trattati in un computer, in particolare uno che è accessibile in vari modi. Suppongo che sia una buona definizione di un moderno database. Ma non mi piace, perché implica un paio di cose. Implica struttura. E ciò implica che è su un computer. E i database non hanno esistono sempre sui computer. Basi di dati realmente esistito in molti modi. 

Quindi una migliore definizione di un database è qualcosa di simile. Un database è un organizzato meccanismo di archiviazione, la gestione, e il recupero di informazioni. Questo è da About.com. Così mi piace questo perché in realtà i colloqui su un database di essere un repository, un repository di informazioni, non necessariamente qualcosa che si trova su un computer. E nel corso della storia, abbiamo non hanno sempre avuto i computer. 

Ora, se io chiedo la media sviluppatore oggi ciò che è un database, che è la risposta che ottengo. Da qualche parte posso attaccare roba. Destra? Ed è vero. Ma è un peccato. Poiché il database è davvero la fondazione delle app moderno. E 'il fondamento di ogni applicazione. E come si costruisce che banca dati, come si struttura che i dati sta per dettare come questo applicazione esegue come si scala. 

Così un sacco del mio lavoro oggi si occupa di ciò che accade quando gli sviluppatori adottare questo approccio e la gestione delle conseguenze di un'applicazione è ora scalare oltre l'originale intento e la sofferenza dalla cattiva progettazione. Così si spera quando si a piedi oggi, ti un paio di strumenti in la cintura che ti terrà dal fare quegli stessi errori. Tutto ok. Quindi parliamo di un po 'di la timeline di tecnologia di database. Penso che ho letto un articolo non molto tempo fa e ha detto qualcosa sul lines-- si tratta di una dichiarazione molto poetico. Ha detto che la storia del trattamento dei dati è pieno di alte filigrane di abbondanza di dati. OK. Ora, credo che una specie di vero. Ma io in realtà guardare è come la storia è in realtà piena con high watermark di pressione dati. Perché la velocità di trasmissione dati di ingestione non va giù. Si arriva solo fino. 

E l'innovazione si verifica quando vediamo pressione dati, che è la quantità di dati che è Ora venendo al sistema. E non può essere elaborato efficiente nel tempo o di costo. Ed è allora che cominciamo guardare pressione dati. 

Così, quando guardiamo il primo database, questo è quello che è stato tra le nostre orecchie. Siamo tutti nati con esso. E 'un bel database. Ha una elevata disponibilità. E 'sempre su. È sempre possibile ottenerlo. 

Ma è solo utente. Non posso condividere i miei pensieri con voi. Non è possibile ottenere i miei pensieri quando vuoi. E la loro abilitiy non è così buono. Ci dimentichiamo le cose. Ogni tanto, uno di noi foglie e si sposta verso un'altra esistenza e perdiamo tutto che era in quel database. In modo che non è affatto buono. 

E questo ha funzionato bene nel corso del tempo quando siamo tornati nel corso della giornata quando tutti abbiamo veramente bisogno di sapere è dove stiamo andando ad andare domani o dove ci riuniamo il cibo migliore. Ma, come abbiamo cominciato a crescere come la civiltà e il governo ha iniziato a venire in essere, e le aziende hanno cominciato a evolversi, abbiamo iniziato a capire che necessario un po 'più di quello abbiamo potuto mettere nella nostra testa. Tutto ok? 

Avevamo bisogno di sistemi di registrazione. Avevamo bisogno di essere posti in grado memorizzare i dati. Così abbiamo iniziato la scrittura di documenti, la creazione di biblioteche e archivi. Abbiamo iniziato lo sviluppo di un sistema una contabilità libro mastro. E quel sistema di conteggio contabilità correva il mondo per molti secoli, e forse anche millenni come abbiamo tipo cresciuti al punto dove il carico di dati ha superato la capacità di tali sistemi essere in grado di contenere. 

E questo è realmente accaduto nel 1880. Destra? Nel Censimenti 1880. Questo è davvero in cui la svolta puntare trattamento moderno. Questo è il punto in che la quantità di dati che veniva riscossa dalle Governo degli Stati Uniti ha ottenuto al punto dove ci sono voluti otto anni per elaborare. 

Ora, otto anni-- come si sa, il censimento corse ogni 10 anni-- quindi è abbastanza evidente che da tempo siamo ottenuto il censimento 1890, la quantità di dati che stava per essere elaborati da parte del governo è stato andando a superare i 10 anni che avrebbe portato al lancio del nuovo censimento. Questo è stato un problema. 

Così un ragazzo di nome Herman Hollerith è arrivato e ha inventato unità disco pugno carte, lettore di schede perforate, schede perforate tabulatore, e le regole di confronto i meccanismi di questa tecnologia. E quella società che ha formato alla tempo, insieme con un paio di altri, in realtà è diventato uno dei pilastri di una piccola azienda che conosciamo oggi chiamato IBM. 

Così IBM originariamente era in il database aziendale. E questo è davvero quello che hanno fatto. Hanno fatto l'elaborazione dei dati. 

Come così la proliferazione di punch carte, un ingegnoso meccanismi di essere in grado di sfruttare tale la tecnologia per il polling set di risultati ordinati. Si può vedere in questa foto ci abbiamo un little-- è un po 'small-- ma si può vedere un meccanismo meccanico molto ingegnoso dove abbiamo un mazzo di carte pugno. E presa di qualcuno un piccolo cacciavite e attaccare attraverso il slot e sollevandola per ottenere quella partita, che impostati risultati ordinati. 

Questo è un aggregato. Facciamo questo per tutto il tempo oggi nel computer, dove lo si fa nel database. Abbiamo usato per farlo manualmente, giusto? Persone mettere insieme queste cose. E fu la proliferazione di queste schede perforate in quello che abbiamo chiamato tamburi dati e bobine di dati, nastro di carta. 

L'industria di trasformazione dei dati ha preso una lezione dai pianole. Giocatore pianoforti indietro la fine del secolo utilizzato per utilizzare bobine di carta con slot a dire che i tasti da suonare. In modo che la tecnologia è stata adattata eventualmente per memorizzare dati digitali, perché potrebbero mettere tali dati su quelle bobine di nastro di carta. 

Ora, come risultato, i dati è stato come actually-- Accedendo a questo dati sono stati direttamente dipende da come l'avete memorizzato. Quindi, se ho messo i dati su un nastro, Ho avuto accedere ai dati in modo lineare. Ho avuto a rotolare tutto nastro per accedere a tutti i dati. Se metto i dati in pugno carte, ho potuto accedervi in poco più casuale moda, forse non così velocemente. 

Ma c'erano limiti nel modo in cui l'accesso ai dati in base a come è stato immagazzinato. E quindi questo è stato un problema entrare nei anni '50. Ancora una volta, possiamo iniziare a vedere che come noi sviluppare nuove tecnologie per elaborare i dati, a destra, si apre la porta a nuove soluzioni, per i nuovi programmi, nuovi domande di tali dati. E davvero, la governance potrebbe essere stato il motivo perché abbiamo sviluppato alcuni di questi sistemi. Ma gli affari è diventato rapidamente il driver dietro l'evoluzione del database e moderna il file system moderno. 

Così la prossima cosa che si avvicinò era negli anni '50 è il file system e la sviluppo di memoria ad accesso casuale. Questo è stato bello. Ora, all'improvviso, possiamo mettere la nostra file ovunque su questi hard disk e siamo in grado di accedere a questi dati in modo casuale. Possiamo analizzare che informazioni dai file. E abbiamo risolto tutto il mondo problemi con l'elaborazione dei dati. 

E che è durato circa 20 o 30 anni fino alla evoluzione del database relazionale, che è quando il mondo ha deciso che ora bisogno di avere un repository che sconfigge la distesa di dati attraverso file sistemi che abbiamo costruito. Destra? Troppi dati distribuiti in troppi luoghi, la de-duplicazione dei dati, e il costo dello storage è stato enorme. 

Negli anni '70, la risorsa più costoso che un computer aveva era lo stoccaggio. Il processore era visto come un costo fisso. Quando compro la scatola, la CPU fa un certo lavoro. E sta per essere filatura se in realtà è lavoro oppure no. Questo è davvero un costo sommerso. 

Ma quello che mi è costato un affari è di stoccaggio. Se devo comprare più dischi prossimo mese, questo è un vero e proprio costo che pago. E che lo stoccaggio è costoso. 

Ora siamo veloci in avanti 40 anni e abbiamo un problema diverso. Il calcolo è ora il risorsa più costoso. Il deposito è a buon mercato. Voglio dire, si può andare in qualsiasi punto della Cloud e possiamo trovare di stoccaggio a basso costo. Ma quello che non riesco a trovare è calcolo economico. 

Così l'evoluzione di oggi La tecnologia, di tecnologia di database, è molto concentrato intorno database distribuiti che non soffrono di lo stesso tipo di scala limitazioni di database relazionali. Parleremo un po 'di che cosa significa realmente. 

Ma uno dei motivi e il driver dietro questo-- noi ha parlato della pressione dei dati. Pressione dati è qualcosa che spinge l'innovazione. E se si guarda al di sopra negli ultimi cinque anni, questo è un grafico di quello dei dati carico in tutta l'azienda in generale sembra che negli ultimi cinque anni. 

E la regola generale questi days-- se si va Google-- è il 90% dei dati che memorizziamo oggi, ed era generato nel corso degli ultimi due anni. OK. Ora, questa non è una tendenza che è nuovo. Questa è una tendenza che è stato uscire per 100 anni. Da quando Herman Hollerith sviluppato la scheda perforata, abbiamo costruito repository di dati e la raccolta di dati a velocità fenomenali. 

Così nel corso degli ultimi 100 anni, abbiamo visto questa tendenza. Questo non cambierà. Andando avanti, stiamo andando a vedere questo, se non una tendenza accelerata. E si può vedere ciò che sembra. 

Se un'impresa nel 2010 ha avuto un terabyte di dati in gestione, oggi che significa che sono gestione di 6,5 petabyte di dati. Questo è 6.500 volte più dati. E so che questo. Io lavoro con queste aziende ogni giorno. Cinque anni fa, ho sarebbe parlare con le aziende che avrebbe parlare con me di quello che un dolore che è quello di gestire terabyte di dati. E avrebbero parlato a me su come vediamo che questa è destinata probabilmente essere una o due petabyte entro un paio di anni. 

Queste stesse aziende oggi ho un incontro con, e stanno parlando con me circa il problema stanno avendo lì la gestione decine, 20 petabyte di dati. Così l'esplosione del Dati del settore sta guidando l'enorme necessità di soluzioni migliori. E il database relazionale è semplicemente non vivere fino alla domanda. 

E quindi c'è una lineari la correlazione tra la pressione dei dati e innovazione tecnica. La storia ci ha mostrato questo, che nel tempo, ogni volta che il volume dei dati che deve essere processato supera la capacità del sistema di elaborare in un tempo ragionevole o ad un costo ragionevole, poi le nuove tecnologie sono inventato per risolvere questi problemi. Queste nuove tecnologie, a sua volta, aprire la porta a un'altra serie di problemi, che sta raccogliendo ancora più dati. 

Ora, non stiamo andando a fermare tutto questo. Destra? Non stiamo andando a fermare tutto questo. Come mai? Poiché non è possibile sapere tutto c'è da sapere nell'universo. E finché siamo stati vivi, in tutta la storia dell'uomo, abbiamo sempre spinto a saperne di più. 

Così sembra che ogni pollice ci muoviamo lungo il sentiero della scoperta scientifica, stiamo moltiplicando la quantità di dati che abbiamo bisogno di elaborare in modo esponenziale come scopriamo sempre più sul funzionamento interno della vita, su come funziona l'universo, su guidare la scoperta scientifica, e l'invenzione che stiamo facendo oggi. Il volume di dati appena aumenta continuamente. Quindi essere in grado di affrontare questo problema è enorme. 

Così una delle cose guardiamo come NoSQL perché? In che modo NoSQL risolvere questo problema? Beh, database relazionali, Structured Query Language, SQL-- che è davvero un costrutto della relazionale database-- queste cose sono ottimizzato per la conservazione. 

Già negli anni '70, ancora una volta, disco è costoso. L'esercizio provisioning dello storage in azienda è senza fine. Lo so. Ho vissuto. Ho scritto driver di archiviazione per un società superserver Enterprised indietro negli anni '90. E la linea di fondo è un'altra svinatura array di storage era solo qualcosa che accaduto ogni giorno in azienda. E non si è mai fermato. Archiviazione maggiore densità, la domanda per lo stoccaggio ad alta densità, e per lo storage più efficiente devices-- non è mai fermato. 

E NoSQL è una grande tecnologia perché normalizza i dati. Si de-duplica dei dati. Si mette i dati in una struttura che è agnostico per ogni tipo di accesso. Più applicazioni che possono colpire Database SQL, eseguire query ad hoc, e ottenere i dati nella forma che necessario elaborare per i loro carichi di lavoro. Che suona fantastico. Ma la linea di fondo è con qualsiasi sistema, se è agnostica a tutto, è ottimizzato per nulla. ok? 

Ed è quello che si ottiene con il database relazionale. È ottimizzato per la conservazione. È normalizzato. E 'relazionale. Supporta le query ad hoc. Ed esso e scale in verticale. 

Se ho bisogno di ottenere un database SQL più grande o un database SQL più potente, Vado comprare un pezzo più grande di ferro. ok? Ho lavorato con un sacco di clienti che sono state con importanti aggiornamenti nella loro infrastruttura di SQL solo per scoprire sei mesi più tardi, che stanno colpendo il muro di nuovo. E la risposta da Oracle o MSSQL o chiunque altro è ottenere una scatola più grande. Beh, prima o poi, non si può comprare un scatola più grande, e questo è vero problema. Abbiamo bisogno di cambiare realmente le cose. Allora, dove funziona? Funziona bene per linea analisi OLAP, tipo i carichi di lavoro. E questo è davvero dove SQL appartiene. Ora, è oggi utilizzato in molti on-line transazionale lavorazione di tipo applicazioni. E funziona bene in un certo livello di utilizzazione, ma semplicemente non scala il modo in cui lo fa NoSQL. E parleremo un po ' po 'su perché. 

Ora, NoSQL, d'altra parte, è più ottimizzato per calcolo. ok? Non è agnostica di il modello di accesso. È ciò che chiamiamo de-normalizzata struttura o una struttura gerarchica. I dati in un database relazionale è uniti da più tabelle per produrre l'opinione che si ha bisogno. I dati in un database NoSQL è memorizzato in un documento che contiene la struttura gerarchica. Tutti i dati che normalmente sarebbe uniti per produrre quella vista è memorizzato in un unico documento. E parleremo un po 'di come funziona in un paio di grafici. 

Ma l'idea è che si memorizza i tuoi dati come questi punti di vista istanziato. ok? Si scala orizzontalmente. Destra? Se ho bisogno di aumentare la dimensioni del mio gruppo NoSQL, Non ho bisogno di ottenere una scatola più grande. Ho un'altra scatola. E io CLUSTER quelli insieme, e posso coccio tali dati. Parleremo un po ' cosa sharding è, di essere in grado di scalare quel database su più dispositivi fisici e rimuovere la barriera che mi impone di scalare verticalmente. 

Quindi è davvero costruito per linea elaborazione delle transazioni e la scala. C'è una grande differenza qui tra reporting, giusto? Segnalazione, non so il domande ho intenzione di chiedere. Destra? Reporting-- se qualcuno da il mio ufficio marketing vuole solo-- come molti dei miei clienti avere questa caratteristica particolare che comprato su questo giorno-- non so cosa interrogare hanno intenzione di chiedere. Così ho bisogno di essere agnostico. 

Ora, in una linea un'applicazione transazionale, So quello che sto chiedendo domande. Ho costruito la domanda di un flusso di lavoro molto specifico. ok? Quindi, se ho ottimizzare i dati memorizzare per sostenere che il flusso di lavoro, che sta per essere più veloce. Ed è per questo che può NoSQL davvero accelerare la consegna di quei tipi di servizi. Tutto ok. 

Quindi stiamo per entrare in un po 'di teoria qui. E alcuni di voi, i vostri occhi potrebbe ripristinare un po '. Ma cercherò di tenerlo come di alto livello possibile. Quindi, se siete in progetto gestione, c'e ' un costrutto chiamato triangolo di vincoli. OK. Il triangolo di vincoli dettati non si può avere tutto ogni volta. Non può avere la vostra torta e la moglie ubriaca. Quindi, nella gestione dei progetti, quel triangolo vincoli è che si può avere a buon mercato, si può avere fretta, o si può avere una buona. Prendine due. Poiché non è possibile avere tutti e tre. Destra? OK. 

Così avete sentito parlare di questo un sacco. Si tratta di un vincolo tripla, triangolo triplo vincolo, o il triangolo di ferro è oftentimes-- quando si parla di project manager, faranno parlare di questo. Ora, database hanno proprio triangolo di ferro. E il triangolo di ferro dei dati è quello che chiamiamo teorema cap. ok? 

PAC dettami teorema come funzionano i database sotto una condizione molto specifica. E parleremo ciò che tale condizione sia. Ma i tre vertici del triangolo, per così dire, sono C, consistenza. ok? Così in CAP, consistenza significa che tutti i clienti che possono accedere alla banca dati avrà sempre molto visione coerente dei dati. Andando di nessuno vedere due cose diverse. ok? Se vedo il database, Vedo la stessa vista come il mio compagno che vede lo stesso database. Questa è la coerenza. 

Disponibilità significa che se la database online, se può essere raggiunto, che tutti i clienti sarà sempre essere in grado di leggere e scrivere. ok? Così ogni client che in grado di leggere il database sarà sempre in grado di lettura dati dati e scrivere. E se questo è il caso, si tratta di un sistema disponibile. 

E il terzo punto è quello che chiamiamo tolleranza partizione. ok? Mezzi di tolleranza Partition che il sistema funziona bene nonostante rete fisica pareti divisorie tra i nodi. ok? Quindi i nodi del cluster non può parlano tra loro, che cosa succede? Tutto ok. 

I database relazionali così prego-- è possibile scegliere due di questi. OK. I database relazionali così scegliere essere coerenti e disponibile. Se la partizione avviene tra le DataNodes nell'archivio dati, il database si blocca. Destra? Semplicemente va giù. OK. 

E questo è il motivo per cui hanno di crescere con le scatole più grandi. Destra? Perché c'è no-- solito, un cluster database, non c'è molto molti di loro che operano in questo modo. Ma la maggior parte dei database scala verticalmente all'interno di un unico contenitore. Perché hanno bisogno di essere coerente e disponibili. Se una partizione venisse iniettata, allora si dovrà fare una scelta. Devi fare una scelta tra essere coerente e disponibile. 

Ed è quello che i database NoSQL fanno. Tutto ok. Quindi un database NoSQL, esso è disponibile in due versioni. Noi have-- bene, è disponibile in molti sapori, ma si tratta di due di base characteristics-- cosa noi chiameremmo dati del CP, o un tolleranza costante e la partizione sistema. Questi ragazzi fanno la scelta che quando i nodi perdono il contatto con l'altro, non stiamo andando per consentire persone a scrivere più. ok? 

Fino a quel divisorio viene rimosso, l'accesso in scrittura è bloccato. Ciò significa che non sono disponibili. Sono coerente. Quando vediamo che partizione iniettare se stesso, siamo ora coerente, perché non stiamo andando per consentire la variazione dei dati su due lati della partizione indipendente a vicenda. Dovremo ristabilire la comunicazione prima di qualsiasi aggiornamento il dato è permesso. ok? 

Il sapore successivo sarebbe un sistema AP, o partizionato un disponibile e sistema di tolleranza. Questi ragazzi non si preoccupano. Destra? Qualsiasi nodo che ottiene un scriviamo, noi lo prenderemo. Così sto replica dei miei dati in più nodi. Questi nodi ottengono un cliente, cliente viene in, dice, ho intenzione di scrivere alcuni dati. Nodo dice, nessun problema. Il nodo accanto a lui si una scrittura sullo stesso disco, ha intenzione di dire di no problema. Da qualche parte indietro sul back-end, che i dati sta per replicare. E poi qualcuno sta per realizzare, uh-oh, sistema realizzerà, uh-oh, c'è stato un aggiornamento di due parti. Cosa facciamo? E quello che fanno, allora è fanno qualcosa che permette loro di risolvere tale stato i dati. E parleremo che nella tabella seguente. 

Cosa da sottolineare qui. E io non ho intenzione di arrivare troppo molto in questo, perché questo riceve in teoria i dati in profondità. Ma c'è un transazionale quadro che viene eseguito in un sistema relazionale che mi permette di fare in modo sicuro gli aggiornamenti di più entità nel database. E si verificheranno tali aggiornamenti tutto in una volta o per niente. E questo si chiama transazioni ACID. ok? 

ACID ci dà atomicità, consistenza, isolamento e durata. ok? Ciò significa atomici, le transazioni, tutto i miei aggiornamenti o avvengono o non lo fanno. Coerenza significa che la banca dati sarà sempre essere portato in un consistente stato dopo un aggiornamento. Non potrò mai lasciare il database in uno cattivo stato dopo l'applicazione di un aggiornamento. ok? 

Quindi è un po 'diverso di consistenza PAC. Coerenza PAC significa tutto il mio i clienti possono sempre vedere i dati. Consistenza ACIDO significa che quando una transazione è fatto, i dati di buono. I miei rapporti sono tutti buoni. Io non ho intenzione di eliminare una riga padre e lasciare un po 'di bambini orfani in qualche altra tabella. Non può succedere se sono coerente in una transazione acida. 

Isolamento significa che le operazioni avverrà sempre uno dopo l'altro. Il risultato finale dei dati sarà lo stesso stato come se tali operazioni che sono stati emessi contemporaneamente sono stati eseguiti in serie. Quindi è concorrenza controllo nel database. Quindi, fondamentalmente, non riesco a incrementare il stesso valore due volte con due operazioni. 

Ma se dico aggiungere 1 a questo valore, e due operazioni sono disponibili in e cercare di farlo, si è intenzione di arrivare prima e l'altro di un intenzione di arrivare dopo. Così, alla fine, ho aggiunto due. Vedete cosa voglio dire? OK. 

La durabilità è abbastanza semplice. Quando la transazione è riconosciuta, e ' sta per essere lì anche se il sistema va in crash. Quando questo sistema recupera, che operazione che è stato commesso è in realtà sta per essere lì. Ecco, questo è le garanzie di transazioni ACID. Quelli sono molto carino garanzie disporre su un database, ma vengono a quel costo. Destra? 

Perché il problema con questo quadro è se c'è una partizione nei dati insieme, devo prendere una decisione. Sto andando ad avere per consentire aggiornamenti su un lato o l'altro. E se questo accade, allora non ho più intenzione sono per poter mantenere tali caratteristiche. Non saranno coerenti. Non saranno isolati. Questo è dove si rompe per i database relazionali. Questa è la ragione relazionale database scala verticalmente. 

D'altra parte, abbiamo quello che chiama tecnologia di base. E questi sono i database NoSQL. Tutto ok. Così abbiamo la nostra CP, i database AP. E questi sono ciò che si chiama fondamentalmente disponibile, soft stato, alla fine coerente. ok? 

Fondamentalmente disponibile, perché sono tolleranti partizione. Saranno sempre lì, anche se non c'è una partizione di rete tra i nodi. Se posso parlare con un nodo, sono sarà in grado di leggere i dati. ok? Potrei non essere sempre in grado di scrivere dati se io sono una piattaforma coerente. Ma sarò in grado di leggere i dati. 

Lo stato morbido indica che quando ho letto che i dati, potrebbe non essere la stessa di altri nodi. Se un diritto è stato rilasciato su un nodo da qualche altra parte nel cluster e non è stato replicato in tutto il grappolo ma quando ho letto che i dati, questo stato potrebbe non essere coerente. Tuttavia, sarà finalmente coerente, il che significa che quando una scrittura è fatto per il sistema, si replicherà attraverso i nodi. E alla fine, quello stato sarà portato in ordine, e sarà uno stato coerente. 

Ora, CAP teorema davvero gioca in una sola condizione. Tale condizione è quando questo accade. Perché ogni volta che è operante in modalità normale, non c'è nessuna partizione, tutto è coerente e disponibile. Ti preoccupi solo di PAC quando abbiamo quella partizione. Quindi questi sono rari. Ma come il sistema reagisce quando quelli si verificano dettare quale tipo di sistema abbiamo a che fare. 

Quindi, diamo un'occhiata a ciò che che assomiglia per i sistemi di AP. ok? Sistemi di AP sono di due tipi. Vengono nel sapore che è un Master, 100%, sempre a disposizione. E vengono in altro sapore, che dice: sai cosa, ho intenzione di preoccuparsi di questa cosa partizionamento quando si verifica una partizione reale. In caso contrario, ci sara 'primario nodi che sta andando a prendere i diritti. ok? 

Quindi, se qualcosa di simile a Cassandra. Cassandra sarebbe un maestro padrone, andiamo a scrivere ad ogni nodo. Allora, cosa succede? Così ho un oggetto nella database esistente su due nodi. Chiamiamolo quell'oggetto S. Così abbiamo statale per S. Abbiamo alcune operazioni su S che sono in corso. Cassandra mi permette di scrivere a più nodi. Quindi diciamo che ho un scrivere per s a due nodi. Ebbene, ciò che finisce accadendo è noi chiamiamo che un evento di partizionamento. Non ci può essere un partizione rete fisica. Ma a causa del disegno del sistema, è in realtà il più presto partizionamento come ottengo una scrittura su due nodi. Non mi sta costringendo a scrivere tutto attraverso un nodo. Sto scrivendo su due nodi. ok? 

Così ora ho due stati. ok? Cosa succederà è prima o poi, ci sara 'un evento di replica. Ci sara 'quello che abbiamo chiamato un recupero del divisorio, che è dove questi due Stati tornano insieme e ci sara 'un algoritmo che corre all'interno del database, decide cosa fare. ok? Per impostazione predefinita, ultimo aggiornamento vince nella maggior parte dei sistemi di AP. Così di solito c'è un algoritmo predefinito, cosa che chiamano un callback funzione, cosa che sarà chiamato quando questa condizione viene rilevato ad eseguire qualche logica per risolvere quel conflitto. ok? Il callback di default e di default resolver nella maggior parte dei database AP è, indovinate un po ', timestamp vince. Questo era l'ultimo aggiornamento. Ho intenzione di mettere che si aggiornano in là. Posso scaricare questo disco che ho dumping fuori in un registro per il recupero in modo che l'utente possa tornare più tardi e dire: ehi, c'è stata una collisione. Quello che è successo? E si può effettivamente scaricare un record di tutte le collisioni e le rollback e vedere cosa succede. 

Ora, come utente, è anche possibile includere logica in quella richiamata. Così si può cambiare la situazione operazione di richiamata. Si può dire, ehi, voglio per rimediare questi dati. E voglio cercare di unire i due record. Ma questo sta a voi. Il database non sa come farlo per impostazione predefinita. La maggior parte del tempo, l'unica cosa database sa come fare è dire, questo era l'ultimo record. Questo è quello che sta andando a vincere, e questo è il valore che ho intenzione di mettere. Una volta che il recupero delle partizioni e la replica si verifica, abbiamo il nostro Stato, che è ora S primo, che è lo stato di unione di tutti quegli oggetti. Così i sistemi di AP hanno questo. Sistemi CP non necessitano preoccuparsi di questo. Perché appena arriva una partizione in gioco, hanno semplicemente smettere di prendere scrive. ok? Ecco, questo è molto facile fare con l'essere coerente quando non si accetta eventuali aggiornamenti. Questo è con i sistemi CP fanno. Tutto ok. 

Così parliamo un po ' po 'di modelli di accesso. Quando si parla di NoSQL, è tutto sul modello di accesso. Ora, SQL è ad hoc, le query. E 'archivio relazionale. Noi non dobbiamo preoccuparci circa il modello di accesso. Scrivo una domanda molto complessa. Va e riceve i dati. Questo è ciò che questo sembra come, la normalizzazione. 

Quindi, in questa particolare struttura, stiamo guardando un catalogo prodotti. Ho diversi tipi di prodotti. Ho libri. Ho album. Ho i video. Il rapporto tra i prodotti e uno di questi libri, album, e video tavoli è di 1: 1. Tutto ok? Ho un ID del prodotto, e che corrisponde ID di un libro, un album o un video. ok? Questa è una relazione 1: 1 attraverso tali tabelle. 

Ora, tutto quello che books-- avere è proprietà di root. Nessun problema. È fantastico. Uno-a-uno, ho tutti i dati che ho bisogno di descrivere quel libro. Album Albums-- hanno tracce. Questo è ciò che noi chiamiamo uno a molti. Ogni album può avere molte tracce. Così, per ogni traccia su l'album, ho potuto avere un altro record in questa tabella figlio. Così ho creato un record nel mio tavolo album. Creo più record nella tabella tracce. Uno-a-molti. 

Questa relazione è quello chiamiamo molti-a-molti. ok? Si vede che gli attori potrebbero essere in molti film, molti video. Quindi quello che facciamo è che abbiamo messo questa mappatura tavolo tra coloro, i quali solo mappe l'ID attore all'ID video. Ora posso creare una query join video attraverso attore video da attori, e mi dà una bella lista di tutti i film e tutti gli attori che erano in quel film. 

OK. Quindi qui si va. One-to-one è il primo livello relazione; uno-a-molti, album alle tracce; molti-a-molti. Questi sono i tre livelli top relazioni in qualsiasi database. Se sai come quelli rapporti di lavoro insieme, poi si sa un sacco su base di dati già. Così NoSQL funziona un po 'diverso. Pensiamo per un attimo quello che sembra che per andare a prendere tutti i miei prodotti. 

In un negozio relazionale, io vuole ottenere tutti i miei prodotti su un elenco di tutti i miei prodotti. Questo è un sacco di domande. Ho una domanda per tutti i miei libri. Ho una domanda da miei album. E io ho una domanda per tutti i miei video. E ho avuto modo di mettere tutti insieme in una lista e servire indietro fino al applicazione che è lo richiedono. 

Per ottenere i miei libri, mi unisco Prodotti e Libri. Per ottenere i miei album, ho avuto modo di unirsi Prodotti, Album e tracce. E per ottenere il mio video, ho di aderire a prodotti video, unirsi attraverso Attore Video, e portare gli attori. Ecco, questo è tre domande. Query molto complesso montare un set di risultati. 

Questo è meno che ottimale. Ecco perché quando si parla di una struttura di dati che è costruita per essere agnostici all'accesso pattern-- bene che è grande. E si può vedere questo è davvero bello come abbiamo organizzato i dati. E sai una cosa? Ho solo un record per un attore. 

Questo è figo. Ho deduplicato tutti i miei attori, e ho mantenuto le mie associazioni in questa tabella di mappatura. Tuttavia, ottenere i dati fuori diventa costoso. Sto inviando la CPU in tutto il sistema unendo queste strutture dati insieme per essere in grado di tirare indietro che dati. 

Allora, come faccio ad andare in giro così? In NoSQL si tratta di aggregazione, non la normalizzazione. Quindi, vogliamo dire che vogliamo supportare il modello di accesso. Se il modello di accesso alle applicazioni, Ho bisogno di ottenere tutti i miei prodotti. Mettiamo tutti i prodotti di una tabella. Se metto tutti i prodotti di una tabella, Posso solo selezionare tutti i prodotti da quel tavolo e ho capito tutto. Bene come posso fare? Bene in NoSQL non c'è struttura alla tabella. Parleremo un po 'di come funziona in Dynamo DB. Ma non si ha la stessa attributi e le stesse proprietà in ogni singola riga, in ogni singolo voce, come si fa in una tabella SQL. E ciò che questo mi permette di fare è un sacco di cose e mi danno un sacco di flessibilità. In questo caso particolare, i miei documenti di prodotto. E in questa particolare esempio, tutto è un documento nella tabella Products. E il prodotto per un libro potrebbe disporre di un ID tipo che specifica un libro. E l'applicazione sarebbe attivare tale ID. 

Al livello applicazione, io vado a dire oh, che tipo di record è questo? Oh, è un record di libro. Prenota record hanno queste proprietà. Mi permetta di creare un oggetto libro. Quindi ho intenzione di riempire il oggetto libro con questo oggetto. Prodotto successivo arriva e dice, che cosa è questo articolo? Beh, questa voce è un album. Oh, ho ottenuto un intero diverso routine di trattamento per questo, perché è un album. Vedete cosa voglio dire? 

Così l'applicazione tier-- I basta selezionare tutti questi record. Tutti cominciano ad arrivare. Essi potrebbero essere tutti i tipi diversi. Ed è la logica dell'applicazione che gli interruttori attraverso questi tipi e decide come elaborare loro. 

Ancora una volta, quindi stiamo ottimizzando il schema per il modello di accesso. Lo stiamo facendo da collasso tali tabelle. Stiamo fondamentalmente prendendo queste strutture normalizzati, e stiamo costruendo strutture gerarchiche. All'interno di ciascuno di questi record Io vado a vedere le proprietà di matrice. 

All'interno di questo documento per gli album, Sto vedendo array di tracce. Queste tracce ora become-- è fondamentalmente questa tabella figlio che esiste proprio qui in questa struttura. Così si può fare questo in DynamoDB. È possibile farlo in MongoDB. È possibile farlo in qualsiasi database NoSQL. Creare questi tipi di strutture di dati gerarchiche che consentono di recuperare i dati molto in fretta perché ora non devono conformarsi. Quando inserisco una riga in the Tracks tavolo, o una riga nella tabella Album, Devo conformarsi a tale schema. Devo avere l'attributo o il proprietà definita su quella tabella. Ognuno di essi, quando inserisco quella riga. Questo non è il caso di NoSQL. 

Posso avere completamente diverso immobili a ogni documento che inserisco nella collezione. Meccanismo in modo molto potente. Ed è davvero come si ottimizzare il sistema. Perché ora quella query, invece di unire tutte queste tabelle e l'esecuzione di una mezza dozzina di domande per tirare indietro i dati che ho bisogno, Sto eseguendo una query. E sto iterazione attraverso i risultati prefissati. ti dà un'idea del potere di NoSQL. Ho intenzione di andare tipo di traverso qui e parlare un po 'di questo. Questo è più del tipo di marketing o tecnologici, quali la commercializzazione della tecnologia tipo di discussione. Ma è importante capire perché se guardiamo in alto qui in questo grafico, quello che stiamo guardando è ciò che chiamiamo il La tecnologia curva di hype. E ciò significa novità entra in gioco. La gente pensa che sia grande. Ho risolto tutti i miei problemi. 

Questa potrebbe essere la fine tutto, essere tutto a tutto. E iniziano ad usarlo. E dicono, questa roba non funziona. Non è giusto. La roba vecchia era meglio. E tornano a fare le cose come erano. E poi alla fine vanno, sai una cosa? Questa roba non è così male. Oh, è così che funziona. E una volta che capire come opere, iniziano sempre meglio. 

E la cosa divertente su di esso è, che tipo di linee fino a che che noi chiamiamo la curva Technology Adoption. Quindi, quello che succede è che abbiamo alcuni trigger tecnologia sorta. Nel caso di banche dati, è la pressione dei dati. Abbiamo parlato dei punti d'acqua alti della pressione dei dati nel tempo. Quando la pressione che i dati colpisce un certo punto, che è un trigger di tecnologia. 

Sta diventando troppo costoso. Ci vuole troppo tempo per elaborare i dati. Abbiamo bisogno di qualcosa di meglio. È possibile ottenere gli innovatori là fuori in giro, cercando di scoprire qual è la soluzione. Qual è la nuova idea? 

Qual è il prossimo migliore modo di fare questa cosa? E sono venuti fuori con qualcosa. E la gente con il vero dolore, i ragazzi al bordo sanguinamento, faranno saltare tutto su di esso, perché hanno bisogno di una risposta. Ora che cosa inevitabilmente happens-- e sta accadendo in questo momento nel NoSQL. Lo vedo tutto il tempo. 

Quello che succede è inevitabilmente persone iniziare a utilizzare il nuovo strumento allo stesso modo in cui ha utilizzato il vecchio strumento. E scoprono che non funziona così bene. Non riesco a ricordare chi ero parlando prima di oggi. Ma è come, quando la martello pneumatico è stato inventato, la gente non ha oscillare sopra la loro testa per distruggere il calcestruzzo. 

Ma questo è ciò che è accadendo con NoSQL oggi. Se si cammina per maggior parte dei negozi, stanno cercando di essere negozi NoSQL. Quello che stanno facendo è stanno usando NoSQL, e stanno caricarlo pieno di schema relazionale. Perché è così che progettano database. E stanno chiedendo, perché è non eseguire molto bene? Ragazzi, questa cosa puzza. Dovevo mantenere tutto il mio unisce dentro-- è come, no, no. Mantenere unisce? Perché si stanno unendo i dati? Non si uniscono i dati in NoSQL. Si aggregare esso. 

Quindi, se si vuole evitare questo, imparare come funziona lo strumento prima che realmente iniziare ad usarlo. Non cercare di utilizzare i nuovi strumenti del Allo stesso modo si è utilizzato i vecchi strumenti. Stai andando ad avere una brutta esperienza. E ogni volta questo è ciò che si tratta. Quando cominciamo a venire qui, è perché la gente capito come utilizzare gli strumenti. 

Hanno fatto la stessa cosa quando database relazionali sono stati inventati, e stavano sostituendo i file system. Hanno cercato di costruire sistemi di file con i database relazionali perché è quello che la gente capisse. Non ha funzionato. Così la comprensione delle buone pratiche della tecnologia si sta lavorando è enorme. Molto importante. 

Quindi stiamo per entrare in DynamoDB. DynamoDB è AWS di completamente gestiti piattaforma NoSQL. Che cosa significa completamente gestiti significa? Significa che non è necessario davvero preoccuparsi di nulla. 

Vieni a, si dice noi, ho bisogno di un tavolo. Ha bisogno di questa capacità molto. Si preme il pulsante, e la fornitura noi tutte le infrastrutture dietro la scena. Ora che è enorme. 

Perché quando si parla su scala di un database, Cluster di dati NoSQL a scala, petabyte in esecuzione, esecuzione di milioni di transazioni al secondo, queste cose non sono piccoli grappoli. Stiamo parlando di migliaia di casi. Gestione delle migliaia di casi, anche istanze virtuali, è un vero e proprio dolore nel culo. Voglio dire, penso ogni volta che un patch del sistema operativo esce o una nuova versione del database. Cosa significa a voi operativamente? Ciò significa che hai 1.200 i server che hanno bisogno di essere aggiornati. Ora anche con l'automazione, che può richiedere molto tempo. Questo può causare un sacco di emicranie operative, perché potrei avere servizi verso il basso. 

Come aggiorno questi database, io potrebbe fare implementazioni verde blu dove ho implementano e aggiornano metà del mio nodi, e quindi aggiornare l'altra metà. Prendete quelli giù. Così gestione dell'infrastruttura scala è enormemente doloroso. E AWS prendere quel dolore fuori di esso. E i database NoSQL può essere straordinariamente doloroso a causa del loro modo di scala. 

Scala orizzontale. Se si vuole ottenere un maggiore NoSQL banca dati, comprate più nodi. Ogni nodo si acquista è altro mal di testa operativa. Quindi cerchiamo qualcun altro farlo per voi. AWS può farlo. 

Sosteniamo valori chiave del documento. Ora non siamo andati troppo in dall'altro tabella. C'è un sacco di diverso sapori di NoSQL. Sono tutti i tipi di ottenere munged insieme a questo punto. Potete guardare DynamoDB e dire di sì, siamo entrambi un documento e un valore chiave memorizzare questo punto. E si può discutere le caratteristiche di uno sopra l'altro. Per me, un sacco di questo è davvero sei di una mezza dozzina dell'altro. Ognuna di queste tecnologie è un La tecnologia raffinata e una buona soluzione. Non direi che MongoDB è migliore o peggio di Couch, poi Cassandra, poi Dynamo, o viceversa. Voglio dire, questi sono solo opzioni. 

E 'veloce ed è coerente a qualsiasi scala. Quindi questo è uno dei più grandi bonus si ottiene con AWS. Con DynamoDB è la capacità per ottenere un basso sola cifra latenza millisecondo in qualsiasi scala. E 'stato un obiettivo di progettazione del sistema. E abbiamo clienti che stanno facendo milioni di transazioni al secondo. 

Ora andrò attraverso alcune di quelle casi d'uso in pochi minuti qui. Accesso control-- integrato abbiamo quello che chiamiamo Identity Access Management, o IAM. Essa permea ogni sistema, ogni servizio che AWS offre. DynamoDB non fa eccezione. È possibile controllare l'accesso ai tavoli DynamoDB. Attraverso tutti i tuoi account di AWS per definizione dei ruoli di accesso e autorizzazioni nelle infrastrutture IAM. 

Ed è un componente chiave e integrale in ciò che noi chiamiamo Event Driven Programming. Ora, questo è un nuovo paradigma. 

PUBBLICO: Come è il tuo tasso di vero positivi contro falsi negativi sul vostro sistema di controllo accessi? RICK Houlihan: veri positivi contro falsi negativi? PUBBLICO: Tornando cosa si dovrebbe essere di ritorno? A differenza di una volta in un mentre non restituisce quando dovrebbe convalidare? 

RICK Houlihan: non ho potuto dirvi che. Se c'è eventuali guasti di sorta su questo, Io non sono la persona a chiedere quella particolare domanda. Ma questa è una buona domanda. Sarei curioso di sapere che io, in realtà. 

E così poi di nuovo, nuovo paradigma è la programmazione event driven. Questa è l'idea che si può distribuire applicazioni complesse che può funzionare molto, molto elevata scala senza alcuna infrastruttura di sorta. Senza alcun fissa infrastrutture di sorta. E parleremo un po ' su cosa significa come noi andare avanti per il prossimo paio di grafici. 

La prima cosa che faremo è parleremo di tabelle. I tipi di dati API per Dynamo. E la prima cosa che si notare quando si guarda a questo, se si ha familiarità con qualsiasi database, database hanno davvero due tipi di API Lo definirei. O due serie di API. Uno di questi sarebbe API amministrativo. 

Le cose che si prendono cura di le funzioni del database. Configurazione del motore di archiviazione, la creazione e l'aggiunta di tabelle. la creazione del database cataloghi e le istanze. Questi things-- in DynamoDB, è sono molto brevi, liste brevi. 

Quindi, in altre banche dati, si potrebbe vedere decine di comandi, di tipo amministrativo comandi, per la configurazione queste opzioni aggiuntive. In DynamoDB non hai bisogno di quelli, perché non si configura il sistema, che facciamo. Quindi l'unica cosa che devi fare è mi dice che formato tabella ho bisogno. Così si ottiene un insieme limitato di comandi. 

Si ottiene un CREATE TABLE aggiornamento, Tavolo, Elimina tabella, e Descrivere Tabella. Queste sono le uniche cose il necessario per DynamoDB. Non hai bisogno di una memoria configurazione del motore. Non ho bisogno di preoccuparsi di replica. Non ho bisogno di preoccuparsi di sharding. 

Non ho bisogno di preoccuparsi di tutto questo roba. Facciamo tutto per voi. Ecco, questo è un enorme quantità di overhead che è appena alzato dal tuo piatto. Poi abbiamo gli operatori CRUD. CRUD è qualcosa quello che abbiamo chiamare database che è Creare, Update, Delete operatori. Questi sono i vostri comuni operazioni di database. Cose come mettere voce, diventano voce, aggiornamento articoli, eliminare elementi, interrogare batch, scansione. Se si desidera acquisire l'intera tabella. Tirare tutto fuori dal tavolo. Una delle cose belle di DynamoDB è che permette la scansione parallela. Così si può effettivamente farmi sapere quanti le discussioni che si desidera eseguire su quella scansione. E possiamo eseguire quei fili. Possiamo girare che la scansione su attraverso più thread in modo da poter acquisire l'intera tabella spazio molto, molto rapidamente in DynamoDB. 

L'altra API che abbiamo è quello che noi chiamiamo il nostro Stream API. Non stiamo andando a parlare troppo molto di questo adesso. Ho alcuni contenuti più tardi su nel mazzo su questo. Ma Streams è davvero un running-- pensare ad esso come il tempo ordinato e change log partizione. Tutto ciò che sta accadendo sul la tabella mostra sul torrente. 

Ogni scrittura sul tavolo si presenta sul torrente. Si può leggere quel flusso, e si possono fare le cose con esso. Parleremo di ciò che tipi di cose che si che fare con le cose come replica, creazione di indici secondari. Tutti i tipi di davvero cool cose che si possono fare con questo. 

Tipi di dati. In DynamoDB, sosteniamo entrambi chiave valore e dati documento tipi. Sul lato sinistro dello schermo qui, abbiamo i nostri tipi di base. Tipi di valore chiave. Si tratta di stringhe, numeri e binari. 

Così solo tre tipi fondamentali. E allora si può avere insiemi di quelli. Una delle cose belle di NoSQL è è possibile contenere le matrici come proprietà. E con DynamoDB è possibile contenere le matrici di tipi di base come una proprietà di root. 

E poi ci sono i tipi di documento. Quante persone hanno familiarità con JSON? Voi ragazzi che hanno familiarità con JSON così tanto? Si tratta fondamentalmente di JavaScript, Oggetto, Notation. Esso consente di fondamentalmente definire una struttura gerarchica. 

È possibile memorizzare un documento JSON su DynamoDB utilizzando componenti comuni o la costruzione di blocchi che sono disponibili nella maggior parte dei linguaggi di programmazione. Quindi, se avete Java, sei guardando le mappe ed elenchi. Posso creare oggetti che mappa. Una mappa come valori chiave memorizzato come proprietà. E potrebbe avere liste di valori all'interno di tali proprietà. È possibile memorizzare questo complesso struttura gerarchica come un singolo attributo di un elemento DynamoDB. 

Così tavoli in DynamoDB, come la maggior parte Database NoSQL, tabelle hanno elementi. In MongoDB si farebbe chiamare questi documenti. E sarebbe la base divano. Anche un database di documenti. Si chiama questi documenti. Documenti o oggetti hanno attributi. Possono esistere attributi o non esiste per l'oggetto. In DynamoDB, c'è un attributo obbligatorio. Proprio come in un database relazionale, si dispone di una chiave primaria nella tabella. 

DynamoDB ha ciò che noi chiamiamo una chiave hash. Tasto cancelletto deve essere univoco. Così, quando ho definire una tabella hash, fondamentalmente quello che sto dicendo è ogni articolo avrà un tasto cancelletto. E ogni tasto cancelletto deve essere univoco. 

Ogni articolo è definito da quella chiave hash univoco. E non ci può essere una sola. Questo va bene, ma spesso quello che la gente ha bisogno è che vogliono è questo hash la chiave per fare un po 'di più di essere solo un identificativo univoco. Spesso vogliamo usare quel tasto cancelletto come il top secchio di aggregazione di livello. E il nostro modo di fare che è di l'aggiunta di ciò che noi chiamiamo una chiave gamma. 

Quindi, se è solo un hash tavolo, questo deve essere univoco. Se si tratta di una tabella di hash e la gamma, la combinazione di hash e la gamma deve essere unico. Quindi, pensare in questo modo. Se ho un forum. E la forma ha argomenti, non ha posts, e ha le risposte. 

Così potrei avere un hash chiave, che è l'ID argomento. E potrei avere una chiave gamma, che è l'ID risposta. In questo modo se voglio ottenere tutte le risposte per argomento specifico, Posso solo interrogare l'hash. Posso solo dire che mi danno tutto gli elementi che hanno questo hash. E ho intenzione di ottenere ogni domanda o inviare per quel particolare argomento. Queste aggregazioni di alto livello sono molto importanti. Sostengono l'accesso primario modello dell'applicazione. In generale, questo è quello che vogliamo fare. Vogliamo che table-- come si carica il tavolo, vogliamo strutturare i dati all'interno della tabella in modo tale che l'applicazione può molto recuperare rapidamente i risultati. E spesso il modo per farlo è di mantenere queste aggregazioni come noi inserire i dati. In sostanza, stiamo diffondendo i dati nel secchio luminoso mentre entra. 

Chiavi Gamma consentono hash me-- chiavi devono essere l'uguaglianza. Quando mi interrogo un hash, devo dire dammi un hash che è uguale a questo. Quando mi interrogo un intervallo, io può dire dammi una gamma cioè usando qualsiasi tipo di ricco operatore che sosteniamo. Datemi tutti gli elementi per un hash. E 'uguale, superiore, meno, vuol cominciare, e non esiste tra questi due valori? Quindi questi tipi di query gamma che siamo sempre interessati a. Ora, una cosa su dati, quando guardate l'accesso ai dati, quando si accede ai dati, è sempre di una aggregazione. E 'sempre sui record che sono legati a questo. Dammi tutto qui that's-- tutto le operazioni su questa carta di credito per l'ultimo mese. Questo è un aggregazione. 

Quasi tutto quello che fai nella database è una sorta di aggregazione. Così poter essere in grado di definire questi secchi e darvi questi vanno attributi poter interrogare, quelle ricche query sostengono molti, molti, molti modelli di accesso alle applicazioni. 

Così l'altra cosa il tasto cancelletto non fa altro che ci dà un meccanismo essere in grado di diffondere i dati intorno. I database NoSQL funzionano meglio quando i dati sono uniformemente distribuiti in tutto il cluster. Quante persone sono familiari con algoritmi di hashing? Quando dico hash e un hashing-- perché un algoritmo di hashing è un modo di essere in grado di generare un valore casuale da ogni valore dato. Quindi, in questo caso particolare, la algoritmo di hash che si corre è ND 5 basato. 

E se ho un ID, e questo è il mio tasto cancelletto, ho 1, 2, 3. Quando faccio funzionare l'algoritmo di hash, che sta per tornare indietro e dire, bene 1 uguale 7B, 2 è uguale a 48, 3 è uguale a CD. Sono diffusi in tutto lo spazio chiave. E perché lo fai? Perché questo fa in modo che posso mettere i record su più nodi. 

Se io sto facendo questo incrementale, 1, 2, 3. E ho una gamma hash che viene eseguito in questo caso particolare, un piccolo spazio di hash, corre da 00 a FF, poi i record stanno per entrare in e che stanno andando ad andare 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12. Che succede? Ogni inserto sta allo stesso nodo. Vedete cosa voglio dire? 

Perché quando ho diviso lo spazio, io stesi questi record in tutto, e la partizione io, che sto per dire partizione 1, dispone di spazi chiave 0-54. Partizione 2 è 55-89. Partizione 3 è AA a FF. Quindi se sto utilizzando in modo lineare l'incremento ID, si può vedere cosa sta succedendo. 1, 2, 3, 4, 5, 6, tutto fino a 54. Così come io sto martellando l' record nel sistema, tutto finisce per andare a un nodo. 

Questo non va bene. Questo è un antipattern. In MongoDB hanno questo problema se non si utilizza una chiave hash. MongoDB ti dà la possibilità di hashing del valore della chiave. Si dovrebbe sempre farlo, se stai usando un hash di incremento chiave in MongoDB, o sarai inchiodare ogni scrittura per un nodo, e sarete limitando il vostro rendimento scrivere male. 

PUBBLICO: È che A9 169 in decimale? 

RICK Houlihan: Sì, è da qualche parte lì intorno. A9, non lo so. Dovreste ottenere il mio binario di calcolatrice decimale. Il mio cervello non funziona così. PUBBLICO: Solo un rapido uno dei vostri commenti Mongo. Così è l'ID oggetto che viene nativamente con Mongo farlo? RICK Houlihan: Ha fatto? Se si specifica che. Con MongoDB, si ha la possibilità. È possibile specify-- ogni documento MongoDB deve avere un ID di sottolineatura. Questo è il valore unico. 

In MongoDB è possibile specificare se hash o meno. Hanno appena ti danno la possibilità. Se si sa che si tratta di casuale, nessun problema. Non c'è bisogno di farlo. Se si sa che non è casuale, che è incrementato, quindi effettuare l'hash. 

Ora la cosa su hashing, una volta che si hash un value-- e questo è Perché chiavi hash sono sempre query uniche, perché ho cambiato il valore, ora non posso fare una query gamma. Non posso dire che è questo tra questo o quello, perché il valore di hash non sta andando per essere equivalente al valore reale. Quindi, quando si hash chiave, è solo l'uguaglianza. È per questo che in chiave hash DynamoDB query sono sempre solo uguaglianza. 

Così ora in una gamma key-- quando aggiungo che chiave gamma, i record chiave gamma provengono tutti in e essi vengono memorizzati sulla stessa partizione. Quindi sono molto rapidamente, facilmente recuperate perché questa è l'hash, questa è la gamma. E si vede tutto con lo stesso hash viene memorizzato sullo stesso spazio partizione. È possibile utilizzare la chiave per aiutare gamma individuare i dati vicino al suo genitore. Così che cosa sto veramente facendo qui? Questo è un uno a molti. La relazione tra una chiave hash e la chiave di gamma è uno a molti. Posso avere più chiavi di hash. Posso avere solo gamma multipla chiavi all'interno di ogni tasto cancelletto. 

L'hash definisce il genitore, la gamma definisce i bambini. Così si può vedere c'è analogico qui tra il costrutto relazionale e gli stessi tipi di costruisce in NoSQL. La gente parla di NoSQL come non relazionali. Non è non relazionali. Data ha sempre rapporti. Quei rapporti solo sono modellati in modo diverso. Parliamo un po ' po 'di durata. Quando si scrive di DynamoDB, scrive sono sempre a tre vie replicato. Il che significa che abbiamo tre AZ. AZ sono Zone Disponibilità. Si può pensare a un Disponibilità Zone come un data center o un insieme di data center. Queste cose sono geograficamente isolati l'uno dall'altro tra le diverse zone di faglia, attraverso diverse reti elettriche e delle pianure alluvionali. Un guasto in uno AZ non è andando a prendere giù un altro. Essi sono anche legate insieme con fibra spenta. Supporta un sub 1 latenza millisecondo tra AZS. Così repliche dei dati in tempo reale capace in AZS multiple. 

E implementazioni spesso multi-AZ soddisfare i requisiti di disponibilità elevata della maggior parte delle organizzazioni aziendali. Così DynamoDB si sviluppa in tre AZS per impostazione predefinita. Stiamo solo andando alla conoscenza della scrittura quando due di questi tre nodi tornare e dico, Sì, ho capito. Perché? Perché sul lato lettura siamo solo andando a dare i dati indietro quando abbiamo capito da due nodi. 

Se sto replicare attraverso tre, e sto leggendo da due, Sono sempre garantito avere almeno un Di quelli legge per la la maggior copia corrente di dati. Questo è ciò che rende DynamoDB coerente. Ora è possibile scegliere di girare quelli coerenti letture fuori. Nel qual caso ho intenzione di dire, Leggo da un solo nodo. E io non posso garantire che sta andando essere i dati più recenti. 

Quindi, se la scrittura è in arrivo, essa non ha ancora replicato, si sta andando ad ottenere quella copia. Questa è una lettura finalmente coerente. E di cosa si tratta è la metà del costo. Quindi questo è qualcosa a cui pensare. Quando stai leggendo fuori DynamoDB, e stai impostando la vostra capacità di lettura unità, se si sceglie alla fine coerente legge, è molto più economico, è circa la metà del costo. 

E così di risparmiare denaro. Ma questa è la vostra scelta. Se si desidera una lettura coerente o una lettura finalmente coerente. Questo è qualcosa che si può scegliere. 

Parliamo di indici. Così abbiamo detto che l'aggregazione di alto livello. Abbiamo chiavi hash, e abbiamo chiavi gamma. Bello. E questo è sul tavolo primario, io ottenuto una chiave hash, ho ottenuto una chiave gamma. 

Cosa significa? Ho un attributo che io possono eseguire query ricchi contro. E 'la chiave di gamma. Gli altri attributi su quel item-- Posso filtrare quegli attributi. Ma non posso fare cose simili, inizia con, o è superiore. 

Come lo faccio? Creo un indice. Ci sono due tipi di indici in DynamoDB. Un indice è davvero un'altra vista del tavolo. E l'indice secondario locale. 

La prima ne parleremo. Così secondari locali sono coesistevano sulla stessa partizione come i dati. E come tali, sono lo stesso nodo fisico. Sono ciò che noi chiamiamo coerente. Significato, essi riconosceranno la scrittura insieme al tavolo. Quando la scrittura entra, scriveremo attraverso l'indice. Scriveremo al tavolo, e poi ci riconoscere. Ecco, questo è coerente. Una volta che la scrittura è stata riconosciuto dalla tabella, è garantito che il indice secondario locali avrà la stessa visione dei dati. Ma quello che ti permettono di fare è definire le chiavi alternative gamma. 

È necessario utilizzare lo stesso hash chiave come tabella primaria, perché sono co-situato sulla stessa partizione, e sono coerenti. Ma posso creare un indice con chiavi diverse gamma. Così, per esempio, se avessi un produttore che aveva un tavolo le parti prima proveniente in. E pezzi grezzi entrano, e stanno aggregati per il montaggio. E forse c'è un richiamo. 

Qualsiasi parte che è stato fatto da questo produttore dopo tale data, Ho bisogno di tirare da mia linea. Posso girare un indice che sarebbe in cerca, aggregando alla data di fabbricazione di quella parte particolare. Quindi, se il mio tavolo livello superiore era già hashed dal costruttore, forse era organizzato su ID parte, io in grado di creare un indice fuori quel tavolo come hash dal costruttore e a distanza alla data di costruzione. E in questo modo potrei dire, tutto ciò che è stato prodotto tra queste date, Ho bisogno di tirare dalla linea. Quindi questo è un indice secondario locale. 

Questi hanno l'effetto di limitando l'hash spazio chiave. Perché loro co-esistiti sullo stesso nodo di archiviazione, limitano il tasto cancelletto spazio a 10 gigabyte. DynamoDB, sotto la tavoli, si ripartisce il vostro tavolo ogni 10 gigabyte. Quando si mettono 10 giga di dati in, abbiamo andare [PHH], e aggiungiamo un altro nodo. 

Noi non dividere il LSI attraverso più partizioni. Ci divideremo il tavolo. Ma noi non dividere il LSI. Ecco, questo è qualcosa importante capire è se si sta facendo molto, molto, molto grandi aggregazioni, allora si sta andando ad essere limitato a 10 gigabyte sul LSI. 

Se questo è il caso, si può utilizzare secondari globali. Secondari globali sono davvero un altro tavolo. Esistono completamente fuori a il lato della tabella primaria. E loro mi permettono di trovare un struttura completamente diversa. Così pensare ad esso come viene inserito dati in due diverse tabelle, strutturato in due modi diversi. 

Posso definire totalmente diverso tasto cancelletto. Posso definire totalmente chiave diversa gamma. E posso correre questo completamente indipendente. È un dato di fatto, ho provisioning la mia capacità di lettura e scrivere la mia capacità di indici secondari globali completamente indipendente della mia tabella primaria. Se io definisco tale indice, dico esso quanto leggere e scrivere capacità che sta per essere utilizzato. 

E questo è separata dalla mia tabella primaria. Ora sia degli indici ci permettono di definire non solo le chiavi di hash e gamma, ma ci hanno permettono di proiettare valori aggiuntivi. Quindi, se voglio leggere l'indice, e voglio ottenere un insieme di dati, Non ho bisogno di tornare alla principale tavolo per ottenere gli attributi aggiuntivi. Posso proiettare quelli supplementari attributi nella tabella per supportare il tipo di accesso. So che probabilmente stiamo ottenendo in qualche davvero, really-- entrare le erbacce qui su alcune di queste cose. Ora ho avuto modo di andare alla deriva da questo. 

PUBBLICO: [incomprensibile] chiave --table dire era un hash? L'hash originale? Multi-stecche? 

RICK Houlihan: Sì. Sì. La chiave della tabella in fondo punti di nuovo alla voce. Così un indice è un indicatore di nuovo a gli elementi originali sul tavolo. Ora si può scegliere di costruire un indice che ha solo la chiave della tabella, e non altre proprietà. E perché potrei farlo? Beh, forse ho molto oggetti di grandi dimensioni. 

Ho davvero bisogno solo di sapere which-- il mio modello di accesso potrebbe dire, quali elementi contengono questa struttura? Non c'è bisogno di restituire l'articolo. Ho solo bisogno di sapere quali elementi contengono. Così si può costruire indici che hanno solo la chiave della tabella. 

Ma questo è in primo luogo ciò un indice nel database è per. E 'per poter rapidamente identificare che registra, le righe, che elementi nella tabella hanno le proprietà che sto cercando. 

GSI, così come funzionano? GSI fondamentalmente sono asincroni. L'aggiornamento viene in tabella, tabella viene aggiornata in modo asincrono tutti i tuoi GSI. Questo è il motivo per cui sono GSI infine coerente. 

È importante notare che quando si sta costruendo GSI, e si capisce che si sta creando un'altra dimensione di aggregation-- Ora diciamo che il buon esempio qui è un produttore. Penso che avrei potuto parlato un produttore di dispositivi medici. Produttori di dispositivi medici hanno spesso parti serializzati. Le parti che entrano in una protesi all'anca tutto avere un po 'di numero di serie su di loro. E potrebbero avere milioni e milioni e miliardi di pezzi in tutti i dispositivi che spediscono. Beh, hanno bisogno di aggregare sotto diverse dimensioni, tutte le parti in un assieme, tutti i parti che sono state fatte su una determinata linea, tutte le parti in dotazione in di un determinato produttore in una certa data. E queste aggregazioni volte alzarsi in miliardi. 

Così io lavoro con alcuni dei questi ragazzi che soffrono perché sono la creazione di queste aggregazioni ginormous nei loro indici secondari. Potrebbero avere un pezzi grezzi tavolo che si presenta come unico hash. Ogni parte ha un numero di serie unico. Io uso il numero di serie come l'hash. È bellissimo. Il mio tavolo dati grezzi si sviluppa in tutto lo spazio chiave. Il mio [? scrivere ?] [? ingestione?] è impressionante. Prendo un sacco di dati. Poi quello che fanno è creano un GSI. E io dico, sai cosa, ho bisogno di vedere tutte le parti per questo produttore. Beh, tutto ad un tratto sono prendere un miliardo di righe, e li roba su un nodo, perché quando Ho aggregato il ID produttore come l'hash, e il numero di parte come la gamma, poi all'improvviso sono mettendo un miliardo di parti in quello che questo produttore mi ha consegnato. 

Questo può causare un sacco di pressione sul GSI, ancora una volta, perché sto martellando un nodo. Sto mettendo tutto questo inserisce in un nodo. E questo è un vero e proprio caso d'uso problematico. Ora, ho ottenuto un buon progetto modello per come si evita che. E questo è uno dei problemi che ho sempre lavorato con. Ma ciò che accade, è il GSI può Non avere una capacità di scrittura abbastanza essere in grado di spingere tutti coloro righe in un unico nodo. E cosa succede allora è il primaria, la tabella client, la tabella primaria verrà strozzata perché il GSI non può tenere il passo. Quindi il mio tasso di inserimento sarà cadere sul tavolo primario come il mio GSI cerca di tenere il passo. 

Va bene, così GSI di LSI di, quale dovrei usare? LSI di sono coerenti. GSI di sono finalmente coerenti. Se va bene, mi consiglia di utilizzare un GSI, loro sono molto più flessibile. LSI di può essere modellato come un GSI. E se la dimensione dei dati per chiavi hash in la vostra collezione supera i 10 gigabyte, allora si sta andando a voler utilizzare tale GSI perché è solo un limite rigido. 

Va bene, così ridimensionamento. Throughput in Dynamo DB, è disposizione può [incomprensibile] throughput di un tavolo. Abbiamo clienti che hanno provisioning 60 billion-- stanno facendo 60 miliardi di richieste, regolarmente in esecuzione a oltre un milione di richieste al secondo sulle nostre tavole. Non c'è davvero nessun limite teorico a quanto e quanto velocemente il tavolo può essere eseguito in Dynamo DB. Ci sono alcuni morbido limiti sul tuo conto che abbiamo messo in là così che non si va pazzo. Se si desidera più di che, non è un problema. Vieni dirci. Faremo girare il quadrante. 

Ogni account è limitato a un certo livello in ogni servizio, appena fuori del blocco così la gente non impazzire si sono nei guai. Nessun limite di dimensione. È possibile inserire un qualsiasi numero di oggetti su un tavolo. Le dimensioni di un oggetto è limitato a 400 kilobyte, che non sarebbero oggetto gli attributi. Quindi la somma di tutti gli attributi è limitata a 400 kilobyte. E poi di nuovo, abbiamo quel piccolo problema LSI con il limite di 10 gigabyte per hash. PUBBLICO: Piccolo numero, mi manca quello che mi stai dicendo, che è-- PUBBLICO: Oh, 400 kilobyte è la dimensione massima per ogni articolo. Quindi un elemento ha tutti gli attributi. Così 400 k è la dimensione totale di tale voce, 400 kilobyte. Così, tutti gli attributi combinati, tutti i dati che è in tutti questi attributi, arrotolato in una dimensione totale, Attualmente il limite di elementi oggi è di 400 k. Quindi il ridimensionamento di nuovo, raggiunto attraverso il partizionamento. Throughput provisioning a livello di tabella. E ci sono davvero due manopole. Abbiamo letto di capacità e scrivere la capacità. 

Quindi questi sono regolati indipendentemente l'uno dall'altro. Misura di telecomando rigorosamente coerente legge. OK, quindi se stai dicendo che voglio 1000 Telecomando di quelli sono strettamente coerenti, queste sono letture coerenti. Se dici che voglio eventuale coerente legge, è possibile disposizione 1.000 RCU di, si sta andando per ottenere 2.000 alla fine coerente legge. E la metà del prezzo per chi infine consisterà nella legge. 

Ancora una volta, rettificato indipendentemente l'uno dall'altro. E hanno la throughput-- Se si consumano 100% del tuo telecomando, non avete intenzione di influenzare il disponibilità dei vostri diritti. Quindi sono completamente indipendenti l'uno dall'altro. Va bene, quindi una delle cose che Ho accennato brevemente è stato di limitazione. Throttling è male. Throttling indica male no SQL. Ci sono cose che possiamo fare per aiutare ad alleviare la limitazione che si stanno vivendo. Ma la soluzione migliore per questo è diamo uno sguardo a quello che stai facendo, perché c'è un anti-modello in gioco qui. 

Queste cose, cose come non uniforme i carichi di lavoro, tasti di scelta rapida, divisori calde. Mi colpisce un particolare spazio chiave molto difficile per qualche ragione particolare. Perché sto facendo questo? Cerchiamo di capirlo. Sto mescolare i miei dati a caldo con i dati freddi. Sto lasciando mie tabelle ottenere enorme, ma non c'è davvero solo un sottoinsieme dei dati che è davvero interessante per me. Così, per dati di log, per esempio, molti clienti, che ricevono i dati di log ogni giorno. Hanno ottenuto una quantità enorme di dati di log. 

Se sei solo il dumping tutto quel registro i dati in un unico grande tavolo, nel corso del tempo quel tavolo sta per ottenere massiccia. Ma sono davvero interessati solo a ultime 24 ore, gli ultimi sette giorni, negli ultimi 30 giorni. Qualunque sia la finestra di tempo che io sono interessato a guardare per l'evento che mi preoccupa, o l'evento che è interessante per me, questa è l'unica volta che ho bisogno della finestra. Allora perché sto mettendo 10 anni vale la pena di dati di registro nella tabella? Che cosa è che causa il tavolo il frammento. 

Diventa enorme. Si comincia diffondendo attraverso migliaia di nodi. E dal momento che la capacità è così basso, sei in realtà rate limiting su ogni uno di quei singoli nodi. Quindi cominciamo a guardare come facciamo rotolare quel tavolo. Come gestire i dati che un po ' meglio evitare questi problemi. E questo cosa assomigliano? Questo è ciò che sembra. Questo è ciò che male NoSQL assomiglia. 

Ho qui un tasto di scelta rapida. Se si guarda dal lato qui, queste sono tutte le mie partizioni. Ho 16 partizioni qui su questo particolare database. Facciamo questo per tutto il tempo. Corro questo per i clienti di tutto il tempo. Si chiama la mappa di calore. Mappa di calore mi dice come sei accedere al proprio spazio delle chiavi. E ciò che questo mi sta dicendo è che ci sia un particolare hash che questo ragazzo piace un lotto terribile, perché è colpisce davvero, davvero difficile. 

Così il blu è bello. Ci piace blu. Non ci piace rosso. Red dove la pressione si alza a 100%. 100%, ora si sta andando ad essere strozzato. Quindi, ogni volta che vedete tutte le linee rosse come questo-- e non è solo Dynamo DB-- tutti i database NoSQL ha questo problema. Ci sono anti-pattern che possono guidare questi tipi di condizioni. Quello che faccio è che lavoro con i clienti per alleviare queste condizioni. 

E questo cosa assomigliano? E questo è sempre il più di rendimento Dynamo DB, ma è davvero sempre il massimo da NoSQL. Questo non è limitata a dinamo. Questo è io definitely-- abituato a lavorare a Mongo. Ho familiarità con molte piattaforme NoSQL. Ognuno ha questi tipi di problemi di tasti di scelta rapida. Per ottenere il massimo da qualsiasi NoSQL base di dati, in particolare Dynamo DB, si desidera creare le tabelle dove l'elemento chiave hash ha un gran numero di valori distinti, un alto grado di cardinalità. Perché significa che sto scrivendo a un sacco di differenti secchi. 

I più secchi Sono la scrittura, più è probabile Sono a diffondere quel carico scrittura o Leggere caricare fuori attraverso più nodi, più è probabile che io sono di avere una throughput elevato sul tavolo. E poi voglio i valori siano richiesto abbastanza uniforme nel tempo e più uniforme possibile in modo casuale. Beh, questo è abbastanza interessante, perché non posso davvero controllo quando gli utenti arrivano. Quindi, basti dire, se abbiamo diffuso cose fuori tutto lo spazio delle chiavi, Probabilmente ci andremo più in forma. 

C'è una certa quantità di tempo di consegna che non si sta andando per essere in grado di controllo. Ma questi sono davvero il due dimensioni che abbiamo, spazio, l'accesso in modo uniforme spread, il tempo, le richieste di arrivare distribuiti uniformemente nel tempo. E se quei due condizioni sono soddisfatte, allora questo è quello che è andare a guardare come. Questo è molto più bello. Siamo davvero felici qui. Abbiamo un modello di accesso molto anche. Sì, forse stai ricevendo un poca pressione ogni tanto, ma niente di veramente troppo estesa. Quindi è sorprendente quante volte, quando lavoro con i clienti, quel primo grafico con il grande rosso bar e tutto ciò che esso è brutto giallo tutto il posto, abbiamo ottenere fatto con l'esercizio dopo un paio di mesi di ri-architettura, sono in esecuzione la stessa identica carico di lavoro presso lo stesso esatto carico. E questo è ciò che sta cercando come ora. Quindi, quello che si ottiene con NoSQL è un schema di dati che è assolutamente legata al tipo di accesso. 

Ed è possibile ottimizzare tale schema dati per supportare quel modello di accesso. Se non lo fai, allora si sta andando vedere quei tipi di problemi con questi tasti di scelta rapida. 

PUBBLICO: Bene, inevitabilmente alcuni posti stanno per essere più caldo rispetto ad altri. 

RICK Houlihan: Sempre. Sempre. Sì, voglio dire c'è sempre a-- e ancora una volta, non c'è alcuni modelli di progettazione ce la caveremo che parlerà di come si affronta con questi super-grandi aggregazioni. Voglio dire, ho avuto modo di avere loro, come possiamo trattare con loro? Ho ottenuto un buon caso d'uso che parleremo per questo. 

Va bene, quindi cerchiamo di parlare circa alcuni clienti ora. Questi ragazzi sono AdRoll. Non so se siete familiarità con AdRoll. Probabilmente li vede molto sul browser. Sono annunci re-targeting, sono il più grande business degli annunci riorientamento là fuori. Normalmente passano regolarmente su 60 miliardi di transazioni al giorno. Stanno facendo più di un milione transazioni al secondo. Hanno una bella semplice tavolo la struttura, la tabella più trafficato. E 'fondamentalmente solo una chiave hash è il cookie, la gamma è il demografica categoria, e poi il terzo attributo è il punteggio. 

Quindi tutti noi abbiamo i biscotti in il nostro browser da questi ragazzi. E quando si va a una merchant partecipanti, essi fondamentalmente punteggio attraverso diverse categorie demografiche. Quando vai a un sito web e dici che voglio vedere questo ad-- o in fondo non si dice che-- ma quando si va al sito web dicono che si vuole vedere questo annuncio. E vanno ottenere tale annuncio da AdRoll. AdRoll si guarda in alto sul loro tavolo. Trovano il cookie. Gli inserzionisti che raccontano li, voglio qualcuno chi è di mezza età, 40-year-old man, in sport. E ti segnano in quei dati demografici e decidono se questo è un buon annuncio per voi. 

Ora hanno un SLA con i loro fornitori di pubblicità per fornire sub-10 millisecondi risposta su ogni singola richiesta. Così stanno usando Dynamo DB per questo. Ci stanno colpendo un milioni di richieste al secondo. Sono in grado di fare tutto il loro ricerche, triage tutti i dati, e ottenere che puntano aggiungere di nuovo a quel l'inserzionista in meno di 10 millisecondi. E 'davvero davvero fenomenale attuazione che hanno. 

Questi ragazzi actually-- sono questi i ragazzi. Io non sono sicuro se è questi ragazzi. Potrebbe essere questi ragazzi. Fondamentalmente noi-- detto no, non credo che loro era. Penso che sia stato qualcun altro. Stavo lavorando con un cliente che mi ha detto che ora che hanno andato a Dynamo DB, sono spendere più soldi per spuntini per il loro team di sviluppo di ogni mese quello che spendono in loro database. Quindi ti do un idea dei risparmi sui costi che si può ottenere in Dynamo DB è enorme. Va bene, dropcam è un'altra società. Questi tipo una specie di-- se si pensa di internet delle cose, dropcam è fondamentalmente video di sicurezza Internet. Hai messo la macchina fotografica là fuori. Fotocamera dispone di un sensore di movimento. Qualcuno arriva, innesca un cue point. Camera avvia la registrazione per un po 'fino a non rileva più alcun movimento. Mette quel video su internet. 

Dropcam era una società che è fondamentalmente passati a Dynamo DB perché erano vivendo enormi dolori della crescita. E quello che ci hanno detto, petabyte improvvisamente di dati. Non avevano idea loro servizio sarebbe così tanto successo. Altri video in entrata di YouTube è ciò che questi ragazzi stanno ottenendo. Usano DynamoDB seguire tutto il metadati su tutti i loro punti chiave video. 

Così hanno secchi S3 Spingono tutti gli artefatti binari in. E poi hanno Record Dynamo DB indicare le persone a quegli S3 tre oggetti. Quando hanno bisogno di guardare un video, guardano il record di Dynamo DB. Fatto clic sul collegamento. Essi tirare giù il video da S3. Ecco, questo è ciò che questo tipo di assomiglia. E questo è direttamente dal loro squadra. 

Dynamo DB riduce la loro termine di consegna per eventi video da cinque a 10 secondi. Nel loro negozio relazionale vecchio, hanno usato per andare ed eseguire più query complesse a figura quale video per tirare giù, a meno di 50 millisecondi. Quindi è incredibile, incredibile quanto le prestazioni si può ottenere quando si ottimizza e si sintonizza il database sottostante per supportare il tipo di accesso. Halfbrick, questi ragazzi, di cosa si tratta, Fruit Ninja Credo che è la loro cosa. Che tutte le corse su Dynamo DB. E questi ragazzi, sono una grande team di sviluppo, grande sviluppo negozio. 

Non è una buona squadra ops. Non avevano un sacco delle risorse di funzionamento. Loro stavano lottando cercando di mantenere la loro infrastruttura applicativa su e funzionante. Sono venuti da noi. Hanno guardato che la DB Dynamo. Hanno detto, questo è per noi. Hanno costruito la loro intera framework applicazione su di esso. Alcuni commenti veramente bello qui dal team sulla loro capacità per ora concentrarsi sulla costruzione il gioco e non dover mantenere la infrastrutture, che stava diventando una quantità enorme di overhead per la loro squadra. Quindi questo è qualcosa che-- la beneficio che si ottiene da Dynamo DB. 

Va bene, entrare in modellazione dei dati qui. E abbiamo parlato un po ' questo per uno, uno a molti, e molti a molti rapporti di tipo. E come si fa a mantenere quelli in Dynamo. In Dynamo DB usiamo indici, in generale, per ruotare i dati da un sapore all'altro. Chiavi hash, chiavi gamma e indici. 

In questo particolare ad esempio, come la maggior parte degli stati hanno un obbligo di licenza che solo una licenza di pilota di a persona. Non si può andare a prendere due guidatore licenze nello stato di Boston. Io non posso farlo in Texas. Questo è il tipo di così com'è. E così al DMV, abbiamo le ricerche, abbiamo voler cercare la patente di guida per il numero di previdenza sociale. Voglio guardare i dati utente dal numero della patente di guida. 

Così potremmo avere tavolo di un utente che ha una chiave hash sul numero di serie, o il numero di previdenza sociale, e vari attributi definiti sulla voce. Ora su quel tavolo io potrebbe definire un GSI che flip che in giro che dice che voglio una chiave hash sulla licenza e poi tutte le altre voci. Ora, se voglio interrogare e trovare il numero di licenza per un dato sociale Numero di sicurezza, non posso interrogare la tabella principale. 

Se voglio interrogare e voglio per ottenere la sicurezza sociale numero o altri attributi di un numero di licenza, posso interrogare il GSI. Questo modello è che uno una relazione. Basta un semplice GSI, capovolgere le cose intorno. Ora, parlare di uno a molti. Uno a molti è fondamentalmente la chiave gamma hash. Dove abbiamo un sacco con questo caso d'uso è dati di monitoraggio. Dati Monitor è disponibile in regolare intervallo, come internet delle cose. Siamo sempre tutti questi record proveniente in tutto il tempo. 

E voglio trovare tutte le letture tra un determinato periodo di tempo. E 'una domanda molto comune in infrastruttura di monitoraggio. Il modo in cui andare a tale proposito è quello di trovare una semplice struttura della tabella, una tabella. Ho una tabella di misure dell'apparecchiatura con una chiave hash l'ID del dispositivo. E ho una chiave gamma sul timestamp, o in questo caso, l'epopea. E che mi permette eseguire complesse query che chiave gamma e restituire quei record che sono relative al risultato set che sto cercando. E costruisce che uno ai molti rapporto nella tabella principale utilizzando la tasto cancelletto, gamma struttura chiave. 

Ecco, questo è tipo di costruito nella tabella di Dynamo DB. Quando mi definisco un hash e tavolo gamma t, io sono definire un uno a molti. Si tratta di una relazione padre-figlio. 

Parliamo di molti per molte relazioni. E per questo particolare esempio, ancora una volta, stiamo andando a utilizzare GSI di. E parliamo di gioco scenario in cui ho un determinato utente. Voglio trovare tutti i giochi che ha registrato per o giocare in. E per un determinato gioco, vuole trovare tutti gli utenti. Allora, come faccio a farlo? Il mio tavolo giochi degli utenti, vado per avere una chiave hash di ID utente e una chiave gamma del gioco. 

Così un utente può avere più giochi. E 'un uno a molti tra l'utente e le partite che interpreta. E poi il GSI, Io capovolgere che circa. Io hash sul gioco e Io gamma per l'utente. Quindi, se voglio ottenere tutte le gioco l'utente di giocare in, Mi interrogo la tabella principale. Se voglio ottenere tutti gli utenti che stanno giocando un gioco particolare, Interrogo il GSI. Quindi, vedete come lo facciamo? Si crea di questi GSI a sostegno della uso caso, l'applicazione, l'accesso modello, l'applicazione. 

Se ho bisogno di interrogare su questa dimensione, lascia me crea un indice su quella dimensione. Se non lo faccio, non mi interessa. E a seconda del caso d'uso, I potrebbe essere necessario l'indice o non potrebbe. Se si tratta di un semplice uno a molti, tabella primaria va bene. Se ho bisogno di fare questi molti a molti di, o ho bisogno di fare un a quelli, allora forse ho bisogno al secondo l'indice. Quindi tutto dipende da quello che sto cercando di fare e quello che sto cercando di ottenere compiuta. 

Probabilmente io non ho intenzione di spendere troppo molto tempo a parlare di documenti. Questo diventa un po ', probabilmente, più profondo di quanto abbiamo bisogno di andare in. Parliamo un po ' espressione di query su ricchi. Quindi, in Dynamo DB abbiamo la capacità di creare ciò che noi chiamiamo le espressioni di proiezione. Espressioni di proiezione sono semplicemente scegliere i campi oi valori che si desidera visualizzare. OK, allora faccio una selezione. Faccio una query contro la Dynamo DB. E io dico, sai cosa, spettacolo me solo le recensioni a cinque stelle per questo particolare prodotto. Ecco, questo è tutto quello che voglio vedere. Non voglio vedere tutto il altri attributi della fila, Voglio solo vedere questo. È proprio come in SQL quando si dire selezionare stella o da tavolo, si ottiene tutto. Quando dico selezionare il nome da tavolo, io ho soltanto un attributo. E 'lo stesso tipo di cosa in Dynamo DB o un altro database NoSQL. Filtrare espressioni mi permettono di fondamentalmente tagliare il set di risultati verso il basso. Così faccio una query. Query può tornare con 500 articoli. Ma io voglio solo gli elementi che avere un attributo che dice questo. OK, quindi cerchiamo di filtrare le voci che non corrispondono quella query particolare. Così abbiamo espressioni di filtro. 

Filtro espressioni possono essere eseguito su qualsiasi attributo. Non sono come le query gamma. Alzare query sono più selettivi. Query di filtro mi impongono di andare vengono impostati l'intero risultato e poi ritagliarsi i dati che non voglio. Perché è così importante? Perché ho letto tutto. In una query, ho intenzione di leggere e sta andando essere un gigante sui dati. E poi ho intenzione di ritagliarmi cosa ho bisogno. E se sto solo ritagliarsi un paio di righe, quindi va bene così. Non è così inefficiente. 

Ma se io sto leggendo un mucchio di i dati, solo per ritagliarsi una voce, poi ho intenzione di essere meglio fuori utilizzando una query gamma, perché è molto più selettivo. Sta andando a me risparmiare un sacco di soldi, perché devo pagare per quella lettura. Se i risultati che ritorna attraversare quel filo potrebbe essere più piccolo, ma sto pagando per la lettura. Quindi, capire come che stai ricevendo i dati. Questo è molto importante in Dynamo DB. 

Espressioni condizionali, questo è ciò che si potrebbe chiamare lock ottimistico. Aggiornamento SE ESISTE, o se questo valore è equivalente a quello che ho specificato. E se ho un timbro di tempo su un disco, potrei leggere i dati. Potrei cambiare la situazione dei dati. Potrei andare scrivere che indietro i dati nel database. Se qualcuno ha modificato il record, il timestamp potrebbe avere cambiato. E in questo modo il mio condizionale aggiornamento potrebbe dire aggiornamento se il timestamp è uguale a questo. O l'aggiornamento non riuscirà perché qualcuno aggiornato il record nel frattempo. 

Questo è ciò che noi chiamiamo il blocco ottimistico. Vuol dire che qualcuno può entrare e cambiare, e ho intenzione di rilevarla quando torno a scrivere. E poi posso effettivamente letto che dati e dire: oh, ha cambiato questo. Ho bisogno di tenere conto di questo. E posso modificare i dati della mia registrare e applicare un altro aggiornamento. Così si può prendere quelli incrementali aggiornamenti che si verificano tra il momento di leggere i dati e la ora è possibile scrivere i dati. 

AUDIENCE: E il filtro espressione in realtà non significa nel numero o not-- 

[VOICES interponendo] RICK Houlihan: non lo farò ottenere troppo in questo. Questa è una parola chiave riservata. La vista è una libbra riservata parola chiave in Dynamo DB. Ogni database ha il suo riservata nome della raccolta non possono essere utilizzate. Dynamo DB, se si specifica una libbra di fronte a questo, è possibile definire i nomi sopra. Questo è un valore di riferimento. Non è probabilmente il miglior sintassi per avere lassù per questa discussione, perché ottiene in alcuni real-- Avrei parlato di più riguardo ad un livello più profondo. 

Ma basti dire, questo potrebbe essere richiesta la scansione in cui views-- né viste libbra è maggiore di 10. Si tratta di un valore numerico, sì. Se si vuole, si può parlare di che dopo la discussione. Va bene, quindi stiamo entrando alcuni scenari in best practice dove stiamo andando a parlare su alcune applicazioni qui. Quali sono i casi di utilizzo per la Dynamo DB. Quali sono il disegno modelli in Dynamo DB. 

E il primo che andremo a parlare è l'internet delle cose. Quindi abbiamo un sacco di-- credo, ciò è it-- più del 50% del traffico su internet in questi giorni è in realtà generato dalle macchine, processi automatizzati, non da esseri umani. Voglio dire, questa cosa questa cosa che portare in giro in tasca, quantità di dati che che cosa è in realtà l'invio in giro senza di te sapendo che è assolutamente incredibile. La posizione, le informazioni su quanto velocemente si sta andando. Come pensi che Google Maps funziona quando vi dicono che cosa il traffico è. È perché ci sono milioni e milioni di persone guidando con i telefoni che inviano Dati di tutto luogo per tutto il tempo. Così una delle cose su questo tipo di dati che viene in, dati di monitoraggio, il log- dati, dati di serie temporali, è il suo di solito solo interessante per un po 'di tempo. Dopo questo tempo, è non così interessante. Così abbiamo parlato, non lasciare tali tabelle crescere senza limiti. L'idea è che forse ho 24 ora vale la pena di eventi della mia tavola calda. E quella tavola calda sta per essere provisioning a un tasso molto alto, perché sta prendendo un sacco di dati. Sta prendendo un sacco di dati in e sto leggendo molto. Ho un sacco di operazione query in esecuzione contro tali dati. 

Dopo 24 ore, hey, so cosa, non mi interessa. Così forse io ogni rotolo di mezzanotte mio tavolo a un nuovo tavolo e io deprovisioning questa tabella. E mi prendo il telecomando e Giù di WCU perché 24 ore dopo Io non sto correndo come molti query che i dati. Quindi ho intenzione di risparmiare denaro. E forse i 30 giorni più tardi non lo faccio nemmeno bisogno di preoccuparsi di tutto. Potrei prendere il WCU del tutta la strada fino a uno, perché si sa che cosa, e ' mai andando ottenere scritto. Il dato è di 30 giorni. Non cambia mai. 

Ed è quasi mai andando ottenere leggere, quindi cerchiamo di prendere solo quello telecomando fino a 10. E sto risparmiando un sacco di soldi per questo i dati, e pagare solo per i miei dati a caldo. Ecco, questo è la cosa importante da guardare a quando si guarda a una serie storica dati che arriva in volume. Si tratta di strategie. Ora, ho potuto solo lasciarlo vanno tutti allo stesso tavolo e lasciare quel tavolo crescere. Alla fine, ho intenzione di vedi problemi di prestazioni. Ho intenzione di dover ricominciare da archiviare alcuni di tali dati dal tavolo, cosa no. 

Facciamo molto meglio progettare l'applicazione in modo da poter operare in questo modo giusto. Quindi è solo automatica nel codice dell'applicazione. A mezzanotte ogni notte rotola tabella. Forse quello che mi serve è un scorrevole finestra di 24 ore di dati. Poi su base regolare sono chiamando i dati fuori dal tavolo. Sto taglio con un Cron lavoro e sto mettendo su queste altre tabelle, qualunque cosa ti serva. Quindi, se un rollover funziona, che è grande. In caso contrario, finiture. Ma teniamo che i dati a caldo via dai vostri dati freddi. Esso ti risparmiare un sacco di soldi e rendere le tabelle più performante. Così la prossima cosa ne parleremo circa è catalogo prodotti. Catalogo prodotti è caso d'uso piuttosto comune. Questo è in realtà un modello molto comune che vedremo in una varietà di cose. Sai, per Twitter ad esempio, un tweet caldo. Ognuno sta arrivando e afferrando quel tweet. Catalogo prodotti, ho ottenuto una vendita. Ho ottenuto una vendita calda. Ho ottenuto 70.000 richieste al seconda venuta di un prodotto descrizione dal mio catalogo prodotti. Lo vediamo in dettaglio operazione un po '. Quindi, come abbiamo a che fare con questo? Non c'è modo di fare con questo. Tutti i miei utenti vogliono vedere lo stesso pezzo di dati. Stanno stanno arrivando, contemporaneamente. E stanno tutti facendo richieste per la stessa porzione di dati. Questo mi dà quella chiave caldo, quel grande rosso striscia sul mio grafico che non ci piace. Ed è quello che sembra. Così attraverso il mio spazio chiave Ricevo martellato nelle voci di vendita. Sto ottenendo nulla altrove. 

Come posso alleviare questo problema? Beh, alleviamo questo con cache. Cache, si mette in pratica un in-memory partizione di fronte al database. Siamo riusciti [Incomprensibile] cache, come si può impostare la propria cache, [incomprensibile] cache [? d,?] quello che volete. Mettere che di fronte database. E in questo modo è possibile memorizzare i dati da quei tasti di scelta rapida in quel nascondiglio spazio e leggere attraverso la cache. 

E poi la maggior parte del vostro letture iniziare a guardare come questo. Mi sono tutti questi nascondiglio urta qui e mi sono nulla succede qui perché database è seduto dietro la cache e la letture mai venire attraverso. Se cambio i dati del base di dati, devo aggiornare la cache. Possiamo usare qualcosa come vapori di farlo. E ti spiego come funziona. D'accordo, la messaggistica. E-mail, che noi tutti usiamo e-mail. 

Questo è un buon esempio. Abbiamo una sorta di tabella dei messaggi. E abbiamo ottenuto posta in arrivo e in uscita. Questo è ciò che il SQL sarebbe guarda come per costruire quella casella di posta. Noi tipo di utilizzo dello stesso tipo di strategia da utilizzare GSI di, GSI di per la mia casella di posta e la mia posta in uscita. Così ho preso i messaggi provenienti prime nella mia tabella dei messaggi. E il primo approccio a questo potrebbe essere, diciamo, OK, nessun problema. Ho messaggi prime. Messaggi provenienti [incomprensibile], messaggio di ID, che è grande. Questo è il mio hash univoco. Ho intenzione di creare due GSI di, uno per la mia casella di posta, uno per il mio in uscita. E la prima cosa che farò è Dirò la mia chiave hash è sarà il destinatario e Ho intenzione di organizzare il giorno. È fantastico. Ho ottenuto il mio bella vista qui. Ma c'è un piccolo problema qui. E si esegue in questo database relazionali come bene. Hanno chiamato partizionamento verticale. Si desidera mantenere i vostri dati grande via dai vostri dati piccoli. 

E il motivo è perché io devo andare a leggere gli elementi per ottenere gli attributi. E se i miei corpi sono tutti qui, poi leggendo pochi elementi se il mio corpo è la lunghezza una media di 256 kilobyte ciascuno, la matematica diventa piuttosto brutto. Quindi dire che voglio leggere posta in arrivo di David. Posta in arrivo di David ha 50 elementi. La media e la dimensione è di 256 kilobyte. Ecco il mio rapporto di conversione per RCU di è quattro kilobyte. 

Ok, andiamo con infine coerente legge. Sto ancora mangiando 1.600 telecomando di solo per leggere posta in arrivo di David. Ahia. OK, ora pensiamo su come funziona l'applicazione. Se mi trovo in una e-mail app e Sto guardando la mia casella di posta, e guardo il corpo di ogni messaggio, no, sto guardando i sommari. Sto guardando solo le intestazioni. Quindi cerchiamo di costruire una struttura di tabella che sembra più simile a quella. 

Quindi, ecco le informazioni che il mio flusso di lavoro ha bisogno. E 'nella mia casella di posta GSI. E 'la data, il mittente, il soggetto, e quindi l'ID del messaggio, che punta torna alla tabella dei messaggi dove posso trovare il corpo. Ebbene, questi sarebbero gli ID record. Avrebbero puntare di nuovo al ID elemento sul tavolo Dynamo DB. Ogni indice creates-- sempre ha sempre la voce ID come parte di-- che viene fornito con l'indice. 

Tutto ok. PUBBLICO: Si dice che dove è conservato? RICK Houlihan: Sì, racconta exactly-- questo è esattamente quello che fa. Qui dice il mio record di re. E sarà puntare di nuovo al mio record re. Di preciso. OK, ora la mia casella di posta è in realtà molto più piccolo. E questo in realtà sostiene il flusso di lavoro di una e-mail app. Così la mia casella di posta, clicco. Vado avanti e faccio clic sul messaggio, in quel momento che ho bisogno di andare a prendere il corpo, perché ho intenzione di andare a una visione diversa. Quindi, se si pensa di tipo MVC quadro, controllore vista del modello. 

Il modello contiene la i dati che i bisogni vista e il controllore interagisce. Quando cambio il telaio, quando A cambiare il punto di vista, va bene per tornare al server e ripopolare il modello, perché è quello che l'utente si aspetta. Quando cambiano di vista, in quel momento possiamo tornare al database. Quindi e-mail, fare clic su. Sto cercando il corpo. Andata e ritorno. Vai a prendere il corpo. 

Leggo molto meno dati. Sono solo leggendo i corpi che David ha bisogno quando ne ha bisogno. E non sto brucio nel 1600 RCU di solo per mostrare la sua casella di posta. Così ora che-- questo è il modo che LSI o GSI-- mi dispiace, GSI, avrebbe funzionato. Abbiamo il nostro hash al beneficiario. Abbiamo il tasto della gamma della data. E abbiamo gli attributi previsti che abbiamo bisogno solo di sostegno della tesi. 

Ruotiamo che per la posta in uscita. Hash al mittente. E in sostanza, abbiamo molto bella, vista pulita. Ed è che basically-- avere questo bel messaggio tabella che viene diffuso bene perché è solo hash, ID messaggio hash. E abbiamo due indici sono a rotazione fuori di quel tavolo. Va bene, quindi idea qui è fare non tenere i grandi dati e questo piccolo dati insieme. Partition verticalmente, partizionare tali tabelle. Non leggere dati che non è necessario. Va bene, il gioco. A tutti noi piace giochi. Almeno Mi piacciono i giochi allora. Così alcune delle cose che abbiamo a che fare con quando stiamo pensando di gioco, giusto? Gaming questi giorni, soprattutto mobili di gioco, è tutto di pensare. E ho intenzione di girare qui un po 'lontano dalla DynamoDB. Ho intenzione di portare a alcune delle discussioni intorno alcuni dei altre tecnologie AWS. 

Ma l'idea di gioco è quella di pensare circa in termini di API, le API che sono, in generale, HTTP e JSON. E 'come i giochi mobili tipo di interagire con i loro back end. Fanno JSON distacco. Ottengono i dati, ed è tutto, in generale, in bei API JSON. 

Cose come ottenere amici, ottengono i dati leaderboard, scambio, contenuto generato dall'utente, spingere indietro fino al sistema, questi sono i tipi di cose che andremo a fare. Dati risorsa binari, questi dati potrebbe non sedersi nel database. Questo potrebbe sedersi in un archivio degli oggetti, giusto? Ma il database sta per finiscono per raccontare il sistema, raccontando l'applicazione dove andarlo a prendere. E, inevitabilmente, il multiplayer server, infrastruttura di back-end, e progettata per elevate disponibilità e scalabilità. Quindi, queste sono cose che tutti noi vogliamo nelle infrastrutture di gioco di oggi. 

Quindi, diamo uno sguardo a quello che sembra. Hai un back-end di base, molto semplice. Abbiamo un sistema di qui con più zone disponibilità. Abbiamo parlato di come AZS being-- pensare a loro come data center separati. Più di un centro dati per AZ, ma va bene così, basti pensare a loro come dati separata Centri che sono geograficamente e colpa isolato. 

Stiamo per avere un istanze EC2 coppia. Stiamo per avere qualche server back-end. Forse, se sei un lascito architettura, siamo utilizzando ciò che noi chiamiamo RDS, servizi di database relazionali. Potrebbe essere MSSQL, MySQL, o qualcosa di simile. Si tratta di un sacco di applicazioni way sono oggi progettato. 

Beh si potrebbe desiderare di andare con questo è quando si scala fuori. Andremo avanti e mettere il secchio S3 lassù. E quel secchio S3, invece di servire up quegli oggetti del nostro servers-- potremmo farlo. Hai messo tutto il tuo binario oggetti nei server ed è possibile utilizzare quelli di server le istanze per servire i dati su. Ma questo è piuttosto costoso. 

Modo migliore da fare è andare avanti e mettere quegli oggetti in un secchio di S3. S3 è oggetto un repository. E 'costruito appositamente per servendo questi tipi di cose. E lasciare che i clienti richiedono direttamente da quelli secchi oggetto, offload dei server. Quindi stiamo iniziando a scalare qui. 

Ora abbiamo ottenuto utenti di tutto il mondo. Ho utenti. Ho bisogno di avere contenuti a livello locale situato vicino a questi utenti, giusto? Ho creato un secchio S3 come il mio repository di origine. E sarò anteriore che con la distribuzione CloudFront. 

CloudFront è un CD e un Content Delivery Network. Fondamentalmente prende i dati che si specifica e memorizza nella cache il tutto su internet così gli utenti in tutto il mondo possono avere una risposta molto veloce quando chiedono tali oggetti. 

Così si ottiene un idea. Stai tipo di sfruttare tutte le aspetti di AWS qui per ottenere questo fatto. E alla fine, gettiamo in un gruppo di ridimensionamento automatico. Così i nostri casi AC2 dei nostri server di gioco, in cui iniziano a essere più affollato e più affollate e frequentate, faranno solo girare un altro esempio, girare un altro caso, girare un'altra istanza. Così la tecnologia AWS ha, consente di specificare i parametri attorno al quale i server cresceranno. Così si può avere n numero di server là fuori in un dato momento. E se il vostro carico se ne va, faranno restringersi, il numero si ridurrà. E se il carico torna, esso crescerà di nuovo fuori, elasticamente. 

Quindi questo sembra grande. Abbiamo un sacco di istanze EC2. Possiamo mettere cache fronte dei database, cercare di accelerare i database. Il punto di pressione prossimo in genere la gente vede sono loro scalare un gioco con un sistema di database relazionale. Cribbio, il database prestazioni è terribile. Come possiamo migliorare questo? Proviamo mettendo la cache di fronte a quella. 

Beh, la cache non funziona così grande nei giochi, giusto? Per i giochi, la scrittura è doloroso. I giochi sono molto scrivono pesante. Cache non funziona quando si è scrivere pesante perché hai sempre avuto modo di aggiornare la cache. Si aggiorna la cache, è irrilevante da caching. In realtà è solo un lavoro extra. 

Allora dove andiamo qui? Hai un grande collo di bottiglia laggiù nel database. E il posto dove andare ovviamente è partizionamento. Partizionamento non è facile da fare quando si è che fare con i database relazionali. Con i database relazionali, sei responsabile della gestione, in modo efficace, lo spazio delle chiavi. Stai dicendo che gli utenti tra A e M andate qui, tra N e Z ci vanno. E stai passando attraverso l'applicazione. Quindi hai a che fare con questa fonte di dati partizione. Si hanno vincoli transazionali che non si estendono le partizioni. Hai tutti i tipi di disordine che sei trattare con laggiù provare a che fare con la scalabilità orizzontale e la costruzione di una infrastruttura più grande. E 'solo non è divertente. 

PUBBLICO: Quindi stai dicendo che aumentando punti sorgente accelera il processo? RICK Houlihan: Aumento? Punti Fonte: UDIENZA. RICK Houlihan: punti di origine? AUDIENCE: Dalle informazioni, dove l'informazione proviene da? RICK Houlihan: No. Quello che sto dicendo è l'aumento della numero di partizioni in archivio dati migliora il throughput. Così che cosa sta accadendo qui è utenti entrando nella istanza EC2 qui, bene, se ho bisogno di un utente che è da A a M, vado qui. Da N a p, vado qui. Da P alla Z, vado qui. 

PUBBLICO: OK, quelli così quelle sono tutti memorizzati in diversi nodi? 

RICK Houlihan: Sì. Pensate a questi come diversi silos di dati. Quindi stai dover fare questo. Se stai cercando di fare questo, se si sta cercando in scala su una piattaforma relazionale, questo è quello che stai facendo. Stai prendendo i dati e si sta tagliando verso il basso. E stai partizionamento trasversalmente più istanze di database. E si sta gestendo tutto ciò che al livello applicazione. Non è divertente. Così che cosa vogliamo andare? Vogliamo andare DynamoDB, completamente gestito, Archivio dati NoSQL, il throughput disposizione. Usiamo indici secondari. Si tratta fondamentalmente di HTTP API e include il supporto dei documenti. Quindi non ci si deve preoccupare nulla di tutto ciò partizionamento. Facciamo tutto per voi. Così ora, invece, basta scrivere al tavolo. Se la tabella deve essere partizionato, che accade dietro le quinte. Sei completamente isolato da che come sviluppatore. Quindi parliamo di alcuni casi di utilizzo che ci imbattiamo in nel gioco, comuni scenari di gioco, classifica. Così hai gli utenti in arrivo, le BoardNames che stanno su, i punteggi per questo utente. Potremmo essere hashing sul UserID, e poi abbiamo gamma sul gioco. Così ogni utente vuole vedere tutto il gioco che ha giocato e tutto il suo punteggio più alto attraverso tutto il gioco. Ecco, questo è il suo classifica personale. 

Ora voglio andare e voglio get-- in modo da ottenere queste classifiche personali. Quello che voglio fare è andare a prendere il punteggio più alto tra tutti gli utenti. Allora, come faccio a farlo? Quando il mio disco viene assegnata su la UserID, spaziava sul gioco, bene ho intenzione di andare avanti e ristrutturare, creare un GSI, e ho intenzione di ristrutturare tali dati. 

Ora ho intenzione di hash sul BoardName, che è il gioco. E ho intenzione di spaziare sul punteggio superiore. E ora ho creato diversi secchi. Sto utilizzando la stessa tabella, gli stessi dati voce. Ma Sto creando un secchio che dà mi un'aggregazione di punteggio più alto da gioco. 

E posso interrogare quel tavolo per ottenere tali informazioni. Quindi ho messo quel modello di query fino a essere sostenuta da un indice secondario. Ora possono essere ordinati per BoardName e ordinati per Topscore, seconda. Così si può vedere, questi sono i tipi di casi d'uso che si ottiene nel gioco. Un altro buon caso di utilizzo entriamo in gioco è premi e che ha vinto i premi. E questo è un grande caso d'uso dove noi chiamiamo indici sparse. Sparse indici sono il capacità di generare un indice che non lo fa necessariamente contenere ogni singolo elemento sul tavolo. E perchè no? Perché l'attributo che viene indicizzato non esiste su ogni articolo. 

Quindi, in questa particolare uso caso, sto dicendo, sai cosa, ho intenzione di creare un attributo denominato Award. E ho intenzione di dare ad ogni utente che ha un premio che attributo. Gli utenti che non dispongono di premi sono non andando ad avere tale attributo. Così, quando creo il indice, gli unici utenti che stanno per mostrare nell'indice sono quelli che effettivamente hanno vinto premi. Ecco, questo è un ottimo modo per essere in grado per creare indici filtrati che sono molto, molto selettivo che non lo fanno avere per indicizzare l'intera tabella. 

Così siamo sempre a corto di tempo qui. Ho intenzione di andare avanti e saltare fuori e saltare questo scenario. Parlare un po 'about-- 

PUBBLICO: Posso fare una domanda veloce? Uno è scrivere pesante? RICK Houlihan: Che cosa è? PUBBLICO: Scrivi pesante. RICK Houlihan: Scrivere pesante. Fammi vedere. 

PUBBLICO: O è che non qualcosa che si può solo voce in pochi secondi? RICK Houlihan: Andiamo attraverso lo scenario di voto. Non è così male. Fate voi ragazzi avete qualche minuto? OK. 

Quindi parleremo di voto. Così il voto in tempo reale, abbiamo requisiti per il voto. I requisiti sono che ci permettono ogni persona di votare una sola volta. Vogliamo che nessuno sia in grado a cambiare il loro voto. Vogliamo aggregazione in tempo reale e analisi di dati demografici che stiamo andando a essere dimostrando di utenti sul sito. 

Pensate a questo scenario. Lavoriamo molto della realtà TV mostra dove sono facendo queste esatto tipo di cose. Così si può pensare di scenario, abbiamo milioni e milioni ragazze di adolescenti là con i loro telefoni cellulari e il voto, e il voto, e votare per chiunque essi siano trova ad essere il più popolare. Quindi questi sono alcuni dei richieste di prenotazione esauriscono. 

E così la prima prendere per risolvere il problema sarebbe di costruire un molto semplice applicazione. Così ho questa applicazione. Ho alcuni elettori là fuori. Vengono in, hanno colpito l'applicazione di voto. Ho un po 'grezzo voti tavolo Mi limiterò a discarica quei voti in. Avrò qualche aggregato voti tabella che faranno i miei analisi e la demografia, e metteremo tutto in là. 

E questo è grande. La vita è bella. La vita è buona fino a quando abbiamo scoperto che c'è sempre solo uno o due persone che sono popolari in un'elezione. Ci sono solo una o due cose che le persone veramente a cuore. E se si sta votando a scala, tutto ad un tratto sono andando a martellare l'inferno fuori di due candidati, uno o due candidati. Un numero molto limitato di articoli persone trovano ad essere popolare. 

Questo non è un buon modello di progettazione. Questo è in realtà un pessimo design pattern perché crea esattamente ciò che parlato che era tasti di scelta rapida. Tasti di scelta rapida sono qualcosa che non ci piace. 

Quindi, come possiamo risolvere questo? E davvero, il modo per risolvere questo problema è prendendo quelli secchi candidati e per ogni candidato che abbiamo, stiamo andando a aggiungere un valore casuale, qualcosa che sappiamo, casuale valore compreso tra uno e 100, tra 100 e 1.000, o tra uno e 1.000, tuttavia molti valori casuali si desidera aggiungere sulla fine di quel candidato. 

E quello che ho fatto veramente, allora? Se sto utilizzando l'ID candidato come il secchio per voti aggregati, se ho aggiunto un caso numero alla fine di questo, Ho creato la società 10 secchi, un cento, mille secchi secchi che sto aggregare voti in tutto. 

Così ho milioni e milioni, e milioni di record in arrivo per questi candidati, ora sto diffondendo quei voti in tutta A_1 Candidate attraverso A_100 Candidato, perché ogni volta che un voto entra, Sto generando un casuale valore compreso tra uno e 100. Sto virata che sull'estremità del il candidato che la persona di votare per. Sto dumping in quel secchio. 

Ora sul retro, lo so che ho avuto un centinaio di secchi. Così, quando ho voglia di andare avanti e aggregare i voti, Ho letto da tutti quelli secchi. Così vado avanti e aggiungi. E poi io la dispersione raccogliere dove vado fuori e dire hey, si sa che cosa, la chiave di questo candidato spazi è oltre un centinaio di secchi. Ho intenzione di raccogliere tutte le voti da quei cento secchi. Ho intenzione di aggregare li e ho intenzione di dire, Il candidato A ha ora conteggio totale voto di x. 

Ora sia la scrittura query e la query di lettura sono ben distribuite perché sto scrivendo tutto e sto leggendo su centinaia di chiavi. Non sto scrivendo e la lettura attraverso una chiave ora. Ecco, questo è un grande modello. 

Questo è in realtà probabilmente uno del design più importante modelli per scala NoSQL. Vedrete questo tipo di modello di progettazione in ogni sapore. MongoDB, DynamoDB, non è così materia, tutti noi dobbiamo fare questo. Perché quando hai a che fare con quelle enormi aggregazioni, si deve trovare un modo per diffonderli fuori attraverso secchi. Quindi questo è il modo di fare questo. Va bene, e allora si sta facendo in questo momento è entrato in negoziazione fuori di lettura costo per la scalabilità in scrittura. Il costo della mia lettura è un po 'più complesso e devo andare leggere da un cento secchi invece di uno. Ma io sono in grado di scrivere. E il mio rendimento, la mia scrittura il throughput è incredibile. Quindi è di solito una preziosa tecnica per il ridimensionamento DynamoDB, o qualsiasi database NoSQL per quella materia. Così abbiamo capito come la dimensioni. E abbiamo capito come eliminare i nostri tasti di scelta rapida. E questo è fantastico. E abbiamo ottenuto questo bel sistema. E ci ha dato molto corretto voto perché abbiamo record di voto de-babbeo. E 'costruito in DynamoDB. Abbiamo parlato di diritti condizionati. 

Quando un elettore entra, mette un inserimento nella tabella, inseriscono con la loro ID elettore, se si cerca di inserire un altro voto, Faccio una scrittura condizionale. Solo dire scrivere questo se questo non esiste. Così, non appena vedo che che il voto di colpire il tavolo, nessun altro sta per essere in grado di mettere il loro voto in. E questo è fantastico. E stiamo incrementando nostri sportelli candidati. E stiamo facendo del nostro demografia e tutto il resto. Ma cosa succede se il mio applicazione cade? Ora, tutto ad un tratto voti sono in arrivo, e io Non so se stanno ottenendo trattati nelle mie analisi e dati demografici più. E quando l'applicazione torna su, come diavolo faccio a sapere cosa hanno voti stato elaborato e da dove si comincia? 

Quindi questo è un vero problema quando si iniziare a guardare questo tipo di scenario. E come si fa a risolvere questo? Risolviamo con quello che abbiamo chiamare DynamoDB Streams. Streams è un tempo ordinato e partizionato change log di ogni accesso al tavolo, ogni scrittura accesso alla tabella. Tutti i dati che è scritto al tabella mostra sul torrente. 

Si tratta fondamentalmente di una coda di 24 ore. Elementi colpito il torrente, vivono per 24 ore. Essi possono essere letti più volte. Garantito da consegnare solo una volta al torrente, potrebbe essere letto n volte. Così tuttavia molti processi che si desidera consumare tali dati, si può consumare. Apparirà ogni aggiornamento. Ogni scrittura sarà solo comparire una sola volta sul torrente. Quindi non ci si deve preoccupare circa il trattamento due volte dallo stesso processo. 

E 'severamente ordinato per articolo. Quando diciamo tempo ordinato e diviso, vedrete per partizione sul torrente. Vedrete articoli, aggiornamenti in ordine. Noi non siamo garanti sul flusso che sei intenzione di ottenere ogni transazione nell'ordine di tutti gli elementi. 

Così flussi sono idempotente. Dobbiamo tutti cosa idempotente significa? Idempotent significa che si può fare oltre, e oltre, e più volte. Il risultato sarà lo stesso. 

Flussi sono idempotente, ma devono essere giocato dal punto di partenza, ovunque si desideri, fino alla fine, o non comporteranno negli stessi valori. 

Stessa cosa con MongoDB. MongoDB è un costrutto che chiamano la oplog. E 'esattamente lo stesso costrutto. Molti database NoSQL avere questo costrutto. Lo usano per fare le cose come la replica, che è esattamente quello che facciamo con i flussi. PUBBLICO: Forse un domanda eretica, ma voi parlare di applicazioni facendo giù un così via. Sono flussi garantiti mai possibilmente andare giù? RICK Houlihan: Sì, i flussi sono garantiti per non andare giù. Gestiamo l'infrastruttura alle spalle. ruscelli automaticamente implementare nel loro gruppo ridimensionamento automatico. Andremo attraverso un po ' po 'di quello che accade. 

Non dovrei dire che non sono garantito per non andare giù. Gli elementi sono garantiti ad apparire nel flusso. E il flusso sarà accessibile. Così che cosa va giù o ritorna up, ciò accade sotto. E covers-- è OK. D'accordo, in modo da ottenere diversi Tipi fuori dallo schermo. I tipi di vista che sono importanti per un programmatore in genere sono, che cosa era? Ho la vecchia visione. Quando un aggiornamento colpisce il tavolo, che sarà spingere il vecchio vista del flusso quindi i dati possono archiviare, o il cambiamento il controllo, l'identificazione cambiamento, cambiamento gestione. 

La nuova immagine, quello che è ora, dopo l'aggiornamento, questo è un altro tipo di vista Puoi prendere. È possibile ottenere sia le vecchie e nuove immagini. Forse tutti e due che voglio. Voglio vedere cosa fosse. Voglio vedere che cosa è cambiato a. 

Ho un tipo di conformità di processo che corre. Ha bisogno di verificare che quando queste cose cambiano, che sono entro certi limiti o entro certi parametri. 

E poi forse solo bisogno di sapere cosa è cambiato. Non mi interessa quello che è cambiato voce. Non ho bisogno di bisogno di sapere quali attributi cambiato. Ho solo bisogno di sapere che i prodotti sono toccati. Quindi questi sono i tipi di viste che si scende dal torrente e si può interagire. 

L'applicazione che consuma il torrente, questo è una specie di modo in cui funziona. Cliente DynamoDB chiede di spingere i dati nelle tabelle. Flussi distribuire su ciò che chiamiamo cocci. Frammenti vengono scalate indipendentemente dalla tabella. Essi non sono allineate completamente per le partizioni del vostro tavolo. E la ragione per cui è perché si allineano alla capacità, la corrente capacità del tavolo. 

Essi implementare nella loro proprio gruppo ridimensionamento automatico, e cominciano a girare fuori a seconda da quante scritture sono in arrivo, quanti reads-- realtà è scritto. Non c'è reads-- ma come diverse scritture sono in arrivo. 

E poi sul retro fine, abbiamo quello che chiamare un KCL o Kinesis Client Library. Kinesis è un flusso di dati tecnologia di elaborazione da Amazon. E torrenti è costruito su questo. 

Quindi si utilizza un KCL abilitato un'applicazione di leggere il flusso. La Biblioteca Kinesis Cliente realtà gestisce gli operai per voi. E lo fa anche un po ' cose interessanti. Si creerà alcune tabelle su nel tablespace DynamoDB per tracciare quali articoli sono stati elaborati. Quindi, in questo modo se cade indietro, se essa cade e viene e ottiene sorgeva il backup, è possibile determinare dove era nella elaborazione del flusso. 

Questo è molto importante quando si stai parlando di replica. Ho bisogno di sapere che cosa dati sono stati elaborati stati e quali dati sono ancora da elaborare. Così la libreria KCL per i flussi saranno vi darà un sacco di tale funzionalità. Si prende cura di tutto il servizio di pulizia. Si alza un lavoratore per ogni frammento. Si crea una tabella amministrativo per ogni frammento, per ogni lavoratore. E come quelli dei lavoratori del fuoco, mantengono tali tabelle in modo da sapere questo record è stato letto e trasformati. E poi in questo modo se il processo muore e torna in linea, può riprendere a destra dove è decollato. 

Quindi usiamo questo per replica tra regione. Molti clienti hanno la necessità di spostare i dati o le parti di loro tabelle di dati intorno alle diverse regioni. Ci sono nove regioni in tutto il mondo. Quindi ci potrebbe essere un io need-- potrebbero avere gli utenti in Asia, gli utenti nella costa orientale degli Stati Uniti. Essi hanno dati diversi che deve essere distribuito a livello locale. E forse un utente vola da Asia verso gli Stati Uniti, e voglio replicare i suoi dati con lui. Così, quando si scende dall'aereo, ha una buona esperienza con la sua app mobile. 

È possibile utilizzare la cross-regione biblioteca replica per fare questo. Fondamentalmente abbiamo fornito due tecnologie. Uno è un'applicazione console è possibile stare in piedi da soli istanza EC2. Funziona replica puro. E allora vi abbiamo dato la biblioteca. La biblioteca è possibile utilizzare per costruire la propria applicazione se si voglia di fare cose folli con quella data-- filtro, replicare solo una parte di essa, ruotare i dati, spostare in un tabella diversa, così via e così via. Ecco, questo è una specie di ciò che sembra. 

DynamoDB Streams può essere elaborati da ciò che noi chiamiamo Lambda. Abbiamo detto un po 'di evento architetture applicative guidato. Lambda è un componente chiave di questo. Lambda è il codice che spara su richiesta in risposta a un evento particolare. Uno di questi eventi può essere disco che appare sul torrente. Se un record appare sul torrente, chiameremo questa funzione Java. Bene, questo è JavaScript e Lambda supporta Node.js, Java, Python, e presto sostenere altre lingue. E basti dire, è codice puro. scrittura In Java, si definisce una classe. Si preme il JAR su in Lambda. E poi si specifica quale classe chiamare in risposta al quale evento. E poi l'infrastruttura Lambda dietro che verrà eseguito il codice. 

Quel codice in grado di elaborare record fuori dal torrente. Si può fare qualsiasi cosa che vuole con esso. In questo particolare esempio, tutti siamo realmente facendo sta registrando gli attributi. Ma questo è solo codice. Il codice può fare qualsiasi cosa, giusto? 

Così è possibile ruotare i dati. È possibile creare una vista derivata. Se si tratta di una struttura del documento, si può appiattire la struttura. È possibile creare indici alternativi. Tutti i tipi di cose che si possono che fare con i flussi DynamoDB. 

E davvero, questo è quello che sembra. Così si ottiene tali aggiornamenti in arrivo. Stanno venendo fuori la corda. Sono letti dalla funzione Lambda. Stanno rotazione i dati e spingendola verso l'alto nelle tabelle derivate, notificando sistemi esterni di cambiamento, e spingendo i dati in ElastiCache. 

Abbiamo parlato di come mettere la cache davanti al database per le vendite scenario. Beh, che cosa succede se aggiornare la descrizione articolo? Beh, se avessi un Lambda la funzione in esecuzione su quel tavolo, se aggiorno la descrizione dell'oggetto, sarà prendere il record fuori dal torrente, e sarà aggiornare il ElastiCache esempio con i nuovi dati. Ecco, questo è un sacco di ciò che facciamo con Lambda. E 'il codice colla, connettori. E dà realmente la capacità di lanciare e per eseguire applicazioni molto complesse senza un server dedicato infrastrutture, che è davvero cool. 

Quindi torniamo al nostro in tempo reale architettura votazioni. Questo è nuovo e migliorato con la nostra ruscelli e LKC abilitata applicazione. Stessa di prima, possiamo gestire qualsiasi scala di elezione. Ci piace questo. Stiamo facendo fuori raccoglie scatter in più secchi. Abbiamo blocco ottimistico in corso. Siamo in grado di mantenere i nostri elettori di cambiare i loro voti. Possono votare solo una volta sola. È fantastico. Tolleranza ai guasti in tempo reale, aggregazione scalabile ora. Se la cosa cade, esso sa dove per riavviare stesso quando si tratta di eseguire il backup perché stiamo utilizzando l'applicazione KCL. E poi possiamo anche usare quella Applicazione KCL per spingere i dati fuori a redshift per altri analisi delle applicazioni, o l'uso le MapReduce elastici a correre streaming in tempo reale aggregazioni off di tali dati. 

Quindi, queste sono le cose che noi Non hanno parlato molto. Ma sono aggiuntivo tecnologie che vengono a sopportare quando stai cercando questi tipi di scenari. 

Va bene, in modo che su di analisi con DynamoDB Streams. È possibile raccogliere de-babbeo i dati, fare tutti i tipi di roba bella, dati aggregati in la memoria, creare tali tabelle derivati. Questo è un enorme caso d'uso che un sacco di clienti sono coinvolti con, prendendo la nidificato proprietà di tali documenti JSON e la creazione di indici aggiuntivi. 

Siamo alla fine. Grazie per cuscinetto con me. Quindi parliamo di architettura di riferimento. DynamoDB si trova nel mezzo di così gran parte dell'infrastruttura AWS. Fondamentalmente si può collegarlo fino a tutto quello che vuoi. Le applicazioni create utilizzando Dynamo includono Lambda, ElastiCache, CloudSearch, spingere i dati fuori in elastico MapReduce, import export da DynamoDB in S3, tutti i tipi di flussi di lavoro. Ma probabilmente il migliore cosa di cui parlare, e questo è ciò che è realmente interessante è quando noi parlare di applicazioni event-driven. 

Questo è un esempio di un progetto interno che abbiamo dove siamo realmente pubblicazione per raccogliere i risultati dell'indagine. Quindi, in un collegamento e-mail che inviamo fuori, ci sarò essere un po 'click collegamento dicendo qui a rispondere al sondaggio. E quando una persona fa clic quel collegamento, ciò che accade è tirano giù un sicuro Modulo di indagine HTML da S3. Non c'è alcun server. Questo è solo un oggetto S3. 

Quella forma viene in su, carica nel browser. E 'ottenuto Backbone. E 'ottenuto complesso JavaScript che è in esecuzione. Quindi è molto ricco applicazione in esecuzione nel browser del client. Non sanno che non sono interagire con un server back-end. A questo punto, è tutto browser. 

Pubblicano i risultati a ciò che che noi chiamiamo l'Amazzonia gateway API. Gateway API è semplicemente una API web che è possibile definire e collegare o qualsiasi altra cosa. In questo caso particolare, siamo collegato ad una funzione Lambda. 

Così la mia operazione POST accadendo con nessun server. Fondamentalmente che gateway API sta lì. Mi costa nulla finché la gente iniziare a postare ad esso, giusto? La funzione Lambda appena ci si siede. E mi costa nulla fino la gente inizia colpirlo. Così si può vedere, come il volume aumenta, in quel momento che le accuse arrivano. Non sto in esecuzione un server 7/24. 

Così ho tirare il modulo giù dal secchio, e vi posto attraverso l'API Gateway nella funzione Lambda. E poi il Lambda Funzione dice, sai ciò, ho alcuni PII, alcuni informazioni di identificazione personale in queste risposte. Ho avuto i commenti provenienti da utenti. Ho indirizzi e-mail. Ho i nomi utente. 

Permettetemi di dividere questa via. Ho intenzione di generare un certo metadati fuori questo disco. E ho intenzione di spingere la metadati in DynamoDB. E potrei crittografare tutti i dati e spingerlo in DynamoDB se voglio. Ma è più facile per me, in questo utilizzare caso, di andare avanti un esempio, Ho intenzione di spingere i dati grezzi in un secchio S3 crittografato. Così ho utilizzare costruito in lato server S3 crittografia e gestione delle chiavi di Amazon Servizio in modo da avere una chiave che può ruotare a intervalli regolari, e posso proteggere i dati PII come parte di tutto questo flusso di lavoro. 

Allora, cosa ho fatto? Ho appena implementato un intero applicazione, e non ho alcun server. Quindi, è ciò che l'applicazione event driven architettura fa per voi. 

Ora, se ci pensate il caso d'uso per questo-- abbiamo altri clienti di cui sto parlando per questo esatto architettura che eseguire fenomenale grandi campagne, che stanno guardando questo e andare, oh mio. Perché ora, possono fondamentalmente spingerlo fuori là, lasciare che la campagna solo sedersi lì fino a quando non lancia, e non devono preoccuparsi un fico su che tipo di infrastruttura sta per essere lì per sostenerlo. E poi, non appena che la campagna è fatto, è come l'infrastruttura va solo subito via perché non c'è davvero è alcuna infrastruttura. E 'solo il codice che si trova sulla Lambda. E 'solo i dati che si trova in DynamoDB. Si tratta di un fantastico modo per creare applicazioni. 

PUBBLICO: Quindi è più effimero quanto lo sarebbe se è stato memorizzato in un server vero e proprio? 

RICK Houlihan: Assolutamente. Poiché tale istanza del server avrebbe dovuto essere un 7/24. Deve essere disponibile per qualcuno per rispondere a. Beh indovinate un po? S3 è disponibile 24/7. S3 risponde sempre. E S3 è molto, molto buono a servire gli oggetti. Gli oggetti possono essere file HTML, o File JavaScript, o quello che volete. È possibile eseguire le applicazioni web molto ricchi fuori secchi S3, e la gente fa. 

E così questa è l'idea qui è quello di allontanarsi dalla strada eravamo abituati a pensarci. Siamo tutti abituati a pensare in termini di server e host. Non si tratta di più così. Si tratta di infrastrutture come codice. Distribuire il codice per la nube e lasciare che la nube funzionare per voi. Ed è quello che AWS sta cercando di fare. 

PUBBLICO: Così il vostro contenitore di oro nel mezzo del gateway API non è il server-like, ma invece è solo-- 

RICK Houlihan: Si può pensare di come facciata del server. Tutto ciò che è è ci vorrà un HTTP richiesta e la mappa di un altro processo. Questo è tutto ciò che fa. E in questo caso, stiamo mappando ad una funzione Lambda. Va bene, allora questo è tutto quello che ho. Grazie mille. Lo apprezzo. So che ci vuole un po 'nel corso del tempo. E si spera voi ragazzi avete un po 'di informazioni che si può prendere via oggi. E mi scuso se sono andato su alcune delle vostre teste, ma c'è un sacco di buona conoscenze fondamentali fondazionale che secondo me è molto importante per voi. Quindi grazie per avermi. [APPLAUSI] PUBBLICO: [incomprensibile] è quando dicevi si doveva passare attraverso la cosa dall'inizio alla fine per ottenere i valori giusti o gli stessi valori, come sarebbe i valori cambiare se [incomprensibile]. 

RICK Houlihan: Oh, idempotente? Come potrebbero i valori cambiare? Beh, perché se io non corro tutto fino alla fine, poi non so cosa cambia sono stati effettuati nell'ultimo miglio. Non sarà il stessi dati come quello che ho visto. PUBBLICO: Oh, quindi basta non hanno ottenuto l'intero input. RICK Houlihan: Giusto. Dovete andare dall'inizio alla fine, e quindi è sta per essere uno stato coerente. Raffreddare. 

PUBBLICO: Così ci ha mostrato DynamoDB può fare documento o il valore della chiave. E abbiamo passato un sacco di tempo sul valore di chiave con un hash e modi per capovolgere in giro. Quando hai guardato quei tavoli, è che lasciandosi alle spalle l'approccio del documento? 

RICK Houlihan: non vorrei dire lasciando alle spalle. 

PUBBLICO: Sono stati separati da the-- 

RICK Houlihan: Con il documento approccio, il tipo di documento in DynamoDB è solo pensare come un altro attributo. Si tratta di un attributo che contiene una struttura di dati gerarchica. E poi nelle query, è possibile utilizzare le proprietà di quegli oggetti utilizzando Object Notation. Così posso filtrare su un nidificato di proprietà del documento JSON. PUBBLICO: Così ogni volta che mi fare un approccio del documento, Posso sorta di arrivare al tabular-- PUBBLICO: Assolutamente. Pubblico: --indexes e cose che proprio parlato. RICK Houlihan: Sì, il indici e tutto ciò che, quando si vuole indicizzare il proprietà del JSON, il modo in cui avremmo dovuto farlo è se si inserisce un oggetto JSON o di un documento in Dynamo, è necessario utilizzare i flussi. Flussi leggevano l'ingresso. Si otterrebbe che JSON Oggetto e avresti detto OK, qual è la proprietà che voglio index? 

È possibile creare una tabella derivata. Ora che è il modo in cui funziona adesso. Noi non vi consentono di indicizzare direttamente tali proprietà. 

PUBBLICO: Tabularizing vostri documenti. 

RICK Houlihan: Esattamente, appiattimento esso, tabularizing, esattamente. Questo è quello che si fa con esso. 

PUBBLICO: Grazie. 

RICK Houlihan: Sì, assolutamente, grazie. PUBBLICO: Quindi è una specie di Mongo incontra classifers Redis. 

RICK Houlihan: Sì, è molto simile. Questa è una buona descrizione per questo. Raffreddare.