Tổng hợp kết nối PostgreSQL:Phần 1 - Ưu và nhược điểm

Cách đây rất lâu, trong một thiên hà xa xôi, ‘luồng’ là một tính năng lập trình mới lạ hiếm khi được sử dụng và hiếm khi được tin cậy. Trong môi trường đó, các nhà phát triển PostgreSQL đầu tiên đã quyết định tạo một quy trình cho mỗi kết nối đến cơ sở dữ liệu là lựa chọn an toàn nhất. Sẽ thật tiếc nếu cơ sở dữ liệu của bạn bị sập.

Kể từ đó, rất nhiều nước đã trôi xuống dưới cây cầu đó, nhưng cộng đồng PostgreSQL đã bế tắc bởi quyết định ban đầu của họ. Rất khó để làm sai lập luận của họ - vì điều đó hoàn toàn đúng:

• Mỗi ứng dụng có quy trình riêng để ngăn một ứng dụng hoạt động kém làm hỏng toàn bộ cơ sở dữ liệu.
• Trên các hệ thống Linux hiện đại, sự khác biệt về chi phí giữa việc tạo một quy trình và tạo một luồng ít hơn nhiều so với trước đây.
• Chuyển sang kiến ​​trúc đa luồng sẽ yêu cầu viết lại nhiều.

Tuy nhiên, trong các ứng dụng web hiện đại, máy khách có xu hướng mở nhiều kết nối. Các nhà phát triển thường không được khuyến khích duy trì kết nối cơ sở dữ liệu trong khi các hoạt động khác diễn ra. “Mở kết nối càng muộn càng tốt, đóng kết nối càng sớm càng tốt”. Nhưng điều đó gây ra vấn đề với kiến ​​trúc của PostgreSQL - việc tạo ra một quy trình trở nên đắt đỏ khi các giao dịch diễn ra rất ngắn, như sự khôn ngoan thông thường cho rằng chúng phải như vậy.

Kiến trúc Bể bơi Kết nối

Sử dụng thư viện ngôn ngữ hiện đại sẽ giảm bớt phần nào vấn đề - gộp kết nối là một tính năng thiết yếu của hầu hết các thư viện truy cập cơ sở dữ liệu phổ biến. Nó đảm bảo các kết nối "đã đóng" không thực sự bị đóng, mà được trả về một nhóm và việc "mở" một kết nối mới sẽ trả lại cùng một "kết nối vật lý", giảm bớt sự phân nhánh thực tế ở phía PostgreSQL.

Tuy nhiên, các ứng dụng web hiện đại hiếm khi nguyên khối và thường sử dụng nhiều ngôn ngữ và công nghệ. Sử dụng nhóm kết nối trong mỗi mô-đun hầu như không hiệu quả:

• Ngay cả với số lượng mô-đun tương đối nhỏ và kích thước nhóm nhỏ trong mỗi mô-đun, bạn vẫn phải thực hiện rất nhiều quy trình máy chủ. Việc chuyển đổi ngữ cảnh giữa chúng rất tốn kém.
• Hỗ trợ gộp rất khác nhau giữa các thư viện và ngôn ngữ - một nhóm hoạt động kém có thể tiêu thụ tất cả tài nguyên và khiến các mô-đun khác không thể truy cập được cơ sở dữ liệu.
• Không có kiểm soát tập trung - bạn không thể sử dụng các biện pháp như giới hạn truy cập dành riêng cho máy khách.

Do đó, các phần mềm trung gian phổ biến đã được phát triển cho PostgreSQL. Chúng nằm giữa cơ sở dữ liệu và các máy khách, đôi khi trên một máy chủ riêng biệt (vật lý hoặc ảo) và đôi khi trên cùng một hộp và tạo ra một nhóm mà máy khách có thể kết nối. Các phần mềm trung gian này là:

• Được tối ưu hóa cho PostgreSQL và kiến ​​trúc khá độc đáo của nó giữa các DBMS hiện đại.
• Cung cấp khả năng kiểm soát truy cập tập trung cho các khách hàng đa dạng.
• Cho phép bạn gặt hái được những phần thưởng tương tự như nhóm phía khách hàng và hơn thế nữa (chúng ta sẽ thảo luận chi tiết hơn về những điều này trong các bài viết tiếp theo)!

Nhược điểm của PostgreSQL Connection Pooler

Bộ gộp kết nối là một phần gần như không thể thiếu trong thiết lập PostgreSQL sẵn sàng cho sản xuất. Mặc dù có rất nhiều lợi ích được ghi nhận rõ ràng khi sử dụng trình gộp kết nối, nhưng có một số đối số được đưa ra để chống lại việc sử dụng một:

• Giới thiệu phần mềm trung gian trong giao tiếp chắc chắn sẽ dẫn đến một số độ trễ. Tuy nhiên, khi được đặt trên cùng một máy chủ và bao gồm chi phí của việc phân chia kết nối, điều này trên thực tế là không đáng kể như chúng ta sẽ thấy trong phần tiếp theo.
• Phần mềm trung gian trở thành một điểm lỗi duy nhất. Sử dụng một cụm ở cấp độ này có thể giải quyết vấn đề này, nhưng điều đó làm tăng thêm độ phức tạp cho kiến ​​trúc.

  

• Phần mềm trung gian ngụ ý chi phí bổ sung. Bạn cần một (hoặc 3) máy chủ bổ sung hoặc (các) máy chủ cơ sở dữ liệu của bạn phải có đủ tài nguyên để hỗ trợ một trình gộp kết nối, ngoài PostgreSQL.
• Chia sẻ kết nối giữa các mô-đun khác nhau có thể trở thành một lỗ hổng bảo mật. Điều rất quan trọng là chúng tôi phải định cấu hình pgPool hoặc PgBouncer để làm sạch các kết nối trước khi chúng được đưa trở lại nhóm.
• Xác thực chuyển từ DBMS sang bộ kết nối. Điều này có thể không phải lúc nào cũng được chấp nhận.

  

• Nó làm tăng diện tích bề mặt để tấn công, trừ khi quyền truy cập vào cơ sở dữ liệu bên dưới bị khóa để chỉ cho phép truy cập thông qua bộ kết nối.
• Nó tạo ra một thành phần khác phải được duy trì, tinh chỉnh cho phù hợp với khối lượng công việc của bạn, thường xuyên vá lỗi bảo mật và nâng cấp theo yêu cầu.

Bạn có nên sử dụng Trình tổng hợp kết nối PostgreSQL không?

Tuy nhiên, tất cả những vấn đề này đều được thảo luận kỹ lưỡng trong cộng đồng PostgreSQL và các chiến lược giảm thiểu đảm bảo ưu điểm của trình gộp kết nối vượt xa nhược điểm của chúng. Các thử nghiệm của chúng tôi cho thấy rằng ngay cả một số lượng nhỏ khách hàng cũng có thể được hưởng lợi đáng kể từ việc sử dụng trình gộp kết nối. Chúng rất xứng đáng với cấu hình bổ sung và nỗ lực bảo trì.

Trong bài đăng tiếp theo, chúng ta sẽ thảo luận về một trong những trình đánh cắp kết nối phổ biến nhất trong thế giới PostgreSQL - PgBouncer, tiếp theo là Pgpool-II và cuối cùng là so sánh kiểm tra hiệu suất của hai trình này Bộ xử lý kết nối PostgreSQL trong bài đăng cuối cùng của loạt bài này.