Bài toán này tăng tốc độ query tìm kiếm trên hierarchy tree, nhưng mục tiêu là cây ít bị thay đổi vì có quá nhiều workload cho việc insert/update các node. Chỉ nên áp dụng cho các bài toán có cây tương đối ổn định, chỉ read hoặc dc update ở phía admin site và rất ít khi thay đổi. Trên bài wiki họ còn đưa example là clothing store catalog là phù hợp. Bạn đưa ra và apply vào bài toán đối với comment thì nó không phù hợp nên sẽ xảy ra nhiều luồng suy nghĩ khác nhau cho người xem. Các clip của bạn rất hữu ích cho người mới để hiểu sâu sắc hơn về javascript cũng như thuật toán, nhưng cần đưa use cases cụ thể hơn để mọi người có cái overview rõ ràng và apply đúng đắng hơn. Thank bạn rất nhiều vì sự đóng góp cho cộng động.
a giải thích hay quá ạ, mà còn phần update thì nên sử dụng loại nào, hay có loại nào cân bằng ( cũng có đánh đổi lại performene read) giữa read và update không anh?
Mới theo dõi kênh của a dc hơn tuần nay, thật sự một kênh lập trình quá hay, quá bổ ích. Xem nội dung của a e như khai phá thêm kiến thức về thế giới lập trình. Cám ơn a nhiều
lâu lâu ,anh lại lên mấy video về DB với các trick xử lý như này rất là hay . Em ko học nodejs nên em rất thích xem video như này. Mong anh ra nhiều hơn ạ.
Cái này nó giống kiểu Left Node Right hoặc là Deep First Search trong thuật toán nhưng mà nó chỉ same same thôi chứ ko phải 100%, nhưng đc cái là học mấy thuật toán rồi, anh giải thích cái là liên tưởng được, cái đau đầu ở đây là mỗi lần thêm vào phải sử lý logic các kiểu nữa, nhưng mà cũng ko phải vấn đề lớn, lúc học CTDL> ở trường thì em thấy nó chả có tác dụng gì nhưng bây giờ xem ra cũng có tác dụng rồi haha
@@anonystick Vâng anh, nhưng ko biêt bao giờ mới có thể đạt đến trình độ đó, và theo anh thì để làm những task liên quan nhiều đến thuật toán như thế, mình phải nên join vô các công ty lớn ko anh, hoặc làm như thế nào chứ em thấy 99% các dev ở trình độ < 5 năm thì ko dụng đến nhiều thuật toán, anh thấy sao ạ
Thực sự rất cảm ơn anh, rất hay anh ạ. Bên em đang lưu sparkjob ở mông theo kiểu array và không tối ưu tìm kiếm lắm. Hiện tại bên em đang có yêu cầu vẽ lineage của meta data, mà hạ tầng triển khai datahub hay openmetadata còn nhiều vướng mắc quá anh ạ. Anh có thể gợi ý cho em về lineage có thể xử lí như thế nào được không ạ
mình có thắc mắc . Vấn đề hiện tại của Nested set model là insert lâu . vậy kết hợp thêm parent child thì sẽ thêm cột mà nhiệm vụ mỗi lần insert cho th nested set không thay đổi thì việc thêm 1 cột cho parent child có thể giúp được gì . Hay mình đang hiểu chưa đúng cách kết hợp. Bạn giải thích giúp mình với.
@@duyettran7919 việc insert mình nói với sql thôi nó sẽ bị database lock hoặc record lock vì phải build lại nguyên cây chỉ mục left right tùy theo từng trường hợp nếu dữ liệu ít thì nested set model có hay ko cũng vậy nhưng đối với dữ liệu hàng triệu bản ghi như bài toán comment thì coi như sẽ lock cả bảng nên là đánh parent child trước xong sau đó xử lý bulk update theo block độ ưu tiên dựa theo timestamp (thời gian gọi xa nhất) để update trc còn còn các record dùng để display sẽ update sau vì gọi đệ quy 2 cấp kèm phân trang ko quá lâu
@@duyettran7919 thêm nữa trong nested set model có thêm định nghĩa là leaf_index (level của node - hay trong bài toán này còn gọi là tầng comment) việc hiển thị sẽ chỉ cần tầng 1 hoặc 2 kịch kim là 3 nên đánh index left right để sau ko vấn đề, đánh parent child trước kèm leaf_index. Đây là 2 bài toán "giữ chỗ" và "xếp chỗ" mà mình vẫn hay gọi
@@duyettran7919 quan trọng là comment nó ko phải là từng comment đẩy vào mà là rất nhiều comment đẩy vào 1 lúc nên không thể lúc nào có comment là build lại cây index được khi đó thà ko đung nested set model thì hơn
chỉ cần +2 left right cho tất cả các node lớn hơn giá trị đầu của node cha thôi, các node còn lại không bị ảnh hưởng, vd như thêm 1 child vào node 14-15 trong video thì chỉ +2 cho 15 trở đi, node 14-15 thành 14-17, có child là node mới thêm 15-16
Giả sử như em thêm 2 comment reply của comment 1.1.1.2(Jackets) thì em sẽ phải sửa 1 loạt các comment phía sau. comment 1.1.1.2 left: 6 right 11, comment 1.1.1.2.1 left 7, right 8. comment 1.1.1.2.2 left 9, right 10. đúng không anh? Case đọc nhiều, ghi ít thì cách này ok ạ. Còn case đọc nhiều, ghi nhiều thì sẽ làm ntn ạ?
thực ra thì phải sửa tất cả bên nhánh 1.2 nữa, nhưng k phức tạp như bạn nghĩ đâu, việc insert sẽ chia ra làm những bước sau: - Tính width cần extend, ở đây bạn thêm 2 node, thì width là 4 - Tìm ra left right của node cha, ở đây là 6-7 - Cộng tất cả value nào lớn hơn left của node cha với width, nghĩa tất cả giá trị left right >6 đều được +4. Node cha cũng sẽ tăng right từ 6-7 thành 6-11 - Thêm 2 node con vào, tính từ node cha +1, ở đây là 2 node mới 7-8 và 9-10 2 field left right được indexing nên việc tìm và thao tác sẽ rất nhanh, kể cả với số lượng cmt lớn lên đến hàng nghìn. Nếu việc insert cmt được thực hiện theo queue thì có thể skip được cả bước tính width
Bài toán này tăng tốc độ query tìm kiếm trên hierarchy tree, nhưng mục tiêu là cây ít bị thay đổi vì có quá nhiều workload cho việc insert/update các node. Chỉ nên áp dụng cho các bài toán có cây tương đối ổn định, chỉ read hoặc dc update ở phía admin site và rất ít khi thay đổi. Trên bài wiki họ còn đưa example là clothing store catalog là phù hợp.
Bạn đưa ra và apply vào bài toán đối với comment thì nó không phù hợp nên sẽ xảy ra nhiều luồng suy nghĩ khác nhau cho người xem. Các clip của bạn rất hữu ích cho người mới để hiểu sâu sắc hơn về javascript cũng như thuật toán, nhưng cần đưa use cases cụ thể hơn để mọi người có cái overview rõ ràng và apply đúng đắng hơn. Thank bạn rất nhiều vì sự đóng góp cho cộng động.
Doc cua Mongodb cung luu y chi su dung cho cac tree it bien doi, chu comment phat sua left voi right cua tat ca cac comment con lai thi...
a giải thích hay quá ạ, mà còn phần update thì nên sử dụng loại nào, hay có loại nào cân bằng ( cũng có đánh đổi lại performene read) giữa read và update không anh?
Bạn nói đúng, khi dữ liệu càng to, effort cho việc re-order rất lớn
mình cũng thấy nhược điểm nó ngay từ khi đánh số. Khi insert một comment vào thì số phải được đánh lại từ thằng insert. Dẫn đến ảnh hưởng rất to lớn.
Mới theo dõi kênh của a dc hơn tuần nay, thật sự một kênh lập trình quá hay, quá bổ ích. Xem nội dung của a e như khai phá thêm kiến thức về thế giới lập trình. Cám ơn a nhiều
Cảm ơn em nhiều, chúng ta có duyên với nhau rồi, giờ mới gặp thôi...
Bác ơi. Bác dạy tuyệt vời ạ
lâu lâu ,anh lại lên mấy video về DB với các trick xử lý như này rất là hay . Em ko học nodejs nên em rất thích xem video như này. Mong anh ra nhiều hơn ạ.
OK em, tks em!
hay quá ạ ... vừa hôm trc e đang ngồi nghĩ về cái nested comments này thì nay thầy ra video ạ ^^
Duyên tới rồi em.
quá đỉnh luôn anh Likeeee
cảm ơn em.
Mong chờ video thực hành cả mongodb và sql
Cam on anh đã chia sẻ
Like cho bác tips
Hay quá anh :)
Cái mô hình đầu tiên 09:46 nó dựa trên depth first search ae à
cái này giống cấu trúc node cây nhị phân ấy nhỉ
xịn quá xịn
ngồi xem ỗng đánh số trong khi đã có bên kia đánh số sẵn rồi, làm ơn lần sau vô thẳng vấn đề.
THỜI GIAN CỦA BẠN RẤT QUÝ.. TÔI CŨNG VẬY... CÙNG NHAU TẬN HƯỞNG. TÔI ĐÂU CÓ MUỐN ĐÁNH SỐ LẠI...
cảm ơn anh đã chia sẽ kiến thức rất hay, em hỏi thêm, làm sao create new 1 comment mà vẫn giữ được cấu trúc left-right đúng?
Cái này nó giống kiểu Left Node Right hoặc là Deep First Search trong thuật toán nhưng mà nó chỉ same same thôi chứ ko phải 100%, nhưng đc cái là học mấy thuật toán rồi, anh giải thích cái là liên tưởng được, cái đau đầu ở đây là mỗi lần thêm vào phải sử lý logic các kiểu nữa, nhưng mà cũng ko phải vấn đề lớn, lúc học CTDL> ở trường thì em thấy nó chả có tác dụng gì nhưng bây giờ xem ra cũng có tác dụng rồi haha
No no, do thông thường chúng ta làm những task nhẹ. Nhưng nếu thay đổi thế giới thì các devs level xxx thì thuật toán như cơm bữa.
@@anonystick Vâng anh, nhưng ko biêt bao giờ mới có thể đạt đến trình độ đó, và theo anh thì để làm những task liên quan nhiều đến thuật toán như thế, mình phải nên join vô các công ty lớn ko anh, hoặc làm như thế nào chứ em thấy 99% các dev ở trình độ < 5 năm thì ko dụng đến nhiều thuật toán, anh thấy sao ạ
Hay
Anh làm về kiểm thử database đi ạ
Thực sự rất cảm ơn anh, rất hay anh ạ. Bên em đang lưu sparkjob ở mông theo kiểu array và không tối ưu tìm kiếm lắm. Hiện tại bên em đang có yêu cầu vẽ lineage của meta data, mà hạ tầng triển khai datahub hay openmetadata còn nhiều vướng mắc quá anh ạ. Anh có thể gợi ý cho em về lineage có thể xử lí như thế nào được không ạ
Anh ơi, cách lưu trữ như này rất là hay ạ, nhưng mà em vẫn thắc mắc là mình sẽ phân trang kiểu như nào với cấu trúc dữ liệu như này ạ?
Giống FB á em. Lấy cha trước, khi click vào cha thì lấy con...
Nested insert chậm nhưng query nhanh thế nên là nên kết hợp cả Nested set model vs parent child
mình có thắc mắc . Vấn đề hiện tại của Nested set model là insert lâu . vậy kết hợp thêm parent child thì sẽ thêm cột mà nhiệm vụ mỗi lần insert cho th nested set không thay đổi thì việc thêm 1 cột cho parent child có thể giúp được gì . Hay mình đang hiểu chưa đúng cách kết hợp. Bạn giải thích giúp mình với.
@@duyettran7919 việc insert mình nói với sql thôi nó sẽ bị database lock hoặc record lock vì phải build lại nguyên cây chỉ mục left right tùy theo từng trường hợp nếu dữ liệu ít thì nested set model có hay ko cũng vậy nhưng đối với dữ liệu hàng triệu bản ghi như bài toán comment thì coi như sẽ lock cả bảng nên là đánh parent child trước xong sau đó xử lý bulk update theo block độ ưu tiên dựa theo timestamp (thời gian gọi xa nhất) để update trc còn còn các record dùng để display sẽ update sau vì gọi đệ quy 2 cấp kèm phân trang ko quá lâu
@@duyettran7919 thêm nữa trong nested set model có thêm định nghĩa là leaf_index (level của node - hay trong bài toán này còn gọi là tầng comment) việc hiển thị sẽ chỉ cần tầng 1 hoặc 2 kịch kim là 3 nên đánh index left right để sau ko vấn đề, đánh parent child trước kèm leaf_index. Đây là 2 bài toán "giữ chỗ" và "xếp chỗ" mà mình vẫn hay gọi
@@duyettran7919 quan trọng là comment nó ko phải là từng comment đẩy vào mà là rất nhiều comment đẩy vào 1 lúc nên không thể lúc nào có comment là build lại cây index được khi đó thà ko đung nested set model thì hơn
@@daokhoinguyen bác có bài nào nói về cái này không bác , em đọc chưa thấm được ý bác
nhìn giống cái giải thuật cây nhị phân vậy a
Không em! Xem cách tổ chức dữ liệu nó khác nhau!
nice
a cho e hỏi, hk có credit card thì có cách nào khác để tham gia hội viên hk ạ
Momo á em, nghe các bạn làm được vậy
visa debit á bạn hầu như bank nào củng có ra bank mở dùng chung vs thẻ Atm hiện tại được
mk dùng android vào CH play xong connect tới Viettel Telecom trong mục phương thức thanh toán, xong bạn đăng kí hội viên là được ắ :'v
Khi update thì lại tốn công đánh lại tree. Hệ thống update thường xuyên thì tốn tài nguyên update lại ghê lắm đây
Cách này mỗi lần insert phải đánh lại left và right cho toàn bộ cây phải không anh?
Đúng, nhưng không chậm như chúng ta nghĩ. Thuật toán mà.
chỉ cần +2 left right cho tất cả các node lớn hơn giá trị đầu của node cha thôi, các node còn lại không bị ảnh hưởng, vd như thêm 1 child vào node 14-15 trong video thì chỉ +2 cho 15 trở đi, node 14-15 thành 14-17, có child là node mới thêm 15-16
Giả sử như em thêm 2 comment reply của comment 1.1.1.2(Jackets) thì em sẽ phải sửa 1 loạt các comment phía sau.
comment 1.1.1.2 left: 6 right 11, comment 1.1.1.2.1 left 7, right 8. comment 1.1.1.2.2 left 9, right 10. đúng không anh?
Case đọc nhiều, ghi ít thì cách này ok ạ. Còn case đọc nhiều, ghi nhiều thì sẽ làm ntn ạ?
thực ra thì phải sửa tất cả bên nhánh 1.2 nữa, nhưng k phức tạp như bạn nghĩ đâu, việc insert sẽ chia ra làm những bước sau:
- Tính width cần extend, ở đây bạn thêm 2 node, thì width là 4
- Tìm ra left right của node cha, ở đây là 6-7
- Cộng tất cả value nào lớn hơn left của node cha với width, nghĩa tất cả giá trị left right >6 đều được +4. Node cha cũng sẽ tăng right từ 6-7 thành 6-11
- Thêm 2 node con vào, tính từ node cha +1, ở đây là 2 node mới 7-8 và 9-10
2 field left right được indexing nên việc tìm và thao tác sẽ rất nhanh, kể cả với số lượng cmt lớn lên đến hàng nghìn. Nếu việc insert cmt được thực hiện theo queue thì có thể skip được cả bước tính width
❤
🥰
Anh có thể giới thiệu và hướng dẫn recommendation system sử dụng thuật toán Collaborative filtering. Em cảm ơn anh rất nhiệu ạ.
Được chứ, sắp tới comment, notification, suggestion...
ko có video 51 hả anh
Chết quên đánh index kaka
ban nhạc bắc ninh . hehe
cho a 1 like 1 cmt :v
tks em nhiều!
thế thì kiểu này insert cực kì lâu
Không em. Xem thực hành em sẽ biết. Joe tiến sĩ mà em...
Kiến trúc BTree
quá khinh khủng
🥰