Apresentação

1ISACA JOURNAL VOLUME 5, 2013

O surgimento de plataformas de computação em nuvem com bases de usuários maciças e grandes exigências de transação e taxa de transferência obrigou as empresas a encontrar formas de escalar os serviços de forma rápida e com baixo custo. Isso pressiona os arquitetos de sistema a criar sistemas maiores e melhores de forma rentável. Na era do big data, as empresas estão observando cada vez mais os caches enormes de dados subprocessados ou descartados como recursos a ser explorados.

O processamento de grandes volumes de dados requer uma plataforma rápida e escalável. Antes, as implementações desses tipos de plataformas estavam limitadas a algumas grandes empresas, que podiam pagar por essas soluções de mineração de dados de alto custo. Atualmente, as empresas têm mais opções. Este artigo fornece uma visão geral de uma das opções disponíveis - o In-Memory Database (IMDB)1 - a evolução e os riscos envolvidos na adoção.

A tecnologia IMDB tem sido apontada como a solução para problemas de desempenho de banco de dados - o fator principal é a capacidade para carregar e executar todos os dados na memória. Isso remove uma quantidade considerável de entrada/saída (E/S) relacionada a problemas de desempenho com sistemas de banco de dados. No entanto, as tecnologias IMDB apresentam um risco fundamental, que deve ser considerado na implementação: durabilidade dos dados, controles de segurança mais flexíveis (em comparação com o banco de dados homólogo completo) e as preocupações de migração. É fundamental que o risco seja considerado quando se está explorando a utilização da tecnologia IMDB.

FORMAS DE SE ESCALARHá duas maneiras de escalar aplicações: horizontal e verticalmente. Escalar horizontalmente permite que a empresa crie aplicações que podem ser utilizados simplesmente adicionando nós de computação quando precisam de maior capacidade. Em geral, os aplicações que

exigem uma grande quantidade de dados de trabalho atômico ou a realização de uma grande quantidade de operações exclusivas/excessivas são adequados para a paralelização horizontal. Há pouco tempo, isso foi chamado de paralelo ou supercomputação.2 Aplicações grandes da web em que cada transação é atômica e não depende de outras transações concorrentes, é um exemplo de escala horizontal. Portanto, cada transação pode ser encaminhada para os nós de computação separados para processamento. A escala horizontal permite que o Facebook, Linkedin e Twitter lidem com milhões de usuários. Entretanto, nem todos os aplicações são facilmente transportáveis para plataformas de escala horizontal. Um dos principais desafios da escala horizontal é que os aplicações geralmente não são criados com a escalabilidade horizontal/simultaneidade em mente. Mesmo os aplicações típicos de desktop não são criados para utilizar a unidade central de processamento (CPU), que são núcleos disponíveis em plataformas de computação modernas. Nestes casos e em outros semelhantes, as empresas podem optar por utilizar a escala vertical.

Escalar verticalmente envolve o aumento da capacidade interna de um sistema para que ele possa lidar com mais transações. Esse normalmente é o modo mais rápido para aumentar a capacidade sem alterar de forma considerável o ambiente de operação ou a arquitetura do sistema. O aumento da memória ou o armazenamento em disco de um sistema de computação para processar mais transações é um exemplo de escala vertical. A escala vertical não se limita à adição de hardware, mas também pode ser utilizada para melhorar o aplicação, para tirar o máximo proveito dos recursos existentes. No entanto, a escalabilidade vertical é geralmente mais cara.

ESTÁ TUDO NA MEMÓRIA RAMHá também outras formas de aumentar a escalabilidade de sistemas verticalmente. Uma delas é a utilização da tecnologia de computação In-Memory. A habilidade de

William Emmanuel Yu, Ph.D.,

CISM, CRISC, CISSP, CSSLP,

é vice-presidente de tecnologia

na Novare Technologies. Yu

está trabalhando em serviços

de telecomunicações de

última geração, integração de

sistemas com valor agregado

e projetos de consultoria

com foco em convergência

fixo-móvel e aplicações de

mobilidade empresarial com

operadores de rede móvel

e fornecedores de tecnologia.

Ele está ativamente envolvido

na engenharia da internet,

plataformas móveis e pesquisas

de segurança da informação.

