Câu chuyện CSR # 8: Tại sao đánh giá khủng khiếp lại tốt cho bạn!

Câu chuyện CSR # 8 đến từ Giáo sư Barzan Mozafari tại Michigan. Barzan dẫn đầu một nhóm nghiên cứu thiết kế thế hệ cơ sở dữ liệu có thể mở rộng tiếp theo bằng các mô hình thống kê tiên tiến. Gần đây, thuật toán lập lịch khóa VATS của họ đã được MySQL và MariaDB áp dụng, vì vậy tôi đã nói chuyện với Barzan về cách thức thực hiện công việc VATS. Tôi cũng trò chuyện với một trong những cộng tác viên công nghiệp của họ, Sunny Bains từ Oracle, để có được khía cạnh công nghiệp của câu chuyện này. Nhìn chung, nó làm cho một câu chuyện CSR tuyệt vời! Đầu tiên, hãy nghe từ Barzan:

Đó là mùa hè năm 2013. Tôi mới bắt đầu làm giáo sư theo dõi nhiệm kỳ tại Đại học Michigan, và tôi đang cố gắng tìm ra những gì để làm việc. Trong postdoc của tôi tại MIT, tôi đã đóng góp cho một số dự án khác nhau, từ phân tích (ví dụ: BlinkDB), đến các giao dịch và điện toán đám mây (ví dụ: DBSeer) cho đến dịch vụ đám đông. Trong số này, DBSeer là thử thách khó khăn nhất mà tôi đã từng thực hiện. Mục tiêu với DBSeer là dự đoán hiệu năng của một hệ thống cơ sở dữ liệu (trong trường hợp này là MySQL) với một khối lượng công việc. Trong gần hai năm, tôi đã thử mọi thuật toán học máy trong sách giáo khoa. Mặc dù chúng tôi đã có một số thành công trong việc dự đoán việc sử dụng tài nguyên (ví dụ: IO đĩa hoặc CPU), kết quả của chúng tôi rất tầm thường khi dự đoán độ trễ thực tế của giao dịch.

Có hai lý do cơ bản cho việc này. Đầu tiên, chúng tôi đã quyết định rằng chúng tôi chỉ quan tâm đến các giải pháp không xâm phạm. Ví dụ, chúng ta sẽ chỉ xem xét các biến trạng thái toàn cầu của MySQL. Điều đó có nghĩa là chúng tôi đã không có quyền truy cập vào một số thống kê quan trọng đơn giản chỉ vì MySQL didn lộ ra chúng. (Dự án Andy Pavlo từ Peloton là một cách tuyệt vời để giải quyết vấn đề đầu tiên này bằng cách truy cập vào cơ sở dữ liệu). Nhưng vào thời điểm đó, lý do của chúng tôi là nếu chúng tôi có thể thực hiện công việc này, thì việc áp dụng DBSeer sẽ trở thành không có trí tuệ. Lý do thứ hai đơn giản hơn nhiều: MySQL chỉ là một hệ thống có thể dự đoán được để bắt đầu! Bạn có thể gửi cùng một truy vấn trong cùng một điều kiện chính xác nhiều lần và bạn vẫn nhận được độ trễ khác nhau rộng rãi mỗi lần! Với nhiều tiếng ồn trong tín hiệu này, có rất nhiều việc phải làm cho máy học. Nó đơn giản như vậy. Và tôi nên chỉ ra rằng đây không phải là MySQL: mọi DBMS khác mà chúng tôi đã xem đều không thể đoán trước được. Tổ tiên của chúng ta, khi họ đang thiết kế các hệ thống di sản này, đã quá tập trung vào việc làm cho chúng nhanh hơn, và kết quả là không có gì đáng lo ngại về khả năng dự đoán của chúng.

Vì vậy, tôi đã ở đó, vừa mới bắt đầu ở Michigan, và tôi nhận ra rằng có một cơ hội tuyệt vời để thay đổi điều này một lần và mãi mãi: hãy để hệ thống cơ sở dữ liệu dễ dự đoán hơn, không chỉ nhanh hơn. Gần đây tôi đã tuyển dụng Jiamin Huang, một sinh viên ấn tượng với các kỹ năng hệ thống không thể tin được. Chúng tôi đặt ra để giải mã những gì có thể gây ra không thể đoán trước. Nghi ngờ đầu tiên của chúng tôi là L2 nhớ cache. Chúng tôi đã hợp tác với một trong những đồng nghiệp phần cứng của tôi (Tom Wenisch) để điều tra vấn đề này và một số nguyên nhân tiềm năng khác, nhưng rất nhanh, đó là một kỳ công không thể giải quyết bằng tay, vì mức độ phức tạp của mã cơ sở MySQL. Chúng tôi sớm thấy mình tạo ra trình tạo hồ sơ của riêng mình, không giống như Dtrace và các trình biên dịch khác, được thiết kế đặc biệt để tìm ra nguyên nhân gốc của phương sai hiệu năng trong một cơ sở mã lớn và phức tạp. Hóa ra trình hồ sơ của chúng tôi không dành riêng cho cơ sở dữ liệu và cuối cùng chúng tôi đã biến nó thành VProfiler và sau đó đã xuất bản nó tại EuroSys 2017. Nó đã xem xét hàng triệu dòng mã và sau đó thông báo cho nhà phát triển một vài cặp đôi cần thiết các chức năng sử dụng để làm cho ứng dụng của bạn có thể dự đoán được.

Phần cơ sở dữ liệu của những phát hiện của chúng tôi có một câu chuyện thú vị hơn nhiều. VProfiler tiết lộ một loạt các thủ phạm gây ra sự khó lường. Ví dụ, một trong những phát hiện của chúng tôi là trong MySQL Hàng đợi xếp hàng đằng sau các tài nguyên được chia sẻ là nguyên nhân chính của phương sai độ trễ. Nhìn chung, điều này rất trực quan: khi N giao dịch đang chờ trong hàng đợi cho cùng một tài nguyên được chia sẻ, thì giao dịch trước hàng đợi sẽ trải qua thời gian chờ rất khác so với giao dịch ở cuối hàng đợi và cả hai đều là sẽ rất khác so với cái ở giữa hàng đợi. Đây là lý do tại sao họ kết thúc triển lãm độ trễ rất khác nhau để làm cùng một lượng công việc.

Tóm lại, chúng tôi tập trung vào cách quản lý hàng đợi và thật kinh ngạc, chúng tôi nhận ra rằng mọi cơ sở dữ liệu trên thế giới vẫn đang sử dụng một số biến thể của FIFO (nhập trước, xuất trước). Chúng tôi đã đưa ra một thuật toán mới, được gọi là VATS (Lập kế hoạch giao dịch Aware), để giảm phương sai và xuất bản nó trong bài báo SIGMOD 2017 của chúng tôi (Cách tiếp cận từ trên xuống để đạt được khả năng dự đoán hiệu suất trong hệ thống cơ sở dữ liệu). Một trong những điều tuyệt vời của cái nhìn sâu sắc được cung cấp này là khả năng dự đoán không phải trả giá bằng hiệu suất trung bình. Nói cách khác, có một cách để làm cho các hệ thống dễ dự đoán hơn đồng thời làm cho chúng nhanh hơn: bằng cách giảm phương sai dựa trên tranh chấp.

Sau đó, chúng tôi đưa ra vấn đề chung về lập lịch khóa. Chúng tôi đã khám phá một thuật toán mới, khác biệt, tối ưu để giảm độ trễ trung bình (và tăng thông lượng) và được xuất bản trong VLDB 2018 (Lập lịch khóa nhận biết của Contection cho cơ sở dữ liệu giao dịch. Chúng tôi đã gọi thuật toán mới này là VATS 3.0 (chúng tôi chưa bao giờ công bố VATS 2.0) mà sau này chúng tôi đặt tên là CATS (Lập kế hoạch giao dịch Aware-Aware).

Lập kế hoạch giao dịch Aware-Aware: Cấp khóa trên O1 cho t1 cho phép song song hơn (giảm nhiều tranh chấp hơn) so với cấp cho t2

Từ góc độ áp dụng công nghiệp, mọi thứ diễn ra khá suôn sẻ: cả MySQL và MariaDB đều chạy các điểm chuẩn riêng với thuật toán mới của chúng tôi và quyết định áp dụng nó trong các phiên bản độc lập của chúng (MySQL thậm chí còn biến nó thành chiến lược mặc định của chúng). Chúng tôi rất biết ơn tất cả các cộng tác viên nguồn mở của chúng tôi trong cộng đồng MySQL, bao gồm phản hồi và trợ giúp vô giá từ Jan Lindstrom (MariaDB), Sunny Bains và Dimitri Kravtchuk (Oracle), Laurynas Biveinis và Alexey Stroganov (Percona), Mark Callaghan ( Facebook) và Daniel Black (IBM).

Tuy nhiên, từ quan điểm học thuật, mọi thứ đã diễn ra khá suôn sẻ. Đây là một dòng thời gian của những gì đã xảy ra:

Tuyên bố miễn trừ trách nhiệm: Một số tên / năm của hội nghị có thể khác

  • SIGMOD [16: Chúng tôi đã gửi kết quả MySQL của mình.
  • Từ chối: Làm sao chúng ta biết nếu nó hoạt động cho bất cứ thứ gì khác ngoài MySQL?

Bình luận: Thật thú vị, bạn chỉ nhận được những bình luận như ý kiến ​​này khi bạn áp dụng ý tưởng của mình vào một hệ thống thực sự. Nếu bạn chỉ đơn giản tạo nguyên mẫu cho ý tưởng của mình từ đầu và tạo cơ sở dữ liệu mô phỏng, thông thường sẽ không có ai hỏi liệu nó có áp dụng cho các hệ thống thực khác không! Không nản lòng trước những bình luận này, học sinh của tôi đã quyết định chứng minh người đánh giá sai

  • VLDB hè16: Chúng tôi cũng đã áp dụng VProfile cho Postgres và VoltDB.
  • Từ chối: Trước đây, nếu vấn đề này đủ quan trọng, người khác sẽ làm điều đó ngay bây giờ!

Bình luận: Cho đến ngày nay, đây vẫn là một trong những đánh giá yêu thích của tôi! Nhận được một đánh giá không công bằng không bao giờ là niềm vui, nhưng điều này thật vô lý đến nỗi nó đã làm phiền chúng tôi - thực tế, chúng tôi thấy nó khá thú vị. Mặc dù chúng tôi muốn chúng tôi có cơ hội hỏi người đánh giá đó hai câu hỏi:

1) Người đánh giá có đo lường nghiên cứu của mình chống lại cùng một thanh không? (Chúng tôi biết đó là một người anh hùng, xem Bài 5.)

2) Làm thế nào chúng ta có thể đạt được sự tiến bộ trong nghiên cứu bằng cách áp dụng nguyên tắc này? Nếu một cái gì đó đã được thực hiện, thì nó không phải là mới và có thể xuất bản, và nếu nó chưa được thực hiện, thì nó chỉ không đủ quan trọng và không có điểm nào trong việc xuất bản chúng!

  • OSDI Số16: Tuy nhiên, học sinh của tôi một lần nữa quyết định chứng minh người đánh giá sai và chứng minh rằng vấn đề là có thật. Vì vậy, chúng tôi đã gửi các thuật toán và kết quả của mình cho cả MariaDB và MySQL. VATS đã được MySQL chọn làm lịch trình mặc định và chúng tôi đã đề cập đến nó trong bài báo.
  • Từ chối: Bạn đã áp dụng VProfiler cho MySQL, Postgres và VoltDB. Làm thế nào để chúng ta biết nếu nó hoạt động cho bất cứ điều gì khác ngoài DBMS?

Bình luận: Đây là một mối quan tâm công bằng. Xét cho cùng, OSDI là một hội nghị về hệ điều hành. Chúng tôi thực sự rất hài lòng với chất lượng của các đánh giá chúng tôi nhận được. Là một nhà nghiên cứu DB, tôi luôn ghen tị với cộng đồng hệ điều hành vì hệ thống đánh giá tốt hơn đáng kể của họ.

  • SIGMOD xông17: Chúng tôi đã gửi VATS và các kết quả cơ sở dữ liệu khác.
  • Chấp nhận! Cuối cùng!
  • EuroSysTHER17: Chúng tôi đã khái quát hóa trình hồ sơ của mình, sau này trở thành VProfiler và áp dụng cho Máy chủ Web Apache ngoài các hệ thống cơ sở dữ liệu.
  • Chấp nhận! Yay!
  • VLDBiên18: Cuối cùng, một khi chúng tôi quản lý để chính thức hóa vấn đề lập lịch khóa, chúng tôi cũng có thể giải quyết hiệu năng (không chỉ là dự đoán). Điều này đã trở thành thuật toán CATS.
  • Chấp nhận. Chúng tôi thực sự đã nhận được những đánh giá tuyệt vời từ VLDBiên18. Chúng tôi cũng đã nhận được phản hồi đặc biệt từ Peter Bailis sau khi bài báo được xuất bản.

Vì vậy, đây là một số bài học từ bài viết dài này:

Bài học 1. Đánh giá khủng khiếp thực sự tốt cho bạn. Họ thúc đẩy bạn (và học sinh của bạn!) Làm nhiều việc hơn, đó không phải là kết quả xấu!

Bài 2. Donith tin tưởng những gì mọi người nói trên bảng. Mặc dù tất cả mọi người trong học viện sẽ ghi nhận về việc xác định giá trị tác động trong thế giới thực và xác nhận trong thế giới thực, một số người trong số họ đôi khi nói dối trong tiềm thức. Khi họ đội mũ người đánh giá, họ thường phạt các giấy tờ sử dụng hệ thống thực để đánh giá, ví dụ, bằng cách yêu cầu hàng tỷ thứ khác chỉ có thể có nếu bạn sử dụng mô phỏng nguyên mẫu. Tôi không có nghĩa là bạn nên từ bỏ việc sử dụng các hệ thống thực trong các thí nghiệm của mình, nhưng đơn giản là hãy chuẩn bị để thực hiện nhiều công việc hơn!

Bài 3. Học viện và công nghiệp có bước sóng khác nhau. Đối với những người trong chúng ta trong học viện, ba tháng cảm thấy như một sự vĩnh cửu. Tuy nhiên, các nhóm sản phẩm chạy theo dòng thời gian của riêng họ - đôi khi có thể mất đến một năm trước khi họ có bất kỳ chu kỳ nào cho bạn. Bạn chỉ cần kiên nhẫn và đánh giá cao công việc tuyệt vời mà họ làm trong việc duy trì một hệ sinh thái nguồn mở chất lượng cao.

Bài 4. Không phải mọi nhà phê bình đều là nhà toán học. Trong một trong những lần gửi trước đó của chúng tôi, chúng tôi đã báo cáo tỷ lệ phần trăm của tổng phương sai mà chúng tôi đã loại bỏ, đó là khoảng 65%. Rõ ràng là bạn có thể loại bỏ bất cứ thứ gì hơn 100%. Thật không may, đó chỉ là một giới hạn của luật toán học. Nhưng một trong những đánh giá của chúng tôi (tôi nghĩ SIGMOD hè16 hoặc VLDB hè16) đã cho rằng giảm 65% là không đủ. Vì vậy, trong lần gửi tiếp theo, chúng tôi đã chuyển sang báo cáo tỷ lệ cải tiến, được định nghĩa là phương sai của MySQL ban đầu chia cho phương sai của phiên bản sửa đổi của chúng tôi. Mức giảm 65% tương tự hiện được báo cáo là giảm 3 lần phương sai và những người đánh giá (mặc dù có lẽ là những người khác nhau) đã vui hơn lần này.

Bài học 5. Hãy tử tế, hoặc ẩn danh. Điều này áp dụng cho người đánh giá yêu thích của chúng tôi: Nếu bạn sẽ viết một bài đánh giá khó chịu, thì đó có lẽ không phải là một ý tưởng hay để yêu cầu các tác giả trích dẫn ba bài báo của riêng bạn. Nó không giá vé tốt với việc duy trì tính ẩn danh của bạn

