Giang Thiên Phú - Kinh nghiệm tối ưu mongodb với database hơn 100 triệu record và xử lý 10 triệu transaction / ngày

1. MongoDB at Callio
Kinh nghiệm tối ưu DB 100 triệu record

2. 01 Vấn đề
● Mỗi ngày ~10 triệu record mới, ~5 triệu update, ~200 triệu read
● Launch từ tháng 7/2020, tính tới nay khoảng 3.6 tỷ record

3. 02 Phân tích & ý tưởng
Nhận định
● Cần đánh index các collection (khỏi bàn lý do)
● Đa số các read ops không yêu cầu real-time data
consistency
● Data nhiều chủ yếu tập trung một vài collection:
call log, chat log, customer log
● Data cũ ít dùng hơn data mới
● Một số loại wire không cần write ngay cũng được
● Ban ngày user dùng nhiều hơn ban đêm
Ý tưởng
➢ Thống nhất giữa code và index, query gì thì đánh
index cái đó
➢ Có thể replicate để phân tải read, chấp nhận
replica lag (1-2s) với đa số các read query
➢ Tập trung tối ưu bọn này trước!
➢ Có thể xóa data cũ
➢ Một số tác vụ write có thể queue lại chạy dần
➢ Nhiều tác vụ write nhiều, dọn dẹp data có thể
chạy vào ban đêm

4. 03 Tối ưu index & query
Kinh nghiệm index
● Query trên nhiều field -> phải index trên nhiều field
(compound index)
○ Thứ tự field trong index rất quan trọng, vd:
■ Theo query: chính xác > range > sort
■ Theo data đa dạng: nhiều > ít
■ Theo tần suất query: nhiều > ít
○ Không tham index thừa nhiều field (2-4)
● Dùng partial index với các collection lớn
● Dùng hashed index với các field dài cần tìm kiếm
chính xác (vd: token, uuid…)
● Với các collection lớn, field ít query: khỏi index
(dùng chung index)
Lưu ý
● Query không có index thì phải scan -> chậm, nặng
● Index nhiều tốn ram, write nặng -> index thừa nguy hiểm hơn index thiếu
Tối ưu ứng dụng
● 99% tác vụ backend có bottleneck nằm ở DB ->
không bắt DB tính toán, cái gì dùng backend tính
được thì tính ở backend
● Tối ưu UI/UX -> mỗi user interaction = một query
vào 1 collection
● Thống nhất filter & search theo 1 kiểu ngay từ đầu,
dùng cho mọi chức năng
● Collection lớn: không query prefix, regex, text ->
dùng search engine riêng (elasticsearch)
● Caching các data ít thay đổi

5. 04 Replication

6. 05 Report caching
● Các báo cáo thường là query count, sum, aggregate ->
bản chất là scan DB để tính toán -> rất nặng
● Đặc điểm của các báo cáo này là data trong quá khứ
không thay đổi
● Cần xây dựng cơ chế cache kết quả theo time range của
các báo cáo để giảm tải

7. 06 Xóa data cũ
● Data cũ rất ít khi cần dùng
● Gây nặng db, tốn dung
lượng, nặng index chậm cả
write lẫn read
● Chứa nhiều thông tin quan
trọng, không được xóa

8. 07 Monitor & log
“You can’t improve what you don’t measure.”
● Liên tục log slow query
● Họp định kỳ, theo dõi và tối ưu các slow
query

9. THANK
YOU