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