Chúng tôi hiện đang gặp phải một số vấn đề về hiệu suất do cơ sở dữ liệu của chúng tôi đang trở nên quá lớn. Có dữ liệu được lưu trữ trong 10 năm qua và tôi không thấy lý do tại sao dữ liệu cũ hơn 2 năm phải được lưu trữ trong cùng bảng với dữ liệu mới.

Bây giờ vì tôi không có kinh nghiệm sâu sắc trong việc quản trị cơ sở dữ liệu, tôi đang tìm cách tốt nhất để lưu trữ dữ liệu cũ.

Thông tin

• Tổng cộng có khoảng 310'000'000 hồ sơ trong cơ sở dữ liệu.

• Cơ sở dữ liệu cần 250 GB trên đĩa cứng.

• Phiên bản Máy chủ là SQL Server 2008 với mức độ tương thích SQL Server 2005 (90), nhưng chúng tôi sẽ sớm nâng cấp lên SQL Server 2012

Tôi đã nghĩ về hai khả năng:

Cơ sở dữ liệu mới

Tạo cơ sở dữ liệu tương tự như trên máy chủ sản xuất và chèn tất cả dữ liệu cũ vào cơ sở dữ liệu mới.

• Nhược điểm: Do các máy chủ được liên kết không được phép trong môi trường của chúng tôi, nên sẽ khó tham gia dữ liệu cũ nếu cần

Lược đồ lịch sử

Tạo một lược đồ mới [hist] với các bảng giống như trong cơ sở dữ liệu sản xuất. Chèn tất cả dữ liệu cũ vào các bảng mới này trong lược đồ mới.

• Ưu điểm: Dễ dàng tham gia, nếu cần dữ liệu cũ trong tương lai

• Bạn có đặt trước một trong những giải pháp khác không?
  • Tại sao?
• Có khả năng nào tốt hơn không?
• Có các công cụ hiện có mà nhiệm vụ này có thể dễ dàng?
• Còn suy nghĩ nào khác không?

Cảm ơn trước

Chỉnh sửa

Câu hỏi bổ sung:

Bảng lưu trữ mới được tạo cũng cần khóa chính / khóa ngoài?

Hoặc họ chỉ nên có các cột nhưng không có khóa / ràng buộc?

Tôi nghĩ rằng câu trả lời cho nhiều câu hỏi của bạn là nó phụ thuộc. Những vấn đề hiệu suất bạn đang có? Có vẻ bất thường khi một cơ sở dữ liệu sẽ có vấn đề về hiệu năng chỉ từ việc tăng lên 250GB.

Có lẽ các truy vấn của bạn đang thực hiện quét bảng trên toàn bộ bảng thực tế ngay cả khi chỉ cần một phần nhỏ (ví dụ: năm ngoái) của phạm vi ngày là cần thiết? Nếu có một truy vấn cụ thể quan trọng nhất để tối ưu hóa, hãy xem xét việc đăng lược đồ, truy vấn của bạn và kế hoạch thực hiện thực tế trong một câu hỏi khác để xem liệu nó có thể được tối ưu hóa không.

Bạn có thích một trong những giải pháp khác không?

Tôi thường thích cơ sở dữ liệu lịch sử và tôi nghĩ Guy mô tả lý do chính đáng cho điều này trong phản hồi của mình .

Nhược điểm chính mà tôi thấy đối với cơ sở dữ liệu lịch sử (trái ngược với lược đồ) là bạn không còn có thể sử dụng khóa ngoại cho bảng lưu trữ của mình. Điều này có thể tốt cho bạn, nhưng đó là điều cần lưu ý.

Nhược điểm bạn liệt kê cho phương pháp này là không chính xác; bạn sẽ có thể truy vấn trên các cơ sở dữ liệu trên cùng một máy chủ một cách dễ dàng và trình tối ưu hóa truy vấn thường xử lý các truy vấn cơ sở dữ liệu chéo rất tốt.

Có khả năng nào tốt hơn không?

