O que é mais rápido? Usando a API REST ou consultando um banco de dados diretamente?

16

Qual é o desempenho mais rápido? Criando uma API REST e fazendo com que seu aplicativo Web use a API REST para fazer todas as interações com o banco de dados OU consultando diretamente o banco de dados (por exemplo, usando qualquer objeto típico que sua linguagem utilize para consultar um banco de dados como o JDBC for Java)?

Do jeito que eu vejo isso com o REST:

  1. Você cria um objeto no seu código para chamar o método REST
  2. Chamar método http
  3. O código dentro da API REST consulta o banco de dados
  4. Banco de dados retorna alguns dados
  5. O código da API REST compacta os dados no Json e os envia ao seu cliente
  6. Cliente recebe resposta Json / XML
  7. Mapeie a resposta a um objeto no seu código

Por outro lado, consultando um banco de dados diretamente:

  1. Você cria um objeto com uma string de consulta para consultar o banco de dados
  2. Banco de dados retorna alguns dados
  3. Mapeie a resposta a um objeto no seu código

Portanto, isso não significa que o uso de uma API REST seria mais lento? Talvez isso dependa do tipo de banco de dados (SQL vs NoSQL)?

database  rest  sql 
— Micro
fonte
3
Uma API REST não é um protocolo de acesso ao banco de dados, portanto, a questão é um grande erro de categoria. Uma API REST é um armazenamento de documentos. PODE usar um banco de dados no lado do servidor (ou não). Se você não precisa de uma API REST, obviamente não use uma. Mas então isso vale para tudo. Se você não precisar de um banco de dados, não use um, gravar no sistema de arquivos será mais rápido que um banco de dados. Se você não precisar de um sistema de arquivos, não use um, gravar na RAM é mais rápido que no disco. Se você não precisa de RAM não usá-lo, escrevendo a cache da CPU é mais rápido etc etc etc
— Cormac Mulhall
1
O "por outro lado" exige que você exponha seu banco de dados ao grande mundo ruim.
— Pieter B
@ PieterB: Não, o "por outro lado" está expondo o banco de dados ao aplicativo Web confiável.
— JacquesB
@JacquesB e o aplicativo Web são executados no computador do cliente. Portanto, não deve ser confiável, pois pode ser uma versão modificada.
— Pieter B
@ PieterB: A questão não declara nada sobre o aplicativo Web em execução em um servidor não confiável. Isso seria uma configuração altamente incomum.
— JacquesB

Respostas:

18

Quando você adiciona complexidade, o código fica mais lento. A introdução de um serviço REST, se não for necessário, atrasará a execução, pois o sistema está fazendo mais.

Abstrair o banco de dados é uma boa prática. Se você está preocupado com a velocidade, pode tentar armazenar em cache os dados na memória para que o banco de dados não precise ser tocado para lidar com a solicitação.

Antes de otimizar o desempenho, analisando o problema que você está tentando resolver e a arquitetura que está usando, estou lutando para pensar em uma situação em que as opções do banco de dados sejam de acesso direto versus REST.

— Klee
fonte
+1 por mencionar o cache. Embora esteja fazendo extra work. Mas, na verdade, poderia ser mais rápido armazenando em cache consultas repetidas.
— Yana Agun Siswanto
3
@Klee Sua resposta não está certa. »A introdução de um serviço REST, se não for necessário, atrasará a execução, pois o sistema está fazendo mais.« Nem sempre existe tráfego para o terminal, se, por exemplo, um proxy reverso puder lidar com resultados capturados.
— Thomas Junk
@klee A razão pela qual eu fiz essa pergunta foi deste SO post programmers.stackexchange.com/questions/277701/… - uma resposta fala sobre como a Amazon teve grande sucesso usando um sistema totalmente RESTful em vez de acesso direto. Só me fez pensar ...
— Micro
9

Se sua preocupação for velocidade, sim, um serviço de Descanso será mais lento pelos motivos mencionados acima. No entanto, a velocidade do tipo que você descreve raramente é a principal preocupação e, se for, pode ser tratada de outras maneiras. A otimização prematura é a raiz de todo mal .

Considere se sua principal preocupação é a interoperabilidade (móvel, web, B2B), agora o REST é muito atraente porque é independente da tecnologia.

Suponha que você codifique para um banco de dados. O que você faria se optar por alterar seu armazenamento de dados subjacente. Quão difícil seria se você estivesse fortemente acoplado à loja subjacente?

A resposta real é que depende , mas espero ter lhe dado algumas coisas para pensar!

— Romski
fonte
6

Se achar difícil responder a essa pergunta.

A resposta geral correta deve ser: depende.

Do jeito que eu vejo isso com o REST:

  1. Você cria um objeto no seu código para chamar o método REST
  2. Chamar método http
  3. O código dentro da API REST consulta o banco de dados
  4. Banco de dados retorna alguns dados
  5. O código da API REST compacta os dados no Json e os envia ao seu cliente
  6. Cliente recebe resposta Json / XML
  7. Mapeie a resposta a um objeto no seu código

Há um erro no seu pensamento.

E esse erro decorre do fato de você não entender completamente o REST e seus princípios. O REST não foi inventado, porque alguns nerds acharam legal (é claro) enviar objetos Javascript via HTTP através da conexão. A principal vantagem do uso do HTTP é a possibilidade de usar o cache . Se você tornar seus resultados armazenáveis ​​em cache , haverá menos solicitações a serem feitas no banco de dados. E nenhum empacotamento está envolvido. A resposta pode ser entregue diretamente.

Na medida em que a resposta do @Klees não está certa :

Quando você adiciona complexidade, o código fica mais lento. A introdução de um serviço REST, se não for necessário, atrasará a execução, pois o sistema está fazendo mais.

