Construindo uma aplicação Ionic CRUD com Firestore

O Firestore é o novo banco de dados do Firebase. É um banco de dados orientado a documentos NoSQL para desenvolvimento móvel e web.

Ele é projetado para armazenar e sincronizar dados de aplicativos em escala global com facilidade. Algumas de suas principais características incluem:

  • Documentos e Coleções com consultas poderosas.
  • Acesso off-line ao WEB SDK.
  • Sincronização de dados em tempo real.

Hoje vamos aprender a integrar o Firestore com o Ionic para criar um fluxo de trabalho CRUD. Este aplicativo de amostra mostrará a você como:

  • Mostrando uma lista de itens do seu banco de dados ( que no Firestore é chamado exibindo uma coleção de documentos ).
  • Criando um novo item e adicionando-o à lista.
  • Navegar para a página de detalhes desse item.
  • Excluindo um item da nossa lista.

captura de tela mostrando as diferentes visualizações para o firestore CRUD

Vamos dividir este processo em X passos:

  • Etapa 1: crie e inicialize nosso aplicativo Ionic.
  • Etapa 2: adicione itens à lista.
  • Passo # 3: Mostre a lista de itens.
  • Passo # 4: Navegue até a página de detalhes de um item.
  • Etapa 5: excluir um item da lista.

Agora que sabemos o que vamos fazer, vamos pular para o modo de codificação.

Etapa 1: criar e inicializar seu aplicativo

O objetivo desta etapa é criar seu novo aplicativo iônico, instalar os pacotes necessários ( somente Firebase e AngularFire2 ) e inicializar nosso aplicativo do Firebase.

Com isso em mente, vamos criar nosso aplicativo primeiro, abrir seu terminal e navegar até a pasta que você usa para codificação ( ou em qualquer lugar que você quiser, para mim, essa é a pasta Desenvolvimento ) e criar seu aplicativo:

cd Development/
ionic start firestore-example blank
cd firestore-example 

Depois que criarmos o aplicativo, precisaremos instalar o Firebase. Para isso, abra o terminal novamente e ( enquanto estiver na raiz do projeto ), digite:

npm install angularfire2 firebase

Esse comando instalará as versões estáveis ​​mais recentes do AngularFire2 e do Firebase Web SDK.

Agora que instalamos tudo, vamos conectar o Ionic ao nosso aplicativo do Firebase.

A primeira coisa que precisamos é obter as credenciais do nosso aplicativo, fazer login no Firebase Console e navegar até o aplicativo do Firebase ( ou criar um novo caso você ainda não tenha o aplicativo ).

Na guia Visão geral do projeto, você verá a tela “Primeiros passos”, com opções para adicionar o Firebase a diferentes tipos de aplicativos, e selecione “Adicionar o Firebase ao seu aplicativo da web”.

De todo o código que aparece nessa janela pop-up, concentre-se nesse bit:

var config = {
  apiKey: "Your credentials here",
  authDomain: "Your credentials here",
  databaseURL: "Your credentials here",
  projectId: "Your credentials here",
  storageBucket: "Your credentials here",
  messagingSenderId: "Your credentials here",
};

Esse é o seu objeto de configuração do Firebase, ele tem todas as informações necessárias para acessar as diferentes APIs do Firebase, e precisaremos disso para conectar nosso aplicativo iônico ao nosso aplicativo do Firebase.

Vá para a sua src/apppasta e crie um arquivo chamado credentials.tsa idéia deste arquivo é manter todas as nossas credenciais em um só lugar, este arquivo não deve estar no controle de origem para adicioná-lo ao seu .gitignorearquivo.

Copie seu objeto de configuração para essa página. Vou mudar o nome para algo que faça mais sentido para mim:

export var firebasConfig = {
  apiKey: "AIzaSyBJT6tfre8uh3LGBm5CTiO5DUZ4",
  authDomain: "javebratt-playground.firebaseapp.com",
  databaseURL: "https://javebratt-playground.firebaseio.com",
  projectId: "javebratt-playground",
  storageBucket: "javebratt-playground.appspot.com",
  messagingSenderId: "3676553551"
};

Estamos exportando para que possamos importá-lo para outros arquivos onde precisarmos.

Agora é hora da parte final desta etapa, precisamos inicializar o Firebase, para isso, vamos entrar app.module.tse, primeiro, vamos importar os pacotes AngularFire2 que precisaremos e nosso objeto de credencial:

import { AngularFireModule } from 'angularfire2';
import { AngularFirestoreModule } from 'angularfire2/firestore';
import { firebaseConfig } from './credentials';

Como vamos usar apenas o banco de dados Firestore, importamos o módulo de base AF2 ( vou me referir a AngularFire2 como AF2 de agora em diante ) e o módulo Firestore. Se você também precisasse de autenticação ou armazenamento, você precisaria adicionar esses módulos aqui.

Dentro de sua @NgModule()aparência para sua importsmatriz e adicione o módulo AF2 e o módulo Firestore:

imports: [
  BrowserModule,
  IonicModule.forRoot(MyApp),
  AngularFireModule.initializeApp(firebaseConfig),
  AngularFirestoreModule,
],

Estamos chamando o .initializeApp(firebaseConfig)método e passando nosso objeto de credencial para que nosso aplicativo saiba como se conectar ao Firebase.

E é isso, pode não parecer muito ainda , mas nossos aplicativos Firebase e Ionic agora podem conversar entre si.

Etapa 2: adicione itens à lista.

É hora de começar a trabalhar com nossos dados, vamos construir um aplicativo CRUD, usaremos uma lista de músicas como um exemplo, mas os mesmos princípios se aplicam a qualquer fluxo de trabalho Mestre / Detalhe que você queira construir.

A primeira coisa que precisamos é entender como nossos dados são armazenados, o Firestore é um banco de dados NoSQL orientado a documentos, que é um pouco diferente do RTDB ( banco de dados em tempo real ).

Isso significa que temos dois tipos de dados em nosso banco de dados, documentos, que são objetos com os quais podemos trabalhar, e coleções que são os contêineres que agrupam esses objetos.

Por exemplo, se estivermos criando um banco de dados de músicas, nossa coleção seria chamada songs, ou songList, que conteria todos os objetos de música individuais e cada objeto teria suas propriedades, como o nome da música, o artista etc.

Em nosso exemplo, o objeto song terá cinco propriedades, um id, o álbum, o artista, uma descrição e o nome da música. No espírito de aproveitar os recursos de verificação de tipos do TypeScript, vamos criar uma interface que funcione como modelo para todas as nossas músicas.

Vá até a srcpasta e crie uma pasta chamada models, adicione um arquivo chamado song.interface.tse preencha-o com os seguintes dados:

export interface Song {
  id: string;
  albumName: string;
  artistName: string;
  songDescription: string;
  sonName: string;
}

Essa é a interface da música e garante que, sempre que estivermos trabalhando com um objeto de música, ele tenha todos os dados necessários.

Para começar a criar novas músicas e adicioná-las à nossa lista, precisamos ter uma página que contenha um formulário para inserir os dados da música, criar essa página com o Ionic CLI, abrir o terminal e digitar:

ionic generate page Create

Na verdade, enquanto estamos nisso, vamos dedicar alguns minutos para criar a página de detalhes, uma visualização detalhada de uma música específica e o provedor de Firestore, ele cuidará de todas as interações do banco de dados para que possamos gerenciar tudo desse arquivo.

ionic generate page Detail
ionic generate provider Firestore

Agora precisamos de uma maneira de ir da home page para o CreatePage, para que abrir home.htmle alterar seu cabeçalho para ficar assim:

