1

它看起来越来越像我必须在我有时间调整所有查询/表格等之前上线，然后再上线一个网站（已经比计划晚了 6 个月，所以尽管这不是理想的场景- 事情就是这样）。

它现在不得不咬紧牙关。这只是一个尝试计算当我们“咬”它时子弹会有多大的例子。一旦数据库上线，显然我们不能随心所欲地更改数据，因为它是实时数据。我对大多数 db 模式相当有信心——例如，表是大多数 3 和 4 范式，并且使用约束来确保数据完整性。我还在某些列上放置了一些索引（我认为）将在查询中大量使用，尽管这样做非常匆忙并且没有经过测试 - 这是我担心的一点。

澄清一下，我不是在谈论批发结构变化。表格本身不太可能改变（如果有的话），但是几乎可以保证我将不得不在某个阶段调整表格（个人或通过雇用某人）。

我想知道这是一项多么艰巨的任务。具体来说，假设一个数 GB 的数据库（到目前为止大约 300 个表）

假设 50% 的表需要在接下来的几个月内进行调整：

  1. 执行调音需要多长时间（我知道这是一个“一根绳子有多长”类型的问题） - 但是需要努力的主要决定因素是什么，所以我可以计算出它可能需要多长时间拿？

  2. 是否可以在重新设计索引时锁定数据库的部分（或特定表），或者整个数据库是否需要脱机？（我使用 mySQL 5.x 作为数据库）

  3. 我所描述的（在所有表完美调整之前上线）是否存在极大的风险/不可取？（这是否证明了这几个月给我造成的不眠之夜）？

4

4 回答 4

2

一般来说，修复一个在上线后导致性能问题的糟糕数据库设计要困难得多，因为您必须处理现有记录。更糟糕的是，糟糕的设计可能要到上线几个月后才会变得明显，那时记录很多而不是很少。这就是为什么在设计数据库时应该考虑性能（不，这不是过早的优化，已知的技术通常比其他技术性能更好，并且应该在设计中考虑它们）并且应该针对一组测试记录对数据库进行测试接近或超过您几年后的预期记录水平。

至于完全修复设计糟糕的数据库需要多长时间，几个月或几年。通常最糟糕的部分是设计的核心部分（比如 EAV 表），并且几乎需要每个查询/sp/视图。UDF 被调整以移动到更好的结构。然后，您必须确保将所有记录移至新的更好的结构。越早解决这样的错误越好。将几千条记录移动到一个新的结构比 100,000,000 条记录要好得多。

如果你的结构没问题，但你的查询很糟糕，你会更好，因为你可以选择性能最差的前十名（不仅根据运行的总时间，而且根据运行的时间 X 次进行选择）并修复、冲洗并重复。

如果你正在修复一个糟糕的数据库，这本书可能会派上用场：

http://www.amazon.com/Refactoring-Databases-Evolutionary-Database-Design/dp/0321293533/ref=sr_1_1?ie=UTF8&s=books&qid=1268158669&sr=8-1

于 2010-03-09T18:19:06.653 回答
1

我会尝试至少在上线之前量化数据库的限制，这样至少您会知道应用程序生成的活动何时接近该阈值。

您可能希望（尽可能自动地）从您的应用程序中模拟数据库的典型使用情况，并检查它在中断之前可以处理多少并发用户/会话/事务等。至少，这应该可以让你解决“不眠之夜”的问题。

至于原来的“这有多容易……？” 问题，答案显然取决于许多因素。但是，上述分析无疑会有所帮助，因为至少您可以说出您的数据库是否需要调整。

于 2010-03-09T17:48:12.853 回答
1

要回答标题问题，我想说在部署到生产环境后调整数据库相当容易。

在部署到任何环境后提高性能是一个好主意。随着时间的推移，正在生产增加了一些压力。我建议部署到 Prod，并让它按预期运行。然后开始测量：

  • 报告 X 在不同时间运行多长时间（高峰与下班后，如果您的应用中有这样的概念）。
  • 将应用程序用于这些关键用例时，用户的体验如何？

然后备份您的 Prod 环境，并为自己创建一个 pre-Prod 环境。在那里，您将能够运行您的升级脚本，以便能够衡量您遇到的“多长时间”类型的问题。索引创建、升级停机时间等。在调整查询等时，您将对它如何处理生产数据和卷有一个很好的了解。当然，您不会获得让这些用户同时执行这些插入的好处。

为多次迭代、升级失败、新的/未准备好的问题等保留该备份。

在每次部署后继续进行备份，以便您可以测试对数据库的下一轮改进。

于 2010-03-09T18:47:50.683 回答
1

  1. 这取决于你在调整什么。假设您要为几个表添加索引，或者将表类型从 MyISAM 更改为 InnoDB 或其他东西，然后使用足够大的表，这些事情可以在 5 到 10 分钟内完成，具体取决于您的硬件。不需要几个小时。也就是说，最好还是在半夜进行任何 live-db 调优。

  2. 您可以通过调用获取读取锁定，FLUSH TABLES WITH READ LOCK但为了安全起见，最好在您的应用程序中放置 15-30 分钟的“我们正在维护”消息。

  3. 风险是情况固有的，如果出现严重问题会发生什么。我通常会采取更牛仔的方式并进行直播，尤其是在负载不高的情况下，这样我就可以轻松找到痛点并修复它们。如果这是一个关键任务系统，那么不，负载测试或任何您可以首先确保您已做好准备的事情。另外，请记住，您无法预见您将遇到的所有问题。如果您的索引很好，那么您可能可以将其上线并查看需要处理的内容。

于 2010-03-09T18:49:49.853 回答