Thứ năm, 14/02/2019 | 00:00 GMT+7

Công cụ kết nối dịch vụ database và đo điểm chuẩn PostgreSQL bằng pgbench

Dịch vụdatabase DigitalOcean cho phép bạn mở rộng database PostgreSQL của bạn bằng một số phương pháp. Một trong những phương pháp như vậy là bộ gộp kết nối tích hợp cho phép bạn xử lý hiệu quả số lượng lớn các kết nối client và giảm dung lượng bộ nhớ và CPU của các kết nối mở này. Bằng cách sử dụng group kết nối và chia sẻ một tập hợp cố định các kết nối có thể tái chế, bạn có thể xử lý nhiều kết nối client đồng thời hơn đáng kể và tăng hiệu suất từ database PostgreSQL của bạn.

Trong hướng dẫn này, ta sẽ sử dụng pgbench , công cụ đo điểm chuẩn được tích hợp sẵn của PostgreSQL, để chạy thử nghiệm tải trên Database PostgreSQL được quản lý bởi DigitalOcean. Ta sẽ đi sâu vào các group kết nối, mô tả cách chúng hoạt động và hướng dẫn cách tạo một group bằng cách sử dụng Control panel cloud . Cuối cùng, sử dụng kết quả từ các bài kiểm tra pgbench , ta sẽ chứng minh cách sử dụng group kết nối có thể là một phương pháp không tốn kém để tăng thông lượng database .

Yêu cầu

Để hoàn thành hướng dẫn này, bạn cần :

  • Một cụm database PostgreSQL được quản lý DigitalOcean. Để tìm hiểu cách cung cấp và cấu hình một cụm DigitalOcean PostgreSQL, hãy tham khảo tài liệu sản phẩm Dịch vụdatabase.
  • Máy khách có cài đặt PostgreSQL. Theo mặc định, cài đặt PostgreSQL của bạn sẽ chứa tiện ích đo điểm chuẩn pgbench và ứng dụng client psql , cả hai đều mà ta sẽ sử dụng trong hướng dẫn này. Tham khảo Cách cài đặt và sử dụng PostgreSQL trên Ubuntu 18.04 để tìm hiểu cách cài đặt PostgreSQL. Nếu bạn không chạy Ubuntu trên client của bạn , bạn có thể sử dụng công cụ tìm version để tìm hướng dẫn thích hợp.

Khi bạn đã cài đặt và chạy một cụm DigitalOcean PostgreSQL và một client có cài đặt pgbench , bạn đã sẵn sàng để bắt đầu với hướng dẫn này.

Bước 1 - Tạo và khởi tạo database benchmark

Trước khi ta tạo một group kết nối cho database của bạn , trước tiên ta sẽ tạo database benchmark trên cụm PostgreSQL của ta và điền vào nó một số dữ liệu giả mà pgbench sẽ chạy thử nghiệm của nó. Tiện ích pgbench liên tục chạy một loạt năm lệnh SQL (bao gồm các SELECT , UPDATEINSERT ) trong một giao dịch, sử dụng nhiều stream và client , đồng thời tính toán một số liệu hiệu suất hữu ích được gọi là T ransactions p er S econd (TPS). TPS là thước đo thông lượng database , đếm số lượng giao dịch nguyên tử được database xử lý trong một giây. Để tìm hiểu thêm về các lệnh cụ thể được thực thi bởi pgbench , hãy tham khảo "Giao dịch" Thực sự được Thực hiện trong pgbench là gì? từ tài liệu pgbench chính thức.

Hãy bắt đầu bằng cách kết nối với cụm PostgreSQL của ta và tạo database benchmark .

Đầu tiên, truy xuất Chi tiết kết nối của cụm của bạn bằng cách chuyển đến Database và định vị cụm PostgreSQL của bạn. Nhấp vào cụm của bạn. Bạn sẽ thấy trang tổng quan về cụm có hộp Chi tiết kết nối sau:

Chi tiết kết nối cụm PostgreSQL

Từ đó, ta có thể phân tích cú pháp các biến cấu hình sau:

  • Admin-user : doadmin
  • Mật khẩu administrator : your_password
  • Điểm cuối cụm: dbaas-test-do-user-3587522-0.db.ondigitalocean.com
  • Cổng kết nối: 25060
  • Database để kết nối với: defaultdb
  • Chế độ SSL: require (sử dụng kết nối được mã hóa SSL để tăng cường bảo mật)

