top of page

Onde devo colocar meus dados?

Um mundo orientado por dados, com quantidades cada vez maiores de dados, selecionar a tecnologia de banco de dados correta pode ser a chave para o sucesso.



Antes que você comece:


Você pode ter uma ideia de mudança de mundo em sua cabeça, mas o primeiro passo para realmente sair da prancheta envolverá uma variedade estonteante de escolhas. Você deve descobrir a pilha de tecnologia, o plano de negócios certo, uma estratégia de marketing e um programa de incentivos de vendas, para listar apenas alguns itens.

Você também precisará escolher a tecnologia de banco de dados que servirá de base para seu novo projeto. Embora não possa ajudá-lo com tudo na lista acima, posso fornecer informações para orientar seu processo de seleção em relação aos bancos de dados.

Vivemos em um mundo orientado por dados, onde seus dados costumam ser muito mais valiosos do que qualquer outra coisa no negócio. No entanto, fazer bom uso dos dados pode ser um grande desafio. E o tipo de banco de dados que você emprega pode afetar muito sua velocidade e capacidade de adaptação às suas necessidades.

Henry Ford disse a famosa frase que você pode ter um carro da cor que quiser, desde que seja preto. O mesmo costumava acontecer com os bancos de dados. Costumava ser simples. Sua escolha de banco de dados foi entre diferentes  fornecedores , todos eles fornecendo um banco de dados relacional usando um dialeto SQL. A escolha foi principalmente sobre recursos específicos, considerações de licenciamento e acordos de suporte.

Então surgiu a Internet, e a quantidade de dados que mantemos e as formas como trabalhamos com eles simplesmente explodiram. Os bancos de dados relacionais tiveram um grande problema de adaptação a um ambiente distribuído com as novas demandas de escalabilidade.

A necessidade de processar quantidades cada vez maiores de dados em maior velocidade levou ao desenvolvimento de novos mecanismos e abordagens de banco de dados. Eles abandonaram o modelo relacional porque muitas vezes ele não conseguia gerenciar a escala necessária e acabamos com muitas opções de tecnologia de banco de dados.

Neste artigo, tentarei entender as diversas opções e dar algumas dicas sobre como você pode selecionar a tecnologia de banco de dados apropriada para suas necessidades.


Restrições Relacionais:


Os bancos de dados relacionais são modelados usando alguns conceitos básicos. Tabelas e linhas estão no centro do modelo relacional. Você pode  JOIN  dados de tabelas diferentes quando precisar de estruturas mais complexas. Você pode definir esquemas e restrições para garantir que seus dados façam sentido e usar transações para garantir a consistência geral.

Este é um ótimo modelo e tem sido um grande sucesso. Na verdade, as guerras de bancos de dados da década de 1980 foram decididas conclusivamente em favor dos bancos de dados relacionais. Acontece que as necessidades da década de 2000 expuseram diversas limitações na forma como os bancos de dados relacionais podem ser usados. Esses limites tornaram-se evidentes quando o tamanho dos dados e o número de transações dispararam à medida que todos os aspectos das nossas vidas se tornaram digitais.


Um esquema rígido é excelente para consistência, mas também atua como uma barreira significativa à mudança quando você precisa modificar seu sistema para atender a requisitos adicionais. Tentar lidar com dados dinâmicos ou gerados pelo usuário em um banco de dados relacional é uma receita bem conhecida para problemas, consultas lentas e muita complexidade.

O modelo relacional também contém uma suposição oculta: você pode acessar todo o conjunto de dados a qualquer momento. Essa suposição foi violada quando o tamanho dos nossos conjuntos de dados excedeu a quantidade de dados que caberia em uma única máquina.

Considere o cenário simples de garantir que o campo Email seja exclusivo para todos os usuários no banco de dados. Se você dividir seus usuários entre vários servidores, como poderá garantir que não estará criando entradas duplicadas? As coisas ficam muito mais difíceis quando você adiciona falhas e como lidar com elas à mistura.


Existem soluções para esse tipo de questão, mas são um pouco mais complicadas do que simplesmente marcar o campo como ÚNICO, como você costumava fazer. Na verdade, essas soluções muitas vezes exigiam que você tivesse um doutorado. nível de compreensão em aspectos internos de banco de dados e teoria de sistemas distribuídos. Independentemente da solução escolhida, uma coisa ficou clara: ela estava muito longe de ser um banco de dados relacional clássico.


