Mọi thứ bạn gợi ý đều là công thức cho sự đau đớn và những lần di cư thất bại. Mọi người sẽ khen ngợi và tán dương về việc PostgreSQL khủng khiếp, chậm chạp và không đáng tin cậy như thế nào nếu bạn cố gắng sử dụng cách tiếp cận này. Đó sẽ là một động thái chính trị lớn của một người muốn giữ lại SQL Server, nhưng không phải là một cách tốt để chuyển sang PostgreSQL.
Có một trình bao bọc dữ liệu nước ngoài đọc / ghi sắp có cho các phiên bản Pg mới hơn, nhưng ban đầu nó sẽ chỉ hỗ trợ các máy chủ PostgreSQL khác. Việc hỗ trợ MS SQL sẽ khó hơn rất nhiều do cần phải dịch các sqlstates và thông báo lỗi, điều kiện tìm kiếm, v.v., vì vậy mọi trình bao bọc chắc chắn sẽ khá hạn chế và có hiệu suất kém hơn. Như bạn nói, dù sao thì hỗ trợ FDW vẫn còn quá non nớt vào thời điểm này.
Có rất nhiều thứ bạn mất khi cố gắng thực hiện một kết hợp như thế này:
-
Không thực thi tính toàn vẹn của khóa ngoại
-
Các kiểu dữ liệu ở mỗi bên có thể không hoạt động giống nhau 100% nên dữ liệu có thể ổn ở một bên và không ở bên kia. Suy nghĩ về dấu thời gian / ngày tháng.
-
Các phép nối hiệu quả sẽ yêu cầu một trình bao bọc dữ liệu nước ngoài cực kỳ phức tạp - vì vậy điều thường xảy ra là toàn bộ bảng sẽ được tìm nạp sau đó được nối với cục bộ. Hiệu suất sẽ rất khủng khiếp.
-
Viết truy vấn trở thành một cơn ác mộng khi bạn đang làm bất cứ điều gì ngoại trừ nhiệm vụ nhỏ nhất. Tên hàm khác nhau, v.v.
-
Bạn mất hoặc làm suy yếu nhiều thuộc tính ACID và / hoặc phải sử dụng cam kết hai giai đoạn, điều này rất khó cho hiệu suất.
Nghiêm túc, đừng làm điều này.
Đồng bộ hóa các DB có lẽ thậm chí còn tồi tệ hơn - trừ khi đó là một cách, nó sẽ trở thành công thức cho các bản cập nhật bị mất, các hàng bị xóa xuất hiện lại và tệ hơn. Đồng bộ hóa hai chiều là cực kỳ khó.
Bắt đầu chuẩn bị ứng dụng của bạn để di chuyển bằng cách làm cho chúng có thể chạy trên cả hai máy chủ, nhưng chỉ một máy chủ tại một thời điểm. Khi bạn đã có ứng dụng sẵn sàng để chạy trên Pg, hãy bắt đầu thực hiện một số thử nghiệm tải và kiểm tra độ tin cậy với bản sao dữ liệu trực tiếp được di chuyển. sau đó suy nghĩ về việc di chuyển, nhưng có kế hoạch làm thế nào để đảo ngược việc di chuyển nếu bạn nhận thấy các vấn đề vào phút cuối buộc bạn phải trì hoãn.
Nếu bạn đang thêm các phần hoàn toàn mới vào ứng dụng, có thể hợp lý để có chúng trong Pg nếu chúng hoàn toàn không tương tác với dữ liệu khác trong DB. Tuy nhiên, điều đó khá khó xảy ra và các sysadmins của bạn sẽ vẫn ghét bạn khi bạn nói với họ rằng bây giờ bạn cần một ảnh chụp nhanh nguyên tử trên hai cơ sở dữ liệu riêng biệt ...
