[REPRODUCCIÓ DE MÚSICA] RICK Houlihan: D'acord. Hola a tothom. El meu nom és Rick Houlihan. Jo sóc un director d'alt nivell arquitecte de solucions de AWS. Em concentro en NoSQL i Tecnologies DynamoDB. Estic avui aquí per parlar que una mica sobre ells. 

La meva formació és principalment a la capa de dades. Vaig passar la meitat del meu desenvolupament carrera escrivint base de dades, d'accés a dades, solucions per a diverses aplicacions. He estat a la virtualització del núvol durant uns 20 anys. Així que abans que el núvol era Núvol, solíem dir-utility computing. I la idea va ser, és com PG & E, que paga pel que fa servir. Avui en diem el núvol. 

Però amb els anys, he treballat durant un parell d'empreses probablement mai has sentit parlar. Però he compilat una llista de tècnics èxits, suposo que diries. Tinc 8 patents en els sistemes del núvol virtualització, disseny de microprocessadors, processament d'esdeveniments complexos, i altres àrees també. 

Així que en aquests dies, em centre sobretot en NoSQL tecnologies i la propera generació base de dades. I això és en general el que vaig estar aquí parlant amb vostè avui sobre. Llavors, què es pot esperar d'aquesta sessió, anirem a través d'una breu història de processament de dades. Sempre és útil entendre d'on venim i per què som on som. I parlarem una mica poc sobre la tecnologia NoSQL des d'un punt de vista fonamental. 

Anem a entrar en alguns les interioritats DynamoDB. DynamoDB és de AWS sense sabor. És una totalment gestionat i NoSQL solució allotjada. I parlarem una mica sobre la taula estructura, API, tipus de dades, índexs, i alguns dels internals que la tecnologia DynamoDB. Anem a entrar en alguns dels dissenys patrons i millors pràctiques. Anem a parlar de com es utilitzar aquesta tecnologia per a alguns de les aplicacions d'avui en dia. I després anem a parlar una mica sobre l'evolució o de l'emergència d'un nou paradigma en la programació cridats aplicacions orientades a esdeveniments i com juga DynamoDB en això també. I us deixem una mica de una arquitectura de referència discussió pel que podem parlar d'algunes de les formes en què es poden utilitzar DynamoDB. 

Així que primer off-- aquesta és una pregunta He sentit parlar molt és, el que és una base de dades. Molta gent pensa que sap el que és una base de dades. Si Google, veuràs això. És un un conjunt estructurat de dades celebrada en un ordinador, especialment un que accessible de diverses maneres. Suposo que és una bona definició d'una base de dades modern. Però no m'agrada, perquè implica un parell de coses. Implica estructura. I això implica que està en un ordinador. I les bases de dades no ho van fer sempre existirà en els ordinadors. Bases de dades realment existien en moltes maneres. 

Així que una millor definició d'un base de dades és una cosa com això. Una base de dades és una organitzada mecanisme per emmagatzemar, gestionar, i recuperació d'informació. Es tracta d'About.com. Així que m'agrada això perquè realment parla sobre una base de dades és un repositori, un dipòsit de informació, no necessàriament cosa que s'asseu en un ordinador. I a través de la història, no sempre han tingut els ordinadors. 

Ara, si li pregunto a la mitjana avui desenvolupador el que és una base de dades, que és la resposta que rebo. En algun lloc que puc ficar coses. Oi? I és cert. Però és lamentable. A causa de que la base de dades és realment el fonament de l'aplicació moderna. És la base de cada aplicació. I la manera de construir que base de dades, com s'estructura que les dades que va a dictar la forma en què aplicació realitza com es canvia l'escala. 

Així que una gran part del meu treball avui es tracta del que passa quan els desenvolupadors adoptar aquest enfocament i fer front a les seqüeles d'una aplicació que ara està més enllà de l'escala original intenció i el sofriment de mal disseny. Així que espero que quan allunyar d'avui, podràs tenir un parell d'eines el cinturó que et mantindrà de fer els mateixos errors. Tot bé. Així que anem a parlar una mica de la línia de temps de la tecnologia de base de dades. Crec que vaig llegir un article no fa tant de temps i va dir alguna cosa sobre la lines-- que és una declaració molt poètic. Va dir que la història de processament de dades és plena d'altes marques d'aigua de l'abundància de dades. D'ACORD. Ara, suposo que això és part de veritat. Però jo en realitat mirar és com la història és en realitat plena amb alta marca d'aigua de la pressió de dades. A causa de que la velocitat de dades de la ingestió no es posa. Només puja. 

I la innovació es produeix quan veiem pressió de dades, que és la quantitat de dades que és Ara a que entra al sistema. I no pot ser processada de manera eficient, ja sigui en el temps o en el cost. I va ser llavors quan vam començar per mirar la pressió de dades. 

Així que quan ens fixem en la primera base de dades, aquesta és el que estava entre els nostres oïdes. Tots naixem amb ella. És una base de dades bé. Té una alta disponibilitat. És sempre encès. Vostè sempre pot aconseguir-ho. 

Però és sol usuari. No puc compartir els meus pensaments amb vosaltres. No es pot tenir en els meus pensaments quan vulguis. I la seva abilitiy no és tan bo. Ens oblidem de les coses. De tant en tant, un de nosaltres fulles i es mou a una altra existència i perdem tot això va ser en aquesta base de dades. Així que no és tan bo. 

I això va funcionar bé amb el temps quan estàvem de tornada en el dia quan tot el que realment necessitem saber és ¿A on anirem demà o quan ens reunim el millor menjar. Però, com hem començat a créixer com la civilització i el govern van començar per venir a ser, i les empreses van començar a evolucionar, comencem a adonar-nos que necessiten una mica més del que podríem posar en el nostre cap. Tot bé? 

Necessitàvem els sistemes de registre. Necessitàvem llocs per ser capaços d'emmagatzemar dades. Així que vam començar a escriure documents, la creació de biblioteques i arxius. Comencem el desenvolupament d'un sistema d'un llibre major de comptabilitat. I aquest sistema de comptatge de llibre major va córrer el món durant molts segles, i potser fins i tot mil·lennis com quin tipus de créixer fins al punt on aquesta càrrega de dades va superar la capacitat d'aquests sistemes per ser capaç de contenir-lo. 

I això realment va ocórrer en la dècada de 1880. Oi? Als EUA Cens 1880. Això és realment on el gir punt de processament de dades modern. Aquest és el punt en que la quantitat de dades que estava sent recollit pel Govern dels Estats Units va arribar al punt on va prendre vuit anys per processar. 

Ara, vuit anys-- com vostè sap, el cens surt cada 10 anys-- pel que és bastant obvi que per al moment en què té el cens de 1890, la quantitat de dades que que anava a ser processat pel govern era va superar els 10 anys que portaria a posat en marxa el nou cens. Això era un problema. 

Així que un tipus anomenat Herman Hollerith va arribar i va inventar ponx registre de la unitat targetes, lector de targetes perforades, targetes perforades tabulador, i la confrontació de els mecanismes per a aquesta tecnologia. I aquesta empresa que es va formar al temps, juntament amb un parell dels altres, en realitat es va convertir en un dels pilars d'un petita empresa que avui coneixem diu IBM. 

Així IBM originalment estava en el negoci de base de dades. I això és realment el que van fer. Ho van fer de processament de dades. 

Com el que la proliferació de cop targetes, 01:00 mecanismes enginyosos de ser capaç d'aprofitar aquest tecnologia per sondejar conjunts de resultats ordenats. Es pot veure en aquesta foto no tenim un poc-- que és una mica small-- però es pot veure un mecanisme mecànic molt enginyós on tenim una baralla de targetes perforades. I la presa d'algú una mica de tornavís i ajustar-se a través de la ranures i aixecant per aconseguir que el partit, que resultats ordenats estableixen. 

Aquesta és una agregació. Fem això tot el temps avui a l'ordinador, quan ho fas a la base de dades. Solíem fer-ho manualment, no? La gent posa aquestes coses juntes. I va ser la proliferació d'aquestes targetes perforades en el que anomenem la bateria de dades i rodets de dades, cinta de paper. 

La indústria de processament de dades es va dur una lliçó dels jugadors pianos. Reproductor de pianos de tornada a el canvi de segle utilitzat per utilitzar bobines de paper amb ranures a dir-li que què tecles per jugar. Així que la tecnologia es va adaptar finalment per emmagatzemar dades digitals, perquè podrien posar aquestes dades en aquests rodets de cinta de paper. 

Ara, com a resultat, les dades va ser actually-- com accedeix a aquesta dada va anar directament depèn del que vas guardar. Així que si poso les dades en una cinta, Vaig tenir accés a les dades de forma lineal. Vaig haver de rodar el tot cinta per accedir a totes les dades. Si poso les dades en el cop targetes, que podrien accedir-hi en una mica més a l'atzar la moda, potser no tan ràpid. 

Però hi va haver limitacions en la forma en què accés a les dades en funció de com es va emmagatzemar. I pel que aquest era un problema entrar en els '50s. Un cop més, podem començar a veure que a mesura que desenvolupar noves tecnologies per processar les dades, a la dreta, s'obre la porta a noves solucions, per als nous programes, nous les sol·licituds d'aquestes dades. I realment, la governança va poder haver estat la raó Per això hem desenvolupat alguns d'aquests sistemes. Però el negoci es va convertir ràpidament el conductor darrere de l'evolució de la base de dades modern i el sistema d'arxius modern. 

Així que la propera cosa que ocórrer va ser en els anys 50 va ser el sistema d'arxius i la desenvolupament d'emmagatzematge d'accés aleatori. Aquesta era bonica. Ara, de sobte, podem posar la nostra arxius en qualsevol part d'aquests discos durs i podem accedir a aquestes dades a l'atzar. Podem analitzar que la informació dels arxius. I hem resolt tot el món problemes amb el processament de dades. 

I que va durar al voltant de 20 o 30 anys, fins a l'evolució de la base de dades relacional, que és quan el món va decidir que ara necessita tenir un repositori que derrota la dispersió de les dades a través de l'arxiu sistemes que hem construït. Oi? Massa dades distribuïts en massa llocs, la de-duplicació de dades, i el cost d'emmagatzematge va ser enorme. 

En els anys 70, el recurs més car que un equip tenia era el d'emmagatzematge. El processador era vist com un cost fix. Quan compro la caixa, la CPU fa algun treball. Es va a estar girant si que està treballant o no en realitat. Això és realment un cost enfonsat. 

Però el que m'ha costat com negoci és l'emmagatzematge. Si he de comprar més discos proper mes, això és un cost real que he de pagar. I que l'emmagatzematge és car. 

Ara tenim avanç ràpid 40 anys i tenim un problema diferent. El càlcul és ara la recurs més car. L'emmagatzematge és barat. Vull dir, podem anar a qualsevol part de la Cloud i podem trobar emmagatzematge barat. Però el que no puc trobar és computi barat. 

Així que l'evolució d'avui la tecnologia, de la tecnologia de base de dades, que realment està centrat al voltant bases de dades distribuïdes que no pateixen de el mateix tipus d'escala limitacions de les bases de dades relacionals. Parlarem una mica sobre el que realment significa. 

Però una de les raons i el conductor darrere d'això- ens va parlar de la pressió de dades. Les dades de pressió és una cosa que impulsa la innovació. I si ens fixem en més de els últims cinc anys, aquesta és una gràfica del que les dades càrrega a través de l'empresa en general sembla que en els últims cinc anys. 

I la regla general aquests days-- si van Google-- és 90% de les dades que emmagatzemem avui, i va ser generada en els últims dos anys. D'ACORD. Ara, això no és una tendència que hi ha de nou. Aquesta és una tendència que ha estat sortir per 100 anys. Des Herman Hollerith desenvolupat la targeta perforada, hem estat construint dipòsits de dades i la recol·lecció de dades a velocitats fenomenals. 

Així que en els últims 100 anys, que hem vist aquesta tendència. Això no canviarà. En el futur, veurem això, si no una tendència accelerada. I vostè pot veure el que sembla. 

Si un negoci en l'any 2010 tenia una terabyte de dades sota gestió, avui que vol dir que són la gestió de 6,5 petabytes de dades. Això és 6.500 vegades més dades. I sé que això. Jo treball amb aquests negocis cada dia. Fa cinc anys, seria parlar amb empreses qui parlar amb mi sobre el que és un dolor que és gestionar terabytes de dades. I que parlarien a mi sobre com veiem que aquest és probablement va ser un petabyte o dos aquí a un parell d'anys. 

Aquestes mateixes empreses avui em vaig a reunir amb, i que estan parlant amb mi sobre la problema s'hagi tenint gestió desenes, 20 petabytes de dades. Així l'explosió de la dades en la indústria està impulsant l'enorme la necessitat de millors solucions. I la base de dades relacional és simplement no viure d'acord a la demanda. 

I així hi ha un lineal correlació entre la pressió de dades i la innovació tècnica. La història ens ha demostrat això, que amb el temps, sempre que el volum de dades que necessita ser processada excedeix la capacitat del sistema de per processar-ho en un temps raonable oa un cost raonable, a continuació, les noves tecnologies han estat inventats per resoldre aquests problemes. Aquestes noves tecnologies, al seu torn, obre la porta a una altra sèrie de problemes, que està reunint encara més dades. 

Ara, nosaltres no pararem això. Oi? No pararem això. Per què? Perquè no es pot saber tot que cal saber en l'univers. I mentre hem estat vius, en tota la història de l'home, sempre hem impulsat saber més. 

Així que sembla que cada polzada que avancem pel camí dels descobriments científics, estem multiplicant la quantitat de dades que necessitem per processar de forma exponencial com descobrim més i més i més sobre el funcionament intern de la vida, sobre com funciona l'univers, sobre conduint el descobriment científic, i la invenció que que estem fent avui. El volum de dades simplement augmenta contínuament. Així que ser capaç de fer front aquest problema és enorme. 

Així que una de les coses mirem com per què NoSQL? Com NoSQL a resoldre aquest problema? Bé, bases de dades relacionals, Structured Query Language, SQL-- això és realment una construcció de la relacional database-- aquestes coses són optimitzat per a l'emmagatzematge. 

Allà pels anys 70, de nou, disc és car. L'exercici d'aprovisionament d'emmagatzematge a l'empresa és de mai acabar. Ho sé. Jo ho vaig viure. Vaig escriure controladors d'emmagatzematge per a un empresa SuperServer Enterprised allà pels anys 90. I el resultat final està acumulant una altra matriu d'emmagatzematge era només una cosa que passar tots els dies a l'empresa. I mai es va aturar. Major densitat d'emmagatzematge, la demanda per a l'emmagatzematge d'alta densitat, i per a l'emmagatzematge més eficient devices-- mai es va aturar. 

I NoSQL és una gran tecnologia perquè normalitza les dades. És de-duplica les dades. Es posa les dades en una estructura que és agnòstic a cada patró d'accés. Múltiples aplicacions poden arribar a aquest Base de dades SQL, executar consultes ad hoc, i obtenir dades en la forma que hagi de processar per les seves càrregues de treball. Això sona fantàstic. Però la conclusió és que amb qualsevol sistema, si és agnòstic a tot, està optimitzat per a res. D'ACORD? 

I això és el que vam aconseguir amb la base de dades relacional. Està optimitzat per al seu emmagatzematge. És normalitzada. És relacional. És compatible amb les consultes ad hoc. I ella i s'escala verticalment. 

Si he d'aconseguir una base de dades SQL gran o una base de dades SQL més potent, Vaig comprar un tros més gran de ferro. D'ACORD? He treballat amb molts clients que han estat a través de millores importants en la seva infraestructura de SQL única per esbrinar sis mesos més tard, que estan colpejant la paret de nou. I la resposta d'Oracle o MSSQL o qualsevol altra persona és aconseguir una caixa més gran. Bé, tard o d'hora, no es pot comprar una caixa més gran, i això és un problema real. Hem de canviar realment les coses. Llavors, on funciona això? Funciona bé per fora de línia anàlisi, les càrregues de treball de tipus OLAP. I això és realment on SQL pertany. Ara, s'utilitza avui dia en molts en línia transaccional de tipus de processament aplicacions. I funciona molt bé en un cert nivell d'utilització, però simplement no escala la forma en què NoSQL fa. I parlarem una mica poc sobre per què és així. 

Ara, NoSQL, d'altra banda, està més optimitzat per a càlcul. D'ACORD? No és agnòstic a el patró d'accés. És el que anomenem de-normalitzada estructura o una estructura jeràrquica. Les dades en una base de dades relacional és unit de diverses taules per produir l'opinió que el que necessita. Les dades a la base de dades NoSQL 1 s'emmagatzema en un document que conté l'estructura jeràrquica. Totes les dades que normalment seria unit per produir aquest punt de vista s'emmagatzema en un únic document. I parlarem una mica sobre el que funciona en un parell de cartes. 

Però la idea és que vostè emmagatzema les dades mentre que aquests punts de vista instanciados. D'ACORD? Vostè escalar horitzontalment. Oi? Si he de augmentar el mida de la meva grup de NoSQL, No necessito aconseguir una caixa més gran. Tinc una altra caixa. I jo Clúster les juntes, i puc fragmentar aquestes dades. Parlarem una mica sobre el sharding és, per a ser capaç d'escalar aquesta base de dades a través de múltiples dispositius físics i treure la barrera que em requereix per escalar verticalment. 

Així que és realment construït per en línia processament de transaccions i l'escala. Hi ha una gran diferència aquí entre la informació, no? Informes, jo no sé la preguntes vaig a preguntar. Oi? Reporting-- si algú de meu departament de màrqueting vol sol-- com molts dels meus clients tenir aquesta característica particular que comprat en aquest dia-- No sé ho consulta van a preguntar. Així que he de ser agnòstic. 

Ara, en una línia aplicació transaccional, Jo sé el que estic demanant preguntes. Vaig construir la sol·licitud d' un flux de treball molt específic. D'ACORD? Així que si puc optimitzar les dades emmagatzemar per recolzar aquest flux de treball, que serà més ràpid. I és per això que NoSQL pot realment accelerar el lliurament d'aquests tipus de serveis. Tot bé. 

Així que entrarem en una mica de la teoria aquí. I alguns de vostès, els seus ulls podria fer retrocedir una mica. Però vaig a tractar de mantenir-lo tan alt nivell com pugui. Així que si vostè està en projecte gestió, hi ha un constructe anomenat triangle de restriccions. D'ACORD. El triangle de Restringeix dictats no es pot tenir tot, tot el temps. No pot tenir el seu pastís i menjar-se'l també. Així que en la gestió de projectes, aquest triangle limitacions és que es pot tenir barat, es pot tenir ràpid, o es pot tenir bona. Esculli dos. A causa de que no es pot tenir als tres. Oi? D'ACORD. 

Així es va assabentar d'això molt. És una triple restricció, triangle de la triple restricció, o en el triangle de ferro és oftentimes-- quan parles amb els gerents de projecte, van a parlar d'això. Ara, bases de dades tenen el seu propi triangle de ferro. I el triangle de ferro de les dades és el que anomenem teorema CAP. D'ACORD? 

Dictats teorema CAP com funcionen les bases de dades sota una condició molt específica. I parlarem de el que la condició és. Però els tres punts del triangle, per així dir-ho, són C, la consistència. D'ACORD? Així que en la PAC, la coherència significa que totes clients que poden accedir a la base de dades sempre tindrà un vista consistent de les dades. Ningú va a veure dues coses diferents. D'ACORD? Si veig a la base de dades, Estic veient la mateixa vista com el meu company que veu la mateixa base de dades. Aquesta és la consistència. 

Disponibilitat vol dir que si el base de dades en línia, si es pot arribar, que tots els clients serà sempre ser capaç de llegir i escriure. D'ACORD? Així que cada client que pot llegir la base de dades sempre serà capaç de llegir dades de dades i escriure. I si aquest és el cas, és un sistema disponible. 

I el tercer punt és el que que anomenem tolerància partició. D'ACORD? Mitjans de tolerància de repartiment que el sistema funciona bé malgrat xarxa física particions entre els nodes. D'ACORD? Així que els nodes del clúster no pot parlar l'un a l'altre, què passa? Tot bé. 

Bases de dades relacionals Així choose-- vostè pot escollir dos d'ells. D'ACORD. Bases de dades relacionals Així que trien ser consistents i disponibles. Si la partició ocorre entre els DataNodes al magatzem de dades, la base de dades es bloqueja. Oi? Simplement va cap avall. D'ACORD. 

I és per això que tenen per créixer amb les caixes més grans. Oi? Perquè hi ha no-- En general, un clúster base de dades, no hi ha molts d'ells que funcionen d'aquesta manera. Però la majoria de les bases de dades d'escala verticalment dins d'una sola caixa. A causa de que han de ser consistent i disponible. Si una partició anaven a ser injectat, llavors vostè hauria de prendre una decisió. Vostè ha de fer una elecció entre ser coherent i disponible. 

I això és el que les bases de dades NoSQL fan. Tot bé. Així que una base de dades NoSQL, es ve en dos sabors. Ens tener-- bé, ve en molts sabors, però ve amb dues concepcions fonamentals characteristics-- ho que anomenaríem base de dades de PC, o un tolerància consistent i partició sistema. Aquests nois prendre la decisió de que quan els nodes perden contacte entre si, no permetrem que gent escrigui més. D'ACORD? 

Fins que s'elimina la partició, es bloqueja l'accés a escriptura. Això vol dir que no estan disponibles. Són consistents. Quan veiem que partició injectar si mateix, ara som coherents, perquè no anem per permetre el canvi de dades en dos costats de la partició de forma independent l'un de l'altre. Haurem de restablir la comunicació abans de qualsevol actualització de es deixa que la de dades. D'ACORD? 

El següent gust seria un sistema AP, o disponibles i es va repartir sistema de tolerància. Aquests nois no els importa. Oi? Qualsevol node que rep una escrivim, el prendrem. Així que estic replicant les meves dades a través de múltiples nodes. Aquests nodes reben un client, client ve en, diu, vaig a escriure algunes dades. Node diu, cap problema. El node al costat d'ell aconsegueix una escriptura en el mateix registre, ell dirà que no hi ha problema. En algun lloc de nou a la part de darrere, que les dades que va a replicar. I llavors algú va a realitzar, uh-oh, que el sistema s'adonarà, uh-oh, ha hagut una actualització de dos costats. Què fem? I el que fan és, llavors, fan alguna cosa que els permet resoldre aquest estat de dades. I parlarem de que, en la següent taula. 

Cosa a destacar aquí. I jo no vaig a ser massa molt en això, perquè aquest es fica en la teoria de les dades de profunditat. Però hi ha una transaccional marc que s'executa en un sistema relacional que em permet fer de forma segura les actualitzacions a múltiples entitats a la base de dades. I aquests canvis es produiran tots alhora o no en absolut. I això es diu transaccions ACID. D'ACORD? 

ÀCID ens dóna l'atomicidad, consistència, l'aïllament i la durabilitat. D'ACORD? Això vol dir atòmiques, transaccions, tot les actualitzacions o bé ocorren o no ho fan. La consistència vol dir que la base de dades serà sempre ser portat a un constant estat després d'una actualització. Mai deixaré la base de dades en un mal estat després d'aplicar una actualització. D'ACORD? 

Així que és una mica diferent que la PAC consistència. CAP consistència significa tota la meva clients sempre poden veure les dades. Significa que quan la consistència ACID una transacció ha fet, de les dades bones. Els meus relacions són tots bons. Jo no vaig a eliminar una fila pare i deixar un munt de nens orfes en alguna altra taula. No pot succeir si sóc coherent en una transacció d'àcid. 

Aïllament significa que les transaccions sempre ocórrer un després de l'altre. El resultat final de les dades serà el mateix estat com si aquestes transaccions que es van emetre simultàniament van ser executats en sèrie. Així que és de concurrència control a la base de dades. Així que, bàsicament, no puc incrementar el mateix valor dues vegades amb dues operacions. 

Però si dic afegir 1 a aquest valor, i dues transaccions vénen en i tractar de fer-ho, una és va a arribar primer i l'altre d'un sol heu d'arribar a. Així que al final, he afegit dos. Veus el que vull dir? D'ACORD. 

La durabilitat és bastant senzill. Quan la transacció es reconeix, és va a ser-hi, fins i tot si el sistema es bloqueja. Quan aquest sistema es recupera, que transacció que es va cometre és en realitat va a ser-hi. Així que aquesta és la garantia de transaccions ACID. Aquestes són molt bones garanties per tenir a una base de dades, però vénen a aquest cost. Oi? 

A causa que el problema amb aquest marc és si hi ha una partició de dades en el conjunt, he de prendre una decisió. Vaig a haver de permetre actualitzacions d'un costat o de l'altre. I si això passa, llavors jo ja no sóc d'anar per ser capaç de mantenir aquestes característiques. No seran consistent. No van a ser aïllats. Aquí és on es trenca per a bases de dades relacionals. Aquesta és la raó relacional bases de dades escalar verticalment. 

D'altra banda, tenim el que crida l'tecnologia BASE. I aquests són les seves bases de dades NoSQL. Tot bé. Així que tenim el nostre CP, les bases de dades d'AP. I aquests són el que s'anomena bàsicament disponible, estat tou, finalment consistent. D'ACORD? 

Bàsicament disponible, perquè són tolerants partició. Sempre seran allà, fins i tot si hi ha una partició de xarxa entre els nodes. Si puc parlar amb un node, estic serà capaç de llegir dades. D'ACORD? No sempre podria ser capaç d'escriure dades si sóc una plataforma consistent. Però seré capaç de llegir les dades. 

L'estat tou indica que quan vaig llegir que les dades, potser no és el mateix que la resta dels nodes. Si el dret es va emetre en un node en un altre lloc en el clúster i no s'ha replicat a tot el raïm però, quan vaig llegir que les dades, aquest estat podria no ser consistent. No obstant això, serà finalment consistent, el que significa que quan una escriptura es fa al sistema, es replicarà en tots els nodes. I amb el temps, aquest estat serà posat en ordre, i serà un estat coherent. 

Ara, CAP teorema realment juga només en una condició. Aquesta condició és quan això succeeix. Com que cada vegada s'està operant en manera normal, no hi ha cap partició, tot és coherent i disponible. Només es preocupi per la PAC quan tenim aquesta partició. Així que aquests són rars. Però, ¿com reacciona el sistema quan els ocorren dictar quin tipus de sistema que estem tractant. 

Així que donem una ullada al que es veu com per als sistemes d'AP. D'ACORD? Sistemes d'AP són de dos tipus. Vénen en el gust que és un estimo estimo, 100%, sempre disponible. I vénen al un altre gust, que diu: Saps què, jo em vaig a preocupar sobre aquesta cosa de particions quan es produeix una partició real. En cas contrari, no serà primària nodes que prendrà els drets. D'ACORD? 

Així que si tenim una mena Cassandra. Cassandra seria un mestre mestra, anem a escriure a qualsevol node. Llavors, què passa? Així que tinc un objecte al base de dades que existeix en dos nodes. Anem a trucar a aquest objecte S. Així que tenim l'estat de S. Tenim algunes operacions en S que estan en curs. Cassandra em permet escriure en diversos nodes. Així que diguem que rebo una escriure per s de dos nodes. Bé, el que acaba succeint és cridem a que un esdeveniment de partició. Pot ser que no hi hagi una partició de xarxa física. Però a causa del disseny del sistema, és en realitat particions tan aviat com puc obtenir una escriptura en dos nodes. No m'està obligant a escriure tot a través d'un node. Estic escrivint en dos nodes. D'ACORD? 

Així que ara tinc dos estats. D'ACORD? ¿Què passarà és més aviat o més tard, que serà un esdeveniment de replicació. No va ser el que anomenat recuperació de la partició, el qual és on aquests dos estats vénen de nou junts i no hi haurà un algoritme que s'executa dins de la base de dades, decideix què fer. D'ACORD? Per defecte, darrera actualització guanya en la majoria dels sistemes d'AP. Així que en general hi ha una algoritme per defecte, el que que ells anomenen una devolució de trucada funció, cosa que serà cridat quan aquesta condició es detecta per executar alguna lògica per resoldre aquest conflicte. D'ACORD? La devolució de trucada per defecte i per defecte resoldre la majoria de les bases de dades d'AP en És a dir, endevinin què, marca de temps guanya. Aquesta va ser l'última actualització. Me'n vaig a posar aquesta actualització en aquest país. Puc bolcar aquest disc que em objecte de dúmping fora en un registre de recuperació de manera que l'usuari pot tornar més tard i dir, bé, hi va haver una col·lisió. Que ha passat? I en realitat es pot bolcar un registre de totes les col·lisions i les reversions i veure què passa. 

Ara, com a usuari, també pot incloure lògica en aquesta devolució de trucada. Així que vostè pot canviar això operació de devolució de trucada. Es pot dir, bé, jo vull per remeiar aquestes dades. I vull intentar fusionar aquests dos registres. Però això depèn de tu. La base de dades no sap com fer-ho per defecte. La major part del temps, l'únic que la base de dades sap que fer és a dir, aquest va ser l'últim registre. Aquest és el que guanyarà, i aquest és el valor que posaré. Una vegada que la recuperació de la partició i la replicació es produeix, tenim el nostre estat, que ara és el Primer, que és l'estat de combinació de tots aquests objectes. Així que els sistemes d'AP tenen això. Sistemes de CP no necessiten de preocupar per això. Perquè tan aviat com arriba una partició en joc, simplement deixen de prendre escriu. D'ACORD? Així que això és molt fàcil tractar de ser coherent quan vostè no accepta les actualitzacions. Això és amb els sistemes CP fan. Tot bé. 

Així que anem a parlar una mica poc sobre els patrons d'accés. Quan parlem de NoSQL, és tot sobre el patró d'accés. Ara, SQL és ad hoc, les consultes. És magatzem relacional. No hem de preocupar sobre el patró d'accés. Escric una consulta molt complexa. Es va i obté les dades. Això és el que això es veu com, la normalització. 

Així que en aquesta estructura particular, estem mirant un catàleg de productes. Tinc diferents tipus de productes. Tinc llibres. Tinc àlbums. Tinc vídeos. La relació entre els productes i qualsevol d'aquests llibres, àlbums, i vídeos de taules és de 1: 1. Tot bé? Tinc un identificador de producte, i que correspon identificació a un llibre, un àlbum o un vídeo. D'ACORD? Això és una relació 1: 1 a través d'aquestes taules. 

Ara, tot el que books-- tenir és les propietats de l'arrel. Cap problema. Això és genial. Un a un, relació, em surt tot les dades que necessita per descriure aquest llibre. Àlbums Albums-- tenen pistes. Això és el que anomenem un a molts. Cada àlbum podria tenir moltes pistes. Així, per cada pista en l'àlbum, que podria tenir un altre rècord en aquesta taula secundària. Així que puc crear un registre a la meva taula d'àlbums. Puc crear diversos registres a la taula de pistes. Un-a-molts relació. 

Aquesta relació és el que que anomenem de molts a molts. D'ACORD? Vostè veu que els actors podrien ser en moltes pel·lícules, molts vídeos. Així que el que fem és que posem aquest mapeig taula, entre els quals només mapes de la ID d'actor per a l'ID de vídeo. Ara puc crear una consulta de les unions vídeos a través actor de vídeo als actors, i em dóna una bona llista de totes les pel·lícules i tots els actors que estaven en aquesta pel·lícula. 

D'ACORD. Així que aquí anem. Un-a-un és el de nivell superior relació; un-a-molts, àlbums a les pistes; molts-a-molts. Aquests són els tres de nivell superior relacions en qualsevol base de dades. Si vostè sap com els relacions treballen junts, llavors vostè sap molt sobre la base de dades ja. Així NoSQL funciona una mica diferent. Pensem per un segon que sembla que anar a buscar tots els meus productes. 

