Lesson 5.3: Search Best Practices

Thời lượng: 20 phút
Level: Intermediate
Yêu cầu: Đã nắm vững về Filtering qua Query Params.

Mục tiêu bài học

Sau bài học này, bạn sẽ:

• Phân biệt được Tìm kiếm chính xác (Filtering) và Tìm kiếm từ khóa (Search).
• Biết cách thiết kế tham số q (query) chuẩn cho API tìm kiếm.
• Hiểu khi nào cần chuyển từ Database quan hệ sang các Search Engine chuyên dụng.

Nội dung chính

1. Search vs Filtering

Rất nhiều người nhầm lẫn giữa hai khái niệm này.

• Filtering: Tìm chính xác hoặc theo khoảng (VD: status=completed, price > 100). Mục tiêu là thu hẹp tập hợp dữ liệu.
• Search (Full-text): Tìm theo từ khóa trong các đoạn văn bản (VD: Tìm từ "iPhone" trong tên và mô tả sản phẩm). Mục tiêu là tìm các bản ghi có độ liên quan (relevance) cao nhất.

2. Thiết kế tham số Search

Trong một Design System, hãy dùng một tham số duy nhất cho việc tìm kiếm từ khóa chung. Tham số phổ biến nhất là q (viết tắt của query).

Ví dụ: GET /products?q=tai+nghe+bluetooth

Backend sẽ tìm từ khóa này trên nhiều trường cùng lúc (VD: name, description, tags).

3. Hiệu năng: Kẻ thù của Search

Cấp độ 1: SQL LIKE (Dữ liệu nhỏ) WHERE name LIKE '%tai nghe%'

• ❌ Nhược điểm: Rất chậm khi dữ liệu lớn vì DB không dùng được Index thông thường (vì có dấu % ở đầu).

Cấp độ 2: Full-text Search chuyên dụng (Dữ liệu vừa) Dùng GIN Index trong PostgreSQL hoặc Match() trong MySQL.

• ✅ Ưu điểm: Nhanh hơn LIKE rất nhiều, hỗ trợ tìm kiếm không dấu, tìm từ tương đồng.

Cấp độ 3: External Search Engine (Dữ liệu lớn/Phức tạp) Đưa dữ liệu sang Elasticsearch, Meilisearch hoặc Algolia.

• ✅ Ưu điểm: Hỗ trợ "Typo tolerance" (tìm đúng cả khi gõ sai), Search Suggestion, lọc theo độ liên quan cực mạnh.

Nguyên tắc then chốt

"Đừng bao giờ để tính năng tìm kiếm làm sập database chính."

Tìm kiếm từ khóa (LIKE '%...%') là một trong những nguyên nhân hàng đầu gây treo database do Full Table Scan. Nếu bảng dữ liệu của bạn có trên 100,000 dòng, hãy cân nhắc dùng Full-text Index hoặc Search Engine bên ngoài.

Thực hành

Bài tập 1: Phân tích tham số search của Google/Stripe

Yêu cầu:

• Hãy quan sát URL của Google hoặc Stripe khi bạn tìm kiếm.
• Họ dùng tham số gì? Họ xử lý các khoảng trắng trong từ khóa như thế nào?

Tình huống thực tế

Scenario 1: Tìm kiếm "Mỳ tôm" hay "Mì tôm"?

Bối cảnh: User gõ "Mỳ tôm" nhưng trong DB bạn lưu là "Mì tôm". Với SQL LIKE thông thường, bạn sẽ không tìm thấy gì.

Giải quyết: Đây là lúc bạn cần Normalization dữ liệu trước khi search:

1. Chuyển tất cả về chữ thường (Lower-case).
2. Loại bỏ dấu tiếng Việt hoặc dùng thư viện xử lý từ đồng nghĩa.
3. Nếu dùng PostgreSQL, hãy dùng tsvector để hỗ trợ search tiếng Việt chuyên nghiệp hơn.

Câu hỏi phỏng vấn

Senior Level

1. Q: Làm thế nào để triển khai tính năng "Tìm kiếm ngay khi đang gõ" (Search-as-you-type) mà không làm "spam" server? A:
   • Debouncing: Phía Client chỉ gửi request sau khi user dừng gõ khoảng 300-500ms.
   • Throttling: Giới hạn số lượng request tối đa trong một khoảng thời gian.
   • Caching: Cache lại các từ khóa phổ biến ngay tại lớp Gateway hoặc CDN.
   • Edge Search: Dùng các dịch vụ như Algolia để đưa dữ liệu search ra gần user nhất có thể.

Tóm tắt

Những điều cần nhớ

• Dùng tham số q cho tìm kiếm tổng quát.
• Cẩn thận với hiệu năng của lệnh LIKE.
• Tìm kiếm từ khóa khác hoàn toàn với việc lọc dữ liệu chính xác.

Bước tiếp theo

🎉 Chúc mừng! Bạn đã hoàn thành Module 5: Pagination & Filtering.

Bạn đã học được cách:

• Phân trang chuẩn cho mọi loại thiết bị.
• Thiết kế hệ thống lọc và sắp xếp linh hoạt.
• Triển khai tìm kiếm an toàn, hiệu quả.

Module tiếp theo: Module 6: Authentication & Authorization - Tìm hiểu về bảo mật, JWT, OAuth2 và phân quyền.

Bắt đầu Module 6 →