AWS Study Group

Di chuyển từ SQL Server sang Amazon DynamoDB bằng cách chuyển đổi dữ liệu bằng bảng phân tầng

Với sự phát triển của kiến ​​trúc dựa trên vi dịch vụ, các tổ chức ngày càng áp dụng cơ sở dữ liệu được xây dựng có mục đích. Đôi khi, các doanh nghiệp cần được hướng dẫn về dịch vụ và giải pháp đám mây nào phù hợp nhất với họ cũng như kế hoạch trợ giúp di chuyển. Khi thực hiện di chuyển cơ sở dữ liệu không đồng nhất, bạn có thể gặp phải sự cố với các mẫu thuộc tính trên NoSQL so với các hệ thống quản lý cơ sở dữ liệu quan hệ (RDBMS) truyền thống như tái cấu trúc các thuộc tính bảng và cột truyền thống từ SQL Server tự quản lý của bạn sang các mẫu truy cập Amazon DynamoDB .

Động lực chính để di chuyển sang DynamoDB là giảm chi phí đồng thời đơn giản hóa hoạt động và cải thiện hiệu suất trên quy mô lớn. DynamoDB cho phép bạn giải phóng tài nguyên để góp phần tăng doanh thu và giá trị hàng đầu cho khách hàng của mình. Kiến trúc không có máy chủ của nó cho phép bạn tiết kiệm chi phí với các khả năng như trả tiền cho mỗi yêu cầu, mở rộng quy mô về 0 và không có chi phí trả trước. Về mặt vận hành, việc không phải xử lý các vấn đề về mở rộng tài nguyên, thời gian bảo trì hoặc nâng cấp phiên bản chính giúp tiết kiệm đáng kể thời gian vận hành và loại bỏ các công việc nặng nhọc không phân biệt. Nhìn chung, DynamoDB cung cấp cách tiếp cận tối ưu hóa chi phí để xây dựng các giải pháp sáng tạo và đột phá nhằm mang lại trải nghiệm khác biệt cho khách hàng.

Mỗi ứng dụng đều có một mẫu yêu cầu cụ thể để đáp ứng trường hợp sử dụng kinh doanh, cho dù đó là NoSQL, SQL truyền thống (RDBMS) hay cả hai. Khối lượng công việc từ các ứng dụng giao tiếp với máy chủ cơ sở dữ liệu thuộc một trong các loại này (đọc hoặc ghi). Trong bài đăng này, chúng tôi thảo luận về các mẫu truy cập nhấn mạnh vào việc viết hơn là đọc. Chúng tôi xem xét thiết kế các mẫu truy cập và di chuyển thành công bảng SQL Server thông thường (quan hệ) sang DynamoDB (không quan hệ) cho ứng dụng vi dịch vụ bằng cách sử dụng Dịch vụ di chuyển cơ sở dữ liệu AWS (AWS DMS).

Bất kỳ ứng dụng vi dịch vụ nào muốn chuyển từ bảng nguyên khối nhỏ hoặc lớn trong RDBMS sang DynamoDB (NoSQL) đều có thể sử dụng giải pháp này.

Tổng quan về giải pháp

Giải pháp của chúng tôi liên quan đến việc sử dụng bảng tham chiếu được tạo trên Máy chủ SQL tự quản lý trên Đám mây điện toán đàn hồi của Amazon (Amazon EC2). Bảng tham chiếu được xây dựng bằng cách phân tích các mẫu truy cập dữ liệu và thực hiện ánh xạ thuộc tính trong DynamoDB. Sau khi thiết lập mẫu thiết kế, chúng tôi cung cấp cho bảng DynamoDB khóa chính và khóa sắp xếp thích hợp để ánh xạ bảng tham chiếu. Sau đó, chúng tôi sử dụng AWS DMS để di chuyển dữ liệu và thiết lập sao chép liên tục từ điểm cuối nguồn được ánh xạ tới bảng tham chiếu này trong SQL Server sang bảng DynamoDB đích.

Sơ đồ sau đây minh họa kiến ​​trúc.

