- 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 เตรียมพร้อมรับการขยายตัวในอนาคต และจะแนะนำขั้นตอนการออกแบบฟีเจอร์บางส่วนเพิ่มเติมผ่านบล็อกในภายหลัง
ยังไม่มีความคิดเห็น