Yu também é membro do corpo

docente da Universidade Ateneo

de Manila, Filipinas, e do Instituto

asiático de gerenciamento,

Manila, Filipinas.

Computação In-Memory — Evolução, oportunidades e riscos

2 ISACA JOURNAL VOLUME 5, 2013

escalar sistemas envolve a identificação de gargalos ao realizar transações. Ao determinar as principais áreas de desaceleração, os arquitetos de sistemas podem trabalhar na otimização dessas áreas, sem a necessidade de comprar mais hardware. Diferentes aplicações terão diferentes níveis de um determinado recurso e terão diferentes gargalos.3 Para aplicações baseados em dados, o gargalo mais provável é o armazenamento em disco ou E/S. Um gargalo existe quando o aplicação exige muita interação de dados e, posteriormente, o acesso ao disco. Uma grande quantidade de aplicações de banco de dados complexos é associada à E/S.

Por outro lado, o acesso à memória é normalmente medido em nanossegundos, enquanto o acesso de armazenamento em disco é medido em milissegundos.4 Isso mostra que o acesso à memória é muito mais rápido do que o acesso de armazenamento em disco. Portanto, uma possível solução para aplicações associados à E/S é o uso de computação In-Memory. Todos os dados são carregados na memória, e todas as transações são executadas na memória. A manifestação mais tangível da computação In-Memory é o IMDB. Os IMDBs proporcionam ganhos significativos de desempenho, armazenando todos os dados na memória principal, em vez de utilizar discos. Isso oferece o benefício da capacidade de executar operações de E/S inteiramente na memória. Uma pessoa que memoriza o dicionário pode responder mais rapidamente a uma consulta de definição de palavra do que uma pessoa que não memorizou o dicionário inteiro, e tem que procurar a palavra em um livro impresso.

QUEM PODE SE BENEFICIAR COM A COMPUTAÇÃO IN-MEMORY?O primeiro passo para determinar a necessidade da computação In-Memory é definir se o aplicação requer uma grande quantidade de acesso e manipulação de dados. Normalmente, os aplicações de banco de dados podem se beneficiar da tecnologia IMDB. Em geral, qualquer tipo de transação de banco de dados será mais lenta em um banco de dados baseado em disco em comparação a um IMDB. As empresas são atraídas para os IMDBs porque estes permitem fácil portabilidade de aplicações de sistemas de banco de dados baseados em disco. Nem todas as especificações e os aspectos relacionados a eles serão considerados no início e utilizados para a necessidade de planejamento prévio e implementação da tecnologia de IMDB. Às vezes, os gargalos podem ser determinados durante o curso do desenvolvimento, testes de aceitação do usuário ou mesmo durante a produção atual.

Duas formas comuns para determinar gargalos de E/S são:1. Problemas de E/S que se manifestam como uma alta

utilização da CPU - Por exemplo, se o disco de E/S está ocupado em um sistema, o processo de espera de E/S pode tomar um tempo considerável da CPU. Em

alguns casos, o processo do banco de dados mostra uma alta utilização da CPU. Portanto, algumas pessoas pensam que é a CPU (poder de processamento) que precisa de atualização. Na realidade, é o subsistema de armazenamento que é o gargalo e precisa ser resolvido.

2. Sistemas operacionais com ferramentas de monitoramento de E/S - Linux e sistemas derivados do UNIX vêm com a ferramenta iostat5 altamente funcional. Os sistemas baseados no Windows MS vêm com o perfmon.6 Os administradores devem procurar parâmetros como o comprimento médio da fila, o tempo médio de transferência e o tempo de disco percentual. Se esses valores forem elevados, há a possibilidade de contenção de E/S.A melhor maneira de determinar se um aplicação pode

se beneficiar com a tecnologia IMDB é experimentar as soluções. Há uma série de soluções comerciais (Oracle TimesTen,7 SAP HANA,8 IBM solidDB,9 VMWare Gemfire10) e de plataforma aberta (MySQL cluster,11 SQLite,12 VoltDB,13 Druid14) disponíveis no mercado.

