Nếu bạn đang đọc điều này, bạn có thể đã nghe nói về Amazon Aurora. Như bạn đã biết, Amazon Aurora là một dịch vụ PaaS do AWS cung cấp như một phần của bộ dịch vụ RDS, cung cấp một hệ thống quản lý cơ sở dữ liệu quan hệ được quản lý đầy đủ (RDBMS) có hai phiên bản, MySQL và Postgres, trong khi vẫn duy trì khả năng tương thích dây với cả hai. Tuy nhiên, điều này ảnh hưởng như thế nào đến các chiến lược và lựa chọn có tính khả dụng cao của bạn?
Bạn có thể tự hỏi Amazon Aurora khác MySQL hoặc PostgreSQL onAmazon RDS như thế nào. Đây cũng là các dịch vụ RDBMS được quản lý đầy đủ, đúng không? Vâng, về cơ bản chúng là các triển khai mã nguồn mở tiêu chuẩn chạy trên một nhóm các phiên bản EC2 và được quản lý bởi AWS. Sự khác biệt chính với Aurora là AWS đã tách công cụ lưu trữ khỏi công cụ cơ sở dữ liệu. AWS đã áp dụng Nguyên tắc về mối quan tâm riêng biệt cho cơ sở dữ liệu nguồn mở.
Tách biệt các mối quan tâm
Thông thường, một RDBMS phải chạy trên phần cứng thường có sẵn. Điều này có nghĩa là việc triển khai phải hoạt động trong các giới hạn do HĐH và phần cứng áp đặt để hoàn thành tất cả các tính năng mà chúng tôi mong đợi từ một cơ sở dữ liệu hiện đại, chẳng hạn như:xử lý DML và DDL, các giao dịch tuân thủ ACID, sao chép, tính khả dụng cao (HA), và khả năng chịu lỗi. Tuy nhiên, nếu việc thực thi không bắt buộc phải chạy trên phần cứng có sẵn nói chung mà chỉ trong môi trường được thiết kế đặc biệt cho cơ sở dữ liệu, thì các trách nhiệm khác nhau có thể được tách thành các lớp, cho phép công cụ cơ sở dữ liệu và công cụ lưu trữ được tập trung và chuyên biệt. Do đó, tính khả dụng cao và hiệu suất có thể được tăng lên đáng kể - hiệu suất cao hơn tới 5 lần so với thanstand MySQL và gấp 3 lần so với PostgreSQL tiêu chuẩn.
Được rồi, nhanh hơn, nhưng cơ sở dữ liệu và công cụ lưu trữ chuyên biệt giúp sử dụng HA như thế nào? Có một số cách giúp chúng ta đạt được HA. Tuy nhiên, trước khi chúng ta tìm hiểu nội dung, hãy xem nhanh cách hoạt động của công cụ lưu trữ Aurora để giúp chúng ta hiểu cách HA được hình thành từ sự tách biệt này.
Khi dữ liệu được ghi vào công cụ lưu trữ Aurora, công cụ này sẽ đảm bảo dữ liệu được ghi nhất quán, chính xác và lâu dài. Dữ liệu được ghi ở hai vị trí trong mỗi vùng trong số ba vùng khả dụng, tổng cộng là 6 nơi khác nhau. Công cụ lưu trữ xử lý sự phức tạp của việc đảm bảo tất cả những điều đó diễn ra một cách chính xác. Mặc dù có thể hơi đơn giản hóa một chút, nhưng về cơ bản, công cụ cơ sở dữ liệu giờ đây có thể “chữa cháy và quên”, không còn cần phải nhắc nhở về việc dữ liệu đã được ghi, nhật ký giao dịch, khả năng cần khôi phục, v.v.
Loại bỏ mối quan tâm về lưu trữ khỏi công cụ cơ sở dữ liệu, một số chiến lược HA có sẵn.
Đọc các bản sao
Mặc dù khái niệm Bản sao Đọc từ lâu đã có trước Aurora, nhưng các giải pháp nguồn inopen triển khai liên quan đến việc vận chuyển nhật ký hoặc phát lại truy vấn. Với Aurora, ReadReplicas có quyền truy cập chỉ đọc vào cùng một bộ nhớ chính xác với bộ nhớ chính. Điều này có nghĩa là độ trễ sao chép rất nhỏ từ khi dữ liệu thời gian được ghi đến thời gian hiển thị cho Bản sao đọc (độ trễ sao chép sẽ là một trường hợp nhầm lẫn trong trường hợp này). Khi cần nhiều Bản sao Đọc, tất cả Bản sao Đọc sẽ kiểm tra cùng một dữ liệu, loại bỏ chi phí và độ phức tạp được đặt trên bản triển khai MySQL và PostgreSQL chuẩn, được tìm thấy. Các tính năng này kết hợp với nhau để cho phép Bản sao đã đọc ngay lập tức tiếp quản nếu bản chính bị lỗi. Ngoài ra, AWS xử lý việc thay thế phiên bản bị lỗi, để đáp ứng dung lượng được cung cấp, với phiên bản mới và cập nhật DNS để trỏ đến phiên bản chính mới.
Đây là một giải pháp tuyệt vời cho các ứng dụng có tỷ lệ đọc-ghi cao, tuy nhiên, hãy nhớ rằng phiên bản chính của bạn phải đủ lớn để xử lý toàn bộ tải ghi. Ngoài ra, để ghi HA, bạn muốn cung cấp ít nhất một Bản sao đọc có cùng kích thước với bản chính của bạn. Sau đó, đặt Bản sao Đọc này là bản sao ưu tiên để được thăng cấp lên bản sao chính. Trong trường hợp không hoạt động, bạn sẽ duy trì tính khả dụng cao cho cả khả năng đọc và ghi.
Tự động thay đổi tỷ lệ
Tự động thay đổi tỷ lệ là khả năng mở rộng quy mô theo chiều ngang (thêm phiên bản) hoặc mở rộng (xóa phiên bản) khỏi tập hợp các máy chủ có sẵn của bạn. Bạn có thể đã nghe nói về Tính năng thay đổi tỷ lệ cho các phiên bản EC2, nhưng bạn có biết rằng bạn cũng có thể có tính đàn hồi trong Bản sao đọc Aurora của mình không? Thông thường, bạn sẽ định cấu hình số lượng Bản sao đọc tối thiểu để xử lý tải cơ sở của mình và có các chính sách tự động phân hạng để thêm phiên bản orremove khi nhu cầu thay đổi. Khả năng tận dụng độ co giãn là một hệ quả khác của thực tế là bộ máy lưu trữ tách biệt với cơ sở dữ liệu.
Một tình huống ví dụ trong đó điều này sẽ hữu ích là một trang web thương mại điện tử B2B. Nó có lưu lượng truy cập đông đúc trong giờ làm việc các ngày trong tuần nhưng rất ít qua đêm và vào cuối tuần. Hình ảnh và mô tả nội dung có tỷ lệ đọc-ghi cao và được hưởng lợi từ cả tính năng Đọc bản sao và tính năng Tự động thay đổi tỷ lệ. Việc tự động phân loại ReadReplicas của bạn cho phép bạn đáp ứng nhu cầu trong giờ cao điểm đồng thời giảm thiểu chi phí trong giờ ngoài giờ.
Sao chép giữa các vùng
Nếu bạn cần đưa tính khả dụng lên cấp độ tiếp theo, hãy nhân rộng nó sang khu vực khác. Bằng cách để công cụ cơ sở dữ liệu sao chép dữ liệu sang một vùng khác, nó có thể được đọc cục bộ hoặc được sử dụng trong trường hợp vùng chính bị lỗi. Phần bổ trợ trong vùng phụ được coi là Bản sao Đọc (đây không phải là bản chính), nhưng nó cũng có thể có Bản sao Đọc của riêng mình hoặc trở thành masterif mà vùng chính bị lỗi.
Có nhiều lý do tại sao cần nhân rộng giữa các vùng. Dữ liệu nào đó quá quan trọng để được lưu trữ trong một khu vực địa lý duy nhất. Điều này có thể là do tính liên tục của hoạt động kinh doanh, lý do quy định hoặc tài chính. Một lý do khác là giảm độ trễ giữa người dùng và cơ sở dữ liệu phụ trợ. Sử dụngecommerce làm ví dụ một lần nữa, các thay đổi đối với hình ảnh và mô tả có thể được áp dụng cho trang cái ở một khu vực duy nhất nhưng được phân phối trên toàn cầu để có thể đọc được ở địa phương.
Sao chép bên ngoài
Còn các trường hợp bạn cần dữ liệu bên ngoài cụm Aurora thì sao? Nhân rộng bên ngoài.
Thật dễ dàng để Aurora sao chép dữ liệu sang một phiên bản Amazon EC2 MySQL, một phiên bản Amazon EC2 chạy MySQL hoặc thậm chí một phiên bản MySQL chạy trong trung tâm dữ liệu công ty của bạn. Sử dụng bản sao một chiều này, dữ liệu của bạn luôn không đồng bộ với cụm Aurora của bạn và có sẵn để sử dụng bên ngoài Aurora.
Không máy chủ
Cuối cùng, nhưng chắc chắn không kém, là không có máy chủ. Có thể một trong những phát triển quan trọng nhất về tính khả dụng và khả năng mở rộng là việc bổ sung phương trình không máy chủ. Rõ ràng là không có máy chủ không có nghĩa là không có máy chủ. Có nghĩa là bạn không phải lo lắng về việc cung cấp, cấu hình, mở rộng quy mô hoặc bảo trì bất kỳ máy chủ nào.
Để định cấu hình Aurora Serverless, bạn chỉ định dung lượng có sẵn cho ứng dụng của bạn và AWS xử lý các chi tiết để đảm bảo rằng dung lượng đó luôn sẵn có theo yêu cầu, khi khách hàng của bạn cần. Đối với serverless, một lớp bổ sung, lớp aproxy, đã được thêm vào hai lớp hiện có, công cụ cơ sở dữ liệu và công cụ lưu trữ.
AWS duy trì một nhóm máy chủ proxy lắng nghe các yêu cầu đến. Inaddition, một hồ bơi ấm áp có sức chứa DB đang chờ đợi để phục vụ yêu cầu. Khi truy vấn đầu tiên của bạn đến, nhóm proxy sẽ nhận nó, yêu cầu một cá thể từ vùng ấm và chuyển tiếp yêu cầu đến phiên bản đó, sau khi nó được cấp phát cho bạn sử dụng. Thậm chí tốt hơn, số lượng phiên bản được phân bổ cho việc sử dụng của bạn là không co giãn và mở rộng quy mô dựa trên nhu cầu và các giới hạn bạn chỉ định trong cấu hình Aurora Serverless. Như với các chiến lược trước đó, khả năng phân bổ động động cơ sở dữ liệu cho bạn có thể thực hiện được nhờ cơ sở dữ liệu và lưu trữ riêng biệt. Dựa trên cấu hình của bạn, phiên bản cơ sở dữ liệu vẫn được giao cho bạn và có sẵn để sử dụng ngay lập tức. Sau khi hết khoảng thời gian chờ, phiên bản được trả về hồ bơi ấm. Bạn chỉ bị tính phí cho các tài nguyên bạn đang sử dụng. Khi một phiên bản được cấp phát để bạn sử dụng, bạn sẽ bị tính phí cho nó cộng với bất kỳ bộ nhớ đã tiêu thụ nào. Khi không được phân bổ, bạn chỉ bị tính phí cho phần lưu trữ đã sử dụng.
Đối với các khối lượng công việc lớn, chẳng hạn như môi trường phát triển và thử nghiệm hoặc các ứng dụng mới không có đủ lịch sử để dự đoán các kiểu sử dụng, thì không cần máy chủ là cách để đi. Bạn không còn phải trả tiền cho tài nguyên bạn không sử dụng, không phải lo lắng về việc đảm bảo nhóm phát triển đã tắt đèn trước khi rời đi vào cuối tuần và bạn sẽ không bị đánh thức vào nửa đêm để điều chỉnh dung lượng vì người dùng của bạn 'múi giờ trùng với múi giờ của bạn.
Kết thúc
Amazon Aurora được xây dựng chú trọng đến tính khả dụng, độ bền và khả năng mở rộng. Với cái nhìn sâu hơn một chút về các khả năng của Aurora và các mô hình tận dụng chúng, bạn có thể triển khai giải pháp để đáp ứng nhu cầu của mình, từ giảm tải khi đọc cục bộ đến khả năng cung cấp được phân phối trên toàn cầu.
Sử dụng tab Phản hồi để đưa ra bất kỳ nhận xét hoặc đặt câu hỏi nào.