วิธีการย้ายจาก Elasticsearch และ MongoDB มาเป็น Rust และ RocksDB

 (radar.com)
4 คะแนน โดย GN⁺ 2025-08-10 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Radar ให้บริการ โครงสร้างพื้นฐานข้อมูลภูมิศาสตร์ ที่รับคำขอ API มากกว่า 1 พันล้านรายการต่อวัน และเพื่อแก้ปัญหาด้านประสิทธิภาพและการขยายตัวได้ดีขึ้น ได้ย้ายจาก Elasticsearch และ MongoDB เดิมมาใช้ HorizonDB ที่พัฒนาขึ้นเอง
  • HorizonDB พัฒนาด้วย Rust และเป็น ฐานข้อมูลภูมิศาสตร์ประสิทธิภาพสูง ที่รวมเครื่องมือโอเพนซอร์สหลายตัวเข้าด้วยกัน เช่น RocksDB, S2, Tantivy, FST, LightGBM, FastText
  • ในโครงสร้างเดิม ต้นทุนและความซับซ้อนในการขยาย Elasticsearch และ MongoDB สูงมาก ทำให้การดำเนินงานเป็นเรื่องยาก
  • HorizonDB ทำงานบน single-process แบบหลายเธรด จึงสามารถลดต้นทุน ปรับปรุงประสิทธิภาพ และเพิ่มความน่าเชื่อถือได้
  • โดยรวมแล้ว ผลผลิตการพัฒนา และประสิทธิภาพการดำเนินงานดีขึ้นอย่างมาก ทำให้สามารถนำข้อมูลหรือฟีเจอร์ใหม่มาใช้งานได้อย่างรวดเร็ว
  • ข้อมูลถูก preprocess ด้วย Apache Spark แล้วเก็บตามเวอร์ชันบน AWS S3 ทำให้ผู้พัฒนาสามารถรันและทดสอบได้ง่ายในเครื่องท้องถิ่น
  • ด้วยวิธีนี้ Radar ปิดการใช้งานคลัสเตอร์ Mongo และ Elasticsearch ช่วยลดต้นทุนได้มาก และปรับปรุงความเร็วในการพัฒนาฟีเจอร์พร้อมเพิ่มประสิทธิภาพการประมวลผลข้อมูล

แนะนำและภูมิหลัง

  • Radar เป็นแพลตฟอร์มโครงสร้างพื้นฐานข้อมูลตำแหน่งภูมิศาสตร์ (geolocation infrastructure platform) ที่รองรับคำขอ API กว่า 1 พันล้านรายการต่อวันทั่วโลก
    • API หลักได้แก่ Geocoding, Search, Routing, Geolocation compliance
  • เมื่อขนาดข้อมูลและผลิตภัณฑ์ขยายตัวขึ้น ประเด็น ประสิทธิภาพสูง, ความสามารถในการขยาย และต้นทุน กลายเป็นความต้องการที่เร่งด่วน
  • เพื่อแก้ปัญหานี้ Radar นำ HorizonDB ที่เขียนด้วย Rust มาใช้ เพื่อเสนอบริการด้านตำแหน่งหลายอย่างในไบนารีประสิทธิภาพสูงตัวเดียว
    • รองรับ 1,000 QPS ต่อคอร์
    • ค่า latency กลางของ forward geocoding อยู่ที่ 50ms และ reverse geocoding <1ms
    • ขยายขนาดเชิงเส้นได้บนฮาร์ดแวร์ทั่วไป

ข้อจำกัดของระบบเดิม

  • โครงสร้างเดิม: geocoding ด้านหน้าใช้ Elasticsearch, reverse geocoding ใช้ MongoDB
  • ปัญหา:
    • Elasticsearch กระจายคิวรีไปยังทุก shard และต้องอัปเดตแบบ batch เป็นระยะ
    • MongoDB ยากในการป้อนข้อมูลแบบ batch ขนาดใหญ่ ต้องจัดสรรทรัพยากรมากเกินไป และไม่รองรับ rollback ที่เสถียร

เป้าหมายสถาปัตยกรรมของ HorizonDB

  • ประสิทธิภาพ - ทำงานบนฮาร์ดแวร์ทั่วไป, auto-scaling ที่คาดเดาได้, ทำหน้าที่เป็นแหล่งข้อมูลเดียวของเอนทิตีภูมิศาสตร์ทั้งหมด
  • การใช้งาน/การดำเนินงาน - สร้างและประมวลผลสินทรัพย์ข้อมูลได้หลายครั้งต่อวัน, การเปลี่ยนแปลงและ rollback ทำได้ง่าย, ลดความซับซ้อนการดำเนินงาน
  • ประสบการณ์การพัฒนา - รันได้บนเครื่องท้องถิ่น, เปลี่ยนแปลงและทดสอบได้ง่าย