Hãy lưu ý những thông số này, vì bạn cần chúng khi sử dụng cả công cụ psql client và pgbench .

Nhấp vào menu thả xuống phía trên hộp này và chọn Chuỗi kết nối . Ta sẽ sao chép chuỗi này và chuyển nó vào psql để kết nối với nút PostgreSQL này.

Kết nối với cụm của bạn bằng psql và chuỗi kết nối bạn vừa sao chép:

  • psql postgresql://doadmin:your_password@your_cluster_endpoint:25060/defaultdb?sslmode=require

Bạn sẽ thấy dấu nhắc client PostgreSQL sau, cho biết rằng bạn đã kết nối thành công với cụm PostgreSQL của bạn :

Output
psql (10.6 (Ubuntu 10.6-0ubuntu0.18.04.1)) SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off) Type "help" for help. defaultdb=>

Từ đây, tạo database benchmark :

  • CREATE DATABASE benchmark;

Bạn sẽ thấy kết quả sau:

Output
CREATE DATABASE

Bây giờ, ngắt kết nối khỏi cụm:

  • \q

Trước khi chạy các bài kiểm tra pgbench , ta cần điền vào database benchmark này với một số bảng và dữ liệu giả cần thiết để chạy các bài kiểm tra.

Để làm điều này, ta sẽ chạy pgbench với các cờ sau:

  • -h : Điểm cuối của cụm PostgreSQL
  • -p : Cổng kết nối cụm PostgreSQL
  • -U : Tên user database
  • -i : Cho biết ta muốn khởi tạo benchmark database với các bảng điểm chuẩn và dữ liệu giả của họ.
  • -s : Đặt hệ số tỷ lệ là 150, hệ số này sẽ nhân kích thước bảng với 150. Hệ số tỷ lệ mặc định là 1 dẫn đến các bảng có kích thước sau:

    table                   # of rows --------------------------------- pgbench_branches        1 pgbench_tellers         10 pgbench_accounts        100000 pgbench_history         0 

    Sử dụng hệ số tỷ lệ 150, bảng pgbench_accounts sẽ chứa 15.000.000 hàng.

    Lưu ý: Để tránh các giao dịch bị chặn quá nhiều, hãy đảm bảo đặt hệ số quy mô thành giá trị ít nhất là lớn bằng số lượng khách hàng đồng thời mà bạn định thử nghiệm. Trong hướng dẫn này, ta sẽ kiểm tra tối đa 150 khách hàng, vì vậy ta đặt -s thành 150 ở đây. Để tìm hiểu thêm, hãy tham khảo các phương pháp được đề xuất này từ tài liệu pgbench chính thức.

Chạy lệnh pgbench hoàn chỉnh:

  • pgbench -h your_cluster_endpoint -p 25060 -U doadmin -i -s 150 benchmark

Sau khi chạy lệnh này, bạn sẽ được yêu cầu nhập password cho user database mà bạn đã chỉ định. Nhập password và nhấn ENTER .

Bạn sẽ thấy kết quả sau:

Output
dropping old tables... NOTICE: table "pgbench_accounts" does not exist, skipping NOTICE: table "pgbench_branches" does not exist, skipping NOTICE: table "pgbench_history" does not exist, skipping NOTICE: table "pgbench_tellers" does not exist, skipping creating tables... generating data... 100000 of 15000000 tuples (0%) done (elapsed 0.19 s, remaining 27.93 s) 200000 of 15000000 tuples (1%) done (elapsed 0.85 s, remaining 62.62 s) 300000 of 15000000 tuples (2%) done (elapsed 1.21 s, remaining 59.23 s) 400000 of 15000000 tuples (2%) done (elapsed 1.63 s, remaining 59.44 s) 500000 of 15000000 tuples (3%) done (elapsed 2.05 s, remaining 59.51 s) . . . 14700000 of 15000000 tuples (98%) done (elapsed 70.87 s, remaining 1.45 s) 14800000 of 15000000 tuples (98%) done (elapsed 71.39 s, remaining 0.96 s) 14900000 of 15000000 tuples (99%) done (elapsed 71.91 s, remaining 0.48 s) 15000000 of 15000000 tuples (100%) done (elapsed 72.42 s, remaining 0.00 s) vacuuming... creating primary keys... done.