<ion-header>
  <ion-navbar color="primary">
    <ion-title>
      Song List
    </ion-title>
    <ion-buttons end>
      <button ion-button icon-only (click)="goToCreatePage()">
        <ion-icon name="add"></ion-icon>
      </button>
    </ion-buttons>
  </ion-navbar>
</ion-header>

Estamos adicionando um botão ao cabeçalho que aciona a goToCreatePage()função, para que funcione, vamos abrir o home.tsarquivo e escrever essa função:

import { Component } from '@angular/core';
import { NavController } from 'ionic-angular';

@Component({
  selector: 'page-home',
  templateUrl: 'home.html',
})
export class HomePage {
  constructor(public navCtrl: NavController) {}

  goToCreatePage(): void {
    this.navCtrl.push('CreatePage');
  }
}

A única coisa que esta função está fazendo é levá-lo para o CreatePage, agora que podemos chegar a essa página, é hora de construir sua funcionalidade. A funcionalidade consistirá em 3 coisas:

  • A exibição de HTML que mostra o formulário.
  • A classe TypeScript que coleta os dados do formulário e os envia ao provedor.
  • A função no provedor que cria a música e a adiciona à lista de músicas.

Vamos começar com o HTML, abrir o create.htmlarquivo e dentro das <ion-content></ion-content>tags criar o formulário:

<ion-content>
  <form [formGroup]="createSongForm" (submit)="createSong()" novalidate>
    <ion-item>
      <ion-label stacked>Song Name</ion-label>
      <ion-input formControlName="songName" type="text" 
        placeholder="What's this song called?">
      </ion-input>
    </ion-item>

    <ion-item>
      <ion-label stacked>Artist Name</ion-label>
      <ion-input formControlName="artistName" type="text" 
        placeholder="Who sings this song?">
      </ion-input>
    </ion-item>

    <ion-item>
      <ion-label stacked>Album Name</ion-label>
      <ion-input formControlName="albumName" type="text" 
        placeholder="What's the album's name?">
      </ion-input>
    </ion-item>

    <ion-item>
      <ion-label stacked>Song Description</ion-label>
      <ion-textarea formControlName="songDescription" type="text" 
        placeholder="What's this song about?">
      </ion-textarea>
    </ion-item>


    <button ion-button block type="submit" [disabled]="!createSongForm.valid">
      Add Song
    </button>
  </form>

</ion-content>

Se você é novo em formas angulares, então aqui está o que está acontecendo:

  • [formGroup]="createSongForm" => Este é o nome do formulário que estamos criando.
  • (submit)="createSong()"=> Isso indica o formulário que, ao enviar, deve chamar a createSong()função.
  • formControlName => Este é o nome do campo.
  • [disabled]="!createSongForm.valid" => Isso define o botão a ser desativado até que o formulário seja válido.

Agora vamos para o create.tsarquivo, aqui coletamos os dados do nosso formulário e passamos para o nosso provedor. Primeiro, vamos importar tudo o que precisaremos:

import { Component } from '@angular/core';
import {
  IonicPage,
  NavController,
  Loading,
  LoadingController,
  AlertController,
  Alert,
} from 'ionic-angular';
import { FormGroup, FormBuilder, Validators } from '@angular/forms';
import { FirestoreProvider } from '../../providers/firestore/firestore';

Estamos importando:

  • Formulário métodos auxiliares de @angular/forms.
  • Carregando controlador para mostrar um widget de carregamento para nossos usuários enquanto o formulário processa os dados.
  • Alertar o controlador para exibir um alerta para o nosso usuário, se houver algum erro.
  • E o provedor Firestore para chamar a função que adicionará a música ao banco de dados.

Agora precisamos injetar todos esses provedores no construtor e inicializar nosso formulário:

public createSongForm: FormGroup; // This is the form we're creating.

constructor(
  public navCtrl: NavController,
  public loadingCtrl: LoadingController,
  public alertCtrl: AlertController,
  public firestoreProvider: FirestoreProvider,
  formBuilder: FormBuilder
) {
  this.createSongForm = formBuilder.group({
    albumName: ['', Validators.required],
    artistName: ['', Validators.required],
    songDescription: ['', Validators.required],
    songName: ['', Validators.required],
  });
}

E agora tudo que precisamos é a função que coleta os dados e os envia para o provedor, se você se lembrar da parte HTML, nós a chamamos createSong()

createSong(): void { }

A primeira coisa que queremos fazer dentro dessa função é acionar um componente de carregamento que permitirá ao usuário saber que os dados estão sendo processados ​​e, depois disso, extrairemos todos os dados de campo do formulário.

createSong(): void {
  const loading: Loading = this.loadingCtrl.create();
  loading.present();

  const albumName = this.createSongForm.value.albumName;
  const artistName = this.createSongForm.value.artistName;
  const songDescription = this.createSongForm.value.songDescription;
  const songName = this.createSongForm.value.songName;
}

E, por último, enviaremos os dados para o provedor, assim que a música for criada com sucesso, o usuário deverá navegar de volta para a página anterior, e se houver algo errado ao criá-lo, exibiremos um alerta com a mensagem de erro.

createSong(): void {
  const loading: Loading = this.loadingCtrl.create();
  loading.present();

  const albumName = this.createSongForm.value.albumName;
  const artistName = this.createSongForm.value.artistName;
  const songDescription = this.createSongForm.value.songDescription;
  const songName = this.createSongForm.value.songName;

  this.firestoreProvider
    .createSong(albumName, artistName, songDescription, songName)
    .then(
      () => {
        loading.dismiss().then(() => {
          this.navCtrl.pop();
        });
      },
      error => {
        loading.dismiss().then(() => {
          const alert: Alert = this.alertCtrl.create({
            message: error.message,
            buttons: [{ text: 'Ok', role: 'cancel' }],
          });
          alert.present();
        });
      }
    );
}

OBSERVAÇÃO: Como uma boa prática, manipule esses erros você mesmo, em vez de mostrar a mensagem de erro padrão para os usuários, certifique-se de fazer algo mais fácil de usar e usar suas mensagens personalizadas, somos técnicos, sabemos o que o erro significa, do tempo que nossos usuários não vão.

Nós quase terminamos essa parte, tudo que precisamos agora é criar a função dentro do provedor que recebe todos os dados do formulário que estamos enviando e usa para criar uma música em nosso banco de dados.

Abra providers/firestore/firestore.tse vamos fazer algumas coisas, precisamos:

  • Importar Firestore.
  • Importe nossa interface de música.
  • Injetar firestore no construtor.
  • E escreva a createSong()função que leva todos os parâmetros que enviamos do nosso formulário.
import { Injectable } from '@angular/core';
import { AngularFirestore } from 'angularfire2/firestore';
import { Song } from '../../models/song.interface';

@Injectable()
export class FirestoreProvider {
  constructor(public firestore: AngularFirestore) {}

  createSong(
    albumName: string,
    artistName: string,
    songDescription: string,
    songName: string
  ): Promise<void> { }
}

A função está tomando todos os parâmetros que estamos enviando. Agora vamos fazer algo que possa parecer incomum . Nós vamos usar a createId()função firestore para gerar um id para a nossa nova música.

import { Injectable } from '@angular/core';
import { AngularFirestore } from 'angularfire2/firestore';
import { Song } from '../../models/song.interface';

@Injectable()
export class FirestoreProvider {
  constructor(public firestore: AngularFirestore) {}

  createSong(
    albumName: string,
    artistName: string,
    songDescription: string,
    songName: string
  ): Promise<void> {
    const id = this.firestore.createId();
  }
}

O Firestore gera automaticamente IDs para nós quando enviamos itens para uma lista, mas eu gosto de criar primeiro o ID e depois armazená-lo dentro do item. Dessa forma, se eu puxar um item, posso obter sua ID e não tem que fazer quaisquer outras operações para obtê-lo.

Agora que criamos o id, vamos criar uma referência para essa música e definir todas as propriedades que temos, incluindo o id.

import { Injectable } from '@angular/core';
import { AngularFirestore } from 'angularfire2/firestore';
import { Song } from '../../models/song.interface';

@Injectable()
export class FirestoreProvider {
  constructor(public firestore: AngularFirestore) {}

  createSong(
    albumName: string,
    artistName: string,
    songDescription: string,
    songName: string
  ): Promise<void> {
    const id = this.firestore.createId();

    return this.firestore.doc(`songList/${id}`).set({
      id,
      albumName,
      artistName,
      songDescription,
      songName,
    });
  }
}

Essa última parte do código está criando uma referência ao documento identificado com esse ID em nossa songListcoleção e, depois de criar a referência, ele adiciona todas as informações que enviamos como parâmetros.

E é isso. Agora você pode adicionar músicas à nossa lista. E uma vez que cada música é criada, o usuário irá navegar de volta para a página inicial, onde vamos mostrar a lista de músicas armazenadas no banco de dados.

Passo # 3: Mostre a lista de itens.

Para mostrar a lista de músicas, seguiremos a mesma abordagem que usamos para nossa última funcionalidade, criaremos a exibição HTML, a classe TypeScript e a função dentro do provedor que se comunica com o Firebase.

Já que temos o provedor aberto a partir da funcionalidade anterior vamos começar por aí, queremos criar uma função chamada de getSongList()função que deva retornar uma coleção de músicas:

getSongList(): AngularFirestoreCollection<Song> {
  return this.firestore.collection(`songList`);
}

Note que para isso funcionar você precisa importar AngularFirestoreCollectiondo angularfire2/firestorepacote ( ou remover a verificação de tipo se você não se importa com isso ).

Agora, vamos para a página inicial e importamos tudo o que precisaremos:

import { Song } from '../../models/song.interface';
import { FirestoreProvider } from '../../providers/firestore/firestore';
import { Observable } from 'rxjs/Observable';

Queremos a Songinterface para uma verificação de tipo restrita, FirestoreProviderpara se comunicar com o banco de dados e Observabletambém para verificação de tipo, nosso provedor retornará um AngularFirestoreCollection que transformaremos em um observável para exibir em nossa visualização.

Então, dentro de nossa classe, queremos criar a songListpropriedade, vamos usá-la para exibir as músicas no HTML e injetar o provedor firestore no construtor.

public songList: Observable<Song[]>;
constructor(
  public navCtrl: NavController,
  public firestoreProvider: FirestoreProvider
) {}

E, por último, queremos esperar até que a página carregue e buscar a lista do nosso provedor:

ionViewDidLoad() {
  this.songList = this.firestoreProvider.getSongList().valueChanges();
}

.valueChanges()método pega o AngularFirestoreCollection e o transforma em um tipo Observable of Songs.

Agora podemos ir para home.htmldentro e dentro da <ion-content>nossa lista de músicas para exibir todas as músicas no banco de dados.

<ion-content>
  <ion-card *ngFor="let song of songList | async" 
    (click)="goToDetailPage(song)">
    <ion-card-header>
      {{ song.songName }}
    </ion-card-header>
    <ion-card-content>
      Artist Name: {{ song.artistName }}
    </ion-card-content>
  </ion-card>
</ion-content>

Estamos apenas mostrando o nome da música e o nome do artista, e estamos adicionando um evento de clique ao nosso cartão, uma vez que o usuário clica no cartão, ele deve acionar a goToDetailPage()função e passar todo o objeto da música como um parâmetro.

Nós não criamos essa função, então vamos criar um momento para criá-la em nossa homepage:

goToDetailPage(song: Song): void {
  this.navCtrl.push('DetailPage', { song: song });
}

A função navega o usuário até a página Detail e passa todo o objeto da música como um parâmetro de navegação. Na próxima seção, usaremos esse parâmetro de navegação para exibir os dados da música inteira na página de detalhes.

Por enquanto, pegue um biscoito ou algo assim, você já leu muito, e seus níveis de açúcar podem precisar de um impulso. Vejo vocês em alguns minutos na próxima seção🙂

Passo # 4: Navegue até a página de detalhes de um item.

Na etapa anterior, criamos uma função que nos leva à página de detalhes com as informações da música e, agora, vamos usar essas informações e exibi-las para o usuário ver.

Em vez de falar com o provedor para obter o registro da música, estamos passando a música inteira como um parâmetro de navegação, portanto, não precisamos importar nosso provedor do firestore agora.

A primeira coisa que faremos é detail.htmlcriar uma visualização básica que exiba todos os dados que temos para nossa música:

<ion-header>
  <ion-navbar color="primary">
    <ion-title>
      {{ song.songName }}
    </ion-title>
  </ion-navbar>
</ion-header>

<ion-content padding>
  <h3> Artist </h3>
  <p>
    The song {{ song.songName }} was released by {{ song.artistName }}.
  </p>

  <h3> Album </h3>
  <p>
    It was part of the {{ song.albumName }} album.
  </p>

  <h3> Description </h3>
  <p>
    {{ song.songDescription }}
  </p>
</ion-content>

Estamos mostrando o nome da música na barra de navegação e adicionamos o restante dos dados ao conteúdo da página.

Agora vamos pular detail.tspara que possamos fazer o songcontrário, isso irá cometer erros.

Tudo que você precisa fazer é criar uma propriedade songdo tipo Song, para isso precisamos importar a Songinterface.

Então, você deseja obter o parâmetro de navegação que enviamos para a página e atribuir seu valor à songpropriedade que você criou.

import { Component } from '@angular/core';
import { IonicPage, NavController, NavParams } from 'ionic-angular';
import { Song } from '../../models/song.interface';

@IonicPage()
@Component({
  selector: 'page-detail',
  templateUrl: 'detail.html',
})
export class DetailPage {
  public song: Song;
  constructor(public navCtrl: NavController, public navParams: NavParams) {
    this.song = this.navParams.get('song');
  }
}

Você deve fazer um teste agora mesmo, pois ionic serveseu aplicativo deve estar funcionando, e você deve ser capaz de criar novas músicas, mostrar a lista de músicas e entrar na página de detalhes de uma música.

Etapa 5: excluir um item da lista.

Na última parte do tutorial vamos adicionar um botão dentro da DetailPage, esse botão dará ao usuário a capacidade de remover músicas da lista.

Primeiro, abra detail.htmle crie o botão, nada muito chique, um botão regular que chame a função remove fará, configure-o imediatamente antes da tag de conteúdo iônico de fechamento.

<button ion-button block (click)="deleteSong(song.id, song.songName)">
    DELETE SONG
  </button>
</ion-content>

Agora vá para o detail.tse crie a deleteSong()função, ele deve levar 2 parâmetros, o ID da música e o nome da música:

deleteSong(songId: string, songName: string): void {}

A função deve acionar um alerta que solicita ao usuário uma confirmação e, se o usuário aceitar a confirmação, deverá chamar a função de exclusão do provedor e retornar à página anterior ( Nossa home page ou página de listagem ).

deleteSong(songId: string, songName: string): void {
    const alert: Alert = this.alertCtrl.create({
      message: `Are you sure you want to delete ${songName} from your list?`,
      buttons: [
        {
          text: 'Cancel',
          handler: () => {
            console.log('Clicked Cancel');
          },
        },
        {
          text: 'OK',
          handler: () => {
            this.firestoreProvider.deleteSong(songId).then(() => {
              this.navCtrl.pop();
            });
          },
        },
      ],
    });
    alert.present();
  }

