Các thực hành bạn làm theo để tránh cập nhật dữ liệu sai trong cơ sở dữ liệu lớn là gì?

Một lời khuyên điển hình trước khi triển khai sản xuất là sao lưu DB trước. Bằng cách này, nếu bản cập nhật mới có một số vấn đề có thể dẫn đến mất dữ liệu tiềm ẩn hoặc hỏng dữ liệu logic, thì bạn vẫn có một bản sao lưu để so sánh và sửa các bản ghi cũ.

Tuy nhiên, điều này có thể hoạt động tốt cho đến khi kích thước DB là vài GB. Khi kích thước DB rất lớn, việc sao lưu sẽ mất nhiều thời gian. Một số thực tiễn tốt nhất nên được tuân theo trong các tình huống như vậy là gì để tránh hỏng dữ liệu logic vì các vấn đề logic trong triển khai mã?

Là người thường xuyên xử lý cập nhật cơ sở dữ liệu sản xuất cho khách hàng để nâng cấp phần mềm của chúng tôi, tôi nói với bạn rằng cách tốt nhất để giảm thiểu lỗi là thực hiện cập nhật càng đơn giản càng tốt.

Nếu bạn có thể thực hiện thay đổi cho tất cả các bản ghi thay vì các bản ghi cụ thể, thì tốt hơn là nên.

Nói cách khác, nếu bạn được cung cấp một danh sách id của các bản ghi cần thay đổi trạng thái của chúng, bạn nên tự hỏi tại sao bản cập nhật được thực hiện trong bối cảnh của chương trình. Nó có thể là trong số 10 bản ghi bạn cần cập nhật, bảng chỉ có 10 phần tử. Do đó, bạn nên tự hỏi mình về mặt khái niệm tất cả những gì bạn đang làm là cập nhật trạng thái của tất cả các hồ sơ.

Nếu bạn có thể chèn, nó là tốt hơn.

Hành động thêm một bản ghi là khép kín. Điều này có nghĩa là tôi chỉ có một tác dụng phụ của việc thêm một bản ghi và đó là sự tồn tại của một bản ghi không tồn tại trước đó. Do đó, trừ khi bạn thêm một bản ghi không nên có, sẽ không có vấn đề gì.

Nếu bạn có thể tránh xóa, nó là tốt hơn.

Nếu bạn đang thực hiện xóa, bạn sẽ xóa dữ liệu mà không thể khôi phục được nếu không có bản sao lưu. Nếu có thể, hãy cố gắng sắp xếp dữ liệu theo cách mà bạn có thể vô hiệu hóa các bản ghi bằng cách thay đổi trạng thái của nó thay vì xóa vật lý bản ghi. Phần dư của dữ liệu có thể được đặt trong một phân vùng hoặc nó có thể được loại bỏ hoàn toàn trong một khoảnh khắc sau khi bạn chắc chắn không có vấn đề gì.

Có một chính sách cập nhật nhất quán.

Nếu bạn cần cập nhật một bản ghi, một trong nhiều điều có thể xảy ra:

1. Hồ sơ của bạn không tồn tại.
2. Hồ sơ của bạn tồn tại nhưng nó đã được thay đổi.
3. Hồ sơ của bạn tồn tại và yêu cầu thay đổi.

Bạn cần có một chính sách để xác định quá trình hành động nên một cái gì đó không đi theo kế hoạch. Để đơn giản, bạn nên nhất quán trong hội đồng quản trị và áp dụng chính sách này trong mọi tình huống của loại này, không chỉ cho các bảng cụ thể. Điều này giúp dễ dàng hơn để có thể khôi phục dữ liệu sau này. Nói chung, chính sách của tôi là viết kịch bản theo cách để có thể thực hiện lại nó sau này. Nếu kịch bản thất bại, thật tốt khi biết bạn có thể thực hiện các điều chỉnh phù hợp và thực hiện lại, tuy nhiên bạn có thể tự do chọn chính sách phù hợp nhất với mình.

Sao lưu

Điều này không có nghĩa là không cho phép bạn thực hiện sao lưu trước khi thực hiện bất kỳ cập nhật nào trong môi trường sản xuất! Mặc dù với một bản sao lưu, tôi coi đó là một thất bại khi phải sử dụng bản sao lưu. Mất dữ liệu có thể là một khả năng ngay cả trong trường hợp xấu nhất.

Phần kết luận

Bạn không phải lúc nào cũng có thể có nó theo cách của bạn. Lược đồ bảng có thể sẽ không được xác định bởi bạn và do đó, điều đó có nghĩa là các loại cập nhật bạn có thể mong đợi thực hiện sẽ vừa phức tạp vừa rủi ro. Mặc dù nếu bạn có bất kỳ vấn đề nào trong vấn đề này, điều đó sẽ giúp ghi nhớ những điểm này khi chúng thực hiện bất kỳ cập nhật nào một cách đơn giản và không có rủi ro đáng kể.

Chúc may mắn!

Tại thời điểm đó, bạn nên sử dụng hệ thống DB cấp thương mại hỗ trợ ảnh chụp nhanh (Oracles gọi là Flashback ) - đó chính xác là loại mà chúng dành cho.

