Giải pháp lưu trữ cơ sở dữ liệu

Tiếp tục cho một câu hỏi được đăng bởi tôi trên Có phải là một ý tưởng tốt để di chuyển các bảng có khối lượng lớn và truy cập cao đến một cơ sở dữ liệu riêng biệt? , đang tìm kiếm các kỹ thuật / giải pháp khác nhau có sẵn để lưu trữ cơ sở dữ liệu trong PostgreSQL.

Một vài giải pháp tôi có thể nghĩ đến là:

1. Phân vùng bảng
2. Không gian bảng và / hoặc lược đồ riêng biệt
3. Di chuyển các bản ghi / bảng lưu trữ sang một ổ cứng khác

Bất kỳ đề xuất / gợi ý / giải pháp khác thực sự được hoan nghênh và đánh giá cao.

LƯU Ý: Chúng tôi đang chạy PostgreSQL v9.1.3 trên CentOS5.2

Đề nghị của tôi về lưu trữ:

1. Tạo archive_tablespace(nếu bạn muốn bạn có thể tách phần cứng trên kho lưu trữ)

2. Tạo bảng. Ví dụ chúng tôi muốn lưu trữ bài viết bảng.

   create table  posts_all ( LIKE public.posts)  ;
   create table  posts_archive () inherits  ( public.posts_all)  ;
   alter table  public.posts  inherits ( public.posts_all ) ;

   Sau đó, chúng ta sẽ có 2 bảng mới: public.posts_all (có cùng cột như trong bài viết) để truy vấn tất cả các bài đăng (lưu trữ và sản xuất) và public.posts_archive để truy vấn tất cả các bài đăng lưu trữ. Public.posts sẽ kế thừa từ post_all.
   Các phần chèn sẽ đi theo một cách cũ (vào bảng public.posts) trừ khi bạn sẽ viết các trình kích hoạt trên post_all để chuyển hướng các phần chèn vào bảng bài viết. Nếu bạn có phân vùng thì sẽ phức tạp hơn. Với ứng dụng hoạt động và trước khi di chuyển dữ liệu cũ, bạn không phải thay đổi bất cứ điều gì trong mã ứng dụng để làm việc với phương pháp này.

3. Tạo lưu trữ lược đồ để phân tách hợp lý. Đề xuất của tôi sẽ là tách dữ liệu lưu trữ theo một khoảng thời gian (năm hoặc tháng) nếu có thể (archive_2005).

4. Tạo các bảng lưu trữ trong lược đồ archive_year

   create table archive_2005.posts (
     check(record_date >= '2005-01-01 00:00:00'::timestamp 
       and record_date <  '2006-01-01 00:00:00'::timestamp)
   ) inherits (posts_archive) tablespace archive_tablesapce;

   Sau đó, bạn sẽ có các bài đăng bảng mới trong lược đồ archive_2005 và trình lập kế hoạch postgresql sẽ biết rằng dữ liệu chỉ có trong khoảng thời gian được thiết kế. Nếu bạn truy vấn bởi một khoảng thời gian khác, postgresql sẽ không tìm kiếm trong bảng này.

5. Tạo các hàm / thủ tục / trình kích hoạt để di chuyển dữ liệu vào các bảng lưu trữ.

6. Lưu trữ một lần trong một khoảng thời gian (năm ở đây) và hút bụi bảng cũ hoặc thực hiện tự động bằng các kích hoạt (nặng hơn trên autovacuum). Có nhiều ưu điểm và nhược điểm trong cả hai kỹ thuật.

Nếu được thực hiện:

1. Có thể truy vấn lưu trữ dữ liệu (chọn * từ post_archive), tất cả (chọn * từ post_all) và sản xuất (chọn * từ public.posts) dữ liệu
2. Có thể thực hiện các lược đồ lưu trữ riêng biệt và thả tầng trên chúng một cách dễ dàng. pg_dump -s archive_2005 datase_name thả lược đồ archive_2005 tầng; - cẩn thận vì nó loại bỏ tất cả các bảng liên quan
3. Dữ liệu cũ được phân tách vật lý bằng không gian bảng và logic bằng lược đồ.
4. Cấu trúc khá phức tạp để quản lý quá trình lưu trữ
5. Có thể tạo các chỉ mục khác nhau trên các bảng sản xuất và lưu trữ để tối ưu hóa các truy vấn cho cả hai (chỉ mục nhỏ hơn và chuyên biệt = truy vấn nhanh hơn và cần ít không gian hơn)
6. Nếu bạn đã phân vùng các bảng (theo năm hoặc tháng), quá trình lưu trữ sẽ chỉ là di chuyển toàn bộ bảng sang archive_tablespacehoặc chỉ thay đổi nó để kế thừa từ post_archive (Tôi đã không kiểm tra điều này)
7. Nếu bạn không muốn truy cập dữ liệu cũ (được lưu trữ), bạn không phải thay đổi bất cứ điều gì trong ứng dụng.

Đây là kỹ thuật chung và bạn nên điều chỉnh nó theo nhu cầu của bạn. Bất kỳ đề xuất để cải thiện điều này?

Đọc thêm: Kế thừa PostgreSQL , phân vùng