大数据集是否需要存储过程？

Question

我刚开始为一家规模合理的公司开展我的第一份开发工作，该公司必须管理大量数据。平均数据库是6GB（从我到目前为止看到的）。其中一项工作是报道。目前的工作方式是 -

将数据复制并传输到数据仓库。从那里，收集特定报告所需的所有数据（数千行和大量表）并汇总到仓库中的报告数据库。这都是通过存储过程完成的。

当请求报告时，会调用存储过程将数据复制到PHP读取的报告数据库中以显示数据。

我根本不是存储过程的忠实粉丝。但是我所说过的人坚持认为存储过程是唯一的选择，因为通过编程语言直接查询数据的速度非常慢（想想30分钟？）。安全也是一个问题。

所以我的问题是 - 当你有一个非常大的数据集时，是否需要存储过程？对于如此大量的数据，查询是否确实需要很长时间，或者DB服务器是否存在问题或数据的排列方式（以及索引？）。我感觉有些不对劲。

Answer 1

使用存储过程的原因是SQL Server在称为计划缓存的内存区域中缓存为执行过程而创建的执行计划。当该程序随后在以后重新运行时，执行计划有可能被重新使用。

存储过程的运行速度不会超过同一个查询，作为一批T-SQL执行。重复使用的执行计划可以提高性能。对于实际的T-SQL，查询开销将是相同的。

将数据卸载到报告数据库是一种典型的追求，但您可能需要检查报告数据库上的索引策略，因为它可能需要与您的OLTP平台完全不同。

您可能还希望考虑使用SQL Server Analysis Services来满足您的报告要求，因为它听起来像您的报告包含大量数据聚合。存储和处理数据以实现快速计数和分析正是SSAS的全部内容。听起来您的业务是时候构建数据仓库了。

我希望这会有所帮助，但请随时索取更多详情。

干杯，约翰

Answer 2

在您运营的环境中 - 在多个地方访问的大型企业数据库 - 实际上总是最好尽可能多地将业务逻辑放在数据库中。

在这种情况下，您的直接表现优势是：

1. 首先，因为如果SP涉及超出简单选择的任何处理，则数据库内数据的处理速度比通过网络向您的程序发送行的速度要快几个数量级。
2. 您确实获得了SP存储已编译的一些好处。与1.处理大量数据相比，这通常是边际的

然而，在我看来，通常比性能更重要的是，企业数据库将逻辑封装在数据库本身内部，提供了重要的管理和维护优势： -

1. 数据结构可以从程序逻辑中抽象出来，允许更改数据库结构，而无需更改访问数据的程序。在进行简单的数据库更改之前，花了几个小时使用[mytable]为SQL编写公司代码库的人都会对此表示赞赏。
2. SP可以提供安全层，但这可能会被过度使用和过度使用。

你说这是你拥有这种类型数据库的公司的第一份工作，所以你可以原谅我不理解以数据库为中心的处理数据的方法在这种环境中是如何必不可少的。你并不孤单 - 在最近的一个播客中，Jeff Attwood说他并不喜欢将代码放入数据库。这是一个很好的有效的意见，你正在处理一个服务于单个应用程序的数据库，但100％错误与一个公司在几个应用程序中使用的数据库，其中最好的政策是搞砸具有完整约束的数据，并且可以自由地使用SP进行访问和更新。

原因是如果你没有这样的数据库总是会丢失数据完整性并积累crud。有时几乎不可能想象它们是如何做的，但是在没有足够约束的任何大型公司数据库（数千万条记录）中，都会有错误形成的记录 - 最多这些会强制定期清理数据（我经常使用的任务）作为初级程序员倾倒，或者更糟糕的是导致应用程序因无效输入而崩溃，或者更糟糕的是不会导致应用程序崩溃但向最终用户提供错误的业务信息。如果您的最终用户是您的财务总监，那么这就是您的工作： - ）

Answer 3

在我看来，还有一个额外的步骤，根据你的描述，似乎是不必要的。这就是我所指的 -

  

请求报告时，存储   调用过程来收集过程   将数据转换为a所需的格式   报告，并转发给另一个   转换的存储过程   数据进入视图，并转发THAT   关闭到PHP框架进行显示。

一个sproc转换报告的数据，然后另一个sproc将这些数据转换成另一种格式用于前端表示 - 是否在第一个sproc之后的格式中使用过的数据？如果没有，那个阶段对我来说似乎是不必要的。

我假设您的报告数据库是一个数据仓库，并且该数据已经过ETL并以格式存储在报告中。我目前在哪里工作，这是常见的做法。

至于你关于存储过程的问题，它们允许你在数据库中集中逻辑并“封装”安全性，鉴于你拥有的其他数据转换的sprocs，第一个看起来在你的组织中看起来是有益的。存储过程还有一个存储的执行计划，在某些情况下，可以对性能进行一些改进。

Answer 4

我发现存储过程有助于处理大型数据集，因为它们消除了大量的网络流量，这可能是一个巨大的性能瓶颈，具体取决于数据集的实际大小。

Answer 5

