Java e MongoDB. Há muito tempo se utilizava arquivos sequenciais. mongodb_. O desenvolvimento de uma aplicação

Transcrição

1 mongodb_ Java e MongoDB Há muito tempo se utilizava arquivos sequenciais para armazenamento de dados (os famosos arquivos.dat), depois veio a migração para banco de dados relacional. Desde esta última evolução, nunca houve questionamento em relação ao modelo de banco de dados a ser utilizado, o questionamento, quando havia, era sobre a compra de licença ou do expertise das equipes da empresa em trabalhar com um ou outro banco de dados. Após problemas de escalabilidade, custo e performance, muitas empresas começaram a pesquisar e a investir em novos mecanismos de armazenamento. Entre elas: Facebook com o Cassandra, Google com o BigTable e Linkedin com o Voldemort. Tais bancos de dados são considerados NoSQL, onde não existe obrigatoriedade quanto ao modelo também não suportam joins entre as tabelas. colher um banco de dados NoSQL que esteja na moda e este resolverá todos os seus problemas quanto a escalabilidade. Existem alguns modelos de bancos de dados e cada qual focado em resolver um ou mais problemas, vide quadro Tipos de bancos de dados NoSQL. O objetivo deste artigo é mostrar ao leitor como O desenvolvimento de uma aplicação onde seja requerido o armazenamento de grandes volumes de dados pode ser bastante custoso não só para o tempo de desenvolvimento, mas principalmente para a manutenção do sistema e também para a infraestrutura. Neste artigo, é mostrado como utilizar o MongoDB, um banco de dados NoSQL com Java utilizando o Morphia nesta comunicação. trabalhar na prática com Java e MongoDB, que é um banco de dados NoSQL orientado a documentos e um dos mais genéricos dos bancos de dados NoSQL. Utilizar um banco de dados relacional em um sistema que terá um grande volume de acessos até há alguns anos poderia ser a única solução, incluindo neste cenário muito dinheiro com licenças de softwares, arquiteturas complexas e times de especialistas a preço de ouro. A partir de meados da década de 90, começaram mais fortemente as pesquisas sobre formas alternativas de armazenamento de dados que não tivessem como base os bancos de dados relacionais. Entre essas soluções, pode-se citar: banco de dados orientado a documentos, banco de dados tabular. Tais soluções começaram a ser utilizadas de forma comercial focadas na solução de alguns mazenar dados em cache, ou seja, em vez de buscar dados do banco de dados ou mesmo de arquivos em disco, no caso de arquivos estáticos, poderia se lan- valor em memória com persistência em disco para acelerar a entrega deste conteúdo. Um banco de dados que desempenha muito bem este papel é o Redis. / 10

