Lnotes2
Allikas: Lambda
Hajutatud andmekogud
Mis sorti teemad seal on?
* integreerimine
ettevõttes hirmus palju osakondi,
rakendusi, värke, igaüks eraldi
seega mingeid joine ei saa teha
warehouse: teeme iga baasi külge
proge, mis ööseti pumpab päeva
data kesksesse baasi ühisesse
schemasse:
- sellelt saab teha joine
- tekivad päevased snapshotid
data warehouse tekiks:
- extract proged
- transform proge: teisendab
data ühise schema jaoks
- load: pumpad transformitud
data warehouse andmebaasi
- põhieesmärk: ülevaateraportid
* machine-readable web
semantic web project
pushiks rdf-i kasutamist
universaalse dataformaadina
- hajutamine: miks?
* üks server ei suuda vbl teenindada
* ühte serverisse data ei mahu
* CDN-i idee, data oleks kasutajatele
füüsiliselt lähedal
skypes läks kohe alguses vaja
----------
Memcached is an in-memory
key-value store for small
chunks of arbitrary data
(strings, objects) from
results of database calls,
API calls, or page rendering.
key-value baas
{"http://xx.com/api/people":23,
"bsesd": "dfsdfsdf",
...
}
põhirakendus: päringute cachimine
API päringud
- keyd
- aega, millal salvestati
- data
memcachedit on lihtne panna
korraga mitme masina peale
10 serverit, igaühes jookseb
variandid mis oleks:
- (memcached ei tee seda)
iga server sisaldab kogu datat
- iga server sisaldab osa datat
uus data tuleb mingi key "k1":
- peame otsustama mis serverisse
panna
- päring otsib "k1"-te: peame teadma
mis serveris ta on ja sealt
küsima
arvutad key hashi
hash("k1") oleks ntx 192202
jagad serverite arvuga, saad
jäägi: see on serveri nr
- alternatiiv: redis
veidi keerulisem datastruktuur
ja päringud
* Replikeerimine baasides:
põhiststsenaarium:
- ei mahu ära, ei jaksa
vastata päringutele
jagame osa datat ühte serverisse
teise osa teise, kolmanda
kolmandasse jne
- mis põhimõtte järgi?
* jagame väga suured tabelid
a la memcachedi moodi
ridade kaupa
kasutajanime esitäht:
a-c: server 1
d-k: server 2.
...
x-z: server N
osa datat replitseerida,
osa jagada
* osa tabeleid serverisse 1,
osa serverisse 2,
* eksootiline: osa tulpasid
suurest tabelist server 1,
osa server 2,
- kuidas tehniliselt saadad
ja päringuid ruudid?
--------
x-tee
------
mida ta teeb?
- põhimõtted:
- P2P:
asutused suhtlevad apide kaudu
omavahel, mingit keskust pole
kust data läbi jookseks
- API-de autentimine:
kokkulepe ja keskne süsteem
sertidega majandamiseks ehk
tuvastamiseks, et kas saatja/
saaja on ikka see asutus,
kes ta ütleb ennast olevat
Seda majandamist teeb x-tee
keskus.
- on olemas spec, et kuidas
konkreetselt teha SOAP apisid
et datat küsida ja saata
- SOAP
- kohustuslikud väljad headeris
- mismoodi datat tegelikult
kodeerid, on suuresti igaühe
oma teha
- tarkvaratükk nimega
x-tee turvaserver
reeglina pannakse eraldi linuxi
purki
kogu liiklus nii küsijalt kui
saajalt läheb läbi nende oma
x-tee turvaserver
optsioon:
- oma masinasse (võib virtual olla)
- kasutad mingit turvaserveri
hostingut
mida turvaserver veel teeb?
- logib enda kõhtu liikluse
metainfot ja osa liikluse
sisu, ca ühe kuu jagu
seda detailinfot ei saadeta
kuhugile
- nö basic metainfo, et kellega
on ühendust võetud ja mis
ajal, selle saadab turvaserver
keskusesse:
st keskuses on piiratud logi
logis on näha osapooled
ja aeg ja api calli nimi
- mis on x-tee lisaväärtus versus
harilik https?
Lisaväärtus on korrektne ja
kontrollitud autentimine, ehk
sertidega majandamine.
- tähelepanek: turvaserverit
ei ole väga lihtne konfida
- ajalugu:
- kui x-tee algas, siis tegid
softi kaks firmat:
Cybernetica
Assert .... Fujitsu
.... Aktors
- algul oli x-tee xml-rpc-ga
siis oli paralleelselt juures
soap
- lõpuks ainult soap
- regulaarselt iga paari aasta
tagant (ca 4-5 a) uued versioonid
Uusim x-tee versioon
- väiksed kasulikud headeri
muutused
- selle asemel et öelda
organisatsiooni id,
on nüüd ka alamorganisatsiooni
id
- hakati nõudma riistvaralist
turvat, st eriseadet arvuti
küljes sertidega kindlamaks
majandamiseks
- uuemale üleminek venis
planeeritust 1.5 a hiljemaks
ja praegu on käimas mõlemid
paralleelselt
RIA
https://www.x-tee.ee/docs/live/xroad/pr-mess_x-road_message_protocol.html