Làm thế nào lớn là quá lớn cho một bảng PostgreSQL?

127

Tôi đang làm việc thiết kế cho một dự án RoR cho công ty của mình và nhóm phát triển của chúng tôi đã có một cuộc tranh luận về thiết kế, đặc biệt là cơ sở dữ liệu.

Chúng tôi có một mô hình được gọi là Messagecần phải được kiên trì. Đó là một mô hình rất, rất nhỏ chỉ có ba cột db ngoài id, tuy nhiên có thể sẽ có RẤT NHIỀU mô hình này khi chúng tôi đi vào sản xuất. Chúng tôi đang xem xét tới 1.000.000 lần chèn mỗi ngày. Các mô hình sẽ chỉ được tìm kiếm bởi hai khóa ngoại trên chúng có thể được lập chỉ mục. Đồng thời, các mô hình không bao giờ phải xóa, nhưng chúng tôi cũng không phải giữ chúng một khi chúng khoảng ba tháng tuổi.

Vì vậy, điều chúng tôi tự hỏi là nếu triển khai bảng này trong Postgres sẽ đưa ra một vấn đề hiệu suất quan trọng? Có ai có kinh nghiệm với cơ sở dữ liệu SQL rất lớn để cho chúng tôi biết liệu đây có phải là vấn đề không? Và nếu vậy, chúng ta nên đi với sự thay thế nào?

— Dylan Karr
nguồn

với một lớp bộ nhớ đệm tốt và một số cấu hình nhỏ trong PG, bạn sẽ ổn thôi. Bạn nên giải quyết các vấn đề về hiệu suất theo từng trường hợp và tránh việc chuẩn bị trước. Điều đó nói rằng, phân vùng và nhân rộng luôn là những lựa chọn tuyệt vời mà bạn có thể tận dụng khi bạn gặp phải tắc nghẽn.

— Sam

Câu hỏi liên quan ở đây và đây .

— Erwin Brandstetter

Chúng tôi xử lý khoảng 30 triệu tin nhắn mỗi ngày trong một cơ sở dữ liệu 5+ TB PostgreSQL, hoạt động tốt.

— Frank Heikens

xem thêm stackoverflow.com/questions/3132444/

— Mạnh

FYI, tôi tình cờ đọc postgresql.org/about hôm nay và nhận thấy rằng nó nói rằng (về nguyên tắc) số lượng hàng trong một bảng là không giới hạn.

— Al Chou

Câu trả lời:

115

Hàng trên một bảng sẽ không phải là vấn đề của riêng nó.

Vì vậy, đại khái là 1 triệu hàng một ngày trong 90 ngày là 90 triệu hàng. Tôi thấy không có lý do gì Postgres không thể đối phó với điều đó, mà không biết tất cả các chi tiết về những gì bạn đang làm.

Tùy thuộc vào phân phối dữ liệu của bạn, bạn có thể sử dụng hỗn hợp các chỉ mục, chỉ mục được lọc và phân vùng bảng một số loại để tăng tốc độ khi bạn thấy vấn đề về hiệu suất mà bạn có thể có hoặc không có. Vấn đề của bạn sẽ giống nhau trên bất kỳ RDMS nào khác mà tôi biết. Nếu bạn chỉ cần 3 tháng thiết kế dữ liệu trong một quy trình để cắt bớt dữ liệu bạn không cần thêm nữa. Bằng cách đó bạn sẽ có một khối lượng dữ liệu nhất quán trên bàn. May mắn của bạn, bạn biết có bao nhiêu dữ liệu sẽ tồn tại, kiểm tra nó cho khối lượng của bạn và xem những gì bạn nhận được. Kiểm tra một bảng với 90 triệu hàng có thể dễ dàng như:

select x,1 as c2,2 as c3
from generate_series(1,90000000) x;

https://wiki.postgresql.org/wiki/FAQ

Limit   Value
Maximum Database Size       Unlimited
Maximum Table Size          32 TB
Maximum Row Size            1.6 TB
Maximum Field Size          1 GB
Maximum Rows per Table      Unlimited
Maximum Columns per Table   250 - 1600 depending on column types
Maximum Indexes per Table   Unlimited

— Kuberchaun
nguồn

Tôi đồng ý rằng 90 triệu hàng sẽ không phải là vấn đề đối với PostgreSQL. Nhưng nó có thể là một vấn đề đối với một ORM với PostgreSQL. (Một ORM với bất kỳ dbms nào, thực sự.)

— Mike Sherrill 'Cat Recall'

@ MikeSherrill'Catcall 'Điểm hay, tôi chỉ tập trung vào "Lớn như thế nào là quá lớn cho một bảng PostgreQuery?"

— Kuberchaun

@yeyo: Bởi vì các ORM thường sử dụng rất nhiều truy vấn để lấy dữ liệu có thể được trả về chỉ với một hoặc hai. OP đang sử dụng Ruby on Rails.

— Mike Sherrill 'Nhớ lại mèo'

Điều này hơi muộn nhưng tôi nghĩ rằng trong rất nhiều trường hợp (đặc biệt là với đường ray / bản ghi hoạt động), người ta thường loại bỏ hoàn toàn ORM khỏi phương trình và viết một chuỗi sql thô để truy vấn vì lý do hiệu suất. Đừng để ORM của bạn đưa ra quyết định dữ liệu cho bạn! Đây là một phụ kiện không phải là một thiết yếu.

— Stefan Theard

URL giới thiệu được trích dẫn trong URL hiện không hiển thị các giới hạn này - có ai biết nó được chuyển đến đâu không?

— Shorn

Một cách khác để tăng tốc đáng kể các truy vấn của bạn trên một bảng có> 100 triệu hàng là trong giờ nghỉ, cụm bảng trên chỉ mục thường được sử dụng nhất trong các truy vấn của bạn. Chúng tôi có một bảng với> 218 triệu hàng và đã tìm thấy 30 lần cải tiến.

Ngoài ra, đối với một bảng rất lớn, bạn nên tạo một chỉ mục trên các khóa ngoại của mình.

— James Doherty
nguồn

> trong giờ nghỉ, cụm bảng trên chỉ mục thường được sử dụng nhất trong các truy vấn của bạn .... bạn có thể giải thích cách thực hiện việc này không?

— gián điệp

Có ở đây là từng bước VÍ DỤ: 1) Bảng tôi đang đề cập đến được gọi là đầu tư trong ví dụ này. 2) Chỉ mục được sử dụng nhiều nhất trong các truy vấn là (bankid, record_date) Vì vậy, đây là bước của bạn: 1) psql -c "thả chỉ số đầu tư_bankid_rec_dt_idx;" dbname 2) psql -c "tạo chỉ mục đầu tư_bankid_rec_dt_idx về đầu tư (bankid, record_date);" 3) psql -c "cụm đầu tư_bankid_rec_dt_idx về đầu tư;" 4) voiddb -d ccbank -z -v -t đầu tư Vì vậy, trong bước một và hai, chúng tôi bỏ chỉ mục và tạo lại nó.

— James Doherty

Bước 3 chúng ta tạo cụm, điều này về cơ bản sẽ đặt bảng DB theo thứ tự vật lý của chỉ mục, vì vậy khi postgresql thực hiện một truy vấn, nó lưu trữ các hàng tiếp theo rất có thể. Bước 4 chúng tôi hút bụi cơ sở dữ liệu để đặt lại số liệu thống kê cho trình lập kế hoạch truy vấn

— James Doherty