Magento是否可以支持500,000产品？如果可以，怎样处理？

在为大型产品目录选择电子商务平台时，商家自然希望确定Magento是否是他们的正确选择，因此问题出现了：Magento实际能管理多少产品？很难给出标准答案，但绝对有依据提供一些实用参考指南。

为了更好更快的找到合适问题答案，我们先列出一些常遇到的问题点：

• 默认情况下，不同版本的Magento可以轻松管理多少产品，托管在普通服务器上，有没有额外需要的优化？

• 不同Magento版本在目录性能方面有何不同？

• Magento大型目录的主要瓶颈是什么？Magento如何扩展以处理更多产品？

• 在处理巨大的Magento目录时，人们可以犯的常见错误是什么？

默认情况下，不同版本的Magento可以轻松管理多少产品，托管在普通服务器上，有无额外扩展？

• 在大多数情况下，Magento CE 1.9.x可以管理大约10,000~25,000种产品，而无需额外的扩展*。另一方面面说，通过系统扩展，资源调整和代码优化后，它可以管理100,000到200,000个产品。

• Magento EE 13.x. 14.x在大多数情况下可以管理~100,000~ 200,000个产品，没有太多额外的扩展*；在具有适当扩展，优化和服务器资源后，可以达400,000~500,000甚至更多。

• 在大多数情况下，Magento 2 CE可以管理大约100,000~200,000个产品，没有太多的额外扩展，在具有适当扩展，优化和服务器资源后，可以达400,000~500,000甚至更多。

• Magento 2 EE旨在能够管理更多，具体取决于一些非常先进的企业功能，如数据库分片，作业队列，高级mysql和Web服务器拓扑以及适当的资源。

ps：CE即现在的社区版。

当然，所有这些都是非常粗略的数字，指的是具有一些属性，类别和简单产品的目录。这些数字基于Magento自己的性能测试和我们自己的经验。服务器设置，软件和资源也有很大差异。不同的优化配置，结果也是很大差异。   这也是为什么市面上很多反映magento不足等现象，其实真正的原因却不知如何而寻呀。

另外值得注意的是，由于Magento的数据库设计，有一些特别重要的方面，可以作为倍增因素来获得Magento在后台真正使用的实际产品数量。

影响巨大的一些最重要因素是：

• Magento商店/语言数量

• 产品属性数量

• 类别树的类别和深度的数量

• 可配置/捆绑产品的数量

• 具有不同产品价格的客户群数量

所有这些意味着就目录管理而言，在重量级目录设置中有几千种产品的Magento目录。例如~20种语言，不同的属性和类别结构，主要是可配置产品和多个客户价格组，可能在一家商店中有100,000多种简单产品的Magento目录。

这些功能用起来非常灵活，但同样也是需要牺牲部分性能为代价的。

不同Magento版本在性能上有何不同？

• Magento CE 1.x，包括1.9.x最新

              - 索引，尤其是URL和搜索索引未针对大型目录进行优化（这也适用于高达1.12.x的EE）。

              - 默认情况下，不提供整页缓存（FPC）

             +一些前端优化，如javascript + css合并，CDN支持

• Magento 1.x EE

            + FPC可用，可加快目录浏览速度并节省大量服务器资源

            +从版本1.13 + .x引入增量索引，通过cron作业在后台重新编制已更改或添加的产品。

            +从版本1.13 + .x完全重新索引流程也得到了很大改进，即使对于大型目录也能很好地工作。

            + Solr搜索引擎默认可用

• Magento 2 CE

           +从Magento EE 1.13 + .x继承增量索引功能

           +从EE 1.13 + .x继承FPC，并添加Varnish前端缓存作为FPC的选择。 Varnish缓存提供的请求永远不需要访问Magento应用程序服务器，这样可以减少Web节点上的负载，同时显着缩短响应时间。

           +浏览器缓存用于会话数据缓存

           +结账流程大大改善

           +异步订单和产品更新

           +客户端优化，如缩小，js资源捆绑，缓存静态内容，图像压缩

           +默认情况下支持PHP 7。 PHP 7甚至可以比PHP 5.x提供200％的性能提升。

• Magento 2 EE

          +具有Magento 2 CE的所有功能

          + Solr（2.0）和Elasticsearch（2.1）用于搜索

          +数据库分片可以分离目录，结帐和订单业务域

          +支持Mysql集群和Multi-master mysql设置

          +为高级后台数据处理引入的作业队列（作为第一个实现的延期库存更新）

Magento大型目录站点主要瓶颈是什么？如何提升可以让其处理更多产品？

• 服务器托管——大型目录显然需要更多资源，具有大内存的VPS和多核处理器是必须的，可能需要多节点服务器设置。

• 服务器软件 —— 强烈推荐Nginx作为Web服务器和PHP 7和Mysql 5.6或同等版本（Percona / MariaDb），即使对于Magento 1，在这种情况下，对Magento的这些服务器软件进行微调也是必不可少的。

• 产品导入 ——优化和量身定制的产品导入和更新是关键要素之一。启用批量数据库更新的工具非常有用。任何使用单一产品更新的方法或工具都是一个巨大的潜在瓶颈。 Magmi是这里最好的选择之一。

• 一些经验法则     

•       -- 只保存已更改的内
        --使用专用资源进行导入

              --单独的价格，库存和基本产品数据导入

              --仅重新索引需要重新编制索引的产品和产品数据

• 索引——Magento中的索引是保存产品数据的第二步，它是拥有庞大目录时最棘手的部分。它包含一系列过程，用于将针对数据存储优化的数据库表中的产品数据复制到针对前端数据访问的不同方面优化的表。由于Magento前端功能只需“索引”，因此可以将索引与产品保存或导入分开。在较新版本的Magento 1 EE和Magento 2 CE和EE增量背景索引中引入，这加速了管理员的工作，但可能仍然不适合大批量产品更新。

