Các ngôn ngữ thủ tục của PostgreSQL trên cao (plpython / plsql / pllua Thẻ)


12

Tôi đang cố gắng tìm thông tin về các hàm do người dùng PostgreQuery xác định trong hiệu năng ngôn ngữ thủ tục cho các tác vụ thời gian thực.

  1. Làm thế nào để họ so sánh với các hàm dựng sẵn?
  2. Có sự khác biệt nào không (về chi phí hoạt động) cách Postgres gọi / quản lý các hàm plpython vs plpgsql và pllua (Tôi quan tâm đến phía tích hợp / bối cảnh / truyền dữ liệu của Postgres, chứ không phải chính VM)?
  3. Là bối cảnh một chi phí lớn? Tôi có thể sử dụng nó để ánh xạ dữ liệu thời gian thực không (giả sử 1000 truy vấn / s))
  4. Có bất kỳ lợi ích của việc viết các hàm do người dùng định nghĩa trong plpgsql sau đó là pg / ngôn ngữ khác không? Trên tài liệu họ liệt kê những lợi thế, nhưng tôi nghĩ rằng chúng áp dụng cho tất cả các ngôn ngữ thủ tục postgresql.

Những phát hiện liên quan:

Câu trả lời:


13
  1. Các UDF trong các ngôn ngữ được dịch là khá chậm luôn luôn chậm hơn các UDF được viết bằng C hoặc các hàm dựng sẵn, tất cả những thứ khác đều giống nhau.

  2. Mỗi ràng buộc ngôn ngữ có mã khác nhau để kết nối PostgreSQL với ngôn ngữ, với mức độ tối ưu hóa khác nhau, cách truyền khác nhau của một số loại dữ liệu, v.v ... Vì vậy, sự biến đổi chắc chắn tồn tại. Nó không nên lớn trừ khi bạn chuyển một loại dữ liệu được xử lý rất khác nhau bởi một ngôn ngữ khác, ví dụ một loại truyền hstoremột chuỗi như một chuỗi và một loại khác chuyển đổi nó thành một dict.

  3. Không rõ "bối cảnh" là gì. Bạn có thể sử dụng nó cho "ánh xạ dữ liệu thời gian thực" không ... tùy thuộc vào chức năng làm gì và nó có đủ nhanh trên máy chủ mà nó đang chạy hay không, cho các máy khách đang sử dụng và cho các yêu cầu của bạn. Bao lâu là một mảnh của chuỗi? Điểm chuẩn.

  4. PL / PGQuery đơn giản hơn để viết và cung cấp quyền truy cập nhanh hơn vào SQL. Nói chung là tốt hơn khi bạn cần bao bọc một chút logic xung quanh rất nhiều SQL. Nó rất chậm đối với các hoạt động toán học và các thuật toán phức tạp, do đó, nên sử dụng mã tính toán thuần túy trong PL / PGQuery bất cứ khi nào có thể có lợi cho C hoặc ngôn ngữ thủ tục nhanh hơn.

Tăng tốc khi triển khai lại mã PL / PGQuery trong C có thể thay đổi từ không đáng kể đến hơn 1000 lần. Tất cả phụ thuộc vào những gì mã thực sự đang làm.

(Loại câu hỏi đa dạng này không phù hợp với Stack Exchange vì khó có câu trả lời dứt khoát hơn)


Theo ngữ cảnh, ý tôi là tất cả dữ liệu cần được chuyển qua lại vào môi trường thủ tục
Robert Zaremba

4

Điều này khá khó để nói. nó thực sự phụ thuộc vào những gì bạn đang làm. ví dụ: PL / pgSQL thật tuyệt vời nếu bạn có các câu lệnh SQL lớn trong đó - nó thực sự phát điên nếu bạn có tất cả các loại phân nhánh, quản lý chuỗi con và tất cả những thứ đó.

bạn thực sự phải kiểm tra từng trường hợp.


4

Là bối cảnh một chi phí lớn? Tôi có thể sử dụng nó để ánh xạ dữ liệu thời gian thực không (giả sử 1000 truy vấn / s))

Hiệu suất phụ thuộc vào phần cứng và độ phức tạp của các chức năng của bạn. Tôi đã tạo một thiết bị chạy trên máy chủ 12 lõi nhỏ và thẻ FusionIO (tổng chi phí 10000 euro) và thực hiện khoảng 2500 giao dịch mỗi giây với 20 người dùng đồng thời. Mỗi giao dịch gọi 29 thủ tục được lưu trữ để xử lý dữ liệu và trả lại một số thông tin hữu ích cho khách hàng. Một số hàm thực thi chỉ một truy vấn, một số khác là một vài truy vấn. Tổng cộng, nó thực thi khoảng 200000 câu lệnh INSERT, SELECT và UPDATE mỗi giây.

Tất cả được viết bằng PL / SQL, PL / pgSQL và PL / PerlU. Và tôi khá chắc chắn rằng hệ thống có thể chạy nhanh hơn nữa khi (một số) chức năng được viết lại trong C.

Trong thiết bị này, hầu hết hiệu suất đến từ thẻ SSD. Trên một đĩa quay duy nhất, chúng tôi sẽ không bao giờ có được hiệu suất này. Ổ SSD giá rẻ cũng bị lỗi, nó hoạt động trong một giờ (do bộ nhớ đệm của thẻ đột kích) và sau đó trò chơi kết thúc. Thẻ FusionIO đắt tiền, nhưng là một khoản đầu tư rất tốt khi bạn bị ràng buộc IO.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.