Quy trình làm việc của giải pháp bao gồm các bước sau:

  1. Kết nối với phiên bản SQL Server tự quản lý của bạn và xem các bảng nguồn quan hệ sẽ được chuyển sang bảng DynamoDB.
  2. Vì bảng nguồn SQL tuân thủ các tiêu chuẩn SQL truyền thống và không khớp với các thuộc tính của DynamoDB nên chúng tôi sử dụng tập lệnh tùy chỉnh để chuyển đổi bảng nguồn thành bảng phân tầng phù hợp với chất lượng của DynamoDB. Một bảng phân tầng mới được tạo trong SQL Server và dữ liệu được thêm vào bằng các tập lệnh tùy chỉnh như sau:
    1. Tải một lần (tải đầy đủ) – Bạn có thể chạy tập lệnh đặc biệt để điền vào bảng phân tầng nếu bạn chỉ muốn thực hiện truyền dữ liệu một lần từ bảng nguồn.
    2. Thu thập dữ liệu thay đổi (CDC) – Khi theo dõi các thay đổi theo thời gian thực trên bảng nguồn, trình kích hoạt gốc SQL (INSERT) được tạo trên bảng nguồn để chèn các thay đổi vào bảng phân tầng. Bài đăng này chỉ nói về thao tác INSERT trên bảng nguồn. Trong các trường hợp sử dụng khác, nếu có các điều kiện để giải quyết CHÈN, CẬP NHẬT hoặc XÓA, bạn nên tạo các trình kích hoạt tương ứng.
  3. Bảng phân tầng được ánh xạ dưới dạng nguồn từ SQL Server.
  4. Tạo bảng trong DynamoDB bằng khóa phân vùng và khóa sắp xếp tương ứng với các thuộc tính trên bảng phân tầng SQL.
  5. Sử dụng AWS DMS để di chuyển dữ liệu từ SQL Server nguồn sang DynamoDB đích. Để di chuyển dữ liệu, hãy ánh xạ bảng phân tầng SQL Server làm nguồn và bảng DynamoDB làm đích. Với sự hỗ trợ của trình kích hoạt gốc SQL, chúng tôi sử dụng cả tải đầy đủ và CDC trong kịch bản của mình để lấy dữ liệu thời gian thực từ bảng phân tầng nguồn SQL Server.

Chúng tôi sử dụng AWS Secrets Manager để lưu trữ thông tin xác thực SQL trong AWS DMS và sử dụng Amazon CloudWatch để giám sát tác vụ AWS DMS.

Các bước thực hiện giải pháp như sau:

  1. Định cấu hình chính sách và vai trò AWS Identity and Access Management (IAM).
  2. Định cấu hình các mẫu truy cập DynamoDB và chỉ mục phụ toàn cầu (GSI).
  3. Tạo bảng DynamoDB.
  4. Định cấu hình ánh xạ bảng SQL Server.
  5. Di chuyển dữ liệu bằng AWS DMS.
  6. Xác minh dữ liệu đã di chuyển trong DynamoDB.
  7. Giám sát tác vụ di chuyển AWS DMS.

Điều kiện tiên quyết

Để theo dõi bài đăng, bạn phải có các điều kiện tiên quyết sau:

Vì bài đăng này khám phá các mẫu truy cập và ánh xạ thuộc tính tới DynamoDB (NoSQL) từ SQL Server (RDBMS), nên cần có hiểu biết cơ bản về các khái niệm cốt lõi của DynamoDB và các mẫu thiết kế của nó. Ngoài ra, bạn nên có kiến ​​thức về AWS DMS liên quan đến việc định cấu hình nguồn SQL Server và mục tiêu DynamoDB .

Định cấu hình chính sách và vai trò IAM

Hoàn thành các bước sau để đặt cấu hình chính sách IAM và vai trò cho DynamoDB:

  1. Trên bảng điều khiển IAM, chọn Chính sách trong ngăn điều hướng.
  2. Chọn Tạo chính sách .
  3. Chọn JSON và sử dụng chính sách sau làm mẫu, thay thế ARN DynamoDB bằng Khu vực, số tài khoản và tên bảng DynamoDB chính xác:
  4. Trong ngăn điều hướng, chọn Vai trò .
  5. Chọn Tạo vai trò .
  6. Chọn AWS DMS , sau đó chọn Tiếp theo: Quyền .
  7. Chọn chính sách bạn đã tạo.
  8. Gán tên vai trò rồi chọn Tạo vai trò .

Định cấu hình các mẫu truy cập DynamoDB và GSI

Các bảng DynamoDB thường được tạo dựa trên tính duy nhất của khóa chính để đáp ứng các mẫu truy cập ứng dụng hoặc doanh nghiệp. Khóa phân vùng và khóa sắp xếp được kết hợp để tạo thành khóa chính.

Mẫu truy cập

Trong trường hợp sử dụng hiện tại, chúng tôi sử dụng bảng SQL ( tbl_StatusHistory_log) làm nguồn để chuyển sang DynamoDB. Vì chúng tôi nhấn mạnh vào khối lượng công việc ghi (INSERT), khóa phân vùng phải dựa trên mẫu truy cập ghi so với mẫu đọc. Ảnh chụp màn hình sau đây hiển thị các cột trong bảng nguồn RowIDcó khóa chính.

Chúng ta phải phát triển một mẫu phù hợp với ứng dụng vi dịch vụ vì RowIDsẽ không cung cấp mẫu riêng biệt cho các ứng dụng trên DynamoDB. Khóa phân vùng có sự kết hợp của các cột ( Usr_ID, account_id,và silo_id) để cung cấp các mẫu truy cập có ý nghĩa hơn trên DynamoDB, nhưng sự kết hợp này có thể không phải là duy nhất vì bảng ( tbl_StatusHistory_log) có thể có nhiều account_idvà silo_idgiá trị cho cùng một người dùng.

Để làm cho khóa chính DynamoDB trở thành duy nhất, tốt nhất nên kết hợp khóa phân vùng với khóa sắp xếp. Vì RowIDnó đã là duy nhất trong bảng nguồn nên chúng tôi sử dụng nó làm khóa sắp xếp. Bảng sau đây cho thấy cách chúng tôi có thể mở rộng mẫu hình truy cập trên các đối số ứng dụng (nhu cầu truy vấn) miễn là tính duy nhất của bảng được giữ nguyên. Các cột bổ sung ( Status_Code, Reason_Code,và Status_Date) được thêm vào khóa phân vùng để cho phép tìm kiếm ứng dụng mở rộng thuộc tính.

Bảng tóm tắt các thông tin sau:

  • Đối số đầu vào – Kịch bản lý tưởng về cách ứng dụng có thể cung cấp đối số đầu vào cho DynamoDB để truy vấn
  • Thuộc tính được trả về – Nếu bảng DynamoDB sẽ cung cấp tất cả thuộc tính dưới dạng kết quả hoặc cột cụ thể (dựa trên truy vấn ứng dụng)
  • Tần suất – Tần suất các yêu cầu ứng dụng xuất hiện đối với các đối số
  • Hoạt động của DynamoDB – Các trường hợp sử dụng phổ biến nhất cho các yêu cầu ứng dụng
  • Bảng – Các tùy chọn bảng (cơ sở hoặc GSI)

Ảnh chụp màn hình sau đây mô tả trực quan về khóa phân vùng và khóa sắp xếp, tạo nên khóa chính. Ngoài ra, phần Thuộc tính khác liệt kê tất cả các cột từ nguồn ban đầu sẽ là một phần của kết quả đầu ra trong DynamoDB.

Chỉ số phụ toàn cầu

Thuộc GSI-PKtính đã được thêm vào bảng cơ sở để cải thiện hiệu suất truy vấn khối lượng công việc đọc vì chỉ mục GSI có thể mở rộng tất cả dữ liệu trong bảng cơ sở trên tất cả các phân vùng. GSI-PKlà sự kết hợp của các cột ( Usr_Idvà silo_Id) tương đương với khóa phân vùng của bảng cơ sở nhưng không bao gồm account_Id. Một lợi ích khác của GSI là bạn có thể chọn không đưa tất cả các thuộc tính dự đoán vào kết quả. Trong mô hình thiết kế sau đây, chúng tôi cung cấp khóa phân vùng GSI và khóa sắp xếp cùng với các thuộc tính làm ví dụ.

Tạo bảng DynamoDB

Sử dụng mã sau đây để tạo bảng DynamoDB bằng AWS CLI . Chúng tôi gọi bảng là DDB_StatusHistory_Logs. PK và SK lần lượt được định nghĩa là tên thuộc tính cho khóa phân vùng và khóa sắp xếp.

Sau khi bạn chạy các lệnh, hãy đợi bảng được tạo. Bạn có thể xác minh bảng DynamoDB đã được tạo thông qua AWS CLI.

Định cấu hình ánh xạ bảng SQL Server

