Recentemente, tive a oportunidade de entrevistar Oren Eini, CEO e fundador da Hibernating Rhinos, que fornece o RavenDB, um NoSQL orientado a documentos de código aberto projetado especialmente para a plataforma .NET/Windows.

Oren tem mais de 20 anos de experiência no mundo do desenvolvimento com forte foco no ecossistema Microsoft e .NET. Reconhecido como um dos profissionais mais valiosos da Microsoft desde 2007, Oren também é autor de “DSLs in Boo:Domain Specific Languages ​​in .NET”. Ele frequentemente fala em conferências do setor, como DevTeach, JAOO, QCon, Oredev, NDC, Yow! e Progressive.NET.

Você pode ler a entrevista completa abaixo:

1. Neste mundo digitalizado, os dados se tornaram um dos ativos mais valiosos. e, portanto, a maneira como os dados são armazenados, organizados e processados ​​é fundamental para o sucesso dos negócios. À medida que as empresas são bombardeadas com mais e mais dados, o armazenamento e a análise de dados estão se tornando mais complexos. Você pode nos contar alguns dos desafios comuns de gerenciamento de banco de dados que as empresas enfrentam hoje?

A questão principal, acredito, é apenas o tamanho dos dados. Não estou falando necessariamente sobre Big Data e as complexidades de gerenciar um conjunto de dados medido em centenas de terabytes. Estou falando sobre o número de bancos de dados e silos de dados que você tem em uma organização. Como tudo é digital, você tem funcionalidades críticas para os negócios que residem em uma planilha do Excel em uma unidade compartilhada e dados históricos de compras de clientes em um servidor do qual ninguém quer se aproximar por medo de aceitar a propriedade.

Apenas descobrir o que a organização como um todo sabe pode ser uma tarefa complexa. Os dados que escapam pelas rachaduras são tristemente comuns.

As tentativas de criar um repositório centralizado para toda a empresa também estão fadadas ao fracasso. Diferentes partes da empresa têm ideias muito diferentes sobre o que parecem ser coisas óbvias. Por exemplo, o departamento de cobrança tem uma noção muito diferente do que é um cliente do que o departamento de marketing. Tentar fazer com que os dados se encaixem em um molde comum é um desserviço a todos.

2. Como vamos superar esses desafios? Você acha que escolher uma solução de gerenciamento de banco de dados eficaz é o primeiro passo? E por quê?

O primeiro passo é definir, no nível organizacional, a propriedade dos dados e as regras de responsabilidade. No nível mais básico, o Faturamento possui o conceito de tudo o que um Cliente está em um status de Pagamento Atrasado e o Marketing possui os Interesses de um Cliente. A ideia não é criar silos de informação na organização, mas ter um reconhecimento explícito das diferentes necessidades. Feito isso, você pode definir o fluxo de dados adequado na organização.

O departamento de Faturamento disponibilizará sua visão de um Cliente para o resto da organização, mantendo a liberdade de alterar a forma como ele é moldado dentro do departamento.

Eu uso os departamentos de faturamento e marketing e a noção de cliente como este exemplo para poder falar sobre o negócio primeiro, o que é importante. Para passar para uma forma um pouco mais técnica, estamos falando de serviços e contratos de fluxo de dados. Vou encaminhá-lo ao Mandato de Bezos e como ele transformou a Amazon. A ideia é simples:em vez de tratar a organização inteira como um todo único, o que é quase impossível além de um certo tamanho, trate-a como um grupo de organizações cooperativas que têm limites muito claros entre elas.

Depois de ter esses limites e ter uma boa ideia do fluxo de dados na organização, você pode fazer com que seus encanadores entrem e façam coisas como redirecionar o fluxo de dados para um local central para análise.

Ter essas interfaces publicadas ajuda muito quando chega a hora de mudar o comportamento de algumas coisas. Desde que o comportamento externo seja o mesmo, somos livres para mudar a forma como o processamos.

3. Nos últimos anos, as empresas adotaram vários tipos de bancos de dados NoSQL. Com dados cada vez mais sensíveis sendo armazenados em bancos de dados NoSQL, os problemas de segurança tornaram-se preocupações crescentes. Qual é a sua opinião sobre isso?

Em geral, o motivo mais comum para a falta de segurança em bancos de dados NoSQL é a negligência do operador. Quero separar claramente duas questões distintas aqui. Temos bancos de dados NoSQL, como o Redis, cujo modelo de segurança é explicitamente sobre a execução em um ambiente confiável. Existem alguns recursos de segurança rudimentares para o Redis, mas a suposição geral é que eles devem servir apenas como a terceira ou quarta linha de defesa.

Espera-se que outros bancos de dados NoSQL, como o MongoDB, sejam executados em redes hostis (ou seja, a Internet). No entanto, é fácil configurar o MongoDB sem nenhuma segurança. À primeira vista, o MongoDB vem em uma configuração segura, permitindo que ele ouça apenas a máquina local.

