Hello các bác, Tình hình là em có vài cái db MySQL có cái lên tới 3-40 triệu row. Và tốc độ query của nó là ác mộng của em, server thì em xài gói thấp nhất của Vultr 5$/tháng nên đương nhiên nó yếu. Web thì xài Cloudflare nên cứ trang nào chậm quá timeout của Cloudflare là nó quăng lỗi. Em đã bật slow_query_log rà từng câu query chậm và explain, thêm index và khắc phục nhưng ko cải thiện được mấy. Em cũng có dùng memcache nhưng chỉ có thể cache một số trang, user/bot mà chui vào trang chưa cache thì cũng vẫn đâm đầu vào tường. Em có xem MySQL partition, chia table ra từng partition theo thời gian, tốc độ thì ổn nhưng có những câu query mình cần lấy hết table thì nó lại thành vòng lẩn quẩn . Em có nghe nói về tốc độ thần sầu của nosql/mongodb nhưng chưa xài qua nên chưa biết thế nào. Xin các bác cho em lời khuyên ạ.
Nhanh vô địch thiên hạ thì chuyển sang Elasticsearch nhé. Còn mySQL nếu vài M rows thì cũng ko chậm lắm, trừ khi query kiểu like '%xxx%'
À sorry, tay nhanh hơn não, thớt nói là 30-40M rows thì đúng là query fulltext cũng chậm. Chỉ có query theo field = :value với field được oánh index thì nhanh.
Em query đơn giản theo kiểu category (có index cat) thôi đã chậm lắm rồi chứ like '%xxx%' thì nó treo luôn bác ợ. Để em nghiên cứu cái Elasticsearch xem sao
Ví dụ đây là 1 query trên mysql: so sánh category = :value (category có index và data cho category này khoảng hơn 1M rows chút xíu) và limit 10 rows từ 1 table có khoảng 70M rows và thời gian là 0.01 giây. Nó nhanh như vậy là vì: 1. lấy paging ngay page đầu tiên, nếu limit là limit 100000, 10 thì sẽ chậm hơn nhiều (category này có hơn 1M rows) 2. vì không có thêm order by hay toán tử khác trong where. Giả sử thêm vào order by id desc thì sẽ rất chậm (vì mysql sẽ phải order trên 1 tirệu rows và lấy ra 10 cái) Thế rút ra là gì: nếu muốn nhanh trên mysql thì hãy sửa code đi và bỏ mấy cái lông lá vớ vẩn đi. Ví dụ muốn paging đến page mấy ngàn làm gì? Ai xem? Chỉ cho paging vài page là dc rồi. Còn order by id có cần thiết không? Bỏ order by id thì dùng cách khác như sinh ra random id trước rồi query với where id in {....} cũng được chứ có sao đâu. Nhắc lại cho thớt nhớ là cái vụ thớt bán than hôm trước bị anh dập ko phải anh ác ý gì, chẳng qua anh biết thớt chưa đủ sáng tạo. Làm autoweb ko cần thông minh, cũng không cần giỏi, chỉ cần đẹp trai là vậy đó.
Đây là 1 cách query khác để lấy ra data trong category ở trên, vẫn nhanh như thường và thay cho paging khi dùng limit vối số page lớn (khi số page lớn, mysql sẽ phải dùng pointer để move đến vùng data cần query --> chậm)
Thôi nhé, demo nhiêu đó mệt roài. Còn muốn nhanh 1 cách toàn vẹn khỏi suy nghĩ thì cứ Elasticsearc (ES) mà táng.
like '%xxx%' đây là bạn lọc database row có xxx không tất nhiên chậm rồi,nếu bạn ko giới hạn kết quả nữa đơ là có thể hiểu. giải pháp hãy để xxx đó thành bảng từ khóa liên kết một nhiều với bảng cần lọc đi.
Mình đang làm theo kiểu chỉ giới hạn 100 page. Mysql vẫn ổn. Ko giới hạn chậm thôi rồi Mình dùng fulltext và giới hạn 100 page
Giải pháp với category thì làm một tab riêng chỉ dùng lưu id mỗi id lưu riêng id category. Lúc này tab này dung lượng rất nhỏ đọc file db sẽ nhanh hơn rất nhiều so Đấy là ý kiến của mình
Cảm ơn anh đã rất nhiệt tình chỉ dẫn, đúng là em bị cái bệnh cầu toàn làm web auto mà cứ như làm cho chính mình xài . Vụ sáng tạo em xin tiếp thu ạ, trước giờ em cứ đi 1 mình nên lạc đường suốt
table riêng chỉ lưu id mình nghĩ cũng ko khác mấy so với table full vì khi query đâu ai select * cho chậm
ý bác là thay vì search like thì mình dùng dạng tag phải ko ạ? like '%xxx%' chỉ là 1 VD em đưa ra thôi còn với db lớn thì hầu như query nào nó cũng chậm bác ợ
Khác chứ ý mình là tách bảng làm giảm kích thước file db server đọc sẽ nhanh hơn. Mình nghĩ 1 file 500mb đọc nhanh hơn file 20gb
ES thì liên quan gì Vultr $5? Chuyển sang cái mới thì phải nghiên cứu mà làm chứ ai nói dùng ES trên con Vultr $5? Còn fulltext khác search like thì cám ơn pé nha, anh đủ giỏi để hiểu ko cần pé chỉ.
Lúc nói ở trên là thớt chưa đề cập đến Vultr $5, sau này mới edit bài thêm vào. Dù vậy lần sau đừng có comment kiểu sân si với anh nhé, nghe vớ vẩn lắm. @Tony Vu thớt làm db có thông tin gì, niche gì mà 30-40M rows chỉ gói gọn trong cỡ ~20Gb ổ cứng?
Câu trả lời giống "Giải pháp với category thì làm một tab riêng chỉ dùng lưu id mỗi id lưu riêng id category. Lúc này tab này dung lượng rất nhỏ đọc file db sẽ nhanh hơn rất nhiều so" Thêm cái làm gì có một giải pháp áp dụng cho tất cả.Bạn mắc đâu thì nghĩ giải pháp đến đó chứ
em làm Instagram bác, row nó nhiều nhưng chủ yếu là tag, user, location, relation thôi chứ data ko có bao nhiêu hết. Cái nhiều data nhất là comment với des thì khi vô trang detail em mới get thôi. Ủa sao em coi trong thread ko thấy comment của bác code4foodnbeer mà lại có trong quote của bác money nhỉ?