Đến đây, ta đã tạo một database đo điểm chuẩn, chứa các bảng và dữ liệu cần thiết để chạy các bài kiểm tra pgbench . Bây giờ ta có thể chuyển sang chạy thử nghiệm cơ bản mà ta sẽ sử dụng để so sánh hiệu suất trước và sau khi bật tính năng tổng hợp kết nối.

Bước 2 - Chạy Kiểm tra pgbench cơ sở

Trước khi ta chạy điểm chuẩn đầu tiên của bạn , bạn nên đi sâu vào những gì ta đang cố gắng tối ưu hóa với các group kết nối.

Thông thường, khi một client kết nối với database PostgreSQL, quy trình chính của Hệ điều hành PostgreSQL tự phân tách thành một quy trình con tương ứng với kết nối mới này. Khi chỉ có một vài kết nối, điều này hiếm khi gây ra sự cố. Tuy nhiên, khi client và kết nối mở rộng quy mô, chi phí CPU và bộ nhớ trong việc tạo và duy trì các kết nối này bắt đầu tăng lên, đặc biệt nếu ứng dụng được đề cập không sử dụng hiệu quả các kết nối database . Ngoài ra, cài đặt max_connections PostgreSQL có thể giới hạn số lượng kết nối client được phép, dẫn đến các kết nối bổ sung bị từ chối hoặc bị loại bỏ.

Kết nối database  mà không cần gộp

Một group kết nối luôn mở một số lượng cố định các kết nối database , kích thước group , sau đó nó sẽ sử dụng để phân phối và thực hiện các yêu cầu của khách hàng. Điều này nghĩa là bạn có thể cung cấp nhiều kết nối đồng thời hơn, giải quyết hiệu quả các ứng dụng client nhàn rỗi hoặc trì trệ, cũng như xếp hàng các yêu cầu của khách hàng khi lưu lượng truy cập tăng đột biến thay vì từ chối chúng. Bằng cách tái chế các kết nối, bạn có thể sử dụng hiệu quả hơn các tài nguyên của máy trong môi trường có dung lượng kết nối lớn và giảm hiệu suất bổ sung ra khỏi database của bạn.

Kết nối database  với gộp

Một group kết nối có thể được triển khai ở phía ứng dụng hoặc dưới dạng phần mềm trung gian giữa database và ứng dụng của bạn. Bộ gộp kết nối Dịch vụdatabase được xây dựng dựa trên pgBouncer , một bộ gộp kết nối phần mềm trung gian open-souce nhẹ cho PostgreSQL. Giao diện của nó có sẵn thông qua giao diện user Cloud Control Panel.

Điều hướng đến Database trong Control panel , sau đó nhấp vào cụm PostgreSQL của bạn. Từ đây, nhấp vào Bể bơi kết nối . Sau đó, nhấp vào Tạo group kết nối . Bạn sẽ thấy cửa sổ cấu hình sau:

Cửa sổ cấu hình hồ bơi kết nối

Tại đây, bạn có thể cấu hình các trường sau:

  • Tên group : Tên duy nhất cho group kết nối của bạn
  • Database : Database mà bạn muốn gộp các kết nối
  • User : User PostgreSQL group kết nối sẽ xác thực là
  • Chế độ : Một trong các Phiên , Giao dịch hoặc Tuyên bố . Tùy chọn này kiểm soát thời gian group chỉ định kết nối backend cho một client .
    • Phiên : Máy khách giữ kết nối cho đến khi nó ngắt kết nối rõ ràng.
    • Giao dịch : Khách hàng có được kết nối cho đến khi nó hoàn thành một giao dịch, sau đó kết nối được trả lại cho group .
    • Câu lệnh : Pool tái chế tích cực các kết nối sau mỗi câu lệnh của client . Trong chế độ sao kê, không cho phép các giao dịch nhiều sao kê. Để tìm hiểu thêm, hãy tham khảo tài liệu sản phẩm Bể bơi kết nối.
  • Pool Size : Số lượng kết nối mà group kết nối sẽ mở giữa chính nó và database .