Nếu bạn cần truy vấn dữ liệu lưu trữ thường xuyên, tôi có thể xem xét phân vùng bảng theo ngày . Tuy nhiên, đây là một thay đổi lớn có thể mang nhiều ý nghĩa về hiệu suất, cả tích cực (ví dụ: loại bỏ phân vùng, tải dữ liệu hiệu quả hơn) và tiêu cực (ví dụ: tìm kiếm đơn lẻ chậm hơn, tiềm năng lớn hơn cho việc xiên chuỗi trong các truy vấn song song). Vì vậy, tôi sẽ không đưa ra quyết định này một cách nhẹ nhàng nếu đó là một cơ sở dữ liệu được sử dụng nhiều.

Bảng lưu trữ mới được tạo cũng cần khóa chính / khóa ngoài? Hoặc họ chỉ nên có các cột nhưng không có khóa / ràng buộc?

Tôi khuyên bạn nên có ít nhất khóa chính và chỉ mục duy nhất để bạn có thể nhận được lợi ích toàn vẹn dữ liệu mà họ cung cấp. Ví dụ, điều này sẽ ngăn bạn vô tình chèn một năm dữ liệu vào bảng lịch sử hai lần. Và như một lợi ích phụ, nó có thể cải thiện hiệu suất nếu bạn cần truy vấn bảng lịch sử.

Còn suy nghĩ nào khác không?

Vì bạn đang sử dụng phiên bản Enterprise và dự định nâng cấp lên SQL 2008+, bạn có thể xem xét nén dữ liệu cho bảng này. Nén chắc chắn sẽ giảm dung lượng ổ đĩa, nhưng tùy thuộc vào tài nguyên ổ đĩa và CPU của máy chủ, nó cũng có thể cải thiện hiệu năng truy vấn để đọc bằng cách giảm I / O của đĩa và cải thiện việc sử dụng bộ nhớ (nhiều dữ liệu phù hợp với bộ đệm cùng một lúc).

Tôi muốn có một lược đồ lịch sử hoặc cơ sở dữ liệu lịch sử thứ hai trên một máy chủ được liên kết bất cứ ngày nào. Nó tiết kiệm chi phí giấy phép dễ dàng hơn để quản lý và truy vấn. Sau đó, bạn cũng có thể sử dụng lược đồ đơn giản hơn và loại bỏ một số chỉ mục làm cho cơ sở dữ liệu nhỏ hơn

Nhưng vì bạn có phiên bản doanh nghiệp, bạn có tùy chọn thứ ba là phân vùng các bảng của mình , khi được đặt vào vị trí giúp việc lưu trữ dữ liệu dễ dàng hơn và truy vấn dữ liệu cũ là minh bạch cho người dùng của bạn và bạn sẽ không cần phải thay đổi ứng dụng .

Theo kinh nghiệm của tôi, một cơ sở dữ liệu thứ hai sẽ là lựa chọn ưu tiên vì hai lý do.

1. Bạn có thể khôi phục dữ liệu từ bản sao lưu lịch sử sau đó bỏ các bảng và chỉ mục bạn không cần.
2. Bạn có thể di chuyển cái này đến một máy chủ khác cho mục đích báo cáo, điều này có lợi ích của việc không sử dụng tài nguyên của máy chủ chính

Bạn vẫn sẽ cần xóa tất cả dữ liệu lịch sử khỏi cơ sở dữ liệu chính nhưng điều này có thể được lên lịch.

Bỏ qua giấy phép bây giờ vì đó không phải là nơi tôi dành thời gian.

IMHO, cơ sở dữ liệu lưu trữ là đơn giản nhất để thực hiện và duy trì. Chúng là những thực thể riêng biệt, lỏng lẻo. Di chuyển dữ liệu và kiểm soát tải / tài nguyên có ranh giới rõ ràng. Có thể dễ dàng di chuyển đến một cá thể hoặc máy chủ khác để quản lý hiệu suất tốt hơn và chi phí không phải là vấn đề chính. Lưu ý rằng đơn giản nhất! = Rẻ nhất hoặc ít nỗ lực nhất. Nó thực sự có nhiều nhiệm vụ hơn một chút nhưng tất cả đều là những nhiệm vụ đơn giản với hai ngoại lệ quan trọng:

1. ràng buộc thực thi - không có thứ gọi là ràng buộc cơ sở dữ liệu chéo trong SQL Server, do đó bạn cần phải quyết định xem đó có phải là công cụ giải quyết không.
2. truy vấn cơ sở dữ liệu chéo sử dụng truy vấn phân tán vẫn phụ thuộc vào OLEDB không dùng nữa. Điều đó có nghĩa là bạn có thể gặp phải sự cố với các loại dữ liệu mới cộng với nếu bạn gặp phải sự cố về hiệu suất, không chắc chúng sẽ được sửa chữa

