什么更快？使用REST API还是直接查询数据库？

16

什么是更快的性能明智的选择？创建REST API并让您的Web应用使用REST API来与数据库进行所有交互，或者直接查询数据库（即使用您的语言用来查询数据库的任何典型对象，例如Java的JDBC）？

我使用REST的方式：

您在代码中创建一个对象以调用REST方法
调用http方法
REST API中的代码查询数据库
数据库返回一些数据
REST API代码将数据打包到Json中并将其发送到您的客户端
客户端收到Json / XML响应
将响应映射到代码中的对象

另一方面，直接查询数据库：

使用查询字符串创建对象以查询数据库
数据库返回一些数据
将响应映射到代码中的对象

因此，这是否意味着使用REST API会更慢？也许取决于数据库的类型（SQL vs NoSQL）？

database rest sql

— 微
source

3

REST API不是数据库访问协议，因此问题主要是类别错误。REST api是文档存储。它可能在服务器端使用数据库（或者可能不会）。如果您不需要REST API，那么显然不要使用REST API。但这一切都适用。如果不需要数据库，请不要使用数据库，写入文件系统的速度将比数据库快。如果不需要文件系统，请不要使用它，写入RAM的速度比磁盘快。如果你不需要RAM不使用它，写入到CPU缓存快等等等等

— 科马克马尔霍尔

1

“另一方面”要求您将数据库暴露给大的坏世界。

— Pieter B

@PieterB：不，“另一方面”是将数据库公开给受信任的Web应用程序。

— JacquesB 2015年

@ JacquesB，Web应用程序在客户端计算机上运行。因此它不应该被信任，因为它可能是修改版本。

— 彼得乙

@PieterB：该问题未说明有关在不受信任的服务器上运行的Web应用程序的任何信息。那将是非常不寻常的设置。

— JacquesB 2015年

18

当您增加复杂性时，代码将运行得更慢。如果不需要，则引入REST服务会降低执行速度，因为系统会做更多事情。

抽象数据库是一种好习惯。如果您担心速度，可以考虑将数据缓存在内存中，这样就无需触摸数据库来处理请求。

在优化性能之前，尽管我会研究您要解决的问题以及所使用的体系结构，但我一直在努力思考数据库选项是直接访问还是REST的情况。

— 克莱
source

+1表示缓存。虽然在做extra work。但是实际上，通过缓存重复查询可能会更快。

— Yana Agun Siswanto

3

@Klee您的答案不太正确。»如果不需要，则引入REST服务会降低执行速度，因为系统正在做更多事情。«并非在每种情况下都没有到达端点的流量，例如，反向代理可以处理严重的结果。

— Thomas Junk 2015年

@klee我问这个问题的原因来自于SO 程序员 -stackexchange.com/questions/277701/…- 一个答案谈到了亚马逊如何通过使用完全RESTful系统而不是直接访问来取得巨大成功。只是让我在想...

— Micro Micro

9

如果您担心速度，那么基于上述原因，Rest服务的速度会变慢。但是，您描述的类型的速度很少是主要关注的问题，如果可以解决，则可以通过其他方式解决。过早的优化是万恶之源。

考虑一下您是否主要关注互操作性（移动，Web，B2B），现在REST非常有吸引力，因为它与技术无关。

假设您为数据库编码。如果您选择更改基础数据存储，该怎么办。如果您与基础商店紧密耦合，将会有多困难？

真正的答案取决于情况，但希望我给了您一些思考的机会！

— 罗姆斯基
source

6

如果发现很难回答这个问题。

正确的一般答案应该是：取决于。

我使用REST的方式：

您在代码中创建一个对象以调用REST方法

调用http方法

REST API中的代码查询数据库

数据库返回一些数据

REST API代码将数据打包到Json中并将其发送到您的客户端

客户端收到Json / XML响应

将响应映射到代码中的对象

您的想法有误。

这个错误源于您不完全了解REST及其原理的事实。REST并非是发明的，因为有些书呆子发现通过HTTP通过HTTP发送Javascript对象很酷（当然是这样）。使用HTTP的主要优点是可以使用Caching。如果使结果可缓存，则对数据库的请求更少。而且没有编组涉及。答案可以直接传递。

就@Klees而言，答案并不完全正确：

当您增加复杂性时，代码将运行得更慢。如果不需要，则引入REST服务会降低执行速度，因为系统会做更多事情。