2 Marcio Garcia Bacharel em Ciência da Computação. Trabalha com Java desde Já trabalhou em empresas de pequeno e grande porte bem cações SCJP, SCWCD, SCBCD, SCEA I e CSM. Atualmente, é desenvolvedor de Software freelancer, e mantém dois blogs: mangar.com.br e No entanto, utilizar um banco de dados como este como alternativa a um banco de dados relacional é praticamente impraticável, principalmente considerando a utilização de um banco de dados orientado a documentos como o MongoDB. Um banco de dados orientado a documentos é o que mais se assemelha a um banco de dados relacional, mas com a vantagem, no caso dos NoSQL, de não Bancos de dados NoSQL, embora não sejam ACID, são muito rápidos na resposta a queries e escaláveis horizontalmente. Ou seja, para problemas de performance na aplicação, de forma geral, basta lancer dependendo da arquitetura seguida. Neste artigo, é considerada a utilização do Mon- uma equipe de desenvolvimento e uma comunidade bastante ativa que ajuda na localização e correção de bugs. Vamos começar pela instalação do MongoDB. Iniciando com o MongoDB Vamos iniciar obtendo o binário do banco de dados. O MongoDB está disponível gratuitamente para praticamente todas as plataformas, Windows, Linux, Linux. Pouquíssimos ajustes são necessários para funcionar no Windows e, sempre que necessário, são feitas pequenas considerações a respeito. Toda a troca de informação entre a aplicação e o servidor do banco de dados se dá, em linhas gerais, Figura 1. MongoDB inicializado na porta padrão: Figura 2. Criando e obtendo registro via console do MongoDB. com troca de mensagens de texto em formato JSON. O binário do MongoDB pode ser obtido através do site do MongoDB: wnloads. No momento que este artigo é escrito, a última versão estável é a E é nela que se baseiam todos os exemplos apresentados neste trabalho. Uma vez com o arquivo em seu computador, descompacte-o. Será necessário que manualmente sejam criados dois diretórios, que será onde os dados serão armazenados. Por padrão, estes diretórios serão buscados pelo MongoDB dentro do diretório- -raiz do seu drive. No Windows: C:\data\db, no *nix: jeto sob controle, vamos criar esta estrutura dentro do nosso próprio diretório binário. No Windows e no *nix: Vamos tratar o diretório em que você descompactou o banco de dados como MONGO_DIR Criado o diretório de dados, é hora de iniciar o banco de dados. Execute o comando: Testando a instalação do MongoDB Com o MongoDB em execução, podemos fazer um teste simples de conexão via linha de comando, de que tudo está correto com o banco de dados. No Windows, apenas dê um duplo clique no executável do mongo (MONGO_ *nix abra um novo terminal, e digite: mongo Uma vez conectado no console, ele informará a versão do MongoDB que está em execução e automaticamente você já estará conectado ao bando de dados test. 11 \

3 Vamos criar um banco de dados para armazenar os estados do Brasil. Conectado ao console do MongoDB, digite: db.estados.save({ sigla : SP, nome : São Paulo ) Caso você não utilize Maven em seus projetos e reto à área de download no site do Morphia. Vamos começar a detalhar o funcionamento das operações de inclusão, alteração, exclusão e seleção de registros (o famoso CRUD), apresentando um código bastante simples, mas que abrange cada uma das operações básicas utilizando MongoDB com Morphia. Após este primeiro contato, teremos um pouco mais de familiaridade para evoluir com criação de índices, busca avançada de registros e referências. Neste momento já temos o MongoDB instalando e funcionando perfeitamente. Vamos ver agora o processo de comunicação e manipulação de dados através de uma aplicação Java. Java e MongoDB As informações no MongoDB são organizadas de forma diferente dos bancos de dados relacionais que estamos acostumados. Em vez de tabelas, as informações são armazenadas em coleções. A comunicação com o servior MongoDB é feito através de socket, e a forma de troca de informação é feita nativamente através de JSON. Para quem está acostumado com JPA, abrir um socket e trocar JSONs é um tanto estranho e com certeza, na utilização frequente, mesmo utilizando bibliotecas para facilitar a geração e interpretação de JSON, este procedimento se mostrará bastante trabalhoso além de improdutivo. Em vez disso, utilizaremos um dos drivers mais maduros e independentes para comunicação entre uma aplicação Java e o MongoDB, o Morphia. Existem outros drivers para Java ou mesmo para Groovy, Scala, Clojure, JRuby e várias outras linguagens que rodam sobre a JVM. Neste artigo, é utilizado o Morphia, por se mostrar mais maduro e independente de frameworks externos, como é o caso do Spring MongoDB. - no seu pom.xml é esta: Listagem 1. Dependência do MavenDepCriando e obtendo registro via console do MongoDB. / 12 <dependency> <groupid>com.google.code.morphia</groupid> <artifactid>morphia</artifactid> <version>0.99</version> </dependency> Um CRUD de exemplo Iniciando pelo básico, vamos detalhar uma classe que obtém, insere, atualiza e exclui registros de uma coleção. A listagem completa pode ser obtida no site da MundoJ, e vamos mostrar aqui as partes mais relevantes do nosso primeiro CRUD. Vamos utilizar um objeto chamado Estado. Esta é uma classe anotada que representa a nossa coleção. Neste ponto, apenas utilizaremos esta classe. No próximo tópico, vamos descrever os itens mais importantes no mapeamento entre objeto vs. coleção. Comecemos pela conexão com o banco de dados. Esta deve ser feita utilizando um objeto do tipo Datastore, onde é passado como parâmetro um objeto do tipo Mongo, que pode receber como parâmetro o endereço do servidor e a porta de conexão. Vamos ções padrão. O segundo parâmetro é o nome do banco de dados a ser conectado. Todo código da Listagem 2 até a Listagem 7 está na classe mg.mundoj.mongodb.appmorphiasimple. Listagem 2. Conexão com o servidor MongoDB. private Datastore ds; private Mongo mongo; public AppMorphiaSimple() throws Exception { mongo = new Mongo(); ds = new Morphia().createDatastore(mongo, test ); Assim que concluímos a instalação do servidor MongoDB, inserimos um registro na coleção chamada estados. Pois bem, vamos consultar novamente a nossa coleção e obter este registro dentro da aplicação. Vamos utilizar o método get(). Este método retorna o primeiro registro da coleção. Listagem 3. Obtendo o primeiro registro da coleção Estados. public void getfirst() { Estado e = this.ds. (Estado.class).get(); System.out.println(e.sigla e.nome);

4 Vamos ver como inserir um registro em nossa coleção. Para salvar um novo registro, basta inicializar uma classe mapeada para uma coleção e acionar o método save(entity) da classe Datastore. Listagem 4. Inclusão do registro na coleção: estados. public void createone() { new Estado( RJ, Rio de Janeiro ); ds.save Com mais um registro na coleção estados, vamos obter todos os registros que já estão presentes nesta utilizando um novo elemento, a classe Query. Este objeto é criado a partir do Datastore. O primeiro parâmetro é a Entity. Após, obtemos a listagem de todos - List() da classe Query. Listagem 5. Obtendo todos os registros da coleção. public void getall() { Query query = ds.createquery(estado.class); List<Estado> listaestados = q.aslist(); for (Estado estado : listaestados) { System.out.println(estado.sigla estado.nome); Excluir um documento é uma tarefa bem simples e pode ser executada por meio do objeto Query, como exibido na Listagem 6. Os detalhes do funcionamento do objeto Query são descritos mais adiante, onde é tratada a busca de documentos. Listagem 6. Excluindo um documento. public void deletelast() { Query query = ds.createquery(estado.class). ( sigla ).equal( RJ ); ds.delete(q); A atualização de um documento é executada em três passos: encontrar o documento a ser alterado, fazer a dor. A Listagem 7 mostra todas essas etapas. Listagem 7. Atualizando um documento. public void updatesp() { Query q = ds.createquery(estado.class). ( sigla ). equal( SP ); UpdateOperations<Estado> estadosupdate = super.ds.createupdateoperations( Estado.class).set( nome, Sao Paolo ); ds.update(q, estadosupdate); Agora, com os primeiros passos de como manipular registros na base de dados do MongoDB, vamos dar uma olhada mais detalhada em cada uma dessas etapas, iniciando pelo mapeamento entre uma classe e uma coleção no banco de dados. Documento Em nosso primeiro exemplo, Listagens 2 a 5 uti- responsável por mapear o objeto e o documento no banco de dados, nesta parte, vamos detalhar como este mapeamento pode ser feito e como o Morphia trata este mapeamento. Nossa entidade foi criada como mostrado na Listagem 8. Utilizamos três anotações do MongoDB para fazer este responsável pelo mapeamento entre a classe e o documento no banco de dados. Opcionalmente recebe o primeiro parâmetro que é o nome da coleção no parecida com da JPA. Esta é a chave primária do nosso esta anotação faz o mapeamento similar mas no nível de campos do nosso documento. A anotação é opcional, e caso ela seja omitida, o Morphia fará o mapeamento de mesmo nome entre o campo do objeto e o campo no documento. Listagem 8 e estados ) public class Estado sigla ) public String sigla; public veremos com detalhes a seguir campos anotados Embedded servem como apontamento ou chaves estrangeiras para outros também tratado em detalhes 13 \

5 adiante, esta anotação cria um índice para o campo em questão. Bastante útil quando existe carga elevada de consulta baseada no campo em campos com esta anotação não serão persistidos no o conteúdo do objeto será armazenado em um campo este campo não será armazenado no banco de dados, apenas transferido do documento para o objeto. Comportamento diferente que, além de não ser armazenado no banco de dados, também não será carregado. Ainda existem algumas anotações dedicadas ao ciclo de vida da entidade sendo ativadas sempre que um objeto é enviado ao servidor ou recebido do servidor. Estas anotações atuam como callback para o método chamado imediatamente antes do objeto ser salvo no banco de chamado logo após o MongoDB chamado antes de popular o objeto com os valores do documento no banco de chamado logo após os campos do objeto serem populados com os valores do documento. Os métodos de callback anotados podem receber um parâmetro do tipo DBObject, que é uma cópia do documento que está sendo trabalhado no momento, antes ou depois de gravar no banco de dados. Pode-se ver as assinaturas e a utilização das anotações na Listagem 9. callback para cada evento, por exemplo, pode-se ter mais de um para uma mesma entidade. Não existem ainda métodos de callback para registros a serem excluídos. Listagem void postload() { + new Date()); Adicionalmente, pode-se utilizar a EntityListeners informando como parâmetro uma classe com os métodos anotados referentes ao ciclo de vida da entidade. Desta forma, a classe de modelo tivas ou genéricas para todos os modelos, como, por classe da entidade passando como parâmetro o nome da classe que implementará esta classe. Listagem 10. public class EstadoEventListener void EstadoEventListener... + new Date()); Embedded tados e adicionar mais duas novas entidades: Cidade e Bairros. Ou seja, um estado poderá ter mais de uma cidade e uma cidade poderá ter zero ou vários bairros. Ambas as anotações são bastante autoexplicativas: enquanto cria uma referência entre um documento e outro, cria um documento dentro de outro. Vamos ver na prática como funciona uma e outra, a void prepersist + new void postpersist + new void preload() { + new Date()); Uma referência entre documentos é a criação de um link (foreign key) entre um documento e outro. Em nosso exemplo, vamos entre as entidades Cidade e Estado. Na Listagem 11 é mostrada a estrutura da entidade Cidade, e na Listagem 12 a utilização desta referência. Listagem 11. referência à entidade cidades ) public class Cidade { / 14

6 @Id public public String public Estado estado; Listagem 12. a entre cidades e estados. protected void criarcidades() { Estado sp = ds. (Estado.class). ( sigla ). equal( SP ).get(); Cidade cidade = new Cidade(); cidade.nome = Sao Paulo ; cidade.estado = sp; super.ds.save(cidade); protected void listarcidades() { for (Cidade cidade : super.ds. (Cidade.class)) { System.out.println(cidade); protected void alterarsp() { Query<Estado> q = super.ds.createquery(estado.class). ( sigla ).equal( SP ); UpdateOperations<Estado> estadosupdate = super.ds.createupdateoperations( Estado.class).set( nome, São Paulo ); super.ds.update(q, estadosupdate); public static void main(string[] args) throws Exception { AppCidadeReferencia app = new AppCidadeReferencia(); app.criarcidades(); app.listarcidades(); app.alterarsp(); app.listarcidades(); Repare que tínhamos um registro no documento de estado: sigla: SP nome: Sao Paolo. Criamos uma nova cidade e associamos a ela este estado. Em um segundo momento, foi alterado o nome deste estado para o nome correto: São Paulo. Quando executamos o método: app.listarcidades() novamente, o nome do estado foi alterado de fato para todas as cidades que tinham uma referência para este estado. Agora, em nosso banco de dados, existem duas coleções de documentos: estados e cidades. Outra modalidade de referência de documentos são os documentos embutidos, anotados Estes não possuem uma coleção física fora da entidade pai, ou seja, se tentar obter uma listagem via console desta coleção, não será possível. O principal motivo é que este documento referenciado está presente apenas no objeto pai. Voltando para nosso exemplo, vamos criar Embedded para os bairros de uma cidade. No trecho de código a seguir é mostrada esta alteração na classe public List<Bairro> bairros; Pode-se ver na Listagem 13 que o objeto Bairro não possui um campo com a e nem a anotação de por se tratar de um documento que apenas faz parte do documento Cidade, e fora deste contexto, o documento Bairro não existe. Este é apenas um POJO. Listagem 13. public class Bairro { public String nome; de cidades após a utilização dos bairros Obtendo registros (documentos) Os documentos são obtidos do banco de dados por meio da interface Query. Existem duas formas - leitor, e não existe benchmark com a informação de é mais legível. Desta forma, também é possível criar queries dinâmicas, observando os parâmetros de entrada quando utilizado um DAO, por exemplo. Na Listagem 14 é mostrada a classe AppQuery e a utilização do Filter, e na Listagem 15, na mesma clas- Listagem 14. utilizando Filter. public void (String sigla) { Estado estado = super.ds.createquery( Estado.class). ( sigla =, sigla).get(); 15 \

7 Query<Cidade> q = super.ds.createquery( Cidade.class). ( estado =, estado);.. Listagem 15. utilizando Interface Fluente. public void (String sigla) { Estado estado = super.ds.createquery(estado.class). ( sigla ).equal(sigla).get(); Query<Cidade> query = super.ds.createquery( Cidade.class); query. ( estado ).equal(estado);.. for (Cidade cidade: query.fetch()) { System.out.println(cidade); Dependendo do que é esperado como retorno, um método do objeto Query deve ser chamado. Por exemplo, se você espera que apenas um registro seja retornado na query, chame o método get(). Veja abaixo os resultados possíveis.» get(): retorna apenas um objeto, o primeiro da listagem.» aslist(): retorna uma lista de objetos como resultado.» fetch(): obtém um Iterable de objetos.» askeylist() com apenas o Id do objeto. Muito útil e rápido quando é necessário apenas o Id do objeto.» fetchemptyentities(): um mix entre o fetch() e o askeylist(), este retorna uma lista contendo apenas o Id do objeto. As duas formas mais utilizadas são o get() e o fetch(), exibidos na Listagem 15. Os demais serão deixados como exercício para o leitor avaliar as reais utilidades das mesmas. Operadores A listagem completa de operadores pode ser obtida no site do Morphia (na tabela 1 são mostrados Figura 3. Coleções de cidades e estados em nosso banco de dados. Figura 4. Status da coleção cidades após a associação de bairros. Filter Fluente = Equal!=, <> notequal > greaterthan < lessthan >= greaterthanoreq <= lessthanoreq Tabela 1. Relação dos operadores. Ordenação de registros A ordenação dos registros acontece chamando-se cessário informar mais de um campo para ordenação, basta separá-los por vírgulas. Por padrão, a ordenação é feita em ordem ascendente, e para inverter a ordem (descendente), basta incluir o caracter - no começo do campo. Na Listagem 16 é mostrada a utilização do método order e suas opções. Listagem 16. mentos. public void showorderbynome() { Query<Cidade> q = super.ds.createquery( Cidade.class).order( nome, estado.sigla ); public void showdescorderbynome() { Query<Cidade> q = super.ds.createquery( Cidade.class).order( -nome ); Limit e Offset Limit e Offset são duas opções bastante úteis quando é necessário, por exemplo, mostrar registros agrupados ou em quantida- utilização é bastante parecida com a ordenação, incluindo a chamada de um método Offset e Limit podem ser utilizadas juntas para que a paginação possa ocorrer na camada do banco de dados. Na Listagem 17 é mostrado como utilizar ambas as funções. / 16

8 Listagem 17. Limite e Offset. public void all() { System.out.println( \n all() ); /referências Query<Cidade> q = super.ds.createquery(cidade.class); public void limit(int no) { System.out.println( \n limit( + no + ) ); Query<Cidade> q = super.ds.createquery(cidade.class). limit(no); public void offset(int no) { System.out.println( \n----- offset( + no + ) ); Query<Cidade> q = super.ds.createquery(cidade.class). offset(no); public void offsetlimit(int noo, int nol) { System.out.println( \n offsetlimit( + noo +, + nol + ) ); Query<Cidade> q = super.ds.createquery(cidade.class). offset(noo).limit(nol); A utilização de um banco de dados orientado NoSQL depende, e muito, das características de cada aplicação e suas necessidades e limites técnicos e não-técnicos. O Morphia é uma alternativa muito produtiva em comparação com o driver nativo Java para o MongoDB. Sua curva de aprendizado para quem está acostumado a trabalhar com JPA é bastante reduzida. A parte mais difícil é se adaptar ao mecanismo orientado a documentos do MongoDB, que acredi- tempo de desenvolvimento e manutenção da apli- documentos podem ser manipulados. Tipos de bancos de dados NoSQL Existe alguns tipos de bancos de dados NoSQL, cada um destinado a solucionar um problema cumentos estão tomando cada vez mais força no âmbito comercial. Entre suas principais características, está a escalabilidade vertical de fácil manutenção e instalação. Para startups e sites de grandes volumes de manipulação de dados, a utilização de bancos de dados NoSQL orientado a documentos podem ser a solução mais adequada. Os principais modelos de bancos de dados NoS- QL são: Orientado a documento: MongoDB, CouchDB, MarLkogic Server, BaseX, sxist Orientado a objetos: Db4o Rdis, SimpleDB, Hbase Tabular: Cassandra, Hypertable - No desenvolvimento do MongoDB foram priorizadas algumas funcionalidades (Flexibilidade, Facilidade e Velocidade) em detrimento de outras (Transações). O MongoDB não suporta transações ACID. Pelo menos não de forma nativa entre coleções, como os bancos de dados relacionais suportam entre tabelas. O MongoDB oferece suporte a ACID nativamente quando as alterações são entre documentos aninhados, mas não entre coleções. Para os casos em que são necessárias controle de transações entre coleções, é possível, através de uma camada intermediária entre a aplicação e o banco de dados. 17 \