Trước khi tạo group kết nối, ta sẽ chạy thử nghiệm cơ bản mà ta có thể so sánh hiệu suất database với group kết nối.

Trong hướng dẫn này, ta sẽ sử dụng RAM 4 GB, 2 vCPU, Đĩa 80 GB, chỉ nút chính cài đặt Dịch vụdatabase.Bạn có thể chia tỷ lệ các thông số kiểm tra điểm chuẩn trong phần này theo thông số kỹ thuật cụm PostgreSQL của bạn.

Các cụm Dịch vụdatabase DigitalOcean có thông số PostgreSQL max_connections đặt trước cho 25 kết nối trên 1 GB RAM. Do đó, một nút PostgreSQL RAM 4 GB có max_connections được đặt thành 100. Ngoài ra, đối với tất cả các cụm, 3 kết nối được dành riêng để bảo trì. Vì vậy, đối với cụm PostgreSQL 4 GB RAM này, 97 kết nối có sẵn để tổng hợp kết nối.

Với ý nghĩ này, hãy chạy thử nghiệm pgbench cơ bản đầu tiên của ta .

Đăng nhập vào client của bạn. Ta sẽ chạy pgbench , chỉ định điểm cuối database , cổng và user như bình thường. Ngoài ra, ta sẽ cung cấp các cờ sau:

  • -c : Số lượng client đồng thời hoặc phiên database để mô phỏng. Ta đặt giá trị này thành 50 để mô phỏng một số kết nối đồng thời nhỏ hơn tham số max_connections cho cụm PostgreSQL của ta .
  • -j : Số stream công nhân mà pgbench sẽ sử dụng để chạy điểm chuẩn. Nếu bạn đang sử dụng máy nhiều CPU, bạn có thể điều chỉnh điều này trở lên để phân phối client trên các stream . Trên máy hai lõi, ta đặt giá trị này thành 2 .
  • -P : Hiển thị tiến trình và số liệu sau mỗi 60 giây.
  • -T : Chạy điểm chuẩn trong 600 giây (10 phút). Để tạo ra kết quả nhất quán, có thể lặp lại, điều quan trọng là bạn phải chạy điểm chuẩn trong vài phút hoặc qua một chu kỳ điểm kiểm tra.

Ta cũng sẽ chỉ định rằng ta muốn chạy điểm chuẩn dựa trên database benchmark mà ta đã tạo và điền trước đó.

Chạy lệnh pgbench hoàn chỉnh sau:

  • pgbench -h your_db_endpoint -p 25060 -U doadmin -c 50 -j 2 -P 60 -T 600 benchmark

Nhấn ENTER rồi nhập password cho user doadmin để bắt đầu chạy thử nghiệm. Bạn sẽ thấy kết quả tương tự như sau (kết quả sẽ phụ thuộc vào thông số kỹ thuật của cụm PostgreSQL của bạn):

Output
starting vacuum...end. progress: 60.0 s, 157.4 tps, lat 282.988 ms stddev 40.261 progress: 120.0 s, 176.2 tps, lat 283.726 ms stddev 38.722 progress: 180.0 s, 167.4 tps, lat 298.663 ms stddev 238.124 progress: 240.0 s, 178.9 tps, lat 279.564 ms stddev 43.619 progress: 300.0 s, 178.5 tps, lat 280.016 ms stddev 43.235 progress: 360.0 s, 178.8 tps, lat 279.737 ms stddev 43.307 progress: 420.0 s, 179.3 tps, lat 278.837 ms stddev 43.783 progress: 480.0 s, 178.5 tps, lat 280.203 ms stddev 43.921 progress: 540.0 s, 180.0 tps, lat 277.816 ms stddev 43.742 progress: 600.0 s, 178.5 tps, lat 280.044 ms stddev 43.705 transaction type: <builtin: TPC-B (sort of)> scaling factor: 150 query mode: simple number of clients: 50 number of threads: 2 duration: 600 s number of transactions actually processed: 105256 latency average = 282.039 ms latency stddev = 84.244 ms tps = 175.329321 (including connections establishing) tps = 175.404174 (excluding connections establishing)

Ở đây, ta quan sát thấy rằng trong 10 phút chạy với 50 phiên đồng thời, ta đã xử lý 105.256 giao dịch với thông lượng khoảng 175 giao dịch mỗi giây.