NOTA: Certifique-se de importar Alert, AlertController e nosso FirestoreProvider para que isso funcione.

Agora, tudo o que precisamos fazer é ir ao nosso provedor e criar a função de exclusão:

deleteSong(songId: string): Promise<void> {
  return this.firestore.doc(`songList/${songId}`).delete();
}

A função usa o ID da música como um parâmetro e, em seguida, usa-a para criar uma referência a esse documento específico no banco de dados. Por último, chama o .delete()método nesse documento.

E é isso. Você deve ter uma funcionalidade Mestre / Detalhe totalmente funcional na qual possa listar objetos, criar novos objetos e excluir objetos do banco de dados.🙂

Próximos passos

Parabéns, esse foi longo, mas estou certo de que você agora entende mais sobre o Firestore e como usá-lo com o Firebase.

Se você quiser saber mais sobre o Firestore e começar a criar aplicativos Ionic mais completos, criei um Crash Course que aborda a teoria por trás do que vimos aqui e também inclui os disparadores do Cloud Functions para as regras de segurança do Firestore e do Firestore.

VOCÊ PODE RECEBER GRATUITAMENTE AQUI .

FONTE: https://javebratt.com/crud-ionic-firestore/

O que é MongoDB e porque usá-lo?

MongoDB é um dos mais populares de banco de dados. E disparado o mais famoso NoSQL no mercado. O mesmo é open-source e escrito em C ++.
Desde fevereiro de 2015, MongoDB ocupa a quarta posição no ranking mundial. Ele foi desenvolvido pela empresa 10gen inicialmente, que é hoje conhecida como MongoDB Inc.
MongoDB é um banco de dados orientado a documentos que armazena dados em documentos JSON com esquema dinâmicoIsso significa que você pode armazenar seus registros sem se preocupar com a estrutura de dados, como o número de campos ou tipos de campos para armazenar valoresOs documentos do MongoDB são semelhantes aos objetos JSON.
MongoDB é um banco de dados multi-plataforma NoSQL, que pode ser executado em Windows, Linux e Mac etc. Ele suporta linguagens de programação mais populares, como C #, Java, PHP, Javascript, NodeJs, Python e muito mais! 

Porque MongoDB?

Como você sabe, RDMS guarda dados em tabelas formatadas e utiliza linguagem de consulta estruturada (SQL)para consulta de banco de dadosRDBMS também tem esquema pré-definido com base nos requisitos e um conjunto de regras para definir as relações entre os campos em tabelas.

Fontehttps://codigosimples.net/2016/03/01/o-que-e-mongodb-e-porque-usa-lo/

Banco de dados NoSQL: Um novo paradigma – Revista SQL Magazine 102

Este artigo tem o objetivo de explicar as principais características dos bancos de dados NoSQL.

De que se trata o artigoEste artigo tem o objetivo de explicar as principais características dos bancos de dados NoSQL. Bancos noSQL se referem a uma classe definida de banco de dados não-relacionais que rompem com uma longa história de banco de dados focados nas propriedades ACID. Para tornar ainda mais clara a diferença trazida por este novo paradigma, este artigo também realiza algumas análises comparativas entre bancos noSQL e relacionais.

Em que situação o tema útil

Conhecer o novo paradigma que vem surgindo na área de banco de dados, noSQL, pode ser considerado muito importante para aqueles que trabalham com banco de dados ou tomadores de decisão da área de tecnologia das organizações. É sempre importante estar atento a novas tecnologias e como elas resolvem problemas provenientes das limitações das tecnologias existentes.

Resumo DevMan

Através deste artigo temos a pretensão de apresentar de forma concisa os fundamentos, características e diferenciais dos bancos de dados NoSQL. Além disso, a autora deste artigo acredita ser de suma importância apresentar os fundamentos relacionados ao Banco de Dados Relacional, assim como realizar diversas comparações entre os dois modelos, para que haja uma melhor compreensão e abstração deste novo paradigma chamado Banco de Dados NoSQL.

A forma como nos comunicamos, trocamos informações e criamos conteúdo mudou muito ao longo dos anos. Estamos vivenciando uma época onde as aplicações Web têm revolucionado o mundo em diversos sentidos e a tendência é que este crescimento habilite a criação de uma série de novas aplicações. O grande volume de dados gerados por estas aplicações Web, aliado com a nova forma de interação com o usuário (dinâmica, eficiente e intuitiva), a escalabilidade sob demanda e a necessidade de um alto grau de disponibilidade, tem fomentado o aparecimento de novos paradigmas e tecnologias.

Todos nós sabemos que o banco de dados relacional tem sido usado há muito tempo em larga escala pelo mundo afora, e desde sua criação, por volta do início dos anos 1970, esse tem sido o tipo de banco de dados mais utilizado em empresas que possuem um intenso volume de dados para serem armazenados [1]. Pensando justamente neste imenso volume de dados que tende a crescer a cada momento, começa a se observar que os bancos de dados relacionais possuem certos fatores limitantes, principalmente quando nos referimos a escalabilidade de um sistema [3]. Este ambiente envolto de limitações que os bancos de dados relacionais têm propiciado instigou o surgimento de outros tipos de modelos alternativos de banco de dados que possam suprir essa necessidade.

Diante de tantas dificuldades que são encontradas à medida que as necessidades surgem, está crescendo uma nova geração de banco de dados que vem ganhando bastante força e espaço, estes são conhecidos como NoSQL (“Not Only SQL”) [4], este é o termo genérico que define um banco de dados não-relacional. Este modelo veio com a proposta de atender e gerenciar os grandes volumes de dados, buscando um alto desempenho e disponibilidade. Neste contexto, neste artigo serão apresentadas características desses bancos de dados e se discute ainda como essas novas soluções podem abordar questões que estão sendo atualmente enfrentadas.

História e característica do banco de dados relacional

O banco de dados relacional surgiu como um sucessor dos modelos hierárquicos de rede. Estas estruturas, por sua vez, foram muito utilizadas nos primeiros sistemas de mainframe. No entanto, devido ao grande número de restrições de relacionar estruturas no mundo real, este modelo foi perdendo força para dar lugar aos bancos de dados relacionais [5]. Este, por último, se tornou o grande padrão para a maioria dos Sistemas Gerenciadores de Banco de Dados (SGBDs). Outro ponto importante a salientar sobre o modelo relacional é a utilização de restrições de integridade que garantem a consistência dos dados em um banco de dados. Estas restrições, em sua grande maioria, são conhecidas como chaves primárias (PRIMARY KEY) e chaves estrangeiras (FOREIGN KEY).

Outra característica que devemos ressaltar no Modelo Relacional é o que chamamos de processo de Normalização. Seu objetivo é a aplicação de uma série de passos com determinadas regras sobre a tabela do banco de dados de forma a garantir o projeto adequado dessas tabelas. Um conceito básico da normalização consiste na separação de dados referentes a elementos distintos em tabelas distintas, associadas através da utilização das chaves. Essas regras permitem um armazenamento consistente e, além disso, um eficiente acesso aos dados, reduzindo redundâncias e diminuindo as chances dos dados se tornarem inconsistentes [7].

Além disso, o modelo relacional começou a adotar uma linguagem para a manipulação e consulta destes dados. Estamos nos referindo ao SQL (Structured Query Language). Criada originalmente pela IBM e inspirada na álgebra relacional, ganhou grande destaque pela facilidade do seu uso, diferenciando-a assim de todas as outras linguagens procedurais da época. Devido a sua grande utilização em 1982, o American National Standard Institute (ANSI) tornou o SQL o padrão oficial de linguagem em ambiente relacional, consolidando assim a sua posição de dominância no modelo relacional [1].

