N + 1问题主要是在ORM的背景下进行讨论。在此问题中,系统需要加载父实体的N个子节点,其中仅请求父实体。默认情况下,ORM配置为启用延迟加载,因此为父实体发出的1个查询会导致N个更多查询,即N个子实体各一个查询。
这个N + 1问题通常被认为是一个主要的性能瓶颈,因此应在设计应用层面上解决。
googletag.cmd.push(function() { googletag.display('waldo-tag-4084'); });
虽然大多数是直接关联的,但N + 1问题并不仅仅针对ORM。这可以与Web API的上下文相关联,例如REST API。
对于Web API,N + 1问题是客户端应用程序需要调用服务器N + 1次以获取1个集合资源+ N个客户端资源的情况,主要是因为集合资源没有足够的有关子资源的信息来构建它的用户界面完全。
例如,REST API将一组书籍作为资源返回。
<books uri="/books" size="100">
<book uri="/books/1" id="1">
<isbn>3434253561</isbn>
</book>
<book uri="/books/2" id="2">
<isbn>3423423534</isbn>
</book>
<book uri="/books/3" id="3">
<isbn>5352342344</isbn>
</book>
...
...
</books>
这里/books
的书籍,只有信息,包括它的资源返还列表id
和isbn
。这些信息显然不足以构建客户端应用程序UI,该UI通常希望以name
UI而不是ISBN 显示书籍。也许他们想要展示其他信息,例如作者和出版年份。
在上面的场景中,客户端应用程序必须为每个单独的书籍资源提出N个更多请求/books/{id}
。因此,总客户端将最终调用REST API N + 1次。
以上场景仅作为示例。想法是,收集资源中的信息不足可能导致REST API中出现N + 1问题。
前面讨论的问题的好处是我们知道究竟是什么问题。这使解决方案变得非常简单。在收集资源中的各个资源中包含更多信息。
您可以咨询API消费者,对类似应用程序及其用户界面进行市场调查,或者只是将自己置于客户的角度。
此外,随着您对客户需求的理解的改善,您可以随时改进API。这可以使用API版本控制。
Powered by RESTful API 中文网 + with by 全栈开发网. 网站地图 按Ctrl+D试试 .