Afastar-nos dos bancos de dados relacionais significou que tivemos que abrir mão de alguns dos recursos considerados padrão no setor, como esquemas ou transações. Isso também significou que tivemos oportunidades de adaptar nossos mecanismos de banco de dados para melhor se adequarem às práticas modernas. A era dos bancos de dados NoSQL começou com um número absolutamente impressionante de opções e escolhas.


A próxima década foi sobre consolidação e descoberta de quais recursos beneficiam nossos sistemas. As transações, que foram descartadas logo no início (é  complicado  fazê-las funcionar em um ambiente distribuído), voltaram com tudo. Afinal, ninguém queria realmente viver em um mundo não transacional. A vantagem é que agora temos soluções de banco de dados maduras e abrangentes que não estão limitadas à mentalidade relacional.


Essas soluções de banco de dados podem ser utilizadas de forma eficaz para acelerar significativamente a construção de aplicativos e sistemas não triviais, uma vez que são explicitamente voltadas para isso. No restante deste artigo, tentarei fornecer informações básicas e detalhes específicos sobre o motivo disso.


Dossiês de Bancos de Dados:


Além dos bancos de dados relacionais, existem algumas opções. Existem bancos de dados de documentos onde você modela os dados usando documentos JSON. Existem bancos de dados gráficos nos quais tudo é um nó ou uma aresta, e os relacionamentos entre os nós são fundamentais. Existem bancos de dados de famílias de colunas focados no gerenciamento de petabytes de informações com velocidades razoáveis. Existem bases de dados de valores-chave que simplificam ao máximo o seu modelo interno para obter um melhor desempenho.


Como mencionei, o mundo dos bancos de dados é vasto (e profundo) e suas necessidades variam dependendo dos seus objetivos. Presumo que você esteja interessado em construir um aplicativo de negócios, o pão com manteiga do nosso setor. Vou usar o aluguel de veículos como exemplo para este artigo. Provavelmente é uma área com a qual você está pelo menos familiarizado e que tem complexidade suficiente para ir além do básico.


A primeira escolha que devemos fazer é considerar qual banco de dados utilizar para nosso projeto de aluguel de veículos. Vamos considerar as opções. Os bancos de dados relacionais costumavam ser o padrão (e a única opção), portanto, deixaremos essa opção de lado e consideraremos primeiro os bancos de dados não relacionais e depois os compararemos com a opção relacional.


Um banco de dados de valores-chave permite armazenar e recuperar dados por chave. Os dados podem ser apenas binários ou ter significado, como uma lista de itens. Construir aplicativos com base nesse modelo é complexo, pois você não tem a capacidade de consultar dados; você só pode buscar por uma chave conhecida. Esses bancos de dados geralmente implementam recursos como carrinhos de compras ou armazenamento de dados de sessão. Eles raramente são usados como banco de dados primário de um aplicativo.


Um banco de dados de documentos lida com documentos. Não arquivos Word ou Excel, mas documentos no sentido de modelagem. Seus dados são um documento JSON, que pode ser arbitrariamente complexo e extenso. Os bancos de dados de documentos permitem consultar os dados e não impõem restrições à sua forma e operações. Eles são adequados para aplicativos de negócios e cenários OLTP.


Bancos de dados gráficos são normalmente utilizados quando a necessidade principal é algum tipo de operação gráfica, seja um mecanismo de recomendação, redes sociais ou encontrar o caminho mais curto para uma viagem. Eles normalmente são usados em conjunto com outro banco de dados e raramente são empregados como sistema de registro.


Os bancos de dados de família de colunas são focados no gerenciamento de quantidades estupendas de dados. Eles modelam seus dados em tabelas e colunas, mas as colunas podem conter listas de valores e as consultas sempre seguem a chave primária. Todo o sistema é construído em torno da restrição de trabalhar em um ambiente distribuído. Essa é ao mesmo tempo a sua vantagem mais significativa e o seu obstáculo mais irritante. A menos que você espere lidar com conjuntos de dados que excedem a marca de 100 TB, não recomendo escolher esta opção.