A RAM É VOLÁTIL? MEUS DADOS ESTÃO SEGUROS?Há muitos fatores que devem ser considerados com qualquer nova tecnologia introduzida no mercado, e o primeiro deles é a durabilidade. É a primeira coisa que geralmente vem à mente ao usar uma tecnologia de computação In-Memory. A memória principal é volátil; portanto, quando a energia é cortada, os sistemas perderão os dados na memória. Essa perda de dados é especialmente prejudicial para aplicações orientados a dados. No entanto, a maioria das soluções In-Memory tem um mecanismo para assegurar que os dados sejam preservados. O mecanismo mais comum é gravar novamente no armazenamento persistente.

Entretanto, isso exige a dependência de discos (lentos). No entanto, a maioria das soluções do mercado usa algo chamado gravação no cache e na memória principal “preguiçosa” ou “imprecisa”. Isso significa que a execução da transação é feita inteiramente nos dados armazenados na memória. As transações são armazenadas na forma de um buffer de log, que também está na memória. O sistema irá gravar os dados em disco para persistência. No caso de falta de energia, há uma chance de perda de dados se o buffer de log não conseguiu completar a gravação em disco. No entanto, a maior parte do banco de dados estará intacta. Algumas soluções IMDB (ex: Oracle TimesTen) permitem variar a “preguiça” da gravação no cache e na memória principal, dependendo da importância das transações. Gravações com baixo valor (ou seja, registros de transação) atrasam as gravações para o disco por um longo período e reduzem a carga de E/S em relação a gravações de alto valor (ou seja, Airtime top-up), que grava de forma síncrona no disco para

3ISACA JOURNAL VOLUME 5, 2013

persistência todo o tempo. Isso permite aos usuários variar a “preguiça” para se adaptar às exigências do aplicação.

Essa limitação é a razão pela qual as implementações de IMDB de alta disponibilidade geralmente pedem o uso de replicação. A taxa de transferência da rede ainda é geralmente mais rápida do que a do disco. Ela permite que várias instâncias de IMDB sincronizem os dados contidos no sistema. A configuração mais comum é ter um único banco de dados ativo, replicado com um banco de dados em modo de espera ou somente de leitura. A probabilidade de todos esses sistemas pararem de funcionar ao mesmo tempo é muito menor do que a probabilidade de uma única falha.

Por outro lado, algumas soluções de In-Memory Database utilizam uma tecnologia para a replicação não compartilhada. Isso significa que as informações desses bancos de dados são distribuídas por meio de um conjunto de nós de computação, para balanceamento de carga e alta disponibilidade. A tecnologia de não compartilhamento tem o benefício adicional de escalar a carga para vários nós de computação, e é um exemplo da escalabilidade horizontal no trabalho. Portanto, a tecnologia de computação In-Memory não compartilhada pode escalar horizontal e verticalmente.

MIGRAÇÃO DE APLICAÇÕES DO BANCO DE DADOS PARA O IMDBEm geral, a maioria dos aplicações de banco de dados pode se beneficiar da tecnologia IMDB, em grande parte porque muitos aplicações usam somente um subconjunto simples da Linguagem de consulta estruturada (SQL). No entanto, as soluções IMDB geralmente não têm o conjunto completo de funcionalidades disponíveis para sistemas de gerenciamento de banco de dados relacionais com base em disco (RDBMS). Por exemplo, alguns IMDBs não suportam acionadores de banco de dados e não teriam o mesmo nível de granularidade para restrições de campo. As limitações a restrições de campo (ou seja, os caracteres unicode, formatos numéricos) são muito importantes, pois os aplicações podem ser gravados para depender da aplicação de restrições de campo para banco de dados. Se a migração para o IMDB suaviza as restrições esperadas anteriormente, isso levanta uma série de questões relacionadas à validação do campo, como ataques do tipo injeção.

Algumas plataformas IMDB não oferecem o mesmo nível de gerenciamento de usuário e direitos, que é comum em bancos de dados relacionais baseados em disco. Em alguns casos, o acesso a uma instância de banco de dados permite o acesso a todos os dados contidos nessa instância. Nesses casos, os administradores são obrigados a criar instâncias separadas do banco de dados para aplicações distintos. Isso exige um paradigma de gerenciamento de usuário diferente.

Os usuários também devem considerar os recursos exigidos para suportar os IMDBs. O recurso principal exigido

é a memória. Em especial, bancos de dados muito grandes podem não se encaixar em quantidades comercialmente disponíveis de RAM. Atualmente o espaço em disco é geralmente medido em terabytes. A memória, por outro lado, é medida em dezenas de gigabytes. Algumas soluções IMDB (ex: solidDB) fazem a medição entre a memória e o disco; isso limita a quantidade de memória principal e o desempenho, que será afetado se o disco for atingido. Portanto, os sistemas de memória não compartilhada (ex: VoltDB/HANA) superam os que são compartilhados.

Por fim, é importante lembrar que um aplicação terá vários componentes e subsistemas diferentes. Otimizar somente o banco de dados produzirá ganhos de desempenho, mas esse pode não ser o único gargalo presente no sistema. É importante levar em consideração outros argumentos. Exemplos de gargalos relacionados ao banco de dados fora do IMDB incluem a conexão de agrupamentos e conversões de interface. Em alguns casos, o número de conexões de banco de dados ao agrupamento é limitado, causando um gargalo de transação. Outro problema comum é quando uma conexão entre uma interface e o banco de dados, como um bloqueio de transação síncrona ou processamento de transformação de dados pesados (ou seja, computações e conversões), cria um cenário onde as limitações de interface suprimem as transações e limitam o potencial de desempenho. Por fim, algumas transações não chegam a tempo ao banco de dados devido a problemas na fila de aplicações (ou seja, algumas transações volumosas não processadas em tempo real podem privar as transações em tempo real). Estes são exemplos de problemas de desempenho que envolvem mover os dados no banco de dados em oposição ao próprio desempenho do banco de dados. É importante não otimizar demais uma única área.

ESCOLHA DE UMA SOLUÇÃO IMDBA seguir estão os fatores principais que devem ser considerados ao escolher uma solução IMDB:• Conformidade com ACID/durabilidade de dados -

Atomicidade, consistência, isolamento e durabilidade (ACID) são propriedades de conformidade que pressupõem que as transações de banco de dados são executadas de forma confiável. Em especial, a durabilidade costuma variar em implementações de IMDB. A maioria das soluções de IMDB (ex: SAP HANA, Oracle TimesTen, VMware

• Obtenha mais informações e dê sua opinião sobre a gestão de riscos e big data no Centro de conhecimento.

www.isaca.org/knowledgecenter

Está gostando deste artigo?

4 ISACA JOURNAL VOLUME 5, 2013

Gemfire, MySQL Cluster, VoltDB, SQLite) está em conformidade com a ACID. No entanto, elas geralmente variam quando se trata de durabilidade no disco. A “preguiça” da gravação no cache e na memória principal determinará isto. Algumas soluções (ex: Oracle TimesTen) permitem que os desenvolvedores ajustem a “preguiça” da gravação no cache e na memória principal, enquanto outros (ex: SQLite) não suportam a gravação em disco.

• Volume de dados e requisitos de escala - Quão escalável o aplicação deve ser? Uma série de soluções IMDB suportam arquiteturas não compartilhadas, que permitem que os desenvolvedores criem facilmente aplicações que se escalam horizontalmente com a adição de nós de computação/armazenamento. Arquiteturas não compartilhadas (ou seja, VMware Gemfire, SAP HANA, VoltDB) permitem o escalamento arbitrário simplesmente com a adição de nós. O recurso mais importante é a capacidade de recuperação por não ter um único ponto de falha (ou seja, configuração espelhada N+1). Algumas arquiteturas (ex., Oracle TimesTen) suportam apenas escalabilidade agregada, quando a mesmo também é feita pela adição de nós com um subconjunto de dados em si bem particionado. No entanto, as arquiteturas que suportam o não compartilhamento podem ser projetadas para suportar requisitos de armazenamento de dados gerais horizontalmente escaláveis - arquiteturas que não exigem que os desenvolvedores projetem aplicações para o escalamento agregado.