Não é possível falar de SQL sem falar também do SGBD, que se caracteriza como um conjunto de programas que permitem armazenar, modificar e extrair em um banco de dado. Falando mais atentamente sobre o assunto, podemos afirmar que o SGBD oferece aos seus usuários processos de validação, recuperação de falhas, segurança, otimização de consultas, garantia de integridade dos dados, entre outros [8].

Além disso, os SGBDs Relacionais oferecem a possibilidade de vários usuários acessarem e manipularem um mesmo banco de dados simultaneamente e principalmente de forma eficiente, algo que é fundamental em sistemas de grande porte.

Os SGBDs relacionais ainda possuem a possibilidade do sistema se recuperar adequadamente de possíveis falhas, ou seja, ele tem a capacidade de voltar ao ponto anterior em que ocorreu a falha, permitindo assim um banco de dados mais consistente.

Vale ressaltar ainda que os bancos de dados relacionais seguem o modelo ACID para preservar a integridade de uma transação. Este conjunto de procedimentos é dividido em quatro propriedades, e são elas:

• Atomicidade: As ações que compõe a ação da transação devem ser concluídas com sucesso para ser efetivada. Se esta transação falhar, será feito o rollback.

• Consistência: Todas as regras/restrições descritas no banco de dados devem ser obedecidas garantindo que o banco de dados passe de uma forma consistente para outra forma consistente.

• Isolamento: Neste caso, a propriedade de isolamento garante que a transição não será interferida por nenhuma outra transação concorrente.

• Durabilidade: Os resultados de uma transação são permanentes, ou seja, o que foi salvo não será mais perdido.

Todos esses diferentes recursos auxiliaram a manter os SGBDs Relacionais sempre em uma posição de predominância entre os mais diversos tipos de ambientes computacionais, mas ao mesmo tempo, não impediu o aparecimento de determinados problemas, isso devido ao grande crescimento do volume de dados presente nos bancos de dados de algumas organizações.

Limitações dos bancos de dados relacionais

Nos dias de hoje, o volume de dados de certas organizações, como podemos citar o caso do Facebook, que atingiu o nível de petabytes (em 2011 este volume de dados ultrapassou 30 petabytes (30 mil terabytes), sendo que menos de um ano antes o volume era de 20 petabytes). Este é um exemplo real de como esse crescimento de dados tem expandido rapidamente [11]. No caso destes tipos de organizações, a utilização dos SGBDs relacionais tem se mostrado muito problemática e não tão eficiente.

Os principais problemas encontrados com a utilização do Modelo Relacional estão principalmente na dificuldade de conciliar o tipo de modelo com a demanda da escalabilidade que está cada vez mais frequente.

Podemos tomar como exemplo o próprio Facebook. Digamos que se o sistema está rodando sobre um SGBD relacional e houver um crescimento do número de usuários, consequentemente haverá uma queda de performance. E para superar este problema seria necessário fazer um upgrade no servidor ou aumentar o número de servidores.

Se o número de usuários continuasse a crescer intensamente, tais soluções apresentadas não se mostrariam suficientes, pois o problema passa a se concentrar no acesso à base de dados. Neste caso, o que poderia ser feito para resolver este problema de escalabilidade seria aumentar o poder do servidor, aumentando sua memória, processador e armazenamento. Este tipo de solução é chamado de Escalabilidade Vertical. Por outro lado, poderíamos aumentar o número de máquinas no servidor web, chamamos esta alternativa de Escalabilidade Horizontal [13].

Vamos citar novamente o Facebook, onde suas aplicações continuam sempre a crescer, chega um momento em que o banco de dados não consegue atender todas as requisições em um tempo hábil. Neste momento poderíamos apelar para a Escalabilidade Vertical e fazer o upgrade na máquina em que está rodando o banco de dados. No entanto, chega um momento em que a capacidade da máquina chega ao limite do orçamento para conseguir uma máquina realmente eficiente. Dessa forma, o próximo passo seria utilizar a Escalabilidade Horizontal, ou seja, colocar mais máquinas rodando o banco de dados. Tal tarefa pode parecer simples, porém, no momento em que escalonamos o banco em diversas máquinas é necessário realizar na grande maioria das vezes uma série de configurações e alterações nas aplicações para que tudo funcione como esperado na nova arquitetura distribuída.

Ainda no campo dos exemplos, vamos imaginar um sistema fictício, e que não se sabe ao certo os campos de determinada entidade, agora imagine este mesmo sistema do dia para a noite sendo acessado por milhares e milhares de pessoas. No outro dia, ao observar sua caixa de email você percebe que diversos usuários possuem ideias realmente inovadoras, porém, para implementar essas ideias no seu sistema é necessário que o banco de dados praticamente por inteiro seja refatorado, afinal, será necessário realizar diversas mudanças estruturais na base de dados . Com este problema em mãos podemos perceber que o Modelo Relacional está focado nos relacionamentos entre as entidades e que isso, por muitas vezes, torna mais “burocrática” a implementação de novas funcionalidades, além dos problemas voltados para a escalabilidade que já havíamos falado, quando há um acesso muito grande de usuários ao sistema.

Como esse intenso volume de dados vem aumentando e pela sua natureza estrutural, os desenvolvedores perceberam a dificuldade ao se organizar dados no Modelo Relacional. É neste ponto que o foco das soluções não-relacionadas está direcionado.

Um novo paradigma: Banco de Dados NoSQL

Pensando em solucionar diversos problemas relacionados à escalabilidade, performance e disponibilidade, projetistas do NoSQL promoveram uma alternativa de alto armazenamento com velocidade e grande disponibilidade, procurando se livrar de certas regras e estruturas que norteiam o Modelo Relacional. Se por um lado havia um rompimento das regras do Modelo Relacional, por outro lado havia ganho de performance, flexibilizando os sistemas de banco de dados para as diversas características que são peculiares de cada empresa. Esta flexibilidade passou a se tornar fundamental para suprir os requisitos de alta escalabilidade necessários para gerenciar grandes quantidades de dados, assim como para garantir uma alta disponibilidade destes, característica fundamental para as aplicações Web 2.0. Algumas grandes organizações passaram a investir em seus próprios SGBDs baseando-se na ideia do NoSQL.

O termo NoSQL foi inicialmente utilizado em 1998 a partir de uma solução que não oferecia uma interface SQL, mas este sistema tinha como base o Modelo Relacional. Futuramente, o modelo passou a representar determinadas soluções que se tornavam melhores que a utilização do Modelo Relacional, desde então passou a utilizar a abreviação Not Only SQL (Não apenas SQL) [13]. A proposta dos bancos NoSQL na realidade não é extinguir o Modelo Relacional, mas utilizá-lo em casos onde é necessária uma maior flexibilidade na estruturação do banco.

Este movimento está bastante enraizado no open source. E apesar de existirem muitos bancos de dados nesta categoria, o movimento passou a ganhar mais força quando determinadas empresas consideradas gigantes da tecnologia passaram a utilizar suas próprias implementações proprietárias [14]. Neste caso, podemos citar o Google, que desde 2004 investe no BigTable que foi desenvolvido para suprir as necessidades de armazenamento da empresa, baseado na filosofia do alto desempenho, escalabilidade e disponibilidade [15]. Além disso, temos também o famoso Cassandra, desenvolvido pelo Facebook para lidar com o grande fluxo de informações [16]. Em 2010 o Cassandra mostrou ser um banco de dados consolidado e passou a ser utilizado pelo Twitter, que utilizava o MySQL anteriormente [17].

Temos ainda o Apache CouchDB, que é um banco de dados open source orientado a documentos que projetado especialmente para suportar computação distribuída em larga escala [18].

