O Google, o Yahoo, a Amazon e algumas outras empresas têm desenvolvido ou estão utilizando soluções de Big Data e NoSQL, devido ao imenso volume de dados e processamento demandado. Mas tais implementações teriam alguma utilidade em cenários mais comuns? Em um artigo recente, Steve Jones indica que o Big Data não é a solução para todas as limitações de um modelo RDBMS convencional, que alguns acreditam ser:
Vejo muito oba-oba sobre Big Data no mercado. Mas algumas empresas estão olhando para essa explosão de volume como uma continuação da história, novas tecnologias, novas abordagens - mas como evolução e não revolução. Sim, o MapReduce é interessante, mas tecnicamente é mais complexo do que SQL e bancos relacionais. Está longe de ser uma panaceia.
Jones sugere que, logo, o armazenamento de banco de dados relacionais extensos em memória será um realidade. Ele ilustra isso fazendo referência a um artigo de alguns anos atrás, que discute como Yahoo usava uma implementação customizada do Postgres para armazenar 2 petabytes de dados:
Mais de 95% do Big Data vem do aumento exponencial de dados, o qual é compensado, ou pelo menos acompanhado, pelo aumento do poder de processamento e do volume de armazenamento. [...] Sim, a otimização de índices pode ser mais difícil e, sim, é possível mover dados para SSDs. Mas na verdade, tudo isso significa tamanhos maiores, e não uma mudança nos fundamentos.
Já ouvimos coisas semelhantes no passado, de pessoas como Mike Stonebraker, que indicou que muitos usuários se beneficiam de estratégias tais como a reestruturação de RDBMS e o armazenamento baseado em colunas, fazendo o máximo uso possível da memória principal e de discos SSD - tudo isso mantendo a tradicional consistência dos dados, a semântica ACID e em alguns casos o próprio SQL.
Steve Jones fala também do Map Reduce. Admite que o modelo por trás dessa implementação requer uma maneira diferente de pensar sobre a forma que são armazenados, consultados e manipulados os dados - o que torna difícil para os usuários o integrarem ao seu legado.
Da mesma forma que não há muitas pessoas que conseguem pensar de maneira multi-threaded, há poucos que conseguem pensar Map Reduce.
Então onde se encaixa o Big Data? O que deve ser levado em consideração ao adotar essas implementações? De acordo com Jones:
Vemos pessoas usando o Big Data da mesma forma que utilizavam SOA, colando um logotipo novo no produto e dizendo coisas como 'integração com Hadoop' ou 'integração com mídia social'.
Haveria o risco de ignorarmos a ideia principal por trás da necessidade de "novas soluções de dados", por causa de modismos e do exagero de fornecedores que marcam com selos de Big Data/NoSQL implementações que não atendem ao prometido?
Com que grau de certeza se pode dizer se o que precisamos é uma solução Big Data ou se estamos caindo numa armadilha? Sobre isso, Jones oferece sugestões para a avaliação de soluções de Big Data, incluindo:
- Se você pode substituir "Big Data" por "Big Database", então é apenas uma upgrade do produto.
- O "avanço" indicado pelo fornecedor pode ser entendido como "temos um conector EAI"?
- Trata-se basicamente do mesmo produto de 2009 mas com um selo "NoSQL/Big Data"?
- Existe algo que transfere o processamento para os dados em vez de simplesmente mudar a localização dos dados? Essa é uma sugestão que muitos fizeram no passado, incluindo Jim Grey.
Infelizmente nenhuma dessas "regras" é exata: elas têm certo nível de subjetividade. Existem outros critérios que poderiam ser utilizados? Se você migrou de uma solução RDBMS tradicional para uma alternativa diferente, quais foram os pontos para sua decisão e como selecionou a implementação mais adequada para realizar a migração?