Esse é o nome de uma palestra que darei nas próximas semanas. Trata-se basicamente de modelagem de dados para dados não estruturados ou semiestruturados.
Se você estiver interessado, eu o apresentarei nas seguintes conferências:
- Java Days Kiev - 6-7 de novembro de 2015 Kiev - http://javaday.org.ua/kyiv/
- Devoxx Marroco - 16-18 de novembro de 2015 Casablanca - http://devoxx.ma/en/
- TopConf Talinn -17-19 de novembro de 2015 Tallinn - http://topconf.com/tallinn-2015/
Se você tiver algum tempo livre, este é basicamente um resumo da introdução da palestra:
As promessas de agilidade e de dados sem esquema estão sempre à espreita para os bancos de dados NoSQL. E o fato é que tudo isso é verdade. Você pode armazenar dados não estruturados facilmente. Mas precisará aplicar a estrutura quando for realmente usar os dados. Há várias maneiras de aplicar essa estrutura. E vamos falar sobre isso hoje.
Mas, primeiro, vamos entrar no tópico Estruturado VS Não estruturado. Os dados estruturados, como os conhecemos nos bancos de dados, referem-se tradicionalmente a colunas. Uma coluna tem um nome e um tipo e é agrupada por tabela. Quando você tenta inserir uma nova linha nessa tabela, todos os elementos dessa linha precisam corresponder ao nome e ao tipo de cada coluna. Não é possível adicionar uma nova coluna em tempo real ou alterar o tipo dinamicamente.
Bem, você provavelmente poderia armazenar tudo como Strings, mas isso meio que anula o propósito de usar colunas de banco de dados (também vale a pena mencionar que a maior parte do armazenamento de colunas está surgindo com um tipo Json). Portanto, é como ter um esquema. E se o que você estiver tentando armazenar não se encaixar nesse esquema, receberá um erro.
Afinal, o que é Schemaless?
Por outro lado, a ausência de esquema permite que você armazene qualquer coisa de qualquer tipo. Se você pensar em programação e estruturas de dados como Maps ou Dictionaries, elas são estruturas sem esquema. Se você pensar em um armazenamento de chave/valor, o valor pode ser qualquer coisa. Pode ser uma imagem codificada em binário, um objeto serializado, JSON, XML, um número, etc.
Embora possa não haver nenhuma estrutura incorporada em um arquivo codificado em binário, há uma estrutura para JSON e XML. Geralmente nos referimos a eles como dados semiestruturados. Ambos oferecem campos nomeados e digitados e flexibilidade para adicionar qualquer campo a qualquer momento. É como um esquema implícito. E ambos têm especificações de esquema reais, como XSD ou JSON-SCHEMA.
Portanto, na maioria das vezes, em bancos de dados, quando se ouve falar em sem esquema, na verdade, isso está mais próximo de dados semiestruturados.
Estruturado, não estruturado ou semiestruturado, entendi, e agora?
E, é claro, como você está armazenando dados, vai querer usá-los em algum momento. Portanto, isso significa aproximadamente três coisas:
- Você precisa gravar esses dados
- Você precisa ler esses dados
- Você precisa mapear a resposta do armazenamento de dados para uma estrutura ou um objeto utilizável pelo seu aplicativo
Esses três pontos, juntamente com a arquitetura da loja que você está usando, levantarão mais questões:
- O que você pode usar para recuperar dados (obtenção de chave simples? visualizações materializadas? linguagem de consulta?)
- Seus dados são distribuídos, replicados e consistentes?
Todos esses pontos terão um impacto sobre como você estrutura seus dados. E, para isso, você pode adicionar todas as especificidades do design do seu domínio.
Tentarei responder a essas perguntas o máximo possível, tomando o Couchbase como exemplo. O Couchbase é um armazenamento distribuído de chave/valor e um banco de dados de documentos e é um bom candidato para isso.
Então, junte-se a mim para saber mais sobre modelagem de dados!
