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