Cái gì nhanh hơn? Sử dụng API REST hoặc truy vấn cơ sở dữ liệu trực tiếp?

16

Hiệu suất nhanh hơn khôn ngoan là gì? Tạo API REST và để ứng dụng web của bạn sử dụng API REST để thực hiện tất cả các tương tác với cơ sở dữ liệu của bạn HOẶC truy vấn trực tiếp cơ sở dữ liệu của bạn (nghĩa là sử dụng bất kỳ đối tượng điển hình nào mà ngôn ngữ của bạn sử dụng để truy vấn cơ sở dữ liệu như JDBC cho Java)?

Cách tôi nhìn thấy nó với REST:

Bạn tạo một đối tượng trong mã của mình để gọi phương thức REST
Gọi phương thức http
Mã bên trong API REST của bạn truy vấn cơ sở dữ liệu
Cơ sở dữ liệu trả về một số dữ liệu
Mã API REST đóng gói dữ liệu vào Json và gửi nó đến máy khách của bạn
Khách hàng nhận được phản hồi Json / XML
Phản hồi bản đồ đến một đối tượng trong mã của bạn

Mặt khác, truy vấn cơ sở dữ liệu trực tiếp:

Bạn tạo một đối tượng với chuỗi truy vấn để truy vấn cơ sở dữ liệu
Cơ sở dữ liệu trả về một số dữ liệu
Phản hồi bản đồ đến một đối tượng trong mã của bạn

Vì vậy, điều này có nghĩa là việc sử dụng API REST sẽ chậm hơn? Có lẽ nó phụ thuộc vào loại cơ sở dữ liệu (SQL vs NoQuery)?

database rest sql

— Vi mô
nguồn

3

API REST không phải là một giao thức truy cập cơ sở dữ liệu, vì vậy câu hỏi là một lỗi lớn của danh mục. Một api REST là một cửa hàng tài liệu. Nó MIGHT sử dụng cơ sở dữ liệu ở phía máy chủ (hoặc có thể không). Nếu bạn không có nhu cầu về API REST thì rõ ràng không nên sử dụng API. Nhưng sau đó là tất cả. Nếu bạn không cần cơ sở dữ liệu, đừng sử dụng cơ sở dữ liệu, việc ghi vào hệ thống tệp sẽ nhanh hơn cơ sở dữ liệu. Nếu bạn không cần một hệ thống tệp không sử dụng một tệp, ghi vào RAM sẽ nhanh hơn đĩa. Nếu bạn không cần RAM, đừng sử dụng nó, ghi vào bộ đệm CPU sẽ nhanh hơn, v.v.

— Cormac Mulhall

1

"Mặt khác" yêu cầu bạn đưa cơ sở dữ liệu của mình đến thế giới xấu lớn.

— Pieter B

@PieterB: Không, "mặt khác" đang hiển thị cơ sở dữ liệu cho ứng dụng web đáng tin cậy.

— JacquesB

@JacquesB và ứng dụng web chạy trên máy khách. Vì vậy, nó không nên được tin cậy bởi vì nó có thể là một phiên bản sửa đổi.

— Pieter B

@PieterB: Câu hỏi không nêu bất cứ điều gì về ứng dụng web đang chạy trên một máy chủ không tin cậy. Đó sẽ là một thiết lập rất bất thường.

— JacquesB

18

Khi bạn thêm độ phức tạp, mã sẽ chạy chậm hơn. Giới thiệu một dịch vụ REST nếu không yêu cầu sẽ làm chậm quá trình thực thi vì hệ thống đang làm nhiều hơn.

Tóm tắt cơ sở dữ liệu là thực hành tốt. Nếu bạn lo lắng về tốc độ, bạn có thể xem bộ đệm dữ liệu trong bộ nhớ để cơ sở dữ liệu không cần phải chạm vào để xử lý yêu cầu.

