>> [Muziek]
RICK Houlihan: Oké.
Hallo iedereen.
Mijn naam is Rick Houlihan.
Ik ben een senior principal oplossingen architect bij AWS.
Ik mij richten op NoSQL en DynamoDB technologieën.
Ik ben hier vandaag om te praten je een beetje over die.
>> Mijn achtergrond is vooral in datalaag.
Ik heb de helft van mijn ontwikkeling carrière schrijven databank
toegang tot de gegevens, oplossingen voor diverse toepassingen.
Ik heb in Cloud virtualisatie geweest ongeveer 20 jaar.
Dus voordat de Cloud was de Cloud, We noemden het utility computing.
En het idee was, het is net als PG & E, je betaalt voor wat je gebruikt.
Vandaag noemen we het de cloud.
>> Maar in de loop der jaren heb ik gewerkt voor een paar bedrijven
heb je waarschijnlijk nog nooit van gehoord.
Maar ik heb een lijst van technische samengesteld prestaties, ik denk dat je zou zeggen.
Ik heb acht octrooien in Cloud systemen virtualisatie, microprocessor ontwerp,
complex event processing, en andere gebieden.
>> Dus deze dagen, richt ik me vooral op NoSQL technologieën en de volgende generatie
database.
En dat is over het algemeen wat ik ga om hier te zijn met je te praten vandaag over.
Dus wat u kunt verwachten van deze sessie,
we gaan door middel van een kort geschiedenis van gegevensverwerking.
Het is altijd nuttig om begrijpen waar we vandaan komen
en waarom we zijn waar we zijn.
En we zullen een beetje praten beetje over NoSQL-technologie
vanuit fundamenteel oogpunt.
>> We krijgen in een aantal van de DynamoDB binnenwerk.
DynamoDB is AWS is geen smaak.
Het is een volledig beheerde en gehoste NoSQL oplossing.
En we zullen een klein beetje over tafel praten structuur, API's, data types, indexen,
en sommige internals DynamoDB van die technologie.
We krijgen in een aantal van het ontwerp patronen en best practices.
We zullen praten over hoe je Gebruik van deze technologie voor sommige
toepassingen van vandaag.
En dan zullen we een beetje praten over de evolutie en de opkomst
van een nieuw paradigma in de programmering zogenaamde event-driven applicaties
en hoe DynamoDB speelt dat ook.
En wij sturen u een klein beetje een referentie-architectuur discussie
zodat we kunnen praten over een aantal van de manieren waarop je kunt DynamoDB gebruiken.
>> Dus eerst off-- dit is een vraag Ik hoor veel is, wat is een database.
Veel mensen denken dat ze weet wat een database is.
Als u Google, zult u dit zien.
Het is een gestructureerd geheel van gegevens waarover in een computer, vooral een die
is bereikbaar op verschillende manieren.
Ik veronderstel dat is een goede definitie van moderne database.
Maar ik vind het niet leuk, omdat het impliceert een paar dingen.
Het impliceert structuur.
En het betekent dat het op een computer.
En databases niet Er bestaan ​​altijd op computers.
Databases daadwerkelijk op vele manieren bestaan.
>> Dus een betere definitie van een database is zoiets als dit.
Een database is een georganiseerde mechanisme voor het opslaan, beheren,
en ophalen van informatie.
Dit is van About.com.
Dus ik vind dit omdat het echt gesprekken over een database die een repository,
een opslagplaats van informatie niet noodzakelijkerwijs
iets dat zit op een computer.
En door de geschiedenis heen, we niet altijd computers.
>> Nu, als ik vraag de gemiddelde ontwikkelaar vandaag wat is
een database, dat is het antwoord dat ik krijg.
Ergens kan ik dingen vasthouden.
Rechts?
En het is waar.
Maar het is jammer.
Omdat de database werkelijk het fundament van de moderne app.
Het is de stichting van elke toepassing.
En hoe je dat bouwen databank, hoe je de structuur
die gegevens gaat dicteren hoe dat applicatie presteert zoals u schalen.
>> Dus veel van mijn werk vandaag houdt zich bezig met wat
gebeurt wanneer ontwikkelaars nemen deze aanpak
en het omgaan met de nasleep van een toepassing die
nu schalen dan de oorspronkelijke intentie en het lijden van slecht ontwerp.
Dus hopelijk wanneer je lopen vandaag weg, zult u
hebben een paar van de gereedschappen in je riem die je houden
van het maken van die dezelfde fouten.
Prima.
Dus laten we praten over een beetje de tijdlijn van databasetechnologie.
Ik denk dat ik las een artikel niet zo lang geleden
en het zei iets over de lines-- het is een zeer poëtisch statement.
Het zei de geschiedenis van de gegevensverwerking is
vol van hoge watermerken data overvloed.
OK.
Nu, ik denk dat dat soort waar.
Maar ik eigenlijk kijken is als de geschiedenis is eigenlijk gevuld
met een high watermark van data druk.
Omdat de datasnelheid van inname gaat nooit naar beneden.
Alleen gaat omhoog.
>> En innovatie ontstaat wanneer zien we data druk, die
is de hoeveelheid gegevens die Nu in die in het systeem.
En het kan niet worden verwerkt efficiënt in tijd of in de kosten.
En dat is wanneer we beginnen om te kijken naar de gegevens druk.
>> Dus als we kijken naar de eerste gegevensbank, dit
is degene die was tussen onze oren.
We zijn allemaal geboren.
Het is een mooie database.
Het heeft een hoge beschikbaarheid.
Het is altijd aan.
U kunt altijd krijgen.
>> Maar het is één gebruiker.
Ik kan niet delen mijn gedachten met u.
Je kunt niet mijn gedachten te krijgen als je wilt dat ze.
En hun abilitiy is niet zo goed.
We vergeten dingen.
Zo nu en dan, een van ons bladeren en verhuist naar een ander bestaan
en we alles kwijt die in de databank.
Dus dat is niet zo goed.
>> En dat werkte goed in de tijd toen we terug in de dag
wanneer alles wat we echt nodig om te weten is waar gaan we heen te gaan op morgen
of waar we verzamelen van de beste voedsel.
Maar zoals we begonnen te groeien als een beschaving en de overheid begonnen
tot stand te komen, en bedrijven begonnen te evolueren,
we begonnen te beseffen dat we hebben een beetje meer dan
konden we in ons hoofd zetten.
Prima?
>> We hadden behoefte aan systemen van het record.
We moesten plaatsen om te kunnen slaan gegevens.
Dus we begonnen met het schrijven van documenten, het creëren van bibliotheken en archieven.
We zijn begonnen met het ontwikkelen van een systeem een ​​grootboek boekhouding.
En dat het systeem van grootboek tellen liep de hele wereld voor vele eeuwen,
en misschien zelfs millennia als we soort groeide uit tot het punt
wanneer die gegevens belasting overtroffen het vermogen van deze systemen
in staat om het te bevatten.
>> En dit werkelijk is gebeurd in de jaren 1880.
Rechts?
In de 1880 US Census.
Dit is echt wanneer het draaien wijzen moderne gegevensverwerking.
Dit is het punt waarbij de hoeveelheid data
dat werd verzameld door de Amerikaanse regering kwam tot het punt
wanneer duurde acht jaar te verwerken.
>> Nu, acht years-- als je weet wel, de volkstelling
rijdt elke 10 years-- dus het is vrij duidelijk dat we door de tijd
kreeg de volkstelling van 1890, de hoeveelheid gegevens die
zou worden verwerkt door de overheid was
naar de 10 jaar overschrijdt dat zou nemen om lanceerde de nieuwe telling.
Dit was een probleem.
>> Dus een man genaamd Herman Hollerith kwam langs
en hij bedacht eenheid plaat punch kaarten, punch kaartlezer, ponskaart
tabulator, en de verzameling van de mechanismen voor deze technologie.
En dat bedrijf dat hij in de gevormde tijd, samen met een aantal anderen,
eigenlijk werd een van de pijlers van een klein bedrijf dat we vandaag kennen genaamd IBM.
>> Dus IBM oorspronkelijk was de database business.
En dat is echt wat ze deden.
Zij deden gegevensverwerking.
>> Zoals zo de proliferatie van punch kaarten, een ingenieus mechanisme
van de mogelijkheid om gebruik te maken dat technologie om gesorteerde resultaat sets pollen.
U kunt zien op deze foto daar hebben we een little--
het is een beetje small-- maar je kunt zien een zeer ingenieus mechanisch mechanisme
waar we een ponskaart dek.
En het nemen van iemands een kleine schroevendraaier
en steken door de slots en tillen
om die wedstrijd te krijgen, dat gesorteerd resultatenset.
>> Dit is een aggregatie.
We doen dit de hele tijd vandaag in de computer,
waar je het doen in de database.
We gebruikt om handmatig te doen, toch?
Mensen zetten deze dingen samen.
En het was de proliferatie van deze ponskaarten
in wat we genaamd data drums en data-rollen, papier tape.
>> De gegevens verwerkende industrie nam een les van de speler piano's.
Pianola's terug op het begin van de eeuw
gebruikt voor papierrollen met slots op om het te vertellen welke toetsen om te spelen.
Zodat technologie aangepast uiteindelijk digitale gegevens,
omdat ze die gegevens kon zetten op die papieren band rollen.
>> Nu, als gevolg, data werd actually-- hoe
u toegang tot deze gegevens was direct afhankelijk van hoe je het opgeslagen.
Dus als ik de gegevens op een tape, Ik had toegang tot de gegevens lineair.
Ik moest de hele rollen tape om alle data.
Als ik de gegevens in punch kaarten, kon ik het toegang
in iets meer willekeurige mode, misschien niet zo snel.
>> Maar er waren beperkingen in de manier waarop we toegang tot gegevens op basis van hoe werd opgeslagen.
En dus was dit een probleem gaan in de jaren '50.
Nogmaals, kunnen we beginnen te zien dat als we nieuwe technologieën te verwerken ontwikkelen
de gegevens, rechts, het opent de deur naar nieuwe oplossingen,
voor nieuwe programma's, nieuwe aanvragen voor die gegevens.
En echt, het bestuur kan de reden geweest
Daarom ontwikkelden we een aantal van deze systemen.
Maar de zaken snel werd de bestuurder achter de evolutie
van de moderne database het moderne bestandssysteem.
>> Dus de volgende ding dat kwam was in de jaren '50
was het bestandssysteem en de ontwikkeling van random access opslag.
Dit was prachtig.
Nu, alle van een plotselinge, kunnen we onze bestanden overal op deze harde schijven
en we kunnen deze gegevens willekeurig toegang.
We kunnen ontleden dat informatie uit bestanden.
En we opgelost hele wereld problemen gegevensverwerking.
>> En dat duurde ongeveer 20 of 30 jaar tot de evolutie
van de relationele database, die wanneer de wereld besloten we nu
moet een repository die nederlagen hebben de wildgroei van de gegevens over het bestand
systemen die we hebben opgebouwd. Rechts?
Te veel gegevens verdeeld in te veel plaatsen, de de-duplicatie van data,
en opslagkosten was enorm.
>> In de jaren '70, de duurste bron een computer had was de opslag.
De processor was gezien vaste kosten.
Toen ik koop de doos, de CPU doet wat werk.
Het gaat om spinnen of het is eigenlijk werkt of niet.
Dat is echt een verzonken kosten.
>> Maar wat kostte me als een business is opslag.
Als ik meer schijven kopen volgende maand, dat is een echte prijs die ik betaal.
En dat de opslag is duur.
>> Nu zijn we snel vooruit 40 jaar en we hebben een ander probleem.
Het berekenen is nu de duurste bron.
De opslag is goedkoop.
Ik bedoel, we kunnen overal op de cloud en kunnen we goedkope opslag te vinden.
Maar wat ik niet kan vinden is goedkoop berekenen.
>> Dus de evolutie van de huidige technologie, database technologie,
is echt rond gericht gedistribueerde databases
die niet lijden hetzelfde type schaal
beperkingen van relationele databases.
We zullen een klein beetje over praten wat dat eigenlijk betekent.
>> Maar een van de redenen en de bestuurder achter dit-- we
sprak over de gegevens druk.
Gegevens druk iets dat drijft innovatie.
En als je kijkt naar boven de laatste vijf jaar,
Dit is een grafiek van wat de data belasting over de algemene enterprise
ziet er in de afgelopen vijf jaar.
>> En de algemene vuistregel deze dagen-- als je Google--
is 90% van de gegevens we nu opslaan en het
gegenereerd in de afgelopen twee jaar.
OK.
Nu, dit is niet een trend die is nieuw.
Dit is een trend die is geweest gaan voor 100 jaar.
Sinds Herman Hollerith ontwikkelde de ponskaart,
we hebben het bouwen van data repositories en het verzamelen van gegevens op fenomenale tarieven.
>> Dus in de afgelopen 100 jaar, we hebben deze trend gezien.
Dat gaat niet veranderen.
Going forward, we gaan om te zien Dit, zo niet een versnelde trend.
En je kunt zien hoe dat eruit ziet.
>> Als een bedrijf in 2010 had een terabyte aan gegevens onder beheer,
vandaag aan dat betekent dat ze managing 6,5 petabyte aan data.
Dat is 6.500 keer meer gegevens.
En ik weet dit.
Ik werk met deze bedrijven elke dag.
Vijf jaar geleden heb ik aan bedrijven zouden praten
die mij zou praten over wat een pijn het is om terabytes aan gegevens te beheren.
En zij zouden praten om me over hoe we zien
dat dit gaat waarschijnlijk een petabyte of twee
binnen een paar jaar.
>> Deze zelfde bedrijven vandaag ben ik een ontmoeting met,
en ze praten met mij over de probleem zijn er met het beheer
tientallen, 20 petabyte aan data.
Dus de explosie van de data in de industrie
drijft de enorme behoefte aan betere oplossingen.
En de relationele database is gewoon niet naleven van de vraag.
>> En dus is er een lineaire correlatie tussen de gegevens druk
en technische innovatie.
De geschiedenis heeft ons geleerd dit, dat de tijd,
wanneer de hoeveelheid gegevens dat moet worden verwerkt
groter is dan de capaciteit van het systeem om het te verwerken in een redelijke tijd
of tegen redelijke kosten, dan nieuwe technologieën
uitgevonden om deze problemen op te lossen.
Deze nieuwe technologieën, op zijn beurt, de deur open
naar een andere set van problemen, die is het verzamelen van nog meer gegevens.
>> Nu, we zijn niet van plan om dit te stoppen.
Rechts?
We zijn niet van plan om dit te stoppen.
Waarom?
Want je kunt niet alles weten er is om te weten in het universum.
En zolang we in leven geweest, de hele geschiedenis van de mens,
we hebben altijd gedreven om meer te weten.
>> Dus het lijkt alsof elke inch we verhuizen het pad van de wetenschappelijke ontdekking,
wij zijn de hoeveelheid data te vermenigvuldigen die we nodig hebben om exponentieel te verwerken
we ontdekken steeds meer over de interne werking van het leven,
over hoe het universum werkt, over besturen van de wetenschappelijke ontdekking,
en de uitvinding die die we vandaag doen.
Het volume van de gegevens alleen voortdurend toeneemt.
Dus in staat om te gaan met Dit probleem is enorm.
>> Dus een van de dingen we kijken als waarom NoSQL?
Hoe werkt NoSQL dit probleem oplossen?
Nou, relationele databases, Structured Query Language,
SQL-- dat is echt een constructie van het relationele database-- deze dingen zijn
geheugenoptimaal.
>> Terug in de jaren '70, opnieuw, disk is duur.
De provisioning uitoefening van opslag in de onderneming is nooit eindigende.
Ik weet.
Ik leefde het.
Ik schreef opslag drivers voor een enterprised superserver bedrijf
terug in de jaren '90.
En de bottom line is racking andere storage array was gewoon iets dat
gebeurd elke dag in de onderneming.
En het nooit gestopt.
Opslag hogere dichtheid vraag voor hoge opslagdichtheid,
en meer efficiënte opslag devices-- het is nooit gestopt.
>> En NoSQL is een geweldige technologie omdat normaliseert de gegevens.
Het de-dupliceert de gegevens.
Het zet de gegevens in een structuur die is agnostisch om elke toegang patroon.
Meerdere applicaties kan raken dat SQL-database, voert ad hoc queries,
en krijgen de gegevens in de vorm die zij moeten werkwijze voor de werklast.
Dat klinkt fantastisch.
Maar de bottom line is met enige systeem, als het agnostisch om alles,
het is geoptimaliseerd voor niets.
OK?
>> En dat is wat we krijgen met de relationele database.
Het is geoptimaliseerd voor opslag.
Het is genormaliseerd.
Het is relationele.
Het ondersteunt de ad hoc queries.
En het en het schalen verticaal.
>> Als ik moet een grotere SQL-database te krijgen of een krachtigere SQL-database,
Ik ga kopen een groter stuk ijzer.
OK?
Ik heb gewerkt met veel klanten dat door middel van belangrijke upgrades zijn geweest
in de SQL alleen infrastructuur om uit te vinden zes maanden later,
ze zijn weer het raken van de muur.
En het antwoord van Oracle of MSSQL of iemand anders is krijgen een grotere doos.
Nou vroeg of laat, kun je niet kopen van een grote doos, en dat is echt een probleem.
We moeten echt dingen te veranderen.
Dus waar komt dit?
Het werkt goed voor offline analytics, OLAP-type workloads.
En dat is echt waar de SQL behoort.
Nu, het is vandaag de dag gebruikt in vele online transactionele verwerking-type
toepassingen.
En het werkt prima op zekere mate van gebruik,
maar het gewoon niet schaal de manier waarop NoSQL doet.
En we zullen een beetje praten beetje over waarom dat zo is.
>> Nu NoSQL, anderzijds, is meer geoptimaliseerd voor compute.
OK?
Het is niet agnostisch te de toegang patroon.
Is wat wij noemen de-genormaliseerde structuur of een hiërarchische structuur.
De gegevens in een relationele database samengevoegd uit meerdere tabellen
de opvatting dat je nodig hebt produceren.
De gegevens in een databank NoSQL wordt opgeslagen in een document
bevat de hiërarchische structuur.
Alle gegevens die normaal zouden zijn samengevoegd dat standpunt te produceren
wordt opgeslagen in een enkel document.
En we zullen een klein beetje over praten hoe dat werkt in een paar grafieken.
>> Maar het idee is hier dat u opslaat uw gegevens zoals deze geïnstantieerd uitzicht.
OK?
Je schaal horizontaal.
Rechts?
Als ik moet het verhogen grootte van mijn NoSQL cluster,
Ik heb geen behoefte om een ​​grotere doos te krijgen.
Ik krijg een andere doos.
En ik cluster die samen, en ik kan die gegevens shard.
We zullen een beetje over praten Wat sharding is, worden
staat op schaal die database over meerdere fysieke apparaten
en verwijder de barrière die vraagt ​​me om verticaal te schalen.
>> Dus het is echt gebouwd voor online transactieverwerking en schaal.
Er is een groot verschil hier tussen rapportage, toch?
Rapporteren, weet ik niet de vragen Ik ga om te vragen.
Rechts?
Reporting-- als iemand uit mijn marketing afdeling
wil hoe veel van mijn klanten gewoon-- hebben deze bijzondere eigenschap die
gekocht op dit dag-- Ik weet het niet wat een query ze gaan vragen.
Dus ik moet agnostisch te zijn.
>> Nu, in een online transactionele applicatie
Ik weet welke vragen ik vraag.
Ik de aanvraag voor gebouwd een zeer specifieke workflow.
OK?
Dus als ik het optimaliseren van de data opslaan die workflow ondersteunen
het gaat sneller.
En dat is waarom NoSQL kan echt versnellen van de levering
van die typen diensten.
Prima.
>> Dus we gaan krijgen in een stukje theorie hier.
En sommigen van u, uw ogen zou terugdraaien een beetje.
Maar ik zal proberen om het te houden zo hoog als ik kan.
Dus als je in het project management, er is
een construct genaamd driehoek van beperkingen.
OK.
De driehoek van bedwingt dictaten je kunt niet alles hebben de hele tijd.
Kan niet over uw taart en eet het ook.
Dus in projectmanagement, dat driehoek beperkingen is dat je kunt het goedkoop hebben,
je kunt het snel moet, of u kunt het goed.
Kies twee.
Want je kunt niet alle drie.
Rechts?
OK.
>> Dus je hoort over dit veel.
Het is een drievoudige beperking, driehoek van drievoudige beperking,
of ijzeren driehoek oftentimes-- als je praat met projectmanagers,
ze over praten.
Nu, databases hun eigen ijzeren driehoek.
En het ijzeren driehoek data is wat wij GLB stelling noemen.
OK?
>> CAP stelling dicteert hoe databases werken
onder een specifieke omstandigheid.
En we praten over wat die voorwaarde is.
Maar de drie punten van de driehoek, zogezegd, zijn C, consistentie.
OK?
Dus in het GLB, consistentie betekent dat alle klanten die toegang tot de database
zal altijd een zeer consistente weergave van gegevens.
Niemand gaat zien twee verschillende dingen.
OK?
Als ik zie de database, Ik zie dezelfde mening
als mijn partner die ziet dezelfde database.
Dat is consistentie.
>> Beschikbaarheid betekent dat als de databank online, als het kan worden bereikt,
dat alle klanten zullen altijd kunnen lezen en schrijven.
OK?
Zodat iedere klant dat kan de database lezen
zal altijd in staat te lezen data en schrijven van gegevens.
En als dat het geval is, het is een beschikbaar systeem.
>> En het derde punt is wat wij noemen partitie tolerantie.
OK?
Partitie tolerantie middelen dat het systeem goed werkt
ondanks fysieke netwerk wanden tussen de knooppunten.
OK?
Dus knooppunten in het cluster kan niet praten met elkaar, wat gebeurt er?
Prima.
>> Dus relationele databases choose-- kunt u twee van deze te halen.
OK.
Dus relationele databases kiezen consistent te zijn en beschikbaar zijn.
Als de partitie gebeurt tussen de DataNodes in de gegevens op te slaan,
de database crasht.
Rechts?
Het gaat gewoon naar beneden.
OK.
>> En dit is waarom ze hebben om te groeien met grotere dozen.
Rechts?
Omdat er no-- meestal een cluster databank, is er niet heel veel van hen
die werken op die manier.
Maar de meeste databases schalen verticaal in een doos.
Omdat ze moeten worden consistente en beschikbaar.
Als een partitie zou worden geïnjecteerd dan zou je een keuze te maken.
Je moet een keuze te maken tussen de consequent en beschikbaar.
>> En dat is wat NoSQL-databases doen.
Prima.
Dus een NoSQL database is komt in twee smaken.
We have-- goed, het komt in vele smaken,
maar het komt met twee fundamentele characteristics-- wat
we zouden CP-database, of een bel consistente en partitie tolerantie
systeem.
Deze jongens maken de keuze die bij de knooppunten verliest contact met elkaar,
we gaan niet toestaan mensen om nog meer te schrijven.
OK?
>> Tot die partitie is verwijderd, schrijftoegang geblokkeerd.
Dat betekent dat ze niet beschikbaar.
Ze zijn consistent.
Wanneer we zien dat partitie injecteren zelf,
we zijn nu consistent, want we gaan niet
om de gegevens te wijzigen op twee toestaan zijden van de scheidingswand zelfstandig
van elkaar.
We moeten herstellen communicatie
voordat een update de gegevens is toegestaan.
OK?
>> Aan de smaak zou AP systeem, of een beschikbare en verdeeld
tolerance systeem.
Deze jongens niet schelen.
Rechts?
Elk knooppunt dat een krijgt schrijven, we nemen het.
Dus ik ben het repliceren van mijn gegevens over meerdere nodes.
Deze knooppunten krijgt een klant, klant komt in, zegt, ga ik een aantal gegevens te schrijven.
Knooppunt zegt, geen probleem.
Het knooppunt naast hem krijgt een waardevermindering op dezelfde record,
hij zal geen probleem te zeggen.
Ergens terug op het einde terug, die gegevens gaat repliceren.
En dan iemand gaan realiseren, uh-oh, ze systeem zal realiseren, uh-oh,
er is al een update naar twee kanten.
Wat doen we?
En wat ze doen, dan is ze iets doen, die
kunnen ze de gegevens staat lossen.
En we praten over die in de volgende tabel.
>> Ding te wijzen hier.
En ik ben niet van plan te krijgen veel in deze, omdat deze
krijgt in diepe data theorie.
Maar er is een transactionele raamwerk dat
uitgevoerd in een relationeel systeem kan ik veilig te actualiseren
meerdere entiteiten in de database.
En die updates zal optreden ineens of helemaal niet.
En dit heet ACID transacties.
OK?
>> ACID geeft ons atomiciteit, consistentie, isolatie en duurzaamheid.
OK?
Dat betekent dat atomaire, transacties, alle mijn updates ofwel gebeuren of ze dat niet doen.
Consistentie betekent dat de database zal altijd
in een consistent worden gebracht staat na een update.
Ik zal nooit de database in een verlaten slechte staat na het aanbrengen van een update.
OK?
>> Dus het is een beetje anders dan CAP consistentie.
CAP consistentie betekent dat al mijn klanten kunnen altijd zien de gegevens.
ACID samenhang betekent dat wanneer een transactie heeft gedaan, de gegevens van goed.
Mijn relaties zijn allemaal goed.
Ik ben niet van plan om een ​​ouder rij verwijderen en laat een stel weeskinderen
in een andere tabel.
Het kan niet gebeuren als ik consequent in zuur transactie.
>> Isolatiemiddelen die transacties geschiedt altijd na elkaar.
Het eindresultaat van de data zal dezelfde toestand
alsof die transacties die werden gelijktijdig uitgegeven
werden serieel uitgevoerd.
Dus het is concurrency controle in de database.
Dus eigenlijk, ik kan niet verhogen van de dezelfde waarde tweemaal met twee operaties.
>> Maar als ik zeg voeg 1 om deze waarde, en twee transacties komen
en proberen om het te doen, één is gaan om daar eerst
en de andere is gaan om daar na te krijgen.
Dus in het einde, voegde ik twee.
Zie je wat ik bedoel?
OK.
>> Duurzaamheid is vrij eenvoudig.
Wanneer de transactie wordt erkend, is het
gaat er zelfs als het systeem crasht.
Toen dat systeem herstelt, dat transactie die werd gepleegd
er werkelijk gaande is om daar te zijn.
Dus dat is de garanties van ACID transacties.
Die zijn vrij aardig garanties om een ​​databank
maar ze komen op die kosten.
Rechts?
>> Omdat het probleem met dit kader is
Als er een wand in de data set, ik moet een beslissing nemen.
Ik ga moeten toestaan updates aan één of de ander.
En als dat gebeurt, dan ben ik niet meer gaan
te kunnen handhaven deze kenmerken.
Ze zullen niet in overeenstemming zijn.
Ze zullen niet worden geïsoleerd.
Dit is waar het afbreekt voor relationele databases.
Dit is de reden relationele databases schalen verticaal.
>> Aan de andere kant zijn wat heet BASE technologie.
En dit zijn uw NoSQL-databases.
Prima.
Dus hebben we onze CP, AP databases.
En deze zijn wat je eigenlijk noemen beschikbaar, zacht staat, uiteindelijk
consequent.
OK?
>> In principe mogelijk, omdat ze partitie tolerant.
Ze zullen altijd daar, zelfs als er
een netwerk afscheiding tussen de knooppunten.
Als ik naar een knooppunt kan praten, ik ben zal in staat zijn om gegevens te lezen.
OK?
Ik misschien niet altijd in staat zijn om te schrijven data als ik een consistent platform.
Maar ik zal in staat zijn om gegevens te lezen.
>> De zachte toestand geeft dat toen ik las dat de gegevens,
het misschien niet hetzelfde als andere knooppunten zijn.
Indien een recht op een knooppunt werd uitgegeven ergens anders in het cluster
en het is niet gerepliceerd over de cluster nog toen ik las dat de gegevens,
die staat misschien niet consistent.
Toch zal het uiteindelijk consistente,
betekent dat wanneer een schrijf wordt aan het systeem,
het zal repliceren over de knooppunten.
En uiteindelijk, die staat in orde zal worden gebracht,
en zal een consistente toestand.
>> Nu, CAP stelling echt speelt slechts in één voorwaarde.
Deze voorwaarde is wanneer dit gebeurt.
Want als het is actief in de normale modus, er is geen partitie,
alles is consequent en beschikbaar.
Je je zorgen alleen over het GLB als we die partitie.
Dus die zijn zeldzaam.
Maar hoe het systeem reageert wanneer die optreden dicteren wat voor soort systeem
we te maken hebben met.
>> Dus laten we eens kijken naar wat dat lijkt voor AP-systemen.
OK?
AP systemen komen in twee smaken.
Ze komen in de smaak, dat is een Meester, 100%, altijd beschikbaar.
En ze komen in de andere smaak, die zegt:
weet je wat, ik ga zorgen te maken over dit partitioneren ding
wanneer een feitelijke verdeling optreedt.
Anders, er zal primair worden knooppunten wie gaat om de rechten te nemen.
OK?
>> Dus als we iets als Cassandra.
Cassandra zou een meester te zijn meester, laat het me te schrijven aan een knooppunt.
Dus wat gebeurt er?
Dus ik heb een object in de database die bestaat op twee knooppunten.
Laten we noemen dat object S. Dus we hebben staat voor S.
We hebben een aantal activiteiten op S die zijn gaande.
Cassandra kan ik schrijven op meerdere knooppunten.
Dus laten we zeggen dat ik een te schrijven voor en twee knooppunten.
Nou, wat uiteindelijk gebeurt is wij noemen dat een opdeling evenement.
Er kan niet worden een fysieke netwerk partitie.
Maar vanwege het ontwerp van het systeem, is het
eigenlijk partitioneren zodra als ik een schrijven op twee knooppunten.
Het is me niet dwingen schrijf alles via één knooppunt.
Ik schrijf over twee knooppunten.
OK?
>> Dus nu heb ik twee staten.
OK?
Wat gaat er gebeuren is vroeg of laat,
er zal een replicatie evenement.
Er gaat worden wat we riep een partitie herstel, die
is waar deze twee staten bij elkaar komen terug
en er zal een algoritme die draait binnen de database
beslist wat te doen.
OK?
Standaard laatste aanpassing wint meeste AP systemen.
Dus er is meestal een standaard algoritme, wat
ze noemen een callback functie, iets wat
zal worden genoemd wanneer deze aandoening wordt gedetecteerd wat logica uit te voeren
om dat conflict op te lossen.
OK?
De standaard callback en standaard resolver meeste AP databases
is, wat denk je, timestamp wint.
Dit was de laatste update.
Ik ga die update daar zetten.
Ik kan dit record dumpen dat ik gedumpt af in een recovery log
zodat de gebruiker later terug kan komen en zeggen: hey, was er een botsing.
Wat er is gebeurd?
En je kunt eigenlijk dumpen een record van alle botsingen en rollbacks
en zie wat er gebeurt.
>> Nu, als een gebruiker, kunt u ook omvatten logica in die callback.
Dus je kan dat veranderen callback operatie.
Je kunt zeggen, hey, ik wil om deze gegevens te saneren.
En ik wil proberen en samenvoegen van deze twee records.
Maar dat is aan jou.
De database weet niet hoe dat doen door standaard. De meeste van de tijd,
de enige database weet hoe dat te doen is te zeggen,
Dit was de laatste record.
Dat is degene die gaat winnen, en dat is de waarde Ik ga zetten.
Zodra dat partitie herstel en replicatie optreedt,
we hebben onze staat, die is nu S eerste, dat is
het samenvoegen toestand van al die objecten.
Dus AP systemen hebben dit.
CP-systemen niet nodig zorgen te maken over dit.
Want zodra een partitie komt in het spel, maar ze stoppen met het innemen
schrijft.
OK?
Dus dat is heel gemakkelijk te behandelen consequent
wanneer u geen updates te accepteren.
Dat is met CP-systemen te doen.
Prima.
>> Dus laten we een beetje praten beetje over toegang patronen.
Als we praten over NoSQL, het is alles over de toegang patroon.
Nu, SQL is ad hoc queries.
Het is relationele winkel.
We hebben geen zorgen te maken over de toegang patroon.
Ik schrijf een zeer complexe vraag.
Het gaat en de gegevens krijgt.
Dat is wat het lijkt zoals, normalisatie.
>> Dus in dit bijzondere structuur, we kijken naar een producten catalogus.
Ik heb verschillende soorten producten.
Ik heb boeken.
Ik heb albums.
Ik heb video's.
De relatie tussen producten en elk van deze boeken, albums,
en video tabellen 1: 1.
Prima?
Ik heb een product-ID, en dat ID overeenkomt
een boek, een album of een video.
OK?
Dat is een 1: 1 relatie over die tabellen.
>> Nu, alles wat ze books-- hebben root eigenschappen.
Geen probleem.
Dat is fantastisch.
Eén-op-één relatie, krijg ik alle de gegevens die ik nodig heb om dat boek te beschrijven.
Albums-- albums hebben tracks.
Dit is wat we een te veel bellen.
Elk album zou kunnen hebben veel tracks.
Dus voor elke track op het album, kon ik heb
een record in dit kind tabel.
Dus ik maak één record in mijn albums tafel.
Ik meerdere records in de tabel tracks.
Een-op-veel-relatie.
>> Deze relatie is waar noemen we many-to-many.
OK?
Je ziet dat de acteurs zou kunnen zijn in vele films, veel video's.
Dus wat we doen is zetten we deze mapping tussen die, waardoor het net
brengt de acteur ID om de video-ID.
Nu kan ik een query de naden te creëren video's via acteur video naar acteurs,
en het geeft me een mooie lijst alle films en alle actoren
die in die film waren.
>> OK.
Dus hier gaan we.
Eén-op-één is de top-level relatie; één-op-veel,
albums te sporen; many-to-many.
Dat zijn de drie top-level relaties in een database.
Als je weet hoe die relaties werken samen,
dan weet je een heleboel over de database al.
Dus NoSQL werkt een beetje anders.
Laten we nadenken over voor een tweede wat het looks willen gaan krijgen al mijn producten.
>> In een relationele winkel I wil al mijn producten te krijgen
op een lijst van al mijn producten.
Dat is een hoop vragen.
Ik heb een vraag voor al mijn boeken.
Ik heb een vraag van mijn albums.
En ik heb een vraag voor al mijn video's.
En ik heb om het te zetten allemaal samen in een lijst
en serveer het terug naar de applicatie dat is het verzoek.
>> Om mijn boeken te krijgen, ik meedoen Producten en boeken.
Mijn albums krijgen, kreeg ik om toe te treden Producten, Albums en Tracks.
En tot mijn video's te krijgen, heb ik om producten aan te sluiten voor video,
toetreden tot Actor's, en brengen de acteurs.
Dus dat is drie queries.
Zeer complexe queries op assembleren een resultaat set.
>> Dat is niet optimaal.
Dit is waarom wanneer we praten over een gegevensstructuur die
gebouwd agnostische om toegang te pattern-- goed, dat is geweldig.
En je kunt zien dit is echt mooi hoe we de gegevens hebben georganiseerd.
En weet je wat?
Ik heb maar één record voor een acteur.
>> Dat is cool.
Ik heb al mijn acteurs gededupliceerd, en ik onderhouden mijn verenigingen
in dit toewijzingstabel.
Echter, om de gegevens out wordt duurder.
Ik ben het verzenden van de CPU over het hele systeem toetreding tot deze gegevens structuren samen
kunnen de gegevens terug te trekken.
>> Dus hoe krijg ik rond dat?
In NoSQL het gaat over aggregatie, niet normalisering.
Dus we willen zeggen dat we willen ondersteuning van de toegang patroon.
Als de toegang patroon de toepassingen,
Ik moet al mijn producten te krijgen.
Laten we alle producten in één tabel.
Als ik alle producten in een tabel, Ik kan gewoon selecteren alle producten
van die tafel en ik krijg het allemaal.
Goed hoe doe ik dat?
Welnu, in NoSQL er geen structuur tafel.
We zullen een klein beetje over praten hoe dit werkt in Dynamo DB.
Maar je hoeft niet dezelfde zijn eigenschappen en dezelfde eigenschappen
in elke rij, in elk voorwerp, zoals je in een SQL-tabel.
En wat dit kan ik te doen is een heleboel dingen
en geef me een veel flexibiliteit.
In dit specifieke geval, I heb mijn product documenten.
En in dit Bijvoorbeeld, alles
een document in de tabel producten.
En het product voor een boek zou kunnen hebben een soort ID die een boek aangeeft.
En de toepassing zou overstappen op dat ID.
>> Bij de toepassing tier, ga ik te zeggen oh, wat opname type is dit?
Oh, het is een boek record.
Boek records deze eigenschappen.
Laat me een boek-object te maken.
Dus ik ga naar het vullen boek object met dit punt.
Volgend item komt en zegt, wat is dit artikel?
Vormt van dit artikel is een album.
Oh, ik heb een heel ander verwerkingsroutine daarvoor,
want het is een album.
Zie je wat ik bedoel?
>> Zodat de toepassing tier-- I Selecteer gewoon al deze records.
Ze beginnen allemaal komen.
Ze kunnen alle verschillende soorten.
En het is de logica van de toepassing dat schakelt over die soorten
en besluit hoe ze te verwerken.
>> Weer, dus we het optimaliseren van de schema voor de toegang patroon.
We doen het door instortende die tabellen.
We zijn in principe nemen Deze genormaliseerde structuren
en we bouwen hiërarchische structuren.
Binnen elk van deze records Ik ga reeks eigenschappen te zien.
>> Binnen dit document voor Albums, Ik zie arrays van tracks.
Die tracks nu become-- het is In principe is dit kind tafel
Er bestaat hier in deze structuur.
Dus u kunt dit doen in DynamoDB.
U kunt dit doen in MongoDB.
U kunt dit doen in een NoSQL-database.
Maak deze soorten hiërarchische datastructuren
dat u gegevens mogelijk te maken op te halen zeer snel omdat ik nu
niet hoeven te voldoen.
Wanneer ik een rij in de Tracks tafel, of een rij in de tabel Albums,
Ik heb om te voldoen aan dat schema.
Ik moet het attribuut of het hebben eigenschap die is gedefinieerd op die tafel.
Ieder van hen, toen ik steek die rij.
Dat is niet het geval in NoSQL.
>> Ik kan totaal verschillend zijn woningen in elk document
dat ik invoegen in de collectie.
Dus zeer krachtig mechanisme.
En het is echt hoe je optimaliseren van het systeem.
Want nu die vraag, in plaats van toetreding al deze tabellen
en uitvoeren van een half dozijn queries terug te trekken van de gegevens die ik nodig,
Ik ben het uitvoeren van een zoekopdracht.
En ik ben itereren over de resultatenset.
het geeft je een idee van de kracht van NoSQL.
Ik ga soort zijwaarts gaan hier en een beetje praten over dit.
Dit is de soort marketing of technology--
op de markt brengen van de technologie soort discussie.
Maar het is belangrijk om te begrijpen want als we kijken naar de top
hier bij deze grafiek, wat we op zoek naar
is wat wij noemen de technologie hype curve.
En wat dit betekent is nieuwe dingen in het spel komt.
Mensen denken dat het geweldig.
Ik heb al mijn problemen opgelost.
>> Dit kan het einde alle, zijn allemaal van alles.
En ze gaan gebruiken.
En zij zeggen, dit spul werkt niet.
Dit is niet goed.
De oude spul was beter.
En ze gaan terug naar het doen dingen zoals ze waren.
En dan uiteindelijk ze gaan, weet je wat?
Dit spul is niet zo slecht.
Oh, dat is hoe het werkt.
En zodra ze erachter te komen hoe het werken, beginnen ze steeds beter.
>> En het grappige ding over het is het soort leidingen tot wat
wij noemen het Technology Adoption Curve.
Dus wat er gebeurt is dat we hebben een soort technologie trekker.
Bij databases, het data druk.
We spraken over het hoge water punten van data druk door de tijd heen.
Wanneer die gegevens druk raakt een bepaald punt, dat is een technologie trekker.
>> Het wordt te duur.
Het duurt te lang om de gegevens te verwerken.
We moeten iets beters.
Je krijgt de vernieuwers die er rond te rennen,
proberen uit te vinden wat is de oplossing.
Wat is het nieuwe idee?
>> Wat is de volgende beste manier om dit te doen?
En ze komen met iets.
En de mensen met de echte pijn, de jongens op de bleeding edge,
ze allemaal te springen over, omdat ze moeten een antwoord.
Nu, wat onvermijdelijk happens-- en is er nu gebeurt in NoSQL.
Ik zie het de hele tijd.
>> Wat onvermijdelijk gebeurt is mensen beginnen met behulp van de nieuwe tool
Op dezelfde manier gebruikten ze de oude tool.
En ze ontdekken dat het niet zo goed.
Ik weet niet meer wie ik was praat eerder vandaag.
Maar het is net als de drilboor werd uitgevonden,
mensen niet swing het over hun hoofd naar de betonnen smash.
>> Maar dat is wat gebeurt met NoSQL vandaag.
Als je loopt in de meeste winkels, ze proberen te zijn NoSQL winkels.
Wat ze doen is ze gebruiken NoSQL,
en ze zijn het laden vol relationele schema.
Want dat is hoe zij ontwerpen databases.
En ze vraagt ​​je af, waarom is het niet uitvoeren van zeer goed?
Jongen, dit ding stinkt.
Ik moest al mijn behouden toetreedt in-- het is als, nee, nee.
Onderhouden toetreedt?
Waarom doe je mee data?
Je hoeft geen gegevens mee NoSQL.
U aggregeren het.
>> Dus als je wilt om dit te voorkomen, te leren hoe de tool werkt voordat je daadwerkelijk
gaan gebruiken.
Probeer niet en gebruik maken van de nieuwe instrumenten van de dezelfde manier gebruikt de oude gereedschappen.
Je gaat naar een slechte ervaring hebben.
En elke keer dat is waar het om gaat.
Wanneer we beginnen komen hier, het is omdat de mensen bedacht
hoe u de tools te gebruiken.
>> Ze deed hetzelfde bij relationele databases werden uitgevonden,
en zij werden vervangen bestandssystemen.
Ze probeerden file systemen te bouwen met relationele databases
want dat is wat de mensen begrepen.
Het werkte niet.
Dus het begrijpen van de 'best practices' van de technologie die u werkt met
is enorm.
Erg belangrijk.
>> Dus we gaan krijgen in DynamoDB.
DynamoDB is AWS volledig beheerde NoSQL platform.
Wat betekent volledig beheerde betekenen?
Het betekent dat je niet hoeft te echt zorgen te maken over iets.
>> Kom je in, je vertellen ons, ik heb een tafel.
Het moet dit veel capaciteit.
U druk op de knop, en wij verstrekken alle infrastructuur achter de schermen.
Nu dat is enorm.
>> Want als je praat schaalvergroting een databank
NoSQL data clusters op schaal, lopen petabytes,
loopt miljoenen transacties per seconde,
deze dingen zijn geen kleine clusters.
We praten duizenden gevallen.
Het beheren van duizenden gevallen zelfs virtuele instances,
is een echte pijn in de kont.
Ik bedoel, denk elke keer een besturingssysteem patch uitkomt
of een nieuwe versie van de database.
Wat betekent dat om u operationeel?
Dat betekent dat je hebt 1200 servers die moeten worden bijgewerkt.
Nu zelfs met automatisering, dat kan een lange tijd in beslag nemen.
Dat kan veel veroorzaken operationele hoofdpijn,
omdat ik misschien diensten naar beneden.
>> Zoals ik updaten deze databases, I misschien blauwgroene implementaties doen
waar ik implementeren en upgraden de helft van mijn knooppunten, en vervolgens een upgrade van de andere helft.
Neem die naar beneden.
Zodat het beheer van de infrastructuur schaal is enorm pijnlijk.
En AWS nemen die pijn uit.
En NoSQL-databases kan zijn buitengewoon pijnlijk
vanwege de manier waarop ze schaal.
>> Schalen horizontaal.
Als u wilt een grotere NoSQL krijgen databank, je koopt meer knooppunten.
Elk knooppunt u koopt is andere operationele hoofdpijn.
Dus laat iemand anders dat voor je doen.
AWS kan dat doen.
>> Wij ondersteunen document kernwaarden.
Nu hebben we niet te veel gaan in op de andere kaart.
Er is een heleboel verschillende smaken van NoSQL.
Ze zijn allemaal soort van krijgen samen onder handen genomen op dit punt.
U kunt kijken naar DynamoDB en zeggen: ja, we allebei een document en een belangrijke waarde
bewaar dit punt.
En u kunt de functies argumenteren van een over de ander.
Voor mij, veel van dit is echt zes van een half dozijn andere.
Elk van deze technologieën is een fijne techniek en een prima oplossing.
Ik zou niet zeggen MongoDB beter of erger dan Couch, dan Cassandra,
dan Dynamo, of vice versa.
Ik bedoel, dit zijn slechts opties.
>> Het is snel en het is consistente op elke schaal.
Dus dit is een van de grootste bonussen je krijgt met AWS.
Met DynamoDB is het vermogen een low single digit krijgen
milliseconde latentie op elke schaal.
Dat was een ontwerp doel van het systeem.
En we hebben klanten die aan het doen zijn miljoenen transacties per seconde.
>> Nu zal ik gaan door middel van een aantal van deze use cases in een paar minuten hier.
Geïntegreerde toegang control-- we hebben wat we noemen
Identity Access Management, of IAM.
Het doordringt elk systeem, elke dienst die AWS biedt.
DynamoDB is geen uitzondering.
U kunt toegang te controleren de DynamoDB tabellen.
Voor al uw AWS-accounts door definiëren van toegang en machtigingen
in de IAM infrastructuur.
>> En het is een belangrijk en integraal onderdeel van wat wij noemen Event Driven Programming.
Nu is dit een nieuw paradigma.
>> Publiek: Hoe is uw snelheid van de ware positieven versus valse negatieven
op uw toegangscontrole systeem?
RICK Houlihan: True positieven versus valse negatieven?
PUBLIEK: Terugkerende wat je moet terug worden?
In tegenstelling tot een keer in een tijdje niet terug te keren wanneer het moet valideren?
>> RICK Houlihan: Ik kan je niet vertellen dat.
Als er geen storingen ook op dat,
Ik ben niet de persoon te vragen die specifieke vraag.
Maar dat is een goede vraag.
Ik zou nieuwsgierig zijn om te weten dat zelf, eigenlijk.
>> En dus nogmaals, nieuw paradigma is event-driven programmeren.
Dit is het idee dat je kunt implementeren van complexe applicaties die
kan een zeer, zeer grote schaal opereren zonder enige infrastructuur dan ook.
Zonder vaste infrastructuur dan ook.
En we zullen een beetje praten over wat dat betekent als we
krijgen op de komende paar grafieken.
>> Het eerste wat we doen is dat we praten over tafels.
Typen API-gegevens voor Dynamo.
En het eerste wat je zult opvalt als je kijkt naar dit,
als je bekend bent met een database, databases hebben eigenlijk twee soorten API's
Ik zou het noemen.
Of twee van API.
Een van die zou administratieve API.
>> De dingen die ze verzorgen de functies van de database.
De opslag motor configureren, opzetten en het toevoegen van tabellen.
het creëren van de database catalogi en gevallen.
Deze things-- in DynamoDB, u hebben zeer korte, korte lijsten.
>> Dus met andere databases, je zou tientallen zien
van commando's, van de administratieve commando's voor het configureren
deze extra opties.
In DynamoDB je niet nodig, omdat die u niet het systeem te configureren, we doen.
Dus het enige wat je hoeft te doen is vertel me welke maat tafel heb ik nodig.
Zodat u een zeer krijgen beperkte set van commando's.
>> Je krijgt een Creëer Table Update, Tafel, Tabel verwijderen, en Beschrijf tabel.
Dat zijn de enige dingen je nodig hebt voor DynamoDB.
U hoeft niet een opslag nodig engine configuratie.
Ik heb geen zorgen te maken over replicatie.
Ik heb geen zorgen te maken over sharding.
>> Ik heb geen zorgen te maken over een van deze spullen.
We doen het allemaal voor u.
Dus dat is een enorme hoeveelheid overhead die net is getild je bord.
Dan hebben we de CRUD operators.
CRUD is iets wat we noemen in de database dat is
Create, Update, Delete operators.
Dit zijn uw gezond databank operaties.
Dingen zoals put punt, item te krijgen, bijwerken items, items te verwijderen, batch query, scannen.
Als u de hele tabel te scannen.
Trek alles uit de tabel.
Een van de leuke dingen over DynamoDB is het mogelijk parallelle scanning.
Dus je kunt eigenlijk laat me weten hoeveel discussies die u wilt uitvoeren op die scan.
En we kunnen draaien die draden.
We kunnen draaien dat scannen up over meerdere threads
dus je kunt de hele tabel te scannen ruimte zeer, zeer snel in DynamoDB.
>> De andere API die we hebben is wat wij noemen ons Streams API.
We gaan niet om te praten veel over dit recht nu.
Ik heb wat inhoud later kreeg op het dek over.
Maar Streams is echt een running-- denk aan het als de tijd besteld
en partitie change log.
Alles wat er gebeurt op de tabel toont op de stream.
>> Elke brief aan de tafel verschijnt op de stroom.
Je kunt die stroom lezen en Je kunt dingen doen.
We zullen praten over wat soorten dingen die je
maken met de dingen zoals replicatie, het creëren van secundaire indexen.
Alle soorten van echt cool dingen die je kunt doen met die.
>> Types data.
In DynamoDB, beide belangrijke steunen wij waarde en het document data types.
Aan de linkerkant van het scherm hier, we hebben onze basistypen.
Key value types.
Dit zijn snaren, getallen en binaries.
>> Dus gewoon drie basistypen.
En dan kunt u sets van die te hebben.
Een van de leuke dingen over NoSQL is U kunt arrays als eigenschappen bevatten.
En met DynamoDB u kunt arrays bevatten van basistypen als een wortel woning.
>> En dan is er het type document.
Hoeveel mensen zijn bekend met JSON?
Jullie vertrouwd met JSON zo veel?
Het is eigenlijk JavaScript, Object, Notation.
Hiermee kunt u in principe definieert een hiërarchische structuur.
>> U kunt een JSON-document op te slaan DynamoDB het gebruik van gemeenschappelijke componenten
of bouwstenen die beschikbaar zijn In de meeste programmeertalen.
Dus als je Java, je bent kijken naar kaarten en lijsten.
Ik kan objecten maken dat gebied kaart.
Een kaart als kernwaarden opgeslagen als eigenschappen.
En het zou een lijst hebben van waarden binnen die eigenschappen.
U kunt dit complex te bewaren hiërarchische structuur
als een enkel attribuut van een DynamoDB punt.
>> Zo tafels in DynamoDB, net als de meeste NoSQL databases, tabellen items.
In MongoDB je zou noemen deze documenten.
En het zou de bank uitvalsbasis.
Ook een document database.
Je noemt deze documenten.
Documenten of items hebben attributen.
Attributen kunnen bestaan ​​of bestaan ​​niet op het item.
In DynamoDB, is er één verplichte attribuut.
Net als in een relationele database, heb je een primaire sleutel op de tafel.
>> DynamoDB heeft wat wij een hekje noemen.
Hash sleutel moet uniek zijn.
Dus toen ik een hash tabel te definiëren, eigenlijk wat ik zeg
is elke punt zal een hash sleutel.
En elke hash sleutel moet uniek zijn.
>> Elk item wordt gedefinieerd door die unieke hekje.
En er kan slechts één.
Dit is OK, maar vaak wat mensen nodig hebben
is dat ze willen is dit hash toets om een ​​beetje meer te doen
dan alleen een unieke identificatie zijn.
Vaak willen we dat hekje-toets gebruiken als het hoogste niveau aggregatie emmer.
En de manier waarop we dat doen is door het toevoegen van wat we een reeks belangrijke noemen.
>> Dus als het is slechts een hash tabel, moet dit uniek zijn.
Als het een hash en het bereik tafel, de combinatie van de hash en gamma
moet uniek zijn.
Dus na te denken over het op deze manier.
Als ik een forum.
En het formulier heeft onderwerpen, het heeft posten, en het heeft reacties.
>> Dus ik zou een hash key, die het onderwerp ID.
En ik zou een reeks sleutel, die de reactie ID.
Op die manier als ik wil al het krijgen antwoorden voor bepaald onderwerp,
Ik kan query de hash.
Ik kan alleen maar zeggen geef me alle punten die deze hash.
En ik ga elke vraag te krijgen of post voor dat specifieke onderwerp.
Deze top level samenvoegingen zijn zeer belangrijk.
Zij ondersteunen de primaire toegang patroon van de applicatie.
In het algemeen, dit is wat we willen doen.
We willen dat table-- als je de tafel te laden,
we willen de datastructuur binnen de tafel zodanig
dat de aanvraag kan zeer snel die resultaten te halen.
En vaak de manier om dat te doen is deze combinaties als we behouden
Steek de gegevens.
Kortom, we de gegevens verspreiden in de lichte emmer als het komt in.
>> Range toetsen kunt mij-- hash sleutels moet gelijkheid zijn.
Als ik een query een hash, moet ik zeggen geef me een hash dat dit evenaart.
Als ik een query een bereik, ik kan zeggen geef me een scala
dat is het gebruik van elke vorm van rijke operator die we ondersteunen.
Geef me alle items voor een hash.
Is het gelijk, groter dan, dan, begint het met,
het bestaat tussen deze twee waarden?
Dus dit soort range queries dat we altijd geïnteresseerd in.
Nu is een ding over data, wanneer je kijkt naar de toegang tot gegevens, wanneer
u toegang tot de gegevens, het is altijd om een ​​aggregatie.
Het gaat altijd over de verslagen die gerelateerd zijn aan deze.
Geef mij alles hier that's-- alle de transacties op deze creditcard
voor de laatste maand.
Dat is een samenvoeging.
>> Bijna alles wat je doet in de database is een soort van aggregatie.
Dus de mogelijkheid om te kunnen definiëren Deze emmers en geven u deze range
attributen kunnen bevragen, die rijke queries ondersteunen vele,
vele, vele toegang applicatie patronen.
>> Dus de andere wat de hekje-toets doet is het geeft ons een mechanisme
kunnen de gegevens rond te spreiden.
NoSQL-databases werken het beste wanneer de data gelijkmatig
verdeeld over de cluster.
Hoeveel mensen zijn bekend met hashing algoritmen?
Toen ik hasj en een hashing-- zeggen omdat een hashing-algoritme
is een manier te kunnen genereren een willekeurige waarde van een gegeven waarde.
Dus in dit geval, de hash-algoritme we lopen is ND 5 gebaseerd.
>> En als ik een ID, en dit is mijn hash sleutel, ik heb 1, 2, 3.
Wanneer ik de hash-algoritme, het gaat om terug te komen en te zeggen:
en 1 gelijk 7B, 2 gelijk aan 48, 3 gelijk CD.
Ze zijn verspreid over de belangrijkste ruimte.
En waarom doe je dit?
Want dat zorgt ervoor dat ik kan zet de verslagen over meerdere nodes.
>> Als ik dit doe stapsgewijs, 1, 2, 3.
En ik heb een hash bereik dat runs in dit geval
een kleine hash ruimte, loopt van 00 tot FF,
dan is de administratie gaan om binnen te komen en ze gaan naar 1, 2, 3, 4, 5,
6, 7, 8, 9, 10, 11, 12.
Wat gebeurt?
Elk inzetstuk naar hetzelfde knooppunt.
Zie je wat ik bedoel?
>> Want als ik deelden de ruimte, en ik verspreid deze records over,
en ik partitie, ik ga zeggen partitie 1 heeft sleutel ruimte 0-54.
Partitie 2 is 55-89.
Partitie 3 is AA FF.
Dus als ik ben met behulp van lineair verhogen Id's, kunt u zien wat er gebeurt.
1, 2, 3, 4, 5, 6, helemaal tot aan 54.
Dus als ik het hameren gegevens in het systeem,
alles eindigt gaat naar een knooppunt.
>> Dat is niet goed.
Dat is een antipattern.
In MongoDB hebben ze dit probleem als je niet beschikt over een hekje te gebruiken.
MongoDB geeft u de mogelijkheid hashing van de belangrijkste waarde.
Je moet altijd dat doen, als je bent met behulp van een hash verhogen
sleutel in MongoDB, of je zult spijkeren elke schrijven naar een knooppunt,
en je zal beperken je schrijft throughput slecht.
>> PUBLIEK: Is dat A9 169 in decimale?
>> RICK Houlihan: Ja, het is ergens rond daar.
A9, ik weet het niet.
Je zou hebben om mijn binaire krijgen decimale rekenmachine.
Mijn brein werkt niet zo.
PUBLIEK: Even snel een van uw Mongo opmerkingen.
Dus is het object ID die geleverd native met Mongo dat doen?
RICK Houlihan: Is het dat?
Als je het opgeeft.
Met MongoDB, heb je de optie.
U kunt elk document in specify-- MongoDB moet een underscore ID hebben.
Dat is de unieke waarde.
>> In MongoDB u kunt opgeven of om het te hash of niet.
Ze geven je gewoon de optie.
Als je weet dat het willekeurig, geen probleem.
U hoeft niet om dat te doen.
Als je weet dat het niet willekeurig, dat het is het verhogen, doe dan de hash.
>> Nu is het ding over hashing, als je eenmaal hash
een value-- en dit is waarom hash toetsen zijn altijd
unieke vragen, want ik ben veranderd de waarde, nu kan ik niet een reeks vragen doen.
Ik kan niet zeggen is dit tussen dit of dat,
omdat de hash-waarde is niet van plan gelijk aan de werkelijke waarde.
Dus als je hash dat sleutel, het is slechts gelijkheid.
Dit is de reden waarom in DynamoDB hekje queries zijn altijd alleen gelijkheid.
>> Dus nu in een reeks key-- toen ik toevoegen dat bereik sleutel,
die reeks belangrijke records allemaal komen en ze worden opgeslagen op dezelfde partitie.
Dus ze zijn erg snel, eenvoudig teruggehaald, want dit is de hash,
Dit is het bereik.
En je alles zien met dezelfde hash
wordt opgeslagen op dezelfde partitie ruimte.
Je kunt dat bereik toets gebruiken om te helpen de locatie van uw gegevens in de buurt van haar moedermaatschappij.
Dus wat doe ik hier eigenlijk doen?
Dit is een één tot vele relatie.
De relatie tussen een hekje en het bereik sleutel is een te veel.
Ik kan meerdere hash sleutels.
Ik kan alleen maar meerdere range sleutels in ieder hekje.
>> De hash bepaalt de ouder, het bereik definieert de kinderen.
Zodat u kunt zien is er analoge hier tussen de relationele construct
en dezelfde soort construeert in NoSQL.
Mensen praten over NoSQL als niet-relationele.
Het is niet niet-relationele.
Data altijd relaties.
Die relaties gewoon worden anders gemodelleerd.
Laten we praten een beetje beetje over duurzaamheid.
Wanneer je schrijven op DynamoDB, schrijft zijn altijd drie-weg gerepliceerd.
Wat betekent dat we hebben drie van AZ.
AZ zijn beschikbaarheid Zones.
U kunt denken aan een Beschikbaarheid Zone als een data center
of een verzameling van datacenters.
Deze dingen zijn geografisch geïsoleerd van elkaar
over verschillende breukzones, over verschillende elektriciteitsnetten en de uiterwaarden.
Een storing in een AZ niet gaan te nemen van de andere.
Zij zijn ook gekoppeld samen met dark fiber.
Het ondersteunt een sub 1 milliseconde latentie tussen AZS.
Dus real time data replicatie staat in multi AZS.
>> En vaak met meerdere AZ implementaties voldoen aan de hoge beschikbaarheidseisen
van de meeste enterprise organisaties.
Dus DynamoDB gespreid over drie AZS standaard.
We zijn alleen maar om de kennis van de write wanneer twee van de drie knooppunten terugkomen
en zeggen: Ja, ik heb het.
Waarom is het zo?
Want op de lees kant zijn we alleen ga je de gegevens terug te geven wanneer
we krijgen van twee knooppunten.
>> Als ik repliceren over drie, en ik ben het lezen van de twee,
Ik ben altijd gegarandeerd ten minste één over
van die leest het zijn meest recente kopie van de gegevens.
Dat maakt DynamoDB consistent.
Nu kunt u kiezen om te draaien die consistente leest uit.
In dat geval ga ik om te zeggen, Ik zal alleen lezen van het ene knooppunt.
En ik kan niet garanderen dat het gaat om de meest actuele gegevens.
>> Dus als een waardevermindering komt in, het is nog niet gerepliceerd,
je gaat om die kopie te krijgen.
Dat is een uiteindelijk consistente lezen.
En wat dat is de helft van de kosten.
Dus dit is iets om na te denken over.
Wanneer je uitlezen DynamoDB en je het opzetten van uw lees- capaciteit
units, als je uiteindelijk kiezen consistente leest, het is een stuk goedkoper,
het is ongeveer de helft van de kosten.
>> En zo bespaart u geld.
Maar dat is uw keuze.
Als u een consistente lezen of een uiteindelijk consistente lezen.
Dat is iets dat je kunt kiezen.
>> Laten we praten over indexen.
Dus hebben we dat genoemd topniveau aggregatie.
We hebben hash toetsen, en we hebben range toetsen.
Dat is leuk.
En dat is op de primaire tabel, I heb er een hekje, ik heb er een reeks sleutel.
>> Wat betekent dat?
Ik heb één attribuut kreeg dat ik kan rijk queries tegen draaien.
Het is het bereik toets.
De andere attributen die item-- Ik kan filteren op deze attributen.
Maar ik kan geen dingen doen, zoals het begint met of groter dan.
>> Hoe doe ik dat?
Ik maak een index.
Er zijn twee types indexen in DynamoDB.
Een index is echt een andere kijk op de tafel.
En de lokale secundaire index.
>> De eerste die we praten over.
Dus lokale secundaire worden naast elkaar op dezelfde partitie als data.
En als zodanig zijn zij op dezelfde fysieke node.
Ze zijn wat we consequent noemen.
Betekenis, zullen ze erkennen het schrijven met de tafel.
Wanneer het schrijven komt, zullen we schrijven via de index.
We zullen naar de tafel te schrijven, en dan zullen we erkennen.
Dus dat is consistent.
Nadat het schrijven is erkend van de tafel,
het is gegarandeerd dat de lokale secundaire index
zal dezelfde visie van gegevens.
Maar wat ze laten je doet is definiëren alternatieve bereik toetsen.
>> Aan dezelfde hash gebruiken key als de primaire tabel,
omdat ze samen op het dezelfde partitie, en ze zijn consistent.
Maar ik kan een index te maken met verschillende bereik toetsen.
Dus bijvoorbeeld, als ik had een fabrikant dat had een ruwe delen tafel komen.
En ruwe onderdelen komen, en ze zijn samengevoegd door de montage.
En misschien is er een recall.
>> Elk deel dat werd gemaakt door dit fabrikant na deze datum,
Ik moet te trekken van mijn lijn.
Ik kan een index draaien dat zou kijken,
aggregeren op de datum van vervaardiging van dat deel.
Dus als mijn top level tafel was al gehashed door de fabrikant,
misschien was aangebracht op een deel ID, I kan een index uit die tabel te maken
zoals hash per fabrikant en varieerden op datum van productie.
En op die manier dat ik kon zeggen, iets dat werd geproduceerd tussen deze data,
Ik moet te trekken van de lijn.
Dus dat is een lokale secundaire index.
>> Deze hebben het effect van de het beperken van uw hekje ruimte.
Omdat ze co-bestonden op dezelfde opslagknooppunt,
ze beperken de hekje-toets ruimte 10 gigabytes.
DynamoDB, onder de tabellen, zal verdelen
uw tafel elke 10 gigabyte.
Wanneer je 10 optredens van de gegevens in, we ga [PHH], en we voegen een ander knooppunt.
>> We zullen niet gesplitst de LSI meerdere partities.
We zullen de tabel splitsen.
Maar we zullen niet splitsing van de LSI.
Dus dat is iets belangrijk te begrijpen
is als je zeer doet, zeer, zeer grote samenvoegingen,
dan zul je worden beperkt tot 10 gigabytes op LSIs.
>> Als dat het geval is, kunnen we Gebruik wereldwijde secondaries.
Global secondaries zijn echt een andere tafel.
Ze bestaan ​​volledig uit te de zijkant van de primaire tabel.
En ze laten me om een ​​vondst volledig andere structuur.
Dus denk aan het als gegevens worden ingebracht in twee verschillende tabellen, gestructureerde
op twee verschillende manieren.
>> Ik kan een heel definiëren verschillende hekje.
Ik kan een heel definiëren ander bereik toets.
En ik kan dit uitvoeren volledig zelfstandig.
Als een zaak van de feiten, ik heb bevoorraad mijn read capaciteit
Schrijf capaciteit voor mijn globale secundaire indexen
volledig onafhankelijk mijn primaire tabel.
Als ik te definiëren die index, ik vertel Het hoeveel lezen en schrijven
capaciteit het gaat gebruiken.
>> En dat is gescheiden van mijn primaire tabel.
Nu beide indexen ons toelaten om niet alleen definiëren hash en het bereik toetsen,
maar wij laten projecteren extra waarden.
Dus als ik wil lezen uit de index, en ik wil een aantal set van gegevens te krijgen,
Ik heb geen behoefte om terug te gaan naar de belangrijkste tabel om de extra attributen te krijgen.
Ik kan die extra projecteren attributen in de tabel
ter ondersteuning van de toegang patroon.
Ik weet dat we waarschijnlijk krijgen in sommige echt, really-- krijgen in het onkruid
hier op een aantal van dit spul.
Nu kreeg ik te drijven uit deze.
>> PUBLIEK: [onverstaanbaar] --table sleutel betekende een hash?
De oorspronkelijke hash?
Multi-lamellen?
>> RICK Houlihan: Ja.
Ja.
De tabel sleutel in principe wijst terug naar het item.
Dus een index is een pointer terug naar de oorspronkelijke items op de tafel.
Nu kunt u kiezen voor een te bouwen index die alleen de tabel sleutel,
en geen andere eigenschappen.
En waarom zou ik dat doen?
Nou ja, misschien heb ik zeer grote items.
>> Ik eigenlijk alleen moet weten which-- mijn toegang patroon zou kunnen zeggen,
welke items deze eigenschap bevatten?
Niet nodig om het item terug te keren.
Ik moet alleen weten welke items indammen.
Dus je kunt indexen bouwen dat alleen de tabel sleutel.
>> Maar dat is vooral wat een index in de database is.
Het is voor snel kunnen identificeren welke registreert,
welke rijen, waarbij items in de tafel
de eigenschappen die ik zoek.
>> GSIS, dus hoe werken ze?
GSIS principe zijn asynchroon.
De update komt in de tabel, tabel wordt vervolgens asynchroon bijgewerkt
al uw GSIS.
Dit is de reden waarom GSIS zijn uiteindelijk consistent.
>> Het is belangrijk op te merken dat als je het bouwen GSIS,
en je begrijpt u maakt een andere dimensie van aggregation--
Nu laten we zeggen een goed voorbeeld Hier is een fabrikant.
Ik denk dat ik heb gesproken over een medisch fabrikant van het apparaat.
Fabrikanten van medische hulpmiddelen vaak hebben series onderdelen.
De onderdelen die verder gaan in een heupprothese alle
een beetje serienummer erop.
En zij konden miljoenen hebben en miljoenen en miljarden onderdelen
in alle apparaten die ze verzenden.
Nou, ze moeten onder aggregeren verschillende dimensies, alle onderdelen
in een samenstel, alle onderdelen die gemaakt
op een bepaalde lijn, alle de onderdelen die kwam
vanaf een bepaalde fabrikant op een bepaalde datum.
En deze combinaties soms opstaan ​​in de miljarden.
>> Dus ik werk met een aantal van deze jongens die lijden
omdat ze creëren deze ginormous aggregaties
in hun secundaire indexen.
Ze misschien een ruwe onderdelen hebben tabel die wordt geleverd zoals alleen hash.
Elk deel heeft een uniek serienummer.
Ik gebruik het serienummer als de hash.
Het is prachtig.
Mijn ruwe data tabel is verspreid Alles over de belangrijkste ruimte.
Mijn [? schrijven ?] [? inslikken?] is geweldig.
Ik neem veel gegevens.
Dan wat ze doen is ze een GSI.
En ik zeg, weet je wat, ik moet zien alle onderdelen voor deze fabrikant.
Nou ja, ineens ben ik het nemen van een miljard rijen,
en vul ze op één knooppunt, want als
Ik aggregeren als fabrikant ID als de hash,
en een deel nummer als het bereik, dan plots ik
zetten een miljard delen in wat Deze fabrikant heeft mij verlost.
>> Dat kan veel veroorzaken druk op de GSI,
weer, want ik hameren één knooppunt.
Ik zet al deze voegt in één knooppunt.
En dat is een echte problematisch use case.
Nu, ik heb een goed ontwerp patroon voor hoe vermijd je dat.
En dat is een van de problemen dat ik werk altijd met.
Maar wat gebeurt, is de GSI misschien genoeg schrijven capaciteit hebben
kunnen duwen alle rijen in een enkel knooppunt.
En wat gebeurt er dan is het primair, de klant tafel,
de primaire tabel wordt gesmoord omdat de GSI niet kan bijbenen.
Dus mijn insert tarief vallen op de primaire tabel
zoals mijn GSI probeert te houden.
>> Oké, dus GSI's, LSI's, welke moet ik gebruiken?
LSI's consistent.
GSI's zijn uiteindelijk consistent.
Als dat is OK, adviseer ik met behulp van een GSI, ze zijn veel flexibeler.
LSI kan worden gemodelleerd als een GSI.
En als de gegevens grootte per hash sleutels in uw collectie meer dan 10 gigabyte,
dan zul je wilt gebruiken GSI want het is gewoon een harde limiet.
>> Oké, dus schaalvergroting.
De overslag in Dynamo DB, u Can bepaling [onverstaanbaar]
doorvoer naar een tafel.
We hebben klanten die hebben bevoorraad 60 billion--
doen 60 miljard verzoeken, regelmatig draait op meer dan een miljoen aanvragen
per seconde op onze tafels.
Er is echt geen theoretische limiet aan hoeveel
en hoe snel de tafel kan in Dynamo DB.
Er zijn een aantal zacht limieten op uw account
dat zetten we daar in zo dat je niet gek.
Als u meer dan wilt dat geen probleem.
Je komt ons vertellen.
We zetten de wijzerplaat.
>> Elk account is beperkt tot een bepaald niveau in elke dienst, net buiten de vleermuis
zodat de mensen niet gek krijgen zich in de problemen.
Geen limiet in grootte.
U kunt elk nummer zetten items op een tafel.
De grootte van een artikel beperkt tot 400 kilobytes per,
dat zou zijn artikel niet de attributen.
Zodat de som van alle attributen is beperkt tot 400 kilobytes.
En nogmaals, we hebben dat kleine LSI kwestie
met de 10 gigabyte limiet per hash.
Doelgroep: Kleine nummer, ik ben ontbrekende wat je me vertelt, dat is--
PUBLIEK: Oh, 400 kilobyte is de maximale grootte per stuk.
Dus een item heeft alle attributen.
Dus 400 k is de totale omvang van dat punt, 400 kilobytes.
Dus alle attributen gecombineerd, alle data
dat is in al die attributen, opgerold tot een totale grootte,
momenteel vandaag het item limiet is 400 k.
Dus nogmaals schalen, bereikt door middel van partitionering.
Doorvoer wordt bevoorraad aan tafel niveau.
En er is echt twee knoppen.
We hebben gelezen capaciteit en schrijf capaciteit.
>> Dus deze worden aangepast onafhankelijk van elkaar.
RCU's maatregel strikt consistente leest.
OK, dus als je zegt ik wil 1000 RCU's die strikt consistent,
die consistent leest.
Als je zegt ik wil uiteindelijke consistente leest,
kunt u bepaling 1000 RCU's, je gaat
om uiteindelijk 2000 consistente leest.
En de helft van de prijs voor die uiteindelijk bestaan ​​uit leest.
>> Nogmaals, gecorrigeerd onafhankelijk van elkaar.
En ze hebben de throughput-- Als u verbruikt 100% van uw afstandsbediening,
je bent niet van plan om de impact beschikbaarheid van uw rechten.
Dus ze zijn volledig onafhankelijk van elkaar.
Oké, dus een van de dingen die Ik noemde het kort werd smoren.
Throttling is slecht.
Smoren geeft slechte geen SQL.
Er zijn dingen die we kunnen doen om te helpen je smoren verlichten dat u
ervaren.
Maar de beste oplossing deze is laten we
Een blik op wat je doet, want is er een anti-patroon in het spel hier.
>> Deze dingen, dingen als niet-uniforme workloads, sneltoetsen, hot partities.
Ik ben het raken van een bepaalde toets ruimte erg moeilijk voor een bepaalde reden.
Waarom doe ik dit?
Laten we dat uit.
Ik ben het mengen van mijn hete data met koud data.
Ik laat mijn tafels enorm, maar er is echt
slechts enkele deelverzameling van de gegevens dat is echt interessant voor mij.
Dus voor logboekgegevens bijvoorbeeld veel klanten, krijgen ze loggegevens elke dag.
Ze hebben een enorme hoeveelheid loggegevens.
>> Als je gewoon dumpen alles wat log gegevens in één grote tafel, na verloop van tijd
die tafel gaat massaal te krijgen.
Maar ik ben echt alleen in geinteresseerd laatste 24 uur, de laatste zeven dagen,
de laatste 30 dagen.
Ongeacht het venster van de tijd dat ik ben geïnteresseerd in het zoeken
voor het geval dat me stoort, of Indien dat is interessant voor mij,
dat is het enige raam keer dat ik nodig heb.
Dus waarom ben ik het zetten 10 jaar ter waarde van log gegevens in de tabel?
Wat dat veroorzaakt is de tafel het fragment.
>> Het wordt enorm.
Het begint uitspreiden over duizenden nodes.
En omdat uw vermogen is zo laag, je bent
eigenlijk snelheidsbeperkende op elke zo'n afzonderlijke knooppunten.
Dus laten we gaan kijken naar hoe doen we roll die tafel over.
Hoe gaan we om die gegevens een beetje beter om deze problemen te voorkomen.
En hoe ziet dat eruit?
Dit is wat die lijkt.
Dit is wat slecht NoSQL eruit ziet.
>> Ik heb hier een sneltoets.
Als je kijkt op de zijkant hier, het zijn allemaal mijn partities.
Ik heb 16 partities hier deze bepaalde database.
We doen dit de hele tijd.
Ik dit lopen voor klanten alle tijden.
Het heet de hitte kaart.
Hitte kaart vertelt me ​​hoe je bent toegang tot uw sleutel ruimte.
En wat dit vertelt mij dat er een bepaalde hash
dat deze man houdt van een verschrikkelijk veel, want hij is
raken het echt, echt moeilijk.
>> Dus de blauwe is leuk.
We willen blauw.
We houden niet van rood.
Rood, waar de druk krijgt tot 100%.
100%, nu je gaat worden gesmoord.
Dus wanneer je zie geen rode lijnen als dit-- en het is niet alleen Dynamo DB--
elke NoSQL-database heeft dit probleem.
Er zijn anti-patronen die kunnen rijden dit soort aandoeningen.
Wat ik doe is dat ik samen met klanten deze omstandigheden te.
>> En hoe ziet dat eruit?
En dit is het krijgen van de meest van Dynamo DB throughput,
maar het is echt het krijgen het meeste uit NoSQL.
Dit is niet beperkt tot Dynamo.
Dit is definitely-- I gebruikt om te werken bij Mongo.
Ik ben bekend met vele NoSQL platforms.
Iedereen heeft deze typen van sneltoets problemen.
Om het meeste te halen uit elke NoSQL databank, in het bijzonder Dynamo DB,
u wilt de tabellen te maken waar de hash sleutel element
een groot aantal verschillende waarden, een hoge mate van belangrijkheid.
Want dat betekent dat ik aan het schrijven ben om veel verschillende emmers.
>> Hoe meer emmers ik ben schrijf, hoe waarschijnlijker
Ik ben dat schrijven belasting verspreiden of lees laden uit over meerdere nodes,
hoe meer kans dat ik een hebben hoge doorvoer op de tafel.
En dan wil ik de waarden te zijn gevraagde redelijk gelijkmatig over de tijd
en uniform willekeurig mogelijk.
Nou, dat is een soort van interessante, want ik kan niet echt
controle bij de gebruiker komen.
Zo volstaat te zeggen, als we spreiden dingen uit over de belangrijkste ruimte,
we zullen waarschijnlijk beter in vorm.
>> Er is een zekere hoeveelheid tijd levering
dat je niet gaat te kunnen controle.
Maar die zijn echt de twee dimensies die we hebben,
ruimte, toegang gelijkmatig spread, tijd, verzoeken
Invaren gelijkmatig verdeeld in de tijd.
Als deze twee voorwaarden wordt voldaan,
dan is dat wat het is gaan uitzien.
Dit is veel mooier.
We zijn hier erg blij.
We hebben een zeer zelfs de toegang patroon.
Ja, misschien heb je krijgt een weinig druk zo nu en dan,
maar niets echt te uitgebreid.
Dus het is verbazingwekkend hoe vaak, toen ik werken met klanten,
die eerste grafiek met de grote rode bar en al die lelijke gele het
all over the place, we gedaan te krijgen met de uitoefening
na een paar maanden van re-architectuur,
ze draaien exact dezelfde werklast op exact dezelfde belasting.
En dit is wat het is op zoek als nu.
Dus wat je krijgt met NoSQL is een data schema dat is absoluut
gebonden aan de toegang patroon.
>> En je kunt die gegevens schema te optimaliseren te steunen die toegang patroon.
Als je dat niet doet, dan zul je om die soorten problemen te zien
met die sneltoetsen.
>> PUBLIEK: Nou, onvermijdelijk sommige plaatsen gaan warmer dan anderen.
>> RICK Houlihan: Altijd.
Altijd.
Ja, ik bedoel er is altijd a-- en nogmaals, er is
sommige design patterns we door te komen die zal spreken over hoe je omgaat
met deze super grote aggregaten.
Ik bedoel, ik heb om ze te hebben, hoe gaan we ermee om?
Ik had een vrij goede use case dat we over praten voor.
>> Oké, dus laten we praten over sommige klanten nu.
Deze jongens zijn AdRoll.
Ik weet niet of je bent vertrouwd met AdRoll.
Je ziet ze waarschijnlijk veel van de browser.
Ze zijn ad re-targeting, ze zijn de grootste ad re-targeting bedrijf
buiten.
Ze normaal gesproken regelmatig overreden 60 miljard transacties per dag.
Ze doen meer dan een miljoen transacties per seconde.
Ze hebben een vrij eenvoudige tafel kreeg structuur, de drukste tafel.
Het is eigenlijk gewoon een hash sleutel is het koekje,
het bereik is van de demografische categorie, en dan
de derde kenmerk is de score.
>> Dus we hebben allemaal cookies in onze browser van deze jongens.
En als je naar een deelnemende handelaar,
ze eigenlijk scoren je tegenkomt verschillende demografische categorieën.
Als je naar een website en je zegt ik wil dit ad-- zien
of eigenlijk hoef je niet zeggen dat-- maar als je naar de website
ze zeggen dat je wilt deze advertentie.
En ze gaan krijgen die advertentie van AdRoll.
AdRoll kijkt u op hun tafel.
Ze vinden uw cookie.
De adverteerders vertellen hen, ik wil iemand
wie is van middelbare leeftijd, 40-jarige man, in de sport.
En zij scoren u in die demografische en ze beslissen of
dat is een goede advertentie voor jou.
>> Nu hebben ze een SLA met hun reclame aanbieders
sub-10 milliseconde bieden respons op elke aanvraag.
Dus ze gebruiken Dynamo DB voor.
Ze ons een raken miljoen aanvragen per seconde.
Ze zijn in staat om alles te doen van hun lookups, triage al die gegevens,
en krijgen dat add link terug naar die adverteerder in minder dan 10 milliseconden.
Het is echt mooi fenomenaal implementatie die ze hebben.
>> Deze jongens actually-- dit zijn de jongens.
Ik ben niet zeker of het deze jongens.
Misschien deze jongens.
Eigenlijk vertelde ons-- nee, ik denk niet dat het hen was.
Ik denk dat het iemand anders was.
Ik werkte met een de klant die me vertelde
dat nu dat ze hebben gegaan naar Dynamo DB, ze zijn
besteden meer geld aan snacks voor hun development team elke maand
dan ze uitgeven aan hun database.
Dus het zal je een geven idee van de kostenbesparingen
die je kunt krijgen in Dynamo DB is enorm.
Oké, dropcam is een ander bedrijf.
Deze man is een soort van-- als je denkt van het internet van de dingen, dropcam
is eigenlijk internet security video.
Je zet je camera die er zijn.
Camera heeft een bewegingsdetector.
Iemand komt langs, triggers een cue punt.
Camera start de opname voor een tijdje tot het geen beweging meer detecteren.
Zet die video op het internet.
>> Dropcam was een bedrijf dat is eigenlijk overgestapt naar Dynamo DB
omdat ze werden ervaren enorme groeipijnen.
En wat ze ons vertelde, plotseling petabyte aan data.
Ze hadden er geen idee van hun dienst zou zo succesvol.
Meer inkomende video dan YouTube is wat deze jongens krijgen.
Zij maken gebruik van DynamoDB te sporen alle metadata van al hun video belangrijke punten.
>> Dus ze hebben S3 emmers ze duwen alle binaire artefacten in.
En dan hebben ze Dynamo DB records
wijzen mensen die S3 drie objecten.
Wanneer ze moeten kijken naar een video, ze zoeken het record in Dynamo DB.
Ze klikt u op de link.
Ze trekken naar beneden de video van S3.
Dus dat is een soort van hoe dit eruit ziet.
En dit is rechtstreeks van hun team.
>> Dynamo DB vermindert hun levertijd voor video-events
van vijf tot 10 seconden.
In hun oude relationele winkel, ze gebruikt te hebben om te gaan en uit te voeren
meervoudige complexe queries figuur welke video's neer te halen,
tot minder dan 50 milliseconden.
Dus het is geweldig, verbazingwekkend hoeveel prestaties
je kunt krijgen als je optimaliseren en u afstemt de onderliggende databank
ter ondersteuning van de toegang patroon.
Halfbrick, deze jongens, wat is het, Fruit Ninja Ik denk dat is hun ding.
Dat alle draait op Dynamo DB.
En deze jongens, ze zijn een geweldige development team, grote ontwikkeling
winkel.
>> Niet een goede ops team.
Ze hadden niet veel van de operatie middelen.
Ze vochten proberen te houden hun applicatie-infrastructuur up
and running.
Ze kwamen naar ons.
Ze keken op dat Dynamo DB.
Ze zeiden, dat is voor ons.
Ze bouwden hun hele applicatie framework op.
Hier een aantal hele leuke reacties van het team op hun vermogen
nu richten op de bouw het spel en niet
dat u het handhaven infrastructuur, die
was steeds een enorme hoeveelheid overhead voor hun team.
Dus dit is iets dat-- de voordeel dat je krijgt van Dynamo DB.
>> Oké, het krijgen in datamodellering hier.
En we praatten een beetje over Deze 1 tot 1, 1 tot vele,
en veel te veel soort relaties.
En hoe ga je te houden die in Dynamo.
In Dynamo DB gebruiken we indexen algemeen
de gegevens van roteren één smaak naar de andere.
Hash toetsen, bereik sleutels en indexen.
>> In dit specifieke Bijvoorbeeld, de meeste staten
hebben een vergunningplicht die slechts rijbewijs één bestuurder per persoon.
Je kunt niet naar twee bestuurder te krijgen licenties in de staat van Boston.
Ik kan het niet doen in Texas.
Dat is een soort van de manier waarop het is.
En zo bij de DMV, hebben we lookups, we wilt opzoeken het rijbewijs
door het aantal sociale zekerheid.
Ik wil opzoeken van de gebruikersgegevens het rijbewijs nummer.
>> Dus kunnen we tafel van een gebruiker hebben die heeft een hash-toets op het serienummer,
of het sofi-nummer, en verschillende attributen gedefinieerd op het punt.
Nu op die tafel I een GSI kon bepalen dat
flips dat rond die zegt: ik wil een hash-toets op de vergunning en vervolgens
alle andere items.
Nu als ik wil op te vragen en vind de licentienummer voor een bepaalde sociale
-Nummer, ik kan query de hoofdtabel.
>> Als ik wil vragen en ik wil aan de sociale zekerheid te krijgen
nummer of andere kenmerken van een licentienummer, kan ik query de GSI.
Dat model is dat men op een relatie.
Slechts een zeer eenvoudige GSI, flip die dingen rond.
Nu, praten over een te veel.
Een tot vele fundamenteel je hash range sleutel.
Waar we veel met dit use case is de monitor gegevens.
Monitor gegevens komen in de reguliere interval, zoals internet van de dingen.
We hebben altijd al deze platen komen hele tijd.
>> En ik wil alle metingen vinden tussen een bepaalde tijdsperiode.
Het is een veel voorkomende vraag in bewaking infrastructuur.
De manier te gaan over dat is een vondst eenvoudige tabel structuur, één tafel.
Ik heb een tafel metingen apparaat kreeg met een hekje toets op het apparaat-ID.
En ik hebben een bereik toets op het tijdstempel, of in dit geval, de epische.
En dat maakt me complexe voeren queries tegen dat bereik sleutel
en terug te keren records die zijn ten opzichte van het resultaat
set die ik zoek.
En het bouwt dat één te veel relatie
in de primaire tabel met de hash key, range sleutel structuur.
>> Dus dat is een soort van ingebouwde in de tabel in Dynamo DB.
Toen ik een hash te definiëren en het bereik t tafel, ik ben
definieert één tot vele relatie.
Het is een ouder-kind relatie.
>> Laten we praten over de vele te veel relaties.
En dit specifieke voorbeeld, nogmaals, we gaan GSI's gebruiken.
En laten we praten over gaming scenario waar ik een bepaalde gebruiker.
Ik wil weten alle games die hij is ingeschreven voor of spelen in.
En voor een bepaald spel, I willen alle gebruikers te vinden.
Dus hoe kan ik dat doen?
Mijn gebruiker spelletjes tafel, ik ga een hash sleutel van gebruikers-ID hebben
en een reeks sleutel van het spel.
>> Zo kan een gebruiker meerdere games.
Het is een te veel relatie tussen de gebruiker en de games die hij speelt.
En vervolgens op de GSI, Ik zal dat ongeveer spiegelen.
Ik op het spel zullen hash en Ik zal variëren van de gebruiker.
Dus als ik wil alle krijgen de gebruiker het spel spelen in,
Ik zal de hoofdtabel te vragen.
Als ik wil alle gebruikers krijgen die het spelen van een bepaald spel,
Ik vraag de GSI.
Zo zie je hoe we dit doen?
Je bouwt deze GSI aan de ondersteuning use case, de toepassing, de toegang
patroon, de toepassing.
>> Als ik nodig om te vragen op deze dimensie, laat
me een index op die dimensie.
Als ik dat niet doen, kan me niet schelen.
En afhankelijk van het gebruik case, I kan de index nodig hebben of ik misschien niet.
Als het simpel voor velen, de primaire tabel is prima.
Als ik moet deze veel te doen om veel van, of ik moet een tot degenen doen,
dan misschien ik moet naar de tweede de index.
Dus het hangt allemaal af van wat ik probeer te doen
en wat ik probeer te krijgen volbracht.
>> Waarschijnlijk ben ik niet van plan om te besteden veel tijd aan het praten over de documenten.
Dit krijgt een beetje, waarschijnlijk, dieper dan we nodig hebben in te gaan.
Laten we praten een beetje over de rijke query-expressie.
Dus in Dynamo DB hebben we de mogelijkheid te creëren
wat wij noemen projectie uitdrukkingen.
Projectie uitdrukkingen zijn gewoon plukken van de velden of de waarden
die u wilt weergeven.
OK, dus ik maak een selectie.
Ik maak een query tegen Dynamo DB.
En ik zeg, weet je wat, laten zien ik alleen de vijf sterren beoordelingen
voor dit specifieke product.
Dus dat is alles wat ik wil zien.
Ik wil niet alle zien andere kenmerken van de rij,
Ik wil alleen maar om dit te zien.
Het is net als wanneer je in SQL zeggen select ster of van tafel,
je krijgt alles.
Als ik zeg select naam uit tafel, krijg ik slechts één attribuut.
Het is hetzelfde soort dingen in Dynamo DB of een andere NoSQL-databases.
Filter uitdrukkingen laat mij eigenlijk snijd de vastgelegd resultaat.
Dus ik maak een query.
Query kan terugkomen met 500 punten.
Maar ik wil alleen de items die een eigenschap die dit zegt.
OK, dus laten filteren die items die niet overeenkomt met die bepaalde query.
Dus hebben we filter uitdrukkingen.
>> Filter uitdrukkingen kan worden op elke attribuut.
Ze zijn niet zoals range queries.
Raise vragen zijn meer selectief.
Queries filter nodig mij om te gaan krijgen de volledige resultaten te stellen en vervolgens
carve out de gegevens die ik niet wil.
Waarom is dat belangrijk?
Want ik lees het allemaal.
In een query, ik ga lezen en het gaat om een ​​gigantische over gegevens.
En dan ga ik carve out wat ik nodig heb.
En als ik ben alleen uithakken van een paar rijen, dan is dat OK.
Het is niet zo inefficiënt.
>> Maar als ik het lezen van een hele stapel data, maar om uit te spitten een item,
dan ga ik beter uit met een reeks vragen,
want het is veel selectiever.
Het gaat me een hoop geld, want ik betaal voor die lezen.
Wanneer de resultaten die terugkomt kruisen die draad kleiner zou kunnen zijn,
maar ik ben te betalen voor de gelezen.
Dus begrijpen hoe je krijgt de gegevens.
Dat is heel belangrijk in Dynamo DB.
>> Voorwaardelijke uitdrukkingen, dit is wat je zou optimistische vergrendeling noemen.
Update als deze bestaat, of als deze waarde is gelijk aan wat ik opgeven.
En als ik een tijd stempel op een record, zou ik de gegevens te lezen.
Ik zou die gegevens veranderen.
Ik zou kunnen gaan schrijven dat data terug naar de database.
Als iemand heeft veranderd het record, de tijdstempel zou hebben veranderd.
En op die manier mijn voorwaardelijke -update-update kon zeggen
Als de tijdstempel gelijk aan deze.
Of de update zal mislukken omdat iemand bijgewerkt het record in de tussentijd.
>> Dat is wat we optimistische vergrendeling noemen.
Dit betekent dat iemand kunnen komen en het veranderen,
en ik ga om het te ontdekken toen ik terug te gaan om te schrijven.
En dan kan ik eigenlijk lezen dat data en zeggen: oh, dit veranderde hij.
Ik moet verklaren dat.
En ik kan de gegevens in te wijzigen mijn opnemen en een andere update.
Dus je kunt deze incrementele vangen updates die zich voordoen tussen het tijdstip
dat u de data en het lezen keer dat u misschien de gegevens te schrijven.
>> Publiek: En de filter uitdrukking betekent eigenlijk niet
van het aantal of niet--
>> [Onderbreekt hem VOICES]
RICK Houlihan: Ik zal niet krijgen te veel in deze.
Dit is een gereserveerde trefwoord.
Het pond view is een gereserveerde zoekwoord in Dynamo DB.
Elke databank heeft zijn eigen gereserveerde namen voor verzamelingen je niet kunt gebruiken.
Dynamo DB, als u opgeeft een pond tegenover dit,
kunt u die namen hierboven definiëren maximaal.
Dit is een referentie waarde.
Het is waarschijnlijk niet de beste syntaxis hebben er voor deze discussie,
want het wordt in sommige real-- Ik heb gesproken meer
daarover op een dieper niveau.
>> Maar volstaat te zeggen, deze kan zijn vraag scan waar ze views--
noch uitzicht pond groter is dan 10.
Het is een numerieke waarde, ja.
Als u wilt, kunnen we praten over dat na de discussie.
Oké, dus we krijgen in sommige scenario's in de beste praktijken
waar we heen gaan praten over een aantal apps hier.
Wat zijn de use cases voor Dynamo DB.
Wat zijn het ontwerp patronen in Dynamo DB.
>> En de eerste die we gaan praten over het internet van de dingen.
Zo krijgen we een veel van-- denk ik, wat het-- meer dan 50%
van het verkeer op het internet deze dagen eigenlijk gegenereerd door machines,
geautomatiseerde processen, niet door de mens.
Ik bedoel, dit ding dit ding dat u rond in uw zak,
hoeveel gegevens dat dat ding is eigenlijk het verzenden van rond zonder jou
wetende dat het is absoluut geweldig.
Uw locatie, informatie over hoe snel je gaat.
Hoe denk je dat Google Maps werken als ze je vertellen wat het verkeer is.
Het is omdat er miljoenen en miljoenen mensen rondrijden
met telefoons die sturen gegevens over de hele tijd plaats.
Dus een van de dingen dit soort gegevens
die wordt geleverd in, monitoren gegevens, log gegevens, tijdreeksen, is het
meestal alleen interessant voor een beetje tijd.
Na die tijd, het is niet zo interessant.
Dus spraken we over, laat die tabellen groeien zonder grenzen.
Het idee hier is dat misschien heb ik 24 uur aan de gebeurtenissen in mijn hete tafel.
En dat heet tafel gaat worden bevoorraad op een zeer hoog tempo,
omdat het nemen van een veel gegevens.
Het nemen van een veel gegevens in en ik lees het een stuk.
Ik heb veel van de operatie kreeg query's tegen deze data.
>> Na 24 uur, hey, je Weet je wat, kan me niet schelen.
Dus misschien elke middernacht Ik roll mijn tafel over naar een nieuwe tabel
en ik deprovision deze tabel.
En ik neem de afstandsbediening en WCU's neer, omdat 24 uur later
Ik ben niet actief als veel query's die gegevens.
Dus ik ga om geld te besparen.
En misschien 30 dagen later heb ik niet zelfs zorgen te maken over dit alles.
Ik kon nemen van de WCU's helemaal naar beneden naar een,
omdat je weet wat het is nooit gaat krijgen geschreven.
De gegevens zijn 30 dagen oud.
Het verandert nooit.
>> En het is bijna nooit gaat krijgen lezen, dus laten we gewoon dat RCU tot 10.
En ik ben aan het sparen een hoop geld op deze data, en alleen betalen voor mijn hete data.
Dus dat is het belangrijkste om te kijken op als je kijkt naar een tijdreeks
binnenkomende data volume.
Deze strategieën zijn.
Nu, ik kon gewoon laten gaan allemaal naar dezelfde tafel
en laat die tafel groeien.
Uiteindelijk ga ik Zie problemen met de prestaties.
Ik ga moeten beginnen te archiveren sommige van die gegevens van de tafel,
wat niet.
>> Laten we veel beter ontwerp uw aanvraag
zodat u kunt op deze manier recht te bedienen.
Dus het is gewoon automatisch in de applicatie code.
Om middernacht elke nacht rolt de tafel.
Misschien wat ik nodig heb is een glijdende raam van 24 uur aan gegevens.
Vervolgens regelmatig ik roepen gegevens van de tafel.
Ik ben het trimmen met een Cron job en ik zetten het
naar deze andere tafels, wat je nodig hebt.
Dus als een rollover werkt, dat is geweldig.
Zo niet, trim het.
Maar laten we dat heet data weg van uw koude gegevens.
Het zal bespaart u een hoop geld en maak uw tafels meer uitvoeren.
Dus het volgende wat we praten over is productcatalogus.
Productcatalogus is vrij gebruikelijk use case.
Dit is eigenlijk een veel voorkomende patroon dat we zullen zien in een verscheidenheid van dingen.
Je weet wel, Twitter voor Bijvoorbeeld, een hot tweet.
Iedereen komt en grijpen die tweet.
Productcatalogus, kreeg ik een verkoop.
Ik heb een hete verkoop.
Ik kreeg 70.000 aanvragen per wederkomst voor een product
beschrijving van mijn product catalogus.
We zien dit op de retail operatie nogal wat.
Dus hoe kunnen we gaan met dat?
Er is geen manier om te gaan met dat.
Al mijn gebruikers willen zien hetzelfde stuk van de gegevens.
Ze komen binnen, gelijktijdig.
En ze zijn allemaal het maken van verzoeken voor hetzelfde stuk van de gegevens.
Dit geeft mij dat sneltoets, die grote rode streep op mijn kaart die we niet willen.
En dat is wat die lijkt.
Dus over mijn sleutel ruimte Ik krijg gehamerd op de verkoop items.
Ik krijg niets ergens anders.
>> Hoe kan ik dit probleem te verlichten?
Nou, we deze te verlichten met cache.
Cache, in principe een zet je in-memory verdeling voor de database.
We zijn erin geslaagd [Onhoorbaar] cache, hoe je
kunt uw eigen cache, [onverstaanbaar] cache [? d,?] wat je wilt.
Zet dat aan de voorkant van de gegevensbank.
En op die manier kunt u die gegevens op te slaan van die sneltoetsen in die cache
ruimte en lezen via de cache.
>> En dan de meeste van uw leest gaan kijken als deze.
Ik heb al deze cache raakt hier en ik heb niets aan de hand hier beneden
omdat de database zit achter de cache en het leest nooit door.
Als ik de gegevens in het veranderen databank, moet ik de cache bij te werken.
We kunnen iets te gebruiken zoals stoomt om dat te doen.
En ik zal uitleggen hoe dat werkt.
Oké, messaging.
E-mail, we allemaal gebruik van e-mail.
>> Dit is een vrij goed voorbeeld.
We hebben een soort van berichten tafel.
En we kregen inbox en outbox.
Dit is wat de SQL zou kijk graag dat inbox te bouwen.
We soort gebruiken dezelfde soort van de strategie om de GSI's, gebruik maken van GSI's
voor mijn inbox en mijn outbox.
Dus ik heb ruwe berichten komen in mijn boodschappen tafel.
De eerste benadering van dit zou kunnen zijn, zeggen: OK, geen probleem.
Ik heb rauwe berichten gekregen.
Berichten komen [onhoorbaar] bericht ID, dat is geweldig.
Dat is mijn unieke hash.
Ik ga maken twee GSI's, een voor mijn inbox, één voor mijn outbox.
En het eerste wat ik doe is Ik zal zeggen dat mijn hekje is
naar de ontvanger en Ik ga om te regelen op de dag.
Dit is fantastisch.
Ik heb mijn mooi uitzicht hier.
Maar er is hier een klein probleem.
En je in deze in relationele databases ook.
Ze noemden verticaal partitionering.
U wilt uw big data te houden weg van uw weinig gegevens.
>> En de reden waarom is omdat ik moet lees dan de items om de kenmerken te krijgen.
En als mijn lichaam zijn allemaal hier, dan is het lezen van een paar artikelen
als mijn lichaam lengte is gemiddeld 256 kilobytes per,
de wiskunde wordt behoorlijk lelijk.
Zo zeg ik wil Davids inbox lezen.
David's inbox heeft 50 items.
De gemiddelde en de grootte is 256 kilobytes.
Hier is mijn conversie ratio voor RCU is vier kilobytes.
>> Oké, laten we gaan met uiteindelijk consistente leest.
Ik ben nog steeds het eten van 1600 RCU's alleen maar om David's inbox lezen.
Ouch.
OK, laten we nu denken over hoe de app werkt.
Als ik in een e-mail app en Ik kijk naar mijn inbox,
en ik kijk naar het lichaam van elk bericht, nee, ik ben op zoek naar de samenvattingen.
Ik ben op zoek naar alleen de headers.
Dus laten we bouwen aan een tafel structuur dat lijkt meer op dat.
>> Dus hier is de informatie dat mijn workflow nodig.
Het is in mijn inbox GSI.
Het is de datum, de afzender, het onderwerp, en dan
de boodschap ID, die wijst terug naar de tafel berichten
waar ik kan het lichaam te krijgen.
Nou, dit zou opnemen ID's.
Ze wijst naar de Item-id's op het Dynamo DB tafel.
Elke index altijd creates-- altijd het artikel
ID als onderdeel van-- dat wordt geleverd met de index.
>> Prima.
Publiek: Het vertelt het waar het is opgeslagen?
RICK Houlihan: Ja, het vertelt exactly-- dat is precies wat het doet.
Het zegt hier is mijn re record.
En het zal het punt terug naar mijn re record.
Precies.
OK, dus nu mijn inbox is eigenlijk veel kleiner.
En dit ook daadwerkelijk ondersteunt de workflow van een e-app.
Dus mijn inbox, ik klik.
Ik ga mee en ik klik op het bericht, dat is wanneer ik moet gaan krijgen van het lichaam,
want ik ga ga dan naar een andere mening toegedaan.
Dus als je nadenkt over MVC type kader, model view controller.
>> Het model bevat de gegevens die de behoeften view
en de controller samenwerkt met.
Toen ik het frame veranderen, wanneer Ik verander het perspectief,
het is OK om terug te gaan naar de server en herbevolken van het model,
want dat is wat de gebruiker verwacht.
Wanneer ze veranderen uitzicht, dat is wanneer we terug naar de database te kunnen gaan.
Dus e-mail, klikt u op.
Ik ben op zoek naar het lichaam.
Rondvaart.
Haal het lichaam.
>> Ik lees veel minder gegevens.
Ik ben alleen het lezen van de instanties die David heeft toen hij ze nodig heeft.
En ik ben niet branden in 1600 RCU's alleen maar om zijn inbox zien.
Dus nu dat-- dit is de manier dat LSI of GSI-- Het spijt me,
GSI, zou werken.
We hebben onze hash op de ontvanger.
We hebben het bereik toets op de datum.
En we hebben de verwachte attributen gekregen dat we alleen om de weergave te ondersteunen.
>> We draaien dat de outbox.
Hash op afzender.
En in wezen we de zeer mooi, schoon uitzicht.
En het is basically-- we hebben deze mooie berichten
tabel die wordt mooi omdat er verspreid het is alleen hash, hash bericht ID.
En we hebben twee indexen die roteren off van die tabel.
Oké, dus idee hier is dat niet houd de big data en dit kleine data
samen.
Partitie verticaal partitie die tabellen.
Geen gegevens niet lezen je niet hoeft te doen.
Oké, gaming.
We allemaal graag spelen.
Tenminste ik graag spelen toen.
Dus sommige van de dingen dat we omgaan met wanneer
we denken over gaming, toch?
Gaming deze dagen, met name mobiele gaming, is alles over denken.
En ik ga hier een roteren beetje uit de buurt van DynamoDB.
Ik ga in te brengen enkele discussie
rond sommige AWS andere technologieën.
>> Maar het idee over gaming is om na te denken over in termen van API's, API's die zijn,
in het algemeen, HTTP en JSON.
Het is hoe mobiele games soort interactie met hun achtereinden.
Ze doen JSON posting.
Ze krijgen van gegevens, en het is allemaal, in het algemeen, in een mooie JSON API's.
>> Dingen zoals krijgen vrienden, krijgen het leaderboard, uitwisseling van gegevens,
door gebruikers gegenereerde inhoud, terugzet naar het systeem,
deze zijn soort dingen dat we gaan doen.
Binaire troef data, deze data misschien niet zitten in de database.
Dit kan in een zitten object op te slaan, toch?
Maar de database gaat uiteindelijk vertellen het systeem,
het vertellen van de applicatie waar te gaan krijgen.
En onvermijdelijk, multiplayer servers, back-end infrastructuur,
en ontworpen voor hoge beschikbaarheid en schaalbaarheid.
Dus dit zijn dingen die we allemaal willen in de gaming-infrastructuur vandaag.
>> Dus laten we een kijkje nemen op hoe dat eruit ziet.
Kreeg een kern back-end, zeer eenvoudig.
We hebben een systeem heb hier met meerdere beschikbaarheid zones.
We spraken over AZS als being-- denken van hen als aparte datacenters.
Meer dan een datacenter per AZ, maar dat is OK,
denk maar aan hen als afzonderlijke gegevens centra die geografisch
en storingen geïsoleerd.
>> We gaan naar een hebben paar EC2 gevallen.
We gaan te hebben sommige back-end server.
Misschien als je een erfenis architectuur, we zijn
met behulp van wat we RDS noemen, relationele database services.
Zou kunnen zijn MSSQL, MySQL, of zoiets.
Dit is zo veel toepassingen zijn ontworpen vandaag.
>> Goed we zouden willen gaan met dit is wanneer we schaal uit.
We zullen verder gaan en zet de S3 emmer daar.
En dat S3 emmer, in plaats van het dienen up die objecten uit onze servers--
we dat konden doen.
Je al je binaire objecten op uw servers
en u kunt deze server gebruiken instanties die gegevens up dienen.
Maar dat is vrij duur.
>> Betere manier om te doen is ga je gang en zet de objecten in een S3 emmer.
S3 is een object repositories.
Het is speciaal gebouwd voor waar je van dit soort dingen.
En laat die cliënten te vragen rechtstreeks vanuit die voorwerp emmers,
offload de servers.
Dus we beginnen hier te schalen.
>> Nu kregen we gebruikers over de hele wereld.
Ik heb gebruikers.
Ik moet de inhoud lokaal hebben dicht bij deze gebruikers, toch?
Ik heb een S3 emmer gemaakt zoals mijn bron repository.
En ik zal dat met de voorzijde de CloudFront distributie.
>> CloudFront is een cd en een content delivery network.
In principe de gegevens die u opgeeft neemt en slaat het allemaal via internet
zodat gebruikers overal kunnen hebben een zeer snelle reactie bij
zij verzoeken die objecten.
>> Zo krijg je een idee.
Je soort hefboomwerking alle aspecten van AWS hier om dit gedaan.
En uiteindelijk, we gooien in een automatische schaling groep.
Dus onze AC2 gevallen van onze game servers,
als ze beginnen te krijgen drukker en drukker en drukker,
zullen ze gewoon een andere spin- Zo draaien een ander voorbeeld,
draaien een ander voorbeeld.
Dus de techniek AWS heeft het kunt u de parameters opgeven
waarrond uw servers zal groeien.
Dus je kunt n aantal servers er op een bepaald moment.
En als uw lading weg gaat, zullen ze krimpt, zal het aantal krimpen.
Als de belasting terugkomt, het zal weer groeien, elastisch.
>> Dus dit ziet er geweldig uit.
We hebben veel van EC2 gevallen.
We kunnen cache zetten in voorzijde van de databases,
proberen en versnellen van de databases.
De volgende drukpunt meestal mensen zien
is deze schaal een spel met behulp van een relationeel databanksysteem.
Jeez, de database prestaties is verschrikkelijk.
Hoe kunnen we dat verbeteren?
Laten we eens proberen cache in de voorkant van dat.
>> Nou, cache werkt niet zo groot in games, toch?
Voor games, schrijven is pijnlijk.
Games zijn zeer zwaar te schrijven.
Cache werkt niet als je schrijf zwaar want je hebt altijd
kreeg om de cache te werken.
U het actualiseren van de cache, het is irrelevant te cachen.
Het is eigenlijk gewoon extra werk.
>> Dus waar we hier gaan?
Je hebt een grote bottleneck gekregen beneden in de database.
En de plek om te gaan uiteraard is partitioneren.
Partitioneren is niet makkelijk te doen als je
omgaan met relationele databases.
Met relationele databases, je bent verantwoordelijk voor het beheer, effectief
de sleutel ruimte.
Je zegt dat gebruikers tussen A en M ga hier, tussen N en Z gaan daar.
En je overschakelen over de toepassing.
Dus je mee bezig bent deze partitie gegevensbron.
Je hebt transactionele beperkingen die geen partities overspannen.
Je hebt allerlei gekregen messiness dat je
omgaan met daar beneden proberen om te gaan met scaling out
en opbouwen van een grotere infrastructuur.
Het is gewoon niet leuk.
>> Publiek: Dus zeg je dat toenemende bron punten versnelt
het proces?
RICK Houlihan: Verhoging?
PUBLIEK: Source punten.
RICK Houlihan: Source punten?
Publiek: Uit de informatie, waar de informatie vandaan komt?
RICK Houlihan: No.
Wat ik wil zeggen is het verhogen van de aantal partities in de gegevens op te slaan
verbetert de doorvoer.
Dus wat hier gebeurt is gebruikers komen in de EC2 bijvoorbeeld hier,
goed, als ik een gebruikersnaam Dat is een aan M, zal ik hier te gaan.
Van N naar p, zal ik hier te gaan.
Van P tot Z, zal ik hier te gaan.
>> Publiek: OK, degenen dus die zijn allemaal opgeslagen in verschillende knooppunten?
>> RICK Houlihan: Ja.
Denk aan deze als verschillende silo's van gegevens.
Dus je hoeft te doen.
Als je probeert te doen dit, als je probeert
op schaal op een relationeel platform, dit is wat je doet.
Je neemt data en je bent te snijden naar beneden.
En je bent te partitioneren over meerdere exemplaren van de database.
En u bent het beheren van al die bij de toepassing tier.
Het is niet leuk.
Dus wat willen we gaan?
We willen gaan DynamoDB, volledig beheerde, NoSQL gegevens op te slaan, bepaling doorvoer.
We maken gebruik van secundaire indexen.
Het is eigenlijk HTTP API en omvat document ondersteuning.
U hoeft dus geen zorgen te maken over een van die verdeling.
We doen het allemaal voor u.
Dus nu, in plaats daarvan kun gewoon schrijven naar de tafel.
Wanneer de tafel moet worden verdeeld, dat gebeurt achter de schermen.
Je bent volledig geïsoleerd uit die als ontwikkelaar.
Dus laten we praten over enkele use cases
dat we tegenkomen in gaming, gemeenschappelijke gaming scenario's leaderboard.
Dus je hebt gebruikers komen, de BoardNames dat ze
op de scores voor deze gebruiker.
We misschien hashing op het gebruikers-ID, en dan hebben we range op het spel.
Zodat iedere gebruiker wil zien al het spel dat hij gespeeld
en al zijn hoogste score in alle het spel.
Dus dat is zijn persoonlijke leaderboard.
>> Nu wil ik gaan en ik wil get-- dus ik krijg deze persoonlijke leaderboards.
Wat ik wil doen is gaan halen de hoogste score in alle gebruikers.
Dus hoe kan ik dat doen?
Toen mijn record is gehashed op de gebruikers-ID, varieerden van het spel,
nou ik ga om verder te gaan en te herstructureren, het creëren van een GSI,
en ik ga om die gegevens te herstructureren.
>> Nu ga ik hash op de BoardName, wat het spel.
En ik ga liggen op de hoogste score.
En nu heb ik verschillende emmers gemaakt.
Ik gebruik dezelfde tafel, dezelfde artikelgegevens.
Maar ik ben het creëren van een emmer dat geeft me een samenvoeging van de top scoren spel.
>> En ik kan die tafel opvragen om die informatie te krijgen.
Dus ik heb ingesteld die vraag patroon tot worden ondersteund door een secundaire index.
Nu kunnen ze worden gesorteerd per BoardName en gesorteerd topscore afhankelijk.
Zodat u kunt zien, zijn dit soort van use cases je in gaming.
Een ander goed gebruik voor het geval we krijgen in gaming is awards en wie won de awards.
En dit is een geweldige use case waar we noemen schaars indexen.
Schaars indexen zijn de mogelijkheid bieden tot het
een index die niet noodzakelijkerwijs bevatten elk punt op de tafel.
En waarom niet?
Omdat het attribuut dat wordt geïndexeerde bestaat niet op elk punt.
>> Dus in dit specifieke use case, ik zeg,
weet je wat, ik ga maak een attribuut genaamd Award.
En ik ga elke gebruiker te geven dat heeft een onderscheiding die toeschrijven.
Gebruikers die niet over awards zijn niet van plan om dat attribuut.
Dus wanneer ik de index, de enige gebruikers
die gaan tonen in de index zijn
degenen die daadwerkelijk awards hebben gewonnen.
Dus dat is een geweldige manier om te kunnen gefilterd indexen te creëren dat
zijn zeer, zeer selectief die dat niet doen moet index de hele tabel.
>> Dus we weinig tijd om hier.
Ik ga om te gaan en sla uit en sla dit scenario.
Praat een beetje about--
>> PUBLIEK: Kan ik een snelle vraag stellen?
Een daarvan is te schrijven zwaar?
RICK Houlihan: Wat is?
Publiek: Schrijf zwaar.
RICK Houlihan: Schrijf zwaar.
Even kijken.
>> Publiek: Of is dat niet iets wat je kunt gewoon
stem binnen enkele seconden?
RICK Houlihan: We gaan door middel van de stemming scenario.
Het is niet zo erg.
Hebben jullie een paar minuten?
OK.
>> Dus we praten over de stemming.
Zo echt tijd stemmen, hebben we vereisten voor de stemming.
Vereisten zijn dat we toestaan elke persoon slechts één keer stemmen.
We willen niemand in staat zijn om hun stem te veranderen.
We willen real-time aggregatie en analytics voor demografie
dat we gaan worden tonen aan gebruikers op de site.
>> Denk aan dit scenario.
We werken veel van de werkelijkheid Tv-programma's waar ze
het doen van deze exacte aard van de dingen.
Zo kunt u denken aan het scenario, We hebben miljoenen en miljoenen
tienermeisjes er met hun mobiele telefoons
en stemmen, en stemmen, en stemmen voor wie ze ook zijn
vinden van de meest populair.
Dit zijn dus enkele eisen we opraken.
>> En dus is de eerste te nemen in oplossen van dit probleem
zou een te bouwen zeer eenvoudige toepassing.
Dus ik heb deze app.
Ik heb een aantal kiezers die er zijn.
Ze komen, ze sloeg de stemming app.
Ik heb wat rauwe stemmen tafel kreeg Ik zal gewoon dumpen die stemmen in.
Ik zal wat totaal hebben stemmen tafel
zal mijn analytics en demografie doen, en we zullen dit er allemaal in te zetten.
>> En dit is geweldig.
Het leven is goed.
Het leven is goed, totdat we erachter komen dat er is altijd slechts één of twee
mensen die populair zijn bij een verkiezing.
Er is slechts één of twee dingen dat mensen echt zorgen over.
En als je in de stemming schaal, ineens ben ik
gaat worden hameren de hel uit twee kandidaten, één of twee kandidaten.
Een zeer beperkt aantal artikelen mensen vinden populair.
>> Dit is niet een goed ontwerp patroon.
Dit is eigenlijk een zeer slecht ontwerp patroon
omdat daarmee precies wat we sprak over die sneltoetsen was.
Sneltoetsen zijn iets wat we niet willen.
>> Dus hoe kunnen we dat oplossen?
En echt, de manier om dit op te lossen is door het nemen van de kandidaat-emmers
en voor elke kandidaat wij, we gaan naar een willekeurige waarde toevoegen,
iets dat we kennen, willekeurige waarde tussen één en 100,
tussen 100 en 1000, of één tot 1000,
echter veel willekeurige waarden die u wilt voeg op het einde van die kandidaat.
>> En wat heb ik dan gedaan?
Als ik met de kandidaat-ID als de emmer te aggregeren stemmen,
als ik heb toegevoegd een willekeurige nummer aan het einde van die,
Ik heb gemaakt nu 10 emmers, een honderd emmers, duizend emmers
dat ik het aggregeren van stemmen over.
>> Dus ik heb miljoenen en miljoenen, en miljoenen records komen
voor deze kandidaten, ik ben nu verspreiden die stemmen over de kandidaat A_1
door middel van Kandidaat A_100, omdat elke keer een stemming komt,
Ik ben het genereren van een willekeurige waarde tussen één en 100.
Ik tacking het op het einde van de kandidaat die persoon te stemmen voor.
Ik dumpen het in die emmer.
>> Nu aan de achterzijde, ik weet dat ik honderd emmers.
Dus als ik wil gaan en aggregeren van de stemmen,
Ik lees van al die emmers.
Dus ik ga je gang en voeg.
En dan heb ik het scatter verzamelen waar ik naar buiten en zeggen hey,
weet je wat, deze kandidaat sleutel ruimten is meer dan honderd emmers.
Ik ga om te verzamelen alle stemt van die honderd emmers.
Ik ga om te aggregeren hen en ik ga zeggen,
Een kandidaat heeft nu totale stem meetellen van x.
>> Nu zowel de schrijf query en de lees vraag
zijn mooi verdeeld want ik ben over het schrijven
en ik lees over honderden sleutels.
Ik ben niet schrijven en lezen over een sleutel nu.
Dus dat is een groot patroon.
>> Dit is in feite waarschijnlijk een van de belangrijkste ontwerp
patronen voor schaal in NoSQL.
U vindt deze soort te zien ontwerp patroon in elke smaak.
MongoDB, DynamoDB, doet het niet materie, we hebben allemaal om dit te doen.
Want als je te maken hebt met die enorme samenvoegingen,
moet je een manier om spreid ze uit over emmers.
Dus dit is de manier waarop je dat doet.
Oké, dus wat je nu aan het doen bent
wordt je de handel af te lezen kosten voor schrijven schaalbaarheid.
De kosten van mijn lezen is wat complexer
en ik moet gaan lezen uit een Honderd emmers in plaats van één.
Maar ik ben in staat om te schrijven.
En mijn throughput, mijn schrijven throughput is ongelooflijk.
Dus het is meestal een waardevolle techniek voor het schalen DynamoDB,
of een NoSQL-database voor die kwestie.
Dus we dachten hoe het te schalen.
En we dachten hoe elimineren onze sneltoetsen.
En dit is fantastisch.
En we hebben dit mooie systeem.
En het is ons gegeven zeer correct stemming want we hebben opname stem de-dupe.
Het is gebouwd in DynamoDB.
We spraken over voorwaardelijke rechten.
>> Wanneer een kiezer binnenkomt, zet een insert op de tafel,
ze te voegen met hun kiezers ID, als ze proberen naar een andere stem in te voegen,
Ik doe een voorwaardelijke schrijven.
Alleen maar zeggen dit schrijf als dit niet bestaat.
Dus zodra ik zie dat dat de stemming spatte uiteen op de tafel,
niemand anders gaat worden in staat zijn om hun stem uit te brengen.
En dat is fantastisch.
En we zijn het verhogen onze kandidaat tellers.
En we doen ons demografie en dat alles.
Maar wat gebeurt er als mijn toepassing valt over?
Nu ineens stemmen zijn komst, en ik
weet niet of ze krijgen verwerkt in mijn analytics en demografie
meer.
En wanneer de toepassing komt een back-up, hoe
de hel weet ik wat stemmen hebben verwerkt en waar moet ik beginnen?
>> Dus dit is echt een probleem als je beginnen te kijken naar dit soort scenario.
En hoe kunnen we dat oplossen?
We lossen het met wat we noemen DynamoDB Streams.
Streams is een tijd besteld en gepartitioneerd change log van elke toegang
naar de tafel, elke schrijven toegang tot de tafel.
Alle gegevens die is geschreven aan de tabel laat zien op de stream.
>> Het is eigenlijk een 24 uurs wachtrij.
Items raakte de beek, ze leven voor 24 uur.
Ze kunnen meerdere keren worden gelezen.
Gegarandeerd te leveren slechts één keer naar de beek,
kon n aantal keer worden gelezen.
Dus hoe veel processen u wilt verbruiken die gegevens, kunt u deze verbruikt.
Het zal elke update verschijnen.
Elke write zal alleen verschijnen eenmaal op de stream.
U hoeft dus geen zorgen te maken over verwerken tweemaal
van hetzelfde proces.
>> Het is strikt besteld per stuk.
Wanneer we de tijd te zeggen besteld en verdeeld,
zie je per partitie op de stream.
Je krijgt punten, updates te zien in orde.
We zijn niet garanderen Op de stroom die je
gaan om elke transactie te krijgen in de volgorde waarin over items.
>> Dus streams zijn idempotent.
Weten we weten allemaal wat idempotent betekent?
Idempotent betekent dat u kunt doen over, en over, en weer.
Het resultaat zal hetzelfde zijn.
>> Streams zijn idempotent, maar ze moeten
afgespeeld vanaf het beginpunt, waar je maar wilt, tot het einde,
of ze zullen niet resulteren in dezelfde waarden.
>> Hetzelfde met MongoDB.
MongoDB een construct zij noemen de oplog.
Het is precies hetzelfde construct.
Veel NoSQL-databases hebben dit construct.
Ze gebruiken het om dingen te doen zoals replicatie, die
is precies wat we doen met beekjes.
PUBLIEK: Misschien een ketterse vraag, maar u
praten over apps doet hij een enzovoort.
Worden streams gegarandeerd nooit mogelijk naar beneden gaan?
RICK Houlihan: Ja, stromen zijn gegarandeerd nooit naar beneden gaan.
Wij beheren de infrastructuur achter. stromen automatisch
implementeren in hun auto scaling-groep.
We gaan door middel van een klein beetje over wat er gebeurt.
>> Ik zou niet zeggen dat ze niet gegarandeerd nooit naar beneden gaan.
De elementen worden gegarandeerd te verschijnen in de beek.
En de stroom zal toegankelijk zijn.
Dus wat naar beneden gaat of komt terug up, dat gebeurt eronder.
Het Covers het is OK.
Oké, dus je anders krijgt types weergave van het scherm af.
De types dat een belangrijk zijn programmeur meestal zijn, wat was het?
Ik krijg het oude uitzicht.
Wanneer er een update raakt de tafel, het zal duwen de oude het oog op de stroom
zodat gegevens kunnen archiveren, of wijzigen controle, identificatie change, change
beheer.
>> Het nieuwe beeld, wat het nu is na de update, dat is een ander type weergave
je kan krijgen.
U kunt zowel de oude en nieuwe beelden.
Misschien wil ik ze allebei.
Ik wil zien wat het was.
Ik wil zien wat er veranderd is.
>> Ik heb een soort naleving van het proces dat loopt.
Het moet om te controleren of wanneer deze dingen te veranderen,
dat ze binnen bepaalde grenzen of binnen bepaalde parameters.
>> En dan alleen ik misschien moet weten wat er veranderd is.
Kan me niet schelen wat punt gewijzigd.
Ik heb geen behoefte om te weten Wat veranderde attributen.
Ik moet gewoon weten dat de producten worden aangeraakt.
Dus dit zijn de soorten bekeken dat je uit de stroom
en je kunt communiceren met.
>> De toepassing die verbruikt de stroom,
Dit is een soort van de manier waarop dit werkt.
DynamoDB klant vragen om druk data naar de tafels.
Streams zetten op wat we scherven noemen.
Scherven worden geschaald onafhankelijk van de tabel.
Ze niet helemaal line-up om de partities van uw tafel.
De reden waarom omdat ze rechtgetrokken
de capaciteit, de huidige capaciteit van de tafel.
>> Zij zetten in hun eigen auto-scaling-groep,
en ze beginnen uit te spinnen, afhankelijk hoeveel schrijft binnenkomen,
hoeveel reads-- echt het schrijft.
Er is geen reads-- maar hoe veel schrijft binnenkomen.
>> En dan op de rug Uiteindelijk hebben we wat we
bel een KCL of Kinesis Client Library.
Kinesis is een stroom data processing technologie van Amazon.
En beken is gebouwd op dat.
>> Zodat je gebruik maken van een KCL enabled toepassing om de stroom te lezen.
Kinesis Client Library eigenlijk beheert de werknemers voor u.
En het heeft ook een aantal Interessante dingen.
Het zal sommige tabellen te maken up in uw DynamoDB tablespace
waarin items bijhouden zijn verwerkt.
Dus op deze manier als het valt terug, als het valt over en komt en krijgt
stond back-up, kan het bepalen waar was het verwerken van de stroom.
>> Dat is heel belangrijk wanneer je praat over replicatie.
Ik moet weten wat gegevens werden verwerkt
en welke gegevens nog worden verwerkt.
Dus de KCL bibliotheek voor streams zal geven je een heleboel van die functionaliteit.
Het zorgt ervoor dat al het huishouden.
Het staat op een werknemer voor elke scherf.
Het creëert een administratieve tafel voor elke scherf, voor iedere werknemer.
En als die werknemers brand, ze te behouden die tabellen
zodat u weet dat dit record werd gelezen en verwerkt.
En dan op die manier als het proces sterft en komt weer online,
het kan hervatten op de plaats waar het nam af.
>> Dus we dit gebruiken voor cross-regio replicatie.
Veel klanten de noodzaak gegevens of delen van hun gegevens verhuizen tafels
rond naar verschillende regio's.
Er zijn negen regio over de hele wereld.
Dus er een need-- ik misschien kunnen gebruikers in Azië, gebruikers
in de oostkust van de Verenigde Staten.
Ze hebben verschillende gegevens die moet lokaal worden verspreid.
En misschien een gebruiker vliegt van Azië naar de Verenigde Staten,
en ik wil repliceren zijn gegevens met hem.
Dus als hij uit het vliegtuig, heeft hij een goede ervaring met zijn mobiele app.
>> U kunt de cross-regio gebruiken replicatie bibliotheek om dit te doen.
Eigenlijk we mits twee technologieën.
Eén is een console applicatie die u kunt staan ​​op uw eigen EC2 bijvoorbeeld.
Het loopt pure replicatie.
En toen gaven we u de bibliotheek.
De bibliotheek die u kunt gebruiken om te bouwen uw eigen applicatie als u
willen gekke dingen doen met die data-- filter, repliceren slechts een deel ervan,
draai de gegevens verplaatsen naar een andere tabel, enzovoort, enzovoort.
Dus dat is een soort van hoe dat eruit ziet.
>> DynamoDB Streams kan worden verwerkt door wat wij noemen Lambda.
We hebben het een beetje over evenement gedreven applicatie architecturen.
Lambda is een belangrijk onderdeel van.
Lambda is code die branden op aanvraag in reactie op een bepaalde gebeurtenis.
Een van die gebeurtenissen zou een opnemen die op de stream.
Als een record wordt weergegeven op de stroom, we zullen deze Java-functie aan te roepen.
Nou, dit is JavaScript en Lambda ondersteunt Node.js, Java, Python,
en zal binnenkort te ondersteunen andere talen.
En het volstaat te zeggen, het is pure code.
schrijven in Java, een klasse te definiëren.
Je duwt de JAR omhoog in Lambda.
En dan aangeven welke klasse je te roepen in respons op welk geval.
En dan de Lambda-infrastructuur achter die zal dat code uit te voeren.
>> Die code kan verwerken registers van de beek.
Het kan om het even wat hij wil mee doen.
In dit specifieke voorbeeld, alles wat we zijn eigenlijk doet is het loggen van de attributen.
Maar dit is gewoon code.
Code kan niets doen, toch?
>> Dus je kunt die gegevens draaien.
U kunt een afgeleide weergave maken.
Als het een document structuur, U kunt de structuur plat.
U kunt alternatieve indexen creëren.
Allerlei dingen die je kunt maken met de DynamoDB Streams.
>> En echt, dat is wat die lijkt.
Zo krijg je de updates komen.
Ze komen uit de string.
Ze worden gelezen door de Lambda functie.
Ze draaien van de gegevens en duwen in afgeleide tabellen,
kennisgeving externe systemen van verandering, en duwen gegevens in ElastiCache.
>> We spraken over hoe de cache te zetten voor de database die de verkoop
scenario.
Tja, wat gebeurt er als ik actualiseren het item beschrijving?
Nou, als ik had een Lambda functie die op die tafel,
als ik het updaten van het item beschrijving, het zal pick-up het record van de stroom,
en het zal de ElastiCache actualiseren Bijvoorbeeld met de nieuwe gegevens.
Dus dat is een heleboel wat we doen met Lambda.
Het is glue code, connectoren.
En het eigenlijk geeft het vermogen om te starten
en zeer complexe applicaties zonder een dedicated server
infrastructuur, die is echt cool.
>> Dus laten we gaan terug naar onze real-time de stemming architectuur.
Dit is nieuw en verbeterd onze beken en KCL enabled applicatie.
Hetzelfde als voorheen, we kunnen handvat elke schaal van de verkiezingen.
We dit leuk.
We doen uit scatter verzamelt over meerdere emmers.
We hebben optimistische vergrendeling gaande.
We kunnen onze kiezers houden van het veranderen van hun stemmen.
Ze kunnen alleen maar één keer stemmen.
Dit is fantastisch.
Real-time fouttolerantie, schaalbare aggregatie nu.
Als het ding omvalt, is het weet waar om zichzelf opnieuw op te starten
als het gaat terug omdat we gebruiken de KCL app.
En dan kunnen we ook gebruik maken van dat KCL verzoek om gegevens uit te duwen
om Redshift voor andere app analytics, of het gebruik
de Elastic MapReduce te lopen real-time streaming aggregaties off
van die data.
>> Dus dit zijn dingen die we hebben niet gesproken over veel.
Maar ze zijn extra technologieën die komen
te dragen als je op zoek bent deze soort scenario.
>> Oké, dus dat is over analytics met DynamoDB Streams.
U kunt de-dupe te verzamelen data, doen allerlei
van mooie spullen, geaggregeerde gegevens in geheugen, maken deze afgeleide tabellen.
Dat is een enorme use case dat veel klanten
betrokken zijn bij, waarbij de geneste eigenschappen van de JSON-documenten
en het creëren van extra indexen.
>> We zijn aan het einde.
Dank u voor het dragen met mij.
Dus laten we praten over referentie-architectuur.
DynamoDB zit in het midden van zo veel van de AWS infrastructuur.
In principe kunt u deze aansluiten tot alles wat je wilt.
Applicaties gebouwd met behulp van Dynamo omvatten Lambda, ElastiCache, CloudSearch,
duw de gegevens uit in Elastic MapReduce, import export van DynamoDB
in S3, allerlei workflows.
Maar waarschijnlijk de beste ding om te praten over,
en dit is wat echt interessant is wanneer we
praten over event-driven applicaties.
>> Dit is een voorbeeld van een intern project
dat we hebben waar we zijn eigenlijk publiceren om onderzoeksresultaten te verzamelen.
Dus in een e-mail link die we sturen, zal er
een beetje koppeling zeggen klik Hier te reageren op het onderzoek.
En wanneer een persoon klikken die verwijzen, wat er gebeurt
is ze pull-down een beveiligde HTML enquêteformulier van S3.
Er is geen server.
Dit is slechts een S3 object.
>> Dit formulier komt, laadt in de browser.
Het heeft Backbone.
Het heeft complexe JavaScript dat het draait.
Dus het is zeer rijk applicatie die in de browser van de klant.
Ze weten niet dat ze niet interactie met een back-end server.
Op dit punt, het is allemaal browser.
>> Zij publiceren de resultaten van wat we de Amazone API Gateway noemen.
API Gateway is gewoon een web API die u kunt definiëren en haak
in wat u wilt.
In dit specifieke geval, we zijn aangesloten op een Lambda functie.
>> Dus mijn POST-bewerking is gebeurt zonder server.
In feite dat API Gateway zit daar.
Het kost me niets totdat de mensen begin met het publiceren om het, toch?
De Lambda functie zit daar gewoon.
En het kost me niets, totdat mensen beginnen te raken.
Zodat u kunt zien, omdat het volume toeneemt, dat is wanneer de kosten komen.
Ik ben niet het draaien van een server 24/7.
>> Dus ik trek de vorm naar beneden uit de emmer,
en ik post via de API Toegangspoort tot de Lambda functie.
En dan de Lambda functie zegt, weet je
wat, heb ik een aantal PIIS kreeg, wat persoonlijk identificeerbare informatie
in deze reacties.
Ik kreeg reacties uit gebruikers.
Ik heb e-mailadressen.
Ik heb gebruikersnamen.
>> Laat me dit af te splitsen.
Ik ga wat te genereren metadata uit dit record.
En ik ga het duwen metadata in DynamoDB.
En ik kon alle data te versleutelen en duw hem in DynamoDB als ik wil.
Maar het is makkelijker voor mij, in dit use case, om verder te gaan van een woord,
Ik ga naar de ruwe data te duwen in een versleutelde S3 emmer.
Dus ik gebruik gebouwd in S3 server side encryptie en Key Management Amazon's
Service dus dat ik een sleutel die kan roteren op regelmatige interval,
en ik kan dat PII gegevens te beschermen als onderdeel van dit hele workflow.
>> Dus wat heb ik gedaan?
Ik heb net ingezet geheel toepassing, en ik heb geen server.
Dus is wat event driven applicatie architectuur voor je doet.
>> Nu, als u denkt over de use case voor dit--
we hebben andere klanten Ik heb het om over exacte architectuur die
gerund fenomenaal grote campagnes, die zijn op zoek naar deze en gaan, oh my.
Omdat nu, kunnen zij Duw het in principe die er zijn,
laat die campagne gewoon zitten daar tot lanceert, en niet
moet je een figuur maken over wat voor infrastructuur
gaat om daar te zijn om het te ondersteunen.
En dan zo snel die campagne wordt gedaan,
het is als de infrastructuur gewoon direct gaat weg
want er echt is geen infrastructuur.
Het is enkel code die zit op Lambda.
Het is gewoon de gegevens die zit in DynamoDB.
Het is een geweldige manier om applicaties te bouwen.
>> Publiek: Dus is het meer efemere dan het zou zijn
als het werd opgeslagen op een echte server?
>> RICK Houlihan: Absoluut.
Want dat serverinstantie zou een 7/24 zijn.
Het moet beschikbaar zijn somebody reageren.
Nou wat denk je?
S3 is beschikbaar 24/7.
S3 reageert altijd.
En S3 is zeer, zeer goed op waar je van objecten.
Deze objecten kunnen HTML bestanden, of JavaScript-bestanden, of wat je wilt.
U kunt zeer rijke webapplicaties draaien uit S3 emmers, en de mensen doen.
>> En dus dat is het idee hier is om uit de buurt van de weg te krijgen
we gebruikt om te denken over.
We hebben allemaal gebruikt om te denken in het gebied van servers en hosts.
Het gaat niet om dat niet meer.
Het gaat over de infrastructuur als code.
Implementeren van de code naar de cloud en laat de cloud draaien voor u.
En dat is wat AWS probeert te doen.
>> Publiek: Dus je gouden kist in het midden van de API Gateway is niet server-achtige,
maar in plaats daarvan is gewoon--
>> RICK Houlihan: U kunt denken het als server gevel.
Al is het is het zal een HTTP nemen aanvragen en toewijzen aan een ander proces.
Dat is alles wat het doet.
En in dit geval, we in kaart brengen aan een Lambda functie.
Oké, dus dat is alles wat ik heb.
Veel dank.
Ik waardeer dat.
Ik weet dat we een beetje in de tijd.
En hopelijk hebben jullie een beetje van informatie
dat u vandaag weg kan nemen.
En ik verontschuldig me als ik ging over een aantal van uw hoofd,
maar er is een goede hoop fundamentele fundamentele kennis
dat ik denk dat is zeer waardevol voor je.
Ik dank u voor het hebben van mij.
[APPLAUS]
PUBLIEK: [onverstaanbaar] is wanneer je zegt
je moest gaan door het ding vanaf het begin tot het einde
om de juiste waarden te krijgen of dezelfde waarden,
hoe zou de waarden veranderen als [onverstaanbaar].
>> RICK Houlihan: Oh, idempotent?
Hoe zou de waarden veranderen?
Nou, want als ik niet lopen het helemaal tot het einde,
dan weet ik niet welke veranderingen werden gemaakt in de laatste mijl.
Het gaat niet om het te dezelfde gegevens als wat ik zag.
PUBLIEK: Oh, dus je gewoon hebben niet de gehele ingang gekregen.
RICK Houlihan: Recht.
Je moet gaan van het begin tot het einde, en dan is het
gaan naar een consistente staat.
Koel.
>> Publiek: Dus u ons toonde DynamoDB kan document of de sleutel waarde te doen.
En we brachten veel tijd op de sleutelwaarde met een hash en wegen
om het te spiegelen rond.
Als je keek naar die tabellen, is dat achterlating van het document aanpak?
>> RICK Houlihan: Ik zou het niet zeggen dat het verlaten van het achter.
>> Publiek: Ze werden gescheiden van the--
>> RICK Houlihan: Met het document aanpak, het type document in DynamoDB
is denk maar aan als een ander attribuut.
Het is een eigenschap die bevat een hiërarchische gegevensstructuur.
En vervolgens in de query, U kunt de eigenschappen gebruiken
van die objecten met behulp van Object Notation.
Dus ik kan filteren op een geneste eigendom van de JSON-document.
Publiek: Dus elke keer als ik doe een document aanpak,
Ik kan soort van komen op de tabular--
Publiek: Absoluut.
PUBLIEK: --indexes en dingen die je net over sprak.
RICK Houlihan: Ja, de indexen en dat alles,
wanneer u wilt de index van de eigenschappen van de JSON,
de manier waarop we zouden moeten doen is als u een JSON object of een document in te voegen
in Dynamo, zou je streams gebruiken.
Streams zou de input te lezen.
Je zou krijgen dat JSON object en je zou zeggen: OK,
wat is het pand wil ik index?
>> U maakt een afgeleide tabel.
Nu dat is de manier waarop het nu werkt.
Wij niet toestaan ​​te indexeren direct die eigenschappen.
>> PUBLIEK: Tabularizing uw documenten.
>> RICK Houlihan: Precies, afvlakking het, tabularizing het, precies.
Dat is wat je ermee doet.
>> Publiek: Dank je wel.
>> RICK Houlihan: Yep, absoluut, dank je.
Publiek: Dus het is een soort van Mongo voldoet Redis classifers.
>> RICK Houlihan: Ja, het is een stuk als dat.
Dat is een goede beschrijving voor.
Koel.