BT

SQLFire 1.0 da VMware: foco em escalabilidade e paralelismo

por Kostis Kapelonis , traduzido por Adalberto Zanata em 02 Fev 2012 |

[Esta nota foi reestruturada e otimizada pela equipe editorial do InfoQ Brasil]

A VMware lançou em dezembro de 2011 a primeira versão estável do SQLFire, um banco de dados SQL distribuído, voltado para alta disponibilidade e escalabilidade horizontal, que oferece replicação e particionamento de tabelas, além da execução de consultas paralelas.

O SQLFire oferece a maioria dos recursos esperados de um sistema de banco de dados relacional tradicional (RDBMS), incluindo o suporte a consultas SQL e drivers JDBC (suporta também .NET). Pode ser implantado no modo embarcado (dentro de um processo Java) ou em uma arquitetura cliente-servidor. Em teoria, o SQLFire pode ser usado em aplicações Java como um repositório de dados SQL auto-contido, já que o driver JDBC, o mecanismo de consultas e o servidor de rede do SQLFire vêm diretamente do Apache Derby, que é um dos componentes da solução.

(Note que, embora muitos dos componentes sejam open source, o SQLFire em si é uma solução proprietária, sendo oferecido como um produto comercial. É possível obter uma versão para fins de avaliação, no entanto.)

O SQLFire oferece recursos adicionais que vão além do paradigma de um único servidor de banco de dados monolítico. Combina a interface SQL tradicional com a tecnologia GemFire, que é baseada em clusters horizontais e pode ser implantado em grupos de clusters com vários hosts. Esses grupos podem conter:

  • Nós (nodes) de armazenamento, que hospedam os dados e podem executar instruções SQL;
  • Nós de acesso, que são capazes de executar instruções SQL, mas não armazenam dados;
  • Nós de localização, que não armazenam dados e não executam instruções, sendo usados apenas para a descoberta de clusters.

Todos os nós têm acesso direto a outros nós e a arquitetura em cluster é completamente abstraída do código de aplicação, que se conecta ao SQLFire via JDBC. Nos bastidores, o SQLFire oferece ainda:

  • Replicação e particionamento de tabelas em todo o cluster;
  • Execução paralela de consultas (Map-Reduce nativo);
  • Transações distribuídas;
  • Persistência em disco opcional;
  • Possibilidade de usar um banco de dados relacional externo (ex.: MySQL) para o armazenamento de dados.

O SQLFire introduz extensões DDL personalizadas que ativam as funcionalidades adicionais. Segue um exemplo em que uma tabela "Airlines" (linhas aéreas) é replicada para os nós do cluster e a tabela "Flights" (voos) é particionada de acordo com uma coluna específica:

    CREATE TABLE AIRLINES
    (
        AIRLINE CHAR(2) NOT NULL CONSTRAINT AIRLINES_PK PRIMARY KEY,
        AIRLINE_FULL VARCHAR(24),
        ECONOMY_SEATS INTEGER,
        BUSINESS_SEATS INTEGER,
        FIRSTCLASS_SEATS INTEGER
    ) REPLICATE;

    CREATE TABLE FLIGHTS
    (
        FLIGHT_ID CHAR(6) NOT NULL ,
        ORIG_AIRPORT CHAR(3),
        DEPART_TIME TIME,
        DEST_AIRPORT CHAR(3),
        ARRIVE_TIME TIME,
        MILES INTEGER,
        AIRCRAFT VARCHAR(6),
        CONSTRAINT FLIGHTS_PK PRIMARY KEY (
        FLIGHT_ID)
    )
    PARTITION BY COLUMN (FLIGHT_ID);

Note que ambas as tabelas são armazenadas apenas na memória por padrão, uma vez que a palavra-chave PERSISTENT do SQLFire não foi utilizada. Há também outras extensões disponíveis, para se definir co-location de tabelas, agrupamento de servidores, execução de procedimentos paralelos etc. Ao selecionar uma combinação dessas funcionalidades, é possível implantar o SQLFire como:

  • Banco de dados SQL independente (stand-alone) em memória;
  • Banco de dados SQL independente com persistência em disco;
  • Banco de dados distribuído misto (com apenas um subconjunto de tabelas em memória, replicadas e/ou particionadas);
  • Cache de memória (várias políticas de despejo são disponibilizadas);
  • Cache para um banco relacional existente.

O último cenário (cache para um banco relacional) é especialmente interessante, pois procura dividir os dados de um banco relacional em duas categorias distintas:

  • Dados históricos que dispensam acesso rápido e podem ser acessados pelo banco relacional;
  • Dados transacionais ou que mantêm estado da aplicação (sessões de usuários, por exemplo), que são acessados através do SQLFire, fazendo o papel de um cache intermediário.

Para conhecer mais sobre o SQLFire, consulte oguia de referência e o blog do produto.

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão
Comentários da comunidade

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2014 C4Media Inc.
Política de privacidade
BT