Apesar da nomenclatura de todos esses bancos de dados serem NoSQL, eles não são completamente iguais, possuem na verdade muitas características semelhantes e muitas particularidades que os diferenciam.

Principais características dos Bancos de Dados NoSQL

Os bancos de dados NoSQL apresentam determinadas características que considero importantes de serem consideradas neste artigo, além disso, são essas características que os tornam tão diferentes dos bancos de dados relacionais. Algumas dessas características são:

• Escalabilidade Horizontal: na medida em que o volume de dados cresce, aumenta-se a necessidade de escalabilidade e melhoria do desempenho. Dentre todas as possibilidades para esta solução, a escalabilidade horizontal se torna a mais viável, porém requer diversas threads ou que processos de um tarefa sejam criadas e distribuídas. Dessa forma, o uso de um banco de dados relacional poderia ser muito complexo. Não queremos dizer que os bancos de dados relacionais não escalam, a verdade é que eles não escalam facilmente. Isto por que no momento em que diversos processos se conectam simultaneamente em um mesmo conjunto de dados há uma geração de uma alta concorrência aumentando assim o tempo de acesso às tabelas. Neste contexto, uma grande vantagem dos bancos NoSQL é justamente a ausência de bloqueios, o que permite a escalabilidade horizontal com uma maior facilidade e eficiência (ele não é afetado pelo aumento da concorrência). Uma alternativa muito utilizada para alcançar a escalabilidade horizontal é o Sharding, que divide os dados em múltiplas tabelas a serem armazenadas ao longo de diversos nós na rede. O que esta técnica faz, na realidade, é romper a cadeia de relacionamentos, que é uma forte característica nos bancos relacionais. É possível realizar o Sharding em banco de dados relacionais de forma manual. Entretanto, esta não é uma tarefa simples e demonstra complexidade de implementação para a equipe que está desenvolvendo [12].

• Ausência de esquema (Schema-free) ou esquema flexível: Outra característica notável em bancos de dados NoSQL é a ausência parcial ou total de esquema que define a estrutura de dados. É justamente essa ausência de esquema que facilita uma alta escalabilidade e alta disponibilidade, mas em contrapartida não há a garantia de integridade dos dados, fato este que não ocorre no Modelo Relacional [20].

• Suporte nativo a replicaçãoEsta é outra forma de prover a escalabilidade, pois, no momento em que permitimos a replicação de forma nativa o tempo gasto para recuperar informações é reduzido [21].

• API simples para acessar o banco de dados: Em banco de dados NoSQL, o foco não está no armazenamento dos dados e sim como recuperar estes dados de forma eficiente. Pensando nisso, é fundamental APIs desenvolvidas para facilitar o acesso às devidas informações para que se possa usar o banco de dados de forma rápida e eficiente.

• Consistência eventual: Outra característica particular de bancos NoSQL é que nem sempre a consistência dos dados é mantida. Esta característica tem embasamento no teorema CAP (Consistency, Availability e Partition tolerance) que afirma que em um dado momento só é possível garantir duas destas três propriedades, que seriam Consistência, Disponibilidade e tolerância à partição [32]. No mundo real, normalmente estas duas últimas são privilegiadas. Como consequência disto, as propriedades do ACID não são respeitadas simultaneamente, ao contrário disto, temos outro conjunto de projetos denominado BASE (Basicamente disponível, Estado leve e consistente em momento indeterminado) [21]. Ou seja, é necessário haver um planejamento para que o sistema possa tolerar inconsistências temporárias com o objetivo de priorizar a disponibilidade.

Agora que falamos brevemente sobre as principais características nos bancos de dados NoSQL, é importante ressaltar algumas técnicas utilizadas para a implementação de suas funcionalidades. Entre elas estão:

• Map/reduce: permite a manipulação de enormes volumes de dados ao longo de nós em uma rede [23]. Funciona da seguinte forma: na fase map, os problemas são particionados em pequenos problemas que são distribuídos em outros nós na rede. Quando chegam à fase reduce, esses pequenos problemas são resolvidos em cada nó filho e o resultado é passado para o pai, que sendo ele consequentemente filho, repassaria para o seu, até chegar à raiz do problema.

• Consistent hashing: suporta mecanismos de armazenamento e recuperação, onde a quantidade de sites está em constante mudança [24]. É interessante usar essa técnica, pois ela evita que haja uma grande migração de dados entre estes sites, que podem ser alocados ou desalocados para a distribuição dos dados.

• MVCC (Multiversion concurrency control): Oferece suporte a transações paralelas em banco de dados. Por não fazer uso de locks para controle de concorrência, faz com que transações de escrita e leitura sejam feitas simultaneamente [25].

• Vector clocks: Ordenam eventos que ocorreram em um sistema. Como existe a possibilidade de várias operações estarem acontecendo simultaneamente, o uso de um log de operações informando suas datas se faz importante para informar qual versão de um dado é a mais atual [21].

Modelos de banco de dados NoSQL

Neste caso, temos quatro categorias do NoSQL que as diferenciam entre si:

• Chave-valor (key-value): Este modelo é considerado simples e permite a sua visualização através de uma tabela de hash, no qual há uma chave única e um indicador de determinado dado, podendo ser uma String ou um binário [27]. A Figura 1 apresenta um exemplo que armazena informações com estas características. A chave representa um campo como nome e idade e o valor representam os campos preenchidos com Mara Rúbia e 43, ou seja, a instância para o campo correspondente. Este modelo é caracterizado pela sua facilidade ao ser implementado, permitindo que os dados sejam acessados rapidamente através da chave, aumentando também a disponibilidade do acesso aos dados. Para manipulá-los, utilizamos comandos simples como get() e set(), que retornam e capturam valores. Um problema enfrentado por este tipo de banco de dados é que o mesmo não permite a recuperação de objetos através de consultas mais complexas. Como exemplo, podemos citar o Dynamo que foi desenvolvido pela Amazon como solução de alta disponibilidade para suas necessidades [28].

Figura 1. Campos e informações

• Banco de Dados Orientado a Documento: Como o próprio nome sugere, este modelo armazena coleções e documentos. Explicando melhor, um documento, no geral, é um objeto identificador único e um conjunto de campos que podem ser strings, listas ou documentos aninhados [27]. Diferente do banco de dados chave-valor onde se cria uma única tabela hash, neste modelo temos um agrupamento de documentos sendo que em cada um destes documentos temos um conjunto de campos e o valor deste campo. Neste modelo temos ausência de esquema pré-definido (schema free). Isto significa que é possível que haja atualizações no documento, com a adição de novos campos, por exemplo, sem afetar adversamente outros documentos. Outra característica interessante é que não é necessário armazenar valores de dados vazios para campos que não possuem um valor. Na Figura 2 temos o exemplo de um determinado documento que foi definido por: Assunto, Autor, Data, Tags e Mensagens. Caso eu deseje implementar outro campo chamado “Minha opinião sobre o site:”, não haverá nenhum tipo de restrição ou complexidade de inserir tal dado no banco de dados, esta flexibilidade é um ponto forte neste tipo de modelo. Como exemplo de sistema de banco de dados que utiliza este tipo de solução destacamos o CouchDB e o MongoDB. O CouchDB utiliza o formato JSON e é implementado em Java. Já o mongo é implementado em C++ e permite tanto concorrência quanto replicação.

Figura 2. Documento com informações

