Arquivo

Posts Tagged ‘raft’

Workshop RavenDB 2018: Segurança, eficiência e produtividade

RavenDbAdminPortal

Participei da edição 2018 dos workshops RavenDb, ocorrida em 22 Junho em São Paulo no complexo jK, e vou contar as principais novidades da versão 4.0 desse poderoso banco de dados, seguro por padrão e otimizado para eficiência.

Anúncio do RavenDB Workshop edição 2018

O RavenDb é desenvolvido pela Hibernating Rhinos, empresa israelense, localizada em um dos pólos de tecnologia e inovação mais importantes do planeta. Israel é reconhecidamente celeiro de inovações importantes no campo da medicina, militar dentre outros.

O workshop foi conduzido pelo consultor independente Elemar Jr, que participa ativamente do desenvolvimento desse SGBD, com outros profissionais de nível mundial com “skillset” extremamente elevado.

Já faz um tempo que venho pesquisando bancos de dados noSql disponíveis no mercado, para que em meus próximos projetos eu utilize essa vertente de banco de dados, tendo em vista ganho de produtividade e performance.

Tendo escolhido o RavenDb acima do MongoDb, iniciei pesquisas mais aprofundadas, e esse workshop consolidou minha escolha, e reforçou as características que tornam o Raven a escolha mais recomendada e segura da atualidade.

No workshop tratamos sobre:

a) Setup do sgbd

RavenDb está habilitado para ser configurado tanto em uma única máquina, quanto em um cluster distribuído.

Ele é multi-plataforma, e está disponível para instalação em todas as principais plataformas do mercado:

  • Windows x64 / x86
  • Linux x64
  • Docker
  • MacOS
  • Raspberry Pi

O processo de setup é super intuitivo, e facilita ao extremo a configuração de um cluster seguro, com certificados Let’s Encrypt totalmente gratuitos.

RavenDbSetupWizard

b) Modelagem de documentos

Aqui vão algumas dicas valiosas ao modelar documentos:

  • O documento deve conter somente dados essenciais, e value objects.
  • Seu documento equivale a uma entidade, então outras entidades que o compõe, devem ser gravadas em coleções de documentos independentes.
  • É possível referenciar essas entidades na entidade associada, e efetuar a carga de entidades associadas de forma eficiente e rápida.
  • Um documento deve ser: Coerente e Auto-Suficiente > Não deve ser preciso carregar outros documentos, para que um documento faça sentido. Ex: Um item de pedido, faz sentido sem o documento *pedido* ? Não. Então a lista de itens de pedido, deve ser gravada em conjunto como documento *pedido*. Agora, a lista de itens de pedido, contém produtos certo? Um produto faz sentido, se não estiver vinculado a uma lista de itens do pedido? Sim, faz sentido. Por esse motivo, produto deve ser gravado em um documento independente, e *referenciado* pelos itens do pedido.
  • Um documento deve ser: Isolado > Deve poder mudar a qualquer momento, sem necessariamente ter que mudar quaisquer outros documentos.
  • É recomendado que o tamanho de um documento não ultrapasse 1 MB. Melhor ainda seria se o tamanho girasse em torno de 80 KB.

c) Alta disponibilidade

RavenDb 4.0 foi criado pensando na alta disponibilidade, e tem uma natureza distribuída. A arquitetura de cluster escolhida pelo raven é a master-master, que tem inúmeras vantagens sobre os concorrentes, por não conter um ponto único de falha. Se um nó master falhar, outro nó assumirá o papel de master.