•       --Magento 1 CE中的索引是最大的瓶颈之一。

           ----URL索引倾向于提供最多的问题，部分原因是它可能膨胀到数百万条记录，部分原因是它运行了很长时间，而在Magento 1 CE中它没有针对大型目录进行优化。

           ----除了目录大小和Magento商店的数量之外，产品平面索引的增加开销将超过其优势，因此最好不要为大型目录启用此功能。

  目录搜索

      --默认的MYSQL全文搜索是资源贪婪，索引和前端的实际搜索往往很慢，其准确性和结果集的相关性相当差。所以它必须被替换，即使在Magento 1中也是如此。Magento 1有一些很好的，甚至是免费的替代品，可以用Solr，Elasticsearch或Sphinx取代MYSQL搜索。默认情况下，Magento 1 EE和Magento 2 从2.1在Elasticsearch上的有Solr。一些第三方Elasticsearch和Solr 3rd扩展可以同时替换默认的MYSQL分层导航引擎，这可以带来巨大的好处。

• 全页缓存（Full Page Cache）

      --整页缓存（FPC）是一种机制，由服务器软件生成的html页面作为一个整体进行缓存。下次需要相同的网页时，将返回缓存版本，而无需重新生成内容。在Magento 1中，CE默认没有FPC，在Magento 1中，EE缓存由Magento代码本身管理。它节省了大量资源并提高了速度，但最好的FPC方法是在Magento前面的层中实现缓存，而不需要在提供缓存内容时完全触摸Magento。这是通过Magento 2中的Varnish缓存实现的。尽管Magento 1 CE没有FPC和Varnish，但实现这些功能也有很好的扩展。

  应用缓存

  Magento严重依赖于不同类型的配置和应用程序缓存，Redis是一种基于内存的可扩展应用程序缓存，强烈建议使用管理。从最新版本的Magento 1 CE开始，处理Redis的扩展内置于Magento中。

Magento不同版本小结：

      --常见的瓶颈是后端的产品导入和索引，前端的搜索和分层导航。结帐和订单管理也是重要因素，但这些因素与访客和交易数量的关系更为密切。

      --在所有Magento版本中定制和优化批量产品导入（即使在Magento 2 EE中，功能丰富且优化的产品导入仍有待解决）。

      --Magento 1 CE是最不准备处理大型目录的平台，但通过大规模扩展，适当的服务器托管和第三方扩展，提供更好的索引，搜索和缓存，它可以大大升级。但是，索引可能仍然是一个瓶颈。

      --Magento 1 EE已经实施了一系列优化，实现Varnish缓存和微调服务器架构是进一步扩展它的最佳选择。

      --Magento 2 CE的设计应该为中型企业服务，就像Magento 1 EE一样。功能方面它缺乏企业功能，例如商店信用，更好的CMS管理等，但就性能而言，它与Magento 1 EE配对 - 或者由于Varnish甚至更好。扩展它的一个显而易见的方法是利用内置的优化选项，微调服务器架构和资源，并实现Elasticsearch或Solr进行目录搜索。

     --Magento 2 EE针对的企业甚至超出中等规模，旨在提供利用云计算优势的高度可扩展架构。

拥有大型magento目录时，常见犯的错误有哪些？

除了以上错误外，还有一些其他常见的

     --降级——也许这里最重要的建议是，以一种拥有大量系统储备的方式构建一个现场Magento商店非常重要，并且有一种经过验证的方法可以在需要时快速扩展它。整个开发周期中的性能测试非常有用，因此系统的限制是已知的。

     --太多/质量差的第三方或自定义扩展——第三方扩展并不总是为大型目录构建和测试，即使对扩展设计进行小规模监督也可能导致性能灾难。

     --缺乏合适的监控——系统监控至关重要，以便及时发现和消除问题和瓶颈。

一些技术细节

常见的magento相关术语和概念，以便更好去理解。

Magento中的数据存储

    有一点明确的是Magento非常复杂，其功能实际上超出了基于PHP / MYSQL的系统的限制。产品是非常庞大的对象，从它真正的多功能属性方案到价格，图像，类别，产品选择到不同的产品关系，它们有很多方面。

    更重要的是，所有这些属性可能具有尽可能多的不同层值，因为使用了许多商店和语言。最重要的是，这些方面可能会被许多第三方扩展所扩引用展。所有这些意味着在数据库中保存和更新产品是一项复杂的操作。

索引——为Magento的前端数据访问准备

    另一点是，主要保存产品数据的数据库表的结构针对灵活的数据存储进行了优化，但由于这种复杂性和关系数据库的性质，并未针对不同类型的数据检索同时进行优化。为了节省时间，Magento引入了所谓的索引表，这些索引表由称为索引的进程填充。

Magento中的索引：是一个将数据从针对数据存储优化的数据库表复制到为前端数据访问优化的表的过程

大多数的索引，如URL，类别/产品关系，价格，属性索引，以及搜索索引对于Magento的工作非常重要。还有一些其他可选的索引，例如目录平面和产品平面索引，它们将EAV和多商店数据展平为专用商店表和单个产品行。

Magento的索引有两个面。一方面，它使Magento最强大的功能可以工作并优化数据访问。另一方面，以前端可用的方式存储产品数据使得更加复杂，耗时和资源贪婪。

后续资料慢慢补充吧，临时简易翻译，凑合着看下。  这样对magento的选择方案，有些帮助也可以了。

PS：大家有更多经验可以尽量多多来补贴。