Quy trình làm việc được đề xuất cho quá trình di chuyển dữ liệu phức tạp

Bài viết này đề xuất quy trình từng bước để di chuyển một lượng lớn dữ liệu. Khi truyền dữ liệu từ CRM dựa trên đám mây mạnh mẽ, điều quan trọng là phải lập kế hoạch cẩn thận vì thiết lập phức tạp của nó—như đối tượng tùy chỉnh, liên kết giữa dữ liệu và ID bản ghi duy nhất. Bạn cần suy nghĩ về cả các bước kỹ thuật và cách di chuyển hoạt động trong thực tế.

Phương pháp tiếp cận kỹ thuật: Bao gồm các bước di chuyển chính—trích xuất, chuyển đổi và tải dữ liệu vào Dataverse—đồng thời đảm bảo tính toàn vẹn, duy trì mối quan hệ và tối ưu hóa hiệu suất thông qua xác thực và xử lý lỗi.
Phương pháp tiếp cận chức năng: Bao gồm các tác vụ di chuyển chức năng như phân đoạn và lưu trữ dữ liệu, đồng thời nhấn mạnh sự cần thiết phải có sự tham gia của các bên liên quan trong kinh doanh để đảm bảo dữ liệu đáp ứng nhu cầu của họ.

Phương pháp kỹ thuật để di chuyển dữ liệu

Đảm bảo quá trình di chuyển diễn ra suôn sẻ bằng cách tuân theo phương pháp tiếp cận có cấu trúc—trích xuất, chuyển đổi và tải dữ liệu trong khi vẫn duy trì tính toàn vẹn và giảm thiểu gián đoạn.

Trích xuất dữ liệu từ nguồn đến cơ sở dữ liệu dàn dựng

Đối với các thao tác di chuyển dữ liệu phức tạp, chúng tôi khuyên bạn nên dàn dựng dữ liệu trong một cơ sở dữ liệu riêng biệt (ví dụ: SQL Server). Khu vực dàn dựng này chụp nhanh hệ thống nguồn mà không làm gián đoạn hoạt động kinh doanh đang diễn ra.

Những cân nhắc chính:

Tải đầy đủ so với tải delta: Sắp xếp dữ liệu dưới dạng tải đầy đủ hoặc tăng dần (delta). Sử dụng dấu thời gian được tạo tự động để theo dõi dữ liệu đến và xác định các thay đổi cho các lần tải trong tương lai.
Xử lý chuyển đổi dự phòng: Thiết kế quy trình để bỏ qua các bản ghi không thành công (ví dụ: do độ dài trường, tra cứu không hợp lệ) mà không tạm dừng di chuyển. Ghi nhật ký và giải quyết vấn đề trước khi xử lý lại.
Ánh xạ trường: Chuyển đổi giá trị nguồn để khớp với các định dạng mục tiêu trong lớp dàn dựng và phạm vi giá trị trong cơ sở dữ liệu dàn dựng trước khi di chuyển dữ liệu sang Dataverse để cải thiện hiệu quả.
Xác thực dữ liệu: Chạy kiểm tra tính toàn vẹn để phát hiện các vấn đề như thiếu tệp đối chiếu. Vì quá trình trích xuất dữ liệu có thể kéo dài hàng giờ hoặc vài ngày, hãy sử dụng lớp dàn dựng để lọc các bản ghi không đầy đủ và đảm bảo tính nhất quán.
Trực quan hóa dữ liệu: Sử dụng cơ sở dữ liệu dàn dựng để kiểm tra và phân tích dữ liệu — ví dụ: đếm bản ghi hoặc tính tổng các trường tài chính — trước khi di chuyển cuối cùng.

Chuyển đổi dữ liệu thành cơ sở dữ liệu dàn dựng đích

Sau khi bạn trích xuất dữ liệu từ hệ thống nguồn, hãy chuyển đổi dữ liệu đó thành cơ sở dữ liệu dàn dựng đích phản ánh lược đồ Dataverse và chứa các giá trị sẵn sàng để chèn hoặc cập nhật trực tiếp.

Các bước chuyển đổi chính:

Lập bản đồ trường: Ánh xạ các cột nguồn để nhắm mục tiêu các cột Dataverse. Sử dụng tập lệnh để nối và hợp nhất các bảng khi cần thiết.
Chuyển đổi bộ tùy chọn: Chuyển đổi giá trị bộ tùy chọn dựa trên văn bản thành số nguyên Dataverse bằng cách sử dụng bảng ánh xạ (ví dụ: OptionSetMapping) và truy vấn cập nhật hàng loạt. Tạo bảng để chuẩn hóa và tự động hóa việc chuyển đổi các giá trị bộ tùy chọn từ hệ thống nguồn sang hệ thống đích.

Bảng: OptionSetMapping

Tên cột Loại dữ liệu

Tên bảng nguồn chuỗi

Tên bảng đích chuỗi

Văn bản nguồn chuỗi

Văn bản đích chuỗi

Giá trị mục tiêu chuỗi

Sử dụng bảng OptionSetMapping để chuyển đổi và cập nhật hàng loạt giá trị bộ tùy chọn một cách hiệu quả. Ví dụ: để cập nhật tất cả các giá trị bộ tùy chọn trong bảng Người liên hệ dựa trên các giá trị văn bản phù hợp:
```
Update C.\<OptionsetValue\> = M.\<TargetValue\> 
FROM Contact C 
JOIN OptionsetMapping M 
  ON C.OptionsetText = M.TargetText 
  AND M.TargetTableName = 'Contact'
```
Tránh GUID tùy chỉnh: Hãy để Dataverse tạo GUID để ngăn chặn các vấn đề về phân mảnh và hiệu suất.
Kiểm tra độ dài chuỗi: Đảm bảo giá trị chuỗi phù hợp với giới hạn Dataverse. Cắt hoặc điều chỉnh khi cần thiết.
Các trường được tính: Thêm các trường dẫn xuất (ví dụ: Tên cho tra cứu) nếu thiếu trong nguồn.
Cân nhắc khác: Khi thiết kế bảng để khớp với lược đồ Dataverse, hãy xem xét các cột chính và bảng hỗ trợ sau.
- DataMigration_CreatedDateTime: Dấu thời gian tự động điền để theo dõi các lô tải dữ liệu.
- Cờ hành động: Cho biết chèn (I), Cập nhật (U) hoặc Xóa (D).
- Cờ xử lý: Trạng thái theo dõi — Đã xử lý (P), Chưa xử lý (U), Lỗi (E) hoặc Thành công (S).
- Cột duy nhất: Sử dụng ID duy nhất (ví dụ: ID duy nhất từ hệ thống nguồn) để ánh xạ bản ghi.
- Bảng thành công/lỗi: Duy trì các bảng riêng biệt (ví dụ: Contact_Success, Contact_Error) để ghi lại kết quả và hỗ trợ thử lại.

Tên cột	Loại dữ liệu
Tên bảng nguồn	chuỗi
Tên bảng đích	chuỗi
Văn bản nguồn	chuỗi
Văn bản đích	chuỗi
Giá trị mục tiêu	chuỗi

Bảng trình tự và tra cứu tải trước

Sau khi chuyển đổi tĩnh, hãy sắp xếp các bảng của bạn để giảm các phần phụ thuộc theo chu kỳ — trường hợp các bảng tham chiếu lẫn nhau, khiến việc nhập riêng biệt không thể thực hiện được. Sử dụng cách tiếp cận này:

Liệt kê tất cả các bảng đủ điều kiện để di chuyển.
Đếm tra cứu duy nhất trên mỗi bảng (bỏ qua các trường sẵn có như Created By và các tra cứu bảng khác nếu không di chuyển).
Sắp xếp bảng theo thứ tự tăng dần theo số lượng tra cứu.
Bao gồm các bảng mối quan hệ N:N, đếm cả hai tra cứu.
Loại trừ tra cứu nhiều bảng (ví dụ: trường "liên quan").

