Що швидше? Використовуєте REST API або запитуєте базу даних безпосередньо?

16

Що є швидшим продуктивним? Створення API REST та використання вашого веб-додатка за допомогою API REST для взаємодії з вашою базою даних АБО безпосередньо запиту вашої бази даних (тобто, використовуючи будь-який типовий об'єкт, який використовується вашою мовою для запиту бази даних, наприклад, JDBC для Java)?

Те, як я бачу це з REST:

Ви робите об'єкт у своєму коді для виклику методу REST
Виклик методу http
Код всередині вашого REST API запитує базу даних
База даних повертає деякі дані
Код REST API пакує дані в Json і надсилає їх вашому клієнту
Клієнт отримує відповідь Json / XML
Відповідь карти на об’єкт у вашому коді

З іншого боку, запит на базу даних безпосередньо:

Ви робите об'єкт із рядком запиту для запиту бази даних
База даних повертає деякі дані
Відповідь карти на об’єкт у вашому коді

Так чи не означає це, що використання API REST буде повільніше? Може, це залежить від типу бази даних (SQL проти NoSQL)?

database rest sql

— Мікро
джерело

3

API REST не є протоколом доступу до бази даних, тому питання велика помилка категорії. REST api - це магазин документів. МОЖЕ використовувати базу даних на стороні сервера (або це не може). Якщо у вас немає потреби в API REST, явно не використовуйте його. Але тоді це стосується всього. Якщо вам не потрібна база даних, не використовуйте її, запис у файлову систему буде швидше, ніж у базу даних. Якщо вам не потрібна файлова система, не використовуйте її, запис в оперативну пам'ять швидше, ніж на диск. Якщо вам не потрібна оперативна пам’ять, не використовуйте її, запис у кеш процесора швидше і т.

— Д. І т. Д.

1

"З іншого боку" вимагає, щоб ви піддавали свою базу даних великому поганому світу.

— Пітер Б

@PieterB: Ні, "з іншого боку" відкриває базу даних веб-додатку, якому довіряють.

— ЖакБ

@JacquesB і веб-додаток працює на комп'ютері клієнтів. Тож йому не слід довіряти, оскільки це може бути модифікована версія.

— Пітер Б

@PieterB: У запитанні нічого не зазначено про веб-додаток, що працює на ненадійному сервері. Це було б надзвичайно незвично.

— ЖакБ

18

При додаванні складності код працюватиме повільніше. Введення послуги REST, якщо вона не потрібна, уповільнить її виконання, оскільки система робить більше.

Абстрагування бази даних - хороша практика. Якщо ви турбуєтесь про швидкість, ви можете заглянути в кешування даних у пам'яті, так що для обробки запиту не потрібно торкатися бази даних.

Перш ніж оптимізувати продуктивність, хоча я розглядаю проблему, яку ви намагаєтеся вирішити, та архітектуру, яку ви використовуєте, я намагаюся думати про ситуацію, коли параметри бази даних будуть прямим доступом до REST.

— Клі
джерело

+1 для згадування кешування. Хоча це робить extra work. Але насправді це може бути швидше кешуванням повторного запиту.

— Яна Агун Сісванто

3

@Klee Ваша відповідь не зовсім правильна. »Введення служби REST, якщо вона не потрібна, сповільнить її виконання, оскільки система робить більше.« Не в кожному випадку трафік до кінцевої точки взагалі є, якщо, наприклад, реверсивний проксі може обробляти кешовані результати.

— Томас Джунк

@klee Тому я поставив це питання було від цього SO поста programmers.stackexchange.com/questions/277701 / ... - один відповідь говорить про те , як Amazon мав великий успіх, використовуючи повністю RESTful системи замість прямого доступу. Щойно змусив мене подумати ...

— Micro

9

Якщо вас турбує швидкість, то так, послуга відпочинку буде повільнішою з причин, зазначених вище. Однак швидкість типу, яку ви описуєте, рідко є першочерговою проблемою, і якщо вона є, її можна вирішити іншими способами. Передчасна оптимізація - корінь усього зла .

Подумайте, якщо ваша основна проблема - інтероперабельність (мобільний, веб, B2B), зараз REST дуже привабливий, оскільки це агностик.

Припустимо, ви кодуєте базу даних. Що ви зробите, якщо вирішите змінити базовий сховище даних. Наскільки важко було б зробити, якщо ви щільно з'єднані з базовим магазином?

Справжня відповідь - це залежить , але, сподіваюся, я дав вам деякі речі, щоб подумати!

— Ромський
джерело

6

Якщо вам важко відповісти на це питання.

Правильна загальна відповідь повинна бути: це залежить.

Те, як я бачу це з REST:

Ви робите об'єкт у своєму коді для виклику методу REST

Виклик методу http

Код всередині вашого REST API запитує базу даних

База даних повертає деякі дані

Код REST API пакує дані в Json і надсилає їх вашому клієнту

Клієнт отримує відповідь Json / XML

Відповідь карти на об’єкт у вашому коді

У вашій думці є помилка.

І ця помилка випливає з того, що ви не повністю розумієте REST та його принципи. REST не був винайдений, тому що деякі ботаніки вважають, що це здорово (звичайно, це є) надсилати Javascript-об’єкти через HTTP через провід. Основна перевага використання HTTP - це можливість використання кешування . Якщо ви зробите кешовані результати , то запитів до БД буде менше. І жоден маршал не бере участь. Відповідь можна було б отримати безпосередньо.

Відповідь Insofar @Klees не зовсім правильна :

При додаванні складності код працюватиме повільніше. Введення послуги REST, якщо вона не потрібна, уповільнить її виконання, оскільки система робить більше.

Якщо мати справу з результатами кеш-пам'яті, це не вплине на вашу програму: надання відомих відповідей на відомі питання може здійснюватися через зворотні проксі.

— Томас Юнк
джерело

4

Якщо дані є кешованими на рівні сервісу відпочинку, то вони можуть кешуватися у веб-додатку, що було б набагато краще за продуктивність.

— ЖакБ

Найшвидший спосіб - це взагалі не потрапляти на веб-додаток.

— Thomas Junk

1

І щоб зробити це цікавіше, не всі "звернення" до бази даних рівні, якщо ви можете отримати доступ до пам'яті проти диска.

— JeffO

@ThomasJunk: Якщо я правильно розумію оригінальне запитання, клієнт - це веб-додаток, і питання полягає в тому, чи повинен веб-додаток підключитися безпосередньо до db або зателефонувати через сервіс відпочинку.

— ЖакБ

1

Це не змінює нічого в моїй відповіді. Виклик REST-сервісу включає виклик на веб-сервер, який може бути за зворотним проксі, де можливі відповіді в кешування - як я вже говорив.

— Томас Юнк

2

Введення додаткового рівня обслуговування завжди має складність та ефективність витрат. Існують деякі специфічні види архітектури, де введення загального рівня обслуговування (наприклад, API REST) може покращити ефективність завдяки спільному кешуванню - але це здається, що це не та архітектура, яку ви маєте.

Розглянемо архітектуру, де у вас є декілька веб-додатків або декілька додатків для настільних ПК, що підключаються безпосередньо до однієї бази даних. Якщо вони виконують однакові запити часто, це може підвищити ефективність кешування результатів запиту в спільній службі. Особливо, якщо ви говорите, що сотні настільних додатків безпосередньо отримують доступ до однієї бази даних (не через веб-додаток!) Та виконують ті самі запити, це може бути серйозним вдосконаленням. Однак навіть у цій архітектурі первинною причиною впровадження спільної послуги, ймовірно, буде безпека та абстрагування даних, а не продуктивність.

Але це здається, що у вас є єдиний веб-додаток, який безпосередньо підключається до бази даних. У цьому випадку немає користі для введення додаткового рівня обслуговування. Кешування, абстрагування баз даних і т.д. можна обробляти на рівні доступу до даних в одній програмі.

— ЖакБ
джерело

1

Це залежить.

Очевидно, що чим більше шарів у вашому коді, тим повільніше він проходить. Але ... настає момент, коли пряма робота в кінці не має значення стільки, скільки масштабованість. Якщо у вас є один користувач, який має доступ до вашої бази даних на локальному ПК, це може швидко пройти. Якщо у вас є тисяча користувачів, які отримують доступ до тієї ж БД на одному і тому ж ПК, швидше за все, ви побачите, що всі вони зіпсуються. Рішення полягає в тому, щоб перенести БД в інше поле, додати шар посередині, і хоча для 1 користувача він буде працювати повільніше, коли тисяча отримає доступ до нього, він піде швидше. (це спрощена відповідь, але в принципі правдива).

Є й інші причини приховувати вашу БД за середнім рівнем ярусу, наприклад, безпека.

— gbjbaanb
джерело

-2

Я не знаю, де ви загубитесь, але цілком зрозуміло, що коли ви використовуєте REST API, ви робите додатковий крок, а додатковий крок "завжди" означає повільніше, коли займаєтесь програмуванням.

Є плюси і мінуси, але якщо ви можете отримати доступ до бази даних безпосередньо зі своєї програми, завжди краще зателефонувати їй безпосередньо замість веб-API, звичайно, якщо ви використовуєте Web API, ви можете легко перенести свою програму на іншу платформу.

— кірі
джерело

1

"Я не знаю, де ти загубишся, але цілком зрозуміло, що коли ти використовуєш REST API, ти робиш додатковий крок, а додатковий крок" завжди "означає повільніше при включенні програмування." Якщо це означає повільніше у виконанні, це не правильно.

— Томас Джунк

1

Чи не буває ситуацій, коли доступ до бази даних є поганою ідеєю, окрім простої портативності? Іноді наявність REST API тощо може підтримувати більше логіки (і кращої безпеки?) На стороні сервера, правда?

— J Trana

@JTrana, що може бути так чи ні, насправді залежить від того, як ви робите щось, тоді як введення додаткового шару може забезпечити додатковий рівень безпеки, додавання додаткового шару також означає, що у вас є більше шансів викрутити щось і відкрити захисну дірку. Я думаю, що сенс Web API - викрити свій "API". Великі програми, такі як Facebook, Amazon, Google, яким потрібно надати доступ стороннім і мають багато платформ, повинні мати веб-API, але для невеликих додатків потрібно подумати двічі, перш ніж це робити.

— kirie

-2

Відпочинок:

відкрито для декількох фронтенів та 1 бекенда
потрібно створити власний API (або використовувати такий, як Loopback)
не працює в режимі офлайн

Місцевий БД:

не відкриті до "ярусів", вони повинні мати доступ до вашого сервера для синхронізації
не потрібно створювати API, використовуйте інтерфейс БД
робота в автономному режимі

ЦЕ ОГРОМНА ВЕЛИЧЕЗНА РАЗЛИКА, ЛЮДИ ДЛЯ ЗАБОРОНУВАНИХ ТОЧКІВ

— Бенджамін Фуентес
джерело

2

-1. Хоча немає необхідності в створенні API, не створення DAL часто призводить до величезних болів, якщо потрібна зміна бекенда бази даних. Крім того, немає причин, якщо у вас БД "в режимі офлайн", що сервіс Відпочинок також не міг бути доступний.

— Джеймс Снелл