Một Ruby gem mới có tên pg_hash_func hứa hẹn tăng tốc các truy vấn hash partition của PostgreSQL lên tới 20 lần, nhưng cộng đồng nhà phát triển đang đặt câu hỏi liệu các tuyên bố về hiệu suất có đúng trong các tình huống thực tế hay không. Gem này nhằm mục đích bỏ qua chi phí tra cứu catalog của PostgreSQL bằng cách tính toán vị trí partition trực tiếp trong mã ứng dụng.
Thiếu bằng chứng hiệu suất thực tế
Mối quan tâm lớn nhất được các nhà phát triển đưa ra tập trung vào việc thiếu các benchmark hiệu suất truy vấn thực tế. Trong khi tác giả của gem tuyên bố cải thiện tốc độ đáng kể, các benchmark chỉ đo thời gian tính toán hash, không phải thời gian thực thi truy vấn hoàn chỉnh. Các nhà phê bình chỉ ra rằng cách tiếp cận này không tính đến những gì xảy ra trong các hoạt động cơ sở dữ liệu thực tế, nơi tra cứu catalog chỉ đại diện cho một phần của toàn bộ quá trình truy vấn.
Cộng đồng đặc biệt hoài nghi vì so sánh hiệu suất chỉ hiển thị tính toán hash của Ruby so với tính toán hash của SQL, mà không chứng minh cải thiện hiệu suất truy vấn từ đầu đến cuối khi truy vấn các partition cụ thể so với việc để PostgreSQL tự động xử lý việc chọn partition.
Tuyên bố hiệu suất so với thực tế
- Cải thiện được tuyên bố: Tính toán hash nhanh hơn 20-40 lần
- Phạm vi benchmark: Chỉ thời gian tính toán hash, không phải toàn bộ quá trình thực thi truy vấn
- Dữ liệu thiếu: So sánh hiệu suất truy vấn từ đầu đến cuối
- Mối quan ngại của cộng đồng: Không cung cấp benchmark truy vấn thực tế
Rủi ro bảo trì và tương thích
Một số nhà phát triển đã nhấn mạnh cơn ác mông bảo trì tiềm tàng của việc tái triển khai các hàm hash nội bộ của PostgreSQL. Cách tiếp cận này yêu cầu đồng bộ hóa với các chi tiết triển khai nội bộ của PostgreSQL, có thể thay đổi giữa các phiên bản. Điều này tạo ra sự kết nối chặt chẽ giữa mã ứng dụng và các phiên bản PostgreSQL cụ thể mà nhiều người thấy đáng lo ngại.
điều này trông giống như cơn ác mông bảo trì trong tương lai, nhưng tôi có thể sai. Nếu bạn bị mắc kẹt với phiên bản pg cụ thể trong một thời gian, có thể nó đáng giá.
Gem hiện tại chỉ hỗ trợ phân vùng dựa trên số nguyên (bigint, integer, smallint) và thiếu hỗ trợ cho text, UUID, hoặc các kiểu dữ liệu phổ biến khác, càng hạn chế thêm khả năng ứng dụng thực tế của nó.
Những Hạn Chế Hiện Tại của Gem pg_hash_func
- Các kiểu dữ liệu được hỗ trợ: bigint (int8), integer (int4), smallint (int2)
- Các kiểu dữ liệu chưa được hỗ trợ: text/string, UUID, các kiểu dữ liệu khác
- Nền tảng: Chỉ Ruby
- Phụ thuộc phiên bản PostgreSQL: Yêu cầu đồng bộ hóa với các thay đổi triển khai nội bộ
Chiến lược tối ưu hóa đáng ngờ
Các thành viên cộng đồng cũng đang đặt câu hỏi về tiền đề cơ bản của việc tối ưu hóa. Hash partitioning thường được chọn cụ thể khi bạn không biết trước các mẫu dữ liệu, nhưng cách tiếp cận này yêu cầu kiến thức chi tiết về các khóa và cấu trúc partition. Điều này dường như mâu thuẫn với một trong những lợi thế chính của hash partitioning - phân phối dữ liệu mà không cần phân tích mẫu trước.
Giải pháp được đề xuất sử dụng các truy vấn SQL tĩnh với các hàm hash được mã hóa cứng thay vì các thủ tục catalog tích hợp của PostgreSQL đã khiến một số nhà phát triển bối rối, vì nó giới thiệu thêm độ phức tạp trong khi có thể hy sinh các tối ưu hóa tích hợp của PostgreSQL.
Kết luận
Mặc dù khái niệm tối ưu hóa các truy vấn partition của PostgreSQL có giá trị, phản hồi của cộng đồng cho thấy cần có các benchmark toàn diện hơn và thử nghiệm thực tế để xác thực các lợi ích được tuyên bố. Cách tiếp cận này có thể có giá trị cho các tình huống thông lượng cao cụ thể với các phiên bản PostgreSQL ổn định, nhưng chi phí bảo trì và phạm vi hạn chế đặt ra câu hỏi về khả năng ứng dụng rộng rãi hơn. Các nhà phát triển dường như quan tâm hơn đến việc thấy các so sánh hiệu suất truy vấn thực tế thay vì các benchmark tính toán hash riêng lẻ để đánh giá đúng kỹ thuật tối ưu hóa này.
Tham khảo: Bypass PostgreSQL catalog overhead with direct partition hash calculations