Cách tiếp cận này xác định trình tự tải di chuyển dữ liệu và hoạt động tốt trong hầu hết các tình huống. Đối với các trường hợp phức tạp hơn:

Sử dụng mã định danh duy nhất (ví dụ: importsequencenumber) để khớp các bản ghi giữa dàn dựng và Dataverse khi GUID được tạo trong quá trình chèn.
Tách nhật ký thành công và lỗi để tránh sự cố khóa và cải thiện hiệu suất.
Tải trước GUID tra cứu từ các bảng đã được di chuyển để giải quyết các tham chiếu trong quá trình chèn.
Xử lý các phần phụ thuộc theo chu kỳ bằng cách:
- Chèn bản ghi mà không cần tra cứu phụ thuộc.
- Cập nhật các tra cứu đó sau khi các bản ghi liên quan được tải.

Tải dữ liệu vào Dataverse

Bước tiếp theo là xác định và triển khai cách tiếp cận của bạn để tải dữ liệu vào Dataverse.

Công cụ: Chọn một công cụ dựa trên kích thước và độ phức tạp của dữ liệu:
- Công cụ di chuyển cấu hình SDK
- Azure Data Factory
- KingswayMềm
- Scribe
- Trình vận chuyển dữ liệu của XrmToolBox
Những cân nhắc chính (bất khả tri về công cụ):
- Xử lý các phần phụ thuộc theo chu kỳ: Tải bảng theo trình tự để giảm thiểu tra cứu vòng tròn. Chèn các bản ghi mà không có tra cứu phụ thuộc, sau đó cập nhật chúng sau.
- Theo dõi ID bản ghi: Ghi lại GUID Dataverse trong bảng thành công, sau đó cập nhật bảng chính bằng cách sử dụng mã định danh duy nhất (ví dụ: importsequencenumber).
- Tối ưu hóa kích thước lô và số lượng luồng: Xem lại hướng dẫn để tối ưu hóa hiệu suất cho các hoạt động hàng loạt. Ứng dụng bạn sử dụng phải quản lý các lỗi bảo vệ dịch vụ xảy ra khi số lượng yêu cầu bất thường được gửi đến Dataverse. Nếu bạn viết mã của riêng mình và sử dụng API Web Dataverse, hãy đảm bảo bạn thử lại lỗi 429 như được mô tả trong Giới hạn API bảo vệ dịch vụ. Nếu bạn sử dụng SDK Dataverse, nó sẽ quản lý các lỗi này cho bạn.
  
  Để đạt được hiệu suất tối ưu, hãy điều chỉnh kích thước lô và số lượng luồng dựa trên độ phức tạp của bảng:
  - Bảng có sẵn (OOB) (ví dụ: Liên hệ, Tài khoản, Khách hàng tiềm năng): Các bảng này chậm hơn do có plugin và công việc tích hợp. Đề xuất: Kích thước lô 200–300, tối đa 30 luồng (nếu ≤10 tra cứu và 50–70 cột).
  - Bảng đơn giản (ít hoặc không tra cứu): Khuyến nghị: Kích thước lô ≤10, tối đa 50 luồng.
  - Bảng tùy chỉnh phức tạp vừa phải (một số tra cứu): Đề xuất: Kích thước lô ≤100, tối đa 30 luồng.
  - Bảng lớn/phức tạp (>100 cột, >20 tra cứu): Khuyến nghị: Kích thước lô 10–20, tối đa 10–20 luồng để giảm lỗi.
