De demonstração de recursos avançados do Sybase Adaptive Server Enterprise 15.5. A versão 15.5 do Sybase ASE é a última versão do SGBD de uso geral lançada pela Sybase, que foi comprada recentemente pela SAP, mantenedora do SAP R/3, o ERP mais utilizado do mundo.
Para que serve
Para conhecer as características e funcionalidades da última versão do Sybase Adaptive Server Enterprise. Uma destas funcionalidades, o InMemory Database, será a abordada neste artigo com detalhes, inclusive a demonstração de sua implementação.
Em que situação o tema é útil
Para tomar uma decisão sobre qual Sistema Gerenciador de Banco de Dados deve-se utilizar em uma implementação. No caso do In Memory Database, trata-se de um recurso único no mercado de SGBDs, sendo que seus comparativos mais próximos são SGBDs que não possuem todas as características ACID.
Resumo DevMan
O Sybase ASE possui diversas funcionalidades que o tornam um Sistema Gerenciador de Banco de Dados extremamente eficaz e eficiente. Uma destas funcionalidades é o In-Memory Database, que permite que o banco de dados esteja “carregado” totalmente em memória.
A grande vantagem desta estratégia é justamente eliminar o maior problema no que diz respeito a desempenho do banco de dados, ou seja, a leitura e gravação em disco.
O Sybase Adaptive Server Enterprise, ou Sybase ASE, é o Sistema Gerenciador de Bancos de Dados (SGBD) (ver Nota DevMan 1) de uso geral da Sybase, sendo sua versão mais atual a 15.5. A Sybase, atualmente uma empresa SAP, é uma empresa de software que produz serviços e produtos relacionados ao gerenciamento de informação, mobilidade, Messaging (“Mensagens”), ferramentas de desenvolvimento (como o Sybase PowerBuilder, muito utilizado no mercado) e Data Warehousing e OLAP. Desde 1984, a Sybase tem sido líder inovadora no desenvolvimento de tecnologia de bancos de dados e ainda mantém um significativo crescimento de negócios acerca de seu banco relacional, o Adaptive Server Enterprise. Sua base global de clientes inclui 80 dos Fortune 100 e uma forte presença em mercados verticais como o de serviços financeiros, telecomunicações, saúde e governo. Ao contrário do que se pensa, o Sybase ASE não é um produto legado, possuindo funcionalidades que não são equiparadas por nenhum outro SGBD, embora, para ser justo, deva muito em facilidade de uso e de manutenção a outros SGBDs.
Um Sistema de Gerenciamento de Banco de Dados (SGBD) - do inglês DBMS (Data Base Management System) - é o conjunto de programas de computador (softwares) responsáveis pelo gerenciamento de uma base de dados. Seu principal objetivo é retirar da aplicação cliente a responsabilidade de gerenciar o acesso, manipulação e organização dos dados. O SGBD disponibiliza uma interface para que seus clientes possam incluir, alterar ou consultar dados previamente armazenados. Em bancos de dados relacionais a interface é constituída pelas APIs (Application Programming Interface) ou drivers do SGBD, que executam comandos na linguagem SQL (Structured Query Language).
Em edições anteriores a revista SQL Magazine publicou artigos falando sobre o Sybase ASE, sua posição no mercado, e demonstramos sua instalação (ver Leitura Recomendada). Foram vistas, além de outras coisas, algumas funcionalidades exclusivas deste SGBD, entre elas o In-Memory Database. É sobre esta excelente funcionalidade que este artigo trata.
O In-Memory Database permite que um banco de dados seja armazenado completamente em memória, eliminando completamente o maior gargalo dos bancos de dados: a gravação e leitura em discos rígidos. E, ao contrário de soluções similares que utilizam tecnologia NoSQL (ver Nota DevMan 2), no In-Memory Database do Sybase ASE não é necessário alteração da aplicação - para esta é transparente se o banco de dados do Sybase ASE é In-Memory ou convencional.
NoSQL (entenda-se "Not only SQL") é um termo genérico para uma classe definida de banco de dados não-relacionais que rompe uma longa história de banco de dados relacionais com propriedades ACID. Outros termos equivalentes para esta categoria de bancos é NF², N1NF (non first normal form), nested relational, dimensional, multivalue, free-form, schemaless, document database e MRNN (Modelo Relacional Não Normalizado).
O NoSQL chamou atenção recentemente quando o Twitter, uma já conhecida rede social e servidor para microblogging, anunciou que estaria migrando do MySQL para o NoSQL Cassandra. Antes do Twitter, outros websites muito conhecidos também passaram a usar alguma implementação de NoSQL, como por exemplo o Facebook, Digg e Rackspace.
O termo NoSQL surgiu em 1998 como uma abreviação de “Not Only SQL”, ou “Não somente SQL”. Uma tradução direta para o português pode gerar um mal-entendido, pois dá a entender que o NoSQL seja de alguma forma contra a já difundida linguagem SQL. Na verdade o NoSQL veio como uma alternativa ou um complemento aos tradicionais BDs relacionais.
Hoje em dia, as opções NoSQL são aplicadas em armazenamento distribuído de dados e projetados para suportar requisitos de acesso a dados em grande escala. Tratar da escrita e da leitura de grandes quantidades de dados, como por exemplo os 7TB por dia do Twitter, pode ser um desafio para bancos de dados relacionais. Assim, a implementação em modo distribuído do NoSQL permite escalar de forma horizontal, distribuindo os dados entre múltiplos nós (servidores).
É importante lembrar que apesar de serem projetados para suportar performance e escalabilidade, os bancos de dados NoSQL não suportam as propriedades Atomicidade, Consistência, Isolamento e Durabilidade (ACID) que são um padrão nos bancos de dados relacionais. Os desenvolvedores acostumados com o padrão SQL utilizado na grande maioria dos bancos de dados relacionais (apesar de existirem pequenas diferenças entre as implementações SQL dos diferentes fornecedores, pode-se dizer que é possível migrar de um produto a outro, com pouca ou nenhuma modificação no SQL), não irão encontrar o mesmo padrão se usarem implementações NoSQL, pois cada implementação usa seu próprio mecanismo de acesso.
Além disto, também não há comprometimento das propriedades ACID (ver Nota DevMan 3) quando se utiliza o Sybase ASE In-Memory Database.
ACID (acrônimo de Atomicidade, Consistência, Isolamento e Durabilidade), é um conceito utilizado em ciência da computação para caracterizar uma transação.
Atomicidade
Trata o trabalho como parte indivisível (atômico). A transação deve ter todas as suas operações executadas em caso de sucesso ou nenhum resultado de alguma operação refletido sobre a base de dados em caso de falha. Ou seja, após o término de uma transação (commit ou abort), a base de dados não deve refletir resultados parciais da transação.
Consistência
Regras de integridade dos dados são asseguradas, ou seja, as transações não podem quebrar as regras do Banco de Dados.
Isolamento
Tudo se parece como se o trabalho estivesse isolado. O resultado de uma transação executada concorrentemente a outra deve ser o mesmo que o de sua execução de forma isolada. Operações exteriores a uma dada transação jamais verão esta transação em estados intermediários.
Durabilidade
Os efeitos de uma transação em caso de sucesso (commit) são permanentes mesmo em presença de falhas.
Alguns produtos similares ao In-Memory Database do Sybase ASE estão presentes no mercado, mas não possuem todas as características ACID que são necessárias a uma aplicação de missão crítica.
Como a principal característica que diferencia a memória RAM dos discos rígidos é a volatilidade, como o recurso In-Memory Database do Sybase ASE pode ser utilizado para um banco de dados relacional se em um desligamento do servidor (planejado ou não) todos os dados são perdidos?
Bem, uma possível aplicação do In-Memory Database é a utilização em bancos de dados de natureza volátil, como por exemplo, um carrinho de compras de uma loja virtual: os dados são temporários por definição, e podem ser perdidos - em contrapartida, seu acesso de leitura e gravação precisa ser muito rápido e escalável, ou o cliente procurará outra loja virtual. Mas mesmo aplicações que manipulam dados críticos utilizam o ...