En un magatzem relacional, jo que desitgi obtenir tots els meus productes en una llista de tots els meus productes. Això és un munt de preguntes. Tinc una consulta per tots els meus llibres. Tinc una pregunta dels meus discos. I tinc una consulta per tots els meus vídeos. I he de dir- tots junts en una llista i servir de nou fins a la aplicació que se sol·licitin. 

Per aconseguir els meus llibres, m'uneixo a Productes i Llibres. Per obtenir els meus àlbums, vaig arribar a unir-se Productes, àlbums i cançons. I per aconseguir els meus vídeos, tinc per unir-se als productes als vídeos, unir-se a través Actor Videos, i portar als actors. Així que això és tres consultes. Consultes molt complexes a acoblar un conjunt de resultats. 

Això és menys que òptim. Per això, quan parlem sobre una estructura de dades que és construït per ser agnòstic a l'accés pattern-- bé això és genial. I es pot veure que això és realment agradable com hem organitzat les dades. ¿I saps què? Només tinc un rècord per a un actor. 

Això està bé. He deduplicado tots els meus actors, i vaig mantenir meus associacions en aquesta taula d'assignacions. Però, obtenir les dades fora es converteix en car. Estic enviant la CPU en tot el sistema unir-se a aquestes estructures de dades juntament ser capaç de tirar de tornar dades. 

Llavors, com faig perquè tot això? En NoSQL es tracta agregació, no normalització. Per això volem dir que volem donar suport al patró d'accés. Si el patró d'accés a les aplicacions, He de aconseguir tots els meus productes. Posarem tots els productes en una sola taula. Si poso tots els productes en una taula, Jo només puc seleccionar tots els productes d'aquesta taula i em surt tot. Bé, com ho faig? Bé, en NoSQL no hi ha estructura a la taula. Parlarem una mica sobre com funciona això en Dynamo DB. Però vostè no té el mateix atributs i les mateixes propietats en cada filera, en cada tema, com ho fa en una taula de SQL. I el que això em permet de fer un munt de coses i em dóna molta flexibilitat. En aquest cas particular, tenir les meves documents de productes. I en aquest particular, exemple, tot és un document a la taula Productes. I el producte d'un llibre pot tenir un ID de tipus que especifica un llibre. I l'aplicació canviaria en aquest ID. 

En el nivell d'aplicació, vaig per dir oh, quin tipus de registre és això? Oh, és un registre de llibres. Registres de la Llibreta tenen aquestes propietats. Déjame crear un objecte de llibre. Així que em vaig a omplir el llibre objecte amb aquest concepte. Següent article ve i diu, què és aquest article? Bé, aquest article és un àlbum. Oh, tinc tota una diferent rutina de processament perquè, perquè és un àlbum. Veus el que vull dir? 

Així que l'aplicació tier-- I només has de seleccionar tots aquests registres. Tots comencen a entrar. Podrien ser tots els tipus diferents. I és la lògica de l'aplicació que els commutadors a través d'aquests tipus i decideix com processar ells. 

Un cop més, pel que estem optimitzant el esquema per l'esquema d'accés. Ho estem fent per col·lapse aquestes taules. Bàsicament estem prenent aquestes estructures normalitzades, i estem construint estructures jeràrquiques. Dins de cada un d'aquests registres Vaig a veure propietats de la matriu. 

Dins d'aquest document per als àlbums, Estic veient sèries de pistes. Aquestes pistes ara become-- és bàsicament aquesta taula secundària que existeix aquí mateix en aquesta estructura. Així que vostè pot fer això en DynamoDB. Vostè pot fer això en MongoDB. Vostè pot fer això en qualsevol base de dades NoSQL. Crear aquest tipus de estructures de dades jeràrquiques que li permeten recuperar dades molt ràpidament perquè ara no han de conformar-se. En inserir una fila a les Pistes taula, o una fila a la taula Àlbums, He de complir amb aquest esquema. He de tenir l'atribut o la propietat que es defineix en aquesta taula. Cada un d'ells, quan inserit aquesta fila. Aquest no és el cas en el NoSQL. 

Puc tenir totalment diferent propietats en tots els documents que inserit en la col·lecció. Així mecanisme molt poderós. I és realment com optimitzar el sistema. Perquè ara aquesta consulta, en lloc d'unir-se a totes aquestes taules i l'execució d'una mitja dotzena de consultes a retirar les dades que necessito, Estic executant una consulta. I estic iteració a través dels conjunt de resultats. que et dóna una idea del poder de NoSQL. Vaig a classe d'anar de costat aquí i parlar una mica sobre això. Això és més classe de la comercialització o la tecnologia, com la comercialització de la tecnologia tipus de discussió. Però és important entendre perquè si ens fixem en la part superior aquí en aquesta taula, el que estem veient és el que anomenem el corba bombo tecnologia. I el que això significa és coses noves entra en joc. La gent pensa que és genial. He resolt tots els meus problemes. 

Aquest podria ser el final tot, ser tot per a tot. I comencen a usar-lo. I diuen, això no funciona. Això no està bé. El material vell era millor. I tornen a fer les coses com estaven. I després, finalment, que vagin, saps què? Aquest material no és tan dolent. Oh, així és com funciona. I una vegada que esbrinar com obres, comencen a millorar. 

I el curiós al respecte és, quin tipus de línies fins a quin que anomenem la corba d'adopció de tecnologia. Així que el que passa és que tenim alguns gallet tecnologia tipus. En el cas de bases de dades, que és la pressió de dades. Parlem dels punts alts d'aigua de la pressió de les dades a través del temps. Quan la pressió que realitza un cert dades punt, que és un disparador tecnologia. 

S'està fent massa car. Es triga massa temps per processar les dades. Necessitem una mica millor. Vostè obté els innovadors per aquí donant voltes, tractant d'esbrinar quina és la solució. Quina és la nova idea? 

Quina és la millor alternativa manera de fer això? I vénen amb alguna cosa. I la gent, el veritable mal, els nois de la punta de llança, que van a saltar per tot arreu, perquè necessiten una resposta. Ara el que inevitablement happens-- i està succeint ara mateix a NoSQL. Ho veig tot el temps. 

El que passa, inevitablement, és la gent comença a utilitzar la nova eina de la mateixa manera que utilitza l'eina d'edat. I s'adonen que no funciona tan bé. No puc recordar qui era jo parlant amb el dia d'avui. Però és com, quan el martell pneumàtic va ser inventat, la gent no swing més el seu cap per trencar el formigó. 

Però això és el que hi ha passant amb NoSQL avui. Si entres en la majoria de botigues, que estan tractant de ser botigues NoSQL. El que estan fent és que estan fent servir NoSQL, i estan carregar plena d'esquema relacional. Perquè així és com dissenyar bases de dades. I estan preguntant, per què és no dur a terme molt bé? Noi, això fa pudor. Vaig haver de mantenir tot el meu uneix en-- és com, no, no. Mantenir uneix? Per què estan unint a les dades? No s'inscriu dades NoSQL. Vostè agregada ella. 

Així que si vols evitar això, aprendre com funciona l'eina abans que realment començar a usar-lo. No tractar d'utilitzar les noves eines de la mateixa manera que va utilitzar les velles eines. Vas a tenir una mala experiència. I cada vegada això és el que es tracta. Quan vam començar a venir aquí, és perquè la gent descobert com usar les eines. 

Ells van fer el mateix quan bases de dades relacionals es van inventar, i van ser reemplaçant als sistemes d'arxius. Van tractar de crear sistemes de fitxers amb bases de dades relacionals perquè això és el entenen les persones. No va funcionar. Així que la comprensió de les millors pràctiques de la tecnologia que està treballant és enorme. Molt important. 

Així que entrarem en DynamoDB. DynamoDB és de AWS totalment gestionats plataforma NoSQL. Què significa gestionats totalment vol dir? Això vol dir que no cal realment preocupar de res. 

Entres, li dius nosaltres, que ens cal una taula. Es necessita tanta capacitat. Es prem el botó, i la provisió que tota la infraestructura darrere de l'escena. Ara que és enorme. 

Perquè quan parles sobre l'expansió d'una base de dades, Clústers de dades NoSQL en escala, petabytes de funcionament, corrent milions de transaccions per segon, aquestes coses no són petits raïms. Estem parlant de milers de casos. La gestió de milers de casos, fins i tot instàncies virtuals, és un veritable mal al cul. Vull dir, penso cada vegada que un pegat de sistema operatiu surt o una nova versió de la base de dades. Què vol dir això a vostè operacionalment? Això vol dir que tens 1200 servidors que necessiten ser actualitzats. Ara, fins i tot amb l'automatització, que pot portar molt de temps. Això pot causar una gran quantitat de mals de cap operacionals, perquè vaig a tenir serveis de sota. 

Com puc actualitzar aquestes bases de dades, que podria fer desplegaments verd blau on puc implementar i actualitzar la meitat del meu nodes i, a continuació, actualitzar l'altra meitat. Prengui els baix. Per tant la gestió de la infraestructura escala és enormement dolorós. I AWS prendre que el dolor fora d'ell. I les bases de dades NoSQL pot ser extraordinàriament dolorosa causa de la manera en què l'escala. 

Escala horitzontal. Si vols aconseguir un NoSQL gran base de dades, vostè compra més nodes. Cada node que vostè compra és un altre mal de cap operativa. Així que deixeu que algú més ho faci per vostè. AWS pot fer això. 

Donem suport valors clau document. Ara no vam ser massa en en l'altre gràfic. Hi ha un munt de diferents sabors de NoSQL. Són tot tipus d'aconseguir munged junts en aquest punt. Vostè pot mirar DynamoDB i dir que sí, els dos som un document i un valor clau emmagatzemar aquest punt. I vostè pot discutir les característiques d'un sobre l'altre. Per a mi, molt d'això és realment de sis de la meitat d'una dotzena dels altres. Cadascuna d'aquestes tecnologies és una tecnologia fina i una multa solució. Jo no diria que MongoDB és millor o pitjor que Couch, a continuació, Cassandra, llavors Dynamo, o viceversa. Vull dir, aquests són només opcions. 

És ràpid i és consistent en qualsevol escala. Així que aquest és un dels més grans bonificacions que reben amb AWS. Amb DynamoDB és la capacitat per obtenir un sol dígit sota latència de milisegons a qualsevol escala. Aquest va ser un objectiu de disseny del sistema. I tenim clients que estan fent milions de transaccions per segon. 

Ara vaig a anar a través d'alguns dels casos d'ús en pocs minuts aquí. Control-- accés integrat tenim el que anomenem Identitat Access Management o IAM. Impregna tot sistema, tots els serveis que ofereix AWS. DynamoDB no és una excepció. Podeu controlar l'accés a les taules DynamoDB. A través de tots els comptes de AWS definició de funcions d'accés i permisos en la infraestructura d'IAM. 

I és un component essencial en el el que anomenem Esdeveniment Programació Driven. Ara bé, aquest és un nou paradigma. 

AUDIÈNCIA: Com és la seva taxa de veritat positius davant falsos negatius en el seu sistema de control d'accés? RICK Houlihan: Els veritables positius enfront de falsos negatius? AUDIÈNCIA: Tornant el vostè ha de tornar? A diferència de tant en tant no torna quan hauria de validar? 

RICK Houlihan: No li podia dir això. Si hi ha qualsevol error algun en què, No sóc la persona per preguntar aquesta pregunta en particular. Però això és una bona pregunta. Seria curiós saber que jo, en realitat. 

I així, de nou, nou paradigma és la programació orientada a esdeveniments. Aquesta és la idea que pugui implementar aplicacions complexes que pot operar una molt alta escala molt sense qualsevol infraestructura de cap tipus. Sense cap tipus fix infraestructura. I parlarem una mica sobre el que això significa, ja que arribar a la següent parell de cartes. 

El primer que farem és parlarem de taules. Tipus de dades API per Dynamo. I la primera cosa que vostè compte quan ens fixem en això, si està familiaritzat amb qualsevol base de dades, bases de dades tenen realment dos tipus d'APIs Jo en diria. O dos conjunts d'API. Un d'ells seria API administrativa. 

Les coses que s'ocupen de les funcions de la base de dades. Configuració del motor d'emmagatzematge, la configuració i l'addició de taules. base de dades de creació catàlegs i instàncies. Aquests coses-- en DynamoDB, que tenen molt curts, llistes curtes. 

Així que en altres bases de dades, vostè pot veure a desenes d'ordres, d'administratiu comandaments, per configurar aquestes opcions addicionals. En DynamoDB que no cal perquè els no configura el sistema, el que fem. Així que l'únic que ha de fer és digues-me quina mida de la taula em cal. Així s'obté una molt conjunt limitat d'ordres. 

Vostè rep un CREATE TABLE actualització, Taula, Eliminar la taula, i descriure la taula. Aquestes són les úniques coses el que necessites per DynamoDB. Vostè no necessita un emmagatzematge configuració del motor. No necessito de preocupar sobre la replicació. No necessito de preocupar sharding. 

No necessito de preocupar sobre qualsevol d'aquestes coses. Ho fem tot per vostè. Així que això és una gran quantitat de sobrecàrrega això és només aixecar el seu plat. Després tenim els operadors CRUD. CRUD és una cosa del que trucar a la base de dades que és Crear, actualitzar, eliminar operadors. Aquests són el comú les operacions de base de dades. Coses com a punt de venda, aconsegueix l'article, actualització elements, eliminar elements, consulta per lots, escanejar. Si voleu escanejar tota la taula. Tiri tota la taula. Una de les coses bones de DynamoDB és que permet l'escaneig paral·lel. Així que en realitat es pot fer-me saber quants fils desitja executar en aquesta exploració. I podem executar aquests fils. Podem girar que mira cap amunt a través de múltiples fils així que vostè pot escanejar tota la taula espai molt, molt ràpidament en DynamoDB. 

L'altra API que tenim és el que anomenem la nostra API Rierols. No anem a parlar massa molt d'això ara. Tinc una mica de contingut més tard en la baralla sobre això. Però Streams és realment un running-- pensar en ell com el temps va ordenar i registre de canvis de particions. Tot el que està succeint en la taula es mostra en la seqüència. 

Cada escriptura en la taula apareix en el corrent. Vostè pot llegir aquest corrent, i es poden fer coses amb ell. Anem a parlar del que tipus de coses que vostè veure amb les coses com la replicació, la creació d'índexs secundaris. Tot tipus de genial coses que pots fer amb això. 

Els tipus de dades. En DynamoDB, donem suport tant clau de valor i dades de documents tipus. A la part esquerra de la pantalla aquí, tenim els nostres tipus bàsics. Tipus de valor clau. Aquests són cadenes, nombres i els binaris. 

Així que només tres tipus bàsics. I llavors vostè pot tenir conjunts d'aquests. Una de les coses bones de NoSQL és pot contenir matrius com a propietats. I amb DynamoDB pot contenir matrius de tipus bàsics com una propietat arrel. 

I després hi ha els tipus de documents. Quantes persones estan familiaritzats amb JSON? Vostès estan familiaritzats amb JSON tant? Es tracta bàsicament de JavaScript, Objecte, notació. Li permet, bàsicament, definir una estructura jeràrquica. 

Podeu desar un document en JSON DynamoDB usant components comuns o blocs de construcció que estan disponibles en la majoria dels llenguatges de programació. Així que si vostè té Java, ets mirant els mapes i llistes. Puc crear objectes que del mapa. Un mapa com a valors clau emmagatzemat com propietats. I podria tenir llistes de valors dins d'aquestes propietats. Pot emmagatzemar aquest complex estructura jeràrquica com un sol atribut d'un element DynamoDB. 

Així taules en DynamoDB, com la majoria Bases de dades NoSQL, taules tenen elements. En MongoDB ho faria cridar a aquests documents. I seria la base sofà. També una base de dades documental. Vostè crida a aquests documents. Documents o elements tenen atributs. Poden existir atributs o no existeix en l'article. En DynamoDB, hi ha un atribut obligatori. Igual que en una base de dades relacional, vostè té una clau principal a la taula. 

DynamoDB té el que anomenem una clau hash. Clau hash ha de ser únic. Així que quan em defineixo una taula hash, bàsicament el que estic dient és cada article tindrà una clau hash. I cada tecla coixinet ha de ser únic. 

Cada article es defineix per aquesta clau hash únic. I només pot haver un. Això està bé, però moltes vegades el que la gent necessita és que volen és aquest hash clau per fer una mica més que simplement ser un identificador únic. Moltes vegades volem utilitzar-la hash com la part superior de cub agregació nivell. I la manera de fer això és per afegint el que anomenem una clau gamma. 

Així que si és només un hash taula, aquest ha de ser únic. Si es tracta d'una taula hash i el rang, la combinació de l'haixix i la gamma ha de ser únic. Així que pensar-hi d'aquesta manera. Si tinc un fòrum. I la forma té temes, té llocs, i té respostes. 

Així que vaig a tenir un hash clau, que és l'identificador de tema. I jo podria tenir una clau de gamma, que és la ID de resposta. D'aquesta forma si vull obtenir tota la respostes per a determinat tema, Jo només puc consultar el hash. Jo només puc dir em dóna tot els elements que tenen aquest hash. I jo vaig a posar totes les preguntes o publicar-los per aquest tema en particular. Aquestes agrupacions de primer nivell són molt importants. Donen suport a l'accés primari patró de l'aplicació. En termes generals, aquest és el que volem fer. Volem que table-- com es carrega la taula, volem estructurar les dades dins de la taula d'una manera tal que l'aplicació pot molt recuperar ràpidament els resultats. I sovint la forma de fer-ho és per mantenir aquestes agregacions com ens inserir les dades. Bàsicament, estem estenent les dades a la galleda brillant, ja que ve a. 

Tecles Range permeten picada mi-- claus han d'haver igualtat. Quan consulta un coixinet, que he de dir dóna'm un hash que és igual a això. Quan consulta una gamma, que pot dir-me una gamma que és l'ús de qualsevol tipus de rica operador que donem suport. Dóna'm tots els elements per a un hash. És igual, més gran que, menys, què començar, ¿Existeix entre aquests dos valors? Així que aquest tipus de consultes de rang que estem sempre interessats en. Ara una cosa sobre les dades, quan ens fixem en l'accés a les dades, quan accedir a les dades, és Sempre es tracta d'una agregació. Sempre es tracta dels registres que tenen a veure amb això. Dóna'm tot el que aquí Això és-- tot les transaccions en aquesta targeta de crèdit per a l'últim mes. Això és una agregació. 

Gairebé tot el que fas en el base de dades és una espècie d'agregació. Així que ser capaç de ser capaç de definir aquests cubs i donar-li aquests van atributs per poder consultar a, aquestes consultes rics donen suport a molts, molts, molts patrons d'accés de l'aplicació. 

Així que l'altra cosa la tecla coixinet fa és que ens dóna un mecanisme per ser capaç de difondre les dades voltant. Bases de dades NoSQL funcionen millor quan les dades són uniformement distribuït en tot el clúster. Quantes persones són familiars amb algoritmes hash? Quan dic hash i un hashing-- perquè un algoritme de hash és una manera de ser capaç de generar un valor aleatori de qualsevol valor donat. Així que en aquest cas particular, l' algoritme de hash correm és ND 5 basat. 

I si tinc una identificació, i això és el meu clau hash, tinc 1, 2, 3. Quan executo l'algoritme de hash, que va a tornar i dir, bé 1 és igual a 7B, 2 és igual a 48, 3 és igual a CD. Estan repartits per tot l'espai de claus. I per què fas això? A causa que s'assegura que puc posar els registres a través de múltiples nodes. 

Si jo estic fent això incremental, 1, 2, 3. I tinc un rang hash que carreres en aquest cas particular, un petit espai de hash, que va des de 00 a FF, a continuació, els registres vindran a i que van a anar a 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12. Què passa? Cada inserit va al mateix node. Veus el que vull dir? 

Perquè quan em vaig separar l'espai, i jo vaig estendre aquests registres a través de, i la partició jo, jo vaig a dir partició 1 té espai de claus 0-54. Partició 2 és 55-89. Partició 3 és AA a FF. Així que si estic fent servir linealment incrementant Identificadors, es pot veure el que està succeint. 1, 2, 3, 4, 5, 6, tot el camí fins a 54. Així com estic colpejant la registres en el sistema, tot acaba anant a un node. 

Això no és bo. Aquest és un anti patró. En MongoDB tenen aquest problema si vostè no utilitza una clau hash. MongoDB li dóna l'opció de hash el valor clau. Vostè sempre ha de fer això, si utilitzeu un hash incrementant clau en MongoDB, o serà clavant cada escriptura per a un node, i se li limitant el seu rendiment d'escriptura malament. 

AUDIÈNCIA: És que A9 169 en decimal? 

RICK Houlihan: Sí, és en algun lloc per allà. A9, jo no ho sé. Caldria aconseguir el meu binària a la calculadora decimal. El meu cervell no funciona d'aquesta manera. AUDIÈNCIA: Només una ràpida dels seus comentaris Mongo. Així és l'ID d'objecte que ve nativa amb Mongo fer això? RICK Houlihan: Fa això? Si s'especifica la mateixa. Amb MongoDB, vostè té l'opció. Pot specify-- cada document en MongoDB ha de tenir un ID de subratllat. Aquest és el valor únic. 

En MongoDB pot especificar ja sigui per discutir o no. Ells només li donen l'opció. Si vostè sap que és a l'atzar, cap problema. Vostè no ha de fer això. Si vostè sap que no és a l'atzar, que està incrementant, i després fer el hash. 

Ara el que passa hash, una vegada que hash de 1 value-- i això és per què claus hash són sempre consultes úniques, perquè he canviat el valor, ara no pot fer una consulta gamma. No puc dir que és això entre això o allò, pel fet que el valor de resum no va ser equivalent al valor real. Així que quan vostè hash que clau, és només la igualtat. Per això, en clau hash DynamoDB consultes són sempre només la igualtat. 

Així que ara en un rang key-- quan afegeixo aquesta clau gamma, aquests registres claus abast tots entren i que s'emmagatzemen en la mateixa partició. Així que són molt ràpidament, fàcilment recuperada perquè aquest és el haixix, aquest és el rang. I es veu tot amb el mateix hash s'emmagatzema en el mateix espai de partició. Vostè pot usar aquesta clau gamma per ajudar localitzar les seves dades a prop del seu pare. Llavors, què estic fent realment aquí? Aquesta és una d'un a molts relació. La relació entre una clau hash i la tecla de rang és d'un a molts. Puc tenir diverses claus hash. Només puc tenir rang múltiple claus dins de cada tecla coixinet. 

El hash defineix el pare, el rang defineix els nens. Així que vostè pot veure que hi ha analògic aquí entre el constructe relacional i els mateixos tipus de construeix en NoSQL. La gent parla de NoSQL com no relacional. No és no relacional. Les dades sempre té relacions. Aquestes relacions simplement es modelen de manera diferent. Anem a parlar una mica poc sobre la durabilitat. Quan s'escriu a DynamoDB, escriu són sempre tres vies replicat. El que vol dir que tenim tres AZ de. AZ de són zones de disponibilitat. Vostè pot pensar en una disponibilitat Zona com un centre de dades o una col·lecció de centres de dades. Aquestes coses són geogràficament aïllats els uns dels altres a través de diferents zones de falles, a través de diferents xarxes elèctriques i les planes d'inundació. Una fallada en un AZ no és va acabar amb l'altre. Ells també estan vinculats juntament amb la fibra fosca. És compatible amb una sub 1 latència de mil·lisegons entre AZS. Així replicacions de dades en temps real capaç en múltiples AZS. 

I moltes vegades els desplegaments múltiples Alfabet complir amb els requisits d'alta disponibilitat de la majoria de les organitzacions empresarials. Així DynamoDB es propaga a través de tres AZS per defecte. Només anem al coneixement de l'escriptura quan dos d'aquests tres nodes tornen i dic: Sí, ho tinc. Perquè és això? A causa de que en el costat de lectura només estem vaig a donar les dades de nou quan ho fem a partir de dos nodes. 

Si estic replicant en tot 3, i estic llegint de dos, Sempre estic garantit per tenir almenys una dels que llegeix ser el més còpia actualitzada de les dades. Això és el que fa DynamoDB consistent. Ara vostè pot optar per activar aquells consistents llegeix fora. En aquest cas vaig a dir, Jo només vaig a llegir d'un node. I no puc garantir que va sent les dades més actuals. 

Així que si una escriptura està entrant, no ha replicat encara, vostè va a aconseguir que la còpia. Aquesta és una lectura finalment coherent. I el que és això és la meitat del cost. Així que això és una cosa en què pensar. Quan vostè està llegint DynamoDB, i està configurant la seva capacitat de lectura unitats, si es trien amb el temps lectures consistents, és molt més barat, que és aproximadament la meitat del cost. 

I pel que li estalvia diners. Però aquesta és la seva elecció. Si vols una lectura consistent o una lectura finalment coherent. Això és una cosa que es pot triar. 

Anem a parlar dels índexs. Així esmentem que agregació de nivell superior. Tenim claus hash, i tenim claus abast. Això està bé. I això és a la taula principal, I ens van donar una clau hash, tinc una clau gamma. 

Què vol dir això? Tinc un atribut que pot executar consultes rics contra. És la clau gamma. Els altres atributs en què item-- Puc filtrar aquests atributs. Però jo no puc fer coses similars, comença amb, o és més gran que. 

Com puc fer això? Puc crear un índex. Hi ha dos tipus de índexs en DynamoDB. Un índex és realment una altra vista de la taula. I l'índex secundari local. 

La primera d'elles parlarem. Així que secundàries locals es van coexistir en la mateixa partició que les dades. I com a tals, són en el mateix node físic. Són el que anomenem consistent. Significat, van a reconèixer l'escriptura juntament amb la taula. Quan l'escriptura ve, anem a escriure a través de l'índex. Anem a escriure fins a la taula, i després anem a reconèixer. Així que això és consistent. Una vegada que l'escriptura ha estat reconegut de la taula, està garantit que la índex secundari locals tindrà la mateixa visió de les dades. Però el que permeten que fas és definir tecles de rang alterns. 

Ha de fer servir el mateix hash tecla que la taula principal, perquè ells són co-ubicat a la mateixa partició, i són consistents. Però puc crear un índex amb diferents claus abast. Així, per exemple, si jo tingués un fabricant que tenia una taula de peces en brut que entra. I parts primes vénen en i que estan agregats pel muntatge. I potser hi ha un recés. 

Qualsevol part que va ser fet per aquest fabricant després d'aquesta data, He de tirar de la meva línia. Puc girar un índex que estaria buscant, afegint a la data de fabricació d'aquesta part en particular. Així que si la meva taula d'alt nivell va ser ja hash pel fabricant, potser es va organitzar en part ID, I pot crear un índex d'aquesta taula com hash segons el fabricant i oscil·lat en la data de fabricació. I d'aquesta manera jo podria dir, tot el que va ser fabricat entre aquestes dates, He de tirar de la línia. Així que això és un índex secundari local. 

Aquests tenen l'efecte de limitant el seu espai clau hash. A causa que co-existit en el mateix node d'emmagatzematge, limiten la tecla coixinet espai per a 10 gigabytes. DynamoDB, sota la taules, es particions seva taula cada 10 gigabytes. Quan vostè posa 10 gigues de dades, ens anar [PHH], i afegim un altre node. 

No anem a dividir l'LSI en diverses particions. Anem a dividir la taula. Però no anem a dividir el LSI. Així que això és una cosa important entendre és si ho estàs fent molt, molt, molt grans agregacions, llavors vostè va a estar limitada 10 gigabytes en el seu LSI. 

Si aquest és el cas, podem utilitzar secundaris globals. Secundàries globals són realment una altra taula. Hi completament fora de el costat de la taula principal. I ells em permeten trobar una completament diferent estructura. Així que pensar-hi com s'està inserint dades en dues taules diferents, estructurats de dues maneres diferents. 

Puc definir una totalment diferent clau hash. Puc definir una totalment clau diferent rang. I puc executar aquest de forma totalment independent. Com a qüestió de fet, tinc aprovisionat la meva capacitat de lectura i escriure capacitat per a mi índexs secundaris globals de forma totalment independent de la meva taula principal. Si defineixo aquest índex, li dic que la quantitat de lectura i escriptura la capacitat que utilitzarà. 

I això és separada des del meu taula principal. Ara, tant dels índexs ens permeten no només definir claus de hash i d'abast, però ens permeten projectar valors addicionals. Així que si vull llegir l'índex, i vull aconseguir algun conjunt de dades, No necessito tornar a la principal taula per obtenir els atributs addicionals. Puc projectar aquells addicional atributs en la taula per donar suport al patró d'accés. Sé que probablement estem arribant a algun Realment, realmente-- entrar a la mala herba aquí a algunes d'aquestes coses. Ara tinc a la deriva fora d'això. 

AUDIÈNCIA: [inaudible] clau --table volia dir era un hash? El hash original? Multi-lames? 

RICK Houlihan: Sí. Sí. La clau de la taula, bàsicament, apunta de nou al tema. Així que un índex és un punter de nou a els elements originals en la taula. Ara vostè pot triar per construir un índex que només té la clau de la taula, i no hi ha altres propietats. ¿I per què podria jo fer això? Bé, potser tinc articles molt grans. 

En realitat només necessito saber which-- el meu patró d'accés podria dir: els elements que contenen aquesta propietat? No cal retornar l'article. Només necessito saber els elements que contenen. Així que vostè pot construir índexs que només tenen la clau de la taula. 

Però això és principalment el que un índex a la base de dades és per. És per poder ràpidament identificar que registra, què files, les quals els elements de la taula tenen les propietats que estic buscant. 

GSI, així que com funcionen? GSI bàsicament són asíncrones. L'actualització entra a la taula, A continuació, s'actualitza la taula de forma asíncrona tota la seva GSI. Aquesta és la raó per GSI són finalment consistent. 

És important assenyalar que quan vostè està construint GSI, i entén que està creant una altra dimensió de aggregation-- Ara diguem que un bon exemple aquí és un fabricant. Crec que podria haver parlat un fabricant de dispositius mèdics. Fabricants de dispositius mèdics moltes vegades tenen parts serialitzats. Les parts que intervenen en la un reemplaçament de maluc tot tenir un petit nombre de sèrie en ells. I podrien tenir milions i milions i milers de milions de peces en tots els dispositius que envien. Bé, han de agregar sota diferents dimensions, totes les peces en una assemblea, tota la parts que es van fer en una determinada línia, tot les parts que vénen des d'un cert fabricant en una data determinada. I aquestes agregacions de vegades aixecar-se als milers de milions. 

Així que jo treball amb alguns aquests nois que estan patint perquè estan creant aquestes agregacions ginormous en els seus índexs secundaris. Pot ser que tinguin unes parts primes taula que ve ja que només hash. Cada part té un número de sèrie únic. Jo ús el número de sèrie que el hash. És bonic. El meu taula de dades en brut es propaga tot l'espai de claus. La meva [? escriure?] [? la ingestió?] és impressionant. Tinc una gran quantitat de dades. Llavors el que fan és que creen un GSI. I dic jo, saps què, he de veure totes les parts d'aquest fabricant. Bé, de sobte estic tenint un bilió de files, i ficar-los en un node, perquè quan Jo agregada com el ID del fabricant com el haixix, i el nombre de peça com el rang, llavors de cop i volta estic posar mil milions d'parts en el que aquest fabricant m'ha lliurat. 

Això pot causar una gran quantitat de pressió sobre el GSI, de nou, perquè estic martellejant un node. Estic posant tot això s'insereix en un node. I això és un cas real ús problemàtic. Ara, tinc un bon disseny patró de com evitar això. I aquest és un dels problemes que jo sempre treball amb. Però el que passa, és el GSI podria no tenen suficient capacitat d'escriptura per ser capaç d'empènyer tots aquells files en un sol node. I el que passa a continuació és la primària, la taula de clients, la taula principal serà estrangulat pel fet que el GSI no pot seguir el ritme. Així que la meva taxa d'inserció serà caure en la taula principal com el meu GSI tracta de mantenir el ritme. 

Molt bé, així GSI de, LSI de, quina hauria d'utilitzar? LSI de són consistents. GSI de són finalment consistent. Si això està bé, recomano l'ús d'un GSI, són molt més flexibles. LSI de es pot modelar com un GSI. I si la mida de les dades per claus hash en la seva col·lecció supera els 10 gigabytes, llavors vostè va a voler usar aquest GSI perquè és només un límit dur. 

Molt bé, pel que l'escala. El rendiment en el Dynamo DB, prestació llauna [inaudible] rendiment per a una taula. Tenim clients que tenen aprovisionat 60 billion-- estan fent 60 mil milions de sol·licituds, amb regularitat funcionant a més d'un milió sol·licituds per segon a les nostres taules. En realitat no hi ha límit teòric a la quantitat de i la rapidesa amb la taula es pot executar en Dynamo DB. Hi ha alguns suau límits en el seu compte que posem allà, així que no tornar-se boig. Si voleu més que, no és un problema. Vens dir-nos. Anem a pujar el dial. 

Cada compte està limitada a un cert nivell en cada servei, just al costat del pal de manera que les persones no es tornen bojos es fiquen en problemes. No hi ha límit de mida. Vostè pot posar qualsevol nombre d'elements en una taula. La mida d'un element és limitat a 400 kilobytes cadascun, això seria no tema els atributs. Així que la suma de tots els atributs està limitat a 400 kilobytes. I, de nou, tenim aquest petit problema de LSI amb el límit de 10 gigabytes per hash. AUDIÈNCIA: Petit nombre, estic desapareguts el que m'estàs dient, que és-- AUDIÈNCIA: Oh, 400 kilobytes és la mida màxima per article. Així que un element té tots els atributs. Així que 400 k és la mida total d'aquest article, 400 kilobytes. Així que de tots els atributs combinats, totes les dades això és en tots aquests atributs, enrotllat en una mida total, Actualment l'actualitat el límit d'elements és de 400 k. Així escalat de nou, aconseguit a través de la partició. El rendiment s'aprovisiona a nivell de taula. I no hi ha realment dos perillós. Hem llegit la capacitat i escriure capacitat. 

Així que aquests s'ajusten independentment un de l'altre. Mesura de RCU estrictament llegeix consistent. OK, així que si vostè està dient que vull 1000 UCR d'aquests són estrictament coherent, aquests són lectures consistents. Si dius que vull eventual coherent llegeix, vostè pot aprovisionar 1000 UCR de, vas per arribar finalment 2000 llegeix consistent. I la meitat del preu dels finalment consistir en llegeix. 

Un cop més, ajustat independentment un de l'altre. I tenen la throughput-- Si vostè consumeix 100% del seu comandament a distància, vostè no va a afectar el disponibilitat dels seus drets. Pel que són completament independents entre si. Molt bé, així que una de les coses que Vaig esmentar breument estava estrangulant. Throttling és dolent. Throttling indica malament sense SQL. Hi ha coses que podem fer per ajudar a alleujar l'estrangulació que estan experimentant. Però la millor solució a això és que tirem Una mirada al que està fent, perquè hi ha un anti-patró en joc aquí. 

Aquestes coses, coses com no uniforme les càrregues de treball, tecles d'accés ràpid, particions calents. Estic colpejant un espai clau particular molt dur per alguna raó en particular. Per què estic fent això? Anem a donar-se compte d'això. Estic barrejant les meves dades calents amb les dades fredes. Jo vaig a deixar els meus quadres aconsegueixen enorme, però no hi ha realment només alguns subconjunt de les dades això és molt interessant per a mi. Així que per a les dades de registre, per exemple, una gran quantitat de clients, que reben dades de registre cada dia. Tenen una enorme quantitat de dades de registre. 

Si acaba d'abocament tot aquest registre dades en una gran taula, amb el temps aquesta taula es posarà massiva. Però estic realment només interessat en últimes 24 hores, els últims set dies, els últims 30 dies. Qualsevol que sigui la finestra de temps que estic interessat en mirar per al cas que em molesta, o el cas que és interessant per a mi, aquesta és l'única ocasió en la finestra que necessito. Així que per què estic posant 10 anys el valor de les dades de registre a la taula? El que fa és la taula del fragment. 

Es posa enorme. Comença estesa a través de milers de nodes. I ja que la seva capacitat és tan baixa, que està en realitat la limitació de velocitat a cada un d'aquests nodes individuals. Així que anem a començar a mirar com fem vam rodar aquesta taula. Com gestionem les dades una mica millor evitar-los. I ¿què s'assemblen? Això és el que sembla. Això és el dolent NoSQL es sembla. 

Vaig rebre una tecla d'accés ràpid aquí. Si ens fixem en el costat aquí, aquests són tots els meus particions. Tinc 16 particions aquí en aquesta base de dades particular. Ho fem tot el temps. Corro això per als clients de tots els temps. Es diu el mapa de calor. Mapa de calor em diu el que ets l'accés al seu espai de claus. I el que això m'està dient és que hi ha un coixinet especial que aquest noi li agrada 1 moltíssim, perquè és copejant molt, molt difícil. 

Així que el blau és agradable. Ens agrada blau. No ens agrada el vermell. Xarxa on la pressió s'incorpora al 100%. 100%, ara seràs estrangulat. Així que cada vegada que hi ha línies vermelles com esto-- i no es tracta només Dynamo DB-- cada base de dades NoSQL té aquest problema. No són anti-patrons que poden conduir aquest tipus de condicions. El que faig és que treball amb els clients per alleujar aquestes condicions. 

I ¿què s'assemblen? I això és cada vegada més fora del Dynamo DB rendiment, però és realment arribar el màxim profit de NoSQL. Això no es limita a Dynamo. Això és el definitely-- solia treballar en Mongo. Estic familiaritzat amb moltes plataformes NoSQL. Cada un té aquest tipus dels problemes claus calents. Per treure el màxim partit de qualsevol NoSQL base de dades, específicament Dynamo DB, Per crear les taules on l'element clau hash té un gran nombre de valors diferents, un alt grau de cardinalitat. Perquè això vol dir que estic escrivint a un munt de diferents cubs. 

Els més cubs estic escrit a, més probable Estic a difondre que la càrrega d'escriptura o llegir carregar a terme a través de múltiples nodes, és més probable que sóc i tenir una d'alt rendiment a la taula. I després vull que els valors siguin sol·licitat de manera bastant uniforme en el temps i uniformement com a l'atzar com sigui possible. Bé, això és força interessant, perquè no puc realment control quan els usuaris entren. Així que n'hi ha prou amb dir, si vam difondre coses fora de tot l'espai de claus, probablement estarem en millor forma. 

Hi ha una certa quantitat de temps de lliurament que no vas ser capaços de control. Però aquests són en realitat el dues dimensions que tenim, espai, l'accés de manera uniforme propagació, el temps, les sol·licituds arribin uniformement espaiades en el temps. I si aquests dos s'estan complint les condicions, llavors això és el que és va a semblar. Això és molt més bonic. Estem molt feliços aquí. Tenim un esquema d'accés molt parell. Sí, potser vostè està rebent un poca pressió de tant en tant, però res realment massa extensa. Així que és increïble la quantitat de vegades, quan treballo amb els clients, aquesta primera gràfica la gran vermella bar i tot el lleig de color groc que és per tot el lloc, ens aconseguir fet amb l'exercici després d'un parell de mesos de la re-arquitectura, estan corrent la mateixa exacta càrrega de treball en la mateixa càrrega exacta. I això és el que està buscant com ara. Així que el que obtens amb NoSQL és un esquema de dades que és absolutament lligat al patró d'accés. 

I vostè pot optimitzar aquest esquema de dades per donar suport aquest patró d'accés. Si no ho fa, llavors vostè va veure aquests tipus de problemes amb aquestes tecles d'accés ràpid. 

AUDIÈNCIA: Bé, inevitablement, alguns llocs seran més calent que altres. 

RICK Houlihan: Sempre. Sempre. Sí, vull dir que sempre hi ha A-- i una altra, no hi ha alguns patrons de disseny que van a obtenir a través d' que va a parlar sobre com tractar amb aquestes súper grans agregacions. Vull dir, he de tenir-les, Com ens ocupem d'ells? Tinc un molt bon cas d'ús que anem a parlar d'això. 

Molt bé, així que anem a parlar sobre alguns clients ara. Aquests nois són Adroll. No sé si estàs familiaritzats amb Adroll. És probable que els vegi molt en el navegador. Són ad re-focalització, són el negoci més gran ad re-focalització per allà. Normalment surten regularment sobre 60 mil milions de transaccions per dia. Estan fent més d'un milió transaccions per segon. Tenen una taula bastant simple estructura, la taula més concorreguda. És bàsicament un clau hash és la galeta, la gamma és el demogràfic categoria, i després el tercer atribut és la puntuació. 

Així que tots tenim galetes nostre navegador d'aquests nois. I quan vas a un comerç participant, que bàsicament s'anoten en tot diverses categories demogràfiques. Quan vas a un lloc web i vostè diu que vull veure aquesta ad-- o bàsicament no dius que-- però quan vas a la pàgina web ells diuen que vostè desitja veure aquest anunci. I van aconseguir aquest anunci de Adroll. Adroll que mira cap amunt a la seva taula. Ells troben que el seu galeta. Els anunciants diuen ells, em volen a algú que és de mitjana edat, Home de 40 anys d'edat, en els esports. I et anoten en aquestes dades demogràfiques i decideixen si és o no això és un bon anunci per a tu. 

Ara tenen un SLA amb seus proveïdors de publicitat per proporcionar sub-10 milisegons resposta a cada petició individual. Així que estan usant Dynamo DB per això. Ells ens estan colpejant un milió de sol·licituds per segon. Són capaços de fer tot el seu recerques, triatge totes aquestes dades, i aconseguir que l'enllaç afegir de nou a aquest anunciant en menys de 10 milisegons. És realment bastant fenomenal aplicació que tenen. 

Aquests nois actually-- són aquests els nois. No estic segur de si es tracta d'aquests nois. Podria ser que aquests nois. Bàsicament nosaltres-- vaig dir que no, em no crec que eren ells. Crec que va ser una altra persona. Jo estava treballant amb un al client que em va dir que ara que han anat a Dynamo DB, són gastar més diners en entrepans per el seu equip de desenvolupament de cada mes el que gasten a la base de dades. Així que ell es pot donar una idea dels estalvis de costos que es pot obtenir en el Dynamo DB és enorme. Molt bé, Dropcam és una altra companyia. Aquests tipus és tipus de-- si vostè pensa d'Internet de les coses, Dropcam és bàsicament el vídeo de seguretat d'Internet. Vostè posa el seu càmera per aquí. La càmera té un detector de moviment. Algú ve, desencadena un punt de referència. Cambra comença a gravar durant un temps fins no detecta cap moviment més. Posa aquest vídeo en l'internet. 

Dropcam era una empresa que és bàsicament canviat a Dynamo DB perquè estaven experimentant enormes dolors de creixement. I el que ens van dir, sobtadament petabytes de dades. No tenien idea del seu servei seria tan reeixit. Més de vídeo d'entrada de YouTube és el que aquests nois estan rebent. Utilitzen DynamoDB seguir fins al metadades en tots els seus punts clau de vídeo. 

Així que tenen cubs S3 que empenyen tots els artefactes binaris en. I després tenen Registres Dynamo DB que assenyalar a la gent als tres objectes S3. Quan necessiten per mirar un vídeo, es veuen fins al registre a Dynamo DB. Fer clic a l'enllaç. Que tiri cap avall el vídeo de S3. Així que això és una cosa del que això es sembla. I això és directament del seu equip. 

Dynamo DB redueix la seva temps de lliurament d'esdeveniments de vídeo de cinc a 10 segons. A la seva botiga relacional d'edat, solien haver d'anar i executar múltiples consultes complexes a la figura quins vídeos per tirar avall, a menys de 50 milisegons. Així que és increïble, increïble quant rendiment vostè pot aconseguir quan optimitzar i sintonitza la base de dades subjacent per donar suport al patró d'accés. Halfbrick, aquests nois, ¿què és, Fruit Ninja Suposo que és el seu. Que totes les carreres i Dynamo DB. I aquests nois, que són una gran equip de desenvolupament, gran desenvolupament botiga. 

No és un bon equip d'operacions. Ells no tenen molt dels recursos d'operació. Ells estaven lluitant tractant de mantenir la seva infraestructura d'aplicacions fins i en execució. Ells van venir a nosaltres. Es veien en aquest Dynamo DB. Ells van dir, això és per a nosaltres. Van construir la seva totalitat marc d'aplicació de la mateixa. Alguns comentaris molt bonics aquí De l'equip de la seva capacitat ara a centrar-se en la creació el joc i no haver de mantenir la infraestructura, que s'estava convertint en una quantitat enorme de les despeses generals per al seu equip. Així que això és una cosa que-- el benefici que s'obté de Dynamo DB. 

Molt bé, entrar en modelatge de dades aquí. I parlem una mica sobre aquest un a un, un a molts, i molts de moltes relacions de tipus. I ¿com mantenir els de Dynamo. En Dynamo DB fem servir índexs, parlant en general, per girar les dades de un sabor a l'altra. Claus hash, claus abast, i els índexs. 

En aquest particular, exemple, com la majoria dels estats tenir un requisit de llicència que Només una llicència d'un conductor per persona. Vostè no pot anar a aconseguir dos controlador de llicències en l'estat de Boston. Jo no puc fer-ho a Texas. Això és una cosa de la manera que és. I així en el DMV, tenim les recerques, que vulgueu cercar la llicència de conduir pel nombre d'assegurança social. Vull veure els detalls d'usuari per nombre de llicència de conduir. 

Així que pot ser que tinguem la taula d'un usuari que té una clau hash en el nombre de sèrie, o el nombre d'assegurança social, i diversos atributs definits en l'article. Ara en aquesta taula I podria definir un GSI que mou d'una tirada que al voltant del qual diu que vull Un resum en la llicència i després tots els altres articles. Ara si vull consultar i trobar la número de llicència per a qualsevol Social donada Nombre d'assegurança, puc consultar la taula principal. 

Si vull consultar i vull per aconseguir la seguretat social nombre o altres atributs per una número de llicència, puc consultar el GSI. Aquest model és que un una relació. Només un molt simple GSI, voltejar aquestes coses. Ara, parlar d'un a molts. Un de molts és, bàsicament, seva clau gamma hash. D'on traiem molt amb aquest de casos d'ús és dades del monitor. Les dades del monitor ve en regulars interval, com Internet de les coses. Sempre ens donen tots aquests registres venint en tot el temps. 

I vull trobar totes les lectures entre un període de temps determinat. És una consulta molt comú en infraestructura de monitorització. La manera d'anar sobre que és trobar un senzilla estructura de la taula, una taula. Tinc una taula de mesuraments del dispositiu amb una clau hash en l'identificador de dispositiu. I tinc una clau de rang en la marca de temps, o en aquest cas, l'èpica. I això em permet executar complexes consultes en aquesta clau gamma i tornar els registres que són en relació amb el resultat vaig proposar que jo estic buscant. I és que un construeix a molts relació a la taula principal utilitzant la clau hash, estructura clau gamma. 

Així que això és quelcom construït en la taula de Dynamo DB. Quan defineixo un hash i la gamma t taula, estic la definició d'una relació d'un a molts. És una relació pare-fill. 

