Đánh giá MySQL 8.0.34 của Jepsen

 (jepsen.io)
3 điểm bởi GN⁺ 2023-12-20 | 1 bình luận | Chia sẻ qua WhatsApp

Bối cảnh của MySQL

  • MySQL là một trong những cơ sở dữ liệu SQL được triển khai rộng rãi nhất trong suốt 28 năm qua.
  • Chủ yếu được dùng cho xử lý giao dịch trực tuyến (OLTP), đồng thời cũng được triển khai cho OLAP và như một phần của các hệ thống hàng đợi.
  • Ban đầu được thiết kế như một cơ sở dữ liệu máy chủ đơn, nhưng đã được mở rộng bằng nhiều phương thức sao chép đa nút khác nhau.
  • Bài viết tập trung phân tích MySQL sử dụng storage engine InnoDB.

Các mức cô lập ANSI SQL thực ra không tốt

  • Để bàn về những sắc thái tinh vi của các mức cô lập SQL, cần giải thích bối cảnh lịch sử của bốn mức an toàn cho tính nhất quán giao dịch được đề xuất năm 1977 và tiêu chuẩn SQL do ANSI công bố năm 1986.
  • ANSI SQL định nghĩa các mức cô lập thông qua ba hiện tượng có thể xảy ra: dirty read, non-repeatable read và phantom.
  • Năm 1995, các khiếm khuyết của mức cô lập ANSI SQL đã được chỉ ra; đến năm 1999, Adya đã xây dựng một định nghĩa hình thức và độc lập với cách triển khai cho các mức cô lập của ANSI SQL.

Các mức cô lập của MySQL

  • Tài liệu MySQL cho biết hệ thống cung cấp bốn mức cô lập giao dịch được mô tả trong tiêu chuẩn SQL:1992.
  • Có kèm theo phần giải thích cách MySQL đạt được điều đó ở từng mức cô lập.
  • Mức cô lập Repeatable Read của MySQL đảm bảo tính an toàn thông qua cơ chế snapshot.

Thiết kế kiểm thử

  • Thiết kế một bộ kiểm thử cho MySQL bằng thư viện kiểm thử Jepsen.
  • Tiến hành kiểm thử trên nhiều môi trường khác nhau như một nút MySQL đơn, cụm sao chép binlog và cụm AWS RDS.
  • Sử dụng trình kiểm tra list-append của Elle để chạy các workload chính cho cô lập giao dịch.

Kết quả

  • Repeatable Read của MySQL cho phép G2-item, điều bị mức cô lập PL-2.99 của Adya cấm.
  • Repeatable Read của MySQL cũng cho phép G-single (read skew).
  • Repeatable Read của MySQL cho phép hiện tượng P4 (lost update).
  • Repeatable Read của MySQL cho thấy lỗi nhất quán nội bộ.
  • Repeatable Read của MySQL vi phạm Monotonic Atomic View.

GN⁺ bình luận

  • Việc mức cô lập Repeatable Read của MySQL thể hiện hành vi khác với những gì được nêu trong tiêu chuẩn là thông tin quan trọng đối với lập trình viên và quản trị viên cơ sở dữ liệu. Điều đó có nghĩa là nó có thể không đáp ứng được kỳ vọng về tính nhất quán dữ liệu và cô lập.
  • Kết quả kiểm thử cung cấp thông tin thiết yếu để hiểu các mức cô lập của hệ quản trị cơ sở dữ liệu và lựa chọn cơ chế cô lập phù hợp.
  • Những phát hiện này mang lại góc nhìn về việc các tiêu chuẩn liên quan đến mức cô lập của cơ sở dữ liệu có thể khác với cách triển khai thực tế như thế nào. Điều này giúp hiểu rõ hơn sự phức tạp của công nghệ cơ sở dữ liệu và những khác biệt tinh vi giữa các mức cô lập.

Bài viết liên quan

1 bình luận

 
GN⁺ 2023-12-20
Ý kiến trên Hacker News

  • Từ lâu đã cho rằng repeatable read là một ý tưởng tồi. Ngay cả khi việc triển khai là hoàn hảo và hoạt động đúng trong cơ sở dữ liệu, nó vẫn khó hiểu khi xử lý các truy vấn phức tạp.

    • Nghĩ rằng chỉ có hai mức cô lập thực sự có ý nghĩa:
      • read committed
      • serializable
    • Với thiết lập serializable thì không có gì bất ngờ xảy ra. Ở phía read committed, nếu muốn có một góc nhìn nhất quán về dữ liệu thì điều hiển nhiên là phải khóa hàng trước khi bắt đầu đọc.
    • read committed rất giống với mã đa luồng thông thường và quản lý bộ nhớ, nên hầu hết kỹ sư có thể hiểu theo trực giác.
    • serializable rất nghiêm ngặt nên khó mắc phải những sai lầm ngoài dự kiến.
    • Mức ở giữa là vùng đất không thuộc về ai, và thứ gì kém nhất quán hơn Read Committed thì không còn là cơ sở dữ liệu nữa.

  • Sẽ có bài trình bày tại FOSSDEM-2024 về "Isolation Levels and MVCC in SQL Databases: A Technical Comparative Study".

    • Nghiên cứu so sánh Oracle, MySQL, SQL Server, PostgreSQL, YugabyteDB.

  • Bài viết đang đánh giá AWS RDS, nhưng tự hỏi liệu có tập trung vào AWS Aurora (MySQL) hay không. AWS xây dựng một nền tảng cơ sở dữ liệu giả làm MySQL hoặc PostgreSQL. Sẽ rất thú vị nếu xem Aurora MySQL có những "tính năng" giống RDS hay MariaDB hay không.

  • Nghĩ rằng đây là một ví dụ tuyệt vời cho thấy những "hệ thống thực sự hoạt động" được xây dựng trên một nền tảng phơi bày rất nhiều hiện tượng nhất quán.

  • Khá đáng lo khi bản sao RDS ngừng hoạt động chỉ sau 5 phút mà không có cảnh báo kiểm tra sức khỏe thất bại.

  • Tò mò không biết append (a) được ánh xạ như thế nào sang thao tác SQL thực tế trên bảng đã cho, và liệu trường TEXT có đang được dùng như một danh sách hay không.

    • Đã từng có vấn đề trong chế độ repeatable read của MySQL, nơi một câu SELECT đơn lẻ chọn một hàng duy nhất nhưng trả về kết quả bất khả. Ví dụ, trong SELECT min(value), max(value) FROM table WHERE id = 1;, khi id là khóa chính thì đã từng nhận được các giá trị khác nhau cho min và max.

  • Sẽ hữu ích nếu có so sánh với các cơ sở dữ liệu quan hệ phổ biến khác như PostgreSQL, MS SQL, Oracle, chứ không chỉ so với định nghĩa lý thuyết của các chế độ cô lập. Đây là điều các nhà phát triển cần ghi nhớ khi muốn đảm bảo tính tương thích.

  • Có vẻ như SELECT ... FOR UPDATE là lời giải cho tất cả các vấn đề này; nếu khóa các hàng sẽ được cập nhật thì mọi thứ sẽ hoạt động đúng như quảng cáo.

  • Hôm nay định làm chút việc, nhưng cảm ơn aphyr vì 'call me maybe' và jepsen.io là một phần trong số những nội dung hay nhất từng đọc trên internet.

  • Tò mò không biết bao nhiêu phần trong phân tích về MySQL cũng sẽ đúng với MariaDB, vốn dùng InnoDB làm storage engine mặc định.