• Orientado a Coluna (column family): Demonstra maior complexidade que o de chave-valor. Este tipo de banco de dados foi criado para armazenar e processar uma grande quantidade de dados distribuídos em diversas máquinas. Aqui existem as chaves, mas neste caso, elas apontam para atributos ou colunas múltiplas. Neste caso, os dados são indexados por uma tripla (coluna, linha e timestamp), a coluna e linha são identificadas por chaves e o timestamp permite diferenciar múltiplas versões de um mesmo dado [14]. Como o próprio nome sugere, as colunas são organizadas por família da coluna. Vale destacar que as operações de escrita e leitura são atômicas, ou seja, os valores associados a uma linha são considerados em sua execução, independente das colunas que estão sendo lidas/escritas. O conceito associado a este modelo é o de família de colunas, com o objetivo de reunir colunas que armazenam o mesmo tipo de informação. Como exemplo, a Figura 3 modela o conceito de amigos, onde o primeiroNome e sobrenome são colunas pertencentes à família de colunas denominada “nome”. Da mesma forma, as colunas endereço, cidade e estado pertencem à família local. É interessante observar que na linha 001 a pessoa Mara tem diversos endereços. Como a busca neste tipo de banco de dados é atômica, mesmo que o interesse seja buscar o primeiroNome da linha 001, todas as colunas serão retornadas quando esta mesma linha for consultada. Este modelo permite ainda o particionamento de dados, oferecendo forte consistência, no entanto, a alta disponibilidade é o seu ponto fraco. Este modelo de dados surgiu com o BigTable criado pelo Google [15]. Além do BigTable temos também o Cassandra que foi desenvolvido pelo Facebook [16].

Figura 3. Representação de amigos

• Orientado a Grafos: este modelo possui três componentes básicos: nós (vértices dos grafos), os relacionamentos (arestas) e as propriedades (conhecidos também como atributos). Este modelo é visto como multigrafo rotulado e direcionado, onde cada par de nós pode ser conectado por mais de uma aresta. A utilização deste modelo é muito útil quando é necessário fazer consultas demasiadamente complexas. O modelo orientado a grafos possui uma alta performance, permitindo um bom desempenho nas aplicações [27]. Para exemplificar o que foi dito, podemos analisar a Figura 4 que representa uma aplicação que mantêm informações relativas à viagem. Uma consulta pertinente seria: “Quais cidades foram visitadas anteriormente por pessoas que foram para Nova Iorque?”. No modelo de banco de dados relacional tal consulta poderia se mostrar complexa, pois não permitem que os dados sejam representados de uma forma natural.

Como exemplo, podemos citar o Neo4j que é um banco de dados open source. O Neo4J trata-se de um banco de dados baseado em grafos desenvolvido em Java. Além de possuir suporte completo para transactions, ele também trabalha com nós e relacionamentos. Ainda no exemplo da Figura 4, temos diversas pessoas: João, Ricardo, Carolina, Maria, Fernando e Fábio que representam nós do grafo e estão conectadas a cidades que visitaram ou residiram. Por exemplo: Ricardo viajou para Roma e Bruxelas e já residiu em Toronto e Paris. A partir de cada cidade, precisamos dos relacionamentos de entrada que também sejam do tipo “viajou” e com isso encontramos pessoas que viajaram para o mesmo lugar que Ricardo, neste caso, Carolina e Fernando.

Figura 4.Nós do grafo

Levando em consideração tudo o que foi dito, é fundamental ressaltar que nenhum modelo é superior a outro. Na realidade, o que ocorre é que um modelo pode ser mais adequado para ser utilizado em certas situações. Por exemplo, para a utilização de um banco de dados de manipulação de dados que frequentemente serão escritos, mas não lidos (um contador de hits na Web, por exemplo), pode ser usado um banco de dados orientado a documento como o MongoDB. Já aplicativos que demandam alta disponibilidade, onde a minimização da atividade é essencial, podemos utilizar um modelo orientado a colunas como o Cassandra. Aplicações que exigem um alto desempenho em consultas com muitos agrupamentos podem utilizar um modelo orientado a grafos.

O importante é que no momento da criação do aplicativo os desenvolvedores utilizem a melhor solução que se encaixa no perfil desejado. Utilizar a solução adequada ao criar o banco de dados significa uma diminuição dos custos para a sua criação, assim como um banco eficiente no processamento de dados do ponto de vista das suas necessidades.

Principais diferenças entre SGBDs Relacionais e NoSQL

A partir do momento em que se pensa na possibilidade de utilizar um banco de dados NoSQL ao invés de um modelo relacional, é preciso levar algumas questões em consideração, como critérios de escalonamento, consistência e disponibilidade de dados. Vamos apresentar algumas discussões comparativas mais marcantes no que se diz respeito a estes três conceitos.

Falar sobre escalabilidade é essencial porque é neste aspecto que os bancos de dados NoSQL possuem uma grande vantagem em relação aos SGBDs tradicionais, basicamente por terem sido criados para essa finalidade. Os bancos de dados relacionais possuem uma estruturação que não a permite tanta flexibilidade, além disso, é menos adaptada para situações em que o escalonamento se faz necessário.

Para alcançar uma melhor escalabilidade, os bancos de dados relacionais utilizam o recurso da escalabilidade vertical (scale up) que tem como característica a simplicidade de sua implementação e esta tem sido a forma mais indicada para se realizar o escalonamento do banco de dados. A partir do momento em que uma aplicação está sendo demasiadamente acessada por um número muito grande de usuários, este tipo de escalonamento passa a não ser mais suficiente. O próximo passo consiste em escalonar o próprio banco de dados, que consiste basicamente em distribuir o banco em várias máquinas, particionando os dados. Conhecido também como sharding ou escalonamento horizontal. Esse tipo de escalonamento se mostra muito complexo ao ser implementado em um SGBD relacional devido à dificuldade em se adaptar a toda estrutura lógica do Modelo Relacional, primeiro porque os SGBDs relacionais obedecem aos critérios de normalização e o processo de sharding vai contra a tudo isso, pois se caracteriza pela desnomarlização dos dados. Segundo ponto, há uma mudança de paradigma em relação ao processo de escalonamento. Enquando SGBDs tradicionais trabalham para reforçar o servidor, o sharding tem como objetivo trabalhar com o escalonamento horizontal, distribuindo seus dados em diversos setores. Terceiro ponto, o volume de dados por máquina é minimizado devido a esta distribuição, afinal, conjunto de dados menores são mais simples de serem gerenciados, acessados e atualizados. Por último, a disponibilidade do sistema é otimizada em relação ao modelo relacional, pelo fato de que se houver a queda do sistema em uma máquina não irá causar a interrupção do mesmo.

Esta questão da disponibilidade demonstra muita preocupação em determinadas organizações. Podemos citar um evento que ocorreu em 2008, em que a rede social Twitter ficou fora do ar durante 84 horas, neste evento o Twitter ainda utilizava o PostgreSQL, sendo considerada a rede social mais instável daquele ano [30]. A partir de 2009, quando começou a utilizar o Cassandra, outro evento similar ocorreu, porém o site ficou fora dor ar durante 23 horas e 45 minutos [17].

Neste quesito, o banco de dados NoSQL se destaca pela maior disponibilidade, maior rapidez nas consultas, paralelismo de atualização de dados e maior grau de concorrência.

Os bancos de dados NoSQL foram projetados para este fim, e da forma mais simples e natural possível. Como exemplo podemos citar o MongoDB que inclui um módulo de sharding automático que permite a construção de um cluster de banco de dados escalado horizontalmente para, dessa forma, incorporar novas máquinas de forma dinâmica [19].

Outra coisa que devemos notar ao fazer a comparação de uma banco de dados relacional e NoSQL é no que se refere ao controle de concorrência. Se por um lado, no Modelo Relacional utilizamos locks para garantir que dois usuários não acessem o mesmo item simultaneamente, no banco de dados NoSQL utilizam-se outras estratégias que acabam por permitir um maior grau de concorrência. Para citar uma dessas estratégias podemos citar como exemplo o banco de dados CouchDB que utiliza o MMVC. A ideia principal é criar diversas versões dos documentos e permitir a atualização sobre uma dessas versões mantendo ainda a versão desatualizada. Agindo dessa forma não há a necessidade de bloquear os itens dos dados.

