Tổng hợp kết nối cho một ứng dụng Android kết nối với DB Postgresql

Cách thực hiện gộp kết nối

Mỗi nền tảng có một giao diện gộp kết nối khác nhau. Bạn sẽ cần đọc tài liệu về nền tảng cụ thể mà bạn sử dụng (Ruby + Rails hoặc bất cứ thứ gì) hoặc sử dụng lớp giữa tổng hợp chung như PgBouncer.

Các câu trả lời liên quan đến một công cụ (giả sử PHP với Zend Framework) sẽ không liên quan gì đến câu trả lời liên quan đến một công cụ khác (như Ruby on Rails). Ngay cả khi bạn chọn một cái gì đó như PgBouncer, vẫn có các chi tiết liên quan đến cách nền tảng xử lý thời gian giao dịch, chế độ gộp để chọn dựa trên nhu cầu của ứng dụng, v.v.

Vì vậy, trước tiên bạn cần xác định những gì bạn đang sử dụng và những gì bạn cần làm với nó. Sau đó nghiên cứu cách thiết lập tổng hợp kết nối của nó. (Với nhiều công cụ, nó chỉ tự động).

Nếu bạn vẫn gặp khó khăn sau khi đọc tài liệu về nền tảng bạn chọn , hỏi một chi tiết và cụ thể mới câu hỏi được gắn thẻ thích hợp cho nền tảng.

Tổng hợp và phần mềm trung gian

Không để ứng dụng của bạn kết nối trực tiếp với PostgreSQL. Đặc biệt nếu nó qua Internet từ các khách hàng ngẫu nhiên.

Sử dụng máy chủ web gần máy chủ PostgreSQL và để máy chủ này chấp nhận các yêu cầu dịch vụ web để môi giới truy cập vào cơ sở dữ liệu thông qua API web được xác định rõ với các giao dịch ngắn có phạm vi yêu cầu càng nhiều càng tốt.

Đây không chỉ là một trường hợp của sự khôn ngoan - có những lý do chính đáng để làm điều đó và các vấn đề nghiêm trọng khi chạy PostgreSQL từ các thiết bị ngẫu nhiên trên Internet.

Ứng dụng Android nói chuyện trực tiếp với Pg

Các vấn đề khi nói chuyện trực tiếp với Pg qua Internet từ nhiều khách hàng bao gồm:

• Mỗi chương trình phụ trợ PostgreSQL đều có chi phí, cho dù nhàn rỗi hay không. PgBouncer trong chế độ tổng hợp giao dịch giúp thực hiện điều này ở một mức độ nào đó.

• Kết nối bị mất ngẫu nhiên khi bạn đang làm việc trên Internet. WiFi giảm, thay đổi địa chỉ IP trên các dịch vụ IP động, dịch vụ di động mất dần hoặc hết dung lượng hoặc chỉ hoạt động ì ạch cùng với mất gói cao ở đó. Điều này khiến bạn có rất nhiều kết nối PostgreSQL ở trạng thái không xác định, có thể là với các giao dịch đang mở, mang lại cho bạn <IDLE> in transaction các vấn đề và nhu cầu cho phép nhiều kết nối hơn là thực sự đang hoạt động.

• Đó là giao dịch - nếu điều gì đó không hoàn thành, bạn có thể chấm dứt giao dịch và biết rằng nó sẽ không có hiệu lực.

Ưu điểm của việc có lớp giữa

Một máy chủ phản hồi các yêu cầu dịch vụ web HTTP từ ứng dụng của bạn trên thiết bị Android để hoạt động như một nhà môi giới để truy cập cơ sở dữ liệu có thể là một lợi thế lớn.

• Bạn có thể xác định một API được tạo phiên bản, vì vậy khi bạn giới thiệu các tính năng mới hoặc cần thay đổi API, bạn không cần phải phá vỡ các ứng dụng khách cũ. Điều này có thể thực hiện được với Pg bằng cách sử dụng các thủ tục được lưu trữ hoặc nhiều chế độ xem nhưng có thể trở nên khó hiểu.

• Bạn kiểm soát chặt chẽ phạm vi truy cập cơ sở dữ liệu và vòng đời giao dịch.

• Bạn có thể xác định một API Idempotent, trong đó việc chạy cùng một yêu cầu nhiều lần chỉ có tác dụng một. (Tôi thực sự khuyên bạn nên làm điều này vì điểm tiếp theo).

• Mọi thứ đều không có trạng thái và có thể có thời gian chờ ngắn. Nếu một cái gì đó không hoạt động, bạn chỉ cần thử lại nó.

• Mọi kết nối cơ sở dữ liệu đều đi qua một nhóm, vì vậy bạn không có các phiên nhàn rỗi ngồi xung quanh. Mọi chương trình phụ trợ cơ sở dữ liệu đang làm việc chăm chỉ để đạt được thông lượng tối đa.

• Bạn có thể xếp hàng đợi công việc thay vì cố gắng thực hiện hàng tấn đồng thời và làm hỏng máy chủ. (Bạn cũng có thể làm điều này với PgBouncer trong chế độ tổng hợp giao dịch).

... và chỉnh sửa lại để thay đổi ý nghĩa của câu hỏi:

Hiệu suất

Hiệu suất "Cũng" của bạn thực sự là một câu hỏi hoàn toàn khác (và tốt nhất là nên được đăng như vậy). Phiên bản rất ngắn:hoàn toàn không thể dự đoán nếu không có thêm nhiều thông tin về khối lượng công việc, như số lượng yêu cầu db trên mỗi yêu cầu ứng dụng khách, loại dữ liệu, loại truy vấn, kích thước dữ liệu, tần suất truy vấn, tính thực tế của bộ nhớ đệm, .. .... không ngừng. Bất kỳ ai tuyên bố trả lời dứt khoát câu hỏi đó đều là nhà ngoại cảm có thật đầu tiên trong lịch sử hoặc hoàn toàn hiểu rõ về nó.

Bạn cần tìm ra kích thước dữ liệu, các mẫu truy vấn, v.v. của mình sẽ như thế nào. Tìm ra bao nhiêu bạn có thể đủ khả năng để lưu vào bộ đệm ẩn lớp giữa như redis / memcached, mức độ cũ mà bạn có thể để nó nhận được, mức độ vô hiệu bộ nhớ cache bạn cần. Xác định xem tập dữ liệu "nóng" của bạn (mà bạn truy cập nhiều) có phù hợp với RAM hay không. Xác định xem các chỉ mục cho các bảng được truy vấn thường xuyên có phù hợp với RAM hay không. Tìm hiểu xem số dư đọc / ghi thô của bạn là bao nhiêu và mức độ ghi của bạn có khả năng là chỉ chèn (nối thêm) hoặc OLTP thông thường hơn (chèn / cập nhật / xóa). Giả thiết lập một tập dữ liệu và một số khối lượng công việc của khách hàng. Sau đó bạn có thể bắt đầu trả lời câu hỏi đó - có thể. Để làm đúng, bạn cũng phải mô phỏng các ứng dụng khách bị đình trệ / biến mất, v.v.

Hãy xem tại sao nó không chỉ là "Ngoài ra?".