Bây giờ, hãy chạy thử nghiệm tương tự, lần này sử dụng 150 client đồng thời, một giá trị cao hơn max_connections cho database này, để mô phỏng tổng hợp một loạt các kết nối client :

  • pgbench -h your_db_endpoint -p 25060 -U doadmin -c 150 -j 2 -P 60 -T 600 benchmark

Bạn sẽ thấy kết quả tương tự như sau:

Output
starting vacuum...end. connection to database "pgbench" failed: FATAL: remaining connection slots are reserved for non-replication superuser connections progress: 60.0 s, 182.6 tps, lat 280.069 ms stddev 42.009 progress: 120.0 s, 253.8 tps, lat 295.612 ms stddev 237.448 progress: 180.0 s, 271.3 tps, lat 276.411 ms stddev 40.643 progress: 240.0 s, 273.0 tps, lat 274.653 ms stddev 40.942 progress: 300.0 s, 272.8 tps, lat 274.977 ms stddev 41.660 progress: 360.0 s, 250.0 tps, lat 300.033 ms stddev 282.712 progress: 420.0 s, 272.1 tps, lat 275.614 ms stddev 42.901 progress: 480.0 s, 261.1 tps, lat 287.226 ms stddev 112.499 progress: 540.0 s, 272.5 tps, lat 275.309 ms stddev 41.740 progress: 600.0 s, 271.2 tps, lat 276.585 ms stddev 41.221 transaction type: <builtin: TPC-B (sort of)> scaling factor: 150 query mode: simple number of clients: 150 number of threads: 2 duration: 600 s number of transactions actually processed: 154892 latency average = 281.421 ms latency stddev = 125.929 ms tps = 257.994941 (including connections establishing) tps = 258.049251 (excluding connections establishing)

Lưu ý lỗi FATAL , cho biết rằng pgbench đạt đến ngưỡng giới hạn kết nối 100 do max_connections , dẫn đến kết nối bị từ chối. Thử nghiệm vẫn có thể hoàn thành, với TPS khoảng 257.

Đến đây, ta có thể điều tra cách một group kết nối có thể cải thiện thông lượng database của ta .

Bước 3 - Tạo và kiểm tra group kết nối

Trong bước này, ta sẽ tạo một group kết nối và chạy lại kiểm tra pgbench trước đó để xem liệu ta có thể cải thiện thông lượng database của bạn hay không.

Nói chung, cài đặt max_connections và tham số group kết nối được điều chỉnh song song để tối đa hóa tải của database . Tuy nhiên, vì max_connections được trừu tượng hóa khỏi user trong Dịch vụdatabase DigitalOcean, đòn bẩy chính của ta ở đây là cài đặt Kích thướcChế độ group kết nối.

Để bắt đầu, hãy tạo một group kết nối trong chế độ Giao dịch để mở tất cả các kết nối backend có sẵn.

Điều hướng đến Database trong Control panel , sau đó nhấp vào cụm PostgreSQL của bạn. Từ đây, nhấp vào Bể bơi kết nối . Sau đó, nhấp vào Tạo group kết nối .

Trong cửa sổ cấu hình xuất hiện, hãy điền vào các giá trị sau:

Giá trị cấu hình  group  kết nối

Ở đây ta đặt tên cho group kiểm tra group kết nối của ta và sử dụng nó với database điểm chuẩn . User database của ta là doadmin và ta đặt group kết nối thành chế độ Giao dịch . Nhớ lại trước đó rằng đối với một cụm database được quản lý với 4GB RAM, có 97 kết nối database khả dụng. Theo đó, hãy cấu hình pool để giữ 97 kết nối database mở.

Khi bạn hoàn tất, hãy nhấn Create Pool .

Đến đây bạn sẽ thấy group này trong Control panel :

 Group  kết nối trong console

Lấy URI của nó bằng cách nhấp vào Chi tiết kết nối . Nó trông giống như sau

postgres://doadmin:password@pool_endpoint:pool_port/test-pool?sslmode=require 

Bạn sẽ thấy một cổng khác ở đây và có khả năng là một điểm cuối và tên database khác, tương ứng với group test-pool tên test-pool .

Bây giờ ta đã tạo group kết nối test-pool pool, ta có thể chạy lại kiểm tra pgbench mà ta đã chạy ở trên.