Mẹo về cơ sở hạ tầng: Để tối đa hóa hiệu suất di chuyển dữ liệu, hãy chạy di chuyển từ máy ảo (VM) nằm trong cùng khu vực với môi trường Dataverse của bạn. Cách tiếp cận này làm giảm đáng kể độ trễ và tăng tốc toàn bộ quá trình. Tìm hiểu cách xác định khu vực của môi trường Dataverse của bạn.
Xử lý lỗi: Đừng bỏ qua lỗi—hãy giải quyết chúng để tránh lỗi theo tầng. Sử dụng mặc định (ví dụ: tra cứu trống, giá trị bộ tùy chọn mặc định) để chèn bản ghi giữ chỗ và chụp GUID.
Cập nhật trạng thái: Chỉ đặt trạng thái hoạt động trong quá trình chèn bản ghi ban đầu. Đối với các bản ghi không hoạt động hoặc mã trạng thái/trạng thái tùy chỉnh, hãy cập nhật chúng sau khi xác thực dữ liệu. Đối với hầu hết các bảng tùy chỉnh, cập nhật trạng thái có thể theo sau ngay sau khi chèn. Tuy nhiên, đối với các bảng đặc biệt như Trường hợp, Cơ hội hoặc Khách hàng tiềm năng, hãy trì hoãn cập nhật trạng thái cho đến khi kết thúc quá trình di chuyển. Một khi các bản ghi này được đóng, chúng không thể được sửa đổi trừ khi được mở lại — một quá trình tốn thời gian có nguy cơ gây rủi ro cho tính toàn vẹn của dữ liệu.
Quyền sở hữu và bảo mật: Đặt chủ sở hữu bản ghi chính xác trong quá trình chèn dữ liệu, vì cả bảo mật cấp người dùng và đơn vị kinh doanh trong Dataverse đều được gắn với đơn vị kinh doanh của chủ sở hữu. Chỉ định đơn vị kinh doanh phù hợp khi tạo—cập nhật sau đó sẽ loại bỏ tất cả các vai trò bảo mật.
- Sử dụng người dùng sơ khai:
  - Dataverse hỗ trợ người dùng sơ khai (không được cấp phép), hữu ích cho các cuộc di chuyển lớn hoặc lịch sử. Người dùng sơ khai được tự động gán vai trò bảo mật Nhân viên bán hàng—không đổi tên hoặc sửa đổi vai trò này. Người dùng sơ khai có thể sở hữu các bản ghi nếu họ có quyền truy cập đọc cấp người dùng vào các bảng có liên quan.
- Khuyến nghị:
  - Tạo tất cả người dùng không được cấp phép trong quá trình di chuyển với đơn vị kinh doanh chính xác được đặt tại thời điểm chèn.
  - Không thay đổi đơn vị kinh doanh sau khi tạo—làm như vậy sẽ xóa tất cả các vai trò, bao gồm cả Nhân viên bán hàng.
  - Đảm bảo vai trò Nhân viên bán hàng có quyền đọc vào tất cả các bảng đủ điều kiện di chuyển.
  - Ngay cả người dùng bị vô hiệu hóa trong môi trường Dataverse với vai trò này cũng có thể sở hữu bản ghi.
Xử lý tiền tệ: Đặt tỷ giá hối đoái trong quá trình chèn bằng cách sử dụng plugin xác thực trước, vì Dataverse không hỗ trợ tỷ giá trước đây.

Đăng tải dữ liệu vào Dataverse

Sau khi tải dữ liệu vào Dataverse, hãy làm theo các bước sau để đảm bảo tính toàn vẹn của dữ liệu và giảm thiểu các sự cố xuôi dòng:

Cập nhật bảng chính với GUID:
- Sau khi tải thành công, hãy sao chép GUID bản ghi Dataverse từ Bảng thành công vào Bảng chính bằng cách sử dụng mã định danh duy nhất, chẳng hạn như importsequencenumber.
- Cập nhật Cờ xử lý để đánh dấu các bản ghi là:
  - P - Đã xử lý
  - E - Lỗi
  - U – Unprocessed Chiến lược này cho phép chạy lại hiệu quả bằng cách bỏ qua các bản ghi đã được xử lý và hỗ trợ giải quyết tra cứu trong các lần tải tiếp theo.
