Quan sát sự phát triển của phần mềm doanh nghiệp hàng đầu trong hai thập kỷ, người ta có thể thấy một xu hướng không thể phủ nhận trong vài năm gần đây – chuyển cơ sở dữ liệu lên đám mây.
Tôi đã tham gia vào một số dự án di chuyển nhằm chuyển cơ sở dữ liệu tại chỗ hiện có sang cơ sở dữ liệu Amazon Đám mây dịch vụ web (AWS). Mặc dù tài liệu tài liệu của AWS sẽ cho bạn biết việc này có thể dễ dàng như thế nào nhưng tôi sẽ cho bạn biết rằng việc triển khai một kế hoạch như vậy không phải lúc nào cũng dễ dàng và có những trường hợp có thể xảy ra sai sót.
Trong bài đăng này, tôi sẽ thảo luận về trải nghiệm thực tế trong trường hợp sau:
- Nguồn: Mặc dù về mặt lý thuyết, nguồn của bạn là gì không quan trọng (bạn có thể sử dụng cách tiếp cận rất giống nhau cho hầu hết các cơ sở dữ liệu phổ biến nhất), Oracle đã là hệ thống cơ sở dữ liệu được lựa chọn trong các công ty doanh nghiệp lớn trong nhiều năm và đó là điều tôi tôi sẽ tập trung vào.
- Mục tiêu: Không có lý do gì phải cụ thể về mặt này. Bạn có thể chọn bất kỳ cơ sở dữ liệu đích nào trong AWS và cách tiếp cận vẫn phù hợp.
- Chế độ: Bạn có thể làm mới toàn bộ hoặc làm mới tăng dần. Tải dữ liệu hàng loạt (trạng thái nguồn và đích bị trì hoãn) hoặc (gần như) tải dữ liệu theo thời gian thực. Cả hai sẽ được giải quyết ở đây.
- Tần suất: Bạn có thể cần di chuyển một lần, sau đó chuyển hoàn toàn sang đám mây hoặc yêu cầu một khoảng thời gian chuyển đổi và giữ cho dữ liệu của bạn được cập nhật trên cả hai bên cùng một lúc, điều đó có nghĩa là phát triển tính năng đồng bộ hóa hàng ngày giữa tại chỗ và AWS. Cái trước đơn giản hơn và có ý nghĩa hơn nhiều, nhưng cái sau được yêu cầu thường xuyên hơn và có nhiều điểm ngắt hơn. Tôi sẽ thảo luận về cả hai ở đây.
mô tả vấn đề
Yêu cầu thường đơn giản:
Chúng tôi muốn bắt đầu phát triển các dịch vụ bên trong AWS, vì vậy vui lòng sao chép tất cả dữ liệu của chúng tôi vào cơ sở dữ liệu “ABC”. Nhanh chóng và đơn giản. Bây giờ chúng ta cần sử dụng dữ liệu trong AWS. Sau đó, chúng tôi sẽ xác định phần nào của dự án DB cần được thay đổi để phù hợp với hoạt động của chúng tôi.
Trước khi chúng ta tiến hành, có điều gì đó cần xem xét:
- Đừng quá nhanh chóng rơi vào suy nghĩ “cứ sao chép những gì chúng ta có và xử lý nó sau”. Ý tôi là, vâng, đó là điều dễ dàng nhất bạn có thể làm và nó sẽ được thực hiện nhanh chóng, nhưng nó có thể tạo ra một vấn đề kiến trúc cơ bản mà bạn không thể khắc phục sau này nếu không tái cấu trúc phần lớn nền tảng đám mây mới. Hãy tưởng tượng rằng hệ sinh thái đám mây hoàn toàn khác so với hệ sinh thái tại chỗ. Một số dịch vụ mới sẽ được giới thiệu theo thời gian. Tất nhiên, mọi người sẽ bắt đầu sử dụng cùng một thứ theo những cách rất khác nhau. Hầu như không bao giờ là một ý tưởng hay khi sao chép tại chỗ trên đám mây ở quy mô lớn 1:1. Đây có thể là trường hợp cụ thể của bạn, nhưng hãy nhớ kiểm tra kỹ.
- Tranh chấp yêu cầu với một số mối quan ngại đáng kể, chẳng hạn như:
- Ai sẽ là người dùng thông thường sử dụng nền tảng mới? Tại địa phương, đây có thể là người dùng doanh nghiệp giao dịch; trên đám mây, đây có thể là nhà phân tích dữ liệu hoặc nhà phân tích kho dữ liệu hoặc người dùng chính của dữ liệu có thể là dịch vụ (ví dụ: Databricks, Glue, mô hình học máy, v.v.).
- Các công việc thông thường hàng ngày có được duy trì ngay cả sau khi chuyển sang đám mây không? Nếu không thì họ sẽ thay đổi như thế nào?
- Bạn có dự định tăng đáng kể lượng dữ liệu theo thời gian không? Rất có thể câu trả lời là có, vì đây thường là lý do số một để chuyển sang đám mây. Mô hình dữ liệu mới sẽ sẵn sàng cho việc này.
- Mong người dùng cuối suy nghĩ về các truy vấn chung, được dự đoán trước mà cơ sở dữ liệu mới sẽ nhận được từ người dùng. Điều này sẽ xác định mức độ cần thay đổi của mô hình dữ liệu hiện tại để duy trì phù hợp với hiệu suất.
Định cấu hình di chuyển
Sau khi chọn cơ sở dữ liệu đích và có cái nhìn tổng quan thỏa đáng về mô hình dữ liệu, bước tiếp theo là làm quen với Công cụ chuyển đổi lược đồ AWS. Có một số lĩnh vực có thể sử dụng công cụ này:
Tham khảo: Tài liệu AWS
Dưới đây là một số mẹo sử dụng công cụ chuyển đổi lược đồ.
Đầu tiên, hầu như không bao giờ được sử dụng trực tiếp đầu ra. Tôi sẽ coi nó nhiều hơn như là kết quả tham khảo mà từ đó nên thực hiện các điều chỉnh dựa trên sự hiểu biết và mục đích của dữ liệu cũng như cách dữ liệu sẽ được sử dụng trên đám mây.
Thứ hai, các bảng trước đây có thể được chọn bởi những người dùng đang tìm kiếm kết quả ngắn gọn, nhanh chóng cho một số thực thể miền dữ liệu cụ thể. Nhưng bây giờ dữ liệu có thể được chọn để phân tích. Ví dụ: các chỉ mục cơ sở dữ liệu trước đây hoạt động trong cơ sở dữ liệu tại chỗ giờ đây sẽ vô dụng và chắc chắn sẽ không cải thiện hiệu suất của hệ thống DB liên quan đến trường hợp sử dụng mới này. Tương tự, bạn có thể phân vùng dữ liệu trên hệ thống đích khác với cách phân vùng dữ liệu trước đây trên hệ thống nguồn.
Bạn cũng nên xem xét thực hiện một số chuyển đổi dữ liệu trong quá trình di chuyển, về cơ bản có nghĩa là thay đổi mô hình dữ liệu đích cho một số bảng (để chúng không còn là bản sao của 1:1). Sau đó, các quy tắc chuyển đổi sẽ cần được triển khai trong công cụ di chuyển.
Nếu cơ sở dữ liệu nguồn và đích cùng loại (ví dụ: Oracle tại chỗ so với Oracle trên AWS, PostgreSQL so với Aurora Postgresql, v.v.), thì tốt nhất nên sử dụng công cụ di chuyển chuyên dụng mà cơ sở dữ liệu cụ thể hỗ trợ nguyên bản (ví dụ: xuất nhập khẩu máy bơm dữ liệu, Oracle Goldengate, v.v.).
Tuy nhiên, trong hầu hết các trường hợp, cơ sở dữ liệu nguồn và đích sẽ không tương thích và khi đó Dịch vụ di chuyển cơ sở dữ liệu AWS sẽ là công cụ được lựa chọn rõ ràng.
Tham khảo: Tài liệu AWS
AWS DMS về cơ bản cho phép bạn thiết lập danh sách tác vụ ở cấp độ bảng sẽ xác định:
- Cơ sở dữ liệu nguồn và bảng chính xác để kết nối là gì?
- Các thông số kỹ thuật của câu lệnh sẽ được sử dụng để lấy dữ liệu cho bảng mục tiêu.
- Các công cụ chuyển đổi (nếu có) chỉ định cách ánh xạ dữ liệu nguồn tới dữ liệu bảng đích (nếu không 1:1).
- Cơ sở dữ liệu đích chính xác và bảng để tải dữ liệu vào là gì?
Việc cấu hình các công việc DMS được thực hiện ở một số định dạng thân thiện với người dùng như JSON.
Bây giờ, trong kịch bản đơn giản nhất, tất cả những gì bạn cần làm là chạy các tập lệnh triển khai trên cơ sở dữ liệu đích và chạy công việc DMS. Nhưng nó còn nhiều hơn thế nữa.
Di chuyển dữ liệu đầy đủ một lần
Trường hợp thực thi dễ dàng nhất là khi yêu cầu di chuyển toàn bộ cơ sở dữ liệu sang cơ sở dữ liệu đám mây đích một lần. Sau đó, về cơ bản tất cả những gì cần làm sẽ như thế này:
Nếu cấu hình DMS được thực hiện tốt thì sẽ không có gì xấu xảy ra trong trường hợp này. Mỗi bảng nguồn sẽ được tìm nạp và sao chép vào cơ sở dữ liệu AWS đích. Điều lo lắng duy nhất là làm theo các bước và đảm bảo kích thước phù hợp trong mỗi bước để không bị lỗi do không đủ dung lượng lưu trữ.
Đồng bộ hóa gia tăng hàng ngày
Đây là nơi mọi thứ bắt đầu trở nên phức tạp. Ý tôi là, nếu thế giới này hoàn hảo thì có lẽ nó sẽ luôn hoạt động tốt. Nhưng thế giới không bao giờ hoàn hảo.
DMS có thể được cấu hình để hoạt động ở hai chế độ:
- Tải đầy – chế độ mặc định được mô tả và sử dụng ở trên. Công việc DMS chạy khi khởi động hoặc theo lịch trình. Sau khi hoàn thành, các nhiệm vụ DMS đã hoàn tất.
- Change Data Capture (CDC) – ở chế độ này, các tác vụ DMS chạy liên tục. DMS quét cơ sở dữ liệu nguồn để tìm những thay đổi ở cấp độ bảng. Nếu một thay đổi xảy ra, nó sẽ ngay lập tức cố gắng sao chép thay đổi đó trong cơ sở dữ liệu đích dựa trên cấu hình bên trong công việc DMS liên quan đến bảng đã thay đổi.
Khi quyết định chọn CDC, bạn có thêm một lựa chọn nữa – và đó là cách CDC sẽ trích xuất các thay đổi delta từ cơ sở dữ liệu nguồn.
# 1. Trình đọc nhật ký làm lại của Oracle
Một tùy chọn là chọn trình đọc nhật ký làm lại cơ sở dữ liệu Oracle gốc mà CDC có thể sử dụng để tìm nạp dữ liệu đã thay đổi và dựa trên những thay đổi mới nhất, sao chép các thay đổi tương tự vào cơ sở dữ liệu đích.
Mặc dù đây có vẻ là một lựa chọn hiển nhiên khi coi oracle là nguồn, nhưng có một nhược điểm: trình đọc nhật ký oracle redo sử dụng cụm oracle nguồn và do đó ảnh hưởng trực tiếp đến tất cả các hoạt động khác đang chạy trong cơ sở dữ liệu (thực ra nó trực tiếp tạo ra các phiên hoạt động trong dữ liệu cơ sở dữ liệu).
Bạn càng thiết lập nhiều công việc DMS (hoặc càng nhiều cụm DMS song song), bạn càng có nhiều khả năng cần phát triển cụm Oracle của mình – về cơ bản hãy điều chỉnh tỷ lệ theo chiều dọc của cụm cơ sở dữ liệu Oracle chính của bạn. Điều này chắc chắn sẽ ảnh hưởng đến tổng chi phí của giải pháp, thậm chí còn ảnh hưởng nhiều hơn nếu việc đồng bộ hóa hàng ngày được thực hiện với dự án trong một thời gian dài.
#2. Công cụ khai thác nhật ký AWS DMS
Không giống như tùy chọn ở trên, đây là giải pháp AWS gốc cho cùng một vấn đề. Trong trường hợp này, DMS không ảnh hưởng đến Oracle DB nguồn. Thay vào đó, nó sao chép nhật ký làm lại của Oracle vào cụm DMS và thực hiện tất cả quá trình xử lý ở đó. Mặc dù nó tiết kiệm tài nguyên của Oracle nhưng nó là một giải pháp chậm hơn vì yêu cầu nhiều thao tác hơn. Ngoài ra, có thể dễ dàng giả định rằng trình đọc nhật ký làm lại tùy chỉnh của Oracle có thể hoạt động chậm hơn so với trình đọc Oracle gốc.
Tùy thuộc vào kích thước của cơ sở dữ liệu nguồn và số lượng thay đổi hàng ngày đối với cơ sở dữ liệu đó, việc đồng bộ hóa dữ liệu tăng dần từ cơ sở dữ liệu Oracle cục bộ sang cơ sở dữ liệu đám mây AWS có thể diễn ra trong thời gian gần như thời gian thực.
Trong các trường hợp khác, nó vẫn chưa đạt đến mức đồng bộ hóa theo thời gian thực, nhưng bạn có thể cố gắng đạt được độ trễ có thể chấp nhận được (giữa nguồn và đích) càng gần càng tốt bằng cách tinh chỉnh cấu hình hiệu suất và tính song song của nguồn và đích các cụm hoặc bằng cách thử nghiệm số lượng công việc DMS và sự phân bổ của chúng giữa các phiên bản CDC.
Bạn cũng có thể muốn biết những thay đổi nào đối với bảng nguồn được CDC hỗ trợ (ví dụ: thêm một cột), vì không phải tất cả các thay đổi có thể có đều được hỗ trợ. Trong một số trường hợp, cách duy nhất là thay đổi bảng mục tiêu theo cách thủ công và khởi động lại công việc CDC từ đầu (mất tất cả dữ liệu hiện có trong cơ sở dữ liệu đích trong quá trình thực hiện).
Khi có sự cố xảy ra, dù thế nào đi chăng nữa
Tôi đã học được điều đó một cách khó khăn, nhưng có một tình huống cụ thể liên quan đến DMS mà lời hứa về việc sao chép hàng ngày khó có thể thực hiện được.
DMS chỉ có thể xử lý nhật ký làm lại ở một tốc độ nhất định. Sẽ không có vấn đề gì nếu có nhiều phiên bản DMS hơn thực hiện công việc của bạn. Tuy nhiên, mỗi phiên bản DMS chỉ đọc nhật ký làm lại ở một tốc độ cụ thể và mỗi phiên bản phải đọc toàn bộ nhật ký đó. Việc bạn đang sử dụng nhật ký viết lại của Oracle hoặc trình khám phá nhật ký AWS cũng không thành vấn đề. Cả hai đều có giới hạn này.
Nếu cơ sở dữ liệu nguồn có số lượng thay đổi lớn trong một ngày và nhật ký làm lại của oracle thực sự lớn đến mức cực kỳ lớn (chẳng hạn như 500 GB + lớn) mỗi ngày, CDC sẽ không hoạt động. Việc sao chép sẽ không được hoàn thành cho đến cuối ngày. Nó sẽ chuyển một số công việc chưa được xử lý sang ngày hôm sau, nơi một loạt thay đổi mới đang chờ được sao chép. Lượng dữ liệu chưa được xử lý sẽ tăng lên từng ngày.
Trong trường hợp cụ thể này, CDC đã không còn khả năng thực hiện (sau rất nhiều thử nghiệm và thử nghiệm hiệu suất mà chúng tôi đã thực hiện). Cách duy nhất để đảm bảo rằng ít nhất tất cả các thay đổi delta từ ngày hiện tại sẽ được sao chép trong cùng một ngày là tiếp cận nó như thế này:
- Tách các bảng thực sự lớn không được sử dụng nhiều và chỉ sao chép chúng mỗi tuần một lần (ví dụ: vào cuối tuần).
- Định cấu hình sao chép các bảng không lớn lắm nhưng vẫn lớn để phân chia giữa một số tác vụ DMS; một bảng cuối cùng đã được di chuyển song song qua 10 công việc DMS riêng biệt trở lên, đảm bảo rằng dữ liệu được phân chia giữa các công việc DMS riêng biệt (trong trường hợp này là để mã hóa tùy chỉnh) và được thực thi hàng ngày.
- Thêm nhiều hơn (trong trường hợp này là 4) của phiên bản DMS và chia đều các công việc DMS cho chúng, nghĩa là không chỉ số lượng bảng mà còn cả kích thước.
Về cơ bản, chúng tôi đã sử dụng chế độ đầy tải DMS để sao chép dữ liệu hàng ngày vì đó là cách duy nhất để hoàn thành sao chép dữ liệu ít nhất trong cùng một ngày.
Đó không phải là một giải pháp hoàn hảo nhưng nó vẫn tồn tại và thậm chí sau nhiều năm nó vẫn hoạt động như vậy. Vì vậy, có lẽ đây không phải là một giải pháp tồi. 😃
