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.

Avalie esse artigo

Relevância
Estilo/Redação

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
Feedback geral
Bugs
Publicidade
Editorial
Marketing
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2016 C4Media Inc.
Política de privacidade
BT

We notice you’re using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.