Show HN: ScratchDB - Snowflake mã nguồn mở trên ClickHouse

 (github.com/scratchdata)
4 điểm bởi GN⁺ 2023-10-29 | 1 bình luận | Chia sẻ qua WhatsApp
  • Scratch Data là một wrapper cho cơ sở dữ liệu phân tích, cho phép stream dữ liệu vào·ra và thực hiện truy vấn phân tích trên đầu vào JSON tùy ý
  • Khi chạy không cần cấu hình, hệ thống sẽ tự động chuẩn bị một cơ sở dữ liệu DuckDB cục bộ có thể đọc và ghi
  • Khi đưa dữ liệu JSON vào POST /api/data/insert/events?api_key=local, hệ thống sẽ tự động tạo bảng events và các cột
  • Luồng sử dụng HTTP API là truyền truy vấn SQL vào GET /api/data/query để xem dữ liệu đã được chèn
  • Cung cấp tính năng chia sẻ hoặc sao chép kết quả truy vấn
    • API share tạo ID truy vấn và sẽ hết hạn sau duration tính bằng giây đã chỉ định, cho phép chia sẻ dữ liệu qua liên kết CSV hoặc JSON
    • Sau khi cấu hình nhiều cơ sở dữ liệu, có thể chạy truy vấn SQL trên cơ sở dữ liệu nguồn, đồng thời tự động xử lý việc tạo bảng đích và chèn dữ liệu

Bài viết liên quan

