Cách đồng bộ hóa Cơ sở dữ liệu Oracle tại chỗ của bạn với AWS hàng ngày

Spread the love

Theo dõi quá trình phát triển phần mềm của công ty từ hàng đầu tiên trong hai thập kỷ, xu hướng không thể phủ nhận trong vài năm qua là rõ ràng – 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, với mục tiêu là đưa cơ sở dữ liệu tại chỗ hiện có vào cơ sở dữ liệu Đám mây của Amazon Web Services (AWS). Mặc dù từ tài liệu AWS, bạn sẽ biết được việc này có thể dễ dàng như thế nào, nhưng tôi ở đây để cho bạn biết rằng việc thực hiện 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 kế hoạch đó có thể thất bại.

Trong bài viết này, mình sẽ đề cập đến kinh nghiệm thực tế cho trường hợp sau:

  • Nguồn: Mặc dù về lý thuyết, nguồn của bạn là gì không thực sự quan trọng (bạn có thể sử dụng một cách tiếp cận rất giống nhau cho phần lớn các DB 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 lớn trong nhiều năm và đó là nơi tôi sẽ tập trung.
  • Mục tiêu: Không có lý do tại sao phải cụ thể về mặt này. Bạn có thể chọn bất kỳ cơ sở dữ liệu mục tiêu nào trong AWS và cách tiếp cận sẽ vẫn phù hợp.
  • Chế độ: Bạn có thể làm mới toàn bộ hoặc làm mới gia tăng. Tải dữ liệu hàng loạt (trạng thái nguồn và đích bị trễ) hoặc (gần) tải dữ liệu thời gian thực. Cả hai sẽ được chạm vào ở đây.
  • Tần suất: Bạn có thể muốn di chuyển một lần, sau đó là chuyển đổi hoàn toàn sang đám mây hoặc yêu cầu một số khoảng thời gian chuyển đổi và cập nhật dữ liệu đồng thời trên cả hai bên, điều này ngụ ý phát triển đồ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 thường được yêu cầu hơn và có nhiều điểm dừng hơn. Tôi sẽ bao gồm 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. Chúng tôi cần sử dụng dữ liệu bên trong AWS ngay bây giờ. Sau này, chúng ta sẽ tìm ra những phần nào của thiết kế DB cần thay đổi để phù hợp với các hoạt động của chúng ta.

Trước khi đi xa hơn, có một số điều cần xem xét:

  • Đừng nhảy vào ý tưởng “cứ sao chép những gì chúng tôi có và giải quyết nó sau” quá nhanh. Ý tôi là, vâng, đây là cách dễ nhất bạn có thể làm và nó sẽ được thực hiện nhanh chóng, nhưng điều này có khả năng tạo ra một vấn đề kiến ​​trúc cơ bản mà sau này sẽ không thể khắc phục nếu không tái cấu trúc nghiêm túc phần lớn nền tảng đám mây mới . Chỉ cần tưởng tượng hệ sinh thái đám mây hoàn toàn khác 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. Đương nhiên, mọi người sẽ bắt đầu sử dụng cùng một cách rất khác nhau. Hầu như không bao giờ là một ý tưởng hay khi sao chép trạng thái tại chỗ trên đám mây theo kiểu 1:1. Nó có thể phù hợp với trường hợp cụ thể của bạn, nhưng hãy nhớ kiểm tra kỹ điều này.
  • Đặt câu hỏi về yêu cầu với một số nghi ngờ có ý nghĩa như:
    • Ai sẽ là người dùng điển hình sử dụng nền tảng mới? Trong khi tại chỗ, nó có thể là người dùng doanh nghiệp giao dịch; trên đám mây, đó có thể là nhà khoa học 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 máy học, v.v.).
    • Các công việc thường ngày có được duy trì ngay cả sau khi chuyển đổi sang đám mây không? Nếu không, làm thế nào họ dự kiến ​​​​sẽ thay đổi?
    • Bạn có kế hoạch tăng trưởng đáng kể dữ liệu theo thời gian không? Rất có thể, câu trả lời là có, vì đó thường là lý do quan trọng nhất để di chuyển vào đám mây. Một mô hình dữ liệu mới sẽ sẵn sàng cho nó.
  • Yêu cầu người dùng cuối suy nghĩ về một số 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 độ thay đổi của mô hình dữ liệu hiện có để duy trì hiệu suất phù hợp.
  BeamNG Drive có trên Xbox không?

