Hãy tận dụng tối đa hệ thống bạn đang có

• Bài viết bàn về trải nghiệm của tác giả trong việc quản lý hiệu năng Postgres trong một ứng dụng SaaS, khi cơ sở dữ liệu gặp khó khăn trong việc chịu tải.
• Nhóm của tác giả đã mở rộng theo chiều dọc bằng cách thay thế bằng các instance lớn hơn mỗi khi cơ sở dữ liệu trở nên quá bận. Tuy nhiên, họ đã dùng tới instance lớn nhất và đang tiến gần đến tình trạng quá tải.
• Hai hướng giải quyết khả dĩ được đưa ra: sharding ghi sang các cụm cơ sở dữ liệu độc lập, và tách khối nguyên khối thành nhiều dịch vụ liên kết với nhau (microservices).
• Cả hai giải pháp đều có thể tăng năng lực xử lý và mang lại những lựa chọn thú vị về khả năng chịu lỗi cũng như độ bền vững trong vận hành, nhưng sẽ làm độ phức tạp tăng lên đáng kể.
• Tác giả cho rằng chi phí thực sự của việc tăng độ phức tạp là sự chú ý, và điều đó làm mọi quyết định kỹ thuật tiếp theo trở nên phức tạp hơn.
• Tác giả gợi ý rằng trước khi làm độ phức tạp tăng mạnh, thường vẫn có cơ hội "vắt" thêm một chút hiệu năng từ hệ thống hiện có bằng cách điều chỉnh khối lượng công việc, tinh chỉnh hiệu năng, hoặc bổ sung cho hệ thống theo một cách nào đó.
• Trong trường hợp của họ, bằng cách tối ưu các truy vấn nặng, tinh chỉnh cấu hình Postgres và offload một số truy vấn chỉ đọc tốn kém sang DB replica, họ đã giảm mức sử dụng CPU đỉnh theo tuần của cơ sở dữ liệu từ 90% xuống 30%.
• Tác giả kết luận rằng độ phức tạp là cần thiết và không thể tránh khỏi, nhưng tốt hơn hết là nên trì hoãn việc gia tăng độ phức tạp càng lâu càng tốt và trước tiên khai thác tối đa hiệu năng từ hệ thống hiện có.

[GN⁺]

Ý kiến trên Hacker News

• Bài viết nhấn mạnh tầm quan trọng của việc khai thác tối đa tiềm năng của hệ thống hiện tại trước khi cân nhắc thay thế hoặc nâng cấp.
• Bài viết cho rằng các nhóm nên tận dụng những gì họ đang có, dù chưa hoàn hảo, và tìm cách đạt mục tiêu bằng các nguồn lực hiện hữu.
• Bài viết thảo luận về ý tưởng thiết kế ứng dụng để tránh dùng join trong cơ sở dữ liệu, đồng thời cho rằng dung lượng lưu trữ rẻ và mọi thứ nên được phi chuẩn hóa để cập nhật trong transaction.
• Bài viết đề xuất dùng UUID để tránh hot partition, nhờ đó có thể mở rộng theo chiều ngang thay vì phụ thuộc vào số nguyên vốn cuối cùng có thể thất bại.
• Bài viết chia sẻ một trường hợp thành công khi một nhóm cải thiện đáng kể hiệu năng hệ thống bằng cách thay đổi cách tiếp cận giải quyết vấn đề thay vì bổ sung thêm phần cứng hay độ phức tạp.
• Bài viết phản đối việc chia monolith thành nhiều dịch vụ liên kết cùng một lúc, thay vào đó đề xuất xác định phần tách nào sẽ tạo ra tác động lớn nhất.
• Bài viết nhấn mạnh tầm quan trọng của việc tối ưu truy vấn trong các ứng dụng web xây trên ORM, nơi thường vẫn còn rất nhiều dư địa để cải thiện.
• Bài viết cảnh báo về gánh nặng nhận thức và độ phức tạp khi làm việc với hệ thống microservice, cho rằng chúng thường dẫn đến downtime và hỗn loạn.
• Bài viết phân biệt giữa hiệu quả (giảm thiểu lãng phí và tránh độ phức tạp) với tối ưu hóa (dùng các thuật toán chuyên biệt với cái giá là tăng thêm độ phức tạp).
• Bài viết bày tỏ lo ngại về việc chuyển sang hạ tầng phức tạp hơn, cho rằng đó có thể không phải là lời giải vạn năng như mọi người kỳ vọng.
• Bài viết ủng hộ sự đơn giản hơn là độ phức tạp, đặc biệt khi nguồn lực hạn chế và hệ thống không quá mức tối quan trọng.
• Cuối cùng, bài viết thảo luận về sharding theo từng tenant (khách hàng) như một giải pháp tiềm năng cho các vấn đề về khả năng mở rộng.