Chạy lại pgbench

Từ client của bạn, hãy chạy lệnh pgbench sau (với 150 client đồng thời), đảm bảo thay thế các giá trị được đánh dấu bằng các giá trị trong URI group kết nối của bạn:

  • pgbench -h pool_endpoint -p pool_port -U doadmin -c 150 -j 2 -P 60 -T 600 test-pool

Ở đây, ta sử dụng 150 client đồng thời, chạy thử nghiệm trên 2 stream , tiến trình in cứ sau 60 giây và chạy thử nghiệm trong 600 giây. Ta đặt tên database thành test-pool , tên của group kết nối.

Khi quá trình kiểm tra hoàn tất, bạn sẽ thấy kết quả giống như sau ( lưu ý các kết quả này sẽ khác nhau tùy thuộc vào thông số kỹ thuật của nút database của bạn):

Output
starting vacuum...end. progress: 60.0 s, 240.0 tps, lat 425.251 ms stddev 59.773 progress: 120.0 s, 350.0 tps, lat 428.647 ms stddev 57.084 progress: 180.0 s, 340.3 tps, lat 440.680 ms stddev 313.631 progress: 240.0 s, 364.9 tps, lat 411.083 ms stddev 61.106 progress: 300.0 s, 366.5 tps, lat 409.367 ms stddev 60.165 progress: 360.0 s, 362.5 tps, lat 413.750 ms stddev 59.005 progress: 420.0 s, 359.5 tps, lat 417.292 ms stddev 60.395 progress: 480.0 s, 363.8 tps, lat 412.130 ms stddev 60.361 progress: 540.0 s, 351.6 tps, lat 426.661 ms stddev 62.960 progress: 600.0 s, 344.5 tps, lat 435.516 ms stddev 65.182 transaction type: <builtin: TPC-B (sort of)> scaling factor: 150 query mode: simple number of clients: 150 number of threads: 2 duration: 600 s number of transactions actually processed: 206768 latency average = 421.719 ms latency stddev = 114.676 ms tps = 344.240797 (including connections establishing) tps = 344.385646 (excluding connections establishing)

Lưu ý ở đây rằng ta có thể tăng thông lượng database của bạn từ 257 TPS lên 344 TPS với 150 kết nối đồng thời (tăng 33%) và không vượt quá giới hạn max_connections mà ta đã đạt trước đó mà không có group kết nối. Bằng cách đặt một group kết nối trước database , ta có thể tránh kết nối bị rớt và tăng đáng kể thông lượng database trong môi trường có số lượng lớn các kết nối đồng thời.

Nếu bạn chạy cùng một thử nghiệm này, nhưng với giá trị -c là 50 (chỉ định một số lượng khách hàng nhỏ hơn), lợi ích từ việc sử dụng group kết nối trở nên ít rõ ràng hơn nhiều:

Output
starting vacuum...end. progress: 60.0 s, 154.0 tps, lat 290.592 ms stddev 35.530 progress: 120.0 s, 162.7 tps, lat 307.168 ms stddev 241.003 progress: 180.0 s, 172.0 tps, lat 290.678 ms stddev 36.225 progress: 240.0 s, 172.4 tps, lat 290.169 ms stddev 37.603 progress: 300.0 s, 177.8 tps, lat 281.214 ms stddev 35.365 progress: 360.0 s, 177.7 tps, lat 281.402 ms stddev 35.227 progress: 420.0 s, 174.5 tps, lat 286.404 ms stddev 34.797 progress: 480.0 s, 176.1 tps, lat 284.107 ms stddev 36.540 progress: 540.0 s, 173.1 tps, lat 288.771 ms stddev 38.059 progress: 600.0 s, 174.5 tps, lat 286.508 ms stddev 59.941 transaction type: <builtin: TPC-B (sort of)> scaling factor: 150 query mode: simple number of clients: 50 number of threads: 2 duration: 600 s number of transactions actually processed: 102938 latency average = 288.509 ms latency stddev = 83.503 ms tps = 171.482966 (including connections establishing) tps = 171.553434 (excluding connections establishing)

Ở đây, ta thấy rằng ta không thể tăng thông lượng bằng cách sử dụng group kết nối. Thông lượng của ta đã giảm xuống 171 TPS từ 175 TPS.

