Lập trình BackEnd: 4 cách tăng hiệu suất truy vấn khi Order (đơn hàng) trong database đã phình to !

👉 Link khóa học backend Nodejs: / @anonystick
Trong video này sẽ giới thiệu bốn cách mà hầu hết các công ty internet đều triển khai trường hợp khi dữ liệu phình to ra. Và đây cũng là câu hỏi của cộng đồng Tipjs đã hỏi. Để ý phút 18 đến 19 nếu bạn là người lười biếng.
Câu hỏi như sau:
"chào anh, anh cho em hỏi, đứng dưới góc độ là backend engineer thì theo anh, khi user order món hàng và tiến hành thanh toán
Thì lưu lại thông tin đơn hàng đó vào collection (em sử dụng mongodb). Nếu đơn hàng cứ tới tiếp tục từ nhiều users khác nhau thì db và server sẽ phình to ra và tới mức cố định, vậy cho em hỏi: Có nên xoá dữ liệu lịch sử đơn hàng theo năm (ví dụ sau 1 năm) hoặc 1 khoảng thời gian hay là không được xoá luôn, em cảm ơn, chúc anh sức khoẻ ".
Time lines:
00:00 Giới thiệu và phân tích câu hỏi
06:30 Nói về thuật toán khi database đạt tới giới hạn thì sẽ chậm mặc dù có index.
12:32 Cách thiết kể model schema Order tối ưu trong Database
16:11 4 thuât toán chia dữ liệu khi đạt tới giới hạn.
🚩 Subscribe ➜ / tipsjavascript
#mysql #mongodb #database
✅ Follow Me:
Blog: anonystick.com
Facebook: / tipjs
KZbin: / tipsjavascript

[@duyettran7919]

Em rất thích nghe những video về phân tích như này , thật sự hay .Cảm ơn anh đã chia sẻ.

[@anonystick]

Comment này tôi biết bạn đã xem hết. Có những bạn bỏ qua những phân tích trong video..

[@VuNguyen-yj5wi]

hay quá a ơi, mong a ra nhiều video kiểu này nữa ạ!

[@vanxuan7883]

Thanks bác, giải pháp phân tán dữ liệu hay. Hóng bí kíp $

[@congquyen2032]

Video rất hay, e cảm ơn những chia sẻ của a ❤️

[@anonystick]

Cảm ơn em

[@tochaocau]

Cái này có thế dùng consistent hashing để băm kết hợp virtual node để scale up an toàn

[@parashao5360]

Dạ cho e hỏi cách này khác gì với partion table ạ. Hy vọng anh có 1 video so sánh 2 cái này ạ, Chúc a 1 ngày tốt lành!

[@QuyNguyen-ct6yr]

A ơi làm video về filter delay queue đi a

[@nguyentrong750]

Cái kỹ năng trong video gọi là sharding database mình ko biết problem cuối chủ kênh có solution gì đó khủng hơn so với thế giới ko nhưng trong thực tế mn có thể dùng thêm 1 distributed search database như elasticsearch.

[@anonystick]

Không phải "sharding database" nếu nói đến chủ đề đó là phải giải thích khác còn ở đây tập trung vào dữ liệu con thôi chứ nói đến vấn đề bạn đưa ra nó còn ghê hơn nữa..., cũng như "elasticsearch" cũng là chuyện khác nữa.

[@nguyentrong750]

À vì mình thấy chủ kênh bảo phải mất tiền gi đó nên mình nghĩ nó phải dùng đến sharding, còn đơn thuần là partitioning thì mọi thứ nó đơn giản để giải quyết cái vấn đề trong video cũng có rất nhiều cách, thậm chí những version db hiện tại nó support scan trên toàn partitioning cũng rất nhanh rồi.

[@anonystick]

@@nguyentrong750 Anh chưa xem hết video nên comment không đúng với case trên. Nếu partitioning thì tôi không cần đưa ra những Thuật Toán và 4 biện pháp trên.

[@quanao6121]

@@anonystick e vẫn chưa hiểu lắm tại sao lại chia 1 bẳng thành 3(cụ thể 1 số thôi) bảng như anh nói. Thế 3 bảng con kia là 3 bảng mới hay chỉ là 3 bảng tạm thôi?

[@tiendatbui5405]

Anh có thể làm 1 video phân tích về sharding database như ở cuối vid không ạ vì nó có khá nhiều vấn đề (mất cân bằng dữ liệu, sử dụng thuật toán consitent hashing...). Cảm ơn a đã chia sẻ.

[@anonystick]

Để anh xem cách giải thích thế nào? Chứ sợ không biết cách chia sẻ, nó lại rối.

[@phucnguyen-tr3bd]

kkkk

[@thuongson8086]

Thanks a, vậy cho e hỏi trường hợp module theo userID ở ví dụ cuối của a nếu gặp bài toán cần thống kê 1 sản phẩm được bán cho bao nhiêu khách hàng thì lại phải thiết kế khác ạ?

[@anonystick]

Em. Rate cái đó có khi 1 năm hay 1 quý mới thực hiện nghĩa là rate read vs ửite thoải mái

[@dragon7083]

Anh ơi anh có dạy học không ạ, em muốn tham gia khoá học của anh nếu có ạ.

[@anonystick]

Không em. Thời gian chả có nữa á em. Sr em nhé

[@tangvu3703]

Anh có nhận đào tạo học viên không anh

[@thanhtung738]

Anh ơi, nếu dữ liệu mà nó cứ tăng mãi, trong khi số lượng collection của mongo nó đạt limit rồi hoặc là số lượng table nó quá nhiều rồi thì như vậy sẽ xử lý tiếp theo như thế nào anh?

[@anonystick]

modulo tiếp em. Sub-collection

[@truongduy270]

chào anh, cho e hỏi là trong trường hợp mở rộng số table lên vd: từ 3 -> 5 thì đơn hàng user _6 ban đầu được đưa vào table 0, sau khi mở rộng thì tính toán bảng lưu của user _6 lại ở table 1, vậy hướng có cách nào xử lý cho case này không ạ ?

[@anonystick]

Chạy background chia lại em. Giống như đập ra xây lại vậy. Mà cũng đúng thực tế như em nói, mới đầu mình không tính được mấy chuyện này, nhưng khi bussiness lớn thì mình cần phải xây lại.

[@truongduy270]

@@anonystick cảm ơn a. có thời gian a nói về ELK và demo nhé a.

[@ThangLe-pd6tk]

@@anonystick Ngoài vấn đề như bạn Trường Duy ở trên em thấy còn vấn đề như sort thì xử lý sao anh. Giả sử mình cần phải sort theo 1 tiêu chí nào đó chẳng hạn như ngày tạo order, hoặc order nào có tổng tiền lớn nhất, nhỏ nhất.

[@anonystick]

Có rồi á. Chờ up thôi em

[@anonystick]

Phần cuối á em. Dùng modulo của user. Em tinh ý đấy

[@TuanAnh-yl9rx]

lúc đầu mình chia 3 nhưng sau 1 thời gian dữ liệu quá nhiều cần chia 5 thì mình migrate lại data đúng ko a?

[@anonystick]

Để vậy thôi. Không cần migrate..

[@trunganhtruongngoc2861]

​@@anonystick a ơi cho e hỏi, nếu để như vậy mà ko chia lại, vậy thì dữ liệu nó mất cân bằng giữa các database thì sao a, trường hợp dùng modulo

[@ThacHungDev]

​@@trunganhtruongngoc2861 giả sử chia 3 mà full cả 3 thì bạn sẽ tạo ra 4,5,6 đúng ko? thế thì vẫn là modulo nhưng +1