处理可缓存结果时，对您的应用程序没有影响：可以通过反向代理来完成对已知问题的已知答案。

— 托马斯·容克
source

4

如果数据可在其余服务层中缓存，则它可在Web应用程序中缓存，这对于性能而言会更好。

— JacquesB 2015年

最快的方法是完全不使用Web应用程序。

— Thomas Junk 2015年

1

只是为了使它更有趣，如果您可以访问内存v。磁盘，并不是所有对数据库的“命中”都是相等的。

— JeffO 2015年

@ThomasJunk：如果我理解正确的原始问题，则客户端是Web应用程序，问题是Web应用程序应直接连接到db还是通过rest服务调用。

— JacquesB 2015年

1

这并没有改变我的答案。调用REST服务包括调用Web服务器，该服务器可能位于反向代理之后，在反向代理中可以缓存可能的答案-正如我已经说过的。

— Thomas Junk 2015年

2

引入额外的服务层总是会在复杂性和性能开销上付出代价。在某些特定类型的体系结构中，引入共享服务层（如REST API）可能会由于共享缓存而提高性能-但听起来这不是您所拥有的体系结构。

考虑一种架构，其中您有多个Web应用程序或多个桌面应用程序直接连接到同一数据库。如果他们经常执行相同的查询，则可以提高将查询结果缓存在共享服务中的性能。特别是如果您说有数百个桌面应用程序直接访问同一数据库（而不是通过Web应用程序！）并执行相同的查询，则可能会有重大改进。但是，即使在这种体系结构中，引入共享服务的主要原因也可能是安全性和数据抽象性而非性能。

但这听起来像您有一个直接连接到数据库的Web应用程序。在这种情况下，引入额外的服务层没有任何好处。缓存，数据库抽象等可以在同一应用程序的数据访问层进行处理。

— 雅克B
source

1

这取决于。

显然，代码中的层越多，运行速度越慢。但是...有时候，直接的端到端性能与可伸缩性无关紧要。如果您有1位用户在本地PC上访问数据库，则数据库运行速度会很快。如果您有一千个用户在同一台PC上访问同一数据库，那么您很可能会看到他们都感到沮丧。解决方案是将数据库移动到另一个框，在中间添加一个层，尽管对于1个用户而言，它的执行速度会较慢，当访问数以千计时，它的执行速度会更快。（这是一个简单的答案，但原则上是正确的）。

还有其他将数据库隐藏在中间层后面的原因，例如安全性。

— gbjbaanb
source

-2

我不知道您在哪里迷路了，但是很明显，当您使用REST API时，您会做额外的步骤，而额外的步骤“总是”意味着在进行编程时会变慢。

有优点和缺点，但是如果您可以直接从应用程序访问数据库，则最好直接调用它而不是使用Web API，当然，如果您使用Web API，则可以轻松地将应用程序移植到其他平台。

— 基里
source

1

»我不知道您会迷失在哪里，但很明显，当您使用REST API时，您会做额外的步骤，而额外的步骤“总是”意味着在进行编程时会变慢。«如果这意味着执行速度变慢，那是不对的。

— Thomas Junk 2015年

1

除了可移植性之外，是否存在访问数据库不是一个好主意的情况？有时拥有REST API等可以在服务器端保留更多逻辑（以及更好的安全性？），对吗？

— J特拉纳

@JTrana可以为是或否，实际上取决于您的操作方式，而引入额外的层可以提供额外的安全性，添加额外的层还意味着您有更多机会搞砸某些东西并暴露安全漏洞。我认为Web API的重点是公开您的“ API”。诸如Facebook，Amazon，Google之类的大型应用程序需要提供对第三方的访问权限，并且具有很多平台，必须具有Web API，但是对于小型应用程序，您需要三思而后行。

— 基里

-2

REST：

对多个前端和1个后端开放
需要创建自己的API（或使用类似Loopback的API）
不能离线工作

本地数据库：

没有开放给“层”，他们需要有权访问您的后端以进行同步
无需创建API，使用DB接口
离线工作

这是非常大的差异，人们经常会忽略这些要点

— 本杰明·富恩特斯
source

2

-1。尽管不需要“创建” API，但如果需要更改数据库后端，则不创建DAL通常会带来极大的痛苦。同样也没有理由为什么您的数据库“离线”也无法在其上提供Rest服务。

— 詹姆斯·斯内尔