Từ SQL sang Redisearch, ánh xạ lệnh SQL sang Redisearch

Từ SQL sang Redisearch, ánh xạ lệnh SQL sang Redisearch

Những mẩu tin ngắn hàng ngày dành cho bạn
  • Hẳn là nhiều người ở đây đã nghe đến kiểu tấn công bảo mật Clickjacking rồi nhỉ. Kẻ tấn công thường nhúng một website (thường là mục tiêu) vào trong một iframe trên website của chúng, sau đó làm mờ hoặc ẩn nó đi rồi đặt vào vị trí các nút bấm trên web, ví dụ "Bấm vào để nhận quà". Đâu ai ngờ rằng phía trên nút bấm đó là một nút bấm khác trong iframe. Khá nguy hiểm!

    Nhưng trình duyệt đã có cách ngăn chặn kiểu tấn công này bằng các quy tắc như tiêu đề X-Frame-Options, frame-ancestors của CSP và SameSite: Lax/Strict của Cookies...

    Mới đây, đã xuất hiện thêm kiểu tấn công mới - "DoubleClickjacking" 😨. Đại ý là "hắn" lợi dụng hành động double click để lừa người dùng bấm vào một nút mà hắn muốn. Chi tiết hơn trong bài viết này: DoubleClickjacking: A New Era of UI Redressing.

    » Xem thêm
  • Mọi người đã nghe nói đến Jujutsu - jj - một dạng quản lý phiên bản cho mã nguồn (version control system) chưa? Có vẻ như nó đang nhận được nhiều sự quan tâm.

    Chờ xíu! Chẳng phải git đã quá tốt rồi sao? Thế thì chế ra thằng jj để làm gì nữa? Cũng hơi khó trả lời nhỉ? Mỗi công cụ sinh ra chắc chắn phải cải thiện hoặc khắc phục được nhược điểm của cái trước. Cho nên jj ắt hẳn phải làm được điều gì đó mà git chưa làm được nên mới nổi lên như vậy.

    Thật ra mình đã nghe nói đến jj từ vài tháng trước rồi, nhưng vào đọc thì toàn kiến thức cao siêu. Hoặc là đang mang nặng cái lối suy nghĩ của git vào trong đầu rồi nên chưa lĩnh hội ra được điều gì cả.

    Mình hay có kiểu cái gì đọc lần 1 mà không hiểu thì đọc tiếp lần 2, lần 2 không hiểu thì đọc tiếp lần 3... đến lần thứ n mà vẫn không hiểu thì bỏ. Cơ mà không phải là từ bỏ mà một thời gian sau đó quay lại đọc tiếp. Đến một lúc nào đó khả năng mình sẽ hiểu ra một ít vấn đề, thế mới tài 😆.

    Thì cái jj này có vẻ như nó đang mở ra được tính linh hoạt trong việc "cam kết" mã. Tưởng tượng bạn đang làm việc trên một dự án, đang ở nhánh này, muốn sang nhánh khác để sửa, nhưng mà lại đang viết dở ở nhánh này, thế là phải stash, rồi checkout, rồi commit, rồi merge hoặc rebase lại vào nhánh cũ... nhìn chung quá trình làm việc với git nghiêm ngặt đến mức cứng nhắc, cần nhiều thao tác để giải quyết một vấn đề, chưa kể cái cây commit (commit-tree) nữa thì ôi thôi, khỏi xem cho đỡ nhức mắt. Thế nên ông jj này đang làm cách nào đó để bạn khỏi cần phải quan tâm đến các nhánh luôn, sửa trực tiếp vào commit. Nghe ảo nhỉ 😂.

    Đấy mới lĩnh hội được đến đấy, hy vọng sau n lần đọc lại nữa mình sẽ viết được một bài chi tiết hơn về công cụ này.

    » Xem thêm
  • Gòi gòi tới công chiện gòi 🤤🤤🤤

    » Xem thêm

Vấn đề

Để tôi kể cho bạn nghe một câu chuyện, trước đây blog của tôi tôi sử dụng MySQL cùng với API bằng Node.js. Để duy trì được chúng tôi phải dùng đến máy chủ 2GB RAM. Phí duy trì hàng tháng là 10$ - 12$. Một số tiền không phải quá lớn, nhưng nó sẽ đủ lớn nếu phải duy trì liên tục. Chưa kể hàng tháng, tôi phải chi trả một số hóa đơn khác nữa.

Việc này là vấn đề lớn đến mức buộc tôi phải ngồi đánh giá lại xem liệu có cách nào chạy được blog trên cấu hình máy chủ thấp nhất hay không, khi đó số tiền sẽ giảm đi một nửa. Tôi biết đến redis từ trước, nhưng sử dụng redis để thay thế cho SQL là bất tiện vì một vài hạn chế về lưu trữ và cả truy vấn của redis so với SQL - vốn đã rất tốt và quen thuộc.

Tình cờ tôi biết đến Redisearch trong quá trình nghiên cứu, đây quả thực là một công cụ phù hợp trong tình huống này. Ngoài khả năng lưu trữ, tốc độ truy vấn... Redisearch còn mang lại khả năng tìm kiếm trên cả mong đợi. Tìm kiếm là tính năng tôi đặt lên hàng đầu vì mong muốn mang lại trải nghiệm tìm kiếm tốt cho người dùng. Giúp họ nhanh chóng tìm được thứ mình cần mà không tốn quá nhiều thời gian.

Trải qua một thời gian cùng Redisearch tôi có đúc kết một vài kinh nghiệm cho những ai đang có suy nghĩ "dùng Redisearch như là SQL" hay nói cách khác là ánh xạ những câu truy vấn của SQL sang Redisearch.

