SQLFire 1.0 da VMware: foco em escalabilidade e paralelismo

[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.