Thử lại bản ghi không thành công: Để giảm làm lại và duy trì tính toàn vẹn của tham chiếu, hãy xem xét các hành động sau:
- Cắt các giá trị chuỗi nếu chúng vượt quá độ dài cho phép.
- Áp dụng các giá trị bộ tùy chọn mặc định khi thiếu ánh xạ.
- Chỉ định chủ sở hữu dự phòng nếu chủ sở hữu ban đầu không có sẵn (ngay cả với tư cách là người dùng sơ khai).
- Sử dụng giá trị trống hoặc giá trị mặc định cho các tra cứu chưa được giải quyết.
- Ngay cả bản ghi giữ chỗ cũng có thể giúp tạo GUID cần thiết để tra cứu trong các bảng liên quan.

Sử dụng bảng linh hoạt để di chuyển dữ liệu

Bảng linh hoạt được thiết kế để xử lý khối lượng lớn dữ liệu trong thời gian thực. Với bảng linh hoạt, bạn có thể nhập, lưu trữ và phân tích khối lượng lớn dữ liệu mà không gặp vấn đề về khả năng mở rộng, độ trễ hoặc hiệu suất.

Bảng linh hoạt cung cấp các khả năng độc đáo cho lược đồ linh hoạt, thay đổi tỷ lệ theo chiều ngang và tự động xóa dữ liệu sau một khoảng thời gian cụ thể.

Bảng linh hoạt được lưu trữ trong Azure Cosmos DB và hỗ trợ:

Dữ liệu không có lược đồ thông qua cột JSON
Tự động chia tỷ lệ ngang
Thời gian tồn tại (TTL) để tự động xóa dữ liệu cũ
Phân vùng để tối ưu hóa hiệu suất

Bảng đàn hồi phù hợp nhất để nhập số lượng lớn với lược đồ thay đổi.

Các loại dữ liệu được đề xuất cho bảng linh hoạt trong quá trình di chuyển dữ liệu

Bảng đàn hồi lý tưởng cho các loại dữ liệu cụ thể.

Loại dữ liệu	Description
Dữ liệu nhập thô	Nhật ký nguồn, nguồn cấp dữ liệu cảm biến hoặc xuất hàng loạt từ các hệ thống cũ. Ví dụ: nhật ký tương tác của khách hàng từ ERP cũ, chuỗi email cũ và phiếu hỗ trợ từ hệ thống trước đó.
Bản ghi bán cấu trúc	Dữ liệu có các trường tùy chọn hoặc đang phát triển không phù hợp với lược đồ cứng. Ví dụ: biểu mẫu phản hồi của khách hàng với các trường tùy chọn hoặc biểu mẫu đăng ký sự kiện có ghi chú hoặc thẻ tùy chỉnh.
Dàn dựng dữ liệu để xác thực	Một vùng giữ tạm thời trước khi đồng bộ hóa dữ liệu với các bảng quan hệ. Ví dụ: dữ liệu khách hàng tiềm năng đã nhập đang chờ loại bỏ trùng lặp và xác thực trước khi được thêm vào bảng Khách hàng tiềm năng chính.
Dữ liệu nhạy cảm về thời gian hoặc sắp hết hạn	Sử dụng TTL (Thời gian tồn tại) để tự động xóa các bản ghi CRM tạm thời. Ví dụ: mã giảm giá khuyến mại gắn với chiến dịch, liên kết truy cập một lần cho khảo sát khách hàng hoặc cổng giới thiệu và phản hồi khảo sát tạm thời.
Dữ liệu hàng loạt được phân vùng	Phân vùng dữ liệu theo ID hoặc danh mục để cải thiện hiệu suất và khả năng mở rộng. Ví dụ: phân vùng theo ID tài khoản hoặc ID khu vực trong quá trình di chuyển dữ liệu hàng loạt hoặc phân đoạn nhật ký hoạt động của khách hàng theo ID chiến dịch để phân tích.

Kiểu dữ liệu không phù hợp với bảng đàn hồi