1 bình luận

 
GN⁺ 2023-10-29
Ý kiến trên Hacker News

  • Sẽ rất hay nếu giải thích open-source Snowflake nghĩa là gì. Mình không thấy phần diễn giải nào trong mô tả, repository hay trang web
    Mình tò mò liệu mục tiêu có phải là tái hiện rõ ràng toàn bộ tính năng của Snowflake không: https://docs.snowflake.com/en/user-guide/intro-supported-fea...

    • Đây là phản hồi hữu ích để viết thông điệp rõ ràng hơn, mình xin tiếp thu
      Mục tiêu của dự án này là tạo ra trải nghiệm lập trình viên tuyệt vời trên một cơ sở dữ liệu phân tích. Mình xem đó là một trong nhiều đề xuất giá trị của Snowflake. Ngoài ra, mục tiêu cũng là cho phép người dùng hoàn toàn kiểm soát dữ liệu và cách xử lý của mình, đồng thời sử dụng tài nguyên tính toán một cách tiết kiệm
      Mục tiêu không phải là khớp tính năng với sản phẩm khác, nhưng khi phát triển, chúng mình sẽ xây dựng các tính năng quan trọng với doanh nghiệp

  • Mình làm việc ở ClickHouse
    Mình nghĩ cơ sở dữ liệu OLAP thời gian thực có tiềm năng hỗ trợ tốt hơn một số công việc hiện đang được xử lý bằng Postgres hoặc cloud data warehouse, trong các trường hợp cần nạp dữ liệu và truy vấn phân tích theo thời gian thực. Nếu đơn giản hóa trải nghiệm lập trình viên để họ không phải học mọi chi tiết của một cơ sở dữ liệu mạnh, tốc độ phát triển cũng sẽ tăng đáng kể
    Mình tò mò dự án này khác GraphJSON(https://www.graphjson.com/) và Tinybird(https://www.tinybird.co/) như thế nào

    • Mình mới thấy GraphJSON lần đầu và sẽ xem thử. Mình cũng thích Tinybird, và nghĩ mục tiêu giúp mọi người áp dụng OLAP dễ dàng hơn là tương tự
      Về mặt kỹ thuật, chúng mình đã đưa ra các quyết định thiết kế khác trong việc nạp và xử lý dữ liệu. Ví dụ, ngay cả sau khi tạo bảng, bạn vẫn có thể gửi JSON mới với các cột khác, và dữ liệu sẽ được nạp mà không cần migration thủ công. Với mảng JSON, chúng mình cũng xử lý khác bằng cách cho phép tách thành nhiều hàng ClickHouse thay vì dùng mảng của ClickHouse
      Về triết lý, mình cho rằng còn rất nhiều chỗ cho phần mềm nguồn mở có UI và trải nghiệm lập trình viên xuất sắc. Mình đã viết phần mềm nguồn mở trong thời gian dài và tin rằng đó là cách tốt nhất để tạo ra công cụ lập trình viên thành công
    • Không phải tác giả bài gốc, nhưng cả GraphJSON lẫn Tinybird đều có vẻ không phải là nguồn mở

  • Sản phẩm hay, cảm ơn vì đã chia sẻ
    Mình từng hiểu là ClickHouse đã hỗ trợ native việc làm phẳng JSON[1]. Dù đây là tính năng mới xuất hiện gần đây ở phiên bản 22.3.1, mình tò mò không biết các bạn đã bắt đầu làm trước đó[2], hay đây là một cách tiếp cận khác. Mình cũng muốn biết ưu và nhược điểm của từng bên
    [1] https://clickhouse.com/docs/en/integrations/data-formats/jso...
    [2] https://scratchdb.com/blog/flatten-json/

    • Câu hỏi khá hay. Câu trả lời hơi mỉa mai một chút là “cách chúng mình nạp JSON không cần 50 trang tài liệu và n giá trị cấu hình để giải thích”
      Nói thực tế hơn, với JSON lồng nhau, chúng mình không dùng tuple mà biểu diễn quan hệ parent_child trong key bằng dấu gạch dưới. Chúng mình cũng không dùng mảng, mà khiến việc tách thành nhiều hàng trở nên dễ dàng để có thể dùng SQL thông thường
      Mình chưa so sánh trực tiếp với nhiều cách xử lý JSON khác nhau của ClickHouse, nhưng mục tiêu là tạo ra thứ mà khi chạy thì cứ hoạt động đúng như mong đợi
    • Suy luận schema cho đối tượng JSON lồng nhau là tính năng của ClickHouse 23.9. Mình đã làm một video liên quan: https://www.youtube.com/watch?v=yS8YU-rBpMM&t=1846s

  • Với những ai tò mò, giấy phép là AGPL-3.0

  • Chúc mừng ra mắt. Mình tò mò liệu có thể dùng cái này cho dữ liệu log không, và dữ liệu đã nạp sẽ được lưu trong bao lâu

    • Có thể dùng cho log. Ví dụ cơ bản ở đây: https://scratchdb.com/blog/fly-logs-to-clickhouse/
      Vì chỉ là lưu vào cơ sở dữ liệu nên bạn có thể giữ bao lâu tùy muốn. Bản hosted tính phí theo mỗi GB dữ liệu nén, nên dù có nhiều log vẫn có thể lưu trữ, và nếu muốn tiết kiệm dung lượng đĩa thì có thể xóa dữ liệu cũ

  • Cảm ơn vì đã chia sẻ, trông rất gọn gàng và dễ dùng
    Mình tò mò liệu có kế hoạch hỗ trợ định dạng dữ liệu không phải JSON khi insert không. Ví dụ như file CSV, file Parquet, hay message Avro hoặc Protobuf

  • Nên gửi benchmark lên ClickBench

  • Mình tò mò về ý nghĩa giấy phép nếu dùng cái này để cung cấp một dịch vụ công khai mà không sửa mã nguồn được cung cấp
    Ví dụ trường hợp dùng nó cho một diễn đàn, nhưng dùng một đoạn mã riêng để đưa dữ liệu vào và lấy dữ liệu ra khỏi ScratchDB

  • Mình tò mò vì sao storage lại đắt hơn BigQuery 10 lần. Cũng muốn biết giá compute so với BigQuery như thế nào
    Sửa: Bigtable → BigQuery

    • Chúng mình không tính riêng compute và storage như Bigtable. Compute đã được bao gồm trong giá theo mỗi GB dữ liệu. Mục tiêu là mô hình giá chỉ trả cho phần bạn dùng, tương tự DynamoDB. Một cách tính phí khác dựa trên thời gian thực tế trôi qua của truy vấn, nên truy vấn 30 giây sẽ đắt hơn truy vấn 500ms
      Mình chưa dùng Bigtable, nhưng có vẻ mức phí tối thiểu khoảng 300 đô la ngay cả khi không có dữ liệu. ScratchDB tối thiểu 10 đô la cho 30GB
      Ngoài ra, trung bình tỷ lệ nén dữ liệu là 25%. Nếu 1TB dữ liệu chỉ chiếm 250GB thì bạn chỉ trả tiền cho phần đó
      Bigtable không phải OLAP nên sẽ không dùng cho cùng loại dữ liệu. Cái này cạnh tranh trực tiếp hơn với BigQuery của GCP
      Chúng mình rất quan tâm đến phản hồi về giá. Vì cần duy trì phát triển, chúng mình muốn tìm hướng hợp lý

  • Chúc mừng ra mắt, trông có vẻ tốt. Việc suy luận schema tức thì rất tuyệt để bắt đầu nhanh, nhưng mình tò mò liệu có cách định nghĩa schema tường minh nếu muốn không
    Ví dụ mình đang nghĩ đến cấu hình nén theo từng cột

    • Hiện chưa có, nhưng chúng mình cởi mở với ý tưởng cho phép cấu hình
      Việc cấu hình ngay tại chỗ, hoặc tốt hơn là tính năng gợi ý cho người dùng nên dùng phương thức nén nào dựa trên dữ liệu thực tế, có thể sẽ hữu ích. Mình cũng sẵn lòng thảo luận trên GitHub issue