原型数据库设计中的陷阱（用于性能可行性测试）答案

【问题标题】：Pitfalls in prototype database design (for performance viability testing)原型数据库设计中的陷阱（用于性能可行性测试）
【发布时间】：2011-01-02 23:53:15
【问题描述】：

从my previous question 开始，我希望对对象模型的各种潜在模式表示进行一些性能测试。然而，问题在于，虽然模型在概念上是完整的，但实际上还没有最终确定 - 因此表格的确切数量以及每个表格中属性的数量/类型都不确定。

从我（可能很天真）的角度来看，似乎应该可以为每种方法组合一个代表性原型模型，并测试每种方法的性能以确定哪种方法最快每种情况。

这就是问题所在。我知道数据库的性能特征可能非常不直观，以至于很小（甚至“微不足道”）的变化都可能导致数量级的差异。因此，我想知道在设置虚拟表结构并用虚拟数据填充它时可能存在哪些常见缺陷。由于这里的环境可能会产生巨大的影响，因此目标是在 RHEL 3 上运行的 Oracle 10.2.0.3.0。

（特别是，我正在寻找诸如“确保其中一个表的索引比另一个表更具选择性”；“确保您有超过 x 行/columns 因为在此之下您不会遇到页面错误并且性能会有所不同”；“如果要使用它，请确保使用 DATETIME 数据类型进行测试，因为它会极大地改变查询计划”，等等。我尝试了谷歌，希望有很多关于该领域最佳实践的页面/博客文章，但找不到合适的树木（很多关于调整现有数据库性能的页面）。）

作为说明，如果情况确实如此，我愿意接受这样的答案：“在对结果的传递性有任何程度的信心的情况下执行这样的测试是不可行的”。

【问题讨论】：

标签： performance oracle database-design prototype

【解决方案1】：

您可以采取一些措施来定位自己以实现绩效目标。我认为它们按以下顺序发生：

了解架构、最佳实践和模式
了解数据库的工作原理
抽查性能以获得更高的精度或确定古怪设计区域的影响

更多信息：

架构、最佳实践和模式：报告数据库无法执行的最常见原因之一是构建它们的人完全不熟悉报告域。他们可能是事务数据库领域的专家——但该领域的技术并不能转化为仓库/报告领域。因此，您需要充分了解您的领域 - 如果您这样做，您将能够快速确定几乎总是有效的适当方法 - 并且您可以从那里进行调整。
数据库的工作原理：您需要大致了解优化器/规划器为您的查询提供哪些选项。添加索引的不同语句有什么影响？索引 256 字节的 varchar 有什么影响？报告查询甚至会使用您的索引吗？等等
现在您已经找到了正确的方法，并且大致了解了 90% 的模型将如何执行 - 您通常已经完成了对大多数中小型数据库的性能预测。如果你有一个巨大的，有很多风险，你必须变得更精确（可能需要订购更多的硬件），或者在设计中有一些古怪的地方——然后把你的测试集中在这个上。生成合理的测试数据 - 以及您在生产中看到的（重要的）统计数据。并查看数据库将如何处理这些数据。除非你有真实的数据和真实的产品大小的服务器，否则你仍然需要推断——但你至少应该能够相当接近。

【讨论】：

三个答案都很好，得出的结论大致相同；我主要通过 eenie-meenie-minie-mo 接受了这个。

【解决方案2】：

针对概念模型的各种假定实现运行性能测试与其说是天真，不如说是英勇的前瞻性思维。唉，我怀疑这会浪费你的时间。

让我们举一个例子：数据。大概您打算生成随机数据来填充您的表。这可能会让您对查询在大容量下的执行情况有所了解。但性能问题通常是数据偏差的产物；一组随机数据将为您提供值的平均分布。

另一个例子：代码。大多数性能问题是由于 SQL 编写不当造成的，尤其是不适当的连接。您也许可以应用索引来针对 SELECT * FROM my_table WHERE blah 调整个人，但这并不能帮助您防止写得不好的查询。

关于过早优化的真理适用于数据库和算法。最重要的是让数据模型完整和正确。如果你能做到这一点，你就已经领先了。

编辑

阅读了您所链接的问题后，我更清楚地了解您来自哪里。从数据库设计者的角度来看，我对这个 Hibernate 映射问题有一点经验。以您在页面末尾给出的示例...

Animal > Vertebrate > Mammal > Carnivore > Canine > Dog type 层次结构，

...关键是将对象实例化到尽可能远的位置。实例化Animals 的列将比实例化Dogs、Cats 等的单独集合执行得慢得多（假设您有所有或部分这些子类型的表）。

这更像是一个应用程序设计问题，而不是数据库问题。不同之处在于您是仅在具体级别（CATS、DOGS）构建表，还是在表中复制层次结构（ANIMALS、VERTEBRATES 等）。不幸的是，这里没有简单的答案。例如，您不仅要考虑数据检索的性能，还要考虑 Hibernate 将如何处理插入和更新：当涉及到持久数据时，对查询执行良好的设计可能是一场真正的噩梦。关系完整性也会产生影响：如果您有一些适用于所有 Mammals 的实体，那么能够对 MAMMALS 表强制执行外键是令人欣慰的。

【讨论】：

感谢您深思熟虑的回答。数据的代表性是一个真正的问题，我认为这可能是不可克服的，正如您似乎同意的那样。碰巧我不太担心应用程序中编写不佳的 SQL - 根据我之前的问题（链接），我想尝试各种表格布局，以确定哪些将允许最高性能的 SQL。由于这最终将由 Hibernate 发布并且可以根据需要进行调整，因此我不太担心其他开发人员会编写糟糕的查询（否则这可能是一个真正的问题）。
（回复编辑）：我完全同意获取最具体的类型是前进的方向，并且在执行手动 HQL 查询以获取 Animal 实例本身时，这几乎总是可能的。但是，如果我使用 Hibernate 来获取，比如说，Cage（它有一个具有一对一映射的 Animal 字段），那么从 ID 中查找它的查询必须位于顶部 -级别类型。我也很欣赏你的最后一段；我知道将在各种 CRUD 操作中使用的 SQL，并将测试所有这些操作以确定针对这种情况的最佳权衡。

【解决方案3】：

数据库的性能问题不会随数据量线性扩展。一个包含一百万行的数据库可能会显示一个热点，而一个包含十亿行的类似数据库可能会显示一个完全不同的热点。谨防使用样本数据进行的测试。

您需要良好的数据库设计实践，以使您的设计保持简单和合理。在开始担心速度之前，请先担心您的数据库是否满足数据要求，以及您的模型是否相关、完整、正确和相关（前提是您正在构建关系数据库）。

然后，一旦你得到了简单、合理和正确的东西，就开始担心速度。您会惊讶于您可以通过调整数据库的物理特性来加快速度，而无需更改任何应用程序代码。为此，您需要了解很多关于您的特定 DBMS 的知识。

他们从未说过数据库开发会很容易。他们只是说这会很有趣！

【讨论】：