Thiết lập di chuyển

Khi cơ sở dữ liệu đích được chọn và mô hình dữ liệu được thảo luận thỏa đáng, 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 mà công cụ này có thể phục vụ:

  • Phân tích và trích xuất mô hình dữ liệu nguồn. SCT sẽ đọc những gì có trong cơ sở dữ liệu tại chỗ hiện tại và sẽ tạo một mô hình dữ liệu nguồn để bắt đầu.
  • Đề xuất cấu trúc mô hình dữ liệu đích dựa trên cơ sở dữ liệu đích.
  • Tạo tập lệnh triển khai cơ sở dữ liệu đích để cài đặt mô hình dữ liệu đích (dựa trên những gì công cụ tìm thấy từ cơ sở dữ liệu nguồn). Điều này sẽ tạo tập lệnh triển khai và sau khi thực thi, cơ sở dữ liệu trên đám mây sẽ sẵn sàng để tải dữ liệu từ cơ sở dữ liệu tại chỗ.
  • Tham khảo: Tài liệu AWS

    Bây giờ có một số mẹo để sử dụng Công cụ chuyển đổi giản đồ.

    Đầu tiên, hầu như không bao giờ nên sử dụng đầu ra trực tiếp. Tôi sẽ coi nó giống kết quả tham khảo hơn, từ đó bạn sẽ thực hiện các điều chỉnh của mình dựa trên hiểu biết và mục đích của bạn về dữ liệu cũng như cách dữ liệu sẽ được sử dụng trong đám mây.

    Thứ hai, trước đó, các bảng có thể đã được chọn bởi người dùng mong đợi kết quả ngắn gọn nhanh chóng về 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 cho mục đích 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 không cải thiện hiệu suất của hệ thống DB liên quan đến cách sử dụng mới này. Tương tự, bạn có thể muốn phân vùng dữ liệu theo cách khác trên hệ thống đích, giống như trước đây trên hệ thống nguồn.

    Ngoài ra, bạn nên cân nhắc 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 1:1 nữa). Sau này, các quy tắc chuyển đổi sẽ cần được triển khai vào công cụ di chuyển.

    Nếu cơ sở dữ liệu nguồn và đích thuộc cùng một loại (ví dụ: Oracle tại chỗ so với Oracle trong AWS, PostgreSQL so với Aurora Postgresql, v.v.), thì tốt nhất bạn 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 và nhập 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 đó, công cụ được lựa chọn rõ ràng sẽ là Dịch vụ di chuyển cơ sở dữ liệu AWS.

    Tham khảo: Tài liệu AWS

    AWS DMS về cơ bản cho phép định cấu hình danh sách tác vụ ở cấp độ bảng, danh sách này sẽ xác định:

    • DB và bảng nguồn chính xác để kết nối là gì?
    • Thông số kỹ thuật câu lệnh sẽ được sử dụng để lấy dữ liệu cho bảng đích.
    • Các công cụ chuyển đổi (nếu có), xác định cách dữ liệu nguồn sẽ được ánh xạ vào dữ liệu bảng đích (nếu không phải là 1:1).
    • Cơ sở dữ liệu đích chính xác và bảng để tải dữ liệu vào là gì?

    Cấu hình tác vụ 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 tập lệnh triển khai trên cơ sở dữ liệu đích và bắt đầu tác vụ DMS. Nhưng còn nhiều điều hơn thế nữa.

    Di chuyển toàn bộ dữ liệu một lần

    Trường hợp dễ thực hiện nhất là khi có yêu cầu di chuyển toàn bộ cơ sở dữ liệu một lần vào cơ sở dữ liệu đám mây đích. Sau đó, về cơ bản, tất cả những gì cần làm sẽ giống như sau:

      Dấu chấm màu cam và màu xanh lá cây trên iPhone hoặc iPad là gì?
  • Xác định Nhiệm vụ DMS cho từng bảng nguồn.
  • Đảm bảo chỉ định đúng cấu hình của công việc DMS. Điều này có nghĩa là thiết lập tính song song hợp lý, biến bộ đệm, cấu hình máy chủ DMS, kích thước của cụm DMS, v.v. Đây thường là giai đoạn tốn nhiều thời gian nhất vì nó yêu cầu thử nghiệm rộng rãi và tinh chỉnh trạng thái cấu hình tối ưu.
  • Đảm bảo mỗi bảng đích được tạo (trống) trong cơ sở dữ liệu đích theo cấu trúc bảng dự kiến.
  • Lên lịch một khoảng thời gian trong đó quá trình di chuyển dữ liệu sẽ được thực hiện. Rõ ràng, trước đó, hãy đảm bảo (bằng cách thực hiện kiểm tra hiệu năng) khoảng thời gian đủ để quá trình di chuyển hoàn tất. Trong quá trình di chuyển, cơ sở dữ liệu nguồn có thể bị hạn chế về mặt hiệu suất. Ngoài ra, dự kiến ​​cơ sở dữ liệu nguồn sẽ không thay đổi trong thời gian quá trình di chuyển sẽ chạy. Mặt khác, dữ liệu được di chuyển có thể khác với dữ liệu được lưu trữ trong cơ sở dữ liệu nguồn sau khi quá trình di chuyển hoàn tất.
  • Nếu cấu hình của DMS được thực hiện tốt, sẽ không có gì xấu xảy ra trong trường hợp này. Mỗi bảng nguồn đơn lẻ sẽ được chọn và sao chép vào cơ sở dữ liệu đích của AWS. Mối quan tâm duy nhất sẽ là hiệu suất của hoạt động và đảm bảo kích thước phù hợp trong từng bước để hoạt động 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 là lý tưởng, thì có lẽ nó sẽ luôn hoạt động tốt. Nhưng thế giới không bao giờ là lý tưởng.

    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ác tác vụ DMS được bắt đầu khi bạn khởi động chúng hoặc khi chúng được lên lịch để bắt đầu. Sau khi hoàn thành, các nhiệm vụ DMS đã hoàn thành.
    • Change Data Capture (CDC) – trong chế độ này, tác vụ DMS đang chạy liên tục. DMS quét cơ sở dữ liệu nguồn để tìm thay đổi ở cấp độ bảng. Nếu 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 tác vụ DMS liên quan đến bảng đã thay đổi.

    Khi sử dụng CDC, bạn cần đưa ra lựa chọn khác – cụ thể là cách CDC sẽ trích xuất các thay đổi delta từ DB 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 gốc từ Oracle, mà CDC có thể sử dụng để lấy dữ liệu đã thay đổi và dựa trên các thay đổi mới nhất, sao chép các thay đổi tương tự trên cơ sở dữ liệu đích.

    Mặc dù điều này có vẻ như là một lựa chọn rõ ràng nếu xử lý Oracle với tư cách là nguồn, nhưng có một nhược điểm: Trình đọc nhật ký làm lại của Oracle 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 (nó thực sự trực tiếp tạo ra các phiên hoạt động trong kho dữ liệu).

    Bạn càng cấu hình nhiều Nhiệm vụ DMS (hoặc càng nhiều cụm DMS song song), bạn càng có thể cần tăng kích thước cụm Oracle – về cơ bản, đ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 sắp diễn ra 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 riêng cho cùng một vấn đề. Trong trường hợp này, DMS không ảnh hưởng đến nguồn Oracle DB. Thay vào đó, nó sao chép các bản ghi 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 đây là giải pháp chậm hơn vì có nhiều hoạt động hơn. Ngoài ra, như người ta có thể dễ dàng giả định, trình đọc tùy chỉnh cho nhật ký làm lại của Oracle có thể chậm hơn trong công việc của nó với tư cách là trình đọc gốc từ Oracle.

      Làm việc với ngày bằng cách sử dụng date-fns trong JavaScript

    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 ở đó, trong trường hợp tốt nhất, bạn có thể kết thúc quá trình đồng bộ hóa dữ liệu gia tăng gần như theo thời gian thực từ cơ sở dữ liệu Oracle tại chỗ vào cơ sở dữ liệu đám mây AWS.

    Trong bất kỳ trường hợp nào khác, nó vẫn sẽ không gần đồng bộ hóa theo thời gian thực, nhưng bạn có thể cố gắng tiến gần nhất có thể đến độ trễ được chấp nhận (giữa nguồn và đích) bằng cách điều chỉnh cấu hình hiệu suất của cụm nguồn và cụm đích cũng như tính song song hoặc thử nghiệm với số lượng nhiệm vụ DMS và việc phân phối chúng giữa các phiên bản CDC.

    Và bạn có thể muốn tìm hiểu những thay đổi trong bảng nguồn được CDC hỗ trợ (chẳng hạn như 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à làm cho bảng đích thay đổi theo cách thủ công và khởi động lại tác vụ 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 mọi thứ trở nên tồi tệ, không có vấn đề gì

    Tôi đã học được điều này một cách khó khăn, nhưng có một tình huống cụ thể được kết nối với DMS mà lời hứa về việc sao chép hàng ngày khó đạt được.

    DMS chỉ có thể xử lý nhật ký làm lại với một số tốc độ xác định. Sẽ không có vấn đề gì nếu có nhiều phiên bản DMS thực thi nhiệm vụ của bạn hơn. Tuy nhiên, mỗi phiên bản DMS chỉ đọc nhật ký làm lại với một tốc độ xác định duy nhất và mỗi phiên bản phải đọc toàn bộ. Nó thậm chí không thành vấn đề nếu bạn sử dụng nhật ký làm lại của Oracle hoặc công cụ khai thác nhật ký AWS. Cả hai đều có giới hạn này.

    Nếu cơ sở dữ liệu nguồn bao gồm một số lượng lớn các thay đổi trong vòng một ngày mà nhật ký làm lại của Oracle trở nên thực sự lớn (như lớn hơn 500GB) mỗi ngày, thì CDC sẽ không hoạt động. Bản sao sẽ không được hoàn thành trước cuối ngày. Nó sẽ chuyển một số công việc chưa xử lý sang ngày hôm sau, nơi một loạt thay đổi mới sẽ được sao chép đang chờ sẵn. Lượng dữ liệu chưa được xử lý sẽ chỉ tăng lên hàng ngày.

    Trong trường hợp cụ thể này, CDC không phải là một tùy chọn (sau 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 ít nhất tất cả các thay đổi đồng bằng 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ư sau:

    • Tách các bảng thực sự lớn không được sử dụng thường xuyên và chỉ lặp lại chúng một lần mỗi tuần (ví dụ: vào cuối tuần).
    • Định cấu hình bản sao của các bảng không quá lớn nhưng vẫn lớn để được 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 bởi 10 tác vụ DMS tách biệt trở lên, đảm bảo phân chia dữ liệu giữa các tác vụ DMS là khác biệt (mã hóa tùy chỉnh liên quan ở đây) và thực thi chúng hàng ngày.
    • Thêm nhiều phiên bản DMS hơn (tối đa 4 trong trường hợp này) và phân chia đồng đều các tác vụ DMS giữa chúng, nghĩa là không chỉ theo số lượng bảng mà còn theo kích thước.

    Về cơ bản, chúng tôi đã sử dụng chế độ tải đầy đủ của 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 ở đó, và thậm chí sau nhiều năm, vẫn hoạt động theo cách cũ. Vì vậy, có lẽ đó không phải là một giải pháp tồi. 😃

    x