Para a avaliac¸˜ao do modelo proposto nesta tese, foi idealizada uma me- todologia de experimentos e nesta sec¸˜ao esta ´e discutida. A validac¸˜ao deste modelo esta sendo aplicada como estudo de caso, o primeiro experimento foi analisar o armazenamento e recuperac¸˜ao de imagens m´edicas no modelo atual, utilizando o sistema gerenciador de bancos de dados relacionais Post- greSQL. Desta forma, com os resultados do modelo atual ´e poss´ıvel trac¸ar comparac¸˜oes estat´ısticas com modelo que esta sendo proposto. Assim, todos os outros resultados obtidos ser˜ao comparados diretamente, com os resultados adquiridos nos testes do modelo atual.
Em um segundo momento a validac¸˜ao do modelo ´e efetuada a com- parac¸˜ao da aplicac¸˜ao do modelo em diferentes softwares para construc¸˜ao de SADs. Assim, identificando qual destes pacotes de software tem o compor- tamento mais eficiente, se integrado ao modelo proposto. Sobre o sistemas de arquivos distribu´ıdos que ser˜ao utilizados nos experimentos, estes s˜ao o Lustre, PVFS, CEPH e o FhGFS, por raz˜oes j´a expostas.
Como informac¸˜ao, o sistema de arquivos distribu´ıdos HDFS, do Ha- doop, foi exclu´ıdo das rotinas de experimentos devido a problemas de esta- bilidade que o mesmo apresentou quando integrado com o modelo proposto, ficando este como um dos trabalhos futuros a serem desenvolvidos. Proble- mas destas natureza, utilizando o HDFS j´a foram relatados na literatura, como por exemplo em (TANTISIRIROJ et al., 2011).
A metodologia de experimentos para o SGBD foi a mesma dos testes com os SADs, ou seja, foram realizadas operac¸˜oes com 1000, 2500, 5000 e 10000 imagens, onde foram coletados os tempos de inserc¸˜ao por objeto e ainda os tempos totais da operac¸˜ao. Baseados nestes dados, foram geradas as m´edias, medianas, desvio padr˜ao, maior n´umero e menor n´umero. O foco dos experimentos foi averiguar o desempenho e a escalabilidade do modelo hier´arquico proposto. Nestes experimentos foram tratadas as operac¸˜oes de armazenamento e recuperac¸˜ao de imagens m´edicas DICOM, tando de forma serial, como de forma paralela.
Por exemplo: foram armazenadas 1000 imagens DICOM de forma se- rial no sistema de arquivos distribu´ıdos CEPH, onde foram coletados o tempo
de cada uma das inserc¸˜oes no container HDF5 e o tempo total. Por fim, bus- cando garantir o m´ınimo de significˆancia estat´ıstica aos resultados dos testes, e ainda, buscando proporcionar maiores n´ıveis de confiabilidade nos dados apresentados, cada um dos testes foi realizados 25 vezes, onde extraiu-se a m´edia, mediana, desvio padr˜ao, menor valor e maior valor.
Sobre o tipo de exames que comp˜oem a base de dados, estes foram retirados aleatoriamente de uma base de dados de testes, com exames devida- mente anonimizados, para preservar a identidade dos pacientes. A proporc¸˜ao da quantidade de arquivos, por modalidades, foi determinada de acordo com a realidade de um sistema PACS de produc¸˜ao. Na Tabela 7 ´e poss´ıvel visua- lizar os tipos de modalidades que foram utilizadas, a quantidade de imagens por modalidade e ainda, o tamanho destes conjuntos de dados. A heteroge- neidade dos tipos de exames, de variadas modalidades diferentes ´e importante para simular um cen´ario real de um PACS em produc¸˜ao.
Modalidade Quantidade Tamanho
Raio-X Digital (CR) 100 1.1 Gb Ressonancia (RM) 300 0.135 Gb Tomografia (CT) 18530 9.2 Gb Angiografia (XA) 1977 3.4 Gb Ultra-som (US) 2370 2.1 Gb TOTAL 23277 15.935 Gb
Tabela 7: Composic¸˜ao da Base de Dados
Acerca do modo de operac¸˜ao dos testes, o fluxo de informac¸˜ao foi ini- ciado no cliente DICOM, que envia para o servidor DICOM uma quantidade Xde exames a serem armazenados, ou ainda, uma quantidade Y que deseja que sejam recuperados. O servidor DICOM, no caso do armazenamento, re- cebe a solicitac¸˜ao de armazenamento, e em tempo real inicia o recebimento das imagens e a posterior desconstruc¸˜ao das imagens e entrega para o modelo proposto (prot´otipo), que iniciar´a o procedimento de hierarquizac¸˜ao, indexa os metadados do exame, faz a selec¸˜ao do backend a ser utilizado, define a forma de armazenamento e de fato, finaliza com o armazenamento do dado. No caso do processo de recuperac¸˜ao de dados, o cliente DICOM solicita ao servidor DICOM a localizac¸˜ao de uma determinada imagem. O servidor en- trega a solicitac¸˜ao ao indexador do modelo proposto (prot´otipo). O indexador far´a uma consulta interna em sua base de dados e informar´a ao servidor DI- COM qual a localizac¸˜ao do exame solicitado dentro do container de dados.
Com relac¸˜ao ao modo de operac¸˜ao dos testes, no caso dos processos de avaliac¸˜ao do modelo proposto, foram utilizados o cliente DICOM, o servidor DICOM, o Nodo 1 atuou como servidor de metadados e dados, enquanto
os outros sete servidores atuaram como servidores de dados. No caso de avaliac¸˜ao do modelo atual, foram utilizados o cliente DICOM, o servidor DICOM e o Nodo 1 atual como servidor de bancos de dados, onde de fato estava instalado o sistema gerenciador de bancos de dados PostgreSQL.
Finalizando o cen´ario relativo a metodologia, na Tabela 8 pode ser vi- sualizado o tamanho dos conjuntos de dados e qual sua relac¸˜ao de tamanho para cada um dos backends, a saber, HDF5, CLucene, PostgreSQL e no sis- tema de arquivos. No caso do HDF5, esta informac¸˜ao faz referˆencia ao tama- nho do container HDF5 quando armazenado em um disco local. No caso do CLucene, esta informac¸˜ao faz referˆencia ao tamanho do ´ındice que ser´a pes- quisado. No caso do PostgreSQL, esta informac¸˜ao faz referˆencia ao tamanho dos conjuntos de dados quando persistidos neste SGBD. No caso espec´ıfico do filesystem, esta informac¸˜ao faz referˆencia ao tamanho dos conjuntos de dados quando persistidos nos sistemas de arquivos distribu´ıdos.
Imagens 1000 2.500 5.000 10.000
HDF5 695 MB 1.7 GB 3.4 GB 6.6 GB
CLucene 1004 KB 1.2 MB 2 MB 3 MB
PostgreSQL 488 MB 1.2 GB 2.4 GB 4.7 GB FileSystem 562 MB 1.3 GB 2.7 GB 5.3 GB
Tabela 8: Tamanho da Base de Dados