47 Trusted site
6.1. Configurac¸ ˜oes Experimentais
com 10 milh ˜oes de linhas durante 20 minutos com um per´ıodo de ”aquecimento” pr´evio de 3minutos. Ainda, cada um dos testes foi repetido 5 vezes para calcular a m´edia e o desvio padr˜ao de cada execuc¸˜ao. De notar ainda que as avaliac¸ ˜oes dos micro testes, macro testes e com m ´ultiplos clientes demoraram aproximadamente 2 dias e 13 horas, 2 dias e 10 dias, respetivamente.
6.1.1 Yahoo! Cloud Serving Benchmark
OYCSB ´e uma plataforma de avaliac¸˜ao de desempenho de bases de dados NoSQL alojadas em nuvem, incluindo HBase, que permite a avaliac¸˜ao destes sistemas com workloads realistas [84]. A motivac¸˜ao da criac¸˜ao desta plataforma rege-se pela uniformizac¸˜ao do processo de avaliac¸˜ao de bases de dados, possibilitando a avaliac¸˜ao de sistemas diferentes com workloads iguais. Uma workload disp ˜oem de um conjunto de propriedades parametriz´aveis que ditam o ambiente de execuc¸˜ao e a carga de trabalho a ser exercida sobre a base de dados.
Cada propriedade presente numa workload influencia diretamente o ambiente de testes. As propriedades mais comuns do YCSB s˜ao: o RecordCount que corresponde ao n ´umero de linhas a inserir na fase de populac¸˜ao da base de dados (de notar que nesta fase n˜ao s˜ao realizadas operac¸ ˜oes para al´em da populac¸˜ao da base de dados); o OperationCount que corresponde ao n ´umero total de operac¸ ˜oes a efetuar durante a execuc¸˜ao dos testes de avaliac¸˜ao; MaxExecutionTime que corresponde ao tempo m´aximo de cada execuc¸˜ao (a execuc¸˜ao termina quando o tempo decorrido do teste ´e igual ao MaxExecutionTime especifi- cado ou quando o n ´umero total de operac¸ ˜oes foi atingido); o ThreadCount corresponde ao n ´umero de clientes (threads) de base de dados a operar em simultˆaneo; o RequestDistribu- tion corresponde ao tipo de distribuic¸˜ao a aplicar sobre a gerac¸˜ao de pares chave-valor e a ordem das operac¸ ˜oes a serem executadas. Os dois tipos mais comuns de distribuic¸˜ao s˜ao a uniforme (Uniform Distribution) que gera e distribui conte ´udo aleat ´orio e a zipfian (Zipfian Distribution) que gera e distribui o conte ´udo segundo uma distribuic¸˜ao em que certos ele- mentos da base de dados s˜ao acedidos mais frequentemente (mais populares). Por fim, o OperationProportion corresponde `a percentagem do tipo de operac¸ ˜oes a efetuar na execuc¸˜ao da workload. Esta propriedade ´e composta por um conjunto de 6 operac¸ ˜oes: InsertProportion corresponde `a proporc¸˜ao de operac¸ ˜oes de inserc¸˜ao (operac¸˜ao HBase Put); ReadProportion corresponde `a proporc¸˜ao de operac¸ ˜oes de leitura (operac¸˜ao HBase Get); DeleteProportion cor- responde `a proporc¸˜ao da operac¸ ˜oes de eliminac¸˜ao (operac¸˜ao HBase Delete); UpdatePropor- tion corresponde `a porporc¸˜ao de operac¸ ˜oes de atualizac¸˜ao de valores (operac¸˜ao HBase Put); ScanProportion corresponde `a proporc¸˜ao de operac¸ ˜oes de pesquisa (operac¸˜ao HBase Scan) e ReadModifyWriteProportion corresponde `a proporc¸˜ao de operac¸ ˜oes de leitura de uma linha, modificac¸˜ao de um valor, e respetiva atualizac¸˜ao desse valor (operac¸ ˜oes HBase Get-Put). A soma das proporc¸ ˜oes das operac¸ ˜oes a realizar deve ser igual a 100%.
6.1. Configurac¸ ˜oes Experimentais 63
Contudo, o YCSB nativo n˜ao fornece algumas propriedades ´uteis para a avaliac¸˜ao do sistema SafeNoSQL, que ´e o caso dos operadores de filtro, gerac¸˜ao de workloads pseudo- aleat ´orias e ainda ”tempo de aquecimento” pr´evio da base de dados. Desta forma, o m ´odulo YCSBpara a base de dados HBase foi modificado de forma a possibilitar estas propriedades. Ainda, o conjunto de propriedades disponibilizado pelo YCSB foi extendido com as pro- priedades: FilterProportion que corresponde `a proporc¸˜ao de operac¸ ˜oes de filtro; FilterType que corresponde ao tipo de filtro a ser executado (atualmente os filtros suportados s˜ao o RowFilter e SingleColumnValueFilter); CompareValue que corresponde ao valor a ser com- parado pelo filtro; FilterColumnDescriptors que indica a que column family e column qualifier o filtro ser´a executado; ComparisonProportion que corresponde `a proporc¸˜ao do comparador a usar sobre o filtro (=,>,<,>=,<=); Seed que corresponde ao valor a inserir nos ger- adores aleat ´orios que determinam a pr ´oxima operac¸˜ao e os valores sobre os quais ir´a ser aplicada, de modo a gerar valores pseudo-aleat ´orios e garantir sempre o mesmo ambiente de execuc¸˜ao; RampUpTime que corresponde ao ”tempo de aquecimento” da base de dados.
6.1.2 Esquemas de base de dados
De modo a avaliar de forma realista o sistema SafeNoSQL, foram criadas especificamente dois esquemas de bases de dados, tabelas 6 e 7, que simulam casos de estudo reais no ambiente do setor da sa ´ude [85]. Este caso de estudo ´e relevante pois, visto ser um setor que gere grandes quantidades de informac¸˜ao sens´ıvel acerca de pacientes, m´edicos, auxiliares de sa ´ude e infraestruturas de sa ´ude. N˜ao obstante, o armazenamento desta informac¸˜ao deve cumprir v´arios regulamentos legais relativos `a privacidade de dados [86]. Desta forma,
´e poss´ıvel extrair resultados mais relevantes, levando consequentemente a conclus ˜oes mais significativas acerca dos custos de desempenho induzidos pelo uso de diferentes t´ecnicas criptogr´aficas.
O primeiro esquema, Patients, ´e descrito na tabela 6 e complementa um subconjunto de dados tipicamente encontrados numa base de dados hospitalar que dizem respeito `a informac¸˜ao pessoal dos pacientes. Este esquema ´e composto por um identificador de linha para cada paciente, aleatoriamente gerado pela camada aplicacional, e por um conjunto de column families (Identificac¸˜ao, Contactos, Obs. e Cons.) que agrupam um conjunto distinto de column qualifiers que dizem respeito `a informac¸˜ao sens´ıvel dos pacientes (MainID, Nome, Apelido, D. Nasc., Nac., C.C., Morada, Contacto e Obs.). A column family Cons. pode ter um n ´umero dinˆamico de column qualifiers, cada um deles fazendo referˆencia ao identificador de uma consulta m´edica de um paciente em quest˜ao (este identificador diz respeito ao identificador de linha do esquema da tabela7).
A tabela 6 indica ainda o tamanho, em bytes, de cada column qualifier, bem como uma proposta das t´ecnicas criptogr´aficas a serem aplicadas sobre cada campo, de forma a obter o
6.1. Configurac¸ ˜oes Experimentais 64
melhor compromisso entre as funcionalidades a processar na base de dados e a privacidade da informac¸˜ao sens´ıvel dos pacientes.
Key
Identificac¸˜ao Contactos Obs. Cons.
MainID Apelido Nome D. Nasc.
Nac. C.C. Morada Contacto Obs. [1-*]
8 64 64 64 14 4 9 256 13 1024 8
DET DET STD STD STD STD STD STD STD STD STD
Cons. - Consultas; MainID - Identificador principal; D. Nasc. - Data de Nascimento; Nac. Nacionalidade; C.C. - Cart˜ao de Cidad˜ao; Obs. - Observac¸˜oes.
Tabela 6: Esquema de base de dados NoSQL relativo a pacientes hospitalares.
Como ´e poss´ıvel verificar, os campos diretamente associados `a informac¸˜ao pessoal dos pa- cientes s˜ao protegidos com Standard Encryption. Contudo, de forma a possibilitar computac¸˜ao sobre a informac¸˜ao dos pacientes, o column qualifier MainID foi protegido com Determinis- tic Encryption. Este identificador ´e constru´ıdo atrav´es do primeiro e ´ultimo nome e data de nascimento do paciente, sendo frequentemente usado para identificar os pacientes em sistemas da ´area da sa ´ude.
De notar ainda que o espac¸o de armazenamento de uma linha em plaintext ´e 1552 bytes e para o esquema seguro proposto ´e 1888 bytes. Este aspeto revela-se importante por representar novos compromissos em sistemas de computac¸˜ao segura sobre bases de dados NoSQL, que ´e o caso do espac¸o de armazenamento dos criptogramas e a largura de banda no processamento dos mesmos.
O segundo esquema, Appointments, ´e apresentado na tabela 7 e armazena as consultas m´edicas de um hospital para um dado m´edico e um paciente. O esquema ´e composto por um identificador de linha para cada consulta, gerado aleatoriamente pela camada apli- cacional, e por um conjunto de column families (M´edico, Paciente, Consulta e Instituic¸˜ao) que agrupam um conjunto distinto de column qualifiers que dizem respeito `a informac¸˜ao sens´ıvel das consultas m´edicas (M´ed. ID, Pac. ID, Data, Tipo, Obs., Nome e Morada).
Nesta tabela, ´e apresentada uma proposta para um poss´ıvel esquema de base de dados em que os column qualifiers M´ed. ID ´e cifrado com DET e a Data com OPE, enquanto que os restantes column qualifiers s˜ao cifrado com STD. Desta forma, o esquema permite realizar as operac¸ ˜oes mais comuns sobre consultas m´edicas, p.e., quais as consultas agendadas para um determinado m´edico para o mˆes x.
De acordo com a otimizac¸˜ao discutida na secc¸˜ao5.4, o column qualifier Data-STD ´e criado dinˆamicamente e permite reduzir o custo de decifrar dados protegidos com OPE. Relati- vamente ao espac¸o de armazenamento, uma linha em plaintext tem um tamanho de 1552 bytes, ao passo que uma linha do esquema seguro tem 1756 bytes.