Anem a parlar de molts a moltes relacions. I per aquest exemple en particular, de nou, utilitzarem GSI de. I anem a parlar dels jocs escenari en el qual tinc un usuari determinat. Vull saber tots els jocs que que ha registrat a favor o jugant a. I per a un determinat joc, em que vulgueu trobar tots els usuaris. Llavors, com ho faig? La meva taula jocs d'usuari, vaig tenir una clau hash del ID d'usuari i una clau gamma del joc. 

Així, un usuari pot tenir diversos jocs. És un un a molts relació entre l'usuari i els partits en què juga. I després en el GSI, Vaig a la FLIP que al voltant. Vaig hash en el joc i Vaig a oscil·lar en l'usuari. Així que si vull obtenir tota la joc l'usuari de jugar a, Vaig a consultar la taula principal. Si vull aconseguir tots els usuaris que estan jugant un joc en particular, Jo consultar el GSI. Així que ja veus com fem això? Vostè construeix d'aquests GSI per donar suport a la de cas d'ús, l'aplicació, l'accés patró, l'aplicació. 

Si he de consultar a aquesta dimensió, anem em crea un índex en aquesta dimensió. Si no ho faig, no m'importa. I depenent del cas d'ús, I pot necessitar l'índex o jo no podria. Si és una simple un a molts, la taula principal està molt bé. Si he de fer això a molts a molts, o que han de fer una per a uns, llavors potser ho necessito al segon índex. Així que tot depèn de el que estic tractant de fer i el que jo estic tractant d'aconseguir consumat. 

Probablement no vaig a gastar massa molt de temps parlant de documents. Això posa una mica, probablement, més profund que hem d'entrar. Anem a parlar una mica sobre la rica expressió de consulta. Així que en Dynamo DB tenim la capacitat de crear el que anomenem expressions de projecció. Expressions de projecció són simplement recollint els camps o els valors que vol mostrar. OK, així que faig una selecció. Faig una consulta contra Dynamo DB. I dic jo, saps què, espectacle em només les cinc estrelles comentaris per a aquest producte en particular. Així que això és tot el que vull veure. No vull veure a tota la altres atributs de la fila, Només vull veure això. És com en SQL quan dir selecte estrella o de la taula, vostè aconsegueix tot. Quan dic seleccioneu el nom de taula, només tinc un atribut. És el mateix tipus de cosa en Dynamo DB o altres bases de dades NoSQL. Expressions Filtrar em permeten bàsicament tallar el resultat establert. Així que faig una consulta. Consulta pot tornar amb 500 articles. Però jo només vull que els elements que tenen un atribut que diu això. OK, així que anem a filtrar cap a fora els articles que no concorden amb aquesta consulta particular. Així que tenim expressions de filtre. 

Expressions filtre pot ser executat en qualsevol atribut. No són com consultes de rang. Raise consultes són més selectius. Consultes Filtrar em requereixen per anar obtenir tot el conjunt de resultats i després tallar les dades que jo no vull. Per què és important? Perquè he llegit tot. En una consulta, vaig a llegir i que serà un gegant sobre les dades. I després vaig a tallar el que necessito. I si només estic tallant un parell de files, llavors això està bé. No és tan ineficient. 

Però si estic llegint tota una pila de dades, només per llaurar-se un article, llavors jo seré millor fora mitjançant una consulta gamma, perquè és molt més selectiu. Es em va a estalviar un munt de diners, perquè he de pagar per aquesta lectura. Quan els resultats que ve de tornada creuar aquest filferro podria ser més petit, però jo estic pagant per la lectura. Així entendre com que està rebent les dades. Això és molt important en Dynamo DB. 

Les expressions condicionals, això és el que que es podria anomenar el bloqueig optimista. Actualització SI EXISTEIX, o si aquest valor és equivalent al que específic. I si tinc una marca de temps en un registre, podria llegir les dades. Jo podria canviar aquestes dades. Jo podria anar d'escriptura que tornar a la base de dades. Si algú ha canviat el registre, la marca de temps podria haver canviat. I d'aquesta manera la meva condicional actualització podria dir d'actualització Si la marca de temps és igual a aquest. O l'actualització fallarà perquè algú actualitzat el registre en el interí. 

Això és el que anomenem el bloqueig optimista. Això vol dir que algú pot entrar i canviar-la, i jo vaig a detectar- quan torni a escriure. I llavors puc realment llegit que dades i dir, oh, va canviar això. He de donar compte d'això. I puc canviar les dades de la meva gravar i aplicar una altra actualització. Així que vostè pot agafar els incrementals canvis que es produeixen entre el moment que llegeixi les dades i la el temps és possible escriure les dades. 

AUDIÈNCIA: I el filtre expressió en realitat no vol dir en el nombre o no-- 

[Interposant VEUS] RICK Houlihan: No ho faré tenir massa en això. Aquesta és una paraula clau reservada. La vista lliures és una reserva paraula clau en Dynamo DB. Cada base de dades té el seu propi reservats noms per a col·leccions que no es pot utilitzar. Dynamo DB, si especifica una lliura enfront d'això, pot definir els noms amunt. Aquest és un valor de referència. Probablement no sigui la millor sintaxi per tenir-hi per aquesta discussió, perquè es fica en alguns real-- Jo he estat parlant més sobre això en un nivell més profund. 

Però n'hi ha prou amb dir, això podria siguin consulta escanejar on views-- ni vistes lliures és més gran que 10. És un valor numèric, si. Si vols, podem parlar de que després de la discussió. Molt bé, així que estem ficant alguns escenaris en les millors pràctiques on parlarem sobre algunes aplicacions aquí. Quins són els casos d'ús per Dynamo DB. Quins són el disseny patrons en Dynamo DB. 

I el primer que anem a parlar és l'Internet de les coses. Així que tenim una gran quantitat de-- suposo, el que és it-- més del 50% del trànsit a Internet en aquests dies en realitat és generat per les màquines, processos automatitzats i no per éssers humans. Vull dir aquesta cosa aquesta cosa que que portes a la butxaca, la quantitat de dades que aquesta cosa és enviar realment tot sense tu sabent que és absolutament increïble. La seva ubicació, la informació sobre què tan ràpid se'n va. Com creus que Google Maps obres quan et diuen el que el trànsit és. És perquè hi ha milions i milions de persones que condueixen al voltant amb els telèfons que estan enviant dades en tot lloc tot el temps. Així que una de les coses sobre aquest tipus de dades que ve en, dades de monitorització, registre les dades, les dades de sèries de temps, és que és en general només és interessant per una mica de temps. Després d'aquest temps, és no tan interessant. Així que parlem, no deixis aquestes taules créixer sense límits. La idea és que potser tinc 24 hores de valor dels esdeveniments a la meva taula calent. I aquesta taula calenta serà aprovisionat a un ritme molt alt, perquè està tenint una gran quantitat de dades. Es tracta de prendre una gran quantitat de dades i estic llegint molt. Tinc un munt de funcionament consultes que s'executen en contra que les dades. 

Després de 24 hores, bé, sé què, no m'importa. Així que potser cada rotlle mitjanit la meva taula a una nova taula i jo desproveir aquesta taula. I vaig a prendre de la UCR i A baix de WCU perquè 24 hores després No estic corrent fins consultes en aquestes dades. Així que em vaig a estalviar diners. I potser 30 dies després no ho faig fins i tot necessitat de preocupar-se per tot. Jo podria prendre la UMM de tot el camí a un, perquè saps què, és mai va a quedar per escrit a. Les dades són de 30 dies d'edat. Mai canvia. 

I gairebé mai aconseguirà llegir, així que anem a prendre aquest UCR fins a 10. I jo estic estalviant un munt de diners en aquest de dades, i només per pagar les meves dades calents. Així que això és el més important per buscar en tant ens fixem en una sèrie temporal dades que entren en el volum. Aquestes són estratègies. Ara, jo podria deixar-ho tots van a la mateixa taula i deixar que la taula creixi. Amb el temps, vaig a veure els problemes de rendiment. Vaig a haver de començar a arxivar alguns que les dades de la taula, el que no. 

Anem molt millor dissenyar l'aplicació perquè pugui operar d'aquesta manera dreta. Així que és només automàtic en el codi d'aplicació. A la mitjanit cada nit roda de la taula. Potser el que necessito és una esllavissada finestra de 24 hores de dades. A continuació, de forma regular estic trucant a les dades de la taula. Estic retallada amb un Cron treball i m'estic posant en aquestes altres taules, tot el que necessitis. Així que si un tomb funciona, això és genial. Si no, retallar-lo. Però anem a mantenir aquestes dades en calent lluny de les seves dades fredes. Li estalviarà molts diners i fer els seus quadres més rendiment. Així que el següent que anem a parlar aproximadament és el catàleg de productes. Catàleg de productes és cas d'ús molt comú. Això és en realitat un patró molt comú que veurem en una varietat de coses. Ja saps, per Twitter exemple, un tweet calent. Tothom ve i agafant aquest tweet. Catàleg de productes, tinc una venda. Tinc una venda calenta. Tinc 70.000 sol·licituds per la segona vinguda d'un producte Descripció del meu catàleg de productes. Veiem això en la venda al detall operació bastant. Llavors, com podem fer davant d'això? No hi ha manera de tractar amb això. Tots els meus usuaris volen veure la mateixa peça de dades. Estan estan arribant, al mateix temps. I tots estan fent peticions per a la mateixa peça de dades. Això em dóna aquesta tecla d'accés ràpid, que vermell gran ratlla en la meva carta que no ens agrada. I això és el que sembla. Així que a través del meu espai de claus que estic rebent martillado en els articles de la venda. M'estic posant res en cap altre lloc. 

Com puc solucionar aquest problema? Bé, ens alleugem això amb memòria cau. Cache, que va posar bàsicament un in-memory partició al davant de la base de dades. Hem aconseguit [Inaudible] memòria cau, com pot configurar la seva pròpia memòria cau, [inaudible] memòria cau [? d ,?] el que vulguis. Posa això al davant de la base de dades. I d'aquesta manera vostè pot emmagatzemar les dades d'aquestes tecles d'accés ràpid en aquest cau espai i llegir a través de la memòria cau. 

I llavors la majoria de les teves lectures començar a buscar d'aquesta manera. Vaig aconseguir tots aquests encerts de memòria cau aquí i jo no tinc res passa aquí baix perquè la base de dades està assegut darrere de la memòria cau i mai llegeix vénen a través. Si canvi de les dades de la base de dades, he de actualitzar la memòria cau. Podem usar alguna cosa com vapors de fer això. I vaig a explicar com funciona. Molt bé, la missatgeria. Correu electrònic, tots fem servir correu electrònic. 

Aquest és un molt bon exemple. Tenim una espècie de taula de missatges. I arribem safata d'entrada i safata de sortida. Això és el que l'SQL faria semblar-se a construir aquesta safata d'entrada. És com que fem servir el mateix tipus de l'estratègia d'utilitzar GSI de, GSI de per la meva safata d'entrada i la meva safata de sortida. Així que em van donar missatges primeres procedents en el meu taula de missatges. I la primera aproximació a aquest podria ser, per exemple, està bé, cap problema. Tinc missatges primeres. Missatges propers [inaudible], ID de missatge, que és gran. Aquesta és la meva hash únic. Vaig a crear de dues GSI d'un per la meva safata d'entrada, un per la meva bústia de sortida. I el primer que faré és que em vaig a dir la meva clau hash és serà el receptor i Vaig a organitzar en la data. Això és fantàstic. Tinc la meva bonica vista aquí. Però hi ha un petit problema aquí. I arribes a tenir això en bases de dades relacionals, així. Van cridar a la partició vertical. Vostè vol mantenir les seves dades gran lluny de les seves poques dades. 

I la raó és perquè he de veu a llegir els articles per obtenir els atributs. I si els meus òrgans són tots aquí, després de llegir uns pocs articles si el meu longitud del cos és una mitjana de 256 kilobytes cadascun, les matemàtiques es posa molt lletja. Així que dic vull llegir la safata d'entrada de David. Safata d'entrada de David té 50 articles. La mitjana i la mida és de 256 kilobytes. Aquí està la meva relació de conversió per a la UCR de és quatre kilobytes. 

OK, anirem amb llegeix finalment consistent. Encara estic menjant 1600 RCU de només per llegir la safata d'entrada de David. Ouch. Bé, ara anem a pensar sobre com funciona l'aplicació. Si estic en una aplicació de correu electrònic i Estic buscant a la meva safata d'entrada, i miro el cos de cada missatge, no, jo estic mirant als resums. Estic mirant només les capçaleres. Així que anem a construir una estructura de taula que s'assembla més a això. 

Així que aquí està la informació que el meu flux de treball necessita. Està en la meva safata d'entrada de GSI. És la data, el remitent, el tema, i després l'ID de missatge, que apunta tornar a la taula de missatges on puc aconseguir el cos. Bé, aquests serien els ID de registre. Ells assenyalar de nou a la ID d'elements sobre la taula Dynamo DB. Cada índex sempre creates-- sempre té l'element ID com a part de-- que ve amb l'índex. 

Tot bé. AUDIÈNCIA: Es diu que on s'emmagatzema? RICK Houlihan: Sí, diu exactly-- això és exactament el que fa. Es diu que aquí està el meu disc re. I que va assenyalar de nou al meu disc re. Exactament. OK, així que ara la meva safata d'entrada és en realitat molt més petit. I això dóna suport realitat el flux de treball d'una aplicació de correu electrònic. Així que la meva safata d'entrada, faig clic. Que avanço i faig clic al missatge, això és quan he d'anar a buscar el cos, perquè jo vaig a anar a un punt de vista diferent. Així que si vostè pensa sobre el tipus de MVC marc, model vista controlador. 

El model conté la dades que les necessitats vista i el controlador interactua amb. Quan canvi la trama, al Puc canviar la perspectiva, que està bé per tornar a la servidor i repoblar el model, perquè això és el que espera l'usuari. Quan canvien punts de vista, que és quan podem tornar a la base de dades. Així de correu electrònic, feu clic a. Estic buscant el cos. Viatge d'anada i tornada. Aneu a buscar el cos. 

Llegeixo molt menys dades. Jo només estic llegint els cossos que David necessita quan les necessita. I no em cremo en 1600 UCR de simplement per mostrar la safata d'entrada. Així que ara que-- aquest és el camí que LSI o GSI-- ho sento, GSI, anava a sortir. Tenim la nostra haixix al destinatari. Tenim la clau de rang en la data. I tenim els atributs projectats que només hem de recolzar a la vista. 

Girem per que a la bústia de sortida. Hash en el remitent. I en essència, tenim la molt agradable, vista neta. I és que basically-- tenir aquest agradable missatges taula que està sent difós molt bé perquè és només haixix, ID de missatge hash. I tenim dos índexs que estan girant fora d'aquest quadre. Molt bé, així que la idea aquí no és fer mantenir els grans dades i aquesta petita dades junts. Partició vertical, particions les taules. No llegeixi les dades que vostè no ha de. Molt bé, els jocs. A tots ens agrada els jocs. Almenys m'agraden els jocs llavors. Així que algunes de les coses que ens ocupem quan estem pensant en el joc, no? Gaming aquests dies, especialment mòbil jocs, té a veure amb el pensament. I vaig a girar aquí mica lluny de DynamoDB. Vaig a portar Part de la discussió al voltant d'alguns dels altres tecnologies de AWS. 

Però la idea de joc és pensar sobre en termes d'API, API que són, en termes generals, HTTP i JSON. És la forma de jocs mòbils tipus de interactuar amb els seus extrems posteriors. Ho fan JSON publicació. S'obtenen les dades, i és tot, en termes generals, en les API JSON agradables. 