Para quase todas as aplicações de negócios (OLTP – Online Transaction Processing), eu recomendaria um banco de dados de documentos como a escolha mais adequada para seu banco de dados. Das opções que exploramos até agora, é de longe a mais adequada. No entanto, ainda há um concorrente que não abordamos. Como um banco de dados de documentos se compararia a um banco de dados relacional para necessidades de aplicativos de negócios?


Documento/Dilema Relacional:


Há algum tempo, o termo du-jour era sistemas baseados em dados. Provavelmente estou namorando porque isso foi há mais de 25 anos. Essa foi a época em que tudo começou a se tornar digital e a rápida disponibilidade de dados transformou o nosso mundo. Considere a aplicação típica daquela época. Você ainda pode encontrá-los; os sistemas de reserva de companhias aéreas ainda funcionam nos mesmos terminais de linha de comando, por exemplo.


O nível de complexidade e sofisticação que exigimos hoje dos nossos sistemas, em comparação com o que era exigido das aplicações do passado, é vasto. No entanto, os bancos de dados que usamos para esses sistemas são os mesmos bancos de dados relacionais que temos hoje.


Conceitualmente, pouco mudou nos bancos de dados relacionais desde aquela época. Mas que tipos de sistemas construímos? Eles são drasticamente diferentes.


Considere o aspecto do modelo de dados no cenário de aluguel de veículos. Em um banco de dados relacional, você teria tabelas para Veículo, Cliente e Aluguel. Aplicar isso a cenários de aluguel é bastante simples e óbvio.


Até você perceber que este é um modelo altamente simplificado das reais necessidades do negócio. Concentrando-se apenas no aspecto de aluguel do negócio, você espera poder selecionar o tipo específico de carro e seus recursos, bem como qualquer número de complementos (como uma cadeirinha de bebê ou um GPS). No contrato de locação, além do período em que você alugará o carro, há muitos tipos adicionais de informações que você precisa acompanhar, desde os motoristas permitidos no veículo até o tipo de seguro selecionado, a estratégia de combustível, etc. Os pagamentos podem ser feitos com cartão de crédito ou dinheiro, ou vários cartões de crédito. Quando você começa a observar o  modelo real  com o qual precisa lidar, o número de entidades e tabelas explode. Isso tem um impacto significativo na arquitetura e no comportamento geral do seu sistema.


O interessante disso é que há 30 anos isso não teria sido um problema. Não existia  o conceito  de tentar gerenciar tudo em um sistema. Os recursos que você obteve com a digitalização do seu sistema foram limitados em comparação com o que esperamos hoje. Principalmente devido às capacidades dos sistemas disponíveis na época.


Como um banco de dados de documentos resolveria esses problemas? O que tornaria mais simples construir sistemas modernos complexos usando um banco de dados de documentos em vez de um banco de dados relacional?


A resposta começa com os diferentes modelos. Em um banco de dados relacional, entidades complexas são unidas usando diversas tabelas, junções e consultas complicadas. Por outro lado, um banco de dados de documentos permite expressar uma entidade complexa diretamente como um único documento.


Considere o contrato de aluguel que você assinou quando aceitou o carro. Tem muitas cláusulas e opções. Quase cada um deles exigiria a criação de uma tabela adicional para ser unida em um sistema relacional. Numa base de dados documental, podemos representar aquele contrato de aluguer, com toda a sua complexidade, como um único documento.


Fornecerei exemplos específicos para facilitar a compreensão da distinção entre bancos de dados relacionais e de documentos.


Lidando com dados emaranhados:


Considere o painel de um agente de aluguel de veículos. Eles possuem um painel dos veículos do estacionamento, mostrando quais estão disponíveis. O problema é que para realmente mostrar informações úteis, é preciso encontrar os veículos que estão localizados no estacionamento. Isso é bastante fácil, mas agora você precisa verificar o status de manutenção e o nível de combustível de cada um deles (para saber quais estão disponíveis para aluguel).


De longe, a maneira mais comum de lidar com isso é emitir uma consulta separada para cada veículo disponível para verificar seu status. Se tiver 50 veículos disponíveis, você emitirá uma consulta para obter os veículos disponíveis e, em seguida, 50 consultas separadas para cada um deles.


