Talk:Opasnet base structure

Opasnet base should be restructured

How to read discussions

Fact discussion: .
Opening statement: Opasnet Base should be restructured. Closing statement: Resolution not yet found. (A closing statement, when resolved, should be updated to the main page.)
Argumentation: ←--1: . Nykyisen rakenteen suorituskyvyn rajat alkaa tosissaan tuntua. Isoilla datoilla latailu on hidasta vaikka kuinka sitä leikkaisi. Vajaa puoli tuntia meni ladata 11 000 riviä 44 000 000 rivin datasta (Op_en2778) R downloadilla, opasnetin käyttöliittymä crashaa ennen kuin mitään pääsee näkemäänkään, joka johtunee rivien laskemisesta, mikä kesti 95s MySQL Query Browserissa. Ladattavan datan leikkaaminen lokaatioiden perusteella on nykyrakenteen kriittisin heikko kohta. Se on pakko hoitaa erillisellä queryllä, joka tunnistaa haluttuun dataan kuuluvat ja/tai kuulumattomat solut. Toinen hieman pienempi ongelma on joinien suurehko määrä. En teknisistä yksityiskohdista mitään tiedä, mutta jos oletetaan että yhdessä joinissa tulee ekasta taulukosta poimittujen kriteerien määrä + tokan taulukon osumien määrä ylimääräisiä operaatioita verrattuna ideaalitapaukseen jossa data on valmiina sopivassa muodossa eikä näitä operaatioita tarvita. Joineja nykyrakenteella tulee ainakin 7 yhtä latausta kohden (obj -> actobj -> act l-> cell -> res l-> loccell -> loc -> obj); alkupään joinit ovat kuitenkin hyvin nopeita eli ei niillä väliä, mutta laskeskelin että ylimääräisiä operaatioita tulisi yhteensä noin 5 + ncell * (2 + nres + 5nloc/nind). Tämän kuvittelisin olevan mahdollinen pullonkaula datanlatauksen nopeudessa: Windowsin tehtävienhallinnasta network activity graphia katsomalla olen pannut merkille eri maksimilatausnopeudet isoilla ja hyvin isoilla datoilla. Vaihtoehtoisesti kannan voisi järjestellä niin että kutakin objektia kohti tulisi oma taulukko kantaan; Muutettaisiin nykyiset virtuaaliset taulukot oikeiksi taulukoiksi. Taulut olisivat jo valmiiksi samassa muodossa kuin nykyinen lopputulos: cell_id (series_id) (obs) ind1 ind2 ind3 res/SIP 1 (1) (0) 1 1 1 0 Objektien metadata, actit ja vaikka lokaatioiden tiedot voitaisiin keskittää omiin tauluihinsa, mutta nykyrakenteen raskain osa (rakenne) olisi valmiina. Samalla kannan käyttämisen koodi trivialisoituisi huomattavasti, niin että asiaan vihkiytymättömänkin olisi se helpompi ymmärtää ja kehittää omia sovellutuksia (itselleni tuli heti mieleen kahden taulun yhdistäminen ja tulostaminen vain tiettyjen lokaatioiden osalta databasen tasolla). Leikkaaminen olisi huomattavasti nopeampaa, kun pärjää yksinkertaisilla where lausekkeilla (WHERE obj1.ind1 (NOT) IN (...)). Joinien määrä putoaisi ja ylimääräisiä operaatioita olisi vain 5 + ncell * (1 + nloc/nind). Tilaakin säästyisi hieman kun loccell putoaisi pois kuvioista. Sippeihin vaihtaminen pitäisi samalla toteuttaa, niin ei tulisi toistettua samoja lokaatioita joka obsille. Kääntöpuolella käyttöoikeuksien hallinta vaikeutuisi, kun uuden objektin luomiseen tarvittaisiin oikeuksia tablejen tekoon ja dramaattisemmat muutokset nykyisissä taulukoissa vaatisivat oikeuksia muuttaa taulun rakennetta. Pieniä vaikeuksia tulee myös silloin kun jo olemassa olevaan objektiin ladataan aikaisempaan verrattuna eri muotoista dataa (eri indeksit): uusien indeksien lisääminen olisi triviaali toimenpide, ja poistaminen myös, jossa tapauksessa tosin vanha data tuhoutuisi. Jossakin erillisessä taulussa voisi kertoa sarjan käyttämien indeksien nimet, mutta silloin dataan jäisi turhia indeksejä lojumaan. En tosin nää mitään rajoitteita, jotka estäisivät taulukkojen massaamisen lataamalla objektit series_id kohtaisesti: nimeksi vaan concat(obj.id, series_id). Dataa hallittaisiin aika samoilla periaatteilla, queryt vaan menis uusiksi ja homma yksinkertaistuis. Näin tuumasin. Oliko järkeä? --Teemu R 12:42, 19 November 2010 (UTC) (type: truth; paradigms: science: defence) ⇤--2: . En innostu yhtään ajatuksesta, että kantaan pitäisi tehdä rakenteellisia muutoksia (eli lisää tauluja) muuttujien lisääntyessä. Kannan hienous on juuri siinä, että siinä on yksinkertainen mutta älyttömän joustava taulurakenne. Se että onko tämä vain fiilistelyä vai onko tässä jotain kovempaa tietoteoreettista pointtia onkin toinen juttu. --Jouni 12:42, 19 November 2010 (UTC) (type: truth; paradigms: science: attack) ⇤--3: . Vaihtoehtoisena ajatuksena esitän, että tosi isoille datoille perustetaan jokin eri kanta. Tämä ajatus on ollut ennenkin esillä, kun Kopra-datojen kohtaloa on mietitty (15 GB tavaraa). Järjestelmänhän pitäisi olla sillä tavalla joustava, että wikejä voi olla useita ja kantoja voi olla useita, ja kun nämä on esitelty toisilleen, mihin tahansa wikiin voi rakentaa muuttujan, jonka data voidaan ladata mihin tahansa näistä kannoista (suojausten puitteissa tietysti). --Jouni 12:42, 19 November 2010 (UTC) (type: truth; paradigms: science: attack) ⇤--4: . Minäkään en innostu ajatuksesta, jossa jokaisella objektilla olisi oma taulu. Parempi olla simppeli ja eheä rakenne, jota on siten helpompi hallita ja ylläpitää. Yritetään löytää ongelmiin muita ratkaisuja? Tuon UI:n osalta auttaisi paljon se, että pistettäisiin esim. ACT-tauluun uusia kenttiä, joihin on etukäteen laskettu esim. seuraavat tiedot koko datalle (actille): mean, result-rivien määrä, cell-rivien määrä. Noiden perusjuttujen selvittäminen isosta datasta on hidasta ja jos nuo lasketaan uploadin yhteydessä, niin saavutetaan jo erittäin merkittäviä hyötyjä nopeudessa. En nää uploadaamisen hitautta suurena ongelmana, jos nyt ei sentään päiviä kestä se lataaminen. Olennaista lie valmistella data kunnolla ja testata ensin pienemmällä otoksella, jotta vältytään lopulta turhalta työltä ja ajan haaskaukselta? --Einari 9:36, 22 November 2010 (UTC) (type: truth; paradigms: science: attack) ←--4: . Hienoa ajattelua ja perehtymistä tärkeään asiaan. Ensi lukemalla en ymmärtänyt kaikkia pointteja. Olen samaa mieltä, että pitkä joinien ketju on ongelma. --Jouni 12:42, 19 November 2010 (UTC) (type: truth; paradigms: science: defence) ←--5: . Kannatan siirtymistä SIPs and SLURPseihin. --Jouni 12:42, 19 November 2010 (UTC) (type: truth; paradigms: science: defence) ←--6: . Suurin ongelma mielestäni oli siis tuo datan leikkaamisen monimutkaisuus: Lopullinen query jolla data haetaan kannasta tuottaa taulukon jossa sarakkeet id, obs, loc, ind, res; lokaatiot ovat kaikki samassa sarakkeessa. Jos queryyn lisätään suorilta käsin where loc.id (not) in(), niin rivejä poistetaan sokeasti huomoimatta sitä että oikeasti pitää jättää matchaavien solujen lokaatiot kaikkiin objektin indekseihin ehjäksi/poistaa loputkin indeksit. Tätä pitää kiertää tunnistamalla erikseen solut, joilla on jossakin indeksissä jokin lokaatio joka halutaan mukaan/pois. Ja tämä kiertotie aiheuttaa isoilla datoilla usean minuutin queryn ennen varsinaista datan lataamista. --Teemu R 13:36, 19 November 2010 (UTC) (type: truth; paradigms: science: defence) ←--7: . Loccell on itse asiassa reippaasti suurikokoisin taulukko kannassa (Data length = 3.4GB; Index length = 9.2GB). Eli tällä uudella rakenteella säästyisi aika paljon tilaa... --Teemu R 07:50, 22 November 2010 (UTC) (type: truth; paradigms: science: defence)

