9 คะแนน โดย GN⁺ 2024-07-11 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ช่วงปลายปี 2022 ระหว่างขยายโครงสร้างพื้นฐานของ Readwise มีแผนจะเพิ่มฟีเจอร์แนะนำบทความและการค้นหาเชิงความหมายโดยใช้เวกเตอร์เอ็มเบดดิง
  • เดิมค่าใช้จ่ายของฐานข้อมูลเชิงสัมพันธ์อยู่ที่ $5k ต่อเดือน แต่ค่าใช้จ่ายสำหรับการค้นหาเวกเตอร์สูงกว่า $20k ต่อเดือน จึงต้องล้มเลิกการพัฒนาฟีเจอร์เพราะต้นทุนสูง
  • เสิร์ชเอนจินแบบเดิมมีราคาแพงและดูแลยาก: ด้วยความก้าวหน้าของอ็อบเจ็กต์สตอเรจ, NVMe SSD, AI และเทคโนโลยีเวกเตอร์ จึงจำเป็นต้องมีเสิร์ชเอนจินรูปแบบใหม่
  • ฐานข้อมูลเวกเตอร์แบบเดิมใช้สตอเรจในหน่วยความจำ ทำให้มีต้นทุนสูง
    • สามารถลดต้นทุนได้อย่างมากด้วยการใช้อ็อบเจ็กต์สตอเรจ (S3, GCS) และ SSD caching
    • ตัวอย่าง: สตอเรจในหน่วยความจำมีค่าใช้จ่าย $2+/GB ขณะที่อ็อบเจ็กต์สตอเรจอยู่ที่ $0.02/GB

การออกแบบของ turbopuffer

  • พัฒนาเสิร์ชเอนจินที่เหมาะกับยุคปัจจุบัน
  • ใช้อ็อบเจ็กต์สตอเรจและสมาร์ตแคชชิงเพื่อให้ได้ทั้งความคุ้มค่าและประสิทธิภาพ
  • รองรับเวกเตอร์ระดับหลายหมื่นล้านรายการและเทนเนนต์หลายล้านรายได้
  • เสิร์ชเอนจินที่มีอ็อบเจ็กต์สตอเรจเป็นฐาน
    • เสิร์ชเอนจินแบบเดิมใช้อาร์กิเทกเจอร์ replicated disk ของฐานข้อมูลเชิงสัมพันธ์
    • เสิร์ชเอนจินต้องการ write throughput สูงและยอมรับ write latency ที่ผ่อนปรนได้
    • ใช้อ็อบเจ็กต์สตอเรจและ SSD/หน่วยความจำแคชชิงเพื่อลดต้นทุนโดยยังคงประสิทธิภาพไว้
  • การสร้างฐานข้อมูลแบบ Native สำหรับอ็อบเจ็กต์สตอเรจ
    • สร้างฐานข้อมูลที่มีอ็อบเจ็กต์สตอเรจเป็นพื้นฐาน
    • ให้ความน่าเชื่อถือสูงและการขยายตัวได้ไม่จำกัด
    • รักษาความพร้อมใช้งานสูงด้วย multi-tenancy และ sharding
  • กรณีศึกษาลูกค้า
    • Cursor: AI code editor จัดการเวกเตอร์ระดับหลายหมื่นล้านรายการ พร้อมลดต้นทุนลง 10 เท่า
    • Suno: ฟีเจอร์วิทยุ
    • Dot: ฟีเจอร์หน่วยความจำ
    • Shapes: ฟีเจอร์หน่วยความจำ