Isso é extremamente ineficiente, mas é comum devido à forma como a API é exposta ao aplicativo. Você tem uma consulta para carregar os veículos disponíveis e outro método para carregar seu status. Outro motivo comum para isso é o uso de ferramentas OR/M, como Hibernate ou Entity Framework.


Você pode usar consultas mais complexas para juntar os dados, é claro, mas isso só leva você até certo ponto. Unir dados de múltiplas tabelas representa um risco para um produto cartesiano e, mesmo sem ele, pode aumentar bastante a quantidade de dados que o banco de dados relacional precisa processar.


Um banco de dados de documentos, por outro lado, permite uma modelagem mais eficiente desses dados. Um documento nesse banco de dados permite armazenar informações complexas em um único local. Esse recurso permite recuperar todos os dados relacionados como uma única consulta sem precisar lidar com diversas consultas ou junções complexas.


Além disso, os bancos de dados de documentos não estão limitados ao modelo relacional. O tratamento de relações em um banco de dados de documentos não exige que você lide com um produto cartesiano. Você pode solicitar que o banco de dados forneça os resultados da consulta e os dados relacionados em uma única chamada remota, sem complicações.


Isso parece algo pequeno, mas tem um impacto enorme tanto no tempo de desenvolvimento quanto nos custos de execução. O número reduzido de consultas não só melhora a eficiência, mas também reduz bastante a latência do sistema – o tempo gasto no processamento de suas solicitações. Essa é uma métrica chave tanto na usabilidade quanto nas conversões de vendas.


Ao usar RavenDB, você tem a liberdade de modelar seus dados como achar melhor, incluindo trabalhar com objetos complexos e gráficos de objetos. Você não está limitado apenas a documentos únicos, mas também pode trabalhar com relações entre documentos.


Em particular, você pode  incluir  documentos relacionados em uma consulta, o que significa que, além dos documentos correspondentes resultantes, o RavenDB buscará os documentos relacionados como parte do processamento da consulta em uma única chamada remota.


Alternativamente, você pode  carregar  dados de documentos relacionados durante a consulta, projetando apenas as partes dos documentos e suas relações que são importantes para você.


Dimensionamento e gerenciamento contínuos de alta disponibilidade


Um dos maiores desafios ao projetar sua solução de banco de dados em escala é atender à necessidade de gerenciar um grande número de solicitações e garantir a disponibilidade durante falhas.


Os bancos de dados relacionais geralmente requerem assistência externa para lidar com esse requisito. É comum ter um nó primário que aceita gravações e nós secundários que servem como réplicas de leitura. O problema é que esta configuração é  complexa  e  frágil . Por exemplo, a  interrupção do GitHub em 2018  está diretamente ligada a uma falha transitória de um roteador (com duração de menos de um minuto) que derrubou o GitHub por mais de um dia.


A causa subjacente foi o tratamento inadequado de cenários de falha ao usar um banco de dados relacional em um ambiente distribuído. A questão principal é que os bancos de dados relacionais nunca foram projetados desde o início para ambientes distribuídos e implantá-los com sucesso é uma tarefa complicada e fácil de errar.


Os bancos de dados de documentos destinam-se universalmente ao uso em um ambiente distribuído. Dessa forma, cenários como escalabilidade, balanceamento de carga e failover automático fazem parte do conjunto principal de recursos do banco de dados.


RavenDB segue o modelo de nós ativos-ativos. Em um cluster de servidores, qualquer nó do cluster pode aceitar uma gravação, embora geralmente um único nó seja designado como primário. Isso garante que, enquanto pelo menos um nó estiver operando, seu sistema poderá continuar funcionando. Durante as operações normais, você pode exigir que as leituras vão do nó primário, de um nó secundário ou do nó mais próximo do cliente.


Para modos de falha, RavenDB segue o ditado de que tudo deveria funcionar. Um nó inativo não deve derrubar seu sistema. Você também não deve exigir nenhuma configuração ou configuração especial para garantir alta disponibilidade. A simples configuração de um cluster RavenDB garante failover automático, com clientes e servidores cooperando perfeitamente para manter a funcionalidade do seu sistema.




O triunfo das transações:


Anteriormente neste artigo, mencionei que uma das coisas das quais os primeiros bancos de dados não relacionais desistiram foram as transações. Não consigo expressar verdadeiramente o quão horrorizado fiquei quando soube que esse era o caso.


