Xây dựng hệ thống tìm kiếm chuẩn GitHub với Go: Từ Lexer đến SQL Compiler

Bài viết được dịch và tổng hợp từ tin tức gốc. Bạn có thể đọc bài viết gốc bằng tiếng Anh tại đây.

Điểm tin nhanh:

• Sử dụng kỹ thuật Lexer có thứ tự ưu tiên để giải quyết xung đột ký tự (như dấu gạch ngang trong tìm kiếm).
• Xây dựng Abstract Syntax Tree (AST) giúp tách biệt logic phân tích cú pháp và logic truy vấn cơ sở dữ liệu.
• Đảm bảo an toàn tuyệt đối trước SQL Injection bằng cách tách biệt cấu trúc SQL và tham số người dùng.

Việc tìm kiếm dữ liệu trong các hệ thống lớn không chỉ đơn thuần là một câu lệnh LIKE trong SQL. Nếu bạn từng tự hỏi làm thế nào GitHub xử lý các truy vấn phức tạp như is:open label:bug -author:bot, câu trả lời nằm ở sự kết hợp tinh tế giữa Lexer, Parser và một Compiler mạnh mẽ. Thay vì để người dùng đối mặt với những lỗi truy vấn ngớ ngẩn, chúng ta sẽ cùng xây dựng một hệ thống tìm kiếm chuẩn chỉnh bằng Go, giúp tối ưu hóa quy trình quản lý tri thức cho lập trình viên vốn thường bị gián đoạn bởi các công cụ tìm kiếm kém hiệu quả.

Xử lý Lexer: Nghệ thuật của thứ tự ưu tiên

Thách thức lớn nhất khi xây dựng một bộ lọc tìm kiếm là xử lý các ký tự đặc biệt. Hãy lấy ví dụ với dấu gạch ngang (-). Nếu bạn coi nó là toán tử phủ định, thì help-wanted sẽ bị hiểu nhầm thành help, NOT wanted. Để giải quyết vấn đề này mà không cần dùng đến các máy trạng thái phức tạp, chúng ta sử dụng participle với quy tắc Lexer có thứ tự ưu tiên.

var searchLexer = lexer.MustSimple([]lexer.SimpleRule{
    {Name: "whitespace", Pattern: `\s+`},
    {Name: "String", Pattern: `"(\\.|[^\"])*"`},
    {Name: "Date", Pattern: `\d{4}-\d{2}-\d{2}`},
    {Name: "Number", Pattern: `\d+`},
    {Name: "Op", Pattern: `>=|<=|>|<`},
    {Name: "Colon", Pattern: `:`},
    {Name: "Ident", Pattern: `[a-zA-Z_][a-zA-Z0-9_./-]*`},
    {Name: "Dash", Pattern: `-`},
})

Mẹo hay: Bằng cách đặt Date, Number và Ident trước quy tắc Dash, Lexer sẽ ưu tiên bắt các chuỗi phức tạp trước. Dấu gạch ngang chỉ được coi là toán tử phủ định khi nó không thể thuộc về bất kỳ token nào khác.

Biên dịch cây cú pháp thành SQL

Sau khi đã có AST (Abstract Syntax Tree), bước tiếp theo là chuyển đổi nó thành SQL. Đây là lúc chúng ta cần một registry để ánh xạ các từ khóa tìm kiếm sang các cột tương ứng trong database. Việc này giúp bạn tối ưu hóa quy trình quản lý tri thức cho lập trình viên mà không cần thay đổi cấu trúc grammar.

Khi thực hiện biên dịch, mỗi term sẽ được chuyển thành một đoạn mã SQL. Đối với các trường hợp như label, chúng ta sử dụng EXISTS để truy vấn qua bảng trung gian, đảm bảo tính chính xác cho hệ thống xây dựng ứng dụng AI cấp độ Production.

Đảm bảo an toàn trước SQL Injection

Một trong những sai lầm phổ biến nhất là nối chuỗi trực tiếp vào câu lệnh SQL. Trong hệ thống này, chúng ta tách biệt hoàn toàn cấu trúc SQL và giá trị người dùng thông qua các placeholder ?.

Lưu ý: Tuyệt đối không bao giờ chèn trực tiếp input của người dùng vào câu lệnh SQL. Việc sử dụng []any để truyền tham số giúp driver database tự động xử lý escaping, ngăn chặn hoàn toàn các cuộc tấn công SQL Injection.

Đánh giá & Lời khuyên Thực tiễn

Giải pháp này cực kỳ hiệu quả cho các ứng dụng cần bộ lọc tìm kiếm linh hoạt mà không muốn phụ thuộc vào các engine tìm kiếm cồng kềnh như Elasticsearch.

• Ưu điểm: Cấu trúc code sạch, dễ mở rộng (chỉ cần thêm một dòng vào registry để hỗ trợ field mới), an toàn cao.
• Nhược điểm: Chưa hỗ trợ các truy vấn phức tạp với OR hoặc ngoặc đơn (parentheses) trong phiên bản cơ bản.
• Phạm vi ứng dụng: Phù hợp cho các hệ thống quản trị nội bộ, dashboard dữ liệu, hoặc các công cụ CLI cần khả năng lọc dữ liệu mạnh mẽ.

Khi triển khai trên Production, hãy cân nhắc việc xây dựng hệ thống Presence nếu bạn cần đồng bộ trạng thái người dùng trong thời gian thực, hoặc tối ưu hóa quy trình kiểm thử Cloudflare Workers để đảm bảo tính ổn định của các service liên quan.

Câu hỏi thường gặp (FAQ)

Tại sao nên dùng AST thay vì Regex trực tiếp?

AST cho phép bạn phân tích cấu trúc truy vấn một cách logic, hỗ trợ tốt cho việc lồng ghép các toán tử và dễ dàng debug hơn nhiều so với việc viết các biểu thức Regex khổng lồ.

Làm thế nào để thêm hỗ trợ cho toán tử OR?

Bạn cần định nghĩa thêm các node OrExpr trong grammar và cập nhật Compiler để xử lý việc nối các đoạn SQL bằng từ khóa OR thay vì AND mặc định.

Giải pháp này có thể thay thế Elasticsearch không?

Nếu dữ liệu của bạn nằm trong phạm vi hàng triệu dòng và không yêu cầu tìm kiếm mờ (fuzzy search) quá phức tạp, thì đây là giải pháp thay thế nhẹ nhàng và hiệu quả về chi phí.

Kết luận

Việc tự xây dựng một bộ máy tìm kiếm không chỉ là bài tập kỹ thuật thú vị mà còn giúp bạn hiểu sâu hơn về cách các hệ thống lớn vận hành. Bằng cách áp dụng tư duy AST và Lexer, bạn hoàn toàn có thể tạo ra những công cụ mạnh mẽ, an toàn và dễ bảo trì. Hãy bắt đầu clone repository, chạy thử demo và thử thêm một qualifier mới ngay hôm nay. Đừng quên theo dõi hi_dev để cập nhật thêm những kiến thức chuyên sâu về kiến trúc phần mềm và công cụ lập trình.

Bạn đã bao giờ gặp khó khăn khi thiết kế DSL cho ứng dụng của mình? Hãy để lại bình luận bên dưới để cùng thảo luận!