สแตกเทคโนโลยีที่ใช้

RocksDB, S2, Tantivy, FSTs, LightGBM, FastText และโอเพนซอร์สอื่นๆ หลายตัวถูกนำมาใช้ โดยข้อมูลถูกเตรียมล่วงหน้าด้วย Apache Spark แล้วถูกเก็บเป็นไฟล์ที่จัดการเวอร์ชันบน S3 ด้วย Rust

  • Rust

    • ภาษาการเขียนโปรแกรมระบบที่พัฒนาโดย Mozilla
    • รักษาความปลอดภัยด้านคอมไพล์และหน่วยความจำ พร้อมการจัดการหน่วยความจำของดัชนีขนาดใหญ่อย่างคาดเดาได้โดยไม่ต้องมี garbage collection
    • รองรับการจัดการค่า null และ pattern matching ระดับสูง ทำให้การนิยามตรรกะการจัดอันดับการค้นหาที่ซับซ้อนทำได้ง่าย
    • เหมาะสมสำหรับการประมวลผลข้อมูลหลายร้อย GB บน SSD ด้วย multi-threaded single process

  • RocksDB

    • ที่เก็บข้อมูลภายในโปรเซสแบบ in-process ที่อิงโครงสร้าง LSM-tree ซึ่งมีประสิทธิภาพสูง
    • มีการตอบสนองระดับไมโครวินาที และความเร็วคงที่แม้กับข้อมูลจำนวนมาก

  • S2

    • ไลบรารีการจัดทำดรรชนีเชิงพื้นที่ของ Google ที่แบ่งโลกเป็นควิลต์ย่อยเพื่อเพิ่มความเร็วของการค้นหา point-in-polygon
    • Radar พัฒนาการผูก (binding) ของ Rust สำหรับไลบรารี S2 ฉบับ C++ ของตนเอง และจะเปิดเผยเป็นโอเพนซอร์สในเร็ว ๆ นี้

  • FSTs (Finite State Transducers)

    • โครงสร้างข้อมูลสำหรับการบีบอัดสตริงและการค้นหาด้วยคำนำหน้าอย่างมีประสิทธิภาพ
    • สะท้อนว่าคิวรี 80% เป็นเส้นทางตามปกติแบบ “happy-path” จึงสามารถแคชเส้นทางได้หลายล้านเส้นทางด้วยหน่วยความจำเพียงไม่กี่ MB

  • Tantivy

    • ไลบรารี inverted index แบบ in-process ที่คล้าย Lucene
    • เหตุผลที่เลือกแทนบริการภายนอกอย่าง Elasticsearch:
      • คุณภาพการค้นหา - รองรับการประมวลผลการค้นหาขั้นสูง เช่น การขยายคีย์เวิร์ดแบบไดนามิก โดยไม่ต้องพึ่งการหน่วงความหน่วงจากการสื่อสารข้าม process
      • การใช้งานง่ายขึ้น - ประมวลผลในโปรเซสเดียว รองรับการขยายสเกลอย่างง่ายด้วย memory-mapping แม้กับดัชนีขนาดใหญ่

  • FastText

    • ใช้ โมเดล FastText ที่ฝึกด้วยคอร์ปัสและล็อกขององค์กร เพื่อสร้าง vector representation ของคำ และนำไปใช้กับงาน ML
    • ทนทานต่อการพิมพ์ผิดและคำที่ไม่อยู่ในพจนานุกรม โดยใช้ความหมายคล้ายกันของเวกเตอร์ข้างเคียงในการทำความเข้าใจความหมายของการค้นหา

  • LightGBM

    • ใช้โมเดล LightGBM จำนวนมากสำหรับ การจำแนกเจตนาคำค้นและการแท็กคุณสมบัติภายในคำค้น
    • ตัวอย่างเช่น คำค้นเชิงภูมิภาคอย่าง “New York” จะข้ามขั้นตอนการค้นหาที่อยู่, ในกรณีของ “841 Broadway” จะข้ามการค้นหา POI/พื้นที่

  • Apache Spark

    • ประมวลผลข้อมูลหลายร้อยล้านจุดภายใน 1 ชั่วโมง และมีการพัฒนา pipeline ต่อเนื่องเพื่อยกระดับประสิทธิภาพ join และ aggregation
    • ข้อมูลสุดท้ายถูกเก็บใน S3 และสามารถสำรวจผลลัพธ์แบบ SQL ด้วย Amazon Athena หรือ DuckDB ได้

