Show HN: ScratchDB - Snowflake แบบโอเพนซอร์สบน ClickHouse

• Scratch Data เป็นแรปเปอร์สำหรับฐานข้อมูลเชิงวิเคราะห์ ที่ช่วยให้สตรีมข้อมูลเข้า·ออก และรันคำสั่งวิเคราะห์กับอินพุต JSON แบบใดก็ได้
• เมื่่อรันโดยไม่ต้องตั้งค่า ระบบจะเตรียมฐานข้อมูล DuckDB แบบโลคัลที่อ่านและเขียนได้ให้โดยอัตโนมัติ
• เมื่อส่งข้อมูล JSON ไปที่ POST /api/data/insert/events?api_key=local ระบบจะสร้างตาราง events และคอลัมน์ต่าง ๆ ให้อัตโนมัติ
• ใช้งานผ่าน HTTP API โดยส่งคำสั่ง SQL ไปที่ GET /api/data/query เพื่อดึงข้อมูลที่ถูกแทรกไว้
• มีฟังก์ชันสำหรับแชร์หรือคัดลอกผลลัพธ์ของคิวรี
  • API share จะสร้าง ID ของคิวรีและหมดอายุหลังจาก duration ที่กำหนดเป็นวินาที พร้อมแชร์ข้อมูลผ่านลิงก์ CSV หรือ JSON ได้
  • หลังตั้งค่าหลายฐานข้อมูลแล้ว สามารถรันคำสั่ง SQL บนฐานข้อมูลต้นทาง และให้ระบบจัดการการสร้างตารางปลายทางพร้อมแทรกข้อมูลให้อัตโนมัติ

[GN⁺]

ความคิดเห็นจาก Hacker News

• น่าจะดีถ้ามีคำอธิบายว่าคำว่า open-source Snowflake หมายถึงอะไร เพราะดูเหมือนไม่มีการขยายความไว้ทั้งในคำอธิบาย รีโพซิทอรี หรือเว็บไซต์
  เลยสงสัยว่าเป้าหมายคือการทำซ้ำฟีเจอร์ทั้งหมดของ Snowflake แบบชัดเจนหรือไม่: https://docs.snowflake.com/en/user-guide/intro-supported-fea...

  • เป็นฟีดแบ็กที่ดีสำหรับการสื่อสารให้ชัดขึ้น และขอบคุณมาก
    เป้าหมายของโปรเจกต์นี้คือการสร้างประสบการณ์นักพัฒนาที่ยอดเยี่ยมบน ฐานข้อมูลเชิงวิเคราะห์ ซึ่งเรามองว่านี่คือหนึ่งในคุณค่าหลักที่ Snowflake มอบให้ นอกจากนี้ยังตั้งใจให้ผู้ใช้ควบคุมข้อมูลและวิธีประมวลผลได้อย่างเต็มที่ และใช้ทรัพยากรคอมพิวต์ได้อย่างคุ้มค่า
    เป้าหมายไม่ใช่การไล่ตามฟีเจอร์ของผลิตภัณฑ์อื่น แต่เมื่อเติบโตขึ้นก็จะสร้างฟีเจอร์ที่สำคัญต่อองค์กร

