Se as tecnologias de banco de dados oferecessem desempenho, flexibilidade e segurança, a maioria dos profissionais ficaria feliz em obter duas das três, e talvez também esperassem aceitar alguns compromissos. Sistemas otimizados para velocidade exigem ajuste manual, enquanto plataformas flexíveis podem impor custos quando os projetos iniciais se tornam restrições. Infelizmente, às vezes, a segurança é um complemento, com os DBAs contando com as habilidades e o conhecimento das equipes internas para não introduzir alterações significativas.
RavenDB, no entanto, existe porque seu fundador viu os custos cumulativos dessas compensações comuns e os problemas inerentes delas decorrentes. Eles queriam um sistema de banco de dados que não obrigasse os desenvolvedores e administradores a escolherem.
Abstraindo a complexidade
Oren Eini, fundador e CTO do RavenDB, trabalhava como consultor freelance de desempenho de banco de dados há quase duas décadas. Numa entrevista exclusiva, ele contou como encontrou muitas equipes capazes “se enterrando em um buraco” à medida que os sistemas sob seus cuidados cresciam em complexidade. Os problemas que lhe foram apresentados não decorriam de desenvolvedores que não possuíam as habilidades necessárias, mas sim da arquitetura do sistema. Os bancos de dados tendem a orientar seus desenvolvedores para designs frágeis e punir os desenvolvedores por seguirem esses caminhos, diz ele. RavenDB foi um projeto que começou como uma forma de reduzir o atrito quando a força imparável do que é necessário encontra a montanha de esquemas de banco de dados.
A ênfase da plataforma está no desempenho e na adaptabilidade sem (ironicamente) em algum momento exigir os serviços de pessoas como Oren. Armado com uma bagagem cheia de experiência e conhecimento, ele formou o RavenDB, que já existe há mais de quinze anos – muito antes do atual interesse no desenvolvimento assistido por IA.
O resultado final é que, com o tempo, o banco de dados RavenDB se adapta ao que interessa à organização, em vez de ao que ela imaginou que poderia se importar quando o banco de dados foi criado pela primeira vez. “Quando converso com empresários”, diz Eini, “digo-lhes que cuido da complexidade da propriedade dos dados”.
Por exemplo, em vez de esperar que os desenvolvedores ou DBAs antecipem todos os padrões de consulta possíveis, o RavenDB observa as consultas à medida que são executadas. Se detectar que uma consulta se beneficiaria de um índice, ele criará um em segundo plano, com sobrecarga mínima no processamento existente. Isto contrasta com a maioria dos bancos de dados relacionais, onde o esquema e as estratégias de indexação são definidos pelos desenvolvedores iniciais, por isso são difíceis de alterar posteriormente, independentemente de como uma organização possa ter mudado.
Oren faz a comparação com a concretagem das fundações de um edifício antes de decidir onde as portas e colunas de suporte podem ficar. É uma abordagem que pode trabalho, mas quando o negócio muda de direção ao longo dos anos, o custo de se arrepender dessas decisões iniciais pode ser alarmante.
Falando antes da aparição da empresa no próximo evento TechEx Global em Londres este ano (4 e 5 de fevereiro, Olympia), ele citou o exemplo de um cliente europeu que lutou para se expandir para os mercados dos EUA porque seu banco de dados presumia uma taxa de IVA simples que havia relegado a um único campo, um esquema não adequado para as complexidades dos impostos estaduais e federais sobre vendas. A partir de decisões aparentemente simples tomadas no passado (e talvez sem muita reflexão – o IVA europeu é bastante normal), o cliente estava a acumular dificuldades financeiras e dívidas técnicas para a próxima geração.
Grande parte da atratividade do RavenDB se manifesta em detalhes práticos e pequenos ajustes que tornam os bancos de dados com melhor desempenho e mais fáceis de lidar. A paginação, por exemplo, requer duas chamadas de banco de dados na maioria dos sistemas (uma para buscar uma página de resultados, outra para contar registros correspondentes). RavenDB retorna ambos em uma única consulta. Individualmente, essas otimizações podem parecer pequenas, mas em escala elas aumentam. Oren diz. “Se você suavizar o atrito onde quer que vá, terá um sistema realmente bom, onde não precisa lidar com o atrito.”
A remoção combinada de atritos melhora o desempenho e simplifica o trabalho dos desenvolvedores. Os dados relacionados são incorporados ou incluídos sem as penalidades associadas às junções de tabelas em bancos de dados relacionais, de modo que consultas complexas são concluídas em uma única viagem de ida e volta. Os engenheiros de software não precisam ser especialistas em bancos de dados. Em seu mundo, eles apenas formulam consultas semelhantes a SQL para as APIs do RavenDB.
Em comparação com outros bancos de dados NoSQL, o Raven DB fornece transações ACID completas por padrão e complexidade operacional reduzida: muitos de seus recursos integrados (pipelines ETL, assinaturas, pesquisa de texto completo, contadores, séries temporais, etc.) reduzem a necessidade de sistemas externos.
Em contraste com os DBAs e desenvolvedores de software que abordam um sistema de banco de dados concorrente e seus complementos necessários, tanto os desenvolvedores quanto os administradores gastam menos tempo se preocupando com os detalhes com o Raven DB. Isso é uma boa notícia, principalmente para aqueles que controlam os recursos financeiros de uma organização.
Dimensionando para se adequar ao propósito
RavenDB também foi desenvolvido para escalar, de forma tão fácil quanto lida com consultas complexas. Ele pode criar clusters de vários nós, se desejado, para suportar um grande número de usuários simultâneos. Esses clusters são criados pelo RavenDB sem configuração manual demorada. “Com RavenDB, esse é o custo normal dos negócios”, diz ele.
Em fevereiro deste ano, RavenDB Cloud anunciou a versão 7.2, e sendo 2026, é preciso mencionar a IA. O AI Assistant do Raven DB é, “na verdade, (…) um DBA virtual que vem dentro do seu banco de dados”, diz ele. A palavra-chave é dentro. Ele foi projetado para desenvolvedores e administradores, e não para usuários finais, respondendo às suas perguntas sobre indexação, uso de armazenamento ou comportamento do sistema.
IA como ferramenta profissional
Ele é cético quanto a dar às IAs acesso irrestrito a qualquer armazenamento de dados. Permitir que uma IA atue como um guardião genérico de informações confidenciais cria riscos de segurança inevitáveis, porque tais sistemas são difíceis de restringir de forma confiável.
Para o DBA e desenvolvedor de software, é outra história – a IA é uma ferramenta útil que funciona como uma mão amiga, configurando e tratando os dados. O assistente de IA do RavenDB herda as permissões do usuário que o invoca, não tendo acesso privilegiado próprio. “Qualquer coisa que ele saiba sobre sua instância RavenDB vem porque, nos bastidores, ele está acessando seu sistema com suas permissões”, diz ele.
A estratégia de IA da empresa é fornecer aos desenvolvedores e administradores recursos opinativos: geração de consultas, explicação de índices, ajuda na exploração de esquemas e resposta a perguntas operacionais, com chamadas limitadas por validação e privilégios do operador.
As equipes que desenvolvem aplicativos com RavenDB obtêm suporte para pesquisa vetorial, incorporações nativas, indexação no servidor e integração agnóstica com LLMs externos. Isso, diz Oren, permite que as organizações forneçam recursos úteis baseados em IA em seus aplicativos rapidamente, sem expor o negócio a riscos e problemas de conformidade.
Segurança e risco
Segurança e risco constituem uma daquelas áreas onde RavenDB traça uma linha clara entre ele e seus concorrentes. Abordamos a recente vulnerabilidade MongoBleed, que expôs dados de instâncias não autenticadas do MongoDB devido a uma interação entre compactação e código de autenticação. Oren descreve o problema como uma falha arquitetônica causada pela mistura de caminhos de código de uso geral e de segurança crítica. “A razão pela qual isso é uma vulnerabilidade”, diz ele, “é especificamente o fato de que você está tentando misturar preocupações”.
RavenDB usa infraestrutura criptográfica estabelecida para lidar com a autenticação antes que qualquer lógica de banco de dados seja invocada. E mesmo que uma falha viesse de outro lugar, a superfície de ataque seria significativamente menor porque os usuários não autenticados nunca alcançam os caminhos gerais do código: essa separação arquitetônica limita o raio de explosão.
Embora os componentes internos do RavenDB sejam altamente técnicos e especializados, os tomadores de decisão de negócios podem facilmente perceber que atrasos causados por alterações de esquema, ajuste de desempenho ou alterações de infraestrutura terão um impacto econômico significativo. Mas a maleabilidade e a velocidade do RavenDB também eliminam o que Oren descreve como conversas do tipo “não, você não pode fazer isso”.
As organizações que executam o RavenDB reduzem sua dependência de conhecimentos especializados, além de obterem a capacidade de responder às mudanças nas necessidades de negócios com muito mais rapidez. “O papel (do banco de dados) é trazer valor real ao negócio”, diz Eini, argumentando que a infraestrutura deveria, em contextos operacionais, ficar em segundo plano. Tal como está, muitas vezes determina o âmbito das discussões estratégicas.
Migração e primeiros passos
RavenDB usa uma linguagem de consulta familiar semelhante a SQL, e a maioria das equipes precisará de apenas um dia, no máximo, para se atualizar. Onde o atrito aparece, sugere Oren, muitas vezes é devido a suposições herdadas de outras plataformas em torno de segurança e alta disponibilidade. Para RavenDB, eles estão integrados ao design, portanto, não causam carga de trabalho extra que precisa ser levada em consideração.
Surgindo como resultado da experiência de dificuldades operacionais do próprio fundador da empresa, a diferença do RavenDB decorre de decisões de design acumuladas: indexação em segundo plano, otimização consciente de consultas, separação de questões de segurança e autenticação e, ultimamente, a necessidade de restrições nas ferramentas de IA. No uso diário, os desenvolvedores experimentam menos arestas vivas e, no longo prazo, os líderes empresariais observam uma redução nos custos, especialmente em tempos de mudança. A combinação é suficientemente convincente para substituir plataformas consolidadas em muitos contextos.
Para saber mais, você pode falar com representantes da RavenDB na TechEx Global, realizada em Olympia, Londres, nos dias 4 e 5 de fevereiro. Se o que você leu aqui despertou seu interesse, acesse o site da empresa.
(Fonte da imagem: “#316 AVZ Database” de Ralf Appelt está licenciado sob CC BY-NC-SA 2.0.)
Quer saber mais sobre IA e big data dos líderes do setor? Confira a AI & Big Data Expo que acontece em Amsterdã, Califórnia e Londres. O evento abrangente faz parte da TechEx e é realizado junto com outros eventos de tecnologia líderes. Clique aqui para mais informações.
AI News é desenvolvido pela TechForge Media. Explore outros eventos e webinars de tecnologia empresarial futuros aqui.
Fontesartificialintelligence
