我在一家网络公司工作,我们目前使用 OSCommerce 的高度修改版本作为我们的主要电子商务应用程序,但最近我们与一些公司接洽,他们希望在线销售超过 200 万个单独的产品模型。
基本上我的问题是 - 是否有任何预构建的 PHP/MySQL 购物应用程序可以优雅地处理这么多产品,或者我在这方面不走运?我需要创建自定义应用程序吗?我在这里有什么选择?
nosql 数据库会比 MySQL 更好吗?
我在一家网络公司工作,我们目前使用 OSCommerce 的高度修改版本作为我们的主要电子商务应用程序,但最近我们与一些公司接洽,他们希望在线销售超过 200 万个单独的产品模型。
基本上我的问题是 - 是否有任何预构建的 PHP/MySQL 购物应用程序可以优雅地处理这么多产品,或者我在这方面不走运?我需要创建自定义应用程序吗?我在这里有什么选择?
nosql 数据库会比 MySQL 更好吗?
基本上我的问题是 - 是否有任何预构建的 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 的好消息,但我不确定预先存在的解决方案。
为响应 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 可以轻松处理这么多产品。工程.
我只是好奇是否有人认为这个设置可以做到。具有反向代理(可能是清漆)和 memcached 作为应用程序缓存的 magento 社区。产品页面上没有动态内容(因为它可以在与缓存响应的自定义交互时呈现)以将对应用程序的请求保持在绝对最低限度。使用负载平衡的 nginx 服务器。
您还可以将更结构化的数据库维护和优化程序作为一个单独的应用程序来实施。
也许您可以做一些非常激进但非常便宜的事情(我猜拥有 200 万种产品的人对您和我的廉价观念不同),将销售、税收和销售规则模块更改为不太灵活但更有效的模块。
我不知道对我来说似乎是最好的方法。每年为 magento EE 付费,而不是为了炫耀性能而花费的初始费用。
这种产品负载的最佳答案之一(顺便说一下,我们正在使用的那个)是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 转移?
我自己 10 岁的问题的答案基本上是 @jvenema 在他的评论中试图告诉我的。索引。好的指标。
10 年前我基本上不知道他在做什么,我们基本上只是在出现性能问题时才添加索引。
这些天来,数据库中的 200 万行对我来说基本上算不了什么。我现在工作的地方有数 TB 大小的表,有数十亿行。