สรุปโดย GN⁺

  • turbopuffer ใช้อ็อบเจ็กต์สตอเรจและสมาร์ตแคชชิงเพื่อปรับปรุงทั้งความคุ้มค่าและประสิทธิภาพของเสิร์ชเอนจินอย่างมาก
  • มีเป้าหมายเพื่อแก้ปัญหาต้นทุนสูงและความยากในการดูแลของเสิร์ชเอนจินแบบเดิม
  • ออกแบบเสิร์ชเอนจินใหม่ให้สอดรับกับความก้าวหน้าของ AI และเทคโนโลยีเวกเตอร์
  • พิสูจน์การลดต้นทุนและการเพิ่มประสิทธิภาพผ่านกรณีศึกษาลูกค้ากลุ่มแรก เช่น Cursor
  • โปรเจกต์อื่นที่มีความสามารถคล้ายกัน ได้แก่ ElasticSearch และ Vector DBs

1 ความคิดเห็น

 
GN⁺ 2024-07-11
ความคิดเห็นบน Hacker News
  • เคยร่วมงานกับ Simon มาก่อน และเขาเชี่ยวชาญในสายงานของตัวเองมาก

    • เคยทำงานด้านการค้นหาร่วมกันที่ Shopify และได้คุยกันเยอะเกี่ยวกับ search stack ในอุดมคติ
    • ต้องการระบบในอุดมคติที่สามารถแสดง ranking ผ่าน search API บนคลาวด์ และใช้คณิตศาสตร์แบบ dataframe เพื่อ boost ตามคุณสมบัติต่าง ๆ
  • หวังว่า Turbopuffer จะทำงานได้เหมือน Polars dataframe เพื่อให้สามารถแสดง ranking ใน search API ได้

    • ต้องการความสามารถในการทำ first pass ด้วยคณิตศาสตร์แบบ dataframe และรันโมเดล reranking
  • ชอบดีไซน์เว็บไซต์ของ Fixie.ai มากเช่นกัน

    • Fixie.ai เป็นหนึ่งในลูกค้าของ Turbopuffer
  • ค่าใช้จ่าย RAM บน Hetzner อยู่ที่ $200/TB/เดือน ซึ่งถูกกว่าที่อื่น 18 เท่า

    • ถ้าลดความซับซ้อนได้ ก็จะไปถึงเป้าหมายได้เร็วขึ้น
  • pg_vector มีอยู่มาตั้งแต่ก่อนปี 2022 และไม่จำเป็นต้องใช้ in-memory storage

    • สามารถทำ vector search กับเอกสารมากกว่า 100 ล้านชิ้นได้
  • สงสัยว่าสามารถสร้างแนวทางที่ใช้ Lucene โดยวางโหนด SSD cache ไว้หน้า object storage ได้หรือไม่

    • เคยเห็นการ deploy Elasticsearch ขนาดใหญ่มาแล้ว และถ้าสามารถใส่ทุกอย่างไว้ใน S3 ได้ก็น่าทึ่งมาก
  • ฟังดูเหมือน Quickwit เวอร์ชันที่ไม่เปิดซอร์ส

  • สงสัยว่ามีโซลูชันทั่วไปสำหรับเก็บฐานข้อมูลขนาดใหญ่แบบอ่านอย่างเดียวไว้ใน S3 และ query ได้โดยตรงหรือไม่

    • Duckdb สามารถเปิดไฟล์ parquet ผ่าน http และ query ได้ แต่จะกระตุ้น request เล็ก ๆ จำนวนมาก
    • ต้องการไฟล์เดียวและดัชนีที่ cache ได้ เพื่อจัดการอ็อบเจ็กต์นับล้านรายการ
  • เวลาแฝงในการอ่านของ ClickHouse ต่ำกว่า 100ms และเวลาแฝงในการเขียนต่ำกว่า 1 วินาที

    • ClickHouse เหมาะกับงาน logging, real-time analytics และ RAG ด้วย
  • ไม่ค่อยรู้เรื่อง vector database มากนัก แต่คิดว่าส่วนใหญ่ถูกใช้กับงาน RAG และงานที่เกี่ยวกับ AI อื่น ๆ

    • น่าจะต้องลงลึกศึกษาเพิ่มเติม
  • คิดว่าแนวทางแบบ object storage-first เข้ากับคลาวด์ได้อย่างเป็นธรรมชาติ