Co jest szybsze? Korzystasz z interfejsu API REST lub bezpośrednio przeszukujesz bazę danych?

16

Co jest szybsze pod względem wydajności? Utworzenie interfejsu API REST i użycie aplikacji REST API do wykonywania wszystkich interakcji z bazą danych LUB bezpośrednie zapytania do bazy danych (tj. Przy użyciu typowego obiektu używanego przez język do tworzenia zapytań do bazy danych, takiego jak JDBC dla Java)?

Sposób w jaki widzę to z REST:

Tworzysz obiekt w kodzie, aby wywoływał metodę REST
Wywołaj metodę http
Kod wewnątrz interfejsu API REST odpytuje bazę danych
Baza danych zwraca niektóre dane
Kod API REST pakuje dane do Jsona i wysyła je do klienta
Klient otrzymuje odpowiedź Json / XML
Odwzoruj odpowiedź na obiekt w kodzie

Z drugiej strony, zapytanie bezpośrednio do bazy danych:

Tworzysz obiekt za pomocą ciągu zapytania do zapytania do bazy danych
Baza danych zwraca niektóre dane
Odwzoruj odpowiedź na obiekt w kodzie

Czy to nie znaczy, że używanie interfejsu API REST byłoby wolniejsze? Może zależy to od typu bazy danych (SQL vs NoSQL)?

database rest sql

— Micro
źródło

3

Interfejs API REST nie jest protokołem dostępu do bazy danych, więc pytanie jest dużym błędem kategorii. Interfejs API REST to magazyn dokumentów. MOŻE użyć bazy danych po stronie serwera (lub nie musi). Jeśli nie potrzebujesz interfejsu API REST, to oczywiście nie używaj go. Ale to dotyczy wszystkiego. Jeśli nie potrzebujesz bazy danych, nie korzystaj z niej, zapis do systemu plików będzie szybszy niż baza danych. Jeśli nie potrzebujesz systemu plików, nie używaj go, zapisywanie w pamięci RAM jest szybsze niż na dysku. Jeśli nie potrzebujesz pamięci RAM, nie używaj jej, zapisywanie do pamięci podręcznej procesora jest szybsze itp. Itd. Itd.

— Cormac Mulhall

1

„Z drugiej strony” wymaga, abyś wystawił swoją bazę danych na wielki zły świat.

— Pieter B,

@PieterB: Nie, „z drugiej strony” udostępnia bazę danych zaufanej aplikacji internetowej.

— JacquesB

@JacquesB, a aplikacja internetowa działa na komputerze klienta. Dlatego nie należy ufać, ponieważ może to być zmodyfikowana wersja.

— Pieter B

@PieterB: Pytanie nie mówi nic o aplikacji internetowej działającej na niezaufanym serwerze. To byłaby bardzo nietypowa konfiguracja.

— JacquesB

18

Po dodaniu złożoności kod będzie działał wolniej. Wprowadzenie usługi REST, jeśli nie jest wymagana, spowolni wykonanie, ponieważ system robi więcej.

Wyodrębnianie bazy danych jest dobrą praktyką. Jeśli martwisz się o szybkość, możesz zajrzeć do buforowania danych w pamięci, aby baza danych nie musiała być dotykana, aby obsłużyć żądanie.

Zanim jednak zoptymalizuję wydajność, przyjrzę się temu, jaki problem próbujesz rozwiązać i używanej architekturze, staram się wymyślić sytuację, w której opcje bazy danych byłyby dostępem bezpośrednim w porównaniu z REST.

— Klee
źródło

+1 za wzmiankę o buforowaniu. Chociaż to robi extra work. Ale tak naprawdę może to być szybsze przez buforowanie powtarzających się zapytań.

— Yana Agun Siswanto

3

@Klee Twoja odpowiedź jest nieprawidłowa. »Wprowadzenie usługi REST, jeśli nie jest wymagana, spowolni wykonanie, ponieważ system robi więcej.« Nie w każdym przypadku ruch do punktu końcowego jest w ogóle, jeśli np. Odwrotny serwer proxy może obsłużyć spreparowane wyniki.

— Thomas Junk

@klee Powód, dla którego zadałem to pytanie, pochodzi z tego postu SO programmers.stackexchange.com/questions/277701/... - jedna odpowiedź mówi o tym, jak Amazon odniósł wielki sukces, używając systemu w pełni RESTful zamiast bezpośredniego dostępu. Dopiero co pomyślałem ...

— Micro

9

