Advertisement
Guest User

Untitled

a guest
Nov 29th, 2015
134
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
Latex 14.84 KB | None | 0 0
  1. \documentclass[12pt]{article}
  2.  
  3. \usepackage{sbc-template}  
  4.  
  5. \usepackage{graphicx}
  6.  
  7. \usepackage[brazil]{babel}    
  8. \usepackage[utf8]{inputenc}  
  9. \usepackage[square,authoryear]{natbib}
  10.    
  11. \sloppy
  12.  
  13. \title {Análise de desempenho dos bancos de dados NoSQL Monetdb e SciDB}
  14.  
  15. \author{Arthur Nascimento, Iuri Bloch, Thaís Ribeiro}
  16.  
  17. \address{Centro Federal de Educação Tecnológica Celso Suckow da Fonseca - CEFET/RJ
  18. \email{arthur\_vn@hotmail.com, iurivalladaresbloch@gmail.com, thaisribeiro-@hotmail.com}}
  19.  
  20.  
  21. \begin{document}
  22.    
  23.     \maketitle
  24.    
  25.     \begin{abstract}
  26.         This report presents a comparison of two types of NoSQL database management systems, the SciDB array oriented and MonetDB column store. Being compared from the same database, it is observed which of the two types of guidance is more efficient to work with in large data stream.
  27.     \end{abstract}
  28.    
  29.     \begin{resumo}
  30.         Este relatório apresenta uma comparação de dois tipos de sistemas de gerenciamento de banco de dados em NoSQL, o SciDB orientado a array e o Monetdb orientado a coluna. Sendo comparados a partir de uma mesma base de dados, é observado qual dos dois tipos de orientação é mais eficiente para se trabalhar com um grande fluxo de dados.
  31.     \end{resumo}
  32.    
  33.    
  34.     \section{Introdução}
  35.    
  36.     Atualmente pode-se observar um grande volume de dados, que ao utilizar processamento de dados tradicionais para armazenamento, mostrou-se insuficiente à grande quantidade de dados, a partir dessa necessidade, foi criado o conceito de Big Data.
  37.    
  38.     Os sistemas de gerenciamento de dados NoSQL, surgiram para atender a necessidade de administrar um grande fluxo de dados, alta escabilidade e disponibilidade e menor custo operacional e de gestão.
  39.  
  40.     \subsection{NoSQL} \label{sec:NoSQL}
  41.    
  42.    O NoSQL possui como principais características ser não-relacional, ser distribuído, possuir fonte aberta e ser escalável. Nele existem diversos tipos orientação de processamento de dados, cujo podemos citar: os orientados à coluna, orientados à chaves, orientado à documentos, baseados em grafos, baseado em banco de dados multidimensionais e entre outros.
  43.  
  44.    Dentre os sistemas de banco de dados NOSQL, foram escolhidos o SciDB, que possui seu banco de dados orientado a array e Monetdb, com seu banco de dados orientado a coluna para fazer a comparação e estabelecer o melhor método.
  45.  
  46.  
  47.     \subsection{SciDB} \label{sec:SciDB}
  48.    
  49.     Banco de dados que foi projetado para análises avançadas de dados multidimensionais, possui aplicações em gerenciamento e análise de finanças, indústrias e na ciência.
  50.    
  51.     Sua arquitetura massiva de processamento distribuída em paralelo permite armazenar e acessar dados mais facilmente, diferentemente do banco de dados usando álgebra linear, em que se gasta mais tempo analisando e menos tempo na movimentação de dados móveis para um pacote de software de matemática.
  52.    
  53.    
  54.     \subsubsection{Chunk e Chunk Overlap}
  55.    
  56.     O SciDB possui os conceitos de Chunk e Chunk Overlap que são definidos na criação do Array. O Chunk é uma técnica de particionamento para arrays multidimensionais, onde cada instância é responsável por armazenar e atualizar um subconjunto da matriz localmente, e para a execução de consultas que usam os dados armazenados localmente.
  57.    
  58.     O Chunk Overlap é uma sobreposição de chunks, essa sobreposição também precisa ser bem definida. Porque se a célula que está sendo buscada estiver nesse sobreposição é preciso ter um tamanho bem definido para otimizar a busca. As vantagens de usar o chunk overlap, ou sobreposição de chunks é: acelerar consultas de vizinhos mais próximos, onde cada chunk pode precisar acessar alguns elementos de seus chunks vizinhos e detectar clusters de dados ou recursos que atravessam mais de um chunk.
  59.    
  60.     Chunking é especificado para cada matriz da seguinte maneira. Cada dimensão de uma matriz é dividida em pedaços. Por exemplo, uma matriz com comprimento i de tamanho 10, com chunk de tamanho 5 e j de tamanho 30 com chunk tamanho 10 , iria ser fragmentada da seguinte forma:
  61.    
  62.     \begin{figure}[ht]
  63.         \centering
  64.         \includegraphics[width=.5\textwidth]{Figures/chunked_dimensions.png}
  65.         \caption{Dimensão de um chunk}
  66.         \label{fig:chunked_dimensions}
  67.     \end{figure}
  68.    
  69.     \subsection{Monetdb}
  70.    
  71.     Pioneiro em armazenamento de dados por coluna, ele é construído sobre a representação canônica de relações de banco de dados como colunas. Utiliza-se de tabelas para representação  de  entidades, e  os  dados  são  gravados  em  disco,  agrupados por  colunas,  o  que  reduz  o  tempo  de  leitura  e  escrita  em  disco
  72.    
  73.     MonetDB é projetado para execução em paralelo multi-core em desktops para reduzir o tempo de resposta do processamento de consultas complexas. Cada coluna é mapeada para um arquivo, cujo limite é ditado pelo sistema operativo e plataforma de hardware. O número de segmentos de usuários simultâneos é um parâmetro de configuração.
  74.    
  75.     \subsection{TPC-H}
  76.    
  77.     Antes de abordar a concepção do trabalho, deve ser falado sobre a base de dados TPC-H que foi a utilizada nos bancos.
  78.    
  79.     O TPC-H é um executador de apoio à decisões. Ele consiste em modificações de dados simultâneas. As consultas e os dados que povoam o banco de dados devem ter sido previamente escolhidos para ter ampla relevância em toda a indústria, mantendo um grau de facilidade de implementação. Ele ilustra sistemas que dão suporte à decisão que examinam grande volume de dados(Big Data), executam consultas com um alto grau de complexidade e obtém respostas a questões críticas de negócio.
  80.    
  81.     TPC-H avalia o desempenho de vários sistemas de suporte à decisão pela execução de conjuntos de consultas contra um banco de dados padrão, sob condições controladas. A métrica de desempenho relatado pelo TPC-H é chamado o TPC-H Composite Query-per-hour Performance Metric (QphH @ Size), e reflete vários aspectos da capacidade do sistema para processar consultas. Estes aspectos incluem o tamanho do banco de dados selecionado contra as consultas que serão executadas, o poder de processamento de consulta quando as consultas são apresentadas por um único fluxo, e a taxa de transferência da consulta quando as consultas são apresentadas por vários usuários simultâneos.
  82.    
  83.         \begin{figure}[ht]
  84.         \centering
  85.         \includegraphics[width=1.05\textwidth]{Figures/tpch.png}
  86.         \caption{Esquema do TPC-H}
  87.         \label{fig:chunked_dimensions}
  88.     \end{figure}
  89.    
  90.     \section{Concepção do trabalho}
  91.    
  92.     Em cada sistema de gerenciamento foram introduzidas as informações necessárias para obter-se o desempenho de cada uma e ao final deste relatório será mostrado qual é melhor em relação ao outro. Nas subseções será mostrado os comandos utilizados e cada descrição necessária para o entendimento dos comandos.
  93.    
  94.     Primeiro serão demonstradas as etapas realizadas pelo Monetdb e seu tempo de resposta com os dados introduzidos. Em seguida, o mesmo será feito com o SciDB.
  95.    
  96.    
  97.     \subsection{Criação de tabelas no Monetdb}
  98.    
  99.     A primeiro momento, no Monetdb, foram criadas tabelas, a partir dos comandos:
  100.    
  101.    \begin{verbatim}
  102. CREATE TABLE part (p_partkey integer primary key, p_name
  103. varchar(55), p_mfgr char(25), p_brand char(10), p_type
  104. varchar(25), p_size int, p_container char(10), p_retailprice
  105. decimal, p_comment varchar(23));
  106.    
  107. CREATE TABLE supplier (s_suppkey int primary key, s_name
  108. char(25), s_address varchar(40), s_nationkey int, s_phone
  109. char(15), s_acctbal decimal, s_comment varchar(101));
  110.    
  111. CREATE TABLE partsupp (ps_partkey int, ps_suppkey int,
  112. ps_availqty int, ps_supplycost decimal, ps_comment varchar(199));
  113.    \end{verbatim}
  114.    
  115.     Na primeira tabela são introduzidas as características do produto: uma chave primária, de identificação (primary key), um nome (p\_name), (P\_mfgr) um texto pré-definido fixo,  marca (p\_brand), tipo (p\_type), tamanho (p\_size), (p\_container) um texto pré-definido fixo, preço de varejo (p\_retailprice), e a parte alocada para eventuais comentários (p\_comment).
  116.    
  117.         \begin{figure}[ht]
  118.         \centering
  119.         \includegraphics[width=1\textwidth]{Figures/part_table.png}
  120.         \caption{Tabela 1}
  121.         \label{fig:part_table}
  122.     \end{figure}
  123.  
  124.     Na segunda tabela são introduzidas as características do fornecedor que possui além de seu identificador (s\_suppkey), seu nome (s\_name), endereço (s\_address), identificador de seu país (s\_nationkey), número de telefone (s\_phone), (s\_accbal) um número decimal pré-definido e a parte alocada para comentários(s\_comment).
  125.    
  126.         \begin{figure}[ht]
  127.         \centering
  128.         \includegraphics[width=1\textwidth]{Figures/supllier-ta.png}
  129.         \caption{Tabela 2}
  130.         \label{fig:supllier-ta}
  131.     \end{figure}
  132.    
  133.     Na terceira tabela são introduzidas as partes suplementares como: seu identificador (ps\_partkey), o identificador do fornecedor (ps\_suppkey), a avaliação de qualidade (que varia de 0 a 10) (ps\_availqty), o custo deste produto (ps\_supplycost) e o espaço reservado para comentários (ps\_comment).
  134.    
  135.         \begin{figure}[ht]
  136.         \centering
  137.         \includegraphics[width=1\textwidth]{Figures/partsupp.png}
  138.         \caption{Tabela 3}
  139.         \label{fig:partsupp}
  140.     \end{figure}
  141.    
  142.     \subsection{Inserção de dados na tabela}\label{sec:int}
  143.    
  144.     Após criadas as tabelas, foram inseridos os dados nas listas a partir dos comandos:
  145.  
  146.    \begin{verbatim}
  147.    
  148. COPY INTO nation FROM '/home/bigdata/monetdb/arthureiuri/
  149. nation.tbl' USING DELIMITERS '|', '\n';
  150.  
  151.  
  152.     COPY INTO region FROM '/home/bigdata/monetdb/arthureiuri/
  153.     region.tbl' USING DELIMITERS '|', '\n';
  154.    
  155.    
  156.     COPY INTO part FROM '/home/bigdata/monetdb/arthureiuri/
  157.     part.tbl' USING DELIMITERS '|', '\n';
  158.    \end{verbatim}
  159.    
  160.    
  161.     \subsection{Teste de eficiência}\label{sec:teste}
  162.    
  163.     Em seguida a adição dos dados no banco, foi testada a eficiência do Monetdb.
  164.    
  165.    
  166.     \subsection{Inserção de arrays no SciDB}
  167.    
  168.     Terminado o experimento no Monetdb, foi inicializado o mesmo no SciDB, primeiramente criando-se arrays a partir dos comandos:
  169.    
  170.    \begin{verbatim}
  171.    
  172. CREATE ARRAY region <r_regionkey : int64, r_name : string,
  173. r_comment : string > [I = 0:*, 5, 0];
  174.    
  175.  
  176.     CREATE ARRAY nation <n_nationkey : int64, n_name : string,
  177.     n_regionkey : int64, n_comment : string > [I = 0:*, 5, 0];
  178.    
  179.    
  180.     CREATE ARRAY supplier <s_suppkey : int64, s_name : string,
  181.     s_address : string, s_nationkey : int64, s_phone : string,
  182.     s_acctbal : float, s_comment : string >  [I = 0:*, 5, 0];
  183.    
  184.    \end{verbatim}
  185.    
  186.     No primeiro array foram introduzidas as características da região, como  identificador (r\_regionkey), o nome (r\_name), e o espaço reservado para comentários(r\_comment).
  187.    
  188.     No segundo array foram introduzidas as características do país, como  identificador (n\_nationkey), o nome (n\_name), o identificador da região(n\_regionkey) e o espaço reservado para comentários(r\_comment).
  189.    
  190.     No terceiro array foram introduzidas as características do fornecedor, que contém seu identificador (s\_suppkey), seu nome (s\_name), endereço (s\_address), identificador de seu país (s\_nationkey), número de telefone (s\_phone), (s\_accbal) ? e a parte alocada para comentários(s\_comment).
  191.    
  192.     Ao final da criação de cada array, como pode ser observado, foi apresentado o comando \textit{[I = 0:*, 5, 0]}.
  193.     O primeiro atributo passado, i, assume o valor de 0,
  194.    
  195.    
  196.     \subsection{Tranformação de arquivos .csv para .scidb}
  197.    
  198.     Já criadas as tabelas, foram transformados os arquivos do tipo .csv, com valores de saída separado por vírgulas,  para .scidb, com valores em formato de array:
  199.    
  200.     \begin{verbatim}
  201.     csv2scidb -s 0 -p NSNS -d ';' </home/bigdata/monetdb/
  202.     arthureiuri/nation.csv> /home/bigdata/monetdb/arthureiuri/
  203.     nation.scidb
  204.    
  205.     csv2scidb -s 0 -p NSSNSNS -d ';' </home/bigdata/monetdb/
  206.     arthureiuri/supplier.csv> /home/bigdata/monetdb/arthureiuri/
  207.     supplier.scidb
  208.    
  209.     csv2scidb -s 0 -p NNSNNSSNS -d ';' </home/bigdata/monetdb/
  210.     arthureiuri/orders.csv> /home/bigdata/monetdb/arthureiuri/
  211.     orders.scidb
  212.     \end{verbatim}
  213.    
  214.    O comando inicial cvs2scidb, prepara a transformação do tipo de arquivo .cvc para o .scidb,
  215.    
  216.     \subsection{Inserção de dados nos arrays}
  217.    
  218.     Após inseridos os arrays e transformados os arquivos para a extensão do SciDB, foram inseridos os dados nos arrays.
  219.    
  220.    \begin{verbatim}
  221. LOAD nation FROM '/home/bigdata/monetdb/arthureiuri/nation.scidb';
  222.    
  223. LOAD supplier FROM '/home/bigdata/monetdb/arthureiuri/supplier.scidb';
  224.  
  225. LOAD customer FROM '/home/bigdata/monetdb/arthureiuri/customer.scidb';
  226.    \end{verbatim}
  227.    
  228.     No primeiro momento foi carregado no banco de dados o arquivo que contém os países, posteriormente foram carregados os fornecedores e em seguida, o arquivo que contém os clientes.
  229.    
  230.     \subsection{Teste de eficiência}
  231.    
  232.     O banco agora com dados, permite com que seja testado o banco orientado à arrays, SciDB.
  233.    
  234.    
  235.    
  236. %   \begin{figure}[ht]
  237. %       \centering
  238. %       \includegraphics[width=.5\textwidth]{figures/fig1.jpg}
  239. %       \caption{A typical figure}
  240. %       \label{fig:exampleFig1}
  241. %   \end{figure}
  242. %  
  243. %   \begin{figure}[ht]
  244. %       \centering
  245. %       \includegraphics[width=.3\textwidth]{figures/fig2.jpg}
  246. %       \caption{This figure is an example of a figure caption taking more than one
  247. %           line and justified considering margins mentioned in Section~\ref{sec:figs}.}
  248. %       \label{fig:exampleFig2}
  249. %   \end{figure}
  250.    
  251.     %In tables, try to avoid the use of colored or shaded backgrounds, and avoid
  252. %   thick, doubled, or unnecessary framing lines. When reporting empirical data,
  253. %   do not use more decimal digits than warranted by their precision and
  254. %   reproducibility. Table caption must be placed before the table (see Table 1)
  255. %   and the font used must also be Helvetica, 10 point, boldface, with 6 points of
  256. %   space before and after each caption.
  257.    
  258. %   \begin{table}[ht]
  259. %       \centering
  260. %       \caption{Variables to be considered on the evaluation of interaction
  261. %           techniques}
  262. %       \label{tab:exTable1}
  263. %       \includegraphics[width=.7\textwidth]{figures/table.jpg}
  264. %   \end{table}
  265.    
  266. %   \section{Images}
  267.    
  268. %   All images and illustrations should be in black-and-white, or gray tones,
  269. %   excepting for the papers that will be electronically available (on CD-ROMs,
  270. %   internet, etc.). The image resolution on paper should be about 600 dpi for
  271. %   black-and-white images, and 150-300 dpi for grayscale images.  Do not include
  272. %   images with excessive resolution, as they may take hours to print, without any
  273. %   visible difference in the result.
  274.    
  275. %   \section{References}
  276.    
  277. %   Bibliographic references must be unambiguous and uniform.  We recommend giving
  278. %   the author names references in brackets, e.g. \cite{knuth:84},
  279. %   \cite{boulic:91}, and \cite{smith:99}.
  280.    
  281. %   The references must be listed using 12 point font size, with 6 points of space
  282. %   before each reference. The first line of each reference should not be
  283. %   indented, while the subsequent should be indented by 0.5 cm.
  284.  
  285. \bibliography{referencias}
  286. \bibliographystyle{apa}
  287.  
  288. \end{document}
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement