Các phương pháp đồng bộ dữ liệu từ MySQL sang Elasticsearch: Lựa chọn nào dành cho bạn?

Chào các bạn!

Hôm nay, ViVu sẽ cùng các bạn khám phá chủ đề đồng bộ dữ liệu từ MySQL sang Elasticsearch (hay còn gọi là ES) - một vấn đề thường gặp trong thương mại điện tử.

Vấn đề: Dữ liệu sản phẩm thường được lưu trữ trong MySQL, nhưng để tìm kiếm hiệu quả, chúng ta cần chuyển nó sang ES. Vậy, làm thế nào để thực hiện việc này một cách mượt mà?

4 phương pháp đồng bộ dữ liệu:

1. Ghi kép đồng bộ (Sync-Write):

Cách thức: Ghi dữ liệu vào MySQL đồng thời ghi vào ES.
Ưu điểm: Dễ dàng thực hiện, độ trễ thấp.
Nhược điểm:
- Gắn bó chặt chẽ với nghiệp vụ, logic phải viết trong hệ thống nghiệp vụ .
- Làm giảm hiệu suất do việc ghi vào hai hệ thống lưu trữ dẫn đến thời gian phản hồi kéo dài..
- Hạn chế về mở rộng: Tìm kiếm có thể có một số yêu cầu cá nhân hóa, đòi hỏi việc tổ chức dữ liệu, điều này không dễ dàng thực hiện với phương pháp này.

2. Ghi kép bất đồng bộ (Async-Write):

Cách thức:
- Ghi dữ liệu vào MySQL và hàng đợi tin nhắn (Message Queue - MQ).
- Dịch vụ tìm kiếm riêng nhận tin nhắn từ MQ và đồng bộ dữ liệu sang ES.
Ưu điểm:
- Tách rời ứng dụng, giúp sửa đổi dữ liệu dễ dàng hơn.
- Tính thời gian thực tốt vì dữ liệu được ghi vào ES sau.
Nhược điểm: Tăng độ phức tạp của hệ thống do cần thêm MQ và dịch vụ tìm kiếm.

3. Nhiệm vụ định kỳ (Scheduled Tasks):

Cách thức: Nếu chúng ta cần một giải pháp nhanh và khối lượng dữ liệu không quá lớn, các nhiệm vụ lập lịch cũng có thể là lựa chọn tốt.
Nhiệm vụ lập lịch: Thách thức lớn nhất của các nhiệm vụ lập lịch là lựa chọn tần suất phù hợp. Tần suất cao có thể dẫn đến các đỉnh kinh doanh không tự nhiên, gây ra sự gia tăng về CPU và bộ nhớ trong hệ thống lưu trữ. Tần suất thấp dẫn đến hiệu suất thời gian thực kém và có thể gặp các tình huống đỉnh.
Ưu điểm: Đơn giản để thực hiện.
Nhược điểm:
- Khó đảm bảo tính thời gian thực.
- Gây áp lực lên hệ thống lưu trữ vì dữ liệu được đồng bộ cùng lúc.

4. Đăng ký dữ liệu (Data Subscription):

Cách thức: Binlog subscription hoạt động dựa trên nguyên tắc mô phỏng một slave MySQL để theo dõi và nhận log binlog. Từ đó, nó có thể thực hiện CDC (Change Data Capture) - thu thập dữ liệu thay đổi từ database. (Chi tiết binlog như thế nào các bạn có thể tham khảo docs của MySQL nhé!)
Ưu điểm:
- Ít ảnh hưởng đến ứng dụng.
- Tính thời gian thực tốt vì dữ liệu được đồng bộ ngay khi thay đổi.
Nhược điểm: Cần viết mã để xử lý các trường hợp đặc biệt, ví dụ như tổng hợp dữ liệu từ nhiều bảng, bên cạnh đó cần phải test rất nhiều.

Binlog - Chìa khóa cho phương pháp thứ 4:

Binlog ghi lại mọi thay đổi dữ liệu trong MySQL, giúp Data Subscription theo dõi và đồng bộ dữ liệu sang ES một cách hiệu quả.

Tò mò về phương pháp thứ 4?

Hãy theo dõi bài viết tiếp theo để khám phá chi tiết về cách triển khai phương pháp Data Subscription với Binlog nhé!.

Lời khuyên:

Hãy chọn giải pháp có những nhược điểm chấp nhận được, đáp ứng nhu cầu của bạn và có chi phí thấp nhất.
Tham khảo thêm tài liệu để hiểu rõ hơn về từng phương pháp.
Đừng ngại hỏi nếu bạn cần trợ giúp.

Chúc các bạn thành công!

Lưu ý: