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
KZread: / tipsjavascript
Пікірлер: 35
Thanks bác, giải pháp phân tán dữ liệu hay. Hóng bí kíp $
hay quá a ơi, mong a ra nhiều video kiểu này nữa ạ!
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..
Video rất hay, e cảm ơn những chia sẻ của a ❤️
@anonystick
Жыл бұрын
Cảm ơn em
Cái này có thế dùng consistent hashing để băm kết hợp virtual node để scale up an toàn
A ơi làm video về filter delay queue đi a
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?
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!
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
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
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é
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
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
Anh có nhận đào tạo học viên không anh
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
7 ай бұрын
@@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