• Compatibilidade com SQL/dialeto SQL - Nem todos os IMDBs são iguais em se tratando de suporte de SQL. Alguns oferecem um conjunto básico de SQL primitivos (ou seja, criar, selecionar, inserir, excluir, atualizar), enquanto outros oferecem um conjunto mais amplo (ex: restrições de chave externa, procedimentos armazenados). Pacotes mais simples como o SQLite costumam ter um suporte de SQL mais elementar, mas são mais fáceis de se implementar. Pacotes com suporte para SQL mais complexo permitem uma migração mais fácil para aplicações que já utilizam essas primitivas. Esta é a principal razão pela qual a tecnologia IMDB é atraente. A facilidade da portabilidade depende do tamanho do conjunto de SQL primitivos exigido pelo aplicação. Este é o principal motivo pelo qual as empresas com aplicações baseados em RDBMS preferem o IMDB ao NoSQL.15

• Compressão - A utilização da memória principal para processar transações coloca uma restrição no tamanho absoluto dos dados que podem ser processados em um determinado período ou nó. Isso pode ser contornado com a utilização da compressão às custas do tempo de processamento da CPU. Alguns bancos de dados (ex: Oracle TimesTen) suportam isto. No entanto, o motivo para usar os IMDBs é remover um gargalo de desempenho (E/S). Seria contraprodutivo substituí-lo por outra CPU. No entanto, é necessário um planejamento cuidadoso.

• Custo - Há uma série de soluções IMDB com plataforma aberta e comerciais. A escolha dependerá principalmente dos requisitos relacionados anteriormente. Se os candidatos restantes oferecerem uma opção de plataforma aberta e comercial, fatores como requisitos de suporte e manutenção devem ser considerados. As opções recomendadas são as comerciais e de plataforma aberta com soluções comerciais pagas. Soluções de plataforma aberta são viáveis quando o suporte comercial não é necessário e o pacote tem uma comunidade de desenvolvedores robusta.

CONCLUSÃOA tecnologia IMDB não é nova. Ela vem sendo usada em casos de uso especializados de taxa de transferência (ex: telecomunicações) ou requisitos de armazenamento em cache (ex: proxies de rede e de autenticação) há algum tempo. Atualmente, a tendência do big data está obrigando as empresas a minerar seu grande tesouro interno de dados. A percepção adicional oferecida pela mineração dessas informações pode ser inestimável para criar uma melhor experiência do usuário. Os casos de uso, que exigem tempos de resposta de processamento rápido, podem ser beneficiados pela tecnologia de memória. Felizmente, o setor também adotou ofertas que facilitam a consideração da tecnologia de memória, como a introdução de interfaces SQL, replicação de nada compartilhado e gravação no cache e na memória principal para obter durabilidade.

Em termos de custo, a tecnologia IMDB exige uma quantidade considerável de memória, visto que todos os dados devem caber nela. As velocidades de memória são de 100.000 a um milhão de vezes mais rápidas do que os discos rígidos mecânicos em termos de tempos de acesso. O custo da memória é cerca de 100 vezes maior do que os discos rígidos mecânicos. A certeza (1.000 a 10.000 vezes) é um ganho de desempenho considerável ao mudar para soluções

ARQUITETURA ALTERNATIVA DE IN-MEMORY DATABASE

Uma alternativa para utilizar um sistema de computação In-Memory exclusivo, como o IMDB, seria usar um RDBMS comum em uma plataforma de computação que faz uso exclusivo de dispositivos de armazenamento baseado In-Memory, como os drives de estado sólido (SSD). Certamente, a arquitetura de computação moderna ainda trata os discos SSD como dispositivos de E/S, mesmo se tiverem memória interna. Assim, a implementação somente de RAM ainda traz algum benefício. No entanto, conforme a tecnologia é aprimorada, pode haver soluções em que os tempos de acesso de armazenamento flash se tornam comparáveis aos tempos de acesso à RAM.

5ISACA JOURNAL VOLUME 5, 2013

baseadas In-Memory. O possível desafio é obter módulos de memória suficientes em uma máquina, visto que a maioria dos hardwares de computação aceita apenas uma quantidade limitada de RAM (ex: dmidecode -t 16).16 Outra opção é utilizar a tecnologia de disco de estado sólido (SSD) com a tecnologia comum de RDBMs (consulte a barra lateral Arquitetura alternativa de In-Memory Database).