Os princípios de transações e ACID são a base para manter a consistência nos bancos de dados. RavenDB, como um banco de dados não relacional, se diferencia por fornecer suporte completo a transações desde o seu início.


Os últimos anos mostraram como isso é importante, já que a grande maioria dos bancos de dados não relacionais agora suportam transações. No entanto, existe uma diferença distinta no nível de apoio entre os diferentes produtos. Por exemplo, embora o MongoDB e o Couchbase suportem transações, habilitá-los requer uma análise caso a caso e tem um custo alto.


O RavenDB, por outro lado, é sempre transacional e tem desempenho suficiente para competir da melhor forma com outros bancos de dados, sem comprometer seus dados.


Como o RavenDB se compara aos bancos de dados relacionais no que diz respeito às transações? Acontece que há uma diferença muito importante na maneira como os bancos de dados relacionais e o RavenDB implementam transações. Um banco de dados relacional usando SQL precisa processar cada operação na transação individualmente, geralmente confirmando o sucesso ou falha de cada comando para o cliente antes de aceitar o próximo comando na transação.


RavenDB, por outro lado, usa um protocolo diferente. Todo o conjunto de comandos é enviado ao banco de dados em uma única unidade, o que dá ao RavenDB uma grande vantagem em desempenho, latência e oportunidades de otimização. Em vez de ir e voltar entre cliente e servidor, uma única chamada remota é suficiente para processar toda a transação.


Ter toda a transação para processar de uma só vez também tem outro impacto no design do RavenDB. Isso significa que o mecanismo de banco de dados não precisa gerenciar bloqueios no mesmo nível que um banco de dados relacional faria. O gerenciamento de bloqueios pode consumir  mais de 30% do tempo total que um banco de dados relacional gasta processando solicitações. RavenDB pode eliminar totalmente todos esses custos, sem comprometer a segurança.




Lidando com dados dinâmicos


Os bancos de dados relacionais operam sobre um esquema fixo, o que é ótimo se o seu modelo for bem conhecido e não mudar. Na prática, muitas vezes você precisa evoluir seu modelo ao longo do tempo e frequentemente precisa lidar com dados dinâmicos e definidos pelo usuário. A evolução do esquema em um banco de dados relacional é um processo complexo e delicado, o suficiente para que  livros inteiros sejam escritos sobre ele.


Os bancos de dados de documentos não têm esquema, o que significa que você não precisa realizar ações especiais para evoluir seu modelo. Trabalhar com dados dinâmicos e definidos pelo usuário é muito fácil (incluindo consultas em dados dinâmicos, tradicionalmente um processo complexo e lento).


Os bancos de dados de documentos exigem mais sobrecarga do que os bancos de dados relacionais por registro (uma vez que não podem assumir um esquema e precisam manter metadados por registro em vez de por tabela). Isso geralmente pode ser mitigado usando o uso de compactação.


O fato de cada documento do banco de dados ser independente significa que você também pode evoluir seus documentos ao longo do tempo. Você não precisa ter um grande momento em que converte todos os seus dados para um novo formato. Isto é particularmente importante se você adota métodos ágeis e deseja fazer pequenas mudanças continuamente ao longo do tempo, em vez de ser forçado a fazer o que é efetivamente uma mudança de paradigma sempre que precisar atualizar a estrutura de suas entidades.


O simples fato de adicionar ou remover um campo não ser um processo doloroso significa que sua equipe de desenvolvimento não precisa lutar para fazer alterações em seu aplicativo, levando a um rápido desenvolvimento e melhoria.


No RavenDB, o banco de dados pode derivar um dicionário de compactação dos dados reais que você está armazenando. Isso significa que o banco de dados pode compactar documentos individuais muito bem (removendo efetivamente os custos de metadados por documento), mantendo ao mesmo tempo a capacidade de trabalhar com formato sem esquema.


A compactação geralmente é considerada cara devido ao cálculo adicional necessário, mas acaba sendo um resultado positivo no mundo real. A redução nos custos de E/S obtida com a redução de 50% a 70% no armazenamento que a compactação de documentos traz mais do que compensa os custos de compactação.


Diversificação de Documentos:


