如何处理 200 万种产品
我在一家网络公司工作，我们目前使用经过高度修改的 OSCommerce 版本作为我们的主要电子商务应用程序，但最近许多公司与我们接洽，他们希望在线销售超过 200 万个单独的产品模型。
从本质上讲，我的问题是 - 是否有任何预构建的 PHP/MySQL 购物应用程序可以优雅地处理这么多产品，或者我在这方面运气不佳？我需要创建一个自定义应用程序吗？我在这里有什么选择？
nosql 数据库会比 MySQL 更好吗？
I work for a web company and we currently use a highly modified version of OSCommerce as our primary ecommerce application, but recently we have been approached by a number of companies with over 2 million individual product models they want to sell online.
Essentially my question is - are there any prebuilt PHP/MySQL shopping applications that are going to handle this many products gracefully or am I out of luck on that front? Am I going to need to create a custom app? What are my options here?
Would a nosql database be better than MySQL?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
不。如果有这些拥有 2,000,000 种产品的公司就会使用它。
你已经有了。您以 OS Commerce 作为基础开始，并在其之上构建了一个自定义应用程序。您可能不认为它是一个应用程序，但它确实是一个应用程序。
承认您需要一个像样的 IT/开发团队来完成这项工作，并评估该成本和研发是否值得去完成这项新业务。
不。但是 MySQL 数据库也不会比“nosql”数据库更好。
No. If there was these companies with the 2,000,000 products would be using it.
You already have. You started with OS Commerce as a base and built a custom application on top of it. You may not think of it as an application, but it is.
Accept that you'll need a decent IT/Development team to chase after this work, and asses if that cost and R&D is worth going after this new business.
No. But a MySQL database wouldn't be better than a "nosql" database either.
您肯定想构建一个定制解决方案，并且您肯定想收取比平常高得多的费用，因为需要承担很多风险和尽职调查。
至于您的架构，使用 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 是其中最好的。
You definitely want to build a custom solution, and you definitely want to charge a lot more than you normally would because there's a lot of risk and due diligence needed.
As for your architecture, using NoSQL is possible and there are some compelling reasons behind using NoSQL for ecommerce - the main reason being that it is schemaless and if you have a ton of categories and a ton of products which all need to be sold differently (ie you sell computers differently than you sell watches) because the product attributes are different, managing database complexity becomes really important.
This video will show you what a really forward thinking start-up in NYC is doing. They're using MongoDB for their entire product database. This video should be a real eye opener as it outlines a lot of the pitfalls in MySQL for big ecommerce sites, and alot of the game-changing potential of NoSQL:
http://engineering.shopopensky.com/topics/mongodb
As for handling payments, you definitely do NOT want to store those in NoSQL. Keep your users, sessions, and payment data in MySQL and make sure it's highly secured. Here is a great (even though old) piece on securing sessions in PHP applications:
http://www.troubleshooters.com/codecorn/php/persist.htm
As a note, this last link should help you understand the theory better. Most PHP frameworks support this type of session handling out of the box. CodeIgniter, Yii, and ZendFramework are among the best.
您没有明确说明这是 200 万件产品的库存还是他们想要销售的 200 万件单独的商品。不管怎样，传统的 SQL 数据库应该能够很好地处理它，尽管这完全取决于模式的设计方式等。尽管我听说过 Magento 的好消息，但我不确定现有的解决方案。
You don't make it clear as to whether that's an inventory of 2 million products or 2 million individual items they'd like to sell. Either way a traditional SQL database should be able to handle it fine, although this is entirely dependent on how the schema is designed, etc. I'm not sure about pre-existing solutions though although I've heard good things about Magento.
为了响应 Magento Enterprise 的建议，我们最近为我们的网站实施了此应用程序，该网站包含大约 150,000 多个 SKU。我们也从广泛定制的 osCommerce 版本迁移。由于企业系统运行速度缓慢以及缺乏实施文档，我们的经历是令人沮丧和项目延迟。因此，我们实际上无法使用企业版的大部分功能。
该应用程序因缺乏文档和 Varien 支持团队响应缓慢而臭名昭著，我们已经亲身经历过这一点。模板系统似乎只是部分完成，并且没有经过特别深思熟虑。 Alan Storm 是您问题的回答者之一，他写得很好，而且在 stackoverflow.com 上给出了慷慨的回答，他实际上是我们团队的救世主。
我的建议是事先对 Magento Enterprise 平台进行广泛的研究 - 它与社区版本不同。正如鲍勃·布罗迪（Bob Brodie）上面发布的那样，服务器要求和设置不适合胆小的人，而且也不便宜。研究可用的速度增强选项 - 您将需要它们、服务器开销成本、考虑学习曲线和它将添加到项目时间表中的额外时间 - Magento 与 osCommerce 显着不同 - 最重要的是找到一个可靠、经验丰富的网络托管服务商在您支付 12,000 美元的一年许可费之前。
In response to the Magento Enterprise suggestion, we've recently implemented this application for our site which carries approximately 150,000+ SKU's. We too were migrating from an extensively customized osCommerce version. Our experience has been one of frustration and project delays because of the slow speed with which the enterprise system functions as well as lack of documentation for implementation. We've actually been unable to use much of the enterprise edition functionality because of this.
The application is notorious for its lack of documentation and slow response from the Varien support team, which we've experienced first hand. The templating system appears to be only partially complete, and not particularly well thought out. One of the responders to your question, Alan Storm, has actually been a savior to our team with his well written tutorials and generous stackoverflow.com answers.
My recommendation is to do extensive research beforehand of the Magento Enterprise platform - it is not the same as the community version. As Bob Brodie posted above, the server requirements and setup are not for the faint of heart, nor are they inexpensive. Investigate the speed enhancement options available - you will need them, the server overhead costs, consider the learning curve and additional time that it will add to the project timeline - Magento is significantly different from osCommerce - and above all find a reliable, experienced web host before you pay the $12,000 One Year licensing fee.
根据预算，Magento Enterprise 可能是您的一个不错的解决方案。 （我这么说不是为了卖，我不是合伙人）。您可以构建解决方案，也可以让托管公司帮助您。 Rackspace 是一流的合作伙伴托管公司，擅长将这些解决方案整合在一起。有很多数字在起作用，例如峰值同时连接数、每小时页面浏览量、每小时事务数等。您需要研究至少有 2 个 MySQL 服务器（主/从复制）和多个 MySQL 服务器的服务器。负载均衡器后面的前端服务器。看看 nginx，而不是 Apache。您还需要查看 apc & memcached 用于缓存。这样的设置会有很长的路要走。如果设置正确，Magento Enterprise 可以轻松处理这么多产品。需要记住的重要一点是，自定义解决方案不需要开发 - 它需要设计。
Depending on budget, Magento Enterprise may be a good solution for you. (I don't say that to sell it, I'm not a partner). You could either architect the solution or have a hosting company help you out. Rackspace is the premier partner hosting company and is great at putting these solutions together. There are a lot of numbers that come into play, such as peak simultaneous connections, pageviews per hour, transactions per hour, etc. You'd want to look into something that has at least 2 MySQL servers (master/slave replication) and multiple frontend servers behind a loadbalancer. Instead of Apache, take a look into nginx. You'll also want to check out apc & memcached for caching. A setup like that will go a long way. When set up correctly, Magento Enterprise could handle this many products with ease. The important thing to remember is that a custom solution wouldn't need to be developed - it would need to be engineered.
我只是好奇是否有人认为这个设置可以做到这一点。
magento 社区使用反向代理（可能是 varnish）和 memcached 作为应用程序的缓存。产品页面上没有动态内容（因为它可以在与缓存响应的自定义交互时呈现），以将对应用程序的请求保持在绝对最低限度。
使用负载平衡的 nginx 服务器。
您还可以作为单独的应用程序实施更结构化的数据库维护和优化过程。
也许你可以做一些相当激进但相当便宜的事情（我猜那些拥有 200 万种产品的人对你和我来说便宜有不同的想法），将销售、税收和销售规则模块更改为不太灵活但更高效的东西。
我不知道这对我来说似乎是最好的方式。每年支付 magento EE 与初始支出
夸耀表现。
i'm just curious if anyone thinks that this set up could do it.
magento community with a reverse proxy (probably varnish) and memcached as the app's cache. with no dynamic content on the product pages (since it could be rendered upon custom interaction with the cached response) to keep requests to app to an absolute minimum.
using load balanced nginx servers.
also you could implement more structured database maintenance and optimisation procedures as a separate app.
maybe you could do something quite radical, but quite cheaply (i guess the guys with 2 millions products have a different idea of cheap to you and me), change the sales, tax and sales rule modules to something less flexible but more efficient.
i dunno seems like the best way to me. paying for magento EE every year vs a initial spend to
boast performance.
这种产品负载的最佳答案之一（顺便说一句，我们正在使用的）是 https://magento.stackexchange.com/questions/459/running-magento-in-an-aws-environment
我们正在 Amazon 上运行自定义 magento 社区 (1.9) 服务器Web 服务 beanstalk 环境，包括用于产品的 RDS、用于缓存的 redis S3->与 Magento 相关的媒体的 CDN。现在还处于早期阶段，但到目前为止我们还没有发现真正的问题。预计开发时间...从具有本地 mysql/cache/apache/php 的 VPS 传输可能需要一周左右？
One of the best answers to this sort of product load (and, incidentally, the one we're using) is https://magento.stackexchange.com/questions/459/running-magento-in-an-aws-environment
We're running a custom magento community (1.9) server on an Amazon Web Services beanstalk environment with RDS for products, redis for cache & S3 -> CDN for the media associated with Magento. It's early days, but we've found no real issues so far. Estimated development time... maybe a week or so to transfer from a VPS with local mysql / cache / apache / php?
我自己 10 年前的问题的答案基本上就是 @jvenema 在他的评论中试图告诉我的内容。索引。良好的指标。
10 年前，我基本上不知道他在做什么，我们基本上只是在出现性能问题时才添加索引。
如今，数据库中的 200 万行对我来说基本上不算什么。在我现在工作的地方，我们的表大小为 TB，包含数十亿行。
The answer to my own 10 year old question is basically what @jvenema was trying to tell me in his comment. Indexes. Good indexes.
10 years ago me had essentially no idea what he was doing, we largely only added indexes when there was a performance issue.
2 million rows in a database to me these days is basically nothing. Where I work now we have tables terabytes in size with billions and billions of rows.