什么时候优化性能为时已晚？

Question

我知道你不应该过早地进行优化，而应该以可维护性为目标。我的问题是，在什么时候为时已晚？

我在网站上工作，类似于雅虎的答案，我的数据库结构正是我认为应该是的。 users，questions，answers，question_comments，answer_comments等表格

我的问题是，如果网站增长，这个架构将如何扩展？我想将问题和答案放在一个表格中posts），按类型分隔，然后将question_comments和answer_comments放在同一个表格中comments）。我相信这与stackoverflow的DB方案类似。

我知道你们会说些什么，＆＃34;不要担心它，直到它成为一个实际的问题＆＃34;。但那么担心它会不会太迟？

由于

Answer 1

为什么在您的网站看到大量流量之前，不知道您的瓶颈会在哪里，这是一个不好的做法。此时，您的用户如何访问您的网站并与您的网站进行互动尚未知。

几乎总是最好从一个'好'的架构（规范化数据库，MVC架构，DRY，精心编写的前端代码等）开始，然后从那里开始。与过早优化的架构相比，扩展一个干净，有组织的架构要容易得多。

现在，您可以通过ab或其他负载测试工具进行一些负载测试，以查看当前瓶颈的位置。它肯定不会找到所有这些，但它会找到一些。

如果您真的对此感到担心（并且您现在还不应该），请在服务器上安装Nagios或Munin以监控性能。使用第三方工具每天测量页面加载时间。一旦你开始看到问题，那么你可以分析和调整。

Answer 2

如果快速服务是应用程序的基本要求，您绝对应该优化。

如果亚秒级响应不是必需的，那么您可以编写干净的代码并在以后进行优化。

这方面的一个很好的例子是在最新版本的浏览器之前的JavaScript，为他们的页面编写了漂亮，干净，可扩展的JS的人表现糟糕，不得不从头开始。

Answer 3

一张大桌子通常难以维护。人们通常将他们的表分割成分区，甚至将他们的数据库分成碎片。

我没有看到如何将所有注释放入同一个表中会为您节省连接。实际上，将问题和答案放在同一个表格中也不会为您节省加入，您只需加入同一个表格。

如果你想节省联接，我希望你使用面向文档的NoSQL数据库，比如MongoDB。在这里，您可以将所有相关答案和评论存储在单个“记录”中，可通过一个操作获取。

Answer 4

数据库需要在设计时考虑到性能，而不是等到以后出现问题。过早优化并不意味着不要在设计中做到这一点，这意味着不要对它过分夸大。但是，每个数据库后端都有已知的性能杀手，如果你熟悉它，那么当一个不同的技术会更快并且花费相同的时间来编写代码时，设计使用其中一个是愚蠢的。因此，在设计任何数据库之前，请阅读性能调优，然后再也不会以相同的方式编写数据库代码。