ciao a tutti, sono Matt Brender, sono
uno sviluppatore avvocato a bash oh no
parlerò molto di ciò che facciamo a
bash oh eccetto solo dire che costruiamo
reagire come un open source distribuito
il database è il motivo per cui sono stato
ricercare molto di più sugli altri no
sequel database e come le persone costruiscono a
sistema distribuito come parte di un più grande
l’architettura è davvero all’altezza
discutere di dati non strutturati che sono a
termine confuso e ne entreremo in pochi
teorie se vuoi imparare come
sviluppare un’app che non ho intenzione di mostrare
codice sorgente qui c’è un sacco di codice
sui nostri repository github c’è
in realtà qualcosa è stato chiamato il gusto
di reagire che ti guiderà
installare un client nel tuo preferito
lingua e effettivamente ottenere il tuo primo
codice nel nostro database distribuito noi
avere un cluster di dub che è possibile eseguire
localmente lo fanno girare in vagabondo
tutta quella roba ma non riguarda noi
si tratta in realtà di cercare di risolvere un
problema molto più complesso di cui voglio parlare
su alcune delle teorie e
architetture che ho visto in tutto questo
che trovo davvero affascinante perché
in fondo sono più un sysadmin che un
coder più di una persona operatrice che a
sviluppatore, lotto tra i due e
quando parliamo di dati non strutturati
non è che non ci sia semantica
non c’è schema qualunque sia quello
è solo diverso da quello a cui siamo abituati
stiamo vedendo un sacco più dati che sembra
come questo blob JSON di un tweet in cui andare
Chicago da me al contrario di qualcosa
che si inserisce molto bene in un bel tavolo
con righe e colonne e questo perché
sono solo una quantità di fonti di dati
che sono un po ‘assurdo in questi giorni noi
streaming dei dati dei social media da
ovunque tu possa desiderarti
può attaccarsi alle API per github e ottenere
ogni impegno noto all’umanità che sta accadendo
in questo momento ogni dispositivo ne abbiamo pochi
che abbiamo sulle nostre persone e sui molti
più di tutto ciò che abbiamo nelle nostre case
registri di streaming in tempo reale e e
questi schemi cambiano le quantità
cambiare ma l’unica cosa che siamo
certo è che c’è molto valore
nel correlare questi dati disparati
tipi e questo è interessante se solo noi
ho avuto un buon termine per quello
non ne ho ascoltati molti, quindi vado con
quello che sento di più che se non lo faccio
senti almeno uno cresciuto qui che saresti
i primi grandi dati del pubblico che tutti odiamo
il termine ma è così buono giusto che sia
sta spiegando questa idea che c’è
solo una quantità di informazioni che
non si adatta a un singolo sistema o è in
forme diverse da quelle a cui siamo abituati
i postgres non sembrano tagliare
o il mio sequel non è il migliore e io
non ho abbastanza di un budget per il
database Oracle che stanno cercando di
vendetemi , quindi eccoci qui a mescolare
di ops e dev e diventiamo leone
domatore con tutti questi dati in arrivo
attraverso diversi flussi e diversi
architetture e stiamo cercando di ottenere
informazioni vere fuori da esso ma chiunque
che è mai stato ereditato in architettura è
familiare che non puoi iniziare
da zero non ne prendi un po ‘
bellissimo parco giochi dove vai
con la scelta migliore del primo giorno
di solito stai costruendo un prototipo e
quel prototipo su qualcosa che è molto
fragile se effettivamente raggiunge il
scala che stai cercando di raggiungere
quindi come iniziamo a pensarci
e e quali sono le opportunità per
iterare su questi lungo la strada bene
pensiamo a cosa sono realmente i big data
comprende anche se sei ancora
gemendo al termine ce ne sono a
buona definizione di dati in crescita a
scala del volume di velocità dei dati e
varietà l’informazione è che ci conosciamo
usato per essere molto bene con orario o
rapporti giornalieri sulle informazioni ora vogliamo
il più veloce possibile in tempo reale
volume non era assolutamente nulla da avere
kilobyte ma come la crescita di due terabyte
e ci si suppone essere qualcosa
come 40 zettabyte o solo numeri
stai diventando assurdo sulla quantità di
informazioni che vogliamo memorizzare e poi
la varietà di nuovo in cui era usata
belle righe e colonne e ora siamo
trattare con diversi tipi di registri
schemi che stanno cambiando al volo
informazioni che non sono facilmente normalizzabili
o D normalizzato e ancora vuoi ancora
per correlarli, vuoi ancora il tuo
scienziati dei dati o voi da mettere insieme
qualcosa che lo aggiunge a qualcosa di
valore per il business e quello che trovo
interessante è che è fondamentalmente
appena
problema dei sistemi di perline, quindi perché i dati
non si adatta facilmente a questi secchi
che erano abituati a usare dobbiamo pensare
su come ci coordiniamo su più punti
macchine ora se vuoi capire
l’informatica dietro quella lì
sono due persone molto intelligenti nella parte posteriore
che entrambi stanno presentando oggi che lo faranno
andare in parte della teoria e
Pratica di ciò parlerò di nuovo
dalla strategia pensiamo di andare
pensa praticamente come i nerd che
sono più recenti a questo così quando stai cercando
a varietà di dati è il tipo di
l’informazione non si adatta in modo naturale
in un unico tipo di database così come
contrario a cercare di massaggiare le informazioni
e trasformalo al volo dal tuo
strato applicativo direttamente nel tuo
strato di persistenza iniziale è it’s
meglio conservare eventi grezzi in
qualcosa che può gestire non strutturato
tipi di dati e quindi analizzarli dopo il
fatto che al fine di raggiungere la scala
che stiamo usando in questi giorni richiede
più di un computer quando guardi
la velocità non c’è uno sportello unico
non c’è una singola piattaforma e nessuno
non dovresti credere a nessuno che sia
cercando di venderti uno che sarà in grado
fare tutto da un lotto all’altro
analisi in tempo reale per te o archiviazione
informazioni alla scala e alla varietà
che sei abituato a trattare oggi
e il volume è solo diverso
euristica in atto che si desidera utilizzare
quando hai a che fare con piccole quantità
di dati e quantità molto grandi di
dati come te potrebbero essere assolutamente felici
con la memorizzazione dei terabyte di
informazioni sul file HDFS e o
sistema distribuito o ma se lo sei
aspettandomi tutto ciò che è lontanamente basso
quando si tratta di tempo di risposta sul
front-end è incredibilmente
Scelta inappropriata hai bisogno di qualcosa
più che ti dà garanzie di latenza
quindi a causa di ciò c’è una soluzione
che finisce per venire ripetutamente
di nuovo anche non il termine più utile in
il mondo ma nessun sequel è una conclusione
è abbastanza utile quante persone
è venuto qui molto familiare con no
seguito
okay, una parte di te è familiare
pensiamoci davvero solo come qualcosa
che non si adatta confortevolmente in a
database relazionale a volte arriva
sotto forma di un grafico a volte lo è
a volte colonnare il livello di base
il suo valore chiave ma i dati memorizzati in modi
diverso da quello che abbiamo fatto per il
ultimi 40 anni e quando parliamo di no
il seguito è un sacco di opzioni questo è
intenzionalmente non utile come un grafico
perché ci sono un certo numero di varietà
valore chiave documenti tour grafici essi
tutti tendono ad essere arrossati insieme ma loro
risolvere problemi leggermente diversi in
modi leggermente ottimizzati l’uno dall’altro
e se stai cercando di risolvere a
problema di disponibilità su scala o
se stai cercando di trovare intuizioni
al volo nel modo sub millisecondo
se stai facendo ricerca di testo contro
analisi delle relazioni devi
capire che ogni strumento ha il suo
usa il caso e in questo momento non c’è un
unico strumento che fa tutto ciò che serve
un ottimo motivo in realtà
un bel po ‘ di compromessi e voglio
passare attraverso tre in particolare che vengono
mentre analizziamo diversi no sequel
in particolare le piattaforme così quando siamo
parlando di una soluzione senza sequel loro
caduta ho trovato utile guardare a questi
tre categorie di informazioni correlate
a loro cosa fanno quando si tratta di
coerenza che cosa stanno garantendo
se hai visto la nota chiave di Kyle su Jepsen
hai una comprensione molto profonda di
coerenza e cosa significa che lo farò
parlaci da un livello più alto e prendi
un passo indietro da lì c’è conflitto
risoluzione quindi cosa succede quando
alla fine avrai sempre dentro
Atkins in un sistema distribuito cosa
succede quando c’è l’opportunità
i conflitti hanno una disponibilità elevata
o hai un conflitto è davvero uno o
l’altro e poi partizionare cosa
succede quando o come stai separando
informazioni e la diffusione fuori corso
il cluster per garantire il tipo di
prestazioni e scalabilità che tu
bisogno
e la definizione che abbiamo sempre venire
torna ad iniziare come una semplice congettura
da Eric Brewer il teorema del cappuccio che
Prenderò un secondo da Belabor
il punto nel caso in cui le persone non sono familiari
con esso lo trovo interessante
capisci che il teorema di cappuccio è davvero
solo dicendo che nel caso di a
partizione nella rete cosa dovrei
aspettarsi che succedano i clienti su ciascuno
il lato di quella partizione è ancora in grado di
leggere e o scrivere al database che
può vedere o in qualche modo non lo farà
essere disponibili stiamo andando a sacrificare
la disponibilità a garantire qualche forma
di consistenza l’unica cosa che noi
può essere certo di attraverso più nodi
è che le partizioni si verificheranno in modo tale che
uno siamo disposti a sintonizzare e per cosa
costo in modo che tendono a scoppiare
nelle orbite c’è una specie di AP
il sistema è ciò di cui stiamo parlando in generale
su una maggioranza del no sequel
soluzione quindi andrò oltre il nostro AP e quello
ti fornisce una maggiore disponibilità
il che significa minore latenza ma allo
costo di un po ‘di quella coerenza che
avremmo dovuto risolvere tutta la linea un CP
sistema saprai nella partizione
alcuni il sistema non sarà disponibile ma
sarà in grado di scalare su più punti
nodi quindi è una questione di te
aspettatevi un 404 dal vostro sistema o se
ti aspetti una risposta anche se quella risposta
non è il più aggiornato di un sistema di CA
quello a cui sei abituato è un Postgres
database nel mio database sequel così giusto
per mappare quelli un po ‘e dare un po’
esempi con cui ho più familiarità reagire
il database che facciamo a bash oh e
quello è un cassandra di sistema AP regolabile
simili sono entrambi basati sulla dinamo
carta di Amazon nel 2007 che va
attraverso fondamentalmente alcune lezioni con cui
puoi costruire sistemi distribuiti in a
modo altamente fault tolerant while
rendendosi conto che ci sai che c’è
cose più importanti del giusto
coerenza se apprezzi la coerenza
oltre a ciò puoi usare fortemente
piattaforma coerente come mango o Redis
ovviamente il rattus per la memoria è in memoria
solo così è più come uno strato di cache
contrario a essere usato per qualcosa per
persistenza quindi devi capire
gli strati che si sta andando a costruire su
uno sopra l’altro e poi in modo che si concentrino
in sui sistemi AP perché penso
questo è davvero quello che tutti sono d’accordo
abbastanza interessante quando stai andando
attraverso più nodi in se si dispone di a
mille nodi e ottieni una partizione
nel mezzo non vuoi solo tutto
essere indisponibili che preferiresti avere
a 500 nodi di nodi disponibili
a voi da leggere e scrivere da ma quello
inevitabilmente se diciamo che stiamo usando una chiave
database di valori come reagire se scrivo a
la stessa chiave su ogni lato come faccio a saperlo
su quando è finita quella partizione che sono
avere informazioni che valgono
avere o o sarà semplicemente
distrutto insieme nel modo in cui Kyle
stava mostrando con Jepsen e vedendolo
l’informazione è infatti sovrascritta
non dovrebbe essere come possiamo garantirlo
l’informazione è corretta quindi scende
al modo in cui ti occupi di
risoluzione del conflitto davvero due principali
opzioni hai l’ultima vittoria destra dove
stai prestando attenzione all’orologio
sul tuo sistema o stai usando qualcosa
diverso una sorta di contesto causale
questi sono chiamati orologi vettoriali o puntinati
i vettori di versione in alcune piattaforme e
altri sono fondamentalmente diversi
algoritmi con cui puoi garantire
quell’informazione è scritta in un certo
Ordina così di fare un passo indietro e pensare
va bene dal punto di vista teorico così può
Faccio affidamento sugli orologi nel mio sistema o lo faccio
Mi aspetto una sorta di causa ed effetto
catena che sono in grado di risolvere sul mio
lato applicazione è importante
capire la differenza ed essere pronti
anticipare quella perdita o quella
rispondi anche se la risposta è di fatto
non la risposta più recente che ti aspettavi
nel caso di un sistema distribuito successivo
quando hai a che fare con multipli
sistemi alla fine devi partizionare
dove le informazioni sono memorizzate così in in a
sistema come
come Mongo il sistema CP come a
metodologia master-slave quindi ogni parte
ogni parte dei dati è archiviata e
ha un master e quindi più slave o
altri nodi che saranno in grado di risolvere
legge contro qualcosa che sta usando a
tavolo di hashing coerente come Cassandra
e reagire entrambi i casi in cui i dati sono
memorizzato in una sorta di contratti di solito
chiamato un nodo V ed è distribuito
uniformemente in tutto e per tutto
nodi disponibili nel cluster, quindi se noi
pensa agli scenari di fallimento in
queste diverse architetture se un nodo
scende in un anello di hashing coerente
devi avere una sorta di logica
quali informazioni vengono lette da altri
nodi che è vero su Cassandra e
reagire nel caso in cui si ha un
la metodologia master-slave c’è un
opportunità in cui un singolo nodo può andare
giù con il maestro e in quello in quello
tempo in cui uno schiavo deve essere eletto come a
maestro quindi hai un’opportunità dove a
porzione di tempo del tuo database
in realtà non disponibile che non lo è
effettivamente possibile in modo coerente
design di hashing quindi è importante mantenere
in mente come te quando stai costruendo
questi sistemi che ti piacciono posso farlo io
aspettiamo che un singolo nodo che scende possa
porta giù la mia mia infrastruttura che hai
per essere devi riconoscere quei maestri
le metodologie di master slave hanno questo
rischio per loro mentre un hashing coerente
l’algoritmo funziona davvero intorno a questo
dove hai una specie di quorum tu
definito e fino a quel quorum di
il naso è disponibile il sistema sarà
disponibile a vederlo in poco tempo
contesto più ampio questo è reagire in modo specifico
quindi dovrete scusarmi, ma con
dati e reagire abbiamo avuto un quattro nodo
cluster questa volta i dati sono distribuiti
attraverso algoritmo di hashing coerente e
in realtà pezzi di informazioni vengono diffusi
in modo uniforme su ogni nodo puoi vederlo
una parte di quella coerente
la tabella di hashing è effettivamente memorizzata su ciascuna di esse
vinodh e poi atterra su ciascuno dei
nodi fisici
in definitiva significa che i dati saranno
distribuire uniformemente su tutti i nodi cosa cosa
rende importante quello che vuoi
una sorta di scalabilità prevedibile per
la tua infrastruttura e mentre a
metodologia master-slave di solito tu
devono definire dove saranno i dati
andando dalla tua logica di applicazione come
stai aggiungendo una sorta di semantica su
cima a quello che hai costruito da un
database durante l’ hashing coerente
suona in realtà che sarà il sistema
disperdendolo automaticamente per te
basato su un algoritmo ti salva un po ‘
logica dell’applicazione e fornisce di più
modello scalabile linearmente, quindi passiamo
ingranaggi e parlare di alcune tattiche su
progettare le tue informazioni e come tu
salvalo, penseremo
cap on mi viene chiesto molto bene di solito
ascolta la dichiarazione che anche il mio appuntamento è
complesso per database di valori chiave questo no
la cosa successiva è che va bene, ma ho bisogno di un
database relazionale con nice
transazioni e la certezza e
stabilità a cui sono abituato e II
finalmente l’esperimento mentale che
le persone sono nella giusta mentalità
ponendo la domanda su quali domande
prevedi che devi chiedere così sono
hai intenzione di chiedere come su un
per utente, che tipo di ordini sono
loro avranno o gerarchicamente
albero di informazioni come quali sono le
sotto alberi quindi se puoi rispondere a questo
domanda in un bel modo atomico che puoi
scrivi quelle informazioni poi una chiave
il valore è assolutamente perfetto
l’architettura per il tuo bisogno lo imposta
in un modo più semplice possiamo andare a scuola vecchia
il data store del valore della chiave originale qui
è il Dewey Decimal System ogni volta
scrivi le informazioni sulla carta
ha una risposta definitiva sull’altro
lato e si può andare a ottenere quel aggregante
i dati in questo modo sono in realtà molto
efficace e quando puoi fare affidamento su ciascuno di essi
chiave disponibile in questo in questo
metodo puoi scalare in modo molto
bel modo rubato da un fantastico blog
post parlando di modellazione dei dati ecco
un esempio di riflessione sul
rami di informazioni su un e-commerce
sito e vedendo alcune quantità arbitrarie di
quell’informazione è vista come un
singolo albero e sta per essere conservato in
un singolo aggregato non sarà D
normalizzato così si sta effettivamente andando a
avere alcuni dati di ripetizione, ma sta andando a
essere un po ‘di blob Jason non è quello
molto nella quantità di spazio ed è
sta per essere molto più veloce su una lettura
varrà la pena dedicare del tempo a te
quindi quale è un modo totalmente diverso di
pensando da un database relazionale
un altro altro post sul blog che davvero
influenzato via era stato capire
come progettare i tipi di dati è in realtà
pensandoci dal punto di vista di a
sistema di elaborazione del flusso in modo da vedere
eventi in un modo più immutabile preso in prestito
per fortuna da parte di Martin dalla sua
parla a dev / dev wynter yeah a Londra
parla invece di formulare
dati in un modo in cui stai aggiornando un
tabella rispetto all’aggiornamento di un valore come
si trova su un file corrente o un icky
valore invece di leggere quella chiave
valore aggiornando una quantità e un carrello e
rimettendo questo valore chiave prova a pensare
di tutto come stato e tempo e
salvarli come file raw o raw raw
eventi e che ti permetteranno di pensare
della tua architettura in modo totalmente
modo diverso così il suo esempio è da aggiungere
informazioni su un carrello al primo tentativo
aggiungi queste informazioni che potresti
potrebbe avere una quantità di una di quella di
qualunque cosa tu stia comprando e poi tu
potrei aggiornarlo a tre e poi a te
può aggiornarlo due al contrario di
avendo un valore relativo e
sottraendo e facendo ciò ogni
di queste sono le vere dichiarazioni che sono
lì in sé e per sé precisi
ciò che è bello è che nel
caso di conflitto puoi usare qualcosa
come la logica del vettore versione punteggiata noi
stavamo parlando e potremmo
risolvi questo più sicuramente e tu
potrebbe anche dargli da mangiare in qualche altro
sistema che prende quella informazione grezza e
vedendo
oh i miei utenti cambiano effettivamente la loro carta a
poche volte prima di questo e quello potrebbe
avere alcuni interessanti a valle
ramificazioni quindi volevo anche parlare
su alcune delle architetture che sono
abbastanza interessante e portato
su un’ora di conversazione iniziale a
al keynote e solo per ricordare
che tipo di problemi dobbiamo ancora
trattare come conosci gente di sistemi
guardare molti sistemi diversi
costruito provare a riferire su qualcosa di simile
questa che è stata la vera piattaforma di dati
quello era dietro linkedin prima di loro
ha iniziato la migrazione e la creazione di apache
ciò che è ora apache kafka così hanno avuto un
numero di servizi applicativi con
domande in cima andando in hanno avuto
messaggistica Hugh sta portando altre app
conducendo i valori chiave c’è il registro
aggregazione sul lato in cui è memorizzato
su tipi di dati disparati c’è davvero
nessun percorso chiaro in cui l’informazione è
viaggiare in qualsiasi modo che sarebbe
ti dà l’opportunità di replicare
informazioni in questo un modo bellissimo noi
erano solo parlando e essere in grado di
fare alcune analisi interessanti in aggiunta
questo quindi cosa propongono e cosa loro
Da allora si è trasferito su LinkedIn
qualcosa di più simile a questo e io davvero
amo questa architettura è così
ovviamente più facile da leggere ma
le applicazioni stanno memorizzando in alcuni locali
informazioni o qualche tipo di database
questo è appropriato per l’applicazione
proprio come se tu stia cercando di fare
qualche analisi sulle relazioni che hai
una specie di grafico sociale, ma tu puoi
anche scrivere quei dati su qualcosa
persistente o garantito
livello di persistenza come un AP senza sequenze
sistema che scala linearmente e poi tu
potrebbe anche tirare quelle informazioni
direttamente dal key value store o
o anche memorizzarlo in una ricerca come
ricerca elastica ed essere in esecuzione alcuni
domande al di sopra di ciò che amo
su questo è che poi si nutre
una sorta di piattaforma dati in streaming
che ovviamente raccomanderebbero
kafka l’hanno costruito ma puoi usare AP
nessuna soluzione sequel pure
per un sistema di streaming in cui le informazioni
può essere estratto da quella centrale
fonte ora e bene si puoi usare a
potresti usare un database come quello ma
Kafka è davvero forte nel fatto che
ti permette di avere una sorta di offset
per vostra informazione quindi ogni flusso è
in realtà un elenco ripetibile di dati in a
certo ordine che puoi tirare e
dare da mangiare a tutti questi diversi sistemi
e poi, alla fine, un ragazzino potrebbe crollare
puoi trovare qualcosa come Dupin
fare qualche ulteriore elaborazione in batch
elaborazione dopo che così quando iniziamo
pensando alle architetture che possiamo
pensa a qualcosa come un errore
sistema di analisi in cui si sta memorizzando
informazioni principalmente sul tuo no
sequel soluzione e quindi avete entrambi
abbinato a un ammasso solare ne ha alcuni
tipo di o utilizzando un negozio di documenti dove
puoi fare quella ricerca e tirare
informazioni là fuori che stai facendo
qualcosa in cui stai cercando di trovare
altri schemi che potresti fare
cosa stiamo mostrando in quel livello superiore
architettura dove sono le applicazioni
scrivere usando un modello multi-cliente
a più archivi di dati
contemporaneamente e poi hanno qualche tipo
di sistemi batch in cima a quello o sì
è quasi sempre un sistema batch
estraendo informazioni da questo
prodotti a bassa latenza più veloci o memorizzati
in cima a HDFS e poi in esecuzione
qualcosa in più o meno
è possibile memorizzare informazioni e nessun sequel
in una sorta di processo ETL in cui ti trovi
estraendo i tuoi flussi formando il tuo
informazioni e spingendolo nel set
coda di messaggi ora che è in a
formato più pulito e poi tirarlo dentro
qualunque tipo di piattaforma di analisi
stai usando oggi così solo per visualizzare
che un po ‘di nuovo in prestito dal
lavoro straordinario da parte della squadra di kafka
mostrando una sorta di spinta del servizio web
informazioni direttamente a un flusso di eventi
e che quindi l’informazione grezza può essere
memorizzato su qualcosa come un nessun seguito
database e quindi puoi anche essere
aggregando tali informazioni e memorizzandole
a un altro secchio sullo stesso
database o qualcosa di diverso c’è
un sacco di flessibilità per la costruzione di questi
le cose stanno davvero pensando
come stai memorizzando immutabile
informazioni guardando a un altro
architettura che lo spiega dal genere
di angolo di risposta del ristorante
database relazionali senza database sequel
tutte le altre applicazioni prevedono una latenza molto bassa
possono dare informazioni a qualcosa
come una piattaforma di streaming come Kafka e
allora puoi avere questi livelli di batch
analisi che segue dopo e poi esso
è stato allevato brevemente ma un lambda
architettura che si suppone possa rompere
teorema del cappuccio ma è davvero solo un
modo di vedere non lineare
informazioni sia come la velocità di massa
strato di informazioni che sta accadendo
regolarmente e poi il lotto più lento
strato di informazioni e quindi
aggregando quelle richieste una volta arrivate
a valle ma il tipo di
l’architettura di queste cose è abbastanza
può essere abbastanza complesso ma ha il
beneficio di avere sia il tuo più veloce
dati con i dati del lotto quindi basta prendere un
fare un passo indietro come la ragione è tutto
interessante è che non puoi davvero
analizzare le informazioni che non hai
stato in grado di memorizzare in modo da conservare
l’informazione finisce per essere molto complessa
problema che è necessario prendere in
considerazione e mentre lo fai ci sono
una grande quantità di sfide da equilibrare
mi piace come sono la mia latenza
aspettative per ciascuno di questi
applicazioni come sto andando a mantenere
questi come gestiscono un conflitto
risoluzione e ciò che trovi molto
rapidamente è che la maggior parte di questo funziona a
scala molto piccola diventa complessa una volta
attraversi più sistemi che
entra in un problema assurdo di
sistemi distribuiti in modo da riassumere alcuni
dei problemi fondamentali che stiamo trattando
con ci sono alcuni termini qui che mi piacciono
come pensare a nessun sequel come a
qualcosa che è davvero solo un
una raccolta di alta disponibilità
sistemi scalabili che rientrano nel
il problema del teorema del cappuccio
i dati non strutturati sono solo alcuni dei
informazioni che cercano di analizzare e poi
alcune delle architetture che eravamo
parlando e alcuni degli strumenti così io
certamente finito presto felice di portare
casi più specifici e discuterli
ma grazie a tutti
uno sviluppatore avvocato a bash oh no
parlerò molto di ciò che facciamo a
bash oh eccetto solo dire che costruiamo
reagire come un open source distribuito
il database è il motivo per cui sono stato
ricercare molto di più sugli altri no
sequel database e come le persone costruiscono a
sistema distribuito come parte di un più grande
l’architettura è davvero all’altezza
discutere di dati non strutturati che sono a
termine confuso e ne entreremo in pochi
teorie se vuoi imparare come
sviluppare un’app che non ho intenzione di mostrare
codice sorgente qui c’è un sacco di codice
sui nostri repository github c’è
in realtà qualcosa è stato chiamato il gusto
di reagire che ti guiderà
installare un client nel tuo preferito
lingua e effettivamente ottenere il tuo primo
codice nel nostro database distribuito noi
avere un cluster di dub che è possibile eseguire
localmente lo fanno girare in vagabondo
tutta quella roba ma non riguarda noi
si tratta in realtà di cercare di risolvere un
problema molto più complesso di cui voglio parlare
su alcune delle teorie e
architetture che ho visto in tutto questo
che trovo davvero affascinante perché
in fondo sono più un sysadmin che un
coder più di una persona operatrice che a
sviluppatore, lotto tra i due e
quando parliamo di dati non strutturati
non è che non ci sia semantica
non c’è schema qualunque sia quello
è solo diverso da quello a cui siamo abituati
stiamo vedendo un sacco più dati che sembra
come questo blob JSON di un tweet in cui andare
Chicago da me al contrario di qualcosa
che si inserisce molto bene in un bel tavolo
con righe e colonne e questo perché
sono solo una quantità di fonti di dati
che sono un po ‘assurdo in questi giorni noi
streaming dei dati dei social media da
ovunque tu possa desiderarti
può attaccarsi alle API per github e ottenere
ogni impegno noto all’umanità che sta accadendo
in questo momento ogni dispositivo ne abbiamo pochi
che abbiamo sulle nostre persone e sui molti
più di tutto ciò che abbiamo nelle nostre case
registri di streaming in tempo reale e e
questi schemi cambiano le quantità
cambiare ma l’unica cosa che siamo
certo è che c’è molto valore
nel correlare questi dati disparati
tipi e questo è interessante se solo noi
ho avuto un buon termine per quello
non ne ho ascoltati molti, quindi vado con
quello che sento di più che se non lo faccio
senti almeno uno cresciuto qui che saresti
i primi grandi dati del pubblico che tutti odiamo
il termine ma è così buono giusto che sia
sta spiegando questa idea che c’è
solo una quantità di informazioni che
non si adatta a un singolo sistema o è in
forme diverse da quelle a cui siamo abituati
i postgres non sembrano tagliare
o il mio sequel non è il migliore e io
non ho abbastanza di un budget per il
database Oracle che stanno cercando di
vendetemi , quindi eccoci qui a mescolare
di ops e dev e diventiamo leone
domatore con tutti questi dati in arrivo
attraverso diversi flussi e diversi
architetture e stiamo cercando di ottenere
informazioni vere fuori da esso ma chiunque
che è mai stato ereditato in architettura è
familiare che non puoi iniziare
da zero non ne prendi un po ‘
bellissimo parco giochi dove vai
con la scelta migliore del primo giorno
di solito stai costruendo un prototipo e
quel prototipo su qualcosa che è molto
fragile se effettivamente raggiunge il
scala che stai cercando di raggiungere
quindi come iniziamo a pensarci
e e quali sono le opportunità per
iterare su questi lungo la strada bene
pensiamo a cosa sono realmente i big data
comprende anche se sei ancora
gemendo al termine ce ne sono a
buona definizione di dati in crescita a
scala del volume di velocità dei dati e
varietà l’informazione è che ci conosciamo
usato per essere molto bene con orario o
rapporti giornalieri sulle informazioni ora vogliamo
il più veloce possibile in tempo reale
volume non era assolutamente nulla da avere
kilobyte ma come la crescita di due terabyte
e ci si suppone essere qualcosa
come 40 zettabyte o solo numeri
stai diventando assurdo sulla quantità di
informazioni che vogliamo memorizzare e poi
la varietà di nuovo in cui era usata
belle righe e colonne e ora siamo
trattare con diversi tipi di registri
schemi che stanno cambiando al volo
informazioni che non sono facilmente normalizzabili
o D normalizzato e ancora vuoi ancora
per correlarli, vuoi ancora il tuo
scienziati dei dati o voi da mettere insieme
qualcosa che lo aggiunge a qualcosa di
valore per il business e quello che trovo
interessante è che è fondamentalmente
appena
problema dei sistemi di perline, quindi perché i dati
non si adatta facilmente a questi secchi
che erano abituati a usare dobbiamo pensare
su come ci coordiniamo su più punti
macchine ora se vuoi capire
l’informatica dietro quella lì
sono due persone molto intelligenti nella parte posteriore
che entrambi stanno presentando oggi che lo faranno
andare in parte della teoria e
Pratica di ciò parlerò di nuovo
dalla strategia pensiamo di andare
pensa praticamente come i nerd che
sono più recenti a questo così quando stai cercando
a varietà di dati è il tipo di
l’informazione non si adatta in modo naturale
in un unico tipo di database così come
contrario a cercare di massaggiare le informazioni
e trasformalo al volo dal tuo
strato applicativo direttamente nel tuo
strato di persistenza iniziale è it’s
meglio conservare eventi grezzi in
qualcosa che può gestire non strutturato
tipi di dati e quindi analizzarli dopo il
fatto che al fine di raggiungere la scala
che stiamo usando in questi giorni richiede
più di un computer quando guardi
la velocità non c’è uno sportello unico
non c’è una singola piattaforma e nessuno
non dovresti credere a nessuno che sia
cercando di venderti uno che sarà in grado
fare tutto da un lotto all’altro
analisi in tempo reale per te o archiviazione
informazioni alla scala e alla varietà
che sei abituato a trattare oggi
e il volume è solo diverso
euristica in atto che si desidera utilizzare
quando hai a che fare con piccole quantità
di dati e quantità molto grandi di
dati come te potrebbero essere assolutamente felici
con la memorizzazione dei terabyte di
informazioni sul file HDFS e o
sistema distribuito o ma se lo sei
aspettandomi tutto ciò che è lontanamente basso
quando si tratta di tempo di risposta sul
front-end è incredibilmente
Scelta inappropriata hai bisogno di qualcosa
più che ti dà garanzie di latenza
quindi a causa di ciò c’è una soluzione
che finisce per venire ripetutamente
di nuovo anche non il termine più utile in
il mondo ma nessun sequel è una conclusione
è abbastanza utile quante persone
è venuto qui molto familiare con no
seguito
okay, una parte di te è familiare
pensiamoci davvero solo come qualcosa
che non si adatta confortevolmente in a
database relazionale a volte arriva
sotto forma di un grafico a volte lo è
a volte colonnare il livello di base
il suo valore chiave ma i dati memorizzati in modi
diverso da quello che abbiamo fatto per il
ultimi 40 anni e quando parliamo di no
il seguito è un sacco di opzioni questo è
intenzionalmente non utile come un grafico
perché ci sono un certo numero di varietà
valore chiave documenti tour grafici essi
tutti tendono ad essere arrossati insieme ma loro
risolvere problemi leggermente diversi in
modi leggermente ottimizzati l’uno dall’altro
e se stai cercando di risolvere a
problema di disponibilità su scala o
se stai cercando di trovare intuizioni
al volo nel modo sub millisecondo
se stai facendo ricerca di testo contro
analisi delle relazioni devi
capire che ogni strumento ha il suo
usa il caso e in questo momento non c’è un
unico strumento che fa tutto ciò che serve
un ottimo motivo in realtà
un bel po ‘ di compromessi e voglio
passare attraverso tre in particolare che vengono
mentre analizziamo diversi no sequel
in particolare le piattaforme così quando siamo
parlando di una soluzione senza sequel loro
caduta ho trovato utile guardare a questi
tre categorie di informazioni correlate
a loro cosa fanno quando si tratta di
coerenza che cosa stanno garantendo
se hai visto la nota chiave di Kyle su Jepsen
hai una comprensione molto profonda di
coerenza e cosa significa che lo farò
parlaci da un livello più alto e prendi
un passo indietro da lì c’è conflitto
risoluzione quindi cosa succede quando
alla fine avrai sempre dentro
Atkins in un sistema distribuito cosa
succede quando c’è l’opportunità
i conflitti hanno una disponibilità elevata
o hai un conflitto è davvero uno o
l’altro e poi partizionare cosa
succede quando o come stai separando
informazioni e la diffusione fuori corso
il cluster per garantire il tipo di
prestazioni e scalabilità che tu
bisogno
e la definizione che abbiamo sempre venire
torna ad iniziare come una semplice congettura
da Eric Brewer il teorema del cappuccio che
Prenderò un secondo da Belabor
il punto nel caso in cui le persone non sono familiari
con esso lo trovo interessante
capisci che il teorema di cappuccio è davvero
solo dicendo che nel caso di a
partizione nella rete cosa dovrei
aspettarsi che succedano i clienti su ciascuno
il lato di quella partizione è ancora in grado di
leggere e o scrivere al database che
può vedere o in qualche modo non lo farà
essere disponibili stiamo andando a sacrificare
la disponibilità a garantire qualche forma
di consistenza l’unica cosa che noi
può essere certo di attraverso più nodi
è che le partizioni si verificheranno in modo tale che
uno siamo disposti a sintonizzare e per cosa
costo in modo che tendono a scoppiare
nelle orbite c’è una specie di AP
il sistema è ciò di cui stiamo parlando in generale
su una maggioranza del no sequel
soluzione quindi andrò oltre il nostro AP e quello
ti fornisce una maggiore disponibilità
il che significa minore latenza ma allo
costo di un po ‘di quella coerenza che
avremmo dovuto risolvere tutta la linea un CP
sistema saprai nella partizione
alcuni il sistema non sarà disponibile ma
sarà in grado di scalare su più punti
nodi quindi è una questione di te
aspettatevi un 404 dal vostro sistema o se
ti aspetti una risposta anche se quella risposta
non è il più aggiornato di un sistema di CA
quello a cui sei abituato è un Postgres
database nel mio database sequel così giusto
per mappare quelli un po ‘e dare un po’
esempi con cui ho più familiarità reagire
il database che facciamo a bash oh e
quello è un cassandra di sistema AP regolabile
simili sono entrambi basati sulla dinamo
carta di Amazon nel 2007 che va
attraverso fondamentalmente alcune lezioni con cui
puoi costruire sistemi distribuiti in a
modo altamente fault tolerant while
rendendosi conto che ci sai che c’è
cose più importanti del giusto
coerenza se apprezzi la coerenza
oltre a ciò puoi usare fortemente
piattaforma coerente come mango o Redis
ovviamente il rattus per la memoria è in memoria
solo così è più come uno strato di cache
contrario a essere usato per qualcosa per
persistenza quindi devi capire
gli strati che si sta andando a costruire su
uno sopra l’altro e poi in modo che si concentrino
in sui sistemi AP perché penso
questo è davvero quello che tutti sono d’accordo
abbastanza interessante quando stai andando
attraverso più nodi in se si dispone di a
mille nodi e ottieni una partizione
nel mezzo non vuoi solo tutto
essere indisponibili che preferiresti avere
a 500 nodi di nodi disponibili
a voi da leggere e scrivere da ma quello
inevitabilmente se diciamo che stiamo usando una chiave
database di valori come reagire se scrivo a
la stessa chiave su ogni lato come faccio a saperlo
su quando è finita quella partizione che sono
avere informazioni che valgono
avere o o sarà semplicemente
distrutto insieme nel modo in cui Kyle
stava mostrando con Jepsen e vedendolo
l’informazione è infatti sovrascritta
non dovrebbe essere come possiamo garantirlo
l’informazione è corretta quindi scende
al modo in cui ti occupi di
risoluzione del conflitto davvero due principali
opzioni hai l’ultima vittoria destra dove
stai prestando attenzione all’orologio
sul tuo sistema o stai usando qualcosa
diverso una sorta di contesto causale
questi sono chiamati orologi vettoriali o puntinati
i vettori di versione in alcune piattaforme e
altri sono fondamentalmente diversi
algoritmi con cui puoi garantire
quell’informazione è scritta in un certo
Ordina così di fare un passo indietro e pensare
va bene dal punto di vista teorico così può
Faccio affidamento sugli orologi nel mio sistema o lo faccio
Mi aspetto una sorta di causa ed effetto
catena che sono in grado di risolvere sul mio
lato applicazione è importante
capire la differenza ed essere pronti
anticipare quella perdita o quella
rispondi anche se la risposta è di fatto
non la risposta più recente che ti aspettavi
nel caso di un sistema distribuito successivo
quando hai a che fare con multipli
sistemi alla fine devi partizionare
dove le informazioni sono memorizzate così in in a
sistema come
come Mongo il sistema CP come a
metodologia master-slave quindi ogni parte
ogni parte dei dati è archiviata e
ha un master e quindi più slave o
altri nodi che saranno in grado di risolvere
legge contro qualcosa che sta usando a
tavolo di hashing coerente come Cassandra
e reagire entrambi i casi in cui i dati sono
memorizzato in una sorta di contratti di solito
chiamato un nodo V ed è distribuito
uniformemente in tutto e per tutto
nodi disponibili nel cluster, quindi se noi
pensa agli scenari di fallimento in
queste diverse architetture se un nodo
scende in un anello di hashing coerente
devi avere una sorta di logica
quali informazioni vengono lette da altri
nodi che è vero su Cassandra e
reagire nel caso in cui si ha un
la metodologia master-slave c’è un
opportunità in cui un singolo nodo può andare
giù con il maestro e in quello in quello
tempo in cui uno schiavo deve essere eletto come a
maestro quindi hai un’opportunità dove a
porzione di tempo del tuo database
in realtà non disponibile che non lo è
effettivamente possibile in modo coerente
design di hashing quindi è importante mantenere
in mente come te quando stai costruendo
questi sistemi che ti piacciono posso farlo io
aspettiamo che un singolo nodo che scende possa
porta giù la mia mia infrastruttura che hai
per essere devi riconoscere quei maestri
le metodologie di master slave hanno questo
rischio per loro mentre un hashing coerente
l’algoritmo funziona davvero intorno a questo
dove hai una specie di quorum tu
definito e fino a quel quorum di
il naso è disponibile il sistema sarà
disponibile a vederlo in poco tempo
contesto più ampio questo è reagire in modo specifico
quindi dovrete scusarmi, ma con
dati e reagire abbiamo avuto un quattro nodo
cluster questa volta i dati sono distribuiti
attraverso algoritmo di hashing coerente e
in realtà pezzi di informazioni vengono diffusi
in modo uniforme su ogni nodo puoi vederlo
una parte di quella coerente
la tabella di hashing è effettivamente memorizzata su ciascuna di esse
vinodh e poi atterra su ciascuno dei
nodi fisici
in definitiva significa che i dati saranno
distribuire uniformemente su tutti i nodi cosa cosa
rende importante quello che vuoi
una sorta di scalabilità prevedibile per
la tua infrastruttura e mentre a
metodologia master-slave di solito tu
devono definire dove saranno i dati
andando dalla tua logica di applicazione come
stai aggiungendo una sorta di semantica su
cima a quello che hai costruito da un
database durante l’ hashing coerente
suona in realtà che sarà il sistema
disperdendolo automaticamente per te
basato su un algoritmo ti salva un po ‘
logica dell’applicazione e fornisce di più
modello scalabile linearmente, quindi passiamo
ingranaggi e parlare di alcune tattiche su
progettare le tue informazioni e come tu
salvalo, penseremo
cap on mi viene chiesto molto bene di solito
ascolta la dichiarazione che anche il mio appuntamento è
complesso per database di valori chiave questo no
la cosa successiva è che va bene, ma ho bisogno di un
database relazionale con nice
transazioni e la certezza e
stabilità a cui sono abituato e II
finalmente l’esperimento mentale che
le persone sono nella giusta mentalità
ponendo la domanda su quali domande
prevedi che devi chiedere così sono
hai intenzione di chiedere come su un
per utente, che tipo di ordini sono
loro avranno o gerarchicamente
albero di informazioni come quali sono le
sotto alberi quindi se puoi rispondere a questo
domanda in un bel modo atomico che puoi
scrivi quelle informazioni poi una chiave
il valore è assolutamente perfetto
l’architettura per il tuo bisogno lo imposta
in un modo più semplice possiamo andare a scuola vecchia
il data store del valore della chiave originale qui
è il Dewey Decimal System ogni volta
scrivi le informazioni sulla carta
ha una risposta definitiva sull’altro
lato e si può andare a ottenere quel aggregante
i dati in questo modo sono in realtà molto
efficace e quando puoi fare affidamento su ciascuno di essi
chiave disponibile in questo in questo
metodo puoi scalare in modo molto
bel modo rubato da un fantastico blog
post parlando di modellazione dei dati ecco
un esempio di riflessione sul
rami di informazioni su un e-commerce
sito e vedendo alcune quantità arbitrarie di
quell’informazione è vista come un
singolo albero e sta per essere conservato in
un singolo aggregato non sarà D
normalizzato così si sta effettivamente andando a
avere alcuni dati di ripetizione, ma sta andando a
essere un po ‘di blob Jason non è quello
molto nella quantità di spazio ed è
sta per essere molto più veloce su una lettura
varrà la pena dedicare del tempo a te
quindi quale è un modo totalmente diverso di
pensando da un database relazionale
un altro altro post sul blog che davvero
influenzato via era stato capire
come progettare i tipi di dati è in realtà
pensandoci dal punto di vista di a
sistema di elaborazione del flusso in modo da vedere
eventi in un modo più immutabile preso in prestito
per fortuna da parte di Martin dalla sua
parla a dev / dev wynter yeah a Londra
parla invece di formulare
dati in un modo in cui stai aggiornando un
tabella rispetto all’aggiornamento di un valore come
si trova su un file corrente o un icky
valore invece di leggere quella chiave
valore aggiornando una quantità e un carrello e
rimettendo questo valore chiave prova a pensare
di tutto come stato e tempo e
salvarli come file raw o raw raw
eventi e che ti permetteranno di pensare
della tua architettura in modo totalmente
modo diverso così il suo esempio è da aggiungere
informazioni su un carrello al primo tentativo
aggiungi queste informazioni che potresti
potrebbe avere una quantità di una di quella di
qualunque cosa tu stia comprando e poi tu
potrei aggiornarlo a tre e poi a te
può aggiornarlo due al contrario di
avendo un valore relativo e
sottraendo e facendo ciò ogni
di queste sono le vere dichiarazioni che sono
lì in sé e per sé precisi
ciò che è bello è che nel
caso di conflitto puoi usare qualcosa
come la logica del vettore versione punteggiata noi
stavamo parlando e potremmo
risolvi questo più sicuramente e tu
potrebbe anche dargli da mangiare in qualche altro
sistema che prende quella informazione grezza e
vedendo
oh i miei utenti cambiano effettivamente la loro carta a
poche volte prima di questo e quello potrebbe
avere alcuni interessanti a valle
ramificazioni quindi volevo anche parlare
su alcune delle architetture che sono
abbastanza interessante e portato
su un’ora di conversazione iniziale a
al keynote e solo per ricordare
che tipo di problemi dobbiamo ancora
trattare come conosci gente di sistemi
guardare molti sistemi diversi
costruito provare a riferire su qualcosa di simile
questa che è stata la vera piattaforma di dati
quello era dietro linkedin prima di loro
ha iniziato la migrazione e la creazione di apache
ciò che è ora apache kafka così hanno avuto un
numero di servizi applicativi con
domande in cima andando in hanno avuto
messaggistica Hugh sta portando altre app
conducendo i valori chiave c’è il registro
aggregazione sul lato in cui è memorizzato
su tipi di dati disparati c’è davvero
nessun percorso chiaro in cui l’informazione è
viaggiare in qualsiasi modo che sarebbe
ti dà l’opportunità di replicare
informazioni in questo un modo bellissimo noi
erano solo parlando e essere in grado di
fare alcune analisi interessanti in aggiunta
questo quindi cosa propongono e cosa loro
Da allora si è trasferito su LinkedIn
qualcosa di più simile a questo e io davvero
amo questa architettura è così
ovviamente più facile da leggere ma
le applicazioni stanno memorizzando in alcuni locali
informazioni o qualche tipo di database
questo è appropriato per l’applicazione
proprio come se tu stia cercando di fare
qualche analisi sulle relazioni che hai
una specie di grafico sociale, ma tu puoi
anche scrivere quei dati su qualcosa
persistente o garantito
livello di persistenza come un AP senza sequenze
sistema che scala linearmente e poi tu
potrebbe anche tirare quelle informazioni
direttamente dal key value store o
o anche memorizzarlo in una ricerca come
ricerca elastica ed essere in esecuzione alcuni
domande al di sopra di ciò che amo
su questo è che poi si nutre
una sorta di piattaforma dati in streaming
che ovviamente raccomanderebbero
kafka l’hanno costruito ma puoi usare AP
nessuna soluzione sequel pure
per un sistema di streaming in cui le informazioni
può essere estratto da quella centrale
fonte ora e bene si puoi usare a
potresti usare un database come quello ma
Kafka è davvero forte nel fatto che
ti permette di avere una sorta di offset
per vostra informazione quindi ogni flusso è
in realtà un elenco ripetibile di dati in a
certo ordine che puoi tirare e
dare da mangiare a tutti questi diversi sistemi
e poi, alla fine, un ragazzino potrebbe crollare
puoi trovare qualcosa come Dupin
fare qualche ulteriore elaborazione in batch
elaborazione dopo che così quando iniziamo
pensando alle architetture che possiamo
pensa a qualcosa come un errore
sistema di analisi in cui si sta memorizzando
informazioni principalmente sul tuo no
sequel soluzione e quindi avete entrambi
abbinato a un ammasso solare ne ha alcuni
tipo di o utilizzando un negozio di documenti dove
puoi fare quella ricerca e tirare
informazioni là fuori che stai facendo
qualcosa in cui stai cercando di trovare
altri schemi che potresti fare
cosa stiamo mostrando in quel livello superiore
architettura dove sono le applicazioni
scrivere usando un modello multi-cliente
a più archivi di dati
contemporaneamente e poi hanno qualche tipo
di sistemi batch in cima a quello o sì
è quasi sempre un sistema batch
estraendo informazioni da questo
prodotti a bassa latenza più veloci o memorizzati
in cima a HDFS e poi in esecuzione
qualcosa in più o meno
è possibile memorizzare informazioni e nessun sequel
in una sorta di processo ETL in cui ti trovi
estraendo i tuoi flussi formando il tuo
informazioni e spingendolo nel set
coda di messaggi ora che è in a
formato più pulito e poi tirarlo dentro
qualunque tipo di piattaforma di analisi
stai usando oggi così solo per visualizzare
che un po ‘di nuovo in prestito dal
lavoro straordinario da parte della squadra di kafka
mostrando una sorta di spinta del servizio web
informazioni direttamente a un flusso di eventi
e che quindi l’informazione grezza può essere
memorizzato su qualcosa come un nessun seguito
database e quindi puoi anche essere
aggregando tali informazioni e memorizzandole
a un altro secchio sullo stesso
database o qualcosa di diverso c’è
un sacco di flessibilità per la costruzione di questi
le cose stanno davvero pensando
come stai memorizzando immutabile
informazioni guardando a un altro
architettura che lo spiega dal genere
di angolo di risposta del ristorante
database relazionali senza database sequel
tutte le altre applicazioni prevedono una latenza molto bassa
possono dare informazioni a qualcosa
come una piattaforma di streaming come Kafka e
allora puoi avere questi livelli di batch
analisi che segue dopo e poi esso
è stato allevato brevemente ma un lambda
architettura che si suppone possa rompere
teorema del cappuccio ma è davvero solo un
modo di vedere non lineare
informazioni sia come la velocità di massa
strato di informazioni che sta accadendo
regolarmente e poi il lotto più lento
strato di informazioni e quindi
aggregando quelle richieste una volta arrivate
a valle ma il tipo di
l’architettura di queste cose è abbastanza
può essere abbastanza complesso ma ha il
beneficio di avere sia il tuo più veloce
dati con i dati del lotto quindi basta prendere un
fare un passo indietro come la ragione è tutto
interessante è che non puoi davvero
analizzare le informazioni che non hai
stato in grado di memorizzare in modo da conservare
l’informazione finisce per essere molto complessa
problema che è necessario prendere in
considerazione e mentre lo fai ci sono
una grande quantità di sfide da equilibrare
mi piace come sono la mia latenza
aspettative per ciascuno di questi
applicazioni come sto andando a mantenere
questi come gestiscono un conflitto
risoluzione e ciò che trovi molto
rapidamente è che la maggior parte di questo funziona a
scala molto piccola diventa complessa una volta
attraversi più sistemi che
entra in un problema assurdo di
sistemi distribuiti in modo da riassumere alcuni
dei problemi fondamentali che stiamo trattando
con ci sono alcuni termini qui che mi piacciono
come pensare a nessun sequel come a
qualcosa che è davvero solo un
una raccolta di alta disponibilità
sistemi scalabili che rientrano nel
il problema del teorema del cappuccio
i dati non strutturati sono solo alcuni dei
informazioni che cercano di analizzare e poi
alcune delle architetture che eravamo
parlando e alcuni degli strumenti così io
certamente finito presto felice di portare
casi più specifici e discuterli
ma grazie a tutti
Please follow and like us: