Tìm hiểu sâu hơn về MySQL 8 của Facebook. 0 di cư

Tuần này, tổ chức phát triển của Facebook tuyên bố hoàn thành loại nhiệm vụ khiến doanh nghiệp khiếp sợ. một bản nâng cấp lớn cho cơ sở dữ liệu cốt lõi của nó. Larry Dignan đã nêu ra những điểm nổi bật trong phần tổng quan của anh ấy ngày hôm qua. Và trong phần tổng quan đó, anh ấy đã bóng gió nhiều hơn về những thử thách và khó khăn mà cuộc di cư gặp phải

Việc di chuyển cơ sở dữ liệu diễn ra mọi lúc và không thiếu lời khuyên về cách tiến hành chúng. Nhưng bài đăng trên blog chi tiết của Facebook đã mang lại những bài học quý giá, chúng ta sẽ tìm hiểu chi tiết hơn tại đây. Đó là một dự án lớn kéo dài nhiều năm, đặc biệt là vì Facebook có rất nhiều phiên bản MySQL

Trước hết, tất cả những ồn ào về là gì? . Việc nâng cấp quan trọng đến mức Oracle, công ty sở hữu MySQL, đã được yêu cầu thực hiện một đợt làm mới và nâng cấp lớn dịch vụ MySQL trên nền tảng đám mây của riêng mình

Có một danh sách dài các thay đổi trong 8. 0, nhưng chúng tôi sẽ đánh dấu một vài trong số chúng ở đây. Nó bắt đầu với khả năng quản lý. mysql 8. 0 thêm từ điển dữ liệu giao dịch theo tiêu chuẩn khác cho cơ sở dữ liệu cấp doanh nghiệp. Đơn giản hơn. tất cả các tác vụ liên quan đến ngôn ngữ định nghĩa dữ liệu (DDL) được gọi cho các lệnh thông thường hiện được kết hợp thành một câu lệnh duy nhất. Vì vậy, bạn không cần phải viết các câu lệnh riêng biệt để cập nhật từ điển dữ liệu, vận hành công cụ lưu trữ và ghi nhật ký nhị phân. Mã hóa bảng đã được sắp xếp hợp lý và hỗ trợ cải thiện cho các loại dữ liệu mở rộng như BLOB, TEXT, GEOMETRY và JSON

Có tính năng mới thú vị là "chỉ mục vô hình" cho phép kiểm tra tác động của việc xóa chỉ mục mà không cần phải xóa nó theo cách vật lý. Tính năng này tương tự như các tính năng lập chỉ mục nâng cao trong và Cơ sở dữ liệu Microsoft Azure SQL cho phép thử nghiệm các sơ đồ lập chỉ mục thay thế để đánh giá xem một số chỉ mục có đang lãng phí dung lượng hay không hoặc các chỉ mục mới hoặc đã sửa đổi có thể truy xuất dữ liệu với ít chi phí tính toán hơn

Nhưng như bất kỳ DBA có kinh nghiệm nào cũng sẽ chứng thực, luôn có một cái giá phải trả khi nâng cấp, chẳng hạn như làm mất ổn định các ứng dụng, đó là lý do tại sao hầu hết các tổ chức trì hoãn việc di chuyển cho đến khi nhu cầu quá lớn. Không phải ngẫu nhiên, hầu hết các nhà cung cấp Cơ sở dữ liệu dưới dạng dịch vụ (DBaaS) trên đám mây đều hứa hẹn sẽ loại bỏ nỗi đau nâng cấp vì họ trút bỏ gánh nặng đó cho khách hàng

Vì vậy, không có gì ngạc nhiên khi đứng đầu danh sách các bài học kinh nghiệm là xử lý các vấn đề về tính tương thích. Hãy bắt đầu với các tùy chỉnh, điển hình cho việc cài đặt dữ liệu doanh nghiệp cố định. Không có gì đáng ngạc nhiên, đây cũng là một vấn đề từ lâu trong thế giới ứng dụng doanh nghiệp, nơi các công cụ di chuyển tự động thường bỏ qua khi nói đến các tùy chỉnh. Trên thực tế, SAP hiện khuyến khích khách hàng thay vì giữ nguyên các triển khai cốt lõi và trừu tượng hóa các triển khai thông qua các API sẽ duy trì ổn định. Facebook không có được điều xa xỉ này với việc di chuyển MySQL. Như Larry đã lưu ý trong tài khoản của mình, chỉ có 1500 trong số 2300 bản vá tùy chỉnh được di chuyển, phần còn lại không được dùng nữa.

Một vấn đề liên quan là khả năng tương thích API và đây là lúc Facebook phát hiện ra một "gotcha" ẩn. " Như đã lưu ý, khách hàng thường trì hoãn việc di chuyển các hệ thống doanh nghiệp lớn vì thời gian và sự gián đoạn liên quan, và trong trường hợp này, điều đó có nghĩa là Facebook đã bỏ qua một chu kỳ. Thay vì đi từ MySQL 5. 6 đến 5. 7, họ đã bỏ qua bản phát hành tạm thời và đi thẳng đến 8. 0. Kết quả là cần phải thực hiện công việc điều tra liên quan đến các API được hỗ trợ; . 6 phát hành không được bao gồm trong 8. 0 tài liệu. Điều này đã thêm một hình phạt về thời gian

Việc di chuyển trong một số trường hợp cũng liên quan đến công cụ lưu trữ cơ bản. MySQL là một cơ sở dữ liệu hỗ trợ các công cụ lưu trữ có thể cắm được và kể từ năm 2016, Facebook đã chuyển các triển khai MySQL hướng tới người dùng của mình từ InnoDB, công cụ phổ biến nhất được sử dụng trong MySQL, sang MyRocks, một công cụ lưu trữ mã nguồn mở mà Facebook đã phát triển trên thực tế. Ưu điểm của MyRocks là nén và ghi hiệu quả hơn

Việc di chuyển từ InnoDB sang MyRocks yêu cầu khung thử nghiệm "bóng tối" để nắm bắt lưu lượng sản xuất và phát lại chúng trong các phiên bản thử nghiệm. Nhưng quá trình này không phải là hoàn hảo; . Đạo đức của câu chuyện là mặc dù bạn có thể mô phỏng một số tình huống, nhưng trong một số trường hợp, các lỗi sẽ không xuất hiện cho đến sau khi thực tế xảy ra và bạn nên tích hợp các bản sửa lỗi sau thực tế vào bất kỳ kế hoạch di chuyển và thử nghiệm nào

Vì tất cả các sự cố tương thích dự kiến ​​và không mong muốn, Facebook đã chơi rất thận trọng khi di chuyển dữ liệu. Thay vì quy trình sao chép bảng hoặc câu lệnh SQL thông thường, Facebook đã thực hiện từng hàng một – một quy trình rất khó khăn. Nhu cầu về hành động quyết liệt như vậy được thúc đẩy bởi danh mục ứng dụng lớn và khả năng gặp phải sự phụ thuộc lẫn nhau. một số dữ liệu có thể được Ứng dụng A sử dụng có thể được lấy từ quá trình xử lý của Ứng dụng B

Bài học không ngạc nhiên là việc di chuyển cơ sở dữ liệu doanh nghiệp hiếm khi tầm thường

Có rất nhiều lý do khiến Facebook đi theo con đường phổ biến đối với các doanh nghiệp lớn là trì hoãn cho đến khi thực sự cần thiết và vì điều đó có nghĩa là bỏ qua việc nâng cấp phiên bản trung gian nên nó đã phải trả giá. Nó khiến Larry đặt ra câu hỏi trong tác phẩm của mình rằng liệu tất cả những nỗ lực đó có xứng đáng hay không.

Câu hỏi đặt ra là liệu những vấn đề đau đầu này có thể tránh được hoặc giảm thiểu trong tương lai hay không, khi có MySQL 9. 0. Một câu trả lời – nếu bạn không phải là Facebook – đang chuyển sang DBaaS Cơ sở dữ liệu dưới dạng dịch vụ trên đám mây), nơi các nhà cung cấp đám mây liên tục giữ phiên bản hiện tại và được cho là bảo vệ khách hàng khỏi những thay đổi nền tảng cơ bản

Nhưng nếu bạn vẫn đang thử điều này ở nhà, Larry gợi ý cho câu trả lời. Bắt đầu lập kế hoạch ngay bây giờ cho tình huống đó. Cụ thể hơn, hãy nâng cấp bản phát hành dấu chấm, nhưng có thể về lâu dài, hãy bắt đầu tùy chỉnh trừu tượng bằng API, nếu có thể. Có thể trong tương lai, máy học có thể hỗ trợ dự đoán nơi có thể phát sinh các vấn đề tương thích, nhưng đây chắc chắn là một trường hợp mà trực giác của con người phải được kiểm soát

fb còn dùng MySQL ko?

MySQL vẫn được hỗ trợ chứ?