Ao se pensar em substituir um banco de dados relacional por um NoSQL, a arquitetura fica vulnerável à perda de consistência, porém, pode-se ganhar em flexibilidade, disponibilidade e performance. Outra coisa interessante para ser destacada são as diferenças de paradigmas utilizadas no Modelo Relacional e nos bancos NoSQL. No que diz respeito a este primeiro, temos o ACID que força a consistência ao final de cada operação, já o paradigma BASE, que é utilizado comumente pelo segundo, permite que o banco de dados eventualmente seja consistente, ou seja, o sistema só torna-se consistente no seu devido momento.

Para compreendermos melhor todas essas diferenças, observe a Tabela 1 que exemplifica de forma concisa alguns dos conceitos descritos neste artigo.

Banco de Dados Relacional Banco de Dados NoSQL
Escalonamento É importante lembrar que é possível ser feito o escalonamento em um Modelo Relacional, no entanto, é muito complexo. Possui uma natureza estruturada, portanto, a inserção dinâmica e transparente de novos nós a tabela não é realizada naturalmente. Não possui um esquema pré-definido fazendo com que este tipo de modelo seja flexível o que favorece a inserção transparente de outros elementos.
Consistência Neste quesito, o Modelo Relacional se mostra forte. As suas regras de consistência são bastante rigorosas no que diz respeito à consistência das informações. É realizada eventualmente no modelo: tem apenas a garantia que se não houver nenhuma atualização nos dados, todos os acessos aos itens devolverão o último valor que foi atualizado.
Disponibilidade Por não conseguir trabalhar de forma eficiente com a distribuição de dados, o Modelo Relacional acaba não suportando uma demanda muito grande de informações. Outro ponto forte neste modelo é o que diz respeito à disponibilidade, pois possui um alto nível de distribuição de dados, permitindo assim que seja possível fazer com que um enorme fluxo de solicitações aos dados seja atendido com a vantagem do sistema ficar indisponível o menor tempo possível.

Tabela 1. Análise comparativa entre Banco de Dados Relacional e NoSQL

Conclusão

Com o grande crescimento do volume de dados em determinadas organizações, os bancos de dados NoSQL tem se tornado uma grande alternativa quando nos referimos a escalabilidade e disponibilidade, fatores estes que se tornam imprescindíveis em algumas aplicações Web.

Para realizar a migração de um SGBD Relacional para um banco de dados NoSQL é preciso levar diversos fatores em consideração. A empresa em questão deve mensurar as diversas vantagens e desvantagens propostas por ambos os modelos, e estes critérios de comparação são dos mais diversos tipos, indo desde a escalabilidade do sistema, passando por avaliação sobre consistência de dados e quão importante é a disponibilidade do banco de dados para o sistema.

Em relação a bancos de dados relacionais, sabemos da sua “experiência” no mercado, no qual é utilizado em larga escala. Além disso, sabemos da solidez de suas soluções que são mais maduras e experimentadas. Enquanto isso, os bancos de dados NoSQL ainda estão conquistando seu espaço no mercado e definindo os seus próprios padrões. Além disso, sabemos que para diversas organizações a consistência de dados se torna um fator determinante e as transações através dos SGBDs Relacionais são a melhor alternativa para lidar com esse problema.

Por outro lado, temos o problema do grande volume de dados enfrentado por diversas empresas, assim como a necessidade que estes sistemas estejam disponíveis para os seus usuários. Nestas situações, os bancos de dados NoSQL acrescentam diversos pontos positivos, primeiro pela sua possibilidade de escalonamento e pela simplicidade do seu modelo, onde não há esquemas pré-definidos, e segundo pela existência de uma grande distribuição de dados, oferecendo assim um maior suporte de solicitações a estes dados para serem atingidos. Adicionalmente, é importante ressaltar que uma escalabilidade em alto grau se faz necessária a empresas que utilizam um banco de dados de grande porte e onde a disponibilidade é um fator decisivo. Acredito que a utilização de um banco de dados NoSQL onde a escalabilidade e a disponibilidade não se demonstre determinante, ainda é algo que é necessário discutir.

Neste sentido, este artigo teve a finalidade de explicar as principais características dos bancos de dados NoSQL e de forma mais concisa o banco de dados Relacional, assim como realizar algumas análises comparativas entre estes dois modelos que atualmente disputam e complementam o mercado. Ressaltando que não existe um banco de dados superior ao outro, a decisão do uso de cada um se refere à necessidade que a empresa está enfrentando.

Referências1. http://www.jornaltemporeal.com/2010/06/10/o-crescimento-da-internet-o-avanco-da-tecnologia-pelo-mundo/

2. http://nosql-database.org/

3. http://uniredes.org/kb/?View=entry&EntryID=224

4. http://www.ime.usp.br/~andrers/aulas/bd2005-1/aula11.html

5. http://www.dicasparacomputador.com/pesquisa-revela-que-empresas-tem-dificuldade-administrar-grandes-volumes-dados.

6. http://www.infoq.com/br/news/2011/08/facebook-maior-migracao.

7. http://escalabilidade.com/2010/03/08/introducao-ao-nosql-parte-i/.

8. http://blog.caelum.com.br/bancos-de-dados-nao-relacionais-e-o-movimento-nosql/

9. F. Chang , J. Dean , S. Ghemawat , W. C. Hsieh , D. A. Wallach , M. Burrows , T. Chandra , A. Fikes , R. E. Gruber, “Bigtable: A distributed storage system for structured data”, In Proceedings of the 7th Conference on Usenix Symposium on Operating Systems Design And Implementation, Volume 7, 2006.

10. Lakshman, P. Malik, “Cassandra – A Decentralized Structured Storage System”, LADIS 2009.

11. http://computerworld.uol.com.br/tecnologia/2010/02/23/crescimento-faz-twitter-trocar-o mysql-pelo-cassandra/.

12. J. C. Anderson, N. Slater, J. Lehnardt,, “CouchDB: The Definitive Guide”, 1ª edição, O’Reilly Media, 2009.

13. http://www.mongodb.org/.

14. http://www.igvita.com/2010/03/01/schema-free-mysql-vs-nosql/.

15. http://dbpedias.com/wiki/NoSQL:Consistency_Models_in_Non-Relational_Databases.

16. http://ccsl.ime.usp.br/wiki/images/2/20/NoSQL_Vantagens_Desvantagens_e_Compromissos.pdf.

17. http://www.nosqldatabases.com/main/tag/consistent-hashing.

18. http://dbpedias.com/wiki/NoSQL:Consistency_Models_in_Non-Relational_Databases.

19. https://www.ibm.com/developerworks/mydeveloperworks/blogs/fd26864d-cb41-49cf-b719-d89c6b072893/entry/escolhendo_a_ferramenta_certa_para_o_banco_de_dados_nosql1?lang=en.

20. http://www.allthingsdistributed.com/2007/10/amazons_dynamo.html.

21. http://nosqlba.com.br/.

22. http://idgnow.uol.com.br/internet/2009/02/19/twitter-e-o-servico-social-mais-instavel durante-2008-aponta-estudo/.

23. http://www.ffb.edu.br/sites/default/files/tcc-20102-gleidson-sobreira-leite.pdf .

24. W. Vogels, “Eventually Consistent”, Scalable Web Services, Volume 6 No. 6, Outubro de 2008.

Fonte: https://www.devmedia.com.br/banco-de-dados-nosql-um-novo-paradigma-revista-sql-magazine-102/25918