Jeśli obawiasz się o szybkość, to tak, usługa odpoczynku będzie wolniejsza z wyżej wymienionych powodów. Jednak szybkość opisanego typu rzadko stanowi główny problem, a jeśli tak, to można go rozwiązać na inne sposoby. Przedwczesna optymalizacja jest źródłem wszelkiego zła .

Zastanów się, czy Twoim głównym celem jest interoperacyjność (mobilna, internetowa, B2B), teraz REST jest bardzo atrakcyjny, ponieważ jest niezależny od technologii.

Załóżmy, że kodujesz bazę danych. Co byś zrobił, gdybyś zmienił swój bazowy magazyn danych. Jak trudno byłoby to zrobić, jeśli jesteś ściśle związany ze sklepem?

Prawdziwa odpowiedź to zależy , ale mam nadzieję, że dałem ci kilka rzeczy do przemyślenia!

— Romski
źródło

6

Jeśli trudno jest odpowiedzieć na to pytanie.

Prawidłowa ogólna odpowiedź powinna brzmieć: to zależy.

Sposób w jaki widzę to z REST:

Tworzysz obiekt w kodzie, aby wywoływał metodę REST

Wywołaj metodę http

Kod wewnątrz interfejsu API REST odpytuje bazę danych

Baza danych zwraca niektóre dane

Kod API REST pakuje dane do Jsona i wysyła je do klienta

Klient otrzymuje odpowiedź Json / XML

Odwzoruj odpowiedź na obiekt w kodzie

W twojej myśli jest błąd.

Ten błąd wynika z faktu, że nie w pełni rozumiesz REST i jego zasady. REST nie został wymyślony, ponieważ niektórzy nerdowie uważali, że fajnie (oczywiście jest) wysyłać obiekty Javascript przez HTTP za pośrednictwem drutu. Główną zaletą korzystania z HTTP jest możliwość korzystania z buforowania . Jeśli sprawisz , że wyniki będą buforowane , to do bazy danych będzie mniej żądań. I nie jest zaangażowany żaden marshalling . Odpowiedź może zostać dostarczona bezpośrednio.

O ile odpowiedź na @Klees nie jest całkiem poprawna :

Po dodaniu złożoności kod będzie działał wolniej. Wprowadzenie usługi REST, jeśli nie jest wymagana, spowolni wykonanie, ponieważ system robi więcej.

W przypadku wyników z pamięci podręcznej nie ma to wpływu na twoją aplikację: dostarczanie znanych odpowiedzi na znane pytania można uzyskać za pośrednictwem odwrotnych serwerów proxy.

— Thomas Junk
źródło

4

Jeśli dane można buforować w warstwie usługi spoczynkowej, można je buforować w aplikacji internetowej, co byłoby znacznie lepsze dla wydajności.

— JacquesB

Najszybszym sposobem jest całkowite wyłączenie aplikacji internetowej.

— Thomas Junk

1

Żeby było bardziej interesująco, nie wszystkie „trafienia” do bazy danych są sobie równe, jeśli można uzyskać dostęp do pamięci v. Dysku.

— JeffO

@ThomasJunk: Jeśli rozumiem, że oryginalne pytanie jest prawidłowe, klient jest aplikacją internetową, a pytanie brzmi, czy aplikacja internetowa powinna połączyć się bezpośrednio z bazą danych lub zadzwonić za pośrednictwem usługi odpoczynku.

— JacquesB

1

To nic nie zmienia w mojej odpowiedzi. Wywołanie usługi REST obejmuje wywołanie do serwera WWW, który może znajdować się za zwrotnym serwerem proxy, gdzie możliwe są buforowanie możliwych odpowiedzi - jak już powiedziałem.

— Thomas Junk

2

Wprowadzenie dodatkowej warstwy usług zawsze wiąże się z kosztami złożoności i wydajności. Istnieją pewne specyficzne rodzaje architektury, w których wprowadzenie warstwy usług wspólnych (jak API REST) może poprawić perforację ze względu na buforowanie współdzielone - ale wygląda na to, że nie jest to architektura, którą masz.

Rozważ architekturę, w której masz wiele aplikacji internetowych lub wiele aplikacji komputerowych łączących się bezpośrednio z tą samą bazą danych. Jeśli często wykonują te same zapytania, może to poprawić wydajność buforowania wyników zapytań w usłudze współdzielonej. Zwłaszcza jeśli powiesz, że setki aplikacji komputerowych uzyskują dostęp do tej samej bazy danych bezpośrednio (nie przez aplikację internetową!) I wykonują te same zapytania, może być znaczna poprawa. Jednak nawet w tej architekturze głównym powodem wprowadzenia wspólnej usługi byłyby prawdopodobnie bezpieczeństwo i abstrakcja danych, a nie wydajność.

