Czy Magento jest odpowiednią platformą dla produktów 1M?

31

Muszę zobaczyć, jak Magento będzie działać z jednostkami SKU 1M; ale staram się znaleźć duży zestaw danych przykładowych danych do pobrania - lub znaleźć wykonalną metodę generowania pliku danych do importu (i samego procesu importowania).

  1. Czy ktoś wie, skąd mogę pobrać duży zestaw danych fikcyjnych danych do zaimportowania (lub rozsądny sposób na ich wygenerowanie i zaimportowanie)?
  2. Jakie masz problemy z katalogiem o wielkości 1M +?
  3. Czy istnieje sposób na udostępnienie jednej bazy danych produktów wielu niezależnym sklepom (różnym firmom)?
performance import Gabriele
źródło

Odpowiedzi:

36

tl;dr ->„ Czy Magento może obsługiwać produkty 1M ”, odpowiedź brzmi „ tak” , ale z pewnymi uwagami. W tej skali można by założyć, że masz wolumen, aby wesprzeć przyzwoitą inwestycję w infrastrukturę i personel, aby sprzedać katalog tej proporcji.

Pierwszy:

Przykładowe dane Magento CE, jak mogłeś zobaczyć, zawierają tylko garść produktów z różnych kategorii. Przykładowe dane EE mają więcej i są rozdzielone według typu sklepu.

Możesz pobrać przykładowe dane CE tutaj . Będziesz musiał pobrać przykładowe dane EE ze swojego konta MagentoCommerce.com, jeśli masz EE.

Przekonasz się jednak, że to nie są setki, a nawet tysiące produktów. Radzę importować produkty do bazy danych - dobre ćwiczenie, aby dowiedzieć się, jak działa ten proces. Można to zrobić za pomocą przepływu danych Magento lub importu API - informacje o tym, jak to zrobić na dużą skalę, są łatwo dostępne w Internecie.

Słowo ostrzeżenia - Przepływ danych jest notorycznie wolny, więc zaimportowanie katalogu o żądanym rozmiarze może zająć sporo czasu. O ile mi wiadomo, nie ma na miejscu przykładowego katalogu z setkami tysięcy lub milionami produktów.

Edytuj 1/7/14:

@ryaan_anthony na Twitterze wydała procedurę przechowywaną MySQL, która wygeneruje setki tysięcy produktów https://gist.github.com/ryaan-anthony/6290973

Trochę czytania o Magento API i przepływie danych:

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

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

Druga:

Produkt, przepisywanie adresów URL i indeksowanie zapasów to główne problemy podczas uruchamiania katalogu o tym rozmiarze . Wyszukiwanie katalogu może być również dość powolne, ale można je złagodzić, jeśli używasz Apache Solr (integracja zapewniona natywnie w EE). Istnieją wtyczki CE dla Solr - Sonassi ma jedną, a inne można znaleźć za pośrednictwem Google.

Zarządzałem katalogami w zakresie 700 tys., Co wciąż stanowi o wiele mniej niż 1 mln, a indeksowanie może trwać wiele godzin . Ten problem został rozwiązany w Enterprise 1.13 . Ja bardzo polecam wziąć twarde spojrzenie na Enterprise Edition w tej skali. Czy jest to możliwe dzięki CE? Absolutnie; ale ulepszenia indeksowania w EE 1.13 są specjalnie dostosowane do tego rodzaju sytuacji.

Trzeci:

Multi-sklep pochodzi z Magento; możesz skonfigurować różne kategorie i witryny najwyższego poziomu. Nie wszystkie muszą udostępniać ten sam katalog - możesz wybrać, które produkty będą udostępniane w różnych witrynach, lub zdecydować o zachowaniu segregacji katalogu. Więcej informacji tutaj:

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

Im więcej sklepów, widoków sklepu masz w Magento, tym więcej pozycji indeksu i tym bardziej twój płaski katalog może się rozrastać do tego stopnia, że ​​płaski katalog może w rzeczywistości spowodować obniżenie wydajności. Ponownie Sonassi ma mnóstwo informacji na ten temat tutaj na Magento.SE i na swojej stronie . Będziesz chciał przeszukać niektóre odpowiedzi Sonassi na Magento.SE dotyczące obsługi / skalowania Magento, gdy przejdziesz do tej dziedziny zarządzania produktem.