Coses com aconseguir amics, aconsegueixen les dades de la taula de posicions, de canvi, contingut generat per usuaris, fer retrocedir al sistema, aquests són els tipus de coses que farem. Dades actiu binari, aquestes dades podria no seure a la base de dades. Això podria seure en una magatzem d'objectes, oi? Però la base de dades es va a acabar dient al sistema, dient l'aplicació on anar a buscar-ho. I inevitablement, multijugador servidors, infraestructura back-end, i dissenyat per a alta disponibilitat i escalabilitat. Així que aquestes són les coses que tots volem en la infraestructura de joc avui. 

Així que donem una ullada a del que sembla. Va aconseguir un extrem posterior del nucli, molt senzill. Tenim un sistema d'aquí amb múltiples zones de disponibilitat. Parlem de AZS com being-- pensar d'ells com a centres de dades independents. Més d'un centre de dades per AZ, però això està bé, només pensar en ells com dades independent centres que estan geogràficament i es va aïllar decisió. 

Tindrem un casos parella EC2. Tindrem algun servidor back-end. Potser si vostè és un llegat arquitectura, estem utilitzant el que anomenem RDS, serveis de bases de dades relacionals. Podria ser MSSQL, MySQL, o alguna cosa per l'estil. Aquesta és la manera moltes de les aplicacions avui són dissenyats. 

Bé podríem desitjar anar amb això és quan escalem a terme. Seguirem endavant i posar el cub S3 fins allà. I aquest cub S3, en comptes de servir fins als objectes del nostre servers-- podríem fer això. Poses tota la teva binària objectes en els seus servidors i pot utilitzar els servidors casos per servir que les dades dalt. Però això és bastant car. 

Millor manera de fer-ho és seguir endavant i posar els objectes en una galleda de S3. S3 és una repositoris d'objectes. Està construït específicament per servint aquest tipus de coses. I que sol·liciten els clients directament des d'aquests cubs d'objecte, descarregar els servidors. Així que estem començant a escalar aquí. 

Ara que tenim els usuaris de tot el món. Tinc usuaris. Necessito tenir contingut localment situat a prop d'aquests usuaris, no? He creat una galleda S3 com el meu repositori de codi font. I vaig a cara que amb la distribució CloudFront. 

CloudFront és un CD i un xarxa de lliurament de contingut. Bàsicament es pren les dades que especifiqui i emmagatzema en memòria cau tot a internet perquè els usuaris de tot el món poden tenir una resposta molt ràpida quan sol·liciten aquests objectes. 

Perquè pugui obtenir una idea. Estàs tipus d'aprofitament de tot el aspectes de AWS aquí per fer això. I finalment, ens tirem en un grup d'escala automàtica. Així que els nostres casos AC2 dels nostres servidors de joc, quan comencen a aconseguir més concorregut i cada vegada més ocupat, ells només fan girar una altra exemple, girar una altra instància, girar una altra instància. Així que la tecnologia AWS té, és li permet especificar els paràmetres al voltant de la qual els servidors creixerà. Així que vostè pot tenir un nombre n de servidors per aquí en un moment donat. I si la càrrega es va, que va reduir la mida, el nombre es reduirà. I si la càrrega es torna, que tornarà a créixer cap a fora, elàsticament. 

Així que això es veu molt bé. Tenim una gran quantitat d'instàncies de EC2. Podem posar en memòria cau davant de les bases de dades, tractar d'accelerar les bases de dades. El següent punt de pressió normalment la gent veu és que l'escala d'un joc utilitzant un sistema de base de dades relacional. Per Déu, la base de dades rendiment és terrible. Com podem millorar això? Anem a tractar de posar cau davant d'això. 

Bé, cau no funciona tan gran en els jocs, oi? Pels jocs, l'escriptura és dolorós. Els jocs són molt escriuen pesat. Memòria cau no funciona quan estàs escriure pesada perquè tens sempre ha de refrescar la cau. Actualitza la memòria cau, és irrellevant per ser l'emmagatzematge en memòria cau. En realitat és només una feina extra. 

Llavors, on anem aquí? Tens un gran coll d'ampolla allà a la base de dades. I el lloc per anar òbviament està particionat. La partició no és fàcil de fer quan estàs es tracta de bases de dades relacionals. Amb les bases de dades relacionals, ets responsable de la gestió, de manera efectiva, l'espai de claus. Estàs dient que els usuaris entre A i M anar aquí, entre N i Z van allà. I vostè està canviant a través de l'aplicació. Així que vostè està tractant amb aquesta font de dades de la partició. Vostè té limitacions transaccionals que no abasten les particions. Tens tota mena de desordre que ets es tracta d'allà baix tractant per fer front a escalar i la construcció d'una infraestructura més gran. És simplement no és divertit. 

AUDIÈNCIA: Llavors, estàs dient que augmentant els punts d'origen accelera el procés de? RICK Houlihan: L'augment? Punts Font: AUDIÈNCIA. RICK Houlihan: punts d'origen? AUDIÈNCIA: A partir de la informació, on la informació està venint? RICK Houlihan: No. El que estic dient és l'augment de la nombre de particions al magatzem de dades millora el rendiment. Llavors, què està passant aquí és que els usuaris que entra a la instància EC2 aquí, així, si necessito un usuari aquesta és la A a la M, aniré aquí. Des N fins p, aniré aquí. Des de P fins Z, aniré aquí. 

AUDIÈNCIA: OK, així que aquests són els tots els emmagatzemats en diferents nodes? 

RICK Houlihan: Sí. Penseu en això com diferents sitges de dades. Així que has de fer això. Si vostè està tractant de fer això, si vostè està tractant a escala en una plataforma relacional, això és el que estàs fent. Vostè està prenent les dades i que està a tallar-lo. I vostè està a l'altre costat de la partició diverses instàncies de la base de dades. I va administrar tot el que en el nivell d'aplicació. No és divertit. Llavors, què és el que volem anar? Volem anar DynamoDB, va aconseguir plenament, Magatzem de dades NoSQL, rendiment disposició. Utilitzem índexs secundaris. Es tracta bàsicament d'HTTP API i inclou suport de documents. Així que vostè no ha de preocupar res d'això partició. Ho fem tot per vostè. Així que ara, en canvi, simplement escriure a la taula. Si la taula ha de ser dividit, això succeeix darrere de les escenes. Vostè està completament aïllat que com a desenvolupador. Així que anem a parlar de alguns dels casos d'ús que ens trobem en els jocs, comuna escenaris de joc, taula de classificació. Així que tens als usuaris a arribar, els BoardNames que són des d'ara, les qualificacions d'aquest usuari. Podríem estar hash en la identificació d'usuari, i després tenim varietat en el joc. Així que cada usuari vol veure tot el joc que ha jugat i tota la seva puntuació més alta a través de tot el joc. Així que aquest és el seu classificació personal. 

Ara vull anar i vull get-- de manera que obtenir aquestes taules de classificació personals. El que vull fer és anar a buscar la puntuació més alta entre tots els usuaris. Llavors, com ho faig? Quan es hash en el meu disc la ID d'usuari, va oscil·lar en el joc, així que seguiré endavant i reestructurar, crear un GSI, i jo vaig a reestructurar aquestes dades. 

Ara em vaig per discutir sobre la BoardName, que és el joc. I jo vaig a anar a la puntuació més alta. I ara que he creat diferents cubs. Estic usant la mateixa taula, les mateixes dades de l'element. Però estic creant una galleda que dóna em una agregació de puntuació màxima per joc. 

I puc consultar aquesta taula per obtenir aquesta informació. Així que m'he fixat que el patró de consulta fins amb el suport d'un índex secundari. Ara poden ordenar-se per BoardName i ordenats per topscore, depenent. Així es pot veure, es tracta de tipus dels casos d'ús que obté en els videojocs. Un altre bon cas d'ús que obtenim en els jocs és premis i que ha guanyat els premis. I aquest és un gran cas d'ús on ens diem índexs dispersos. Escassos són els índexs capacitat de generar un índex que no necessàriament contenir cada article sobre la taula. I per què no? A causa de que l'atribut que està sent indexada no existeix en cada article. 

Així que en aquest particular, cas d'ús, el que estic dient, Saps què, vaig a crear un atribut anomenat Premi. I jo vaig a donar a cada usuari que té un premi que atribueixen. Els usuaris que no tenen premis són No va tenir aquest atribut. Així que quan va crear el índex, els únics usuaris que es van a mostrar en l'índex són els que realment han guanyat premis. Així que això és una gran manera de poder per crear índexs filtrats que són molt, molt selectiu que no ho fan que índex de tota la taula. 

Així que ens estem sota el temps aquí. Vaig a seguir endavant i saltar i ometre aquest escenari. Parli una mica sobre-- 

AUDIÈNCIA: Puc fer una pregunta ràpida? Un és escriure pesat? RICK Houlihan: Què és? AUDIÈNCIA: Escrigui pesat. RICK Houlihan: Escriure pesat. Deixa'm veure. 

AUDIÈNCIA: O és que no una cosa que vostè pot simplement veu a en qüestió de segons? RICK Houlihan: Anem a través de l'escenari electoral. No és tan dolent. Vostès tenen un parell de minuts? D'ACORD. 

Així que anem a parlar sobre la votació. Així que la votació en temps real, tenim requisits per a votar. Els requisits són que permetem cada persona a votar només una vegada. Volem que ningú sigui capaç canviar el seu vot. Volem que l'agregació en temps real i l'anàlisi de dades demogràfiques que nosaltres serem mostrant als usuaris en el lloc. 

Penseu en aquest escenari. Treballem molt de la realitat Programes de televisió on estan fent aquest tipus exacte de les coses. Així que vostè pot pensar en l'escenari, tenim milions i milions nenes d'adolescents allà amb els seus telèfons mòbils i el vot, i la votació, i votar per qualsevol que siguin trobar a ser el més popular. Així que aquests són alguns dels requisits que s'esgotin. 

I així, la primera presa en la solució d'aquest problema seria la de construir un aplicació molt simple. Així que tinc aquesta aplicació. Tinc alguns votants que hi ha. Vénen en, que arribin a l'aplicació de la votació. Tinc una mica de taula qualifiquen prima Només vaig a bolcar aquests vots en. Vaig a tenir algun agregat taula de vots que Faré la meva anàlisi i les dades demogràfiques, i posarem tot això en aquest país. 

I això és molt bo. La vida és bona. De bona fins que ens adonem que la vida sempre hi ha un o dos les persones que són populars en una elecció. Hi ha només una o dues coses que la gent realment es preocupen. I si vostè està votant en escala, de sobte estic va a estar colpejant a la merda de dos candidats, un o dos candidats. Un nombre molt limitat d'articles persones troben per ser popular. 

Aquest no és un bon patró de disseny. Això és realment una patró de disseny molt dolent perquè crea exactament el que va parlar que era tecles d'accés ràpid. Tecles d'accés són una cosa que no ens agrada. 

Llavors, com solucionar-ho? I realment, la forma de fer això és mitjançant l'adopció d'aquests cubs candidats i per a cada candidat que tenim, anem a afegir un valor aleatori, una cosa que sabem, a l'atzar valor entre un i 100, entre 100 i 1.000, o entre un i 1.000, No obstant això molts valors aleatoris que volen annexar a l'extrem d'aquest candidat. 

I què he fet realment llavors? Si estic fent servir la identificació de candidat el cub als vots totals, si he afegit un atzar nombre al final d'això, He creat ara 10 galledes, un cent cubs, mil cubs que estic agregant qualifiquen d'ample. 

Així que tinc milions i milions, i milions de registres procedents de per a aquests candidats, ara estic difonent aquests vots en tot A_1 Candidat a través A_100 Candidat, perquè cada vegada que un vot entra, Estic generant un atzar valor entre un i 100. Estic virades sobre l'extrem de la candidat a aquesta persona de votar a favor. Estic de dúmping en aquest cub. 

Ara a la part posterior, ho sé que em van donar cent cubs. Així que quan em vull anar per davant i afegir els vots, He llegit de tots els cubs. Així que segueixo endavant i afegir. I llavors jo recullo la dispersió on surto i dic bé, vostè sap el que, la clau d'aquest candidat espais és més de cent cubs. Vaig a reunir tota la els vots dels cent cubs. Vaig a afegir ells i vaig a dir, Candidat A té ara recompte total de vots de x. 

Ara tant l'escriptura consulta i la consulta de lectura estan molt ben distribuïda perquè jo estic escrivint un altre costat i jo estic llegint a través de centenars de claus. No estic escrivint i la lectura a través d'una clau ara. Així que això és un gran model. 

Això és en realitat probablement un del disseny més important les pautes d'escala en NoSQL. Vostè veurà aquest tipus de patró de disseny de tots els sabors. MongoDB, DynamoDB, no ho fa importa, tots hem de fer això. Perquè quan es tracta amb aquests enormes agregacions, vostè ha de trobar una manera de escamparan per tot galledes. Així que aquesta és la forma de fer això. Molt bé, així que el que que estàs fent en aquest moment és el que està operant fora de lectura cost per escriure escalabilitat. El cost de la meva lectura és una mica més complex i he d'anar a llegir a partir d'un cent cubs en lloc d'un. Però sóc capaç d'escriure. I el meu rendiment, la meva escriptura rendiment és increïble. Així que és en general una valuosa tècnica per escalar DynamoDB, o qualsevol base de dades NoSQL per al cas. Llavors ens vam adonar de com escalar ella. I ens vam adonar de com eliminar les claus calents. I això és fantàstic. I tenim aquest bonic sistema. I ens ha donat de votació molt correcte perquè tenim registre de vot de-dupe. Està construït en DynamoDB. Parlem dels drets condicionals. 

Quan un votant entra, posa una inserció a la taula, s'insereixen amb la seva credencial d'elector, si tracten d'inserir una altra votació, Faig una escriptura condicional. Diguem només escriure aquest si això no existeix. Així que tan aviat com veig que que el vot de colpejar la taula, ningú més serà capaç de posar el seu vot en. I això és fantàstic. I estem incrementant els nostres comptadors de candidats. I estem fent el nostre demografia i tot això. Però què passa si el meu aplicació es cau? Ara, de sobte vots estan entrant, i jo no saben si estan rebent processats en les meves anàlisis i demografia més. I quan l'aplicació torna, com diables vaig a saber el que qualifiquen tenen estat processat i per on començo? 

Així que aquest és un problema real quan començar a mirar aquest tipus d'escenari. ¿I com es resol això? Resolem amb el que cridar DynamoDB Rierols. Corrents s'ordena la vegada i registre de canvis particions de cada accés a taula, cada escriptura l'accés a la taula. Totes les dades que s'escriuen en el taula apareix en la seqüència. 

Es tracta bàsicament d'una cua de 24 hores. Els productes que arribin al rierol, viuen durant 24 hores. Es poden llegir diverses vegades. Garantit per ser lliurats només una vegada a la corrent, es podia llegir un nombre n de vegades. Així que no obstant això molts processos que vols consumir aquestes dades, es pot consumir. Apareixerà cada actualització. Cada escriptura només es aparèixer una vegada en la seqüència. Així que vostè no ha de preocupar sobre el processament de dues vegades De la mateixa procés. 

Està estrictament ordenat per article. Quan diem que el temps ordenat i es va repartir, veuràs per partició en la seqüència. Veurà articles, actualitzacions en ordre. No estem garantint sobre el rierol que ets posarà cada transacció en l'ordre a través d'articles. 

Així rierols són idempotent. Tenim tots sabem el idempotent significa? Idempotent vol dir que vostè pot fer-ho una altra vegada, i una altra, i una altra. El resultat va ser el mateix. 

Streams són idempotent, però han de ser jugat des del punt de partida, on sigui que triï, fins al final, o que no es traduirà en els mateixos valors. 

El mateix amb MongoDB. MongoDB té una construcció que ells anomenen el oplog. És la mateixa construcció exacta. Moltes bases de dades NoSQL tenir aquest constructe. El fan servir per fer les coses com la replicació, que és exactament el que fem amb els corrents. AUDIÈNCIA: Potser una pregunta herètica, però parlar d'aplicacions fent de sòl així successivament. Són corrents garantits per Mai possiblement baixar? RICK Houlihan: Sí, rierols estan garantits per no baixar. Gestionem la infraestructura darrere. rierols automàticament implementar en el seu grup d'escala automàtica. Anem a anar a través d'una petita poc sobre el que succeeix. 

