Chỉ Perf thôi là chưa đủ

Văn hóa ám ảnh hiệu năng của cơ sở dữ liệu

• Ngành cơ sở dữ liệu đang tập trung vào việc cải thiện hiệu năng, nhưng trải nghiệm người dùng thực tế thường bị ảnh hưởng bởi các yếu tố khác.
• Với người dùng khi xử lý dữ liệu, điều thực sự quan trọng có thể không phải là tối ưu hóa truy vấn mà là định dạng của dữ liệu hoặc khả năng diễn đạt câu hỏi bằng SQL.
• Hiệu năng của cơ sở dữ liệu rất quan trọng, nhưng có thể tốt hơn nếu chọn cơ sở dữ liệu dựa trên các yếu tố khác như tính dễ sử dụng, hệ sinh thái, tốc độ cập nhật và khả năng tích hợp vào quy trình làm việc.

Hồi kết của cuộc chiến benchmark

• Năm 2019, GigaOm đã công bố một benchmark so sánh các cloud data warehouse, nhưng kết quả thị trường thực tế lại cho thấy một cục diện khác.
• Khi kết quả benchmark không khớp với trải nghiệm người dùng, điều đó gợi ý rằng benchmark có thể đã sai, đã kiểm thử sai thứ cần kiểm thử, hoặc hiệu năng có thể không quan trọng đến vậy.

Ý nghĩa của sự nhanh

• Trong lĩnh vực cơ sở dữ liệu đám mây, người ta có xu hướng tập trung vào khoảng thời gian từ lúc người dùng bấm nút "Run" đến khi kết quả sẵn sàng.
• Điều thực sự tác động đến người dùng là thời gian để hoàn thành công việc, và đó không đồng nghĩa với thời gian của máy chủ cơ sở dữ liệu.

Hiệu năng mang tính chủ quan

• Hiệu năng phải được đo từ góc nhìn của người dùng, và vì là vấn đề UX nên không thể diễn tả bằng một con số duy nhất.
• Tính chủ quan của hiệu năng có nghĩa là việc cái nào nhanh hơn sẽ được quyết định bởi cách cơ sở dữ liệu được sử dụng.

Tốc độ thay đổi

• DuckDB đang được cải thiện rất nhanh, khiến các benchmark hiện tại trở nên kém ý nghĩa.
• Khi chọn cơ sở dữ liệu, không chỉ hiệu năng hiện tại mà cả những thay đổi về hiệu năng và tính năng trong tương lai cũng là biến số quan trọng.

Không có hạt đậu thần kỳ

• Nếu mọi cơ sở dữ liệu đều được duy trì tích cực, hiệu năng theo thời gian sẽ có xu hướng hội tụ.
• Những khác biệt hiệu năng lớn khó có khả năng duy trì lâu dài theo thời gian.

Vấn đề nằm giữa ghế và bàn phím, giữa bàn phím và cơ sở dữ liệu

• Thước đo hiệu năng quan trọng với người dùng là thời gian từ khi có câu hỏi đến khi nhận được câu trả lời.
• Tính năng quan trọng là tốc độ đi từ ý tưởng đến câu trả lời, chứ không phải chỉ là thời gian cơ sở dữ liệu chạy truy vấn.

Về những chùm nho chua

• DuckDB hiện đứng nhóm đầu trong các benchmark của ClickBench và h20.ai, đồng thời cũng cho hiệu năng không tệ ở TPC-H và TPC-DS.
• Trước khi giả định một cơ sở dữ liệu là nhanh, điều quan trọng là phải thử nó trên khối lượng công việc thực tế.

Kết luận

• Những công ty cơ sở dữ liệu thành công nhất không thành công nhờ hiệu năng nhanh hơn đối thủ.
• Những cơ sở dữ liệu lấy hiệu năng làm điểm bán hàng chính đã không thành công trên thị trường.
• Khi chọn cơ sở dữ liệu, lời khuyên là nên quyết định dựa trên các yếu tố khác ngoài tốc độ thô.

