อ่านเจอบทความเกี่ยวกับการเปลี่ยนระบบ search engine ของ Yelp มาใช้ Elasticsearch
Moving Yelp’s Core Business Search to Elasticsearch
โดยที่ระบบเดิมนั้น ทำการ custom จาก Apache Lucene มากมายเช่น

  • Distributed Lucene
  • Master-slave
  • Custom text analysis สำหรับภาษาต่าง ๆ
  • Custom ระบบ ranking ของการค้นหาให้เป็นไปตาม business model เช่น การ review, เวลาเปิดปิด และตำแหน่งของร้าน เป็นต้น

สิ่งที่น่าสนใจคือ เหตุผลของการเปลี่ยนแปลงมาใช้ Elasticsearch ?
จึงทำการแปลและสรุปไว้นิดหน่อย

1. ปัญหาเรื่อง Realtime indexing

เนื่องจากระบบเดิมนั้นมีโครงสร้างแบบ Master-Slave
โดยที่ master server ทำหน้าที่สำหรับการ indexing data
ส่วน slave นั้นทำหน้าที่สำหรับ query หรือดึงข้อมูล

ข้อมูลจากการทำ indexing บน master นั้น
จะถูก upload ไปไว้ที่ Amazon S3
จากนั้น slave จะทำการ download ข้อมูลจาก Amazon S3 มาตามเวลาที่กำหนดไว้ (Scheduler)
เพื่อได้ข้อมูลใหม่มาใช้งาน
ซึ่งทำให้เกิดปัญหากับบางระบบที่ต้องการข้อมูลแบบ realtime (ใช้คำว่าต้องรอไม่กี่วินาที)
ตัวอย่างเช่น ระบบการจอง และ transaction ต่าง ๆ เป็นต้น

การแก้ไขคือ นำ data store ที่ทำงานแบบ realtime มาใช้งานสำหรับงานนั้น ๆ
ยกตัวอย่างเช่น Elasticsearch มาทำงานควบคู่กันไป
โดยควบคุมการทำงานโดย application layer
แต่ก็มีปัญหาเรื่องประสิทธิภาพการทำงานเมื่อระบบขยายใหญ่ขึ้น
เนื่องจากทั้งการรวมและจัดเรียงผลการค้นหา ต้องทำในส่วน application layer !! (คอขวด)

2. ปัญหาเรื่อง ช้าต่อการเปลี่ยนแปลง

การทำงานนั้นจะมีทีมที่ทำหน้าที่ปรับปรุง ranking algorithm ของผลการค้นหา
ซึ่งจะมีการเปลี่ยนแปลง code และ push code หลายครั้งต่อวัน
จากนั้นจึงเข้าสู่กระบวนการ deploy แบบอัตโนมัติ
แต่กว่าจะ rollout ได้แต่ละครั้งต้องใช้เวลานนาน
โดยระบบการค้นหานี้เป็น microservice ที่ใหญ่ที่สุดของ Yelp แล้ว !!

ที่สำคัญการ sharding ข้อมูลของการค้นหาจะแบ่งเป็น 2 ชั้นคือ (ข้อมูลใหญ่มาก ๆ)
1. Geosharding แบ่งจาก geolocation เช่นการแบ่ง business model แยกตามรัฐไปเลย
2. Microsharding /Microindex แบ่งโดยใช้ modulo (%) ตามจำนวนที่กำหนด

ในแต่ละ instance จะมีการทำ indexing แยกกันไปอีก
ดังนั้นหมายความว่า ถ้ามีการเปลี่ยนแปลงข้อมูลและ algorithm แล้ว
ต้องทำการ update ในทุก ๆ instance !!!
ส่งผลให้การเปลี่ยนแปลงแต่ละรอบต้องใช้เวลานาน
ส่งผลต่อ business อย่างมากมาย
จะปรับปรุงอย่างไรดี ?

3. ยากต่อการเพิ่ม feature ใหม่ ๆ ในอนาคต !!

เนื่องการทำ indexing ใหม่ หรือ reindexing ต้องใช้เวลาที่นาน
นั่นหมายความว่าถ้าต้องการเพิ่ม feature ใหม่ ๆ เข้ามาในอนาคต
ต้องทำมีค่าใช้จ่ายต่าง ๆ สูงมาก หรืออาจจะเป็นไปไม่ได้เลย (Exponential)
เนื่องจากระบบปัจจุบันนั้นไม่สามารถทำสิ่งเหล่านี้ได้อย่างรวดเร็ว

  • เปลี่ยนแปลง sharing algorithm
  • เปลี่ยนแปลง Analyzer
  • เปลี่ยนแปลง Ranking
  • ติดปัญหาเรื่องข้อจำกัดของ JVM Heap size

จากทั้ง 3 เหตุผลนี้ทำให้ทางทีมพัฒนาคิดว่า

ต้องทำอะไรบางอย่างแล้ว ?
ทั้งออกแบบและสร้างระบบใหม่ขึ้นมา
ซึ่งมีเป้าหมายดังนี้

  • แยกการทำงานระหว่าง application layer และ backend service ออกจากกัน
  • เปลี่ยนแปลง code ได้รวดเร็วขึ้น
  • ง่ายต่อการ custom หรือแก้ไข ranking ต่าง ๆ
  • Realtime indexing
  • ว่าด้วยเรื่องของ performance ของระบบที่เพิ่มขึ้นต้องเป็น linear ตาม business และ feature ที่เพิ่มขึ้น

โดยทีมพัฒนามองว่า Elasticsearch คือหนึ่งในเครื่องมือที่น่าจะช่วยแก้ไขปัญหาต่าง ๆ เหล่านี้ได้
แต่เชื่อได้ว่า ต้องมีการ custom อะไรอีกมากมาย