Nos últimos anos, os dados tiveram um crescimento exponencial devido à evolução dos dispositivos conectados e à Internet das Coisas (IoT). Com isso vem uma alarmante taxa de expansão na quantidade de metadados, ou seja, dados que descrevem e fornecem informações sobre outros dados. Embora os metadados sempre existissem, eles costumavam ser armazenados na memória e nos bastidores, pois tinham uma fração do tamanho atual. 

Dez anos atrás, a proporção típica entre dados e metadados era de 1.000:1. Isso significa que uma unidade de dados (arquivo, bloco ou objeto) com tamanho de 32k teria metadados de cerca de 32 bytes. Os mecanismos de dados existentes foram capazes de lidar com essas quantidades de dados de forma bastante eficaz. Desde então, no entanto, a proporção mudou significativamente para metadados. A proporção agora pode variar de 1000:1 quando o tamanho do objeto é grande e 1:10 quando o objeto é muito pequeno. A explosão de metadados tem um impacto direto e imediato em nossas infraestruturas de dados.

A adoção massiva de aplicativos em nuvem e serviços de infraestrutura, juntamente com IoT, análise de big data e outras cargas de trabalho com uso intenso de dados, significa que os volumes de dados não estruturados continuarão a crescer nos próximos anos. As arquiteturas de dados atuais não podem mais atender às necessidades das empresas modernas. Para enfrentar o desafio cada vez maior dos metadados, precisamos de uma nova arquitetura para sustentar uma nova geração de mecanismos de dados que possam lidar efetivamente com o tsunami de metadados e, ao mesmo tempo, fornecer aos aplicativos acesso rápido a esses metadados. 

Entendendo os metadados: o assassino profissional do banco de dados

Todo sistema de banco de dados, seja SQL ou NoSQL, usa um mecanismo de armazenamento – ou mecanismo de dados – integrado ou não, para gerenciar como os dados são armazenados. Em nossa vida cotidiana, não prestamos muita atenção a esses motores que movem nosso mundo. Normalmente, só os notamos quando eles falham repentinamente. Da mesma forma, a maioria de nós nunca ouviu o termo “motor de dados” até recentemente. Eles executam nossos bancos de dados, sistemas de armazenamento e basicamente qualquer aplicativo que lide com uma grande quantidade de dados. Assim como o motor de um carro, só percebemos sua existência quando quebram. Afinal, não esperaríamos que um motor de carro sedan fosse capaz de operar um caminhão gigante. Em algum momento, provavelmente mais cedo ou mais tarde, ele vai quebrar sob a tensão. 

Então, o que está causando o aquecimento de nossos mecanismos de dados? A principal razão é o ritmo avassalador de crescimento de dados, especialmente em metadados, que é o assassino silencioso do mecanismo de dados. Metadados referem-se a qualquer informação sobre os dados — como índices, por exemplo — que facilita a localização e o trabalho com dados. Isso significa que os metadados não têm um esquema pré-fixado para caber em um banco de dados (que geralmente está em um formato de valor-chave); em vez disso, é uma descrição geral dos dados criados por vários sistemas e dispositivos. Esses dados, que precisam ser armazenados em algum lugar e geralmente ficam ocultos na memória RAM em cache, agora estão se tornando cada vez maiores.

Além do aumento contínuo no volume de dados não estruturados, como documentos e arquivos de áudio/vídeo, a rápida propagação de dispositivos conectados e sensores de IoT cria uma expansão de metadados que deve acelerar no futuro . Os dados em si são normalmente muito pequenos (por exemplo, uma leitura alfanumérica de um sensor), mas são acompanhados por grandes pedaços de metadados (local, carimbo de data/hora, descrição) que podem ser ainda maiores do que os próprios dados.

Os mecanismos de dados existentes são baseados em arquiteturas que não foram projetadas para dar suporte à escala de conjuntos de dados modernos. Eles são levados ao limite tentando acompanhar os volumes cada vez maiores de dados. Isso inclui armazenamentos de valores-chave baseados em SQL, dados de séries temporais e até mecanismos de dados não estruturados como o MongoDB . Todos eles usam um mecanismo de armazenamento subjacente (incorporado ou não) que não foi criado para oferecer suporte aos tamanhos de dados atuais. Agora que os metadados são muito maiores e “vazam” a memória, o acesso à mídia subjacente é muito mais lento e prejudica o desempenho. O impacto do impacto no desempenho do aplicativo é determinado diretamente pelo tamanho dos dados e pelo número de objetos. 

