Qual versão do Magento você está usando? Muitas alterações foram feitas na v1.13 - portanto, espere diferenças na versão anterior a essa versão. Aqui está uma boa postagem no blog, explicando o módulo mView e a indexação na versão 1.13 do Magento: eschrade.com/page/…
Pitt
Respostas:
63
Existem diferentes tipos de índices no Magento.
Todos os indexadores estão lá para acelerar o processo.
Vou cobrir aqui apenas alguns deles.
Índice Simples
Existem 2 desses índices. Um para categorias e outro para produtos.
Por padrão, as entidades de categoria e produto (e clientes e endereços de clientes, mas não são importantes nessa situação) são entidades EAV . Isso é muito bom para extensibilidade. Mas é um fator que prejudica o desempenho, porque, para obter todos os valores para todos os atributos, você precisa de muitas junções ou várias consultas.
Aqui é onde o indexador plano entra em ação.
Ele transforma a estrutura do EAV em uma estrutura plana. Quero dizer, ele cria uma tabela (uma para cada visualização da loja no Magento) que possui uma coluna correspondente a um atributo. Isso torna as seleções mais rápidas. Para categorias, todos os atributos são convertidos em colunas da tabela. Para produtos, apenas os marcados como 'Utilizados na lista de produtos', porque você pode vender todos os tipos de produtos com atributos diferentes, e a criação de uma tabela com um zilhão de colunas pode não ser possível.
Além disso, alguns produtos podem estar desativados ou podem não pertencer a um determinado site e não há necessidade de incluí-los nas entradas para pesquisar. Eles são excluídos pelo indexador.
As tabelas simples geradas são usadas para a leitura de dados na frente. O back-end ainda usa a estrutura EAV.
Índice de pesquisa de catálogo
Você pode procurar produtos por vários valores de atributo. Alguns deles podem não ser incluídos nas tabelas simples geradas pelo indexador simples. Esse índice preenche uma tabela com os valores de atributos pesquisáveis para produtos, para que seja mais fácil procurá-los com base em palavras-chave. Ter todas as informações em uma tabela (ou em um campo) torna possível usar a pesquisa de texto completo e obter resultados relevantes.
Preços dos produtos .
O preço de um produto pode ser afetado por muitas variáveis. Por exemplo, grupo de clientes, site, regras de desconto de catálogo.
Assim como acima, obter os produtos com seus preços significará muitas junções ou várias seleções. Além disso, os produtos de pacote possuem um sistema de preços estranho. Este indexador agrega os dados em algumas tabelas ( catalog_product_index_price_*) e facilita as seleções (classificação e filtragem).
Regravações de URL do catálogo
Limpa as regras de reescrita de URL, definindo qual URL corresponde a qual produto ou categoria. Dessa forma, é mais fácil para o sistema interno de gerenciamento de URL decidir qual página você deve exibir ao chamar um URL não padrão. Em vez de pesquisar em todas as chaves de URL do produto e das categorias, ele apenas pesquisa em uma tabela.
Produtos de categoria
No Magento, você pode definir um atributo de categoria chamado 'Is Anchor' como true ou false. Se for verdade, significa que a categoria em questão listará todos os produtos das categorias filho. Novamente, para determinar esse tempo real, serão necessários mais recursos do que apenas ler uma tabela. Esse indexador cria a associação entre produtos e categorias com base nas associações definidas no back-end e no sinalizador 'É âncora' nas categorias.
Status de estoque
Para produtos simples, é fácil. Eles podem estar em estoque ou fora de estoque, mas para configurável, agrupado e agrupado não é tão fácil. Eles podem estar em estoque ou fora de estoque, dependendo dos produtos filhos associados ao produto principal. Novamente (estou apenas me repetindo aqui), obter seu status em tempo real significaria muitas consultas.
Atributos do produto .
Este coleta todos os atributos que podem ser usados na navegação em camadas pelo mesmo motivo. Ter todos eles em um só lugar para uma leitura mais rápida.
Agregação de tags
Não tenho idéia do que isso faz. Eu nunca usei tags em um projeto real ao vivo.
obrigado marius esta é até onde a melhor resposta ... eu tenho
sonam
O que você quis dizer quando disse que as tabelas simples são usadas apenas no front-end (e o back-end ainda usa a estrutura do EAV)? Sou novato e, pelo que entendi, quando criamos / atualizamos entidades como produtos, ele ainda usa as tabelas EAV para executar essas operações e temos de definir a opção de atualizar as tabelas simples ao salvar ou atualizá-las manualmente para essas alterações serão refletidas em tabelas planas. Você está se referindo a esse processo quando disse isso? Você poderia elaborar isso por favor? Obrigado!
Bharadwaj Srigiriraju
1
@ Marius: Durante a re-indexação, estou recebendo um erro de tabela cheia. Por favor ajude. O erro que estou recebendo é A tabela 'catalog_product_index_price_bundle_sel_tmp' está cheia
zed Blackbeard
1
@Marius, após 3 anos desta resposta, agora você tem alguma idéia sobre a agregação de tags, está relacionada a tags de produtos?
Murtuza Zabuawala
1
@Preto. Você tem 2 configurações para os índices. "Atualização ao salvar" e "Manual". Para atualizar ao salvar tudo deve acontecer automaticamente quando você salvar o produto. Mas isso pode causar problemas de desempenho. Por exemplo, se você alterar vários produtos ao mesmo tempo. Para o modo manual, nenhuma reindexação é acionada imediatamente após o salvamento, mas é necessário reconstruir manualmente quando terminar.
A indexação do Magento é semelhante apenas à indexação no nível do banco de dados em espírito. Como afirma Anton, é um processo de desnormalização para permitir uma operação mais rápida de um site. Deixe-me tentar explicar alguns dos pensamentos por trás da estrutura do banco de dados Magento e por que torna a indexação necessária para operar em alta velocidade.
Em um banco de dados MySQL mais "típico", uma tabela para armazenar produtos de catálogo seria estruturada da seguinte forma:
PRODUCT:
product_id INT
sku VARCHAR
name VARCHAR
size VARCHAR
longdesc VARCHAR
shortdesc VARCHAR
... etc ...
Isso é rápido para recuperação, mas deixa um problema fundamental para um software de comércio eletrônico: o que você faz quando deseja adicionar mais atributos? E se você vende brinquedos e, em vez de uma coluna de tamanho, precisa de um intervalo de idade? Bem, você pode adicionar outra coluna, mas deve ficar claro que em uma loja grande (pense no Walmart, por exemplo), isso resultaria em linhas 90% vazias e tentar manter novos atributos é quase impossível.
Para combater esse problema, o Magento divide as tabelas em unidades menores. Não quero recriar todo o sistema EAV nesta resposta; portanto, aceite este modelo simplificado:
PRODUCT:
product_id INT
sku VARCHAR
PRODUCT_ATTRIBUTE_VALUES
product_id INT
attribute_id INT
value MISC
PRODUCT_ATTRIBUTES
attribute_id
name
Agora é possível adicionar atributos à vontade, inserindo novos valores em product_attributes e colocando registros adjacentes em product_attribute_values. Isso é basicamente o que o Magento faz (com um pouco mais de respeito pelos tipos de dados do que eu mostrei aqui). De fato, agora não há razão para dois produtos terem campos idênticos, para que possamos criar tipos de produtos inteiros com diferentes conjuntos de atributos!
No entanto, essa flexibilidade tem um custo. Se eu quiser encontrar a cor de uma camisa no meu sistema (um exemplo trivial), preciso encontrar:
O product_id do item (na tabela de produtos)
O attribute_id para cores (na tabela de atributos)
Por fim, o valor real (na tabela attribute_values)
O Magento costumava funcionar assim, mas era lento demais. Portanto, para permitir um melhor desempenho, eles fizeram um compromisso: assim que o dono da loja definir os atributos que deseja, vá em frente e gere a grande mesa desde o início. Quando algo mudar, retire-o do espaço e gere-o novamente. Dessa forma, os dados são armazenados principalmente em nosso bom formato flexível, mas consultados em uma única tabela.
Essas tabelas de pesquisa resultantes são os "índices" do Magento. Quando você re-indexa, está explodindo a tabela antiga e gerando-a novamente.
Magento é um sistema bastante poderoso e complexo. Ele permite trabalhar com grandes quantidades de dados, mas quando o banco de dados é sobrecarregado com toneladas de registros, torna-se pesado e lento. Magento usa índices para resolver este problema. Os índices são tabelas adicionais do banco de dados com alguns dados simples, o que permite organizar respostas rápidas do banco de dados.
Por padrão, o sistema principal atualiza os índices no salvamento de cada item. Mas, em alguns casos, é necessário fazê-lo manualmente, por exemplo, alguns tipos de ações em massa, etc. Você pode atualizar os índices a qualquer momento a partir do administrador (Admin-> Sistema-> Gerenciamento de índice). Mas, às vezes, causa problemas.
Por exemplo, se você tiver mais de 10.000 produtos e várias categorias, a reconstrução do índice 'reescrita de URL do catálogo' poderá levar horas. Em seguida, o script php pode simplesmente quebrar devido ao excesso de max_execution_time. Existe uma maneira de resolver vários problemas executando o processo reindex na linha de comando.
Respostas:
Existem diferentes tipos de índices no Magento.
Todos os indexadores estão lá para acelerar o processo.
Vou cobrir aqui apenas alguns deles.
Índice Simples
Existem 2 desses índices. Um para categorias e outro para produtos.
Por padrão, as entidades de categoria e produto (e clientes e endereços de clientes, mas não são importantes nessa situação) são entidades EAV . Isso é muito bom para extensibilidade. Mas é um fator que prejudica o desempenho, porque, para obter todos os valores para todos os atributos, você precisa de muitas junções ou várias consultas.
Aqui é onde o indexador plano entra em ação.
Ele transforma a estrutura do EAV em uma estrutura plana. Quero dizer, ele cria uma tabela (uma para cada visualização da loja no Magento) que possui uma coluna correspondente a um atributo. Isso torna as seleções mais rápidas. Para categorias, todos os atributos são convertidos em colunas da tabela. Para produtos, apenas os marcados como 'Utilizados na lista de produtos', porque você pode vender todos os tipos de produtos com atributos diferentes, e a criação de uma tabela com um zilhão de colunas pode não ser possível.
Além disso, alguns produtos podem estar desativados ou podem não pertencer a um determinado site e não há necessidade de incluí-los nas entradas para pesquisar. Eles são excluídos pelo indexador.
As tabelas simples geradas são usadas para a leitura de dados na frente. O back-end ainda usa a estrutura EAV.
Índice de pesquisa de catálogo
Você pode procurar produtos por vários valores de atributo. Alguns deles podem não ser incluídos nas tabelas simples geradas pelo indexador simples. Esse índice preenche uma tabela com os valores de atributos pesquisáveis para produtos, para que seja mais fácil procurá-los com base em palavras-chave. Ter todas as informações em uma tabela (ou em um campo) torna possível usar a pesquisa de texto completo e obter resultados relevantes.
Preços dos produtos .
O preço de um produto pode ser afetado por muitas variáveis. Por exemplo, grupo de clientes, site, regras de desconto de catálogo.
Assim como acima, obter os produtos com seus preços significará muitas junções ou várias seleções. Além disso, os produtos de pacote possuem um sistema de preços estranho. Este indexador agrega os dados em algumas tabelas (
catalog_product_index_price_*) e facilita as seleções (classificação e filtragem).Regravações de URL do catálogo
Limpa as regras de reescrita de URL, definindo qual URL corresponde a qual produto ou categoria. Dessa forma, é mais fácil para o sistema interno de gerenciamento de URL decidir qual página você deve exibir ao chamar um URL não padrão. Em vez de pesquisar em todas as chaves de URL do produto e das categorias, ele apenas pesquisa em uma tabela.
Produtos de categoria
No Magento, você pode definir um atributo de categoria chamado 'Is Anchor' como true ou false. Se for verdade, significa que a categoria em questão listará todos os produtos das categorias filho. Novamente, para determinar esse tempo real, serão necessários mais recursos do que apenas ler uma tabela. Esse indexador cria a associação entre produtos e categorias com base nas associações definidas no back-end e no sinalizador 'É âncora' nas categorias.
Status de estoque
Para produtos simples, é fácil. Eles podem estar em estoque ou fora de estoque, mas para configurável, agrupado e agrupado não é tão fácil. Eles podem estar em estoque ou fora de estoque, dependendo dos produtos filhos associados ao produto principal. Novamente (estou apenas me repetindo aqui), obter seu status em tempo real significaria muitas consultas.
Atributos do produto .
Este coleta todos os atributos que podem ser usados na navegação em camadas pelo mesmo motivo. Ter todos eles em um só lugar para uma leitura mais rápida.
Agregação de tags
Não tenho idéia do que isso faz. Eu nunca usei tags em um projeto real ao vivo.
fonte
Não é possível receber crédito por isso, pois é retirado da postagem original em: https://stackoverflow.com/questions/4945307/can-someone-explain-magentos-indexing-feature-in-detail
A indexação do Magento é semelhante apenas à indexação no nível do banco de dados em espírito. Como afirma Anton, é um processo de desnormalização para permitir uma operação mais rápida de um site. Deixe-me tentar explicar alguns dos pensamentos por trás da estrutura do banco de dados Magento e por que torna a indexação necessária para operar em alta velocidade.
Em um banco de dados MySQL mais "típico", uma tabela para armazenar produtos de catálogo seria estruturada da seguinte forma:
Isso é rápido para recuperação, mas deixa um problema fundamental para um software de comércio eletrônico: o que você faz quando deseja adicionar mais atributos? E se você vende brinquedos e, em vez de uma coluna de tamanho, precisa de um intervalo de idade? Bem, você pode adicionar outra coluna, mas deve ficar claro que em uma loja grande (pense no Walmart, por exemplo), isso resultaria em linhas 90% vazias e tentar manter novos atributos é quase impossível.
Para combater esse problema, o Magento divide as tabelas em unidades menores. Não quero recriar todo o sistema EAV nesta resposta; portanto, aceite este modelo simplificado:
Agora é possível adicionar atributos à vontade, inserindo novos valores em product_attributes e colocando registros adjacentes em product_attribute_values. Isso é basicamente o que o Magento faz (com um pouco mais de respeito pelos tipos de dados do que eu mostrei aqui). De fato, agora não há razão para dois produtos terem campos idênticos, para que possamos criar tipos de produtos inteiros com diferentes conjuntos de atributos!
No entanto, essa flexibilidade tem um custo. Se eu quiser encontrar a cor de uma camisa no meu sistema (um exemplo trivial), preciso encontrar:
O Magento costumava funcionar assim, mas era lento demais. Portanto, para permitir um melhor desempenho, eles fizeram um compromisso: assim que o dono da loja definir os atributos que deseja, vá em frente e gere a grande mesa desde o início. Quando algo mudar, retire-o do espaço e gere-o novamente. Dessa forma, os dados são armazenados principalmente em nosso bom formato flexível, mas consultados em uma única tabela.
Essas tabelas de pesquisa resultantes são os "índices" do Magento. Quando você re-indexa, está explodindo a tabela antiga e gerando-a novamente.
Espero que esclareça um pouco as coisas!
fonte
nuke it from space, nice :)Magento é um sistema bastante poderoso e complexo. Ele permite trabalhar com grandes quantidades de dados, mas quando o banco de dados é sobrecarregado com toneladas de registros, torna-se pesado e lento. Magento usa índices para resolver este problema. Os índices são tabelas adicionais do banco de dados com alguns dados simples, o que permite organizar respostas rápidas do banco de dados.
Por padrão, o sistema principal atualiza os índices no salvamento de cada item. Mas, em alguns casos, é necessário fazê-lo manualmente, por exemplo, alguns tipos de ações em massa, etc. Você pode atualizar os índices a qualquer momento a partir do administrador (Admin-> Sistema-> Gerenciamento de índice). Mas, às vezes, causa problemas.
Por exemplo, se você tiver mais de 10.000 produtos e várias categorias, a reconstrução do índice 'reescrita de URL do catálogo' poderá levar horas. Em seguida, o script php pode simplesmente quebrar devido ao excesso de max_execution_time. Existe uma maneira de resolver vários problemas executando o processo reindex na linha de comando.
fonte