Ý kiến của GN⁺

• Bài viết này nhấn mạnh rằng không chỉ tập trung vào hiệu năng của cơ sở dữ liệu mà còn cần tối ưu hóa trải nghiệm người dùng và quy trình làm việc. Đây cũng là một bài học quan trọng cho các kỹ sư phần mềm mới vào nghề: khi chọn cơ sở dữ liệu, cần cân nhắc cách tiếp cận lấy người dùng làm trung tâm thay vì chỉ nhìn vào các chỉ số hiệu năng đơn thuần.
• Hiệu năng của cơ sở dữ liệu có xu hướng hội tụ theo thời gian, vì sự tiến bộ công nghệ lan tỏa trên mọi nền tảng. Điều này cho thấy khi lựa chọn công nghệ, nên cân nhắc hỗ trợ dài hạn và khả năng cải tiến thay vì chỉ nhìn vào hiệu năng ngắn hạn.
• Các dự án mã nguồn mở như DuckDB có thể phát triển rất nhanh nhờ tốc độ cải tiến và sự hỗ trợ từ cộng đồng. Điều này có nghĩa là khi áp dụng công nghệ mới, cần xem xét mức độ năng động của cộng đồng và tốc độ phát triển của dự án.
• Khi chọn cơ sở dữ liệu, điều quan trọng là không nên chỉ dựa vào kết quả benchmark hiệu năng mà cần kiểm thử hiệu năng trên khối lượng công việc thực tế. Điều này có thể giúp chọn được cơ sở dữ liệu phù hợp hơn với trường hợp sử dụng thực tế.
• Bài viết nhấn mạnh rằng việc lựa chọn công nghệ cơ sở dữ liệu cần xem xét không chỉ khía cạnh kỹ thuật mà còn cả nhu cầu kinh doanh, độ dễ bảo trì và hiệu quả xử lý dữ liệu.

[GN⁺]

Ý kiến Hacker News

• Sau vài năm có rất nhiều phàn nàn từ khách hàng, họ mới nhận ra lỗi trong driver JDBC đang làm giảm hiệu năng. Rất nhiều thời gian của kỹ sư đã được đầu tư để tăng tốc truy vấn, nhưng connector mà đa số người dùng sử dụng lại thêm độ trễ lớn hơn rất nhiều so với phần thời gian đã tiết kiệm được. Hơn nữa, họ hoàn toàn không nhận ra điều này. Vì không ai bên trong Google dùng driver JDBC nên họ không thể nhìn thấy thời gian truy vấn mà người dùng thực sự trải nghiệm, và xem đó là vấn đề của người khác.

  • Bình luận này bày tỏ sự thất vọng vì Google đã "hoàn toàn mù mờ" trước những phàn nàn của khách hàng và không tự dùng chính sản phẩm của mình. Câu chuyện về phần JDBC đặc biệt gây ấn tượng.
• Google đã xây dựng một cơ sở dữ liệu hoạt động tốt trong nội bộ, nhưng lại thuê ngoài lớp adapter cho thế giới bên ngoài, và nó không hoạt động đúng cách, khiến bên ngoài phải dùng một cơ sở dữ liệu tồi. Phần lõi tinh vi mà Google sử dụng được bao quanh bởi các adapter không hoàn thiện, tạo ra một sản phẩm tổng thể lộn xộn một cách không cần thiết. Bên trong thì không nhận ra điều đó, còn người bên ngoài thì khó mà xác định được.
  • Bình luận này cho rằng nhận xét đó rất đúng với chiến lược mã nguồn mở của Google.