Instalacja każdej osoby jest inna - musisz stale testować, udoskonalać, wdrażać poprawki, aby znaleźć ustawienia, które najlepiej pasują do twojego katalogu, w twojej sytuacji.

philwinkle
źródło
Witam Dziękuję bardzo za wszystkie te informacje.
Gabriele
Baza danych jest budowana automatycznie przez system podłączony do wielu edytorów, którzy regularnie aktualizują naszą bazę danych. Zapewniamy ostateczną bazę danych i aktualizacje dla księgarń, a teraz chcemy zaoferować naszym klientom kompletne rozwiązanie e-commerce. Zrobiłem to, aby zaimportować wszystkie dane przez Magmi. To jest dla nas fantastyczne i idealne. Jeśli chodzi o indeksowanie, wybiorę rozwiązanie Solr. Nie mogę korzystać z MultiStores, ponieważ muszę zapewnić moim klientom pełny dostęp administracyjny. Jeszcze raz dziękuję!
Gabriele,
Ciekawe, że nie wspomniałeś o rozważeniu hostingu, optymalizacji db, alternatyw lub ulepszeń przepływu danych, użycia klonowania zamiast fabrycznej instancji do przetwarzania dużych danych, pamięci podręcznej i optymalizacji wydajności oraz innych opcji wydajności do optymalizacji Magento dla katalogu tego rozmiar. Czekanie kilku godzin na indeksowanie brzmi bolesnie ... dlaczego nie uruchomić klastra lub użyć mysql proxy do przetworzenia indeksowania i pozwolić synchronizacji tabeli DB po jej zakończeniu? Tylko kilka podstawowych myśli ... dostępne są również bardziej zaawansowane metody.
mprototyp
@ mprototype możesz dodać własną odpowiedź według własnego uznania.
philwinkle,
7

Użyj ApiImport do importowania tak dużej ilości produktów. Opiera się na ImportExport i bardzo szybko ... Udało mi się zarządzać do 500 000 (indeksowanych) prostych produktów na godzinę na maszynie wirtualnej.

Wystarczy uruchomić testy / benchmark_import_api.php. Edytuj ten plik, aby usunąć niepotrzebne typy jednostek (i podtypy). Możesz także ustawić USE_API na false, aby uzyskać szybsze wyniki.

Daniel Sloof
źródło
4

W przeszłości korzystaliśmy z witryny http://www.icecat.biz/en/ w celu wyodrębnienia plików danych produktów w celu załadowania przykładowych danych. Jest też kilka rozszerzeń Magento, ale one dla nas nigdy nie działały, więc napisaliśmy większość naszych skryptów importowych.

Vinci Rufus
źródło
4

aby uzyskać milion produktów w Magento. napisz prosty skrypt php, który generuje plik csv importowany z obsługą magmi produktu z różnymi rodzajami produktów. Następnie użyj magmi, aby je zaimportować

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

Sutha Kathir
źródło
Magmi jest importerem CSV, prawda? Więc muszę karmić Magm plikami csv zawierającymi katalog, prawda?
Gabriele
1
tak, na wiki jest dokumentacja, jak sformatować plik csv do importu produktu, a następnie utworzyć profil za pomocą interfejsu internetowego i użyć polecenia cli, aby zaimportować go do / usr / bin / php magmi.cli.php -profile = custom_options -mode = utwórz -CSV: nazwa_pliku = "$ {x}"; gotowe
Sutha Kathir
CSV jest jednym ze źródeł danych, z których Magmi może korzystać. Należy pamiętać, że Magmi ma interfejs pompy danych, do którego można wstrzykiwać dane bez plików CSV.
Axel
3

Niezupełnie pełna odpowiedź, ponieważ wydaje się, że inni już odpowiedzieli na większość twoich pytań, wystarczy kilka rzeczy do dodania:

1) Miałem taki problem: prawie jeden milion losowych produktów Magento w dziesięciu plikach CSV. Możesz również spróbować http://beta.generatedata.com/ .

2) Jak już wspomniał Philwinkle: indeksowanie, przepływ danych i wyszukiwanie to największa przeszkoda do pokonania przy tak dużym zestawie danych. EE1.13 radzi sobie lepiej z obsługą tak dużych danych (wyzwalacze MySQL, biorąc pod uwagę status wszystkich produktów / kategorii itp.), Ale należy pamiętać, że w tej chwili jest to wersja początkowa (x.0.0), zwykle czekam kilka wydania, aby inni mogli wziąć na siebie ciężar znalezienia błędu przed rozważeniem go jako środowiska produkcyjnego. Kluczowa jest infrastruktura i optymalizacja. Przyszłe uaktualnienie jest również czymś innym do rozważenia, ponieważ ALTER TABLEnie są one łączone podczas uaktualnień i wykonanie aktualizacji na DB może potrwać kilka godzin / dni:

