Cientistas descobrem uma forma de armazenar dados que levam os desenvolvedores à loucura!

Os recursos mais interessantes dos provedores de Cloud no mercado, sem dúvida, são todos os tipos de Cloud Storage que você pode escolher e provisionar com alguns cliques. Neste post vou falar sobre o principal deles: Object Storage.

Francamente, o nome “Object Storage” não é amigável, e tampouco inspira algo moderno. Esse nome é nauseante, nauseabundo, nauseoso, ascoso, e todos os outros 28 sinônimos de repugnante. Se você ainda não conhece Object Storage, certamente é por causa do nome dele. Soa técnico demais, e excessivamente “coisa de infra”. Mas acredite, é “coisa de developer“.

Os nomes dos seus pares também não são dos melhores: diretórios e sistemas de arquivos [filesystems]. Esses nomes me lembram aquelas gavetas do meu escritório que abro uma vez a cada década. A verdade é que os nomes das coisas que referem-se às formas de persistência sempre me lembram armários, gavetas, pastas, baldes e caixas.

… de volta à dissertativa: há muitos anos, ou melhor, em todos os anos desde o início da era dos bancos de dados relacionais, quase TODAS as informações têm sido armazenadas em diretórios e sistemas de arquivos. Mas os anos passam, e alguém sempre inventa algo melhor. Continue lendo.

A Vida antes do Big Data

Antes de entrar no fantástico mundo do Object Storage, que apesar do nome, é realmente fantástico, tenho que desconstruir os filesystems. Rebaixá-los. É! Este post é propositalmente enviesado para enaltecer o poder do Object Storage em detrimento de outras formas de persistência mais convencionais. Desista aqui se não concorda.

Filesystems são ruins. Muito ruins. Eles são fixos. Têm limites. São cheios de regras. Não entendem HTTP, e pior: eles se falam por SAN e NAS [high-tech da época que seu pai ouvia Roupa Nova].

Filesystems são carentes de software inteligente e precisam de alguém para tomar conta – e fazer coisas totalmente zero business value: criar LUNs, formatar e montar discos, e configurar RAID.

Filesystems tornam-se naturalmente lentos enquanto crescem. Tento não acreditar que “ficar lento” faz parte da arquitetura deles, mas a verdade é que com o tempo eles ficam lentos por definição. Esse é o principal motivo pelo qual eles não suportam a escala da internet.

Explicando escala da internet: pense em uma Vespa. Sim, o inseto. Ela está parada, e de repente vai a 100 km/h, e para [freia no ar]. Depois ela faz uma curva de 90 graus, e acelera instantaneamente até 100 km/h de novo. De zero a 100 km/h em 0,00001 segundo. Agora ela faz outra curva de 90 graus sem parar, ignorando as forças da gravidade e da inércia. Agora troque a “Vespa” por “quantidade de usuários que acessam o seu sistema“. Pronto! Você já tem uma ideia do que é a escala da internet!

Obrigado Filesystems! Obrigado por nos ajudar no mundo dos megabytes e das coisas pequenas. Não nos veremos mais, pois agora as coisas são grandes demais pra vocês.

O Novo Centro do Universo

Há também aqueles que dizem que os bancos de dados também não suportam a escala da internet. Nenhum deles. Nécas. Nadicas. E isso inclui a maioria dos NoSQL. Sim, nem eles escapam.

O principal argumento é: dados não-estruturados [fotos, vídeos e textos] são complexos demais para os banco de dados. Se eu concordo? Em relação aos filesystems, sim, claro. Eles realmente não escalam. Mas e os bancos de dados? Prossiga na leitura.

Passaram por cima de todas as formas de persistência que existia, e criaram uma coisa que mais parece a pia da minha cozinha depois daquele almoço de domingo, e eles chamam de Object Storage. Agora esse treco é o centro do universo. Você coloca tudo lá, e ele se resolve [o Object Storage, não a pia da minha cozinha!].

Bom, mas e os bancos de dados?

O que diz minha chatbot Alexandra?

