我在一家网络公司工作，我们目前使用经过高度修改的 OSCommerce 版本作为我们的主要电子商务应用程序，但最近一些公司与我们接洽，他们希望在线销售超过 200 万种单独的产品模型。
基本上我的问题是 - 是否有任何预构建的 PHP/MySQL 购物应用程序可以优雅地处理这么多产品，还是我在这方面不走运？我需要创建自定义应用程序吗？我在这里有什么选择？
nosql 数据库会比 MySQL 更好吗？
【问题讨论】：
标签： mysql magento e-commerce oscommerce
我自己 10 岁的问题的答案基本上是 @jvenema 在他的评论中试图告诉我的。索引。良好的索引。
10 年前我基本上不知道他在做什么，我们基本上只是在出现性能问题时才添加索引。
这些天来，数据库中的 200 万行对我来说基本上不算什么。我现在工作的地方有数 TB 大小的表，有数十亿行。
【讨论】：
对于此类产品负载（顺便说一下，我们正在使用的产品）的最佳答案之一是https://magento.stackexchange.com/questions/459/running-magento-in-an-aws-environment
我们在 Amazon Web Services beanstalk 环境中运行自定义 magento 社区 (1.9) 服务器，其中 RDS 用于产品，redis 用于缓存和 S3 -> CDN 用于与 Magento 关联的媒体。现在还为时尚早，但到目前为止我们还没有发现任何真正的问题。预计开发时间...可能需要一周左右的时间从本地 mysql/cache/apache/php 的 VPS 转移？
【讨论】：
我只是好奇是否有人认为这种设置可以做到。 具有反向代理（可能是清漆）和 memcached 作为应用程序缓存的 magento 社区。产品页面上没有动态内容（因为它可以在与缓存响应的自定义交互时呈现），以将对应用程序的请求保持在绝对最低限度。 使用负载平衡的 nginx 服务器。
您还可以将更结构化的数据库维护和优化程序作为单独的应用程序来实施。
也许你可以做一些非常激进但非常便宜的事情（我猜拥有 200 万种产品的人对你和我的廉价观念不同），将销售、税收和销售规则模块更改为不太灵活但更多的东西高效。
我不知道对我来说似乎是最好的方法。每年支付 magento EE 与初始支出 夸业绩。
【讨论】：
为了响应 Magento Enterprise 的建议，我们最近为我们的网站实施了此应用程序，该应用程序包含大约 150,000 多个 SKU。我们也是从一个广泛定制的 osCommerce 版本迁移过来的。由于企业系统运行速度缓慢以及缺乏实施文档，我们的经历是挫折和项目延迟之一。因此，我们实际上无法使用大部分企业版功能。
该应用程序因缺乏文档和 Varien 支持团队的缓慢响应而臭名昭著，我们亲身体验过。模板系统似乎只是部分完成，并且没有经过深思熟虑。您的问题的一位回答者 Alan Storm 实际上是我们团队的救星，他编写了良好的教程和慷慨的 stackoverflow.com 答案。
我的建议是事先对 Magento Enterprise 平台进行广泛的研究——它与社区版本不同。正如 Bob Brodie 上面所说，服务器要求和设置不适合胆小的人，也不便宜。调查可用的速度增强选项 - 您将需要它们、服务器开销成本、考虑学习曲线和它将添加到项目时间表中的额外时间 - Magento 与 osCommerce 有很大不同 - 最重要的是找到一个可靠、经验丰富的网络主机在您支付 12,000 美元的一年许可费之前。
【讨论】：
根据预算，Magento Enterprise 可能是您的理想解决方案。 （我不是说要卖，我不是合伙人）。您可以设计解决方案或让托管公司帮助您。 Rackspace 是主要的合作伙伴托管公司，擅长将这些解决方案整合在一起。有很多数字可以发挥作用，例如峰值同时连接数、每小时的页面浏览量、每小时的事务数等。您需要研究至少具有 2 个 MySQL 服务器（主/从复制）和多个负载均衡器后面的前端服务器。代替 Apache，看看 nginx。您还需要查看 apc 和 memcached 的缓存。像这样的设置将有很长的路要走。如果设置正确，Magento Enterprise 可以轻松处理这么多产品。要记住的重要一点是，不需要开发自定义解决方案 - 它需要设计。
【讨论】：
基本上我的问题是 - 是否有任何预构建的 PHP/MySQL 购物应用程序可以优雅地处理这么多产品
没有。如果有这些拥有 2,000,000 种产品的公司会使用它。
我是否需要创建自定义应用程序？
你已经有了。您从 OS Commerce 作为基础开始并在其上构建了一个自定义应用程序。你可能不认为它是一个应用程序，但它确实是。
我有什么选择？
接受你需要一个体面的 IT/开发团队来完成这项工作，并评估这项新业务是否值得投入成本和研发。
nosql 数据库会比 MySQL 更好吗？
没有。但是 MySQL 数据库也不会比“nosql”数据库好。
【讨论】：
您肯定想构建一个自定义解决方案，并且您肯定希望收取比平时更多的费用，因为需要承担很多风险和尽职调查。
就您的架构而言，使用 NoSQL 是可能的，并且在电子商务中使用 NoSQL 背后有一些令人信服的理由 - 主要原因是它是无模式的，如果您有大量类别和大量产品，所有这些都需要由于产品属性不同，因此销售方式不同（即您销售计算机的方式与销售手表的方式不同），管理数据库复杂性变得非常重要。
本视频将向您展示纽约市一家真正具有前瞻性的初创公司正在做什么。他们将 MongoDB 用于他们的整个产品数据库。这个视频应该是一个真正的大开眼界，因为它概述了大型电子商务网站在 MySQL 中的许多陷阱，以及 NoSQL 的许多改变游戏规则的潜力：
http://engineering.shopopensky.com/topics/mongodb
至于处理付款，您绝对不想将它们存储在 NoSQL 中。将您的用户、会话和支付数据保存在 MySQL 中，并确保其高度安全。这是一篇关于在 PHP 应用程序中保护会话的好文章（尽管很旧）：
http://www.troubleshooters.com/codecorn/php/persist.htm
请注意，最后一个链接应该可以帮助您更好地理解理论。大多数 PHP 框架开箱即用地支持这种类型的会话处理。 CodeIgniter、Yii 和 ZendFramework 名列前茅。
【讨论】：
您没有明确说明这是 200 万件产品的库存，还是他们想要销售的 200 万件单件商品的库存。无论哪种方式，传统的 SQL 数据库都应该能够很好地处理它，尽管这完全取决于模式的设计方式等。尽管我听说过有关 Magento 的好消息，但我不确定预先存在的解决方案。
【讨论】：