Tình hình mình với thằng học sinh có làm 1 phần mềm chat dạng discord để đi thi giải khoa học kỹ thuật ở tỉnh nhà. Làm thì ok rồi nhưng đang mắc phải 1 vấn đề cần giải quyết là: - khi người dùng mở 1 chanel chat, các nội dung chat ở trong đó đc lưu vào CSDL dạng như mysql. Nhưng khi người dùng tắt ứng dụng đi, mở lại thì thời gian để máy tìm lại và hiện nội dung đã chat từ trước sẽ rất lâu ( khi csdl khá nhiều) Tôi thì lâu lắm rồi ko động vào lập trình nên cũng chẳng rõ hiện giờ dùng thuật toán gì để tìm kiếm Đây là định dạng table để lưu csdl các dòng chat
vì chỉ là 1 bài thi , không phải product nên hãy cache query . lúc mở lại app đa có cache thì load thì cache luôn
Show cái truy vấn lên xem nào. Chat thì người ta k dùng sql vì truy vấn sẽ lâu, phải dùng nosql . Nhưng mà app để thi thố thì dùng cũng đc vì data không có mấy.
TRong DB thì đánh index theo channel id Và đừng load toàn bộ mess của channel đó 1 lúc, chỉ load giới hạn tầm 100 - 1000 mess mới nhất chẳng hạn, kéo lên trên cùng thì load more....
Cách này chỉ là ăn xổi loè bọn mù công nghệ, nếu là một cuộc thi tử tế thì sẽ có demo và soi code luôn, chơi bài này thì ra chuồng gà sớm.
Tuỳ cache ở đâu á, cache query như ông kia nói thì là cache vào ram ở server rồi Còn cache ở client (phone, browser...) thì là cache theo request/api Dù cache theo cái nào thì cũng nên áp dụng kiểu check nếu có cache thì lấy ra luôn, nếu ko có thì mới thực hiện request Và chỉ cache ngắn thôi, tầm 1h chẳng hạn, hoặc cơ chế refresh cache khi có dữ liệu mới (là event channel đó có mess mới chẳng hạn), chứ đừng có cache forever Cho nó thực tế 1 chút, đừng làm ăn xổi chỉ để pass bài thi, sau ra làm quen tay áp dụng kịch bản tương tự thì.... hỏng người
Index lên elasticsearch mà truy vấn nếu yêu cầu bài thi cần giải pháp. Hỏi tiếp giải pháp indexing elasticsearch thì dùng tiếp Kafka Connect Sink. Demo thì chẳng cần vì tốc độ query trên MySQL thừa sức nhanh đáp ứng demo, chỉ khi nào làm prod mới cần quan tâm.
Nãy đọc lướt không để ý dòng này, lâu là mất bao lâu khi lấy 100 records? Trường hợp db đã lên đến hàng triệu record thì dù join 3-4 bảng, nếu đánh index đúng và sử dụng WHERE đúng, với cấu trúc table chỉ đơn giản như trên thì mất khoảng 1-2s đổ lại thôi. Thậm chí 2s là quá lâu. Làm no load data thì còn có 1 cách khác là cache trên ứng dụng giống các ứng dụng chat đang làm, cache file, sqlite...
Mới làm demo thử nghiệm và cũng ko cần data lớn tới mức hàng triệu record đâu bác ạ, chỉ là biết cách giải quyết đc vấn đề thì khi trình bày, nhỡ bị hỏi về vấn đề này thì trả lời sẽ suôn sẻ hơn, học sinh cũng hiểu rõ hơn bác ạ
Thày order theo timestamp xong limit vài chục cái gần nhất, kéo lên thì load thêm tính từ offset của bản ghi cuối cùng. Cái này gọi là pagination/lazy load Index thì nếu cần thì tạo, mà em thấy dữ liệu ít quá không cần lắm.
Lỡ làm đi thi có thuyết trình thì dùng nosql luôn đi fen. Coi như có thêm cái để thuyết trình cho có điểm +
Cơ bản thì sql đc rồi. Data ko nhiều với ko quen tối ưu chắc gì nosql đã nhanh hơn. Chat thì có thể dùng mấy cái có sẵn của firebase. Các service của firebase đủ cho 1 app chat realtime cơ bản
Chat thì dùng MongoDB để lưu má ơi Với cả load chat trên server những data hay dùng nên thì dùng Redis để cache