Os documentos são uma ótima opção para aplicativos de negócios. Isso ocorre principalmente porque geralmente você pode desenhar um mapeamento 1:1 entre os formulários e documentos reais que administram o negócio e suas entidades no modelo de banco de dados. Esse alinhamento da forma como o negócio pensa seus processos e a forma como o banco de dados os armazena tem muito valor.


Os documentos não são a única coisa com a qual você lidará na maioria dos aplicativos, e os bancos de dados de documentos não estão limitados  apenas  a dados JSON. Dados binários, como imagens, documentos do Office e arquivos de áudio e vídeo, são todos dados que você normalmente precisa manipular.


Armazená-los como documentos seria abaixo do ideal. Felizmente, você não é forçado a fazer isso; você pode armazenar dados e arquivos binários diretamente em um banco de dados de documentos. No MongoDB, isso é chamado de GridFS, enquanto o RavenDB permite usar Anexos, que são dados binários anexados a documentos e armazenados junto com eles. Isso oferece uma maneira eficiente de lidar com dados binários.


Observe que os anexos são armazenados como estão, sem compactação. Os tipos de arquivos mais comuns já incluem compactação, portanto, tentar compactar arquivos já compactados é um desperdício. Se você estiver tentando armazenar dados binários não compactados, é recomendável compactá-los primeiro.


Além de lidar com anexos binários, RavenDB oferece suporte a vários outros tipos de dados que fornecem soluções de armazenamento especializadas, adaptadas a necessidades específicas.

O principal deles é o suporte para armazenamento nativo de dados de séries temporais. Vamos supor que a locadora de veículos tenha um rastreador GPS em todos os seus veículos. É importante que a agência acompanhe sempre onde cada veículo esteve. A cada 5 segundos, ele fará ping no servidor com o ID do veículo, a hora atual e as coordenadas GPS. Isso pode crescer muito ao longo da vida útil de um veículo e não é muito adequado para armazenamento em formato de documento.


RavenDB oferece suporte ao armazenamento de dados de série temporal de maneira direta e eficiente, permitindo gerenciar bilhões de pontos de dados, agregá-los e consultá-los.


História Revisionista:


Seu aplicativo precisa de um sistema de registro onde todos os dados, operações e ações sejam registrados. Esse é o papel do banco de dados, é claro. Indo além da parte óbvia de armazenamento e recuperação de dados, há também uma série de funções auxiliares desejáveis.

Um deles é a necessidade de rastrear alterações em seus dados ao longo do tempo. Isso pode ser porque você gostaria de ver seus documentos como eram no passado ou devido a regulamentações rígidas. Muitas áreas, como saúde ou finanças, possuem requisitos de auditoria que você deve atender.


RavenDB permite definir um esquema de controle de versão no qual o banco de dados rastreia revisões antigas de seus documentos à medida que eles mudam. Isso fornece uma trilha de auditoria imutável de suas alterações. Mesmo o administrador do banco de dados não pode modificar essas revisões, elas são verdadeiramente imutáveis.


O recurso de revisões é útil para trilhas de auditoria, mas também simplesmente para ver o que mudou em um documento ao longo do tempo e pode ser uma grande vantagem para cenários de negócios complexos.


Consultas mais rápidas e insights de indexação:


Até agora, tratamos principalmente de como você modela seus dados, realiza transações e armazena e recupera dados. Essa é apenas uma parte, e geralmente não é a parte interessante, do uso de um banco de dados.


Uma vez que seus dados residam no banco de dados, você geralmente estará interessado em consultá-los, muitas vezes de todas as maneiras interessantes. Aqui, durante muito tempo, os bancos de dados relacionais mantiveram uma primazia absoluta.


A palavra-chave original para bancos de dados não relacionais era: bancos de dados NoSQL. A ideia era abandonar não apenas o modelo relacional, mas também a linguagem de consulta que o acompanhava. Isso provou ser um problema sério no futuro.


Hoje, além do MongoDB, não consigo pensar em um único banco de dados que  não  tenha uma linguagem de consulta semelhante ao SQL. O modelo relacional é limitante, mas a capacidade de expressar suas consultas de forma estruturada, independentemente de como os dados são realmente armazenados, é um enorme benefício para os usuários.


