O que é exatamente o Membase?

Faz pouco mais de duas semanas desde o lançamento do membase.org, juntamente com os parceiros da NorthScale na Zynga e NHN. Nesse período, temos aumentado constantemente as postagens no wiki e respondido a perguntas no lista de mala diretao bate-papo XMPP e o canal IRC. Quando surgem perguntas, elas tendem a ser sobre como o sistema de gerenciamento de banco de dados membase se compara a outros projetos de código aberto, que tipo de cliente seria usado ou quais são as peças quando implantadas.

O mundo do NoSQL

Em geral, acho que as pessoas entendem que, em um nível mais alto, o membase é um sistema de gerenciamento de banco de dados de valor-chave distribuído, projetado para aumentar e diminuir a escala, sem interromper os serviços de dados.

O Membase é um exemplo de banco de dados projetado para oferecer o mesmo tipo de desempenho que os aplicativos precisam para estar no caminho crítico da obtenção de dados para o usuário. Observando o mundo do NoSQL, na minha opinião, essa era uma área mal atendida.

Por ser uma área nova, há muita experimentação com o NoSQL. Alguns estão experimentando uma combinação de análise e on-line, outros estão experimentando uma consistência mais frouxa ou eventual, outros estão adicionando mais primitivos de estrutura de dados em armazenamentos K/V e outros ainda estão analisando os dados de uma forma mais orientada a documentos.

Conhecíamos e até fizemos experiências com vários deles, mas acabamos seguindo um caminho diferente com o membase, pois estávamos tentando resolver alguns problemas muito específicos junto com nossos parceiros. Os aplicativos haviam sido criados com base no memcached. Uma parte desses aplicativos precisava absolutamente de SQL; para isso, eles já tinham o Drizzle, MySQL ou PostgreSQLou Cubrid (O Cubrid é grande na NHN). Outra parte dos mesmos aplicativos realmente não precisava de SQL, mas precisava da replicação, da persistência e do gerenciamento de dados que a maioria dos sistemas de gerenciamento de banco de dados relacionais (RDBMS) baseados em SQL fornecia, embora com mais complexidade e gerenciamento do que o normalmente desejado.

Entra em cena o membase. Poderíamos pegar a infraestrutura existente em torno da qual os aplicativos haviam sido criados (protocolo e clientes memcached) e adicionar o nível necessário de durabilidade, adicionar regras para permitir que os administradores e desenvolvedores controlassem como essa durabilidade ocorre por item e ser inteligentes sobre como ela seria executada de forma distribuída.

Como a borracha encontra a estrada?

Precisávamos injetar um pouco de inteligência no sistema. A beleza do memcached é que a inteligência está, em sua maior parte, no cliente, de modo que o servidor pode ser apenas rápido e burro. Não queríamos nos afastar muito disso, mas se você espera que o sistema seja não volátil, tenha replicação e possa crescer e diminuir enquanto estiver on-line, você precisa que o sistema tenha algum conceito de onde as coisas estão. Isso levou ao vbuckets, que O excelente blog de Dustin aborda.

Com uma maneira de saber onde as coisas estão, ainda precisamos de durabilidade e replicação junto com esses buckets. É aí que entra o mecanismo do membase. O mecanismo do membase pode ser instruído a replicar um conjunto de dados de um nó alternativo. Ele também pode ser informado, por meio de um mapa de configuração, quem é a autoridade para um determinado bucket.

Porém, mais adiante na pilha, os clientes não saberão sobre vbuckets. Eles conhecem modulus ou hashing consistente para se conectar aos servidores, portanto, precisávamos de algo compatível. Já tínhamos o moxi, que daria aos clientes uma inteligência muito simples em relação à deduplicação de operações, compartilhamento inteligente de conexões, o que fazer em caso de falhas e até mesmo algum cache não coerente para acelerar ainda mais as coisas. Não seria preciso muito mais para ensinar o moxi e seu mecanismo de configuração subjacente, libconflate, a saber o que fazer com o mesmo mapa vbucket. Isso permitiria que os clientes existentes e até mesmo os aplicativos existentes obtivessem o banco de dados de chave/valor rápido e distribuído de que precisavam, então foi isso que fizemos.

Conclusão

Em sua essência, o membase é o mecanismo do membase que implementa a persistência, a replicação e os vbuckets para crescer e diminuir dinamicamente. Para levar os vbuckets aos clientes que não têm essa pequena parcela extra de inteligência, existe o moxi. Para migrar dados entre nós sem interromper o serviço, existe o vbucketmigrator. Fique de olho no site membase.org à medida que formos fornecendo mais detalhes.