Should all variables go to result distribution database?

How to read discussions

Fact discussion: .
Opening statement: Not all variables should go to the result distribution database Closing statement: Not accepted. (A closing statement, when resolved, should be updated to the main page.)
Argumentation: ←--1P: . There should be two levels of variables: 1) The results of important variables are uploaded in the result database, and they should be coherent with each other. 2) Other variables that are less important are used in case-specific assessments. They don't need to be coherent with all variables in the result database, only with those within the same assessment. --Jouni 23:52, 20 August 2007 (EEST) (type: truth; paradigms: science: defence) ----2P: . How do you define an important variable? I see variable importance as a varying aspect, not absolute and often case-specific. --Anna Karjalainen 14:17, 7 May 2008 (EEST) (type: truth; paradigms: science: comment) ⇤--3: . There is no separation to important and less important variables. There are only variables, and they are described in Opasnet. All these also go to the Opasnet Base. Some variables are in an early developmental stage and there is nothing to put to the Base yet, but this does not change the principle. However, there are also intermediate nodes in models that are not described as variables. They do not go into the Base. --Jouni 08:22, 21 February 2009 (EET) (type: truth; paradigms: science: attack)

Indeksien standardointi

Nykyään kantaan voi ladata mitä indeksejä tahansa. Jos samanniminen indeksi jo on, lokaatiot lisätään siihen. Jos samanniminen lokaatio jo on, käytetään sitä. Mutta jos on jo sisällöllisesti sama mutta nimeltään eri indeksi tai lokaatio, tätä ei tunnisteta millään tavalla. Tämä on iso ongelma, koska se estää tehokkaan muuttujien linkkaamisen toisiinsa samojen lokaatioiden osalta.

