Na segunda-feira, o analista Matt Aslett publicou Como o pro-SQL responderá ao NoSQL? no blog "Too Much Information" do The 451 Group. É uma boa leitura. A essência da postagem era a seguinte: Há um monte de indivíduos e empresas afirmando que sua versão específica da tecnologia de banco de dados SQL, memcached ou tecnologia de banco de dados "NoSQL" é a "melhor". O título dá a entender que há um campo "pró-SQL" e um campo NoSQL em conflito entre si, lutando por algum prêmio. Ele conclui de forma muito prática: Isso não deve ser uma questão do tipo "nós contra eles". Não poderíamos estar mais de acordo. A NorthScale não é a favor do SQL nem do NoSQL, somos a favor da escolha.
Nenhuma dessas tecnologias é a "melhor" em um sentido absoluto. Mas cada uma delas pode ser a melhor opção para um determinado aplicativo, caso de uso e ambiente. A tecnologia de banco de dados relacional é a melhor opção para muitos aplicativos; a tecnologia de banco de dados relacional combinada com o memcached é a melhor opção para muitos outros aplicativos; e para outros, tecnologias alternativas de banco de dados representam a melhor opção. Para alguns aplicativos, é indicada uma combinação dessas abordagens. Além da conclusão de Matt de que "muito dependerá da carga de trabalho em questão", também é verdade que essa não é uma decisão estritamente tecnológica. Muito também dependerá dos conjuntos de habilidades de desenvolvedores e operações, investimentos em ferramentas, requisitos de integração, infraestrutura de hardware e muitos outros fatores. Inevitavelmente, esses fatores também representam insumos para a decisão de qual abordagem, ou abordagens, deve ser usada para armazenar os dados operacionais por trás de um determinado sistema de software. Nosso objetivo é fornecer aos usuários orientação e uma opção. O NorthScale Memcached Server é implementado juntamente com a tecnologia de banco de dados relacional, quando apropriado; o NorthScale Membase Server fornece uma tecnologia de banco de dados elástica que é uma escolha apropriada para uma grande classe de aplicativos e dados, e uma opção perfeita para ambientes de computação em nuvem. Também acreditamos que é importante oferecer um caminho claro e contínuo do relacional para o relacional + memcached e para o relacional + memcached + membase. Não posso concluir sem comentar também as observações iniciais da postagem de Matt. Como Matt aponta, memcached é um cache (daí o nome) e não um armazenamento de valores-chave. Embora alguns possam rejeitar essa afirmação como uma zombaria, obscurecer a questão sobrecarregando o nome pode levar (e tem levado) à confusão do usuário e à perda de dados. No entanto, uma coisa é clara: muitos usuários expressaram o desejo de ter algo que tenha algumas das características do memcached (simples, rápido e horizontalmente escalável), com total compatibilidade com o cliente memcached e a API, mas com a semântica e as garantias adicionais de um armazenamento de dados. A comunidade memcached tem trabalhado em uma estrutura de mecanismo de armazenamento para permitir uma resposta sensata a essa solicitação. A estrutura do mecanismo de armazenamento foi desenvolvida abertamente como um ramo de desenvolvimento publicado e, após uma análise mais aprofundada, será adicionada ao ramo de desenvolvimento principal da comunidade. Ela permite que o "front-end" do memcached (ouvinte, inspetor de pacotes, decodificador de protocolo, algum suporte a threading e estatísticas) seja combinado com um back-end que executa operações de dados sob a direção do front-end. Esses mecanismos de armazenamento de back-end podem fornecer persistência, replicação e inúmeros outros recursos que seriam claramente contraproducentes se fossem forçados a entrar em uma "distribuição memcached" monolítica. A NorthScale, juntamente com a Zynga e a NHN, anunciou recentemente o Membase Server. Esse projeto aproveita a interface do mecanismo de armazenamento do memcached para criar um armazenamento de valores-chave, totalmente compatível com o memcached, sem criar uma oferta Frankenstein (um memcached meio que meio que armazena coisas). Provavelmente, a vantagem mais importante dessa abordagem é que somos totalmente compatíveis com o protocolo memcached e construídos a partir da base de código mais recente. Assim, os usuários da nossa distribuição continuarão a se beneficiar dos esforços da comunidade (da qual a NorthScale é a principal colaboradora do código-fonte). Em vez de trabalhar no contexto da comunidade, outras pessoas tiraram um retrato pontual do projeto memcached e começaram a fazer alterações de forma privada. O desafio é que os sistemas resultantes não são mais, para citar um dos líderes do projeto memcached, "distribuições do memcached". Eles são uma bifurcação privada do que já foi memcached - um instantâneo de uma versão antiga do memcached com alterações proprietárias nesse código antigo (e cada vez mais antigo). Há uma séria desvantagem nessa abordagem. Os usuários desses sistemas perdem o que torna o código-fonte aberto um modelo tão bem-sucedido para o desenvolvimento de software de infraestrutura: uma comunidade rica de inovadores que evoluem e aprimoram o software, além de enfatizar e corrigir problemas no código. Porque o NorthScale Memcached Server é Uma vez que o memcached é uma distribuição do memcached, os usuários se beneficiam da compatibilidade completa com o protocolo memcached, da autenticação SASL, do mecanismo de bucket que permite o multilocatário seguro e de muitos outros aprimoramentos atuais e futuros do projeto. Os usuários não ficam presos a uma base de código antiga. E como estamos usando APIs e interfaces suportadas pela comunidade, podemos criar soluções compatíveis com o memcached sem criar ofertas Frankenstein que são meio que memcached e meio que armazenam dados. E não somos colocados no que deve ser uma posição realmente desconfortável de tentar convencer o mundo de que um cache é um banco de dados.