Bảng linh hoạt được tối ưu hóa cho các tình huống linh hoạt, quy mô lớn—nhưng không phải loại dữ liệu nào cũng phù hợp. Phần này nêu bật các mẫu dữ liệu CRM phổ biến được lưu trữ tốt hơn ở nơi khác để đảm bảo hiệu suất, hiệu quả chi phí và khả năng bảo trì. Tìm hiểu thêm về các tính năng hiện không được hỗ trợ với bảng linh hoạt

Loại dữ liệu	Reason
Dữ liệu có quan hệ cao	Bảng đàn hồi không hỗ trợ nối hoặc tra cứu
Hồ sơ quan trọng của doanh nghiệp	Không có tính toàn vẹn giao dịch hoặc hỗ trợ plugin
Dữ liệu yêu cầu xác thực phức tạp	Xử lý tốt hơn trong các bảng tiêu chuẩn với các quy tắc công việc

Phân đoạn dữ liệu chức năng và khung lưu trữ

Lập kế hoạch kỹ thuật hiệu quả bao gồm lựa chọn các công cụ và cơ sở hạ tầng phù hợp, điều chỉnh khối lượng dữ liệu nguồn và đích, đồng thời thiết lập các quy trình kiểm tra và đối chiếu. Nhiều thao tác di chuyển trở nên phức tạp do thiếu phân tích trước, đặc biệt là về những dữ liệu cần di chuyển và vị trí của dữ liệu. Phần này phác thảo các nguyên tắc cốt lõi của phân tích dữ liệu để hỗ trợ quá trình di chuyển thành công.

Phân đoạn dữ liệu

Phân đoạn dữ liệu là một bước quan trọng trong việc di chuyển từ một hệ thống CRM sang Dataverse. Sắp xếp bảng dữ liệu theo chức năng kinh doanh—chẳng hạn như bán hàng, dịch vụ hoặc tiếp thị—để đơn giản hóa việc lập kế hoạch và thực hiện di chuyển.

Phân đoạn bảng

Bắt đầu bằng cách liệt kê tất cả các bảng đủ điều kiện để di chuyển, được nhóm theo lĩnh vực kinh doanh (ví dụ: bán hàng, tiếp thị, dịch vụ). Sau đó:

Ghi lại lược đồ trong Excel hoặc một công cụ tương tự.
Chạy các truy vấn cơ bản trong hệ thống nguồn để kiểm tra mức sử dụng cột.
Gắn cờ các cột ít sử dụng. Nếu ít hơn 5% hồ sơ chứa các giá trị, hãy tham khảo ý kiến của các bên liên quan trong kinh doanh để quyết định giữ lại hay loại bỏ chúng.

Phân tích đơn giản này có thể giảm đáng kể phạm vi di chuyển. Trong các hệ thống CRM chạy lâu dài, thông thường loại bỏ 30–40% cột và tối đa 20% bảng, hợp lý hóa quy trình và cải thiện hiệu suất.

Mức độ liên quan của cột

Một số cột hệ thống nguồn ánh xạ trực tiếp đến Dataverse, trong khi những cột khác trở thành trường được tính toán. Tách các cột này và tham khảo ý kiến của các bên liên quan trong kinh doanh để quyết định xem có cần công việc di chuyển hay không.

Bỏ qua các cột chỉ có liên quan trong hệ thống nguồn hoặc không có ý nghĩa trong mục tiêu. Điều này bao gồm nhiều trường có sẵn như Tạo bởi, Sửa đổi bởi hoặc Số phiên bản hàng, trừ khi chúng phục vụ mục đích cụ thể trong quá trình di chuyển của bạn.

Dữ liệu loại tệp

Nếu hệ thống nguồn của bạn bao gồm dữ liệu loại tệp, hãy gắn cờ sớm các trường này và lập kế hoạch di chuyển riêng biệt. Hãy xem xét các loại tệp sau:

Tài liệu Office (ví dụ: Word, Excel, PowerPoint): Đối với tối đa 20.000 tệp, hãy di chuyển sang nền tảng cộng tác như SharePoint để cho phép truy nhập nhiều người dùng.
Tệp đa phương tiện (ví dụ: hình ảnh, video): Chọn nền tảng hỗ trợ phát lại. Các tùy chọn bao gồm SharePoint, dịch vụ phát trực tuyến hoặc các giải pháp lưu trữ thân thiện với phương tiện khác.
Khối lượng hoặc kích thước tệp lớn: Nếu chi phí lưu trữ là mối quan tâm, hãy sử dụng Lưu trữ Azure Blob hoặc cột tệp gốc trong Dataverse, sử dụng Azure Blob đằng sau hậu trường.
Bảo vệ chống phần mềm độc hại: Chạy tệp thông qua công cụ phát hiện phần mềm độc hại (ví dụ: Azure Advanced Threat Protection) trước khi di chuyển để đảm bảo bảo mật.

Sau khi xem xét mức độ liên quan của tệp, bạn thường thấy rằng tổng khối lượng dữ liệu giảm đáng kể—đặc biệt là trong các hệ thống CRM chạy lâu dài—giúp việc di chuyển hiệu quả hơn.

Chiến lược lưu trữ dữ liệu

Một số dữ liệu—như email cũ, trường hợp đã đóng hoặc khách hàng tiềm năng bị loại—vẫn quan trọng nhưng hiếm khi được truy cập. Để giảm khối lượng di chuyển mà không làm gián đoạn hoạt động kinh doanh, hãy phát triển chiến lược lưu trữ thông minh.

Bước 1: Xác định dữ liệu có thể lưu trữ

Các ứng cử viên phổ biến bao gồm:

Email cũ hơn ba năm
Các trường hợp đã đóng
Cơ hội bị mất
Khách hàng tiềm năng bị loại
Email tiếp thị, bài đăng và nhật ký kiểm tra

Xem lại hệ thống của bạn để xác định các bảng khác mà bạn có thể lưu trữ.

Bước 2: Chọn phương pháp lưu trữ

Giữ dữ liệu trong hệ thống nguồn. Giữ lại một vài giấy phép quản trị để truy cập trong khi hủy kích hoạt các giấy phép khác để giảm chi phí.
Chuyển sang bộ nhớ ngoài. Sử dụng cơ sở dữ liệu cục bộ, Lưu trữ Azure Blob hoặc Bảng Azure để lưu trữ các bản ghi đã lưu trữ. Cách tiếp cận này giúp giảm chi phí lưu trữ và di chuyển nhưng yêu cầu một chiến lược di chuyển riêng biệt.
Sử dụng môi trường Dataverse riêng biệt. Tùy chọn này ít phổ biến hơn, nhưng nó hữu ích nếu bạn muốn cô lập dữ liệu đã lưu trữ. Bạn có thể ngừng sử dụng môi trường này sau này để đơn giản hóa việc lập kế hoạch chuyển nhượng.

Cơ sở hạ tầng di chuyển dữ liệu được đề xuất

Để đảm bảo di chuyển dữ liệu nhanh chóng và đáng tin cậy vào Dataverse:

Sử dụng máy ảo (VM) trong cùng khu vực với môi trường Dataverse của bạn để giảm độ trễ và cải thiện tốc độ di chuyển.
Chọn một máy ảo hiệu suất cao. Tối thiểu, sử dụng máy ảo D4 với tám lõi, RAM 28 GB và bộ nhớ 500 GB để xử lý khối lượng dữ liệu lớn một cách hiệu quả.
Ưu tiên cơ sở dữ liệu cục bộ trên máy ảo. Tránh kết nối từ xa trong quá trình di chuyển. Nếu bạn sử dụng Azure Data Factory, hãy triển khai nó trong cùng khu vực với môi trường Dataverse của bạn để có hiệu suất tối ưu.

Bước tiếp theo

Theo dõi Power Platform Well-Architected để có kiến trúc xuất sắc

Phản hồi

Trang này có hữu ích không?

Last updated on 2025-10-03