DB2 Express-C 9.5

2,703 views
2,598 views

Published on

Documento do trabalho final da cadeira Sistemas de Bancos de Dados, do semestre 2010/A, da UNIVATES.

http://blog.brunozambiazi.com

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,703
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
0
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

DB2 Express-C 9.5

  1. 1. Trabalho de Sistemas de Bancos de Dados Centro Universitário UNIVATES DB2 Express-C 9.5 Bruno Dadalt Zambiazi Lajeado, 10 de julho de 2010.
  2. 2. Sumário Sumário............................................................................................................................. 2 Introdução......................................................................................................................... 3 DB2................................................................................................................................... 4 DB2 Express-C 9.5 ....................................................................................................... 4 Controle e Recuperação de Transações ............................................................................ 5 Teste 1 .......................................................................................................................... 5 Teste 2 .......................................................................................................................... 5 Teste 3 .......................................................................................................................... 6 Controle de Concorrência................................................................................................. 6 Níveis de Isolamento .................................................................................................... 6 → Uncommited Read ............................................................................................ 6 → Cursor Stability................................................................................................. 7 → Read Stability ................................................................................................... 7 → Repeatable Read ............................................................................................... 7 Bloqueio ....................................................................................................................... 8 → Shared Locks .................................................................................................... 9 → Exclusive Locks................................................................................................ 9 Testes ............................................................................................................................ 9 Caso 1 ....................................................................................................................... 9 Caso 2 ....................................................................................................................... 9 Processamento e Otimização de Consultas .................................................................... 10 Consulta 1 ................................................................................................................... 10 Consulta 2 ................................................................................................................... 12 Consulta 3 ................................................................................................................... 14 Consulta 4 ................................................................................................................... 14 Consulta 5 ................................................................................................................... 15 Consulta 6 ................................................................................................................... 16 Replicação de Dados ...................................................................................................... 17 Bidirecional com um Mestre ...................................................................................... 18 Bidirecional sem um Mestre....................................................................................... 18 Suporte e Recursos a XML............................................................................................. 19 XML – Enabled .......................................................................................................... 19 → Modelo Clob/Varchar ..................................................................................... 20 → Modelo Shredding .......................................................................................... 20 PureXML.................................................................................................................... 20 Exemplos .................................................................................................................... 21 Conclusões...................................................................................................................... 23 2
  3. 3. Introdução O presente documento visa apresentar uma visão geral acerca do Sistema Gerenciador de Bancos de Dados DB2, além dos resultados obtidos em todas as etapas de testes propostas pelo trabalho solicitado. Os testes envolvem os seguintes conceitos: controle de transações, controle de concorrência, otimização e processamento de consultas, replicação de dados e suporte a XML. Para o desenvolvimento do trabalho, foi utilizada a versão gratuita mais recente do DB2, a Express-C 9.5. Todos os testes que envolviam operações de inserção/alteração/exclusão de registros, foram feitos através de programas Java que se conectavam ao banco de dados através de uma conexão JDBC. Todos os relatórios e arquivos de log contêm o prefixo [Anexo] e foram anexados ao documento PDF através da ferramenta Foxit Reader. Caso o leitor de PDF com o qual esteja visualizando este documento não permita tal funcionalidade, o software pode ser baixado no seguinte endereço: http://www.foxitsoftware.com/downloads/. 3
  4. 4. DB2 Em 1983, a IBM, International Business Machine, anunciou o lançamento do Sistema Gerenciador de Bancos de Dados DB2. Inicialmente projetado para rodar apenas nos mainframes da própria IBM, o projeto começou no ano de 1978 e foi nomeado de System R, nome que permaneceu até a data do lançamento oficial. No início da década de 1990, a IBM anunciou o lançamento de versões do DB2 para outras plataformas de servidores, como UNIX e Windows. Atualmente, o DB2 suporta a instalação, também, em ambientes Linux e em PDA’s. É considerado um dos SGBD’s mais poderosos do mercado, sendo recomendado para aplicações que necessitam de grande quantidade de armazenamento de dados e alto desempenho em consultas. Duas características interessantes do DB2 são o suporte nativo a XML e a possibilidade de criação de stored procedures em diversas linguagens de programação, tais quais SQL PL, C/C++, Java, COBOL, entre outras. A IBM oferece quatro diferentes edições para o DB2: Express-C, Express Edition, Workgroup Edition e Enterprise Edition. Enquanto as três últimas são pagas, a primeira é livre e foi utilizada para o desenvolvimento deste trabalho. A imagem a seguir dá uma ideia da diferença de funcionalidades encontradas nas diferentes edições do DB2: DB2 Express-C 9.5 Em 2006, após o anúncio do lançamento das edições gratuitas dos SGBD’s da Oracle e da Microsoft, seus maiores concorrentes, a IBM resolveu adotar a mesma 4
  5. 5. estratégia e lançar uma edição gratuita do seu banco de dados, o qual ganhou o nome de DB2 Express-C. Utilizando a mesma funcionalidade principal e o mesmo código-fonte das edições pagas, o DB2 Express-C pode ser utilizado em sistemas de 32 ou 64 bits e em sistemas operacionais Linux, Solaris e Windows. Pode ser utilizado em servidores que contenham, no máximo, 2 processadores e 2GB de memória RAM . Não possui limites quanto à utilização em relação ao tamanho da base de dados, número de bancos de dados ou número de usuários/conexões. Controle e Recuperação de Transações Neste capítulo, não será explicada nenhuma teoria. Haverá apenas a apresentação dos testes realizados conforme solicitado. Teste 1 Descrição: Executar uma rotina e, durante a mesma, parar o servidor. Iniciar novamente o servidor, verificando se a transação funcionou corretamente; Método: execução de uma rotina responsável pela inserção de 425 registros na tabela retiradas; Mensagem: Erro fatal: [jcc][t4][2055][11259][4.8.87] O gerenciador de banco de dados não está apto a aceitar novos pedidos, todos os pedidos em progresso foram terminados, ou este pedido específico foi terminado devido a condições de erro inesperadas detectadas no sistema de destino. ERRORCODE=-4499, SQLSTATE=58009; Log: [Anexo] 1 – 7.1; Número de registros na tabela antes de parar o servidor: 0 (zero); Número de registros na tabela após parar o servidor: 0 (zero); Conclusão: passou no teste, pois nenhum registro foi inserido ao ocorrer um erro durante a transação. Teste 2 Descrição: Executar duas rotinas de forma simultânea e, quando uma delas indicar que terminou, parar o servidor. Iniciar novamente o servidor e verificar se a transação que terminou teve os dados efetivados e se a outra teve as atualizações desfeitas; Método: execução de uma rotina responsável pela inserção de 25 registros na tabela exemplares, e outra pela inserção de 440 registros na tabela retiradas; Mensagem: Erro fatal: [jcc][t4][2055][11259][4.8.87] O gerenciador de banco de dados não está apto a aceitar novos pedidos, todos os pedidos em progresso foram 5
  6. 6. terminados, ou este pedido específico foi terminado devido a condições de erro inesperadas detectadas no sistema de destino. ERRORCODE=-4499, SQLSTATE=58009; Log: [Anexo] 1 – 7.2; Número de registros na tabela exemplares antes de parar o servidor: 500; Número de registros na tabela retiradas antes de parar o servidor: 0 (zero); Número de registros na tabela exemplares após de parar o servidor: 525; Número de registros na tabela retiradas após de parar o servidor: 0 (zero); Conclusão: passou no teste, pois a transação que estava aberta no momento em que o servidor parou, não teve seus dados salvos. Teste 3 Descrição: Executar uma rotina e, antes do término, finalizá-la. Verificar se as atualizações aparecem na base de dados. Finalizar o servidor ou matar o processo da conexão para verificar se os dados inseridos aparecem no banco; Método: execução de um rotina responsável pela inserção de 400 registros na tabela retiradas, realizando o seu cancelamento através da linha de comando; Mensagem: nenhuma, pois a rotina foi cancelada pela linha de comando; Log: [Anexo] 1 – 7.3 (o arquivo ficou vazio pois a rotina foi cancelada antes de gravar os dados, que é a última parte do código da rotina); Número de registros na tabela antes de parar o servidor: 0 (zero); Número de registros na tabela após parar o servidor: 0 (zero); Conclusão: passou no teste, pois nenhum registro foi inserido ao ocorrer um erro durante a transação. Controle de Concorrência Pode-se definir a concorrência como o fato de diversas aplicações acessarem o mesmo dado simultaneamente. Este acesso, no entanto, deve ser coordenado de forma correta para que seja a atualização das informações seja transparente aos usuários. No SGBD DB2, há quatro níveis de isolamento e dois níveis de bloqueio permitidos para que o controle de concorrência ocorra de forma adequada. Níveis de Isolamento → Uncommited Read Uncommited Read, Leitura de Dados não Finalizado, é o menor nível de isolamento e, consequentemente, oferece o maior nível de concorrência. Não ocorrem bloqueios de linha quando são executadas operações de leitura, exceto quando existem operações de 6
  7. 7. DROP ou ALTER TABLE. As operações de UPDATE bloqueiam a linha até que a transação termine. Problemas que podem ocorrer: Leitura de dados não finalizados; Leitura de dados não repetidos; Leitura fantasma. Problemas que são evitados: Perda na atualização. → Cursor Stability Cursor Stability, Estabilidade do Cursor, é o nível de isolamento padrão do DB2 e fornece o menor nível de bloqueio. Em operações de leitura, bloqueia a linha corrente do cursor até que a mesma seja capturada (fetched); se for para atualiações, o bloqueio das linhas é feito até o término da transação. Problemas que podem ocorrer: Leitura de dados não repetidos; Leitura fantasma. Problemas que são evitados: Perda na atualização; Leitura de dados não finalizados. → Read Stability Read Stability, Estabilidade de Leitura, bloqueia todas as linhas que fazem parte da operação solicitada, por qualquer cursor, até que a transação termine. Exemplo: numa consulta que retorna 100 linhas de determinada tabela, sendo que a mesma possui 1000, todas as 100 ficam bloqueadas até o término da operação. Problemas que podem ocorrer: Leitura fantasma. Problemas que são evitados: Perda na atualização; Leitura de dados não finalizados; Leitura de dados não repetidos. → Repeatable Read Repeatable Read, Leitura Repetida, é o maior nível de isolamento pois provê o maior grau de bloqueio e o menor nível de concorrência. O bloqueio é realizado em todas as linhas processadas, ou seja, mesmo as linhas que não fazem parte do resultado final são bloqueadas. Dessa forma, nenhuma transação poderá fazer algo com os dados até que a requisição anterior termine. Problemas que podem ocorrer: Nenhum. 7
  8. 8. Problemas que são evitados: Perda na atualização; Leitura de dados não finalizados; Leitura de dados não repetidos; Leitura fantasma. O nível de isolamento configurado como padrão no DB2 é o Cursor Stability. Para modificá-lo, há três possibilidades: sessão, conexão ou instrução. A configuração à nível de instrução é bastante simples, bastando adicionar a cláusula WITH XX, onde XX pode ser UR, CS, RS, RR (as iniciais dos nomes), ao final de uma instrução SQL normal. Abaixo, uma imagem que exemplifica a diferença entre os quatro níveis de bloqueio do DB2: Bloqueio O conceito de bloqueio é relacionado com o de concorrência, pois o objetivo dele – o bloqueio – é parar temporariamente outras operações até que a primeira operação termine. Quanto mais bloqueios houver, menor será a concorrência, enquanto que com menos bloqueios a concorrência será maior. Os bloqueios ocorrem de forma automática, de acordo com a necessidade de garantir a segurança da transação e sempre há o desbloqueio ao término da mesma. Podem acontecer à nível de tabela ou apenas de linhas de tabelas. Existem dois tipos de bloqueio: 8
  9. 9. → Shared Locks Os Shared Locks, ou Bloqueios Divididos, acontecem quando uma transação está lendo os dados de uma tabela e impede que outras transações realizem operações de alteração nas mesmas linhas. → Exclusive Locks Os Exclusive Locks, ou Bloqueios Exclusivos, acontecem quando uma transação quer realizar alterações (inserção, exclusão, alteração) em uma linha e impede que outras transações façam a leitura destes dados. Testes Não foram executados testes com diferentes níveis de isolamento e/ou bloqueio. Todos os testes realizados levaram em conta apenas as configurações default do SGBD DB2. Caso 1 Descrição: Executar duas rotinas simultâneas que alteram dados na tabela retiradas. A primeira rotina deve efetuar consultas por períodos, ou seja, de 01 a 02 de março, depois de 03 a 04 do mesmo mês e assim por diante. Após a consulta, os dados dos registros devem ter a data alterada, adicionando um dia a ela. Devem ser executadas diversas consultas em sequência durante um certo tempo. Já a segunda rotina deve efetuar consultas por período, primeiro para o usuário 1, depois para o 2 e assim por diante. Após a consulta, os dados dos registros devem ter a data alterada, subtraindo um dia a ela. Em ambas as rotinas, cada consulta e alteração deve ser considerada uma transação; Método: a primeira rotina buscou as retiradas do mês 03/2010, de dois em dois dias, adicionando um dia à data de retirada e atualizando o registro; a segunda rotina buscou as retiradas de 20 usuários sorteados, subtraindo um dia à data de cada retirada; Log: [Anexo] 2 – 2.1.1 - Período e [Anexo] 2 – 2.1.2 - Usuário; Conclusão: baseando-se na retirada 29780, registro encontrado nos dois arquivos de log, é possível concluir que não houve problemas de concorrência. No primeiro log (de consultas por período), as datas antiga e nova dessa retirada são 01/03 e 02/03, respectivamente, havendo o update no horário 09:48:32:609. Já no segundo log (de consultas por usuário), a mesma retirada apareceu com as datas antiga e nova, respectivamente, como 02/03 e 01/03, com a atualização no horário 09:48:33:484. Caso 2 Descrição: três rotinas, uma lendo os exemplares de livros, uma alterando a data de compra dos exemplares e outra inserindo novos exemplares. A rotina que lê os valores deve executar repetidamente uma instrução SQL que conta os exemplares por livro; 9
  10. 10. Método: a primeira rotina realizou a contagem do número de exemplares para cada produto por 500 vezes seguidas; a segunda rotina adicionou um dia à data de aquisição de cada exemplar dos livros; a terceira rotina inseriu um exemplar para cada livro, colocando como data 30 dias após a maior data de aquisição de um exemplar daquele mesmo livro. Obs.: os produtos utilizados para as três rotinas foram: 10507, 11136, 9352, 9566, 11132, 8553, 8739, 9527, 10956, 10076, 9063, 9013, 8994, 10637, 9464, 8578, 10089, 10217, 11017, 10032, 8887, 11030, 9707, 9005, 10195, 10134, 9645, 8620, 8579, 9197, 9309, 10371, 9745, 9241, 10388, 10392, 8747, 9830, 9732, 10855, 8919, 8569, 10620, 9288, 11125, 11027, 9690, 10397, 9365, 9218, 9706, 11087, 9929, 9373, 9943, 10490, 11062, 10506, 9378, 9305, 9842, 8615, 9554, 9718, 9825, 9215, 10839, 10052, 8713, 9737, 9162, 8907, 9787, 9861, 11081, 10500, 9631, 9844, 9219, 9030, 10753, 9656, 9642, 9573, 9441, 9673, 8688, 10309, 9096, 9069, 9754, 9488, 10373, 10636, 9607, 9439, 9826, 9945, 9996, 8824, 11094, 9927, 10591, 11012, 9523, 9592, 9308, 8980, 10306, 10060, 10919, 10805, 8780, 9363, 10549, 11121, 10631, 9797, 10078, 9126, 9178, 9188, 10285, 9449, 8716; Log: [Anexo] 2 – 2.2.1 – Contagem, [Anexo] 2 – 2.2.2 – Atualização e [Anexo] 2 – 2.2.3 - Inclusão; Conclusão: baseando-se na contagem de exemplares do livro 8553, pode-se concluir que não houve problema de concorrência. Segundo o primeiro arquivo de log (contagem de exemplares), havia 5 exemplares desse livro até o horário 15:04:40:375, mas, a partir do horário 15.04.40.390, passou a haver 6 exemplares pois, alguns milissegundos antes, de acordo com o terceiro arquivo de log (inclusões de exemplares), houve a inserção de um novo exemplar para o livro. Processamento e Otimização de Consultas Neste capítulo, não será explicada nenhuma teoria. Haverá apenas a apresentação dos testes realizados conforme solicitado. Todos os tempos de execução apresentados foram “capturados” pelo programa Centro de Controle, no qual foram executadas as consultas. Todos os tempos são a média de execução das consultas, todas realizadas três vezes. Consulta 1 10
  11. 11. [Figura 1] Consulta 1 - consulta original Tempos de execução: Consulta original: 0:00:16:98 Consulta sem a cláusula ORDER BY: 0:00:07:22 Consulta original com índices: 0:00:14:19 Índices criados: reti.id_livro reti.nr_sequencia reti.dt_retirada Planos de execução: [Figura 2] Consulta 1 - plano de execução da consulta original 11
  12. 12. [Figura 3] Consulta 1 - plano de execução da consulta sem a clásula ORDER BY [Figura 4] Consulta 1 - plano de execução da consulta original com os índices Consulta 2 [Figura 5] Consulta 2 - consulta Tempos de execução: 12
  13. 13. Consulta: 0:00:05:81 Consulta com índices: 0:00:01:23 Índices criados: reti.id_usuario reti.id_atendente usua.id_cidade aten.id_cidade Planos de execução: [Figura 6] Consulta 2 – plano de execução da consulta original [Figura 7] Consulta 2 - plano de execução da consulta com índices 13
  14. 14. Consulta 3 [Figura 8] Consulta 3 - consulta original (à esquerda) e alternativa (à direita) Tempos de execução: Consulta original: 0:00:48:06 Consulta alternativa: 0:00:21:88 Consulta original com índices: 0:00:11:91 Índices criados: livr.nm_livro Planos de execução: [Figura 9] Consulta 3 – plano de execução da consulta original Consulta 4 [Figura 10] Consulta 4 - consulta 14
  15. 15. Tempos de execução: Consulta original: 0:00:12:32 Consulta sem a condição sobre a data: 0:00:11:94 Planos de execução: [Figura 11] Consulta 4 - plano de execução da consulta original Consulta 5 [Figura 12] Consulta 5 - consulta original (à esquerda) e utilizando junções (à direita) Tempos de execução: Consulta original: 0:00:10:78 Consulta utilizando junções: 0:00:09:36 Planos de execução (os planos das duas consultas ficaram iguais): 15
  16. 16. [Figura 13] Consulta 5 - plano de execução das consultas Consulta 6 [Figura 14] Consulta 6 - consulta original (à esquerda) e alternativa (à direita) Tempos de execução: Consulta original: 0:00:10:39 Consulta utilizando junções: 0:00:06:57 Planos de execução: 16
  17. 17. [Figura 15] Consulta 6 - plano de execução da consulta original Replicação de Dados Este tópico foi o que gerou a maior dificuldade durante o trabalho, em virtude do DB2 não dispor de nenhuma ferramenta gratuita para replicação de dados na edição Express C. No entanto, nas outras edições, a replicação de dados é sempre feita através da captura das informações em determinado servidor e posterior aplicação das alterações nos outros servidores de bancos de dados. Toda a estrutura de replicação do DB2 baseia-se em dois softwares: Capture e Apply. O primeiro software, Capture, deve estar presente nos servidores que sofrerão operações de alteração/exclusão/inserção de dados, por ser o responsável pela captura das informações que estarão sendo manipuladas nele - servidor. Já o segundo, Apply, deve estar presente nos servidores que sofrerão as atualizações pelo processo de replicação, pois é o responsável por aplicar as alterações. Além disso, o DB2 trabalha com as nomenclaturas Source e Target para designar os servidores considerados mestre – Source – e escravos – Target. Existem dois modelos de replicação: com um mestre e sem um mestre. 17
  18. 18. Bidirecional com um Mestre É equivalente ao modelo tradicionalmente conhecido como Master-Slave, no qual o servidor Mestre é o único a receber as alterações e fica responsável por repassá- las aos servidores escravos. No modelo do DB2, o servidor Source – Mestre – precisa conter o software Capture rodando para capturar as alterações sofridas. A partir daí, a replicação é aplicada nos servidores Target – Escravo – através do software Apply que precisa haver nestes. A figura abaixo exemplifica o modelo: Bidirecional sem um Mestre É equivalente ao modelo tradicionalmente conhecido como Multi-Master, no qual qualquer um dos servidores pode receber atualizações e fica responsável por repassar as atualizações aos outros servidores. Dessa forma, todos passam a ser mestres e escravos ao mesmo tempo. No modelo do DB2, todos os servidores precisam conter tanto o software Capture quando o Apply rodando para que consigam capturar as alterações e aplicá-las em si quando necessário. O modelo Biderecional sem um Mestre do DB2 funciona apenas de forma assíncrona. A figura abaixo exemplifica o modelo: 18
  19. 19. Suporte e Recursos a XML O DB2 é, notadamente, um dos SGBD’s que oferece melhor suporte e maior nível de recursos a XML. Algumas características extraídas diretamente da documentação oficial: Técnicas exclusivas para armazenamento e gerenciamento eficiente de estruturas hierárquicas de documentos XML; Técnicas exclusivas de indexação para acelerar pesquisas em documentos XML; Suporte total às linguagens XQuery e XPath; Suporte à validação de dados baseados em esquemas fornecidos por usuários. No DB2, existem dois tipos de bases de dados capazes de armazenar XML: XML-Enabled e XML Nativo. XML – Enabled Utiliza o modelo relacional como núcleo do modelo de armazenamento, o que torna necessário o armazenamento do XML em um campo grande (Modelo Clob/Varchar) ou requer uma espécie de mapeamento entre o modelo hierárquico do XML com o modelo de dados relacional tradicional (Modelo Shredding). 19
  20. 20. → Modelo Clob/Varchar O documento XML é armazenado inteiramente dentro de um único campo de uma tabela relacional, sendo o campo geralmente do tipo Clob ou Varchar. Neste modelo, o documento acaba sendo inserido sem que seja feita uma análise sintática do seu conteúdo, o que torna esta opção não muito flexível no momento da recuperação e manipulação dos dados. → Modelo Shredding Também conhecido como Fragmentação, este modelo faz a análise do documento XML e fragmenta-o em pequenas partes que serão inseridas em diversas tabelas do banco de dados, sendo o documento “forçado” a se tornar um modelo relacional. Esse método também não possui muita flexibilidade devido à complexidade de serem realizadas alterações na estrutura hierárquica do documento XML, além das consultas se tornarem pesadas pela necessidade de utilizar diversas tabelas e junções para formar o resultado final. Abaixo, uma figura ilustrando o funcionamento dos dois modelos: PureXML As bases de dados que armazenam XML nativo, no DB2 conhecido como pureXML, utilizam o modelo de dados hierárquico para armazenar e processar XML internamente. A forma como o documento é armazenado é a mesma com que é processado, sem necessitar de uma conversão para o modelo relacional e nem exigindo que seja feita uma imagem do XML. Quando instruções XQuery e XPath são executadas, estas não precisam ser convertidas para SQL pois são processadas de forma nativa, diretamente no documento. Segundo a documentação oficial, o DB2 foi o 20
  21. 21. primeiro banco de dados a incorporar o XML nativo a sua implementação, o que ocorreu na versão 9. A figura abaixo ilustra a diferença no armazenamento de um dado relacional e de um documento XML na mesma tabela de uma base de dados: O DB2 permite que o acesso aos dados para tabelas que possuem tanto dados relacionais quanto XML pode ser feito de quatro formas: Utilização de SQL para buscar dados relacionais; Utilização de SQL com extensões XML para acessar dados XML; Uso de XQuery para buscar dados XML; Uso de XQuery para acessar dados relacionais. Em virtude de tanta flexibilidade, o DB2 pode ser considerado tanto um banco de dados relacional de alto desempenho, quanto um repositório de documentos XML bastante poderoso. Exemplos A tabela abaixo ilustra as principais funções que podem ser utilizadas para a manipulação de dados XML através de SQL/X, a extensão XML para SQL: 21
  22. 22. Alguns exemplos de utilização de SQL/X: 22
  23. 23. Conclusões Mesmo o pouco tempo de trabalho com o banco de dados DB2 deixa claro que o ele é extremamente poderoso e caracterizado pelo alto desempenho na execução de consultas, mesmo as mais complexas. Fora isso, a enorme gama de ferramentas que o banco possui para administração dá a entender que ele não foi feito para aplicações de pequeno porte. Para utilizar o DB2 como SGBD, é necessário que a empresa possua um DBA específico para conseguir retirar o máximo do poder deste banco. É fácil perceber que ele se encaixa perfeitamente em ambientes de alta disponibilidade e que necessitam de uma ferramenta de armazenamento rápida, confiável, robusta e flexível. 23

×