Ratkaisu: luodaan standardi-indeksien ja -lokaatioiden järjestelmä. Näitä käytetään aina kun mahdollista. Tarvitaan ylläpitäjä, joka seuraa uusia indeksejä ja tunnistaa, jos ne ovat sisällöltään samoja kuin jokin entinen. Kun tämmöinen löytyy, jokin indekseistä nimetään standardiksi (tai tarvittaessa luodaan uusi). Muut indeksit linkataan tähän, ja tulosteessa käytetään standardi-indeksin arvoja, ei alkuperäisiä.

Teknisesti tämä toteutetaan siten, että tarvitaan uusi taulu. Siinä on lista lokaatioita, ja kullekin lokaatiolle kerrotaan standardilokaatio. Tämä määrittelee samalla käytettävän indeksi yksiselitteisesti. Lista on uniikki lokaation suhteen mutta ei standardilokaation suhteen. Itse asiassa tästähän seuraa, ettei tarvita uutta taulua, vaan Loc-tauluun tarvitaan vain uusi kenttä standardilokaatiolle, mikä on paljon miellyttävämpi ratkaisu. Sen sijaan että käytettäisiin alkuperäistä Loc.id:tä, käytetäänkin Loc.Std_id ehdolla

<anacode> SELECT Rawloc.id, Loc.Obj_id_i, Loc.Location, Loc.Roww, Loc.Description FROM Loc AS Rawloc, Loc WHERE Rawloc.Std_id = Loc.id </anacode>

----1: . Tämä muutos on jo Opasnet-kantaan tehty. --Jouni 16:01, 22 May 2009 (EEST) (type: truth; paradigms: science: comment)

Tämä toimii joss kaikilla lokaatioilla on standardilokaatio. Tämä onnistuu, jos kaikkien lokaatioiden oletusarvo standardilokaatiolle on kyseinen lokaatio itse. Standardilokaation muutokset tekee ylläpitäjä käsin jälkikäteen.

SD

Salaisen datan käytössä on se ongelma, että se on salaista. Kuitenkin olisi tärkeää selvittää, kuinka tärkeää data on, ilman että paljastetaan, mikä se data on. Tähän tuli mieleeni ratkaisu:

Lähdetään siitä, että vaikka data sinänsä on salaista, sen keskihajonta on julkinen tieto. Niinpä voidaan Cell-tauluun lisätä kenttä SD, johon tämä hajonta sijoitetaan. Sen sijaan salatun tiedon tapauksessa Cell.Mean-kenttä jätetään tyhjäksi.

----1: . Tämä muutos on jo Opasnet-kantaan tehty. --Jouni 16:01, 22 May 2009 (EEST) (type: truth; paradigms: science: comment)

Nyt kuvitellaan tilanne, että meillä on muuttujasta julkinen estimaatti, joka on epävarma, ja salainen lisätutkimus, joka on informatiivinen. Jos tiedämme lisätutkimuksen hajonnan, voimme laskea EVPIIn (tiedon arvo osittaiselle epätäydelliselle tiedolle). Se tapahtuu siten, että oletamme saavamme tuon salaisen tutkimuksemme käyttöön, jolloin tiedon informatiivisuus lisääntyy eli keskihajonta kapenee. EVPIIssä verrataan alkuperäistä julkista jakaumaa tilanteeseen, jossa uusi tieto on jakauma, jonka keskiarvo otetaan alkuperäisestä jakaumasta arpomalla mutta keskihajonta salaisesta tutkimuksesta. Täydellisen tiedon EVPPIhän lasketaan muuten samalla tavalla mutta oletetaan, että uuden tiedon SD=0.

EVPII:n käyttö on erittäin tehokas työkalu osoittamaan sitä, kuinka kalliiksi yhteiskunnalle tulee jonkin tietyn informaation pimittäminen. Jos saamme pimitetystä tiedosta hajonnan selville, voimme demonstroida tämän kvantitatiivisesti. Tällä lähestymistavalla vielä tehdään jokin juttu Scienceen...

Res and Resinfo -tables should be merged

How to read discussions

Fact discussion: .
Opening statement: Res and Resinfo -tables should be merged Closing statement: Tables will be merged (A closing statement, when resolved, should be updated to the main page.)
Argumentation: ←--1: . Merging these tables makes some queries faster because we can get rid of at least one join-query --Juha Villman 12:51, 7 September 2009 (EEST) (type: truth; paradigms: science: defence) ----2: . Merging makes Res-table slightly larger (approx. 2 %) because Restext, Who and When -fields require some amount of space even if they are empty (10 bits). --Juha Villman 12:51, 7 September 2009 (EEST) (type: truth; paradigms: science: comment)