O Magento é a plataforma certa para os produtos da 1M?


31

Eu preciso ver como o Magento funcionará com 1M SKUs; mas estou com dificuldades para encontrar um grande conjunto de dados de amostra para download - ou para encontrar um método viável de gerar o feed para importação (e o próprio processo de importação).

  1. Alguém sabe onde eu poderia baixar um grande conjunto de dados de dados fictícios para importação (ou um meio sensato de gerá-los e importá-los)?
  2. Que problemas você pensa em ter um tamanho de catálogo de mais de 1 milhão de produtos?
  3. Existe uma maneira de compartilhar um único banco de dados de produtos com várias lojas independentes (empresas diferentes)?

Respostas:


36

tl;dr ->" O Magento pode lidar com produtos da 1M ", a resposta é sim , mas com algumas considerações. Nesta escala, presume-se que você tenha volume para apoiar um investimento decente em infraestrutura e pessoal para comercializar um catálogo dessa proporção.

Primeiro:

Os dados de amostra do Magento CE, como você já deve ter visto, têm apenas um punhado de produtos de várias categorias. Os dados de amostra do EE têm mais e os separam por tipo de loja.

Você pode fazer o download dos dados de amostra da CE aqui . Você precisará fazer o download dos dados de amostra de EE na sua conta MagentoCommerce.com se você tiver EE.

Você encontrará, no entanto, que isso não é centenas ou mesmo milhares de produtos. Aconselho que você importe produtos para o banco de dados - um bom exercício para entender como esse processo funciona. Isso pode ser feito através do fluxo de dados do Magento ou da importação da API - informações sobre como fazer isso em escala estão prontamente disponíveis na internet.

Uma palavra de cautela: o fluxo de dados é notoriamente lento; portanto, pode demorar bastante tempo para importar um catálogo do tamanho que você solicita. Que eu saiba, não existe um catálogo de amostras na natureza com centenas de milhares ou milhões de produtos que existem.


Editar 1/7/14:

@ryaan_anthony no Twitter lançou um procedimento armazenado MySQL que gerará centenas de milhares de produtos https://gist.github.com/ryaan-anthony/6290973


Algumas leituras sobre a API do Magento e o fluxo de dados:

http://www.magentocommerce.com/knowledge-base/entry/introduction-to-magento-dataflow

http://www.magentocommerce.com/api/soap/catalog/catalog.html

Segundo:

Produto, regravação de URL e indexação de inventário são os principais problemas ao executar um catálogo desse tamanho . A pesquisa de catálogo também pode ser bastante lenta, mas pode ser atenuada se você usar o Apache Solr (integração fornecida nativa ao EE). Existem plugins CE para o Solr - o Sonassi possui um, e outros podem ser encontrados no Google.

Eu gerenciei catálogos no intervalo de 700k, que ainda é muito menor que 1 milhão, e a indexação pode levar horas e horas . Isso foi abordado no Enterprise 1.13 . Eu recomendo que você dê uma olhada no Enterprise Edition nessa escala. Isso é possível com a CE? Absolutamente; mas as melhorias de indexação no EE 1.13 são especificamente adaptadas para esse tipo de situação.

Terceiro:

A loja múltipla é nativa do Magento; você pode configurar diferentes categorias e sites de nível superior. Nem todos eles precisam compartilhar o mesmo catálogo - você pode escolher quais produtos compartilhar nos sites ou decidir manter seu catálogo segregado. Mais informações aqui:

http://www.magentocommerce.com/knowledge-base/entry/overview-how-multiple-websites-stores-work

Quanto mais lojas e exibições de loja você tiver no Magento, mais entradas de índice e mais seu catálogo plano pode inchar a tal ponto que o catálogo plano pode realmente ser uma perda de desempenho. Novamente, Sonassi tem uma tonelada de informações sobre isso aqui no Magento.SE e em seu site . Você deseja pesquisar algumas das respostas da Sonassi no Magento.SE para manipular / dimensionar o Magento quando entrar neste campo de gerenciamento de produtos.

