NoSQL no Delphi XE 2 - Revista ClubeDelphi 138

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (2)  (0)

Sobre entender o que é um banco de dados NoSQL, suas características, aplicações e como é possível utilizar essa tecnologia com Delphi.

Atenção: esse artigo tem um vídeo complementar. Clique e assista!

De que se trata o artigo

Sobre entender o que é um banco de dados NoSQL, suas características, aplicações e como é possível utilizar essa tecnologia com Delphi.


Em que situação o tema é útil

Conhecendo os recursos e aplicações do NoSQL é possível criar aplicações híbridas, aliviando assim alguma possível sobrecarga em bancos de dados relacionais, direcionando isso aos bancos NoSQL.

Desenvolvimento NoSQL no Delphi XE 2

Mais uma sigla surge no mercado, a NoSQL. Como desenvolvedores não podemos ficar fora disso, é preciso entender do que se trata e se é possível utilizar com Delphi. O objetivo deste artigo é esclarecer de forma simples, prática, consciente o que são os bancos de dados NoSQL e implementar o uso de um deles, o mongoDB. Através de um exemplo vamos centralizar operações de log em um banco NoSQL e mostrar como é possível utilizá-lo com o Delphi em operações simples.

Quando somos chamados para desenvolver um novo projeto, logo pensamos em como esses dados serão armazenados, consequentemente já pensamos em qual banco de dados utilizar, qual estrutura de tabelas empregar, logo, imaginamos um banco relacional SQL.

Os bancos relacionais, juntamente com a linguagem SQL, têm controlado a área de armazenamento de informações por pelo menos 30 anos. Não havia, e ainda não há, dúvidas de que são o padrão para armazenagem de informações complexas provenientes de sistemas de negócio. O fato é que não existia alternativa à altura da dupla SGBDR e SQL. Seu uso tem sido justificado até hoje por sua propriedade transacional ACID, de atomicidade, consistência, isolamento e durabilidade, o que garante segurança aos sistemas de negócio. A evolução natural dessa tecnologia criou sistemas de alta disponibilidade, recursos como replicação, suporte a dados estruturados e muito mais. Isso tudo tem um custo. Bancos de dados relacionais, no geral, não são muito eficientes no escalonamento horizontal, sua especialidade é a vertical. Ou seja, se seu sistema demanda mais processamento do banco de dados, melhora-se o servidor, incluindo mais memória, mais espaço físico, mais processadores, etc.

Grandes empresas, que possuem produtos que gerenciam centenas de milhões de usuários, como Google, Facebook, Amazon e Twitter, não utilizam por trás de seus sistemas um banco relacional, utilizam algo especificado como NoSQL.

Um novo paradigma

NoSQL é uma definição para uma forma de armazenamento de dados que pode variar dependendo de quem a explica. Pode ser explicada como “Sem SQL” ou “Não apenas SQL”. Essas são definições que não expressam suas características de armazenamento. Em sua ideia básica um banco de dados NoSQL pode ser representado pelo acrônimo BASE:

• Basicamente, disponível: a disponibilidade é a marca de um banco NoSQL. Através do uso de mecanismos de replicação e o uso de sharding (particionamento de dados por diferentes servidores) resultam em um sistema de informações onde falhas são parciais, onde pequenas porções de toda informação armazenada fica indisponível por curtos períodos de tempo. Assim, é pode-se dizer que é um banco de dados sempre disponível;

• eStado flexível: enquanto os sistemas relacionais garantem consistência de informações, sistemas NoSQL permitem a inconsistência de dados. Isso acontece porque no mundo NoSQL não existe a necessidade de se definir um esquema rígido para os dados, permitindo que suas informações se adequem rapidamente às mudanças de negócio envolvidas, deixando contudo, ao desenvolvedor a tarefa de lidar com isso;

• Eventualmente consistente: Embora os aplicativos precisam lidar com uma consistência instantânea, o NoSQL garante que em algum ponto adiante no tempo a informação estará consistente. Isso é bastante contrário ao pensamento ACID, onde o commit de uma transação assegura consistência.

Essas são características básicas, mas existem implementações que asseguram, por exemplo, o conceito de atomicidade em suas operações de atualização/inserção de dados. Mas toda essa diferença vai um pouco além. Quando utilizamos um banco de dados relacional pensamos em como armazenar os dados, porém, o cenário atual nos leva a pensar diferente, nos leva a perguntar “como utilizamos os dados”. O armazenamento agora é projetado com base em como usamos as informações.

"

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?