Phân vùng bảng để lưu trữ dữ liệu

13

Kịch bản:

hai cơ sở dữ liệu: DB_A và DB_Archive với một bảng rất lớn gọi là bảngA.
mỗi ngày, các bản ghi cũ hơn 60 ngày sẽ bị xóa khỏi DB_A và chuyển sang DB_Archive chủ yếu để "tách" vì bảngA được truy vấn rất nhiều trên DB_A cho các bản ghi trong 2 tháng qua.

Tôi muốn thoát khỏi quá trình này vì nó chậm và tiêu tốn nhiều tài nguyên. Tôi đang nghĩ đến việc triển khai phân vùng bảng trên DB_A với chức năng phân vùng trên cột ngày và lưu trữ tất cả các bản ghi <2 tháng trên một phân vùng và tất cả các bản ghi> 2 tháng trên một phân vùng khác. Những câu hỏi của tôi:

kịch bản này sẽ hành xử như thế nào nếu tôi có 2 cơ sở dữ liệu khác nhau? Nếu tôi truy vấn bảngA của tôi để biết các bản ghi> getdate () - 30, nó có đọc được phân vùng lưu trữ không?
Tôi nghĩ rằng tôi phải phân vùng các chỉ mục là tốt, phải không?
Làm thế nào để tôi đối phó với thực tế là ngày mai chức năng phân vùng của tôi sẽ "thay đổi", ý tôi là, nếu tôi tạo chức năng hôm nay (ngày 2 tháng 7, phạm vi của nó sẽ là ngày 2 tháng 5, nhưng ngày mai sẽ là ngày 3 tháng 5). Tôi có thể tạo một chức năng phân vùng động không?

sql-server sql-server-2005 partitioning

— Diego
nguồn

Tôi không nghĩ rằng một chức năng động là một ý tưởng tốt ngay cả khi nó được cho phép (tôi không nghĩ vậy) ... chúng ta có thể sớm hiểu chi tiết hơn nhưng tôi nghĩ có lẽ bạn nên phân vùng dựa trên ngày dương lịch và chuyển đi một phân vùng tại một thời điểm ... Nhưng có nhiều lựa chọn ở đây.

— JNK

Tôi đã viết lên một ví dụ dọc theo dòng về những gì bạn muốn làm năm ngoái. Đó là một trường hợp hơi đặc biệt, theo đó chúng tôi muốn giữ x ngày dữ liệu trên một mảng nhanh (đắt tiền) và chuyển dữ liệu lưu trữ sang bộ nhớ rẻ hơn. Nếu tôi có thể vệ sinh một tập lệnh mẫu, tôi sẽ đăng nó, nếu không nó sẽ chỉ là một bản tóm tắt của quy trình.

— Mark Storey-Smith

xin chào, vâng, xin vui lòng, và nếu bạn có thể chia sẻ kinh nghiệm của bạn là tốt. nó có thành công không

— Diego

Nó hoạt động nhưng cuối cùng không cần thiết (chúng tôi đã đi một con đường đơn giản hơn). Có lẽ bạn có thể mở rộng lý do tại sao ranh giới 60 ngày tồn tại trong trường hợp của bạn? Sẽ giúp mọi người chỉ cho bạn đi đúng hướng.

— Mark Storey-Smith

6

Với phân vùng, bạn sẽ phải thực hiện phân vùng mỗi ngày, điều này đặt giới hạn Pre-SQL 2012 là 1000 phân vùng trong một phối cảnh mới vì nó chỉ cho phép lưu trữ trong 3 năm. Với SQL Server 2012, bạn nhận được 15000 phân vùng, rất nhiều cho 1 phân vùng mỗi ngày.

Mỗi ngày bạn sẽ thêm một phân vùng mới. Nếu bạn muốn di chuyển phân vùng thứ 61 ngày qua, bạn có thể thực hiện một cách hiệu quả, nhưng vẫn là một hoạt động ngoại tuyến. Xem Di chuyển một phân vùng đến một nhóm tệp khác một cách hiệu quả .

Tất cả các chỉ mục của bạn sẽ phải được căn chỉnh, xem Hướng dẫn đặc biệt cho các chỉ mục được phân vùng .