Trong phần này, chúng ta sẽ hướng dẫn các bước để định cấu hình ánh xạ bảng SQL Server. Chúng tôi tạo các bảng SQL nguồn và dàn dựng, điền vào bảng nguồn để kiểm tra, tạo tập lệnh để tải một lần vào bảng dàn dựng và tạo trình kích hoạt INSERT bảng SQL.

Tạo bảng SQL nguồn và dàn dựng

Đối với ví dụ tham khảo của chúng tôi, chúng tôi có hai bảng SQL Server để thực hiện di chuyển. Trong đoạn mã sau, chúng ta tạo một cơ sở dữ liệu mới có tên là dmsload. Chúng tôi tạo bảng nguồn tbl_StatusHistory_logđóng vai trò là dữ liệu cơ sở cho tải AWS DMS và bảng phân tầng DDB_StatusHistory_DMSLoadmà chúng tôi sử dụng làm bảng tham chiếu cho AWS DMS để ánh xạ các thuộc tính chính được xác định trong DynamoDB.

Vì bảng phân tầng đóng vai trò là nguồn cấp dữ liệu cho DynamoDB nên các thuộc tính thông thường sẽ được sao chép từ bảng cơ sở sang bảng phân tầng. PK, SKvà GSI-PKlà các cột chính tạo thành mẫu truy cập duy nhất trên DynamoDB. Các tập lệnh sau minh họa việc tải dữ liệu trong bảng phân tầng.

Điền vào bảng nguồn để thử nghiệm

Sử dụng đoạn mã sau để điền dữ liệu thử nghiệm vào bảng nguồn ( tbl_StatusHistory_log) trên SQL Server:

Tạo tập lệnh để tải một lần vào bảng phân tầng

Chúng tôi sử dụng tập lệnh đặc biệt để điền DDB_StatusHistory_DMSLoaddữ liệu vào bảng phân tầng ( ) nhằm khớp với mẫu truy cập cho DynamoDB. Trong phần mã, bạn có thể tìm thấy các tập lệnh ánh xạ mẫu truy cập DynamoDB bằng cách sử dụng mệnh đề UNION tham chiếu bảng nguồn ( tbl_StatusHistory_log).

Đầu ra từ bảng phân tầng ( DDB_StatusHistory_DMSLoad) hiển thị dữ liệu đã được chuyển đổi để ánh xạ mẫu truy cập trên DynamoDB. Bạn có thể quan sát sự hình thành PKvà GSI-PKmô hình.

Tạo trình kích hoạt bảng SQL (INSERT)

Nếu bạn có các ứng dụng không thể có thời gian ngừng hoạt động lâu hơn và cần theo dõi các thay đổi theo thời gian thực trên bảng nguồn, bạn có thể tạo trình kích hoạt gốc SQL (INSERT) trên bảng nguồn ( tbl_StatusHistory_log) để chèn các thay đổi vào bảng phân tầng ( DDB_StatusHistory_DMSLoad). Trình kích hoạt bảng (sau INSERT) tuân theo cách tiếp cận mẫu truy cập tương tự cho các tập lệnh tải đầy đủ (ad hoc). Sau khi hoàn thành toàn bộ tải thông qua AWS DMS, bạn có thể thả trình kích hoạt vào bảng nguồn trong SQL Server.

Di chuyển dữ liệu bằng AWS DMS

Bây giờ chúng ta đã thiết lập bảng phân tổ SQL Server, bạn có thể di chuyển dữ liệu từ bảng phân tổ SQL Server nguồn sang bảng DynamoDB đích.

Để bắt đầu làm việc với AWS DMS, hãy tạo phiên bản sao chép AWS DMS . Phiên bản này phải có đủ bộ nhớ và khả năng xử lý để di chuyển dữ liệu từ cơ sở dữ liệu nguồn sang cơ sở dữ liệu đích. Để biết thông tin về cách chọn phiên bản thích hợp, hãy tham khảo Làm việc với phiên bản sao chép AWS DMS .

Tạo điểm cuối AWS DMS

Tiếp theo, tạo điểm cuối AWS DMS cho cơ sở dữ liệu nguồn và đích. Điểm cuối AWS DMS cung cấp kết nối, loại kho dữ liệu và thông tin vị trí về kho dữ liệu của bạn.

Điểm cuối nguồn