No hauria de dir que no són garantit per no baixar. Els elements estan garantits a aparèixer en el corrent. I el corrent serà accessible. Llavors, què cau o es torna dalt, això passa per sota. Es Cobertes està bé. Molt bé, de manera que obtenir diferents tipus de vista de la pantalla. Els tipus de vista que són importants per a un programador normalment són, què era? Tinc la vella visió. Quan una actualització colpeja la taula, que va empènyer l'antiga visió del corrent el que les dades es poden arxivar o canvi control, identificació canvi, canvi gestió. 

La nova imatge, el que és ara, després de l'actualització, que és un altre tipus de vista vostè pot aconseguir. Vostè pot obtenir tant les velles i noves imatges. Potser els dos vulgui. Vull veure el que era. Vull veure el que ha canviat a. 

Tinc un tipus de compliment del procés que s'executa. Ha de verificar que Quan aquestes coses canvien, que estan dins de certs límits o dins de certs paràmetres. 

I llavors potser només necessitat de saber el que ha canviat. No m'importa el que el tema va canviar. No necessito a necessitar saber ho atribueix canviat. Només necessito saber que els articles estan sent tocats. Així que aquests són els tipus de vistes que es baixi el corrent i es pot interactuar. 

L'aplicació que consumeix el corrent, això és una espècie de la forma en que funciona. Client DynamoDB demani enviar dades a les taules. Streams desplegar en el que anomenem fragments. Fragments s'escalen independentment de la taula. Ells no s'alineen completament a les particions de la taula. I la raó per la qual és perquè s'alineen a la capacitat, el corrent la capacitat de la taula. 

Es despleguen en el seu propi grup d'escalat automàtic, i comencen a girar a terme en funció de la quantitat d'escriptures estan entrant, quants reads-- realitat és escriu. No hi ha reads-- sinó com moltes escriptures estan arribant. 

I després a la part posterior fi, tenim el que trucar a un KCL o Kinesis Client Library. Kinesis és un flux de dades tecnologia de processament d'Amazon. I rierols es construeix en això. 

Així s'utilitza un KCL habilitat aplicació llegir el corrent. La biblioteca de clients Kinesis realitat gestiona els treballadors per a vostè. I també fa alguns coses interessants. Es crearà algunes taules fins en el seu espai de taula DynamoDB per rastrejar quins articles han estat processats. Així d'aquesta manera si es cau de nou, si cau una i ve i es posa es va posar dret, es pot determinar on era que en la tramitació del corrent. 

Això és molt important quan vostè està parlant de replicació. Necessito saber el les dades s'ha processat i el que les dades encara no s'ha processat. Així que la biblioteca KCL per als fluxos voluntat li donarà una gran quantitat d'aquesta funcionalitat. S'ocupa de tot el servei de neteja. Es posa dret a un treballador per cada fragment. Es crea una taula administrativa per a cada fragment, per cada treballador. I a mesura que els treballadors d'incendis, mantenen aquestes taules perquè sàpiga aquest registre va ser llegida i processada. I després d'aquesta manera si el procés mor i ve de nou en línia, pot reprendre just on va desenganxar. 

Així que fem servir això per replicació creuada regió. Molts clients tenen la necessitat de moure dades o parts de les seves taules de dades voltant de les diferents regions. Hi ha nou regions al voltant del món. Així que podria haver-hi un jo need-- podria tenir els usuaris a Àsia, els usuaris a la costa est dels Estats Units. Tenen diferents dades que necessita ser distribuït localment. I potser un usuari vola des Àsia als Estats Units, i vull replicar les seves dades amb ell. Així que quan ell es baixa de l'avió, que té una bona experiència en l'ús de la seva aplicació mòbil. 

Podeu utilitzar la regió creu biblioteca de replicació per fer això. Bàsicament tenim proporcionat dues tecnologies. Un és una aplicació de consola que pugui posar-se dret a la seva pròpia instància EC2. S'executa la replicació pur. I després us vam donar la biblioteca. La biblioteca es pot utilitzar per construir seva pròpia aplicació si voler fer coses boges amb aquest data-- filtre, replicar només part d'ella, rotar les dades, moure en un diferent de taula, així successivament i així successivament. Així que això és una cosa del que sembla. 

DynamoDB Streams pot haver processat pel que anomenem Lambda. Hem esmentat una mica sobre esdeveniments arquitectures d'aplicacions accionades. Lambda és un component clau d'això. Lambda és el codi que dispara la demanda en resposta a un esdeveniment en particular. Un d'aquests esdeveniments podria ser una registre que apareix en la seqüència. Si un registre apareix a la corrent, anem a cridar aquesta funció Java. Bé, aquest és JavaScript i Lambda dóna suport NODE.JS, Java, Python, i aviat donar suport altres idiomes també. I n'hi ha prou amb dir, és de codi pur. escriure En Java, es defineix una classe. Vostè prem el JAR dalt a Lambda. I a continuació, s'especifica quina classe trucar en resposta a quin esdeveniment. I llavors la infraestructura Lambda darrere que s'executarà aquest codi. 

Aquest codi pot processar registres fora del corrent. Pot fer el que vulgui amb ell. En aquest exemple en particular, tots estem realment fent és registrar els atributs. Però això és només codi. El codi pot fer qualsevol cosa, oi? 

Així que vostè pot girar aquestes dades. Podeu obtenir una vista derivada. Si es tracta d'una estructura de document, vostè pot aplanar l'estructura. Podeu crear índexs alternatius. Tots els tipus de coses que vostè pot veure amb els corrents DynamoDB. 

I realment, això és el que sembla. Perquè pugui obtenir aquestes actualitzacions entrant. Estan sortint de la cadena. Són llegits per la funció de Lambda. Estan girant les dades i empenyent-la cap amunt en les taules derivades, notificar a sistemes externs de canvi, i empenyent dades en ElastiCache. 

Parlem de com posar la memòria cau al davant de la base de dades perquè les vendes escenari. Bé, què passa si actualitzar la descripció de l'article? Bé, si jo tingués un Lambda funció que s'executa en aquesta taula, si actualitzo la descripció de l'article, que va recollir el registre del corrent, i que va a actualitzar el ElastiCache instància amb les noves dades. Així que això és una gran quantitat de el que fem amb Lambda. És codi cola, connectors. I el que realment dóna la capacitat de llançar i per executar aplicacions molt complexes sense un servidor dedicat infraestructura, que és realment genial. 

Així que anem a tornar al nostre en temps real l'arquitectura de votació. Això és nou i millorat amb el nostre rierols i KCL habilitat aplicació. Igual que abans, podem gestionar qualsevol escala de les eleccions. Ens agrada això. Estem fent fora frunzits de dispersió a través de múltiples cubs. Tenim bloqueig optimista passant. Podem mantenir els nostres votants canviïn els seus vots. Només poden votar només una vegada. Això és fantàstic. Tolerància a fallades en temps real, agregació escalable ara. Si la cosa es cau, es sap on per reiniciar en si quan es tracta d'una còpia de seguretat, ja estem fent servir l'aplicació KCL. I llavors també podem usar aquesta Aplicació KCL per empènyer dades fora al desplaçament al vermell per a altres anàlisi d'aplicacions, o l'ús MapReduce els elàstics per executar agregacions de streaming en temps real fos d'aquestes dades. 

Així que aquestes són les coses que nosaltres no han parlat molt. Però són addicionals tecnologies que vénen tenir quan estàs buscant en aquests tipus d'escenaris. 

Molt bé, així que això és tot anàlisi amb DynamoDB Rierols. Vostè pot obtenir de-dupe dades, fer tot tipus de coses boniques, les dades agregades en memòria, crear aquestes taules derivades. Això és un cas d'ús enorme que molts dels clients estan involucrats amb, prenent el niada propietats dels documents JSON i la creació d'índexs addicionals. 

Som al final. Gràcies per la seva paciència amb mi. Així que anem a parlar de arquitectura de referència. DynamoDB es troba enmig del gran part de la infraestructura de AWS. Bàsicament, vostè pot connectar fins al que vulguis. Les aplicacions creades usant Dynamo inclou Lambda, ElastiCache, CloudSearch, empènyer les dades cap elàstic MapReduce, importació i exportació de DynamoDB en S3, tots els tipus de fluxos de treball. Però probablement la millor cosa que parlar, i això és el que és realment interessant és quan parlar d'aplicacions per esdeveniments. 

Aquest és un exemple de un projecte intern que tenim quan estem en realitat publicació per recollir resultats de l'enquesta. Així que en un enllaç de correu electrònic que que vam enviar, hi haurà ser una mica clic enllaç que diu aquí per respondre a l'enquesta. I quan una persona fa clic aquest vincle, el que passa és que tiri avall d'una assegurança HTML formulari d'enquesta de S3. No hi ha servidor. Això és només un objecte S3. 

Aquesta forma apareix, càrrega en el navegador. Té Backbone. Té complex JavaScript que s'està executant. Així que és d'aplicació molt rica s'executa en el navegador del client. Ells no saben que no ho són interactuar amb un servidor back-end. En aquest punt, és tot navegador. 

Publiquen els resultats al cridem a l'API d'Amazon Gateway. API Gateway és simplement una API web que es pot definir i connectar al que vulguis. En aquest cas particular, estem connectat a una funció lambda. 

Així que la meva operació POST és passant amb cap servidor. Bàsicament aquesta porta d'enllaç API s'asseu allà. Em costa res fins que la gent comença a publicar a ella, no? La funció de Lambda només se senti allà. I em costa res fins la gent comença a colpejar-lo. Així es pot veure, ja que el volum augmenta, aquí és quan les acusacions vénen. No estic corrent un servidor 24.7. 

Així que em tiri de la forma baixar de la galleda, i he posat a través de l'API Porta d'entrada a la funció de Lambda. I llavors el Lambda funció diu, ja saps la qual cosa, tinc alguns PII, alguns informació d'identificació personal en aquestes respostes. Vaig aconseguir comentaris procedents dels usuaris. Tinc adreces de correu electrònic. Tinc els noms d'usuari. 

Déjame dividir això. Vaig a generar una mica de metadades fora d'aquest registre. I vaig a empènyer el metadades en DynamoDB. I podria xifrar totes les dades i poseu-lo a DynamoDB si vull. Però és més fàcil per a mi, en aquest utilitzi cas, perquè endavant un exemple, Vaig a empènyer les dades en brut en una galleda de S3 xifrat. Així que utilitzar construït a la banda del servidor S3 encriptació i gestió de claus d'Amazon Servei de manera que tinc una clau que pot girar en un interval regular, i puc protegir les dades PII com a part de tot aquest flux de treball. 

Llavors, què he fet? Acabo desplegat en el seu conjunt aplicació, i no tinc cap servidor. Així que és el que de successos d'aplicació impulsada arquitectura fa per vostè. 

Ara bé, si es pensa en el cas d'ús de esto-- tenim altres clients que estic parlant al voltant d'aquesta arquitectura exacta que executar fenomenalment grans campanyes, que estan mirant això i va, oh el meu. Perquè ara, que poden bàsicament empènyer fora d'allà, deixar que la campanya simplement seure allà fins que llança, i no has de preocupar un rave quin tipus d'infraestructura va a ser-hi per donar-li suport. I llavors tan aviat com que la campanya es porta a terme, és com la infraestructura acaba immediatament desapareix perquè realment hi ha infraestructura. És codi només que seu a Lambda. És només que les dades es troba a DynamoDB. És una manera increïble per crear aplicacions. 

AUDIÈNCIA: Llavors, és més efímer del que seria si s'emmagatzema en un servidor real? 

RICK Houlihan: Per descomptat. Perquè aquesta instància de servidor hauria de ser un 7/24. Ha d'estar disponible per algú per respondre a. Bé endevinin què? S3 està disponible 7/24. S3 sempre respon. I S3 és molt, molt bo a servir els objectes. Aquests objectes poden ser arxius HTML, o Arxius JavaScript, o el que vulguis. Podeu executar aplicacions web molt rics de cubs S3, i la gent fa. 

I així, aquesta és la idea aquí és allunyar-se de la forma solíem pensar-hi. A tots ens acostumem a pensar en termes de servidors i els tècnics. No es tracta d'això. Es tracta de la infraestructura com a codi. Implementar el codi per al núvol i deixeu que el núvol dirigit per vostè. I això és el AWS està tractant de fer. 

AUDIÈNCIA: Així que la seva caixa d'or en el medi de la porta d'enllaç API no és com al servidor, però en canvi és sol-- 

RICK Houlihan: Vostè pot pensar això com a façana servidor. Tot el que és és que va a prendre un HTTP sol·licitar i assignar a un altre procés. Això és tot el que fa. I en aquest cas, estem cartografia a una funció Lambda. Molt bé, així que això és tot el que tinc. Moltes gràcies. T'ho agraeixo. Sé que volem una mica més de temps. I espero que vostès ja ha rebut una mica d'informació que es pot portar a l'actualitat. I demano disculpes si em vaig anar sobre alguns dels seus caps, però hi ha una bona quantitat de coneixements bàsics fonamentals que crec que és molt valuós per a vostè. Així que gràcies per convidar-me. [Aplaudiments] AUDIÈNCIA: [inaudible] és quan vostè deia que havia d'anar a través de la cosa des del principi fins al final per obtenir els valors correctes o els mateixos valors, Com els valors canviar si [inaudible]. 

RICK Houlihan: Oh, idempotent? Com canviarien els valors? Bé, perquè si jo no corro tot el camí fins al final, llavors jo no sé el que canvia es van fer en l'última milla. No serà el mateixes dades que el que vaig veure. AUDIÈNCIA: Oh, de manera que només no han aconseguit l'entrada completa. RICK Houlihan: Correcte. Has d'anar des del principi a fi, i llavors és serà un estat coherent. Fresc. 

AUDIÈNCIA: ¿Així que ens heu mostrat DynamoDB pot fer de documents o el valor de la clau. I ens vam passar un munt de temps en el valor de la clau amb un hash i les formes per donar-li la volta al voltant. Quan es mirava en aquestes taules, és que deixant enrere l'enfocament document? 

RICK Houlihan: Jo no ho faria dir deixant enrere. 

AUDIÈNCIA: Ells van ser separats d'ell-- 

RICK Houlihan: Amb el document enfocament, el tipus de document en DynamoDB és només pensar en com un altre atribut. És un atribut que conté una estructura de dades jeràrquica. I després, a les consultes, pot utilitzar les propietats d'aquests objectes utilitzant notació d'objectes. Així que pot filtrar en una imbricada propietat del document JSON. AUDIÈNCIA: Així que cada vegada que fer un enfocament document, Puc espècie d'arribar a la tabular-- AUDIÈNCIA: Absolutament. Audiència: --indexes i coses que acabem de parlar. RICK Houlihan: Sí, la índexs i tot això, quan es vol indexar el propietats de la JSON, la forma en què ens agradaria haver de fer això és si insereix un objecte JSON o un document en Dynamo, utilitzaria els rierols. Streams llegirien l'entrada. Vostè aconseguiria que JSON objecte i que anaves a dir OK, ¿Quina és la propietat que vull índex? 

Es crea una taula derivada. Ara aquesta és la forma en què funciona ara. Nosaltres no permetem a l'índex directament aquestes propietats. 

AUDIÈNCIA: Tabularizing seus documents. 

RICK Houlihan: Exactament, aplanant que, tabularizing, exactament. Això és el que fas amb ell. 

AUDIÈNCIA: Gràcies. 

RICK Houlihan: Sí, absolutament, gràcies. AUDIÈNCIA: Així que és una espècie de Mongo compleix classifers Redis. 

RICK Houlihan: Sí, que és molt semblant a això. Aquesta és una bona descripció de la mateixa. Fresc.