Paolo Atzeni, Francesca Bugiotti, Luca Cabibbo, Riccardo Torlone,
Data modeling in the NoSQL world, Computer Standards & Interfaces, Volume 67, 2020, 103149, ISSN 0920-5489,https://doi.org/10.1016/j.csi.
A proposta do artigo é apresentar um modelo de dados abstrato para bancos de dados NoSQL, chamado NoAM (NoSQL Abstract Model) assim como uma metodologia de projeto de banco de dados com atividades iniciais (conceitual e lógica) independentes do modelo de dados NoSQL onde será implementado.
Os autores demostram a metodologia usando um exemplo de aplicação de Jogos Online
O modelo se baseia em agregação de dados no qual cada agregado é um grupo de objetos relacionados, representando uma unidade de acesso e distribuição atômica por parte da aplicação. Em outras palavras, "Unidade de acesso" é definida como um grupo de objetos relacionados para a qual o sistema oferece operações para acessar e manipular um unidade individual de cada vez, de maneira atômica, eficiente e escalável enquanto que "Unidade de distribuição" é definida como unidade totalmente armazenada em um servidor do cluster.
O modelo de dados NoAM é definido pelos autores da seguinte forma:
• Um banco de dados NoAM é um conjunto de coleções. Cada coleção possui um nome distinto.
• Uma coleção é um conjunto de blocos. Cada bloco em uma coleção é identificado por uma chave de bloco, que é única nessa coleção.
• Um bloco é um conjunto de entradas não vazio. Cada entrada é um par 〈ek, ev〉, onde ek é a chave de entrada (única dentro de seu bloco) e ev é seu valor (complexo ou escalar), chamado valor de entrada.
A metodologia NoAM é baseada nas seguintes etapas:
• modelagem conceitual de dados e projeto de agregados, para identificar as várias entidades, atributos e relações necessárias em um aplicativo, e agrupar entidades relacionadas em agregados;
• particionamento do agregado e projeto de banco de dados NoSQL de alto nível, onde os agregados são particionados em elementos de dados menores e depois mapeado para o modelo de dados intermediário NoAM;
• implementação, para mapear a representação intermediária em um NoSQL DataStore específico.
Os autores sugerem que a modelagem conceitual pode usar uma metodologia já conhecida como, por exemplo, o Domain Driven Design (DDD) para gerar um modelo UML de Classes ou Objetos. Esse modelo é usado como entrada para a atividade de identificação de agregados. Cada agregado tem uma entidade como sua raiz e também pode conter muitos objetos. Uma entidade e um grupo de objetos de valor são usados para definir um agregado e esses devem ser projetados como as unidades nas quais a atomicidade deve ser garantida assim como reduzir colisões de atualização simultânea. No NoAM cada classe de agregados é representada por meios de uma coleção distinta, e a coleção recebe o nome da classe, e cada indivíduo agregado é um bloco onde o identificador do agregado é usado como chave de bloco.
Na etapa seguinte, o particionamento do agregado pode ser baseado nas seguintes diretrizes:
• Em caso de agregado pequeno (!!!), ou todos ou a maioria dos dados forem acessados ou modificados juntos, deve ser representado por uma única entrada.
• Um agregado deve ser particionado em várias entradas se seu tamanho é grande (!!!) e existem operações que acessam ou modifique apenas partes específicas do agregado.
• Dois ou mais elementos de dados devem pertencer à mesma entrada se são freqüentemente acessados ou modificados juntos.
• Dois ou mais elementos de dados devem pertencer a entradas distintas se geralmente são acessados ou modificados separadamente.
No artigo os autores apresentam o resultado da terceira etapa da metodologia utilizando 3 NoSQL DataStores com modelos de dados diferentes: Oracle NoSQL, DynamoDB e MongoDB.
O modelo de dados NoAM é definido pelos autores da seguinte forma:
• Um banco de dados NoAM é um conjunto de coleções. Cada coleção possui um nome distinto.
• Uma coleção é um conjunto de blocos. Cada bloco em uma coleção é identificado por uma chave de bloco, que é única nessa coleção.
• Um bloco é um conjunto de entradas não vazio. Cada entrada é um par 〈ek, ev〉, onde ek é a chave de entrada (única dentro de seu bloco) e ev é seu valor (complexo ou escalar), chamado valor de entrada.
A metodologia NoAM é baseada nas seguintes etapas:
• modelagem conceitual de dados e projeto de agregados, para identificar as várias entidades, atributos e relações necessárias em um aplicativo, e agrupar entidades relacionadas em agregados;
• particionamento do agregado e projeto de banco de dados NoSQL de alto nível, onde os agregados são particionados em elementos de dados menores e depois mapeado para o modelo de dados intermediário NoAM;
• implementação, para mapear a representação intermediária em um NoSQL DataStore específico.
Os autores sugerem que a modelagem conceitual pode usar uma metodologia já conhecida como, por exemplo, o Domain Driven Design (DDD) para gerar um modelo UML de Classes ou Objetos. Esse modelo é usado como entrada para a atividade de identificação de agregados. Cada agregado tem uma entidade como sua raiz e também pode conter muitos objetos. Uma entidade e um grupo de objetos de valor são usados para definir um agregado e esses devem ser projetados como as unidades nas quais a atomicidade deve ser garantida assim como reduzir colisões de atualização simultânea. No NoAM cada classe de agregados é representada por meios de uma coleção distinta, e a coleção recebe o nome da classe, e cada indivíduo agregado é um bloco onde o identificador do agregado é usado como chave de bloco.
Na etapa seguinte, o particionamento do agregado pode ser baseado nas seguintes diretrizes:
• Em caso de agregado pequeno (!!!), ou todos ou a maioria dos dados forem acessados ou modificados juntos, deve ser representado por uma única entrada.
• Um agregado deve ser particionado em várias entradas se seu tamanho é grande (!!!) e existem operações que acessam ou modifique apenas partes específicas do agregado.
• Dois ou mais elementos de dados devem pertencer à mesma entrada se são freqüentemente acessados ou modificados juntos.
• Dois ou mais elementos de dados devem pertencer a entradas distintas se geralmente são acessados ou modificados separadamente.
No artigo os autores apresentam o resultado da terceira etapa da metodologia utilizando 3 NoSQL DataStores com modelos de dados diferentes: Oracle NoSQL, DynamoDB e MongoDB.
Não foi usado um do tipo Grafo. Talvez pq esses não foram considerados como orientados a agregação de dados pelos autores.
Além disso, os autores conduziram um pequeno experimento com 3 tipos de carga de trabalho no Oracle NoSQL comparando duas abordagens de particionamento do agregado. Com esse experimento, concluem que o projeto de banco de dados NoSQL devem ser feitos com cuidado, pois a forma que os agregados são particionados afeta consideravelmente o desempenho e a consistência das operações. Mas a figura 14 mostra uma tendência de equiparação dos tempos de resposta em ambas as abordagens a medida que o volume de dados aumenta (!!!).
Um resumo em formato CANVAS do artigo está disponível aqui.
Vou fazer um novo resumo do NoAM usando o CANVAS
ResponderExcluir