Hoàn thành các bước sau để tạo điểm cuối nguồn của bạn:

  1. Trên bảng điều khiển AWS DMS, tạo điểm cuối nguồn.
  2. Đối với Mã định danh điểm cuối , hãy nhập tên.
  3. Đối với Source engine , chọn Microsoft SQL Server .
  4. Đối với Truy cập vào điểm cuối , hãy chọn Cung cấp thông tin truy cập theo cách thủ công .
  5. Đối với Server name , nhập tên máy chủ SQL Server.
  6. Đối với Cổng , nhập số cổng đang được sử dụng.
  7. Nhập tên người dùng và mật khẩu thích hợp.
  8. Nhập tên cơ sở dữ liệu thích hợp.
  9. Kiểm tra điểm cuối, sau đó hoàn tất việc tạo điểm cuối.

Điểm cuối mục tiêu

Lặp lại các bước trước đó với các tham số sau cho điểm cuối đích:

  1. Đối với Mã định danh điểm cuối , hãy nhập tên.
  2. Đối với Target engine , chọn Amazon DynamoDB .
  3. Đối với Tên tài nguyên Amazon (ARN) dành cho vai trò truy cập dịch vụ , hãy nhập vai trò IAM .
  4. Kiểm tra điểm cuối, sau đó hoàn tất việc tạo điểm cuối.

Tạo tác vụ di chuyển AWS DMS

Nhiệm vụ AWS DMS là nơi diễn ra tất cả công việc. Đây là nơi bạn định cấu hình những đối tượng cơ sở dữ liệu nào sẽ di chuyển, yêu cầu ghi nhật ký, xử lý lỗi, v.v. Hoàn thành các bước sau để tạo nhiệm vụ của bạn:

  1. Trên bảng điều khiển AWS DMS, tạo tác vụ di chuyển mới.
  2. Đối với Mã định danh nhiệm vụ , hãy nhập tên có thể nhận dạng.
  3. Đối với Phiên bản sao chép , hãy chọn phiên bản sao chép mà bạn đã tạo.
  4. Đối với Điểm cuối cơ sở dữ liệu nguồn , hãy chọn điểm cuối SQL Server mà bạn đã tạo.
  5. Đối với Điểm cuối cơ sở dữ liệu đích , hãy chọn điểm cuối DynamoDB mà bạn đã tạo.
  6. Đối với Loại di chuyển , hãy chọn Di chuyển dữ liệu hiện có và sao chép các thay đổi đang diễn ra .
  7. Bật Nhật ký CloudWatch trong cài đặt tác vụ để bạn có thể gỡ lỗi sự cố.
  8. Trong phần Ánh xạ bảng , đối với chế độ Chỉnh sửa , hãy chọn trình soạn thảo JSON .
  9. Sử dụng JSON sau đây để tạo ánh xạ bảng:

JSON có hai phần (lựa chọn và ánh xạ). Bảng SQL ( DDB_StatusHistory_DMSLoad) đóng vai trò thực hiện việc lựa chọn nguồn và ánh xạ đối tượng với bảng đích là bảng DynamoDB ( DDB_StatusHistory_Logs) với PK(khóa phân vùng) và SK(khóa sắp xếp) làm tham số ánh xạ khóa. Trong kịch bản của chúng tôi, các giá trị thuộc tính được khớp với giá trị khóa của bảng nguồn SQL ${PK}và ${SK}.

  1. Để mọi thứ khác làm mặc định và chọn Tạo tác vụ .

Ngay sau khi tác vụ được tạo, tác vụ đó sẽ ở trạng thái Đang tạo. Sau vài giây, nó sẽ chuyển sang trạng thái Sẵn sàng. Quá trình di chuyển (và CDC nếu được bật) bắt đầu tự động.

Xác minh dữ liệu đã di chuyển trong DynamoDB

Sau khi tải xong, hãy điều hướng đến tab Thống kê bảng . Ảnh chụp màn hình sau đây cho thấy quá trình tải toàn bộ đã hoàn tất thành công.

Bạn cũng có thể kiểm tra dữ liệu cho CDC bằng cách chèn bản ghi vào bảng cơ sở dbo.tbl_StatusHistory_logtrên cơ sở dữ liệu SQL Server:

Dữ liệu tham chiếu đã được chèn thành công vào bảng cơ sở tbl_StatusHistory_logvà bảng phân tầng DDB_StatusHistory_DMSLoad.

