2

我正在开发一个 API 来查询数据库服务器（在我的例子中是 Oracle）以检索大量数据。（这实际上是 JDBC 之上的一层。）

我创建的 API 试图尽可能限制将每个查询信息加载到内存中。我的意思是，我更喜欢迭代结果集并逐一处理返回的行，而不是将每一行加载到内存中并稍后处理它们。

但我想知道这是否是最佳做法，因为它有一些问题：

  • 结果集在整个处理过程中保持不变，如果处理时间与检索数据一样长，则意味着我的结果集将打开两倍
  • 在我的处理循环中执行另一个查询意味着在我已经使用一个结果集时打开另一个结果集，同时开始打开太多结果集可能不是一个好主意。

另一方面，它有一些优点：

  • 对于结果集，我的内存中的数据永远不会超过一行，因为我的查询往往会返回大约 100k 行，这可能是值得的。
  • 由于我的框架很大程度上基于函数式编程概念，因此我从不依赖多个行同时在内存中。
  • 在数据库引擎仍在返回其他行的同时开始对返回的第一行进行处理可以极大地提高性能。

作为对甘道夫的回应，我添加了更多信息：

  • 我总是需要处理整个结果集
  • 我没有对行进行任何聚合

我正在与主数据管理应用程序集成并检索数据，以便验证它们或使用许多不同的格式（到 ERP、到 Web 平台等）导出它们

4

1 回答 1

1

没有普遍的答案。我亲自实施了这两种解决方案数十次。

这取决于对您更重要的因素：内存或网络流量。

如果您的网络连接速度很快LAN（

如果您在 上工作Internet，那么批量提取将对您有所帮助。

您可以设置预取计数或数据库层属性并找到一个中庸之道。

经验法则是：在不注意的情况下获取您可以保留的所有内容

如果您需要更详细的分析，则涉及六个因素：

  • 行生成响应时间/速率（多快Oracle生成第一行/最后一行）
  • 行交付响应时间/速率（多久可以得到第一行/最后一行）
  • 行处理响应时间/速率 （多久可以显示第一行/最后一行）

其中之一将成为瓶颈。

作为一项规则，rate并且responce time是对手。

通过预取，您可以控制行传递响应时间和行传递速率：较高的预取计数会提高速率但会减少响应时间，较低的预取计数会适得其反。

选择对您更重要的一项。

您还可以执行以下操作：为获取和处理创建单独的线程。

只选择足够多的行以使用户在低预取模式（具有高响应时间）下感到愉快，然后切换到高预取模式。

它将在后台获取行，您也可以在后台处理它们，同时用户浏览第一行。

于 2009-05-28T12:29:04.457 回答