funkcionalitás
Az alábbiakban felsoroljuk az alapvető funkciók MDF:
-
kémiai szerkezet keresés: Teljes, Sub, okosság, hasonlóság, képlet
-
kémiai szerkezet keresések lapozható és gyorsítótárazott
-
támogatás többkomponensű vegyületek (keverékek)
-
3 kémiai szerkezet kereshető entitások: ChemicalCompound, Containable and ChemicalCompoundContainer
-
SD-fájlok importálása és exportálása 3 entitás felett
-
tranzakciós adatbázis-hozzáférés
-
opcionális biztonság (engedélyezés)
kémiai szerkezet keresések kombinálható tulajdonság keresések
az MDF tervezésével és funkcionalitásával számos különböző típusú rendszert lehet felépíteni, például regisztrációs rendszereket, leltárrendszereket vagy csak egy egyszerű összetett adatbázist. Bár saját ELN-t is létrehozhat, létezik az ingyenes Indigó ELN is. Ezt az ELN-t a GGA Software Services hozta létre, és a Pfizernél használják .
ellentétben a MolDB5R és a MyMolDB , MDF nem egy teljesen működőképes önálló webes alkalmazás kémiai szerkezet keresés. Ahogy a neve is mutatja, ez egy keretrendszer az ilyen alkalmazás létrehozásának egyszerűsítésére. Az MDF felhasználható helyi vagy kliens-szerver asztali alkalmazások létrehozására is. Az MDF a szoftverfejlesztőket célozza meg, nem pedig maguk a tudósok számára. Az MDF jellemzői azonban nagyon robusztusak. A kémiai szerkezet keresése az adatbázisban történik, nem pedig az alkalmazás kódjában. Így egyszerre kereshet kémiai szerkezet és egyéb tulajdonságok alapján, az eredmények több tulajdonság szerint rendezhetők, és lapozhatók (SQL OFFSET és LIMIT záradékok). Vegye figyelembe, hogy ha az alkalmazáskódban végzi a kémiai szerkezetkeresést, minden lekérdezéshez legalább két út szükséges az adatbázishoz, nevezetesen a szerkezetkeresés, majd a szűrés más tulajdonságok szerint, válogatás és/vagy korlátozás. Mindkettőnek ugyanabban a tranzakcióban kell történnie. Nem állapították meg, hogy a MolDB5R és a MyMolDB valóban ugyanazt a tranzakciót végzi-e.
az MDF-ben a kémiai vegyületek összekapcsolhatók egy tárolóval, amely a nyilvántartási rendszerekben tétel vagy egy leltárrendszer lenne. Ezután egy vonalkódos palackban egy fizikailag rendelkezésre álló minta társítható egy tartályhoz. Ezek a tartályok kémiai szerkezet szerint is kereshetők. Ez az alapja a leltárrendszer létrehozásának. A fejlesztők annyi további tulajdonságot adhatnak hozzá az egyes entitásokhoz, amennyit csak akarnak, és mindegyik kereshető a kémiai szerkezettel együtt.
az MDF-ben minden adathozzáférés tranzakciós, hogy megakadályozza az adatok következetlenségét. MDF lehet beállítani, hogy egy adatbázis kapcsolat medence. RDBMS lekérdezésekor a kapcsolat létrehozása gyakran több időt vesz igénybe, mint maga a lekérdezés, ezért ha már van nyitott kapcsolata, a válaszidők csökkenthetők.
a hasonlóság kereséséhez az MDF feltárta a Bingo patron által biztosított algoritmusokat, amelyek Tanimoto, Tversky és euklideszi metrika az alstruktúrákhoz.
az MDF készen áll a rugós biztonsággal történő használatra. A biztonság opcionális. Az MDF módszerszintű biztonságot (engedélyt) kínál. Nem kínál semmilyen hitelesítési funkciót.
Keverékkezelés
az MDF támogatja a többkomponensű kémiai vegyületeket. Az alstruktúra szerinti keresés minden olyan vegyületet visszaad, amelynek legalább egy komponense (kémiai szerkezete) megfelel a lekérdezési struktúrának. Ez azért fontos, mert a kémiai regisztrációs rendszerbe bevihető reakciótermékek szinte mindig keverékek, hacsak nem végeznek kiterjedt tisztítást.
Ha egy importált SD-fájlban egy bejegyzés több leválasztott struktúrából áll, akkor azt feltételezzük, hogy ez a bejegyzés keverék, és minden szerkezetet külön kémiai szerkezetként tárolnak.
struktúra normalizálása
alapértelmezés szerint az MDF tárolja a kémiai struktúrákat, amikor benyújtják őket. Az MDF nem végez kémiai szerkezetek szabványosítását/normalizálását. Az MDF-et használó fejlesztő feladata annak biztosítása, hogy a kémiai szerkezetek megfelelően normalizálódjanak, mielőtt azokat az adatbázisba mentenék. Jelenleg azt javasoljuk, hogy a fejlesztők végre egy ilyen funkció felülírja a preSave() módszer ChemicalCompoundServiceImpl. Ezt a módszert bármilyen kémiai vegyület létrehozása vagy frissítése előtt hívják meg. Ezen a módszeren belül a kémiai vegyület és az összes kémiai szerkezet, amelyből áll, tetszés szerint szabadon manipulálható. Vegye figyelembe, hogy minden mentett vegyület ezzel a módszerrel kerül feldolgozásra.
sók, szolvátok és oldatok
MDF jelenlegi verzió 1.0.1 nincs speciális kezelése sók, szolvátok vagy oldatok. Az MDF különálló komponenseket tárol egy kémiai szerkezetű fájlban, külön kémiai szerkezetként. Ezért megtakarítás só, mint 1 = CC = CC = C1. a két ion keverékeként jelenik meg, százalékok nélkül. Bármelyik ion pontos szerkezeti keresése visszaadja ezt a sót. Ha a só töltése nagyobb, mint 1, és több ion kapcsolódik hozzá, például 1 = CC = C = C1.. a sót 1 = CC = C = C1 keverékként tároljuk, százalékok nélkül. Ha a kémiai szerkezet egyetlen ion, akkor tárolható és kereshető lesz, mint bármely más kémiai szerkezet. Ha ez a viselkedés egy adott esetben nem megfelelő, a fejlesztők bevezethetik a salt és a solvate kezelési funkciókat a preSave () metódusban.
úgy tűnik, hogy egyes kereskedelmi rendszerek sem képesek kezelni a megoldásokat. Javasoljuk, hogy a vegyületet úgy hozza létre, mintha tiszta lenne, és a megoldási információkat külön mezőkként adja hozzá a vegyület szintjén.
példa webalkalmazás
egy egyszerű webes alkalmazás segítségével MDF jött létre. A webes alkalmazás a tavaszi MVC-t használja. Az alkalmazás nem használja a biztonsági integrációt, és nem használja a tárolható és a ChemicalCompoundContainer entitásokat. Csak vegyi anyagot használösszetevő entitás. Az alkalmazás egy összetett adatbázis többkomponensű vegyületek számára. Van egy oldala az SD-fájlban lévő kémiai struktúrák importálásához az összetett adatbázisba. Az adatbázis alépítmény és tulajdonságok alapján kereshető. A kémiai szerkezetek rajzolásához JSME-t használ (3.ábra). A keresési eredményoldal táblázatos és lapozott módon jeleníti meg a keresési találatokat. Amikor az alépítmény keresése megtörtént, az alépítmény kiemelésre kerül a keresési eredmények között (4.ábra). A találatok a keresési lehet exportálni, mint egy SD-fájlt. A keresési eredmények egyetlen összetett nézetre mutató hivatkozást tartalmaznak. A vegyület tulajdonságai szerkeszthetők, a kompozíciók hozzáadhatók, szerkeszthetők és törölhetők (5., 6. ábra). Vegyület vagy összetétel szerkesztésekor az alkalmazás átláthatóan foglalkozik az egyidejű módosításokkal, és megjelenik a konfliktusmegoldási párbeszédpanel, amelyen a felhasználó kiválaszthatja, hogy mely értékeket használja az egyes tulajdonságokhoz, majd elmentheti az új verziót.
a példa webalkalmazás Keresési oldala MDF használatával. A felhasználó kereshet az összetett adatbázisban kémiai alszerkezet és/vagy tulajdonságok, például összetett név vagy CAS-szám alapján.
egyetlen összetétel. Ugyanazt az oldalt mutatja, mint az 5. ábra, de a kombinált szerkezet fül helyett az első kompozíció lapja van kiválasztva. A kompozíció szerkeszthető az oldalon található megfelelő linkre kattintva.
teljesítmény
az MDF-nek egy fő teljesítményproblémája van a keverékek kezelésekor. Ha egy alkalmazás keverékeket, azaz több komponenst tartalmazó vegyületeket használ, a kémiai szerkezet lekérdezés egy sort ad vissza a lekérdezésnek megfelelő vegyület minden összetevőjéhez. Ez nem kívánatos, mert a végfelhasználók minden olyan vegyületet szeretnének látni, amely csak egyszer felel meg a lekérdezésnek. A probléma megoldása egy különálló lekérdezés használata, és itt történik a teljesítményprobléma. Ha külön lekérdezést hajt végre, a teljes adatbázist a limit záradéktól függetlenül kell keresni, ami jelentősen megnöveli a végrehajtási időt. Vegye figyelembe, hogy a válogatásnak ugyanaz a hatása. Tehát a válogatásnak hatalmas teljesítménybüntetése is lehet, és lapozáskor mindig rendeznie kell, hogy kiszámítható eredményt érjen el. Ahhoz, hogy ez még rosszabb Bingo patron PostgreSQL még nem rendelkezik megfelelő végrehajtását költségbecslés és a költségek használata a kémiai szerkezet index kemény kódolt és alábecsülik. Ez félrevezeti a PostgreSQL lekérdezési gyalut, hogy mindig teljes indexvizsgálatot használjon a structure search Indexen, még akkor is, ha a lekérdezésnek van egy további where-záradéka, amely nagymértékben korlátozza az eredmények mennyiségét. Ezekben az esetekben például gyorsabb lenne az index használata a CAS-számhoz, és a Bingo matchsub függvény használata a szűréshez. A matchsub függvény nem alépítmény megfelelő index nélkül. Ez természetesen lassabb, mint egy Indexnél, de ha csak kis számú struktúrára van szükség, akkor sokkal gyorsabb, mint a teljes indexvizsgálat. A költségbecslési probléma kijavításához az MDF végez néhány belső számítást, hogy kifejezetten eldöntse, hogy a structure index vagy a matchsub függvényt használja-e. Ez nagyságrenddel javíthatja a teljesítményt. Vegye figyelembe, hogy a bingó patron szállítója tisztában van ezzel a problémával, és a javítás ütemterve 2013 vége volt. A különböző lekérdezések és rendezés fő kérdése azonban a relációs adatbázisok működésében rejlik, és nem oldható meg, kivéve egy jobb alszerkezeti keresési indexet vagy jobb hardvert. MDF is kínál egy beállítást, hogy tiltsa le a különböző lekérdezések alkalmazás-szerte az egykomponensű összetett adatbázisok.
az MDF összehasonlításához a korábban vázolt webes alkalmazást használtuk. Az adatbázis 525573 egyedi vegyületet tartalmaz. A vegyületek a cink részhalmaza 13 referencia pH 7 az SD-fájlok 13_P0.0.sdf, 13_p0. 1.sdf, 13_p0. 10.sdf és 13_p0. 11.sdf. A struktúrákat MOSOLYKÉNT tárolják az adatbázisban. Az SD-fájlok importálása, amelyek körülbelül 131 000 kémiai szerkezetet tartalmaznak, 12 percet vett igénybe a kémiai szerkezet keresési index letiltásával. Az index újjáépítése az összes SD-fájl importálása után 22 percet vett igénybe egy laptopon 4 GB RAM-mal, Core i5-3220m CPU-val és egy 512 GB-os Samsung 830 SSD-vel. Ez összesen 1 óra 10 perc, hogy beállítson egy teljesen indexelt adatbázist félmillió vegyülettel. További referenciaként ugyanezt az importálást 12 GB RAM-mal, i7-875K @ 3.4 GHz-es asztali PC-n, valamint Western Digital Green meghajtón (5400 fordulat / perc) futó adatbázison végezték. Itt az import 8 percet vett igénybe, és a következtetés az, hogy az import CPU korlátozott, nem pedig a tárolási sebesség korlátozza. Az index generálása körülbelül 22 percet vett igénybe a laptopon és 20 percet az asztalon. A következtetés itt az, hogy inkább a CPU korlátozza, de a meghajtó sebessége is számít. A struktúrák molfile-ként való tárolásakor az importálási és indexgenerálási teljesítmény nem volt benchmark.
az alépítmény keresési teljesítményét különböző konfigurációs beállításokkal hasonlítottuk össze. Az alépítmény keresést a Bingo PostgreSQL patron végzi,ezért ez a benchmark tükrözi annak teljesítményét, valamint az MDF által okozott esetleges rezsi. A c1ccccc1 kivételével a szerző olyan kémiai struktúrákat rajzolt, amelyeknek nincs különösebb jelentősége, és tesztelte a keresési sebességet. A keresési sebességet az org logbacks megvalósítása határozta meg.slf4j. profiler.Profilozó.
az első referenciaérték egy referencia. Ez a benchmark az összes különálló lekérdezés letiltását használta, és nem történt rendezés. Az MDF elvégzi a teljes találatok számát A kémiai szerkezetkeresés első előfordulásakor, és a számlálás gyorsítótárba kerül, ami az első oldal lassabb betöltését eredményezi, mint a következő oldalak. Minden oldal 4 rekordot tartalmaz. Az eredményeket a 2. táblázat mutatja A találatok száma szerint növekvő sorrendben.
a benchmark megismétlődött, de ezúttal különálló lekérdezések engedélyezve. Az első oldal betöltési ideje megduplázódik, mert a számlálási lekérdezés fut, majd a tényleges lekérdezés fut, amely a különálló záradék miatt körülbelül ugyanannyi időt vesz igénybe, mint a számlálási lekérdezés. A második oldal betöltése ugyanebből az okból mindig fele annyi időt vesz igénybe, mint az első oldal (3.táblázat). A találatok száma megegyezik a 2. táblázatban szereplőkkel, mivel az adatbázisban szereplő összes vegyület csak egy komponensből áll.
Az eredmények azt mutatják, hogy a Bingo nem optimalizál egy általános alépítmény lekérdezést, mint például egy benzolgyűrű, és így keresi a c1ccccc1-et egy olyan adatbázisban, amelyben szinte minden molekula ez a funkció nagyon lassú. A keresési sebesség javítása ilyen forgatókönyv esetén a további tulajdonságok szerinti szűrés ajánlott. Ezért a benchmark megismételtük egy további szűrő vegyület neve kezdődő “ZINC34”.
A 4. táblázat bemutatja az MDF optimalizálás előnyeit, mint a Bingo PostgreSQL patron költségbecslési problémájának megkerülését. Ezen optimalizálás nélkül a referenciaérték ugyanolyan teljesítményt nyújtana, mint a 3.táblázat.
az MDF bingó patronok hasonlóságkeresési funkcióját is használja. Teljesítményét 0,9-es hasonlósági pontszámmal rendelkező vegyületek keresésével tesztelték a Tanimoto hasonlósági intézkedés más néven Jaccard Index. Az eredményeket az 5.táblázat mutatja.
Outlook
a kémiai szerkezeti ábrázolások előállításához az Indigo eszközkészletet használják. Az eszköztár sokféle módon konfigurálható a struktúrák létrehozására, beleértve a heteroatomok színezését, a kötés hosszát és szélességét és még sok mást. Jelenleg ez kemény kódolású, és a felhasználó nem tudja beállítani. A következő lépés az lenne, hogy ki ezeket a konfigurációkat lehetőségeket, így lehet beállítani egy Java properties fájlt. A sók és szolvátok kezelését is meg kell valósítani annak érdekében, hogy az MDF felhasználható legyen olyan területeken, ahol az ilyen vegyületek fontosak.
az MDF használatához képesnek kell lennie a Java programozására, és alapvető ismeretekre van szüksége a Spring framework-ről és annak konfigurálásáról. Ez korlátozza a célközönséget. Az MDF használatakor meg kell írni néhány kazán-lemez kódot, és ezért a következő lépés az lenne, hogy további eszközöket hozzon létre az MDF használatának megkönnyítésére, mint például az entitás osztályok és azok tárolóinak és szolgáltatásainak automatikus generálása. Ezeknek az eszközöknek konfigurálhatónak kell lenniük, hogy a felhasználó meg tudja határozni az egyes entitások kívánt tulajdonságait és a kívánt keresési módszereket. Egy lehetőség lenne egy Maven plugin. Maven plugins generálhat kódot, mint a metamodell létrehozása által végzett QueryDSL-maven plugin. Egy másik lehetőség a kommentárok, amelyek kódot generálnak a fordításon, mint a Lombok projekt .
az utolsó lépés egy olyan webes alkalmazásplatform létrehozása lenne, amely lehetővé teszi a rendszergazdák számára, hogy új webes alkalmazásokat hozzanak létre kémiai szerkezet Keresési képességgel, egyszerűen megadva az entitások kívánt tulajdonságait egy webes űrlapon, majd egy gombra kattintva. Nyilvánvaló, hogy ehhez jelentős fejlesztési erőfeszítésekre lenne szükség.