Điều hướng đến tab Thống kê bảng như trong ảnh chụp màn hình sau. Ở đây chúng ta thấy tổng số hàng và số lần chèn tăng lên.

Bây giờ hãy truy cập DynamoDB và kiểm tra xem các bản ghi đã được chèn thành công và chính xác chưa.

AWS CLI cho thấy một trong các bản ghi mục đã được chèn vào bảng DynamoDB.

Giám sát các tác vụ sao chép AWS DMS

Đặc biệt đối với những lần di chuyển lớn, việc giám sát là rất quan trọng để duy trì tính nhất quán, khả năng sử dụng và hiệu suất của AWS DMS.

AWS cung cấp nhiều loại công cụ khác nhau để giám sát các tác vụ AWS DMS của bạn. Ví dụ: bạn có thể sử dụng CloudWatch để thu thập, theo dõi và giám sát tài nguyên AWS bằng số liệu. Điều quan trọng là phải đảm bảo rằng các tác vụ được tạo bằng các quy tắc ánh xạ cần thiết trên các lược đồ và đối tượng cơ sở dữ liệu. Tham khảo các tài nguyên sau để biết thêm chi tiết về kỹ thuật giám sát và những điều cần chú ý khi giám sát nhiệm vụ AWS DMS:

Dọn dẹp

Để tránh những khoản phí không cần thiết, hãy dọn sạch mọi tài nguyên không còn được sử dụng mà bạn đã xây dựng như một phần của kiến ​​trúc này. Điều này bao gồm việc dừng phiên bản EC2 , xóa chính sách IAM và xóa các bảng DynamoDB cũng như tài nguyên AWS DMS giống như phiên bản sao chép mà bạn đã tạo trong bài đăng này. Ngoài ra, sau khi quá trình di chuyển hoàn tất, nếu không cần giữ lại cơ sở dữ liệu hoặc bảng SQL Server nguồn, bạn có thể loại bỏ chúng.

Phần kết luận

Trong bài đăng này, bạn đã tìm hiểu cách di chuyển dữ liệu từ SQL Server sang DynamoDB bằng AWS DMS với tính năng chuyển đổi dữ liệu bằng bảng phân tầng. Cách tiếp cận mà chúng tôi đã mô tả để tạo bảng phân tầng SQL Server dành riêng cho các mẫu truy cập dữ liệu trong ví dụ về trường hợp sử dụng của chúng tôi. Bạn có thể sử dụng phương pháp này để tạo bất kỳ bảng RDBMS nào và xác định các thuộc tính theo mẫu truy cập dữ liệu bắt buộc của ứng dụng trên DynamoDB. Sau đó, bạn có thể sử dụng AWS DMS để di chuyển dữ liệu từ bảng phân tầng SQL Server nguồn sang bảng DynamoDB đích và thiết lập sao chép liên tục để giảm thiểu thời gian ngừng hoạt động trong quá trình di chuyển.

Nếu bạn có bất kỳ câu hỏi hoặc đề xuất nào, hãy để lại phản hồi của bạn trong phần bình luận.

Giới thiệu về tác giả

Karthick Jayavelu là Chuyên gia tư vấn cơ sở dữ liệu cấp cao tại Amazon Web Services. Anh làm việc với các khách hàng của AWS để cung cấp hỗ trợ kỹ thuật và thiết kế các giải pháp cho khách hàng trong các dự án cơ sở dữ liệu, cũng như giúp họ trong hành trình di chuyển và hiện đại hóa các giải pháp cơ sở dữ liệu từ cơ sở sang AWS.

Poulami Maity là Kiến trúc sư giải pháp chuyên gia cơ sở dữ liệu tại Amazon Web Services. Cô làm việc với khách hàng của AWS để giúp họ di chuyển và hiện đại hóa cơ sở dữ liệu hiện có lên Đám mây AWS.

Vanshika Nigam là Kiến trúc sư giải pháp thuộc nhóm Tăng tốc di chuyển cơ sở dữ liệu tại Amazon Web Services và có hơn 5 năm kinh nghiệm về Amazon RDS. Cô làm cố vấn cho Amazon DMA để giúp khách hàng AWS đẩy nhanh quá trình di chuyển cơ sở dữ liệu thương mại tại chỗ của họ sang các giải pháp cơ sở dữ liệu Đám mây AWS.

←
→

Leave a comment