PHP和MySQL高流量解决方案答案

【问题标题】：PHP and MySQL high traffic solutionPHP和MySQL高流量解决方案
【发布时间】：2011-12-04 05:04:45
【问题描述】：

考虑创建具有许多并行用户的高流量 PHP 网站。就有效性而言，哪个是最好的 MySQL 抽象（ORM 或 OODBMS）（15-20 个数据库表，总和约为 100000 个项目，并且不超过 4 个表之间的 JOIN 查询）？

我听说 Doctrine 库是合适的，或者我应该使用 Zend 之类的框架？哪些数据库解决方案是基于 PDO 构建的，不需要太多学习（此时我使用的是纯 PHP）？

【问题讨论】：

您应该使用最适合问题的解决方案。

标签： php mysql database scalability

【解决方案1】：

如果您缓存查询数据并有计划地使用对象 API，ORM 解决方案将能够优化某些方面。

Column / document[nosql : hbase,mongo] 如果您有大量（数百万+）条记录并且仍在增长，数据库将提高性能。

如果您有大量空闲内存，尤其是在运行大量重复查询时，Memcached 会有所帮助。

【讨论】：

【解决方案2】：

ORM 或任何数据建模层永远不会为您带来更好的性能。它们的唯一目的是让您的开发时间更快、更容易维护。当涉及到实际使用适当的关系并最终查询所有表以找到正确的数据时，他们在决策制定方面是出了名的糟糕。在复杂查询的那个级别，您将无法在不牺牲性能的情况下抽象出这些关系。

MySQL 至少可以处理多达几百万条记录（我已经在一个表中使用了超过 1 亿条记录）。出于性能考虑，您通常希望至少有一个主/从设置和一些在它们之间分配读取的方法。数据库几乎总是性能的限制因素。您总是可以添加更多的 Web 服务器并在它们前面获得负载平衡以解决另一面的问题，但数据库设置总是有点难以维护。

您必须考虑为什么要使用 ORM。如果出于开发原因，那很好，但请注意您的性能会受到影响。否则坚持查询。 ORM 添加了第三层代码来处理和学习。如果您了解 PHP 和 MySQL，您是否需要学习第三种语言才能有效地使用它们？大多数情况下，答案是否定的。

您有许多选项可供选择，但请注意，在某些时候，您选择的框架/ORM 不会按照您希望的方式运行，并且要使其按照您的意愿运行，您必须进行大量搜索并挖掘代码。这是一个典型的问题——先节省时间，以后再付款，或者先花时间，以后没有可能的回报。

【讨论】：

谢谢。您对这个 OODBMS 解决方案 Doctrine 有什么看法，因为我读到它是基于 PDO 构建的。 Doctrine 比纯查询更好的解决方案吗？
在什么方面？表现？不，可用性？取决于你的意见。与对象抽象相比，我个人觉得自己更擅长制作查询，但我最近一直在工作中使用 CakePHP，并且明白当您不必担心它时，它确实使事情变得更容易。我已经将 Doctrine 与 Symfony 一起使用，这没关系，但你最终还是通过它们的函数编写了伪 SQL，所以在那个级别上，我最终问自己“有什么意义？”。我已经知道 SQL，所以将其抽象出来，同时限制我可以编写的查询，但最终并没有帮助。
例如：$items = Doctrine_Query::create()->from('Example e')->leftJoin('e.Foobar')->where('e.id = ?', 20)->execute(); 与原始 SQL。如果您了解 SQL，那么这只是另一层复杂性。如果没有，那么在您了解 SQL 查询的来龙去脉之前，使用 ORM 可能是有意义的。
大多数 ORM 的查询和结果缓存功能怎么样？我觉得这些通常可以弥补任何开销，另一种选择是自己动手
MySQL 已经内置了查询缓存，所以如果你知道如何编写查询，原始查询总是比 ORM 执行得更好。如果不是，那应该是洗了。还要考虑为了维护查询结果集中的这些关系而必须运行的代码量。它非常重要，而且您几乎无法控制。不过，对于新手来说，这已经足够了，但我希望新手不会能够构建高性能的软件。

【解决方案3】：

无论使用哪种数据库解决方案，您都应该使用MemCached 之类的系统。使用适当的缓存策略，您将显着减少数据库对服务器的负载。

有一个用于 memcached 的 PHP API here

【讨论】：

APC 是另一种共享内存缓存解决方案
更新：APC 在 PHP 的后续版本中被逐步淘汰（从 5.5 开始）。它被 Zend OPCache 取代，它不支持用户缓存。因此，如果您认为无需重写代码即可进入更高版本的 PHP，您应该考虑完全不使用 APC。