Điều chỉnh hiệu năng sao chép với AWS DMS cho điểm cuối mục tiêu của Amazon Kinesis Data Streams – Phần 1

Tác giả: Siva Thang, Michael Newlin, Suchindranath Hegde, Wanchen Zhao và Jay Chen | vào 03 MAY 2024 | in Nâng cao (300), AWS Database Migration Service, Kinesis Data Streams, Hướng dẫn kỹ thuật | Liên kết cố định |  Bình luận |  Chia sẻ

AWS Database Migration Service (AWS DMS) cho phép sao chép sang Amazon Kinesis Data Streams từ cơ sở dữ liệu quan hệ, kho dữ liệu, cơ sở dữ liệu NoSQL và các loại kho dữ liệu khác. Bạn có thể sử dụng luồng dữ liệu Kinesis để thu thập và xử lý các luồng bản ghi dữ liệu lớn theo thời gian thực.

Việc sao chép các thay đổi dữ liệu sang luồng dữ liệu Kinesis thường được kỳ vọng sẽ kéo dài và hiệu suất cao. AWS DMS cung cấp các cài đặt tác vụ thu thập dữ liệu (CDC) đa luồng, tải đầy đủ và thay đổi để giúp tăng tốc độ truyền dữ liệu và hiệu năng của CDC.

Khách hàng thường hỏi những câu hỏi sau khi điều chỉnh hiệu năng cho mục tiêu Kinesis Data Streams:

• Những điều cần cân nhắc khi điều chỉnh và cho điểm cuối mục tiêu Kinesis Data Streams là gì?ParallelLoad*ParallelApply*
• Làm cách nào để điều chỉnh tải song song hoặc áp dụng các tham số và tác vụ AWS DMS cho một khối lượng công việc CSDL nguồn nhất định?ParallelLoad*ParallelApply*
• Tôi có nên sử dụng nhiều phân đoạn luồng dữ liệu Kinesis hơn để cải thiện hiệu năng sao chép không?

Loạt bài này bao gồm ba phần. Trong bài đăng đầu tiên này, chúng tôi thảo luận về các cài đặt đa luồng đầy tải và CDC cũng như những điều cần cân nhắc để điều chỉnh các thông số liên quan nhằm tăng hiệu năng tốt hơn nhằm sao chép sang mục tiêu Kinesis Data Streams. Trong bài đăng thứ hai, chúng tôi cung cấp bản trình diễn về điều chỉnh hiệu năng AWS DMS cho mục tiêu Kinesis Data Streams với cài đặt đa luồng. Trong bài đăng thứ ba, chúng tôi chia sẻ một số điều cần cân nhắc và các phương pháp tốt nhất khác để sử dụng Kinesis Data Streams làm mục tiêu.

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

AWS DMS hỗ trợ toàn bộ tải và CDC từ bất kỳ nguồn được hỗ trợ đến mục tiêu Kinesis Data Streams thông qua các cặp giá trị thuộc tínhị trong JSON. Bạn có thể sử dụng ánh xạ đối tượng AWS DMS để di chuyển dữ liệu từ nguồn dữ liệu được hỗ trợ sang luồng dữ liệu mục tiêu của Kinesis. Luồng dữ liệu Kinesis được tạo thành từ các phân đoạn. Bạn có thể xác định khóa phân vùng cho mỗi bảng trong tác vụ DMS mà Kinesis Data Streams sử dụng để nhóm dữ liệu thành các phân đoạn của nó.

Trong giai đoạn tải đầy đủ, như minh họa trong hình dưới đây, AWS DMS tải các bảng song song với mục tiêu Kinesis Data Streams. Các bảng tối đa để tải song song được xác định bởi cài đặt tác vụ AWS DMS . AWS DMS tải từng bảng vào phân đoạn mục tiêu tương ứng bằng cách sử dụng một nhiệm vụ con chuyên dụng. Theo mặc định, AWS DMS tải song song tám bảng; tối đa là 49 bảng. Khóa phân vùng mặc định được sử dụng bởi tác vụ DMS đang trong giai đoạn tải đầy đủ. Bạn có thể chọn chỉ định tham số ánh xạ đối tượng AWS DMS, nghĩa là cùng một bảng cùng một lược đồ của cơ sở dữ liệu nguồn sẽ được tải vào cùng một phân đoạn trong Kinesis Data Streams. MaxFullLoadSubTasks primary-key partition-key-type schema-table

Khi cài đặt tải song song được sử dụng trong giai đoạn tải đầy đủ hoặc cài đặt áp dụng song song được sử dụng trong giai đoạn CDC, AWS DMS sẽ tải dữ liệu và áp dụng các thay đổi trong đa luồng. Bạn có thể sử dụng tham số ánh xạ đối tượng AWS DMS để đặt khóa phân vùng cho mục tiêu. Theo mặc định, với cài đặt tác vụ hoặc được chỉ định, khóa chính của bảng được sử dụng cho khóa phân vùng trong giai đoạn tải đầy đủ hoặc CDC tương ứng. Khi dữ liệu hàng loạt trong giai đoạn tải đầy đủ hoặc bản ghi thay đổi có thể lập số sê-ri trong giai đoạn CDC đến, AWS DMS sẽ trích xuất khóa phân vùng và áp dụng hàm băm để phân phối tin nhắn đến tải song song tương ứng hoặc áp dụng hàng đợi. Theo khóa phân vùng được sử dụng, đặc biệt là khi phân phối thống kê của khóa bị lệch, một số hàng đợi có thể rất bận rộn, trong khi một số hàng đợi có thể tương đối nhàn rỗi. Như thể hiện trong hình sau, Qm (n-1) + 1 đầy, trong khi Qm + 2 và Qm + m trống. Số lượng bản ghi tối đa để lưu trữ trong mỗi hàng đợi đệm được chỉ định cho giai đoạn tải đầy đủ và cho giai đoạn CDC. AWS DMS sử dụng nhiều luồng để thăm dò ý kiến từ tải song song hoặc áp dụng hàng đợi. Số lượng luồng được xác định bởi trong giai đoạn tải đầy đủ và trong giai đoạn CDC. Một chuỗi chỉ thăm dò ý kiến từ một hàng đợi hoặc nhóm hàng đợi cụ thể. Số lượng hàng đợi cho mỗi luồng cần thăm dò được xác định bởi cài đặt tác vụ AWS DMS trong giai đoạn tải đầy đủ và trong giai đoạn CDC. Tổng số hàng đợi song song là × cho giai đoạn tải đầy đủ và × cho giai đoạn CDC. Xác định tổng số bản ghi trên mỗi lô để thực hiện PutRecords cho mục tiêu Kinesis Data Streams. Partition-key-type ParallelLoad* ParallelApply* ParallelLoadBufferSize ParallelApplyBufferSize ParallelLoadThreads ParallelApplyThreads ParallelLoadQueuesPerThread ParallelApplyQueuesPerThread ParallelLoadQueuesPerThread ParallelLoadThreads ParallelApplyQueuesPerThread ParallelApplyThreads Parallel*QueuesPerThread

Để biết thêm thông tin về tải song song và áp dụng cài đặt tác vụ, tham khảo Sử dụng Amazon Kinesis Data Streams làm mục tiêu cho AWS Database Migration Service.

Cân nhắc tải song song và áp dụng cài đặt

Trong phần này, chúng tôi thảo luận về những cân nhắc chính cho tải song song và áp dụng cài đặt.

Xác định xem thứ tự hồ sơ có cần được bảo quản hay không

Thay vì duy trì thứ tự nghiêm ngặt, bạn có thể nhận dữ liệu từ Kinesis Data Streams trên các phân đoạn khác nhau không theo thứ tự. Để đạt được hiệu năng cao, AWS DMS sử dụng API hàng loạt Kinesis cũng như đa luồng. Nếu thứ tự của tin nhắn phải được giữ nguyên, hãy xem xét các tùy chọn sau: PutRecords

• Nếu việc sắp xếp thứ tự tất cả các thao tác được liên kết với cùng một khóa chính, hãy sử dụng trong ánh xạ đối tượng AWS DMS và chỉ định một phân đoạn cho mục tiêu Kinesis mà không cần tải song song hoặc áp dụng cài đặt. Bằng cách này, AWS DMS sao chép các bản ghi dữ liệu trong một luồng theo cùng một thứ tự có thể tuần tự hóa như các giao mục tiêu được liên kết với cùng một khóa chính trong cơ sở dữ liệu nguồn sang cùng một phân đoạn Kinesis. Kinesis Data Streams có giới hạn API 1.000 TPS. Mỗi phân đoạn có thể hỗ trợ ghi tối đa 1.000 bản ghi mỗi giây và ghi dữ liệu tối đa là 1 MB mỗi giây. Để biết thêm chi tiết, hãy tham khảo Hạn ngạch và Giới hạn.schema-tableprimary-keyPutRecord
• Nếu việc sắp xếp thứ tự tất cả các thao tác cho các bảng riêng lẻ quan trọng, hãy sử dụng trong ánh xạ đối tượng AWS DMS và chỉ định một phân đoạn cho mục tiêu Kinesis mà không cần tải song song hoặc áp dụng cài đặt. Bằng cách này, AWS DMS sao chép các bản ghi dữ liệu trong một luồng theo cùng một thứ tự có thể tuần tự hóa như các giao mục tiêu được liên kết với cùng một bảng trong cơ sở dữ liệu nguồn sang cùng một phân đoạn Kinesis. Cũng lưu ý dung lượng của Kinesis mục tiêu được đề cập ở trên, đặc biệt là khi khối lượng công việc từ cơ sở dữ liệu nguồn chuyên sâu. schema-tablepartition-key-type
• Sử dụng cài đặt điểm cuối cho mục tiêu để cung cấp thông tin giao mục tiêu chi tiết từ cơ sở dữ liệu nguồn. Bạn có thể sử dụng thông tin như vị trí đăng nhập và ID giao mục tiêu để nhận ra thứ tự của các tin nhắn bằng ứng dụng xuôi dòng. Cách tiếp cận này phù hợp khi cơ sở dữ liệu nguồn có tính giao mục tiêu cao và các cài đặt tải và áp dụng song song được sử dụng để có hiệu suất tốt hơn. IncludeTransactionDetails

Hiểu khối lượng công việc của cơ sở dữ liệu nguồn

Kích thước dữ liệu và tỷ lệ giao mục tiêu xác định mức độ song song cần thiết để đạt được hiệu suất sao chép mong muốn. Thông thường, trong giai đoạn tải đầy đủ, bạn cần hiểu kích thước của bảng và số hàng trong bảng. Trong giai đoạn CDC, bạn cần hiểu số lượng bản ghi mỗi giây thay vì số lượng giao mục tiêu mỗi giây vì một giao mục tiêu có thể chứa nhiều bản ghi. Thông tin này được sử dụng để chỉ định tải song song và áp dụng cài đặt cho AWS DMS nhằm cải thiện hiệu năng sao chép.

Xác định số lượng phân đoạn và khóa phân vùng của mục tiêu

Đối với mục tiêu Kinesis Data Streams, mỗi phân đoạn cung cấp một đơn vị dung lượng cố định. Bạn có thể chọn giữa chế độ theo nhu cầu và chế độ được cung cấp cho luồng dữ liệu của mình. Nếu tốc độ dữ liệu của bạn thay đổi, trong chế độ được cung cấp, bạn có thể tăng hoặc giảm số lượng phân đoạn được phân bổ cho luồng của mình. Với chế độ theo nhu cầu, Kinesis Data Streams tự động quản lý các phân đoạn để cung cấp thông lượng cần thiết. Dung lượng của mục tiêu Kinesis có thể là nút cổ chai của hiệu suất sao chép; do đó, hãy đảm bảo Kinesis được cấu hình với đủ số lượng phân đoạn để xử lý song song nhiều hơn.

Khóa phân vùng là một yếu tố thiết yếu để xác định việc sử dụng dung lượng của mục tiêu. Dựa trên phân bố thống kê của khóa phân vùng trong cơ sở dữ liệu nguồn, một số phân đoạn có thể nóng hơn các phân đoạn khác. Như đã thảo luận trước đó trong bài đăng này, khóa cũng được AWS DMS sử dụng để phân phối các bản ghi dữ liệu đến tải song song và áp dụng hàng đợi.

Hai kịch bản điển hình được liên kết với khóa phân vùng:

• Việc phân phối dữ liệu bị sai lệch theo khóa phân vùng; Do đó, một vài mảnh vỡ có thể được điều tiết đáng kể. Trong trường hợp này, bạn cần xem xét một số khóa phân vùng khác và phân phối dữ liệu đồng đều giữa các phân đoạn.
• Khi sử dụng khóa phân vùng, dữ liệu được phân bố đều giữa các phân đoạn. Tuy nhiên, khối lượng công việc tối đa từ cơ sở dữ liệu nguồn có thể vượt quá khả năng thông lượng của phân đoạn Kinesis. Trong trường hợp này, bạn cần tăng số lượng phân đoạn, ví dụ: tăng gấp đôi số lượng phân đoạn hiện tại hoặc cân nhắc sử dụng chế độ theo nhu cầu cho dung lượng luồng dữ liệu Kinesis.

Kích thước phiên bản sao chép đúng cách để có tính song song cao hơn

Thông thường, bạn càng sử dụng nhiều cài đặt áp dụng và tải song song AWS DMS, phiên bản sao chép càng cần nhiều tài nguyên. Tăng kích thước phiên bản sao chép khi tăng , và . Nguyên tắc chung là khớp số lượng vCPU với × × số tác vụ chạy song song để tải đầy đủ và × số tác vụ chạy song song cho CDC. Ngoài ra, hãy cân nhắc sử dụng AWS DMS Serverless, mục tiêu vụ này cung cấp khả năng cung cấp và thay đổi quy mô tự động. Đồng thời lưu ý các hạn chế hiện tại với AWS DMS Serverless. Giám sát chặt chẽ việc sử dụng tài nguyên của phiên bản sao chép, như số liệu Amazon CloudWatch , và , khi điều chỉnh , , và . MaxFullLoadSubTasks ParallelLoad* ParallelApply* MaxFullLoadSubTasks ParallelLoadThreads ParallelApplyThreads CPUUtilization FreeableMemory SwapUsage MaxFullLoadSubTasks ParallelLoad* ParallelApply*

Trường hợp sử dụng ví dụ cho cài đặt áp dụng song song

Hãy cùng khám phá một ví dụ. Hãy xem xét trường hợp sử dụng sau:

• Chúng tôi tiến hành sao chép từ Phiên bản tương thích với Amazon Aurora PostgreSQL sang Kinesis Data Streams bằng cách sử dụng pglogical để giải mã WAL
• Khối lượng công việc mô phỏng 1.600 bản ghi mỗi giây và kích thước bản ghi 1 KB
• Không có tranh chấp tài nguyên trong cơ sở dữ liệu nguồn và phiên bản sao chép

Hãy xem cách cài đặt áp dụng song song được chỉ định cho trường hợp sử dụng này.

Trước tiên, đối với mục tiêu Kinesis Data Streams của tác vụ AWS DMS, bạn cần xác định cần bao nhiêu phân đoạn. Bạn xác định cách dữ liệu được phân phối và số lượng và kích thước của bản ghi để đưa vào từng phân đoạn bằng khóa phân vùng. AWS DMS sử dụng khóa chính của bảng nguồn theo mặc định.

Sau khi xác định số lượng phân đoạn cho mục tiêu, bạn có thể xác định cài đặt cho tác vụ AWS DMS. Ví dụ: giả sử chúng ta sử dụng tám phân đoạn cho mục tiêu Kinesis Data Streams ở bước đầu tiên và dữ liệu được phân bố đều giữa các phân đoạn theo khóa chính của cơ sở dữ liệu nguồn. Thông thường, bạn có thể chỉ định là bội số của số phân đoạn. Bạn có thể bắt đầu từ cùng một số phân đoạn trước và điều chỉnh sau nếu cần.ParallelApply*ParallelApplyThreads

Giả sử thời gian khứ hồi trung bình giữa phiên bản sao chép và mục tiêu Kinesis Data Streams là 20 mili giây, tức là 50 chuyến khứ hồi mỗi giây (1.000 ms / 20 ms = 50). Bạn có thể sử dụng AMI hỗ trợ chẩn đoán AWS DMS hoặc lệnh chẩn đoán mạng như hping3 để đo thời gian khứ hồi giữa phiên bản sao chép và điểm cuối mục tiêu.

Công thức của cấu hình như sau:

ParallelApplyThreads × × số chuyến đi khứ hồi giữa phiên bản sao chép và luồng dữ liệu Kinesis mỗi giây >= số bản ghi thay đổi mỗi giây trong cơ sở dữ liệu nguồn.ParallelApplyQueuesPerThread

Hãy so sánh hai cài đặt (giả sử 50 chuyến khứ hồi mỗi giây).

Cài đặt ban đầu của chúng tôi như sau:

ParallelApplyThreads = # của các mảnh = 8
= 4ParallelApplyQueuesPerThread

Với các cài đặt ban đầu trước đó, AWS DMS sẽ có thể đẩy khoảng 8 x 4 x 50 = 1.600 bản ghi mỗi giây với nhiều lệnh gọi API PutRecords. 5 MB cho mỗi lệnh gọi API PutRecords cũng đóng một vai trò để ràng buộc thông lượng sao chép của chúng tôi. Trong trường hợp của chúng tôi, ParallelApplyQueuesPerThread × kích thước mỗi bản ghi = 4 x 1 KB = 4 KB nằm trong giới hạn này.

Hãy xem các cài đặt khác nhau có thể ảnh hưởng như thế nào đến thông lượng sao chép của chúng tôi:

ParallelApplyThreads = 16
= 1ParallelApplyQueuesPerThread

Với các cài đặt này, AWS DMS sẽ có thể đẩy khoảng 16 x 1 x 50 = 800 bản ghi mỗi giây.

Cài đặt đầu tiên có thể đáp ứng yêu cầu sao chép 1.600 bản ghi mỗi giây từ khối lượng công việc nguồn, trong khi cài đặt thứ hai là không đủ mặc dù số lượng luồng () cao hơn cài đặt đầu tiên. Điều này là do không được điều chỉnh (theo mặc định, = 1) hoặc nó quá nhỏ trong cài đặt thứ hai. ParallelApplyThreads ParallelApplyQueuesPerThread ParallelApplyQueuesPerThread

Giả định cơ sở là dữ liệu được phân phối đều giữa các phân đoạn bởi khóa phân vùng (mặc định là khóa chính của bảng nguồn). Nếu có bất kỳ sự tăng đột biến nào do dữ liệu tạm thời bị lệch, hãy điều chỉnh và xử lý tải lớn hơn. Nếu nó luôn nghiêng về một phân đoạn nhất định, hãy xem xét thay đổi sang một khóa phân vùng khác. Đồng thời lưu ý kích thước tải trọng của khối lượng công việc nguồn có nhiều hàng đợi được chỉ định dẫn đến kích thước của lệnh gọi API PutRecords, bị giới hạn bởi 5 MB cho mỗi lệnh gọi API PutRecords. ParallelApplyThreadsParallelApplyQueuesPerThread

Các phương pháp hay nhất chung để điều chỉnh tải song song và áp dụng cài đặt

Hãy ghi nhớ các phương pháp hay nhất sau:

• Xem xét liệu cài đặt tải song song và áp dụng có phù hợp với trường hợp sử dụng cụ thể của bạn hay không khi thứ tự các bản ghi cần được giữ nguyên.
• Chọn khóa phân vùng cho Kinesis Data Streams một cách khôn ngoan dựa trên sự hiểu biết của bạn về phân phối thống kê theo khóa của dữ liệu nguồn. Mục tiêu là phân phối đều dữ liệu giữa các phân đoạn. Không sử dụng bất kỳ khóa duy nhất nào của bảng nguồn cho phép tham số ánh xạ đối tượng AWS DMS hoặc khóa phân vùng của điểm cuối mục tiêu. nullpartition-key-type
• Chọn chế độ dung lượng luồng dữ liệu thích hợp cho mục tiêu để đảm bảo đủ dung lượng. Thông thường, chỉ số CloudWatch cho Kinesis Data Streams và số liệu cũng như AWS DMS sẽ tăng đột biến khi dung lượng mục tiêu là nút cổ chai. WriteProvisionedThroughputExceeded CDCIncomingChanges CDCLatencyTarget
• Tăng kích thước phiên bản sao chép để có tính song song cao hơn và cũng cân nhắc sử dụng AWS DMS Serverless (lưu ý các hạn chế của nó). Giám sát chặt chẽ các chỉ số CloudWatch và AWS DMS khi điều chỉnh , và . CPUUtilization FreeableMemory SwapUsage MaxFullLoadSubTasks ParallelLoad* ParallelApply*
• Parallel*Threads và phải được điều chỉnh cùng nhau dựa trên số lượng bản ghi được thay đổi trong cơ sở dữ liệu nguồn. Kích thước lô cân bằng với các luồng tốt hơn một lô nhỏ nhưng số lượng luồng lớn. Tăng khi bạn có nhiều thư hơn để xử lý trên mỗi hàng đợi hoặc có khả năng một số hàng đợi tải song song và áp dụng có thể bận rộn hơn những người khác vì dữ liệu bị sai lệch dựa trên khóa phân vùng được sử dụng (lý tưởng nhất là bạn cần sử dụng khóa phân vùng tốt hơn). Parallel*QueuesPerThread ParallelApplyBufferSize
• Trong giai đoạn CDC, hãy giám sát chặt chẽ các chỉ số CloudWatch cho Kinesis Data Streams và AWS DMS, đồng thời điều chỉnh cho phù hợp. Mục tiêu là khớp với ba chỉ số CloudWatch này. PutRecords.Records CDCThroughputRowsSource CDCThroughputRowsTarget ParallelApply*
• Tăng bộ đệm luồng AWS DMS khi cần, đặc biệt là khi xử lý các đối tượng lớn hoặc xem cảnh báo về bộ đệm luồng trong nhật ký AWS DMS.
• Không sử dụng ghi nhật ký gỡ lỗi chi tiết cho tác vụ AWS DMS đang được sử dụng sản xuất. Các quy trình ghi nhật ký gỡ lỗi chi tiết chuyên sâu có thể chặn bản sao, kết thúc bằng các thay đổi nguồn được ghi lại tích lũy trong phiên bản sao chép và dẫn đến tăng đột biến và. CDCThroughputRowsSource CDCThroughputRowsTarget

Kết thúc

Trong bài đăng này, chúng tôi đã nói về kiến trúc cấp cao của cài đặt đa luồng đầy tải và CDC, cũng như những cân nhắc và phương pháp hay nhất chung để điều chỉnh các thông số liên quan nhằm tăng hiệu suất tốt hơn nhằm sao chép sang mục tiêu Kinesis Data Streams. Với sự phức tạp liên quan đến việc di chuyển cơ sở dữ liệu, chúng tôi khuyên bạn nên kiểm tra các tham số trong môi trường phi sản xuất với khối lượng công việc sản xuất mô phỏng trước khi thực hiện thay đổi trong sản xuất.

Trong bài đăng thứ hai trong loạt bài này, chúng tôi trình bày các cài đặt đa luồng với các cài đặt khác nhau và đánh giá hiệu suất.

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

---

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

Siva Thang là Kiến trúc sư giải pháp cao cấp, Đối tác của AWS. Chuyên môn của anh ấy là về cơ sở dữ liệu và phân tích, và anh ấy cũng có bằng thạc sĩ về Kỹ thuật. Siva đam mê sâu sắc trong việc giúp khách hàng xây dựng một nền tảng dữ liệu hiện đại trên đám mây bao gồm di chuyển sang cơ sở dữ liệu quan hệ hiện đại và xây dựng hồ dữ liệu và đường ống dữ liệu ở quy mô lớn để phân tích và học máy. Siva cũng thích trình bày trong các hội nghị và hội nghị thượng đỉnh khác nhau về chủ đề cơ sở dữ liệu và phân tích hiện đại.

Suchindranath Hegde là Kiến trúc sư giải pháp chuyên gia di chuyển dữ liệu tại Amazon Web Services. Ông làm việc với khách hàng của mình để cung cấp hướng dẫn và hỗ trợ kỹ thuật về di chuyển dữ liệu lên Đám mây AWS bằng AWS DMS.

Wanchen Zhao là Kiến trúc sư giải pháp chuyên gia cơ sở dữ liệu cao cấp tại AWS. Wanchen chuyên về Amazon RDS và Amazon Aurora, đồng thời là chuyên gia về chủ đề cho AWS DMS. Wanchen làm việc với các đối tác SI và ISV để thiết kế và triển khai các chiến lược di chuyển và hiện đại hóa cơ sở dữ liệu, đồng thời cung cấp hỗ trợ cho khách hàng xây dựng kiến trúc cơ sở dữ liệu có quy mô linh hoạt, bảo mật, hiệu năng và mạnh mẽ trên Đám mây AWS.

Michael Newlin là DBE hỗ trợ đám mây với Amazon Web Services và Chuyên gia về chủ đề cho AWS DMS. Tại AWS, ông làm việc với khách hàng và nhóm nội bộ để đảm bảo quá trình chuyển đổi khối lượng công việc cơ sở dữ liệu sang AWS diễn ra suôn sẻ và nhanh chóng.

Jay Chen là Giám đốc phát triển phần mềm tại AWS DMS, nơi ông giám sát việc phát triển các điểm cuối DMS, bao gồm S3, Kinesis, Kafka, Opensearch, Timestream và các điểm cuối khác. Jay được công nhận rộng rãi vì những đóng góp đáng kể của mình cho lĩnh vực cơ sở dữ liệu. Ông là đồng tác giả của Star Schema Benchmark, là một điểm chuẩn tiêu chuẩn dựa trên điểm chuẩn TPC-H cho cơ sở dữ liệu OLAP. Hơn nữa, ông đã đóng góp với tư cách là đồng tác giả cho C-STORE: A COLUMN-ORIENTED DBMS.Tác giả: Siva Thang, Michael Newlin, Suchindranath Hegde, Wanchen Zhao và Jay Chen | vào 03 MAY 2024 | in Nâng cao (300), AWS Database Migration Service, Kinesis Data Streams, Hướng dẫn kỹ thuật | Liên kết cố định |  Bình luận |  Chia sẻ

AWS Database Migration Service (AWS DMS) cho phép sao chép sang Amazon Kinesis Data Streams từ cơ sở dữ liệu quan hệ, kho dữ liệu, cơ sở dữ liệu NoSQL và các loại kho dữ liệu khác. Bạn có thể sử dụng luồng dữ liệu Kinesis để thu thập và xử lý các luồng bản ghi dữ liệu lớn theo thời gian thực.

Việc sao chép các thay đổi dữ liệu sang luồng dữ liệu Kinesis thường được kỳ vọng sẽ kéo dài và hiệu suất cao. AWS DMS cung cấp các cài đặt tác vụ thu thập dữ liệu (CDC) đa luồng, tải đầy đủ và thay đổi để giúp tăng tốc độ truyền dữ liệu và hiệu năng của CDC.

Khách hàng thường hỏi những câu hỏi sau khi điều chỉnh hiệu năng cho mục tiêu Kinesis Data Streams:

• Những điều cần cân nhắc khi điều chỉnh và cho điểm cuối mục tiêu Kinesis Data Streams là gì?ParallelLoad*ParallelApply*
• Làm cách nào để điều chỉnh tải song song hoặc áp dụng các tham số và tác vụ AWS DMS cho một khối lượng công việc CSDL nguồn nhất định?ParallelLoad*ParallelApply*
• Tôi có nên sử dụng nhiều phân đoạn luồng dữ liệu Kinesis hơn để cải thiện hiệu năng sao chép không?

Loạt bài này bao gồm ba phần. Trong bài đăng đầu tiên này, chúng tôi thảo luận về các cài đặt đa luồng đầy tải và CDC cũng như những điều cần cân nhắc để điều chỉnh các thông số liên quan nhằm tăng hiệu năng tốt hơn nhằm sao chép sang mục tiêu Kinesis Data Streams. Trong bài đăng thứ hai, chúng tôi cung cấp bản trình diễn về điều chỉnh hiệu năng AWS DMS cho mục tiêu Kinesis Data Streams với cài đặt đa luồng. Trong bài đăng thứ ba, chúng tôi chia sẻ một số điều cần cân nhắc và các phương pháp tốt nhất khác để sử dụng Kinesis Data Streams làm mục tiêu.

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

AWS DMS hỗ trợ toàn bộ tải và CDC từ bất kỳ nguồn được hỗ trợ đến mục tiêu Kinesis Data Streams thông qua các cặp giá trị thuộc tínhị trong JSON. Bạn có thể sử dụng ánh xạ đối tượng AWS DMS để di chuyển dữ liệu từ nguồn dữ liệu được hỗ trợ sang luồng dữ liệu mục tiêu của Kinesis. Luồng dữ liệu Kinesis được tạo thành từ các phân đoạn. Bạn có thể xác định khóa phân vùng cho mỗi bảng trong tác vụ DMS mà Kinesis Data Streams sử dụng để nhóm dữ liệu thành các phân đoạn của nó.

Trong giai đoạn tải đầy đủ, như minh họa trong hình dưới đây, AWS DMS tải các bảng song song với mục tiêu Kinesis Data Streams. Các bảng tối đa để tải song song được xác định bởi cài đặt tác vụ AWS DMS . AWS DMS tải từng bảng vào phân đoạn mục tiêu tương ứng bằng cách sử dụng một nhiệm vụ con chuyên dụng. Theo mặc định, AWS DMS tải song song tám bảng; tối đa là 49 bảng. Khóa phân vùng mặc định được sử dụng bởi tác vụ DMS đang trong giai đoạn tải đầy đủ. Bạn có thể chọn chỉ định tham số ánh xạ đối tượng AWS DMS, nghĩa là cùng một bảng cùng một lược đồ của cơ sở dữ liệu nguồn sẽ được tải vào cùng một phân đoạn trong Kinesis Data Streams. MaxFullLoadSubTasks primary-key partition-key-type schema-table

Khi cài đặt tải song song được sử dụng trong giai đoạn tải đầy đủ hoặc cài đặt áp dụng song song được sử dụng trong giai đoạn CDC, AWS DMS sẽ tải dữ liệu và áp dụng các thay đổi trong đa luồng. Bạn có thể sử dụng tham số ánh xạ đối tượng AWS DMS để đặt khóa phân vùng cho mục tiêu. Theo mặc định, với cài đặt tác vụ hoặc được chỉ định, khóa chính của bảng được sử dụng cho khóa phân vùng trong giai đoạn tải đầy đủ hoặc CDC tương ứng. Khi dữ liệu hàng loạt trong giai đoạn tải đầy đủ hoặc bản ghi thay đổi có thể lập số sê-ri trong giai đoạn CDC đến, AWS DMS sẽ trích xuất khóa phân vùng và áp dụng hàm băm để phân phối tin nhắn đến tải song song tương ứng hoặc áp dụng hàng đợi. Theo khóa phân vùng được sử dụng, đặc biệt là khi phân phối thống kê của khóa bị lệch, một số hàng đợi có thể rất bận rộn, trong khi một số hàng đợi có thể tương đối nhàn rỗi. Như thể hiện trong hình sau, Qm (n-1) + 1 đầy, trong khi Qm + 2 và Qm + m trống. Số lượng bản ghi tối đa để lưu trữ trong mỗi hàng đợi đệm được chỉ định cho giai đoạn tải đầy đủ và cho giai đoạn CDC. AWS DMS sử dụng nhiều luồng để thăm dò ý kiến từ tải song song hoặc áp dụng hàng đợi. Số lượng luồng được xác định bởi trong giai đoạn tải đầy đủ và trong giai đoạn CDC. Một chuỗi chỉ thăm dò ý kiến từ một hàng đợi hoặc nhóm hàng đợi cụ thể. Số lượng hàng đợi cho mỗi luồng cần thăm dò được xác định bởi cài đặt tác vụ AWS DMS trong giai đoạn tải đầy đủ và trong giai đoạn CDC. Tổng số hàng đợi song song là × cho giai đoạn tải đầy đủ và × cho giai đoạn CDC. Xác định tổng số bản ghi trên mỗi lô để thực hiện PutRecords cho mục tiêu Kinesis Data Streams. Partition-key-type ParallelLoad* ParallelApply* ParallelLoadBufferSize ParallelApplyBufferSize ParallelLoadThreads ParallelApplyThreads ParallelLoadQueuesPerThread ParallelApplyQueuesPerThread ParallelLoadQueuesPerThread ParallelLoadThreads ParallelApplyQueuesPerThread ParallelApplyThreads Parallel*QueuesPerThread

Để biết thêm thông tin về tải song song và áp dụng cài đặt tác vụ, tham khảo Sử dụng Amazon Kinesis Data Streams làm mục tiêu cho AWS Database Migration Service.

Cân nhắc tải song song và áp dụng cài đặt

Trong phần này, chúng tôi thảo luận về những cân nhắc chính cho tải song song và áp dụng cài đặt.

Xác định xem thứ tự hồ sơ có cần được bảo quản hay không

Thay vì duy trì thứ tự nghiêm ngặt, bạn có thể nhận dữ liệu từ Kinesis Data Streams trên các phân đoạn khác nhau không theo thứ tự. Để đạt được hiệu năng cao, AWS DMS sử dụng API hàng loạt Kinesis cũng như đa luồng. Nếu thứ tự của tin nhắn phải được giữ nguyên, hãy xem xét các tùy chọn sau: PutRecords

• Nếu việc sắp xếp thứ tự tất cả các thao tác được liên kết với cùng một khóa chính, hãy sử dụng trong ánh xạ đối tượng AWS DMS và chỉ định một phân đoạn cho mục tiêu Kinesis mà không cần tải song song hoặc áp dụng cài đặt. Bằng cách này, AWS DMS sao chép các bản ghi dữ liệu trong một luồng theo cùng một thứ tự có thể tuần tự hóa như các giao mục tiêu được liên kết với cùng một khóa chính trong cơ sở dữ liệu nguồn sang cùng một phân đoạn Kinesis. Kinesis Data Streams có giới hạn API 1.000 TPS. Mỗi phân đoạn có thể hỗ trợ ghi tối đa 1.000 bản ghi mỗi giây và ghi dữ liệu tối đa là 1 MB mỗi giây. Để biết thêm chi tiết, hãy tham khảo Hạn ngạch và Giới hạn.schema-tableprimary-keyPutRecord
• Nếu việc sắp xếp thứ tự tất cả các thao tác cho các bảng riêng lẻ quan trọng, hãy sử dụng trong ánh xạ đối tượng AWS DMS và chỉ định một phân đoạn cho mục tiêu Kinesis mà không cần tải song song hoặc áp dụng cài đặt. Bằng cách này, AWS DMS sao chép các bản ghi dữ liệu trong một luồng theo cùng một thứ tự có thể tuần tự hóa như các giao mục tiêu được liên kết với cùng một bảng trong cơ sở dữ liệu nguồn sang cùng một phân đoạn Kinesis. Cũng lưu ý dung lượng của Kinesis mục tiêu được đề cập ở trên, đặc biệt là khi khối lượng công việc từ cơ sở dữ liệu nguồn chuyên sâu. schema-tablepartition-key-type
• Sử dụng cài đặt điểm cuối cho mục tiêu để cung cấp thông tin giao mục tiêu chi tiết từ cơ sở dữ liệu nguồn. Bạn có thể sử dụng thông tin như vị trí đăng nhập và ID giao mục tiêu để nhận ra thứ tự của các tin nhắn bằng ứng dụng xuôi dòng. Cách tiếp cận này phù hợp khi cơ sở dữ liệu nguồn có tính giao mục tiêu cao và các cài đặt tải và áp dụng song song được sử dụng để có hiệu suất tốt hơn. IncludeTransactionDetails

Hiểu khối lượng công việc của cơ sở dữ liệu nguồn

Kích thước dữ liệu và tỷ lệ giao mục tiêu xác định mức độ song song cần thiết để đạt được hiệu suất sao chép mong muốn. Thông thường, trong giai đoạn tải đầy đủ, bạn cần hiểu kích thước của bảng và số hàng trong bảng. Trong giai đoạn CDC, bạn cần hiểu số lượng bản ghi mỗi giây thay vì số lượng giao mục tiêu mỗi giây vì một giao mục tiêu có thể chứa nhiều bản ghi. Thông tin này được sử dụng để chỉ định tải song song và áp dụng cài đặt cho AWS DMS nhằm cải thiện hiệu năng sao chép.

Xác định số lượng phân đoạn và khóa phân vùng của mục tiêu

Đối với mục tiêu Kinesis Data Streams, mỗi phân đoạn cung cấp một đơn vị dung lượng cố định. Bạn có thể chọn giữa chế độ theo nhu cầu và chế độ được cung cấp cho luồng dữ liệu của mình. Nếu tốc độ dữ liệu của bạn thay đổi, trong chế độ được cung cấp, bạn có thể tăng hoặc giảm số lượng phân đoạn được phân bổ cho luồng của mình. Với chế độ theo nhu cầu, Kinesis Data Streams tự động quản lý các phân đoạn để cung cấp thông lượng cần thiết. Dung lượng của mục tiêu Kinesis có thể là nút cổ chai của hiệu suất sao chép; do đó, hãy đảm bảo Kinesis được cấu hình với đủ số lượng phân đoạn để xử lý song song nhiều hơn.

Khóa phân vùng là một yếu tố thiết yếu để xác định việc sử dụng dung lượng của mục tiêu. Dựa trên phân bố thống kê của khóa phân vùng trong cơ sở dữ liệu nguồn, một số phân đoạn có thể nóng hơn các phân đoạn khác. Như đã thảo luận trước đó trong bài đăng này, khóa cũng được AWS DMS sử dụng để phân phối các bản ghi dữ liệu đến tải song song và áp dụng hàng đợi.

Hai kịch bản điển hình được liên kết với khóa phân vùng:

• Việc phân phối dữ liệu bị sai lệch theo khóa phân vùng; Do đó, một vài mảnh vỡ có thể được điều tiết đáng kể. Trong trường hợp này, bạn cần xem xét một số khóa phân vùng khác và phân phối dữ liệu đồng đều giữa các phân đoạn.
• Khi sử dụng khóa phân vùng, dữ liệu được phân bố đều giữa các phân đoạn. Tuy nhiên, khối lượng công việc tối đa từ cơ sở dữ liệu nguồn có thể vượt quá khả năng thông lượng của phân đoạn Kinesis. Trong trường hợp này, bạn cần tăng số lượng phân đoạn, ví dụ: tăng gấp đôi số lượng phân đoạn hiện tại hoặc cân nhắc sử dụng chế độ theo nhu cầu cho dung lượng luồng dữ liệu Kinesis.

