PHP和MySQL高流量解决方案
考虑创建具有许多并行用户的高流量 PHP 网站。就有效性而言（ORM 或 OODBMS），哪一个是最好的 MySQL 抽象（15-20 个数据库表，总计约 100000 个项目，并且在不超过 4 个表之间进行 JOIN 查询）？
我在哪里听说 Doctrine 库是合适的，或者我应该使用像 Zend 这样的框架？其中哪些数据库解决方案是基于 PDO 构建的并且不需要太多学习（目前我使用的是纯 PHP）？
Consider the creation of high traffic PHP web-site with many parallel users. Which is the best possible MySQL abstraction (ORM or OODBMS) in terms of effectiveness (15-20 database tables with sum of about 100000 items and JOIN queries between no more than 4 tables)?
Somewhere I heard that Doctrine libraries are appropriate or I should use framework like Zend? Which of these database solutions are build over PDO and don't require much learning (at this time I'm using pure PHP)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
无论哪种数据库解决方案，您都应该考虑使用像 MemCached 这样的系统。通过正确的缓存策略，您将显着减少数据库给服务器带来的负载。
这里有一个用于 memcached 的 PHP API
Regardless of the DB solution you should look at using a system like MemCached. With the proper caching strategy you will significantly reduce the load your databases are putting on your server.
There is a PHP API for memcached here
ORM 或任何数据建模层永远不会为您带来更好的性能。它们的唯一目的是让您的开发时间更快、更容易维护。当涉及到实际正确使用关系并最终查询所有表以找到正确的数据时，他们在决策方面是出了名的糟糕。在这种复杂查询级别，您将无法在不牺牲性能的情况下抽象出这些关系。
MySQL 至少可以处理数百万条记录（我已经在单个表中使用它处理了超过 1 亿条记录）。出于性能考虑，您通常希望至少有一个主/从设置以及在它们之间分配读取的某种方法。数据库几乎总是性能的限制因素。您始终可以添加更多 Web 服务器并在它们前面获得负载平衡，以解决问题的另一面，但数据库设置总是有点难以维护。
你必须考虑为什么要使用 ORM。如果是出于开发原因，那很好，但要认识到你的性能会受到影响。否则坚持查询。 ORM 添加了第三层代码来处理和学习。如果您了解 PHP 和 MySQL，您是否需要学习第三种语言才能有效地使用它们？大多数情况下答案是否定的。
您有很多选项可供选择，但请注意，在某些时候您选择的框架/ORM 不会按照您想要的方式运行，并且要让它按照您的愿望运行，您将必须进行大量搜索和挖掘代码。这是一个典型的问题——预先节省时间，稍后再付费，或者预先花费时间，但以后却没有可能获得回报。
ORM or any data modeling layer will never get you better performance. Their sole purposes is to make your development time faster and easier to maintain. They are notoriously bad at decision making when it comes to actually using relationships appropriately and end up querying all tables in order to find the correct data. At that level of complex queries you are not going to be able to abstract away these relationships without sacrificing performance.
MySQL is fine for up to a couple million records at least (I've used it for over 100 million in a single table). For performance sake you generally want to have at least a master/slave setup and some method of distributing reads between them. The database will almost always be the limiting factor in performance. You can always add in more web servers and get a load balance in front of them to solve the other side of things but the database setup is always a little harder to maintain.
You have to think about why you want to use an ORM. If its for development reasons, that's fine, but be coginiscent that your performance will suffer. Otherwise stick to queries. An ORM adds a third layer of code to deal with and learn. If you know PHP and MySQL, do you need to learn a 3rd language to use them effectively? Most often the answer is no.
You have many options to choose from but be aware that at some point the framework/ORM you choose will not behave the way you want it to and to get it to behave to your desires you will have to do a lot of searching and digging through code. It's the classic problem - save time up front and pay for it later or spend time up front with no possible payoff later.
如果您缓存查询数据并以有计划且深思熟虑的方式使用对象 API，ORM 解决方案将能够优化某些方面。
如果您有大量（数百万+）记录并且仍在增长，列/文档[nosql：hbase，mongo]数据库将提高性能。
如果您有大量空闲内存，尤其是运行大量重复查询，Memcached 将会有所帮助。
ORM solutions will be able to optimize some aspects, if you cache query data and use the object API in a planned and deliberate way.
Column / document[nosql : hbase,mongo] databases will improve performance if you have lots (millions+) of records, and are still growing.
Memcached will help if you have a lot of spare memory and especially if there are a lot of repetitious queries being run.