Trước khi tối ưu hóa hiệu suất mặc dù tôi đang xem xét vấn đề nào bạn đang cố gắng giải quyết và kiến trúc bạn đang sử dụng, tôi đang loay hoay nghĩ đến một tình huống trong đó các tùy chọn cơ sở dữ liệu sẽ là truy cập trực tiếp so với REST.

— Klee
nguồn

+1 để đề cập đến bộ nhớ đệm. Mặc dù nó đang làm extra work. Nhưng thực sự nó có thể nhanh hơn bằng cách lưu lại truy vấn lặp lại.

— Yana Agun Siswanto

3

@Klee Câu trả lời của bạn không hoàn toàn đúng. »Giới thiệu dịch vụ REST nếu không yêu cầu sẽ làm chậm quá trình thực thi vì hệ thống đang hoạt động nhiều hơn.« Không phải trong mọi trường hợp đều có lưu lượng truy cập đến điểm cuối, nếu ví dụ, proxy ngược có thể xử lý kết quả bị hủy.

— Thomas Junk

@klee Lý do tôi hỏi câu hỏi này là từ các lập trình viên SO này.stackexchange.com/questions/277701/ ( một câu trả lời nói về cách Amazon thành công lớn bằng cách sử dụng hệ thống RESTful đầy đủ thay vì truy cập trực tiếp. Chỉ cần tôi suy nghĩ ...

— Micro

9

Nếu bạn lo lắng là tốc độ, thì có, dịch vụ Nghỉ ngơi sẽ chậm hơn vì những lý do đã nêu ở trên. Tuy nhiên, tốc độ của loại bạn mô tả hiếm khi là mối quan tâm chính và nếu có, có thể được giải quyết theo những cách khác. Tối ưu hóa sớm là gốc rễ của mọi tội lỗi .

Hãy xem xét nếu mối quan tâm chính của bạn là khả năng tương tác (di động, web, B2B), thì bây giờ REST rất hấp dẫn bởi vì nó là bất khả tri về công nghệ.

Giả sử bạn mã cho cơ sở dữ liệu. Bạn sẽ làm gì nếu bạn chọn thay đổi kho dữ liệu cơ bản của mình. Sẽ khó đến mức nào nếu bạn kết hợp chặt chẽ với cửa hàng bên dưới?

Câu trả lời thực sự là tùy thuộc , nhưng hy vọng tôi đã cho bạn một số điều để suy nghĩ!

— Romski
nguồn

6

Nếu thấy khó trả lời câu hỏi này.

Câu trả lời chung đúng nên là: nó phụ thuộc.

Cách tôi nhìn thấy nó với REST:

Bạn tạo một đối tượng trong mã của mình để gọi phương thức REST

Gọi phương thức http

Mã bên trong API REST của bạn truy vấn cơ sở dữ liệu

Cơ sở dữ liệu trả về một số dữ liệu

Mã API REST đóng gói dữ liệu vào Json và gửi nó đến máy khách của bạn

Khách hàng nhận được phản hồi Json / XML

Phản hồi bản đồ đến một đối tượng trong mã của bạn

Có một sai lầm trong suy nghĩ của bạn.

Và sai lầm này xuất phát từ thực tế, rằng bạn không hiểu đầy đủ về REST và các nguyên tắc của nó. REST không được phát minh, bởi vì một số mọt sách thấy nó thật tuyệt (dĩ nhiên là vậy) để gửi các đối tượng Javascript qua HTTP qua dây. Ưu điểm chính của việc sử dụng HTTP là khả năng sử dụng bộ đệm . Nếu bạn làm cho kết quả của mình được lưu trong bộ nhớ cache , thì sẽ có ít yêu cầu được gửi tới DB hơn. Và không có đầm lầy có liên quan. Câu trả lời có thể được gửi trực tiếp.

Câu trả lời của Insofar @Klees không hoàn toàn đúng :

Khi bạn thêm độ phức tạp, mã sẽ chạy chậm hơn. Giới thiệu một dịch vụ REST nếu không yêu cầu sẽ làm chậm quá trình thực thi vì hệ thống đang làm nhiều hơn.

Khi xử lý các kết quả của bộ nhớ cache, không có tác động nào đến ứng dụng của bạn: việc cung cấp các câu trả lời đã biết cho các câu hỏi đã biết có thể được thực hiện thông qua các proxy ngược.

— Thomas Junk
nguồn

4

Nếu dữ liệu được lưu trong bộ nhớ cache trong một lớp dịch vụ còn lại, thì nó có thể được lưu trong bộ nhớ cache trong ứng dụng web, điều này sẽ tốt hơn nhiều cho hiệu suất.

— JacquesB

Cách nhanh nhất là, không nhấn ứng dụng web nào cả.

— Thomas Junk

1

Và chỉ để làm cho nó thú vị hơn, không phải tất cả các "lần truy cập" vào cơ sở dữ liệu đều bằng nhau nếu bạn có thể truy cập vào bộ nhớ v. Đĩa.

— JeffO

@ThomasJunk: Nếu tôi hiểu chính xác câu hỏi ban đầu, máy khách là một ứng dụng web và câu hỏi là liệu ứng dụng web có nên kết nối trực tiếp với db hay gọi qua dịch vụ nghỉ ngơi.

— JacquesB

1

Điều đó không thay đổi bất cứ điều gì trên câu trả lời của tôi. Gọi một Dịch vụ REST bao gồm gọi ra Máy chủ Web có thể đứng sau một proxy ngược nơi các câu trả lời có thể có thể được lưu trong bộ nhớ cache - như tôi đã nói.

— Thomas Junk

2

Giới thiệu một tầng dịch vụ bổ sung luôn có chi phí phức tạp và chi phí hiệu năng. Có một số loại kiến trúc cụ thể trong đó giới thiệu tầng dịch vụ dùng chung (như API REST) có thể cải thiện lực lượng do bộ nhớ đệm được chia sẻ - nhưng có vẻ như đó không phải là loại kiến trúc bạn có.

Hãy xem xét một kiến trúc nơi bạn có nhiều ứng dụng web hoặc nhiều ứng dụng máy tính để bàn kết nối trực tiếp với cùng một cơ sở dữ liệu. Nếu họ thực hiện cùng một truy vấn thường xuyên, nó có thể cải thiện hiệu suất để lưu kết quả truy vấn bộ đệm trong một dịch vụ chia sẻ. Đặc biệt nếu bạn nói rằng hàng trăm ứng dụng máy tính để bàn truy cập trực tiếp vào cùng một cơ sở dữ liệu (không thông qua ứng dụng web!) Và thực hiện các truy vấn tương tự, có thể có một cải tiến lớn. Tuy nhiên, ngay cả trong kiến trúc này, lý do chính để giới thiệu một dịch vụ chia sẻ có lẽ là sự trừu tượng hóa về bảo mật và dữ liệu hơn là hiệu năng.

Nhưng có vẻ như bạn có một ứng dụng web duy nhất kết nối trực tiếp với cơ sở dữ liệu. Trong trường hợp đó, không có lợi ích gì khi giới thiệu một lớp dịch vụ bổ sung. Bộ nhớ đệm, trừu tượng hóa cơ sở dữ liệu, vv có thể được xử lý tại lớp truy cập dữ liệu trong cùng một ứng dụng.

— JacquesB
nguồn

1

Nó phụ thuộc.

Rõ ràng, càng nhiều lớp trong mã của bạn thì nó càng đi chậm. Nhưng ... có một điểm mà hiệu suất từ đầu đến cuối trực tiếp không quan trọng bằng khả năng mở rộng. Nếu bạn có 1 người dùng truy cập cơ sở dữ liệu của mình trên PC cục bộ, nó có thể chạy nhanh. Nếu bạn có một nghìn người dùng truy cập cùng một DB trên cùng một PC, rất có thể bạn sẽ thấy tất cả họ đều cảm thấy thất vọng. Giải pháp là di chuyển DB sang một hộp khác, thêm một lớp ở giữa và mặc dù với 1 người dùng, nó sẽ hoạt động chậm hơn, khi hàng ngàn truy cập vào nó, nó sẽ đi nhanh hơn. (đó là một câu trả lời đơn giản nhưng đúng về nguyên tắc).

Có nhiều lý do khác để ẩn DB của bạn đằng sau lớp trung gian, chẳng hạn như bảo mật.

— gbjbaanb
nguồn

-2

Tôi không biết bạn bị lạc ở đâu, nhưng điều này khá rõ ràng, khi bạn đang sử dụng API REST, bạn đang thực hiện thêm bước và bước thêm "luôn luôn" có nghĩa là chậm hơn khi tham gia lập trình.

Có những ưu và nhược điểm, nhưng nếu bạn có thể truy cập cơ sở dữ liệu trực tiếp từ ứng dụng của mình thì tốt hơn là gọi trực tiếp thay vì sử dụng API Web, tất nhiên nếu bạn sử dụng API Web, bạn có thể dễ dàng chuyển ứng dụng của mình sang nền tảng khác.

— đồng cỏ
nguồn

1

»Tôi không biết bạn bị lạc ở đâu, nhưng khá rõ ràng, khi bạn sử dụng API REST, bạn đang thực hiện thêm bước và bước thêm" luôn luôn "có nghĩa là chậm hơn khi lập trình liên quan.« Nếu điều đó có nghĩa là thực thi chậm hơn, « điều đó không đúng.

— Thomas Junk

1

Không có tình huống truy cập cơ sở dữ liệu là một ý tưởng tồi ngoài việc chỉ có tính di động? Đôi khi, có API REST, vv có thể giữ logic hơn (và bảo mật tốt hơn?) Ở phía máy chủ, phải không?

— J Trana

@JTrana có thể có hoặc không, thực sự phụ thuộc vào cách bạn làm trong khi giới thiệu lớp bổ sung có thể cung cấp thêm lớp bảo mật, thêm lớp bổ sung cũng có nghĩa là bạn có nhiều cơ hội hơn để làm hỏng cái gì đó và lộ lỗ hổng bảo mật. Tôi nghĩ rằng quan điểm của API Web là để lộ "API" của bạn. Ứng dụng lớn như Facebook, Amazon, Google cần cung cấp quyền truy cập cho bên thứ 3 và có nhiều nền tảng phải có API Web, nhưng đối với ứng dụng nhỏ, bạn cần suy nghĩ kỹ trước khi thực hiện.

— Kiri

-2

NGHỈ NGƠI :

mở cho nhiều mặt trận và 1 phụ trợ
cần tạo API của riêng bạn (hoặc sử dụng một API như Loopback)
không hoạt động ngoại tuyến

DB địa phương:

chưa được mở cho 'tầng', họ cần có quyền truy cập vào phần phụ trợ của bạn để đồng bộ hóa
không cần tạo API, hãy sử dụng giao diện DB
làm việc ngoại tuyến

ĐÂY LÀ SỰ KHÁC BIỆT TUYỆT VỜI, MỌI NGƯỜI ĐÃ QUÊN NHỮNG ĐIỂM NÀY

— Benjamin Fuentes
nguồn

2

-1. Mặc dù không có "nhu cầu" để tạo API, nhưng việc không tạo DAL thường dẫn đến nỗi đau rất lớn nên cần phải thay đổi phụ trợ cơ sở dữ liệu. Cũng không có lý do tại sao nếu bạn có DB "ngoại tuyến" thì dịch vụ Rest cũng không thể được cung cấp ở đó.

— James Snell