Kích thước phiên bản sao chép đúng cách để có tính song song cao hơn

Thông thường, bạn càng sử dụng nhiều cài đặt áp dụng và tải song song AWS DMS, phiên bản sao chép càng cần nhiều tài nguyên. Tăng kích thước phiên bản sao chép khi tăng , và . Nguyên tắc chung là khớp số lượng vCPU với × × số tác vụ chạy song song để tải đầy đủ và × số tác vụ chạy song song cho CDC. Ngoài ra, hãy cân nhắc sử dụng AWS DMS Serverless, mục tiêu vụ này cung cấp khả năng cung cấp và thay đổi quy mô tự động. Đồng thời lưu ý các hạn chế hiện tại với AWS DMS Serverless. Giám sát chặt chẽ việc sử dụng tài nguyên của phiên bản sao chép, như số liệu Amazon CloudWatch , và , khi điều chỉnh , , và . MaxFullLoadSubTasks ParallelLoad* ParallelApply* MaxFullLoadSubTasks ParallelLoadThreads ParallelApplyThreads CPUUtilization FreeableMemory SwapUsage MaxFullLoadSubTasks ParallelLoad* ParallelApply*

Trường hợp sử dụng ví dụ cho cài đặt áp dụng song song

Hãy cùng khám phá một ví dụ. Hãy xem xét trường hợp sử dụng sau:

• Chúng tôi tiến hành sao chép từ Phiên bản tương thích với Amazon Aurora PostgreSQL sang Kinesis Data Streams bằng cách sử dụng pglogical để giải mã WAL
• Khối lượng công việc mô phỏng 1.600 bản ghi mỗi giây và kích thước bản ghi 1 KB
• Không có tranh chấp tài nguyên trong cơ sở dữ liệu nguồn và phiên bản sao chép

Hãy xem cách cài đặt áp dụng song song được chỉ định cho trường hợp sử dụng này.

Trước tiên, đối với mục tiêu Kinesis Data Streams của tác vụ AWS DMS, bạn cần xác định cần bao nhiêu phân đoạn. Bạn xác định cách dữ liệu được phân phối và số lượng và kích thước của bản ghi để đưa vào từng phân đoạn bằng khóa phân vùng. AWS DMS sử dụng khóa chính của bảng nguồn theo mặc định.

Sau khi xác định số lượng phân đoạn cho mục tiêu, bạn có thể xác định cài đặt cho tác vụ AWS DMS. Ví dụ: giả sử chúng ta sử dụng tám phân đoạn cho mục tiêu Kinesis Data Streams ở bước đầu tiên và dữ liệu được phân bố đều giữa các phân đoạn theo khóa chính của cơ sở dữ liệu nguồn. Thông thường, bạn có thể chỉ định là bội số của số phân đoạn. Bạn có thể bắt đầu từ cùng một số phân đoạn trước và điều chỉnh sau nếu cần.ParallelApply*ParallelApplyThreads

Giả sử thời gian khứ hồi trung bình giữa phiên bản sao chép và mục tiêu Kinesis Data Streams là 20 mili giây, tức là 50 chuyến khứ hồi mỗi giây (1.000 ms / 20 ms = 50). Bạn có thể sử dụng AMI hỗ trợ chẩn đoán AWS DMS hoặc lệnh chẩn đoán mạng như hping3 để đo thời gian khứ hồi giữa phiên bản sao chép và điểm cuối mục tiêu.

Công thức của cấu hình như sau:

ParallelApplyThreads × × số chuyến đi khứ hồi giữa phiên bản sao chép và luồng dữ liệu Kinesis mỗi giây >= số bản ghi thay đổi mỗi giây trong cơ sở dữ liệu nguồn.ParallelApplyQueuesPerThread

Hãy so sánh hai cài đặt (giả sử 50 chuyến khứ hồi mỗi giây).

Cài đặt ban đầu của chúng tôi như sau:

ParallelApplyThreads = # của các mảnh = 8
= 4ParallelApplyQueuesPerThread

Với các cài đặt ban đầu trước đó, AWS DMS sẽ có thể đẩy khoảng 8 x 4 x 50 = 1.600 bản ghi mỗi giây với nhiều lệnh gọi API PutRecords. 5 MB cho mỗi lệnh gọi API PutRecords cũng đóng một vai trò để ràng buộc thông lượng sao chép của chúng tôi. Trong trường hợp của chúng tôi, ParallelApplyQueuesPerThread × kích thước mỗi bản ghi = 4 x 1 KB = 4 KB nằm trong giới hạn này.

Hãy xem các cài đặt khác nhau có thể ảnh hưởng như thế nào đến thông lượng sao chép của chúng tôi:

ParallelApplyThreads = 16
= 1ParallelApplyQueuesPerThread

Với các cài đặt này, AWS DMS sẽ có thể đẩy khoảng 16 x 1 x 50 = 800 bản ghi mỗi giây.

Cài đặt đầu tiên có thể đáp ứng yêu cầu sao chép 1.600 bản ghi mỗi giây từ khối lượng công việc nguồn, trong khi cài đặt thứ hai là không đủ mặc dù số lượng luồng () cao hơn cài đặt đầu tiên. Điều này là do không được điều chỉnh (theo mặc định, = 1) hoặc nó quá nhỏ trong cài đặt thứ hai. ParallelApplyThreads ParallelApplyQueuesPerThread ParallelApplyQueuesPerThread

Giả định cơ sở là dữ liệu được phân phối đều giữa các phân đoạn bởi khóa phân vùng (mặc định là khóa chính của bảng nguồn). Nếu có bất kỳ sự tăng đột biến nào do dữ liệu tạm thời bị lệch, hãy điều chỉnh và xử lý tải lớn hơn. Nếu nó luôn nghiêng về một phân đoạn nhất định, hãy xem xét thay đổi sang một khóa phân vùng khác. Đồng thời lưu ý kích thước tải trọng của khối lượng công việc nguồn có nhiều hàng đợi được chỉ định dẫn đến kích thước của lệnh gọi API PutRecords, bị giới hạn bởi 5 MB cho mỗi lệnh gọi API PutRecords. ParallelApplyThreadsParallelApplyQueuesPerThread

Các phương pháp hay nhất chung để điều chỉnh tải song song và áp dụng cài đặt

Hãy ghi nhớ các phương pháp hay nhất sau:

