Levelezés

Nincs még Molbiol Mailes címed? Katt ide!


Szerkesztenéd a blogot? Egyszerűen csak írnál? Katt ide!

Lájkolom továbbá

molekuláris biológia online - molbiol, genomika, bioinformatika, hírek, meg ami közben eszembe jut

2011.03.11. 00:13 Kommentáz Károly

Egy bioinformatikai rendszer lehetséges lappangó betegségei

Címkék: hír genom bioinformatika ncbi sra

Share |

Nemrég a Genomika Blogon olvastam, hogy az NCBI megszünteti a Sequence Read Archive genomi szekvenciaadatokat kiszolgáló adatbázisát. Az NCBI nem indokol, inkább ajánl helyette 5 másik adatbázist.

A Genomika Blogon viszont azt olvashatjuk, hogy az NCBI esetleg nem tudott elég háttértárat beboltolni vagy a sávszélesség biztosítása fájt túl sokba a bioinformatikai óriásszervezetek. Természetesen ez is lehetséges, én viszont – a Sequence Read Archive pontos felépítését nem ismerem ugyan – kevésbé prózai tényezőket tartok valószínűnek, ami miatt az adatbázist a régi formájában már nem tartják fenn. Teljes bizonyossággal pedig, senki sem tudná megmondani, hogy miért is szüntették meg, erről fogok most írni.

Bármilyen informatikai projekt vagy működő rendszer később elcsúszhat olyan dolgokon is, amit alapos előre tervezéssel meg lehetett volna előzni, utólag viszont senki sem vallaná, hogy hibázott. Az egyik, talán legfontosabb, hogy a rendszer működtetéséhez szükséges hardver- és szoftverkomponensek legyenek egymástól annyira függetlenek, amennyire csak lehet (régebben beállított rendszereknél ez annyira nem természetes), ezen kívül mindig arra a megoldásra kell hajlani, ami olcsóbb. Hogy a webprogramozás köréből említsek egy nagyon egyszerű példát – akármerre is navigáltok a neten, sokszor a böngésző címsorában látható, hogy a cím php-ra végződik, ami most annyit jelent, hogy az adott dinamikus webhelyet szerveroldalon egy PHP technológiában megvalósított szoftver generálja ki, majd küldi vissza a böngészőprogramnak a ténylegesen megjelenítendő, ún. kliensoldali kódot. Nos, az ún. PHP-interpreter, ami a PHP nyelven megírt programot futtatja a szerveren, többféle is lehet, ezek közül a két legelterjedtebb a PHP Community által kiadott, teljesen ingyenes PHP interpreter, a másik pedig a Zend Technologies által kínált Zend Web Application Server, amiért viszont kemény pénzeket kell fizetni* függően többek közt attól, hogy az IT staff melyik terméktámogatási szint mellett dönt. Abban az esetben, ha egy rendszert felhúznak egy Zend motorra, majd a későbbiekben kiderül, hogy a PHP Community ingyenes PHP motorja több szempontból kedvezőbb, legrosszabb esetben egy éjszaka alatt a szerver(ek)en ki lehet cserélni az egyik motort a másikra anélkül, hogy ez komolyabb kiesést eredményezne. De gondoljunk bele abba, hogy ha egy internetszolgáltató webhosting szolgáltatásáról van szó, és a korábbi Zend motor több tízezer dinamikus webhelyet szolgál ki egy időben! Vagy éppenséggel a világ legnagyobb közösségi hálója, a Facebook alatt próbálnák kicserélni a Zend motort, miközben több millió felhasználó használja egyidejűleg! (A FB természetesen a kezdetektől a PHP Community motorját használja.) Ilyen esetben, ha a szolgáltatás rövid kimaradása nem lenne elég ciki, azzal is számolni kell, hogy az új interpreter a PHP-kódokat esetleg nem ugyanúgy futtatja, mint a másik, így a teljes webszolgáltatás nem működik normálisan, ergo legrosszabb esetben a konfiguráció finomhangolása néhány órás rémálommá válhat, mire a rend helyreáll.

És ez csak egy egyszerű példa volt! Lehet szó olyan szoftverkomponensről is, aminek a használati jogát az NCBI olyan szerencsétlenül vásárolta meg, hogy arról nem tud átváltani egy újabban megjelent olcsóbb vagy teljesen ingyenes verzióra, horribile dictu egy ilyen fizetős komponensre épül más, a rendszer működéséhez elengedhetetlen szoftver. Azaz az egészet vérrel-verejtékkel a felismerhetetlenségig át kellene operálni, egy új szoftveres architektúrára váltás esetén.