• Tôi thấy việc blog khẳng định rằng "hiệu năng là chủ quan" là điều kỳ lạ. Chỉ đo lường thôi thì chưa đủ, nhưng trong ví dụ duy nhất được đưa ra, hiệu năng là điều quan trọng và mang tính khách quan. Chỉ là họ đã đo sai thứ cần đo mà thôi.
  • Bình luận này đặt câu hỏi về lập luận của bài blog liên quan đến việc đo hiệu năng.
• Nghe như đây là vấn đề về tổ chức công ty. Nếu mục tiêu cuối cùng là khiến khách hàng dùng cloud và mang lại giá trị cho họ, thì không thể dùng các chỉ số khác với điều mà khách hàng quan tâm. Trong nội bộ Google phải có người chủ động lắng nghe vấn đề của khách hàng và truyền đạt lại cho kỹ sư để họ biết cần cải thiện điều gì.
  • Bình luận này nhấn mạnh sự cần thiết của một cấu trúc tổ chức để Google hiểu nhu cầu khách hàng và cải thiện dựa trên đó.
• Từ nhà ở Seattle đến văn phòng San Francisco mất khoảng 4,5 giờ tính từ cửa đến cửa.
  • Bình luận này chỉ ra rằng các nhà sáng lập không còn di chuyển với tốc độ nhanh như trước nữa, và đùa rằng có thể là vì Cục Dự trữ Liên bang đã tăng lãi suất.
• Tôi không nghĩ hiệu năng là thứ yếu theo cách bài này đang nói. Sau khi xác nhận hiệu năng đã đủ tốt, mới nên đánh giá mọi thứ khác. Chính tác giả cũng tự nói rằng "DuckDB nhanh". Nếu không phải vậy thì họ đã phải lao vào cuộc đua hiệu năng rồi.
  • Bình luận này không đồng ý với quan điểm cho rằng hiệu năng là thứ yếu, và cho rằng trước hết phải xác nhận hiệu năng đã đủ tốt.
• Hiệu năng là "tương đối", chứ không phải "chủ quan". Ý nghĩa của nó gắn với công việc đang được thực hiện.
  • Bình luận này giải thích tính tương đối của hiệu năng, đồng thời phân biệt nó với cảm nhận về hiệu năng trong thiết kế giao diện người dùng.
• Ứng dụng web phổ biến đầu tiên của tôi lưu toàn bộ trạng thái trong Python dict và cứ vài phút lại dump ra đĩa. API khi đó rất nhanh, nhưng sau khi chuyển sang MongoDB thì hiệu năng không bao giờ hồi phục được nữa. Dù vậy, ngày nay khi xây dựng website, tôi vẫn không chọn "pickledb".
  • Bình luận này chia sẻ trải nghiệm về hiệu năng của một ứng dụng web thời kỳ đầu và sự suy giảm sau khi chuyển đổi cơ sở dữ liệu.
• Tôi đã xây dựng hệ quản trị cơ sở dữ liệu của riêng mình và muốn benchmark hiệu năng với các cơ sở dữ liệu phổ biến khác như Postgres, Sqlite, MySQL, SQL Server.
  • Bình luận này giải thích rằng họ chỉ thấy hài lòng khi đo cả khoảng thời gian từ lúc người dùng nhấn nút "run" đến khi kết quả hiện lên màn hình, và cơ sở dữ liệu của họ nhanh hơn trên nhiều loại truy vấn khác nhau.
• "Tất nhiên, quy tắc này có ngoại lệ, đó là khi khác biệt về kiến trúc rất khó vượt qua. Cơ sở dữ liệu shared nothing sẽ ở thế bất lợi so với shared disk, và Redshift đã mất nhiều năm chủ yếu để chuyển sang kiến trúc shared disk. Lakehouse lưu metadata trên object storage sẽ gặp khó khăn với các cập nhật nhanh; điều đó là nội tại của mô hình."
  • Bình luận này chỉ ra các vấn đề liên quan đến khác biệt kiến trúc cơ sở dữ liệu, đồng thời nói rằng họ đang tìm tài liệu hay về chủ đề này.