当处理大量行，索引可用且SQL相对调整时，数据库引擎直接对数据执行基于集合的操作 - 比如通过SQL - 将几乎总是优于逐行处理（甚至在同一台服务器上）在客户端工具中。数据没有穿过任何物理或逻辑boudaries离开数据库服务器进程或离开数据库服务器并通过网络出去。如果只有有限数量的数据真的需要离开服务器，即使在服务器上执行RBAR（通过痛苦的行划线）也会比在客户端工具中执行更快，因为...

当您开始在网络中提取更多数据时，该过程将减慢并限制每个阶段的行数成为下一个优化。

所有这些都与存储过程无关。存储过程（在SQL Server中）不再提供比批处理SQL更多的性能优势。存储过程确实提供了大量其他好处，如模块化，封装，安全管理，合同设计，版本管理。然而，表现不再是一种优势。

Answer 6

一般而言，存储过程与直接查询相比具有许多优点。我无法评论您的完整端到端流程，但是，SP可能会更快地执行。首先，需要编译直接查询，并在每次执行直接查询时制定执行计划 - SP不会。

还有其他原因，为什么你要使用存储过程 - 集中逻辑，安全等。

Answer 7

端到端流程确实看起来有点复杂，但由于数据量的原因，可能有很好的理由 - 如果你在主数据库上运行报告，那么查询可能会减慢其余部分的速度系统太多了，你会给其他用户带来麻烦。

关于存储过程，它们在这样的场景中的主要优点是它们是预编译的，并且数据库已经计算出它认为是最佳查询计划。特别是对于您所谈论的数据量，这可能会带来非常显着的性能提升。

是的，根据报告的复杂程度，这样的查询可能需要半个小时或更长时间......

Answer 8

此报告解决方案似乎是由认为数据库是世界中心的人设计的。这是一个常见的有效视图 - 但我并不总是坚持这一点。

在表/数据库之间移动数据时，使用存储过程可以快得多，因为数据不需要在数据库和应用程序之间传输。但是在大多数情况下，我宁愿不使用存储过程因为它们使开发变得更复杂，我自己也在ORM阵营。有时你可以通过将批量加载到RAM并在那里处理它来获得很好的加速，然而这是一种完全不同的编码方式，并且不允许重用已经在存储过程中的逻辑。对不起，我觉得你在那份工作中堆积了存储过程。

给出移动的数据量，如果使用SQL服务器，我会看看使用SSIS或DTS - oracle会有同样的东西。 SSIS将在许多线程上进行数据转换，同时为您处理大量细节。

请记住，软件的设计更多地与软件的历史和工作的人有关，而不是与“正确的做法”有关。回到100年后我们可能知道如何编写软件，目前它主要是盲人领导盲人的情况。就像第一座桥梁建成并且很多桥梁倒塌一样，没有人可以提前告诉你巫桥会保持站立和原因。

Answer 9

与ORM产品的自动生成代码不同，存储过程可以进行性能调整。这在大型生产环境中至关重要。有许多方法可以调整使用ORM时无法使用的性能。此外，由大型数据库执行的许多任务与用户界面无关，因此不应从那里生成的代码运行。

如果要控制权限，则还需要存储过程，以便用户只能执行proc中指定的过程而不执行任何其他过程。否则，用户可以更容易地对数据库进行未经授权的更改并进行欺诈。这就是为什么使用大型业务关键系统的数据库人员除了通过存储过程之外不允许任何访问的原因之一。

如果您要将大量数据移动到其他服务器，我会考虑使用DTS（如果使用SQL Server 2000）或SSIS。这可能会进一步加快您的流程，但这在很大程度上取决于您正在做什么以及如何做。

在这种情况下sps可能更快的事实并不排除索引可能是错误的或统计数据过时，但通常管理大量数据的dbas往往在这些东西之上。

你描述的过程确实有点令人费解，但是如果没有看到正在发生的事情的结构并理解数据库和环境，我不能说这可能是最好的过程。

我可以告诉你，进入并希望改变工作内容以适应他们自己的个人偏见的新员工往往不太认真，当你需要提出有效的改变时，你几乎没有信誉。如果您过去的经验不适用于相同大小或类型的处理数据库，则尤其如此。如果你是大型系统的专家，从一开始你可能会受到更严肃的对待，但是，面对它，你不是，因此你的意见不太可能影响任何人，直到你有一段时间，他们有一个你的措施真正的能力。此外，如果您按原样学习系统并按原样使用系统，那么您将在六个月左右的时间内处于更好的位置，以提出改进而不是更改。

Answer 10

我或许可以提出更多，但有几点。

1. 假设有一个现代数据库，由于缓存等原因，存储过程实际上可能不会明显快于正常程序。
2. 存储过程的安全优势有些高估。
3. 改变是邪恶的。一致性是王道。

我会说＃3胜过所有其他问题，除非存储过程导致合法问题。

Answer 11

更快的报告方式是将所有数据读入内存（需要64位操作系统），然后只需遍历对象。这当然仅限于ram大小（价格合理的32 GB），并且报告了你击中db的很大一部分。无需为小报告付出努力。

在过去，我可以运行一个报告，在1.5秒内查询超过800万个对象。在3GHz奔腾4上大约有一GB的内存.64位应该是慢两倍的速度，但这可以通过更快的处理器来补偿。