A primeira coisa que você encontrará ao tentar se conectar remotamente ao MongoDB é um guia que explica como habilitar o acesso remoto ao MongoDB, sem qualquer tipo de segurança.

Até certo ponto, isso é negligência do operador. Mas, dado o grande número de bancos de dados MongoDB que são deixados em aberto, acredito que isso esteja dividindo os cabelos. Na China, um banco de dados aberto do MongoDB tinha mais de 200 milhões de CVs apenas esperando alguém bisbilhotar; um banco de dados configurado descuidadamente expôs os backdoors da Rússia em mais de 2.000 empresas.

Com segurança, você não tem uma segunda chance.

O RavenDB, por outro lado, simplesmente se recusará a ser executado em uma configuração vulnerável. Você pode executar o RavenDB sem segurança na máquina local, mas se você tentar expor o banco de dados à Internet sem as devidas proteções, o banco de dados retornará um erro explicando como você deve configurá-lo corretamente.

Preenchemos a quantidade máxima de lacunas assumindo que a maioria das pessoas fará a quantidade mínima de trabalho necessária e garantimos que, quando isso acontecer, o estado final seja bom, por isso, cobrimos você.

4. Falando sobre RavenDB, você pode citar alguns dos recursos mais importantes que agregam mais valor aos clientes? Como o RavenDB se destaca entre outros fornecedores em termos de recursos e desempenho?

O RavenDB está em execução em sistemas de produção há mais de uma década. Alguns dos recursos mais poderosos que datamos de nossa versão original. A capacidade de reagir dinamicamente ao ambiente operacional é a mais óbvia. RavenDB analisa continuamente o que está acontecendo (consultas recebidas, carga do servidor, etc) e reage a isso alterando a alocação de recursos, estruturas internas, etc. seus próprios assuntos.

Quando começamos a trabalhar no RavenDB, queríamos um banco de dados que tivesse todas as vantagens de um banco de dados relacional (rápido, ACID, confiável), mas nenhuma das desvantagens (esquema rígido, manutenção contínua, alta complexidade).

Quando começamos, eu não tinha ideia de quão grande era essa tarefa. Nos últimos 10 anos, ganhamos muita experiência na construção de um banco de dados que pode simplesmente funcionar, sem exigir que você preste muita atenção nele. Projetamos o RavenDB para facilitar a implementação de coisas com foco no desempenho. Um benchmark recente em uma máquina Raspberry Pi (25 $, 1 GHz, 1 GB de RAM) registrou mais de 5.000 gravações por segundo. Em hardware comum, podemos chegar a mais de 100.000 gravações por segundo e mais de 1.000.000 de leituras por segundo.

Tudo isso está em um único nó, mas RavenDB tem sido um banco de dados distribuído desde o início. Isso significa que você pode configurar um cluster em poucos minutos (e fazê-lo de forma segura, é claro) e ter um sistema altamente disponível e robusto.

Oferecemos alguns recursos exclusivos que não estão disponíveis em outros lugares. O ETL é integrado ao RavenDB e é muito utilizado por nossos clientes para permitir um fluxo de dados rico. Você não precisa costurar uma solução de peças díspares, está tudo ali na caixa e simplesmente funciona.

O recurso Assinatura é um do qual estou particularmente orgulhoso. Ele permite que você execute uma consulta contínua. O banco de dados fornecerá inicialmente todos os resultados que correspondem à sua consulta. Como você ainda está inscrito nesta consulta, seu banco de dados enviará todos os novos documentos que correspondam à sua consulta à medida que forem inseridos ou atualizados para atender a essa consulta. Isso permite que você crie processos de negócios robustos e sistemas de back-end com facilidade.

Concentramos muito esforço em tornar o RavenDB em um banco de dados multimodelo capaz de lidar com documentos, valores-chave, dados binários, contadores distribuídos e consultas de gráficos.

5. E, finalmente, qual é o futuro dos sistemas de gerenciamento de banco de dados? Como isso mudará nos próximos 3-4 anos?

Você verá muito mais foco em bancos de dados multimodelo. Em vez de ter que implantar uma solução dedicada para cada tipo de dado desejado e lidar com a complexa integração entre cada uma das peças, o mercado está migrando para uma solução integrada que pode oferecer um conjunto completo de opções em uma única caixa.

A nuvem continuará a ser mais importante, mas eu não teria pressa em dizer adeus aos sistemas locais e distribuídos. Estamos vendo muitos de nossos clientes fazerem processamento na borda e em sistemas ocasionalmente conectados. Acho que você verá uma mudança de foco, onde os data centers do passado se moveriam para a nuvem, mas muito do processamento real seria distribuído na borda e em dispositivos móveis. Isso requer uma maneira diferente de pensar sobre a distribuição de dados e como enviar dados para a nuvem e extrair dados da nuvem.

Haverá muito mais ênfase no tipo de processamento distribuído de dados que antes era exclusivo dos sistemas de ponta.

Certamente será muito interessante ver como o cenário muda e como construímos as ferramentas e metodologias para lidar com a complexidade e funcionalidade cada vez maiores.