Os IMDBs fornecem um caminho fácil para colher os benefícios da computação In-Memory. A utilização de uma interface SQL tem proporcionado uma opção rápida para a maioria das empresas migrar suas aplicações existentes. A gravação no cache e na memória principal e a replicação podem abordar preocupações com relação ao balanceamento de carga e alta disponibilidade. O pensamento óbvio de que “a memória é mais rápida que o disco” permite a justificativa dessa iniciativa. No entanto, deve-se tomar cuidado para garantir que os aplicações realmente tenham benefício com o uso da tecnologia In-Memory. Os desenvolvedores de sistemas devem se fazer algumas perguntas básicas para determinar se a solução é adequada (Consulte a barra lateral Perguntas que devem ser feitas ao considerar um IMDB). Assim que a decisão para usar a computação In-Memory for tomada, um trabalho adicional deve ser realizado para garantir que as considerações foram ponderadas. Em especial, as áreas de recursos exigidos, funcionalidades e requisitos de segurança (confidencialidade, integridade e disponibilidade) devem ser analisadas. Mais importante, as empresas devem fazer um esforço para experimentar a tecnologia em primeiro lugar.

Na medida em que mais pessoas interagem na web, os fornecedores de serviços e aplicações têm mais dados e ferramentas em suas mãos - uma delas é a tecnologia IMDB - para conhecer melhor os clientes. A proliferação de várias soluções - comerciais e gratuitas - coloca os aplicações de dados tradicionais de alto desempenho ao alcance de todos.

NOTAS FINAIS 1 PC Magazine, “Definition of In-Memory Database,” 2013,

www.pcmag.com/encyclopedia/term/44861/in-memory-database

2 Kumar, V.; A. Grama; A. Gupta; G. Karypis; Introduction to Parallel Computing, vol. 110, Benjamin/Cummings, 1994

3 Hess, K.; “Uncover Your 10 Most Painful Performance Bottlenecks,” 2010 www.serverwatch.com/trends/ article.php/3912821/

4 Jacobs, A.; “The Pathologies of Big Data,” Communications of the ACM, 52(8), 36-44, 2009

5 Godard, Sebastien; “iostat,” Man Page, http://linux.die.net/man/1/iostat/

6 Microsoft Corporation, Perfmon, http://technet.microsoft.com/en-us/library/bb490957.aspx

7 Oracle Corp., “Oracle TimesTen In-Memory Database,” www.oracle.com/technetwork/products/timesten/overview/index.html

8 SAP, “What Is SAP HANA?,” www.saphana.com/docs/DOC-2272

9 IBM Corp., “IBM solidDB-Fastest Data Delivery,” www-01.ibm.com/software/data/soliddb/

10 VMware, VMware vFabric Gemfire, https://www.vmware.com/products/application-platform/vfabric-gemfire/overview.html

11 Oracle Corp., MySQL Cluster FAQ, www.mysql.com/products/cluster/faq.html

12 SQLite, SQLite In-Memory Database, www.sqlite.org/inmemorydb.html

13 VoltDB, http://voltdb.com/ 14 Sethi, Jaypal; “Druid: 15 Minutes to Live Druid,”

Metamarkets, http://metamarkets.com/category/technology/druid/

15 Janssen, Cory; “Definition—What Does NoSql Mean?,” Technopedia, www.techopedia.com/definition/27689/nosql-database

16 Nixcraft, Maximum Memory and CPU Limitations for Linux, www.cyberciti.biz/tips/maximum-memory-and-cpu-limitations-for-linux-server.html

PERGUNTAS QUE DEVEM SER FEITAS AO CONSIDERAR UM IMDB

• O aplicação terá benefício com a tecnologia da computação In-Memory? É essencialmente E/S?

• Os dados podem se adaptar a quantidades de RAM comercialmente disponíveis?

• O aplicação exige uma interface SQL? O IMDB a oferece?• A escolha de IMDB suporta o subconjunto de SQL que o

aplicação exige?• Há suposições de segurança que mudam por causa dos

limites de funcionalidade?• A persistência e durabilidade são necessárias? O IMDB

suporta a persistência baseada em disco? • Existe a chance de perder dados quando os mesmos são

dependentes apenas da persistência baseada em disco? Isso está cERtO?

• O balanceamento de carga é necessário? O IMDB suporta a replicação não compartilhada? Ele pode suportar isto para balanceamento de carga e alta disponibilidade?