A instalação de cada pessoa é diferente - você precisa testar, refinar, implementar constantemente ajustes para descobrir quais configurações funcionam melhor para o seu catálogo, na sua situação.


Olá! Muito obrigado por todas essas informações.
Gabriele

O banco de dados é criado automaticamente por um sistema conectado a muitos editores que atualizam regularmente nosso banco de dados. Fornecemos o banco de dados final e as atualizações para livrarias e agora queremos oferecer uma solução completa de comércio eletrônico aos nossos clientes. Eu fiz isso para importar todos os dados via Magmi. É fantástico e perfeito para nós. Quanto à indexação, eu vou para a solução Solr. Não posso usar o MultiStores, pois preciso fornecer acesso de administrador completo aos meus clientes. Mais uma vez obrigado!
Gabriele 17/05

Interessante que você não tenha mencionado a consideração de hospedagem, otimização de banco de dados, alternativas ou aprimoramentos para fluxo de dados, uso de clone em vez de instanciação de fábrica para processamento de dados grande, otimização de cache e desempenho e outras opções de desempenho para otimizar o magento para um catálogo deste Tamanho. Esperar várias horas pela indexação parece doloroso ... por que não executar um cluster ou usar o proxy mysql para processar a indexação e permitir que uma tabela do banco de dados seja sincronizada quando terminar? Apenas alguns pensamentos básicos ... existem métodos mais avançados disponíveis também.
Mprototype

@mprototype sinta-se à vontade para adicionar sua própria resposta como achar melhor.
philwinkle

7

Use o ApiImport para importar uma quantidade tão grande de produtos. É baseado no ImportExport e muito rápido ... Eu gerenciei até 500 mil produtos simples (indexados) por hora em uma máquina virtual.

Basta executar testes / benchmark_import_api.php. Edite esse arquivo para remover os tipos (e subtipos) de entidade que você não precisa. Você também pode definir USE_API como false para obter resultados mais rápidos.


4

Usamos http://www.icecat.biz/en/ no passado para extrair feeds de produtos para carregar dados de amostra. Também existem algumas extensões Magento, mas elas nunca funcionaram para nós, por isso acabamos escrevendo a maioria dos nossos scripts de importação.


4

para obter mais de um milhão de produtos no magento. escreva um script php simples que gere o arquivo csv de importação de produtos suportados pela magmi com diferentes tipos de tipos de produtos. Em seguida, use o magmi para importá-los

http://sourceforge.net/apps/mediawiki/magmi/index.php?title=Magmi_Wiki


Magmi é um importador de CSV, certo? Então eu tenho que alimentar o Magm com arquivos csv que contêm o catálogo, certo?
Gabriele 13/05

1
sim, no wiki há documentação, como formatar seu csv para a importação do produto e, em seguida, criar o perfil com interface da web e usar o comando cli para importá-lo do / usr / bin / php magmi.cli.php -profile = custom_options -mode = criar -CSV: filename = "$ {x}"; done
sutha kathir

O CSV é uma das fontes de dados que a Magmi pode usar. Lembre-se de que o Magmi possui uma interface de datapump na qual você pode injetar dados, sem arquivos CSV.
Axel

3

Não é realmente uma resposta completa, pois parece que outras pessoas já abordaram a maioria das suas perguntas, apenas algumas coisas a acrescentar:

1) Eu já tive isso: quase um milhão de produtos Magento aleatórios em dez CSVs Você também pode tentar http://beta.generatedata.com/ .

