¶ Melhorar o uso das metakeys
| Data de elaboração | 27/06/2025 |
| Responsável pelo estudo | Diego Barros de Oliveira |
| Equipe do estudo | Esquadrão Suicida |
| Alvo | e-Estado |
| Origem | Consultas lentas quando é necessário filtrar por campos que são metakeys |
| Objetivo | Definir uma nova estrutura para o registro das metakeys do e-Estado com o propósito de melhorar o desempenho de consultas nas tabelas que utilizam metakeys. |
| Observações | Este estudo destaca a estrutura atual das metakeys e propõe melhorar o padrão atual para aprimorar o desempenho das consultas. |
¶ 1. Introdução
A atual estrutura de metakeys do e-Estado tem apresentado baixo desempenho a nível de consultas, isso ocorre porque atualmente uma única tabela é responsável por salvar todos os metadatas das metakeys.
¶ 2. Desenvolvimento
¶ 3.1 Pontos que impactam negativamente o desempenho
- Tabela única para os metadatas de todos os tipos de registros
- Não é possível definir relacionamento a nível de banco na tabela metadata
- Sempre que é necessário filtrar por um campo do bem que é uma metakey é necessário realizar um novo join na consulta para retornar esse campo. Cada novo join em uma tabela mal otimizada e que contém milhões de registros (e que conterá mais, futuramente) impacta muito no desempenho das consultas.
Os pontos citados acima são possíveis de visualizar no diagrama abaixo das tabelas, referente a estrutura atual de metakeys:
Para melhor entendimento da responsabilidade de cada tabela:
- metakey - Responsável pela definição dos campos (metakeys) e para qual tabela esse campo pode, eventualmente, estar disponível.
- metakey_registro - Define para quais registros da tabela informada na metakey a metakey estará disponível.
- metadata - Registra os dados em si, informado qual a metakey, o dado da metakey e em qual tabela foi aplicado.
Um exemplo de utilização pode ser visto abaixo:
// metakey
// Aqui definimos a estrutura do campo e para qual tabela estará disponível
{
"id": 1,
"name": "processo_sei",
"label": "Processo SEI!",
"tabela": "patrimonio.bem_tipo"
}
// metakey_registro
// A metakey acima só estará disponível para o registro de id 2 da tabela patrmonio.bem_tipo
{
"metakey_id": 1,
"registro": 2
}
// metadata
// Aqui é o dado em si
{
"metakey_id": 1,
"tabela": "patrimonio.bem",
"registro": 123112,
"dado": "0000.000000/0000-00"
}
No exemplo acima estamos dizendo que o registro 2 da tabela patrimonio.bem_tipo tem o campo processo_sei, e que o registro 123112 tabela patrimonio.bem está utilizando essa metakey com o valor 0000.000000/0000-00.
¶ 3.2 Melhorias
Como o maior impacto está na tabela metadata, a solução proposta é deixar de utilizar essa tabela e, ao invés dela, utilizar uma coluna chamada metadata em cada tabela que possui campos dinâmicos.
O novo esquema ficaria assim:
E, então, na tabela patrimonio.bem (por exemplo), teríamos uma coluna metadata do tipo JSONB com a seguinte estrutura (exemplo):
{
"patrimonio.bem_tipo": {
"processo_sei": "0000.000000/0000-00"
}
}
Assim é possível registrar os campos dinamicamente e saber qual relacionamento é responsável por gerar essa informação. No caso acima, o campo processo_sei existe por conta do tipo do bem.
Dessa forma eliminamos os joins e a necessidade de filtrar por milhões de registros fora do contexto necessário.
¶ 3. Conclusão
É possível concluir que com a nova estrutura é possível tornar as consultas mais simples e mais performáticas por conta da remoção dos joins e de uma tabela mal planejada e que em momentos de filtros possui milhões de registros fora do contexto necessário.