Chỉ hiệu năng thôi là chưa đủ

 (motherduck.com)
2 điểm bởi GN⁺ 2024-03-12 | 1 bình luận | Chia sẻ qua WhatsApp
  • Khi chọn cơ sở dữ liệu, nếu chỉ nhìn vào tốc độ truy vấn thô và các benchmark tổng quát, bạn dễ bỏ sót tổng thời gian để người dùng đi từ câu hỏi đến câu trả lời
  • Benchmark GigaOm năm 2019 xếp Azure Data Warehouse và Redshift ở vị trí cao, nhưng trên thị trường thực tế Snowflake và BigQuery lại bán chạy hơn, cho thấy sức mạnh của các yếu tố ngoài hiệu năng
  • Ngay cả khi giảm thời gian chạy trên máy chủ, các đường dẫn phụ cận như JDBC driver, tải kết quả xuống, phân tích CSV, độ khó khi viết SQL có thể trở thành nút thắt lớn hơn
  • ClickBench, TPC-H, TPC-DS đều hữu ích, nhưng kết luận có thể thay đổi tùy theo có JOIN hay không, quét một bảng, tinh chỉnh schema, các điều kiện về độ chính xác và bảo đảm ACID
  • Hiệu năng của engine cơ sở dữ liệu sẽ hội tụ theo thời gian, vì vậy tiêu chí lựa chọn dài hạn nên là tốc độ từ ý tưởng đến câu trả lời và khả năng tích hợp vào workflow, hơn là thứ hạng hiện tại

Độ trễ thực tế mà benchmark bỏ sót

  • Trong hành trình 4,5 giờ từ nhà ở Seattle đến văn phòng tại San Francisco, ngay cả khi tăng tốc độ bay hành trình của máy bay lên 10 lần, tổng thời gian có thể chỉ giảm khoảng 20% vì còn di chuyển đến sân bay, kiểm tra an ninh, lên máy bay, chờ trên đường băng, lấy hành lý và di chuyển tại điểm đến
  • Cơ sở dữ liệu cũng tương tự
    • Dù engine nhanh hơn, người dùng vẫn gặp đồng thời các vấn đề như file CSV kỳ lạ, khó diễn đạt câu hỏi bằng SQL, và vấn đề kết nối công cụ
    • Sản phẩm thắng trong cuộc chiến benchmark thì dễ quảng bá, nhưng điều đó không có nghĩa là nó trực tiếp rút ngắn thời gian giải quyết vấn đề của người dùng
  • Khi chọn cơ sở dữ liệu, tính dễ dùng, hệ sinh thái, tốc độ cập nhật và khả năng tích hợp workflow có thể là các tiêu chí đánh giá tốt hơn
  • Hiệu năng chỉ cho thấy thời gian của một tác vụ cụ thể tại một thời điểm cụ thể, và có thể khiến ta ra sức tối ưu một nút thắt đã xác định sai

Kết quả GigaOm năm 2019 và sự lệch pha với thị trường

  • Năm 2019, GigaOm chạy benchmark TPC-H và TPC-DS trên các cloud data warehouse
    • Đối tượng là ba nhà cung cấp cloud lớn và Snowflake
    • Kết quả cho thấy Azure Data Warehouse nhanh nhất, Redshift theo sau, còn Snowflake và BigQuery tụt lại khá xa
  • Khi đó, trong các đánh giá của người dùng BigQuery, nhiều khách hàng từng so sánh trực tiếp với Azure đã chọn BigQuery
  • Kết quả thị trường gần như ngược với thứ hạng benchmark
    • Snowflake và BigQuery bán chạy hơn Redshift
    • Redshift bán chạy hơn Azure
  • TPC-H và TPC-DS là tiêu chuẩn ngành và cũng được dùng để đánh giá hiệu năng nội bộ, nhưng nếu khách hàng mua nhiều hơn các hệ thống bị xếp hạng thấp trong một benchmark hiệu năng tốt, có thể xem là đã có những yếu tố quan trọng hơn hiệu năng

Cảm nhận nhanh của người dùng không phải là thời gian máy chủ

  • Những người xây dựng cơ sở dữ liệu thường có xu hướng tập trung vào thời gian thực thi trên máy chủ từ lúc người dùng bấm nút “run” đến khi kết quả sẵn sàng
  • Thời gian quan trọng với người dùng là tổng thời gian để hoàn thành công việc, và điều này khác với thời gian máy chủ cơ sở dữ liệu thực thi truy vấn
  • Trường hợp JDBC driver của BigQuery cho thấy rõ khác biệt này
    • JDBC driver là giao diện đa dụng để lập trình viên và công cụ BI kết nối đến cơ sở dữ liệu
    • Truy vấn BigQuery chạy xong trong 1–2 giây, nhưng do cách driver polling trạng thái hoàn thành và tải kết quả xuống, với người dùng nó trông chậm hơn thêm vài giây hoặc vài phút
    • Khi có nhiều kết quả, driver kéo về toàn bộ dữ liệu theo từng page, kể cả dữ liệu người dùng không cần, khiến độ trễ tăng lên và đôi khi crash vì thiếu bộ nhớ
  • Các kỹ sư dành nhiều thời gian để giảm thời gian truy vấn đi vài phần mười giây, nhưng connector mà người dùng thực sự dùng nhiều lại tạo ra độ trễ lớn hơn
  • Benchmark nội bộ chạy hằng ngày, nhưng hiệu năng end-to-end và thời gian người dùng cảm nhận thì không hiện ra

Hiệu năng không cố định trong một con số duy nhất

  • Hiệu năng cần được đo từ góc nhìn người dùng, không phải góc nhìn cơ sở dữ liệu, và giống như UX, rất khó được mô tả hoàn toàn bằng một con số
  • Cơ sở dữ liệu nào nhanh hơn phụ thuộc vào workload thực tế
    • Dù Lamborghini nhanh hơn Prius, trong cảnh kẹt xe thời gian đi làm có thể không khác
    • Chênh lệch hiệu năng giữa ClickHouse và Redshift cũng phụ thuộc vào cách sử dụng
  • ClickBench của ClickHouse cho kết quả ClickHouse nhanh hơn nhiều cơ sở dữ liệu khác
    • Benchmark chạy trên một bảng duy nhất, không JOIN, và phụ thuộc nhiều vào distinct count
    • Nó có thể là chỉ báo thay thế tốt cho phân tích log hoặc tính số người dùng duy nhất của website
    • Nhưng có thể gây hiểu nhầm với workload star schema của data warehouse truyền thống
  • Benchmark của vendor thường tập trung vào những phần vendor đó làm tốt
  • BigQuery có thể trông thấp trong benchmark, nhưng vì gần như không có knob và nhìn chung tự tinh chỉnh, trải nghiệm người dùng thực tế có thể được cảm nhận là tốt
  • Một instance SingleStore được tinh chỉnh cao có thể vượt xa BigQuery trong nhiều tác vụ, nhưng cần thời gian tinh chỉnh schema và phải xử lý khi thêm workload mới
  • Để tăng hiệu năng, người ta cũng có thể giảm bớt cơ chế an toàn hoặc độ chính xác
    • bỏ overflow check
    • bỏ qua write flush
    • cung cấp kết quả xấp xỉ cho một số phép toán
    • không cung cấp bảo đảm ACID
  • Những lối tắt như vậy có thể là lựa chọn bạn không muốn dùng, trừ trong môi trường được kiểm soát

Tốc độ cải thiện bền lâu hơn thứ hạng hiện tại

  • Khi lập một công ty dựa trên DuckDB, đã có ý kiến chỉ ra rằng DuckDB thua khá xa trong benchmark h2o.ai
  • Có hai lý do để không lo ngại
    • Hiệu năng là yếu tố thứ cấp
    • DuckDB đang cải thiện với tốc độ rất nhanh
  • Sự cải thiện nhanh của DuckDB chịu ảnh hưởng từ một số quyết định kiến trúc, codebase tương đối mới và sạch, cùng các kỹ sư xuất sắc
  • Trong kết quả công khai cho bản phát hành DuckDB mới nhất trên cùng benchmark, DuckDB đã đi từ nhóm giữa lên nhóm dẫn đầu với khoảng cách lớn
  • Lựa chọn cơ sở dữ liệu là quyết định kéo dài nhiều năm, nên không chỉ hiệu năng và tính năng hiện tại mà năng lực có thể có sau 1 năm cũng quan trọng
  • Nếu hai cơ sở dữ liệu cải thiện với tốc độ khác nhau, nhiều khả năng nên chọn bên di chuyển nhanh hơn