Bài 6. Làm việc trên các hệ thống thực sự là một nỗi đau, nhưng nó hoàn toàn xứng đáng. Nếu bạn có thể sẵn sàng đưa ra các đánh giá kém và thời gian viết bài dài hơn đáng kể, làm việc trên các hệ thống thực sự là một kinh nghiệm cực kỳ bổ ích!

Hãy chuyển sang quan điểm công nghiệp về công việc này. Tôi đã trò chuyện với Sunny Bains từ Oracle, người có công trong việc nhận VATS được thông qua vào MySQL / InnoDB. Tôi trình bày cuộc trò chuyện của mình với anh ấy như một câu hỏi và trả lời.

CSRTales: Lần đầu tiên bạn tìm hiểu về CATS hoạt động như thế nào?

Sunny: IIRC Barzan và Jiamin đã xuất bản một bài báo có điểm chuẩn và được ai đó trong tổ chức của chúng tôi chuyển tiếp cho tôi. Sau đó, họ đã đóng góp một bản vá đó là những gì khiến tôi quan tâm. Khóa luôn cần một số tối ưu hóa hoặc khác và tại thời điểm đó, chúng tôi đang xem xét tối ưu hóa trình quản lý khóa InnoDB. Vì vậy, nó đã rất kịp thời. CATS như được gọi sau đó dường như là một ứng cử viên đầy triển vọng để xem xét. Ở giai đoạn đó, chúng tôi đã quá tập trung vào phân phối đồng đều và không thấy bất kỳ lợi ích nào. Ngoài ra, trọng tâm chuyển sang sửa chữa những thứ khác trong InnoDB. Khi chúng tôi có một số giải pháp tốt cho các vấn đề khác xung quanh việc quản lý giao dịch bên trong InnoDB, các vấn đề khóa lại được đưa lên hàng đầu. Nhóm InnoDB bắt đầu nhìn lại CATS và tình cờ Mark Callaghan từ Facebook gửi cho tôi một email vào ngày hôm sau giới thiệu tôi với Barzan và Jiamin. Hợp tác chặt chẽ hơn bắt đầu sau đó và với giao tiếp trực tiếp và sự giúp đỡ của họ, tất cả đã xuống dốc từ đó.

CSRTales: Bạn thích gì nhất về ý tưởng CATS khi bạn nghe về nó?

Sunny: Nó đã giải quyết một vấn đề thực sự và bản thân nội dung rất chung chung và tôi nghĩ nó có các ứng dụng vượt ra ngoài trình quản lý khóa. Quan trọng không kém từ góc độ thực tế là nó đi kèm với một bằng chứng về khái niệm. Một bản vá mà chúng tôi có thể kiểm tra ngay lập tức. Có rất nhiều ý tưởng hay nổi xung quanh. Để có một cái gì đó cụ thể để kiểm tra là một cộng lớn. Nó giúp chúng ta tiết kiệm rất nhiều thời gian và nguồn lực. Tôi cũng nghĩ rằng đây là một trong những lợi thế của phần mềm nguồn mở. Đây là một ví dụ rất tốt về điều đó.

CSRTales: Mất bao lâu kể từ lần đầu tiên nghe về công việc để hợp nhất nó?

Sunny: Tôi mất khoảng một năm. Từ khi chúng tôi quyết định cam kết với nó và đến lúc nó thực sự bị đẩy mất sáu tháng. Quá trình QA của chúng tôi rất nghiêm ngặt và tôi có thể cảm ơn QA của chúng tôi đủ. Có một số lỗi trong bản vá gốc. Chúng tôi quyết định viết lại nó quá. Chúng tôi cũng muốn giảm số lượng biến cấu hình dưới dạng chính sách. Có một số vấn đề với khóa khoảng cách phải được sửa trong bản vá.

