Search Architecture

Bài tóm tắt Instagram 2015 3. Quy mô lớn Độ khó: Trung bình

Instagram · 2015 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Instagram dùng lại Unicorn, search engine của Facebook (xem Meta 2013). Site chặn crawler; ghi chú viết từ bản đọc qua trình duyệt.

Bối cảnh

  • Đầu 2015, Instagram chuyển toàn bộ hạ tầng search từ Elasticsearch sang Unicorn, hạ tầng search có nhận biết social graph của Facebook, đã chạy với index hàng nghìn tỉ document. Cùng giai đoạn, traffic search tăng 65% (user tăng, cộng 12% nhiều người dùng search hơn mỗi lần mở app).
  • Theo Instagram, được ở trong một công ty lớn nghĩa là có thể "nhảy cóc" tới thứ Facebook mất mười năm xây.

Thay đổi chính

  • Mô hình: một kho denormalize mọi thực thể (hashtag, địa điểm, user, media) thành document, gom thành tập theo term; query là phép tập (AND, OR, NOT) rồi xếp hạng và cắt.
  • Đưa dữ liệu vào (Slipstream + Firehose):
    • Instagram phục vụ hàng triệu request/giây, ghi vào các DB PostgreSQL chính. Search cần nhiều hơn một dòng Postgres (ví dụ tuổi tài khoản của tác giả khi có ảnh mới).
    • Mỗi sự kiện được mã hoá thành một struct Thrift lớn, chứa sẵn nhiều thông tin hơn mức consumer thường cần (sự kiện like kèm cả object Media, người like, chủ ảnh, có đang follow không), gửi qua kênh pub/sub bất đồng bộ Firehose (dựng trên Scribe). Consumer như search lọc sự kiện liên quan.
    • Firehose là best-effort, chấp nhận mất một phần nhỏ. Nhất quán sau đạt bằng base build: mỗi đêm snapshot mọi DB Postgres vào Hive; định kỳ dựng lại document cho từng vertical từ Hive rồi gộp với dữ liệu từ Slipstream.
  • Truy vấn: query được viết lại thành S-expression (ví dụ "người tên maxime được người tôi follow follow"); hai bước đan xen là sinh ứng viên từ inverted index và xếp hạng bằng feature (chấm điểm tay hoặc ML).
  • Search theo đồ thị: index quan hệ follow để trả lời "tài khoản X follow và Y cũng follow"; phải chỉnh ranking của Facebook (bạn bè hai chiều) cho đồ thị follow một chiều của Instagram.
  • Hộp search hợp nhất: bỏ việc chọn trước tài khoản hay hashtag; classifier đoán loại kết quả, click hashtag tăng hơn 20% mà không hại search tài khoản. (Phần ML chỉ tóm tắt ngắn.)
  • Media search là hạ tầng thuần: vertical lớn nhất (hàng tỉ post, hàng nghìn tỉ like), user không gõ query; dùng cho Explore, trang hashtag, địa điểm. Posting list sắp theo thời gian ngược (static rank để ưu tiên mới); term phụ (đã xác minh...) cộng toán tử WEAK AND để đảm bảo đa dạng (ví dụ ít nhất 30% ứng viên từ tài khoản xác minh). Explore là một query Unicorn: "ảnh được like bởi chủ những ảnh bạn đã like".

Vì sao

  • Dùng lại một hạ tầng index đã chín trong công ty mẹ thay vì tự scale Elasticsearch; Unicorn có sẵn toán tử đồ thị mà Elasticsearch không có.

Bài học cho SWE

  • Một hạ tầng index chung phục vụ được cả search có query lẫn tính năng không có query (feed khám phá, trang hashtag) (Hạ tầng tìm kiếm).
  • Cặp luồng sự kiện best-effort + dựng lại định kỳ từ snapshot cho index dẫn xuất: luồng giữ độ tươi, base build sửa phần mất. Không cần exactly-once (Event-driven, message queue và Kafka).
  • Sự kiện mang sẵn dữ liệu denormalize giúp consumer không phải gọi ngược về DB chính.

Liên quan