Az adattárolás módjával kapcsolatos változtatás kevésbé játszhat be, mert egyik típusú adatbázisból egy másik típusú adatbázisba való átkonvertálás nem probléma, általában. De gondoljunk bele, hogy akár az Oracle és a MySQL, akár a MySQL és annak követhetetlenül sok klónja közt is mennyi apró eltérés van, amit mind figyelembe véve azt mondhatjuk, hogy egy extrém nagy rendszer esetén a programozót ki lehet vele kergetni a világból.

Ha pedig specifikus területet nézünk, azt látom, hogy a bioinformatikai szoftverek piacán a kompatibilitás megőrzése vagy fenntartása szinte az utolsó szempont, amiből szintén adódhatnak galibák egy átálláskor.

Azaz általánosságban elmondhatjuk, hogy bármilyen rendszer áthelyezhető ugyan akár teljesen eltérő technológiai alapokra is kisebb-nagyobb energiabefektetéssel, gyakorlatilag ilyen csak akkor történik, ha már minden kötél szakad. Én konkrétan tudok olyanról, hogy egy több millió ügyféllel rendelkező telekom szolgáltató csillagászati összegért beboltolt egy olyan szoftverrendszert, ami nap, mint nap a legváltozatosabb hibajelenségeket produkálja, a szoftverrendszer support csoportja mégis sokszor csak tüneti kezelést tud alkalmazni. A dolog pikantériája, hogy nyílt forráskódú rendszer ide vagy oda, abban ez esetben, ha a szóban forgó szolgáltató, mint ügyfél, megbízna egy szakit a rendszer feljavításával, amint valaki belekotorna a forráskódba, a méregdrága support-licensz elveszne.

Az általam kevéssé ismert szekvencia adatbázis esetén tehát jóval valószínűbb, hogy időben fellépő kompatibilitási problémák tömege jelent meg, amiknek a kiküszöbölése olyan égtelenül drága lett volna, hogy az NCBI célszerűbbnek tartotta más adatbázisaira fordítani azt a pénzt, amit átállításra fordítottak volna, ha a szolgáltatás továbbra is marad. 

 

*több helyen kicsit szájbarágós lett a poszt, mielőtt valaki megjegyezné: igen, tudom, hogy a Zend-nek is vannak ingyenes megoldásai viszont ahhoz semmilyen terméktámogatás nem jár és – lévén, hogy nem nyílt forrású szoftverről van szó – azon túl, hogy egy-egy, az interpreter sajátosságából adódó beállítás kikutatása is jókora szopó lehet, biztonság szempontjából is rizikós, különösen nagy bioinformatikai rendszereknél, ami többek szerint a kiberterrorizmus 2-3. legnagyobb célpontjaivá váltak.

1 komment

A bejegyzés trackback címe:

https://molbiol.blog.hu/api/trackback/id/tr302729688

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

ebarta · http://genomika.blog.hu/ 2011.03.20. 18:32:31

"Az általam kevéssé ismert szekvencia adatbázis esetén tehát jóval valószínűbb, hogy időben fellépő kompatibilitási problémák tömege jelent meg, amiknek a kiküszöbölése olyan égtelenül drága lett volna, hogy az NCBI célszerűbbnek tartotta más adatbázisaira fordítani azt a pénzt, amit átállításra fordítottak volna, ha a szolgáltatás továbbra is marad."

IMHO ez egy téves megállapítás. A rendszer tökéletesen működött/működik! Ráadásul ezeknek az adatoknak a letöltéséhez nem kell semmi komolyabb informatikai hókusz-pókusz, én egyszerűen a jó öreg ftp protokollt használom! A genomika.blog.hu posztom óta egyébként beszéltem külföldi, nálam jobban informált bioinformatikusokkal erről, és mindenkinek az az egybehangzó véleménye, hogy a legnagyobb probléma most a sávszélesség. Magyarul olyan (és exponenciálisan növekvő) mennyiségű adatot (egy-egy NGS szekvenálás eredménye több tíz, sőt mostanában akár 100 Gbyte is lehet) próbálnak fel és letölteni, ami lelassítja, használhatatlanná teszi a rendszert.
A megoldás, amit az EU ELIXIR programja is próbál megvalósítani, az az elosztott adattárolás, azaz, hogy én például ne Amerikából vagy Hinxtonból, hanem egy magyar szerverről töltsem le az adatokat.
Mivel lassan az EBI szerverek elérése is nagyon lassú lesz, előbb-utóbb kénytelenek leszünk mi is áldozni ilyen szerverekre.

Az SRA honlapján felsorolt más adatbázisokban meg eddig is megvoltak ezek az adatok. A különbség az, hogy az SRA-ban vannak a durva szekvenálási adatok (szekvecia read-ek és a hozzájuk tartozó minőségi értékek), míg a GEO-ban például a már feldolgozott adatok (pl. ChIP-seq esetében a beküldők által meghatározott csúcsok)

Web Stats