CSRTales: Thông thường, trong các cộng đồng nguồn mở như nhân Linux, bạn cần phải có uy tín đã được xây dựng trước khi các bản vá của bạn được chấp nhận. Tôi đoán một điều tương tự đã xảy ra ở đây?

Sunny: Tất nhiên rồi. Chúng tôi nhận được khá nhiều bản vá / đóng góp. Nhưng tôi muốn nhấn mạnh rằng nó không phải là điều kiện tiên quyết. Chúng tôi sẵn sàng chấp nhận các bản vá hoạt động ngoài hộp và có một số tài liệu chứng minh vấn đề và cách các bản vá khắc phục các vấn đề này. Mong muốn thực sự của chúng tôi là khuyến khích các nhà nghiên cứu / người dùng / nhà phát triển bất kỳ ai quan tâm đến lĩnh vực này để tận dụng lợi thế của nguồn mở và gửi cho chúng tôi các bản vá của họ. Tôi muốn nhấn mạnh, nói chuyện là rẻ. Cho tôi xem mã :-)

CSRTales: Có phải là thông lệ để viết lại các bản vá đóng góp?

Sunny: Có, một khi chúng tôi quyết định cam kết với một số công việc thì chúng tôi muốn nó được thực hiện hoàn toàn trong nhóm. Có những lý do thực tế cho việc này. Quá trình QA khá căng thẳng và có toàn bộ cơ sở hạ tầng xung quanh các đánh giá mã và theo dõi vấn đề mà người ngoài sẽ không có quyền truy cập. Ngoài ra, người cam kết mã phải có quyền sở hữu cho các bản sửa lỗi sau này, v.v ... Chủ yếu là do thực tiễn mà chúng tôi không cho các tác giả gốc thực hiện công việc khi nó tiến triển. Chúng tôi (thực sự tôi đã làm) viết lại các bản vá. Có một cuộc trao đổi email liên tục giữa Jiamin, Dimitri, Barzan và tôi thảo luận về các vấn đề. Dimitri là kiến ​​trúc sư hiệu suất của chúng tôi. Đầu vào của họ rất hữu ích trong việc đảm bảo rằng tất cả chúng ta đều có cùng một mô hình tinh thần xung quanh ý tưởng của họ.

Tôi muốn chỉ ra một số điều thú vị trong CSRTale này. Đầu tiên, đây là một ví dụ tuyệt vời về cách nhận con nuôi trong ngành. Barzan và nhóm của ông đã đóng góp một bản vá có thể được kiểm tra trực tiếp. Điều này là rất quan trọng. Thứ hai, Barzan và nhóm của anh đã dành một lượng lớn thời gian để thảo luận về ý tưởng của họ với Sunny để đảm bảo họ ở cùng một trang. Chuyển giao công nghệ mất rất nhiều thời gian, trên và ngoài thời gian dành cho việc xuất bản bài báo. Nếu bạn đang tìm kiếm tác động, đây là một con đường tuyệt vời, nhưng hãy chú ý đến chi phí thời gian. Thứ ba, xem xét chất lượng không nhất quán trong cộng đồng hệ thống rộng. Tôi đã thấy những đánh giá tương tự như những gì Barzan nhận được: tôi nhận thấy rằng những người đánh giá nhất định (không phải tất cả đều biết ơn) trước tiên hãy quyết định, sau đó thử và tìm bất kỳ lý do nào để từ chối bài báo. Vì vậy, đôi khi các đánh giá là tín hiệu rất ồn ào: bạn có thể nghĩ rằng nếu bạn đã sửa những gì người đánh giá yêu cầu, bạn sẽ được chấp nhận, nhưng đó không phải là trường hợp thường xảy ra. Có thể có những điểm yếu khác trong bài viết của bạn mà bạn có thể dành thời gian để sửa chữa tốt hơn. Ví dụ: nếu các ý tưởng trong bài viết của bạn không xuất hiện rõ ràng, một người đánh giá có thể không thích bài viết của bạn và phàn nàn về việc đánh giá. Sửa lỗi đánh giá (không sửa lỗi viết) sẽ không cải thiện cơ hội chấp nhận của bạn. Nói chuyện với các cố vấn của bạn về điều này :)