Trong các cuộc thảo luận về cơ sở dữ liệu NoQuery vs SQL, đôi khi tôi nghe nói rằng các công ty thích sử dụng cơ sở dữ liệu NoQuery của schemaless vì việc di chuyển lược đồ sang phiên bản mới có vấn đề. Nhưng đó có thực sự là một vấn đề lớn khi thực hiện nâng cấp? Là cơ sở dữ liệu quan hệ xấu cho các hoạt động như vậy?
Tôi đọc bài đăng trên blog này trên blog MongoDB: Tại sao lại là Schemaless?
Câu trả lời:
Chỉ vì cơ sở dữ liệu NoSql của bạn không có lược đồ theo nghĩa truyền thống không có nghĩa là không có lược đồ logic mà bạn cần xử lý khi nó thay đổi. Trong trường hợp một ứng dụng thông thường sử dụng MongoDb, rất có thể mã của bạn mong đợi các trường nhất định của đối tượng json hoạt động theo những cách nhất định. Nếu bạn thay đổi hành vi, nó sẽ theo bạn có thể muốn cập nhật dữ liệu đã có trong cơ sở dữ liệu. Bây giờ, với RDBMS truyền thống, đây là một vấn đề được giải quyết phần lớn - bạn chỉ cần THAY ĐỔI các bảng bên dưới. Nhưng với các cơ sở dữ liệu NoQuery mới lạ này, bạn có một quyết định - bạn có viết một tập lệnh để munge và cập nhật tất cả các đối tượng của mình không? Hay bạn thêm mã để chuyển đổi giữa các phiên bản một cách nhanh chóng? Nếu vậy, bạn hỗ trợ các đối tượng v1 trong bao lâu? Mãi mãi? Cho đến v3?
Tôi sẽ thêm rằng ví dụ được sử dụng trong bài đăng trên blog MongoDb là một chút đơn giản và một trường hợp rất dễ xử lý nếu bạn có một quy trình cập nhật hợp lý cho dù RDBMS là gì; thêm một lĩnh vực hiếm khi làm tổn thương. Đó là khi bạn quyết định tách Namelĩnh vực của mình thành FirstNamevà LastNamemọi thứ trở nên thú vị.
Nhưng đó có thực sự là một vấn đề lớn khi thực hiện nâng cấp?
Nó có thể.
Một số tổ chức - rất - vô tổ chức và thực hiện một công việc rất tệ là di chuyển lược đồ.
"Cuối tuần di cư". Dừng các máy chủ. Sao lưu và xuất tất cả dữ liệu. Xây dựng lược đồ mới (thường bằng cách sửa đổi lược đồ hiện có). Tải lại dữ liệu hoặc cố gắng tái cấu trúc tại chỗ.
"Tinh chỉnh liên tục". Thay đổi bảng trong phạm vi cho phép của SQL. Không theo dõi trình tự của ALTER được thực hiện. Không có cách nào để quay lại phiên bản lược đồ trước đó. Khi cần thiết, tạo các bảng mới từ các bảng hiện có, hy vọng điều chỉnh tất cả các ứng dụng để sử dụng các bảng mới. Nhưng - thiếu QA tốt - để các bảng cũ thay thế "chỉ trong trường hợp".
"Hoảng loạn hoàn toàn". Đơn giản chỉ cần ngăn chặn sửa đổi lược đồ. Làm một mùi hôi thối lớn. Yêu cầu rủi ro quá cao. Chặn mọi nỗ lực theo hướng này. Lấy con tin lược đồ cho đến khi buộc phải áp dụng một số cách tiếp cận hợp lý hơn.
Là cơ sở dữ liệu quan hệ xấu cho các hoạt động như vậy?
Bất kỳ lược đồ là một nỗi đau để di chuyển.
Vấn đề lớn nhất không phải là kỹ thuật.
Đó là ngữ nghĩa.
Một lý do chính cho sự thay đổi lược đồ là lược đồ trước đó không khớp với miền vấn đề rất tốt. Vì ngữ nghĩa đã thay đổi, cơ sở dữ liệu (và ứng dụng) cần thay đổi. Đôi khi đây là những thay đổi sâu sắc đòi hỏi phải suy nghĩ lại về cách các ứng dụng làm việc với dữ liệu.
Sửa đổi ngữ nghĩa của cơ sở dữ liệu có thể rất khó khăn.
Những gì mọi người làm thay vì thay đổi lược đồ chỉ là sử dụng sai lược đồ vật lý. Họ bắt đầu tải dữ liệu sai vào các trường hiện có bởi vì họ có thể. Trường "bình luận" đột nhiên bắt đầu có một phần quan trọng của thông tin quản lý khách hàng, theo sau là "//", sau đó là bình luận thực. Điều đó phát triển để có các phần dữ liệu "trường 1 - trường 2 // bình luận". Người dùng có một bảng tính trích xuất dữ liệu bổ sung này từ trường nhận xét vì phần mềm ứng dụng "thực" có một lược đồ khó thay đổi mà CNTT từ chối thay đổi.
Chúng tôi nâng cấp cơ sở dữ liệu sản xuất thêm bảng và cột (không thể) không có vấn đề. Các phiên bản trước của ứng dụng hoạt động tốt với cơ sở dữ liệu được nâng cấp, chúng chỉ không tham chiếu các công cụ mới. Chúng tôi tránh xóa bảng hoặc cột hoặc thay đổi cách lưu trữ dữ liệu hiện có, mặc dù khi điều này là cần thiết, chúng tôi tạo ra các tập lệnh chuyển đổi phù hợp. Cho dù cơ sở dữ liệu của bạn có lược đồ an toàn loại khai báo hay không, các thay đổi trong cấu trúc dữ liệu yêu cầu chuyển đổi dữ liệu và nâng cấp ứng dụng để tương tác với cấu trúc mới.
Nó phụ thuộc.
Đầu tiên, nếu bạn có một cơ sở dữ liệu thực sự lớn bao gồm nhiều máy, thì mọi thứ (không chỉ là cập nhật cơ sở dữ liệu) sẽ trở nên khó khăn. (không có vấn đề bao nhiêu bạn lên kế hoạch trước thời hạn).
Thứ hai, cập nhật cơ sở dữ liệu KHÔNG chỉ là một điều cơ sở dữ liệu - nó còn phụ thuộc vào hệ thống lớn hơn mà DB là một phần. Điều này cũng bao gồm việc triển khai cơ sở dữ liệu (nhiều máy chủ cơ sở dữ liệu, nhiều trung tâm dữ liệu, thiết lập chủ nô, v.v.)
Nỗi đau có thể được giảm bớt bằng cách kiến trúc các thành phần hệ thống của bạn sao cho tất cả chúng đều có một số 'nhận thức' về sự kiện thay đổi lược đồ DB. Điều này có nghĩa là toàn bộ hệ thống phải chịu được các thay đổi lược đồ và có thể đáp ứng nó theo cách 'lành mạnh'.
Bạn có thể kiểm tra một tiện ích do Facebook phát triển để xử lý các cập nhật lược đồ MySQL.
Ngoài ra, có những thực tiễn tốt nhất tiêu chuẩn như biến bạn thành chủ chỉ đọc, thực hiện thay đổi thành nô lệ hoặc trên bản sao phát triển, v.v.
Trong mọi trường hợp, có một bản sao lưu đầy đủ và bộ kiểm tra mở rộng là PHẢI. Chỉ sau đó, bạn có thể thực hiện bất kỳ thay đổi tự tin và an toàn.