Dave Engberg, CTO do Evernote apresentou em seu blog as razões da empresa ter construído sua arquitetura em torno de um banco de dados relacional, em vez de adotar uma das opções NoSQL que vêm sendo consideradas como as mais adequadas para aplicações web. O Evernote é um serviço de armazenamento e compartilhamento de notas e documentos em nuvem, que vem se tornando cada vez mais popular entre usuários de tablets e smartphones. Engberg comenta:
Quando descrevemos nossa arquitetura de serviços para pessoas inteligentes que estiveram envolvidas em outros serviços de grande porte, duas perguntas surgem com frequência:
- Por que seus dados estruturados estão armazenados em bancos de dados SQL (relacionais) em vez de alguma alternativa NoSQL?
- Por que vocês mantêm seu próprio hardware em vez de hospedarem o Evernote em algum serviço de nuvem?
Engberg reconhece que, para muitas aplicações, sistemas de armazenamento baseados em chave/valor (como é o caso de vários produtos NoSQL) podem oferecer vantagens significativas de escala e performance, quando comparados com uma única instância de um banco de dados relacional. Além disso, ele afirma:
Os benefícios ACID de um banco de dados transacional dificultam escalar um conjunto de dados para além dos limites de um único servidor. O Clustering e a replicação multi-master de bancos de dados relacionais são ainda uma arte obscura e complexa; repositórios de dados chave/valor, por outro lado, oferecem uma maneira muito mais simples de se escalar um único pool de armazenamento em vários servidores de baixo custo.
Apesar das desvantagens, Engberg afirma que as características transacionais do banco de dados MySQL com InnoDB são fundamentais para o Evernote e seu modelo de sincronização. A correspondência entre cada chamada à API de serviços do Evernote com uma transação de banco de dados evita diversos cenários de inconsistência de dados e a necessidade das aplicações terem que gerenciá-los.
Esse alinhamento entre chamada de API e transação garante não apenas que os usuários do serviço sejam cobrados corretamente pelo seu uso, mas também que os efeitos de qualquer ação de atualização de dados realizada por um usuário tornem-se imediatamente visíveis em todos os seus dispositivos, ou acessíveis através de funcionalidades de busca.
Engberg destaca o quanto é importante a durabilidade das transações (o "D" do ACID) para o Evernote:
Se o cliente não pudesse ter a certeza de que mudanças salvas no servidor sejam duráveis, o protocolo se tornaria muito mais complexo e menos eficiente. Cada cliente sendo sincronizado teria que verificar constantemente se o estado de cada objeto de servidor está de acordo com o estado local. Manter a consistência para uma conta com 20 mil nós, 40 mil recursos e 10 mil rótulos seria muito caro, se as alterações não pudessem contar com a durabilidade.
A questão da escalabilidade é resolvida pelo Evernote utilizando o particionamento horizontal de dados. Esta técnica, conhecida como sharding, é suportada sem esforço pelos frameworks Java adotados pela empresa: Hibernate, EhCache, Sharding e Lucene. Engberg explica que o Evernote não representa um cenário de Big Data, apesar de já ter ultrapassado os dois bilhões de recursos (imagens, arquivos, notas etc) armazenados, pois os dados de um usuário não têm relacionamentos com os dados de outros usuários. Assim os dados dos 20 milhões de usuários são particionados em 90 servidores, cada qual servindo aproximadamente 100 mil usuários.
Todos os dados de um usuário estão na mesma máquina virtual Xen, que hospeda um banco de dados MySQL local e também os índices do Lucene para esses dados. Os índices e o banco de dados são armazenados em RAID zero, e replicados via DRDB para outra VM, em uma máquina físia diferente, garantindo assim alta disponibilidade. Novos usuários são direcionados a um pool de servidores novos, e assim novos shards são adicionados a cada mês, para acomodar a população crescente de usuários do serviço.
O sucesso da abordagem tradicional e do MySQL em particular não significa que os desenvolvedores do Evernote deixem de considerar soluções NoSQL para outras áreas da empresa:
Nosso sistema de relatórios analíticos está próximo a superar a capacidade do seu atual banco MySQL. Ambos precisam ser substituídos por algo maior, mais rápido e mais moderno. Mas estamos satisfeitos com o uso de bancos MySQL particionados para o armazenamento de metadados de contas de usuários do Evernote, embora isso não nos traga prêmios em estilo e sofisticação.
Houve várias reações contrárias às ideias defendidas no post do Evernote, e também várias manifestações de apoio. Por exemplo, Alex Popescu, CTO do InfoQ/C4Media, chama a atenção para o fato de que a maioria das opções NoSQL atuais oferecem as garantias transacionais de Atomicidade, Consistência e Durabilidade, de modo que seriam adequadas ao cenário do Evernote sem perda de facilidade de programação nem de funcionalidades; mas reconhece que decisões técnicas nunca são simples e que ele precisaria ter acesso a detalhes sobre o caso do Evernote para dar um parecer mais embasado.
Já Rob Gonzalez da Cambridge Semantics, fornecedora de soluções para a web semântica, destaca que a falha da atual geração de bancos NoSQL, em fornecer níveis de confiabilidade e previsibilidade comparáveis aos bancos de dados relacionais, faz com que sua adoção em sistemas corporativos ainda seja mínima. Gonzalez afirma que o caminho para estes sistemas seria a persistência poliglota, com o uso de bases semânticas em cenários específicos, lado a lado e com soluções relacionais mais tradicionais.