blendb issueshttps://gitlab.c3sl.ufpr.br/c3sl/blendb/-/issues2018-05-16T13:40:51Zhttps://gitlab.c3sl.ufpr.br/c3sl/blendb/-/issues/66Redefinir algoritmo de junção2018-05-16T13:40:51ZLucas Fernandes de OliveiraRedefinir algoritmo de junçãoO algoritmo de junção possui uma regra: Quando agregações de granularidade diferentes são unidas, não é possível agregagar. Essa regra atrapalha alguns casos onde a ordem das junções afeta o resultado final. Buscar uma solução. Possíveis...O algoritmo de junção possui uma regra: Quando agregações de granularidade diferentes são unidas, não é possível agregagar. Essa regra atrapalha alguns casos onde a ordem das junções afeta o resultado final. Buscar uma solução. Possíveis soluções incluir utilizar dependência funcional e salvar esse tipo de informação na agregação ou dimensão.1.0Lucas Fernandes de OliveiraLucas Fernandes de Oliveirahttps://gitlab.c3sl.ufpr.br/c3sl/blendb/-/issues/63Controle de transformações2018-08-29T13:51:58ZLucas Fernandes de OliveiraControle de transformaçõesConstrução das agregações a partir das fontes.
* A construção de uma agregação é a construção de suas métricas e dimensões a partir dos campos de uma fonte.
* Para cada registro na fonte será gerado um único registro na agregação.
* A ...Construção das agregações a partir das fontes.
* A construção de uma agregação é a construção de suas métricas e dimensões a partir dos campos de uma fonte.
* Para cada registro na fonte será gerado um único registro na agregação.
* A construção de uma métrica ou dimensão é o resultado de uma expressão dos campos da fonte e de constantes
Para resolver o problema será necessário:
* Alteração do arquivo de configuração. Transformações devem estart no arquivo de configuração
* Criação de um *parser* para verificar a validade das expressões de construção
* Tradução das transformações pelos adaptadores
* Definição de uma técnica de atualização
Sugestões para solucionar os tópicos acima:
* [ ] Adição de um campo *transformers* na definição da agregação. Esse campo será uma lista com identificadores de transformações que são usados para criar essa agregação
* [ ] Adição de uma novo campo no nível 0 do arquivo de configuração chamado *transformers*. Esse campo contém uma lista de definição de transformações. Uma transformação pode ser definida por:
* **name**: nome/identificador da transformação (utilizado na definição da agregação)
* **source**: fonte na qual a transformação é aplicada
* **dimensions**: objeto onde cada chave é uma dimenção criada pela transformação
* Uma dimensão é definida como uma lista de condições seguidas de expressões
* A propósta é utilziar essa lista como um **CASE/WHEN** de SQL
* **metrics**: objeto onde cada chave é uma métrica criada pela transformação
* Uma métricas é definida como uma lista de condições seguidas de expressões
* A propósta é utilziar essa lista como um **CASE/WHEN** de SQL
* [ ] Utilização do pacote **sintax-cli** para criação de um parser de expressões. A principal função do parser é validar as expressões e devolver os tipos (int, float, bool, ...) das expressões para validação
* [ ] Criação de uma nova variável de ambiente para definir a politica de atualização, chamada **BLENDB_UPDATE**
* Para a primeira versão está sendo considerado que existira uma única política de atualização para o Blendb todo
* Outras alternativas seriam uma politica para cada transformer ou para cada fonte
* Há duas politicas propóstas. **Temporal**, a cada **X** tempo é realizada a transformação. **Frequência**, a cada **X** inserções é realizada a transformação.
* [ ] Adição de uma função no adaptador (abstrato) para aplicação de transformações
1.0Lucas Fernandes de OliveiraLucas Fernandes de Oliveirahttps://gitlab.c3sl.ufpr.br/c3sl/blendb/-/issues/44Mover metricas dimensionais para Engine2018-05-16T13:40:54ZLucas Fernandes de OliveiraMover metricas dimensionais para EngineAtualmente as métricas dimensionais são tratadas apenas pelo adapter. Esse efeito surge ao realizar certos Joins entre as views sobre certas condições.
Descobrir se esse problema já pode ser detectado na Engine, e resolvido nesse ponto....Atualmente as métricas dimensionais são tratadas apenas pelo adapter. Esse efeito surge ao realizar certos Joins entre as views sobre certas condições.
Descobrir se esse problema já pode ser detectado na Engine, e resolvido nesse ponto. Provavelmente se isso for possivel, a view deverá ter uma estrutura mais elaborada do que um vetor de childViews para passar ao adapter para gerar a consulta. Provavelmente terá que indicar exatamente quais joins devem ser feitos e quais agregações devem ser feitas.
Com essa alteração o adapter terá que ser refatorado (Novamente), mas provavelmente deverá ficar mais simples.1.0Lucas Fernandes de OliveiraLucas Fernandes de Oliveirahttps://gitlab.c3sl.ufpr.br/c3sl/blendb/-/issues/41[BUG]: Metricas retornam resultados incorretos em alguns joins2017-09-12T14:00:54ZLucas Fernandes de Oliveira[BUG]: Metricas retornam resultados incorretos em alguns joinsEmbora o mecanismo funcione corretamente o resultado não é o esperado. O problema ocorre quando a junção das tabelas não é "perfeita". Um exemplo uma view tem os atributos met:count:point e dim:point e outra tem met:sum:download, dim:poi...Embora o mecanismo funcione corretamente o resultado não é o esperado. O problema ocorre quando a junção das tabelas não é "perfeita". Um exemplo uma view tem os atributos met:count:point e dim:point e outra tem met:sum:download, dim:point, dim:macAddr. A consulta seleciona as duas métricas, logo será feita uam junção das duas views pela dimensão dim:point que é comum entre os dois. Porém o resultado da métrica met:count:point possivelmente será incorreto.
Isso ocorre pois é muito provavel que a segunda tabela que tem mais dimensões tenha mais de uma entrada por dim:point, dessa forma ao realizar o join as entradas da primeira serão repeditas e contabilizadas mais de uma vez, resultando em um resultado incorreto.
*Proposta:* para realizar joins as views tem que ter uma relação de um para um, ou seja, as mesmas dimensões antes de fazer um join.
*Problemas:* Em alguns casos é necessário fazer junções com quantidades de dimensões diferentes.
Considere o mesmo exemplo, agora além das métricas a dim:macAddr também é selecionada, a junção com quantidade diferente de dimensões é obrigatória.
*Proposta:* Em certos casos, a partir de um ponto as métricas devem se comportar como dimensões.
A junção com outra view com quantidade de entradas maior é inevitavel, porém se met:count:point fosse uma dimensão o resultado não seria incorreto, em outras palavras se o valor fosse agrupado ao invés de agregado não seriam contabilizadas de forma errada, logo se comportária como uma dimensão.
*Proposta:*
1. Agregamos as views materializadas separadamente, com as respectivas dimensões necessárias
2. Depois da agregação é feito o join, com as dimensões restantes, que seriam as necessárias para realizar o join entre as views e as que foram escolhidas na consulta
3. Remoção das dimensões extras (usadas apenas para propósito de junção) agrupando por todos os parametros que estavam na consulta
*Problemas:*
1. Nem todas as views criadas podem ser reaproveitas para realizar outras consultas, e portanto essas não podem ser materializadas.
2. A partir do momento que um métrica tem que ser tratada como uma dimensão, ela pode ser replicada e não pode ser agregada novamente
Usando esse algoritmo a query 1 (apenas as métricas) não funcionaria, na realidade ela seria equivalente a consulta utilizando também a dim:point, para que o resultado fosse correto, as métricas teriam que ser agregadas novamente, não tratadas como dimensões, isso se deve ao fato de que a junção nesse caso poderia ter sido "perfeita", primeiro agrupando por dim:point seriam criadas views com dimensões iguais, assim elas poderiam ser juntadas normalmente e as metricas poderiam ser agregadas normalmente.
*Solução:*
As junções devem ser feitas 2 a 2, ao invés de todas ao mesmo tempo, em formato de árvore, sempre que uma junção "perfeita" foi feita em um passo, então o resultado deve ser agregado novamente removendo as dimensões de junção, se for o caso. Se a junção não for perfeita a partir desse ponto as métricas devem ser tratadas como dimensões.
1. Escolhe-se 2 views
2. Agregamos as views separadamente, com as respectivas dimensões necessárias, tanto para consulta como para joins (além das duas em questão, mas de todo o conjunto)
3. Faz-se o join das duas views
4. Se a junção foi perfeita, as métricas continuam factíveis e podem continuar sendo agregadas, caso contrário marca as métricas para que sejam tratadas como dimensões agora e a view como não-materializavel
5. Volta para o passo 1 até que reste apenas uma view
6. Se a última junção foi perfeita agrega a view com as métricas restantes (métricas marcadas para o algoritmo não são consideradas métricas)
*Problemas:*
1. Vão existir views não-materializaveis (Elas podem serr materizalizadas mas seu resultado não pode ser aproveitado por outras consultas, então é pouco desejavel materializar uma consulta dessas)
2. Muito provavelmente a consulta construída será muito menos eficiente
3. A partir do momento que um métrica tem que ser tratada como uma dimensão, ela pode ser replicada e não pode ser agregada novamente
*Resolve:*
A junção de views com quantidade de dimensões diferentes se torna possível e retorna o resutlado corretoLucas Fernandes de OliveiraLucas Fernandes de Oliveirahttps://gitlab.c3sl.ufpr.br/c3sl/blendb/-/issues/33Melhorar função de analise dos filtros2017-10-16T11:49:30ZLucas Fernandes de OliveiraMelhorar função de analise dos filtrosA escolha de views e agregações é limitada pelos filtros aplicados. No momento apenas se o filtro casar perfeitamente (tem que se identico) a view é escolhida. En varios casos é o suficiente (Para operadores == e !=), porém com o operado...A escolha de views e agregações é limitada pelos filtros aplicados. No momento apenas se o filtro casar perfeitamente (tem que se identico) a view é escolhida. En varios casos é o suficiente (Para operadores == e !=), porém com o operador de > por exemplo, se a restrição é de maior que 3 meses, maior que 6 meses também poderia utilizar essa view, mas isso não ocorre.
Operadores individuais parecem simples de resolver, bastaria olhar o operador do filtro e aplicar algumas comparações, entretanto quando combinados com operador OR (maior que 3 meses ou ativo) já não funciona tão bem.
Acredito que o melhor é analizar alguns casos que seriam mais úteis que e que mais ocorrem e tentar abordar esse modelo mais restrito do que acertar 100% dos casos.
Encontrar essa lista de casos e melhorar a escolha dos filtros, a principio modificar a função checkConstranits da classe graph deve ser o suficiente para aplicar as mudanças.Lucas Fernandes de OliveiraLucas Fernandes de Oliveirahttps://gitlab.c3sl.ufpr.br/c3sl/blendb/-/issues/23Implementar filtros básicos2017-08-10T12:35:24ZLucas Fernandes de OliveiraImplementar filtros básicosImplementar filtros para dimensões. Isso significa o trabalho completo, desde adicionar o parâmetro na API até modificar o gerador de consulta para aplicar os filtros
No momento apenas dois operadores serão implementados, igualdade e de...Implementar filtros para dimensões. Isso significa o trabalho completo, desde adicionar o parâmetro na API até modificar o gerador de consulta para aplicar os filtros
No momento apenas dois operadores serão implementados, igualdade e desigualdade, mas a estrutura deve ser feita para facilitar a criação de outros filtros.Lucas Fernandes de OliveiraLucas Fernandes de Oliveirahttps://gitlab.c3sl.ufpr.br/c3sl/blendb/-/issues/22Incrementar Algoritmo de Cobertura para considerar conectividade das Views2017-07-14T14:36:49ZLucas Fernandes de OliveiraIncrementar Algoritmo de Cobertura para considerar conectividade das ViewsUm problema conhecido com a cobertura gerada pelo BlenDB é que o conjunto de Views selecionadas nem sempre pode sofrer um join perfeito, em alguns casos é feito um produto cartesiano que pode levar a resultados inconsistentes.
O esquema...Um problema conhecido com a cobertura gerada pelo BlenDB é que o conjunto de Views selecionadas nem sempre pode sofrer um join perfeito, em alguns casos é feito um produto cartesiano que pode levar a resultados inconsistentes.
O esquema do banco que o BlenDB usa pode ser representado por um grafo onde os vértices são métricas e dimensões e uma aresta existe entre dois vértices se, e somente se eles fazem parte de uma mesma view.
Uma consulta pode ser vista como um sub-grafo, onde o Usuário escolhe os vértices e o BlenDB escolhe as arestas.
Para que a consulta não realize produtos, o sub-grafo resultante da consulta deve ser conexo.
Implementar esse grafo para representar o esquema do banco, mantê-lo com a adição de métricas e dimensões e views e implementar o algoritmo que verifica conectividade do sub-grafo. Uma busca em largura deve resolver.Lucas Fernandes de OliveiraLucas Fernandes de Oliveira