ผลลัพธ์การนำ HorizonDB มาใช้

  • บริการ เร็วขึ้นมากและการดำเนินงานง่ายขึ้น พร้อมเพิ่มความน่าเชื่อถือโดยรวม
  • ทีมพัฒนาสามารถ นำข้อมูลและฟีเจอร์ใหม่มาใช้งานและประเมินได้ภายในวันเดียว
  • การปิดการใช้งาน Mongo, Elasticsearch และ microservice จำนวนมาก ทำให้ประหยัดได้หลายหมื่นดอลลาร์ต่อเดือน
  • Radar เตรียมพร้อมรับการขยายตัวในอนาคต และจะแนะนำขั้นตอนการออกแบบฟีเจอร์บางส่วนเพิ่มเติมผ่านบล็อกในภายหลัง

บทความที่เกี่ยวข้อง

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

 
GN⁺ 2025-08-10
ความคิดเห็นบน Hacker News

  • รู้สึกเสียดายที่ข้อมูลละเอียดค่อนข้างน้อยและดูเหมือนว่าไม่มีแผนโอเพนซอร์สด้วย ถ้าคุณเข้ามาอ่านบทความนี้เพราะกำลังหาแนวทางแทน ES (ElasticSearch) ผมอยากแนะนำ typesense.org และ duckdb.org (โดยเฉพาะพร้อมปลั๊กอิน spatial) เพราะทั้งสองบริการมีประสิทธิภาพข้อมูลเชิงพื้นที่ยอดเยี่ยม และ DuckDB ดูเหมาะมากสำหรับใช้งานโปรดักชันกับข้อมูลที่แทบไม่เปลี่ยนแปลง คำว่าโอเพนซอร์สก็ครบในโครงสร้าง cluster/sharding และนี่เป็นข้อแนะนำที่อ้างอิงจากประสบการณ์ใช้งานจริงแบบตรง ๆ

    • โปรเจกต์ทั้งสองยอดเยี่ยมมาก เราในทีมกำลังใช้ DuckDB อย่างแข็งขันสำหรับตรวจสอบ data lake และการทำ data processing แบบง่าย ๆ อยู่บ่อยครั้ง และตั้งใจจะเพิ่มบทความที่อธิบายรายละเอียดแต่ละส่วนของระบบต่อไป เพราะกังวลว่าข้อมูลมากเกินไปในโพสต์เดียวจะอ่านยาก

    • ขอบคุณที่ยังมีโปรเจกต์โอเพนซอร์สแบบนี้อยู่ แต่มันรู้สึกไม่ง่ายเมื่อจะผสานเข้ากับโปรเจกต์ของผม เดิมเคยพยายาม build โดยลิงก์แบบ static ระหว่าง duckdb, spatial และส่วนขยายของ SQLite แต่ตอนท้าย build ล้มเหลวเพราะสัญลักษณ์ SQLite เวอร์ชันต่างกัน ทำให้รู้สึกหนักหน่วงขึ้น

    • DuckDB ไม่มี sharding หรือ clustering เลยใช่ไหมครับ? ไม่มีเซิร์ฟเวอร์แยกต่างหากด้วย (ยกเว้น HTTP Server Extension)

    • Typesense ประสิทธิภาพดีมาก และประสบการณ์การพัฒนาก็ดีมากจริง ๆ

    • ผมไม่แน่ใจว่าจะโอเพนซอร์สอะไรดี—โค้ด Rust หรือไม่ก็ได้? ถึงจะประกาศตัวว่าเป็น DB แต่ดูแล้วเหมือนอธิบาย stack ทั้งหมด

  • สิ่งที่ขำใจเรื่องหน้าหางานคือการเอา 'วัฒนธรรมการทำงานในออฟฟิศ' มาเป็นข้อดึงดูดใจอันดับแรก ทำให้สงสัยจริง ๆ ว่าการคอมิวตจะเป็น benefit ได้ยังไง

    • คอมิวต vs. ทำงานจากบ้านไม่ใช่แค่เวลาเดินทาง แต่รวมถึงสภาพแวดล้อมการทำงานและ work-life balance หลายด้านด้วย ตัวอย่างที่ดีคือ ถ้าคอมิวตไม่เกิน 30 นาทีและเดินหรือปั่นจักรยานได้ มันเป็นประสบการณ์ที่ดีมาก ได้ออกกำลังกาย ได้คิดทบทวนตัวเอง และยังช่วยแยกโหมดบ้านกับโหมดทำงานด้วย ตัวช่วงที่ผม Work from Home เต็มรูปแบบในปี 2020 ทำในพื้นที่เดียวกันทั้งงานและพักผ่อนทำให้ใจเหนื่อยลงเรื่อย ๆ จนต้องเดินทุกวันหลังเลิกงานประมาณ 1 ชั่วโมงเพื่อฟื้นฟูสภาพจิตใจ แต่ถ้าต้องใช้เวลาคอมิวตมากกว่า 1 ชั่วโมงด้วยรถสาธารณะหรือบนทางด่วน ก็น่าจะหนักพอสมควร

    • ถ้าจะบอกว่าออฟฟิศมีข้อดีจริง ๆ ควรมีโอกาสเรียนรู้จากคนเก่ง ๆ, ทำความรู้จักเพื่อนใหม่, อาหาร/เครื่องดื่มฟรี, เครื่อง DDR และอย่างอื่นแบบนี้ด้วย ตอนประสบการณ์ออฟฟิศครั้งล่าสุดของผมไม่พบข้อดีเหล่านี้เลย บรรยากาศกลับดูคล้ายการทำงานจากบ้านในเวอร์ชันที่ขยายใหญ่ขึ้น

    • มีบางคนที่ชอบไปออฟฟิศได้แน่นอน เพราะแต่ละคนต่างกัน

    • ผมชอบคอมิวตมากกว่า WFH และเชื่อว่ามีคนจำนวนหนึ่งที่เห็นว่าคอมิวตคือ benefit

  • ผมสงสัยว่านี่น่าจะช่วย Photon ซึ่งเป็น search engine โอเพนซอร์สสำหรับข้อมูล OSM (OpenStreetMap) ได้หรือไม่ ค้นหาบนแอป OSM ส่วนใหญ่ตอนนี้ยังไม่ดีและพับพริบ typo ได้ แต่ Photon ทำให้ปัญหานี้ดีขึ้นเล็กน้อย ลิงก์ GitHub ของ Photon

    • กรณีนี้ผมคิดว่าระบบที่รันบน LMDB จะเข้ากันได้ดีกว่า RocksDB สำหรับโจทย์นี้ อีกอย่าง OSM Express ใช้ LMDB อยู่แล้ว ลิงก์วิกิ OSM Express

  • เป็นความเห็นเชิงเมตา แต่ผมดีใจที่เห็นการกลับมาของการออกแบบ storage/query engine ภายในองค์กรและการเขียนบล็อกที่คึกคักอีกครั้ง ช่วงปี 2010 เคยมีคลื่นแบบนี้ และช่วงหลังๆ ก็หันไปโฟกัส AI

    • ผมคิดว่าคลื่นนั้นไม่ใช่เพราะ AI แต่อย่างเดียว แต่เพราะท้ายที่สุดก็เห็นว่าอะไรหลายอย่างไม่มีประโยชน์มากนักและยังปรับ performance ของระบบเดิมด้วย tuning หรือ scaling ได้อยู่พอสมควร ดังนั้น stack ที่เฉพาะทางเกินไปจึงไม่จำเป็นในระยะยาว ระบบเก็บข้อมูล/คิวรีภายในที่ไม่มีแผนขายเป็นผลิตภัณฑ์ ก็กลายเป็นอาการ NIH (Not Invented Here) ขององค์กรที่มีทรัพยากรเหลือเฟือ

    • NoSQL/ฐานข้อมูลทางเลือกเคยเป็นกระแสเหมือนกันมาก จนสุดท้ายเมื่อมีการยอมรับว่าหลายองค์กรใช้ Postgres ตัวเดียวก็เพียงพอ กระแสนั้นก็ค่อย ๆ จางหาย

    • ผมยังไม่แน่ใจว่าอีกก้าวที่แท้จริงมีเหลือหรือไม่ แต่ส่วนใหญ่ผมจะเลือกใช้ของที่เชื่อถือได้และผ่านการพิสูจน์มากกว่าสโตร์เก็บข้อมูลเชิงทดลอง

  • ผมรู้สึกแปลกที่ในหัวข้อข่าวมีคำว่า "Rust" แทรกอยู่ เพราะผู้อ่านน่าจะงงว่า Rust แทนอะไร—ElasticSearch หรือ MongoDB

  • บทความนี้ขาดรายละเอียดเชิงเทคนิคเยอะมาก เช่น รูปแบบการ sharding ข้อมูล, ความต่างเวลาในการทำ indexing กับบริการ, การจัดการโหนดที่ล่ม, และ latency ใน distributed system

  • ในฐานะคนสาย search ผมกำลังเฝ้าดูด้วยความสนใจว่าปีหลัง ๆ มีบริษัทมากน้อยแค่ไหนที่ตั้งใจ "แทน ElasticSearch"

    • เขียนโดยผมเอง ตอนมุมมองการดำเนินงานทำให้ผมตัดสินใจย้ายจากการออกแบบแบบ "distributed system" มาเป็น "monolithic system" เพราะเชื่อว่าด้วยฮาร์ดแวร์ปัจจุบันก็ทำได้แล้ว เลือก RocksDB และ Tantivy ซึ่งเป็น embedded storage system แทน โดดเด่นด้วย memory-mapping ที่ทำให้รองรับการใช้งานทั่วโลกได้ และเนื่องจากคอมพิวต์คลาวด์เพิ่ม RAM ได้อิสระ ทำให้การทำแบ็กฟิลด์และอัปเดตนั้นไม่ต้องกังวลสถานะปัจจุบันแบบ ES/Mongo ซึ่งก่อนหน้าต้องดูเป็นพิเศษ อีกทางคือ reindex ทั้งระบบใหม่บน node ใหม่ด้วย binary เดียวแล้วส่งไปยัง S3 ทำงานได้ค่อนข้างง่าย

    • มักรู้สึกว่าความพยายามและเวลาที่ใช้ในการ run และดูแล Elasticsearch cluster มักมากกว่าการดูแลฐานข้อมูล production ตามปกติมาก จึงอยากใช้ตัวเลือกสำรองที่ง่ายกว่า ให้ฟังก์ชันน้อยกว่า ES แบบเดิมและมีโอกาสพังน้อยลงในหลายสถานการณ์

  • ผมสนุกกับการเห็นหลายบริษัทประกอบโซลูชันที่เข้ากับตัวเอง โดยเฉพาะการเริ่มต้นด้วยเครื่องมือโอเพนซอร์สเชิงพาณิชย์แทนการสร้างโซลูชันเองมากเกินไป โดยเฉพาะอย่างยิ่ง Quickwit ซึ่งผมพบผ่าน Tantivy ดูให้ความรู้สึกค่อนข้างใกล้ Lucene-based ES ลิงก์ GitHub ของ Quickwit

    • tantivy เอง :)

  • Rocks เป็นฟอร์กของ Level และ Level เป็นที่รู้จักเรื่องบั๊กแบบ data corruption และอื่น ๆ ทั้งสองระบบถูกใช้ใน production อย่างกว้างขวาง แต่ตอนที่ผมใช้ Level ทีมปฏิบัติการต้องต่อสู้กับการจัดการข้อผิดพลาดหนักมากเพื่อคงระบบให้เดินได้ เรื่องแบบนี้มักไม่ค่อยถูกพูดถึงในบล็อกของบริษัทที่มีสแต็กใหม่ๆ เพราะมักไม่พูดข้อเสียหนัก ๆ ของตนเอง และ tech talk ของบริษัทชื่อดังก็มักเป็นการโฆษณาเรื่องราวบริษัทเองสรุปแล้ว

    • RocksDB แยกตัวจาก LevelDB มาหลายปีแล้ว และตอนนี้ทั้งอุตสาหกรรมและวงการวิจัยได้พัฒนาปรับปรุงอย่างมาก จึงไม่ใช่ toy database แบบ LevelDB อีกต่อไป อาจมีจุดอ่อนที่ยังไม่เห็นทั้งหมด แต่ผมเชื่อว่าโอกาสที่ RocksDB จะมีปัญหาใหญ่โผล่ขึ้นมาน้อยมาก

    • ประสบการณ์ของผมต่างออกไป ตลอด 4 ปีที่ผ่านมา ผมรัน RocksDB บนเซิร์ฟเวอร์หลายพันเครื่อง (หลาย TB ต่อเครื่อง) โดยไม่เคยเจอข้อผิดพลาดจาก RocksDB เองเลย

  • ผมเข้ามาเพราะ keyword Elasticsearch และไม่เคยรู้จัก radar.com มาก่อน ซึ่งน่าทึ่งมาก; ตอนเห็นฟีเจอร์ autocomplete ในราคาเหมาะสมกับสิ่งที่ผมต้องการ มันเลยดึงความสนใจผม