ฉันต้องดูว่า Magento จะทำงานกับ 1M SKUs ได้อย่างไร แต่ฉันพยายามหาชุดข้อมูลตัวอย่างขนาดใหญ่เพื่อดาวน์โหลด - หรือค้นหาวิธีที่เป็นไปได้ในการสร้างฟีดสำหรับการนำเข้า (และกระบวนการนำเข้าเอง)
คำตอบ:
tl;dr ->" Can Magento จัดการกับผลิตภัณฑ์ 1M " คำตอบคือใช่แต่มีข้อควรพิจารณาบางประการ ในระดับนี้คุณจะมีปริมาณที่จะสนับสนุนการลงทุนที่เหมาะสมในโครงสร้างพื้นฐานและบุคลากรในการจัดทำแคตตาล็อกของสัดส่วนนี้
ครั้งแรก:
ข้อมูลตัวอย่าง Magento CE อย่างที่คุณอาจเห็นมีเพียงไม่กี่ผลิตภัณฑ์จากหมวดหมู่ที่แตกต่างกัน ข้อมูลตัวอย่าง EE มีมากขึ้นและแยกออกเป็นประเภทร้านค้า
คุณสามารถดาวน์โหลดข้อมูลตัวอย่าง CE ที่นี่ คุณจะต้องดาวน์โหลดข้อมูลตัวอย่าง EE จากภายใน MagentoCommerce.com ของคุณหากคุณมี EE
คุณจะพบว่านี่ไม่ใช่ผลิตภัณฑ์นับร้อยหรือพันรายการ ฉันอยากจะแนะนำให้คุณนำเข้าผลิตภัณฑ์เข้าสู่ฐานข้อมูล - เป็นการออกกำลังกายที่ดีเพื่อให้ทราบว่ากระบวนการทำงานอย่างไร ซึ่งสามารถทำได้ผ่าน Dataflow ของวีโอไอพีหรือผ่านการนำเข้า API - ข้อมูลเกี่ยวกับวิธีการทำสิ่งนี้ในระดับพร้อมใช้งานบนอินเทอร์เน็ต
คำเตือน - Dataflow ช้ามากดังนั้นอาจใช้เวลาพอสมควรในการนำเข้าแคตตาล็อกตามขนาดที่คุณต้องการ สำหรับความรู้ของฉันไม่มีแคตตาล็อกตัวอย่างในป่าที่มีผลิตภัณฑ์นับแสนหรือล้านที่มีอยู่
แก้ไข 1/7/14:
@ryaan_anthony บน Twitter ปล่อยขั้นตอนการจัดเก็บ MySQL ที่จะสร้างผลิตภัณฑ์หลายแสนรายการhttps://gist.github.com/ryaan-anthony/6290973
การอ่าน Magento API และ Dataflow:
http://www.magentocommerce.com/knowledge-base/entry/introduction-to-magento-dataflow
http://www.magentocommerce.com/api/soap/catalog/catalog.html
ประการที่สอง:
ผลิตภัณฑ์การเขียนซ้ำ URL และการจัดทำดัชนีสินค้าคงคลังเป็นปัญหาสำคัญเมื่อเรียกใช้แคตตาล็อกขนาดนี้ การค้นหาแคตตาล็อกอาจค่อนข้างช้าเช่นกัน แต่สามารถลดลงได้หากคุณใช้ Apache Solr (การรวมที่จัดเตรียมไว้ให้กับ EE) มีปลั๊กอิน CE สำหรับ Solr - Sonassiมีหนึ่งรายการและอื่น ๆสามารถพบได้ผ่าน Google
ฉันจัดการแคตตาล็อกในช่วง 700k ซึ่งยังมีข้อตกลงน้อยกว่า 1M และการสร้างดัชนีอาจใช้เวลาหลายชั่วโมงต่อชั่วโมง นี้ได้รับการแก้ไขในองค์กร 1.13 ฉันขอแนะนำให้คุณดูที่ Enterprise Edition ในระดับนี้ เป็นไปได้กับ CE หรือไม่ แน่นอน; แต่การปรับปรุงการจัดทำดัชนีใน EE 1.13 ได้รับการปรับให้เหมาะกับสถานการณ์เช่นนี้
ที่สาม:
Multi-store เป็นของ Magento; คุณสามารถตั้งค่าหมวดหมู่และเว็บไซต์ระดับบนสุดที่แตกต่างกัน พวกเขาไม่จำเป็นต้องแบ่งปันแคตตาล็อกเดียวกันทั้งหมด - คุณสามารถเลือกผลิตภัณฑ์ที่จะแชร์ข้ามไซต์หรือตัดสินใจแยกแคตตาล็อกของคุณ ข้อมูลเพิ่มเติมที่นี่:
http://www.magentocommerce.com/knowledge-base/entry/overview-how-multiple-websites-stores-work
ยิ่งมีร้านค้ามากเท่าไหร่ร้านค้าที่คุณมีในวีโอไอพียิ่งมีรายการดัชนีมากขึ้นเท่าไหร่แคตตาล็อกแบบแฟลตของคุณก็อาจขยายไปจนถึงจุดที่แคตตาล็อกแบบแบนอาจจะทำให้ประสิทธิภาพลดลง อีกครั้ง Sonassi มีตันของข้อมูลเกี่ยวกับเรื่องนี้ที่นี่ใน Magento.SE และบนเว็บไซต์ของพวกเขา คุณจะต้องค้นหาคำตอบของ Sonassi ใน Magento.SE สำหรับการจัดการ / การปรับ Magento เมื่อคุณเข้าสู่ขอบเขตของการจัดการผลิตภัณฑ์นี้
การติดตั้งของทุกคนนั้นแตกต่างกัน - คุณต้องทดสอบปรับแต่งปรับใช้อย่างสม่ำเสมอเพื่อค้นหาการตั้งค่าที่ดีที่สุดสำหรับแคตตาล็อกของคุณในสถานการณ์ของคุณ
ใช้ApiImportเพื่อนำเข้าผลิตภัณฑ์จำนวนมากเช่นนี้ มันขึ้นอยู่กับ ImportExport และรวดเร็วมาก ... ฉันจัดการผลิตภัณฑ์ง่าย ๆ ได้มากถึง 500k (ดัชนี) ต่อชั่วโมงบนเครื่องเสมือน
เพียงเรียกใช้การทดสอบ / benchmark_import_api.php แก้ไขไฟล์นั้นเพื่อลบประเภทเอนทิตี (และชนิดย่อย) ที่คุณไม่ต้องการ คุณอาจต้องการตั้งค่า USE_API เป็น false เพื่อให้ได้ผลลัพธ์ที่เร็วขึ้น
เราเคยใช้http://www.icecat.biz/en/ในอดีตเพื่อแยกฟีดผลิตภัณฑ์สำหรับการโหลดในข้อมูลตัวอย่าง มีส่วนขยายของวีโอไอพีสองสามตัวเช่นกัน แต่ก็ไม่ได้ผลสำหรับเราดังนั้นเราจึงเขียนสคริปต์นำเข้าเกือบทั้งหมด
เพื่อรับผลิตภัณฑ์หนึ่งล้านชิ้นขึ้นไปในคุณภาพเยี่ยม เขียนสคริปต์ PHP อย่างง่ายซึ่งสร้างไฟล์ csv นำเข้าผลิตภัณฑ์ที่สนับสนุน magmi ด้วยประเภทผลิตภัณฑ์ที่แตกต่างกัน จากนั้นใช้ magmi เพื่อนำเข้าพวกเขา
http://sourceforge.net/apps/mediawiki/magmi/index.php?title=Magmi_Wiki
ไม่ใช่คำตอบแบบเต็มจริง ๆ เพราะดูเหมือนว่าคนอื่น ๆ ได้ตอบคำถามส่วนใหญ่ของคุณไปแล้วเพียงเพิ่มบางสิ่ง:
1)ฉันมีรอบนี้: เกือบหนึ่งล้านผลิตภัณฑ์วีโอไอพีแบบสุ่มในสิบ CSVs คุณยังสามารถลองhttp://beta.generatedata.com/
2)ดังที่ Philwinkle ได้กล่าวถึงแล้ว: การจัดทำดัชนีการไหลของข้อมูลและการค้นหาเป็นอุปสรรค์ที่ใหญ่ที่สุดที่จะเอาชนะด้วยชุดข้อมูลขนาดใหญ่เช่นนี้ EE1.13 ทำงานได้ดีกว่าในการจัดการข้อมูลขนาดใหญ่ (MySQL Triggers, พิจารณาสถานะผลิตภัณฑ์ / หมวดหมู่ทั้งหมด ฯลฯ ) แต่โปรดจำไว้ว่ามันยังคงเป็นรุ่นแรก (x.0.0) ในตอนนี้ฉันมักจะรอสักครู่ เผยแพร่เพื่อให้ผู้อื่นรับภาระในการค้นหาข้อบกพร่องก่อนที่จะพิจารณาสำหรับสภาพแวดล้อมการผลิต โครงสร้างพื้นฐานและการเพิ่มประสิทธิภาพเป็นกุญแจสำคัญ การอัพเกรดในอนาคตเป็นอย่างอื่นที่ต้องพิจารณาเนื่องจากALTER TABLEจะไม่รวมระหว่างการอัพเกรดและอาจใช้เวลาหลายชั่วโมง / วันในการอัพเกรดบนฐานข้อมูล:
อ่านเพิ่มเติมเกี่ยวกับหัวข้อของการจัดทำดัชนีในฐานข้อมูลขนาดใหญ่:
3)วิธีที่ง่ายที่สุดในการแบ่งปันข้อมูลระหว่างร้านค้า Magento สองแห่งคือการร้องขอ REST / SOAP ให้กับ บริษัท อื่น ๆ ใน Magento API อีกทางเลือกหนึ่งคือการทิ้งแคตตาล็อกจาก บริษัท หนึ่งและอนุญาตให้ บริษัท อื่นหยิบมันมาและแยกวิเคราะห์มันอาจเร็วกว่าการผ่าน API ด้วยผลิตภัณฑ์มากกว่า 1 ล้านรายการ
เราเพิ่งทำงานในโครงการที่มี 1.2m (ไม่มีแอททริบิวต์และโดยเฉพาะอย่างยิ่งหนึ่งวิวร้านค้า) ผลิตภัณฑ์ที่ใช้ magento 1.7.x และนี่คือประสบการณ์ที่เรามี:
จริง ๆ แล้วการนำเข้าผลิตภัณฑ์ค่อนข้างดีฉันคิดว่าการนำเข้าครั้งแรกของเราใช้เวลาประมาณ 1.5 ชม
เมื่อทำ reindex ดิสก์ io ของเราจะได้รับผลกระทบอย่างมากทางออกคือได้ ram จำนวนมาก (อินสแตนซ์ 32gb ram amazon ssd) ปรับการตั้งค่า innodb ให้เหมาะสมที่สุดซึ่งเราวางการจัดสรรหน่วยความจำ innodb ให้เล็กกว่าขนาดของฐานข้อมูลและโดยเฉพาะอย่างยิ่งการเปลี่ยนบัฟเฟอร์ตารางชั่วคราวจากค่าเริ่มต้น 16mb เป็น 128mb นี่คือสิ่งที่บันทึกกระบวนการการทำดัชนีใหม่ของเรา
แคชที่ใช้แคช APC เท่านั้นสำหรับแคชที่รวดเร็วไฟล์สำหรับแคชที่ช้าปิดการบันทึกที่ไม่จำเป็นและโมดูลพร้อมกับโต๊ะแบนและการเพิ่มประสิทธิภาพอื่น ๆ ทำให้เซิร์ฟเวอร์ส่งมอบหน้าผลิตภัณฑ์ html (ไม่ใช่ทั้งหน้า) ใน 200ms ในรายการสิ่งที่ต้องทำของเราคือวานิชแคช
เราที่ซึ่งการต่อสู้และฆ่าปัญหาการหยุดชะงักจำนวนมาก (บางส่วนในผู้ดูแลระบบยังคงอยู่) อาจเป็นเวอร์ชันใหม่กว่าของ Magento ที่จะไม่ให้ปัญหาเหล่านี้ตามฟอรัม
ฉันจะบอกว่ามีปัญหาเกี่ยวกับผลิตภัณฑ์ 1.2 ม. ไม่ใช่สิ่งที่ฉันแนะนำให้ทำโดยไม่ต้องมีทีมงานและทรัพยากรที่เหมาะสม แต่ถ้าคุณมีเวลาคุณก็สามารถทำงานได้
ฉันไม่รู้ว่าแพลตฟอร์มอื่นจะทำอะไรได้ดีกว่านี้
สิ่งนี้ดีเสมอใช่ Magento CE & EE สามารถ (จากประสบการณ์ไม่ใช่ทฤษฎีโดยใช้ชุดข้อมูลที่ให้มา) แม้ว่า EE จะดีกว่าสำหรับการทำดัชนี Magmi นั้นดี แต่เมื่อคุณทำดัชนีสำหรับการโหลดครั้งแรกคุณจะมีปัญหาร้ายแรง นอกจากนั้นคุณยังต้องบำรุงรักษาซึ่งหาก 3% ของผลิตภัณฑ์เปลี่ยนไปทุกวันคุณต้องอัปเดตผลิตภัณฑ์ 30,000 รายการด้วยดัชนีอัตโนมัติคุณจะไม่สามารถทำดัชนีใหม่ได้ทุกวัน ทั้งหมดนี้มีสองสิ่งคือการโฮสต์และการเปิดใช้งานซัพพลายเออร์แบบออนไลน์บนเดลต้าซึ่งเป็นโดเมนของ บริษัท องค์กร
คนดูเหมือนจะคิดว่างานจะจบลงเมื่อมีการโหลดผลิตภัณฑ์อย่างไรก็ตามนั่นคือเมื่อเริ่มทำงานหนัก หากคุณมีร้านค้ามากเกินไปการกำหนดราคาระดับนั้นโฮสติ้งของคุณจำเป็นต้องเพิ่มเป็นสองเท่าดังนั้นสำหรับทุกเจตนาและวัตถุประสงค์ 95% ไม่มีโอกาสที่จะใช้มัน 99% ไม่มีโอกาสที่จะรักษามัน ผลิตภัณฑ์นับล้านเท่ากับองค์กรขนาดกลางถึงขนาดใหญ่ - หากที่ปรึกษาของคุณไม่มีประสบการณ์นี้คาดว่าโครงสร้างพื้นฐานจะยุบตัวในระยะปานกลางถึงระยะยาว
Magmi นั้นยอดเยี่ยมสำหรับการนำเข้าผลิตภัณฑ์จำนวนมากเช่นกัน http://sourceforge.net/apps/mediawiki/magmi/index.php?title=Magmi_Wiki
เรากำลังดำเนินการพัฒนาสำหรับลูกค้าในขณะนี้ที่มี 2.2 ล้าน SKUs การนำเข้าเริ่มต้นทำได้โดยใช้ Magmi