Khoảng cách hiệu năng thu hẹp theo thời gian

  • Khi nhiều cơ sở dữ liệu được bảo trì tích cực được cải thiện lặp đi lặp lại trong vài năm, hiệu năng có xu hướng hội tụ
  • Kỹ thuật hiệu năng của một sản phẩm có thể được triển khai ở sản phẩm khác theo thời gian
    • Nếu ClickHouse dùng kỹ thuật có lợi thế về tốc độ scan, Snowflake cũng có thể có tính năng tương tự trong 1–2 năm
    • Nếu Snowflake thêm materialized view tăng dần, BigQuery cũng có thể sớm theo sau
  • Mỗi cơ sở dữ liệu có các kỹ thuật khác nhau để đạt hiệu năng
    • biên dịch truy vấn thành machine code
    • cache dữ liệu trên SSD cục bộ
    • xử lý shuffle bằng phần cứng mạng chuyên dụng
  • Với đủ thời gian, ai cũng có thể triển khai các kỹ thuật hiệu quả, và nếu chúng hoạt động tốt, chúng có khả năng lan sang nhiều hệ thống
  • Trong so sánh hiệu năng data warehouse của CEO Fivetran George Fraser, năm 2020 thời gian nhanh nhất là 8 giây và chậm nhất là 18 giây, nhưng đến năm 2022 ba vendor đạt khoảng 7 giây và vendor chậm nhất cũng gần lại ở mức 9 giây
  • Tuy nhiên, khác biệt kiến trúc thì khó vượt qua
    • Cơ sở dữ liệu shared nothing có thể bất lợi so với shared disk
    • Redshift đã mất nhiều năm để chuyển chủ yếu sang kiến trúc shared disk
    • Lakehouse lưu metadata trong object store có thể gặp khó khăn với các cập nhật nhanh
  • Những khác biệt này chủ yếu xuất hiện ở các điều kiện biên, và về dài hạn không có lý do bản chất nào khiến Redshift phải nhanh hơn hay chậm hơn Snowflake

Các tính năng rút ngắn thời gian từ câu hỏi đến câu trả lời

  • Hiệu năng quan trọng với người dùng là thời gian từ lúc nảy sinh câu hỏi đến lúc có câu trả lời
  • Cách rút ngắn thời gian này không chỉ là cải thiện query plan
    • Có thể giúp diễn đạt câu hỏi dễ hơn
    • Có thể biến kết quả truy vấn thành dạng dễ hiểu hơn
    • Có thể đưa phản hồi khi người dùng đặt câu hỏi sai
    • Có thể giúp hiểu vấn đề của dữ liệu
    • Có thể giúp chuẩn bị dữ liệu cần thiết ở đúng vị trí và đúng hình thức
  • Snowflake có thế mạnh trong việc khiến SQL người dùng nhập vào “cứ thế chạy”
    • Khi tính chênh lệch ngày, có thể dùng cả DATEDIFF và TIMEDIFF
    • Nếu type hợp lý thì cả hai đều hoạt động
    • Có thể chỉ định hoặc bỏ qua granularity
    • Có thể dùng hoặc không dùng dấu nháy cho granularity
  • DuckDB cũng bổ sung các tính năng giúp viết và bảo trì truy vấn dễ hơn với Friendlier SQL
    • GROUP BY ALL giảm việc bỏ sót field trong mệnh đề GROUP BY của truy vấn tổng hợp
    • Chỉ cần thay đổi danh sách SELECT, nên khi truy vấn tiến hóa sẽ giảm nhu cầu sửa ở nhiều vị trí
    • Khi tính năng này trở nên hữu ích, nhiều vendor cơ sở dữ liệu đã thêm tính năng tương tự
  • CSV là định dạng chứa rất nhiều dữ liệu trên thế giới, nhưng nhiều file được cấu trúc sai và việc parsing thực sự khó
    • CSV splitter ban đầu của BigQuery không làm được inference, và bị rối khi schema giữa các file hơi khác nhau
    • Parsing CSV là vấn đề khó hơn nhiều so với tưởng tượng
  • Nếu hai kỹ sư phải đọc dữ liệu CSV và tính cùng một kết quả, bên ingest CSV dễ dàng và đúng hơn có thể lấy được câu trả lời trước, bất kể tốc độ query engine
  • Cách xử lý kết quả cũng ảnh hưởng lớn đến trải nghiệm người dùng
    • Nếu SELECT * trả về page đầu tiên và cursor như MySQL, kết quả có thể hiện ra ngay
    • Nếu phải tạo một bản sao bảng ở phía server như BigQuery, với bảng lớn có thể mất vài giờ
    • Nếu client cố tải toàn bộ dữ liệu xuống, có thể hết bộ nhớ
    • Kết nối dài dễ bị ảnh hưởng bởi sự cố mạng, còn polling có thể làm truy vấn trông chậm hơn khi nó kết thúc giữa hai lần polling