Ale wygląda na to, że masz jedną aplikację internetową, która łączy się bezpośrednio z bazą danych. W takim przypadku nie ma korzyści z wprowadzenia dodatkowej warstwy usług. Buforowanie, abstrakcja bazy danych itp. Mogą być obsługiwane w warstwie dostępu do danych w tej samej aplikacji.

— JacquesB
źródło

1

To zależy.

Oczywiście im więcej warstw w kodzie, tym wolniej. Ale ... przychodzi moment, w którym bezpośrednia kompleksowa wydajność nie ma tak dużego znaczenia, jak skalowalność. Jeśli 1 użytkownik uzyskuje dostęp do bazy danych na komputerze lokalnym, może ona działać szybko. Jeśli masz tysiąc użytkowników uzyskujących dostęp do tego samego DB na tym samym komputerze, istnieje szansa, że wszyscy się sfrustrują. Rozwiązaniem jest przeniesienie bazy danych do innej skrzynki, dodanie warstwy pośrodku i chociaż dla 1 użytkownika będzie działał wolniej, gdy tysiąc dostępu do niego, pójdzie szybciej. (to uproszczona odpowiedź, ale z zasady prawdziwa).

Istnieją inne powody, aby ukryć swoją bazę danych za warstwą warstwy środkowej, takie jak bezpieczeństwo.

— gbjbaanb
źródło

-2

Nie wiem, gdzie się zgubiłeś, ale jest całkiem jasne, że kiedy używasz interfejsu API REST, robisz dodatkowy krok, a dodatkowy krok „zawsze” oznacza wolniejszy, gdy programowanie jest zaangażowane.

Są plusy i minusy, ale jeśli możesz uzyskać dostęp do bazy danych bezpośrednio z aplikacji, zawsze lepiej jest wywoływać ją bezpośrednio zamiast używać Web API, oczywiście jeśli używasz Web API, możesz łatwo przenieść aplikację na inną platformę.

— kirie
źródło

1

»Nie wiem, gdzie się zgubiłeś, ale jest całkiem jasne, że kiedy używasz interfejsu API REST, robisz dodatkowy krok, a dodatkowy krok„ zawsze ”oznacza wolniej podczas programowania.« Jeśli to oznacza wolniejsze działanie, to nie jest poprawne.

— Thomas Junk

1

Czy nie są sytuacje, w których dostęp do bazy danych jest złym pomysłem oprócz samej przenośności? Czasami posiadanie interfejsu API REST itp. Pozwala zachować większą logikę (i lepsze bezpieczeństwo?) Po stronie serwera, prawda?

— J Trana,

@JTrana, która może być tak lub nie, naprawdę zależy od tego, co robisz, a wprowadzenie dodatkowej warstwy może zapewnić dodatkową warstwę bezpieczeństwa, dodanie dodatkowej warstwy oznacza również, że masz większą szansę zepsuć coś i odsłonić dziurę w zabezpieczeniach. Myślę, że celem interfejsu API sieci Web jest ujawnienie twojego „API”. Duże aplikacje, takie jak Facebook, Amazon, Google, które muszą zapewniać dostęp do stron trzecich i mieć wiele platform, muszą mieć interfejs API sieci Web, ale w przypadku małych aplikacji trzeba to przemyśleć dwa razy.

— kirie

-2

ODPOCZYNEK :

otwarty na wiele frontendów i 1 backend
musisz stworzyć swój własny interfejs API (lub użyć takiego jak Loopback)
nie działa w trybie offline

Lokalna baza danych:

nie otwarte dla „warstw”, muszą mieć dostęp do backendu, aby zsynchronizować
nie musisz tworzyć API, użyj interfejsu DB
pracuje w trybie offline

TO DOSKONAŁA OGROMNA RÓŻNICA, CZĘSTO ZAPOMNIANO TE PUNKTY

— Benjamin Fuentes
źródło

2

-1. Chociaż nie ma „potrzeby” tworzenia interfejsu API, brak tworzenia DAL często prowadzi do ogromnego bólu, jeśli konieczna jest zmiana zaplecza bazy danych. Również nie ma powodu, dla którego jeśli użytkownik ma bazę „offline”, nie można tam również udostępnić usługi Rest.

— James Snell,