Apresentação

Apresentação
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
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 ESCALAR
Há 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 RAM
Há 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
ISACA JOURNAL VOLUME 5, 2013
1
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. P
roblemas 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
2
ISACA JOURNAL VOLUME 5, 2013
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 InMemory 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
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 IMDB
Em 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
Está gostando deste artigo?
•O
btenha 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
é 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 IMDB
A 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
ISACA JOURNAL VOLUME 5, 2013
3
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.
4
ISACA JOURNAL VOLUME 5, 2013
• 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ão
A 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 InMemory, 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.
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.
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?
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
1PC Magazine, “Definition of In-Memory Database,” 2013,
www.pcmag.com/encyclopedia/term/44861/in-memorydatabase
2Kumar, V.; A. Grama; A. Gupta; G. Karypis; Introduction
to Parallel Computing, vol. 110, Benjamin/Cummings,
1994
3Hess, K.; “Uncover Your 10 Most Painful Performance
Bottlenecks,” 2010 www.serverwatch.com/trends/
article.php/3912821/
4Jacobs, A.; “The Pathologies of Big Data,”
Communications of the ACM, 52(8), 36-44, 2009
5Godard, Sebastien; “iostat,” Man Page,
http://linux.die.net/man/1/iostat/
6
Microsoft Corporation, Perfmon, http://technet.microsoft.
com/en-us/library/bb490957.aspx
7Oracle Corp., “Oracle TimesTen In-Memory Database,”
www.oracle.com/technetwork/products/timesten/
overview/index.html
8SAP, “What Is SAP HANA?,” www.saphana.com/docs/
DOC-2272
9IBM Corp., “IBM solidDB-Fastest Data Delivery,”
www-01.ibm.com/software/data/soliddb/
10VMware, VMware vFabric Gemfire,
https://www.vmware.com/products/application-platform/
vfabric-gemfire/overview.html
11Oracle Corp., MySQL Cluster FAQ, www.mysql.com/
products/cluster/faq.html
12SQLite, SQLite In-Memory Database, www.sqlite.org/
inmemorydb.html
13
VoltDB, http://voltdb.com/
14Sethi, Jaypal; “Druid: 15 Minutes to Live Druid,”
Metamarkets, http://metamarkets.com/category/
technology/druid/
15Janssen, Cory; “Definition—What Does NoSql Mean?,”
Technopedia, www.techopedia.com/definition/27689/
nosql-database
16Nixcraft, Maximum Memory and CPU Limitations for
Linux, www.cyberciti.biz/tips/maximum-memory-andcpu-limitations-for-linux-server.html
ISACA JOURNAL VOLUME 5, 2013
5