Manh mối khi xem benchmark DuckDB

  • DuckDB nhanh, và nằm trong nhóm đầu ở ClickBench với một số machine size
    • Ví dụ có nêu kết quả c6a.4xlarge
  • DuckDB cũng có hiệu năng tốt trong hầu hết benchmark h2o.ai, và cũng không tệ ở TPC-H và TPC-DS
  • Trước khi giả định cơ sở dữ liệu nào đó nhanh, bạn nên tự kiểm thử trên workload của mình

Giải quyết vấn đề nhanh hơn, không chỉ truy vấn nhanh hơn

  • Các công ty cơ sở dữ liệu thành công nhất không thành công chỉ vì họ nhanh hơn đối thủ
  • Redshift từng mạnh trong một thời gian, nhưng lý do Snowflake có thể gia nhập thị trường không phải là hiệu năng benchmark mà là khả năng bảo trì
  • 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 đạt kết quả tốt trên thị trường, còn những cơ sở dữ liệu giúp hoàn thành công việc dễ dàng hơn thì trụ vững hơn
  • Khi chọn cơ sở dữ liệu, cần nhìn theo các trục rộng hơn
    • Không có kỹ thuật bí mật kỳ diệu nào; trừ khác biệt kiến trúc, hiệu năng sẽ hội tụ theo thời gian
    • Tốc độ cải thiện của engine cơ sở dữ liệu rất khác nhau, và bên di chuyển nhanh hơn có lợi thế dài hạn
    • Vendor cơ sở dữ liệu ám ảnh nhất với hiệu năng có thể trở nên chậm hơn về dài hạn
    • Hiệu năng cơ sở dữ liệu không có một chỉ số duy nhất, và cơ sở dữ liệu nhanh vẫn có thể tệ với workload cụ thể
    • Tính năng quan trọng không phải là đi từ truy vấn đến kết quả, mà là đi từ ý tưởng đến câu trả lời nhanh đến đâu
  • Truy vấn nhanh tốt hơn truy vấn chậm, nhưng lựa chọn cơ sở dữ liệu nên dựa trên các yếu tố ngoài tốc độ thô

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-03-12
Ý kiến trên Hacker News

  • Thật bực mình ở đoạn nói rằng dù trong nhiều năm có rất nhiều phàn nàn từ khách hàng, họ vẫn “hoàn toàn không biết” vấn đề ở JDBC driver đang phá hỏng hiệu năng
    Nghĩa là trong nội bộ Google họ không dùng sản phẩm của mình như khách hàng thật sự, thời gian truy vấn mà người dùng nhìn thấy lại không hiển thị trong nội bộ, nên họ coi đó là vấn đề của người khác

    • Bài học rút ra ở đây cũng có vẻ hơi lệch. Không phải “chỉ hiệu năng thôi là chưa đủ”, mà là hiệu năng trên luồng khách hàng thực sự sử dụng quan trọng hơn benchmark của từng thành phần riêng lẻ
      Vấn đề không phải là họ đã bỏ quá nhiều công sức vào tối ưu hóa, mà là họ không bắt đầu từ nỗi đau của khách hàng rồi lần theo đến nguyên nhân gốc. Nguyên nhân thực tế rốt cuộc cũng vẫn là vấn đề hiệu năng

  • Câu chuyện JDBC thật sự rất hay. Google đã tạo ra một cơ sở dữ liệu chạy tốt trong nội bộ, rồi thuê ngoài làm lớp adapter cho thế giới bên ngoài, nhưng lớp đó không hoạt động đúng, khiến người dùng bên ngoài phải dùng một cơ sở dữ liệu tệ hại
    Như thể họ bọc một lớp giấy gói hỏng lên trên phần lõi tinh vi mà Google dùng, làm cả sản phẩm trở nên rối tung một cách không cần thiết; trong nội bộ không ai nhận ra, còn người dùng bên ngoài cũng khó xác định nguyên nhân. Trông như một ví dụ thể hiện rất chính xác chiến lược mã nguồn mở của Google

    • Nhìn từ góc độ quản lý thì cũng có thể hiểu được. Kiểu như “chúng ta đã tuyển những nhân tài khoa học máy tính giỏi nhất, hãy để họ giải các vấn đề khoa học máy tính cốt lõi, còn JDBC driver không phải năng lực cốt lõi nên thuê ngoài đi”
      Vấn đề là nếu bạn làm hỏng đủ nhiều ở các mảng không cốt lõi, thì năng lực cốt lõi có giỏi đến đâu cũng trở nên vô ích. Thuê ngoài không phải là bữa trưa miễn phí
    • Các Python wrapper cho Google API đều là những câu chuyện kiểu này
    • Đây là do thiếu tích hợp dọc. Lý do Apple thắng ở nhiều mặt là vì họ làm tích hợp dọc rất tốt
    • Các hợp đồng doanh nghiệp kiểu Workspace cũng đúng cấu trúc này. Trên một sản phẩm lõi tuyệt vời lại bị phủ lên bằng những hợp đồng “hỗ trợ” không chỉ vô dụng mà còn có hại, nơi các công ty tư vấn thuộc loại tệ nhất thế giới lấy khoảng 15%

  • Bài viết nói rằng “hiệu năng mang tính chủ quan” và chỉ đo lường đơn giản là chưa đủ, nhưng các ví dụ đưa ra lại là những trường hợp hiệu năng thực sự quan trọng và khách quan. Chỉ là họ đã đo sai đối tượng mà thôi

    • Ngay từ đoạn đầu đã bắt đầu bằng một ví dụ rất khớp với định luật Amdahl, nhưng thật ngạc nhiên là bài không nhắc đến lần nào

  • Nghe như đây là vấn đề tổ chức của công ty. Nếu mục tiêu cuối cùng là khiến mọi người dùng cloud và tạo ra giá trị, thì không hiểu vì sao họ lại có các chỉ số lệch khỏi những gì khách hàng coi trọng
    Bên trong Google cần có người trực tiếp nói chuyện với khách hàng, nắm được vấn đề là gì, rồi truyền đạt cho kỹ sư để họ biết phải cải thiện điều gì. Tổ chức phải được thiết kế sao cho kỹ sư nhận được các chỉ số họ cần, hoặc bản thân việc tạo ra các chỉ số đó phải nằm trong trách nhiệm công việc

    • “Khi giai thoại và chỉ số mâu thuẫn nhau, thường thì giai thoại mới đúng” — Jeff Bezos. Đáng tiếc là thỉnh thoảng ông ấy cũng nói được vài câu hay
    • Google trông có vẻ hơi dị ứng với việc nói chuyện trực tiếp với khách hàng
    • https://en.wikipedia.org/wiki/Seeing_Like_a_State
    • Nếu giải pháp của chúng ta không giải quyết được vấn đề của khách hàng, thì khách hàng cần có vấn đề khác, hoặc chúng ta cần có khách hàng khác
    • Hoàn toàn đồng ý. Có vẻ đây là vấn đề chọn sai chỉ số để làm mục tiêu. Nhưng không chỉ dừng ở mức đội kỹ thuật đo một phần quá hẹp của độ trễ
      Tôi còn tò mò hơn là đội ngũ sản phẩm và lãnh đạo tổ chức đang nhìn vào những chỉ số nào mà lại bỏ lỡ phản hồi khách hàng như vậy

  • Đọc đoạn “từ nhà ở Seattle đến văn phòng San Francisco, door-to-door mất 4,5 giờ”, có vẻ các founder ngày nay không còn di chuyển với tốc độ 179 dặm/giờ nữa. Có lẽ khi Fed tăng lãi suất thì mọi chuyện thành ra như vậy

    • Lúc đầu đọc tôi tưởng là lái xe, nhưng có lẽ đó là thời gian gồm máy bay + di chuyển ra/vào sân bay + kiểm tra an ninh
    • Hiện tôi đang thật sự đi từ nhà ở Seattle đến văn phòng SF. Tôi xuất phát 48 phút trước, nên khi tới nơi tôi sẽ cập nhật để tự thêm một điểm dữ liệu vào đây

  • Rõ ràng có nhiều điểm hay, nhưng kết luận thì cảm giác hơi lệch. Hiệu năng ở đây không hẳn là thứ phụ như bài nói, mà gần với chuyện đã đủ hay chưa hơn
    Phải vượt qua ngưỡng đủ nhanh trước đã, rồi mới có thể đánh giá các yếu tố khác. Trước đó thì bạn còn chưa được ngồi vào bàn cạnh tranh. Tác giả cũng nói “DuckDB nhanh”; nếu nó không nhanh, thì ít nhất nó vẫn phải cạnh tranh bằng hiệu năng cho đến khi đánh dấu được ô đó
    Ngoài ra, câu “database engine di chuyển nhanh nhất cuối cùng sẽ thắng” có thể đúng ở mức nào đó, nhưng không thực tế. Khi là người chơi mới thì tiến triển nhanh, nhưng khi đã đến vị thế như Snowflake thì tốc độ tất yếu sẽ chậm lại. Với tư cách người chọn hệ thống hôm nay, không thể ngoại suy nguyên xi gia tốc hiện tại ra tương lai
    Dù vậy, góc nhìn “không phải từ truy vấn đến kết quả, mà là từ ý tưởng đến câu trả lời nhanh đến mức nào” có vẻ đáng để đào sâu riêng

  • Hiệu năng không hẳn là “chủ quan” mà là tương đối. Ý nghĩa của nó gắn với công việc trước mắt
    Tuy nhiên, nếu đang nói về giao diện người dùng khiến người dùng cảm thấy nhanh hơn, như một thanh tiến trình chuyển động nhanh, thì đó là chuyện khác. Đó là vấn đề giao diện, không phải vấn đề cơ sở dữ liệu

    • “Chủ quan” mới là cách diễn đạt đúng. Việc tác vụ nào có liên quan phụ thuộc vào chủ thể
      Nếu nói là “tương đối”, thì lẽ ra ngoài việc so sánh giữa các hệ thống sẽ không có cách nào gán con số cho hiệu năng, nhưng điều đó không đúng

  • Web app đầu tiên trở nên phổ biến đã giữ toàn bộ trạng thái trong Python dict và cứ vài phút lại dump ra đĩa. Đó là API nhanh nhất tôi từng thấy trong đời
    Sau khi chuyển sang Mongo, hiệu năng không bao giờ hồi phục. Dù vậy, khi làm website bây giờ tôi cũng không lôi “pickledb” ra dùng

    • Với vai trò thay thế cho fopen, SQLite là điểm trung gian
    • Tôi nghĩ nhiều người hơn nên cân nhắc kiến trúc thường trú trong bộ nhớ + snapshot ngay từ đầu, thay vì cấu trúc cơ sở dữ liệu giao dịch
      Nó kém phù hợp hơn với tương tác người dùng kiểu request/response, nhưng với dữ liệu tĩnh lớn hoặc dữ liệu streaming có thể phát lại được, được xử lý tăng dần hoặc theo lô, thì tôi nghĩ nó nên phổ biến hơn hiện nay

  • Tôi đang tìm tài liệu hay về chủ đề “database shared nothing bất lợi so với shared disk, Redshift đã mất nhiều năm để chuyển chủ yếu sang kiến trúc shared disk. Lakehouse lưu metadata trong object storage nên khó cập nhật nhanh”

  • Bài viết hay. Tôi nghĩ đây cũng là một trong những lý do pandas mạnh trong 10 năm qua
    Hiệu năng trên một máy đơn đã đủ tốt, và nó có thể đọc được 99% CSV mà nhân loại biết đến