PAPER - Modelo de Processo para Criação de BI em Banco de Dados
PAPER - Modelo de Processo para Criação de BI em Banco de Dados
PAPER - Modelo de Processo para Criação de BI em Banco de Dados
1. INTRODUO
Atualmente, as organizaes utilizam como parte essencial o Business Intelligence (BI) para adquirir
vantagens competitivas e possuir pleno conhecimento das informaes referentes ao total ecossistema da
organizao, utilizando as informaes internas quanto dados externos. Com a disponibilizao
exponencial dos dados, os Data Warehouses (DWs) vem tornando-se base de dados imensas. Esta
demanda traz srios problemas para uma plataforma baseada em banco de dados relacionais padres, pois
por natureza o modelo relacional de dados e as arquiteturas desse tipo de Sistemas Gerenciadores de
Banco de Dados (SGBDs) no foram desenvolvidos para DWs destas grandezas.
Os SGBDs tradicionais possuem problemas de escalabilidade, principalmente em nvel horizontal.
Para atender demandas cada vez maiores, vrios fornecedores disponibilizam appliances que so as
arquiteturas robustas que incluem hardware e software personalizados. Entretanto, estas estruturas
customizadas possuem custos elevados de implantao, manuteno e atualizao, no sendo acessvel
para maioria das organizaes, alm de possurem recursos e escalabilidade finita e limitada a um
parmetro determinado de tamanho da base de dados. Em contrapartida, uma alternativa que pode ser
utilizada em ambientes de software e hardware heterogneos so os bancos de dados NoSQL, pois sua
estrutura e arquitetura foram desenvolvidas para trabalharem com base de dados grandes, proverem alta
disponibilidade e escalabilidade horizontal irrestrita.
Diante dos contextos apresentados, o presente artigo apresenta a discusso da arquitetura de BI, os
SGBDs NoSQL, alm de sugerir um modelo de implementao de sistema de BI em SGBD, baseados em
famlia de colunas. Na seo 2 descreve-se a arquitetura tradicional de BI. A Seo 3 introduz o conceito
de NoSQL e bancos de dados em famlia de colunas, exemplificado pelo banco de dados Apache
Cassandra. A seo 4 apresenta a metodologia, a arquitetura de BI com a utilizao de banco de dados
NoSQL colunar. Na seo 5 apresentado um estudo de caso onde aplicado o modelo proposto. Por fim,
a seo 6 traz as consideraes finais e perspectivas sobre a arquitetura de BI sobre banco de dados
NoSQL.
[1] So tambm processos do universo deBI,os DataMiner (minerao de dados) e o Analytics/Data Discovery (anlises e descobrimento
de dados) que no sero abordados neste artigo.
Segundo Kimball e Ross (2013) e Inmon (2005), as principais estruturas e processos para a criao de um
modelo tradicional de aplicaes BI1 so ordenadas a partir de 6(seis) pontos, que so apresentados em
resumo na figura 1.
Figura 1 - Modelo tradicional de construo de aplicaes BI
Os principais pontos definidos por Kimball e Ross (2013) e Inmon (2005), so:
Data Source (DSs): Refere-se s fontes de dados, que podem envolver arquivos sequenciais, banco de
dados estruturados relacionais de diversas naturezas, sistemas transacionais e quaisquer outras fontes de
dados que possam ser processadas e incrementadas aos DWs/Data Mart.
Extract, Transformation and Load System (ETL): Processo que envolve extrair os dados dos DSs.
Aplicar um processo transformao que envolve limpeza, adequao e agregao dos dados, para que
estes possam ser convergidos em uma forma universal e por fim a carga destes dados nos seus devidos
DWs.
Stanging Area\Operational Data Store (ODS): uma rea temporria onde so armazenados os
dados antes da transformao. A rea intermediria (stagin area) geralmente utilizada para carga dos
dados brutos dos DSs para trabalhos posteriores de transformao, sendo acessadas por desenvolvedores e
responsveis de ETL. J a ODS utilizada como rea de integrao de dados pelos usurios e/ou sistemas
transacionais.
Data Warehouse (DW): O armazm central de dados, onde so disponibilizados de forma corporativa.
So bases de dados histricas no volteis, ou seja, possuem dados gravados fisicamente que no sofrem
alteraes e representam diferentes instantes de tempo sobre a informao. So bases de dados que sofrem
processamento massivo de escrita no sendo utilizado para processamento de visualizao de dados. O
DW de forma clssica persistido em bases de dados relacionais, orientada a linhas.
Data Mart (DM): Pequenos armazns de dados com recortes especficos para atendimento das
aplicaes e reas de negcio, com uma ensima parte da totalidade de dados armazenados nos DWs. Por
definio a camada de DM que sofre o processamento das ferramentas de visualizao de dados.
Ferramentas para Visualizao de Dados: Responsveis pela visualizao dos dados contidos nos
DMs. Entre as principais ferramentas destacam-se: On-line Analytical Processing (OLAP) que apresenta
os dados de forma multidimensional. Adicionalmente, ferramentas de relatrios e a Dash Bord (painis de
controle) que apresenta as informaes em forma de grficos, indicadores e tabelas.
Em Kimball e Ross (2013) e Inmon (2005), observa-se que orientam a utilizao da modelagem de
dados de forma desnormalizada em Star Schema (esquema estrela ou modelo estrela) para as bases de
dados dos DWs e os DMs. Os dados que possuem mtricas que podem ser mensurados e/ou calculados so
armazenados em Tabelas Fato. Estas so relacionadas com tabelas que possuem as dimenses, contendo as
informaes para segmentao e anlise de dados, chamadas de Tabelas Dimenso.
(em ingls APIs) para consulta ou linguagem prpria como o Cassandra Query Language2 (CQL)ou
MongoQuery3.
Escalabilidade horizontal: Capacidade de processamento em diversos ns de um cluster ou diversos
clusters. Permitem que a carga de processamento seja dividida em diversos agentes, aumentando
significativamente a capacidade de processamento do SGBD. Possui a possibilidade de incluir no mesmo
cluster, hardwares heterogneos de arquiteturas e configuraes distintas.
Schemaless ou Free Schema: Trabalham com esquemas de dados flexveis ou totalmente sem
esquemas, favorecendo o trabalho com diversos tipos de dados e aplicaes de alta mutabilidade de
formatos.
Sharding e Replicao: Replicao de dados em vrios ns do SGBD e compartilhamento (sharding)
de dados. Estas caractersticas favorecem o processamento paralelo e em geral alta disponibilidade do
sistema.
Consistncia Eventual: Trabalham com o paradigma otimista de consistncia de dados, onde
inconsistncias eventuais e temporrias devem ser aceitas e previstas para priorizar a alta disponibilidade
do sistema. Esta consistncia efetuada em um momento posterior a transao, como descrito em Gilbert
e Lynch (2002) no modelo Basically Avaliable, Soft State, Eventual Consistency (BASE).
Segundo Lcio et al.(2011), os SGBDs NoSQL so altamente relevantes para aplicaes que
necessitam de uma tecnologia que oferea suporte ao gerenciamento e escalabilidade de grandes volumes
de dados, de maneira simples e eficiente. Por exemplo, as aplicaes web que podem produzir volumes
de dados imensos. Por estes motivos, empresas focadas em aplicaes web como o Google, Facebook,
Twitter, Amazon, LinkedIn desenvolvem e/ou adotam tecnologias de SGBD NoSQL.
Moniruzzaman e Hossain (2013) classificam os atuais SGBDs NoSQL em quatro tipos bsicos de
arquiteturas:
Chave-Valor: So normalmente orientados a uma chave alfanumrica e valores associados, sendo
esses valores simples como texto ou complexos como: listas, tabelas, imagens entre outros.
Orientados a Documentos: So bases de dados construdas para armazenar documentos. Esses
documentos so representados internamente de uma forma padro de troca de documentos como XML e
Javascript Option Notation (JSON).
Famlia de Colunas: Assim como o modelo chave-valor, ele representa mltiplos atributos para cada
chave, com a diferena que os atributos so representados por tabelas. Gravando cada coluna da tabela
separadamente, armazenando de forma contnua cada atributo referente chave.
Orientado a Grafos: So bases de dados desenvolvidas sobre os conceitos da teoria dos grafos, onde
as tabelas so representados como uma rede orientada a objetos de ns (objetos conceituais), relaes
entre ns (arestas) e propriedades (atributos de objetos de dados chave-valor). Geralmente, so utilizadas
em aplicaes em que existe alta complexidade de relacionamentos, como redes sociais e sistemas de
recomendaes.
[2] http://docs.datastax.com/en/cql/3.1/cql/cql_intro_c.html
[3] http://docs.mongodb.org/manual/tutorial/query-documents/
dados, j que o sistema de armazenamento de dados em colunas tende a inserir de forma sequencial
informaes semelhantes. Os mtodos de compactao so fundamentais para melhora significativa no
desempenho do banco de dados, Soares e Boscarioli (2013). Yaskevich (2011) relata que a compactao
pode ser responsvel por um desempenho em leitura de 25% a 35%e em escrita em 5% a 10% maior, alm
de uma reduo em armazenamento fsico na ordem de 2 a 4 vezes de acordo com o mtodo de
compactao empregado.
Diante dos pontos mencionados, ressalta-se que bases de dados orientadas a colunas so ideais para
construo de DWs. Em Carniel et al. (2012) visto que o DW uma base de dados volumosa, histrica,
orientada ao assunto e no voltil. SGBDs NoSQL orientados as colunas so indicados para aplicaes
que precisam de alto desempenho em uma operao especfica, como o processamento de consultas em
dados no volteis. Ainda neste sentido, Soares e Boscarioli (2013) trazem a ateno ao fato que, banco
de dados colunares so otimizados para operaes de leitura (read-optimized), tornando-se uma boa
alternativa s aplicaes que possuem grande densidade de dados e que so frequentemente requeridos
para leitura como o caso dos DWs.
Data Source: Fontes de Dados quaisquer, tanto estruturadas como base de dados relacionais e arquivos
sequenciais. Acrescenta-se neste modelo fontes de dados no estruturadas como arquivos de logs e dados
de redes sociais.
Extration, Load e Transformation (ELT): Diferentemente do ETL tradicional em que os dados so
transformados em tempo de extrao, nesse modelo a preocupao com a extrao das fontes de dados e
carregamento na mesma estrutura original na base de dados NoSQL. Desta forma, nenhum dado perdido
ou agrupado. Como o SGBD NoSQL suporta quantidade de dados ilimitada com baixo custo, a principal
preocupao o armazenamento inicial da informao, sem necessidade de tcnicas de reduo na
quantidade de dados carregados. Posteriormente, a informao pode ser minerada e transformada para uma
camada de apresentao. Ferramentas tradicionais de ETL como o Talend e Pentaho Data Integration que
possuem conectores para NoSQL podem ser utilizadas. Outras ferramentas podem ser adicionadas, como o
Apache Kafka que facilita a extrao de diversas fontes no relacionais e o Apache Flume que possibilita a
extrao de dados de fontes relacionais. Estas duas ltimas ferramentas podem ser diretamente ligadas
aplicao da camada de processamento em memria em streaming. Outra abordagem possvel
desenvolver programas em linguagens que possuem APIs para Apache Spark e Apache Cassandra como o
Java e o Python.
Processamento em Memria: adicionada uma camada para o processamento dos dados em
memria. Esta camada responsvel pelo processamento tanto no ato do carregamento dos dados, quanto
no momento de transformao e exibio. Esta camada tambm facilita a minerao, descoberta e juno
de dados, j que banco de dados NoSQL no tem a capacidade de juno de tabelas. A camada de
processamento em memria proporciona esta capacidade, de forma rpida. Seu processamento
inteiramente em memria, com menor custo de I/O fsico. Outras possibilidades tambm so adicionadas
como o processamento em streaming tornando possvel a criao de plataformas de BI para produo de
informaes em tempo real. Esta abordagem, depende naturalmente de grandes quantidades de memria
disponvel em seus ns. Neste modelo o Apache Spark foi adotado como aplicao para atender esta
camada.
Data Warehouse: Neste modelo o DW pode ser representado como camada lgica ou fsica que
compartilha o mesmo SGBD que a rea de carregamento. Neste trabalho sugeriu-se a criao de esquemas
fsicos de tabelas, contendo as informaes acessadas pelas ferramentas de visualizao de dados, para
otimizar o tempo de processamento e facilitar o mapeamento dos metadados. O DW pode tambm ter
acrescentada uma camada lgica dentro da rea de processamento em memria, ou seja, meta-esquemas
lgicos que mapeiam a forma de apresentao das informaes obtidas diretamente das reas de
carregamento do SGBD. Estes meta-esquemas so chamados de sandbox (caixa de areia) onde a
representao dos dados lgica, criada em tempo de execuo e desconstruda depois de sua utilizao.
Essas duas abordagens podem tambm serem adotadas simultaneamente de acordo com as necessidades da
aplicao.
Ferramentas de Visualizao de Dados: So aplicadas sobre a camada de processamento em
memria. Desta forma, a camada de processamento em memria, que tambm clusterizada, proporciona
velocidade adicional camada de visualizao de dados. Ferramentas comuns de mercado como Tableau,
Microstrategy, Qlikview e at Microsof Excel podem ser utilizadas para a visualizao de dados, j que a
camada de processamento em memria como Apache Spark disponibiliza conectores padres de mercado
como ODBC e JDBC. Outras ferramentas como o Jaspersoft Server possuem conectores nativos para
Spark. As consultas de dados assim, podem ser realizadas diretamente com linguagem SQL que so
traduzidas de forma transparente para a linguagem do SGBD NoSQL.
No modelo apresentado so suprimidos as staging areas e as ODS, j que no necessrio uma rea de
carregamento dados temporria, e a rea de processamento operacional pode ser representada diretamente
no SGBD em tabelas ODS ou em uma representao lgica na memria em sandbox. Os DMs tambm so
suprimidos, pois no necessrio separao fsica dos dados para cada rea de negcio, e o processamento
das consultas e das visualizaes de dados podem ser executadas diretamente no DW, pois o SGBD
NoSQL distribudo e clusterizado suporta com eficincia toda carga de processamento. Os DMs podem ser
representados por esquemas fsicos de tabelas diretamente no DW ou em sandbox na rea de
processamento em memria.
A modelagem em star schema apresentada anteriormente, tambm modificada. Os conceitos de fato
e dimenses juntamente com conceitos mais profundos como de granularidade deve ser considerados para
a criao da modelagem de dados, porm no so representados fisicamente no DW. Os dados de fato e de
dimenso devem ser representados em uma nica tabela desnormalizada, que neste trabalho denominou-se
como Tabela Estrela. A volumetria dos dados pode ser ampliada de acordo com a granularidade dos
dados, porm este fator deve ser desconsiderado j que na abordagem NoSQL o custo de armazenagem
infimamente menor que o custo de processamento, ou seja, a velocidade de processamento de ordem de
importncia muito maior e com menor custo do que a volumetria dos dados.
5. METODOLOGIA E RESULTADOS
Com o modelo de estrutura de dados baseado em colunas desenvolvido foi possvel realizar os seguintes
procedimentos: integrao do SGBD, camada de processamento em memria, conectores e camadas de
apresentao. A seguir apresenta-se os materiais e os detalhes do desenvolvimento dos procedimentos:
Para utilizao de uma arquitetura standalone clusterizada, utilizou-se trs servidores em nuvem do
provedor DigitalOcean. Cada servidor apresenta 4GB de memria, 60GB de armazenamento SSD e com
2(dois) ncleos de processamento.
O sistema operacional utilizado foi o Linux Ubuntu Server 15.04x64bits.
O SGBD utilizado foi o Apache Cassandra verso 2.2.1 para persistncia dos dados.
Para camada de processamento em memria foi utilizado o Apache Spark 1.5.
O Python 2.7 foi utilizado como ferramenta para ELT e tratamento dos dados.
Na camada de visualizao de dados foi utilizado o sistema JasperReports Server Community
Edition verso 6.01.
Adicionalmente, como prrequisito para instalao e configurao deste modelo so necessrio os
seguintes softwares: Oracle Java 7, Scala 2.10, SBT 0.13, Git2. 1..
Cabe salientar que se necessitou de conectores, tais como: spark-cassandra-connector 1.5, pysparkcassandra 0.1.1 para conexo entre o Cassandra, Spark e Python alm do Simba Spark ODBC 64bits
para conexo do Apache Spark com JasperReports Server.
Para realizao da validao do modelo utilizou-se uma base de dados disponibilizada em BACEN
(2015). Os dados foram obtidos no formato CSV.
A implementao desenvolvida foi em escala experimental, apenas para demonstrao que a
arquitetura terica proposta possvel de construo de forma prtica.
5.1. Resultados
Todos os itens da arquitetura se integraram conforme o proposto. Dentro da implementao do prottipo
houveram dificuldades em relao quantidade de memria necessria para o processamento dos dados.
Na documentao oficial do Apache Cassandra (DataStax, 2015) e Apache Spark (Spark, 2015)
informado que para desempenho real em produo requisito mnimo pelo menos 8GB de memria para
cada aplicao em cada n. Como cada n possua uma aplicao do Apache Cassandra juntamente com
um Apache Spark, desta forma cada n necessitaria pelo menos 16GB. Sendo assim no se considerou
neste trabalho os tempos de consulta, insero e atualizao de dados nas aplicaes, j que este resultados
esto diretamente relacionados ao tamanho da base, quantidade de ns implementados alm da arquitetura
de hardware.
O hardware utilizado para construo do prottipo desta pesquisa possui especificao menor do que a
sugerida na documentao oficial das aplicaes, entretanto, mesmo com hardware de baixo custo e com
especificaes menores, foi possvel a implementao do modelo. interessante notar tambm que o
prottipo foi totalmente implementado em computao em nuvem. Todos os softwares foram instalados e
configurados em apenas uma mquina virtual. Em seguida, o estado fsico dos softwares desta mquina
virtual foi salvo atravs de um snapshot e replicados aos demais ns. Sendo assim para funcionamento da
aplicao nos demais ns aps replicao do snaptshot, era necessrio apenas a alterao da informao de
IP em um arquivo de configurao respectivamente para Apache Cassandra e outro para o Apache Spark.
Foi criado um shell-script que alterava essas informaes de IP nos arquivos de configurao na
inicializao de cada n, desta forma, aps a replicao, cada n entrava em funcionamento no cluster
automaticamente.
No presente caso de uso a ELT foi efetuada com scripts em Python informando comandos de insert
diretamente no SGBD Cassandra. Foram inseridas duas tabelas distintas, uma contendo as informaes de
carteiras de crdito e outra contendo informaes do tipo dimenso a respeito das instituies bancrias.
Posteriormente, essas tabelas foram transferidas para Data Frames no Spark, ou seja, rplicas das tabelas
completas em formato sandbox em memria. Sobre esses Data Frames foi criada uma juno gerando
uma terceira tabela, a tabela estrela. A juno foi efetuada com SQL-ANSI com conexo via Python.
Esta tabela com a viso final foi posteriormente persistida no SGBD Cassandra.
A camada de visualizao de dados conectou a aplicao Spark atravs de ODBC que necessitou
instalao e configurao prvia. A tabela utilizada pela camada de aplicao foi o Data Frame em
memria, desta forma todas as consultas foram realizadas diretamente com os dados em memria. Assim,
foram implementados a sugesto da arquitetura proposta de criao de in-memory sandbox. importante
ressaltar que para atualizao dos dados em memria necessrio um processo de submisso dos dados
persistidos no SGDB para a aplicao em memria. Assim em produo esse processo precisa ser repetido
periodicamente.
As consultas realizadas na aplicao de visualizao foram feitas atravs de comandos SQL-ANSI. Foi
desenvolvido um relatrio em forma de listagem e um dashboard contendo dois grficos. Os filtros foram
feitos diretamente no JasperReport Server e atingiram a meta esperada.
Assim todas as funcionalidades bsicas de um BI foram implementadas e testadas sobre o modelo
terico proposto.
6. CONSIDERAES FINAIS
As aplicaes de BI vm sendo desenvolvida h diversos anos sobre o modelo sugerido por Kimball e
Inmon, que implicitamente associado com base de dados relacionais, entretanto a arquitetura relacional
de dados possuem limitaes em escalabilidade. Como pode-se verificar, a abordagem NoSQL foi
desenvolvida justamente para lidar com os desafios de base de dados grandes e com escalabilidade
horizontal. Destaca-se como soluo de SGBD NoSQL para construo de DW as arquiteturas voltadas
famlia de colunas. Desta forma hoje a criao de aplicaes de BI em base de dados NoSQL colunares
uma realidade e esta abordagem pode trazer diversas vantagens sobre o modelo relacional.
Yaskevich (2011) relata que a compactao pode ser responsvel por um desempenho em leitura de
25% a 35% e em escrita em 5% a 10% maior, alm de uma reduo em armazenamento fsico na ordem de
2 a 4 vezes de acordo com o mtodo de compactao empregado. Assim umas das principais vantagens de
bancos de dados de modelo colunar em relao aos de modelo relacional esto vinculadas compresso,
materializao e bloco de iterao, como pode ser visto em Soares e Boscarioli (2013) e em Abadi
(2008).
Em aplicaes de banco de dados no modelo colunar no existe problema de escalabilidade da
aplicao. Como visto em Cockcroft e Sheahan (2011), podem ser implementados clusters com centenas
de ns atendendo a mesma aplicao. No prottipo desenvolvido neste trabalho a criao de novos ns se
deu de forma praticamente instantnea, assim diferentemente da arquitetura de BI clssica que necessita de
grandes projetos de implementao e substituio de hardware e software para crescimento de capacidade,
como no caso dos appliances oferecidos por grandes fornecedores de aplicaes de BI, na arquitetura
proposta so necessrios apenas acrscimos de mais ns de processamento.
Existe tambm a possibilidade de diminuio de custos na implementao de uma aplicao em BI.
Lakashman e Malik (2009) mostram que uma arquitetura NoSQL como o Cassandra pode ser
implementada sem a necessidade de um hardware especifico de alto custo, antes, um dos predicados para a
criao do Cassandra se deu que ele fosse capaz de trabalhar em hadwares heterogneos de baixo custo, o
que implica a diminuio no custo com hadware. Outro fator que pode contribuir para reduo de custos
o fato todos os softwares utilizados na arquitetura proposta serem open-source, desta forma custos com
licenciamento podem ser diminudos drasticamente.
Outro fator importante considera foi que em determinados projetos de BI podem ser considerados uma
grande vantagem no modelo o fato dos SGBD NoSQL possurem esquemas de dados totalmente
flexveis. Desta forma a complexidade dos modelos de dados pode ser reduzida, diminuindo tambm a
quantidade de trabalho necessrio para criao da aplicao do BI. O fato de podermos trabalhar com uma
abordagem ELT em contrapartida do clssico ETL pode tambm se enquadrar nesta mesma caracterstica.
importante lembrar que esta vantagem vem em detrimento do controle dos metadados. Desta forma para
que esses fatores sejam realmente uma vantagem necessrio um trabalho intenso sobre a criao e
manuteno dos metadados da aplicao de BI.
Como grande vantagem no modelo apresentado possibilidade de trabalhar com grandes volumes de
dados com total integrao com aplicaes de Big Data. As ferramentas apresentadas foram desenvolvidas
no ambiente de Big Data, desta forma possuem integraes nativas com ferramentas como Apache
Hadoop, que largamente utilizada para ambientes de Big Data. Alm disto, o Apache Spark, utilizado
com camada de processamento em memria, uma aplicao que traz todas as possibilidades para criao
de uma ambiente de Data Science e Analytics (Spark 2015), podendo assim ser facilmente implementado
uma camada adicional estatstica e preditiva ao BI descritivo apresentado.
Assim, este trabalho contribuiu para identificar um modelo vivel para construo de uma aplicao
robusta de BI. Foram analisados diversas arquitetura de SGBD NoSQL bem como outras ferramentas para
construo desta arquitetura de BI. Como resultado foi apresentado implementao do modelo proposto
e verificado que este atende as funcionalidades padres de uma aplicao de Business Inteligence.
7. REFERNCIAS
Abadi, D. J., Boncz, P. A., Harizopoulos, S. Column-Oriented Database Systems. Proceedings of the VLB
Endowment 2009, v. 2, n. 2, p.1664-1665, 2009.
Abadi, D. J., Myers, D. S., Dewitt, D. J., Madden, S. R., Materialization Strategies in a Column-Oriented DBMS. In:
IEEE 23rd InternationalConferenceon Data Engineering, 2007. , p. 466-475. 2007.
Bacen, B. C. B., 50 maiores bancos e o consolidado do Sistema Financeiro Nacional. 2015. Disponvel
em:http://www4.bcb.gov.br/fis/TOP50/port/Top50P.asp
Carniel, A. C, S, A. A.; Brisighello, V. H. P.; Ribeiro, M. X.; Bueno, R.; Ciferri,R. R.; Ciferri, C. D. A. Query
Processing over Data Warehouse using Relational Databases and NoSQL. XXXVIII Conferencia Latinoamericana
Em Informatica (CLEI 2012) p. 1-9, 2012.
DataStax,
CQL
for
Cassandra
2.x
Documentation.
2015
Disponvel
em
http://docs.datastax.com/en/cql/3.1/pdf/cql31.pdf. Acessado em 11/04/2014.
Cockcroft, A., Sheahan, D., Benchmarking Cassandra Scalability on AWS - Over a million writes per second. 2011.
Disponvel em: http://techblog.netflix.com/2011/11/benchmarking-cassandra-scalability-on.html Acessado em:
11/04/2015.
Inmon, W. H. Building the Data Warehouse, 4 Edition. Wiley Publishing, Inc., 2005.
Gilbert, S.,Lynch, N., Brewers Conjecture and the Feasibility of Consistent, Avaliable, Partition-Tolerant WebServices. ACM SIGACT News, New York, NY,USA, v.33, n. 2, p.51,59, Junho, 2002.
J. Han; Haihong, E.; G. Le; J. Du; "Survey on NoSQL database," Pervasive Computing and Applications (ICPCA
2011), 6th International Conference on, pp.363-366, 2011.
Kimball, R., Ross, M., The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling, Third Edition.
John Wiley & Sons, Inc., 2013.
Lakashman, A., Prashant, M., Cassandra A Decentralized Structured Storage System. 2009. Disponvel em:
https://www.cs.cornell.edu/projects/ladis2009/papers/lakshman-ladis2009.pdf Acessado em: 11/04/2015.
Lcio, B. F., Oliveira H. R., Pontes, J. C. S.,NoSQL no desenvolvimento de aplicaes Web Colaborativas. VIII
Simpsio Brasileiro de Sistemas Colaborativos(SBSC 2011), 2011.
Moniruzzaman , A. B. M., Hossain, S. A. NoSQL Database: New Era of atabases for Big data Analytics Classification, Characteristics and Comparison. International Journal of Database Theoryand Application Vol. 6,
No. 4., 2013.
Soares, B. E.,Boscarioli; C. Modelo de Banco de Dados Colunar: Caractersticas, Aplicaes e Exemplos de Sistemas.
IX Escola Regional de Banco de Dados (ERBD 2013), 2013.
Spark, A., Apache Spark Documentation. 2015. Disponvel em: https://spark.apache.org/documentation.html.
Acessado em: 11/04/2015.
Yaskevich, P. Whats new in Cassandra 1.0: Compression.Disponvel em http://www.datastax.com/dev/blog/whatsnew-in-cassandra-1-0-compression. Acessado em 11/04/2015, 2011.