Kilka dalszych lektur na temat indeksowania w dużej bazie danych:

3) Najłatwiejszym sposobem udostępniania danych między dwoma sklepami Magento byłoby przesłanie żądania REST / SOAP do API Magento innych firm. Alternatywą byłoby po prostu zrzucenie katalogu z jednej firmy i umożliwienie drugiej jego pobrania i przeanalizowania, może to być znacznie szybsze niż przejście przez interfejs API z ponad 1 milionem produktów.

B00MER
źródło
1
1) Spojrzę na to. 2) Tak, wybrałem Magmi w CE. Zobaczymy, jak to będzie działać. 3) Tak, myślę, że odrzucenie danych i import do nowego sklepu będzie naszym wyborem, chyba że znajdziemy sposób na dzielenie wspólnej bazy danych produktów między wszystkimi sklepami internetowymi. Dzięki dużo B00mer!
Gabriele
3

Właśnie pracowaliśmy nad projektem z 1,2 m (bez atrybutów, a zwłaszcza tylko jednego widoku sklepu) produktów przy użyciu magento 1.7.xi oto niektóre z naszych doświadczeń:

  1. W rzeczywistości importowanie produktów jest całkiem w porządku, myślę, że nasz początkowy import zajął około 1,5 godziny

  2. Podczas reindeksu nasz dysk io ucierpiałby bardzo, rozwiązaniem było uzyskanie dużej ilości pamięci RAM (instancja RAM Amazon Amazon SSD 32 GB). Zoptymalizuj ustawienia innodb, w których przydzielamy pamięć puli innodb nieco ponad rozmiar bazy danych, a zwłaszcza zmieniając tymczasowy bufor tabeli z domyślnych 16 MB na 128 MB, to właśnie uratowało nasz proces reindeksowania.

  3. Buforowanie, używanie tylko pamięci podręcznej APC do szybkiej pamięci podręcznej, plików do powolnej pamięci podręcznej, wyłączanie niepotrzebnego rejestrowania i modułów wraz z płaską tabelą i kilkoma innymi optymalizacjami sprawia, że ​​serwer dostarcza strony produktu w formacie HTML (nie całą stronę) w 200ms. Na naszej liście rzeczy do zrobienia jest pamięć podręczna lakieru.

  4. My, gdzie walczymy i zabijamy wiele problemów z impasem (niektóre nadal pozostają adminami), być może nowsza wersja Magento nie da tych problemów według forów.

Powiem, że naprawdę są problemy z produktami 1,2 mln, nie polecam tego robić bez posiadania odpowiedniego zespołu i zasobów, jednak jeśli masz czas, możesz to zrobić.

Nie wiem, na jakiej innej platformie byłoby lepiej.

palmik
źródło
2

Zawsze ten dobry, tak Magento CE i EE może (z doświadczenia nie teorii przy użyciu dostarczonych zestawów danych), chociaż oczywiście EE jest lepsze do indeksowania. Magmi jest w porządku, ale jeśli przyjdziesz do ponownego indeksowania początkowego obciążenia, będziesz miał poważny problem. Ponadto masz konserwację, w której jeśli 3% produktów zmienia się codziennie, musisz aktualizować 30 000 produktów z automatycznym indeksem, nie będziesz w stanie wykonywać codziennego reindeksu. Wszystko sprowadza się do dwóch rzeczy: hostingu klastrowego i wdrażania dostawcy z włączoną obsługą delty, które są domenami firm korporacyjnych.

Wydaje się, że ludzie myślą, że praca kończy się po załadowaniu produktów, ale wtedy zaczyna się ciężka praca. Jeśli masz zbyt wiele sklepów, poziom cen to twój hosting musi się podwoić, więc dla wszystkich celów i celów 95% nie ma szans na wdrożenie go, 99% nie ma szans na jego utrzymanie. Miliony produktów to średnie i duże przedsiębiorstwa - jeśli twoi konsultanci nie mają tego doświadczenia, oczekuj załamania infrastruktury w perspektywie średnio- i długoterminowej.


źródło