Uma das grandes inovações do modelo relacional foi a ruptura entre a forma como os dados são armazenados e como são consultados. Felizmente, a linguagem de consulta e o modelo subjacente não estão interligados e é inteiramente possível usar uma linguagem de consulta semelhante ao SQL em um banco de dados não relacional.


No caso do RavenDB, por exemplo, ele suporta consultas usando RQL (Raven Query Language). Essa linguagem oferece a flexibilidade e a legibilidade do SQL e, ao mesmo tempo, é adaptada para funcionar bem em documentos JSON. O suporte nativo para documentos facilita a consulta de seus dados.


Outro aspecto da consulta é a maneira pela qual o banco de dados é capaz de encontrar os dados relevantes. Normalmente, se você apenas emitir uma consulta ao banco de dados, o mecanismo de consulta precisará examinar todos os registros do sistema para encontrar as correspondências. Como você pode imaginar, essa não é uma boa solução quando você tem uma grande quantidade de dados.


Para resolver esse problema, os bancos de dados utilizam índices. Eles permitem que você encontre os dados relevantes rapidamente. A questão é que agora você precisa não apenas gerenciar seu modelo de dados, mas também seus índices. Qualquer pessoa que tenha enfrentado problemas de desempenho de banco de dados tem uma história de como adicionar um índice simples reduziu a latência de uma consulta de minutos ou horas para milissegundos.

Os bancos de dados relacionais exigem que você defina índices e, então, o banco de dados tentará usar os índices relevantes para acelerar suas consultas. Isso geralmente funciona, mas às vezes o mecanismo de banco de dados decide usar um índice diferente (ou não usar nenhum), levando ao que é efetivamente uma arte negra de otimizações de banco de dados. E tudo isso requer que você tenha definido o conjunto apropriado de índices em primeiro lugar, o que não é uma tarefa óbvia ou fácil.


O RavenDB, por outro lado, não faz suposições sobre os índices que foram implantados. Na verdade, um dos princípios básicos que o RavenDB segue é que ele deve fazer a coisa certa. Quando você emite uma consulta com RavenDB, ele não verifica todo o conjunto de dados. Ele sempre usará um índice para fornecer resultados  rápidos .


E se não houver índice correspondente? O otimizador de consulta irá em frente e criará um para você!


O custo é aproximadamente o mesmo entre a criação de um índice e a verificação de todo o conjunto de dados, mas na próxima vez que você emitir esta consulta ou outra semelhante, o índice já existirá e você poderá obter os resultados imediatamente.


Além disso, o otimizador de consulta RavenDB é inteligente o suficiente para criar o conjunto apropriado de índices para você, simplesmente com base nas consultas que você emite. E à medida que seus padrões de consulta mudam com o tempo, ele se ajustará à configuração ideal para suas necessidades.


Em vez de gastar muito tempo e esforço tentando obter a estratégia de indexação correta, você pode simplesmente ignorar todo o tópico, pois o RavenDB cuidará disso para você.


RavenDB ainda oferece suporte à criação de índices para você em cenários avançados, como consultas geoespaciais, pesquisas de texto completo ou agregações.


Você sempre pode definir seus próprios índices explicitamente, mas o importante é que você não precisa transferir esses recursos para outra plataforma (por exemplo, replicar dados para o ElasticSearch para recursos de pesquisa de texto completo), pois eles podem ser manipulados de forma nativa e diretamente no RavenDB.


Além do dever de babá:


Os bancos de dados relacionais foram criados em uma época em que os computadores custavam mais do que uma casa, eram operados por especialistas altamente remunerados e eram máquinas temperamentais e delicadas. Isso teve um enorme impacto na forma como são estruturados, implantados e como se espera que sejam operados.


Um banco de dados relacional geralmente deve ser usado por um especialista, com uma equipe dedicada de plantão para lidar com quaisquer problemas que possam surgir. Falei sobre isso anteriormente ao discutir a indexação. Os bancos de dados relacionais pressupõem que um administrador de banco de dados com conhecimento profundo dos aplicativos e sistemas que utilizam o banco de dados esteja no comando. Se você não tiver uma equipe dedicada ou se eles não tiverem uma visão completa de tudo o que está acontecendo (uma tarefa quase impossível), provavelmente você não aproveitará ao máximo seu banco de dados.