• Xem xét liệu cài đặt tải song song và áp dụng có phù hợp với trường hợp sử dụng cụ thể của bạn hay không khi thứ tự các bản ghi cần được giữ nguyên.
• Chọn khóa phân vùng cho Kinesis Data Streams một cách khôn ngoan dựa trên sự hiểu biết của bạn về phân phối thống kê theo khóa của dữ liệu nguồn. Mục tiêu là phân phối đều dữ liệu giữa các phân đoạn. Không sử dụng bất kỳ khóa duy nhất nào của bảng nguồn cho phép tham số ánh xạ đối tượng AWS DMS hoặc khóa phân vùng của điểm cuối mục tiêu. nullpartition-key-type
• Chọn chế độ dung lượng luồng dữ liệu thích hợp cho mục tiêu để đảm bảo đủ dung lượng. Thông thường, chỉ số CloudWatch cho Kinesis Data Streams và số liệu cũng như AWS DMS sẽ tăng đột biến khi dung lượng mục tiêu là nút cổ chai. WriteProvisionedThroughputExceeded CDCIncomingChanges CDCLatencyTarget
• Tăng kích thước phiên bản sao chép để có tính song song cao hơn và cũng cân nhắc sử dụng AWS DMS Serverless (lưu ý các hạn chế của nó). Giám sát chặt chẽ các chỉ số CloudWatch và AWS DMS khi điều chỉnh , và . CPUUtilization FreeableMemory SwapUsage MaxFullLoadSubTasks ParallelLoad* ParallelApply*
• Parallel*Threads và phải được điều chỉnh cùng nhau dựa trên số lượng bản ghi được thay đổi trong cơ sở dữ liệu nguồn. Kích thước lô cân bằng với các luồng tốt hơn một lô nhỏ nhưng số lượng luồng lớn. Tăng khi bạn có nhiều thư hơn để xử lý trên mỗi hàng đợi hoặc có khả năng một số hàng đợi tải song song và áp dụng có thể bận rộn hơn những người khác vì dữ liệu bị sai lệch dựa trên khóa phân vùng được sử dụng (lý tưởng nhất là bạn cần sử dụng khóa phân vùng tốt hơn). Parallel*QueuesPerThread ParallelApplyBufferSize
• Trong giai đoạn CDC, hãy giám sát chặt chẽ các chỉ số CloudWatch cho Kinesis Data Streams và AWS DMS, đồng thời điều chỉnh cho phù hợp. Mục tiêu là khớp với ba chỉ số CloudWatch này. PutRecords.Records CDCThroughputRowsSource CDCThroughputRowsTarget ParallelApply*
• Tăng bộ đệm luồng AWS DMS khi cần, đặc biệt là khi xử lý các đối tượng lớn hoặc xem cảnh báo về bộ đệm luồng trong nhật ký AWS DMS.
• Không sử dụng ghi nhật ký gỡ lỗi chi tiết cho tác vụ AWS DMS đang được sử dụng sản xuất. Các quy trình ghi nhật ký gỡ lỗi chi tiết chuyên sâu có thể chặn bản sao, kết thúc bằng các thay đổi nguồn được ghi lại tích lũy trong phiên bản sao chép và dẫn đến tăng đột biến và. CDCThroughputRowsSource CDCThroughputRowsTarget

Kết thúc

Trong bài đăng này, chúng tôi đã nói về kiến trúc cấp cao của cài đặt đa luồng đầy tải và CDC, cũng như những cân nhắc và phương pháp hay nhất chung để điều chỉnh các thông số liên quan nhằm tăng hiệu suất tốt hơn nhằm sao chép sang mục tiêu Kinesis Data Streams. Với sự phức tạp liên quan đến việc di chuyển cơ sở dữ liệu, chúng tôi khuyên bạn nên kiểm tra các tham số trong môi trường phi sản xuất với khối lượng công việc sản xuất mô phỏng trước khi thực hiện thay đổi trong sản xuất.

Trong bài đăng thứ hai trong loạt bài này, chúng tôi trình bày các cài đặt đa luồng với các cài đặt khác nhau và đánh giá hiệu suất.

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

---

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

Siva Thang là Kiến trúc sư giải pháp cao cấp, Đối tác của AWS. Chuyên môn của anh ấy là về cơ sở dữ liệu và phân tích, và anh ấy cũng có bằng thạc sĩ về Kỹ thuật. Siva đam mê sâu sắc trong việc giúp khách hàng xây dựng một nền tảng dữ liệu hiện đại trên đám mây bao gồm di chuyển sang cơ sở dữ liệu quan hệ hiện đại và xây dựng hồ dữ liệu và đường ống dữ liệu ở quy mô lớn để phân tích và học máy. Siva cũng thích trình bày trong các hội nghị và hội nghị thượng đỉnh khác nhau về chủ đề cơ sở dữ liệu và phân tích hiện đại.

Suchindranath Hegde là Kiến trúc sư giải pháp chuyên gia di chuyển dữ liệu tại Amazon Web Services. Ông làm việc với khách hàng của mình để cung cấp hướng dẫn và hỗ trợ kỹ thuật về di chuyển dữ liệu lên Đám mây AWS bằng AWS DMS.

Wanchen Zhao là Kiến trúc sư giải pháp chuyên gia cơ sở dữ liệu cao cấp tại AWS. Wanchen chuyên về Amazon RDS và Amazon Aurora, đồng thời là chuyên gia về chủ đề cho AWS DMS. Wanchen làm việc với các đối tác SI và ISV để thiết kế và triển khai các chiến lược di chuyển và hiện đại hóa cơ sở dữ liệu, đồng thời cung cấp hỗ trợ cho khách hàng xây dựng kiến trúc cơ sở dữ liệu có quy mô linh hoạt, bảo mật, hiệu năng và mạnh mẽ trên Đám mây AWS.

Michael Newlin là DBE hỗ trợ đám mây với Amazon Web Services và Chuyên gia về chủ đề cho AWS DMS. Tại AWS, ông làm việc với khách hàng và nhóm nội bộ để đảm bảo quá trình chuyển đổi khối lượng công việc cơ sở dữ liệu sang AWS diễn ra suôn sẻ và nhanh chóng.

Jay Chen là Giám đốc phát triển phần mềm tại AWS DMS, nơi ông giám sát việc phát triển các điểm cuối DMS, bao gồm S3, Kinesis, Kafka, Opensearch, Timestream và các điểm cuối khác. Jay được công nhận rộng rãi vì những đóng góp đáng kể của mình cho lĩnh vực cơ sở dữ liệu. Ông là đồng tác giả của Star Schema Benchmark, là một điểm chuẩn tiêu chuẩn dựa trên điểm chuẩn TPC-H cho cơ sở dữ liệu OLAP. Hơn nữa, ông đã đóng góp với tư cách là đồng tác giả cho C-STORE: A COLUMN-ORIENTED DBMS.