Video học lập trình mỗi ngày

Khi dữ liệu trong hệ thống bán vé tàu tết chúng tôi thông kê mỗi tháng có thể tăng lên đễn 1,5 triệu order (Đây là con số khiêm tốn, thực tế còn x5 lên như vậy).

Lý do rất đơn giản, sau khi hoàn tất những tính năng quan trọng cho việc OpenTicket thì mô hình này được áp dụng cho nhiều trung tâm bán vé với nhiều đại lý liên kết, vì vậy không ngạc nhiên khi dữ liệu chúng tôi lên cao, và nó vượt xa giới hạn của một table trong mysql.

Điều cần làm với Dev và Doanh nghiệp nhỏ

Điều cần làm lúc này là gì?

Hôm nay chúng ta sẽ tham khảo một thủ thuật của những người đi trước, họ không có nguồn lực, không có chi phí cao như ngày nay. Nhưng đổi lại họ đã tìm cách vượt qua điều này như thế nào, chúng ta cùng xem xét.

Đầu tiên sẽ nghĩ ngay tới việc chia tách table và database theo cơ chế dọc và ngang như: KHI NÀO SHARDING TABLE LỚN trong MYSQL? Đây là 2 cách, VẤN ĐỀ phiền toái bắt đầu từ đây nhưng nó chỉ là bạn nghe và phần thực hành thì rất khó, kèm theo đó là nhược điểm nhiều hơn ưu điểm khi mà một công ty vừa và nhỏ không thể có CHI PHÍ lớn để cho thể đầu tư nhiều nguồn lực (devs giỏi) và đầu tư mua thêm những stack có thể giúp chúng ta làm những việc đó.

Công nghệ là đi với thực hành, lý thuyết chỉ là tạm bợ và sẽ quên đi nhanh chóng, vì vậy hãy trải qua việc thực hàng sẽ giúp bạn hiểu và nhớ lâu hơn so với những người xung quanh. OK...

Notes: Trước kia dự án của tôi và những người Anh thật sự không đạt tới hàng trăm triệu mỗi tháng như bây giờ, nhưng vấn đề ngày đó đều xử lý rất giống nhau khi một Table quá lớn. Do vậy, các bạn có thể có một cách tham khảo và tôi tin rằng có thể áp dụng vào hệ thống của bạn nhanh chóng.

MySQL - Xử lý hàng triệu dữ liệu tăng lên theo mỗi tháng

Khi mọi việc xong xuôi về phần phát triển logic và nhanh chóng sử dụng Jmeter để tạo áp lực lên api của chúng tôi. Và cảm xúc tôi còn nhớ như in là anh em lúc đó vô cùng sung sướng. Ngày đó ít có tài liệu cũng như hỗ trợ đắc lực của AI như bây giờ, do đó chúng tôi nghĩ đó cũng là một thành quả.

Nhưng đến việc dữ liệu lưu trữ hệ thống đặt vé được nhân rộng ra cho nhiều đại lý bán vé khoảng 100 trung tâm được mở bán. Lúc đầu theo thông kê thì sẽ có khoảng 5000 - 6000 vé được bán ra mỗi ngày với mỗi đại lý.

Như vậy theo như sự tính toán của TEAM khi họp xong thì con số hằng năm sẽ rơi vào tầm 180tr orders, chi tiết ở đây: Luận bàn về dữ liệu với 100 trung tâm

Nhưng đó là con số hiện tại tính tới thời điểm mà hệ thống đang triển khai, quan trọng liệu khi thiết kế này được đưa ra thì liệu 3 năm hay 5 năm sau nó vẫn hoạt động ổn định hay không? Đó là điều chúng ta phải suy nghĩ, vì có thể hiện tại ngày này năm sau thì không phải là 5000 vé được bán ra mỗi ngày, vì TÀU CAO TỐC BẮC NAM được đưa vào vận hành sau mấy năm thì kiễn trúc dữ liệu này phải khả thi

Vì sao chúng tôi không thêm Database

Trước tiên hãy phân tích tiếp, với số lượng connect trong Mysql với cấu hình server thì có thể đạt tới 1000 - 2000 connects mà chúng tôi chịu được. Và quan trọng nó đủ với hoạt độngREAD vs WRITE (xem lại những bài trước) kết hợp với Distributed và Local Cache thì chúng tôi không sợ điều đó, chỉ sợ rằng khi tách thêm một database nữa thì sẽ lãng phí rất nhiều. Vì sao?

Nhận thây trong Mysql chỉ có Tabler Order là tương đối có dữ liệu lớn, còn các bảng khác như User, Terminal, ... dều có mức tăng trưởng trung bình vì vậy không nên tách vì một thằng Order.

Tiếp đến, nếu một table thì việc lưu trữ tối đã được bao nhiều records. Theo như tài liệu nói về việc sử dụng InnoDB để lưu trữ thì việc lưu trữ tới hàng tỷ dữ liệu khi sử dụng InnoDB là điều có thể, nhưng tất nhiên thực tế thì không bao giờ ai lại làm thế? Rõ ràng, rất nhiều điều đã chứng minh rằng, càng nhiều dữ liệu thì việc truy vấn lại càng giảm.

Điển hình là việc truy vấn phân trang với 13tr dữ liệu mất 6 seconds, nhưng cũng may nhờ vào thủ thuật đơn giản chúng ta đã giảm xuống còn 1 second. Nếu quan tâm bạn có thể tham khảo: MYSQL BACKEND: Tối ưu hoá phân trang từ 7s còn 1s với Table có 10.000.000 dữ liệu.

Mục tiêu và quan trọng nhất là làm sao truy vấn hiệu quả nhưng chi phí là ít nhất, ngoài ra nếu như một table mà lớn thì việc backup cũng khoai lắm không phải chuyện đùa, đúng không?

Vậy chúng tôi tiếp tục họp và phần cãi nhau bắt đầu...

Giải pháp được đưa ra

Tình cờ chúng tôi đi mua sắm ở hệ thống tôi gọi là XXX, thì vô tình lụm được bí kíp lưu trữ dữ liệu của họ. Thật tuyệt vời, tất nhiên là chúng tôi chỉ dự đoán. Chờ bài viết tiếp theo được không Anh em?? ...