Mua vào phân vùng không phải là một cách dễ dàng và nó có thể là một vết cắn lớn để nhai ... xem Cách quyết định nếu bạn nên sử dụng phân vùng bảng . Cụ thể bạn không nên mong đợi cải tiến hiệu suất từ phân vùng. Bạn nên tiếp cận các vấn đề về hiệu năng đúng giờ nhất bằng cách phân cụm theo datetime.

— Remus Rusanu
nguồn

Giới hạn mới khả dụng trong 2008 SP2 và 2008 R2 SP1. blog.msdn.com/b/hanspo/archive/2010/11/29/ từ

— Jon Seigel

@Jon: triển khai 2008 SP2, 2008R2 SP1 đi kèm với một cảnh báo lớn . As explained in this white paper, there are implications on certain features, including performance. . Hỗ trợ SQL 2012 không có cảnh báo.

— Remus Rusanu

Cảm ơn đã chỉ ra rằng; đúng là có một số lưu ý khi sử dụng nó vào 2008/2008 R2, nhưng đó là một tùy chọn có sẵn nếu cần thiết.

— Jon Seigel

cám ơn bạn đã góp ý. Tôi sẽ đọc bình luận tài liệu sau này

— Diego

2

Tôi không biết chức năng phân vùng có thể là động nhưng tôi nghi ngờ nó. Một số tùy chọn cho bạn mà không cần đi theo con đường đó:

1 - Phân vùng trên DATE lịch và di chuyển khỏi phân vùng cũ nhất mỗi ngày

2 - Tạo chế độ xem lọc theo ngày và trỏ tất cả các truy vấn hiện có của bạn vào đó (điều này có thể được quản lý dễ dàng bằng cách đổi tên bảng bên dưới thành một cái khác và đặt tên cho chế độ xem tên của bảng hiện tại là gì). Điều này có thể được tối ưu hóa cũng như thay đổi chỉ số.

Hãy nhớ rằng tùy chọn đầu tiên ở trên sẽ hoạt động tốt hơn rất nhiều nếu bạn sử dụng trường ngày trong các truy vấn của mình. Nếu bạn không, nó vẫn sẽ nhanh hơn quy trình hiện tại nhưng các truy vấn sẽ không có sự cải thiện lớn. Phân vùng nói chung hoạt động tốt nhất nếu bạn có thể lọc trên trường phân vùng của mình và trình tối ưu hóa biết phân vùng nào cần xem xét.

— JNK
nguồn

Tôi muốn tránh các hoạt động thủ công "mỗi ngày"

— Diego

2

Đây là những gì sẽ làm việc cho bạn: DB_A - bảngA với một phân vùng khác nhau cho mỗi 60 ngày qua - stagingTable để di chuyển dữ liệu từ phân vùng cũ nhất

Bảng DB_ArchiveA - lưu trữ tất cả dữ liệu cũ hơn 60 ngày. (không được phân vùng)

Quá trình: 1. trước khi kết thúc ngày: thay đổi chức năng phân vùng - phạm vi phân chia để thêm phân vùng mới cho ngày mới. (NB: thay vì tạo phân vùng cho "ngày hôm nay + 1 ngày", bạn có thể muốn đi trước một vài bước. Ví dụ: "ngày hôm nay + 5 ngày"

Sau khi kết thúc mỗi ngày, trước tiên bạn chuyển phân vùng cũ nhất trong DB_A.tableA sang DB_A.stagingTable; Hợp nhất các phân vùng cũ nhất.
Nhập dữ liệu từ DB_A.stagingTable vào DB_Archive.tableA. Cuối cùng là trunacte DB_A.stagingTable

Ở trên được gọi là Cửa sổ cuộn và là một kịch bản khá phổ biến đối với VLDB. Xem sách trắng này của microsoft về phân vùng: Bảng phân vùng và chiến lược chỉ mục hoặc thử cụ thể điều này trên kịch bản Cửa sổ trượt

— DharmWiki Kumar 'DK'
nguồn

0

Bạn có thể sử dụng phương pháp động của lưu trữ và thanh lọc dữ liệu trong SQL Server. Vui lòng theo liên kết dưới đây cho điều đó.

http://www.sqlscientist.com/2012/09/auto-maintain-archival- Process.html

— Asif Ghanchi
nguồn

1

Bạn có thể vui lòng bao gồm trong câu trả lời của bạn những điểm chính của bài viết đó? Bạn biết đấy, các liên kết đến và đi và khi họ đi, bài viết của bạn sẽ chỉ có một liên kết chết.

— dezso