Lược đồ lưu trữ hoặc chỉ lưu trữ bảng phức tạp hơn một chút để thực hiện nhưng dễ sử dụng hơn nhiều. Tất cả các đối tượng trong cùng một cơ sở dữ liệu có nghĩa là bạn không phải sao chép và duy trì kiểm soát truy cập. Không có truy vấn cơ sở dữ liệu chéo nào giúp điều chỉnh hiệu suất, giám sát, xử lý sự cố, v.v.

Phân vùng bảng là một giải pháp tuyệt vời và cung cấp nhiều lợi ích của bảng / lược đồ lưu trữ nhưng cung cấp tính minh bạch cho người dùng / truy vấn. Điều đó nói rằng, nó là phức tạp nhất để thực hiện và đòi hỏi sự chăm sóc liên tục không dễ dàng cho người mới bắt đầu.

Một số cân nhắc quan trọng:

• Các truy vấn có trả lại dữ liệu lịch sử / lạnh thường xuyên hoặc dữ liệu lạnh được truy cập không thường xuyên không?
• Là dữ liệu lịch sử bất biến hoặc nó được cập nhật / xóa thường xuyên?
• 310m hàng là "vừa phải" (giả sử tất cả trong 1 bảng) tùy thuộc vào kích thước hàng. Bạn có dữ liệu kích thước hàng? Có bao nhiêu GB là hàng 310m?
• Tốc độ tăng trưởng của bảng đó là gì?
• Bạn có thể sửa đổi mã ứng dụng và các truy vấn SQL của nó không?

Đây là những cân nhắc quan trọng vì chúng có thể có tác động đáng kể đến giải pháp bạn chọn hoặc thậm chí có thể không cho phép một số giải pháp nhất định. Ví dụ: nếu dữ liệu lịch sử của bạn được sửa đổi / cập nhật thường xuyên (hơn một lần một tuần), sử dụng cơ sở dữ liệu riêng có nghĩa là bạn phải sử dụng DTC cho các truy vấn đó hoặc quản lý an toàn giao dịch theo cách thủ công (không tầm thường để đảm bảo luôn chính xác). Chi phí cao hơn đáng kể so với dữ liệu lịch sử bất biến.

Ngoài ra, nếu bạn đang nghĩ đến việc nâng cấp, hãy xem xét năm 2016 và tính năng Cơ sở dữ liệu Stretch mới: https://msdn.microsoft.com/en-us/l Library / d935011.aspx

Tôi muốn chia cơ sở dữ liệu thành một cơ sở dữ liệu logic riêng biệt vì những lý do sau:

1. Yêu cầu về tài nguyên

Bằng cách tách nó ra thành một cơ sở dữ liệu riêng biệt, nó có thể được lưu trữ trên một ổ đĩa khác và được theo dõi ở một tốc độ khác với dữ liệu sản xuất chính.

2. Hiệu suất

Bằng cách tách dữ liệu ra một cơ sở dữ liệu riêng biệt, cơ sở dữ liệu Sản xuất chính được giảm kích thước, giúp hiệu suất tổng thể.

3. Sao lưu đơn giản hơn

Sao lưu dữ liệu lưu trữ có thể không được coi là thiết yếu như các bản ghi 'sống / hiện tại' trong cơ sở dữ liệu SQL chính. Điều này có nghĩa là dữ liệu lưu trữ có thể được sao lưu ít thường xuyên hơn. Ngoài ra do tính chất tuần tự của cách dữ liệu Lưu trữ được ghi lại, có thể sao lưu các phần của cơ sở dữ liệu Lưu trữ một lần và sau đó không bao giờ lặp lại. Ví dụ: một khi dữ liệu lưu trữ được ghi trong cơ sở dữ liệu lưu trữ Thay đổi cho năm 2014, sẽ không bao giờ có bất kỳ thay đổi nào đối với dữ liệu đó nữa.

Lưu ý: Tôi nghĩ rằng câu trả lời cho nhiều câu hỏi của bạn đều phụ thuộc vào hoàn cảnh, bản chất của dữ liệu và các vấn đề về hiệu suất mà bạn đang gặp phải.