Ao lidar com resultados de cache, não há impacto no seu aplicativo: o fornecimento de respostas conhecidas para perguntas conhecidas pode ser feito por meio de proxies reversos.

— Thomas Junk
fonte
4
Se os dados puderem ser armazenados em cache em uma camada de serviço de descanso, eles serão armazenados em cache no aplicativo Web, o que seria muito melhor para o desempenho.
— JacquesB
A maneira mais rápida é não acessar o aplicativo da web.
— Thomas Junk
1
E apenas para torná-lo mais interessante, nem todos os "hits" no banco de dados são iguais se você puder acessar na memória v. O disco.
— Jeffo
@ ThomasJunk: Se eu entendi a pergunta original correta, o cliente é um aplicativo da Web e a pergunta é se o aplicativo da Web deve se conectar diretamente ao banco de dados ou ligar através de um serviço de descanso.
— JacquesB
1
Isso não muda nada na minha resposta. Chamar um serviço REST inclui chamar um servidor da Web que pode estar atrás de um proxy reverso, onde possíveis respostas podem ser armazenadas em cache - como eu já disse.
— Thomas Junk
2

A introdução de uma camada de serviço extra sempre tem um custo em complexidade e sobrecarga de desempenho. Existem alguns tipos específicos de arquitetura em que a introdução de uma camada de serviço compartilhada (como uma API REST) ​​pode melhorar forçosamente devido ao cache compartilhado - mas parece que não é o tipo de arquitetura que você possui.

Considere uma arquitetura em que você tenha vários aplicativos da web ou vários aplicativos de desktop conectados diretamente ao mesmo banco de dados. Se eles executam as mesmas consultas frequentemente, pode melhorar o desempenho para armazenar em cache os resultados da consulta em um serviço compartilhado. Especialmente se você disser que centenas de aplicativos de desktop acessam o mesmo banco de dados diretamente (não através de um aplicativo Web!) E realizam as mesmas consultas, pode haver uma grande melhoria. No entanto, mesmo nessa arquitetura, o principal motivo para a introdução de um serviço compartilhado provavelmente seria a segurança e a abstração de dados, e não o desempenho.

Mas parece que você tem um único aplicativo da web que se conecta diretamente ao banco de dados. Nesse caso, não há benefício em introduzir uma camada de serviço adicional. O armazenamento em cache, a abstração do banco de dados etc. podem ser manipulados na camada de acesso a dados no mesmo aplicativo.

— JacquesB
fonte
1

Depende.

Obviamente, quanto mais camadas no seu código, mais lento ele fica. Mas ... chega um momento em que o desempenho direto de ponta a ponta não importa tanto quanto a escalabilidade. Se você tiver um usuário acessando seu banco de dados em um PC local, ele poderá ser mais rápido. Se você tem mil usuários acessando o mesmo banco de dados no mesmo PC, é provável que veja todos eles frustrados. A solução é mover o banco de dados para outra caixa, adicionar uma camada no meio e, embora para 1 usuário, ele tenha um desempenho mais lento, quando os milhares acessarem, ele será mais rápido. (essa é uma resposta simplista, mas verdadeira em princípio).

Há outros motivos para ocultar seu banco de dados atrás de uma camada de camada intermediária, como segurança.

— gbjbaanb
fonte
-2

Não sei onde você se perde, mas é bem claro que, quando você está usando a API REST, está fazendo uma etapa extra, e a etapa extra "sempre" significa mais devagar quando a programação está envolvida.

Há prós e contras, mas se você pode acessar o banco de dados diretamente do seu aplicativo, é sempre melhor chamá-lo diretamente, em vez de usar a API da Web, é claro que se você usa a API da Web, pode facilmente portar seu aplicativo para uma plataforma diferente.

— Kirie
fonte
1
»Não sei onde você se perde, mas é bem claro que, quando você está usando a API REST, está fazendo uma etapa extra, e a etapa extra" sempre "significa mais lenta na programação envolvida.« Se isso significa uma execução mais lenta, isso não está certo.
— Thomas Junk
1
Não existem situações em que acessar o banco de dados é uma má idéia, além da portabilidade? Às vezes, ter uma API REST etc pode manter mais lógica (e melhor segurança?) Do lado do servidor, certo?
— J Trana
O @ JTrana que pode ser sim ou não, depende realmente de como você faz as coisas, ao introduzir uma camada extra, pode fornecer uma camada extra de segurança. A adição de uma camada extra também significa que você tem mais chance de estragar alguma coisa e expor a falha de segurança. Eu acho que o objetivo da API da Web é expor sua "API". Aplicativos grandes como Facebook, Amazon e Google que precisam fornecer acesso a terceiros e têm muita plataforma devem ter API da Web, mas para aplicativos pequenos, é necessário pensar duas vezes antes de fazê-lo.
— kirie
-2

DESCANSAR :

  • aberto para multi-frontends e 1 back-end
  • precisa criar sua própria API (ou usar uma como Loopback)
  • não está trabalhando offline

DB local:

  • não aberto para 'camadas', eles precisam ter acesso ao seu back-end para sincronizar
  • não há necessidade de criar uma API, use a interface DB
  • trabalhando offline

Esta é uma enorme diferença, muitas vezes as pessoas esquecem esses pontos

— Benjamin Fuentes
fonte
2
-1. Embora não haja "necessidade" de criar uma API, a criação de um DAL geralmente leva a uma enorme dor, caso seja necessária uma alteração no back-end do banco de dados. Também não há razão para que, se você tiver o banco de dados "offline", o serviço Rest não possa ser disponibilizado também.
— James Snell
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.