Mặc dù trong hướng dẫn này, ta sử dụng pgbench với bộ dữ liệu điểm chuẩn tích hợp của nó, nhưng bài kiểm tra tốt nhất để xác định có sử dụng group kết nối hay không là tải điểm chuẩn thể hiện chính xác tải production trên database của bạn, so với dữ liệu production . Việc tạo tập lệnh và dữ liệu đo điểm chuẩn tùy chỉnh nằm ngoài phạm vi của hướng dẫn này, nhưng để tìm hiểu thêm, hãy tham khảo tài liệu pgbench chính thức.

Lưu ý: Cài đặt kích thước group rất cụ thể về dung lượng công việc. Trong hướng dẫn này, ta đã cấu hình group kết nối để sử dụng tất cả các kết nối database backend có sẵn. Điều này là do trong suốt điểm chuẩn của ta , database hiếm khi đạt được mức sử dụng đầy đủ (bạn có thể theo dõi tải database từ tab Số liệu trong Control panel cloud ). Tùy thuộc vào tải database của bạn, đây có thể không phải là cài đặt tối ưu. Nếu bạn nhận thấy rằng database của bạn liên tục bão hòa hoàn toàn, việc thu nhỏ group kết nối có thể tăng thông lượng và cải thiện hiệu suất bằng cách xếp hàng các yêu cầu bổ sung thay vì cố gắng thực thi tất cả chúng cùng một lúc trên một server đã được tải.

Kết luận

Tổng hợp kết nối Dịch vụdatabase DigitalOcean là một tính năng mạnh mẽ có thể giúp bạn nhanh chóng tăng hiệu suất ra khỏi database của bạn . Cùng với các kỹ thuật khác như sao chép, bộ nhớ đệm và sharding, kết nối gộp có thể giúp bạn mở rộng lớp database của bạn để xử lý dung lượng yêu cầu lớn hơn.

Trong hướng dẫn này, ta tập trung vào một kịch bản thử nghiệm tổng hợp và đơn giản bằng cách sử dụng công cụ đo điểm chuẩn pgbench hợp sẵn của PostgreSQL và bài kiểm tra điểm chuẩn mặc định của nó. Trong bất kỳ tình huống production nào, bạn nên chạy các điểm chuẩn so với dữ liệu production thực tế trong khi mô phỏng tải production . Điều này sẽ cho phép bạn điều chỉnh database của bạn cho kiểu sử dụng cụ thể của bạn.

Cùng với pgbench , các công cụ khác tồn tại để chuẩn và tải database của bạn. Một công cụ được Percona phát triển là sysbench-tpcc . Một thứ khác là JMeter của Apache, có thể tải database thử nghiệm cũng như các ứng dụng web.

Để tìm hiểu thêm về Dịch vụdatabase DigitalOcean, hãy tham khảo tài liệu sản phẩm Dịch vụdatabase. Để tìm hiểu thêm về sharding, một kỹ thuật chia tỷ lệ hữu ích khác, hãy tham khảo Tìm hiểu về Sharding database .

Người giới thiệu


Tags:

Các tin liên quan

Giới thiệu về Truy vấn trong PostgreSQL
2018-10-17
Cách thiết lập bản sao lôgic với PostgreSQL 10 trên Ubuntu 18.04
2018-08-31
Cách di chuyển thư mục dữ liệu PostgreSQL đến vị trí mới trên Ubuntu 18.04
2018-07-13
Cách cài đặt và sử dụng PostgreSQL trên Ubuntu 18.04
2018-05-04
Cách sử dụng tìm kiếm toàn văn bản trong PostgreSQL trên Ubuntu 16.04
2017-06-15
Cách bảo mật PostgreSQL chống lại các cuộc tấn công tự động
2017-01-24
Cách sử dụng Postgresql với Ứng dụng Django của bạn trên Debian 8
2016-12-22
Cách di chuyển thư mục dữ liệu PostgreSQL đến vị trí mới trên Ubuntu 16.04
2016-07-27
Cách sử dụng PostgreSQL với Ứng dụng Django của bạn trên Ubuntu 16.04
2016-05-18
Cách cài đặt và sử dụng PostgreSQL trên Ubuntu 16.04
2016-05-04