Tôi chắc rằng bạn đã thấy điều này sắp xảy ra, "Nó phụ thuộc".
Nó phụ thuộc vào mọi thứ. Và giải pháp chia sẻ dữ liệu Khách hàng cho bộ phận A có thể hoàn toàn khác đối với việc chia sẻ dữ liệu Khách hàng với bộ phận B.
Khái niệm yêu thích của tôi đã tăng lên trong những năm qua là khái niệm "Tính nhất quán cuối cùng". Thuật ngữ này xuất phát từ Amazon để nói về các hệ thống phân tán.
Tiền đề là mặc dù trạng thái của dữ liệu trong một doanh nghiệp phân tán hiện tại có thể không hoàn toàn nhất quán, nhưng "cuối cùng" sẽ như vậy.
Ví dụ:khi hồ sơ khách hàng được cập nhật trên hệ thống A, dữ liệu khách hàng của hệ thống B hiện đã cũ và không khớp. Nhưng, "cuối cùng", bản ghi từ A sẽ được gửi đến B thông qua một số quá trình. Vì vậy, cuối cùng, hai trường hợp sẽ khớp nhau.
Khi bạn làm việc với một hệ thống duy nhất, bạn không có "EC", thay vào đó bạn có các bản cập nhật tức thì, một "nguồn sự thật" duy nhất và thường là cơ chế khóa để xử lý các điều kiện và xung đột chủng tộc.
Các hoạt động của bạn càng có khả năng làm việc với dữ liệu "EC", thì việc tách các hệ thống này càng dễ dàng. Một ví dụ đơn giản là Kho dữ liệu được sử dụng bởi bán hàng. Họ sử dụng DW để chạy báo cáo hàng ngày của mình, nhưng họ không chạy báo cáo của mình cho đến sáng sớm và họ luôn xem dữ liệu "những ngày cuối năm" (hoặc sớm hơn). Vì vậy, không cần thời gian thực để DW hoàn toàn nhất quán với hệ thống hoạt động hàng ngày. Hoàn toàn có thể chấp nhận được khi một quy trình chạy ở thời điểm, chẳng hạn như kết thúc hoạt động kinh doanh và di chuyển qua các ngày, các giao dịch và hoạt động diễn ra trong một hoạt động cập nhật lớn, duy nhất.
Bạn có thể thấy yêu cầu này có thể giải quyết rất nhiều vấn đề như thế nào. Không có tranh cãi về dữ liệu giao dịch, không phải lo lắng rằng một số dữ liệu báo cáo sẽ thay đổi giữa quá trình tích lũy thống kê vì báo cáo đã thực hiện hai truy vấn riêng biệt đối với cơ sở dữ liệu trực tiếp. Không cần quá nhiều chi tiết để xử lý mạng và cpu, v.v. trong ngày.
Bây giờ, đó là một ví dụ cực đoan, đơn giản và rất thô về EC.
Nhưng hãy xem xét một hệ thống lớn như Google. Với tư cách là người tiêu dùng Tìm kiếm, chúng tôi không biết khi nào hoặc mất bao lâu để một kết quả tìm kiếm mà Google thu thập được để hiển thị trên một trang tìm kiếm. 1ms? 1 giây? 10 giây? 10 giờ? Thật dễ dàng để hình dung nếu bạn đang truy cập các máy chủ Bờ Tây của Googles, bạn rất có thể nhận được một kết quả tìm kiếm khác với nếu bạn truy cập vào các máy chủ Bờ Đông của họ. Không có lúc nào hai trường hợp này hoàn toàn nhất quán. Nhưng nhìn chung, chúng hầu hết đều nhất quán. Và đối với trường hợp sử dụng của họ, người tiêu dùng của họ không thực sự bị ảnh hưởng bởi độ trễ và độ trễ.
Xem xét email. A muốn gửi tin nhắn cho B, nhưng trong quá trình này, tin nhắn được chuyển qua hệ thống C, D và E. Mỗi hệ thống chấp nhận tin nhắn, chịu hoàn toàn trách nhiệm về nó, rồi giao nó cho hệ thống khác. Người gửi thấy email được chuyển đi. Người nhận không thực sự bỏ lỡ nó bởi vì họ không nhất thiết phải biết nó sắp tới. Vì vậy, có một khoảng thời gian lớn để tin nhắn đó có thể di chuyển qua hệ thống mà không ai cần biết hoặc quan tâm đến tốc độ của nó.
Mặt khác, A có thể đã nói chuyện điện thoại với B. "Tôi vừa gửi nó, bạn đã nhận được nó chưa? Bây giờ? Bây giờ? Nhận nó ngay bây giờ?"
Do đó, có một số loại hiệu suất và mức phản ứng cơ bản, ngụ ý. Cuối cùng, "cuối cùng", hộp thư đi của A khớp với hộp thư đến của B.
Những sự chậm trễ này, việc chấp nhận dữ liệu cũ, cho dù dữ liệu cũ một ngày hay 1-5 tuổi, là những gì kiểm soát sự kết hợp cuối cùng của hệ thống của bạn. Yêu cầu này càng lỏng lẻo, khớp nối càng lỏng lẻo và bạn càng linh hoạt hơn về mặt thiết kế.
Điều này đúng với các lõi trong CPU của bạn. Các ứng dụng hiện đại, đa lõi, đa luồng chạy trên cùng một hệ thống, có thể có các chế độ xem khác nhau đối với cùng một dữ liệu "giống nhau", chỉ lỗi thời bằng micro giây. Nếu mã của bạn có thể hoạt động chính xác với dữ liệu có khả năng không nhất quán với nhau, thì chúc một ngày vui vẻ, nó sẽ nén lại. Nếu không, bạn cần đặc biệt chú ý để đảm bảo dữ liệu của mình hoàn toàn nhất quán, sử dụng các kỹ thuật như bộ nhớ dễ bay hơi đủ điều kiện hoặc khóa cấu trúc, v.v.
Vì vậy, đây là cơ sở xem xét. Tất cả các quyết định khác bắt đầu từ đây. Trả lời câu hỏi này có thể cho bạn biết cách phân vùng ứng dụng trên các máy, tài nguyên nào được chia sẻ và cách chúng được chia sẻ. Những giao thức và kỹ thuật nào có sẵn để di chuyển dữ liệu và chi phí xử lý để thực hiện chuyển dữ liệu là bao nhiêu. Sao chép, cân bằng tải, chia sẻ dữ liệu, v.v. Tất cả đều dựa trên khái niệm này.
Chỉnh sửa, để trả lời nhận xét đầu tiên.
Đúng, chính xác. Trò chơi ở đây, ví dụ, nếu B không thể thay đổi dữ liệu khách hàng, thì tác hại của dữ liệu khách hàng đã thay đổi là gì? Bạn có thể "mạo hiểm" nó bị lỗi thời trong một thời gian ngắn? Có lẽ dữ liệu khách hàng của bạn đến đủ chậm để bạn có thể sao chép nó từ A sang B ngay lập tức. Giả sử thay đổi được đưa vào một hàng đợi, do khối lượng thấp, được chọn dễ dàng (<1 giây), nhưng thậm chí nó vẫn "không giao dịch" với thay đổi ban đầu và do đó, có một cửa sổ nhỏ nơi A sẽ có dữ liệu mà B không có.
Bây giờ tâm trí thực sự bắt đầu quay. Điều gì xảy ra trong 1 giây "lag" đó, kịch bản tồi tệ nhất có thể xảy ra là gì. Và bạn có thể thiết kế xung quanh nó không? Nếu bạn có thể thiết kế độ trễ khoảng 1 giây, bạn có thể thiết kế độ trễ khoảng 5 giây, 1m hoặc thậm chí lâu hơn. Bạn thực sự sử dụng bao nhiêu dữ liệu khách hàng trên B? Có thể B là một hệ thống được thiết kế để tạo điều kiện thuận lợi cho việc chọn đơn hàng từ hàng tồn kho. Thật khó để tưởng tượng bất cứ điều gì cần thiết hơn chỉ đơn giản là ID khách hàng và có lẽ là một cái tên. Chỉ là một cái gì đó để xác định tổng thể đơn đặt hàng của ai trong khi nó được lắp ráp.
Hệ thống lấy hàng không nhất thiết phải in ra tất cả thông tin khách hàng cho đến khi kết thúc quá trình lấy hàng và khi đó đơn đặt hàng có thể đã chuyển sang một hệ thống khác có lẽ hiện tại hơn, đặc biệt là thông tin vận chuyển, vì vậy cuối cùng hệ thống chọn hàng hầu như không cần bất kỳ dữ liệu khách hàng nào. Trên thực tế, bạn có thể KẾT THÚC và không chuẩn hóa thông tin khách hàng trong đơn đặt hàng, vì vậy không cần hoặc kỳ vọng vào việc đồng bộ hóa sau này. Miễn là ID khách hàng chính xác (sẽ không bao giờ thay đổi) và tên (hiếm khi thay đổi nên điều đó không đáng thảo luận), đó là tài liệu tham khảo thực sự duy nhất bạn cần và tất cả phiếu chọn của bạn hoàn toàn chính xác tại thời điểm sáng tạo.
Bí quyết là tư duy phá vỡ hệ thống và tập trung vào dữ liệu thiết yếu cần thiết cho nhiệm vụ. Dữ liệu bạn không cần không cần phải được sao chép hoặc đồng bộ hóa. Nhiều người thích những thứ như không chuẩn hóa và giảm thiểu dữ liệu, đặc biệt là khi họ đến từ thế giới mô hình hóa dữ liệu quan hệ. Và với lý do chính đáng, nó nên được xem xét một cách thận trọng. Nhưng một khi bạn phân phối, bạn đã ngầm hóa. Heck, bạn đang sao chép nó bán buôn bây giờ. Vì vậy, bạn cũng có thể thông minh hơn về nó.
Tất cả điều này có thể được giảm thiểu thông qua các quy trình vững chắc và sự hiểu biết thấu đáo về quy trình làm việc. Xác định các rủi ro và xây dựng chính sách và thủ tục để xử lý chúng.
Nhưng phần khó là phá vỡ chuỗi đối với DB trung tâm ngay từ đầu và hướng dẫn mọi người rằng họ không thể "có tất cả" như họ có thể mong đợi khi bạn có một kho lưu trữ thông tin hoàn hảo, trung tâm và duy nhất.