2) Como Philwinkle já mencionou: indexação, fluxo de dados e pesquisa é o maior obstáculo a ser superado com um conjunto de dados tão grande. O EE1.13 faz um trabalho melhor ao lidar com dados tão grandes (MySQL Triggers, considerando todo o status do produto / categoria, etc.), mas lembre-se de que ainda é um release inicial (x.0.0) neste momento, tendo a esperar alguns lançamentos para permitir que outras pessoas assumam o ônus da descoberta de bugs antes de considerá-la um ambiente de produção. Infraestrutura e otimização são essenciais. A atualização futura também é outra coisa a considerar, pois ALTER TABLEnão é combinada durante as atualizações e pode levar horas / dias para executar a atualização no banco de dados:

Algumas leituras adicionais sobre o tópico de indexação em um banco de dados grande:

3) A maneira mais fácil de compartilhar dados entre duas lojas Magento seria através de uma solicitação REST / SOAP para as outras empresas Magento API. A alternativa seria simplesmente despejar o catálogo de uma empresa e permitir que a outra a buscasse e analisasse; pode ser muito mais rápido do que passar pela API com mais de um milhão de produtos.


1
1) Vou dar uma olhada. 2) Sim, eu fui para Magmi no CE. Vamos ver como vai funcionar. 3) Sim, acho que despejar dados e importar em nova loja será a nossa escolha, a menos que encontre uma maneira de compartilhar um banco de dados de produtos comum entre todas as lojas eletrônicas. Muito obrigado B00mer!
Gabriele

3

Acabamos de trabalhar em um projeto com produtos de 1.2m (sem atributos e, especialmente, apenas uma visualização de loja) usando o magento 1.7.xe aqui estão algumas das experiências que tivemos:

  1. Na verdade, importar os produtos é muito bom, acho que nossa importação inicial levou algo como 1,5h

  2. Ao fazer a reindexação, nosso disco io sofreria extremamente, a solução era obter uma boa quantidade de memória ram (instância ssd ram amazon ssd de 32GB). Otimize as configurações do innodb em que colocamos a alocação de memória do pool do innodb um pouco acima do tamanho do banco de dados e, principalmente, alterando o buffer da tabela temporária do padrão de 16 mb para 128 mb. Foi isso que realmente salvou nosso processo de reindexação.

  3. O cache, usando apenas o cache da APC para cache rápido, arquivos para cache lento, desativando o registro e os módulos desnecessários, juntamente com a tabela plana e algumas outras otimizações, faz com que o servidor entregue as páginas de produtos html (não a página inteira) em 200ms. Em nossa lista de tarefas está o cache de verniz.

  4. Onde lutamos e matamos muitos problemas de conflito (alguns ainda permanecem no admin), possivelmente uma versão mais recente do Magento não apresentará esses problemas de acordo com os fóruns.

Eu direi que realmente existem problemas com os produtos de 1,2 milhão, não é algo que eu recomendaria sem ter a equipe e os recursos adequados, no entanto, se você tiver tempo, poderá fazê-lo funcionar.

Não sei que outra plataforma faria um trabalho melhor.


2

Sempre bom, sim, o Magento CE & EE pode (por experiência, não teoria, usando conjuntos de dados fornecidos), embora obviamente o EE seja melhor para indexação. Magmi está bem, no entanto, quando você reindexar para a carga inicial, terá um problema sério. Além disso, você tem manutenção, onde, se 3% dos produtos mudarem diariamente, você precisará atualizar 30.000 produtos com índice automático, não será possível executar uma reindexação diária. Tudo isso se resume a duas coisas: hospedagem em cluster e integração com fornecedor habilitado para delta, que são os domínios das empresas corporativas.

As pessoas parecem pensar que o trabalho termina quando os produtos são carregados, no entanto, é quando o trabalho duro começa. Se você tiver muitas lojas, níveis de preços, sua hospedagem precisará dobrar, portanto, para todos os efeitos, 95% não têm chance de implementá-lo, 99% não têm chance de mantê-lo. Milhões de produtos são iguais a médias e grandes empresas - se seus consultores não tiverem essa experiência, espere que a infraestrutura entre em colapso a médio e longo prazo.


Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.