Algumas recomendações:

  • Para que um cluster RavenDB seja beneficiado por todo o poder da arquitetura distribuída master-master, ele deve conter no mínimo 3 nós.
  • O cluster deve conter de preferência uma quantidade ímpar de nós. Pois quando nós caírem, alguns processos exigirão que a maioria absoluta dos nós esteja online. Em clusters com números pares, essa eleição da maioria pode falhar, impedindo a execução de operações que exijam consenso, como por exemplo:
    • Criar / excluir um banco de dados.
    • Adicionar/remover um nó de/para um grupo de bancos de dados.
    • Mudar configurações específicas
    • etc
  • No startup da nossa aplicação, devemos informar as url’s dos nós de nosso cluster. Mas caso você tenha por exemplo 30 nós, não é necessária informar a url de todos eles, pois informando a url de somente 1 nó, esse nó irá comunicar ao driver do ravendb a topologia completa do cluster.
  • Mesmo não sendo necessário informar estaticamente a url de todos os nós, é uma boa prática informá-los, pois, caso o nó informado caia, a sua aplicação não irá conseguir encontrar os demais.
  • RavenDb usa o protocolo RAFT para estabelecer consenso no cluster.

d) Raven Query Language

Uma das novidades mais interessantes da versão 4.0 é a RQL, uma linguagem DQL extremamente poderosa para definição de consultas.

Dentre as principais características me chamaram atenção:

  • Similaridade com linguagem SQL e LINQ.
  • Possibilidade de consumir funções javascript dentro das queryes!!!!!!!!!!
  • Possibilidade de declarar novas funções javascripts, e consumí-las imediatamente em seguida dentro de um consulta RQL!!!!!!!!!!!!!!!!!!!!!!!
  • Queryes com busca espacial. Podemos definir uma área com pontos geográficos baseados em coordenadas, e executar buscas contra essa área. O RavenDb computa esses dados e entrega o resultado pronto de forma simples e rápida.

Exemplos:

declare function MontarNomeCompleto(e)
{
var format = function(p) { return p.Nome + “ “ + p.Sobrenome; };
return { NomeCompleto: format(e) };
}
from Funcionarios as f select MontarNomeCompleto(f);

e) Usando RQL para reduzir carga de rede e latência em operações de consulta

Usando RQL, conseguimos efetuar a pré-carga de documentos associados, de forma que quando formos montar nosso DTO/ViewModel, eles já estejam pré-carregados, no mesmo round-trip do documento principal.

É a prática mais recomendada para carga de aggregate roots, pois reduz drasticamente a carga de rede e latência.

f) Features avançadas

Há 2 features extremamente produtivas que me chamaram atenção:

  • Data subscriptions: Permite a uma aplicação cliente receber um lote de documentos do RavenDb e executar operações nestes documentos. Assim que concluído o processamento, deve-se notificar o RavenDb para que ele envie o próximo lote de documentos. Tem uma ótima vantagem sobre a changes API, pois se o ouvinte da assinatura estiver offline, assim que ele se tornar novamente online, poderá continuar de onde parou.
  • Changes API: Oferece um recurso similar a “push notifications”, que avisa um determinado subscriptor de eventos que ocorreram com os dados no servidor.

Esses tópicos são somente a “ponta do iceberg”, de todos os poderosos recursos do RavenDb. Nesse post poderia ter falado mais de índices map-reduce que são impressionantemente úteis, full-text search dentre outros; mas abordarei em futuros posts.

Usa RavenDb e quer falar sobre? Fale comigo, adoraria trocar idéia sobre cenários de aplicação contigo.

Abraço e até a próxima.

 

Viagem e Voo

Dicas para viagens, férias e voos nacionais e internacionais

Ivan Guimarães Meirelles

Analista Desenvolvedor

Void Podcast

Vazio e sem retorno de valor

Elemar DEV

Negócios, tecnologia e desenvolvimento

2,000 Things You Should Know About WPF

Everything a WPF Developer Needs to Know, in Bite-Sized Chunks

Fernando Franzini Blog

Engenharia de Software e Arquitetura Ágil

Gabriel RB.net

Blog técnico, com dicas, códigos, novidades e problemas do dia-a-dia programando.

Alexandre Valente's Blog

Experiências em tecnologia e assuntos diversos

%d blogueiros gostam disto: