Sobre performance do noosfero e modelo do banco de dados

[Antonio Terceiro]

On Wed, Feb 06, 2013 at 09:39:32AM -0200, Daniel Tygel wrote:
> Oi gente,
> 
>    Fiquei muito contente de que se esteja olhando os problemas de consumo de
> memória no AI2569 (http://noosfero.org/Development/ActionItem2569). Fiz um
> comentário lá a partir de pesquisas que temos feito e que na minha opinião
> referendam algo que venho dizendo há tempos: a base de dados do noosfero é mal
> modelada, já que o método de desenvolvimento não se orienta nestas otimizações
> de queries e relações entre as tabelas.

Eu acho que a sua premissa de que temos problemas de desempenho por
causa do projeto ruim (na sua opinião) do banco de dados está
equivocada.

O projeto do banco de dados por ser melhorado? Sim.

Fazer isso vai ajudar no desempenho? Não tenho certeza.

O que eu tenho certeza é de existem pontos críticos de desempenho, com
vazamento de memória, os quais estamos investigando. Isso é ortogonal a
qualquer melhoria no projeto do banco de dados.

>     Gostaria, portanto, de retomar uma sugestão que fiz há 3 anos atrás de, por
> exemplo, quebrar a tabela "categories" (que na minha opinião é um monstro) em 3
> diferentes tabelas:
> 
> 1. categories
> 2. places (uma tabela do tipo geolocalizada com nomes e lat/lng de locais)
> 3. products_services_categories
> 
>     E com isso acabar com a doideira que é este campo "data" e o uso de colunas
> que só servem para um tipo de dados e não para outros. Esta tabela é monstruosa
> e gera várias dores de cabeça na construção de queries.

Os problemas de desempenho estão se manifestando em sites que _não usam_
categorias, então ainda que seja válida a idéia de melhorar o projeto do
banco de dados p/ as categorias, isso não vai ajudar no desempenho.

>     E a tabela profiles, que também usa uma coluna "data"? Talvez fosse
> interessante analizá-la também.

O Noosfero não usa a coluna data pra nenhum tipo de consulta, então
ainda que você ache isso "um absurdo", não tem qualquer relação com os
problemas de desempenho.

>     Neste sentido de analisar a base de dados, visualizar como está modelada e
> as relações entre campos, sugiro que olhemos as queries (as SQLs geradas pelo
> activerecord, que na minha opinião é bastante "obscurecedor" do mundo real das
> queries) para percebermos quais campos necessitam se tornar indices e para
> otimização das queries. Como citei no AI, encontramos, por exemplo, alguns
> absurdos como por exemplo o fato de que dezenas de queries eram feitas somente
> para se fazer o menu de categorias, quando em alguns minutos de reflexão sobre
> o postgresql geramos uma única query complexa para todos os menus de
> categorias, ou então 3 queries mais simples que também geram o menu, reduzindo
> o uso de memória e tempo de processamento para menos de 10% do original.
>
>     Enfim, resumindo: sinto falta de um diagrama e modelo de base de dados que
> nos permita refletir sobre performance de maneira mais global. Tem sentido
> isso?

Tem bastante sentido. Mas existem ferramentas que geram diagramas a
partir de bancos de dados, ou a partir de modelos activerecord. Eu não
acho que a gente ganhe nada desenhando um diagrama na mão.

Por outro lado, com exceção de pouquíssimos pontos, o projeto de BD do
Noosfero é bastante intuitivo pra qualquer pessoa com um mínimo de noção
de BD's relacionais. Na maioria dos pontos em que existem problemas de
desempenho por causa de queries estúpidas geradas pelo ActiveRecord
porque a gente não teve o cuidado devido com o desempenho, a solução é
reprojetar o código que faz a consulta, não reprojetar o banco de dados.

Nos pontos em que o projeto do BD precisa melhorar, ele pode melhorar.
só falta alguém se importar o suficiente pra escrever os patches pra
isso. Pra mim isso só vai ser proridade se for pra resolver um problema
concreto (i.e. se a gente chegar à conclusão de que de fato há um
problema de desempenho relacionado ao projeto do BD), não porque "está
feio".

-- 
Antonio Terceiro <terceiro at colivre.coop.br>
Colivre - Cooperativa de Tecnologias Livres
http://www.colivre.coop.br/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://listas.softwarelivre.org/pipermail/noosfero-br/attachments/20130206/8f6a1dfd/attachment.pgp>