Mối tương quan

Bảng (Table) là thành phần không thể thiếu trong SQL, trong bảng có các cột (Column) định nghĩa kiểu dữ liệu dùng để lưu trữ. Trong Redis có một kiểu dữ liệu gần giống bảng là HASH. Khi dữ liệu được lưu trên HASH, qua bàn tay phù phép của Redisearch chúng ta sẽ có khả năng truy vấn dữ liệu tương đương với SQL.

Cấu trúc một HASH gồm có hash_name, bên trong lưu trữ các cặp thuộc tính - giá trị (key-value).

Ví dụ một dữ liệu lưu trữ trên HASH như sau:

> HSET articles:1 id 1 title "node.js là gì" url "nodejs-la-gi" createdAt 1671032684

Bạn đọc tìm hiểu thêm kiểu dữ liệu HASH tại Redis hashes.

Vì trong Redis, các HASH chỉ đơn giản là các dữ liệu rời rạc, không được chứa trong một tập hợp nào giống như bảng trong SQL, nên Redisearch tạo ra các Index Schema để tập hợp các HASH lại thành một cấu trúc tương tự như bảng.

Một số câu truy vấn thông dụng

Trong ví dụ này, tôi tạo ra một bảng articles gồm có id, title, url và createdAt tương ứng với các thông tin id bài viết, tiêu đề, url và thời gian tạo bài viết.

Kiểu dữ liệu

Trong SQL nói chung, một cột gồm có rất nhiều kiểu dữ liệu như char, varchar, int, float... tùy thuộc vào mục đích lưu trữ của cột mà ta lựa chọn kiểu sao cho tối ưu nhất. Trong Redisearch, một "cột" chỉ bao gồm các kiểu: Text, Numeric, Tag, Geo.

Tạo bảng

SQL:

CREATE TABLE articles (
    id int PRIMARY KEY,
    title varchar,
    url varchar,
    createdAt date
);

Redisearch:

> FT.CREATE articles ON HASH PREFIX 1 articles: SCHEMA id NUMERIC title TEXT url TEXT createdAt NUMERIC

Các HASH tạo ra theo quy tắc articles: được tự động đưa vào Index Schema articles.

Sửa bảng

SQL:

ALTER TABLE articles
ADD deletedAt date;

Redisearch:

> FT.ALTER articles SCHEMA ADD deletedAt NUMERIC

Note: Với SQL lệnh ALTER có thể thêm/sửa/xóa cột còn trong Rediseach thì chỉ có thể thêm Schema. Nếu muốn sửa xóa thì chỉ có cách DROP index schema và tiến hành tạo lại.

INSERT

SQL:

INSERT INTO article (id, title, url, createdAt)
VALUES (1, 'Node.js là gì', 'nodejs-la-gi', 1671032684);

Redisearch:

> HSET articles:1 id 1 title "Node.js là gì" url "nodejs-la-gi" createdAt 1671032684

SELECT

SQL:

SELECT * FROM articles LIMIT 10 OFFSET 0;

Redisearch:

> FT.SEARCH articles * LIMIT 0 10

Bạn đọc xem thêm một số cú pháp truy vấn cơ bản của SQL được chuyển qua Redisearch như thế nào tại Mapping common SQL predicates to RediSearch.

UPDATE

SQL:

UPDATE articles SET title = 'Node.js là gì?' WHERE id = 1;

Redisearch:

> HSET articles:1 title "Node.js là gì?"

GROUP BY

Giả sử có thêm một bảng react gồm có ba cột client_id, reacturl để lưu lại đánh giá của người dùng theo url bài viết. Bây giờ bạn cần lấy ra tổng từng react theo url:

SQL:

SELECT react, COUNT(*) AS count FROM react WHERE url = 'nodejs-la-gi' GROUP BY react;

Redisearch:

> FT.AGGREGATE articles "@url:nodejs-la-gi" GROUPBY 1 @react REDUCE count 0 AS count

Cú pháp có phần khác xa với SQL nhưng về cơ bản Redisearch có hỗ trợ truy vấn AGGREGATE, bạn đọc tìm hiểu thêm cú pháp tại FT.AGGREGATE.

Tổng kết

Bài viết trên đây tôi vừa tổng hợp lại một số lệnh thông dụng của SQL mà có thể ánh xạ sang Redisearch. Qua bài viết này tôi mong muốn cung cấp cho bạn đọc một góc nhìn khác về việc liệu Redisearch có thể giải quyết được vấn đề như SQL hay không. Bạn đọc quan tâm có thể đọc thêm bài viết Redisearch là gì? Estacks đang sử dụng redisearch làm cơ sở dữ liệu! của tôi.

Cao cấp
Hello

Bí mật ngăn xếp của Blog

Là một lập trình viên, bạn có tò mò về bí mật công nghệ hay những khoản nợ kỹ thuật về trang blog này? Tất cả bí mật sẽ được bật mí ngay bài viết dưới đây. Còn chờ đợi gì nữa, hãy bấm vào ngay!

Là một lập trình viên, bạn có tò mò về bí mật công nghệ hay những khoản nợ kỹ thuật về trang blog này? Tất cả bí mật sẽ được bật mí ngay bài viết dưới đây. Còn chờ đợi gì nữa, hãy bấm vào ngay!

Xem tất cả

Đăng ký nhận thông báo bài viết mới

hoặc
* Bản tin tổng hợp được gửi mỗi 1-2 tuần, huỷ bất cứ lúc nào.

Bình luận (0)

Nội dung bình luận...
Bấm hoặc cuộn mạnh để sang bài mới