• ผมทำงานอยู่ที่ ClickHouse
  มองว่า ฐานข้อมูล OLAP แบบเรียลไทม์ มีศักยภาพที่จะรองรับงานบางประเภทได้ดีกว่า Postgres หรือคลังข้อมูลบนคลาวด์ในปัจจุบัน โดยเฉพาะกรณีที่ต้องการทั้งการนำเข้าข้อมูลแบบเรียลไทม์และคิวรีเชิงวิเคราะห์ การทำให้ประสบการณ์นักพัฒนาง่ายขึ้นโดยไม่ต้องเรียนรู้รายละเอียดทั้งหมดของฐานข้อมูลที่ทรงพลัง ก็ช่วยเร่งความเร็วในการพัฒนาได้มาก
  อยากรู้ว่าโปรเจกต์นี้ต่างจาก GraphJSON(https://www.graphjson.com/) และ Tinybird(https://www.tinybird.co/) อย่างไร

  • เพิ่งรู้จัก GraphJSON เดี๋ยวจะไปดู ส่วน Tinybird ก็ชอบเหมือนกัน และคิดว่าเรามีเป้าหมายคล้ายกันคือทำให้คน เริ่มใช้ OLAP ได้ง่ายขึ้น
    ในทางเทคนิค เราตัดสินใจออกแบบต่างกันในส่วนของการนำเข้าข้อมูลและการประมวลผล ตัวอย่างเช่น หลังสร้างตารางแล้วก็ยังสามารถส่ง JSON ใหม่ที่มีคอลัมน์ต่างออกไปได้ และนำเข้าได้โดยไม่ต้องทำ migration เอง อีกอย่างคือเราจัดการกับอาร์เรย์ JSON ต่างออกไป โดยสามารถแยกเป็นหลายแถวของ ClickHouse แทนการใช้อาร์เรย์ของ ClickHouse
    ในเชิงแนวคิด เรามองว่ายังมีพื้นที่มากสำหรับ ซอฟต์แวร์โอเพนซอร์ส ที่มี UI และประสบการณ์นักพัฒนาที่ยอดเยี่ยม ผมเขียนโอเพนซอร์สมานาน และคิดว่านี่คือวิธีที่ดีที่สุดในการสร้างเครื่องมือสำหรับนักพัฒนาที่ประสบความสำเร็จ
  • ผมไม่ใช่ผู้เขียนโพสต์ต้นฉบับ แต่ทั้ง GraphJSON และ Tinybird ดูเหมือนจะไม่ใช่ โอเพนซอร์ส

• เป็นผลิตภัณฑ์ที่ดี และดีใจที่เอามาแชร์
  ผมเข้าใจว่า ClickHouse รองรับการ flatten JSON แบบเนทีฟอยู่แล้ว[1] ฟีเจอร์นี้ออกมาในเวอร์ชัน 22.3.1 ไม่นานมานี้ เลยสงสัยว่าคุณเริ่มทำก่อนหน้านั้นหรือไม่[2] หรือเป็นคนละแนวทางกัน อยากรู้ข้อดีข้อเสียของแต่ละแบบด้วย
  [1] https://clickhouse.com/docs/en/integrations/data-formats/jso...
  [2] https://scratchdb.com/blog/flatten-json/

  • เป็นคำถามที่ดีมาก คำตอบแบบกวน ๆ หน่อยคือ “วิธีที่เรานำเข้า JSON ไม่ต้องใช้เอกสาร 50 หน้าและค่าตั้งค่า n ตัวเพื่ออธิบาย”
    ถ้าตอบแบบตรงไปตรงมามากขึ้นคือ เราไม่ใช้ tuple กับ JSON ที่ซ้อนกัน แต่ใช้ขีดล่างในคีย์เพื่อบอกความสัมพันธ์แบบ parent_child และก็ไม่ใช้อาร์เรย์ แต่ทำให้แยกเป็นหลายแถวได้ง่าย เพื่อให้ใช้ SQL ปกติได้
    ผมยังไม่ได้เปรียบเทียบโดยตรงกับวิธีจัดการ JSON แบบต่าง ๆ ของ ClickHouse แต่เป้าหมายคือทำให้มัน ทำงานได้ตรงตามที่คาดไว้เลย เมื่อรัน
  • การทำ schema inference สำหรับอ็อบเจ็กต์ JSON แบบซ้อนกันเป็นฟีเจอร์ของ ClickHouse 23.9 ผมทำวิดีโอเกี่ยวกับเรื่องนี้ไว้: https://www.youtube.com/watch?v=yS8YU-rBpMM&t=1846s

• เผื่อใครสงสัย ไลเซนส์คือ AGPL-3.0

  • https://github.com/scratchdata/ScratchDB/blob/main/LICENSE

• ยินดีกับการเปิดตัว อยากรู้ว่านำไปใช้กับ ข้อมูลล็อก ได้ไหม และข้อมูลที่นำเข้าแล้วจะเก็บไว้นานแค่ไหน

  • ใช้กับล็อกได้ ตัวอย่างเริ่มต้นอยู่ที่นี่: https://scratchdb.com/blog/fly-logs-to-clickhouse/
    มันก็แค่เก็บไว้ในฐานข้อมูล ดังนั้นจะเก็บไว้นานแค่ไหนก็ได้ตามต้องการ เวอร์ชันโฮสต์คิดราคาตาม GB ของข้อมูลที่บีบอัดแล้ว ดังนั้นแม้มีล็อกจำนวนมากก็เก็บได้ และถ้าอยากประหยัดพื้นที่ดิสก์ก็ลบข้อมูลเก่าออกได้

• ขอบคุณที่แชร์ ดูสะอาดตาและใช้งานง่ายมาก
  อยากรู้ว่ามีแผนรองรับ รูปแบบข้อมูลที่ไม่ใช่ JSON ตอน insert หรือไม่ เช่นไฟล์ CSV, Parquet, หรือข้อความแบบ Avro หรือ Protobuf

  • มีแผนจะรองรับ มี issue ที่เกี่ยวข้องอยู่: https://github.com/scratchdata/ScratchDB/issues/19
    อยากรู้ว่าคุณอยากให้มันออกมาในรูปแบบไหน

• น่าจะลองส่งเบนช์มาร์กเข้า ClickBench

• อยากรู้ว่าในมุมของไลเซนส์ ถ้านำสิ่งนี้ไปใช้ให้บริการสาธารณะโดยไม่แก้โค้ดที่ให้มาเลย จะมีความหมายอย่างไร
  เช่น ใช้กับฟอรัม โดยมีโค้ดแยกต่างหากสำหรับใส่และดึงข้อมูลจาก ScratchDB

• อยากรู้ว่าทำไมสตอเรจถึง แพงกว่า BigQuery 10 เท่า และถ้าเทียบกับ BigQuery แล้ว ราคาคอมพิวต์เป็นอย่างไร
  แก้ไข: Bigtable → BigQuery

  • ไม่ได้คิดค่าคอมพิวต์กับสตอเรจแยกกันแบบ Bigtable ราคาต่อ GB ของข้อมูลนั้น รวมคอมพิวต์ ไว้แล้ว เป้าหมายคือโมเดลราคาแบบจ่ายตามการใช้งาน คล้าย DynamoDB อีกส่วนของการคิดราคาคืออิงตามเวลาที่คิวรีใช้จริง ดังนั้นคิวรี 30 วินาทีก็จะแพงกว่าคิวรี 500ms
    ผมยังไม่เคยใช้ Bigtable แต่ดูเหมือนว่าค่าใช้จ่ายขั้นต่ำจะอยู่ราว 300 ดอลลาร์แม้ไม่มีข้อมูล ส่วน ScratchDB ขั้นต่ำคือ 10 ดอลลาร์สำหรับ 30GB
    อีกอย่าง โดยเฉลี่ยแล้วข้อมูลถูกบีบอัดเหลือ 25% ถ้าข้อมูล 1TB ใช้พื้นที่จริงแค่ 250GB คุณก็จ่ายเท่านั้น
    Bigtable ไม่ใช่ OLAP ดังนั้นคงไม่ใช้กับข้อมูลชุดเดียวกัน อันนี้แข่งขันกับ BigQuery ของ GCP โดยตรงมากกว่า
    ผมสนใจฟีดแบ็กเรื่องราคา เพราะต้องทำให้พัฒนาต่อได้ จึงอยากหาจุดที่สมเหตุสมผล

• ยินดีกับการเปิดตัว ดูดีมาก การ อนุมานสคีมา แบบทันทีนั้นยอดเยี่ยมสำหรับการเริ่มต้นอย่างรวดเร็ว แต่ถ้าต้องการ จะมีวิธีให้กำหนดสคีมาแบบชัดเจนเองได้ไหม
  ตัวอย่างเช่น ผมกำลังคิดถึงการตั้งค่าการบีบอัดรายคอลัมน์

  • ตอนนี้ยังไม่มี แต่ก็เปิดรับไอเดียที่จะเพิ่มได้
    อาจเป็นการตั้งค่าได้ทันที หรือดีกว่านั้นคือมีฟีเจอร์ที่แนะนำผู้ใช้ว่าควรใช้ วิธีบีบอัด แบบใดโดยอิงจากข้อมูลจริง และก็ยินดีคุยกันต่อใน GitHub issue ด้วย