Fernando: Alexandra, o que você usava para armazenar os dados das suas aplicações web?
Alexandra: filesystems e bancos de dados.
Fernando: e o que você usa agora?
Alexandra: Object Storage.
Fernando: mas e o ACID, o 2-Phase Commit, a consistência forte, o teorema CAP que levei uma vida pra entender?
Alexandra: Não precisa.
Fernando: Precisamos ter uma conversa franca sobre coisas limitadas, a pia da minha cozinha, e a volta daqueles que não foram.

Uma Conversa Franca sobre Coisas Limitadas

Há dois tipos de filesystems: os tradicionais, e os que ainda não perderam as esperanças, mas todo mundo já sabe que eles já não têm mais futuro.

Os Filesystems Tradicionais

O primeiro são os filesystems tradicionais, baseados em SAN e NAS, que você provavelmente tem no seu data center on premise. Eles falham feio quando precisam escalar no nível da internet [Petabytes] – e se você acha que Petabyte é muito e nunca vai lhe atingir, lembre-se que há 20 anos um gigabyte era mais inimaginável do que você receber uma cesta de Lindt diretamente das mãos do Coelhinho da Páscoa, fora da Páscoa, no meio de deserto do Saara.

Filesystems precisam de uma tabela de lookup para localizar os arquivos. E essa tabela cresce. Imagine um banco de dados sem particionamento, compressão, paralelismo, índices… é isso. A tabela de lookup dos filesystems me lembra, carinhosamente, o DBU do Clipper.

Essas tabelas de lookup crescem até ao ponto que nada mais funciona. E então neste momento os administradores de storage fazem algo incrível:

Eles criam outra LUN.

Pense na LUN como a cauda de uma lagartixa. As lagartixas soltam sua cauda para confundir o predador e facilitar a fuga. Depois a cauda se regenera.

Quase a mesma coisa acontece com as LUNs. Quando a tabela de lookup fica grande, cria-se outra LUN para confundir o sistema operacional, deixando tudo mais rápido, mas depois a LUN cresce novamente e o processo se repete.

O grande problema é que as LUNs não fogem. Elas ficam lá para sempre e você tem que administrar! E quando você tem muitas LUNs e precisa dar um reboot no servidor, começa a ficar mais claro a definição de “anos-luz” que os cosmonautas usam para medir o tempo que leva para percorrer as viagens no espaço.

Por causa disso os filesystems tradicionais são os grandes perdedores na era do Big Data. Eles simplesmente não existem nesse mundo.

Os Filesystems Scale-Out

Hadoop Distributed Filesystem, HDFS, esse é o nome dele.

HDFS é independente de hardware. Os arquivos, cujos tamanhos não têm limite, são armazenados em blocos que se espalham entre vários discos do mesmo servidor, e entre discos de vários servidores. É scale-out afinal, isso já diz tudo: escala para os lados.

Ele parece melhor que os filesystems tradicionais, certo? Certo! Continue lendo.

HDFS resolve o problema de escalabilidade, mas … você precisa de um high-skilled high-salary high-high-high engenheiro de dados para mantê-lo no ar.

E complementado o “para mantê-lo no ar”: HDFS faz parte de um ecossistema que mais parece um zoológico composto por Zookeeper, Pig, Hive, Flume, HBase, YARN, Ambari … e o que mais mesmo ?! Divirta-se!

HDFS é muito labor-intensive. Sem falar na tripla redundância padrão que faz você gastar 3 PBytes para cada 1 PByte de dado útil. E você ainda acredita que esses filesystems são low cost porque, afinal de contas, o hardware é commodity, certo?

Risos.

HDFS é um filesystem em larga escala. Filesystem é um problema. Logo, HDFS é um problema em larga escala. HDFS é o máximo que se pode obter em larga escala de um filesystem no mundo on premise.

A nuvem chegou, e a festa vai começar. Não pare de ler.

A Pia da Minha Cozinha depois do Almoço

