Theo kinh nghiệm của tôi, Amazon Aurora không thích hợp để chạy cơ sở dữ liệu có lưu lượng ghi lớn. Ít nhất là trong quá trình triển khai vào khoảng năm 2017. Có thể nó sẽ cải thiện theo thời gian.
Tôi đã làm việc trên một số điểm chuẩn cho một ứng dụng viết nhiều vào đầu năm 2017 và chúng tôi nhận thấy rằng RDS (không phải Aurora) vượt trội hơn nhiều so với Aurora về hiệu suất ghi, dựa trên ứng dụng và cơ sở dữ liệu của chúng tôi. Về cơ bản, Aurora chậm hơn RDS hai bậc cường độ. Những tuyên bố của Amazon về hiệu suất cao cho Aurora rõ ràng là hoàn toàn nhảm nhí dựa trên tiếp thị.
Vào tháng 11 năm 2016, tôi tham dự hội nghị Amazon re:Invent ở Las Vegas. Tôi đã cố gắng tìm một kỹ sư am hiểu về Aurora để trả lời các câu hỏi của tôi về hiệu suất. Tất cả những gì tôi có thể tìm thấy là các kỹ sư cấp dưới đã được lệnh lặp lại tuyên bố rằng Aurora nhanh hơn kỳ diệu 5-10 lần so với MySQL.
Vào tháng 4 năm 2017, tôi đã tham dự hội nghị Percona Live và xem một bài thuyết trình về cách phát triển kiến trúc lưu trữ phân tán giống Aurora bằng cách sử dụng MySQL tiêu chuẩn với CEPH cho lớp lưu trữ phân tán mã nguồn mở. Có một hội thảo trên web về cùng chủ đề ở đây: https://www.percona. com / resources / webinars / mysql-and-ceph , đồng trình bày bởi Yves Trudeau, kỹ sư mà tôi đã thấy phát biểu tại hội nghị.
Điều đã trở nên rõ ràng về việc sử dụng MySQL với CEPH là các kỹ sư phải vô hiệu hóa Bộ đệm thay đổi MySQL bởi vì không có cách nào để lưu các thay đổi vào bộ nhớ cache đối với các chỉ mục phụ, đồng thời phân phối bộ nhớ. Điều này gây ra các vấn đề về hiệu suất rất lớn khi ghi vào các bảng có chỉ mục phụ (không phải duy nhất).
Điều này phù hợp với các vấn đề về hiệu suất mà chúng tôi đã thấy khi đo điểm chuẩn cho ứng dụng của chúng tôi với Aurora. Cơ sở dữ liệu của chúng tôi có rất nhiều chỉ mục phụ.
Vì vậy, nếu bạn hoàn toàn phải sử dụng Aurora cho cơ sở dữ liệu có lưu lượng ghi cao, thì điều đầu tiên bạn phải làm là bỏ tất cả các chỉ mục phụ của bạn.
Rõ ràng, đây là một vấn đề nếu các chỉ mục cần thiết để tối ưu hóa một số truy vấn của bạn. Tất nhiên, cả hai truy vấn CHỌN, nhưng một số truy vấn CẬP NHẬT và XÓA có thể sử dụng chỉ mục phụ.
Một chiến lược có thể là tạo một bản sao đọc không phải Aurora của cụm Aurora của bạn và chỉ tạo các chỉ mục phụ trong bản sao đã đọc để hỗ trợ các truy vấn CHỌN của bạn. Tôi chưa bao giờ làm điều này, nhưng rõ ràng là có thể, theo https://aws.amazon.com/premiumsupport/knowledge-center/enable-binary-logging-aurora/
Nhưng điều này vẫn không giúp ích cho các trường hợp các câu lệnh UPDATE / DELETE của bạn cần các chỉ mục phụ. Tôi không có bất kỳ gợi ý nào cho kịch bản đó. Bạn có thể gặp may.
Kết luận của tôi là tôi sẽ không chọn sử dụng Aurora cho một ứng dụng viết nhiều. Có thể điều đó sẽ thay đổi trong tương lai.
Cập nhật tháng 4 năm 2021:
Kể từ khi viết phần trên, tôi đã chạy các điểm chuẩn của sysbench đối với Aurora phiên bản 2. Tôi không thể chia sẻ các con số cụ thể, nhưng tôi kết luận rằng các cải tiến hiện tại của Aurora tốt hơn cho khối lượng công việc nặng về viết. Tôi đã chạy thử nghiệm với rất nhiều chỉ mục phụ để đảm bảo. Nhưng tôi khuyến khích bất kỳ ai nghiêm túc về việc sử dụng Aurora hãy chạy các điểm chuẩn của riêng họ.
Ít nhất, Aurora tốt hơn nhiều so với Amazon RDS thông thường cho MySQL sử dụng lưu trữ EBS. Đó có thể là nơi họ tuyên bố Aurora nhanh hơn gấp 5 lần so với MySQL. Nhưng Aurora không nhanh hơn một số lựa chọn thay thế khác mà tôi đã thử nghiệm và thực tế là không thể sánh bằng:
-
MySQL Server đã tự cài đặt trên các phiên bản EC2 sử dụng bộ nhớ cục bộ, đặc biệt là các phiên bản i3 với NVMe được đính kèm cục bộ. Tôi hiểu rằng bộ nhớ phiên bản là không đáng tin cậy, vì vậy người ta sẽ cần chạy các nút dự phòng.
-
MySQL Server đã tự cài đặt trên các máy chủ vật lý trong trung tâm dữ liệu của chúng tôi, sử dụng bộ lưu trữ SSD gắn trực tiếp.
Giá trị của việc sử dụng Aurora làm cơ sở dữ liệu đám mây được quản lý không chỉ là về hiệu suất. Nó cũng có chức năng giám sát tự động, sao lưu, chuyển đổi dự phòng, nâng cấp, v.v.