À medida que essa tendência continua a se desdobrar, os mecanismos de dados devem se adaptar para que possam suportar efetivamente as necessidades de processamento e gerenciamento de metadados das empresas modernas.

Sob o motor do mecanismo de dados

Instalado como uma camada de software entre o aplicativo e as camadas de armazenamento, um mecanismo de dados é um armazenamento de chave-valor (KVS) incorporado que classifica e indexa dados. Historicamente, os mecanismos de dados eram usados ​​principalmente para lidar com operações básicas de gerenciamento de armazenamento, principalmente para criar, ler, atualizar e excluir dados (CRUD). 

Hoje, o KVS é cada vez mais implementado como uma camada de software dentro do aplicativo para executar diferentes atividades on-the-fly em dados ao vivo enquanto estão em trânsito. Embora os mecanismos de dados existentes, como RocksDB, estejam sendo usados ​​para lidar com operações no aplicativo além do CRUD, eles ainda enfrentam limitações devido ao seu design. Esse tipo de implantação geralmente visa gerenciar cargas de trabalho com uso intensivo de metadados e evitar gargalos de acesso a metadados que podem levar a problemas de desempenho. Como o KVS está indo além de seu papel tradicional como mecanismo de armazenamento, o termo “motor de dados” está sendo usado para descrever um escopo mais amplo de casos de uso.

Os KVSs tradicionais são baseados em estruturas de dados otimizadas para velocidade de gravação rápida ou velocidade de leitura rápida. Para armazenar metadados na memória, os mecanismos de dados geralmente usam um KVS baseado em árvore de mesclagem estruturada em log (LSM). Um KVS baseado em árvore LSM tem uma vantagem sobre árvores B, outra estrutura de dados popular usada no KVS, porque pode armazenar dados muito rapidamente sem precisar fazer alterações na estrutura de dados graças ao uso de arquivos SST imutáveis. Embora as estruturas de dados KVS existentes possam ser ajustadas para velocidades de gravação e leitura suficientes, elas não podem fornecer alto desempenho para ambas as operações. 

Quando seu mecanismo de dados superaquece

À medida que os mecanismos de dados são cada vez mais usados ​​para processar e mapear trilhões de objetos, as limitações dos KVSs tradicionais se tornam aparentes. Apesar de oferecer mais flexibilidade e velocidade do que os bancos de dados relacionais tradicionais, um KVS baseado em LSM tem capacidade limitada e alta utilização de CPU e consumo de memória devido à alta amplificação de gravação, o que afeta seu desempenho de mídia de armazenamento de estado sólido. Os desenvolvedores terão que fazer trocas entre desempenho de gravação e leitura ou vice-versa. No entanto, configurar KVSs para atender a esses requisitos não será apenas uma tarefa contínua, mas também será desafiadora e trabalhosa devido à sua estrutura interna complexa.

Para manter as coisas funcionando, os desenvolvedores de aplicativos gastarão cada vez mais tempo lidando com fragmentação, ajuste de banco de dados e outras tarefas operacionais demoradas. Essas limitações forçarão muitas organizações que não possuem recursos de desenvolvedor adequados a usar configurações padrão que não atendem às necessidades dos mecanismos de dados.

Obviamente, esta abordagem não pode ser sustentada por muito tempo. Devido às deficiências inerentes das ofertas existentes de KVS, os mecanismos de dados disponíveis atualmente

Uma nova arquitetura de dados

Reconhecer os problemas que os metadados geram e as limitações nos atuais mecanismos de dados é o que nos levou a fundar o Speedb, o mecanismo de dados que fornece desempenho mais rápido em escala. Meus cofundadores e eu reconhecemos as limitações das arquiteturas de dados atuais. Decidimos desenvolver um novo mecanismo de dados construído do zero para lidar com a disseminação de metadados que eliminaria as compensações entre escalabilidade, desempenho e custo, proporcionando velocidades superiores de leitura e gravação. 

Para isso, redesenhamos os componentes básicos do KVS. Desenvolvemos um novo método de compactação que reduz drasticamente a amplificação de gravação para LSM de grande escala; um novo mecanismo de controle de fluxo para eliminar picos de latência do usuário; e um índice probabilístico que consome menos de três bytes por objeto, independentemente do objeto e do tamanho da chave, oferecendo desempenho extremo em escala. Speedb é uma solução incorporável drop-in compatível com mecanismos de armazenamento RocksDB que pode atender à crescente demanda por alto desempenho em escala de nuvem. O crescimento dos metadados não está diminuindo, mas com essa nova arquitetura, pelo menos conseguiremos acompanhar a demanda.