Nhiều cơ sở dữ liệu truy cập hoặc một truy cập lớn?

Cách tiếp cận nào tốt hơn khi nói đến hiệu suất và sử dụng tài nguyên tối ưu: truy cập cơ sở dữ liệu nhiều lần thông qua AJAX để chỉ nhận thông tin chính xác cần thiết khi cần hoặc thực hiện một quyền truy cập để truy xuất một đối tượng chứa tất cả thông tin có thể cần thiết , với xác suất cao rằng không phải tất cả thực sự cần thiết?

Tôi biết cách đánh giá các truy vấn thực tế, nhưng tôi không biết cách kiểm tra cái gì là tốt nhất khi nói đến hiệu suất cơ sở dữ liệu khi hàng ngàn người dùng đang truy cập cơ sở dữ liệu cùng lúc và cách kết nối kết nối.

Không có một câu trả lời đúng cho điều này; Giống như bất kỳ tối ưu hóa nào, nó phụ thuộc rất nhiều vào bối cảnh / cách sử dụng.

Tuy nhiên, hãy xem xét những điều sau đây như một quy tắc chung:

x
+: Data is stable / static
-: Data is dynamic / volatile

y
+: Data is frequently used
-: Data is infrequently used

++: fetch large chunks in the fewest number of fetches 
    and persist the data as long as possible within tolerances for staleness.

+-: do what is expedient to the logic & usage; if it is convenient to 
    fetch / calc as needed do so, if it is convenient to pre-fetch and 
    persist then do so. Seek to optimize only if absolutely necessary.

-+: fetch / calc as needed; but if optimization is required consider 
    pre-fetching or pre-calculating if possible, or negotiate a tolerance 
    for less than real time accuracy to reduce volatility.

--: fetch / calc as needed and don't worry about it further unless a 
    specific case is unacceptably expensive; if so see -+.

Hãy nhớ quy tắc tối ưu hóa đầu tiên: đo lường, đừng đoán . Hãy thử cả hai, cung cấp cho họ một số loại mã đồng hồ bấm giờ và xem những gì sẽ mất nhiều thời gian hơn.

Và cũng nhớ rằng trò đùa cũ rằng "chỉ có hai vấn đề khó khăn trong khoa học máy tính: vô hiệu hóa bộ đệm và đặt tên cho mọi thứ tốt." Nếu bạn kéo mọi thứ từ DB cùng một lúc và giữ nó trong bộ nhớ, bạn có bộ đệm. Và bây giờ bạn có một vấn đề mới: bất cứ lúc nào mọi thứ thay đổi ở bất cứ đâu trong hệ thống , nó phải thực hiện cùng một thay đổi ở hai nơi: cơ sở dữ liệu và bộ đệm. Nếu bạn có nhiều máy chủ nói chuyện với DB hoặc nhiều API để làm cho máy chủ sửa đổi dữ liệu, việc này có thể trở nên rất khó khăn rất nhanh.

KHÔNG có giải pháp đạn bạc cho câu hỏi này. Tôi đoán bạn cần phải THỬ những sự đánh đổi có thể và điều chỉnh (các) máy chủ của bạn để đạt được kết quả tốt nhất.

Điểm đầu tiên: trước khi bắt đầu thực hiện bất kỳ cải tiến nào bạn cần phải thiết lập điểm chuẩn hiệu suất hiện tại của mình , đo lường nó và lấy đó làm cơ sở để so sánh các giải pháp có thể để cải thiện nó.

Điều thứ hai là, việc sử dụng ứng dụng cần phải được theo dõi. Cách thức ứng dụng được sử dụng bởi người dùng cuối. Việc cắt giảm số nguyên dữ liệu trả về không cần thiết cho người dùng cuối có thể giúp bạn tiết kiệm rất nhiều tài nguyên máy chủ quý giá . Ví dụ: không có điểm nào trả lại 5000 hồ sơ trong khi người dùng quan tâm đến 50 đầu tiên.

Điểm thứ ba: Bạn phải hiểu tần suất của các cuộc gọi và những tác động có thể xảy ra. Ví dụ: nếu hầu hết các cuộc gọi là truy vấn bảng giá trị tra cứu, thì có thể bạn sẽ tạo cơ sở hạ tầng để lưu trữ các cuộc gọi này . Nói cách khác, nếu dữ liệu của bạn không thay đổi thường xuyên, hãy xem xét tùy chọn bộ đệm. Và tất nhiên, giảm thiểu số lượng cuộc gọi luôn giúp tăng hiệu suất.

Nhận mọi thứ cùng một lúc sẽ mang lại cho bạn hiệu suất tốt hơn, trừ khi "mọi thứ" bao gồm những thứ như BLOB hoặc các đối tượng dữ liệu lớn tương tự. Chi phí hiệu năng để tuần tự hóa mọi thứ, di chuyển nó qua dây dẫn, sau đó giải tuần tự hóa nó ở đầu bên kia là khá đáng kể, với độ trễ mạng là một phần lớn của nó. Bộ nhớ rẻ hơn băng thông mạng và có thể sẽ còn tồn tại trong một thời gian nữa. Câu trả lời thực sự duy nhất của bạn sẽ đến từ điểm chuẩn, nhưng nếu bạn chỉ đang cố gắng đánh giá cái này qua cái khác, thì đó là cách tôi nghiêng.

Nếu bạn đang đưa ra quyết định kiến ​​trúc, thì REST là một lựa chọn. Với REST, bạn luôn yêu cầu tài nguyên nhiều lần, tức là bạn không gửi yêu cầu để nhận 2 đối tượng vì mỗi đối tượng có url riêng. Mối quan tâm về hiệu năng với việc thực hiện theo phong cách này có thể sẽ được giải quyết khi HTTP / 2.0 xuất hiện. Nếu không, bạn chỉ cần tối ưu hóa để làm cho nó càng nhanh càng tốt. Rất nhiều công ty đang làm theo cách này.