Nhưng điều đó có thực sự quan trọng? Hãy xem xét rằng UI phải thực hiện một cuộc gọi mạng tới API; đó là khá lớn (thứ tự cường độ của mili giây). Cơ sở dữ liệu được tối ưu hóa để giữ mọi thứ trong bộ nhớ và thực hiện đọc rất, rất nhanh (ví dụ: SQL Server tải và giữ mọi thứ trong RAM và tiêu thụ gần như tất cả RAM miễn phí của bạn nếu có thể).
Hợp lý
Về lý thuyết, bạn đúng. Tuy nhiên, có một vài sai sót với lý do này:
Từ những gì bạn đã nêu, không rõ liệu bạn có thực sự kiểm tra / định hình ứng dụng của mình không. Nói cách khác, bạn có thực sự biết rằng mạng chuyển từ ứng dụng sang API là thành phần chậm nhất không? Bởi vì đó là trực quan, nên dễ dàng cho rằng nó là. Tuy nhiên, khi thảo luận về hiệu suất, bạn không bao giờ nên giả định. Tại nhà tuyển dụng của tôi, tôi là người dẫn đầu về hiệu suất. Khi tôi mới tham gia, mọi người cứ nói về CDN, sao chép, v.v. dựa trên trực giác về những điểm nghẽn phải là gì. Hóa ra, vấn đề hiệu năng lớn nhất của chúng tôi là các truy vấn cơ sở dữ liệu hoạt động kém.
Bạn đang nói rằng vì cơ sở dữ liệu rất tốt trong việc truy xuất dữ liệu, nên cơ sở dữ liệu nhất thiết phải chạy ở hiệu suất cao nhất, đang được sử dụng tối ưu và không có gì có thể được thực hiện để cải thiện dữ liệu. Nói cách khác, cơ sở dữ liệu được thiết kế nhanh, vì vậy tôi không bao giờ phải lo lắng về nó. Một dòng suy nghĩ nguy hiểm khác. Điều đó giống như nói rằng một chiếc xe có nghĩa là di chuyển nhanh chóng, vì vậy tôi không cần phải thay dầu.
Cách suy nghĩ này giả định một quá trình duy nhất tại một thời điểm, hoặc đặt một cách khác, không đồng thời. Nó giả định rằng một yêu cầu không thể ảnh hưởng đến hiệu suất của yêu cầu khác. Các tài nguyên được chia sẻ, chẳng hạn như I / O đĩa, băng thông mạng, nhóm kết nối, bộ nhớ, chu kỳ CPU, v.v. Do đó, việc giảm việc sử dụng tài nguyên dùng chung của một cuộc gọi cơ sở dữ liệu có thể ngăn không cho các yêu cầu khác chậm lại. Khi tôi mới gia nhập công ty hiện tại, ban quản lý tin rằng việc điều chỉnh truy vấn cơ sở dữ liệu 3 giây là một sự lãng phí thời gian. 3 giây là rất ít, tại sao phải lãng phí thời gian vào nó? Chúng ta sẽ không tốt hơn với CDN hay nén hay cái gì khác chứ? Nhưng nếu tôi có thể thực hiện truy vấn 3 giây trong 1 giây, hãy nói bằng cách thêm một chỉ mục, đó là chặn 2/3 ít hơn, 2/3 ít thời gian hơn để chiếm một luồng và quan trọng hơn là đọc dữ liệu từ đĩa ít hơn,
Học thuyết
Có một quan niệm phổ biến rằng hiệu suất phần mềm chỉ đơn giản là về tốc độ .
Từ quan điểm hoàn toàn tốc độ, bạn đã đúng. Một hệ thống chỉ nhanh như thành phần chậm nhất của nó. Nếu bạn đã lập hồ sơ mã của mình và thấy rằng Internet là thành phần chậm nhất, thì mọi thứ khác rõ ràng không phải là phần chậm nhất.
Tuy nhiên, với những điều trên, tôi hy vọng bạn có thể thấy sự tranh chấp tài nguyên, thiếu lập chỉ mục, mã viết kém, v.v. có thể tạo ra sự khác biệt đáng ngạc nhiên về hiệu suất.
Các giả định
Một điều cuối cùng. Bạn đã đề cập rằng một cuộc gọi cơ sở dữ liệu nên rẻ so với một cuộc gọi mạng từ ứng dụng đến API. Nhưng bạn cũng đã đề cập rằng ứng dụng và máy chủ API nằm trong cùng một mạng LAN. Do đó, không phải cả hai đều có thể so sánh như các cuộc gọi mạng? Nói cách khác, tại sao bạn lại cho rằng việc chuyển API là các lệnh có độ lớn chậm hơn so với chuyển cơ sở dữ liệu khi cả hai đều có cùng băng thông khả dụng? Tất nhiên các giao thức và cấu trúc dữ liệu là khác nhau, tôi hiểu điều đó, nhưng tôi tranh luận về giả định rằng chúng là các đơn đặt hàng có cường độ khác nhau.
Nơi nó nhận được murkey
Toàn bộ câu hỏi này là về các cuộc gọi cơ sở dữ liệu "nhiều" so với "đơn". Nhưng không rõ có bao nhiêu là nhiều. Vì những gì tôi đã nói ở trên, như một quy tắc chung, tôi khuyên bạn nên thực hiện càng ít cuộc gọi cơ sở dữ liệu khi cần thiết. Nhưng đó chỉ là một quy tắc của ngón tay cái.
Đây là lý do tại sao:
- Cơ sở dữ liệu rất tốt trong việc đọc dữ liệu. Chúng là công cụ lưu trữ. Tuy nhiên, logic kinh doanh của bạn sống trong ứng dụng của bạn. Nếu bạn thực hiện quy tắc rằng mọi cuộc gọi API đều dẫn đến chính xác một cuộc gọi cơ sở dữ liệu, thì logic nghiệp vụ của bạn có thể kết thúc trong cơ sở dữ liệu. Có lẽ đó là ok. Rất nhiều hệ thống làm điều đó. Nhưng một số thì không. Đó là về sự linh hoạt.
- Đôi khi để đạt được sự tách rời tốt, bạn muốn tách 2 cuộc gọi cơ sở dữ liệu. Ví dụ: có lẽ mọi yêu cầu HTTP được định tuyến thông qua bộ lọc bảo mật chung xác thực từ DB rằng người dùng có quyền truy cập đúng. Nếu họ làm như vậy, tiến hành thực hiện chức năng thích hợp cho URL đó. Chức năng đó có thể tương tác với cơ sở dữ liệu.
- Gọi cơ sở dữ liệu trong một vòng lặp. Đây là lý do tại sao tôi hỏi có bao nhiêu là nhiều. Trong ví dụ trên, bạn sẽ có 2 cuộc gọi cơ sở dữ liệu. 2 là tốt 3 có thể ổn. N không ổn. Nếu bạn gọi cơ sở dữ liệu trong một vòng lặp, thì bây giờ bạn đã thực hiện tuyến tính hiệu suất, điều đó có nghĩa là nó sẽ mất nhiều thời gian hơn trong đầu vào của vòng lặp. Vì vậy, nói một cách cụ thể rằng thời gian mạng API là chậm nhất hoàn toàn bỏ qua sự bất thường như 1% lưu lượng truy cập của bạn mất nhiều thời gian do vòng lặp chưa được phát hiện gọi cơ sở dữ liệu 10.000 lần.
- Đôi khi có những thứ ứng dụng của bạn tốt hơn, như một số tính toán phức tạp. Bạn có thể cần phải đọc một số dữ liệu từ cơ sở dữ liệu, thực hiện một số tính toán, sau đó dựa trên kết quả, chuyển tham số cho cuộc gọi cơ sở dữ liệu thứ hai (có thể để viết một số kết quả). Nếu bạn kết hợp chúng thành một cuộc gọi duy nhất (như một thủ tục được lưu trữ) chỉ với mục đích chỉ gọi cơ sở dữ liệu một lần, bạn đã buộc mình phải sử dụng cơ sở dữ liệu cho một cái gì đó mà máy chủ ứng dụng có thể tốt hơn.
- Cân bằng tải: Bạn có 1 cơ sở dữ liệu (có lẽ) và nhiều máy chủ ứng dụng cân bằng tải. Do đó, ứng dụng càng hoạt động nhiều và cơ sở dữ liệu càng ít thì càng dễ mở rộng quy mô vì việc thêm một máy chủ ứng dụng thường dễ dàng hơn so với sao chép cơ sở dữ liệu. Dựa trên dấu đầu dòng trước đó, có thể có ý nghĩa khi chạy truy vấn SQL, sau đó thực hiện tất cả các tính toán trong ứng dụng, được phân phối trên nhiều máy chủ và sau đó viết kết quả khi hoàn tất. Điều này có thể cung cấp thông lượng tốt hơn (ngay cả khi thời gian giao dịch tổng thể là như nhau).
TL; DR
TLDR: Có thực sự đáng lo ngại về nhiều cuộc gọi cơ sở dữ liệu khi chúng tôi đã thực hiện một cuộc gọi mạng qua mạng LAN không? Nếu vậy, tại sao?
Có, nhưng chỉ ở một mức độ nhất định. Bạn nên cố gắng giảm thiểu số lượng cuộc gọi cơ sở dữ liệu khi thực tế, nhưng đừng kết hợp các cuộc gọi không liên quan gì đến nhau chỉ vì mục đích kết hợp chúng. Ngoài ra, tránh gọi cơ sở dữ liệu trong một vòng lặp bằng mọi giá.