Ok bạn,. Database đã support sẵn lock, ví dụ như lock trên row, lock trên table... khi một record đc insert/update. Một cách nữa để xử lý vấn đề này đó là sử dụng versioning cho row, nếu đã dùng hibernate thì nó có support điều này. Đó là các cơ chế để đảm bảo không có race-condition trong database.
Về ví dụ của bạn, mình chưa rõ câu hỏi lắm, bạn muốn hỏi về trong 0,5s có 100 async request, mỗi request thực hiện cộng giá trị 1 thêm 1. Với 100 request giá trị là 100, 10k request giá trị là 10k?
Trước hết cần xác định mục tiêu của giá trị đó cần phải như thế nào. Có cần đảm bảo response ngay không, cần update kịp thời ngay lập tức không hay chỉ là giá trị mang tính monitoring, theo dõi các kiểu.
Nếu chỉ là giá trị monitoring, k cần realtime thì có thể đẩy nó sang cache, và có window để cập nhật. Ví dụ 100 request hoặc 10s tùy đkiện nào đến trước. Nếu cần realtime, bạn có 2 phương pháp, 1 sử dụng lock dưới tầng db, 2 async request response về client trước, sau đó thực hiện sync đến database để đảm bảo client đc giải phóng. Việc update mình sẽ handle sau đó với cơ chế mutex: có rất nhiều cách như lock, sync, dùng atomic variable... các bài trước mình có đề cập đến.
REST mà chia ra mỗi action 1 Controller là quá rườm rà, phân tán không cần thiết. Nên gộp chung vào 1 Controller, vd MaterialController
Đã dùng Laravel thì đừng bao giờ có new Class trong code, Service Provider để làm gì? Sau cần kế thừa class thì có mà to tay.
MaterialPostController.php: dùng materialRepository nào là do MaterialPostApplicationService quyết định, không phải do Controller.
Việc validate dữ liệu nên làm như Laravel, thực hiện ngay từ trước khi vào Controller, thực hiện validate khi đã vào tận MaterialPostApplicationService mình nghĩ không nên.
MaterialPostApplicationService.php: việc bắt đầu DB::beginTransaction() trước cả materialRepository->create mình nghĩ là vô nghĩa vì chưa xử lý gì DB cả. Hơn nữa nếu chỉ có create thì mình nghĩ cần gì beginTransaction với try catch, khác gì nhau đâu?
MaterialPostCommand.php nên cho truyền vào array có key value, rồi bên trong set get gì tùy bạn. Có tầm 10 cái thuộc tính mà set get ở ngoài như bạn mình thấy mệt quá.
Tác giả có thể viết 1 bài về đồng bộ request trong database được k.
Ví dụ spring boot mỗi request là bất đồng bộ.
Các request đó đều trỏ update 1 object (user có.1 trường giá trị là 1). Mỗi request mất 0.5
Trong 0.5s đó có 100 request như thế làm thế nào ra đc kết quả 100
Nếu nhân 100 user request 100 lần là 10k request làm sao đảm bảo thời gian và kết quả đúng nhất
T1 Có sẵn tool EXPLAIN ANALYZE trong DBMS luôn đó em, em đọc cái bài sau trong series để biết cách dùng và cách đọc nhé.
T2 khi code nên có log để biết query nào chậm và cải tiến dần, ban đầu db chưa lớn thì ksao, nhưng sau đó lương data lên rất nhanh thì mình đã có log và có tool để xử lý r.
T3 phải monitoring cả DB server vì query chậm có thể là do khi đó CPU hoặc I/O gặp vđề hoặc thậm chí network chứ k phải do query.
T4 nếu dùng các DB có Enterprise, có rất nhiều tool họ cung cấp, sẽ có các report chi tiết luôn.
Đấy là một vài cách a biết, hy vọng trả lời đc câu hỏi của em.
Chào bạn. Bạn cho mình hỏi: Để có thể làm được bảng tổng hợp kiểu như thế này [https://youtu.be/AorNdcSqcH8] thì mình nên học gì ạ? Mình muốn dùng để hỗ trợ và quản lý học sinh nhưng không biết làm (mà liên hệ với người tạo để chuyển giao mà họ không đồng ý). Xin lỗi nếu làm phiền bạn.
THẢO LUẬN
đệ tự này cũng đỉnh quá c k dám nhận đâu
@haialison Tài liệu thì mình k có vì trước toàn bộ tài liệu là mình ôn trên web học tập của công ty mình. b lên udamy tìm mua 1 khóa học trên đấy rồi học cũng đc b ạ https://www.udemy.com/course/aws-certified-solutions-architect-associate-saa-c02/ mình thấy có khóa này đang đc đánh giá cao
Ok bạn,. Database đã support sẵn lock, ví dụ như lock trên row, lock trên table... khi một record đc insert/update. Một cách nữa để xử lý vấn đề này đó là sử dụng versioning cho row, nếu đã dùng hibernate thì nó có support điều này. Đó là các cơ chế để đảm bảo không có race-condition trong database.
Về ví dụ của bạn, mình chưa rõ câu hỏi lắm, bạn muốn hỏi về trong 0,5s có 100 async request, mỗi request thực hiện cộng giá trị 1 thêm 1. Với 100 request giá trị là 100, 10k request giá trị là 10k?
Trước hết cần xác định mục tiêu của giá trị đó cần phải như thế nào. Có cần đảm bảo response ngay không, cần update kịp thời ngay lập tức không hay chỉ là giá trị mang tính monitoring, theo dõi các kiểu.
Nếu chỉ là giá trị monitoring, k cần realtime thì có thể đẩy nó sang cache, và có window để cập nhật. Ví dụ 100 request hoặc 10s tùy đkiện nào đến trước. Nếu cần realtime, bạn có 2 phương pháp, 1 sử dụng lock dưới tầng db, 2 async request response về client trước, sau đó thực hiện sync đến database để đảm bảo client đc giải phóng. Việc update mình sẽ handle sau đó với cơ chế mutex: có rất nhiều cách như lock, sync, dùng atomic variable... các bài trước mình có đề cập đến.
Đã xem Codesanbox của bạn, và không thấy vấn đề gì như bạn đã mô tả cả.
Mình có một số góp ý với bạn như sau:
Tác giả có thể viết 1 bài về đồng bộ request trong database được k. Ví dụ spring boot mỗi request là bất đồng bộ. Các request đó đều trỏ update 1 object (user có.1 trường giá trị là 1). Mỗi request mất 0.5 Trong 0.5s đó có 100 request như thế làm thế nào ra đc kết quả 100 Nếu nhân 100 user request 100 lần là 10k request làm sao đảm bảo thời gian và kết quả đúng nhất
Bài viết rất hay. Thank you!!!
@luongvanphuc post kinh nghiêm đi bạn ơi
Bài viết hữu ích và ví dụ dễ hiểu. Cảm ơn bạn nhé
Cám ơn bạn
thanks a ạ
Chaò bạn. Có thể cho mình xin bộ dataset này được không? hoaidtk@gmail.com Cảm ơn bạn nhiều
không cần dùng
substackở eq cuối em nhé, với cả dùng$$ $$(hoặc\( \)) để eq vào giữa trang (display mode)Bài viết rất hay. Cảm ơn tác giả, mình mới vọc aws nên đọc qua cái này đỡ thiệt
Có cách nào để custom lại cái trang login k bạn nhỉ?
nếu được thì em có thể xin facebook của anh để em có thể nhờ anh giúp đỡ được không ạ.
Cứ tưởng em họ Trương
T1 Có sẵn tool EXPLAIN ANALYZE trong DBMS luôn đó em, em đọc cái bài sau trong series để biết cách dùng và cách đọc nhé.
T2 khi code nên có log để biết query nào chậm và cải tiến dần, ban đầu db chưa lớn thì ksao, nhưng sau đó lương data lên rất nhanh thì mình đã có log và có tool để xử lý r.
T3 phải monitoring cả DB server vì query chậm có thể là do khi đó CPU hoặc I/O gặp vđề hoặc thậm chí network chứ k phải do query.
T4 nếu dùng các DB có Enterprise, có rất nhiều tool họ cung cấp, sẽ có các report chi tiết luôn.
Đấy là một vài cách a biết, hy vọng trả lời đc câu hỏi của em.
@thuanbnb mình thấy StartBlock với EndBlock chỉ cách nhau 1 block thôi, nên khi check require thì gặp lỗi
Chào bạn. Bạn cho mình hỏi: Để có thể làm được bảng tổng hợp kiểu như thế này [https://youtu.be/AorNdcSqcH8] thì mình nên học gì ạ? Mình muốn dùng để hỗ trợ và quản lý học sinh nhưng không biết làm (mà liên hệ với người tạo để chuyển giao mà họ không đồng ý). Xin lỗi nếu làm phiền bạn.
cảm ơn ông, từ bữa viblo bị sự cố đến bây giờ tôi vào lại mới để ý là mất hình