Hãy nhớ rằng dù sao bạn cũng cần một khái niệm sao lưu - có nhiều dữ liệu hơn không có nghĩa là bạn bỏ các bản sao lưu vì chúng trở nên khó khăn, hoàn toàn ngược lại. Bạn cần một số loại sao lưu liên tục, ví dụ dựa trên sao chép với chuyển đổi dự phòng tự động.

Đây là một khu vực rộng lớn - vì vậy mong đợi câu hỏi này sẽ được đóng lại theo thứ tự khá ngắn nhưng, ngoài đỉnh đầu của tôi (như một DBA trước đây trên cơ sở dữ liệu yuge):

Mart / Kho lưu trữ

Bạn có thể giảm thiểu một số rủi ro nếu bạn có một cơ sở dữ liệu riêng để cập nhật và cơ sở dữ liệu riêng biệt mà mọi người sử dụng. Sau đó, nó chỉ là một trường hợp sao chép dữ liệu từ một DB sang một DB khác khi các kiểm tra khác nhau đã diễn ra. Mart / repository là cách đôi khi được mô tả nhưng bạn có thể có chính / phụ, chủ / nô, v.v.

Mã nguồn

Đối với mọi thứ có thể thay đổi, hãy có một mã nguồn liên quan đến cách dữ liệu được cập nhật. Bạn có bao nhiêu trong số này thay đổi từ DB sang DB nhưng bạn có thể có một cho mỗi người dùng, vai trò, nguồn cấp dữ liệu, mô-đun mã, v.v.

Tạo / cập nhật ngày

Một cái gì đó có thể hỗ trợ rất nhiều khi theo dõi nơi mà mọi thứ đã sai là tạo ra và cập nhật dữ liệu cho mỗi hàng. Sau đó, bạn có thể thấy trong nháy mắt những hàng đã được cập nhật.

ETL

Nếu bản cập nhật cơ sở dữ liệu tham gia như một phần của nhà máy dữ liệu, bạn có thể khôi phục bản cũ trước đó từ các tệp phẳng.

Sao lưu

Sao lưu toàn bộ tất nhiên chiếm rất nhiều dung lượng nhưng kịch bản thông thường là sao lưu toàn bộ xảy ra theo định kỳ (nói, hàng tuần) và một phần trên cơ sở thường xuyên hơn (hàng ngày, v.v.).

Thời điểm phục hồi

Tùy thuộc vào RDBMS mà bạn đang sử dụng, một số điểm hỗ trợ trong thời gian phục hồi. Điều này cho phép bạn quay trở lại thời điểm khi một trạng thái tốt đã được biết đến. Tuy nhiên, điều này đòi hỏi một lượng lưu trữ lớn sẽ tăng thêm cho khoảng cách bạn muốn quay lại.

Kiểm toán

Có bảng kiểm toán sẽ cho bạn biết ai (hoặc cái gì) đã thực hiện cập nhật cho một hàng. Điều này có thể cung cấp cho bạn một điểm khởi đầu tốt để điều tra.

Lịch sử

Đối với một số bảng quan trọng, một bản sao của hàng thích hợp được lấy tại thời điểm cập nhật để dữ liệu có thể được khôi phục nếu cần.

Xác nhận dữ liệu

Đảm bảo kiểm tra xác thực cơ bản được thực hiện trên dữ liệu trước khi được lưu trữ - kiểm tra loại dữ liệu cơ bản trên và trên.

Toàn vẹn tham chiếu

Tính toàn vẹn tham chiếu không phải là viên đạn bạc nhưng nó có thể giúp đảm bảo dữ liệu được cấu trúc tốt.

Nhiều lần nếu chúng tôi thực hiện cập nhật "một lần bắn", chúng tôi sẽ sao lưu sản xuất và khôi phục nó về máy chủ thử nghiệm. Sau đó, chúng tôi tạo ra một bộ thử nghiệm và chạy một shot. Chúng tôi xác minh dữ liệu đã thay đổi thông qua các thử nghiệm và trở nên thoải mái, bản cập nhật đó sẽ thành công và sửa đổi dữ liệu theo cách mà chúng tôi mong đợi. Điều này được gọi là chạy khô hoặc chạy thử. Tôi khuyên bạn nên làm điều này.

Điều này mang lại cho tất cả mọi người một cảm giác tốt rằng một phát bắn sẽ thành công. Chúng tôi không thể đảm bảo 100% vì dữ liệu sẽ được cập nhật kể từ ngày chạy thử, nhưng chúng tôi tăng cường sự tự tin và các yếu tố thành công. Điều này cũng đưa ra một ý tưởng thực sự về bất kỳ vấn đề nào sẽ xảy ra vì chúng tôi đang sử dụng một bản sao của sản xuất. Bây giờ nếu vì lý do nào đó, bản cập nhật thất bại, chúng tôi luôn có thể quay lại chạy trước khi khôi phục nếu cần, nhưng chúng tôi nên tìm và khắc phục mọi sự cố với chạy khô.

Nếu bạn không thể lấy toàn bộ cơ sở dữ liệu (nếu thực sự lớn), hãy thử và xuất cỡ mẫu nhỏ hơn và chạy cập nhật (chạy khô nhỏ) đối với dữ liệu thực tế. Tôi muốn toàn bộ tập dữ liệu nếu có thể để đảm bảo kiểm tra hoàn thành nhất có thể.