Nesta parte do texto meu objetivo é explicar para você, com um nível bastante aprofundado de detalhes, o que é Object Storage, e quais são seus benefícios.

Se você acha que um nível aprofundado de detalhes é como 100 páginas, esqueça!

Vou gastar um esforço colossal para tentar colocar 20 palavras numa frase. Não há muito segredo. Object Storage é simples por mais que eu tente criar alguma complexidade. Ele é flat, não tem diretórios ou hierarquias. Você coloca o arquivo lá, e ele vai. Você pede o arquivo, e ele vem.

Object Storage, um dos tipos de Cloud Storage, armazena porções de dados que podem ser identificadas individualmente. Essas porções podem ter metadados associados, e são acessados por meio de APIs. Os provedores de Cloud fazem a gestão do Object Storage, não você.

Arquivos nos filesystems são “objetos” no Object Storage.

O Object Storage também é composto por discos, como os filesystems, mas a diferença é que há “serviços” que fazem o gerenciamento dos arquivos, ao invés de deixar que essa gestão seja feita no nível do sistema operacional.

Esses serviços apresentam os discos como se fossem uma coisa só, formando uma camada de abstração maior, um pool. Cada arquivo que você coloca lá tem um ID, e é tudo que você precisa saber.

O Object Storage expõe seus objetos [arquivos] através de uma interface REST. Então você pode colocar ou recuperar arquivos usando o protocolo HTTP.

No exemplo abaixo eu faço três operações. Vou usar o curl [que é uma espécie de browser em formato texto] para executar operações HTTP:

curl -X PUT -H "X-Auth-Token: codigo_token" https://url/piaCozinha

curl -X PUT -H "X-Auth-Token: codigo_token" https://url/piaCozinha -T meuArquivo.txt

curl -X GET -H "X-Auth-Token: codigo_token" https://url/piaCozinha

Em todas as chamadas precisamos passar um token para segurança, que é gerado antes. E depois usamos comandos HTTP, como PUT, POST, DELETE e GET sobre uma URL [endpoint], que é fornecido pelo seu provedor de cloud para operar sobre um Object Storage.

Na linha 1 eu criei um container chamado piaCozinha, que é onde vão ficar meus arquivos [é como se fosse um diretório].

Na linha 3 eu coloquei um arquivo chamado meuArquivo.txt no container piaCozinha.

Na linha 5 eu busquei todos os arquivos no container piaCozinha, através da operação HTTP GET.

Simples, certo? Acredite, não tem mais nada.

Qual é o lado ruim e perverso desse tipo de persistência?  Imutabilidade [não pode alterar], e segue o AP do teorema CAP [disponibilidade e particionamento, e não consistência].

Como o caso de uso principal do Object Storage é armazenar dados não-transacionais, então esse lado perverso é menos perverso do que parece.

No final do dia, por causa das APIs, Object Storage significa que os desenvolvedores não precisam da benção do pessoal de infraestrutura para alocar mais espaço para a aplicação.

Está ficando quente. Continue lendo.

A Volta Daqueles que Não Foram

É inegável que SQL é a forma mais human-friendly para buscar qualquer coisa. Apache Hive sabe disso. Então melhor do que armazenar arquivos em Object Storage, é processá-los utilizando SQL.

Quais são os melhores engines de SQL? Os bancos de dados. 

Agora vai começar a era onde os bancos de dados processam os dados que armazenam, e também os dados que não armazenam.

Os bancos de dados se tornarão sistemas gerenciadores de dados, não importa onde os dados estejam.  E não estou falando de BLOBs. Estou falando de Object Storage, e em qualquer formato: Parquet, Avro, CSV ou whatever.

Eu tenho uma visão que o padrão do mercado será armazenar boa parte dos dados, não importa o formato, em Object Storage, e esses dados serão acessados nativamente com SQL por sistemas gerenciadores de dados.

Obrigado ecossistema Hadoop/HDFS! Obrigado por aumentarem um pouco a escala das coisas no mundo On Premise, mas no mundo Cloud é a vez dos Object Storages.