O RavenDB, por outro lado, nasceu em uma época muito diferente. Ele funciona sem muita orientação, muitas vezes sem nenhuma, e é capaz de fornecer desempenho e recursos equivalentes ou melhores do que um banco de dados relacional com uma equipe cuidando dele em tempo integral.


Existem dezenas de recursos dentro do RavenDB que visam permitir que você opere em modo autônomo. Ele se ajustará automaticamente às mudanças nas condições, como a implantação de novas versões, mudanças nos padrões do usuário, etc.


Executar RavenDB em um cluster é outro cenário onde você pode realmente apreciar a lacuna geracional dos bancos de dados relacionais. Configurar um cluster, garantir alta disponibilidade, distribuição de carga e otimizar o desempenho do seu aplicativo são coisas complicadas e demoradas para bancos de dados relacionais.


Para RavenDB, é assim que as coisas são. Não há complexidade para lidar, pois o banco de dados pressupõe que é ele quem precisa encapsular tudo, deixando você livre para agregar valor comercial aos seus sistemas.


Delícia de banco de dados: um ótimo resumo:


RavenDB e bancos de dados relacionais permitem armazenar e recuperar dados e, à primeira vista, eles se comportam de maneira muito semelhante. Ambos os sistemas possuem transações, podem ser consultados dinamicamente usando uma linguagem de consulta dedicada e funcionam bem para aplicativos de negócios e processamento de transações on-line (OLTP).


RavenDB possui uma abordagem de modelagem mais flexível, mais adequada para aplicações modernas, tanto em termos de permitir mudanças de forma ágil ao longo do tempo quanto de lidar com dados dinâmicos e gerados pelo usuário. Os bancos de dados relacionais transformam a modificação do seu esquema em uma tarefa complicada e os dados dinâmicos em um grande desafio.


Recursos como indexação automática e autoajuste significam que você pode configurar o RavenDB muito rapidamente e, em geral, esquecer que ele existe. Ele cantarolará e fará seu trabalho, deixando você fazer o seu. Os bancos de dados relacionais, no entanto, exigem manejo frequente e cuidados e manutenção contínuos por parte de pessoal qualificado.


Ao trabalhar em um ambiente distribuído, a escolha do seu banco de dados desempenha um papel crucial. O uso de um banco de dados relacional pode introduzir complexidades que podem impactar a eficiência geral da sua solução. Por outro lado, o RavenDB foi criado propositadamente para cenários distribuídos, o que é evidente em sua simplicidade operacional e facilidade geral de uso.


Concluindo, RavenDB se destaca como uma excelente escolha no cenário dinâmico de aplicações modernas. Oferecendo escalabilidade contínua, recursos transacionais robustos e liberdade das complexidades que muitas vezes sobrecarregam os bancos de dados relacionais tradicionais, o RavenDB é um aliado poderoso no domínio dos ambientes distribuídos. Seu design permite que você enfrente os desafios de um mundo orientado por dados com agilidade e confiança.

Para aqueles que buscam uma base confiável, adaptável e fácil de usar para seus aplicativos, o RavenDB prova ser uma escolha firme e pronta para o futuro.


Espero que este artigo tenha sido útil para você. Adoraríamos ter a oportunidade de discutir isso mais detalhadamente com você em nossa  comunidade GitHub . Se você tiver alguma dúvida, não hesite em nos contatar em  support@ravendb.net .







RavenDB é pioneira em tecnologia de banco de dados NoSQL com mais de 2 milhões de downloads e milhares de clientes, desde startups até grandes empresas da Fortune 100.

Mencionado em pesquisas do Gartner e da Forrester, mais de 1.000 empresas usam RavenDB para IoT, Big Data, arquitetura de microsserviços, desempenho rápido, uma rede de dados distribuída e tudo que você precisa para oferecer suporte a uma pilha de aplicativos moderna para o usuário de hoje.



Para mais informações visite: ravendb.net


Contate-nos em: info@ravendb.net




Treinamento on-line gratuito https://ravendb.net/learn/bootcamp




RavenDB Cloud – Banco de dados como serviço https://cloud.ravendb.net/

12 visualizações0 comentário

Posts recentes

Ver tudo

Kommentare


bottom of page